Re: [TLS] TLS 1.3 unsupported_extension vs illegal_parameter clarification

Hubert Kario <hkario@redhat.com> Thu, 13 February 2020 19:44 UTC

Return-Path: <hkario@redhat.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 C26B81201CE for <tls@ietfa.amsl.com>; Thu, 13 Feb 2020 11:44:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.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 9QDvLtBneUHY for <tls@ietfa.amsl.com>; Thu, 13 Feb 2020 11:44:20 -0800 (PST)
Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [205.139.110.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63B941201AA for <tls@ietf.org>; Thu, 13 Feb 2020 11:44:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1581623058; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=wuYROfYGbCKNUZUGBw6q2x4o0N4neklqJ/bwDS4RH5E=; b=Oi5nhgfl3DKFdHT4GxE5Y+DhEVWho1LWYn6IXu3PPoe7TTI5hfZL4d28wrkGO9GroYHD0I lcR3N3bFEexaWzq5S+p0Xg1g/h6zRnEMc4yZqI29boZkv+pmQD7ubbPZX6YZkdNQR1/jwz UHlbA0QyOQAu7kYLWdCwxQ9ss064I00=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-346-6VxHY-nEMwaOgtl97Qpi7A-1; Thu, 13 Feb 2020 14:44:16 -0500
Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id D6A291800D6B for <tls@ietf.org>; Thu, 13 Feb 2020 19:44:15 +0000 (UTC)
Received: from localhost (unknown [10.43.21.98]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7AD2A62660 for <tls@ietf.org>; Thu, 13 Feb 2020 19:44:15 +0000 (UTC)
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org
Date: Thu, 13 Feb 2020 20:44:13 +0100
MIME-Version: 1.0
Message-ID: <131bef25-b25e-4719-9aff-f171959640ce@redhat.com>
In-Reply-To: <4E5499C8-7461-4366-9F20-EF36EA407BD8@isara.com>
References: <4E5499C8-7461-4366-9F20-EF36EA407BD8@isara.com>
Organization: Red Hat
User-Agent: Trojita/0.7; Qt/5.12.5; xcb; Linux; Fedora release 30 (Thirty)
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15
X-MC-Unique: 6VxHY-nEMwaOgtl97Qpi7A-1
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/hGOGWZRMg718mWqOZ06LwjV9360>
Subject: Re: [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: Thu, 13 Feb 2020 19:44:23 -0000

On Wednesday, 12 February 2020 19:46:01 CET, Daniel Van Geest wrote:
> 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?

it looks like the first part of unsupported_extension is completely 
overriden
in main text of the RFC, it's just the "allowed, but not an echo" that 
should
cause unsupported_extension

but then section 6.2 is quite explicit that it's the main text that is of
higher importance:

   Whenever an implementation encounters a fatal error condition, it
   SHOULD send an appropriate fatal alert and MUST close the connection
   without sending or receiving any additional data.  In the rest of
   this specification, when the phrases "terminate the connection" and
   "abort the handshake" are used without a specific alert it means that
   the implementation SHOULD send the alert indicated by the
   descriptions below.  The phrases "terminate the connection with an X
   alert" and "abort the handshake with an X alert" mean that the
   implementation MUST send alert X if it sends any alert.

so while unfortunate, not really internally inconsistent

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic