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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 24 March 2016 09:56 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 3C77E12D6CE for <tls@ietfa.amsl.com>; Thu, 24 Mar 2016 02:56:38 -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 EIQSEM8rZzg4 for <tls@ietfa.amsl.com>; Thu, 24 Mar 2016 02:56:35 -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 23BBE12D6CD for <tls@ietf.org>; Thu, 24 Mar 2016 02:56:35 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 24EC9BE33; Thu, 24 Mar 2016 09:56:32 +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 kYyw0OYb40RE; Thu, 24 Mar 2016 09:56:30 +0000 (GMT)
Received: from [10.87.49.100] (unknown [86.46.21.5]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B230FBE2D; Thu, 24 Mar 2016 09:56:29 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1458813390; bh=/ehXGgxeiZxAvAVQ/jUPtxG6M0J9Fa6Zd5MXL3H/mho=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=cvdZTDNV+EmAWBeSH6G9TMHvcSf7VCNlpF56oLoSINhv+i/YGS/1Fi45fhbWgkRc5 CMr48QtpeYrufEloZpjVeg/oRoLrEJzKz+9sbS4Ym1FN2Je2e7/Lv3gHhBKCCau2tG H4UAZJUridH99elSmAcLE5RG+iZjs1ntPrC8mKLU=
To: Bodo Moeller <bmoeller@acm.org>
References: <56F2B2E7.1060809@cs.tcd.ie> <CADMpkcLg4c2Q1Rq8n+HKzOM2Q7-S+VRmWy+W9kDOX5dZ9Z67Hg@mail.gmail.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <56F3B9CC.8050305@cs.tcd.ie>
Date: Thu, 24 Mar 2016 09:56:28 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <CADMpkcLg4c2Q1Rq8n+HKzOM2Q7-S+VRmWy+W9kDOX5dZ9Z67Hg@mail.gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms070808020205080108070205"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/YJpsHooInanxqiyondIMtbGGon4>
Cc: 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 09:56:38 -0000

Hiya,

Thanks for the speedy response...

Again #3 below is what I care about, the other stuff isn't
a big deal.

On 24/03/16 00:38, Bodo Moeller wrote:
> "Stephen Farrell" <stephen.farrell@cs.tcd.ie>:
> 
>> (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.)
> 
> I'm myself torn between "Experimental" and "Informational" (certainly not
> "Historic" because the spec has not been superseded by a more recent one
> and is not obsolete for any other reason [
> https://tools.ietf.org/html/rfc2026#section-4.2.4], unless we somehow
> manage to complete TLS 1.3 standardization before this). Taking into
> account how False Start is actually deployed (and taking into

Right. TLS1.3 will hopefully make this historic, so we could just
park this in the RFC editor queue and have both RFCs emerge on the
same day with this one as Historic. With did that with DKIM (4871)
and DomainKeys (4870, Historic) for example. Note that I'm not arguing
for doing that, just raising the option if that's what the WG want
and if the list hasn't discussed it. I assume though that the WG
don't want to take this route so no need to discuss it more in that
case.

> account that
> we expect it to eventually be replaced by a TLS 1.3 mechanism) and how our
> I-D is cited in research papers on TLS, "Experimental" sounds right to me:
> the spec really is part of a research and development effort [
> https://tools.ietf.org/html/rfc2026#section-4.2.4]. "Informational"
> wouldn't be wrong either.

I think the latter matches much better myself, as there really is
no experiment being done here and we're not gonna develop this any
more once TLS1.3 is done, but whatever - I'm ok with saying that
the WG just wanted experimental. But you'll likely get asked this
again and again. At least we can now point at this thread and say
that it was discussed on the list though. (Which was partly why I
asked:-)

It'd be no harm though if a couple of others chimed in on this
just to there's recorded opinion from more than just the AD and
an author.

We can change to informational at the end of LC if need be, i.e.,
there's no need to hold stuff up for that and such a change then
doesn't add any delay.

> 
>> (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.)
> 
> 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.

Fair enough, thanks. (Same to Martin for his follow up.)

> 
>> (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?
> 
> Well, I tried to capture the general reasoning in the spec -- but not the
> detailed reasons for the specific choices suggested, because that again
> would just go stale quickly.

Where are those general reasons stated? I don't see 'em.

> 
> In particular, I think this is an important observation in the I-D:
> 
> "If heuristically a small list of cipher suites and a single protocol
> version is found to be sufficient for the majority of TLS handshakes in
> practice, it could make sense to forego False Start for any handshake that
> does not match this expected pattern, even if there is no concrete reason
> to assume a cryptographic weakness."

That may be important but it doesn't address the issue about which
I'm asking.

> 
> So the whitelists should have algorithms that are actually used in practice
> and that don't have critical weaknesses, but why exactly those particular
> algorithms happen to get used in practice is mostly out of scope here.

Why is the logic behind such security relevant choices out of scope?
That makes no sense to me. Let's imagine a new ciphersuite is invented
and folks start to wonder whether or not it's ok to whitelist that for
false-start - wouldn't they expect this document to explain (maybe
mostly via references) why some ciphersuites are not good enough to
whitelist? I would expect that to be clear.

And to be clear, I'm not asking for an essay, but more like some text
in the intro saying "False start is not safe for a ciphersuite that
has properties <A,B,C> such as <example> because of <problem>. See
[refs] for full details."

For added clarity it'd also be good to have something like:
"Ciphersuites MUST have <good-properties X,Y,Z> to be safe to
whitelist for false-start."

If figuring out text for the above is very hard, then I do think that
would indicate a real issue with this spec. If figuring that out is
just a minor bit of tedium, then I think it's worthwhile so that
future readers of the RFC can understand what's going on here, which
I don't think is the case from the current text.

Cheers,
S.


> 
> Bodo
> 
>> 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.)
>