Re: [hybi] On TLS-only Approaches

Eric Rescorla <ekr@rtfm.com> Mon, 23 August 2010 14:13 UTC

Return-Path: <ekr@rtfm.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 96F6D3A69DD for <hybi@core3.amsl.com>; Mon, 23 Aug 2010 07:13:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.251
X-Spam-Level:
X-Spam-Status: No, score=-101.251 tagged_above=-999 required=5 tests=[AWL=0.725, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
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 231CCSF70dy8 for <hybi@core3.amsl.com>; Mon, 23 Aug 2010 07:13:04 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id B10BF3A6852 for <hybi@ietf.org>; Mon, 23 Aug 2010 07:13:03 -0700 (PDT)
Received: by bwz9 with SMTP id 9so5627682bwz.31 for <hybi@ietf.org>; Mon, 23 Aug 2010 07:13:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.204.81.130 with SMTP id x2mr3477110bkk.210.1282572816336; Mon, 23 Aug 2010 07:13:36 -0700 (PDT)
Received: by 10.204.7.70 with HTTP; Mon, 23 Aug 2010 07:13:36 -0700 (PDT)
In-Reply-To: <AANLkTin5b-EsvSpAGNuOKCWDea_yA11dnRe1y3MNO0+G@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>
Date: Mon, 23 Aug 2010 07:13:36 -0700
Message-ID: <AANLkTimjueG=KCieiVz1ZfN0u8n6qSGt1X1gQg984dH+@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
To: Adam Barth <ietf@adambarth.com>
Content-Type: multipart/alternative; boundary="0016e6d972b51dc7bb048e7e41c7"
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 14:13:05 -0000

I think people are

On Sun, Aug 22, 2010 at 9:13 PM, Adam Barth <ietf@adambarth.com> wrote:

> On Sun, Aug 22, 2010 at 9:05 PM, John Tamplin <jat@google.com> wrote:
> > Another related question:  as I understand it, TLS has some fairly
> > significant per-message overhead, on the order of 5 bytes per record,
> plus
> > the overhead for the encryption algorithm.  For AES128 CBC with SHA1, you
> > have a 20 byte hash plus padding up to 16 byte multiples, so that means
> > small frames will be enormously inefficient under TLS.  For example, we
> have
> > just been arguing for a handful of bytes in the framing, and this would
> > immediately use a minimum of 25 extra bytes per frame.   By the time you
> > count uncompressed TCP/IP headers and WS framing, we have used more than
> > half of the bytes in a low-power FACH frame for mobile devices (depending
> on
> > the carrier configuration about 128-256 bytes).
> > Unless there is some lower overhead option, it doesn't seem like that can
> be
> > mandated for all WebSocket connections.
>
> 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).
>
>
Choosing a message sort of arbitrarily to reply to here:

(1) I think Adam/Maciej are right that it would be desirable to offer a "use
TLS but don't
     expect the certificate to be OK" version.

(2) The host costs of TLS are generally pretty low.  In terms of code size,
< 100k is common.
     For instance, yaSSL claims 30-100k:
http://www.yassl.com/yaSSL/Products.html.
     I posted a link to AGL's writeup on the performance costs the other
day. I would note
     that it's been a long time since I've seen an embedded gizmo that did
HTTP but
     not HTTPS. Consider, for instance, that your average home wireless
gateway has a
     TLS stack for the management interface. I'd be interested in seeing
examples of
     embedded devices which are going to implement WS and do enough traffic
that
     TLS is going to be a big impact.

(3) The minimum wire overhead per TLS record (which of course may contain >1
WS
     frames if you buffer) is 5 bytes for the header. With the
truncated_hmac
     extension, you use a 10 byte MAC, getting the total down to 15 bytes.
TLS
     specifically forbids the negotiation of ciphers with neither
confidentiality nor
     integrity. I'm generally not real hot on the notion of negotiating TLS
and then
     "turning it off". At that point, why not just use RFC 2817 CONNECT and
send
     HTTP over it.

-Ekr