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

John Mattsson <john.mattsson@ericsson.com> Fri, 29 January 2021 10:31 UTC

Return-Path: <john.mattsson@ericsson.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 97C223A0147; Fri, 29 Jan 2021 02:31:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.351
X-Spam-Level:
X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.25, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
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 FWjIRNGhawwd; Fri, 29 Jan 2021 02:31:23 -0800 (PST)
Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2069.outbound.protection.outlook.com [40.107.20.69]) (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 086F23A0A4C; Fri, 29 Jan 2021 02:31:22 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iDRfvNk2GHJh6m/jDUw1ASwJQnqK4dyALCoUK0/rsQ0vPbuEIP6I9WEpgO6H1oQN8a9AV5jpxmKGJvP9/+xw6MH4pNmUWnu/bI71xgQzg0QdQeYVt6BWZT9IEr5O5YTRiW4z3GJYJxXnQ2g9DqTWVB8O7do1pPHfW0HCKAW8I4hEA0nQuBH+ZLMVeaijga0tO+/N4M1T6RpqpcMIR+F7p0T4PKKKSucsOXdiTdM69rkOe7NeCeKcXCW2B9m/5mCzp+o82rMggDF3/8W+rV+lDyGKUefT6v8j1loEWituLityFg9GuyShbRXHWXuroMle88AtbhPNmrvNRETb32+mJQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JPMCZj0CArL2y8goSYFpGsm1Krie2QjMhgHroLLn8/w=; b=Hx7gABv+7XWi1421GkqgzcOjCVL/vpaiBfl0TbuUhlVPmASNA20msOspJaFpZKgF2nzcwIgDSQzDXwDWUX5/uiK7hMf8IuLB0Kha44vEvAvr+QRRpGl6j5woc4qYK0WvbIcxCTnzW9jGLJljgvqMuelnsAZFp99u5w2cIvzYN9rwtpld1UlVWdfOgKKVLQDXZVzu5m40WDDxZS8Ky8B1KNI7zn6PGcnKi/BH6ohThJeuC/8yPDMcH9IRBLkZ16G5QQDH1fEmiK21EUmELNV//zEvVzWFyAouMxTMDDZUkSXLHa078/jc3W1JMfMfAar46puUSqTwn2iJhL0vQGLMrw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JPMCZj0CArL2y8goSYFpGsm1Krie2QjMhgHroLLn8/w=; b=rtaJ9C1nTWMPutMDNvbWlnLh+/gx1+5vklaLjUM6nlR+JsaL2X1BcXWLZu18XMGqadaWdWWklsTYye+ZH9j2c4eK9NsuNSKN93Ij3faWGXT6i/XrzVvmNyiWJqibFIFRKWGhda6yVzqA/6WBbtF31LoeL+/G9vSxy0Q8574Ztbs=
Received: from (2603:10a6:3:4b::8) by HE1PR0701MB2508.eurprd07.prod.outlook.com (2603:10a6:3:72::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3825.8; Fri, 29 Jan 2021 10:31:20 +0000
Received: from HE1PR0701MB3050.eurprd07.prod.outlook.com ([fe80::c555:6e47:970c:1268]) by HE1PR0701MB3050.eurprd07.prod.outlook.com ([fe80::c555:6e47:970c:1268%11]) with mapi id 15.20.3805.017; Fri, 29 Jan 2021 10:31:19 +0000
From: John Mattsson <john.mattsson@ericsson.com>
To: Jorge Vergara <jovergar=40microsoft.com@dmarc.ietf.org>, Alan DeKok <aland@deployingradius.com>, Martin Thomson <mt@lowentropy.net>, Benjamin Kaduk <kaduk@mit.edu>, Roman Danyliw <rdd@cert.org>
CC: "<tls@ietf.org>" <tls@ietf.org>, EMU WG <emu@ietf.org>
Thread-Topic: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)
Thread-Index: AQHW8dc50hS+6hSX6EiOteWBrQHb5Ko9vvGAgADB5oA=
Date: Fri, 29 Jan 2021 10:31:19 +0000
Message-ID: <B2C94459-5C07-4091-9575-3DCB461B75F7@ericsson.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> <ca4c526e-79a0-4fa7-abda-2b626795f068@www.fastmail.com> <3409F71E-4CE4-46BB-8079-BFBE9BE83C9A@deployingradius.com> <66157321-55DC-4831-8EF2-D75934D9024C@deployingradius.com> <MW2PR2101MB0923A68A9D7560D14D7A8C89D1BA9@MW2PR2101MB0923.namprd21.prod.outlook.com>
In-Reply-To: <MW2PR2101MB0923A68A9D7560D14D7A8C89D1BA9@MW2PR2101MB0923.namprd21.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.44.20121301
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=2f31426e-70ae-4afe-90f9-7ebcd95c318c; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2021-01-28T23:53:31Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [81.225.97.222]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 449c19ca-5744-4dcf-8d36-08d8c4410478
x-ms-traffictypediagnostic: HE1PR0701MB2508:
x-microsoft-antispam-prvs: <HE1PR0701MB2508A1B878060B3B81EA2E9689B99@HE1PR0701MB2508.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: wEwDzb7EBJ9RR4JIR45cQyMCePT9PzIs++XGZxQxZUq0xaCWrkqbBBI82y7oOpUS6ODFdMNP0HHHM/I3ST7pDxnRYbBQl6LgwEIs+CbxWZvbA5gzpH0I72odFIEB29aA9eT3B3wu/IGp7wtyfofimtr1KKuerJzIvCFQtN/0EBypKuuMy83LT/eFnyGpXwRWuhj8de/NNw5VYSmcsFS1NslA31nAl6qAlpZqMPiNlzAsUBSwb0v9trA2sM6U9XmEhEaDiCuA+IU71flj/wuCrgHtb2NROLUwaiKUcAJkWseqwyrXbamEY/ZNSiwhd6z2slsPfmhZSibSXbQnG/w3B7tdh35feVHydSEFO6nV1gIa4XJG2lpftTBP5V1FV3EAHAPt7QyZsQm3aAdrygCwn53tQ7ok9KZuiWgmCiUPbJ7HVSxk9NOHCg/MNS3OXowwMsCmeIVzQfnoQ9BPZiZ5qUn8vPcWJycv06uM8Ew6aG2Z3tvGcYK+vPXOvzuiMhIDx5ryn8OyPtiOJ5SIolB7Dqc6o8fQsGtzpe6nNdlxvJvg6s8qPE9xEhlF/Tld4B3HbNPZF/POq6tXwyG0R/MlC1JzGaFjpa85VIIOGHVI3J1wulZz6D6y3bJdjaDSdDNWrvOiupH8RZbifoTcp3FKsg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0701MB3050.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(39860400002)(396003)(136003)(376002)(366004)(6506007)(53546011)(71200400001)(36756003)(66946007)(5660300002)(86362001)(8936002)(2616005)(6512007)(2906002)(33656002)(66476007)(66556008)(4326008)(966005)(478600001)(66446008)(110136005)(316002)(76116006)(83380400001)(26005)(8676002)(44832011)(186003)(64756008)(45080400002)(6486002)(45980500001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: yTeYuyHrGhfZKSb/fRSDVDT9bLzxLNCNW6caFFWnupPbgjAbuTQPhDQtrnKKvArIg8/AYoeXRWs1M25BW83160r8CuDoPvgJxwbFLzR45k9RuHy/lo0qY6LrlbkkZ5b65uAtbZrVbdP/6cT418LEJ8ehYixQ6316VnQDfARiiYd5L/l3D9oa7bATl5ekNvdYFiwzlYgDm+t/cIXS00TqOz69Nqpb61ZxnqYw1lM6dI2Ymp7Yi45/BtN+jn1tyXr+A2wA7dpTwhfwLwel9OZIUAHdNIeb2KBM1AorXw+et4m5xJRvb9GDeqO6aOHXLkfrEFzom1CQNqY6Z+1tsq3UimeAMHZsQ780xNMO0J7hPmg/6l/oD0h/RcjV62jrPGmwFT2R7RWBj1UC4o1gNLMxLcmpPXbSFF31vaBXth9m4lOeZbyLTaX02ObNCWawzI2R8eQCfab5FiG1kdXZk3xVK3owhXzAUlv1k+kiOI+PWa7+LhGc4+NzvYW0jK6kR40zBp4iRfXJb5XkitpYXsRRgRgBgi1ZCYz88GBUiq3j2GZ/QVAZfvorPHZwW2Ivghq0Qq1l6tWws6DwCf1QeL/hqeCwk68O0gcmW4bQUCoTHfsse+Xik1e4SknQFvzgG+ccPRRXB4e/GANbBDwdaQd09thnSDzVXvjYFvv/1R7LniT2kxFGouDiNgFp4sM0jM9T+TbEfQcFUOdJTjB1AzodMkALt3FoZ5fefRtlatkDacf2ArtJg5dx/PK9bn13J9IENbAU2bjF/Wj0frNRf+g/DZxOx2SDjGHsufVsJPRWmnG3mnuoe4YDsEo6SNNTA8qSPmH4tml/Ewy6985HWNH6bsllZa7Q9cw2Ptv6YvAZ/bEjkdP/rvcb4+/HG7CprXCdsA5LnvH+tdVAKxCmw5DCx+pOBnpbqVLTozw9mkJ5xDUkxGCoyTl39jl/pGwK7+GnvVStaLt5Xpn5eWzq5iZJcbIK5cQ7bZVY7MPaQX/YAgokcb5Au5Pu4EwiFbgT73yWl7jzwBZlVLtGIamvvxh1ucUthA5Nix/mOFo98E68Jig4r8tJ6IK/wFmK/e/68awrTNlrRV6sVNJQFM1VWcjqzQ==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <ED83ACD6BDEBAE4595ED7561B695157C@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: HE1PR0701MB3050.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 449c19ca-5744-4dcf-8d36-08d8c4410478
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jan 2021 10:31:19.9143 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: CkQAWJfYt9y5qgMWDCxz+vgpBENG9CTW7TXF1skQy2jXrMaGVg8X+ISZIFSZWtQFgK5m9x7fMXjp22+q2Rcf4qWbH1elkBJgOEbbu9ugyZc=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2508
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Mchb3dmYvh95uKtHXeuf_mHObOM>
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 10:31:26 -0000

Hi,

I can live with any version, the important thing is that interoperable implementations get shipped ASAP. This is important also for 3GPP as EAP-TLS 1.3 is mandatory to support in 3GPP Rel-16 if EAP-TLS is supported.

We (the authors) have addressed all the comments from IESG/TLS WG in GitHub.

https://github.com/emu-wg/draft-ietf-emu-eap-tls13/tree/master

Text format:

https://emu-wg.github.io/draft-ietf-emu-eap-tls13/draft-ietf-emu-eap-tls13.txt

The diff can be found here:

https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-emu-eap-tls13.txt&url2=https://emu-wg.github.io/draft-ietf-emu-eap-tls13/draft-ietf-emu-eap-tls13.txt

This would be ready for submission but I think the Implementors, WGs, Chairs, Shepard, ADs need to agree on the direction before we do that. The two important technical changes from -13 are

(1) Changing key derivation
(2) Changing Commitment message to close_notify

The key derivation changes are good and more modern. I personally like the change but the change but I don't think it is essential and was not done for security reasons.

The close_notity changes are not only positive as it sometimes introduce an additional roundtrip. The Commitment message can according to specification be sent with the server Finish even if some/most/all implementation does not seem to allow this. If the commitment message cannot be send with Finished in practice there is no difference in latency. Still a bit sad how poorly TLS 1.3 and EAP interacts. I am not sure I fully agree with the layer violation argument, my interpretation was that this was information for the EAP state machine which is the application using TLS. Maybe the text regarding the commitment message was badly written and should have talked about the EAP state machine more instead of TLS....

We need to get agreement on how to proceed here asap. I would like implementors and security AD to agree on the way forward before submitting -14. Four ways forward:

A. Add (1) and (2)
B. Only add (1)
C. Only add (2)
D. Do not add (1) or (2)

I assume implementors (Alan, Jorge) are fine with all other changes since -13.

Do we need to have a telephone meeting to discuss these things? We cannot have a formal interim meeting as that formally takes weeks to setup. This can also not wait until the next IETF. As soon as we agree on a way forward we can update and submit a new version within 24 h.

Cheers,
John

-----Original Message-----
From: TLS <tls-bounces@ietf.org> on behalf of Jorge Vergara <jovergar=40microsoft.com@dmarc.ietf.org>
Date: Friday, 29 January 2021 at 00:57
To: Alan DeKok <aland@deployingradius.com>, Martin Thomson <mt@lowentropy.net>
Cc: "TLS@ietf.org" <tls@ietf.org>, EMU WG <emu@ietf.org>
Subject: Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

I am in favor of sticking to draft-13. There was some discussion about whether draft-13 contained a TLS layering violation, but I believe that discussion concluded that it does not. As noted, discussion has mostly stalled since then with a few additional ideas surfacing that have added round trips. Other threads are now popping up expressing dissatisfaction with the extra round trip.

Alan mentions that betas may be months out for his product line - for Microsoft and Windows, the situation is much tighter. If we cannot reach consensus quickly we will need to push this out of our 2021 release cycle. Seeing as we're sitting on draft-13 with multiple implementations available, I would really prefer to reach consensus to finalize draft-13 and get this into the hands of customers this calendar year.

Jorge Vergara

-----Original Message-----
From: Emu <emu-bounces@ietf.org> On Behalf Of Alan DeKok
Sent: Saturday, January 23, 2021 2:28 PM
To: Martin Thomson <mt@lowentropy.net>
Cc: <tls@ietf.org> <tls@ietf.org>; EMU WG <emu@ietf.org>
Subject: Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

  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.

  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.

  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?

* 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://protect2.fireeye.com/v1/url?k=fe7995f2-a1e2acf7-fe79d569-86d2114eab2f-8b83bd94fff2883d&q=1&e=5d168f81-6781-466c-bb9e-ff8cc7ea124e&u=https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Ftools.ietf.org%252Fhtml%252Fdraft-dekok-emu-tls-eap-types-00%26amp%3Bdata%3D04%257C01%257Cjovergar%2540microsoft.com%257Cb558b067ea62444150d008d8bfee5b6a%257C72f988bf86f141af91ab2d7cd011db47%257C1%257C0%257C637470377753309597%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C1000%26amp%3Bsdata%3DeTBptf92iMhYupJv9kRLl%252FzAV75fZXSbDjTI9sKu%252Bvs%253D%26amp%3Breserved%3D0
> 
>  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.
> 

_______________________________________________
Emu mailing list
Emu@ietf.org
https://protect2.fireeye.com/v1/url?k=80417b72-dfda4277-80413be9-86d2114eab2f-701eaa3e4f1d35c4&q=1&e=5d168f81-6781-466c-bb9e-ff8cc7ea124e&u=https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fwww.ietf.org%252Fmailman%252Flistinfo%252Femu%26amp%3Bdata%3D04%257C01%257Cjovergar%2540microsoft.com%257Cb558b067ea62444150d008d8bfee5b6a%257C72f988bf86f141af91ab2d7cd011db47%257C1%257C0%257C637470377753319592%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C1000%26amp%3Bsdata%3DJQCtoTOMTzouZnJ0ILj%252B8%252BtIpJW8t04HbSlDDGYf8VQ%253D%26amp%3Breserved%3D0

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls