Re: [hybi] Websocket success rates and TLS extension.

Justin Erenkrantz <justin@erenkrantz.com> Sat, 17 April 2010 07:46 UTC

Return-Path: <justin.erenkrantz@gmail.com>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0C413A6A89 for <hybi@core3.amsl.com>; Sat, 17 Apr 2010 00:46:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.724
X-Spam-Level:
X-Spam-Status: No, score=-0.724 tagged_above=-999 required=5 tests=[AWL=1.254, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6oiCALyd2bV3 for <hybi@core3.amsl.com>; Sat, 17 Apr 2010 00:46:10 -0700 (PDT)
Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by core3.amsl.com (Postfix) with ESMTP id 85B233A6912 for <hybi@ietf.org>; Sat, 17 Apr 2010 00:46:09 -0700 (PDT)
Received: by qw-out-2122.google.com with SMTP id 9so1078950qwb.31 for <hybi@ietf.org>; Sat, 17 Apr 2010 00:45:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:received:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=f4a2kedvmmJ+QV8xGbW8H2NfIC3JmqYYa+iDTnkj5/g=; b=kaxqD5t9I6nGnLjiKh5BjFEojbl3i0+Px+bqYyCjnlKzWoMYV0YeOCLRgdYRcZL1Rx RgAPfJ3W36ytgFQH/XTp6g6rHXX39VLimQCXuQm+KPXHvHsdFlVlc1XsDZ26o1XRyWLm RB7fFmuL3VHWbEopcTNA6SliZ8roOwKVqrEjY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=U1XAuauRS/PunNZf79xEToRwxl9Ms+LjnG6eYQnhDjjPRB3ysXOk2mIseJmryaUVC5 mYkPlNJJXaZoOVnlosFHpZS5dVixVc0QpCM5DEViOzIFMNTmgH/+u8D4apsaoxfjLiue SS1qNRLAJlD8fVwa2bXUF4dhqjC/hHGzlKDzo=
MIME-Version: 1.0
Sender: justin.erenkrantz@gmail.com
Received: by 10.229.17.84 with HTTP; Sat, 17 Apr 2010 00:45:58 -0700 (PDT)
In-Reply-To: <4BBAECB7.2030009@webtide.com>
References: <4BBAECB7.2030009@webtide.com>
Date: Sat, 17 Apr 2010 00:45:58 -0700
X-Google-Sender-Auth: c4b7ca63f391bb51
Received: by 10.229.186.211 with SMTP id ct19mr3770782qcb.16.1271490358516; Sat, 17 Apr 2010 00:45:58 -0700 (PDT)
Message-ID: <n2j5c902b9e1004170045if1df8e7atf67f926c1452996@mail.gmail.com>
From: Justin Erenkrantz <justin@erenkrantz.com>
To: Greg Wilkins <gregw@webtide.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] Websocket success rates and TLS extension.
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 17 Apr 2010 07:46:11 -0000

On Tue, Apr 6, 2010 at 1:11 AM, Greg Wilkins <gregw@webtide.com> wrote:
> Because TLS negotiations represent round trips, they
> don't want extra round trips for framing negotiations.
> Hence they have proposed a TLS extension to allow
> protocol negotiation during TLS handshake.
>
>  http://tools.ietf.org/html/draft-agl-tls-nextprotoneg-00
>
> This would allow a TLS connection to be negotiated
> with an application protocol and further round trips
> avoided.

Sorry for coming back to this, but Mike's later posts reminded me of
this comment as a way to reduce round-trips.

This is interesting, but the ID doesn't really contain a useful
description of how it would be implemented - it punts that out of
scope and that's the more critical bit, I think.  I'm just not sure I
understand what the "selected_protocol" field would say at all.

Regardless of the vagueness of this ID, doing something to optimize
latency is important.  If this TLS extension makes it way into
OpenSSL, I'm sure httpd/mod_ssl could easily pick up on it.  Is an
implementation available or planned?

I don't know how hard it is for Java servers to support TLS extensions
- I'm sure you know, Greg.  =P  -- justin