Re: [TLS] Genart last call review of draft-ietf-tls-exported-authenticator-09

Nick Sullivan <nick@cloudflare.com> Thu, 19 September 2019 22:57 UTC

Return-Path: <nick@cloudflare.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 EC6DA120043 for <tls@ietfa.amsl.com>; Thu, 19 Sep 2019 15:57:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.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 RUreqc_9qd-V for <tls@ietfa.amsl.com>; Thu, 19 Sep 2019 15:57:37 -0700 (PDT)
Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a]) (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 8D90C120052 for <tls@ietf.org>; Thu, 19 Sep 2019 15:57:37 -0700 (PDT)
Received: by mail-vs1-xe2a.google.com with SMTP id w195so3409101vsw.11 for <tls@ietf.org>; Thu, 19 Sep 2019 15:57:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=a1rnjiqvDBtMybTh1hVUOcJ1rM0dRXGcPEtuvTjdQ4k=; b=JZWKD1hK0d5b/UiBpkJI/+zvdUvhp6lwmxs5hWbPdJ14wrB0YCiCUN7PvG/Iwcvwi4 JDajfPQ5N5ccTqTSuEFEeTkIm1qZFkvbksvvQUWYGNX9LGjmjGDxWXsmj2BJsQARmwYq Ui0MRZYWpnFuXZzWU+b7NvWhBvVRBJFj3gdx8=
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=a1rnjiqvDBtMybTh1hVUOcJ1rM0dRXGcPEtuvTjdQ4k=; b=CYkyDd/ENBRT2UiPj2SOU7dC+Eyj3GFaQw7vjdbTLbhSXa4lR1veBylQw9aTFrvr5s RkHCc3K9A01bFeBR8QYy7Pg9M3ENofmTeZI7HGEV/iQP2qQhmDKGXVPp6/nvFnr+5VDz JkRx7B8Is4nHnVWQgDgdem8WMmlIW7k+CZu2AxRZmu3u97B1l4b8XbwpNtsbcLAFB1bk 6X4c7N+fx0k1hBiBQMLzV9zIMXWbEiVo+2r3ExD5iTAvuqCXiyKNY94BGcM2pe7Zc9pw qLGU8KXhs1BFRol9vNraCtUfm2hr5uQukovl6LoeOxA+Fafm50qFojVRhg0cx4EOhz6U vdnw==
X-Gm-Message-State: APjAAAWy55M/CkRolN2M4xdDLTSiWON5CAKZA+yvDWAamPbLY1v7Vl5v PVs4wCW1SZl0B0JNnWZxjCWrMp9Ti09sqR5ATeXvBg==
X-Google-Smtp-Source: APXvYqzTsgbNPzLQ1qY6g+fwR33q53s97lJS7KdD66ULnodmmv10Qi37BsIVPHzNJ485ocYFnR4lQ2DT5iDJbSasJOA=
X-Received: by 2002:a67:dc13:: with SMTP id x19mr294899vsj.172.1568933856400; Thu, 19 Sep 2019 15:57:36 -0700 (PDT)
MIME-Version: 1.0
References: <156249708979.14501.13745976049183757305@ietfa.amsl.com> <CAFDDyk8iG0R2rT7x-t7fHkFxcYBBkf8j1-mg1xbexoh8gXts6A@mail.gmail.com> <7BDE969A-7B5F-4979-B4E9-7E6C03C0A1B1@ericsson.com>
In-Reply-To: <7BDE969A-7B5F-4979-B4E9-7E6C03C0A1B1@ericsson.com>
From: Nick Sullivan <nick@cloudflare.com>
Date: Thu, 19 Sep 2019 15:57:20 -0700
Message-ID: <CAFDDyk_yoOu01nBPrBj_AVBugFRGUCOthYDysOuAGCrKNWG8dg@mail.gmail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: "gen-art@ietf.org" <gen-art@ietf.org>, "draft-ietf-tls-exported-authenticator.all@ietf.org" <draft-ietf-tls-exported-authenticator.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000030254e0592efe1ef"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/s_sq0NVZvmbeka5rpbVaEwAHSzw>
Subject: Re: [TLS] Genart last call review of draft-ietf-tls-exported-authenticator-09
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, 19 Sep 2019 22:57:41 -0000

Thanks Christer,

Some answers to your questions inline. I'm not sure further changes along
the lines suggested here are needed, but I'm open to arguments that point
in that direction.

On Thu, Sep 19, 2019 at 1:55 AM Christer Holmberg <
christer.holmberg@ericsson.com>; wrote:

> Hi Nick,
>
> Thanks for your reply! Please see inline.
>
> >>MIN_1:
> >>The last sentence of Section 1 says that the mechanism requires TLS
> version 1.2
> >>or later. Would it be useful to state that in a dedicated Applicability
> section?
> >
> > I'm disinclined to include an applicability section considering how
> short it would be.
> > I'm open to being convinced otherwise with examples.
>
> If others think it's clear enough (or, that it doesn't need to be that
> clear, because earlier versions will anyway disappear), I am fine to keep
> in in Section 1.
>
> ---
>
> >> MIN_2:
> >> Can the mechanism be used also for DTLS?
> >
> > I think the answer is yes. I don't see any reason to disallow the use of
> Exported Authenticators in DTLS.
>
> Would it be useful to clarify that?
>

