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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Wed, 23 March 2016 15:15 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 4CB4E12D0EE for <tls@ietfa.amsl.com>; Wed, 23 Mar 2016 08:15:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Level:
X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 6r3NSuMPpBtt for <tls@ietfa.amsl.com>; Wed, 23 Mar 2016 08:14:57 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EE0A12D598 for <tls@ietf.org>; Wed, 23 Mar 2016 08:14:52 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C4EF2BE2D for <tls@ietf.org>; Wed, 23 Mar 2016 15:14:50 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXVyw2YVIvlL for <tls@ietf.org>; Wed, 23 Mar 2016 15:14:48 +0000 (GMT)
Received: from [192.150.181.133] (unknown [192.150.181.133]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A2CF0BDD0 for <tls@ietf.org>; Wed, 23 Mar 2016 15:14:47 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1458746088; bh=Wox9GMT0pvG43KK89lz8PEgYIb9i8eA9AafEKJATuQw=; h=To:From:Subject:Date:From; b=A8rRSW+bMJokZNE6LKzKc0Fv5b/mU5RMgUsodxZKoQuhtsU3HX8+EGvBp0aW4fjcl FpfTKaDh7NPZ0NZBfzYO3BiY5yZJkjwIo707JpV6JSrZow4vhws44p/XvIaNmm7WXi D3pa78qpiYNz+qI7+I5icCDAoUxbdNSC00OfV7yE=
To: "tls@ietf.org" <tls@ietf.org>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <56F2B2E7.1060809@cs.tcd.ie>
Date: Wed, 23 Mar 2016 15:14:47 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms090404070109050808020306"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/UDiFtVrQhjP9MXMW45tiYHrCDn8>
Subject: [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: Wed, 23 Mar 2016 15:15:00 -0000

Hiya,

I've done my AD review of this and have three questions
I'd like to ask before starting IETF last call. I mostly
care about the answer to #3. #1 is just a suggestion that
might avoid some process-crap and #2 is just me being
curious (unless #2 turns out to be a part of #3).

(1) Why experimental? Wouldn't this be better as info
and documented as "here's a spec for a thing that's
widely deployed." I fear we may get questions like
"what's the experiment?", "where's this going in
future?" if this aims for experimental, and info may
avoid that esp if we really want people to move to
TLS1.3. I also didn't see list discussion about what
kind of RFC to aim for, but maybe it was discussed at
a meeting or interim? (Apologies if I missed that in
my scan of the list.)

(2) The write up and some mail list traffic and AGL's
bloggy thing all refer to NPN, but there's no mention of
NPN or ALPN in the draft.  What's up with that? (Not
saying that needs to be explained, but I wondered.)

(3) Why is there no description of the reasons for all
the MUST only use whitelisted <foo> and for the choices
that are whitelisted?  Wouldn't omitting that tend to
lead people to use this more badly?  That could be done
with some explanatory text and using some of the
references below maybe. Or, if we don't really want new
folks to implement this (do we?) then just saying that
might mean it's ok to not explain the "why." (And then
you could also address #1 above then by issuing this
as an historic RFC too if you wanted.)

Cheers,
S.

Possible refs:
 - http://www.ieee-security.org/TC/SP2015/papers-archived/6949a535.pdf
   (esp Section V-C)
 - http://homes.esat.kuleuven.be/~fvercaut/papers/ACM2012.pdf
 - https://hal.inria.fr/hal-01184171/document
 - https://arxiv.org/pdf/1602.02396.pdf
 - https://eprint.iacr.org/2016/072.pdf