Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

[Nico Williams]

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 -- explicitly leaving pinning
> >> semantics to a future document.
> >
> >Exactly.  I'd like to suggest that this is the most reasonable
> >common ground, and would urge the WG and authors to get behind
> >this as a consensus position.
> 
> 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 attack.

The extension would have to be present and contain either the TLSA RRs
and chain, OR the denial of existence chain, in order to even to carry
any TTL value.

Only in the denial of existence case could an impersonator set a TTL
value of the impersonator's choice, and in this case the client must
treat it as zero in order to avoid a DoS.  In the other case, the
impersonator could *not* set a TTL of their choice without compromising
DNSSEC.

> How to go from TTL != 0 to TTL == 0 should be specified carefully,
> either in this document or its own document.

If the server sends a denial of existence, then the TTL can't be fully
trusted, and there is a DoS if the client uses non-zero TTL values.  If
the server sends TLSA RRs and chain then all TTL values can be trusted
and should be used, though we might specify how in a later document.

> The only known save way of going to TTL == 0 is by presenting DoE of
> TLSA records (but it does bind using the TLS extension to the existence
> of TLSA records)

The TTL will be coerced zero on DoE, but it can be set to zero in the
TLSA case as well.

Nico
-- 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

[Viktor Dukhovni]

> 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 attack.
> 
> How to go from TTL != 0 to TTL == 0 should be specified carefully,
> either in this document or its own document.

I did not spell out all the details, which would belong in the
later pinning specification (some of this was described upthread).
Once a non-zero pin is in place, a pin TTL of 0 would require a
denial of existence proof or a handshake authenticated with extant
TLSA RRs.

> The only known save way of going to TTL == 0 is by presenting DoE of
> TLSA records (but it does bind using the TLS extension to the existence
> of TLSA records)

While some previous TTL has not expired, getting to zero requires either
DoE or TLSA-authenticated handshake with TTL == 0.

But, if we're compromising on (C'), then this discussion becomes out of
scope for the present draft, and will be one of the key design elements
of the future downgrade protection ("pinning") draft.

-- 
Viktor.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

[Paul Wouters]

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 like to suggest that this is the most reasonable
common ground, and would urge the WG and authors to get behind
this as a consensus position.


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 attack.

How to go from TTL != 0 to TTL == 0 should be specified carefully,
either in this document or its own document.

The only known save way of going to TTL == 0 is by presenting DoE of
TLSA records (but it does bind using the TLS extension to the existence
of TLSA records)

Paul

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Fwd: New Version Notification for draft-barnes-tls-pake-00.txt

[Richard Barnes]

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'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 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-authenticated
>> protocol?
>>
>> --Richard
>>
>>
>>
>>> I'm assuming here that the salt is public, because salts in general do
>>> not have confidentiality guarantees (otherwise they stretch the metaphor
>>> and become pepper).
>>> (I also assume that the client identity can be derived from observing a
>>> previous session, and that the server identity can be identified through
>>> probing.)
>>>
>>> Regards,
>>>
>>> Jonathan
>>>
>>>
>>>
>>> On Mon, 16 Apr 2018 at 19:43 Richard Barnes  wrote:
>>>
 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/
 a9f097c3bfe43cf50001e1a340c7e2e693850d4b
 https://github.com/bifurcation/mint/pull/193

 With regard to security properties: I don't think it's correct that an
 active attacker can do online password guessing.  Everything that is
 revealed on the wire is blinded with fresh, per-connection entropy, and
 thus doesn't reveal anything about the password.

 --Richard


 On Mon, Apr 16, 2018 at 7:52 AM, Jonathan Hoyland <
 jonathan.hoyl...@gmail.com> wrote:

> 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 order "p*h", with "p" a large prime
>
> and
>
> > o  A password "p"
>
>
> The variable "p" has two different meanings, which is a bit confusing,
> especially later on.
>
>  * The document doesn't explicitly state that X and Y need to be
> non-zero.
> The requirement is in "I-D.irtf-cfrg-spake2", but it would be nice if
> the warning was carried through.
>
> * In terms of security properties, iiuc an active adversary can do
> online password guessing attacks, but a passive adversary cannot derive 
> the
> password from observing the messages. If that is the case perhaps a 
> warning
> about rate-limiting connection attempts is appropriate.
>
> Regards,
>
> Jonathan
>
> On Mon, 16 Apr 2018 at 10:50 Tony Putman 
> wrote:
>
>> 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 rest of your comments I agree with (though they are not all
>> addressed in the updated draft).
>>
>> Tony
>>
>> > From: Richard Barnes [mailto:r...@ipv.sx]
>> > Sent: 13 April 2018 19:50
>> >
>> > 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.org/html/draft-barnes-tls-pake-01
>> >
>> > Some responses inline below.
>>
>> Dyson Technology Limited, company number 01959090, Tetbury Hill,
>> Malmesbury, SN16 0RP, UK.
>> This message is intended solely for the addressee and may contain
>> confidential information. If you have received this message in error,
>> please immediately and permanently delete it, and do not use, copy or
>> disclose the information contained in this message or in any attachment.
>> Dyson may monitor email traffic data and content for security &
>> training.
>> ___

Re: [TLS] Fwd: New Version Notification for draft-barnes-tls-pake-00.txt

[Jonathan Hoyland]

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 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-authenticated
> protocol?
>
> --Richard
>
>
>
>> I'm assuming here that the salt is public, because salts in general do
>> not have confidentiality guarantees (otherwise they stretch the metaphor
>> and become pepper).
>> (I also assume that the client identity can be derived from observing a
>> previous session, and that the server identity can be identified through
>> probing.)
>>
>> Regards,
>>
>> Jonathan
>>
>>
>>
>> On Mon, 16 Apr 2018 at 19:43 Richard Barnes  wrote:
>>
>>> 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/a9f097c3bfe43cf50001e1a340c7e2e693850d4b
>>> https://github.com/bifurcation/mint/pull/193
>>>
>>> With regard to security properties: I don't think it's correct that an
>>> active attacker can do online password guessing.  Everything that is
>>> revealed on the wire is blinded with fresh, per-connection entropy, and
>>> thus doesn't reveal anything about the password.
>>>
>>> --Richard
>>>
>>>
>>> On Mon, Apr 16, 2018 at 7:52 AM, Jonathan Hoyland <
>>> jonathan.hoyl...@gmail.com> wrote:
>>>
 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 order "p*h", with "p" a large prime

 and

 > o  A password "p"


 The variable "p" has two different meanings, which is a bit confusing,
 especially later on.

  * The document doesn't explicitly state that X and Y need to be
 non-zero.
 The requirement is in "I-D.irtf-cfrg-spake2", but it would be nice if
 the warning was carried through.

 * In terms of security properties, iiuc an active adversary can do
 online password guessing attacks, but a passive adversary cannot derive the
 password from observing the messages. If that is the case perhaps a warning
 about rate-limiting connection attempts is appropriate.

 Regards,

 Jonathan

 On Mon, 16 Apr 2018 at 10:50 Tony Putman  wrote:

> 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 rest of your comments I agree with (though they are not all
> addressed in the updated draft).
>
> Tony
>
> > From: Richard Barnes [mailto:r...@ipv.sx]
> > Sent: 13 April 2018 19:50
> >
> > 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.org/html/draft-barnes-tls-pake-01
> >
> > Some responses inline below.
>
> Dyson Technology Limited, company number 01959090, Tetbury Hill,
> Malmesbury, SN16 0RP, UK.
> This message is intended solely for the addressee and may contain
> confidential information. If you have received this message in error,
> please immediately and permanently delete it, and do not use, copy or
> disclose the information contained in this message or in any attachment.
> Dyson may monitor email traffic data and content for security &
> training.
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

>>>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Fwd: New Version Notification for draft-barnes-tls-pake-00.txt

