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

"StJohns, Michael" <msj@nthpermutation.com> Mon, 02 August 2021 07:14 UTC

Return-Path: <msj@nthpermutation.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BEEE3A0E7A for <tls@ietfa.amsl.com>; Mon, 2 Aug 2021 00:14:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k6npUnyXur-4 for <tls@ietfa.amsl.com>; Mon, 2 Aug 2021 00:14:06 -0700 (PDT)
Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE32A3A0E79 for <tls@ietf.org>; Mon, 2 Aug 2021 00:14:05 -0700 (PDT)
Received: by mail-lj1-x231.google.com with SMTP id f12so22659942ljn.1 for <tls@ietf.org>; Mon, 02 Aug 2021 00:14:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=yae9ht726RBCL2ctXPS3DNKMLr2jRGBukb4KQLn+GcQ=; b=i7FIRXvc+ildY2j4Z/TOn5g8GqO7K2mLA/dR1nLM6sA8Q7+j7VazpGAIp36S2DWKDk x51oINVLjsCrgzLmcN5IsfBEWWsXBvEdFTcfzaswwIM2ALmf3Xd0zwAVF+T+3X66c260 ouqN5rBXw8WwuD0W+5NhAQWU6LgumvRDniNCgIOQGehbtT+EnI+x7ldjS6zGPbhnRMlX Ok2wnvoAmdqk/VWb7ovUb4p+ml30SRO3KIahD5Cav4/1D3VfkcHYSMMrzWjpbQYHOXui VVG7FuN+8aSQGxXVFIaTrIaJsWmhPfes37Axts5MvwKSYfw7+VJM4wjy8HVXUuAqyhsl pBVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=yae9ht726RBCL2ctXPS3DNKMLr2jRGBukb4KQLn+GcQ=; b=Az6UnHjZXNd98c2Dimd95r+ynw+QodeR/cyFU5A9DTZCpZjXrdcsxnp9PxOx4AU4Xl Sp0Ed8w5FXHWUXcNHM79/F8pk0inLxUYiGDizeTrPcofAhnEAYqHHEIwCC3YtSXrMbj2 p76KwdBvljAshOWgH7Ui4qBmg9hCeYWN43ZIOw7iwD4UmYElgCSCcZOCGf8lk+gyT2pW l6HgI9HOAfwyRL3Id9XAlRBoF9CbaLVdGizwQ7hgV3HNdCBBmg5++vCstYW3h/FK/bu+ Mm1klmF0MIerwnd/4qigTJ3VjiaFHIyYn8kpW6FpfMEBAV8+Iq64KgCFwIvjB9LiL7Ak fcWw==
X-Gm-Message-State: AOAM532drZfzLsWp9gk5JTgGVp4TsaWOar1v5xyaY0fxeyOtmy1MPANe nuoYr1CGtp5tE13z9I2UY9Rwl+VGb3Eif7Bda4yGLJARRxIewA==
X-Google-Smtp-Source: ABdhPJythbvOzbEk1+/EmfPuwbsF4ti9YbW7qEQDy2iiNPL21aHvzRWw/Z9MH05ddWS8CJ6JpPXWuGP5QyKp9hKjbfQ=
X-Received: by 2002:a2e:955:: with SMTP id 82mr10221065ljj.423.1627888443000; Mon, 02 Aug 2021 00:14:03 -0700 (PDT)
MIME-Version: 1.0
References: <08c558b7-2215-4924-b6a4-807b9b3c8d84@www.fastmail.com> <7fdb8ccb-6102-beea-69df-cd2aba1dbdd4@nthpermutation.com>
In-Reply-To: <7fdb8ccb-6102-beea-69df-cd2aba1dbdd4@nthpermutation.com>
From: "StJohns, Michael" <msj@nthpermutation.com>
Date: Mon, 02 Aug 2021 03:13:52 -0400
Message-ID: <CANeU+ZCogaU6w73G-4CiZgKVgbiP_Hzfh5oRbdFt0J94QsWFcw@mail.gmail.com>
To: tls@ietf.org
Content-Type: multipart/alternative; boundary="000000000000611cc405c88e5061"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/7X5kcVllFUo9YYBazUgGIRkiagU>
Subject: Re: [TLS] WGLC for draft-ietf-tls-flags
X-BeenThere: tls@ietf.org
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." <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: Mon, 02 Aug 2021 07:14:11 -0000

Given that I got a response to a different message on this topic, and that
Martin is making a similar point to that I made below, my guess is that
this message got lost in the shuffle.



On Sun, Jul 18, 2021 at 19:26 Michael StJohns <msj@nthpermutation.com>
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:
> >
> >      https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/
> >
> > Please review this document and send your comments to the list by July
> 30, 2021. The GitHub repository for this draft is available here:
> >
> >      https://github.com/tlswg/tls-flags
> >
> > Thanks,
> > Chris, on behalf of the chairs
> >
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
>
>
> 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
>
>
>
>
>