On Fri, Feb 28, 2020, at 7:58 AM, Jonathan Hoyland 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 ...
> > > > 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.
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
>
> >
> > 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
