Re: [TLS] Keeping TLS extension points working

On Thu, Jul 28, 2016 at 3:28 AM, Hubert Kario <hkario@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 <davidben@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.