[TLS] TLS 1.3 unsupported_extension vs illegal_parameter clarification

Daniel Van Geest <Daniel.VanGeest@isara.com> Wed, 12 February 2020 18:45 UTC

Return-Path: <Daniel.VanGeest@isara.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 58F4A120A46 for <tls@ietfa.amsl.com>; Wed, 12 Feb 2020 10:45:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
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 s1sRBhDUajPw for <tls@ietfa.amsl.com>; Wed, 12 Feb 2020 10:45:25 -0800 (PST)
Received: from esa1.isaracorp.com (esa1.isaracorp.com [207.107.152.166]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A59F5120A53 for <tls@ietf.org>; Wed, 12 Feb 2020 10:45:25 -0800 (PST)
IronPort-SDR: RYU+yyhBsUOqk/OWpfb1tMGK9Q1CiS6h7hEtsYMhE6UFa4nCgUYygzIYDNciPFfkv7lqZrKqAn DM5fh7YOytXtOXpA4hOBrfsCzvAked+lgs/9nSMXAE7LsqgBacFCEDGb6vHOD1zJuwf+SnIYuL OGh97q4hXA8pR2sG6SjafEA9ZJiMrpFZ48lWA9iVYSM6fU21qfniN2CAzmb9DVKy8S0ow265sc xGWsRwC7J6iQg4q52HpJNSypGN36U+s17RMQ5f31JD/ooRRgokkPa2zLN/AFA+Wr5FkLz994pp Pls=
Received: from unknown (HELO V0501WEXGPR02.isaracorp.com) ([10.5.9.20]) by ip1.isaracorp.com with ESMTP; 12 Feb 2020 18:45:26 +0000
Received: from V0501WEXGPR01.isaracorp.com (10.5.8.20) by V0501WEXGPR01.isaracorp.com (10.5.8.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1847.3; Wed, 12 Feb 2020 13:46:01 -0500
Received: from V0501WEXGPR01.isaracorp.com ([fe80::d802:5aec:db34:beba]) by V0501WEXGPR01.isaracorp.com ([fe80::d802:5aec:db34:beba%7]) with mapi id 15.01.1847.005; Wed, 12 Feb 2020 13:46:01 -0500
From: Daniel Van Geest <Daniel.VanGeest@isara.com>
To: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: TLS 1.3 unsupported_extension vs illegal_parameter clarification
Thread-Index: AQHV4dSsu7Pal1sprkOKD5ZOC/nomw==
Date: Wed, 12 Feb 2020 18:46:01 +0000
Message-ID: <4E5499C8-7461-4366-9F20-EF36EA407BD8@isara.com>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.31.5.52]
Content-Type: multipart/alternative; boundary="_000_4E5499C8746143669F20EF36EA407BD8isaracom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/GKcwKqBcejzTmc78FUjJyQqNyK0>
Subject: [TLS] TLS 1.3 unsupported_extension vs illegal_parameter clarification
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: Wed, 12 Feb 2020 18:45:28 -0000

Hi,

I’m looking for some clarification on unsupported_extension vs illegal_parameter alerts in TLS 1.3.

RFC 8446 says:

If an implementation receives an extension
   which it recognizes and which is not specified for the message in
   which it appears, it MUST abort the handshake with an
   "illegal_parameter" alert.

and


The client MUST check EncryptedExtensions for the

   presence of any forbidden extensions and if any are found MUST abort

   the handshake with an "illegal_parameter" alert.

But also


   unsupported_extension:  Sent by endpoints receiving any handshake

      message containing an extension known to be prohibited for

      inclusion in the given handshake message, or including any

      extensions in a ServerHello or Certificate not first offered in

      the corresponding ClientHello or CertificateRequest.

These seem contradictory.  An “unsupported_extension” is for “an extension known to be prohibited for inclusion in the given handshake message”.

But it seems that the first two statements quoted indicate that “illegal_parameter” should be sent in this case.

I’d expect “unsupported_extension” would be more fitting.  Is an errata needed?

Thanks,
Daniel Van Geest