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

Thanks Simon to confirm my remark about "RFC5929" that I have said here:

  *   https://mailarchive.ietf.org/arch/msg/kitten/sN0K0gROlztsQhHwoz2Ydxp4EFg/

Can you look my other points too?

Thanks in advance.

Regards,

BOCQUET Ludovic

________________________________
From: Kitten <kitten-bounces@ietf.org> on behalf of Simon Josefsson <simon=40josefsson.org@dmarc.ietf.org>
Sent: Monday, May 24, 2021 4:46 PM
To: Alexey Melnikov <alexey.melnikov@isode.com>
Cc: KITTEN Working Group <kitten@ietf.org>
Subject: Re: [kitten] SCRAM and draft-ietf-kitten-tls-channel-bindings-for-tls13

Alexey Melnikov <alexey.melnikov@isode.com> 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" <sam@samwhited.com> 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
>>>> Kitten@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/kitten
> _______________________________________________
> Kitten mailing list
> Kitten@ietf.org
> https://www.ietf.org/mailman/listinfo/kitten
>