The statement I'd like to see is something like this...

An endpoint that receives an illegal combination of "things" MAY choose to
treat that as a fatal error.

In this case, that means that if you include an ECDHE suite without an
ECDHE named_group, don't expect to have the connection succeed.
On Aug 27, 2015 12:51 PM, "Dave Garrett" <davemgarr...@gmail.com> wrote:

> On Thursday, August 27, 2015 03:26:03 pm Eric Rescorla wrote:
> > 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.
>
> I'm not fundamentally opposed to having a hard requirement of an error
> check on negotiation, and basically a soft expectation on mere offering
> (SHOULD, MAY, or not mentioned; stern warning and shake of finger). That
> said, categorizing the cipher suites and just doing a quick check for which
> categories are there and what extensions came with it is not a very
> complicated requirement. I'm philosophically in the "do it right or explode
> so it can be found and fixed immediately" camp when it comes to very clear
> requirements like this, but I'm aware that this is sadly not always the
> dominant thought process. :|
>
>
> Dave
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Reply via email to