Re: [kitten] SCRAM and draft-ietf-kitten-tls-channel-bindings-for-tls13

[Simon Josefsson <[e-mail]>]

"Sam Whited" <[e-mail]> writes:

> Done (defaults, the "updates" field, and the security considerations);
> thank you. I'll upload a new version shortly.

Thank you!  It should update RFC 5801 (GS2) as well.

/Simon

> —Sam
>
> On Mon, May 24, 2021, at 12:46, Simon Josefsson wrote:
>> Alexey Melnikov <[e-mail]> writes:
>>
>> > Hi Simon/Sam,
>> >
>> > Picking up an old thread that you had in March 2021:
>> >
>> > On 27/03/2021 19:08, Simon Josefsson wrote:
>> >> "Sam Whited" <[e-mail]> writes:
>> >>
>> >>> I don't really know what "Updates" means in this context, so I
>> >>> just put an RFC that uses tls-unique. The point wasn't so much
>> >>> that it changes any normative text, but that this document should
>> >>> be discoverable from 5802 so that if you read "tls-unique" then go
>> >>> up to the top and see "Updated by <new TLS 1.3 unique CB RFC>" you
>> >>> have a chance at finding and implementing this instead.
>> >> That makes sense, but to me it isn't clear how I would actually
>> >> implement SCRAM (or GS2) when your draft is approved.  Are you
>> >> suggesting to replace tls-unique with something else?  There seems
>> >> to be some guidance missing.  There is backwards compatibility
>> >> concerns with changing the default channel binding.
>> >
>> > After thinking about this with my implementor's hat on, I agree.
>> > This new requirement can be either in SCRAM update (if we ever do
>> > one) or this document. Adding it to this document seems quicker (and
>> > also the right thing) to me. Maybe as a strawman proposal:
>> >
>> > When a client/server implementation supports TLS 1.3 and SCRAM-*-
>> > PLUS, require support for "tls-exporter". Leave "tls-unique" as mandatory-to-
>> > implement for older versions of TLS.
>> >
>> > What do you think?
>>
>> I think this is reasonable.  TLS 1.3 does not support tls-unique, so
>> SCRAM-PLUS under TLS 1.3 is not well specified today.
>>
>> I believe the document should have a 'Updates: RFC 5929' too.
>>
>> Another thing that could be lifted from
>> https://datatracker.ietf.org/doc/html/draft-josefsson-sasl-tls-cb-02
>> would to add the following to the Security Considerations:
>>
>>    The derived data MUST NOT be used for any other purpose than
>>    channel bindings as described in [RFC5056].
>>
>> /Simon
>>
>> >
>> > Best Regards,
>> >
>> > Alexey
>> >
>> >> /Simon
>> >>
>> >>> On Thu, Mar 25, 2021, at 05:41, Simon Josefsson wrote:
>> >>>> Thanks for draft-ietf-kitten-tls-channel-bindings-for-tls13!  It
>> >>>> is not clear to me that it would actually modify anything for
>> >>>> SCRAM/GS2, would it?  Those documents still reference 'tls-uniqe'
>> >>>> and things will still be broken, as far as I can tell.  Should
>> >>>> the new draft update the SCRAM/GS2 specs?  I believe the channel
>> >>>> binding flexibility in SCRAM/GS2 has been one complexity that has
>> >>>> prevented adoption, but solving that may be too late but we may
>> >>>> be able to solve the security issues.  I see that there is an
>> >>>> 'Updates: 5802' but I can't find any text describing what is
>> >>>> intendted to be changed.
>> >>>>
>> >>>> _______________________________________________
>> >>>> Kitten mailing list [e-mail]
>> >>>> https://www.ietf.org/mailman/listinfo/kitten
>> > _______________________________________________
>> > Kitten mailing list [e-mail]
>> > https://www.ietf.org/mailman/listinfo/kitten
>> >
>>
>> Attachments:
>> * signature.asc