On Tue, Feb 23, 2016 at 10:39:37PM -0500, Hugo Krawczyk wrote:
> On Tue, Feb 23, 2016 at 8:57 PM, Dave Garrett
> wrote:
>
> I suggest to also define TLS 1.3-EZ.
> A subset of core safe functionality that should address the majority of the
> usage cases.
What restrictions should there be for tha
>
> The server signature is essentially over raw handshake messages, up
> to and including ServerCertificate. The first message that would
> depend on actual value of SS is ServerFinished, which comes after
> that point…
Yes Ilari, you’re right.
In my TRON talk, I described an attack on PSK+Sign
On Wed, Feb 24, 2016 at 10:08:02AM -0800, Martin Thomson wrote:
> On 24 February 2016 at 10:00, Ilari Liusvaara
> wrote:
> > Be careful with that: One can get server impersonation attacks unless
> > one somehow binds the SS into signature (and unlike with client sigs,
> > there is no straightforw
On 24 February 2016 at 10:00, Ilari Liusvaara wrote:
> Be careful with that: One can get server impersonation attacks unless
> one somehow binds the SS into signature (and unlike with client sigs,
> there is no straightforward way).
The key schedule, in every variation I've seen proposed, does th
On Wed, Feb 24, 2016 at 07:54:27AM -0800, Martin Thomson wrote:
> PSK + DHE + signing
Be careful with that: One can get server impersonation attacks unless
one somehow binds the SS into signature (and unlike with client sigs,
there is no straightforward way).
-Ilari
___
On 24 February 2016 at 08:34, Watson Ladd wrote:
> And if we require a DH+sign every resumption, we don't gain anything
> over the full exchange except 0-RTT. Why is this server liveness issue
> not considered a problem for TLS 1.2 resumption?
It wouldn't be a requirement, merely an option.
In
On Wed, Feb 24, 2016 at 7:54 AM, Martin Thomson
wrote:
> On 24 February 2016 at 07:44, Subodh Iyengar wrote:
>> Unless we add a way for the client to require a server authentication during
>> PSK resumption.
>
> I have been arguing for this now for a while. If there is an
> incentive to do "PSK
On 24 February 2016 at 07:44, Subodh Iyengar wrote:
> Unless we add a way for the client to require a server authentication during
> PSK resumption.
I have been arguing for this now for a while. If there is an
incentive to do "PSK resumption" (there is), and that does not provide
the client a wa
Ladd
Cc: tls@ietf.org
Subject: Re: [TLS] Remove DH-based 0-RTT
On Wed, Feb 24, 2016 at 3:11 PM, Watson Ladd
mailto:watsonbl...@gmail.com>> wrote:
On Tue, Feb 23, 2016 at 7:39 PM, Hugo Krawczyk
mailto:h...@ee.technion.ac.il>> wrote:
>
>
> On Tue, Feb 23, 2016 at
On Wed, Feb 24, 2016 at 3:11 PM, Watson Ladd wrote:
> On Tue, Feb 23, 2016 at 7:39 PM, Hugo Krawczyk
> wrote:
> >
> >
> > On Tue, Feb 23, 2016 at 8:57 PM, Dave Garrett
> > wrote:
> >>
> >> On Tuesday, February 23, 2016 02:03:53 pm Martin Thomson wrote:
> >> > I propose that we remove DH-based 0
On Tue, Feb 23, 2016 at 7:39 PM, Hugo Krawczyk wrote:
>
>
> On Tue, Feb 23, 2016 at 8:57 PM, Dave Garrett
> wrote:
>>
>> On Tuesday, February 23, 2016 02:03:53 pm Martin Thomson wrote:
>> > I propose that we remove DH-based 0-RTT from TLS 1.3.
>> >
>> > As ekr's previous mail noted, the security
On Tue, Feb 23, 2016 at 8:57 PM, Dave Garrett
wrote:
> On Tuesday, February 23, 2016 02:03:53 pm Martin Thomson wrote:
> > I propose that we remove DH-based 0-RTT from TLS 1.3.
> >
> > As ekr's previous mail noted, the security properties of PSK-based
> > 0-RTT and DH-based 0-RTT are almost ident
On Tuesday, February 23, 2016 02:03:53 pm Martin Thomson wrote:
> I propose that we remove DH-based 0-RTT from TLS 1.3.
>
> As ekr's previous mail noted, the security properties of PSK-based
> 0-RTT and DH-based 0-RTT are almost identical. And DH-based 0-RTT is
> much more complex.
>
> For those
: Tuesday, February 23, 2016 11:39 AM
To: Wan-Teh Chang
Cc: tls@ietf.org
Subject: Re: [TLS] Remove DH-based 0-RTT
On 23 February 2016 at 11:24, Wan-Teh Chang wrote:
> It seems sufficient to just ban client authentication in replayable
> DH-based 0-RTT. Why remove DH-based 0-RTT altogethe
On 23 February 2016 at 11:24, Wan-Teh Chang wrote:
> It seems sufficient to just ban client authentication in replayable
> DH-based 0-RTT. Why remove DH-based 0-RTT altogether?
On the grounds that it is more complex to analyze, build, and test.
And given that deferring the feature does no signifi
15 matches
Mail list logo