Subject: [TLS] WGLC for draft-ietf-tls-external-psk-importer

From: Joseph Salowey <[email-masked]>
Date: Thu, 20 Feb 2020 16:45:19 -0800

Hi Folks,

This is the working group last call for the "Importing External PSKs" draft
available at
https://datatracker.ietf.org/doc/draft-ietf-tls-external-psk-importer/.
Please review the document and send your comments to the list by 2359 UTC
on 6 March 2020.

Note the the GH repo for this draft can be found at:
https://github.com/tlswg/draft-ietf-tls-external-psk-importer

Thanks,

Sean and Joe

---

From: Rob Sayre <[email-masked]>
Date: Thu, 20 Feb 2020 19:08:17 -0800

Hi,

I'm not sure how violations of these requirements would result in
poor interoperability:

   Clients which import external keys TLS MUST NOT use these keys for
   any other purpose.  Moreover, each external PSK MUST be associated
   with at most one hash function.

These seem like aspirational security goals. It would be better to describe
the consequences of violating these conditions.

thanks,
Rob

On Thu, Feb 20, 2020 at 4:45 PM Joseph Salowey <[email-masked]> wrote:

> Hi Folks,
>
> This is the working group last call for the "Importing External PSKs"
> draft available at
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 21 Feb 2020 08:34:23 -0800

On Thu, Feb 20, 2020 at 7:08 PM Rob Sayre <[email-masked]> wrote:

> These seem like aspirational security goals. It would be better to
> describe the consequences of violating these conditions.
>

I don't agree. They are requirements in order to be able to make the
assertions we want to make about the security of the protocol.

This is consistent with the following text of RFC 2119 S 6
".. or to limit behavior which has potential for causing harm (e.g.,
limiting retransmisssions) "

I don't think it would be unreasonable.to explain the reason for these,
though this is already a requirement of 8446 S 4.2.11 (though without
justification).

-Ekr

---

From: Rob Sayre <[email-masked]>
Date: Fri, 21 Feb 2020 13:15:50 -0800

