Re: [TLS] Keeping TLS extension points working

Geoffrey Keating <geoffk@geoffk.org> Thu, 28 July 2016 18:01 UTC

Return-Path: <geoffk@geoffk.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3889412DB1B for <tls@ietfa.amsl.com>; Thu, 28 Jul 2016 11:01:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQmOZupwSP82 for <tls@ietfa.amsl.com>; Thu, 28 Jul 2016 11:01:40 -0700 (PDT)
Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [198.0.208.83]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F12512DB22 for <tls@ietf.org>; Thu, 28 Jul 2016 11:01:40 -0700 (PDT)
Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id C307F33D23B; Thu, 28 Jul 2016 18:01:39 +0000 (UTC)
Sender: geoffk@localhost.localdomain
To: Hubert Kario <hkario@redhat.com>
References: <CAF8qwaCaW2Q+z_JoDqzQZaGCWJ2aqUiyK8_J8_CO4Ck_cqtaSA@mail.gmail.com> <1484484.N0J803EhZs@pintsize.usersys.redhat.com> <CACsn0cm+-XxAJ7Oz0RBgwUWJD3zcUZMwSrzS66igdkfTJ1YUFw@mail.gmail.com> <7502983.MiB8z2zUIC@pintsize.usersys.redhat.com>
From: Geoffrey Keating <geoffk@geoffk.org>
Date: 28 Jul 2016 11:01:39 -0700
In-Reply-To: <7502983.MiB8z2zUIC@pintsize.usersys.redhat.com>
Message-ID: <m2h9b9prp8.fsf@localhost.localdomain>
Lines: 33
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/_YsUiuTfK66JncPQANNw-ALtB5A>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Keeping TLS extension points working
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Jul 2016 18:01:41 -0000

Hubert Kario <hkario@redhat.com> writes:

> On Thursday, 28 July 2016 06:12:48 CEST Watson Ladd wrote:
> > 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:
> > >> Another source of interop failures is the firewall devices that do
> > >> anomaly detection.
> > > 
> > > how about adding a section that explicitly says what they are allowed to
> > > do, and what they should not do?
> > 
> > This is what parsing is for.
> 
> yes, and bugs in parsing may very well be exploitable
>  
> > > 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.
> 
> pragmatist would say that double checking is defence in depth
> 
> and whatever we think, doesn't change the fact that people do make them 
> because people do buy them, so at least we can tell them how they can play 
> nice

I don't think 'playing nice' is the point of these devices; the
concept is that unusual is bad, and so should be blocked.  They don't
just block new or unknown features, but sometimes also known features
being used in unusual combinations.  I've seen these devices raise a
security alert because of a ciphersuite list which contained only
ciphersuites used by browsers, but not in the expected
combination/order---at least, that's what I think it was.