On Mon, Jan 16, 2017 at 1:59 AM, Nikos Mavrogiannopoulos <n...@redhat.com> wrote:
> On Sun, 2017-01-15 at 16:51 -0800, RFC Errata System wrote: > > > Original Text > > ------------- > > If a compatible TLS server receives a Supported Groups extension > > from > > a client that includes any FFDHE group (i.e., any codepoint > > between > > 256 and 511, inclusive, even if unknown to the server), and if > > none > > of the client-proposed FFDHE groups are known and acceptable to > > the > > server, then the server MUST NOT select an FFDHE cipher suite. In > > this case, the server SHOULD select an acceptable non-FFDHE cipher > > suite from the client's offered list. If the extension is present > > with FFDHE groups, none of the client's offered groups are > > acceptable > > by the server, and none of the client's proposed non-FFDHE cipher > > suites are acceptable to the server, the server MUST end the > > connection with a fatal TLS alert of type > > insufficient_security(71). > > I understand there will be servers which cannot follow the alert > recommendations on an RFC, but in that case why not replace the alert > types recommendation with a RECOMMENDED or SHOULD? It is good practice > for an RFC to specify the alerts to be send rather than leaving it up > to the implementer to figure out. IMO the spec should avoid prescribing alerts that require a certain structure for the negotiation code, which is what's happening here. In addition, we should probably avoid RFC 2119-level requirements which we know that many implementations will violate, even when they are SHOULD, not MUST -Ekr
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
