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