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

[Eric Rescorla <[e-mail]>]

On Tue, Apr 20, 2021 at 2:09 PM John Scudder via Datatracker <
[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