Re: [TLS] AD Evaluation of draft-ietf-tls-dtls13-39

[Eric Rescorla <[e-mail]>]

I have posted -41, which I believe to be ready for IETF LC

-Ekr


On Sun, Feb 7, 2021 at 12:36 PM Eric Rescorla <[e-mail]> wrote:

>
>
> On Fri, Feb 5, 2021 at 5:16 PM Benjamin Kaduk <[e-mail]> wrote:
>
>> Hi Ekr,
>>
>> Thanks for all the updates, and sorry to have dropped the ball over the
>> holidays.
>>
>> The changes in the -40 are basically all good, and I filed several PRs to
>> cover a few nits and places where you asked for suggested text.  (I see
>> you
>> merged most of them already; thanks!)  For everybody not getting
>> notifications for the githb repo, those are:
>>
>> https://github.com/tlswg/dtls13-spec/pull/208 (general nits)
>> https://github.com/tlswg/dtls13-spec/pull/209 (implementation pitfalls)
>> https://github.com/tlswg/dtls13-spec/pull/210 (anti-replay window per
>> epoch)
>> https://github.com/tlswg/dtls13-spec/pull/211 (implicit ACK)
>> https://github.com/tlswg/dtls13-spec/pull/212 (more security
>> considerations)
>>
>
> Thanks. I have merged these.
>
> The only other comment I had on the -40 that I didn't make a PR for is that
>> (now that we have the automation working to generate appendixes for the
>> procotol-description language) we don't actually show the new value for
>> ACK
>> as a ContentType anywhere!  It seems like we'd have to stick that in
>> Figure
>> 2 if we put it anywhere, though that's admittedly a bit disjointed from
>> where we actually start talking about the message in question.
>>
>
> Yeah, I think we can take a pass on this, but if someone has a clever
> idea, I'll
> take a PR.
>
> >
>> > > Section 4.5.3
>> > >
>> > > As mentioned above, we might mention any reduced limits due to
>> > > sequence-number protection (e.g., with ChaCha20) here, if they exist.
>> >
>> > Filed an issue:
>> > https://github.com/tlswg/dtls13-spec/issues/167
>>
>> It looks like we were maybe going to add a note saying that we don't know
>> the confidentiality bounds for multiple applications of RNE, but I don't
>> think we necessarily need to hold up for that.
>>
>
> MT and I discussed this and came to the conclusion it was OK because the
> nonce is 128-bits long and the bounds are much lower.
>
> https://github.com/tlswg/dtls13-spec/issues/167
>
>
>> > > (I note that a bit further on we say
>> > > "MUST create a new ClientHello ... [following] Section 4.1.2 of
>> > > [TLS13]", which seems to be enough of a normative requirement that the
>> > > "MUST" may not be needed here.)
>> > >
>> > >    The cookie extension is defined in Section 4.2.2 of [TLS13].  When
>> > >
>> > > Do we want to add any discussion of what is stored in the cookie
>> (other
>> > > than the RFC 2522-like address+ports and the ClientHello1 hash that
>> > > [TLS13] mentions), as mentioned in the thread at
>> > >
>> https://mailarchive.ietf.org/arch/msg/tls/QbteFvnk1H2K9OjfHGosuG9e9Rk/ ?
>> > > I am somewhat amenable to the stance that it's more appropriately done
>> > > in 8446bis.
>> >
>> > Yes, I think so.
>> > https://github.com/tlswg/tls13-spec/issues/1206
>>
>> This is still open (on 8446bis), but maybe my
>> https://github.com/tlswg/dtls13-spec/pull/212 covers some of the key
>> points for this document.
>>
>
> I think it does.
>
>
>> > > Section 5.3
>> > >
>> > > [Discussing ServerHello here for want of a better location.]
>> > >
>> > > We specify a ClientHello.legacy_version = {254,253}, but we seem to be
>> > > inheriting the unmodified TLS 1.3 ServerHello, complete with
>> > > ServerHello.legacy_version = 0x0303.  That seems problematic, since
>> the
>> > > legacy DTLS 1.2 ServerHello would use the expected {254,253} like the
>> > > ClientHello.
>> >
>> > https://github.com/tlswg/dtls13-spec/issues/170
>> >
>> >
>> > > Similarly, we should probably specify whether the sentinel
>> > > downgrade-protection Random values are used as-is from TLS 1.3, or if
>> we
>> > > have new ones for DTLS.
>> > > [end ServerHello topics]
>> >
>> > I don't think we need new ones. Don't we just inherit it?
>>
>> I think inheriting the same ones should work, protocol-wise.
>> I was only asking about mentioning them specifically sinnce their stated
>> semantics are tied to "if negotiating TLS 1.2" and "if negotiating TLS 1.1
>> or below", and a literal reading of those requirements doesn't make sense
>> for DTLS versions.
>>
>
> https://github.com/tlswg/dtls13-spec/pull/213
>
> > I don't think I understand you. This is a lockstep protocol so if you
>> > are sending the next flight, then the previous flight must have
>> > been received. In the post-handshake, you can run concurrent
>> > state machines.
>>
>> This was just an editorial comment, that the parenthetical "emptying the
>> buffer first" seems pretty vague about what is supposed to happen (and if
>> the buffer that's getting emptied is the same one used for "buffers them
>> for transmission").  My understanding of what's supposed to happen in
>> practice matches my understanding of your description here.
>>
>
> I changed it to "transmission buffer"
>
>>
>> > > The wording here is a bit amusing, as "up to no less than the ...
>> > > maximum" is facially nonsensical, but the RFC 6298 setting is in fact
>> > > the floor for the implementation-defined maximum.  I don't have a
>> clever
>> > > wording suggestion, though.
>> >
>> > Hmm.... I don't think it's nonsensical, because we're not bound
>> > by 6298, so that's just explaining where 60s comes from. How
>> > about:
>> >
>> >      and double
>> >      the value at each retransmission, up to no less than 60 seconds
>> >      (the maximum defined in RFC 6298)
>> >
>> > How does that sound?
>>
>> That reads better to me, but it's totally editorial (so, your call).
>>
>
> Done.
>
>
>> > >       encrypted.  This may improve correlation of packets from a
>> single
>> > >       connection across different network paths.
>> > >
>> > > I feel like the small width of the epoch field mitigates this somewhat
>> > > (though not fully).
>> >
>> > Sure.
>> >
>> >
>> > > Section 12.  Changes to DTLS 1.2
>> > >
>> > > This section is about changes *since* DTLS 1.2 (and I propose some
>> > > wording tweaks in my editorial PR).  But I think we should also
>> consider
>> > > whether we do need a section on "changes to DTLS 1.2", or rather
>> > > "changes affecting DTLS 1.2 implementations, along the lines of
>> > > https://tools.ietf.org/html/rfc8446#section-1.3 ("Updates Affecting
>> TLS
>> > > 1.2").
>> >
>> > Do you have some proposed contents?
>>
>> Having not actually implemented it, not really :)
>>
>> But skimming through, it seems like maybe
>>
>> - the AEAD limits might be worth using for TLS 1.2 as well
>>
>
> We didn't do this in 1.3 I don't believe, so I would not do it here either.
>
>
> - you have to do the downgrade protection HRR random values
>>
>
> - [the things that TLS 1.3 changed in TLS 1.2 probably also apply
>>
>
> https://github.com/tlswg/dtls13-spec/pull/214
>
> -Ekr
>
>