Going through what the modified text would look like, it seems like a
substantial amount of re-writing (even the title!) for what amounts to an
unclear use case. Keeping in mind that DTLS 1.3 hasn't been finalized and
doesn't directly define exporters, I'm disinclined to define how EAs would
work with DTLS. If someone has a strong use case for EA in DTLS, it may be
worth considering it.


>
> ---
>
> >> MIN_3:
> >> The documents talk about additional certificates. If I only have one
> additional
> >> certificate, can I use that for multiple authenticators throughout the
> TLS
> >> session?
> >
> > Yes, there is nothing disallowing the creation of multiple exported
> authenticators with the same certificate.
>
> Would it be useful to clarify that?
>

I'm not convinced this is a realistic use case. Since exported
authenticators are based on the exporter, there is no inherent ordering. If
you re-authenticate with the same certificate, there's nothing asserting
freshness of the second certificate. Is there something in the text that
suggests that using a certificate multiple times is disallowed? If there's
no suggestion that this is not possible that needs to be corrected, I don't
see the benefit of calling out this specific use case.

>
> ---
>
> >> MIN_4:
> >> Section 3 and 4 say that the authenticator request and authenticator
> SHOULD be
> >> sent using TLS, and Section 1 says that the proof of authentication can
> be sent
> >>out-of-band. I think it would be useful to clarify whether both the
> >>authenticator request and authenticator can be sent out-of-band ( i.e.,
> not
> >>using the TLS connection that the additional authentication is associated
> >>with), and also to state whether it IS allowed to send the authenticator
> >>request and authenticator on the TLS connection they are associated with.
> >
> > Good point. I can clarify this a bit. Both the authenticator and
> authenticator request can be sent
> > through either the TLS connection they were derived from or another TLS
> connection altogether.
> > The important part is that they are sent over an encrypted and
> authenticated connection.
>
> Thanks!
>
> ---
>
> >> MIN_5:
> >> Section 5 talks about an endpoint sending an empty authenticator. But,
> what if
> >> the sender of the authenticator request does not receive anything?
> Does it
> >> simply move on? Does it terminate the TLS session? Is the action based
> on local
> >> policy?
> >
> > The TLS layer is stateless. The decision to time out or fail the
> connection if an authenticator request
> > is not responded to is left to higher-level protocols that leverage EAs.
> >
> >> MIN_6:
> >> Related to MIN_5, I can't find text about how endpoints inform each
> other about
> >> the support of the mechanism, so maybe a few words about that would be
> useful.
> >> And some words about backward compatibility with endpoints that don't
> support
> >> the mechanism.
> >
> > Adding an extension to signal support for exported authenticators was
> discussed at some point,
> > but it was decided that the higher-layer application should handle the
> signaling.
> >
> >> MIN_7:
> >> What happens if the validation of an authenticator fails? Does the
> requester
> >> simply move on? Does it terminate the TLS session? Is the action based
> on local
> >> policy?
> >
> > This is also up to the application-layer protocol. I'll add text
> covering MIN_5, MIN_6 and MIN_7.
>
> Thanks!
>
> ---
>
> >> ED_1:
> >> The document uses "session", "TLS connection" and "TLS communication"
> >> terminology. Is that intentional, or wouuld it be possible to use
> consistent
> >> terminology?
> > Good note. I'll standardize on "connection".
>
> Thanks!
>
> ---
>
> >> ED_2:
> >> Section 3 says: "The authenticator request is a structured message that
> can be
> >> created..." Section 4 says: "The authenticator is a structured message
> that can
> >> be exported..."
> >>
> >> In the 2nd paragraph of Section 4 it is stated that "authenticator" is
> sent
> >> based on an "authenticator request". I wonder if that could be stated
> already
> >> in the beginning of Section 4, to further clarify the difference
> between them.
> >> E.g.,
> >>
> >> "The authenticator is a structured message, triggered by an
> authenticator
> >> request, that can be exported from either party of a TLS connection."
> >
> > The issue is that servers can generate spontaneous exported
> authenticators without
> > an authenticator request.
>
> Where is this written? Did I miss it?
>

Section 4:

   An authenticator message can be constructed by either the client or
   the server given an established TLS connection, a certificate, and a
   corresponding private key.  Clients MUST NOT send an authenticator
   without a preceding authenticator request; *for servers an
   authenticator request is optional*.  For authenticators that do not
   correspond to authenticator requests, the certificate_request_context

   is chosen by the server.


>
> > Given this, the updated sentence would be:
> >
> > "The authenticator is a structured message, sometimes triggered by an
> authenticator
> > request, that can be exported from either party of a TLS connection."
> > Which I'm not sure is an improvement to readability.
>
> I agree that "sometimes triggered" does not improve readability, but
> doesn't there still always have to be at least one authenticator request
> before any authenticator is sent?
>
> Regards,
>
> Christer
>
>
>