Re: Requirements for Secondary Certificates (#522)

On Tue, Apr 10, 2018 at 06:03:37PM +0000, Mike Bishop wrote:
> In my silliness, I thought there hadn’t been enough activity to
> warrant allocating time to Secondary Certs at IETF 101.  😊 
> Instead, we had a brief but lively discussion and hit on an
> important divergence of concerns where Secondary Certificates
> are concerned.
> 
> Let’s start by thinking about the threat model.  The attacker
> has obtained a certificate that’s valid for a victim origin. 
> There are two main ways this could happen:
> 
>   *   Misissuance
>   *   Key compromise
> Now the attacker wishes to convince users to contact it and
> believe it regarding the contents of the victim origin.

Also, the following occured to me recently. Even if secondary
certificates do incorporate secure nonce and thus one can not
pre-sign responses, the attack window is much larger than with
TLS key exchange. Thus, if if the certificate has RSAEncryption
key and the server is vulernable to BB98 (a.k.a. ROBOT), the
attacker might be able to obtain a signature.

> One proposal is to define a new OID and require it to be on any
> certificates that servers present as Secondary.  This poses
> substantial deployment problems. 

Yeah, that is going to have deployment problems.
 
> Another idea is to require the thing presented by the server to be,
> not a certificate, but a delegated credential (see draft-ietf-tls-subcerts). 
> However, that has very similar concerns since subcerts requires the
> certificate to explicitly opt in to Delegated Credentials.  That is
> a more general capability that people are likely to adopt more willingly. 
> The key compromise threat model looks almost exactly the same, though, since
> once the key is compromised you can mint a delegated credential.  (And
> there’s also the fact that it’s a -00 draft that probably has a lot more
> runway before it lands in browsers.)

Also, delegated credentials would be even more vulernable to BB98
(ROBOT) if used with RSAEncryption keys.


-Ilari

Received on Tuesday, 10 April 2018 18:43:30 UTC