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

Alan DeKok <aland@deployingradius.com> Mon, 11 January 2021 13:28 UTC

Return-Path: <aland@deployingradius.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 BE3073A0B18; Mon, 11 Jan 2021 05:28:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 aXRuuXqVLgU1; Mon, 11 Jan 2021 05:28:17 -0800 (PST)
Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C2203A0B10; Mon, 11 Jan 2021 05:28:16 -0800 (PST)
Received: from [192.168.46.129] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id 5DAADD6; Mon, 11 Jan 2021 13:28:13 +0000 (UTC)
Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <CAOgPGoBGOMXH-kMhQSujWxnACdmBL845u0ouE0fUYc4rWtUrZg@mail.gmail.com>
Date: Mon, 11 Jan 2021 08:28:11 -0500
Cc: Martin Thomson <mt@lowentropy.net>, "<tls@ietf.org>" <tls@ietf.org>, EMU WG <emu@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <C540E854-AA9D-40A8-A87C-CA2D42FC31FF@deployingradius.com>
References: <160815821055.25925.15897627611548078426@ietfa.amsl.com> <20201216223842.GR64351@kduck.mit.edu> <0f2b05db-5c98-43d4-aae3-cf620814bacc@www.fastmail.com> <A4BBA31B-8754-4D8C-B0F1-D1C6C859F6AE@deployingradius.com> <CAOgPGoBvBzhA0q4gFqpFSm2HkAs6NoyLc6RVZYLtTYsNd02i8A@mail.gmail.com> <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>
To: Joseph Salowey <joe@salowey.net>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/EvX2PcWpZ31591bJXo0nEU7Tq1Q>
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, 11 Jan 2021 13:28:19 -0000

On Jan 11, 2021, at 1:07 AM, Joseph Salowey <joe@salowey.net> wrote:
> [Joe] I think you propose something like this instead (eliminating context):
> 
> MSK = TLS-Exporter("EXPORTER_EAP_TLS_MSK-" + ASCII-Type-Code, 64) 
> 
> Where + is concatenation and ASCII-Type-Code is "13"
> 
> the IANA section would explicitly list: EXPORTER_EAP_TLS_MSK-13

  That's fine, but I have a minor forward-looking comment based on other EAP types.  They'll have to do similar things.  This is OK for 8-bit EAP types.  This is more complex for the "extended" EAP types.

  For simplicity, I would suggest that the ASCII type code is represented as hex, instead of decimal.  This makes implementations simpler.  They can just hex-ify whatever EAP thing they have (8 bits, or more for extended types), and then append that to the "EXPORTER_EAP_TLS_MSK" string.

  Decimal is just ugly for computers to deal with. :)

> [Joe] I see your point that we should eliminate the context and include the type code in the label as it will always be the same for EAP-TLS (which also goes to the point that has been made by several people that this value may be redundant since we would expect another EAP type to use a different label).  In the past, people have used TLS in all sorts of innovative and unique ways in different EAP methods all loosely based on EAP-TLS.  I don't see this usage as too far outside the intended use of the context field (the value should match on both sides) and I think including the type value in the context value would help avoid some potential implementation problems if the key derivation is reused for another method.  

  I agree here.  I think it's simpler conceptually, for implementations, and there's less for IANA to deal with.

 But maybe the TLS people have a strong opposition to using the context in this way.  In that case, it's ugly, more work for everyone, but still possible to just append the hexified EAP type code to the label.

  Alan DeKok.