On Mon, Jul 25, 2016 at 7:23 PM Viktor Dukhovni <ietf-d...@dukhovni.org> wrote:
> On Mon, Jul 25, 2016 at 10:32:29PM +0000, David Benjamin wrote: > > > I'm not sure how this process usually works, but I would like to reserve > a > > bunch of values in the TLS registries to as part of an idea to keep our > > extension points working. Here's an I-D: > > > > https://tools.ietf.org/html/draft-davidben-tls-grease-00 > > To really make this work, it would be necessary to expand the > reserved pool gradually, rather than all at once, so that servers > can't hard-code just the initially reserved pool, and still fail > with new "real" extensions later. My hope is that, especially with the values allocated sparsely, after getting interop failure once or twice from unknown values, the servers will quickly figure it out. I'm assuming the implementations simply made mistakes or weren't paying enough attention to the specification rather than being actively malicious. But, you are right, one failure mode here is implementations may "accidentally" hard-code the reserved pool... somehow. > Add a new code point every year > for 5-10 years, and eventually servers will have extension tolerance. > To clarify, this is about making sure new implementations don't ossify the whatever set of named groups (etc.) they observe, not flushing intolerance out of existing ones. For existing ones, it'd be equally difficult to deploy, say, GREASE for named groups as it'd be to deploy a new named group to begin with. (Fortunately, we successfully deployed a new named group just this year, so this is the perfect time to do that.) David
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
