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

Michael StJohns <> Sun, 18 July 2021 23:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CA1743A14E0 for <>; Sun, 18 Jul 2021 16:26:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 cBzhQuZM-kuY for <>; Sun, 18 Jul 2021 16:26:58 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::733]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DDEA63A14D6 for <>; Sun, 18 Jul 2021 16:26:57 -0700 (PDT)
Received: by with SMTP id c68so10329719qkf.9 for <>; Sun, 18 Jul 2021 16:26:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=mdHafn2NMMoBe32okXiCYksCE/s5Lq3aijv9C+k0CjM=; b=SrFvHLTVDID8pQpOaixk49Tja8gFqaR63ISSCcrvHZJsqOnvhgET/hrBmfdzoDuxwc u97VeZ6yVtQr6xb8sL7HeRGOrHGI9/Mx9x1AX/i1+JZLeSA5XBG8kIwHgrSi7gY5LLN6 SMYsvzge1kfGc3nhH2WlMBdoIa8NvJoYIWuPG8QLCwFfmpgq6OKsNhp7mQSm/bxDQnRZ KHglYwbgcI8Xnd2/A5Lf5vSjxF2TIiH/cLdRthnlgbgLT/XwDGsdlzwdKYOsdxRVJCRQ MRczhiqBC3kkdIbGH1yoCCYNqPQ0zCH8kvwcvcVaZyfe0dVI9YpjjoZNhredqUTMJd0x MzDA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=mdHafn2NMMoBe32okXiCYksCE/s5Lq3aijv9C+k0CjM=; b=ZOqeqUdWJGXcMzkK5ABBT/1y6NjkWm7hOrnccCv42uYP8b/UG0FNA7XdBZjNaH7+WL 7DNxcuNlp/wtV1VQ1PAwxFGpWRnvOUGMn0qDHSjSpLgDovBrDm6eBYminBOqnEmjYuIs jnbdSDWDBw4JOibqQ7BUA3nMi6kbaI3Zw7Vs4fomVjjwQnQNPd7zKM+nj8WjS7ZgAInU YiDX5rB5+40KpQsgehQkTeArajvUJ1jdflhCDbhaVVJizk5k3/eK59Y4JYtCYMuC5BBp B63j6bU+ubqIbXRTnt9Y4WbBT9PohERF80AAyjpJIP1+XJTjRge0g8SWwWPkC8+0ksaP PeJQ==
X-Gm-Message-State: AOAM532H60EEv2oDKJxeQEAt2rF2QGbYStL5Z+bzMCEcAAFjLim18073 gO+YedD/xNCOGVqXmR+zC0F3x+Rg+O/jfl+NG2c=
X-Google-Smtp-Source: ABdhPJy08juVLv0WFdH9VGS1NlMnhklCY6bxQuWtKzShotxsHH9FFbCiDOToZetBxpxfAwx/GI8TqQ==
X-Received: by 2002:a37:9cf:: with SMTP id 198mr982856qkj.60.1626650814633; Sun, 18 Jul 2021 16:26:54 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id h13sm7318122qkg.13.2021. for <> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 18 Jul 2021 16:26:53 -0700 (PDT)
References: <>
From: Michael StJohns <>
Message-ID: <>
Date: Sun, 18 Jul 2021 19:26:52 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
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: Sun, 18 Jul 2021 23:27:00 -0000

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.

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.

I'd strongly suggest reviewing RFC 8126 and chatting with the IANA to 
see if its possible to reform the registration process along more normal 
IANA lines.   E.g.:

0-7 - Standards Action and Expert Request
8-31 - Standards Action
32 - 63 Specification Required or IETF Review (pick one)
64-79 Private Use
80-127 RFU or Expert Review
128-2039 First Come First Served

Absent these two points, the rest of the content looks good.  I'd 
recommend a draft pass to fix these two items.

Later, Mike