On Thu, Jul 28, 2016 at 3:28 AM, Hubert Kario <hka...@redhat.com> wrote: > On Wednesday, 27 July 2016 09:50:18 CEST Wan-Teh Chang wrote: >> On Mon, Jul 25, 2016 at 3:32 PM, David Benjamin <david...@chromium.org> > wrote: >> > Hi folks, >> > >> > 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 >> > >> > (The name GREASE is in honor of AGL's rusted vs. well-oiled joints analogy >> > from https://www.imperialviolet.org/2016/05/16/agility.html ) >> > >> > One problem we repeatedly run into is servers failing to implement TLS's >> > various extension points correctly. The most obvious being version >> > intolerance. When we deployed X25519 in Chrome, we discovered an >> > intolerant >> > implementation. (Thankfully it was rare enough to not warrant a fallback >> > or >> > revert!) It appears that signature algorithms maybe also be gathering >> > rust. >> > Ciphers and extensions seem to have held up, but I would like to ensure >> > they stay that way. >> > >> > The root problem here is these broken servers interoperate fine with >> > clients at the time they are deployed. It is only after new values get >> > defined do we notice, by which time it is too late. >> > >> > 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. >> >> Hi David, >> >> In general I like your idea. Thank you for writing up a proposal. >> >> Another source of interop failures is the firewall devices that do >> anomaly detection. Some of them will abort TLS handshakes if they see >> unknown TLS protocol versions or extensions in ClientHello. (They all >> seem to allow unknown cipher suite values.) I suspect they will treat >> the GREASE cipher suite, extension, and named group values as "normal" >> and continue to abort the handshake if they see truly new values. I >> can only hope that these network security devices are updated >> regularly. > > how about adding a section that explicitly says what they are allowed to do, > and what they should not do? > > i.e. it is acceptable for them to reject messages that are malformed (data in > client hello past extensions field, odd sizes for arrays that contain just > double-byte values, etc.) but not "undefined" extensions or "undefined" values > in them
This is what parsing is for. > > in other words, how they can still provide added value without breaking TLS in > the future Maybe they can't, and you shouldn't buy those products. > -- > 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 > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- "Man is born free, but everywhere he is in chains". --Rousseau. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
