Re: [hybi] On TLS-only Approaches

Adam Barth <ietf@adambarth.com> Mon, 23 August 2010 04:35 UTC

Return-Path: <ietf@adambarth.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 514433A685A for <hybi@core3.amsl.com>; Sun, 22 Aug 2010 21:35:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.119
X-Spam-Level:
X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[AWL=-0.142, 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 x68ha+f3cLkq for <hybi@core3.amsl.com>; Sun, 22 Aug 2010 21:35:50 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 721DD3A6993 for <hybi@ietf.org>; Sun, 22 Aug 2010 21:35:37 -0700 (PDT)
Received: by gxk20 with SMTP id 20so2300740gxk.31 for <hybi@ietf.org>; Sun, 22 Aug 2010 21:35:33 -0700 (PDT)
Received: by 10.100.197.3 with SMTP id u3mr4672468anf.208.1282538133336; Sun, 22 Aug 2010 21:35:33 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by mx.google.com with ESMTPS id q7sm10068127anf.6.2010.08.22.21.35.31 (version=SSLv3 cipher=RC4-MD5); Sun, 22 Aug 2010 21:35:32 -0700 (PDT)
Received: by iwn3 with SMTP id 3so5926770iwn.31 for <hybi@ietf.org>; Sun, 22 Aug 2010 21:35:31 -0700 (PDT)
Received: by 10.231.77.155 with SMTP id g27mr5453605ibk.195.1282538131162; Sun, 22 Aug 2010 21:35:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.187.218 with HTTP; Sun, 22 Aug 2010 21:35:01 -0700 (PDT)
In-Reply-To: <AANLkTimC6hmpDJk48Op8oUSObiMgUd6jhiKWmsn8V4VU@mail.gmail.com>
References: <AANLkTikJcbyEZ-Y0FOXni89L8Awa_UBmMMDvLgsOuoou@mail.gmail.com> <AANLkTin3r+f1Fn_X5O401PSANRrcgttLR-P4qMJZWKtV@mail.gmail.com> <A8694FF9-334D-42D9-ADDB-6AC23890F9DA@apple.com> <AANLkTinmfRG3qDUK0gYeDV2JEZP74CKWjSD42Mhi=+R+@mail.gmail.com> <AANLkTin5b-EsvSpAGNuOKCWDea_yA11dnRe1y3MNO0+G@mail.gmail.com> <AANLkTimC6hmpDJk48Op8oUSObiMgUd6jhiKWmsn8V4VU@mail.gmail.com>
From: Adam Barth <ietf@adambarth.com>
Date: Sun, 22 Aug 2010 21:35:01 -0700
Message-ID: <AANLkTinmNtaMmyomZiNy=+eO3AnWsD3tgYXNX6osan3q@mail.gmail.com>
To: John Tamplin <jat@google.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: Server-Initiated HTTP <hybi@ietf.org>
Subject: Re: [hybi] On TLS-only Approaches
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: Mon, 23 Aug 2010 04:35:57 -0000

On Sun, Aug 22, 2010 at 9:30 PM, John Tamplin <jat@google.com> wrote:
> On Mon, Aug 23, 2010 at 12:13 AM, Adam Barth <ietf@adambarth.com> wrote:
>> I should probably let EKR respond here, but I'll ask anyway.  What
>> does the message overhead look like for the null cipher spec?  We
>> don't necessarily need to use a non-null cipher spec for ws even if we
>> use a TLS handshake (of course, we need a reasonable cipher spec for
>> wss).
>
> It looks to me, according to openssl ciphers, the only NULL cipher supported
> is AECDH-NULL-SHA which still does SHA1 for integrity protection, so I
> assume it would have the same overhead.  RFC4346 seems to indicate a
> TLS_NULL_WITH_NULL_NULL CipherSuite option which would have a 0-byte MAC, so
> presumably you would only pay the 5-byte record overhead and there would be
> no padding.  That is more reasonable, but still seems large considering we
> have been arguing over a few bytes in the framing.

It's unclear to me whether those arguments have been reasonable, but
that's another discussion.  :)

I suppose another direction to explore is whether we can use the TLS
handshake and then drop the tunnel afterwards in the ws case.  Some of
our resident TLS experts might know.  I'd have to study the protocol
to see how that might work.

Adam