Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable to externally set PSK identity enumeration

[Hubert Kario]

On Tuesday, 20 March 2018 22:21:06 CET Eric Rescorla wrote:
> On Tue, Mar 20, 2018 at 7:42 PM, Hubert Kario  wrote:
> > On Monday, 19 March 2018 14:38:05 CET Eric Rescorla wrote:
> > > On Mon, Mar 19, 2018 at 1:33 PM, Nikos Mavrogiannopoulos <
> > 
> > n...@redhat.com>
> > 
> > > wrote:
> > > > On Fri, 2018-03-16 at 14:45 -0500, Benjamin Kaduk wrote:
> > > > > On Fri, Mar 16, 2018 at 09:11:32AM -0400, Christian Huitema wrote:
> > > > > > On 3/15/2018 5:51 PM, Benjamin Kaduk wrote:
> > > > > > > On Thu, Mar 15, 2018 at 12:25:38PM +0100, Hubert Kario wrote:
> > > > > > > ...
> > > > > > > 
> > > > > > > > we do not have a reliable mechanism of differentiating between
> > > > > > > > external and
> > > > > > > > resumption PSKs while parsing Client Hello
> > > > > > > 
> > > > > > > Well, a valid external PSK (identity) the server will of course
> > > > > > > recognize, and we have a SHOULD-level requirement that the
> > > > > > > obfuscated_ticket_age is zero for external PSKs.  I haven't
> > > > > > > gotten
> > > > > > > to think through whether there is still potential for
> > > > > > > information
> > > > > > > leakage about external PSK identities, but it seems like there
> > > > > > > would
> > > > > > > not be, provided that the server prefers resumption to external-
> > > > > > > PSK
> > > > > > > full handshakes.
> > > > > > 
> > > > > > I am concerned with the privacy issues linked to these "external
> > > > > > PSK
> > > > > > identities". If a system is set so that clients use static PSK
> > > > > > identities, then the identity is an identifier and the client's
> > > > > > movements and connections can be tracked. I don't think privacy is
> > > > > > improved if we make it easy to differentiate external identities
> > > > > > from
> > > > > > resumption tickets.
> > > > > 
> > > > > Oh, of course, the privacy considerations of the current external
> > > > > PSK scheme are terrible!  This follows naturally from external PSKs
> > > > > having not really been a first-class citizen while we were designing
> > > > > things; we stuffed resumption PSKs together with external PSKs for
> > > > > the convenience of having them use the same binder construct and
> > > > > only needing to have one extension at the end of the ClientHello.
> > > > > Resumption flows get single-use tickets for privacy preservation,
> > > > > and external PSKs get infinite use and a gigantic correlation
> > > > > channel.
> > > > 
> > > > I agree.
> > > > 
> > > > > > If you want to use PSK with some level of privacy, you might adopt
> > > > > > a
> > > > > > different setup. For example, servers could provision the clients
> > > > > > with a
> > > > > > set of single-use external PSK identities. But then, that looks a
> > > > > > lot
> > > > > > like resumption. Or, clients could generate single-use external
> > > > > > PSK
> > > > > > identities by encrypting their long term identity and a nonce with
> > > > > > the
> > > > > > public key of the server, a design which of course has its own set
> > > > > > of
> > > > > > issues.
> > > > > 
> > > > > But, as you note, this is something of an open problem for how to do
> > > > > well, and this document is already approved by the IESG.  (It's also
> > > > > not entirely clear that the TLS WG would be the best place to design
> > > > > this sort of scheme, though of course it could choose to do so.)
> > > > > 
> > > > > So to me the open question is whether we consider enumeration of
> > > > > external PSK identifiers to be something we can address reasonably
> > > > > at this stage of the document's lifecycle at all.  (I also note that
> > > > > the presence of a CVE number for a similar issue does not
> > > > > necessarily mean anything -- CVE assignments can occur for
> > > > > situations with no actual security impact and/or against the wishes
> > > > > of the software authors.)  I don't think anyone has proposed a
> > > > > minimal change that would close the enumeration channel, and given
> > > > > that external PSKs already have bad privacy properties, it seems
> > > > > like we may just have to accept this state of affairs for this
> > > > > document.
> > > > 
> > > > That's a good general remark, but not really the case for the
> > > > vulnerabilities that Hubert pointed out.
> > > > 
> > > > > Hubert also says:
> > > > > 
> > > > > % so there's no reliable way to say that, yes, this identity is or
> > > > > is
> > > > > not a
> > > > > % resumption ticket, if I can't decrypt it
> > > > > 
> > > > > Mostly.  External PSKs are established out of band, and that
> > > > > provisioning process *could* include knowledge that the
> > > > > obfuscated_ticket_age would always be zero when those PSKs are in
> > > > > use, and that would be reliable for those specific parties.
> > > > 
> > > > I believe that this can happen in an interoperable way if the protocol
> > > > mandates it (which is not the case now). These specific parties may
> > > > use
> > > > 

Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable to externally set PSK identity enumeration

[Kathleen Moriarty]

The document has been approved for publication and the outstanding
reference will be added in the RFC editor process during Auth48.

Thank you all for your work on this protocol.

Best regards,
Kathleen

On Tue, Mar 20, 2018 at 5:21 PM, Eric Rescorla  wrote:
>
>
> On Tue, Mar 20, 2018 at 7:42 PM, Hubert Kario  wrote:
>>
>> On Monday, 19 March 2018 14:38:05 CET Eric Rescorla wrote:
>> > On Mon, Mar 19, 2018 at 1:33 PM, Nikos Mavrogiannopoulos
>> > 
>> >
>> > wrote:
>> > > On Fri, 2018-03-16 at 14:45 -0500, Benjamin Kaduk wrote:
>> > > > On Fri, Mar 16, 2018 at 09:11:32AM -0400, Christian Huitema wrote:
>> > > > > On 3/15/2018 5:51 PM, Benjamin Kaduk wrote:
>> > > > > > On Thu, Mar 15, 2018 at 12:25:38PM +0100, Hubert Kario wrote:
>> > > > > > ...
>> > > > > >
>> > > > > > > we do not have a reliable mechanism of differentiating between
>> > > > > > > external and
>> > > > > > > resumption PSKs while parsing Client Hello
>> > > > > >
>> > > > > > Well, a valid external PSK (identity) the server will of course
>> > > > > > recognize, and we have a SHOULD-level requirement that the
>> > > > > > obfuscated_ticket_age is zero for external PSKs.  I haven't
>> > > > > > gotten
>> > > > > > to think through whether there is still potential for
>> > > > > > information
>> > > > > > leakage about external PSK identities, but it seems like there
>> > > > > > would
>> > > > > > not be, provided that the server prefers resumption to external-
>> > > > > > PSK
>> > > > > > full handshakes.
>> > > > >
>> > > > > I am concerned with the privacy issues linked to these "external
>> > > > > PSK
>> > > > > identities". If a system is set so that clients use static PSK
>> > > > > identities, then the identity is an identifier and the client's
>> > > > > movements and connections can be tracked. I don't think privacy is
>> > > > > improved if we make it easy to differentiate external identities
>> > > > > from
>> > > > > resumption tickets.
>> > > >
>> > > > Oh, of course, the privacy considerations of the current external
>> > > > PSK scheme are terrible!  This follows naturally from external PSKs
>> > > > having not really been a first-class citizen while we were designing
>> > > > things; we stuffed resumption PSKs together with external PSKs for
>> > > > the convenience of having them use the same binder construct and
>> > > > only needing to have one extension at the end of the ClientHello.
>> > > > Resumption flows get single-use tickets for privacy preservation,
>> > > > and external PSKs get infinite use and a gigantic correlation
>> > > > channel.
>> > >
>> > > I agree.
>> > >
>> > > > > If you want to use PSK with some level of privacy, you might adopt
>> > > > > a
>> > > > > different setup. For example, servers could provision the clients
>> > > > > with a
>> > > > > set of single-use external PSK identities. But then, that looks a
>> > > > > lot
>> > > > > like resumption. Or, clients could generate single-use external
>> > > > > PSK
>> > > > > identities by encrypting their long term identity and a nonce with
>> > > > > the
>> > > > > public key of the server, a design which of course has its own set
>> > > > > of
>> > > > > issues.
>> > > >
>> > > > But, as you note, this is something of an open problem for how to do
>> > > > well, and this document is already approved by the IESG.  (It's also
>> > > > not entirely clear that the TLS WG would be the best place to design
>> > > > this sort of scheme, though of course it could choose to do so.)
>> > > >
>> > > > So to me the open question is whether we consider enumeration of
>> > > > external PSK identifiers to be something we can address reasonably
>> > > > at this stage of the document's lifecycle at all.  (I also note that
>> > > > the presence of a CVE number for a similar issue does not
>> > > > necessarily mean anything -- CVE assignments can occur for
>> > > > situations with no actual security impact and/or against the wishes
>> > > > of the software authors.)  I don't think anyone has proposed a
>> > > > minimal change that would close the enumeration channel, and given
>> > > > that external PSKs already have bad privacy properties, it seems
>> > > > like we may just have to accept this state of affairs for this
>> > > > document.
>> > >
>> > > That's a good general remark, but not really the case for the
>> > > vulnerabilities that Hubert pointed out.
>> > >
>> > > > Hubert also says:
>> > > >
>> > > > % so there's no reliable way to say that, yes, this identity is or
>> > > > is
>> > > > not a
>> > > > % resumption ticket, if I can't decrypt it
>> > > >
>> > > > Mostly.  External PSKs are established out of band, and that
>> > > > provisioning process *could* include knowledge that the
>> > > > obfuscated_ticket_age would always be zero when those PSKs are in
>> > > > use, and that would be reliable for those specific parties.
>> > >
>> > > I believe that this can happen in an interoperable way if the 

Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable to externally set PSK identity enumeration

[Eric Rescorla]

On Tue, Mar 20, 2018 at 7:42 PM, Hubert Kario  wrote:

> On Monday, 19 March 2018 14:38:05 CET Eric Rescorla wrote:
> > On Mon, Mar 19, 2018 at 1:33 PM, Nikos Mavrogiannopoulos <
> n...@redhat.com>
> >
> > wrote:
> > > On Fri, 2018-03-16 at 14:45 -0500, Benjamin Kaduk wrote:
> > > > On Fri, Mar 16, 2018 at 09:11:32AM -0400, Christian Huitema wrote:
> > > > > On 3/15/2018 5:51 PM, Benjamin Kaduk wrote:
> > > > > > On Thu, Mar 15, 2018 at 12:25:38PM +0100, Hubert Kario wrote:
> > > > > > ...
> > > > > >
> > > > > > > we do not have a reliable mechanism of differentiating between
> > > > > > > external and
> > > > > > > resumption PSKs while parsing Client Hello
> > > > > >
> > > > > > Well, a valid external PSK (identity) the server will of course
> > > > > > recognize, and we have a SHOULD-level requirement that the
> > > > > > obfuscated_ticket_age is zero for external PSKs.  I haven't
> > > > > > gotten
> > > > > > to think through whether there is still potential for information
> > > > > > leakage about external PSK identities, but it seems like there
> > > > > > would
> > > > > > not be, provided that the server prefers resumption to external-
> > > > > > PSK
> > > > > > full handshakes.
> > > > >
> > > > > I am concerned with the privacy issues linked to these "external
> > > > > PSK
> > > > > identities". If a system is set so that clients use static PSK
> > > > > identities, then the identity is an identifier and the client's
> > > > > movements and connections can be tracked. I don't think privacy is
> > > > > improved if we make it easy to differentiate external identities
> > > > > from
> > > > > resumption tickets.
> > > >
> > > > Oh, of course, the privacy considerations of the current external
> > > > PSK scheme are terrible!  This follows naturally from external PSKs
> > > > having not really been a first-class citizen while we were designing
> > > > things; we stuffed resumption PSKs together with external PSKs for
> > > > the convenience of having them use the same binder construct and
> > > > only needing to have one extension at the end of the ClientHello.
> > > > Resumption flows get single-use tickets for privacy preservation,
> > > > and external PSKs get infinite use and a gigantic correlation
> > > > channel.
> > >
> > > I agree.
> > >
> > > > > If you want to use PSK with some level of privacy, you might adopt
> > > > > a
> > > > > different setup. For example, servers could provision the clients
> > > > > with a
> > > > > set of single-use external PSK identities. But then, that looks a
> > > > > lot
> > > > > like resumption. Or, clients could generate single-use external PSK
> > > > > identities by encrypting their long term identity and a nonce with
> > > > > the
> > > > > public key of the server, a design which of course has its own set
> > > > > of
> > > > > issues.
> > > >
> > > > But, as you note, this is something of an open problem for how to do
> > > > well, and this document is already approved by the IESG.  (It's also
> > > > not entirely clear that the TLS WG would be the best place to design
> > > > this sort of scheme, though of course it could choose to do so.)
> > > >
> > > > So to me the open question is whether we consider enumeration of
> > > > external PSK identifiers to be something we can address reasonably
> > > > at this stage of the document's lifecycle at all.  (I also note that
> > > > the presence of a CVE number for a similar issue does not
> > > > necessarily mean anything -- CVE assignments can occur for
> > > > situations with no actual security impact and/or against the wishes
> > > > of the software authors.)  I don't think anyone has proposed a
> > > > minimal change that would close the enumeration channel, and given
> > > > that external PSKs already have bad privacy properties, it seems
> > > > like we may just have to accept this state of affairs for this
> > > > document.
> > >
> > > That's a good general remark, but not really the case for the
> > > vulnerabilities that Hubert pointed out.
> > >
> > > > Hubert also says:
> > > >
> > > > % so there's no reliable way to say that, yes, this identity is or is
> > > > not a
> > > > % resumption ticket, if I can't decrypt it
> > > >
> > > > Mostly.  External PSKs are established out of band, and that
> > > > provisioning process *could* include knowledge that the
> > > > obfuscated_ticket_age would always be zero when those PSKs are in
> > > > use, and that would be reliable for those specific parties.
> > >
> > > I believe that this can happen in an interoperable way if the protocol
> > > mandates it (which is not the case now). These specific parties may use
> > > software from different vendors which may use different conventions if
> > > the protocol is not clear enough.
> > >
> > > > It's probably also worth considering the two cases for server
> > > > behavior when presented with a PSK id that is neither a known
> > > > external PSK nor a known resumption ticket -- the 

Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable to externally set PSK identity enumeration

[Hubert Kario]

On Monday, 19 March 2018 14:38:05 CET Eric Rescorla wrote:
> On Mon, Mar 19, 2018 at 1:33 PM, Nikos Mavrogiannopoulos 
> 
> wrote:
> > On Fri, 2018-03-16 at 14:45 -0500, Benjamin Kaduk wrote:
> > > On Fri, Mar 16, 2018 at 09:11:32AM -0400, Christian Huitema wrote:
> > > > On 3/15/2018 5:51 PM, Benjamin Kaduk wrote:
> > > > > On Thu, Mar 15, 2018 at 12:25:38PM +0100, Hubert Kario wrote:
> > > > > ...
> > > > > 
> > > > > > we do not have a reliable mechanism of differentiating between
> > > > > > external and
> > > > > > resumption PSKs while parsing Client Hello
> > > > > 
> > > > > Well, a valid external PSK (identity) the server will of course
> > > > > recognize, and we have a SHOULD-level requirement that the
> > > > > obfuscated_ticket_age is zero for external PSKs.  I haven't
> > > > > gotten
> > > > > to think through whether there is still potential for information
> > > > > leakage about external PSK identities, but it seems like there
> > > > > would
> > > > > not be, provided that the server prefers resumption to external-
> > > > > PSK
> > > > > full handshakes.
> > > > 
> > > > I am concerned with the privacy issues linked to these "external
> > > > PSK
> > > > identities". If a system is set so that clients use static PSK
> > > > identities, then the identity is an identifier and the client's
> > > > movements and connections can be tracked. I don't think privacy is
> > > > improved if we make it easy to differentiate external identities
> > > > from
> > > > resumption tickets.
> > > 
> > > Oh, of course, the privacy considerations of the current external
> > > PSK scheme are terrible!  This follows naturally from external PSKs
> > > having not really been a first-class citizen while we were designing
> > > things; we stuffed resumption PSKs together with external PSKs for
> > > the convenience of having them use the same binder construct and
> > > only needing to have one extension at the end of the ClientHello.
> > > Resumption flows get single-use tickets for privacy preservation,
> > > and external PSKs get infinite use and a gigantic correlation
> > > channel.
> > 
> > I agree.
> > 
> > > > If you want to use PSK with some level of privacy, you might adopt
> > > > a
> > > > different setup. For example, servers could provision the clients
> > > > with a
> > > > set of single-use external PSK identities. But then, that looks a
> > > > lot
> > > > like resumption. Or, clients could generate single-use external PSK
> > > > identities by encrypting their long term identity and a nonce with
> > > > the
> > > > public key of the server, a design which of course has its own set
> > > > of
> > > > issues.
> > > 
> > > But, as you note, this is something of an open problem for how to do
> > > well, and this document is already approved by the IESG.  (It's also
> > > not entirely clear that the TLS WG would be the best place to design
> > > this sort of scheme, though of course it could choose to do so.)
> > > 
> > > So to me the open question is whether we consider enumeration of
> > > external PSK identifiers to be something we can address reasonably
> > > at this stage of the document's lifecycle at all.  (I also note that
> > > the presence of a CVE number for a similar issue does not
> > > necessarily mean anything -- CVE assignments can occur for
> > > situations with no actual security impact and/or against the wishes
> > > of the software authors.)  I don't think anyone has proposed a
> > > minimal change that would close the enumeration channel, and given
> > > that external PSKs already have bad privacy properties, it seems
> > > like we may just have to accept this state of affairs for this
> > > document.
> > 
> > That's a good general remark, but not really the case for the
> > vulnerabilities that Hubert pointed out.
> > 
> > > Hubert also says:
> > > 
> > > % so there's no reliable way to say that, yes, this identity is or is
> > > not a
> > > % resumption ticket, if I can't decrypt it
> > > 
> > > Mostly.  External PSKs are established out of band, and that
> > > provisioning process *could* include knowledge that the
> > > obfuscated_ticket_age would always be zero when those PSKs are in
> > > use, and that would be reliable for those specific parties.
> > 
> > I believe that this can happen in an interoperable way if the protocol
> > mandates it (which is not the case now). These specific parties may use
> > software from different vendors which may use different conventions if
> > the protocol is not clear enough.
> > 
> > > It's probably also worth considering the two cases for server
> > > behavior when presented with a PSK id that is neither a known
> > > external PSK nor a known resumption ticket -- the server could
> > > either treat it as an unknown external PSK id or as a resumption
> > > ticket that fails to decrypt.  The latter case fails because the
> > > attacker can try candidate external identities and the server falls
> > > back to a full 

Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable to externally set PSK identity enumeration

[Sean Turner]

> On Mar 20, 2018, at 12:52, Hubert Kario  wrote:
> 
> On Monday, 19 March 2018 23:53:16 CET Benjamin Kaduk wrote:
>> On Mon, Mar 19, 2018 at 05:00:51PM +0100, Hubert Kario wrote:
>>> On Sunday, 18 March 2018 16:27:34 CET Eric Rescorla wrote:
 After discussion with the chairs and the AD, I have opted to just add a
 section
 that explains the attack. I just merged that (but managed not to get it
 into -27
 due to fumble fingering).
>>> 
>>> If there is no consensus on the recommended fix for the issue, I wonder if
>>> we shouldn't then soften the language in the section about PSK binder
>>> handling, from SHOULD to MAY.
>> 
>> I think on the balance I am happier retaining SHOULD.
>> 
>>> Though, I'd say that the reference to that newly added section is
>>> definitely missing.
>> 
>> I expect that can be done as an RFC Editor note or during AUTH48.
>> 
>> -Benjamin
> 
> https://github.com/tlswg/tls13-spec/pull/1189 filed as a reminder

Thanks!

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

Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable to externally set PSK identity enumeration

[Hubert Kario]

On Monday, 19 March 2018 23:53:16 CET Benjamin Kaduk wrote:
> On Mon, Mar 19, 2018 at 05:00:51PM +0100, Hubert Kario wrote:
> > On Sunday, 18 March 2018 16:27:34 CET Eric Rescorla wrote:
> > > After discussion with the chairs and the AD, I have opted to just add a
> > > section
> > > that explains the attack. I just merged that (but managed not to get it
> > > into -27
> > > due to fumble fingering).
> > 
> > If there is no consensus on the recommended fix for the issue, I wonder if
> > we shouldn't then soften the language in the section about PSK binder
> > handling, from SHOULD to MAY.
> 
> I think on the balance I am happier retaining SHOULD.
> 
> > Though, I'd say that the reference to that newly added section is
> > definitely missing.
> 
> I expect that can be done as an RFC Editor note or during AUTH48.
> 
> -Benjamin

https://github.com/tlswg/tls13-spec/pull/1189 filed as a reminder

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable to externally set PSK identity enumeration

[Benjamin Kaduk]

On Mon, Mar 19, 2018 at 02:33:52PM +0100, Nikos Mavrogiannopoulos wrote:
> On Fri, 2018-03-16 at 14:45 -0500, Benjamin Kaduk wrote:
> > On Fri, Mar 16, 2018 at 09:11:32AM -0400, Christian Huitema wrote:
> > > 
> > 
> > > If you want to use PSK with some level of privacy, you might adopt
> > > a
> > > different setup. For example, servers could provision the clients
> > > with a
> > > set of single-use external PSK identities. But then, that looks a
> > > lot
> > > like resumption. Or, clients could generate single-use external PSK
> > > identities by encrypting their long term identity and a nonce with
> > > the
> > > public key of the server, a design which of course has its own set
> > > of
> > > issues.
> > > 
> > 
> > But, as you note, this is something of an open problem for how to do
> > well, and this document is already approved by the IESG.  (It's also
> > not entirely clear that the TLS WG would be the best place to design
> > this sort of scheme, though of course it could choose to do so.)
> > 
> > So to me the open question is whether we consider enumeration of
> > external PSK identifiers to be something we can address reasonably
> > at this stage of the document's lifecycle at all.  (I also note that
> > the presence of a CVE number for a similar issue does not
> > necessarily mean anything -- CVE assignments can occur for
> > situations with no actual security impact and/or against the wishes
> > of the software authors.)  I don't think anyone has proposed a
> > minimal change that would close the enumeration channel, and given
> > that external PSKs already have bad privacy properties, it seems
> > like we may just have to accept this state of affairs for this
> > document.
> 
> That's a good general remark, but not really the case for the
> vulnerabilities that Hubert pointed out.

I think you are just referring to the bit about CVE numbers not
necessarily indicating much of anything?

I would like to hear your opinion on the "open question" I
identified...

> > Hubert also says:
> > 
> > % so there's no reliable way to say that, yes, this identity is or is
> > not a
> > % resumption ticket, if I can't decrypt it
> > 
> > Mostly.  External PSKs are established out of band, and that
> > provisioning process *could* include knowledge that the
> > obfuscated_ticket_age would always be zero when those PSKs are in
> > use, and that would be reliable for those specific parties.
> 
> I believe that this can happen in an interoperable way if the protocol
> mandates it (which is not the case now). These specific parties may use
> software from different vendors which may use different conventions if
> the protocol is not clear enough.

The convention for PSK-only deployments in the text Ekr added seems
clear enough to me, so it seems that only deployments willing to do
either Certificate or PSK in the same server instance are at risk.

> > It's probably also worth considering the two cases for server
> > behavior when presented with a PSK id that is neither a known
> > external PSK nor a known resumption ticket -- the server could
> > either treat it as an unknown external PSK id or as a resumption
> > ticket that fails to decrypt.  The latter case fails because the
> > attacker can try candidate external identities and the server falls
> > back to a full handshake unless the PSK ID is good.  (Well, maybe
> > the server rejects PSK IDs that are shorter than a ticket would be.)
> > The first case is not really usable since it would lead to spurious
> > triggering of the proposed "at most one external PSK" check.
> > 
> > So, in addition to the "we provision external PSKs only when we know
> > that obfuscated_ticket_age will be zero", deployments could also
> > agree that external PSK ids are shorter than a given length and
> > resumption PSKs are larger, which would again provide a reliable
> > differentiator between resumption and external.
> 
> That cannot easily happen. I can have multiple servers answering to the
> same hostname each using a different implementation. Any conventions
> used in one implementation would not apply to another.

You think there will be a server using resumption PSK identifiers
shorter than 128 bits??

> > % I'd really prefer we exhaust other possibilities before sacrificing
> > support
> > % for multiple external PSK. With TLS 1.2 we had ticket_hint to guide
> > PSK
> > % selection, now we're left with just server IP or hostname.
> > 
> > I think that "do nothing and accept external PSK enumeration as a
> > risk" is more likely than sacrificing support for multiple external
> > PSKs, personally.
> 
> The problem is that you personally are not affected by that risk and I
> guess that makes it easy for you to accept it. TLS1.2 with PSK did
> explicitly prevent enumeration (by asking implementations to proceed to
> handshake even with unknown usernames, and making up a key), meaning
> that this is a risk that the designers of PSK (external) intentionally
> ruled out. 

Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable to externally set PSK identity enumeration

[Benjamin Kaduk]

On Mon, Mar 19, 2018 at 05:00:51PM +0100, Hubert Kario wrote:
> On Sunday, 18 March 2018 16:27:34 CET Eric Rescorla wrote:
> > After discussion with the chairs and the AD, I have opted to just add a
> > section
> > that explains the attack. I just merged that (but managed not to get it
> > into -27
> > due to fumble fingering).
> 
> If there is no consensus on the recommended fix for the issue, I wonder if we 
> shouldn't then soften the language in the section about PSK binder handling, 
> from SHOULD to MAY.

I think on the balance I am happier retaining SHOULD.

> Though, I'd say that the reference to that newly added section is definitely 
> missing.

I expect that can be done as an RFC Editor note or during AUTH48.

-Benjamin


signature.asc
Description: PGP signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable to externally set PSK identity enumeration

[Hubert Kario]

On Sunday, 18 March 2018 16:27:34 CET Eric Rescorla wrote:
> After discussion with the chairs and the AD, I have opted to just add a
> section
> that explains the attack. I just merged that (but managed not to get it
> into -27
> due to fumble fingering).

If there is no consensus on the recommended fix for the issue, I wonder if we 
shouldn't then soften the language in the section about PSK binder handling, 
from SHOULD to MAY.

Though, I'd say that the reference to that newly added section is definitely 
missing.

> -Ekr
> 
> On Mon, Mar 12, 2018 at 8:27 AM, Hubert Kario  wrote:
> > When the server supports externally set PSKs that use human readable
> > identities (or, in general, guessable identities), the current text makes
> > it
> > trivial to perform enumeration attack.
> > 
> > The proposed fix was identified as conflicting with the "Client Hello
> > Recording" security section, the severity of that conflict wasn't
> > quantified
> > though.
> > 
> > 
> > Issue in detail:
> > 
> > Problematic paragraph as it stands in draft-ietf-tls-tls13-26 (section
> > 
> > 4.2.11):
> >Prior to accepting PSK key establishment, the server MUST validate
> >the corresponding binder value (see Section 4.2.11.2 below).  If this
> >value is not present or does not validate, the server MUST abort the
> >handshake.  Servers SHOULD NOT attempt to validate multiple binders;
> >rather they SHOULD select a single PSK and validate solely the binder
> >that corresponds to that PSK.  In order to accept PSK key
> >establishment, the server sends a "pre_shared_key" extension
> >indicating the selected identity.
> > 
> > That means, given a server with both PSK and PKI authentication, if
> > attacker
> > sends multiple PSK identities with garbage binders, the server will abort
> > the
> > connection if and only if at least one of the identities was recognised by
> > server. Applying the well known binary search method allows the attacker
> > to
> > then narrow it down to a single identity in O(log_2(n)) steps.
> > 
> > The solution to ignore that one selected binder, and continuing the
> > connection
> > in case that binder does not validate (this is the version in the PR
> > mentioned
> > below), unfortunately doesn't solve this issue either;
> > 
> > If the attacker is in possession of a known good PSK secret (established
> > either through session resumption mechanism or of a less-privileged
> > identity),
> > it can list the known good one as the very last one in the PSK extension.
> > If
> > server recognises one of the identities earlier in the list it will choose
> > no
> > identity (as the binder didn't validate) or the known good identity if
> > none of
> > the previous identities were recognised. Again, applying binary search
> > method
> > allows the attacker to narrow the list to a single entry in just
> > O(log_2(n))
> > steps.
> > 
> > 
> > Proposed solution:
> > 
> > in paragraph above, in description of `binders`:
> >   binders
> >   
> >   : A series of HMAC values, one for
> >
> >each PSK offered in the "pre_shared_keys" extension and in the same
> >order, computed as described below. If the number of binders does not
> > 
> > match
> > 
> >number of identities the server MUST abort the connection with
> >"illegal_parameter" alert.
> > 
> > problematic paragraph after changes:
> >Prior to accepting PSK key establishment, the server MUST validate
> >the corresponding binder value (see Section 4.2.11.2 below).  If this
> >value does not validate, the server MUST ignore the
> >associated identity and retry selection of identity. If no identity is
> >recognised or, for recognised identities, no binder could be validated
> >the server MUST continue connection as if PSK key establishment wasn't
> >attempted.  In order to accept PSK key
> >establishment, the server sends a "pre_shared_key" extension
> >indicating the selected identity.
> > 
> > Unfortunately that solution was identified as conflicting with "Client
> > Hello
> > Recording" section.
> > 
> > Do we consider that conflict to be severe enough to block this change?
> > 
> > Or should we just add more information to that security section, that it
> > needs
> > to deal with this kind of attack?
> > 
> > PS: some discussion on this issue already happened in the github PR:
> > https://github.com/tlswg/tls13-spec/pull/1167
> > --
> > Regards,
> > Hubert Kario
> > Senior Quality Engineer, QE BaseOS Security team
> > Web: www.cz.redhat.com
> > Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic
> > ___
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls


-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

signature.asc
Description: This is a digitally signed 

Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable to externally set PSK identity enumeration

[Eric Rescorla]

On Mon, Mar 19, 2018 at 1:33 PM, Nikos Mavrogiannopoulos 
wrote:

> On Fri, 2018-03-16 at 14:45 -0500, Benjamin Kaduk wrote:
> > On Fri, Mar 16, 2018 at 09:11:32AM -0400, Christian Huitema wrote:
> > >
> > >
> > > On 3/15/2018 5:51 PM, Benjamin Kaduk wrote:
> > > > On Thu, Mar 15, 2018 at 12:25:38PM +0100, Hubert Kario wrote:
> > > > ...
> > > > > we do not have a reliable mechanism of differentiating between
> > > > > external and
> > > > > resumption PSKs while parsing Client Hello
> > > >
> > > > Well, a valid external PSK (identity) the server will of course
> > > > recognize, and we have a SHOULD-level requirement that the
> > > > obfuscated_ticket_age is zero for external PSKs.  I haven't
> > > > gotten
> > > > to think through whether there is still potential for information
> > > > leakage about external PSK identities, but it seems like there
> > > > would
> > > > not be, provided that the server prefers resumption to external-
> > > > PSK
> > > > full handshakes.
> > > >
> > >
> > > I am concerned with the privacy issues linked to these "external
> > > PSK
> > > identities". If a system is set so that clients use static PSK
> > > identities, then the identity is an identifier and the client's
> > > movements and connections can be tracked. I don't think privacy is
> > > improved if we make it easy to differentiate external identities
> > > from
> > > resumption tickets.
> >
> > Oh, of course, the privacy considerations of the current external
> > PSK scheme are terrible!  This follows naturally from external PSKs
> > having not really been a first-class citizen while we were designing
> > things; we stuffed resumption PSKs together with external PSKs for
> > the convenience of having them use the same binder construct and
> > only needing to have one extension at the end of the ClientHello.
> > Resumption flows get single-use tickets for privacy preservation,
> > and external PSKs get infinite use and a gigantic correlation
> > channel.
>
> I agree.
>
> > > If you want to use PSK with some level of privacy, you might adopt
> > > a
> > > different setup. For example, servers could provision the clients
> > > with a
> > > set of single-use external PSK identities. But then, that looks a
> > > lot
> > > like resumption. Or, clients could generate single-use external PSK
> > > identities by encrypting their long term identity and a nonce with
> > > the
> > > public key of the server, a design which of course has its own set
> > > of
> > > issues.
> > >
> >
> > But, as you note, this is something of an open problem for how to do
> > well, and this document is already approved by the IESG.  (It's also
> > not entirely clear that the TLS WG would be the best place to design
> > this sort of scheme, though of course it could choose to do so.)
> >
> > So to me the open question is whether we consider enumeration of
> > external PSK identifiers to be something we can address reasonably
> > at this stage of the document's lifecycle at all.  (I also note that
> > the presence of a CVE number for a similar issue does not
> > necessarily mean anything -- CVE assignments can occur for
> > situations with no actual security impact and/or against the wishes
> > of the software authors.)  I don't think anyone has proposed a
> > minimal change that would close the enumeration channel, and given
> > that external PSKs already have bad privacy properties, it seems
> > like we may just have to accept this state of affairs for this
> > document.
>
> That's a good general remark, but not really the case for the
> vulnerabilities that Hubert pointed out.
>
> > Hubert also says:
> >
> > % so there's no reliable way to say that, yes, this identity is or is
> > not a
> > % resumption ticket, if I can't decrypt it
> >
> > Mostly.  External PSKs are established out of band, and that
> > provisioning process *could* include knowledge that the
> > obfuscated_ticket_age would always be zero when those PSKs are in
> > use, and that would be reliable for those specific parties.
>
> I believe that this can happen in an interoperable way if the protocol
> mandates it (which is not the case now). These specific parties may use
> software from different vendors which may use different conventions if
> the protocol is not clear enough.
>
> > It's probably also worth considering the two cases for server
> > behavior when presented with a PSK id that is neither a known
> > external PSK nor a known resumption ticket -- the server could
> > either treat it as an unknown external PSK id or as a resumption
> > ticket that fails to decrypt.  The latter case fails because the
> > attacker can try candidate external identities and the server falls
> > back to a full handshake unless the PSK ID is good.  (Well, maybe
> > the server rejects PSK IDs that are shorter than a ticket would be.)
> > The first case is not really usable since it would lead to spurious
> > triggering of the proposed "at most one external PSK" check.
> >

Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable to externally set PSK identity enumeration

[Nikos Mavrogiannopoulos]

On Fri, 2018-03-16 at 14:45 -0500, Benjamin Kaduk wrote:
> On Fri, Mar 16, 2018 at 09:11:32AM -0400, Christian Huitema wrote:
> > 
> > 
> > On 3/15/2018 5:51 PM, Benjamin Kaduk wrote:
> > > On Thu, Mar 15, 2018 at 12:25:38PM +0100, Hubert Kario wrote:
> > > ...
> > > > we do not have a reliable mechanism of differentiating between
> > > > external and 
> > > > resumption PSKs while parsing Client Hello
> > > 
> > > Well, a valid external PSK (identity) the server will of course
> > > recognize, and we have a SHOULD-level requirement that the
> > > obfuscated_ticket_age is zero for external PSKs.  I haven't
> > > gotten
> > > to think through whether there is still potential for information
> > > leakage about external PSK identities, but it seems like there
> > > would
> > > not be, provided that the server prefers resumption to external-
> > > PSK
> > > full handshakes.
> > > 
> > 
> > I am concerned with the privacy issues linked to these "external
> > PSK
> > identities". If a system is set so that clients use static PSK
> > identities, then the identity is an identifier and the client's
> > movements and connections can be tracked. I don't think privacy is
> > improved if we make it easy to differentiate external identities
> > from
> > resumption tickets.
> 
> Oh, of course, the privacy considerations of the current external
> PSK scheme are terrible!  This follows naturally from external PSKs
> having not really been a first-class citizen while we were designing
> things; we stuffed resumption PSKs together with external PSKs for
> the convenience of having them use the same binder construct and
> only needing to have one extension at the end of the ClientHello.
> Resumption flows get single-use tickets for privacy preservation,
> and external PSKs get infinite use and a gigantic correlation
> channel.

I agree.

> > If you want to use PSK with some level of privacy, you might adopt
> > a
> > different setup. For example, servers could provision the clients
> > with a
> > set of single-use external PSK identities. But then, that looks a
> > lot
> > like resumption. Or, clients could generate single-use external PSK
> > identities by encrypting their long term identity and a nonce with
> > the
> > public key of the server, a design which of course has its own set
> > of
> > issues.
> > 
> 
> But, as you note, this is something of an open problem for how to do
> well, and this document is already approved by the IESG.  (It's also
> not entirely clear that the TLS WG would be the best place to design
> this sort of scheme, though of course it could choose to do so.)
> 
> So to me the open question is whether we consider enumeration of
> external PSK identifiers to be something we can address reasonably
> at this stage of the document's lifecycle at all.  (I also note that
> the presence of a CVE number for a similar issue does not
> necessarily mean anything -- CVE assignments can occur for
> situations with no actual security impact and/or against the wishes
> of the software authors.)  I don't think anyone has proposed a
> minimal change that would close the enumeration channel, and given
> that external PSKs already have bad privacy properties, it seems
> like we may just have to accept this state of affairs for this
> document.

That's a good general remark, but not really the case for the
vulnerabilities that Hubert pointed out.

> Hubert also says:
> 
> % so there's no reliable way to say that, yes, this identity is or is
> not a
> % resumption ticket, if I can't decrypt it
> 
> Mostly.  External PSKs are established out of band, and that
> provisioning process *could* include knowledge that the
> obfuscated_ticket_age would always be zero when those PSKs are in
> use, and that would be reliable for those specific parties.

I believe that this can happen in an interoperable way if the protocol
mandates it (which is not the case now). These specific parties may use
software from different vendors which may use different conventions if
the protocol is not clear enough.

> It's probably also worth considering the two cases for server
> behavior when presented with a PSK id that is neither a known
> external PSK nor a known resumption ticket -- the server could
> either treat it as an unknown external PSK id or as a resumption
> ticket that fails to decrypt.  The latter case fails because the
> attacker can try candidate external identities and the server falls
> back to a full handshake unless the PSK ID is good.  (Well, maybe
> the server rejects PSK IDs that are shorter than a ticket would be.)
> The first case is not really usable since it would lead to spurious
> triggering of the proposed "at most one external PSK" check.
> 
> So, in addition to the "we provision external PSKs only when we know
> that obfuscated_ticket_age will be zero", deployments could also
> agree that external PSK ids are shorter than a given length and
> resumption PSKs are larger, which would again provide a reliable
> 

Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable to externally set PSK identity enumeration

[Joseph Lorenzo Hall]

On Mon, Mar 19, 2018 at 6:38 AM, Daniel Kahn Gillmor
 wrote:
> On Sun 2018-03-18 12:08:13 -0400, Viktor Dukhovni wrote:
>
>> The devices that might use external PSKs will likely be unavoidably
>> fingerprinted by source IP address and the target mothership.
>
> I'm not convinced that this is the case -- it's not at all clear that
> IoT devices will be attached to a stable network (so the source IP may
> change), and for large deployments, the devices might all share the same
> "mothership".  But the device might still present significant privacy
> concerns (for example, if it's a device that travels with a person, its
> presence on the network could be used to track that person).

In addition to locative privacy threats, the nature of the IoT device
itself might expose something sensitive about the user (e.g., a
connected pleasure device, medical device, or solid platinum espresso
maker).

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

Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable to externally set PSK identity enumeration

[Daniel Kahn Gillmor]

On Sun 2018-03-18 12:08:13 -0400, Viktor Dukhovni wrote:

> The devices that might use external PSKs will likely be unavoidably
> fingerprinted by source IP address and the target mothership.

I'm not convinced that this is the case -- it's not at all clear that
IoT devices will be attached to a stable network (so the source IP may
change), and for large deployments, the devices might all share the same
"mothership".  But the device might still present significant privacy
concerns (for example, if it's a device that travels with a person, its
presence on the network could be used to track that person). 

> So I agree with the above approach.  It is better to keep external PSKs
> simple, with understood limitations, that to attempt (and fail) to turn
> privacy up to eleven.

fwiw, i agree that a big fat warning about the privacy implications of
reused (if you don't reuse, there is no problem) external PSKs is about
all we can do at this stage of TLS 1.3.

--dkg

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

Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable to externally set PSK identity enumeration

[Benjamin Kaduk]

On Sun, Mar 18, 2018 at 03:24:02PM +, Lanlan Pan wrote:
> Benjamin Kaduk 于2018年3月14日周三 上午10:02写道：
> 
> > It seems like we get ourselves in trouble by allowing multiple
> > external PSKs to be present.  If we allowed at most one external
> > PSK in a given ClientHello, then aborting the handshake on binder
> > failure would be the correct choice, as discovering a valid identity
> > would require discovering a valid key/password as well.
> >
> > Disallowing multiple external PSKs would make migration scenarios a
> > little more annoying, but perhaps not fatally so.
> >
> 
> what about each external PSK's survival time ?
> 
> It seems should be updated in period.

It should, but that has always been the case and nothing has changed
in that regard in TLS 1.3 vs TLS 1.2.  (In practice, they are not,
and nothing we say in the document is likely to produce substantial
change in that regard.)

-Ben

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

Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable to externally set PSK identity enumeration

[Viktor Dukhovni]

> On Mar 18, 2018, at 11:27 AM, Eric Rescorla  wrote:
> 
> After discussion with the chairs and the AD, I have opted to just add a 
> section
> that explains the attack. I just merged that (but managed not to get it into 
> -27
> due to fumble fingering).

It seems to me that privacy considerations for external PSKs are a rather
secondary issue.  These are infinitely more likely to be used by IOT devices
calling the mothership than by users browsing content they'd rather keep
private.  I've never used an external PSK, nor do I expect have any of the
posters pointing out the privacy issues.

The devices that might use external PSKs will likely be unavoidably
fingerprinted by source IP address and the target mothership.

So I agree with the above approach.  It is better to keep external PSKs
simple, with understood limitations, that to attempt (and fail) to turn
privacy up to eleven.

-- 
Viktor.

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

Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable to externally set PSK identity enumeration

[Eric Rescorla]

After discussion with the chairs and the AD, I have opted to just add a
section
that explains the attack. I just merged that (but managed not to get it
into -27
due to fumble fingering).

-Ekr


On Mon, Mar 12, 2018 at 8:27 AM, Hubert Kario  wrote:

> When the server supports externally set PSKs that use human readable
> identities (or, in general, guessable identities), the current text makes
> it
> trivial to perform enumeration attack.
>
> The proposed fix was identified as conflicting with the "Client Hello
> Recording" security section, the severity of that conflict wasn't
> quantified
> though.
>
>
> Issue in detail:
>
> Problematic paragraph as it stands in draft-ietf-tls-tls13-26 (section
> 4.2.11):
>Prior to accepting PSK key establishment, the server MUST validate
>the corresponding binder value (see Section 4.2.11.2 below).  If this
>value is not present or does not validate, the server MUST abort the
>handshake.  Servers SHOULD NOT attempt to validate multiple binders;
>rather they SHOULD select a single PSK and validate solely the binder
>that corresponds to that PSK.  In order to accept PSK key
>establishment, the server sends a "pre_shared_key" extension
>indicating the selected identity.
>
> That means, given a server with both PSK and PKI authentication, if
> attacker
> sends multiple PSK identities with garbage binders, the server will abort
> the
> connection if and only if at least one of the identities was recognised by
> server. Applying the well known binary search method allows the attacker to
> then narrow it down to a single identity in O(log_2(n)) steps.
>
> The solution to ignore that one selected binder, and continuing the
> connection
> in case that binder does not validate (this is the version in the PR
> mentioned
> below), unfortunately doesn't solve this issue either;
>
> If the attacker is in possession of a known good PSK secret (established
> either through session resumption mechanism or of a less-privileged
> identity),
> it can list the known good one as the very last one in the PSK extension.
> If
> server recognises one of the identities earlier in the list it will choose
> no
> identity (as the binder didn't validate) or the known good identity if
> none of
> the previous identities were recognised. Again, applying binary search
> method
> allows the attacker to narrow the list to a single entry in just
> O(log_2(n))
> steps.
>
>
> Proposed solution:
>
> in paragraph above, in description of `binders`:
>   binders
>   : A series of HMAC values, one for
>each PSK offered in the "pre_shared_keys" extension and in the same
>order, computed as described below. If the number of binders does not
> match
>number of identities the server MUST abort the connection with
>"illegal_parameter" alert.
>
> problematic paragraph after changes:
>Prior to accepting PSK key establishment, the server MUST validate
>the corresponding binder value (see Section 4.2.11.2 below).  If this
>value does not validate, the server MUST ignore the
>associated identity and retry selection of identity. If no identity is
>recognised or, for recognised identities, no binder could be validated
>the server MUST continue connection as if PSK key establishment wasn't
>attempted.  In order to accept PSK key
>establishment, the server sends a "pre_shared_key" extension
>indicating the selected identity.
>
> Unfortunately that solution was identified as conflicting with "Client
> Hello
> Recording" section.
>
> Do we consider that conflict to be severe enough to block this change?
>
> Or should we just add more information to that security section, that it
> needs
> to deal with this kind of attack?
>
> PS: some discussion on this issue already happened in the github PR:
> https://github.com/tlswg/tls13-spec/pull/1167
> --
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic
> ___
> 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] draft-ietf-tls-tls13-26 is vulnerable to externally set PSK identity enumeration

[Lanlan Pan]

Benjamin Kaduk 于2018年3月14日周三 上午10:02写道：

> It seems like we get ourselves in trouble by allowing multiple
> external PSKs to be present.  If we allowed at most one external
> PSK in a given ClientHello, then aborting the handshake on binder
> failure would be the correct choice, as discovering a valid identity
> would require discovering a valid key/password as well.
>
> Disallowing multiple external PSKs would make migration scenarios a
> little more annoying, but perhaps not fatally so.
>

what about each external PSK's survival time ?

It seems should be updated in period.


>
> -Ben(jamin)
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable to externally set PSK identity enumeration

[Benjamin Kaduk]

On Fri, Mar 16, 2018 at 09:11:32AM -0400, Christian Huitema wrote:
> 
> 
> On 3/15/2018 5:51 PM, Benjamin Kaduk wrote:
> > On Thu, Mar 15, 2018 at 12:25:38PM +0100, Hubert Kario wrote:
> > ...
> >> we do not have a reliable mechanism of differentiating between external 
> >> and 
> >> resumption PSKs while parsing Client Hello
> > Well, a valid external PSK (identity) the server will of course
> > recognize, and we have a SHOULD-level requirement that the
> > obfuscated_ticket_age is zero for external PSKs.  I haven't gotten
> > to think through whether there is still potential for information
> > leakage about external PSK identities, but it seems like there would
> > not be, provided that the server prefers resumption to external-PSK
> > full handshakes.
> >
> 
> I am concerned with the privacy issues linked to these "external PSK
> identities". If a system is set so that clients use static PSK
> identities, then the identity is an identifier and the client's
> movements and connections can be tracked. I don't think privacy is
> improved if we make it easy to differentiate external identities from
> resumption tickets.

Oh, of course, the privacy considerations of the current external
PSK scheme are terrible!  This follows naturally from external PSKs
having not really been a first-class citizen while we were designing
things; we stuffed resumption PSKs together with external PSKs for
the convenience of having them use the same binder construct and
only needing to have one extension at the end of the ClientHello.
Resumption flows get single-use tickets for privacy preservation,
and external PSKs get infinite use and a gigantic correlation
channel.


> If you want to use PSK with some level of privacy, you might adopt a
> different setup. For example, servers could provision the clients with a
> set of single-use external PSK identities. But then, that looks a lot
> like resumption. Or, clients could generate single-use external PSK
> identities by encrypting their long term identity and a nonce with the
> public key of the server, a design which of course has its own set of
> issues.
> 

But, as you note, this is something of an open problem for how to do
well, and this document is already approved by the IESG.  (It's also
not entirely clear that the TLS WG would be the best place to design
this sort of scheme, though of course it could choose to do so.)

So to me the open question is whether we consider enumeration of
external PSK identifiers to be something we can address reasonably
at this stage of the document's lifecycle at all.  (I also note that
the presence of a CVE number for a similar issue does not
necessarily mean anything -- CVE assignments can occur for
situations with no actual security impact and/or against the wishes
of the software authors.)  I don't think anyone has proposed a
minimal change that would close the enumeration channel, and given
that external PSKs already have bad privacy properties, it seems
like we may just have to accept this state of affairs for this
document.


Hubert also says:

% so there's no reliable way to say that, yes, this identity is or is not a
% resumption ticket, if I can't decrypt it

Mostly.  External PSKs are established out of band, and that
provisioning process *could* include knowledge that the
obfuscated_ticket_age would always be zero when those PSKs are in
use, and that would be reliable for those specific parties.

It's probably also worth considering the two cases for server
behavior when presented with a PSK id that is neither a known
external PSK nor a known resumption ticket -- the server could
either treat it as an unknown external PSK id or as a resumption
ticket that fails to decrypt.  The latter case fails because the
attacker can try candidate external identities and the server falls
back to a full handshake unless the PSK ID is good.  (Well, maybe
the server rejects PSK IDs that are shorter than a ticket would be.)
The first case is not really usable since it would lead to spurious
triggering of the proposed "at most one external PSK" check.

So, in addition to the "we provision external PSKs only when we know
that obfuscated_ticket_age will be zero", deployments could also
agree that external PSK ids are shorter than a given length and
resumption PSKs are larger, which would again provide a reliable
differentiator between resumption and external.

The privacy issues remain terrible, of course.

% I'd really prefer we exhaust other possibilities before sacrificing support
% for multiple external PSK. With TLS 1.2 we had ticket_hint to guide PSK
% selection, now we're left with just server IP or hostname.

I think that "do nothing and accept external PSK enumeration as a
risk" is more likely than sacrificing support for multiple external
PSKs, personally.

-Benjamin

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

Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable to externally set PSK identity enumeration

[Christian Huitema]

On 3/15/2018 5:51 PM, Benjamin Kaduk wrote:
> On Thu, Mar 15, 2018 at 12:25:38PM +0100, Hubert Kario wrote:
> ...
>> we do not have a reliable mechanism of differentiating between external and 
>> resumption PSKs while parsing Client Hello
> Well, a valid external PSK (identity) the server will of course
> recognize, and we have a SHOULD-level requirement that the
> obfuscated_ticket_age is zero for external PSKs.  I haven't gotten
> to think through whether there is still potential for information
> leakage about external PSK identities, but it seems like there would
> not be, provided that the server prefers resumption to external-PSK
> full handshakes.
>

I am concerned with the privacy issues linked to these "external PSK
identities". If a system is set so that clients use static PSK
identities, then the identity is an identifier and the client's
movements and connections can be tracked. I don't think privacy is
improved if we make it easy to differentiate external identities from
resumption tickets.

If you want to use PSK with some level of privacy, you might adopt a
different setup. For example, servers could provision the clients with a
set of single-use external PSK identities. But then, that looks a lot
like resumption. Or, clients could generate single-use external PSK
identities by encrypting their long term identity and a nonce with the
public key of the server, a design which of course has its own set of
issues.

-- Christian Huitema




signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable to externally set PSK identity enumeration

[Hubert Kario]

On Thursday, 15 March 2018 22:51:49 CET Benjamin Kaduk wrote:
> On Thu, Mar 15, 2018 at 12:25:38PM +0100, Hubert Kario wrote:
> > On Wednesday, 14 March 2018 21:13:29 CET Benjamin Kaduk wrote:
> > > On Wed, Mar 14, 2018 at 12:46:25PM +0100, Hubert Kario wrote:
> > > > On Wednesday, 14 March 2018 03:02:10 CET Benjamin Kaduk wrote:
> > > > > It seems like we get ourselves in trouble by allowing multiple
> > > > > external PSKs to be present.  If we allowed at most one external
> > > > > PSK in a given ClientHello, then aborting the handshake on binder
> > > > > failure would be the correct choice, as discovering a valid identity
> > > > > would require discovering a valid key/password as well.
> > > > 
> > > > but identity/binder may be invalid only because the server was
> > > > restarted
> > > > and generated a new in-memory key; we don't want to abort connection
> > > > in
> > > > such
> > > 
> > > For an external PSK?  That hardly sounds like "external" to me...
> > 
> > not my fault that what we called just "PSK"s in TLS 1.2 is now "external
> > PSKs" in TLS 1.3... I wanted to be unambiguous, so please, can we discuss
> > the issue, not semiotics?
> 
> Sure!  (I still don't see how an ephemeral in-server key would be
> used as/with an external PSK.)

aah, that's were the confusion is, I was talking ("only because the server was 
restarted") about resumption PSKs, I didn't think you were proposing ("then 
aborting the handshake on binder failure would be the correct choice") that 
behaviour only for external PSKs — you can't differentiate resumption PSKs 
based on being able to verify the identify (assuming it's a RFC 5077-style 
ticket) because you can't be sure you have all the keys to verify them
(not to mention that the tickets could have been established by a TLS 
implementation that was used on this server yesterday or the identity can be a 
database lookup key, session_id style)

so there's no reliable way to say that, yes, this identity is or is not a 
resumption ticket, if I can't decrypt it

> > > > situation, continuing to a regular handshake is necessary then for
> > > > good
> > > > user experience (and likely, even security, given the history of TLS
> > > > version fallbacks)
> > > > 
> > > > > Disallowing multiple external PSKs would make migration scenarios a
> > > > > little more annoying, but perhaps not fatally so.
> > > > 
> > > > not only migration, but session resumption and regular PSK at the same
> > > > time
> > > > too - for session resumption you may not do DH, while for initial
> > > > handshake
> > > > with PSK you may want to to gain PFS...
> > > > 
> > > > so as tempting as the removal of multiple PSKs from ClientHello is,
> > > > I'm
> > > > afraid the fallout is far too large to do it
> > > 
> > > I did not say removal of multiple PSKs, rather removal of multiple
> > > *external* PSKs.
> > 
> > we do not have a reliable mechanism of differentiating between external
> > and
> > resumption PSKs while parsing Client Hello
> 
> Well, a valid external PSK (identity) the server will of course
> recognize, and we have a SHOULD-level requirement that the
> obfuscated_ticket_age is zero for external PSKs.  I haven't gotten
> to think through whether there is still potential for information
> leakage about external PSK identities, but it seems like there would
> not be, provided that the server prefers resumption to external-PSK
> full handshakes.

SHOULD means we can't depend on it — it's not reliable

if we say that resumption PSKs MUST have zero age and resumption ticket MUST 
NOT be zero (even if that means fudging the time a bit), then yes, there would 
be a way to differentiate them

that doesn't help against attackers that have one valid identity and want to 
find out other identities configured on the server though

I'd really prefer we exhaust other possibilities before sacrificing support 
for multiple external PSK. With TLS 1.2 we had ticket_hint to guide PSK 
selection, now we're left with just server IP or hostname.
(I do admit that requiring one external PSK, having way to identify them with 
no false positives and negatives, and ignoring it completely in case of binder 
verification failure does look solid)
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable to externally set PSK identity enumeration

[Hubert Kario]

On Wednesday, 14 March 2018 21:13:29 CET Benjamin Kaduk wrote:
> On Wed, Mar 14, 2018 at 12:46:25PM +0100, Hubert Kario wrote:
> > On Wednesday, 14 March 2018 03:02:10 CET Benjamin Kaduk wrote:
> > > It seems like we get ourselves in trouble by allowing multiple
> > > external PSKs to be present.  If we allowed at most one external
> > > PSK in a given ClientHello, then aborting the handshake on binder
> > > failure would be the correct choice, as discovering a valid identity
> > > would require discovering a valid key/password as well.
> > 
> > but identity/binder may be invalid only because the server was restarted
> > and generated a new in-memory key; we don't want to abort connection in
> > such
> For an external PSK?  That hardly sounds like "external" to me...

not my fault that what we called just "PSK"s in TLS 1.2 is now "external PSKs" 
in TLS 1.3... I wanted to be unambiguous, so please, can we discuss the issue, 
not semiotics?

> > situation, continuing to a regular handshake is necessary then for good
> > user experience (and likely, even security, given the history of TLS
> > version fallbacks)
> > 
> > > Disallowing multiple external PSKs would make migration scenarios a
> > > little more annoying, but perhaps not fatally so.
> > 
> > not only migration, but session resumption and regular PSK at the same
> > time
> > too - for session resumption you may not do DH, while for initial
> > handshake
> > with PSK you may want to to gain PFS...
> > 
> > so as tempting as the removal of multiple PSKs from ClientHello is, I'm
> > afraid the fallout is far too large to do it
> 
> I did not say removal of multiple PSKs, rather removal of multiple
> *external* PSKs.

we do not have a reliable mechanism of differentiating between external and 
resumption PSKs while parsing Client Hello

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable to externally set PSK identity enumeration

[Benjamin Kaduk]

On Wed, Mar 14, 2018 at 12:46:25PM +0100, Hubert Kario wrote:
> On Wednesday, 14 March 2018 03:02:10 CET Benjamin Kaduk wrote:
> > It seems like we get ourselves in trouble by allowing multiple
> > external PSKs to be present.  If we allowed at most one external
> > PSK in a given ClientHello, then aborting the handshake on binder
> > failure would be the correct choice, as discovering a valid identity
> > would require discovering a valid key/password as well.
> 
> but identity/binder may be invalid only because the server was restarted and 
> generated a new in-memory key; we don't want to abort connection in such 

For an external PSK?  That hardly sounds like "external" to me...

> situation, continuing to a regular handshake is necessary then for good user 
> experience (and likely, even security, given the history of TLS version 
> fallbacks)
>  
> > Disallowing multiple external PSKs would make migration scenarios a
> > little more annoying, but perhaps not fatally so.
> 
> not only migration, but session resumption and regular PSK at the same time 
> too - for session resumption you may not do DH, while for initial handshake 
> with PSK you may want to to gain PFS...
> 
> so as tempting as the removal of multiple PSKs from ClientHello is, I'm 
> afraid 
> the fallout is far too large to do it

I did not say removal of multiple PSKs, rather removal of multiple
*external* PSKs.

-Ben(jamin)

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

Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable to externally set PSK identity enumeration

[Hubert Kario]

On Wednesday, 14 March 2018 03:02:10 CET Benjamin Kaduk wrote:
> It seems like we get ourselves in trouble by allowing multiple
> external PSKs to be present.  If we allowed at most one external
> PSK in a given ClientHello, then aborting the handshake on binder
> failure would be the correct choice, as discovering a valid identity
> would require discovering a valid key/password as well.

but identity/binder may be invalid only because the server was restarted and 
generated a new in-memory key; we don't want to abort connection in such 
situation, continuing to a regular handshake is necessary then for good user 
experience (and likely, even security, given the history of TLS version 
fallbacks)
 
> Disallowing multiple external PSKs would make migration scenarios a
> little more annoying, but perhaps not fatally so.

not only migration, but session resumption and regular PSK at the same time 
too - for session resumption you may not do DH, while for initial handshake 
with PSK you may want to to gain PFS...

so as tempting as the removal of multiple PSKs from ClientHello is, I'm afraid 
the fallout is far too large to do it
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable to externally set PSK identity enumeration

[Hubert Kario]

On Tuesday, 13 March 2018 16:18:48 CET Ilari Liusvaara wrote:
> On Mon, Mar 12, 2018 at 04:27:46PM +0100, Hubert Kario wrote:
> > When the server supports externally set PSKs that use human readable
> > identities (or, in general, guessable identities), the current text makes
> > it trivial to perform enumeration attack.
> 
> What would be impact of such enumeration attack? It seems to me that
> not disclosing identities is to make weak passwords more difficult to
> attack, but here there are no weak passwords.

the usernames themselves can be confidential information

behaviour like that was considered a vulnerability before, irrespective of 
robustness of passwords:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-0190
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5229

> Note that:
> 
> - There is no protection for the PSK identity, so putting anything
>   sensitive in it is a bad idea.

the server can be accessible both through Internet and through encrypted 
connections (e.g. IPsec), and while it exposing identities may not lead to an 
exploit, it very likely will make social engineering easier; it is information 
disclosure one way or the other

> - Passive attack gives attacker not only a valid PSK identity, but
>   enough information to mount high-speed offline cracking attack on the
>   PSK secret. Only one captured key exchange is needed, and (EC)DHE
>   does not help.

that does require you to be on-route of a connection and to capture it, that's 
much harder to do than firing up a simple script against any given server with 
PSK enabled.

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls