Subject: [TLS] TLS 1.3 unsupported_extension vs illegal_parameter clarification

From: Daniel Van Geest <[email-masked]>
Date: Wed, 12 Feb 2020 18:46:01 +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

---

From: Hubert Kario <[email-masked]>
Date: Thu, 13 Feb 2020 20:44:13 +0100

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

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