Oh, sure. In a similar vein, an attacker can also probe for which
identities are known to the server.
https://github.com/bifurcation/tls-pake/commit/0e72bd5244e89970fe61e5434ca7df3d769d057c
On Mon, Apr 16, 2018 at 3:06 PM, Jonathan Hoyland <
jonathan.hoyl...@gmail.com> wrote:
> You are, but it
You are, but it's not mentioned in the security section.
As it's a security consideration that you don't get in vanilla TLS I feel
that it should be mentioned.
Regards,
Jonathan
On Mon, 16 Apr 2018 at 20:01 Richard Barnes wrote:
> That's correct, however if I have a guess of the password can
> That's correct, however if I have a guess of the password can I not just
> try and connect using that password?
> If my guess is correct then the connection will succeed, whereas if my
> guess is incorrect then the connection will fail.
>
Sure, but aren't you going to have that with any password
Hi Richard,
That's correct, however if I have a guess of the password can I not just
try and connect using that password?
If my guess is correct then the connection will succeed, whereas if my
guess is incorrect then the connection will fail.
I'm assuming here that the salt is public, because salt
Hey Jonathan,
Thanks for the comments. I've implemented them in my working copy of the
draft, and in my implementation in mint. I have also changed it over to
use SPAKE2+; I agree with Tony that this is necessary to guard against
server compromise.
https://github.com/bifurcation/tls-pake/commit
Hi Richard,
A few nits.
* In the introduction you have the sentence
> DISCLAIMER: This is a work-in-progress draft of MLS and has not yet
seen significant security analysis.
Iiuc this draft has no connection to MLS, and this is a typo.
* In the setup you define
> o A DH group "G" of orde
Hi Richard,
I don't think that you can protect against server compromise with SPAKE2. The
server can store w*N as you suggest, but it also has to store w*M because it
must calculate y*(T-w*M). An attacker that learns w*M and w*N from a
compromised server can then impersonate a client.
The res
Hey Tony,
Thanks for the comments. Hopefully we can adapt this document to tick more
boxes for you :) Since I had noticed some other errors in the document
(e.g., figures not rendering properly), I went ahead and submitted a new
version that takes these comments into account.
https://tools.ietf
Hi Richard,
I work in the IoT space and am interested in handshakes that involve little
computation but offer better protection than symmetric PSK in the event of
server breach.
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Richard Barnes
Sent: 11 April 2018 15:54
[…]
We would love to h
Hey TLS folks,
As I mentioned in my brief presentation at IETF 101, Owen and I have been
thinking about how to bring PAKE back to TLS 1.3 (since earlier SRP
mechanisms don't really apply).
We've just published an I-D describing a proposed mechanism, and I've
implemented this mechanism in the `min
10 matches
Mail list logo
