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

[David Benjamin <[e-mail]>]

On Fri, Feb 28, 2020 at 10:58 AM Jonathan Hoyland <
[e-mail]> wrote:

> On Fri, 28 Feb 2020 at 04:49, Christopher Wood <[e-mail]>
> wrote:
>
>> On Thu, Feb 27, 2020, at 1:31 PM, David Benjamin wrote:
>> > On Mon, Feb 24, 2020 at 5:58 PM Jonathan Hoyland
>> > <[e-mail]> 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.
>> > >
>> > > * 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.
>>
> 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 ...
>

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. :-)


> > > 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.
>> >
>> > Chris is probably more up-to-date here, but I don't believe the current
>> > ECHO design looks like a funny PSK.
>>
>> That's right -- it's just another extension in the outer CH.
>>
>
> 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 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.
>> >
>> > Of course. Yeah, I think the more pertinent question is whether "imp r
>> > binder" is actually a thing.
>> > > Regards,
>> > >
>> > > Jonathan
>> > >
>> > > On Mon, 24 Feb 2020, 22:23 David Benjamin, <[e-mail]>
>> wrote:
>> > >> On Mon, Feb 24, 2020 at 4:33 PM Jonathan Hoyland <
>> [e-mail]> wrote:
>> > >>> 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.
>> > >>
>> > >> 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
>> > >>> On Mon, 24 Feb 2020 at 20:50, Christopher Wood <[e-mail]>
>> wrote:
>> > >>>> On Fri, Feb 21, 2020, at 1:15 PM, Rob Sayre wrote:
>> > >>>>  >
>> > >>>>  >
>> > >>>>  > On Fri, Feb 21, 2020 at 8:35 AM Eric Rescorla <[e-mail]>
>> wrote:
>> > >>>>  > >
>> > >>>>  > >
>> > >>>>  > > On Thu, Feb 20, 2020 at 7:08 PM Rob Sayre <[e-mail]>
>> wrote:
>> > >>>>  > >> 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.
>> > >>>>  > >
>> > >>>>  > > 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).
>> > >>>>  >
>> > >>>>  > 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
>> > >>>>
>> > >>>>  _______________________________________________
>> > >>>>  TLS mailing list
>> > >>>> [e-mail]
>> > >>>> https://www.ietf.org/mailman/listinfo/tls
>> > >>>  _______________________________________________
>> > >>>  TLS mailing list
>> > >>> [e-mail]
>> > >>> https://www.ietf.org/mailman/listinfo/tls
>>
>