Re: [TLS] Review of draft-agl-tls-nextproto-00

Brian Smith <bsmith@mozilla.com> Sat, 20 August 2011 10:45 UTC

Return-Path: <bsmith@mozilla.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 741C721F8744 for <tls@ietfa.amsl.com>; Sat, 20 Aug 2011 03:45:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_44=0.6]
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 glAN6HHyzHU1 for <tls@ietfa.amsl.com>; Sat, 20 Aug 2011 03:45:05 -0700 (PDT)
Received: from mail.mozilla.com (corp01.sj.mozilla.com [63.245.208.141]) by ietfa.amsl.com (Postfix) with ESMTP id 1180D21F871C for <tls@ietf.org>; Sat, 20 Aug 2011 03:45:05 -0700 (PDT)
Received: from mail.mozilla.com (mail.mozilla.com [10.2.72.15]) by mail.mozilla.com (Postfix) with ESMTP id 25BF8AE647B0; Sat, 20 Aug 2011 03:46:04 -0700 (PDT)
Date: Sat, 20 Aug 2011 03:46:04 -0700 (PDT)
From: Brian Smith <bsmith@mozilla.com>
To: Eric Rescorla <ekr@rtfm.com>
Message-ID: <1360415263.273856.1313837164056.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>
In-Reply-To: <CABcZeBMvyOmTYKeG9odE_QoHjTYrUOZegmW6+FsBzj42+dbKQg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Originating-IP: [99.140.149.214]
X-Mailer: Zimbra 6.0.8_GA_2661 (ZimbraWebClient - FF3.0 (Win)/6.0.8_GA_2661)
Cc: tls@ietf.org
Subject: Re: [TLS] Review of draft-agl-tls-nextproto-00
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: Sat, 20 Aug 2011 10:45:05 -0000

Eric Rescorla wrote:
> MOTIVATION
> It's unclear from the draft what the motivation for this work is.

Practically, it allows multiple protocols to be offered on the same host:port. In particular, it allows SPDY and HTTP to both use port 443. Mozilla will use this extension (or the previous version) for exactly this purpose. In addition, I think we will also eventually use it for all of our TLS-based communication, to reduce the risk of cross-protocol attacks.

> However, WebSockets does not use NPN; the HyBi working group
> explicitly rejected NPN because it would have required the use of TLS
> at all times. I'm not saying I agree with this, but it's what
> happened. Instead, the HyBi WG designed their own application-layer
> handshake which is intended to thwart cross-protocol
> attacks. Similarly, the other major WG which is currently concerned
> with cross-protocol attacks, WebRTC, is not interested in NPN but
> rather is using an ICE-based handshake prior to sending traffic. What
> IETF protocols have a demand for this functionality?

SMTP, HTTP, IMAP, WebSockets. (There are email providers that offer IMAPS and SMTPS over port 443.)

> ENCRYPTED NEGOTIATION
> This document specifies a partially encrypted negotiation mechanism:
> the server advertises some set of protocols (in the ServerHello)
> and the client specifies a specific protocol (in a separate
> handshake message inserted between the CCS and the Finished).
> The client's announcement need not match any of the protocols
> specified by the server. Thus, the negotiation is partly encrypted.
> 
> The reason for this appears to be that this mechanism is designed to
> prevent network attackers from learning which next protocol is being
> requested. (See Section 4). I'm extremely skeptical of this objective:

<snip>

> This wouldn't be a big deal except that this highly imperfect
> functionality comes at significant architectural cost. This mechanism
> is clearly more invasive and complicated than necessary to accomplish
> the goal of addressing cross-protocol attacks.

We should not send data unprotected when we can send it protected. I think this is a more important design goal.

We could generalize the mechanism so that the new message consists of a sequence of TLS extensions, to avoid creating new message types in the future.

Cheers,
Brian