Removing DH based 0-RTT would make it more important to make the lifetime of
the ticket enforced.
One interesting difference is that DH based 0-RTT requires proof of possession
of the private key for the client to accept the connection, however PSK based
0-RTT might not be associated with a cer
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
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 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 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 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 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 02/06/2016 02:36 PM, Yaron Sheffer wrote:
> The draft describes using an opaque ticket (similar to a session
> resumption ticket) to pin the identity of a TLS server. The new
> version addresses several comments on this list, in particular
> regarding the message syntax, and requesting a compari
Hi Jeff,
Tls13-11 I-D is not very clear on this, but my reading is that exporter_secret
is the TLS 1.3 version of the Keying Material Exporters. If this is correct,
then there are two pieces currently missing: the ability to specify a custom
label and the ability to mix in application context.
> Tls13-11 I-D is not very clear on this, but my reading is that
> exporter_secret is the TLS 1.3 version of the Keying Material Exporters.
> If this is correct, then there are two pieces currently missing: the
> ability to specify a custom label and the ability to mix in application
> context. I
Thanks for the feedback, everyone. The OpenSSL SRP code is staying.
--
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Hi,
> Although the lack of modern cipher-suites for SRP makes it not very
> attractive these days.
>
Does anyone know if work on something like "ECSRP" is going on, anywhere?
We've recently worked on getting it working with PKCS #11,
https://github.com/arpa2/srp-pkcs11
https://github.com/arpa2/s
> On 23 Feb 2016, at 16:34, Salz, Rich wrote:
>
> Is anyone using SRP with TLS? The OpenSSL implementation in particular?
>
I have been in the past and know of some installations and customers that
actually use it.
Although the lack of modern cipher-suites for SRP makes it not very attractiv
>
> 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
14 matches
Mail list logo
