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

From: John Scudder <[email-masked]>
Date: Tue, 20 Apr 2021 22:42:26 +0000

On Apr 20, 2021, at 5:32 PM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> 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

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 20 Apr 2021 16:23:40 -0700

On Tue, Apr 20, 2021 at 3:42 PM John Scudder <[email-masked]> wrote:

> On Apr 20, 2021, at 5:32 PM, Eric Rescorla <[email-masked]> wrote:
>
> 3. Section 6:
>>
> 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:
>
> 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.

-Ekr

---

From: Rob Sayre <[email-masked]>
Date: Tue, 20 Apr 2021 16:32:54 -0700

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

The ECH (nee ESNI) spec says "All TLS notation comes from
[RFC8446], Section 3." Something like that should work fine here, in
"Conventions and Terminology".

It is true that most TLS projects have generic code for dealing with this
syntax.

thanks,
Rob

---

From: John Scudder <[email-masked]>
Date: Wed, 21 Apr 2021 00:04:29 +0000

> On Apr 20, 2021, at 7:33 PM, Rob Sayre <[email-masked]> wrote:
> 
> The ECH (nee ESNI) spec says "All TLS notation comes from [RFC8446], Section 3." Something like that should work fine here, in "Conventions and Terminology".

Yes, that would be fine from my point of view. 

—John

---

From: John Scudder <[email-masked]>
Date: Wed, 21 Apr 2021 00:07:15 +0000

On Apr 20, 2021, at 7:24 PM, Eric Rescorla <[email-masked]> wrote:

On Tue, Apr 20, 2021 at 3:42 PM John Scudder <[email-masked]<mailto:[email-masked]>> wrote:
On Apr 20, 2021, at 5:32 PM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:
3. Section 6:

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

---

From: Achim Kraus <[email-masked]>
Date: Wed, 21 Apr 2021 06:59:36 +0200

HI John,

Am 21.04.21 um 00:42 schrieb John Scudder:

> 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.
>

Yes, see
https://github.com/tlswg/dtls-conn-id/issues/103#issuecomment-822306643

best regards
Achim Kraus

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 21 Apr 2021 05:51:11 +0000

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 <[email-masked]>
Sent: Wednesday, April 21, 2021 2:07 AM
To: Eric Rescorla <[email-masked]>
Cc: The IESG <[email-masked]>; [email-masked]; tls-chairs <[email-masked]>; [email-masked]; Joseph Salowey <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> wrote:
On Tue, Apr 20, 2021 at 3:42 PM John Scudder <[email-masked]<mailto:[email-masked]>> wrote:
On Apr 20, 2021, at 5:32 PM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:
3. Section 6:

Yes.

—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.

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 21 Apr 2021 07:15:41 +0000

Hi John,

[Hannes] As mentioned by Ekr it is a matter of taste how to describe the payloads. We follow the style used in previous TLS specifications.
In any case, for an implementer it is important to know the length of each data item.

For example, if you have a ceiling of 2^16-1 for a data item you know that two bytes have to be written (or parsed). Here is a copy-and-paste from the Mbed TLS code to show an example:

    *p++ = (unsigned char)( ( MBEDTLS_TLS_EXT_SERVERNAME >> 8 ) & 0xFF );
    *p++ = (unsigned char)( ( MBEDTLS_TLS_EXT_SERVERNAME ) & 0xFF );

Ciao
Hannes