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

Benjamin Kaduk <kaduk@mit.edu> Thu, 07 January 2021 07:21 UTC

Return-Path: <kaduk@mit.edu>
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 B26173A0407; Wed, 6 Jan 2021 23:21:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level:
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 c1BpR9Fv9ABb; Wed, 6 Jan 2021 23:21:33 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 B21393A0100; Wed, 6 Jan 2021 23:21:33 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 1077LKPU002609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 7 Jan 2021 02:21:24 -0500
Date: Wed, 06 Jan 2021 23:21:20 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: Alan DeKok <aland@deployingradius.com>
Cc: Mohit Sethi M <mohit.m.sethi@ericsson.com>, Martin Thomson <mt@lowentropy.net>, "emu@ietf.org" <emu@ietf.org>, "tls@ietf.org" <tls@ietf.org>
Message-ID: <20210107072120.GI93151@kduck.mit.edu>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <BBC4BCAD-1AA2-4D19-B03E-6A2D5F595509@deployingradius.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/qJsXteQMqIyvveZXzVQ2cZ38-MA>
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: Thu, 07 Jan 2021 07:21:37 -0000

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.

> > 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?

-Ben