Re: [TLS] TLS 1.2 Long-term Support Profile vs HTTP/2.0

[Dave Garrett]

On Friday, April 01, 2016 03:54:51 am Nikos Mavrogiannopoulos wrote:
> On Wed, 2016-03-16 at 12:36 +, Peter Gutmann wrote:
> > After a number of, uh, gentle reminders from people who have been
> > waiting for
> > this, I've finally got around to posting the TLS-LTS draft I
> > mentioned a while
> > back.  It's now available as:
> > 
> > > http://www.ietf.org/id/draft-gutmann-tls-lts-00.txt
> 
> I liked the idea of an LTS profile for TLS 1.2, however I just realized
> that RFC7540 [0] blacklists (with no rationale) 3 out of the 4 LTS
> ciphersuites and I'm wondering how practically useful will be that
> profile.
> 
> regards,
> Nikos
> 
> [0]. https://tools.ietf.org/html/rfc7540#appendix-A

As no such TLS 1.2 LTS existed at the time of publication (which multiple 
people, including myself, said would have been better), some kind of sane 
cipher restrictions were needed to avoid perpetual use of obsolete crypto. The 
consensus was requiring TLS 1.2+ with only PFS+AEAD cipher suites, however at 
the last minute implementors started complaining about the requirements and it 
was reduced to a blacklist of non-compliant cipher suites instead of requiring 
them to just update their APIs to handle things properly.

Noted at the end of the section:
https://tools.ietf.org/html/rfc7540#page-94


Dave

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

Re: [TLS] 0RTT and HelloRetryRequest (Re: Narrowing the replay window)

[Martin Thomson]

On 1 April 2016 at 03:46, Ilari Liusvaara  wrote:
>
>> > I believe Option #2 is simplest.
>>
>> I didn't mention this because I was composing on a phone at the time,
>> but we have to decide whether to allow a second attempt at 0-RTT.  If
>> we do, then the effect is a two round trip setback.  I think that the
>> odds of this happening are small, so I'm OK with it, but I wanted to
>> highlight that.
>
> Not taking it could mix poorly with DTLS, as DTLS rejects need to be
> stateless from server POV.

I thought that we'd already established that this is entirely possible.

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

Re: [TLS] Call for consensus: Removing DHE-based 0-RTT

[Hugo Krawczyk]

On Thu, Mar 31, 2016 at 11:49 PM, Eric Rescorla  wrote:

>
>
> On Thu, Mar 31, 2016 at 8:39 PM, Hugo Krawczyk 
> wrote:
>
>>
>>
>> On Tue, Mar 29, 2016 at 9:11 AM, Sean Turner  wrote:
>>
>>> All,
>>>
>>> To make sure we’ve got a clear way forward coming out of our BA
>>> sessions, we need to make sure there’s consensus on a couple of outstanding
>>> issues.  So...
>>>
>>> There also seems to be (rougher) consensus not to support 0-RTT via DHE
>>> (i.e., semi-static DHE) in TLS 1.3 at this time leaving the only 0-RTT mode
>>> as PSK. The security properties of PSK-based 0-RTT and DHE-based 0-RTT are
>>> almost identical,
>>
>>
>> ​I am not offering an opinion about what the WG should decide regarding
>> keeping
>> DHE-based 0-RTT in the base TLS 1.3 document, but just wanted to note
>> that the
>> above claim "The security properties of PSK-based 0-RTT and DHE-based
>> 0-RTT are
>> almost identical" is not quite right (nothing I say here is new, I just
>> felt
>> that I had to "object" to this statement as written).
>>
>> There are some significant differences - in some cases even "fundamental
>> differences" - between keeping secret state (in the PSK case) and keeping
>> non-secret state (in the DHE case) or even not keeping state at all (in
>> the
>> DHE case) and retrieving the server key g^s from some external source
>> (with
>> integrity but not secrecy).  In addition, using DHE 0-RTT would require
>> the
>> client to send a key share g^x leading to a PFS 1-RTT exchange while with
>> PSK
>> it may be "tempting" to omit PFS.
>>
>
> The current plan of record is to allow the server to specify which cipher
> suites it is
> willing to accept, so it could refuse this
>
>
​I was just wondering if this is what will happen in practice.
But I should have separated this consideration (and the next) from the more
fundamental point of public vs secret state.


>
>
> Moreover,  if the server's configuration
>> key g^s is refreshed often (say each 5 minutes) then the g^xs key used by
>> the
>> client to protect its 0-RTT data already has some good level of forward
>> secrecy (the attacker has a 5 minute window to find s and after that
>> forward
>> security is guaranteed).  The latter point touches on an important aspect
>> which is the key management complexity of ticket encryption/decryption
>> keys
>> (as needed in the PSK case) vs managing secret DH key s (in the DHE
>> case).
>> I am not sure what would be done better (more secure) in practice.
>>
>
> Can you expand on the difference here? Say that the server implements
> tickets
> by storing a DH private key and then encrypting the ticket under the
> corresponding
> public key. How does this provide different PFS properties?
>

​It doesn't. And you don't need a public key for this. If the server
rotates the ticket encrypting key ​

​often (say each 5 minutes as in the example) then you get the same effect.
The point was about which case, g^s or symmetric ticket encryption key will
be managed better in practice. I don't have an answer.

Hugo


> -Ekr
>
>
>> But really it seems that the discussion boils down to identifying cases of
>> enough interest where avoiding the original 1-RTT trip for establishing a
>> session ticket is important. I am puzzled by the fact that the Google team
>> seems ok with something that essentially voids the main feature and design
>> basis of of QUIC.
>>
>> Hugo​
>>
>> ​​
>>
>>> but 0-RTT PSK has better performance properties and is simpler to
>>> specify and implement. Note that this does not permanently preclude
>>> supporting DHE-based 0-RTT in a future extension, but it would not be in
>>> the initial TLS 1.3 RFC.
>>>
>>> If you think that we should keep DHE-based 0-RTT please indicate so now
>>> and provide your rationale.
>>>
>>> J
>>>
>>> ___
>>> 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

[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

[TLS] TLS 1.2 Long-term Support Profile vs HTTP/2.0

[Nikos Mavrogiannopoulos]

On Wed, 2016-03-16 at 12:36 +, Peter Gutmann wrote:
> After a number of, uh, gentle reminders from people who have been
> waiting for
> this, I've finally got around to posting the TLS-LTS draft I
> mentioned a while
> back.  It's now available as:
> 
> > http://www.ietf.org/id/draft-gutmann-tls-lts-00.txt

I liked the idea of an LTS profile for TLS 1.2, however I just realized
that RFC7540 [0] blacklists (with no rationale) 3 out of the 4 LTS
ciphersuites and I'm wondering how practically useful will be that
profile.

regards,
Nikos

[0]. https://tools.ietf.org/html/rfc7540#appendix-A


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