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

[Stephen Farrell <[e-mail]>]

Hi Sean,

Thanks for moving this along,

On 01/04/16 02:19, Sean Turner wrote:
> On Mar 24, 2016, at 05:56, Stephen Farrell
> <[e-mail]> wrote:
>> 
>> 
>> 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" <[e-mail]>:
>>> 
>>>> (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.
> 
> 
> This draft started out as Informational and then we switched it
> Experimental.  The WG has not considered whether we should publish
> this should go Historic now, be held and publish as Historic later,
> etc.
> 
> How do folks feel about Historic vs Experimental vs Informational?
> 
> If we’re going to move it to Historic, then we’ve got a couple of
> options:
> 
> 0) As described above: Get it approved by the IESG, hold it in RFC
> editor’s queue, and publish it as historic at the same time TLS 1.3
> is published.
> 
> 1) Approve it, get it published, and then make it Historic with
> another draft.
> 
> 2) Approve it, get it published, and then make it Historic with an
> IESG initiated Protocol Action, which is a message that the IESG
> initiates requesting the status be changed similar to an IETF but
> requires no draft.
> 
> (there’s probably some other options like an adding an IESG note/new
> section that says “this goes to historic when TLS 1.3 is published,
> but I think the above three options seem more realistic.)
> 
> Option 0 is probably the least amount of work.  We just hold it, but
> in some sense I kind of tend to think that we’re punishing the
> authors.  There’s nothing they’ve really got to do, but it feels
> somehow like we’re hitting them upside the head with the process
> two-by-four.
> 
> Option 1 would be a total PITA.  People say that we can get a draft
> published quickly if we (the royal we) really want to, but my
> experience is otherwise.
> 
> Option 2 is something that I don't think we had in our toolkit when
> DKIM was being worked on.  The draft gets published the authors can
> move on and we (the process moths) can make sure the draft gets moved
> to Historic.
> 
> What do the WG members think about the options of moving to historic?
> Personally, I’d advocate option 2 because it keeps the work load on
> the chairs/AD :)

I'm fine with any of the above.

> 
> ~snipped 2~
> 
>>> 
>>>> (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.
> 
> The whitelisted options are described in the bullets in s4 and those
> point to s5.*

I'm still not seeing it. I do see things listed, but I don't
see any reasons why the things are listed.

The closest I see we get for now is: "The TLS protocol already
relies on such a security property for authentication -- with
False Start, the same is needed for encryption." But there's
quite a gap between that statement and the set of rules given
here.

> 
> It’s stuff like don’t use suspect symmetric ciphers.

But surely that's tautological? When would we ever recommend
using dodgy stuff? I think what's missing is a description of
or reference to what is particularly going to go wrong if you
use a ciphersuite with known attacks and do false-start.

That'd give the reader a chance to do an informed evaluation
for themselves as to whether or not some ciphersuite is or is
not safe with false-start. (And that evaluation will be done
at various points in future.)

> 
>>> 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.
> 
> I think this text is already present:
> 
> Clients MUST NOT use the False Start protocol modification in a 
> handshake unless the cipher suite uses a symmetric cipher that is 
> considered cryptographically strong.
> 
> In the key exchange algorithms and client certificate type security
> considerations, there’s:
> 
> The recommended whitelists are such that if cryptographic algorithms 
> suitable for forward secrecy would possibly be negotiated, no False 
> Start will take place if the current handshake fails to provide 
> forward secrecy.
> 
> .. and ..
> 
> Forward secrecy can be achieved using ephemeral Diffie-Hellman or
> ephemeral Elliptic-Curve Diffie-Hellman ...
> 
> If we summarize these in the Introduction we’re good?

No, I'm on about missing text not placement of text. Again if
we added something like "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" then we'd be done because a reader
could use that to analyse whether or not it is ok to use a future
ciphersuite (or a current one, being re-evaluated in the future) with
false-start.

Cheers,
S.

PS: If I'm just not managing to explain myself well here, we can
chat about it in B-A.

> 
> spt
> 
>> 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.)
>>> 
>> 
>> _______________________________________________ TLS mailing list 
>> [e-mail] https://www.ietf.org/mailman/listinfo/tls
> 
>