[Richard Barnes]

> 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-authenticated
protocol?

--Richard



> I'm assuming here that the salt is public, because salts in general do not
> have confidentiality guarantees (otherwise they stretch the metaphor and
> become pepper).
> (I also assume that the client identity can be derived from observing a
> previous session, and that the server identity can be identified through
> probing.)
>
> Regards,
>
> Jonathan
>
>
>
> On Mon, 16 Apr 2018 at 19:43 Richard Barnes  wrote:
>
>> 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/
>> a9f097c3bfe43cf50001e1a340c7e2e693850d4b
>> https://github.com/bifurcation/mint/pull/193
>>
>> With regard to security properties: I don't think it's correct that an
>> active attacker can do online password guessing.  Everything that is
>> revealed on the wire is blinded with fresh, per-connection entropy, and
>> thus doesn't reveal anything about the password.
>>
>> --Richard
>>
>>
>> On Mon, Apr 16, 2018 at 7:52 AM, Jonathan Hoyland <
>> jonathan.hoyl...@gmail.com> wrote:
>>
>>> 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 order "p*h", with "p" a large prime
>>>
>>> and
>>>
>>> > o  A password "p"
>>>
>>>
>>> The variable "p" has two different meanings, which is a bit confusing,
>>> especially later on.
>>>
>>>  * The document doesn't explicitly state that X and Y need to be
>>> non-zero.
>>> The requirement is in "I-D.irtf-cfrg-spake2", but it would be nice if
>>> the warning was carried through.
>>>
>>> * In terms of security properties, iiuc an active adversary can do
>>> online password guessing attacks, but a passive adversary cannot derive the
>>> password from observing the messages. If that is the case perhaps a warning
>>> about rate-limiting connection attempts is appropriate.
>>>
>>> Regards,
>>>
>>> Jonathan
>>>
>>> On Mon, 16 Apr 2018 at 10:50 Tony Putman  wrote:
>>>
 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 rest of your comments I agree with (though they are not all
 addressed in the updated draft).

 Tony

 > From: Richard Barnes [mailto:r...@ipv.sx]
 > Sent: 13 April 2018 19:50
 >
 > 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.org/html/draft-barnes-tls-pake-01
 >
 > Some responses inline below.

 Dyson Technology Limited, company number 01959090, Tetbury Hill,
 Malmesbury, SN16 0RP, UK.
 This message is intended solely for the addressee and may contain
 confidential information. If you have received this message in error,
 please immediately and permanently delete it, and do not use, copy or
 disclose the information contained in this message or in any attachment.
 Dyson may monitor email traffic data and content for security &
 training.
 ___
 TLS mailing list
 TLS@ietf.org
 https://www.ietf.org/mailman/listinfo/tls

>>>
>>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Fwd: New Version Notification for draft-barnes-tls-pake-00.txt

[Jonathan Hoyland]

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 salts in general do not
have confidentiality guarantees (otherwise they stretch the metaphor and
become pepper).
(I also assume that the client identity can be derived from observing a
previous session, and that the server identity can be identified through
probing.)

Regards,

Jonathan



On Mon, 16 Apr 2018 at 19:43 Richard Barnes  wrote:

