Re: [TLS] Mass 0RTT of subresources with no prior knowledge (was Re: Do we actually need semi-static DHE-based 0-RTT?)

I don't believe that this is going to work very well, since it is a fairly large burden for referring servers to refresh their state. -Ekr On Fri, Feb 19, 2016 at 5:00 PM, Dave Garrett wrote: > On Friday, February 19, 2016 07:47:31 pm Martin Thomson wrote: > > This

Re: [TLS] Mass 0RTT of subresources with no prior knowledge (was Re: Do we actually need semi-static DHE-based 0-RTT?)

This really only helps on the first connection attempt. Browsers already pre-warm connections to subresource hosts. On 19 February 2016 at 16:38, Dave Garrett wrote: > I just had an idea. There is significant doubt of how useful semi-static DHE > 0RTT would be due to

[TLS] Mass 0RTT of subresources with no prior knowledge (was Re: Do we actually need semi-static DHE-based 0-RTT?)

I just had an idea. There is significant doubt of how useful semi-static DHE 0RTT would be due to the difficulty of distributing the configs out-of-bound. I don't dispute this; I merely dispute that no capability is better than minimal, in this realm. There is another way that they could be

Re: [TLS] Do we actually need semi-static DHE-based 0-RTT?

On Fri, Feb 19, 2016 at 4:15 PM, Dave Garrett wrote: > On Friday, February 19, 2016 05:24:25 pm Eric Rescorla wrote: > > My impression is exactly the opposite. All the infrastructure to > PSK-resumption and > > hence PSK-0RTT is already in place for TLS 1.2. And of course

Re: [TLS] Do we actually need semi-static DHE-based 0-RTT?

I would also suggest keeping PSK 0RTT. On of the things I'm looking at is postquatum cryptography (that is, cryptography that would still be secure even if someone manages to build a large quantum computer). While this is not the most important issue that TLS 1.3 needs to deal with; it's

Re: [TLS] Do we actually need semi-static DHE-based 0-RTT?

On Fri, Feb 19, 2016 at 3:08 PM, Dave Garrett wrote: > On Friday, February 19, 2016 12:57:04 am Bill Cox wrote: > > Having two different modes to achieve basically the same > > thing in TLS 1.3 is a bad idea. > > On Friday, February 19, 2016 10:01:31 am Salz, Rich wrote:

Re: [TLS] Do we actually need semi-static DHE-based 0-RTT?

On Friday, February 19, 2016 12:57:04 am Bill Cox wrote: > Having two different modes to achieve basically the same > thing in TLS 1.3 is a bad idea. On Friday, February 19, 2016 10:01:31 am Salz, Rich wrote: > I greatly prefer one way to do things. I do not fundamentally disagree. I would

Re: [TLS] Proposal: don't change keys between handshake and application layer

On Fri, Feb 19, 2016 at 12:58 PM, Cedric Fournet wrote: > As pointed out by Karthik, we are not strongly advocating this > simplification, but we do not think it would weaken the security of TLS. > Details below. > I am glad you are not strongly advocating this. I

Re: [TLS] Proposal: Simplified Key Schedule

Couple of comments below. On Fri, Feb 19, 2016 at 9:14 AM, Eric Rescorla wrote: > > > On Fri, Feb 19, 2016 at 2:12 AM, Karthikeyan Bhargavan < > karthik.bharga...@gmail.com> wrote: > >> >> Note that this is (almost) exactly the original KDF scheme of OPTLS as I >> presented in

Re: [TLS] PSK and client verify

On Fri, Feb 19, 2016 at 11:25 AM, Watson Ladd wrote: > Cf 6.3.4.2. Certificate Verify with 6.3.5.1. New Session Ticket Message > > and we see that client certificate verification is allowed for some > PSK exchanges and not others, and that the PSK exchanges used in >

[TLS] PSK and client verify

Cf 6.3.4.2. Certificate Verify with 6.3.5.1. New Session Ticket Message and we see that client certificate verification is allowed for some PSK exchanges and not others, and that the PSK exchanges used in resumption are ones where it is allowed. (Maybe I am reading that wrong) Right now this

Re: [TLS] Do we actually need semi-static DHE-based 0-RTT?

+ TLS WG On Fri, Feb 19, 2016 at 8:46 AM, Eric Rescorla wrote: > > On Fri, Feb 19, 2016 at 8:01 AM, Salz, Rich wrote: > >> I greatly prefer one way to do things. (Python not perl, if you will :) >> >> On the other hand, there is an elegance about using a

Re: [TLS] Proposal: don't change keys between handshake and application layer

As pointed out by Karthik, we are not strongly advocating this simplification, but we do not think it would weaken the security of TLS. Details below. -Cédric, with the miTLS team In the following, I only consider the record layer keys, which are used for authenticated encryption; I ignore

Re: [TLS] Proposal: don't change keys between handshake and application layer

On Fri, Feb 19, 2016 at 3:58 AM, Ilari Liusvaara wrote: > On Fri, Feb 19, 2016 at 10:04:38AM +0100, Karthikeyan Bhargavan wrote: > > > Regardless of whether we make this change though, I think it would be > > useful for the TLS 1.3 RFC to clearly limit the scope of

Re: [TLS] Proposal: Simplified Key Schedule

On Fri, Feb 19, 2016 at 2:12 AM, Karthikeyan Bhargavan < karthik.bharga...@gmail.com> wrote: > > Note that this is (almost) exactly the original KDF scheme of OPTLS as I > presented in Dallas > > > Indeed, Ekr’s proposed scheme looks much like you original diagram. > I would like to clarify that

Re: [TLS] Proposal: don't change keys between handshake and application layer

On Fri, Feb 19, 2016 at 10:04:38AM +0100, Karthikeyan Bhargavan wrote: > Regardless of whether we make this change though, I think it would be > useful for the TLS 1.3 RFC to clearly limit the scope of various keys > generated by the handshake. During the connection lifetime, we generate > a

Re: [TLS] Proposal: Simplified Key Schedule

> Note that this is (almost) exactly the original KDF scheme of OPTLS as I > presented in Dallas Indeed, Ekr’s proposed scheme looks much like you original diagram. > Anyway, from here you can see that the last HKDF in your scheme (with 0 salt) > is not needed. You can derive the RMS, EMS keys

Re: [TLS] Proposal: don't change keys between handshake and application layer

I do not have a very strong opinion on whether the same traffic keys can or should be used for the handshake and application. As Hugo says, it complicates the cryptographic analysis but we do know now how to do the analysis for such key usage, thanks to years of work on TLS <= 1.2. I am told