I've been looking at the latest TLS 1.3 spec and there are a lot of
MUSTs that are completely toothless. To pick on a recent changeset:
> The signature algorithm and hash algorithm MUST be a pair offered in the
"signature_algorithms" extension (see {{signature-algorithms}}).
> All implementations MUST use the "signature_algorithms" extension when
offering and negotiating certificate authenticated cipher suites.
> All implementations MUST use the "supported_groups" extension when
offering and negotiating DHE or ECDHE cipher suites.
This isn't good. "MUST" language MUST have consequences or you are
left with all sorts of variations. If you don't stipulate
consequences, then people violate the MUST and you get interop issues.
I propose that we don't do this in future without due consideration.
In all these cases, the peer that notices a violation of the
requirement can (and I would argue MUST) fail the handshake and
probably generate a fatal alert.
The exceptions to this are where you need to permit non-compliant
behaviour for legacy interoperability reasons. For TLS 1.3, I think
that we can limit that to the ClientHello handling and - if we feel
like we can mandate changes that affect TLS 1.2 or earlier for clients
that support 1.3 - the ServerHello. I think only the ClientHello.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
