Re: [TLS] WGLC for draft-ietf-tls-cached-info-19

[Martin Thomson <[e-mail]>]

On 15 September 2015 at 20:12, Karthikeyan Bhargavan
<[e-mail]> wrote:
> I assume the client hello extension still has the certificate digest, yes?
> This means that the analysis probably relied on agreement of the certificate hash from the client hello.

This was only in the 1.3 context, and the certificate digest was
completely removed from the handshake...

It was pointed out to me separately that this doesn't work for static
RSA because you need to include the public key in the transcript there
to avoid having an attacker impose a PMS (one of the components of
triple-handshake).  That means that we need a strong hash for that
case.  However, if this is only used for PFS modes, then the analysis
suggests that we are OK to remove or truncate, assuming session-hash.

> For example, is it possible for a website to use the same public key on two certificates for two different purposes? Is it possible for an attacker to obtain a certificate from a CA for a public key even though it does not know the corresponding private key?

Does any of the existing analyses of TLS permit these changes?

If the same key is used for two different purposes, then the risk of
reaching a state where the purposes are confused seems to be too easy.

Similarly, if I can obtain a certificate for a key without
demonstrating proof of possession, then we're in a bad state.  I would
hope that the ACME protocol does not permit that, certainly this is a
fundamental part of the certificate signing request.