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
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
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
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
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
> 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 , but the
> ciphersuites 0x60
> +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
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
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
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
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
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_
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
> 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
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
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
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 is, in case of
> SHA-
17 matches
Mail list logo
