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

Nick Sullivan <nick@cloudflare.com> Thu, 10 October 2019 14:07 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 A5B7D1200C1 for <tls@ietfa.amsl.com>; Thu, 10 Oct 2019 07:07:55 -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=ham 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 7hmgm4rQgjNr for <tls@ietfa.amsl.com>; Thu, 10 Oct 2019 07:07:52 -0700 (PDT)
Received: from mail-vk1-xa2d.google.com (mail-vk1-xa2d.google.com [IPv6:2607:f8b0:4864:20::a2d]) (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 2197C120099 for <tls@ietf.org>; Thu, 10 Oct 2019 07:07:52 -0700 (PDT)
Received: by mail-vk1-xa2d.google.com with SMTP id v78so1366965vke.4 for <tls@ietf.org>; Thu, 10 Oct 2019 07:07:52 -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=/ARW+97LjpsSr/uBJxgkV4R+I4QeI0LHKHlU1qW7jkU=; b=h+2KVkoCey9Lbo4CDmIvP5LpSN/MxPQVqLZ8poO0XNm2qaBP9pJ6I/pOg2GpsrrSin PoYMHTmEPqFLDnF+440bNPrX+xKhP1v6An4tNgH51uFqTRkYRLpHNOXoJH3nCvwvz6/Q eVcMmh6bL91f95Nlq2ayC+HtZlYi1oqduNBgw=
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=/ARW+97LjpsSr/uBJxgkV4R+I4QeI0LHKHlU1qW7jkU=; b=eXlw/mrbPFJDbSAE8wcY8/m402A+o+hseQ8uFXvT+OwUTT6mlIW3kWo48FZguqHTyo cUyBPWh3NY5msJNBqotUy1F8v1iJlgn10ZOyfmUhjaFuAtd8TOtbXiZsyTWLZ/9Ct4l7 ur+0BpC+yPyqndh+RTA6l0Gi9KOFXw56S4YJ/0ivJmeaHzuelAZ1pwv1AZycy9qNhMz2 Xl8e+C2kEewaD5S2XOohDWHW9XUt2qoqNHr24vqwm71aJi1njGLE3ym9BqKhEKbjhbt0 0xLpL8EBLRq/9fl4t4UAGcgb3/iV4AA4FaBU8T5Drj+//n995KazHpmlJlbbxyUUZ7Xl SI9Q==
X-Gm-Message-State: APjAAAVgaCH7Xp1nCla58wdq8bbKgd9NRcItOMQ+9qUBlsQXKnupkGhJ 2M1U3drewWgPlTh5duN9Sd9Pfw2uyFfEeUvKWb+D1dEDEIw=
X-Google-Smtp-Source: APXvYqzmCYbl4U1H1DwUj+e+U6+Rg0BeoopKhrittiR3UxQOqKHXGe/diclT5otwd8WCk8bP5eOonRCqic2pGaqV7sk=
X-Received: by 2002:a1f:1d15:: with SMTP id d21mr5462689vkd.55.1570716470690; Thu, 10 Oct 2019 07:07:50 -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> <CAFDDyk_yoOu01nBPrBj_AVBugFRGUCOthYDysOuAGCrKNWG8dg@mail.gmail.com> <57E5EB36-6A59-45A7-A2F4-1E1626391742@ericsson.com> <CAFDDyk-T_+RHDwEJ+8AQFTvZKykPxwd+A5+8xiZp22bOs48S8w@mail.gmail.com> <0cf4806b-3825-4d25-8be0-13c27533b08d@www.fastmail.com>
In-Reply-To: <0cf4806b-3825-4d25-8be0-13c27533b08d@www.fastmail.com>
From: Nick Sullivan <nick@cloudflare.com>
Date: Thu, 10 Oct 2019 07:07:39 -0700
Message-ID: <CAFDDyk-JyDTfk3JpfvtDZpWcKXE3Nd14oegbeMDetnHkCLr-wA@mail.gmail.com>
To: Martin Thomson <mt@lowentropy.net>
Cc: tls@ietf.org
Content-Type: multipart/alternative; boundary="0000000000004791bd05948eeddb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/re9qsI7N1OCWPD3DkyExz1dbkTo>
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, 10 Oct 2019 14:07:56 -0000

The main concern I had about including DTLS explicitly in this document was
because exporters are not officially defined for DTLS. However, some other
documents assume they are portable so maybe this is an overly conservative
choice.

On Wed, Oct 9, 2019 at 6:26 PM Martin Thomson <mt@lowentropy.net>; wrote:

> I think that the DTLS thing doesn't require as much rewriting as
> observed.  Just say that when you say "TLS" you mean "TLS or DTLS"
> somewhere up front.
>
> As to what a transport needs to provide, I think that there is no real
> text to add regarding DTLS.  You *could* say that as the application
> protocol is responsible for carrying the messages, might find that using a
> DTLS connection introduces new problems.  Specially, these are big messages
> and they are likely to require fragmentation and reassembly if DTLS is
> used.  Also, if the protocol depends on these messages being reliably
> delivered, it will want to provide some sort of loss recovery mechanism.
>
> On Thu, Oct 10, 2019, at 11:47, Nick Sullivan wrote:
> > Thanks again for your review! The PR is on Github
> > (https://github.com/tlswg/tls-exported-authenticator/pull/50) and will
> > be incorporated into a new version of the document that addresses both
> > your comments and those by Yaron Sheffer.
> >
> > On Thu, Sep 19, 2019 at 11:29 PM Christer Holmberg
> > <christer.holmberg@ericsson.com>; wrote:
> > > Hi,
> > >
> > >  >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.
> > >
> > >  I am mostly fine with your answers. Just a couple of comments inline
> still.
> > >
> > >  ---
> > >
> > >  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.
> > >
> > >  Would it then be useful with a statement saying that it might be
> possible to use exporters also with DTLS, but that such usage is outside
> the scope of the document and needs to be specified in a separate document?
> >
> > I added a line to this effect.
> > >
> > >  ---
> > >
> > >  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.
> > >
> > >  I don't think there is any text suggesting that it is disallowed.
> But, if you don't think it is a realistic use case I'll take your word for
> it :)
> > >
> > >  ---
> > >
> > >  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.
> > >
> > >  Ok. Looks good.
> > >
> > >  Regards,
> > >
> > >  Christer
> > >
> > >
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
> >
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>