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

[Eric Rescorla]

On Fri, Apr 1, 2016 at 7:19 AM, Stephen Farrell 
wrote:

>
> > 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  such as  because of .
> 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.
>

The issue isn't primarily the ciphers themselves, it's the security
properties of False Start. Specifically, TLS  is intended to allow a client
and server to negotiate the most preferred joint cipher suite, even if they
also support weaker cipher suites, even in the face of active attack [0].
In TLS 1.2, this guarantee is enforced by the Finished messages and
therefore the client isn't able to verify it at the time it sends its
second flight [1]. Thus, when you are doing False Start, the client has no
guarantee that an attacker hasn't forced him into a much weaker cipher
suite (potentially the weakest cipher suite that the client supports). Of
course, the handshake won't complete, but the client will have already sent
data under the weaker cipher suite.

The restrictions here are targeted at minimizing the exposure due to
potentially negotiating weaker ciphers with the general idea being that the
weakest cipher acceptable for false start is not too far away from the best
cipher. So, it's not really practical to pair it to specific cipher
properties.

-Ekr

[0] Note, this protection starts to break down if the weakest joint cipher
suite is really weak.
[1] This is why TLS 1.3 signs the entire server's second flight and why
False Start is redundant in TLS 1.3.

>
> 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
> >> TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
> >
> >
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Peter Bowen]

On Thu, Mar 31, 2016 at 6:19 PM, Sean Turner  wrote:
>
> 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.

I'm not a fan of this option simply because
draft-ietf-tls-negotiated-ff-dhe has been stuck is MISSREF state in
the RFC editor queue for months waiting on this draft.  I don't think
there is any question the ffdhe draft is forward looking and I, for
one, would like to see it published before TLS 1.3.

Thanks,
Peter

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Stephen Farrell]

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
>  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" :
>>> 
 (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

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

[Sean Turner]

On Mar 24, 2016, at 05:56, Stephen Farrell  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" :
>> 
>>> (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  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 

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

[Martin Thomson]

On 24 March 2016 at 11:38, Bodo Moeller  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...

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Bodo Moeller]

"Stephen Farrell" :

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

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

> (3) Why is there no description of the reasons for all
> the MUST only use whitelisted  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.

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."

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.

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
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Stephen Farrell]

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



smime.p7s
Description: S/MIME Cryptographic Signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls