On Tue, Apr 20, 2021 at 2:09 PM John Scudder via Datatracker < nore...@ietf.org> 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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
