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

Mohit Sethi M <mohit.m.sethi@ericsson.com> Fri, 08 January 2021 08:16 UTC

Return-Path: <mohit.m.sethi@ericsson.com>
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 507113A0A4A; Fri, 8 Jan 2021 00:16:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.613
X-Spam-Level:
X-Spam-Status: No, score=-2.613 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, NICE_REPLY_A=-0.262, 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 yrti5FLm6q4K; Fri, 8 Jan 2021 00:16:27 -0800 (PST)
Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2058.outbound.protection.outlook.com [40.107.22.58]) (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 D54163A091C; Fri, 8 Jan 2021 00:16:26 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hpOdacXh0zCy5npQMmMNCbtP55yKTdhinEh6R86DtWXECANoS1V1VC2PuIycZMVjOw7xbP5dNktMgxCJwUWs/i4FrRVLeck9RuPiwQzqXddV/SmIOO8uINaeHIcFN683JzEY7fr0GGZPXTQ+QQO5waF4+LQQMAztZjJ4DBCZ7eRTGq0eS53jbTHYOgvUTw7JHLY0gaH8HkWyJkhuhoZUcpHRqLd/9CoB1roQdLN7jWdJMCTTqp2df/K5ETZ1QJkv3w/fbv0/ibgkerUFF2TbC46UiPIruu5oKHgd8hT6Yv3S2s236eg9J0ge745qbcYZdf2VyKii76k1Jdw7LwweLw==
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=Nr19CnG/8L7aNF9Dh0Qa9VVZskkfmYVGACZZcP9Acg8=; b=cCKe5ZILDYQDNu3ld5bNiP+ZDQ6llaVJNi6bG/u3kOWShLHr0ObJED/cot+CUWMeCh5Pb90ZkAH8B5w/os2tRd5T71OVDx6RmicbmT6vD91JCxibzovgcKrv3Vqpdh/g3wp4B0GKyavIeNsu2TY+ZcDywZBcgonB6kduS/h2tiNnlOYqi0/I18gDsl1L6UblSGuv2u2lvxE2W1wt9QnRJpTKG/tN6IOrF9mHMHwyO9X50G/eSbkDLgP4ypye/f9Pe/L20C0R1kZmYhGMFHkaIJ6mDzazRYsuZYYrMPENTXg8/QDgu9KPTdyfVbnx7OFikEEw37KXusDI2zlXRyIKvw==
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=Nr19CnG/8L7aNF9Dh0Qa9VVZskkfmYVGACZZcP9Acg8=; b=YLzxKNt4sVR7tWlV4arN/iy1vtVyu8m1hJW27k/toylK2o1LIWno83k1mI92tuk6kbZCIR2zjibczT5h+mJrFS0dNZVTAaTfndAOnT9tsdhNGpuBUE1iXh7PaBYOpYs7nLdB4FDZ0Ohumqjqqn8wIAce939VqkENZqELftuQN0A=
Received: from HE1PR0701MB2394.eurprd07.prod.outlook.com (2603:10a6:3:70::13) by HE1PR07MB3434.eurprd07.prod.outlook.com (2603:10a6:7:2c::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.4; Fri, 8 Jan 2021 08:16:21 +0000
Received: from HE1PR0701MB2394.eurprd07.prod.outlook.com ([fe80::a012:f1c5:3df:a9d7]) by HE1PR0701MB2394.eurprd07.prod.outlook.com ([fe80::a012:f1c5:3df:a9d7%12]) with mapi id 15.20.3742.010; Fri, 8 Jan 2021 08:16:21 +0000
From: Mohit Sethi M <mohit.m.sethi@ericsson.com>
To: Benjamin Kaduk <kaduk@mit.edu>, Alan DeKok <aland@deployingradius.com>
CC: Mohit Sethi M <mohit.m.sethi@ericsson.com>, "emu@ietf.org" <emu@ietf.org>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)
Thread-Index: AQHW40fFS0YPtTFHBEWM+84ed4Ivm6oZLAEAgAKY0wCAAaGzAA==
Date: Fri, 08 Jan 2021 08:16:21 +0000
Message-ID: <c7c607b6-3854-a513-30a8-58764539a73b@ericsson.com>
References: <160815821055.25925.15897627611548078426@ietfa.amsl.com> <20201216223842.GR64351@kduck.mit.edu> <0f2b05db-5c98-43d4-aae3-cf620814bacc@www.fastmail.com> <7745bb87-a946-c739-007d-9d3be1212e19@ericsson.com> <bddc3a92-acd1-46cc-84ad-aea013c544cf@www.fastmail.com> <5E1CF713-D917-4E9A-869F-21A4174D0562@deployingradius.com> <5ec5d8a2-a8ee-40b5-9b43-3d1bde2b0032@www.fastmail.com> <20210105052640.GO93151@kduck.mit.edu> <2aa31d9d-0603-5c5e-de3c-0dc780516863@ericsson.com> <BBC4BCAD-1AA2-4D19-B03E-6A2D5F595509@deployingradius.com> <20210107072120.GI93151@kduck.mit.edu>
In-Reply-To: <20210107072120.GI93151@kduck.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [188.67.160.225]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: a14e2ece-0070-4dd3-1aae-08d8b3adaee9
x-ms-traffictypediagnostic: HE1PR07MB3434:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <HE1PR07MB343431EBBAE733C5604C45D8D0AE0@HE1PR07MB3434.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 6gDZDaQAIxZqA8xPgE8c33wfx6O7E+tXu9slPPQ6wU/DsQkB0ltxcko7r4RQ3X6CVTZGWNXar4uXL8qF1zPdqn5qhqS9YX17EEhlPy7HN+Gt8IUfu4AAf3jWVkRa+O6hNzGg1l3yzgSaTAwR3TpBHqJIB9OzihK92KJpwv7I82YwTG5i6/vL5m/gJ4uxzejpU8aagU4m4qXB/mGE4moCkHsdjWuMK6sV0X3eZ+vHA6YmRhCVENse9FyGDNRAty5UW9FuTxFzCaWmHStLvOgqmFzF36oYv1/cInVWosyPSwbclvditt5FSEzUBSHeoD01Feaw2L6rr8DNLF1VFvwovmqLexxfiJ5c2pJcnuvqzuiWslJ89ScEtbQu+8b3GYr8aIbd2HEU7Lcj++OYrHKkyPgK1l4B5ylLXdesNO1ubg2P+JmOnMg9IeAwBMP1Ppxwgu4fwM+0mXFIaCpW9cZCHh4jbjWzxK4ORGeHgBRm1dW4bCy32SFU0hy82hSOHJn5WB2IOSeyNZubw2beQVVWelDYfQdy/TPRZC7nMPcxNAjfKO83Dbtbd1ovhM/9X5TJ
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0701MB2394.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(366004)(346002)(136003)(39860400002)(396003)(66476007)(66446008)(53546011)(66556008)(26005)(110136005)(186003)(64756008)(71200400001)(2616005)(8936002)(54906003)(76116006)(36756003)(66946007)(316002)(86362001)(966005)(4326008)(478600001)(6512007)(31696002)(83380400001)(6486002)(5660300002)(8676002)(6506007)(31686004)(2906002)(43740500002)(45980500001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: /2n5WISsQEkRkieVEwQUx9ldl6ww3wUQbGTJoH5L2i02Tn3CgYTJeTCafFEDUbDDrhIQaoU1Zg9Tjjlr533MMTy4VI1ehYVXKvOLkMVxQ46KBthgPnRjz/Y6/v/vJGfOoaoY/A8mozJ5NQdrKwDPvZwudnIJAfpJiWB+9vinpproak1v4ly/0cKwMS80363tPGEHgfFErcf/MWSUe2lEG+ALpzKKiVLgz44u9REaiJJKC1l75+nOKmuZgO1Q/obJjCA+cEyDmUWcxDNgLcoXqfBzA2m2S1EcH/ZJ9QmY4mZTWtdiC1t0VGqXPJiEn6L2c0u2xs+GBpe7HwnI77Ass7AlivlKRkVROc5E4fxtbL6sbFJUqQsPkmz2aNp2rHFagF6VssNZfWvSu/u97FDuG1i2uQhOqiJYJ3aa6SJhIe+vw7tmYZOwRpvvhcVPH/3wMuytHmyErRXVEIfzKIBcvAQogwhRYw6mPf5DEHkAacLIFAwHvRZnxgoqKOT3TZY/eUhq9qytm7YOUgu012uhTdUwlw36TS63xX82pXmyDAQpjnxL5uf5zCOUbOgCTxS06bUXasdlp2k5m1fy6cCz6zIe6mGVpTwo/FFMAUFcDdyqd++tdJ0fheO7uoCHjt5ArdKDJ7vXLiWP1xxAO6fVpH+3bRqCMg9aI2UwiX8DLBfcveJHlykgcpz+kSUtV2B5fQvxF8QQfvuxDrtIzUR8Si+jddIDQbpK41SXkuKeGraE5IUS6T2x0AyCpcZ7snUrOIMsLLwFcUSTSMuvGWiCBeo9vfyBcsn7MQAh4FD3xM8VbVE8GWlvGqcQrHNx8ZGD2BSyDl/ESyNuvEkkVnOmWnMxsjMw8+B188OgYPOqCksh4RhAYXLY0ec8LZWYBG+/h0BvIfDGJms5vKFJXBCKjKVme3FGNN7cMz3ICsx/eJ8EvTfdPtZRl+b8ZaKz3WThZrc4aGJfrMO8NqE9XI207GO2BT1D1Z41ErS0iH+w0JQ=
Content-Type: text/plain; charset="utf-8"
Content-ID: <F4E3D0EE4AA15D4195980D05885B58F7@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: HE1PR0701MB2394.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a14e2ece-0070-4dd3-1aae-08d8b3adaee9
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2021 08:16:21.7261 (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: bYdYylaI1lWNs5U7sX6+ja/cI9fh4Nh0MMfMW15K8BxaGb4A7Pzrz864MNslXjNxo3/elJ6iSQ1Y3hmQaV4CL1ynqyTrvHrUC6NsOsNc0kY=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3434
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/zjdSjTdmd_Gk57d--1bZHRrIyQI>
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: Fri, 08 Jan 2021 08:16:29 -0000

Hi Ben,

On 1/7/21 9:21 AM, Benjamin Kaduk wrote:
> On Tue, Jan 05, 2021 at 10:41:50AM -0500, Alan DeKok wrote:
>> On Jan 5, 2021, at 4:47 AM, Mohit Sethi M <mohit.m.sethi@ericsson.com> wrote:
>>> What I am gathering is that this commitment message should instead be
>>> made into a confirmation message, i.e. it should only be sent after
>>> receiving TLS Finished from the client? This would result in one extra
> I forget if it has been explicitly mentioned in the thread so far, but
> https://tools.ietf.org/html/rfc8446#section-4.4.4 is pretty clear that
> "Servers MAY send data after sending their first flight, but because the
> handshake is not yet complete, they have no assurance of either the peer's
> identity or its liveness (i.e., the ClientHello might have been replayed)."
> In particular, "no assurance of the peer's identity" means that the server
> is at this point sending to an unauthenticated client.  If the goal of
> EAP-TLS is to ascertain that there is in fact an authenticated client, it
> may be ill-advised to send indications of overall success to an
> unauthenticated client.  Part of what Martin alluded to with the situation
> being lousy overall is that there are basically two things that can
> cryptographically confirm that the client has authenticated: successful
> processing of the client Finished, and values derived from the resumption
> master secret.  In "normal" TLS usage the server will bail out if the
> client Finished doesn't validate, so continued receipt of application data,
> including application data bearing application-protocol responses to data
> the client sent in 1-RTT after client Finished, effectively implies that
> the server validated the client Finished, but the EAP-TLS usage is quite
> different from that.  There's not a cryptographic way to tell whether 0x00
> application data was generated before or after the client Finished was
> processed.
Yes, this was discussed. See email from Hannes 
(https://mailarchive.ietf.org/arch/msg/emu/Vf4Zor-xIDVZLQB-BE9mPvlDZMM/) 
where we did look at the text from RFC 8446 about the peer being 
unauthenticated. It was (at that time) accepted since the server was 
only committing to not sending more post-handshake messages (rather than 
indicating successful completion of handshake).
>
>>> round trip to both figure 1 and 3 in the current draft. So we would end
>>> up with the same number of messages as RFC 5216 for full authentication
>>> (https://tools.ietf.org/html/rfc5216#section-2.1.1) and actually do
>>> worse than RFC 5216 (one extra round trip) in case resumption
>>> (https://tools.ietf.org/html/rfc5216#section-2.1.2).
>>    That sounds right.
> While counting arrows in the diagram like this is definitely useful, part
> of my concerns related to the need (in non-resumption flows) to convey the
> entire (enlarged) server Certificate chain in individual 1020-byte
> EAP-Requests.  My understanding was that the server had to send a single
> 1020-byte EAP-Request and wait for the corresponding EAP-Response before
> sending the next chunk of the certificate chain.  It was in that scenario
> that I expected a substantial difference between resumption and
> non-resumption.
>
>>> Maybe this is acceptable? The draft anyway notes that "Sending the
>>> Commitment Message in a separate EAP-Request adds an additional
>>> round-trip, but may be necessary in TLS implementations that only
>>> implement a subset of TLS 1.3.". In which case, I am not sure if the
>>> reasons against using close_notify apply anymore.
>>    I won't offer opinions on TLS internals, as I'm out of my depth there.
>>
>>    As an implementor, the priority is getting TLS alerts (expired cert, etc.) back from the EAP server to the EAP peer.  Those messages can then be used to debug deployment issues.
>>
>>    The exact method of doing this is less important.  The "0x00" octet works now, so I'm happy with it.  But if TLS review decides that should change, that's fine, too.
> It's pretty much guaranteed that we can get the TLS alerts if we always
> wait for client Finished to be processed (whatever signal we end up
> choosing to send after that occurs).  Have we reached agreement on whether
> we should always wait for client Finished?

I hope so. I'll try to submit an update next week.

--Mohit

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