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

Benjamin Kaduk <kaduk@mit.edu> Mon, 01 February 2021 02:53 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 2C41E3A1311; Sun, 31 Jan 2021 18:53:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level:
X-Spam-Status: No, score=-1.92 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] 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 85nc0K9s71jk; Sun, 31 Jan 2021 18:53:19 -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 E81583A1565; Sun, 31 Jan 2021 18:53:18 -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 1112rBtd004976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 31 Jan 2021 21:53:15 -0500
Date: Sun, 31 Jan 2021 18:53:11 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: Alan DeKok <aland@deployingradius.com>
Cc: "<tls@ietf.org>" <tls@ietf.org>, EMU WG <emu@ietf.org>
Message-ID: <20210201025311.GZ21@kduck.mit.edu>
References: <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> <20210129183220.GI21@kduck.mit.edu> <1E2EE4CD-20D6-4DE3-A912-5E102DD731B0@deployingradius.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <1E2EE4CD-20D6-4DE3-A912-5E102DD731B0@deployingradius.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/T3jDPrq0JYSLj92Rvsn0nm3_uGM>
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: Mon, 01 Feb 2021 02:53:23 -0000

Hi Alan,

With my apologies to everyone on the thread for so many mails in
succession...

On Fri, Jan 29, 2021 at 02:09:09PM -0500, Alan DeKok wrote:
> On Jan 29, 2021, at 1:32 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
> > 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.
> 
>   OK. 
> 
> >  (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.)
> 
>   The EAP type codes are one octet: 0x00 through 0xfd.  The "expanded" type codes begin with 0xfe.  So there is no prefix issue, even if the type codes form part of the label.

Ah, of course I should have realized that the 0xfe octet separates them.
You are correct; there is no issue with prefixes, and sorry for the
confusion.

Thanks,

Ben