[TLS] The consensus is half-mistaken (Re: Confirming consensus for ALPN)

Nico Williams <nico@cryptonector.com> Fri, 15 March 2013 21:59 UTC

Return-Path: <nico@cryptonector.com>
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 5131A21F8530 for <tls@ietfa.amsl.com>; Fri, 15 Mar 2013 14:59:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.887
X-Spam-Level:
X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 JI+o-t5QPvCz for <tls@ietfa.amsl.com>; Fri, 15 Mar 2013 14:59:52 -0700 (PDT)
Received: from homiemail-a32.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id BAACF21F852A for <tls@ietf.org>; Fri, 15 Mar 2013 14:59:52 -0700 (PDT)
Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id 75E7D58406A for <tls@ietf.org>; Fri, 15 Mar 2013 14:59:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:cc:content-type; s= cryptonector.com; bh=RjKZOxQEDgkZGdhVADq1sQFZw34=; b=ONSrIpWhEo9 aq5oL7Pnxt9WTCw/ea3/oyu0+0aaj6bm3AxM/nffNy8gHBI59m5CWBpchDAkuox7 ujR6GIFiOvBPhU/JTM+tbPuNFLC/RlktuGm3xPM3+8qwcYKTNzBWtDQvpbVe3MWO LOYZ/L7qQ2lqQQqrcx6FxF00Kbw91xao=
Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTPSA id 1F63A584058 for <tls@ietf.org>; Fri, 15 Mar 2013 14:59:51 -0700 (PDT)
Received: by mail-wi0-f169.google.com with SMTP id l13so1128519wie.2 for <tls@ietf.org>; Fri, 15 Mar 2013 14:59:50 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.194.89.169 with SMTP id bp9mr13660156wjb.57.1363384790555; Fri, 15 Mar 2013 14:59:50 -0700 (PDT)
Received: by 10.216.113.68 with HTTP; Fri, 15 Mar 2013 14:59:50 -0700 (PDT)
Date: Fri, 15 Mar 2013 16:59:50 -0500
Message-ID: <CAK3OfOi7sB=bPQXy-PmZgRvPR3N1amaZhn5EXyFHy4CzbmgbaA@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: text/plain; charset="UTF-8"
Cc: tls@ietf.org
Subject: [TLS] The consensus is half-mistaken (Re: Confirming consensus for ALPN)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Fri, 15 Mar 2013 21:59:53 -0000

On Fri, Mar 15, 2013 at 4:45 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> At today's TLS WG f2f meeting we had rough consensus to adopt
> ALPN as the solution to the upper-layer protocol negotiation problem
> posed to us by the HTTP WG.
>
> if you have an opinion on this topic and were not at the meeting,
> please send a message to the mailing list and/or the chairs by
> Friday March 29.

I believe that privacy protection for as much as possible of the
application layer negotiation is highly desirable.  In this sense I
think the consensus for ALPN is mistaken.  I do believe NPN is too
complex, and in that sense the consensus for ALPN is correct.

Can we find a middle of the road?

My compromise proposal is based on providing privacy protection for
the record type in TLS (post-CCS, of course) -- a feature that should
be desirable anyways and separately (e.g., to hide re-negotiation from
non-MITM middleboxes).  Such a feature would allow a post-handshake
non-application-type record for optimistic application protocol
negotiation (zero extra round trips in the optimal case, one more
round trip in the pessimal case).

Nico
--