> 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/a9f097c3bfe43cf50001e1a340c7e2e693850d4b
> https://github.com/bifurcation/mint/pull/193
>
> With regard to security properties: I don't think it's correct that an
> active attacker can do online password guessing.  Everything that is
> revealed on the wire is blinded with fresh, per-connection entropy, and
> thus doesn't reveal anything about the password.
>
> --Richard
>
>
> On Mon, Apr 16, 2018 at 7:52 AM, Jonathan Hoyland <
> jonathan.hoyl...@gmail.com> wrote:
>
>> 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 order "p*h", with "p" a large prime
>>
>> and
>>
>> > o  A password "p"
>>
>>
>> The variable "p" has two different meanings, which is a bit confusing,
>> especially later on.
>>
>>  * The document doesn't explicitly state that X and Y need to be
>> non-zero.
>> The requirement is in "I-D.irtf-cfrg-spake2", but it would be nice if the
>> warning was carried through.
>>
>> * In terms of security properties, iiuc an active adversary can do online
>> password guessing attacks, but a passive adversary cannot derive the
>> password from observing the messages. If that is the case perhaps a warning
>> about rate-limiting connection attempts is appropriate.
>>
>> Regards,
>>
>> Jonathan
>>
>> On Mon, 16 Apr 2018 at 10:50 Tony Putman  wrote:
>>
>>> 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 rest of your comments I agree with (though they are not all
>>> addressed in the updated draft).
>>>
>>> Tony
>>>
>>> > From: Richard Barnes [mailto:r...@ipv.sx]
>>> > Sent: 13 April 2018 19:50
>>> >
>>> > 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.org/html/draft-barnes-tls-pake-01
>>> >
>>> > Some responses inline below.
>>>
>>> Dyson Technology Limited, company number 01959090, Tetbury Hill,
>>> Malmesbury, SN16 0RP, UK.
>>> This message is intended solely for the addressee and may contain
>>> confidential information. If you have received this message in error,
>>> please immediately and permanently delete it, and do not use, copy or
>>> disclose the information contained in this message or in any attachment.
>>> Dyson may monitor email traffic data and content for security & training.
>>> ___
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] question about verification of client side certificate for TLS session for mutual authentication

[Nico Williams]

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 which specific resource the client will ask to
> > access.
> 
> There's also the problem that (at least in an SOA/"microservice
> architecture") people will inevitably want some resources to be accessible
> without a client certificate, e.g. status endpoints or anything consumed by
> clients which do not support TLS certificates. In these cases it really
> helps to force things up a level out of the TLS handshake into something at
> the application level like an ACL language that lets you whitelist
> unauthenticated access to these resources.

Indeed, one might even say that user authentication should be driven by
application needs.  This is done in HTTP, for example, via 401
responses, which can trigger HTTP authentication.  Granted, HTTP
authentication methods are fairly limited.

If a client is authenticated at the TLS layer, authorization should
still happen at the application layer as much as possible, as otherwise
access control is very coarse-grained.

Nico
-- 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Fwd: New Version Notification for draft-barnes-tls-pake-00.txt

[Richard Barnes]

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/a9f097c3bfe43cf50001e1a340c7e2e693850d4b
https://github.com/bifurcation/mint/pull/193

With regard to security properties: I don't think it's correct that an
active attacker can do online password guessing.  Everything that is
revealed on the wire is blinded with fresh, per-connection entropy, and
thus doesn't reveal anything about the password.

--Richard


On Mon, Apr 16, 2018 at 7:52 AM, Jonathan Hoyland <
jonathan.hoyl...@gmail.com> wrote:

> 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 order "p*h", with "p" a large prime
>
> and
>
> > o  A password "p"
>
>
> The variable "p" has two different meanings, which is a bit confusing,
> especially later on.
>
>  * The document doesn't explicitly state that X and Y need to be non-zero.
>
> The requirement is in "I-D.irtf-cfrg-spake2", but it would be nice if the
> warning was carried through.
>
> * In terms of security properties, iiuc an active adversary can do online
> password guessing attacks, but a passive adversary cannot derive the
> password from observing the messages. If that is the case perhaps a warning
> about rate-limiting connection attempts is appropriate.
>
> Regards,
>
> Jonathan
>
> On Mon, 16 Apr 2018 at 10:50 Tony Putman  wrote:
>
>> 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 rest of your comments I agree with (though they are not all addressed
>> in the updated draft).
>>
>> Tony
>>
>> > From: Richard Barnes [mailto:r...@ipv.sx]
>> > Sent: 13 April 2018 19:50
>> >
>> > 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.org/html/draft-barnes-tls-pake-01
>> >
>> > Some responses inline below.
>>
>> Dyson Technology Limited, company number 01959090, Tetbury Hill,
>> Malmesbury, SN16 0RP, UK.
>> This message is intended solely for the addressee and may contain
>> confidential information. If you have received this message in error,
>> please immediately and permanently delete it, and do not use, copy or
>> disclose the information contained in this message or in any attachment.
>> Dyson may monitor email traffic data and content for security & training.
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] question about verification of client side certificate for TLS session for mutual authentication

[Tony Arcieri]

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 also the problem that (at least in an SOA/"microservice
architecture") people will inevitably want some resources to be accessible
without a client certificate, e.g. status endpoints or anything consumed by
clients which do not support TLS certificates. In these cases it really
helps to force things up a level out of the TLS handshake into something at
the application level like an ACL language that lets you whitelist
unauthenticated access to these resources.

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

[Bill Frantz]

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 document.  In such a (C') we'd elide all pinning (or most*)
in this document.


I have always worried about the trust model in PKIX, and thought 
that some form of pinning would an excellent enhancement -- 
modeling how individuals work in the real world:


  Alice, I'd like you to meet Bob. He is an expert in... (Alice 
learns Bob's voice pattern.)


  Bob, this is Alice, I'd like you to... (Alice recognizes 
Bob's voice in the reply.)


I strongly support C or C' as the best way forward, allowing a 
future RFC to address the pinning details. Viktor has some good 
suggestions as well.


Note: I have not been involved in any face-to-face meetings or hums.

Cheers - Bill

-
Bill Frantz| When it comes to the world | Periwinkle
(408)356-8506  | around us, is there any choice | 16345 
Englewood Ave
www.pwpconsult.com | but to explore? - Lisa Randall | Los Gatos, 
CA 95032


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

[Viktor Dukhovni]

> 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.  In such a (C') we'd elide all pinning (or most*)
> in this document.

Specifically, this actually would help the cause of those who don't
want pinning, because in (C') we can specify:

  * Client's MUST NOT employ any pinning for downgrade protection
when the extension support TTL sent by the server is ZERO.
Only a-priori local policy that mandates DANE TLSA records
for particular domains can require the extension, in all other
cases the extension MUST be optional in future connections
when an authenticated server returns a ZERO extension TTL.

  * Pending future specifications, the server MUST set the extension
support TTL to ZERO.

With this, we get to explicitly specify that clients MUST NOT pin,
rather than removing text and leaving the option up to the implementors
imagination.  And implementors will want downgrade protection, and the
current list of half-baked downgrade protection measures in Section 8
was in place at the time of the WG LC consensus for moving the draft
forward, and these were added in lieu of tackling downgrades in a more
systematic way, so ripping it all out does not seem like a minor tweak.

If we add a two byte extension support TTL field, that servers will
set to ZERO, and tell clients to not attempt downgrade protection
when it is so set, we leave room for future downgrade protection
without having to change the extension wire format.

With the TTL always returned as ZERO in the recent past, the server
is equally free to return denial of existence or just not present the
extension.  Operator's choice.

This way, the draft retains the option of future downgrade protection,
thus not completely abandoning its promised scope, while deferring any
pinning for now, and indeed making it very clear to clients that they
MUST NOT (yet) do any TOFU or similar pinning.

> * 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 like to suggest that this is the most reasonable
common ground, and would urge the WG and authors to get behind
this as a consensus position.

-- 
Viktor.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

[Nico Williams]

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 incidental to the performance improvement. That would argue
> in favor of publishing the draft as-is. However:

It's not just a performance improvement.  It's also a last-mile
technology: for clients that cannot perform DNS lookups due to being in,
e.g., hotel networks.  And it adds security.

Using DANE adds security, that's for sure, since one can then rely on
both, PKIX *and* DNSSEC, which can only add security.  Or, if one does
not trust the WebPKI, then only DNSSEC.  I have no opinion as to which
of WebPKI alone, WebPKI + DNSSEC, or DNSSEC alone, is best, but I have
an opinion as to who ought to decide that: the server operator.  This
document gives the server operator that power, but it does not give the
server operator any power over client pinning behavior, which means that
operators will not turn this on for apps where it's not mandatory.

That is, without revision, this document really does not help security
as much as with a rather minor revision.  We should want that minor
revision because the (at-this-time-intangible) gain is potentially
large, while the (at-this-time-intangible) cost/risk of not making that
revision is equally large.

> From the discussion I have read, there seems to be disagreement about
> what even the semantics of this pinning would be. And if it's unclear to

Among proponents there are no disagreements over pinning semantics.
Pinning would be only to the use of the _extension_, not to the use of
DANE, nor to any particular DANE usage.  That is, if the server does not
have TLSA RRs, it could still use this extension [to satisfy a client
pin] to send the denial of existence proof, and the client's pin would
be satisfied.

> the WG participants, it's going to be even less clear to others that are
> implementing this. I am also of the opinion that pinning is somewhat

How would that follow?  Shouldn't we see proposed text before we can
tell if it would be unclear to implementors?

> subtle; it requires a detailed understanding of the mechanism to remove
> (expire) the pin, and if done wrong can result in availability problems.

Exactly!

(A) gives us a modicum of pin-clearing capability: if you get a denial
of existence then you could clear the pin on the client.

However, (A) + (B) (i.e., (C)) would give us the ability to separate the
pin set/clear from the DNSSEC payload of the extension.  *This* would
give server operators all the control they need to feel safe enabling
pinning behavior.

It is much simpler to change a TTL in a server configuration than to
make changes in the relevant DNS zone(s).  Thus (C) or some (C') (see
below) would be much better than (A).

> In addition, the pins here would be maintained in individual browsers.

And other user-agents for other application protocols (e.g., MUAs).

> There is less benefit from pinning because unlike some other pinning
> mechanisms, there isn't any leverage of the TOFU experience had by others.

TOFU works reasonably well.  It's risky for an attacker to mount an
active attack that will be detected if the client has a pin -- this risk
acts as deterrent.

> This requires further thought, and I do not support adding pinning to
> this draft. Perhaps as a separate draft, but the WG needs to decide on that.

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.  In such a (C') we'd elide all pinning (or most*)
in this document.

* 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.

Nico
-- 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] question about verification of client side certificate for TLS session for mutual authentication

[Viktor Dukhovni]

> 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 already during phase of establishing 
> the TLS connection)

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.

If the access control is very coarse, and the client is simply not allowed any 
of the features of the application, then one might terminate the handshake 
"early", but by the time server has processed the client certificate it has 
done pretty much all the heavy lifting (signing its own key exchange messages, 
...) so allowing the handshake to complete and dealing with access control at 
the application layer is far more typical, and makes possible more meaningful 
(to the client application) "Permission denied" error responses, which would be 
far less likely to be understood if communicated via a handshake failure.

-- 
Viktor.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] question about verification of client side certificate for TLS session for mutual authentication

[Tobias Gondrom]

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. 

 

Thanks a lot!

 

Tobias

 

 

From: Kathleen Moriarty  
Sent: Monday, April 16, 2018 9:20 PM
To: Eric Rescorla 
Cc: Tobias Gondrom ;  
Subject: Re: [TLS] question about verification of client side certificate for 
TLS session for mutual authentication

 

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 Apr 16, 2018, at 4:55 AM, Eric Rescorla mailto:e...@rtfm.com> > wrote:

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 mailto:tobias.gond...@gondrom.org> > wrote:

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 
and verification of client id by username & password or by a simple 
verification of client certificate. 

 

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 TLS connection. 

 

For example in this scenario: 

A client with a valid certificate may be allowed to connect to application 1, 
but would not be allowed to connect to application 2. (for sake of separation 
application 1 and 2 are on separate servers (application 1 on server 1 and 
application 2 on server 2).) 

 

>From my current understanding, I would establish the TLS connection in both 
>cases, do mutual authentication and then let application 2 reject access based 
>on that the user is not allowed to access it. There is a question whether this 
>would expose to a risk that server resources could be exhausted by allowing to 
>establish the TLS connection before failing, but this does not seem too bad to 
>me. But maybe I am missing something…

 

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 already during phase of establishing the 
TLS connection)

 

Thank you and sorry for bothering, Tobias

 


___
TLS mailing list
TLS@ietf.org  
https://www.ietf.org/mailman/listinfo/tls

 

___
TLS mailing list
TLS@ietf.org  
https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

[Nico Williams]

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 it regardless), and not having extension then
> > will cause failure.
> >
> > Now, clients that don't do opportunistic pinning would have to... notice
> > the lack of TLSA RRs, but not necessarily bother validating the denial
> > of existence chain.  There's not even a need to say that the client
> > SHOULD (let alone MUST) validate the denial of existence chain.  It
> > suffices that the server SHOULD send it.
> 
> Sure seems like it would be simpler to say "Client MUST NOT cache TLSA
> state".  Yes, that cuts off some use cases.  But it avoids all the

That's not the right way to say "no pinning".

> transition pain that EKR has pointed out.

The I-D needs *some* updates.  You and I disagree about which updates,
but it needs updates.  It cannot be published as-is.  Even removing any
kind of pinning requires WG consensus at this point.

And we've already seem that at least one author support (A), and we
could probably easily get support for a (C') where we get the two bytes
we're asking for as well but with as much semantics as possible left for
a follow-on I-D.

Nico
-- 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] question about verification of client side certificate for TLS session for mutual authentication

[Tony Arcieri]

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 TLS connection.
>

I'm not sure what you mean by "before establishing a TLS connection", as
certificates are generally exchanged during the TLS handshake, so doing
anything "before establishing a TLS connection" would require the server
somehow know the client's certificate a priori. There are several systems
that will abort the handshake unless they receive an acceptable client
certificate, however.

I don't know of any RFCs for this per se, or anything that uses the Subject
CN (I think almost everything has completely moved away from using the CN).
However, as an example, SPIFFE is a largely Kubernetes-focused identity
system which encodes a "SPIFFE ID" in the client cert's subjectAltName and
uses that to determine whether clients are authorized to continue a TLS
connection:

https://github.com/spiffe/spiffe/blob/master/standards/X509-SVID.md

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] question about verification of client side certificate for TLS session for mutual authentication

