Re: [kitten] Martin Duke's Discuss on draft-ietf-kitten-tls-channel-bindings-for-tls13-14: (with DISCUSS)

Benjamin Kaduk <kaduk@mit.edu> Fri, 25 February 2022 02:48 UTC

Return-Path: <kaduk@mit.edu>
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 064D03A10CD; Thu, 24 Feb 2022 18:48:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 EHevn4sXMjYD; Thu, 24 Feb 2022 18:48:29 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BFD23A10D0; Thu, 24 Feb 2022 18:48:28 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 21P2mJCn002579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 24 Feb 2022 21:48:24 -0500
Date: Thu, 24 Feb 2022 18:48:18 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: Sam Whited <sam@samwhited.com>
Cc: Martin Duke <martin.h.duke@gmail.com>, The IESG <iesg@ietf.org>, KITTEN Working Group <kitten@ietf.org>, draft-ietf-kitten-tls-channel-bindings-for-tls13@ietf.org, kitten-chairs@ietf.org
Message-ID: <20220225024818.GQ12881@kduck.mit.edu>
References: <164564529663.28442.4015005677356062750@ietfa.amsl.com> <20220223194317.GI12881@kduck.mit.edu> <cfe6a4ff-a27b-4084-9c03-479260c88f0f@www.fastmail.com> <20220223205926.GJ12881@kduck.mit.edu> <CAM4esxSsQRMnfJnUassNfVtv7OtpXAwXv2Xfnd+vDg-iJyho1Q@mail.gmail.com> <7a949ea1-611a-4919-b8c2-b0fa32d2b40b@www.fastmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <7a949ea1-611a-4919-b8c2-b0fa32d2b40b@www.fastmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/2k4u3vzOcXb0PAgOjIFZJh9ofO8>
Subject: Re: [kitten] Martin Duke's Discuss on draft-ietf-kitten-tls-channel-bindings-for-tls13-14: (with DISCUSS)
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, 25 Feb 2022 02:48:32 -0000

I had planned to highlight that change a bit more prominently in my thread
with you, but I guess I got distracted or something.  I'm sorry to have it
come as a surprise in this thread.

My stance here is roughly:

- the TLS WG is pretty authoritative on what RFCs should Update: the RFCs
  that it produced

- the TLS WG recent practice for (not) using Updates: would fall towards
  "not" in this scenario

- with the publication of TLS 1.3, the TLS WG has established a practice of
  having rigorous formal analysis of the security properties of its output
  where cryptography is involved, even going so far as to explicitly build
  in time to the document lifecycle for such analysis to take place prior
  to IETF last call.  Other security-area WGs have adopted similar
  practice, though it is not universal (and cannot be universal given the
  resources available in the different WGs).  The exporter-based channel
  binding this document defines is not analyzed in such a way, and
  realistically cannot be so analyzed, for the very reasons now documented
  in the security considerations.  That analysis does exist for the
  exporter construct in general, under certain assumptions, but that
  analysis covers only the output of the TLS exporter, not its use as an
  input for the channel binding schemes that consume it.  So, the bar in
  practice of the TLS WG for the amount of analysis a cryptographically
  relevant protocol (extension) received has not been met here (though the
  bar of the KITTEN WG has been met), and so I wouldn't expect the TLS WG
  to conclude that this scheme is ready to be rolled in to be "part of TLS
  1.3" at this time, which is what an "Updates: 8446" status would signal
  to many people.  (The precise meaning of the tag is, unfortunately, quite
  under-specified and a topic on which many emails have been spent in the
  IETF.)

Accordingly, I don't think there's enough reasoning and consensus to
support having this document Update: RFC 8446.

I do, however, think that this is a great opportunity to think about what
draft-ietf-tls-rfc8446bis should say about channel bindings.  While it
remains true that "the channel bindings described in [RFC5929] are not
defined for TLS 1.3", there are analogous (arguably, better) channel
bindings that are defined, and it would be a shame if 8446bis didn't say
anything about them.

-Ben

On Wed, Feb 23, 2022 at 04:40:56PM -0500, Sam Whited wrote:
> I see, I missed that the suggested changes had removed this, or possibly
> forgot to bring it up before applying them. If the text no longer
> matches the header I agree they should match, but I still feel strongly
> that this should in fact update TLS 1.3, which makes it sound as if
> there are no channel bindings for TLS 1.3 (except now there are, so that
> sounds like an update to me and something that's important to make
> discoverable).
> 
> —Sam
> 
> On Wed, Feb 23, 2022, at 16:08, Martin Duke wrote:
> > Yep , I have no opinion on whether it should be updated, but the
> > header and the text should match.
> >
> > That said, if there is no consensus that seems like a bigger issue.
> >
> > On Wed, Feb 23, 2022 at 12:59 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
> >
> >> Hi Sam,
> >>
> >> I think that the proximate topic here is that Martin is noticing a
> >> mismatch between the in-document header (the "Updates:" header) and
> >> the prose of the document.  That's my fault; I sent you suggestions
> >> that removed the header but forgot to touch the prose at all, and if
> >> I had done so, I don't think Martin would have raised the topic
> >> (Martin, please correct me if I'm wrong).
> >>
> >> On the question of whether or not "updates" is correct, I think that
> >> https://mailarchive.ietf.org/arch/msg/tls/YZQWmP_8BDkacfy3O-qcy8EV2N0/
> >> (from a TLS WG co-chair) is a good summary -- the current "normal"
> >> for TLS is to not use the header for this sort of thing.
> >>
> >> It also notes that the question of what text (if any) to put in the
> >> ongoing 8446bis effort is more important, long-term, than whether to
> >> use the "updates" header here.  That is, RFC 8446 itself will
> >> probably only be current for a couple years and then the successor
> >> will be current, so any "updates" relationship would become stale at
> >> that point.
> >>
> >> -Ben
> >>
> >> P.S. Sean also mentioned draft-ietf-ace-coap-est in the linked
> >>      message, and there are changes in flight for that document to
> >>      refer to draft-ietf-kitten-tls-channel-bindings-for-tls13
> >>
> >> On Wed, Feb 23, 2022 at 03:26:00PM -0500, Sam Whited wrote:
> >> > I do not believe there was consensus one way or another on this.
> >> >
> >> > The strong feedback was by one or two members of the TLS working
> >> > group and I do not believe it was correct or represented consensus.
> >> > Unless those people that complained *do* represent consensus among
> >> > that working group and intend to block publication of this document
> >> > based on it (and if they do, I wish they had said so earlier during
> >> > the discussion and not let the matter drop), I would like it to
> >> > move forward with the "updates" line in place if at all possible.
> >> >
> >> > —Sam
> >> >
> >> > On Wed, Feb 23, 2022, at 14:43, Benjamin Kaduk wrote:
> >> > > On Wed, Feb 23, 2022 at 11:41:36AM -0800, Martin Duke via
> >> > > Datatracker wrote:
> >> > >> Martin Duke has entered the following ballot position for
> >> draft-ietf-kitten-tls-channel-bindings-for-tls13-
> >> > >> 14: Discuss
> >> > >>
> >> > >> When responding, please keep the subject line intact and reply
> >> > >> to all email addresses included in the To and CC lines. (Feel
> >> > >> free to cut this introductory paragraph, however.)
> >> > >>
> >> > >>
> >> > >> Please refer to
> >> > >> https://www.ietf.org/blog/handling-iesg-ballot-positions/ for
> >> > >> more information about how to handle DISCUSS and COMMENT
> >> > >> positions.
> >> > >>
> >> > >>
> >> > >> The document, along with other ballot positions, can be found
> >> > >> here:
> >> > >>
> >> https://datatracker.ietf.org/doc/draft-ietf-kitten-tls-channel-bindings-for-tls13/
> >> > >>
> >> > >>
> >> > >>
> >> > >> ---------------------------------------------------------------
> >> > >> -------
> >> > >> DISCUSS:
> >> > >> ---------------------------------------------------------------
> >> > >> -------
> >> > >>
> >> > >> A simple thing: the document header should state that it updates
> >> > >> RFC 8446.
> >> > >
> >> > > No, it should not.
> >> > >
> >> > > This topic was discussed with the TLS WG and there was strong
> >> > > feedback that the use of the "Updates:" header was inappropriate.
> >> > >
> >> > > See the thread at
> >> > > https://mailarchive.ietf.org/arch/msg/tls/vH74JoSGYpJv7Tcem60L3RtNa9U/
> >> > >
> >> > > -Ben
> >> >
> >> > --
> >> > Sam Whited
> >>
> 
> -- 
> Sam Whited