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, 01 February 2021 16:22 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 49EA43A12B0; Mon, 1 Feb 2021 08:22:46 -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 Odzcqr97jvyL; Mon, 1 Feb 2021 08:22:44 -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 E5EFE3A12AE; Mon, 1 Feb 2021 08:22:43 -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 026863D6; Mon, 1 Feb 2021 16:22:37 +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: <CABcZeBPES99+xo16=aSDJQbGpzM_Q+k-pWtg424Gu4UAcFbo9Q@mail.gmail.com>
Date: Mon, 01 Feb 2021 11:22:36 -0500
Cc: Benjamin Kaduk <kaduk@mit.edu>, "<tls@ietf.org>" <tls@ietf.org>, Martin Thomson <mt@lowentropy.net>, EMU WG <emu@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <FFE1B807-B055-45DF-84FA-A0D63C058729@deployingradius.com>
References: <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> <20210129183220.GI21@kduck.mit.edu> <1A830492-3404-4BCC-844B-D7D950458BD9@deployingradius.com> <CABcZeBMAtmPfG0rctvO8UvnhPqY1etk=SxnonP_t6ysNxH7hVA@mail.gmail.com> <D6AAF668-86C8-4C5D-AF1E-B37F106A4D1C@deployingradius.com> <CABcZeBPES99+xo16=aSDJQbGpzM_Q+k-pWtg424Gu4UAcFbo9Q@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/kcUWxA9BjxdYyvQy-hb-gN60ouQ>
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 16:22:46 -0000

On Feb 1, 2021, at 11:09 AM, Eric Rescorla <ekr@rtfm.com> wrote:
> That's not what I'm proposing. I'm only talking about the case where the server says this after flight (2).

  OK, my misreading of the text.

> Right. But close_notify is the message that more matches the TLS semantics.

  I agree.

> Ignoring the protocol mechanics, let's just talk about what signals you think the client ought to want to receive. The two I am aware of are:
> 
> 1. From the server's perspective, the TLS handshake is complete.
> 2. The server will not be sending any more handshake messages to the client.
> 
> When client authentication is being used, then for obvious reasons (1) cannot be delivered prior to the server receiving and processing the client's certificate. Agreed?

  Yes.

> Indeed, this seems like a problem with the flow shown in Figure 1, because the server sends Commitment prior to reading the client's cert.

  Yes.

> ISTM that the relevant question is when one might want to receive (2).  In particular, when would the client want to learn that the server will not send any more handshake messages when the client has second flight handshake messages still outstanding? Can you explain to me how this is useful?

  I'm just trying to summarize the discussion so far, and get clarification on exactly what we're trying to do. So take what I say with a grain of salt... I didn't write the text in the current draft.

  The main issue I can see where (2) might be useful is to deal with TLS 1.3's separation of "TLS finished" from other handshake messages.  If the SessionTicket message comes *after* "TLS finished", then it might be in a separate EAP packet.  The client doesn't know that there's an additional handshake until it receives that message.

  So an explicit CloseNotify sent by the server *after* receiving the client certificate would seem useful.  It's an authenticated message saying "yes, I agree we're done".

  If the client cert has issues, the server can send TLS alerts *before* the CloseNotify.  So the client has to either wait for those, OR an explicit CloseNotify, to see if it's (a) rejected, or (b) authenticated

  Alan DeKok.