On Tue, Jul 26, 2016 at 6:56 AM Hubert Kario <hka...@redhat.com> wrote:
> On Monday, 25 July 2016 22:32:29 CEST David Benjamin wrote: > > I would like to fix this by reserving a few values in our registries so > > that clients may advertise random ones and regularly exercise these > > codepaths in servers. If enough of the client base does this, we can > turn a > > large class of tomorrow's interop failures into today's interop failures. > > This is important because an bug will not thrive in the ecosystem if it > > does not work against the current deployment. > > What prevents an implementation from ignoring values from just those > reserved > ranges and continuing to be intolerant to other values? After all, if they > are > reserved for this, they just need to ignore those values (as no "real" > extension/value will ever use them) to "resolve the problem". > Nothing. Just as nothing prevents an implementation from taking every ClientHello current browsers send (variable parts like client_random normalized), hard-coding their SHA-256 hashes, and rejecting anything that doesn't match. The point is to catch honest mistakes, not to avoid servers that are maliciously trying to mess up the ecosystem. We can certainly increase the pool over time as Viktor suggested if special-casing these becomes a problem. I don't expect it to be, but we'll see. Whereas not ignoring unknown values has empirically been a problem. David
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
