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
Hi dear TLS experts,
Apologies for my stupid question for advise:
I am currently working on some design requirements for mutual authentication
and have a question regarding verification of client certificate.
In many web scenarios the simple use is server authentication by certificate
a
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
I am not aware of anywhere this is documented, primarily because it's so
application-specifiic.
-Ekr
On Mon, Apr 16, 2018 at 2:56 AM, Tobias Gondrom
wrote:
> Hi dear TLS experts,
>
>
>
> Apologies for my stupid question for advise:
>
> I am currently working on some design requirements for mut
Hi Tobias,
If you use search terms that include pkix, authorization, access control, and
attribute certificate profile, you’ll find a few documents. This one should be
helpful based on your description:
https://tools.ietf.org/html/rfc5755
Best regards,
Kathleen
Sent from my mobile device
>
On Mon, Apr 16, 2018 at 2:56 AM, Tobias Gondrom
wrote:
> Are there any RFCs that speak (beyond the general verification of the
> certificate in mutual TLS authentication) to the need to also verify the CN
> inside the client certificate against an additional whitelist _*before*_
> establishing a
On Fri, Apr 13, 2018 at 04:38:55PM -0400, Richard Barnes wrote:
> On Fri, Apr 13, 2018 at 4:30 PM, Nico Williams
> wrote:
> > It's better to send the denial of existence than no extension -- the
> > client could just as well be pinning (because the I-D said it could, or
> > because the client does
Hi Kathleen, Ekr and Tony,
Thank you so much for your fast feedback.
I did google a bit before asking, but didn’t dig deep enough into the document
to find the right one.
Your answers were most helpful.
And I will dig more into the RFC link from Kathleen and the github link from
Tony.
> On Apr 16, 2018, at 5:56 AM, Tobias Gondrom
> wrote:
>
> Are there any informational (or standard) RFCs for TLS that speak about this
> risk and best practices to address it?
> (e.g. using additional whitelist checks of parameters inside the client
> certificate for access control checks
On Fri, Apr 13, 2018 at 12:16:43PM -0700, Jim Fenton wrote:
> From reading the abstract and introduction to this draft, it appears to
> be proposing mostly a performance improvement for retrieving web pages
> using DANE authentication. There is some security improvement, but that
> seems to be inci
> On Apr 16, 2018, at 12:31 PM, Nico Williams wrote:
>
> I wouldn't mind a (C'): a variant of (C) where we get denial of
> existence and a one- or two-byte TTL (one by count of weeks or two-byte
> count of hours) with de minimis text about it, leaving pinning semantics
> to a separate document.
On 4/16/18 at 9:31 AM, n...@cryptonector.com (Nico Williams) wrote:
I wouldn't mind a (C'): a variant of (C) where we get denial of
existence and a one- or two-byte TTL (one by count of weeks or two-byte
count of hours) with de minimis text about it, leaving pinning semantics
to a separate docum
On Mon, Apr 16, 2018 at 9:11 AM, Viktor Dukhovni
wrote:
> A major obstacle to making access control decisions during the TLS
> handshake is that at that time the server often does not yet have enough
> information to determine which specific resource the client will ask to
> access.
There's als
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
On Mon, Apr 16, 2018 at 11:38:28AM -0700, Tony Arcieri wrote:
> On Mon, Apr 16, 2018 at 9:11 AM, Viktor Dukhovni
> wrote:
> > A major obstacle to making access control decisions during the TLS
> > handshake is that at that time the server often does not yet have enough
> > information to determine
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
> 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
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
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
On Mon, 16 Apr 2018, Viktor Dukhovni wrote:
* We might want to say that if the TTL is zero then the clients MUST NOT
pin and must clear any pin. And we might do this in spite of not
describing any pinning semantics -- explicitly leaving pinning
semantics to a future document.
Exactly. I'd
> On Apr 16, 2018, at 4:21 PM, Paul Wouters wrote:
>
> This seems dangerous. If an attacker can re-route and get a rogue
> cert, they can set TTL to 0, negating a previously set TTL, without
> requiring proof by presenting the denial-of-existence of the TLSA
> record. That is also a downgrade a
On Mon, Apr 16, 2018 at 04:21:27PM -0400, Paul Wouters wrote:
> On Mon, 16 Apr 2018, Viktor Dukhovni wrote:
> >>* We might want to say that if the TTL is zero then the clients MUST NOT
> >> pin and must clear any pin. And we might do this in spite of not
> >> describing any pinning semantics -- ex
22 matches
Mail list logo
