From nobody Wed Jul 28 12:02:23 2021 Return-Path: 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 4873C3A1DCC for ; Wed, 28 Jul 2021 12:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 SGczSCsTYfEg for ; Wed, 28 Jul 2021 12:02:07 -0700 (PDT) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 B7BC83A1D28 for ; Wed, 28 Jul 2021 12:01:37 -0700 (PDT) Received: by mail-wr1-x42b.google.com 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; d=gmail.com; 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; d=1e100.net; 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 smtpclient.apple ([46.120.57.183]) by smtp.gmail.com with ESMTPSA id p5sm796908wme.2.2021.07.28.12.01.33 (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.120.0.1.13\)) From: Yoav Nir In-Reply-To: <7fdb8ccb-6102-beea-69df-cd2aba1dbdd4@nthpermutation.com> Date: Wed, 28 Jul 2021 22:01:32 +0300 Cc: tls@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <5BDBC71F-3317-4126-98FC-EC5A32D342ED@gmail.com> References: <08c558b7-2215-4924-b6a4-807b9b3c8d84@www.fastmail.com> <7fdb8ccb-6102-beea-69df-cd2aba1dbdd4@nthpermutation.com> To: Michael StJohns X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: 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." 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: >=20 > 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: >>=20 >> https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/ >>=20 >> Please review this document and send your comments to the list by = July 30, 2021. The GitHub repository for this draft is available here: >>=20 >> https://github.com/tlswg/tls-flags >>=20 >> Thanks, >> Chris, on behalf of the chairs >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >=20 >=20 > 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. >=20 >=20 > 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? >=20 > 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. >=20 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=E2=80=99s up to the experts anyway. Yoav