IETF Logo Mail Archive

Re: [TLS] Bakeoffs

Patrick McManus <pmcmanus@mozilla.com> Thu, 17 April 2014 13:41 UTC

Return-Path: <patrick.ducksong@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B11B61A016D for <tls@ietfa.amsl.com>; Thu, 17 Apr 2014 06:41:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hh9rMyzsPnYA for <tls@ietfa.amsl.com>; Thu, 17 Apr 2014 06:41:11 -0700 (PDT)
Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::234]) by ietfa.amsl.com (Postfix) with ESMTP id 34CF81A015A for <tls@ietf.org>; Thu, 17 Apr 2014 06:41:11 -0700 (PDT)
Received: by mail-qg0-f52.google.com with SMTP id q107so422190qgd.11 for <tls@ietf.org>; Thu, 17 Apr 2014 06:41:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=a/kFzcjgfNN9YfgVwdT0o2ZFqqnZZY4nKlu7xx4bA2s=; b=LGsQ6rgG9abHvsALdQ93bjRu63PcKFeq5DxP+eqdtyHg8yiW2o/DDoHDiARc1/tUVc oVWYVPlPx8DgV6m/2B2u+GyirrwwJkBXueALdliLNglxnkwt3hneY+WQZoL07Q29KEg2 mK4bDWvfArIpQ5YNBod/QwC4Flr+WqrvzWmVYqf2+xY5il8zDh13vIIA8XGhHZ+vyYnY FdPVybK2W124BZ4XRERsyDfoppDNsLI4MzToB3pz8N2zWA7LPu6mxmoLpwfMb3NNdiQk cnH0Y4flf+t9TZ4hLLPmSnTxs+7QosEFf+YC6rUjkkOX4i5eS3MiRvtiYRQvjI56XL/Y bBWA==
MIME-Version: 1.0
X-Received: by 10.229.17.69 with SMTP id r5mr11678583qca.7.1397742067556; Thu, 17 Apr 2014 06:41:07 -0700 (PDT)
Sender: patrick.ducksong@gmail.com
Received: by 10.140.93.180 with HTTP; Thu, 17 Apr 2014 06:41:07 -0700 (PDT)
In-Reply-To: <7EBCF98B-FFE6-49D3-B899-A297C8AAA463@apple.com>
References: <FAD11A6F-DB65-4797-89C2-022DCDED266F@iii.ca> <CACsn0ck5u_Sy7tvAbiT0mwRz0rkw4ZBW23F3R8qBV0urFEq21w@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B4905A5@USMBX1.msg.corp.akamai.com> <CAGZ8ZG1C8L1LW=H__FCiuK-Ywq_c63-pxW39QoCR6f0k1wd2Xg@mail.gmail.com> <534F09D6.1060308@akr.io> <CAGZ8ZG0kCxBa44cSrwF9kjsutp=ooR3QV98OWueFBZga79tMHA@mail.gmail.com> <CABkgnnWwm_z5czbH_=s8bBXMWDU_wGQLxAMh0Ay8VMqBDaywiw@mail.gmail.com> <7EBCF98B-FFE6-49D3-B899-A297C8AAA463@apple.com>
Date: Thu, 17 Apr 2014 09:41:07 -0400
X-Google-Sender-Auth: zlruobiJQbqCXO8iYCYKqkBb0X8
Message-ID: <CAOdDvNoZ-jThwC15FCMr=jTTeiTKsM3wZMLtqCBdFX-=CXjaFg@mail.gmail.com>
From: Patrick McManus <pmcmanus@mozilla.com>
To: Michael Sweet <msweet@apple.com>
Content-Type: multipart/alternative; boundary="001a1133c9386ca87f04f73d2fa7"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/CUK18QOgLiH0KDXjXNF5t-Luslc
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Bakeoffs
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 17 Apr 2014 13:41:12 -0000

On Thu, Apr 17, 2014 at 8:19 AM, Michael Sweet <msweet@apple.com> wrote:
>> FWIW, 1-RTT latency is mainly an issue when you have a browser making a
dozen connections to a secure site.  With HTTP/2 that particular problem
goes away...

As a browser guy I'll say I really disagree with that.

HTTP/2 is important stuff, and helps hide part of the problem, but the
latency issue continues to be an issue for HTTP over TLS use cases. Time to
first byte of course, but also to each different referenced origin (the
cdn, the third-party ad network, the identity provider, etc..). Often
things that block layout are on that cdn (e.g. stylesheets, some
javascript) so the time to perform 2 http transactions on 2 serialized tls
terminated connections is often the same as time to first screen draw. Its
considerably worse in mobile environments where RTT can be out of control.

Establishing TLS is noticeably slow, and that's a problem for the browser
use case where https often competes against http for developer mind share.
As a natural result, some content providers choose to run plaintext http
which we can all agree is an undesirable outcome. Shrinking that gap will
help.

_________________________________________________________

> Michael Sweet, Senior Printing System Engineer, PWG Chair
>
>

v2.23.0 | Report a Bug | By Email