Re: [kitten] TLS export for channel binding

Sam Whited <sam@samwhited.com> Fri, 08 May 2020 15:50 UTC

Return-Path: <sam@samwhited.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 CA2143A0BAE for <kitten@ietfa.amsl.com>; Fri, 8 May 2020 08:50:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=samwhited.com header.b=Urvg7T8W; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=yooSEwEC
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 nsv3CFj59GMr for <kitten@ietfa.amsl.com>; Fri, 8 May 2020 08:50:39 -0700 (PDT)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A5353A0BB2 for <kitten@ietf.org>; Fri, 8 May 2020 08:50:39 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 93ED35C0209; Fri, 8 May 2020 11:50:38 -0400 (EDT)
Received: from imap34 ([10.202.2.84]) by compute7.internal (MEProxy); Fri, 08 May 2020 11:50:38 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samwhited.com; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type:content-transfer-encoding; s=fm2; bh=ah hYCtqkoQt5bAix6JrUvUAVmQgnNJfMRkc46cvMFNA=; b=Urvg7T8W098Wr0KOMR Iv7OVhrGTmqQrPtzi2lsoVlOx8kLmSvjCfc6Nzib1rfo+xnHy9+qPbK4xoG+gDyI DFCdzwSXFyQt4H6BoOcmi9DFt2hTZx91mJJ7kTDZ3ZhhKXpIvKMqQkcIHlPxU6cz gGlevVnAp/bMeAq5eMeFavnL/x/SPDvtTxqv+C2+6+5sIOvYGL2K3jHygM0nYe8l fcpGMBHvmm0G2O5homQWRgzanjWQNHSyMhvpUtPSZC8K9jFU9ozlCeWywHBx4Mi/ liLGsRG0mH3z4iW8ogWwDSyOadPcB2vaNgRLhnySEEKkG70xut+pyaZFs/r4+Yn1 4saQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=ahhYCtqkoQt5bAix6JrUvUAVmQgnNJfMRkc46cvMF NA=; b=yooSEwECH6ouuVPTpQ+Vv4PPImIuD2brmZ5TFouqrbgys6wsoFrsO5s0P txOgyWdVkl/FWnX47dgx1321rJoIWon1b2rJTj3M/J6ZbwJmk8ql3mY6UgCfimGI 5LB9Oc7Qey0Lpadi6YmZL0nH1qc5I1P0Gxm8VeoMGbCS44p4hCrBRZx0tw2DJbgn vV6OCVIXlDN5vdLQJhDKxQsWHNklKJicWE9ElaDM0yR5Y/O4XyRj8IcWYOgcHzFc ZjEHuDr0GQXqmXixv1dlKib6N6hrQM53u4sDlA+DXUBMMHogZRs6XscVZGO3blZf F9lUuhbs1Y03FmbqV4+R5MvU8uPKQ==
X-ME-Sender: <xms:zX-1Xk2oqNg3eMMnzEXTaGrjOGILhCh8kCrAcNzRgngb9tcC7_pZqg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrkeefgddvjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdfurghm ucghhhhithgvugdfuceoshgrmhesshgrmhifhhhithgvugdrtghomheqnecuggftrfgrth htvghrnhepvdffuedvudfhfedvieehueekfffhkeejvefggfegtdelhffhhfeiveekudev hfejnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepsh grmhesshgrmhifhhhithgvugdrtghomh
X-ME-Proxy: <xmx:zX-1XiQ01ND7_HFL6YRGldRDtDb6uFSnqiAZ8NLm9LtJ6I_OR7M1bg> <xmx:zX-1Xjuhj1NGbboi7Z_EPEuostdXuZRlHMY6KgJCn73t2GgF_vu8eA> <xmx:zX-1Xi7F9wgMgwBZzrbDwkOhPuCm_DD1q6RUqmg5LviEGqSsEr0D3Q> <xmx:zn-1XoGQklYMyhyJZibCS2TmsJucT28cUsOtECpFoFWJnt0j9lfHtg>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id A12611460061; Fri, 8 May 2020 11:50:37 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-413-g750b809-fmstable-20200507v1
Mime-Version: 1.0
Message-Id: <70c569d7-de56-4afd-b3d1-509bebd5964b@www.fastmail.com>
In-Reply-To: <1UW9H0ROlm.1L2tuElxz66@pc8xp>
References: <ddff592a-4774-43c7-8b23-392516d892ab@www.fastmail.com> <85d7fb9a-92f7-4b5a-bb20-bb9cfeeae67d@www.fastmail.com> <3d1e7257-004c-aabf-a259-6e532259c78e@isode.com> <80f32eca-9625-4c16-872f-5b0edb975483@www.fastmail.com> <jlg7dxn20ks.fsf@redhat.com> <1UW9H0ROlm.1L2tuElxz66@pc8xp>
Date: Fri, 08 May 2020 11:50:14 -0400
From: Sam Whited <sam@samwhited.com>
To: tom petch <daedulus@btconnect.com>, Robbie Harwood <rharwood@redhat.com>, Alexey Melnikov <alexey.melnikov@isode.com>
Cc: KITTEN Working Group <kitten@ietf.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/WTFlkIYKzk3kpRZ2f4pJc5e_Yu8>
Subject: Re: [kitten] TLS export for channel binding
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: Fri, 08 May 2020 15:50:44 -0000

On Fri, May 8, 2020, at 11:41, tom petch wrote:
> which I think is the problem; whose is? The I-D baldly states that the
> current channel binding does not work with TLS 1.3, with no
> explanation.

I'll fix that, thanks!


> Whatever, this I-D needs to spell the problem out and IMHO update the
> current RFC on TLS Channel Binding so that others can see that there
> is a problem.

Is there a different process to update an existing RFC vs. creating a
new I-D and trying to get it adopted by a WG? I'm still unclear on the
process in general, and it seems like this might be different.

If we're updating that document anyways, I assume the TLS WG would be
the place and we might as well integrate this I-D into the document
update instead of keeping it a separate I-D.

> Which pushes me to thinking that this I-D

Looks like this got cut off?

Thanks for the feedback!

—Sam

-- 
Sam Whited