Re: [TLS] Refactoring client auth/re-key

[Eric Rescorla <[e-mail]>]

Watson,

Thanks for your comments.

On Sat, Oct 18, 2014 at 4:15 PM, Watson Ladd <[e-mail]> wrote:

> On Sat, Oct 18, 2014 at 7:32 AM, Eric Rescorla <[e-mail]> wrote:
> >
> So I seem to remember DJB telling me that once you have a properly
> made channel via Diffie-Hellman, that authenticating requires just
> signing a value derived from the key. (Sadly I forgot/don't know the
> proof, so someone will have to check this or tell me I'm completely
> wrong) So we don't need the session hash to include the certificates,
> and so don't need to keep the running hash going past the first
> exchange.
>
> Concretely the idea would be as follows: A sends to B g^x, and B
> responds with g^y. Both calculate MS=H(g^xy, g^x, g^y). (Of course, we
> need to hash the actual messages.)
>
> At this point we can compute channel_AtoB_key=PRF(MS, "channel AtoB
> key"),  channel_BtoA_key=PRF(MS, "channel BtoA key"),
> A_authstr=PRF(MS, "A authstr"), B_authstr=PRF(MS, "B authstr"). The
> channel keys can be used to encrypt each side as in the proposal, and
> the authstrs can be signed and sent over the channel to provide a
> proof of identity.



Trying to think through this a bit, is this a generic comment on the
session-hash proposal even for TLS 1.2 where they are careful to
sign everything up to CertificateVerify? See:

https://tools.ietf.org/html/draft-ietf-tls-session-hash-02#section-4.1

Perhaps one of the authors of that document can weigh in here.

Best,
-Ekr