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

John Scudder via Datatracker <noreply@ietf.org> Tue, 20 April 2021 21:09 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: tls@ietf.org
Delivered-To: tls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 632EF3A1B20; Tue, 20 Apr 2021 14:09:31 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: John Scudder via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-tls-dtls-connection-id@ietf.org, tls-chairs@ietf.org, tls@ietf.org, Joseph Salowey <joe@salowey.net>, joe@salowey.net
X-Test-IDTracker: no
X-IETF-IDTracker: 7.28.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: John Scudder <jgs@juniper.net>
Message-ID: <161895297137.8190.2910970787366433858@ietfa.amsl.com>
Date: Tue, 20 Apr 2021 14:09:31 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/urqyTwgp7sP7w40bFUhpCVPma-Y>
Subject: [TLS] John Scudder's No Objection on draft-ietf-tls-dtls-connection-id-11: (with COMMENT)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Apr 2021 21:09:31 -0000

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.