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

[Ilari Liusvaara <[e-mail]>]

On Sat, Oct 18, 2014 at 08:15:19AM -0700, Watson Ladd 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.

AFAIK, It is sufficient (dunno if DJB told that).

The idea is: Ensure that keys are unique, even in face of active
attack, and only the (true) endpoints can compute those.

This can be done by hashing in transcript of negotiation and key
exchange into keys obtained from DH.

This causes the following:
- If attacker does not tamper with key exchange, the session key
  becomes unknowable.
- If attacker does tamper with key exchange, the two sides will not
  agree about keys (since keys are unique), and later channel
  authentication will fail.
- Attacker can't replay captured credentials, because keys will
  then be different from anything seen so far (uniqueness).


There's a subtle trap here tho: The authentication messages have to be
exchanged via the channel itself, not out-of-band. Otherwise the
authentication is broken. Not much of an issue here.

> 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.)

That doesn't quite work (why?) :-)

Hint: What's missing (and it is not "certificate")?

> 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. Furthermore, we could extract a channel binding in
> an analogous manner, or application level keys in the same way, or a
> resumption key in the same way.

One subtle decision: Is there a split beween "system" (TLS uses
internally) and "user" keys (handed to application via TLS-EXTRACTOR).

One could imagine that with some of the proposals about fixing key
deriviation, some would want that.

Also, if there is no finished with nontrivial data, one would need
to derive a fake binding value for backward compatiblity (but that's
easy to do).


Also, due to some signature schemes having some real-world nonideal
properties, one wants to also throw the keys used into the message
(easiest way is to throw the whole certificate or hash thereof in).

Also, do client signatures need replay protection (prevents replaying
te same certificate in the same connection)?


Also, could be useful to have some sort of "label" along with client
certificate that gets notified along with the certificate to the
application.

The idea is that TLS would not process the client certificates more
than just validating the signature. Instead, if validation succeeds,
it would fire callback to application, reporting that certificate with
label X and contets Y has been successfully validated.

Then the application could calculate what to do with the certificate
and have latter communications refer to the certificate.

This is AFAIK needed with some applications (along with some more app-
level signaling) to use client authentication safely.


-Ilari