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”. [*] By the way, why not just use “255” in the text instead of “2^8-1”? Eschew obfuscation! 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? Also, the first sentence seems to have no object. (What MUST they send?) 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. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
