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
