Re: [TLS] TLS Export Channel Binding

Alexey Melnikov <alexey.melnikov@isode.com> Mon, 04 May 2020 15:25 UTC

Return-Path: <alexey.melnikov@isode.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35AF13A0A56 for <tls@ietfa.amsl.com>; Mon, 4 May 2020 08:25:45 -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, 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 NZztSC_vin6B for <tls@ietfa.amsl.com>; Mon, 4 May 2020 08:25:44 -0700 (PDT)
Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id D18D73A0A4D for <tls@ietf.org>; Mon, 4 May 2020 08:25:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1588605943; d=isode.com; s=june2016; i=@isode.com; bh=pTRXIEyV17puH2Wu4bVVMNiVZkp+I/9iI95rSpbq8YQ=; 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=L2CRd/MVa+N8mOc/NlM0KpHT2sdaVoG/d02BvVBbbvsM2sUHhQbBKd51RT0kHxFc447y6o 9loN3sO67CBQ74dJUL4JQxkXnbi85V0CVgNa1NB5apHINZ1U9imLSqC29VChpM2WlVqQpP f1TEU8d4fonDg6ExBzBLKKP9ZeFY9NI=;
Received: from [172.27.249.197] (connect.isode.net [172.20.0.72]) by statler.isode.com (submission channel) via TCP with ESMTPSA id <XrAz9gAhH7SQ@statler.isode.com>; Mon, 4 May 2020 16:25:43 +0100
To: Sam Whited <sam@samwhited.com>, Jonathan Hoyland <jonathan.hoyland@gmail.com>
Cc: tls@ietf.org
References: <0f20d1f6-56c1-4e01-813f-f8b3c57a5c9b@www.fastmail.com> <CACykbs3WDk7a0+0vCSDfCuib1Bex8SUJ-kvtZhjchvvm+5xc0g@mail.gmail.com> <13c2ff5e-f68e-45b5-bd64-085b9bdaf17e@www.fastmail.com> <CACykbs3+G8DCwC3ZrCbmzoygGkz6nRoYWHVxKWw3BvJ8YwAv7Q@mail.gmail.com> <ba8c1b17-6032-4420-8ead-a70c529721aa@www.fastmail.com> <CACykbs1Cz4aG1WaXpBeNmpdR90b2x-cGsrpnm=MXgFJiif0K2A@mail.gmail.com> <2621a35e-1731-44d2-9afc-ebdd2b51e2ea@www.fastmail.com>
From: Alexey Melnikov <alexey.melnikov@isode.com>
Message-ID: <5f0c2905-ca45-ed88-a12d-76d73b416dac@isode.com>
Date: Mon, 04 May 2020 16:25:10 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
In-Reply-To: <2621a35e-1731-44d2-9afc-ebdd2b51e2ea@www.fastmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/TXLI7r_3iqMoo5iwKb_yBo4ZJCM>
Subject: Re: [TLS] TLS Export Channel Binding
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 May 2020 15:25:45 -0000

Hi Sam,

On 04/05/2020 15:39, Sam Whited wrote:
> I'm still not entirely clear if this would be a better draft for the
> KITTEN WG or this one. If we update the SCRAM RFCs I think it may be
> better to go through KITTEN, but I'm not sure that they'll want to take
> that work on. I'll ask. Any advice here would be appreciated since I
> know almost nothing about IETF policy or procedures.

IETF doesn't really have rules about situations like this.

I think doing this in KITTEN makes more sense, as long as feedback is 
asked on the TLS mailing list. KITTEN is more likely to have interest to 
drive this work to completion. Having said that, if there is strong 
interest in getting this done in TLS, that would be fine with me.

Best Regards,

Alexey