On Thu, Aug 27, 2015 at 12:19 PM, Dave Garrett <davemgarr...@gmail.com>
wrote:
> 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
My problem is precisely the conflation of offering with negotiating. The
way that
many stacks work (for instance NSS) is that they negotiate the cipher suite
*first* and then they check for the presence or absence of the relevant
extensions.
It's not clear to me that it's an improvement to require them to check for
error
conditions that are not otherwise relevant.
-Ekr
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
