On Fri, Feb 5, 2021 at 5:16 PM Benjamin Kaduk <ka...@mit.edu> 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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
