Re: [TLS] Cleaning up 0-RTT Signaling (ciphersuites, replays, PSK context)

On Mon, Mar 28, 2016 at 9:11 AM, Benjamin Kaduk wrote: > > I understand there are good reasons to want to make the default behavior > of a single-physical-server TLS server as secure as possible, but I think > it's also well-understood that the more "exciting" portions of 0-RTT happen > in a distr

Re: [TLS] Cleaning up 0-RTT Signaling (ciphersuites, replays, PSK context)

On 03/25/2016 02:41 PM, Colm MacCárthaigh wrote: > On Fri, Mar 25, 2016 at 12:02 PM, Karthik Bhargavan > > wrote: > > > +1 but I think we can go further here and specify 0RTT in such a way > that it only works when the server > maintains state, and

Re: [TLS] Cleaning up 0-RTT Signaling (ciphersuites, replays, PSK context)

On Fri, Mar 25, 2016 at 12:24:32PM -0700, Eric Rescorla wrote: > On Fri, Mar 25, 2016 at 12:23 PM, Colm MacCárthaigh > wrote: > > > > An implementation would have to be willing to sacrifice replay protection, > > some cryptographic safety and forward secrecy for the 0RTT data. I'm sure > > there a

Re: [TLS] Cleaning up 0-RTT Signaling (ciphersuites, replays, PSK context)

On Fri, Mar 25, 2016 at 12:02 PM, Karthik Bhargavan < karthikeyan.bharga...@inria.fr> wrote: > > +1 but I think we can go further here and specify 0RTT in such a way > that it only works when the server maintains state, and so that any given > 0RTT ticket may only be used once (to preserve forward

Re: [TLS] Cleaning up 0-RTT Signaling (ciphersuites, replays, PSK context)

On Fri, Mar 25, 2016 at 12:24 PM, Eric Rescorla wrote: > The issue isn't encouraged. It's whether we should design the protocol so > that it cannot be implemented any other way. > I think it is encouraged ... not really intentionally, but economically. We all know that the keys encrypting TLS t

Re: [TLS] Cleaning up 0-RTT Signaling (ciphersuites, replays, PSK context)

On Fri, Mar 25, 2016 at 12:23 PM, Colm MacCárthaigh wrote: > On Fri, Mar 25, 2016 at 11:36 AM, Eric Rescorla wrote: > >> On Fri, Mar 25, 2016 at 11:27 AM, Colm MacCárthaigh >> wrote: >>> >>> +1 but I think we can go further here and specify 0RTT in such a way >>> that it only works when the ser

Re: [TLS] Cleaning up 0-RTT Signaling (ciphersuites, replays, PSK context)

On Fri, Mar 25, 2016 at 11:38 AM, Karthik Bhargavan < karthikeyan.bharga...@inria.fr> wrote: > Hi Eric, > > Yes, I now agree with Ilari and you that we should have a separate > pre_shared_key extension > in order to signal multiple PSKs. I wonder if we could still share the > structure between > P

Re: [TLS] Cleaning up 0-RTT Signaling (ciphersuites, replays, PSK context)

On Fri, Mar 25, 2016 at 11:36 AM, Eric Rescorla wrote: > On Fri, Mar 25, 2016 at 11:27 AM, Colm MacCárthaigh > wrote: >> >> +1 but I think we can go further here and specify 0RTT in such a way that >> it only works when the server maintains state, and so that any given 0RTT >> ticket may only be

Re: [TLS] Cleaning up 0-RTT Signaling (ciphersuites, replays, PSK context)

> +1 but I think we can go further here and specify 0RTT in such a way that it > only works when the server maintains state, and so that any given 0RTT ticket > may only be used once (to preserve forward secrecy as much as possible within > the constrains of 0RTT). Do you envision clients only

Re: [TLS] Cleaning up 0-RTT Signaling (ciphersuites, replays, PSK context)

Hi Eric, Yes, I now agree with Ilari and you that we should have a separate pre_shared_key extension in order to signal multiple PSKs. I wonder if we could still share the structure between PSK and DH though, although that’s mainly an aesthetic choice. > The second idea seems sensible, and I do

Re: [TLS] Cleaning up 0-RTT Signaling (ciphersuites, replays, PSK context)

On Fri, Mar 25, 2016 at 11:27 AM, Colm MacCárthaigh wrote: > > +1 but I think we can go further here and specify 0RTT in such a way that > it only works when the server maintains state, and so that any given 0RTT > ticket may only be used once (to preserve forward secrecy as much as > possible wit

Re: [TLS] Cleaning up 0-RTT Signaling (ciphersuites, replays, PSK context)

On Fri, Mar 25, 2016 at 2:29 AM, Karthik Bhargavan < karthikeyan.bharga...@inria.fr> wrote: > There has been much discussion on 0-RTT replay and here’s a quick summary > of my understanding. > We already knew that an active attacker, or a lossy network, or an > overzealous web browser could > and

Re: [TLS] Cleaning up 0-RTT Signaling (ciphersuites, replays, PSK context)

Karthik, Thanks for sending this. Some initial thoughts below. > After implementing and analyzing TLS 1.3, here are a few suggestions for discussion. > > 1) Early Data Extension > > The current early-data extension is too DH-specific. > When using PSK, we now have to look at both early_data and p

Re: [TLS] Cleaning up 0-RTT Signaling (ciphersuites, replays, PSK context)

On Fri, Mar 25, 2016 at 08:33:20AM -0700, Bill Cox wrote: > Adding 1 byte EarlyDataType seems like a good idea. > > As for the CipherSuite, assuming DH-0RTT goes away, would it be simpler to > require that the cipher suite negotiated from the original 1-RTT connection > be used? TLS_PSK_* or TLS_

Re: [TLS] Cleaning up 0-RTT Signaling (ciphersuites, replays, PSK context)

On Fri, Mar 25, 2016 at 8:33 AM, Bill Cox wrote: > Adding 1 byte EarlyDataType seems like a good idea. > > As for the CipherSuite, assuming DH-0RTT goes away, would it be simpler to > require that the cipher suite negotiated from the original 1-RTT connection > be used? > > For channel binding, t

Re: [TLS] Cleaning up 0-RTT Signaling (ciphersuites, replays, PSK context)

> You mean combining the 0-RTT aspects of pre_shared_key extension with > early_data? Because I don't think this type of structure can present what > PSK extension presents (e.g. multiple candidate PSK identities). Good question. For 0-RTT, multiple PSK identities make no sense, because we can on

Re: [TLS] Cleaning up 0-RTT Signaling (ciphersuites, replays, PSK context)

On Fri, Mar 25, 2016 at 10:29:06AM +0100, Karthik Bhargavan wrote: > We currently allow 0-RTT with Semi-static DH, with PSK resumption, and with > pure PSK. > Whether or not we keep all of these, it would be good to clean up the > protocol design > so that both the client and server have a unifo

[TLS] Cleaning up 0-RTT Signaling (ciphersuites, replays, PSK context)

We currently allow 0-RTT with Semi-static DH, with PSK resumption, and with pure PSK. Whether or not we keep all of these, it would be good to clean up the protocol design so that both the client and server have a uniform way of signaling their preferences. After implementing and analyzing TLS