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...@rtfm.com> Sent: Tuesday, April 20, 2021 11:32 PM To: John Scudder <j...@juniper.net> Cc: The IESG <i...@ietf.org>; draft-ietf-tls-dtls-connection...@ietf.org; tls-chairs <tls-cha...@ietf.org>; <tls@ietf.org> <tls@ietf.org>; Joseph Salowey <j...@salowey.net> 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 <nore...@ietf.org<mailto: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 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.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
