Hi John, Hi Ekr, I hope I correctly understand the essence of your conversation. I am wondering whether a link from the bullet list to the text two paragraphs down will help. Here is my proposal: https://github.com/tlswg/dtls-conn-id/pull/111
Ciao Hannes From: John Scudder <j...@juniper.net> Sent: Wednesday, April 21, 2021 2:07 AM To: Eric Rescorla <e...@rtfm.com> Cc: The IESG <i...@ietf.org>; draft-ietf-tls-dtls-connection...@ietf.org; tls-chairs <tls-cha...@ietf.org>; tls@ietf.org; Joseph Salowey <j...@salowey.net> Subject: Re: John Scudder's No Objection on draft-ietf-tls-dtls-connection-id-11: (with COMMENT) On Apr 20, 2021, at 7:24 PM, Eric Rescorla <e...@rtfm.com<mailto:e...@rtfm.com>> wrote: On Tue, Apr 20, 2021 at 3:42 PM John Scudder <j...@juniper.net<mailto:j...@juniper.net>> wrote: On Apr 20, 2021, at 5:32 PM, Eric Rescorla <e...@rtfm.com<mailto:e...@rtfm.com>> wrote: 3. Section 6: * There is a strategy for ensuring that the new peer address is able to receive and process DTLS records. No such strategy is defined in this specification. This is a little mind-boggling to me. I understand this to mean I can’t send the new address a DTLS record unless I’ve already ensured it can receive and process that record, right? This seems almost like a classic Catch-22. I feel like I must be missing something. This specification *only* allows you to mux, but doesn't allow you to migrate. We could probably make this point clearer. Yes, I think so. Various things led me to think this was supposed to be a feature. For starters, the abstract: A CID is an identifier carried in the record layer header that gives the recipient additional information for selecting the appropriate security association. In "classical" DTLS, selecting a security association of an incoming DTLS record is accomplished with the help of the 5-tuple. If the source IP address and/or source port changes during the lifetime of an ongoing DTLS session then the receiver will be unable to locate the correct security context. It’s true the abstract doesn’t promise that I can migrate to the new address, but I felt led in that direction. But more to the point, §6 itself: When a record with a CID is received that has a source address different than the one currently associated with the DTLS connection, the receiver MUST NOT replace the address it uses for sending records to its peer with the source address specified in the received datagram unless the following three conditions are met: If I understand your reply correctly, the quoted sentence could end “… unless the following three conditions are met (which will never happen):”. Since that seems both capricious and pointless, I still think I’m missing something. Is it that you envision a future specification that does define a strategy that will fulfill the third condition? Yes. Got it, thanks. In that case I think it brings us back to your earlier “we could probably make this point clearer”. —John IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
