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
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
> 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 ,
> +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
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
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
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
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
> 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 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
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
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
12 matches
Mail list logo