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

[Sean Turner <[e-mail]>]

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 :)

~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.*

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

>> 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?

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