> though this is already a requirement of 8446 S 4.2.11 (though without

I think that interpretation of 2119 is a stretch, but your idea to add an
explanation while keeping the 2119 terms addresses my concern. At the very
least, the draft should note this is already a requirement of 8446.

thanks,
Rob

---

From: "Christopher Wood" <[email-masked]>
Date: Mon, 24 Feb 2020 12:50:15 -0800

On Fri, Feb 21, 2020, at 1:15 PM, Rob Sayre wrote:
> >> I'm not sure how violations of these requirements would result in poor interoperability:
> >> 
> >> These seem like aspirational security goals. It would be better to describe the consequences of violating these conditions.
> > 
> > I don't agree. They are requirements in order to be able to make the assertions we want to make about the security of the protocol.
> > 
> > ".. or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) "
> > 
> > I don't think it would be unreasonable.to explain the reason for these, though this is already a requirement of 8446 S 4.2.11 (though without justification).
> 
> I think that interpretation of 2119 is a stretch, but your idea to add 
> an explanation while keeping the 2119 terms addresses my concern. At 
> the very least, the draft should note this is already a requirement of 
> 8446.

That seems perfectly reasonable! We can point to the security considerations to clarify the "single hash function" requirement, and we can note cross protocol attack deterrence for the other claim. Would that suffice? If not, can you please recommend text?

Thanks,
Chris

---

From: Jonathan Hoyland <[email-masked]>
Date: Mon, 24 Feb 2020 21:33:32 +0000

Just looking at this again, it might be better to make a slightly different
tweak to the key schedule.
Instead of:

                0
                |
                v
      PSK ->  HKDF-Extract = Early Secret
                |
                +-----> Derive-Secret(., "ext binder"
                |                      | "res binder"
                |                      | "imp binder", "")
                |                     = binder_key

                v

We should do:

                0
                |
                v
      PSK ->  HKDF-Extract = Early Secret
                |
                +-----> Derive-Secret(., "ext binder"
                |                      | "res binder"
                |                      | "imp e binder"

                |                      | "imp r binder", "")
                |                     = binder_key

                v

or at least:

                0
                |
                v
      PSK ->  HKDF-Extract = Early Secret
                |
                +-----> Derive-Secret(., "ext binder"
                |                      | "res binder"
                |                      | "imp e binder", "")
                |                     = binder_key

                v

Just so that we can distinguish between external imported binders and
resumed imported binders, should we at some point decide to do both.

Regards,

Jonathan

On Mon, 24 Feb 2020 at 20:50, Christopher Wood <[email-masked]> wrote:

> > > I don't think it would be unreasonable.to explain the reason for
> these, though this is already a requirement of 8446 S 4.2.11 (though
> without justification).
> >
> That seems perfectly reasonable! We can point to the security
> considerations to clarify the "single hash function" requirement, and we
> can note cross protocol attack deterrence for the other claim. Would that
> suffice? If not, can you please recommend text?
>
> Thanks,
> Chris
>

---

From: David Benjamin <[email-masked]>
Date: Mon, 24 Feb 2020 17:23:26 -0500

On Mon, Feb 24, 2020 at 4:33 PM Jonathan Hoyland <[email-masked]>
wrote:

> Just looking at this again, it might be better to make a slightly
> different tweak to the key schedule.
> Instead of:
>
>                 0
>                 |
>                 v

I may just be confused, but what would a resumed imported binder mean? I
see this mechanism as largely a bugfix for TLS 1.3 external PSKs, rather
than a new kind of adjective describing PSKs.

("imp binder" also doesn't preclude "imp r binder" later if we later define
something which needs it, but I'm confused what the concept even would be.)

David

---

From: Rob Sayre <[email-masked]>
Date: Mon, 24 Feb 2020 14:27:05 -0800

> suffice? If not, can you please recommend text?

That sounds fine. If I have nits with what's written, I'll suggest text.

thanks,
Rob

---

From: Jonathan Hoyland <[email-masked]>
Date: Mon, 24 Feb 2020 22:57:50 +0000

This would be for cases where we want to inject extra context into a
resumption.
That would be anything that changes an authentication property, so
for example if you wanted to include some agreement on the status of a
post-handshake auth or Exported Authenticator.

So for example imagine I had a session during which I received an EA and
when I came to resume that session I wished to indicate that I was still
willing to accept the EA.
I would offer a special PSK and inject some extra material into the
handshake*, and if the server was able / willing to agree to this it would
select the PSK.
I could also offer a PSK with no extra injected material, as a fallback,
and request the EA again.

* This would only affect the binder for the PSK in the ClientHello.

Another potential use would be the binding for ECHO, although I don't have
a clear enough picture of the precise mechanics of that to know if it would
be helpful.

Something that would allow for a consistent naming in the future would be
my preference, because just as "imp binder" doesn't preclude "imp r
binder", using "imp e binder" doesn't preclude us never adopting "imp r
binder".
I vaguely remember discussing whether the longer name would tip us into an
extra hash invocation at the last IETF,  and concluding that it didn't,
although I'd have to double check that.

Regards,

Jonathan

On Mon, 24 Feb 2020, 22:23 David Benjamin, <[email-masked]> wrote:

> On Mon, Feb 24, 2020 at 4:33 PM Jonathan Hoyland <
> [email-masked]> wrote:
>
> ("imp binder" also doesn't preclude "imp r binder" later if we later
> define something which needs it, but I'm confused what the concept even
> would be.)
>
> David
>
>

---

From: David Benjamin <[email-masked]>
Date: Thu, 27 Feb 2020 16:31:40 -0500

> * This would only affect the binder for the PSK in the ClientHello.

I'm still not following. If you're resuming, this is a PSK issued from a
NewSessionTicket, in which case this isn't an imported PSK at all. It's a
resumption PSK and uses "res binder". If we needed to negotiate variations
on a resumption, this importer mechanism wouldn't give us a way to express
that anyway. I expect we'd instead lean on some combination of multiple
tickets, NewSessionTicket extensions, and plain ClientHello extensions. But
maybe I'm still not understanding the scenario.

> a clear enough picture of the precise mechanics of that to know if it would

Chris is probably more up-to-date here, but I don't believe the current
ECHO design looks like a funny PSK.

> although I'd have to double check that.

Of course. Yeah, I think the more pertinent question is whether "imp r
binder" is actually a thing.

>>>> > > I don't agree. They are requirements in order to be able to make
>>>> the assertions we want to make about the security of the protocol.
>>>> > >

---

From: "Christopher Wood" <[email-masked]>
Date: Thu, 27 Feb 2020 20:49:23 -0800

On Thu, Feb 27, 2020, at 1:31 PM, David Benjamin wrote:
> On Mon, Feb 24, 2020 at 5:58 PM Jonathan Hoyland 
> <[email-masked]> wrote:
> > This would be for cases where we want to inject extra context into a resumption. 
> > That would be anything that changes an authentication property, so for example if you wanted to include some agreement on the status of a post-handshake auth or Exported Authenticator.
> > 
> > So for example imagine I had a session during which I received an EA and when I came to resume that session I wished to indicate that I was still willing to accept the EA.
> > I would offer a special PSK and inject some extra material into the handshake*, and if the server was able / willing to agree to this it would select the PSK. 
> > I could also offer a PSK with no extra injected material, as a fallback, and request the EA again. 
> > 
> I'm still not following. If you're resuming, this is a PSK issued from 
> a NewSessionTicket, in which case this isn't an imported PSK at all. 
> It's a resumption PSK and uses "res binder". If we needed to negotiate 
> variations on a resumption, this importer mechanism wouldn't give us a 
> way to express that anyway. I expect we'd instead lean on some 
> combination of multiple tickets, NewSessionTicket extensions, and plain 
> ClientHello extensions. But maybe I'm still not understanding the 
> scenario.
> > Another potential use would be the binding for ECHO, although I don't have a clear enough picture of the precise mechanics of that to know if it would be helpful.
> 

That's right -- it's just another extension in the outer CH. 

Best,
Chriss

> > Something that would allow for a consistent naming in the future would be my preference, because just as "imp binder" doesn't preclude "imp r binder", using "imp e binder" doesn't preclude us never adopting "imp r binder".
> > I vaguely remember discussing whether the longer name would tip us into an extra hash invocation at the last IETF, and concluding that it didn't, although I'd have to double check that. 
> 
> >> On Mon, Feb 24, 2020 at 4:33 PM Jonathan Hoyland <[email-masked]> wrote:
> >>> Just looking at this again, it might be better to make a slightly different tweak to the key schedule.
> >>> Instead of:
> >>>                 0
>                 |
>                 v
>                 |                     = binder_key                v
>                 |                     = binder_key                v
>                 |                     = binder_key                v
> >>> Just so that we can distinguish between external imported binders and resumed imported binders, should we at some point decide to do both. 
> >> 
> >> I may just be confused, but what would a resumed imported binder mean? I see this mechanism as largely a bugfix for TLS 1.3 external PSKs, rather than a new kind of adjective describing PSKs.
> >> 
> >> ("imp binder" also doesn't preclude "imp r binder" later if we later define something which needs it, but I'm confused what the concept even would be.)
> >> 
> >> David

---

From: Jonathan Hoyland <[email-masked]>
Date: Fri, 28 Feb 2020 15:58:15 +0000

On Fri, 28 Feb 2020 at 04:49, Christopher Wood <[email-masked]> wrote:

> > > That would be anything that changes an authentication property, so for
> example if you wanted to include some agreement on the status of a
> > > So for example imagine I had a session during which I received an EA
> and when I came to resume that session I wished to indicate that I was
> still willing to accept the EA.
The security of combinations of tickets is non-trivial to reason about
(though not impossible), in the same way as Exported Authenticators (which
makes sense given that EAs would be a reason to do this).
I'll have to give some thought to a compelling use case, but I just like
the option for consistency.
Then again it is said "A foolish consistency is the hobgoblin of little
minds [...]", so ...

> > > Another potential use would be the binding for ECHO, although I don't
> have a clear enough picture of the precise mechanics of that to know if it
> would be helpful.
> >

I was thinking about the ECHO design from a forward/backward binding
perspective.
I think we should make the smallest number of changes to the key schedule
possible that will cover all possible future use cases, so an overall
consistent approach would be ideal.
If the WG doesn't adopt a key schedule extension draft (either mine,
draft-Stebila, or some other one) then this looks like the strongest choice.

> Best,
> Chriss
>
> > > Something that would allow for a consistent naming in the future would
> be my preference, because just as "imp binder" doesn't preclude "imp r
> > > I vaguely remember discussing whether the longer name would tip us
> into an extra hash invocation at the last IETF, and concluding that it
> didn't, although I'd have to double check that.
> >
> > >>> Just so that we can distinguish between external imported binders
> and resumed imported binders, should we at some point decide to do both.
> > >>
> > >> I may just be confused, but what would a resumed imported binder
> mean? I see this mechanism as largely a bugfix for TLS 1.3 external PSKs,
> rather than a new kind of adjective describing PSKs.
> > >>
> > >>>>  > >> These seem like aspirational security goals. It would be
> better to describe the consequences of violating these conditions.
> > >>>>  > >
> > >>>>  > > I don't agree. They are requirements in order to be able to
> make the assertions we want to make about the security of the protocol.
> > >>>>  > >
> > >>>>  > > I don't think it would be unreasonable.to explain the reason
> for these, though this is already a requirement of 8446 S 4.2.11 (though
> without justification).
> > >>>>  >

---

From: "Christopher Wood" <[email-masked]>
Date: Fri, 28 Feb 2020 08:02:54 -0800

On Fri, Feb 28, 2020, at 7:58 AM, Jonathan Hoyland wrote:
> (though not impossible), in the same way as Exported Authenticators 
> (which makes sense given that EAs would be a reason to do this).
> I'll have to give some thought to a compelling use case, but I just 
> like the option for consistency. 
> I think we should make the smallest number of changes to the key 
> schedule possible that will cover all possible future use cases, so an 
> overall consistent approach would be ideal. 

The ECHO design presented in Singapore doesn't require any key schedule modification. It tunnels an entire encrypted CH inside an outer CH. Servers pick one and use that for the remainder of the handshake.

I'm inclined to agree with David on this one. I don't think this additional label is necessary.

Best,
Chris

---

From: David Benjamin <[email-masked]>
Date: Fri, 28 Feb 2020 11:09:09 -0500

> Then again it is said "A foolish consistency is the hobgoblin of little

Well, if we never end up adding "imp r binder", then the current spelling
is more consistent. If we later add "imp r binder", then your proposed
spelling is more consistent. If we later add "imp r binder" but spell it
"xyz binder", then I guess the current spelling is more consistent.

The label values don't *actually* matter so this is all aesthetics at this
point. My assertion is that if we have clear reason to believe we'll add
"imp r binder", then "imp e binder" seems reasonable. If we don't have a
reason to believe we will, let's just leave it as is. Either way, it's
probably not worth expending too much effort on it. :-)

>> > > Something that would allow for a consistent naming in the future
>> would be my preference, because just as "imp binder" doesn't preclude "imp
>> r binder", using "imp e binder" doesn't preclude us never adopting "imp r
>> binder".