On Thursday, August 27, 2015 02:48:15 pm Martin Thomson 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}}).
Some changes to this are now in this PR:
https://github.com/tlswg/tls13-spec/pull/231/files
(language based on list discussion)
> > All implementations MUST use the "signature_algorithms" extension when
> offering and negotiating certificate authenticated cipher suites.
Actually, I did get a strict requirement in there for that one:
https://github.com/tlswg/tls13-spec/blob/master/draft-ietf-tls-tls13.md#signature-algorithms
> All clients MUST send a valid "signature_algorithms" extension in their
> ClientHello when offering certificate authenticated cipher suites. Servers
> receiving a TLS 1.3 ClientHello offering certificate authenticated cipher
> suites without this extension MUST send a "missing_extension" alert message
> and close the connection.
I think it warrants repeating in the MTI section as well.
> > All implementations MUST use the "supported_groups" extension when
> offering and negotiating DHE or ECDHE cipher suites.
My initial draft had similar language, however ekr says the WG doesn't have
consensus to be more strict. I would like to consider all of these extensions
as mandatory to send, and malformed if not present when offering/negotiating
any applicable cipher suites:
signature_algorithms, supported_groups, client_key_share, pre_shared_key,
server_name (though, I'm fine with a SHOULD error on lack of SNI when
applicable)
Dave
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
