On Thu, Aug 27, 2015 at 11:48 AM, Martin Thomson <martin.thom...@gmail.com>
wrote:
> 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}}).
>
I note that we had a very extensive discussio n
> > 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 is an example of a MUST that is not always easy to enforce. Consider
what happens if you have a client which offers both ECDHE and PSK
(for resumption) and omits supported_groups. If the server picks
PSK it's a pain to check for supported groups and I'm not sure that
the world is improved by that code.
> 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.
>
I agree consideration of this question is good.
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.
As noted above, I don't think that this is the only exception.
-Ekr
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
