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

Joseph Salowey <joe@salowey.net> Mon, 15 February 2021 20:22 UTC

Return-Path: <joe@salowey.net>
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 46C3C3A10E6 for <tls@ietfa.amsl.com>; Mon, 15 Feb 2021 12:22:28 -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=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.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 DJhDFKscZ1Zp for <tls@ietfa.amsl.com>; Mon, 15 Feb 2021 12:22:26 -0800 (PST)
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CC353A10E3 for <TLS@ietf.org>; Mon, 15 Feb 2021 12:22:26 -0800 (PST)
Received: by mail-lf1-x12a.google.com with SMTP id z11so12423541lfb.9 for <TLS@ietf.org>; Mon, 15 Feb 2021 12:22:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5OZucVKxeDGnv+QCOannaWXNtFYGbK4x4HwOQXMArEY=; b=macPM1BsYjwXYwrK23HgZ7if1nRbQ0UKDd/BsOZuDq46zMFVkw8f2TMAuDQwiuX1lK R+wPs8z+Ou6rSoSgYED5MFYmG+CZ/sCXPjCNhZ2hXuexc413n4pOy/LMEAM4tAy1FX/v SIM+ueszmn88UnzZFfE6KhEGB6p2NWT20EzAcjUcLFtaUtX6lO5n5Z2NGNDWxzaHCAV6 M04lxWzHYs0o4IPCBCfZQvxQNfCuMpEKHs7xjGaN4hWKgtW1tzLUinXRtfqIyYCY+TtE TFEXSwPhBiU7LJwW2weKCEawl8ET8Pw05cTbiiYWNuauv6QJB9X29B1Pm9xvVPzlo7ZX B+Jg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5OZucVKxeDGnv+QCOannaWXNtFYGbK4x4HwOQXMArEY=; b=gnnZuI+CTPqW8v+R9LxSNBOnXL0e2uX3GRBLzHCh1vLsMPSgYwRAh4nYCoNUPbk8F0 rm5XzfgVYAkTIW2w+ehC2LZLXfDZOVnGf2gXsLAgNTvgjZNwyJrIFFP2zZE8om7Di0xf ICDVJ9m99hExaToXMoI2kPz7qXEigqK7jtEZZVXjwCadsiZOBiXv/641ByYJOk/vtDf6 +Ee0dREv/UtJXWU6sIFgQ3BFGI0ccUc1jEM5mPH1WMuyaJ4hqPvdiL7cCuhSkuA9gEmj iCIDo188k745TeIP8pEqjBMn8pULB/79/GJtQPGwZqj9lFwzPoT2LqqPqc2ViYy7TBDu jFgg==
X-Gm-Message-State: AOAM530C4+xoeq31+t67omn5dhWjPFeTL1KNh1UxRXioVu8eq8/M68vO YyXv/aXNH7hI2ZBH/968vAIJXfnMe64ieC6LKN0sXA==
X-Google-Smtp-Source: ABdhPJylTt4JB05VXcmymlxXC06eXzNFxR4rPSgENHJiThS/z7Y/yEYaLskP9fU0zzg/fTOUpNTpGYg9byiG5rG+kR0=
X-Received: by 2002:a05:6512:ad3:: with SMTP id n19mr10004536lfu.328.1613420544218; Mon, 15 Feb 2021 12:22:24 -0800 (PST)
MIME-Version: 1.0
References: <5AC5852A-118A-4FF5-9754-7693AC505F0C@ericsson.com> <20210215024647.GD21@kduck.mit.edu>
In-Reply-To: <20210215024647.GD21@kduck.mit.edu>
From: Joseph Salowey <joe@salowey.net>
Date: Mon, 15 Feb 2021 12:22:12 -0800
Message-ID: <CAOgPGoDAaXJ1yLjiczuXi9eoWodOh4kdbCWGg2hvwbo_DbYS6w@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: John Mattsson <john.mattsson@ericsson.com>, EMU WG <emu@ietf.org>, "TLS@ietf.org" <TLS@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000696a1f05bb65bea9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/V-PTqtPglwcCqUypblK8dJzq-GI>
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 20:22:28 -0000

On Sun, Feb 14, 2021 at 6:47 PM Benjamin Kaduk <kaduk@mit.edu> wrote:

> 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.
>
>
[Joe] In the past handling of close_notify was one of the rougher parts of
TLS implementations.  I'm not sure how much it has improved.


> 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?
>
>
[Joe]  TEAP already has a result indicator within the tunnel, so it would
not need to use the same machinery.  I believe that many of the other
tunnel methods have something similar, so I would expect tunneled methods
to use their own mechanism as a result indication.


> 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
>
> _______________________________________________
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>