Re: [TLS] AD review of draft-ietf-tls-falsestart-01

Martin Thomson <martin.thomson@gmail.com> Thu, 24 March 2016 05:27 UTC

Return-Path: <martin.thomson@gmail.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 A835B12D515 for <tls@ietfa.amsl.com>; Wed, 23 Mar 2016 22:27:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 5JxNiiVI4uJy for <tls@ietfa.amsl.com>; Wed, 23 Mar 2016 22:27:20 -0700 (PDT)
Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C602A12D168 for <tls@ietf.org>; Wed, 23 Mar 2016 22:27:20 -0700 (PDT)
Received: by mail-io0-x232.google.com with SMTP id m184so75606617iof.1 for <tls@ietf.org>; Wed, 23 Mar 2016 22:27:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=hIBL1SUI/Fz8fA6fbQ4SK7BrYzB+8GabNBu+AxINKI4=; b=T/ZFR1TTMzG1wdO1Raoyp1WbZxqKcCwtHJbOGPIJ3WGQh28esrjG3+Z/ysJKqan9Pd rVDjkaaypDSx5tPdch83j7Dt7QRglI4iPVWBT9szw1v/24O3aNdIm/xysAyhdWeeCocl dFrHijEDZs/bSi36brZ+JOnl8p0QbcZhjjwk8NzDcHOe1kguGLubM5JxeIqNM9ilEWMI P6UMWDqU1GdneJrZ3L6NHpGQv/LZ2/qrfQ39gpzoc1Fxu7m5eYIawk9gjNbvC9sNwTme AQ7Q7csxFrRAq1qAK1mIPPSMtn+DmwACFninwKXETl3WfxmLhNSWngCYIdU2TW28LDJE uXcg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=hIBL1SUI/Fz8fA6fbQ4SK7BrYzB+8GabNBu+AxINKI4=; b=JchywvY9c0nkdu9MeiTx3qcqRR0zO6jfOT053bP4uSjvmDQWQN0Vr389m+Vk3zx5bs i8I0YP+olUo7WVqKbu4CYHboDW30YUdqIHHaGisjEEbuUj4SNV/wYEKNqf6UlqYgWim+ Q0cM9nJJu7pdKexTfbCQatUg876Cw7efBPltQQYdevShcnMXaui2ileRi8NPmca4c5Jc X+SYqwiEqIL3evZpEtUSheqejsaAUT8iJThHI5dxA99TEB6m4Rfk5AXWfJsJyYXeOyp0 Zxyy6DX+MV+L2dYNDGZEG1RL2EU88UWhiVuhiseWTdVyjKKD83ZlI2TsicCPAlvDH/k3 PGXg==
X-Gm-Message-State: AD7BkJI4MxquClLO1gDK6awQwwJvyaNVnd9NCvlE7Alcf5hxkbrut1+JvWZVxM7OT0kYSwjDF1vUcFQdwGkCcA==
MIME-Version: 1.0
X-Received: by 10.107.34.139 with SMTP id i133mr6545524ioi.108.1458797240166; Wed, 23 Mar 2016 22:27:20 -0700 (PDT)
Received: by 10.36.43.142 with HTTP; Wed, 23 Mar 2016 22:27:20 -0700 (PDT)
In-Reply-To: <CADMpkcLg4c2Q1Rq8n+HKzOM2Q7-S+VRmWy+W9kDOX5dZ9Z67Hg@mail.gmail.com>
References: <56F2B2E7.1060809@cs.tcd.ie> <CADMpkcLg4c2Q1Rq8n+HKzOM2Q7-S+VRmWy+W9kDOX5dZ9Z67Hg@mail.gmail.com>
Date: Thu, 24 Mar 2016 16:27:20 +1100
Message-ID: <CABkgnnU2V91RGzm1Sq5ubckwm3h8h-x4-uAwdbTfn71_rhh41Q@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Bodo Moeller <bmoeller@acm.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/eJh1I9e0Xa0gbhhSHc8hXlIOV3c>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] AD review of draft-ietf-tls-falsestart-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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, 24 Mar 2016 05:27:22 -0000

On 24 March 2016 at 11:38, Bodo Moeller <bmoeller@acm.org> wrote:
> The NPN dependency was a design decision for one implementation, but it's
> not common to clients using False Start. For interoperability, you always
> have to consider how to deal with what you expect to be deployed *currently*
> (and NPN support certainly is one good indicator for False Start tolerance,
> if you don't mind tons of false negatives), but I wouldn't see much value in
> compiling the minutae of that in this kind of document: it'll go stale
> quickly.

But I agree with this analysis, the original reason for the test was -
if a little iffy - rational. Correlation might not imply causation,
but sometimes correlation is all you need.

BTW, Firefox still has the option to require that a site advertise NPN
(or ALPN) before false starting.  It's off by default and hard to
find, but it's there.  And there are still people who flip that bit.

As a feature, it's not one we need to keep.  I certainly wouldn't want
to bless it by putting it in an RFC, Experimental or otherwise.  Let's
chalk that up to the ugly things we have to do to get things to work.

Which reminds me...