Re: [TLS] WGLC for draft-ietf-tls-flags

Yoav Nir <> Wed, 28 July 2021 19:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4873C3A1DCC for <>; Wed, 28 Jul 2021 12:02:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SGczSCsTYfEg for <>; Wed, 28 Jul 2021 12:02:07 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B7BC83A1D28 for <>; Wed, 28 Jul 2021 12:01:37 -0700 (PDT)
Received: by with SMTP id c16so3771063wrp.13 for <>; Wed, 28 Jul 2021 12:01:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6mEzvuP/Y7fnaVFqOlPYLhnv9KhBdpKa/08r982B9/c=; b=AFbFGqastSusItcp8Gbyxanw2Gs0xHM8pTgJCndpnczfdFdwNsuecYtBkTuz1IXNv1 H1d34MtOJwITc9vDQnFw4NfSoEes5x59KtxBLfSMybI3G+gF8WKpuz9uwWgjernckLQW mAcNTvO1zPVwWrZAvLC0rbDjzUO2dnBN7OeDmVz6eBVj9fraz6fjcYnZC2nYOq6vaqGg IzFf8KPMEqjWoLRnLN/DPziEmo1rmD9MFC65d0aiYgeR2M1abEzB5bMxYJXJbu7AY4tf cWDII4R8R38o5tKPvIcD3HICEADCV87SWFfbG1ajk9kw3KIE6WNJKgKDhq6wc+/7ycjT +Kbg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6mEzvuP/Y7fnaVFqOlPYLhnv9KhBdpKa/08r982B9/c=; b=Zj9BGsJAAlhSqWbz5Wk65ussM38vzigMjNA+VfPbVA1HTjh4PSIo004M2QA/kAXx9z LHUBm3+PXCFiEDSPRVGnsL7k4HFeF4ncvmgM8FiXNRGoEcHq47jDGEXp1SHNHEBQcuji VZK/BPgyjd7eWufXFON/EmCf85n/ug7O0WWrJKe/hSrKyt04OBC2EoIVYj2xox5hqo62 bR6G1aKR7i+LZ8b9DYgkwGvZU60UDsdAzjZrOws9HbGLBey3lfwbSvODSptxHnMjVVd9 1hOUGwvDud0uINy1HQS/58ejVdUsL79hpmrlnAyEIinMefQpi+Ykauz7JEYVfCFtLyyC hWGA==
X-Gm-Message-State: AOAM531KhuXp9UQcUCvR56pFSqJA9/izb8zHzLRPRLe9DVjtEvZEIpjx HyOB+vB4VS0QZNOX+O0CElHzDodJHRUohccM
X-Google-Smtp-Source: ABdhPJxgYjxZvog+1+bhr9ooGMlt6wbMHRrRxlYbZY20+ZRip2DSJ2iaaBpcKVcBnijqrA4BRR8//Q==
X-Received: by 2002:adf:ed50:: with SMTP id u16mr843305wro.174.1627498894842; Wed, 28 Jul 2021 12:01:34 -0700 (PDT)
Received: from ([]) by with ESMTPSA id p5sm796908wme.2.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Jul 2021 12:01:34 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
From: Yoav Nir <>
In-Reply-To: <>
Date: Wed, 28 Jul 2021 22:01:32 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Michael StJohns <>
X-Mailer: Apple Mail (2.3654.
Archived-At: <>
Subject: Re: [TLS] WGLC for draft-ietf-tls-flags
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 28 Jul 2021 19:02:19 -0000

Thanks for the review. Comments inline.

> On 19 Jul 2021, at 2:26, Michael StJohns <> wrote:
> On 7/16/2021 7:55 PM, Christopher Wood wrote:
>> This is the second working group last call for the "A Flags Extension for TLS 1.3" draft, available here:
>> Please review this document and send your comments to the list by July 30, 2021. The GitHub repository for this draft is available here:
>> Thanks,
>> Chris, on behalf of the chairs
>> _______________________________________________
>> TLS mailing list
> Hi - I have not followed the discussion of this document on the mailing list so this review is only against the document itself. It's possible that these concerns have already been discussed.
> Section 2 requires  (MUST) the generation of fatal illegal_parameter alert upon reception of a mal-encoded extension (e.g. any trailing zero bytes), but compare and contrast this with section 3 which is full of MUST and MUST NOT declarations but with no concrete actions to be taken.  E.g. if I (server or client) send 0x01 0x10, and receive 0x01 0x11 from the client or server, wouldn't that be an illegal value as I've added a bit not sent to me?   Should that cause the same fatal illegal_parameter alert? Alternately, "receiver MUST ignore received bits that weren't sent" language could clean this up.

I prefer the hard error, but this should be discussed in the WG. Perhaps a PR is in order?

> Section 4 is a bit painful to read in that it took me three read-throughs to understand that what the document is asking for is a monolithic registry which requires "expert review" for all registrations, but where the experts are responsible for the sub range determinations.   Usually, that's not the way the IANA works.  If a registry has distinct set of ranges, each range normally has a specific registration procedure that the IANA follows before placing a parameter in that registry.

The way it works with all the TLS registries is that IANA asks the expert for advice on which numbers to assign regardless of how the registry is segmented.  So it’s up to the experts anyway.