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

[Sam Whited <[e-mail]>]

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


-- 
Sam Whited