Re: [TLS] [Emu] Protected Result Indicators in EAP-TLS 1.3

Benjamin Kaduk <kaduk@mit.edu> Mon, 15 February 2021 02:46 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 42FB83A10A4; Sun, 14 Feb 2021 18:46:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Level:
X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=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 3yytRUWpuEDC; Sun, 14 Feb 2021 18:46:57 -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 52C653A10A6; Sun, 14 Feb 2021 18:46:56 -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 11F2kmUn003695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 14 Feb 2021 21:46:52 -0500
Date: Sun, 14 Feb 2021 18:46:47 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: John Mattsson <john.mattsson@ericsson.com>
Cc: EMU WG <emu@ietf.org>, "TLS@ietf.org" <TLS@ietf.org>
Message-ID: <20210215024647.GD21@kduck.mit.edu>
References: <5AC5852A-118A-4FF5-9754-7693AC505F0C@ericsson.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5AC5852A-118A-4FF5-9754-7693AC505F0C@ericsson.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/hxr65_UaJq0JoP8dqp52wQJIGL0>
Subject: Re: [TLS] [Emu] Protected Result Indicators in EAP-TLS 1.3
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, 15 Feb 2021 02:46:59 -0000

On Wed, Feb 10, 2021 at 10:48:10AM +0000, John Mattsson wrote:
> With Alan's comments, I think we are down to 3 alternatives:
> 
> (1a). Use close_notify alert as protected success.
>       Use error alerts as protected failure.
> 
>      - Forbid close_notify except as success indication
>      - Mandate Error alert before EAP-Failure
>      - Forbid all use of user_cancelled
> 
> (1b). Use close_notify alert as protected success.
>       Use all other alerts as protected failure.
> 
>       - Forbid close_notify except as success indication
>       - Mandate Error alert or user_cancelled before EAP-Failure
> 
> (2). Use application data as protected success.
>      Use all alerts as protected failure.
> 
>     - After sending application data in an EAP-Request the EAP-TLS server MUST send only EAP-Success.
>     - Mandate alert (closure, error) before EAP-Failure
> 
> I think it is important to discuss what the ongoing EMU consensus call will mean in practice. Previous discussions was mostly about not sending more handshake messages. Protected result indicators are quite different.
> 
> It would we very good with early feedback from Ben and the TLS WG if they see problems with any of the alternatives.

On first look it seems like all of those will be able to achieve the
required properties.  In some sense it is "probably" going to be "easier"
for an application using TLS to use TLS application data (as opposed to
alerts) to affect its behavior, though I believe that TLS implementations
generally do provide the needed information about received alerts and
flexibility in what alert to send that's needed for the (1) variants.

Another potential factor that I'm not (currently) equipped to evaluate is
the reusability of the machinery defined by EAP-TLS for use by other EAP
mechanisms.  E.g., if we say that for EAP-TLS any application data is a
protected success, would that be in conflict with any scenarios for the EAP
mechanisms that do have to send some data on the TLS application data
stream?

I'd be happy to hear some more voices from the TLS WG chiming in to
corroborate (or contradict) my conclusions in the first paragraph.

Thanks,

Ben