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