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

Dan Harkins <dharkins@lounge.org> Tue, 05 January 2021 21:18 UTC

Return-Path: <dharkins@lounge.org>
X-Original-To: emu@ietfa.amsl.com
Delivered-To: emu@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF1E33A011D for <emu@ietfa.amsl.com>; Tue, 5 Jan 2021 13:18:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.162
X-Spam-Level:
X-Spam-Status: No, score=-2.162 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.262, RCVD_IN_DNSWL_BLOCKED=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 MflJ_PTTHk7M for <emu@ietfa.amsl.com>; Tue, 5 Jan 2021 13:18:46 -0800 (PST)
Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (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 3D1393A0115 for <emu@ietf.org>; Tue, 5 Jan 2021 13:18:46 -0800 (PST)
Received: from trixy.bergandi.net (cpe-76-176-14-122.san.res.rr.com [76.176.14.122]) by wwwlocal.goatley.com (PMDF V6.8 #2433) with ESMTP id <0QMH001RBCJAB3@wwwlocal.goatley.com> for emu@ietf.org; Tue, 05 Jan 2021 15:18:46 -0600 (CST)
Received: from blockhead.local ([69.12.173.8]) by trixy.bergandi.net (PMDF V6.7-x01 #2433) with ESMTPSA id <0QMH0072CCI51D@trixy.bergandi.net> for emu@ietf.org; Tue, 05 Jan 2021 13:18:06 -0800 (PST)
Received: from 69-12-173-8.static.dsltransport.net ([69.12.173.8] EXTERNAL) (EHLO blockhead.local) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Tue, 05 Jan 2021 13:18:06 -0800
Date: Tue, 05 Jan 2021 13:18:44 -0800
From: Dan Harkins <dharkins@lounge.org>
In-reply-to: <f5080009-c6e8-4dfd-840e-aab95bde5419@www.fastmail.com>
To: emu@ietf.org
Message-id: <0547e9ce-e9e4-c8d6-af5d-16ab7df8018c@lounge.org>
MIME-version: 1.0
Content-type: text/plain; charset="utf-8"; format="flowed"
Content-language: en-US
Content-transfer-encoding: 8bit
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=69.12.173.8)
X-PMAS-External-Auth: 69-12-173-8.static.dsltransport.net [69.12.173.8] (EHLO blockhead.local)
References: <160815821055.25925.15897627611548078426@ietfa.amsl.com> <20201216223842.GR64351@kduck.mit.edu> <0f2b05db-5c98-43d4-aae3-cf620814bacc@www.fastmail.com> <CAOgPGoDLXuZ=bO8sFOqx8HPsZ-PPgio1_J_BzWCmvzfDR1xHhg@mail.gmail.com> <f5080009-c6e8-4dfd-840e-aab95bde5419@www.fastmail.com>
X-PMAS-Software: PreciseMail V3.3 [210104b] (trixy.bergandi.net)
X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists)
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/bIo75I4aexOXfiH6C6_uVTxjX-c>
Subject: Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)
X-BeenThere: emu@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/emu/>
List-Post: <mailto:emu@ietf.org>
List-Help: <mailto:emu-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Jan 2021 21:18:51 -0000


On 1/3/21 10:38 PM, Martin Thomson wrote:
> On Mon, Jan 4, 2021, at 17:18, Joseph Salowey wrote:
>>> # Key Schedule
>>>
>>> The other thing I observe is the way that this slices up the exporter output.  This was something that old versions of TLS did, but TLS 1.3 did away with.  Though RFC 5216 did this, EAP-TLS for TLS 1.3 doesn't need to.  This could - and should - do the same.  All it means is having more exporter labels.
>>>
>>> I appreciate that this uses exporters now rather than abusing the internal PRF.  That's good.  The next step is to dispense with the intermediate values (Key_Material, MSK, EMSK, IV) and all the slicing that occurs and use the TLS exporter for each of the six values that the protocol requires.  I also note that the 0x0D value is used multiple times, unnecessarily, both as a context strong to the exporter and as a prefix to the session ID.
>>>
>> [Joe]  I can see your point, but I don't think the way the keys are
>> derived is wrong and don't really see the need to change it at this
>> point.
> Depends on what you consider "wrong".  In TLS, we did this so that you could exercise good key hygiene.  If you are backing this with PKCS#11, then you might prefer not to be exporting the value of keys just so that you can do some slicing and then re-import the same value.  I see no reason that EAP would be above this.

   I agree with Martin here. The exporter interface should be used with 
labels
to achieve key separation instead of generating a giant blob and slicing and
dicing. If an EAP method doesn't use an EMSK there's no reason it needs to
generate one. Also this will allow for new keys to be defined in the future
by just exporting a new labeled key. It's not that the old way is 
"wrong", it's
that it's clumsy and rigid.

   regards,

   Dan.

-- 
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius