Re: [TLS] John Scudder's No Objection on draft-ietf-tls-dtls-connection-id-11: (with COMMENT)

[John Scudder <[e-mail]>]

On Apr 20, 2021, at 5:32 PM, Eric Rescorla <[e-mail]<mailto:[e-mail]>> wrote:

This seems like a pretty basic assumption. These aren't just notational conventions
or pseudo-code. They're the protocol description language that TLS is defined in.
If one isn't familiar with how to read this syntax, then you really don't have much of
a hope of correctly implementing this specification.

Be that as it may, the point about courtesy to the naïve reader stands.

[*] By the way, why not just use “255” in the text instead of “2^8-1”? Eschew
obfuscation!

Which one of these is clearer seems like a question of taste, I should think.
It's worth noting that because the length prefix is determined by the ceiling,
arguably 2^8-1 is clearer.

I don’t follow your point, but suit yourself.

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? That might be worth saying, if so.

Thanks,

—John