Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Fri, 29 January 2021 18:32 UTC

Return-Path: <kaduk@mit.edu>
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 75CD33A1207; Fri, 29 Jan 2021 10:32:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level:
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-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 Mtd0crQDI4_d; Fri, 29 Jan 2021 10:32:33 -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 BF7963A0C37; Fri, 29 Jan 2021 10:32:32 -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 10TIWKSi014215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 29 Jan 2021 13:32:25 -0500
Date: Fri, 29 Jan 2021 10:32:20 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: Alan DeKok <aland@deployingradius.com>
Cc: Martin Thomson <mt@lowentropy.net>, "<tls@ietf.org>" <tls@ietf.org>, EMU WG <emu@ietf.org>
Message-ID: <20210129183220.GI21@kduck.mit.edu>
References: <e669002f-caff-1e6e-e28b-d09157eb0c07@ericsson.com> <6241F0B6-C722-449E-AC3A-183DE330E7B5@deployingradius.com> <9ddd1593-3131-f5cc-d0db-74bf3db697bf@ericsson.com> <3CB58153-8CCA-4B1E-B530-BA67A6035310@deployingradius.com> <CAOgPGoA3U+XpZMY7J+KGovNx6MtAdEzRaGW33xVJdQNWSi4LVg@mail.gmail.com> <770e6a49-52fc-4e8b-91af-48f85e581fbb@www.fastmail.com> <CAOgPGoBGOMXH-kMhQSujWxnACdmBL845u0ouE0fUYc4rWtUrZg@mail.gmail.com> <ca4c526e-79a0-4fa7-abda-2b626795f068@www.fastmail.com> <3409F71E-4CE4-46BB-8079-BFBE9BE83C9A@deployingradius.com> <66157321-55DC-4831-8EF2-D75934D9024C@deployingradius.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <66157321-55DC-4831-8EF2-D75934D9024C@deployingradius.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/qbgPBg-GblOXLJPR8Gru8fqEnF0>
Subject: Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)
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: Fri, 29 Jan 2021 18:32:36 -0000

Hi Alan,

I see that the thread is continuing and that perhaps my reply will even
become stale as I write it, but I'm replying to your note instead of the
tip of the thread because it has good context for making some broader
points that I would like to make.

On Sat, Jan 23, 2021 at 05:28:10PM -0500, Alan DeKok wrote:
>   We're approaching 2 weeks since the last discussion of this topic.  This document has been in development for 3 years.  We desperately need to finish it.  IMHO waiting another 6 months is not an option.  Even 3 would be worrying.

My understanding of the discussions involving the TLS WG are that we forked
off into two sub-threads: one about the use of TLS Exporters for key
derivation (the one this is a reply to), that largely concluded with
agreement on a simple change to make, and the other sub-thread about the
protocol element known in -13 as the "commitment message".

With respect to the exporter usage, I do see you had asked about using the
type-code as the exporter context value that Martin didn't see much value
in, but I am willing to accept that as a boon for safety of portability to
other TLS-using EAP mechanisms.  (I do note that the current editor's copy
shows calls to TLS-Exporter() with only two arguments, but three are
required; the construction there also seems to include a propspect for
violation of the requirement that "one label is not a prefix of any other
label" when both regular one-byte and extended type codes are used, but if
the type code is meant to be the context argument I believe that risk goes
away.)

With respect to the "commitment message", I thought we had a discussion
that revealed that the mechanism in the -13 could not fulfil its stated
purpose, and that also called into question whether that stated purpose was
actually the right thing that the protocol needed.  My understanding,
therefore, was that the TLS WG could not contribute further insight until
there was a revised proposal from people who understand the needs of the
EAP-TLS protocol from TLS that would both satisfy the needs of EAP and
actually be achievable.

>   We have multiple inter-operable implementations which have implemented draft-13.  That work over the last few months have resulted in implementors making plans to do beta testing in the next few weeks.  Those plans have been put on indefinite hold, due to the recent request for changes.
> 
>   I understand getting feedback from the TLS WG is useful.  But I would prefer to have consensus on a *solution*. Right now, we just have a series of proposed changes, with little to no discussion.

I think this is becaues the TLS WG members (in aggregate) do not have a
clear picture of what property or properties EAP-TLS will require from TLS
that led to the need for an additional message when using TLS 1.3 as
opposed to the RFC 5216 case with TLS 1.2.  The prospect of an
"authenticated signal from TLS to EAP-TLS that the authentication completed
successfully" was mentioned, but I did not have the sense that there was
universal agreement of that as the sole relevant property.

>   We're getting to the point where we have to ship code as promised to customers soon (weeks, not months).  We therefore need consensus, as soon as possible.
> 
>   My preference is to implement draft-13.  We know the code works.  People are ready to ship it.  Any changes will add not just more months of standard discussion, but more months of interoperability testing.
> 
>   If there is no progress in EMU, we're looking at September for first betas.  With no guarantee that there won't be further changes made after that.
> 
>   So the question is:
> 
> * are the draft-13 0x00 byte and exporter *terrible* enough to delay the standard another 6 months?

Well, the text of the -13 contains a protocol mechanism that cannot deliver
its stated purpose, so I will continue to hold a Discuss position if that
remains.  One Discuss ballot does not have to block the work indefinitely
(the shepherding AD can request a different IESG balloting procedure be
used), and I leave it between the WG and Roman whether to attempt that
route.  It is perhaps possible that (as John noted downthread) the text
about the commitment message was badly written, and that just changing the
surrounding description could work, but that gets back to the question I
mentioned above of what properties EAP-TLS actually requires from TLS.

-Ben

> * if the answer is "no", then we can ship now.
> 
> * if the answer is 'yes", then the next question is "when can we get this finalized?"  "March" would be late.  "July" is a major problem.
> 
> > On Jan 12, 2021, at 10:22 AM, Alan DeKok <aland@deployingradius.com> wrote:
> > 
> > On Jan 11, 2021, at 7:08 PM, Martin Thomson <mt@lowentropy.net> wrote:
> >> I was not exactly.  I was thinking that EAP-TLS uses the unadorned string and other usages (that need a different MSK) define their own string as needed.
> > 
> >  Which is largely what was done for <= TLS 1.2.
> > 
> >  That choice made implementations more difficult.  Not impossible, but annoying.  The other TLS-based EAP types are generally implemented as variants of EAP-TLS.  They re-use much of the EAP-TLS code.  So every difference is more code, and more things to test.
> > 
> >> Though what you describe would scale more, if the ordinality of that scale is bounded by RFC numbers, defining the extra strings would not be that hard.  You could provide some sort of infrastructure in the form of a recommended label prefix if you are concerned about misuse.
> > 
> >  I'm not sure EAP-TLS is the place to make recommendations for other EAP types.  There is a draft to deal with other EAP types:
> > 
> > https://urldefense.com/v3/__https://tools.ietf.org/html/draft-dekok-emu-tls-eap-types-00__;!!GjvTz_vk!BN9rm7SoWGOKFjfY7fFgpHjeV58wJeRS31O8qeE3B4tZbNy-zWi1yMwNRryTgg$ 
> > 
> >  It's pretty trivial.  Adding more complexity is annoying, but not much worse than that.
> > 
> >  My preference is to remain with the EAP type as the context.  The code is simple, and it's easy to understand.  But if it causes issues with TLS review, we can change it.
> > 
> >  Alan DeKok.
> > 
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tls__;!!GjvTz_vk!BN9rm7SoWGOKFjfY7fFgpHjeV58wJeRS31O8qeE3B4tZbNy-zWi1yMwitxxMCA$