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

From: Alexey Melnikov <[email-masked]>
Date: Mon, 24 May 2021 16:38:03 +0100

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" <[email-masked]> 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?

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
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/kitten

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 24 May 2021 18:46:30 +0200

Alexey Melnikov <[email-masked]> writes:

> 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

---

From: "Sam Whited" <[email-masked]>
Date: Tue, 25 May 2021 13:35:42 -0400

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

—Sam

On Mon, May 24, 2021, at 12:46, Simon Josefsson wrote:
> >>> 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.
> >> 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?
>
>    The derived data MUST NOT be used for any other purpose than
>    channel bindings as described in [RFC5056].
>
> /Simon
>
> >
> > Best Regards,
> >
> > Alexey
> >
> >> /Simon
> >>
> >>>> 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 [email-masked]
> > Kitten mailing list [email-masked]
> Attachments:
> * signature.asc

-- 
Sam Whited

---

From: Ludovic BOCQUET <[email-masked]>
Date: Tue, 25 May 2021 18:37:33 +0000

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 <[email-masked]> on behalf of Simon Josefsson <simon=[email-masked]>
Sent: Monday, May 24, 2021 4:46 PM
To: Alexey Melnikov <[email-masked]>
Cc: KITTEN Working Group <[email-masked]>
Subject: Re: [kitten] SCRAM and draft-ietf-kitten-tls-channel-bindings-for-tls13

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 25 May 2021 23:52:56 +0200

> thank you. I'll upload a new version shortly.

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

/Simon

---

From: "Sam Whited" <[email-masked]>
Date: Wed, 26 May 2021 08:46:16 -0400

Done.