On Fri, Feb 28, 2020 at 10:58 AM Jonathan Hoyland <
jonathan.hoyl...@gmail.com> wrote:
> On Fri, 28 Feb 2020 at 04:49, Christopher Wood <c...@heapingbits.net>
> wrote:
>
>> On Thu, Feb 27, 2020, at 1:31 PM, David Benjamin wrote:
>> > On Mon, Feb 24, 2020 at 5:58 PM Jonathan Hoyland
>> > <jonathan.hoyl...@gmail.com> 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, <david...@chromium.org>
>> wrote:
>> > >> On Mon, Feb 24, 2020 at 4:33 PM Jonathan Hoyland <
>> jonathan.hoyl...@gmail.com> 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 <c...@heapingbits.net>
>> 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...@rtfm.com>
>> wrote:
>> > >>>> > >
>> > >>>> > >
>> > >>>> > > On Thu, Feb 20, 2020 at 7:08 PM Rob Sayre <say...@gmail.com>
>> 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
>> > >>>> TLS@ietf.org
>> > >>>> https://www.ietf.org/mailman/listinfo/tls
>> > >>> _______________________________________________
>> > >>> TLS mailing list
>> > >>> TLS@ietf.org
>> > >>> https://www.ietf.org/mailman/listinfo/tls
>>
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
