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

Joseph Salowey <joe@salowey.net> Mon, 01 February 2021 20:01 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 4905F3A1599 for <tls@ietfa.amsl.com>; Mon, 1 Feb 2021 12:01:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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 c8RG2xI335UH for <tls@ietfa.amsl.com>; Mon, 1 Feb 2021 12:01:01 -0800 (PST)
Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 C28B23A15A1 for <tls@ietf.org>; Mon, 1 Feb 2021 12:00:46 -0800 (PST)
Received: by mail-lf1-x134.google.com with SMTP id f1so24556813lfu.3 for <tls@ietf.org>; Mon, 01 Feb 2021 12:00:46 -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=A6KSPtHjH3iDjUMjH8WXDuEmCv8JT+GMTaQiBwxqpV4=; b=lq9/PK8Rck9Bmc24RNNaVxQvxFQzaYW0Sy5GneZaaspnSDhAI0B6CNO302FwVj1bQa F8s9Gwjgub7EX44IscDcmAhBrNhjZn6nzqiLOuAA9cqK5FEZA041BHl5281p73uE6jXM SsmMLssXkLTtEE+5W1ukdC9TPdqefAPJVoHBqZRuH9iOSBWfBRZ5EZe/aHk7tRc+q5s5 c4ufGeuyKbQejnf1C7imseBmPpGX9KWZRt+N8cQZKzeJIoUnEzORPis6AH1ZOTL1Igh0 LkeYet9OoLzptDEF8BpkCKdcqkbqJyyZNEesg2vQk2V6RfcagndiXMUCkoMScuOGpJ5G shFQ==
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=A6KSPtHjH3iDjUMjH8WXDuEmCv8JT+GMTaQiBwxqpV4=; b=j6g5rki7VNdsUlz4DNATEU558XjtCz+tL+0tmUpjy18SvjO5U7sfzY0zDl9U+7/HJz JJ3olN5aKinKRa4YMJqMAAIsy6DSqMcyKTpVarM8yFNESaNKKFjQlNMF6a8AWRVx7KZn vDuyP6pbASP9jxfgwiTcosx2qmlH6fEZlS1Q4k3wyWH/+pkq5j0QiSgAje0tiZPDah/M LTHOjyuypxtloxiX56SuFV9agylnUqJ0tjV5HI58eycuZWWthNikd9JEFK2cUqv2vLH5 wdUWHnCJ4wdCLFVUdxkVfrXN9oeRALLA7VJrmXNDvgrlcyrLxQkaHXOGtsGiTBG3628A fjIg==
X-Gm-Message-State: AOAM533I5W5nrRjGml51+zufgOBCOVeQw/k4/LTVr2QCfvK3Qe5mXCt8 GVuvgPx9Z16cyIMzPN3mvWSLoyAczCif7DKzLgVIaA==
X-Google-Smtp-Source: ABdhPJzPUzQ0nXrfcGDoGdb45DB1/zpPU7RKUXg0gkpJKkuQeRb6DBPdh+p7h4SLhEu/9AUARDYENyR8FJEWay9VWeE=
X-Received: by 2002:a19:a47:: with SMTP id 68mr4274633lfk.525.1612209644746; Mon, 01 Feb 2021 12:00:44 -0800 (PST)
MIME-Version: 1.0
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> <FFE1B807-B055-45DF-84FA-A0D63C058729@deployingradius.com> <CABcZeBMeR-kH_P_Lq9X8sOCvZ=u8_tGEOE2QErKX--Tk3cEg=Q@mail.gmail.com> <9E25ADFC-16F2-4719-B223-E34598633D2B@deployingradius.com> <CAOgPGoCANLd0hisu5cLtb=FKa-TKy2ixrSvJ0dAUVLef9F1L0A@mail.gmail.com> <34757A81-4918-4B48-9ECC-533DB861992A@deployingradius.com>
In-Reply-To: <34757A81-4918-4B48-9ECC-533DB861992A@deployingradius.com>
From: Joseph Salowey <joe@salowey.net>
Date: Mon, 01 Feb 2021 12:00:33 -0800
Message-ID: <CAOgPGoA1boAcWyV9cn6_uXvCRPEBkAUeg2f8u8FaPPk=54tRSw@mail.gmail.com>
To: Alan DeKok <aland@deployingradius.com>
Cc: Eric Rescorla <ekr@rtfm.com>, EMU WG <emu@ietf.org>, Benjamin Kaduk <kaduk@mit.edu>, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002dcd8205ba4bcfc4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/usTlIEdsbGPTthxxpFckuF6GBsk>
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 20:01:10 -0000

On Mon, Feb 1, 2021 at 11:55 AM Alan DeKok <aland@deployingradius.com>
wrote:

> On Feb 1, 2021, at 2:32 PM, Joseph Salowey <joe@salowey.net> wrote:
> >
> >
> >
> > On Mon, Feb 1, 2021 at 11:25 AM Alan DeKok <aland@deployingradius.com>
> wrote:
> > On Feb 1, 2021, at 11:26 AM, Eric Rescorla <ekr@rtfm.com> wrote:
> > > Yes, this is what I have in mind. So, maybe there's never any need for
> the server to say "I won't say anything more" after just one round trip?
> >
> >   I think so, yes.
> >
> >   That means of course EAP-TLS will always require 4.5 round trips.
> >
> > [Joe] I don't follow why this means 4.5 round trips would be required.
>
>   If the CloseNotify signal is sent by the server *after* it receives the
> client certs, then another round trip is required.  At least, according to
> Figure 1 of draft-13.
>
>   The CloseNotify can't be sent with the EAP-Success, because the
> EAP-Success can't carry data.  So the packet flow looks something like this:
>
>
[Joe] What purpose is the CloseNotify serving? RFC 5216 does not require
CloseNotify.


>    EAP-TLS Peer                                      EAP-TLS Server
>
>                                                         EAP-Request/
>                                 <--------                  Identity
>    EAP-Response/
>    Identity (Privacy-Friendly)  -------->
>                                                         EAP-Request/
>                                                    EAP-Type=EAP-TLS
>                                 <--------                (TLS Start)
>    EAP-Response/
>    EAP-Type=EAP-TLS
>   (TLS ClientHello)             -------->
>                                                         EAP-Request/
>                                                    EAP-Type=EAP-TLS
>                                                    (TLS ServerHello,
>                                             TLS EncryptedExtensions,
>                                              TLS CertificateRequest,
>                                                     TLS Certificate,
>                                               TLS CertificateVerify,
>                                 <-------            TLS Finished)
>    EAP-Response/
>    EAP-Type=EAP-TLS
>   (TLS Certificate,
>    TLS CertificateVerify,
>    TLS Finished)                -------->
>
>                                                             EAP-Request/
>                                                    EAP-Type=EAP-TLS
>                             <--------        (TLS CloseNotify)
>
>    EAP-Response/
>    EAP-Type=EAP-TLS
>     (TLS Ack)                 -------->
>                                 <--------               EAP-Success