Re: [perpass] Howdy!

Stephen Farrell <stephen.farrell@cs.tcd.ie> Fri, 13 September 2013 19:13 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: perpass@ietfa.amsl.com
Delivered-To: perpass@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18BD911E8200 for <perpass@ietfa.amsl.com>; Fri, 13 Sep 2013 12:13:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-Vig-WU727h for <perpass@ietfa.amsl.com>; Fri, 13 Sep 2013 12:13:02 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id E634C11E80FF for <perpass@ietf.org>; Fri, 13 Sep 2013 12:13:01 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7ECEABEC6; Fri, 13 Sep 2013 20:12:59 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h2poztrboFIG; Fri, 13 Sep 2013 20:12:58 +0100 (IST)
Received: from [10.87.48.8] (unknown [86.41.55.250]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B3FDABEC3; Fri, 13 Sep 2013 20:12:58 +0100 (IST)
Message-ID: <523363B0.2090503@cs.tcd.ie>
Date: Fri, 13 Sep 2013 20:12:48 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8
MIME-Version: 1.0
To: Dean Willis <dean.willis@softarmor.com>
References: <CAOHm=4ujOYTHO63EFWMYJBgxUWq00zezYKAJ8B4Vgf_C=xRRVg@mail.gmail.com> <5224DF25.60503@cs.tcd.ie> <7C92613E-33E8-48A6-A152-E9DBB29DEC04@softarmor.com> <522A328A.5060008@cs.tcd.ie> <522E17F9.4000206@bbn.com> <522F685B.8040106@gmx.net> <A3F9FD55-E54D-4FAF-8DE2-C28565D6D119@softarmor.com>
In-Reply-To: <A3F9FD55-E54D-4FAF-8DE2-C28565D6D119@softarmor.com>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: perpass@ietf.org, Hannes Tschofenig <hannes.tschofenig@gmx.net>
Subject: Re: [perpass] Howdy!
X-BeenThere: perpass@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " <perpass.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/perpass>, <mailto:perpass-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/perpass>
List-Post: <mailto:perpass@ietf.org>
List-Help: <mailto:perpass-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/perpass>, <mailto:perpass-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Sep 2013 19:13:16 -0000

Hiya,

On 09/13/2013 06:36 PM, Dean Willis wrote:
>> to hear that the ability for demultiplexing HTTP 2.0 and earlier
>> version will be done based on information in the TLS handshake and
>> that the TLS group had decided that they prefer a solution that
>> reveals the type of application and rejected a proposal for hiding
>> it.

> Bad decision. Question the motivations of the people who made it.
> Remember, we've been told that the security of our network is being
> systematically crippled, by design, from within. I believe that to be
> true, in the general (rather than specific) sense. On the other hand,
> maybe they just didn't think about the problem from this
> perspective.

On this point: I think we're actually ok.

The TLS WG were asked to provide this feature for HTTP/2.0.
One proposal involved establishing confidentiality before
nominating the next protocol, but was somewhat hacky in how
it fit into TLS1.2. The other (ALPN) was selected as it did
the job required for HTTP/2.0 more cleanly.

BUT, the WG also decided (formally I guess a little later on)
to start work on TLS1.3 with a major goal of that work being
to confidentiality protect much more of the TLS handshake as
an inherent protocol feature. And that work has started,
though I don't think there's an I-D just yet.

So the TLS WG decision was in fact to go for more
confidentiality.

FWIW I think that was the right choice,

S.