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

[Watson Ladd <[e-mail]>]

On Sat, Oct 18, 2014 at 9:10 AM, Eric Rescorla <[e-mail]> wrote:
> 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

That struck me as an implementation driven decision, since
implementations keep a running hash for the Finished message, which is
repurposed in the session hash proposal. Furthermore, what I  proposed
only works because we are sending the identities over a secure
channel: otherwise an attacker could remove the client authentication
and replace it with their own, thus causing both sides to disagree
over what the authentication status is.

The session hash was designed to be as minor a change as possible to
TLS 1.2. I've got no interest in mixing security improvements with
massive changes, as that slows adoption big time. While you could make
a similar change to TLS 1.2, it would be unnecessarily large.

My only other comment is that this is a much larger change than
1.1->1.2. Perhaps we really should be honest and call it TLS 2.0.

Sincerely,
Watson Ladd
>
> Perhaps one of the authors of that document can weigh in here.
>
> Best,
> -Ekr
>
>
>



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin