Re: [TLS] Distinguishing between external/resumption PSKs

[Rob Sayre]

On Fri, Sep 20, 2019 at 1:07 AM Mohit Sethi M  wrote:

> Chrisitian Huitema rightly points out that having free from PSKIdentity is
> good from a privacy perspective as an attacker cannot distinguish between
> initial authentication and resumption. However, if the server first has to
> lookup the resumption PSKs table before checking for any matching external
> PSKs, the timing information would leak that nonetheless.
>

This timing issue is a good concern to raise.

However, it made me wonder why the various ESNI drafts don't allow any
ClientHello field or extension to be encrypted.

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

Re: [TLS] Distinguishing between external/resumption PSKs

[Rob Sayre]

On Fri, Sep 20, 2019 at 4:32 AM Nikos Mavrogiannopoulos 
wrote:

> On Thu, Sep 19, 2019 at 11:49 PM Nico Williams 
> wrote:
> >
> > On Thu, Sep 19, 2019 at 04:57:17PM -0400, Richard Barnes wrote:
> > > I don't think anyone's asking for these cases to be differentiable on
> the
> > > wire.  The question is whether the *server* can differentiate, in
> > > particular, the application running on the server.
> >
> > And the answer to that one is "yes", because the server has control over
> > the PSK IDs.
>
> You are making a lot of implicit assumptions for that. Consider a
> "server" consisting of multiple front end implementations all
> connected to a DB back-end. Does that "server" has control over PSK
> IDs?
>

While Nico's assertion isn't always practical, I think it fits a pretty
common pattern: a TLS-terminator / edge server validates that the server
issued the credential, without hitting the backing credentials database.
These servers often perform similar checks on HTTP Cookie headers. Then, as
the traffic is passed to the application, the credential is actually
checked against the database.

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

Re: [TLS] Distinguishing between external/resumption PSKs

[Nikos Mavrogiannopoulos]

On Thu, Sep 19, 2019 at 11:49 PM Nico Williams  wrote:
>
> On Thu, Sep 19, 2019 at 04:57:17PM -0400, Richard Barnes wrote:
> > I don't think anyone's asking for these cases to be differentiable on the
> > wire.  The question is whether the *server* can differentiate, in
> > particular, the application running on the server.
>
> And the answer to that one is "yes", because the server has control over
> the PSK IDs.

You are making a lot of implicit assumptions for that. Consider a
"server" consisting of multiple front end implementations all
connected to a DB back-end. Does that "server" has control over PSK
IDs? A server can also be replaced on an upgrade with a different
implementation, or a different version of the implementation, does
that also guarantee that the server still has control over the PSK
IDs? It looks to me like a hard problem to tackle except for few
straightforward cases.

regards,
Nikos

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

Re: [TLS] Distinguishing between external/resumption PSKs

[Mohit Sethi M]

Hi all,

Thanks Owen for starting this discussion. For some context, the EMU working 
group is currently working on a document titled "Using EAP-TLS with TLS 1.3": 
https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-06

There has been recent discussion in the working group on whether EAP-TLS should 
support PSKs for the initial authentication. The current text says "Pre-Shared 
Key (PSK) authentication SHALL NOT be used except for resumption.".

As Richard points out, there is a distinction between "the server". Almost all 
EAP-TLS implementations use existing cryptographic libraries which handle the 
resumption PSK and PskIdentity. However, it is not clear (to me) who would set 
the PSKIdentity for the initial authentication. Should it be left to the 
application logic (in this case the EAP server)?

Do we care about PSKIdentity collisions? As Jonathan points out, having several 
PSKs with the same identity may require trial decryption and that can go wrong 
in several ways.

Chrisitian Huitema rightly points out that having free from PSKIdentity is good 
from a privacy perspective as an attacker cannot distinguish between initial 
authentication and resumption. However, if the server first has to lookup the 
resumption PSKs table before checking for any matching external PSKs, the 
timing information would leak that nonetheless.

Should a server issue NewSessionTickets when the original authentication itself 
was based on PSK? It would be nice to prevent tracking based on PSKIdentity.

We (or at least I) could certainly benefit with some more guidance from the TLS 
working group on this topic.

--Mohit

On 9/20/19 1:03 AM, Richard Barnes wrote:
On Thu, Sep 19, 2019 at 5:49 PM Nico Williams 
mailto:n...@cryptonector.com>> wrote:
On Thu, Sep 19, 2019 at 04:57:17PM -0400, Richard Barnes wrote:
> I don't think anyone's asking for these cases to be differentiable on the
> wire.  The question is whether the *server* can differentiate, in
> particular, the application running on the server.

And the answer to that one is "yes", because the server has control over
the PSK IDs.

That glosses over an important distinction made up-thread: When we say "the 
server", there is typically a distinction between the TLS stack and the server 
application logic.  Resumption PSKs are typically controlled by the TLS stack, 
while external PSKs are provided by the application logic.  The question is how 
the application logic, when presented with a session authenticated under a 
given PSK ID, can distinguish whether the PSK used was one provided by the TLS 
stack for resumption, or provided by the application logic.

--Richard



___
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] Distinguishing between external/resumption PSKs

[Nico Williams]

On Thu, Sep 19, 2019 at 06:03:44PM -0400, Richard Barnes wrote:
> On Thu, Sep 19, 2019 at 5:49 PM Nico Williams  wrote:
> > On Thu, Sep 19, 2019 at 04:57:17PM -0400, Richard Barnes wrote:
> > > I don't think anyone's asking for these cases to be differentiable on the
> > > wire.  The question is whether the *server* can differentiate, in
> > > particular, the application running on the server.
> >
> > And the answer to that one is "yes", because the server has control over
> > the PSK IDs.
> 
> That glosses over an important distinction made up-thread: When we say "the
> server", there is typically a distinction between the TLS stack and the
> server application logic.  Resumption PSKs are typically controlled by the
> TLS stack, while external PSKs are provided by the application logic.  The
> question is how the application logic, when presented with a session
> authenticated under a given PSK ID, can distinguish whether the PSK used
> was one provided by the TLS stack for resumption, or provided by the
> application logic.

Depends on which gets a first crack at it.

You could have a plugin system as well where the plugins are invoked by
the TLS stack.  And again, order may matter if there's no reliable way
to "taste" the PSK IDs.

So the answer is that order of evaluation matters, and that's OK.

Nico
-- 

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

Re: [TLS] Distinguishing between external/resumption PSKs

[Richard Barnes]

On Thu, Sep 19, 2019 at 5:49 PM Nico Williams  wrote:

> On Thu, Sep 19, 2019 at 04:57:17PM -0400, Richard Barnes wrote:
> > I don't think anyone's asking for these cases to be differentiable on the
> > wire.  The question is whether the *server* can differentiate, in
> > particular, the application running on the server.
>
> And the answer to that one is "yes", because the server has control over
> the PSK IDs.
>

That glosses over an important distinction made up-thread: When we say "the
server", there is typically a distinction between the TLS stack and the
server application logic.  Resumption PSKs are typically controlled by the
TLS stack, while external PSKs are provided by the application logic.  The
question is how the application logic, when presented with a session
authenticated under a given PSK ID, can distinguish whether the PSK used
was one provided by the TLS stack for resumption, or provided by the
application logic.

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

Re: [TLS] Distinguishing between external/resumption PSKs

[Nico Williams]

On Thu, Sep 19, 2019 at 04:57:17PM -0400, Richard Barnes wrote:
> I don't think anyone's asking for these cases to be differentiable on the
> wire.  The question is whether the *server* can differentiate, in
> particular, the application running on the server.

And the answer to that one is "yes", because the server has control over
the PSK IDs.

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

Re: [TLS] Distinguishing between external/resumption PSKs

[Jonathan Hoyland]

On Thu, 19 Sep 2019 at 21:57, Richard Barnes  wrote:

> I don't think anyone's asking for these cases to be differentiable on the
> wire.  The question is whether the *server* can differentiate, in
> particular, the application running on the server.
>
> --Richard
>
Exactly. I hope it's not controversial that the TLS server knows what's
going on / what it's agreeing to. The specific restriction I was suggesting
is that a server shouldn't accept multiple PSKs with the same PSK_ID.
That would require the server to do things like trial decryption, and has
so many ways it could go wrong. The PSK Importer draft is designed to make
it easy to take a single PSK and PSK_ID and diversify them safely.
Using one PSK_ID for multiple PSKs has no benefits and lots of risks.

Regards,

Jonathan


>
> On Thu, Sep 19, 2019 at 2:36 PM Nico Williams 
> wrote:
>
>> On Thu, Sep 19, 2019 at 08:06:26AM -1000, Christian Huitema wrote:
>> > There is also a privacy angle. From a privacy point of view, it is
>> > very nice that PSK cannot be distinguished from session resumption.
>>
>> This.
>>
>> PSK is the right way to, for example, integrate Kerberos into TLS 1.3
>> now.  But it's no eavesdropper's business whether a session used
>> Kerberos for setup or resumption tickets.
>>
>> Nico
>> --
>>
> ___
> 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] Distinguishing between external/resumption PSKs

[Richard Barnes]

I don't think anyone's asking for these cases to be differentiable on the
wire.  The question is whether the *server* can differentiate, in
particular, the application running on the server.

--Richard

On Thu, Sep 19, 2019 at 2:36 PM Nico Williams  wrote:

> On Thu, Sep 19, 2019 at 08:06:26AM -1000, Christian Huitema wrote:
> > There is also a privacy angle. From a privacy point of view, it is
> > very nice that PSK cannot be distinguished from session resumption.
>
> This.
>
> PSK is the right way to, for example, integrate Kerberos into TLS 1.3
> now.  But it's no eavesdropper's business whether a session used
> Kerberos for setup or resumption tickets.
>
> Nico
> --
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Distinguishing between external/resumption PSKs

[Nico Williams]

On Thu, Sep 19, 2019 at 08:06:26AM -1000, Christian Huitema wrote:
> There is also a privacy angle. From a privacy point of view, it is
> very nice that PSK cannot be distinguished from session resumption.

This.

PSK is the right way to, for example, integrate Kerberos into TLS 1.3
now.  But it's no eavesdropper's business whether a session used
Kerberos for setup or resumption tickets.

Nico
-- 

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

Re: [TLS] Distinguishing between external/resumption PSKs

[Christian Huitema]

There is also a privacy angle. From a privacy point of view, it is very nice 
that PSK cannot be distinguished from session resumption.

-- Christian Huitema 

> On Sep 19, 2019, at 5:57 AM, Richard Barnes  wrote:
> 
> As nice as that requirement would be, I'm not sure it's really compatible 
> with the way people want to build software.  For example, OpenSSL right now 
> gets external PSKs by calling out to an external callback.  Given that degree 
> of separation, proactively assuring no collisions would be hard.
> 
>> On Thu, Sep 19, 2019 at 11:43 AM Jonathan Hoyland 
>>  wrote:
>> Ah yes, Richard is right, the PSK IDs do not have a defined structure. 
>> 
>> Having two different PSKs attached to a single PSK_ID should be banned if it 
>> isn't already. 
>> 
>> Regards,
>> 
>> Jonathan
>> 
>>> On Thu, 19 Sep 2019 at 16:26, Richard Barnes  wrote:
>>>> On Thu, Sep 19, 2019 at 10:26 AM Jonathan Hoyland 
>>>>  wrote:
>>> 
>>>> That's how I would interpret the spec yes. 
>>>> You could argue that there's a distinguishing attack where the attacker 
>>>> measures the response time on PSKs to determine if it was an OOB PSK or a 
>>>> resumption, but I think you could do equally well just by looking at the 
>>>> PSK lengths, because resumption PSKs have a defined structure. 
>>> 
>>> I don't think that's quite right.  The PSKs resulting from NewSessionTicket 
>>> have a defined structure, but the PSK *IDs* do not; they're specified by 
>>> the server.  AFAICT, existing server stacks generate their own PSK IDs for 
>>> resumption PSKs, so from the application's perspective, the structure of 
>>> the resumption PSKs is unknown (or at best, specific to the TLS library in 
>>> use).
>>> 
>>> If I understand correctly, the worst case here would be:
>>> 
>>> 1. The server application wants to have some behavior change based on the 
>>> use of an external PSK (not resumption)
>>> 2. The server TLS stack is configured with external and resumption PSKs 
>>> with the same PSK ID
>>> 3. The client sends a ClientHello using the resumption PSK
>>> 4. The server TLS stack attempts to verify the binder with the resumption 
>>> PSK and succeeds
>>> 5. The server application gets a session that is authenticated with the PSK 
>>> ID and notes that the PSK ID matches one of its external PSKs
>>> 6. The server application improperly does the external PSK behavior when in 
>>> fact resumption has happened
>>> 
>>> I might be missing something, but I don't see anything in the spec that 
>>> would prevent this situation from arising.  So it's up to the application 
>>> to choose its PSK IDs in such a way that they don't collide with resumption 
>>> PSK IDs.  But the fact that resumption PSK IDs are implementation-specific 
>>> mean that this is tough to do with any generality, unless you're willing to 
>>> rely on long pseudorandom strings not colliding with each other.
>>> 
>>> Maybe the answer is just that TLS stacks that handle their own resumption 
>>> caches need to signal to applications when that cache has been used vs. an 
>>> external PSK.
>>> 
>>> --Richard
>>> 
>>> 
>>>> 
>>>> Regards,
>>>> 
>>>> Jonathan
>>>> 
>>>>> On Thu, 19 Sep 2019 at 15:04, Owen Friel (ofriel)  
>>>>> wrote:
>>>>> 
>>>>> 
>>>>> > -Original Message-
>>>>> > From: Jonathan Hoyland 
>>>>> > Sent: 19 September 2019 14:32
>>>>> > To: Owen Friel (ofriel) 
>>>>> > Cc: Martin Thomson ; tls@ietf.org
>>>>> > Subject: Re: [TLS] Distinguishing between external/resumption PSKs
>>>>> > 
>>>>> > Hi Owen,
>>>>> > 
>>>>> > If I understand your question correctly the distinguishing is done 
>>>>> > implicitly
>>>>> > (not explicitly) through the key schedule.
>>>>> > If the client and server do not agree on whether the PSK is a 
>>>>> > resumption or
>>>>> > an OOB PSK then the `binder_key` will not match, and the handshake will 
>>>>> > fail.
>>>>> > 
>>>>> > See pp. 93-94 of the spec.
>>>>> 
>>>>> And we only eve

Re: [TLS] Distinguishing between external/resumption PSKs

[Richard Barnes]

As nice as that requirement would be, I'm not sure it's really compatible
with the way people want to build software.  For example, OpenSSL right now
gets external PSKs by calling out to an external callback.  Given that
degree of separation, proactively assuring no collisions would be hard.

On Thu, Sep 19, 2019 at 11:43 AM Jonathan Hoyland <
jonathan.hoyl...@gmail.com> wrote:

> Ah yes, Richard is right, the PSK IDs do not have a defined structure.
>
> Having two different PSKs attached to a single PSK_ID should be banned if
> it isn't already.
>
> Regards,
>
> Jonathan
>
> On Thu, 19 Sep 2019 at 16:26, Richard Barnes  wrote:
>
>> On Thu, Sep 19, 2019 at 10:26 AM Jonathan Hoyland <
>> jonathan.hoyl...@gmail.com> wrote:
>>
>>> That's how I would interpret the spec yes.
>>> You could argue that there's a distinguishing attack where the attacker
>>> measures the response time on PSKs to determine if it was an OOB PSK or a
>>> resumption, but I think you could do equally well just by looking at the
>>> PSK lengths, because resumption PSKs have a defined structure.
>>>
>>
>> I don't think that's quite right.  The PSKs resulting from
>> NewSessionTicket have a defined structure, but the PSK *IDs* do not;
>> they're specified by the server.  AFAICT, existing server stacks generate
>> their own PSK IDs for resumption PSKs, so from the application's
>> perspective, the structure of the resumption PSKs is unknown (or at best,
>> specific to the TLS library in use).
>>
>> If I understand correctly, the worst case here would be:
>>
>> 1. The server application wants to have some behavior change based on the
>> use of an external PSK (not resumption)
>> 2. The server TLS stack is configured with external and resumption PSKs
>> with the same PSK ID
>> 3. The client sends a ClientHello using the resumption PSK
>> 4. The server TLS stack attempts to verify the binder with the resumption
>> PSK and succeeds
>> 5. The server application gets a session that is authenticated with the
>> PSK ID and notes that the PSK ID matches one of its external PSKs
>> 6. The server application improperly does the external PSK behavior when
>> in fact resumption has happened
>>
>> I might be missing something, but I don't see anything in the spec that
>> would prevent this situation from arising.  So it's up to the application
>> to choose its PSK IDs in such a way that they don't collide with resumption
>> PSK IDs.  But the fact that resumption PSK IDs are implementation-specific
>> mean that this is tough to do with any generality, unless you're willing to
>> rely on long pseudorandom strings not colliding with each other.
>>
>> Maybe the answer is just that TLS stacks that handle their own resumption
>> caches need to signal to applications when that cache has been used vs. an
>> external PSK.
>>
>> --Richard
>>
>>
>>
>>> Regards,
>>>
>>> Jonathan
>>>
>>> On Thu, 19 Sep 2019 at 15:04, Owen Friel (ofriel) 
>>> wrote:
>>>
>>>>
>>>>
>>>> > -Original Message-
>>>> > From: Jonathan Hoyland 
>>>> > Sent: 19 September 2019 14:32
>>>> > To: Owen Friel (ofriel) 
>>>> > Cc: Martin Thomson ; tls@ietf.org
>>>> > Subject: Re: [TLS] Distinguishing between external/resumption PSKs
>>>> >
>>>> > Hi Owen,
>>>> >
>>>> > If I understand your question correctly the distinguishing is done
>>>> implicitly
>>>> > (not explicitly) through the key schedule.
>>>> > If the client and server do not agree on whether the PSK is a
>>>> resumption or
>>>> > an OOB PSK then the `binder_key` will not match, and the handshake
>>>> will fail.
>>>> >
>>>> > See pp. 93-94 of the spec.
>>>>
>>>> And we only even get that far on the off chance that an ext
>>>> PskIdentity.identity is exactly the same as a res PskIdentity.identity..
>>>> e.g. a client presents an ext PskIdentity.identity, the server somehow
>>>> thinks it’s a res PskIdentity.identity, and then handshaking will fail, not
>>>> only because the actual raw PSK is likely different but the binders will
>>>> not match due to different labels.
>>>>
>>>> But my question was before we even get that far - its an internal
>>>> server implementation decisi

Re: [TLS] Distinguishing between external/resumption PSKs

[Jonathan Hoyland]

Ah yes, Richard is right, the PSK IDs do not have a defined structure.

Having two different PSKs attached to a single PSK_ID should be banned if
it isn't already.

Regards,

Jonathan

On Thu, 19 Sep 2019 at 16:26, Richard Barnes  wrote:

> On Thu, Sep 19, 2019 at 10:26 AM Jonathan Hoyland <
> jonathan.hoyl...@gmail.com> wrote:
>
>> That's how I would interpret the spec yes.
>> You could argue that there's a distinguishing attack where the attacker
>> measures the response time on PSKs to determine if it was an OOB PSK or a
>> resumption, but I think you could do equally well just by looking at the
>> PSK lengths, because resumption PSKs have a defined structure.
>>
>
> I don't think that's quite right.  The PSKs resulting from
> NewSessionTicket have a defined structure, but the PSK *IDs* do not;
> they're specified by the server.  AFAICT, existing server stacks generate
> their own PSK IDs for resumption PSKs, so from the application's
> perspective, the structure of the resumption PSKs is unknown (or at best,
> specific to the TLS library in use).
>
> If I understand correctly, the worst case here would be:
>
> 1. The server application wants to have some behavior change based on the
> use of an external PSK (not resumption)
> 2. The server TLS stack is configured with external and resumption PSKs
> with the same PSK ID
> 3. The client sends a ClientHello using the resumption PSK
> 4. The server TLS stack attempts to verify the binder with the resumption
> PSK and succeeds
> 5. The server application gets a session that is authenticated with the
> PSK ID and notes that the PSK ID matches one of its external PSKs
> 6. The server application improperly does the external PSK behavior when
> in fact resumption has happened
>
> I might be missing something, but I don't see anything in the spec that
> would prevent this situation from arising.  So it's up to the application
> to choose its PSK IDs in such a way that they don't collide with resumption
> PSK IDs.  But the fact that resumption PSK IDs are implementation-specific
> mean that this is tough to do with any generality, unless you're willing to
> rely on long pseudorandom strings not colliding with each other.
>
> Maybe the answer is just that TLS stacks that handle their own resumption
> caches need to signal to applications when that cache has been used vs. an
> external PSK.
>
> --Richard
>
>
>
>> Regards,
>>
>> Jonathan
>>
>> On Thu, 19 Sep 2019 at 15:04, Owen Friel (ofriel) 
>> wrote:
>>
>>>
>>>
>>> > -Original Message-
>>> > From: Jonathan Hoyland 
>>> > Sent: 19 September 2019 14:32
>>> > To: Owen Friel (ofriel) 
>>> > Cc: Martin Thomson ; tls@ietf.org
>>> > Subject: Re: [TLS] Distinguishing between external/resumption PSKs
>>> >
>>> > Hi Owen,
>>> >
>>> > If I understand your question correctly the distinguishing is done
>>> implicitly
>>> > (not explicitly) through the key schedule.
>>> > If the client and server do not agree on whether the PSK is a
>>> resumption or
>>> > an OOB PSK then the `binder_key` will not match, and the handshake
>>> will fail.
>>> >
>>> > See pp. 93-94 of the spec.
>>>
>>> And we only even get that far on the off chance that an ext
>>> PskIdentity.identity is exactly the same as a res PskIdentity.identity.
>>> e.g. a client presents an ext PskIdentity.identity, the server somehow
>>> thinks it’s a res PskIdentity.identity, and then handshaking will fail, not
>>> only because the actual raw PSK is likely different but the binders will
>>> not match due to different labels.
>>>
>>> But my question was before we even get that far - its an internal server
>>> implementation decision how it determines whether the presented
>>> PskIdentity.identity is ext or res, or whether e.g. to try lookup an ext DB
>>> table vs. a res cache first to find a PskIdentity.identity match. And say
>>> it fails to find an ext match then it tries to find a res match, and if it
>>> finds a match, then it knows what binder label to use.
>>>
>>>
>>> >
>>> > Does that answer your question?
>>> >
>>> > Regards,
>>> >
>>> > Jonathan
>>> >
>>> > On Thu, 19 Sep 2019 at 11:52, Owen Friel (ofriel) >> ofr...@cisco.com>
>>> > wrote:
>>> >
>>> > > -Original Message-
>>>

Re: [TLS] Distinguishing between external/resumption PSKs

[Richard Barnes]

On Thu, Sep 19, 2019 at 10:26 AM Jonathan Hoyland <
jonathan.hoyl...@gmail.com> wrote:

> That's how I would interpret the spec yes.
> You could argue that there's a distinguishing attack where the attacker
> measures the response time on PSKs to determine if it was an OOB PSK or a
> resumption, but I think you could do equally well just by looking at the
> PSK lengths, because resumption PSKs have a defined structure.
>

I don't think that's quite right.  The PSKs resulting from NewSessionTicket
have a defined structure, but the PSK *IDs* do not; they're specified by
the server.  AFAICT, existing server stacks generate their own PSK IDs for
resumption PSKs, so from the application's perspective, the structure of
the resumption PSKs is unknown (or at best, specific to the TLS library in
use).

If I understand correctly, the worst case here would be:

1. The server application wants to have some behavior change based on the
use of an external PSK (not resumption)
2. The server TLS stack is configured with external and resumption PSKs
with the same PSK ID
3. The client sends a ClientHello using the resumption PSK
4. The server TLS stack attempts to verify the binder with the resumption
PSK and succeeds
5. The server application gets a session that is authenticated with the PSK
ID and notes that the PSK ID matches one of its external PSKs
6. The server application improperly does the external PSK behavior when in
fact resumption has happened

I might be missing something, but I don't see anything in the spec that
would prevent this situation from arising.  So it's up to the application
to choose its PSK IDs in such a way that they don't collide with resumption
PSK IDs.  But the fact that resumption PSK IDs are implementation-specific
mean that this is tough to do with any generality, unless you're willing to
rely on long pseudorandom strings not colliding with each other.

Maybe the answer is just that TLS stacks that handle their own resumption
caches need to signal to applications when that cache has been used vs. an
external PSK.

--Richard



> Regards,
>
> Jonathan
>
> On Thu, 19 Sep 2019 at 15:04, Owen Friel (ofriel) 
> wrote:
>
>>
>>
>> > -Original Message-
>> > From: Jonathan Hoyland 
>> > Sent: 19 September 2019 14:32
>> > To: Owen Friel (ofriel) 
>> > Cc: Martin Thomson ; tls@ietf.org
>> > Subject: Re: [TLS] Distinguishing between external/resumption PSKs
>> >
>> > Hi Owen,
>> >
>> > If I understand your question correctly the distinguishing is done
>> implicitly
>> > (not explicitly) through the key schedule.
>> > If the client and server do not agree on whether the PSK is a
>> resumption or
>> > an OOB PSK then the `binder_key` will not match, and the handshake will
>> fail.
>> >
>> > See pp. 93-94 of the spec.
>>
>> And we only even get that far on the off chance that an ext
>> PskIdentity.identity is exactly the same as a res PskIdentity.identity.
>> e.g. a client presents an ext PskIdentity.identity, the server somehow
>> thinks it’s a res PskIdentity.identity, and then handshaking will fail, not
>> only because the actual raw PSK is likely different but the binders will
>> not match due to different labels.
>>
>> But my question was before we even get that far - its an internal server
>> implementation decision how it determines whether the presented
>> PskIdentity.identity is ext or res, or whether e.g. to try lookup an ext DB
>> table vs. a res cache first to find a PskIdentity.identity match. And say
>> it fails to find an ext match then it tries to find a res match, and if it
>> finds a match, then it knows what binder label to use.
>>
>>
>> >
>> > Does that answer your question?
>> >
>> > Regards,
>> >
>> > Jonathan
>> >
>> > On Thu, 19 Sep 2019 at 11:52, Owen Friel (ofriel) > ofr...@cisco.com>
>> > wrote:
>> >
>> > > -Original Message-
>> > > From: TLS <mailto:tls-boun...@ietf.org> On Behalf Of Martin Thomson
>> > > Sent: 04 September 2019 02:46
>> > > To: mailto:tls@ietf.org
>> > > Subject: Re: [TLS] Binder key labels for imported PSKs
>> > >
>> > >
>> > > When we built the ext/res distinction, there was a clear problem
>> > expressed.
>> > > We had the potential for both to be used by the same servers at the
>> same
>> > > time (though not for the same connection) and distinguishing between
>> > them
>> > > was important
>> >
>> > Martin, maybe I 

Re: [TLS] Distinguishing between external/resumption PSKs

[Jonathan Hoyland]

That's how I would interpret the spec yes.
You could argue that there's a distinguishing attack where the attacker
measures the response time on PSKs to determine if it was an OOB PSK or a
resumption, but I think you could do equally well just by looking at the
PSK lengths, because resumption PSKs have a defined structure.

Regards,

Jonathan

On Thu, 19 Sep 2019 at 15:04, Owen Friel (ofriel)  wrote:

>
>
> > -Original Message-
> > From: Jonathan Hoyland 
> > Sent: 19 September 2019 14:32
> > To: Owen Friel (ofriel) 
> > Cc: Martin Thomson ; tls@ietf.org
> > Subject: Re: [TLS] Distinguishing between external/resumption PSKs
> >
> > Hi Owen,
> >
> > If I understand your question correctly the distinguishing is done
> implicitly
> > (not explicitly) through the key schedule.
> > If the client and server do not agree on whether the PSK is a resumption
> or
> > an OOB PSK then the `binder_key` will not match, and the handshake will
> fail.
> >
> > See pp. 93-94 of the spec.
>
> And we only even get that far on the off chance that an ext
> PskIdentity.identity is exactly the same as a res PskIdentity.identity.
> e.g. a client presents an ext PskIdentity.identity, the server somehow
> thinks it’s a res PskIdentity.identity, and then handshaking will fail, not
> only because the actual raw PSK is likely different but the binders will
> not match due to different labels.
>
> But my question was before we even get that far - its an internal server
> implementation decision how it determines whether the presented
> PskIdentity.identity is ext or res, or whether e.g. to try lookup an ext DB
> table vs. a res cache first to find a PskIdentity.identity match. And say
> it fails to find an ext match then it tries to find a res match, and if it
> finds a match, then it knows what binder label to use.
>
>
> >
> > Does that answer your question?
> >
> > Regards,
> >
> > Jonathan
> >
> > On Thu, 19 Sep 2019 at 11:52, Owen Friel (ofriel)  ofr...@cisco.com>
> > wrote:
> >
> > > -Original Message-
> > > From: TLS <mailto:tls-boun...@ietf.org> On Behalf Of Martin Thomson
> > > Sent: 04 September 2019 02:46
> > > To: mailto:tls@ietf.org
> > > Subject: Re: [TLS] Binder key labels for imported PSKs
> > >
> > >
> > > When we built the ext/res distinction, there was a clear problem
> > expressed.
> > > We had the potential for both to be used by the same servers at the
> same
> > > time (though not for the same connection) and distinguishing between
> > them
> > > was important
> >
> > Martin, maybe I am missing something in the threads on this. Is there
> > anything explicit planned in ClientHello PreSharedKeyExtension or
> > PskKeyExchangeModes to explicitly distinguish between ext/res PSKs? Or is
> > it up to server implementation and how the server handles the opaque
> > PskIdentity.identity? e.g. ImportedIdentity.external_identity fields
> could be
> > stored in one DB table, and (ignoring
> https://tools.ietf.org/html/draft-ietf-
> > tls-external-psk-importer-00#section-9 for now) the server on receipt of
> a
> > ClientHello searches for PskIdentity.identity in its
> > ImportedIdentity.external_identity  table and if that lookup fails, then
> try to
> > parse PskIdentity.identity  as a NewSessionTicket.ticket? And the order
> of
> > those two operations is of course implementation specific too.
> >
> >
> > ___
> > TLS mailing list
> > mailto: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] Distinguishing between external/resumption PSKs

[Owen Friel (ofriel)]

> -Original Message-
> From: Jonathan Hoyland 
> Sent: 19 September 2019 14:32
> To: Owen Friel (ofriel) 
> Cc: Martin Thomson ; tls@ietf.org
> Subject: Re: [TLS] Distinguishing between external/resumption PSKs
> 
> Hi Owen,
> 
> If I understand your question correctly the distinguishing is done implicitly
> (not explicitly) through the key schedule.
> If the client and server do not agree on whether the PSK is a resumption or
> an OOB PSK then the `binder_key` will not match, and the handshake will fail.
> 
> See pp. 93-94 of the spec.

And we only even get that far on the off chance that an ext 
PskIdentity.identity is exactly the same as a res PskIdentity.identity. e.g. a 
client presents an ext PskIdentity.identity, the server somehow thinks it’s a 
res PskIdentity.identity, and then handshaking will fail, not only because the 
actual raw PSK is likely different but the binders will not match due to 
different labels.

But my question was before we even get that far - its an internal server 
implementation decision how it determines whether the presented 
PskIdentity.identity is ext or res, or whether e.g. to try lookup an ext DB 
table vs. a res cache first to find a PskIdentity.identity match. And say it 
fails to find an ext match then it tries to find a res match, and if it finds a 
match, then it knows what binder label to use.


> 
> Does that answer your question?
> 
> Regards,
> 
> Jonathan
> 
> On Thu, 19 Sep 2019 at 11:52, Owen Friel (ofriel) <mailto:ofr...@cisco.com>
> wrote:
> 
> > -Original Message-
> > From: TLS <mailto:tls-boun...@ietf.org> On Behalf Of Martin Thomson
> > Sent: 04 September 2019 02:46
> > To: mailto:tls@ietf.org
> > Subject: Re: [TLS] Binder key labels for imported PSKs
> >
> >
> > When we built the ext/res distinction, there was a clear problem
> expressed.
> > We had the potential for both to be used by the same servers at the same
> > time (though not for the same connection) and distinguishing between
> them
> > was important
> 
> Martin, maybe I am missing something in the threads on this. Is there
> anything explicit planned in ClientHello PreSharedKeyExtension or
> PskKeyExchangeModes to explicitly distinguish between ext/res PSKs? Or is
> it up to server implementation and how the server handles the opaque
> PskIdentity.identity? e.g. ImportedIdentity.external_identity fields could be
> stored in one DB table, and (ignoring https://tools.ietf.org/html/draft-ietf-
> tls-external-psk-importer-00#section-9 for now) the server on receipt of a
> ClientHello searches for PskIdentity.identity in its
> ImportedIdentity.external_identity  table and if that lookup fails, then try 
> to
> parse PskIdentity.identity  as a NewSessionTicket.ticket? And the order of
> those two operations is of course implementation specific too.
> 
> 
> ___
> TLS mailing list
> mailto: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] Distinguishing between external/resumption PSKs

[Jonathan Hoyland]

Hi Owen,

If I understand your question correctly the distinguishing is done
implicitly (not explicitly) through the key schedule.
If the client and server do not agree on whether the PSK is a resumption or
an OOB PSK then the `binder_key` will not match, and the handshake will
fail.

See pp. 93-94 of the spec.

Does that answer your question?

Regards,

Jonathan

On Thu, 19 Sep 2019 at 11:52, Owen Friel (ofriel)  wrote:

>
> > -Original Message-
> > From: TLS  On Behalf Of Martin Thomson
> > Sent: 04 September 2019 02:46
> > To: tls@ietf.org
> > Subject: Re: [TLS] Binder key labels for imported PSKs
> >
> >
> > When we built the ext/res distinction, there was a clear problem
> expressed.
> > We had the potential for both to be used by the same servers at the same
> > time (though not for the same connection) and distinguishing between them
> > was important
>
> Martin, maybe I am missing something in the threads on this. Is there
> anything explicit planned in ClientHello PreSharedKeyExtension or
> PskKeyExchangeModes to explicitly distinguish between ext/res PSKs? Or is
> it up to server implementation and how the server handles the opaque
> PskIdentity.identity? e.g. ImportedIdentity.external_identity fields could
> be stored in one DB table, and (ignoring
> https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-00#section-9
> for now) the server on receipt of a ClientHello searches for
> PskIdentity.identity in its ImportedIdentity.external_identity  table and
> if that lookup fails, then try to parse PskIdentity.identity  as a
> NewSessionTicket.ticket? And the order of those two operations is of course
> implementation specific too.
>
>
> ___
> 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] Distinguishing between external/resumption PSKs

[Owen Friel (ofriel)]

> -Original Message-
> From: TLS  On Behalf Of Martin Thomson
> Sent: 04 September 2019 02:46
> To: tls@ietf.org
> Subject: Re: [TLS] Binder key labels for imported PSKs
> 
> 
> When we built the ext/res distinction, there was a clear problem expressed.
> We had the potential for both to be used by the same servers at the same
> time (though not for the same connection) and distinguishing between them
> was important

Martin, maybe I am missing something in the threads on this. Is there anything 
explicit planned in ClientHello PreSharedKeyExtension or PskKeyExchangeModes to 
explicitly distinguish between ext/res PSKs? Or is it up to server 
implementation and how the server handles the opaque PskIdentity.identity? e.g. 
ImportedIdentity.external_identity fields could be stored in one DB table, and 
(ignoring 
https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-00#section-9 
for now) the server on receipt of a ClientHello searches for 
PskIdentity.identity in its ImportedIdentity.external_identity  table and if 
that lookup fails, then try to parse PskIdentity.identity  as a 
NewSessionTicket.ticket? And the order of those two operations is of course 
implementation specific too.
 

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