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

Alexey Melnikov <alexey.melnikov@isode.com> Mon, 24 May 2021 15:38 UTC

Return-Path: <alexey.melnikov@isode.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8643A2CB3 for <kitten@ietfa.amsl.com>; Mon, 24 May 2021 08:38:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9qmCfSYxi-E for <kitten@ietfa.amsl.com>; Mon, 24 May 2021 08:38:07 -0700 (PDT)
Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id BBC853A2CB2 for <kitten@ietf.org>; Mon, 24 May 2021 08:38:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1621870686; d=isode.com; s=june2016; i=@isode.com; bh=vniDpSIec4FyhBZRQOAAp8SvMcw3qcUlJoR6JwUX3sQ=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=QygooZ/hB/JgYOlJLA+0eLtB96ze+LTCQjydX1BSwWlh1pm9vsDjhP7XSIGKjEWVwbiPWw gjn9XcniqQaoDyJnLxS3FXi8qzSDa5b4JchKp5VUuxpeBRLPt65HY3yEP4x5FQJ2OkEhYo dQ1bJ4/ysskSTeldeLryDH57ZnS1gbk=;
Received: from [192.168.1.222] (host31-49-142-38.range31-49.btcentralplus.com [31.49.142.38]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id <YKvIXAAX7k2R@waldorf.isode.com>; Mon, 24 May 2021 16:38:06 +0100
To: Simon Josefsson <simon=40josefsson.org@dmarc.ietf.org>, Sam Whited <sam@samwhited.com>
Cc: KITTEN Working Group <kitten@ietf.org>
References: <874kgztvs4.fsf@latte.josefsson.org> <313a79cb-b58e-4098-b79e-2030c4e77c15@www.fastmail.com> <87v99cs9cb.fsf@latte.josefsson.org>
From: Alexey Melnikov <alexey.melnikov@isode.com>
Message-ID: <d0100358-5870-5ca0-6b8f-9f3c94edce25@isode.com>
Date: Mon, 24 May 2021 16:38:03 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
In-Reply-To: <87v99cs9cb.fsf@latte.josefsson.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------C589F46C2479DA2660851899"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/g1ya8IdfcDj_BOysJb5IjHi4dOA>
Subject: Re: [kitten] SCRAM and draft-ietf-kitten-tls-channel-bindings-for-tls13
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 May 2021 15:38:12 -0000

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?

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