[Kathleen Moriarty]

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 Apr 16, 2018, at 4:55 AM, Eric Rescorla  wrote:
> 
> 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 mutual authentication 
>> and have a question regarding verification of client certificate.
>> 
>>  
>> 
>> In many web scenarios the simple use is server authentication by certificate 
>> and verification of client id by username & password or by a simple 
>> verification of client certificate.
>> 
>>  
>> 
>> 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 TLS connection.
>> 
>>  
>> 
>> For example in this scenario:
>> 
>> A client with a valid certificate may be allowed to connect to application 
>> 1, but would not be allowed to connect to application 2. (for sake of 
>> separation application 1 and 2 are on separate servers (application 1 on 
>> server 1 and application 2 on server 2).)
>> 
>>  
>> 
>> From my current understanding, I would establish the TLS connection in both 
>> cases, do mutual authentication and then let application 2 reject access 
>> based on that the user is not allowed to access it. There is a question 
>> whether this would expose to a risk that server resources could be exhausted 
>> by allowing to establish the TLS connection before failing, but this does 
>> not seem too bad to me. But maybe I am missing something…
>> 
>>  
>> 
>> 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 already during phase of establishing 
>> the TLS connection)
>> 
>>  
>> 
>> Thank you and sorry for bothering, Tobias
>> 
>>  
>> 
>> 
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>> 
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] question about verification of client side certificate for TLS session for mutual authentication

