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

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

Re: [TLS] Publishing draft-ietf-tls-56-bit-ciphersuites as Historic

> On 25 Mar 2016, at 8:16 PM, Yuhong Bao wrote: > > I wonder if it would be possible to publish > draft-ietf-tls-56-bit-ciphersuites as Historic (in the sense of RFC 6101). > It would start with > https://tools.ietf.org/html/draft-ietf-tls-56-bit-ciphersuites-01 ,

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

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

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

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)

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

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

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

[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

Re: [TLS] TLS 1.2 Long-term Support Profile draft posted

Hubert Kario writes: >I was thinking of something like the following: > > The length of verify_data (verify_data_length) in the Finished message > MUST be equal to the length of output of the hash function used as the > basis of the PRF selected for the ciphersuite. That