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