Re: [TLS] Comments on PR #95

[Eric Rescorla <[e-mail]>]

[Trimming aggressively]

On Wed, Dec 31, 2014 at 8:54 AM, Watson Ladd <[e-mail]> wrote:

> On Tue, Dec 30, 2014 at 3:19 PM, Eric Rescorla <[e-mail]> wrote:
> > Thanks again for the detailed comments.
> >
> >
> >
> <snip>
> >>
> >> Line 1119: Open issue #5. I've got to think about this one. Likely as
> >> not this will be a very complicated change, that makes TLS 1.3 a lot
> >> harder to implement.
> >
> >
> > Can you elaborate more on why you think that?
>
> Right now the key calculation is the same as TLS 1.2. Changing this to
> separate the generated nonce would be annoying. Probably the easiest
> solution is to not generate the nonce from the master secret, and so
> have all PRF outputs be used only as keys. But this has knock-on
> effects.


I don't think this is going to be too bad, but I guess we'll find out when
we go to do it :)



> >> Line 2995: A TODO DTLS, probably related to the possibility of the
> >> Update message being lost. I don't remember how DTLS deals with this
> >> in the handshake, but there data is not being sent with the new keys
> >> before the other side acknowledges receipt. Will think about it.
> >
> >
> > The general way you deal with this in the handshake is that the last
> > flight is used as an acknowledgement of the previous flight. The sender
> > of the previous flight has to retransmit until they receive the last
> flight
> > and the sender of the last flight has to keep their state around long
> > enough to be able to handle the retransmit or up to 2MSL.
> >
> > This general pattern should work here, but we need to work out the
> > details for DTLS, hence the TODO.
>
> I don't think this is right. After A sends an update, they change the
> encryption keys for data from A to B. Now if the update arrives late,
> we get a bad MAC when the data A sent arrives at B.
>

You'll have to update the DTLS epoch value so that you can distinguish
which set of keys it uses. In DTLS 1.2, the epoch was used for
rehandshake, but we don't need that here, so it's a natural fit.


> >> There does not seem to be a way to request a certificate in the update
> >> protocol.
> >
> >
> > This is deliberate.
>
> So how do servers tell clients what sorts of certificates they want?
> Are we kicking this to higher layers? This prevents drop in
> replacement as I seem to remember HTTP+client cert doesn't work like
> that.


The situation here is a bit messy.

In TLS 1.3 presently, the server sends a CertificateRequest which contains
the same information as it did in TLS 1.2. So we have a number of options
here:

1. Leave client auth as-is.
2. Have client auth in update but allowed only once with CertificateRequest
used
to indicate which certificate you expect.
3. Do client auth in update but with only application level signaling.
4. Some combination of these.

I don't think there's consensus on the best approach because it's partly
about interaction with upper layer semantics.

Best,
-Ekr