Re: [TLS] tls-flags: abort on malformed extension

Yoav Nir <ynir.ietf@gmail.com> Thu, 07 October 2021 18:37 UTC

Return-Path: <ynir.ietf@gmail.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 178053A087E for <tls@ietfa.amsl.com>; Thu, 7 Oct 2021 11:37:30 -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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 du8sZXKM6o2f for <tls@ietfa.amsl.com>; Thu, 7 Oct 2021 11:37:27 -0700 (PDT)
Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (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 B9C673A0691 for <tls@ietf.org>; Thu, 7 Oct 2021 11:37:26 -0700 (PDT)
Received: by mail-wr1-x430.google.com with SMTP id t8so22084189wri.1 for <tls@ietf.org>; Thu, 07 Oct 2021 11:37:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=VgPXOSSkVs10imVD2IrkC3FDHkiNgp4HUs2Zab/T7wg=; b=eQVqLquhWjO1Z7a0sb34tNhZVU2QnFzh0TFXtfELmsKzTIdTlxiZxQOEG5hnKqeL8x FVisET/SJDLhiHct8qqiDyZx+9RHPIi9QeNqfCJ+ytyn/Vpd9CdJAdZEjkz07l4fFRrR gDUFLBlerM5dVNMDCLCob7YegUbMN1thSWHyxIuCz4AA4OtNjz5K2i221UYCXY5JHSdH AbddSL+a++R97HEepz3DAA2stwmoTUoi/pAIBuCfMAx18LNpoGXZXOU3bFTcqYoztzt1 NbJQZaeiZlXJXw25nSURf7z6mv/z3ddp0h0ezcb4q+jhZzfomQKjSzLRf35X3w/M0wYf +WyA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=VgPXOSSkVs10imVD2IrkC3FDHkiNgp4HUs2Zab/T7wg=; b=FQfMC8HYCAJ9m/1gmjWAiTh/khMHPdiA3TrGPPzm5Lyir1xfRJcQau1rhjBsZ3URkv oKghyNq93EUEbtxbKh7na0yyJw6VBPV2pcAz81Dp7FT0kPwxTgOxZIGtouVncQarQFhH rMujxnTgAbiJHSMsnwEcHL52fYCNJfJbHPur8OltQODucmQHNAWu2DGGsLi82JN/Nznp XoOei90UucpjZAiIL7d+cOt6E3S1ZV3VZY301/sYSkCkso6bEkkgZ3wVNEdGMdwUVQmD HqrGbuDV0HbCRsuptLF5CZRc/Mk88LaLP/G8dgWk1sHj0byoykTtA8TImo5JSlPDXtwZ xhVQ==
X-Gm-Message-State: AOAM532BH/APXGIP0VPz9uBjZ0Vj9ElE3/pRmLEb7UQplG+Do/zZ/dAx 2GyScMyvv+gdnFOnOvg7rnTgIrFJv6dpwA==
X-Google-Smtp-Source: ABdhPJz1E7R6HZcDVPFxRaep13UJT4q8z8myaAJprWI2yeks8XLx7qNKYvSE0/UZei7ReDxMlAujog==
X-Received: by 2002:adf:b185:: with SMTP id q5mr7487886wra.213.1633631844271; Thu, 07 Oct 2021 11:37:24 -0700 (PDT)
Received: from smtpclient.apple (84.94.176.50.cable.012.net.il. [84.94.176.50]) by smtp.gmail.com with ESMTPSA id q204sm7573199wme.10.2021.10.07.11.37.22 for <tls@ietf.org> (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Oct 2021 11:37:23 -0700 (PDT)
From: Yoav Nir <ynir.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_5D2319F5-FA1B-406B-B880-C00C2D9054C6"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Date: Thu, 07 Oct 2021 21:37:22 +0300
References: <5BFCE990-52C0-4C0C-BD8A-AC3DB0A48084@gmail.com>
To: "<tls@ietf.org>" <tls@ietf.org>
In-Reply-To: <5BFCE990-52C0-4C0C-BD8A-AC3DB0A48084@gmail.com>
Message-Id: <E37094D9-A40B-4E7B-BE6B-0AE16F0E0C64@gmail.com>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ZybDloj0NHnAy0QmOOJbCBTQcmI>
Subject: Re: [TLS] tls-flags: abort on malformed extension
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: Thu, 07 Oct 2021 18:37:30 -0000

Since I prefer to have the discussion in a single place, I’m copying below a comment by David Benjamin from GitHub:

> On 28 Aug 2021, at 23:36, Yoav Nir <ynir.ietf@gmail.com> wrote:
> 
> Hi.
> 
> To address Michael StJohns comment from 19-July, I submitted PR #12:
> 
> https://github.com/tlswg/tls-flags/pull/12 <https://github.com/tlswg/tls-flags/pull/12>
> 
> What is says is that any implementation receiving a malformed tls_flags extensions should abort the handshake. The text provides a list (which I hope is comprehensive) of all the ways this specific extension can be malformed. 
> 
> Please comment here or on the PR is this makes sense to everybody.


My proposed text:

>    An implementation that receives an invalid tls_flags extension MUST 
>    terminate the TLS handshake with a fatal illegal_parameter alert. 
>    Such invalid tls_flags extensions include: 
>     * zero-length extension
>     * Multiple tls_flags extensions for the same message
>     * A flag set in the tls_flags extension of the wrong message, as 
>       specified in the document for that flag     



David’s comment about the zero-length extension:
> If we want this to be invalid, we can put it in the TLS presentation language. Change FlagExtensions to:
> 
>       struct {
>          opaque flags<1..255>;
>       } FlagExtensions;


David’s comment about the multiple extensions:
> RFC8446 already prohibits this on the sender. We don't do a good job of defining the rules for the receiver, but that should probably be done uniformly across all extensions, rather than just in this one


David’s comment about the flag on the wrong message:
> This seems unimplementable. If I receive a message with a flag I don't recognize, I have no idea whether the flag is allowed in the message or not. Yet this text says I MUST enforce this rule. (There's probably some corresponding wording in RFC8446 we can borrow.)
> 
> Nit: It also seems better to phrase this in terms of the registry, rather than the document. We might have multiple documents for the flag if we have to update it.

OK, so now my response:

I agree with the first and second comments. About the third, what I meant was that a supported flag that is supposed to appear only in CH appears instead and CR, or more likely, a flag that should appear in EE apears in SH instead.

But I think the best way to resolve the issue is to remove the bullet point list and the last sentence before them, IOW: remove the examples.

If this is agreeable to everyone, I will modify it in my PR.

Yoav