[Eric Rescorla]

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 mutual
> authentication and have a question regarding verification of client
> certificate.
>
>
>
> In many web scenarios the simple use is server authentication by
> certificate and verification of client id by username & password or by a
> simple verification of client certificate.
>
>
>
> 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 TLS connection.
>
>
>
> For example in this scenario:
>
> A client with a valid certificate may be allowed to connect to application
> 1, but would not be allowed to connect to application 2. (for sake of
> separation application 1 and 2 are on separate servers (application 1 on
> server 1 and application 2 on server 2).)
>
>
>
> From my current understanding, I would establish the TLS connection in
> both cases, do mutual authentication and then let application 2 reject
> access based on that the user is not allowed to access it. There is a
> question whether this would expose to a risk that server resources could be
> exhausted by allowing to establish the TLS connection before failing, but
> this does not seem too bad to me. But maybe I am missing something…
>
>
>
> *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 already during phase of establishing
> the TLS connection)*
>
>
>
> Thank you and sorry for bothering, Tobias
>
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Fwd: New Version Notification for draft-barnes-tls-pake-00.txt

[Jonathan Hoyland]

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 order "p*h", with "p" a large prime

and

> o  A password "p"


The variable "p" has two different meanings, which is a bit confusing,
especially later on.

 * The document doesn't explicitly state that X and Y need to be non-zero.
The requirement is in "I-D.irtf-cfrg-spake2", but it would be nice if the
warning was carried through.

* In terms of security properties, iiuc an active adversary can do online
password guessing attacks, but a passive adversary cannot derive the
password from observing the messages. If that is the case perhaps a warning
about rate-limiting connection attempts is appropriate.

Regards,

Jonathan

On Mon, 16 Apr 2018 at 10:50 Tony Putman  wrote:

> 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 rest of your comments I agree with (though they are not all addressed
> in the updated draft).
>
> Tony
>
> > From: Richard Barnes [mailto:r...@ipv.sx]
> > Sent: 13 April 2018 19:50
> >
> > 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.org/html/draft-barnes-tls-pake-01
> >
> > Some responses inline below.
>
> Dyson Technology Limited, company number 01959090, Tetbury Hill,
> Malmesbury, SN16 0RP, UK.
> This message is intended solely for the addressee and may contain
> confidential information. If you have received this message in error,
> please immediately and permanently delete it, and do not use, copy or
> disclose the information contained in this message or in any attachment.
> Dyson may monitor email traffic data and content for security & training.
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] question about verification of client side certificate for TLS session for mutual authentication

[Tobias Gondrom]

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
and verification of client id by username & password or by a simple
verification of client certificate. 

 

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 TLS connection. 

 

For example in this scenario: 

A client with a valid certificate may be allowed to connect to application
1, but would not be allowed to connect to application 2. (for sake of
separation application 1 and 2 are on separate servers (application 1 on
server 1 and application 2 on server 2).) 

 

>From my current understanding, I would establish the TLS connection in both
cases, do mutual authentication and then let application 2 reject access
based on that the user is not allowed to access it. There is a question
whether this would expose to a risk that server resources could be exhausted
by allowing to establish the TLS connection before failing, but this does
not seem too bad to me. But maybe I am missing something.

 

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 already during phase of establishing
the TLS connection)

 

Thank you and sorry for bothering, Tobias

 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Fwd: New Version Notification for draft-barnes-tls-pake-00.txt

[Tony Putman]

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 rest of your comments I agree with (though they are not all addressed in 
the updated draft). 

Tony

> From: Richard Barnes [mailto:r...@ipv.sx] 
> Sent: 13 April 2018 19:50
>
> 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.org/html/draft-barnes-tls-pake-01
>
> Some responses inline below.

Dyson Technology Limited, company number 01959090, Tetbury Hill, Malmesbury, 
SN16 0RP, UK.
This message is intended solely for the addressee and may contain confidential 
information. If you have received this message in error, please immediately and 
permanently delete it, and do not use, copy or disclose the information 
contained in this message or in any attachment.
Dyson may monitor email traffic data and content for security & training.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls