On Monday, 25 July 2016 23:32:41 CEST David Benjamin wrote: > 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.
Then we have "pet-projects" of which the primary/only developer walks away/ changes jobs well after it was tightly integrated with already deployed systems, code that is passed over to interns as nobody either has time, inclination or knows much about <insert main subject matter here> anyway[1]... Thus I don't think it solves the problem even for non malicious programmers While the idea of code points that MUST NOT be negotiated by servers is not bad one from testing perspective, we already have few values like this (0x00,0x14 for cipher, 15 for supported groups, just of the top of my head). And for a test suite any value not defined by IANA already has this function (and you do need to test all those values to search for undocumented features, backdoors, etc. anyway). 1 - talking purely hypothetically here, even if I wanted, I wouldn't know where to point fingers in realm of TLS implementations -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
