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

[Hannes Tschofenig <[e-mail]>]

Hi John, Hi Ekr,

Regarding the presentation language used in the document I have added a clarification to the terminology section, see https://github.com/tlswg/dtls-conn-id/pull/110.

I hope this addresses the issue.

Ciao
Hannes


From: Eric Rescorla <[e-mail]>
Sent: Tuesday, April 20, 2021 11:32 PM
To: John Scudder <[e-mail]>
Cc: The IESG <[e-mail]>; [e-mail]; tls-chairs <[e-mail]>; <[e-mail]> <[e-mail]>; Joseph Salowey <[e-mail]>
Subject: Re: John Scudder's No Objection on draft-ietf-tls-dtls-connection-id-11: (with COMMENT)



On Tue, Apr 20, 2021 at 2:09 PM John Scudder via Datatracker <[e-mail]<mailto:[e-mail]>> wrote:
John Scudder has entered the following ballot position for
draft-ietf-tls-dtls-connection-id-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I found this document heavy sledding but once I was through it, it all came
together, with the exception of my #3, below. The “heavy sledding” part I think
would be largely fixed by addressing my #1, below.

1. Section 3:

This pseudocode is a little too pseudo for me:

     struct {
         opaque cid<0..2^8-1>;
     } ConnectionId;

What does the content of the angle brackets mean? At first I took it to mean
“this can take on a value from 0 to 255” [*] but parts of the spec that go on
about variable lengths made me think that couldn’t be right. Eventually, by
paging through RFC 5246, I found some explanations of what this stuff is
supposed to mean; in §4.3 of that RFC I found out that

   Variable-length vectors are defined by specifying a subrange of legal
   lengths, inclusively, using the notation <floor..ceiling>.  When
   these are encoded, the actual length precedes the vector's contents
   in the byte stream.  The length will be in the form of a number
   consuming as many bytes as required to hold the vector's specified
   maximum (ceiling) length.

I assume this is what’s going on in DTLS as well. This cleared up my main
source of confusion, which was regarding just how you were encoding these
variable-length CIDs anyway. (And oh by the way, that definition doesn’t say
what the units of length are. Bytes seems implied but isn’t explicit.)

While I don’t expect you to supply these definitions again, it would be
courteous to your readers to have a sentence or two explaining that pseudo-code
conventions are found in RFC 5246, special extra credit for section references
as well. And yes, I did notice "This document assumes familiarity with DTLS 1.2
[RFC6347].” That’s well and good, but I don’t think “familiarity” is the same
as “we have adopted the same notational conventions”

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.


[*] 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.


2. Section 3:

   If DTLS peers have negotiated the use of a non-zero-length CID for a
   given direction, then once encryption is enabled they MUST send with
   the record format defined in {{dtls-ciphertext} with the new MAC
   computation defined in Section 5 and the content type tls12_cid.
   Plaintext payloads never use the new record type and the CID content
   type.

What’s “{{dtls-ciphertext}”? I’m guessing just a botched xref?

Yes, presumably. Looks like I forgot a }}.


Also, the first sentence seems to have no object. (What MUST they send?)

send anything, but I suppose "send records". I can make a change.


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.

-Ekr

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.