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
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
