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