What Russ said here is important. However, I don't see any reason that this record should not be protected.
I also think that we can use a content type outside of the scarce range we have for TLS record content types. This only makes sense for use with DTLS 1.3 and DTLS 1.2 with connection IDs, so we can rely on the content type being encrypted. That means multiplexing constraints don't apply (they probably wouldn't anyway as this makes no sense for use with ICE). Finally, I think that the flexible size of the cookie is not necessary. Pick a fixed size. Unlike the handshake cookie, there is no reason for this to be stateless. (I also wouldn't call it a cookie.) The comments that Martin Duke currently has on the connection ID regarding path validation rules apply more fully here than they do on that draft. Perhaps we could fix them here. On Wed, May 5, 2021, at 04:12, Russ Housley wrote: > This document seems fine to me, but the first paragraph of Section 3 > needs some work. This can be sorted out after adoption. > > Section 3 begins with: > > When a record with CID is received that has the source address of the > enclosing UDP datagram different from the one previously associated > with that CID, the receiver MUST NOT update its view of the peer's IP > address and port number with the source specified in the UDP datagram > before cryptographically validating the enclosed record(s) but > instead perform a return routability check. > > I agree that the return routability check should be performed before > updating the peer's IP address and port number, but I the part about > "before cryptographically validating the enclosed record" seems to open > up some opportunities for trouble. > > Russ > > > > On May 3, 2021, at 11:44 AM, Sean Turner <s...@sn3rd.com> wrote: > > > > Hi! > > > > We would like to re-run the WG adoption call for "Return Routability Check > > for DTLS 1.2 and DTLS 1.3”. Please state whether you support adoption of > > this draft as a WG item by posting a message to the TLS list by 2359 UTC 24 > > May 2021. Please include any additional information that is helpful in > > understanding your position. > > > > NOTES: > > > > 1) We are re-running this WG adoption now that DTLS 1.3 [1] and Connection > > Identifiers for DTLS 1.2 [2] is done. > > 2) Here is a link to the original WG adoption call [3]. > > > > Thanks, > > Chris, Joe, and Sean > > > > [1] https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/ > > [2] https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/ > > [3] https://mailarchive.ietf.org/arch/msg/tls/IJYqpTmSHsCkiMaUPt_AltvKbe8/ > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
