Re: [Gen-art] Genart last call review of draft-ietf-tls-exported-authenticator-09
Nick Sullivan <nick@cloudflare.com> Wed, 18 September 2019 21:50 UTC
Return-Path: <nick@cloudflare.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E0C6120043 for <gen-art@ietfa.amsl.com>; Wed, 18 Sep 2019 14:50:17 -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 fCpbE6TOLZtL for <gen-art@ietfa.amsl.com>; Wed, 18 Sep 2019 14:50:14 -0700 (PDT)
Received: from mail-vs1-xe44.google.com (mail-vs1-xe44.google.com [IPv6:2607:f8b0:4864:20::e44]) (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 574F41200E6 for <gen-art@ietf.org>; Wed, 18 Sep 2019 14:50:14 -0700 (PDT)
Received: by mail-vs1-xe44.google.com with SMTP id z14so842178vsz.13 for <gen-art@ietf.org>; Wed, 18 Sep 2019 14:50:14 -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=RdOSOUQb2/M8A9t12+XdvAF27RIdX2BO1PNNkfA8juU=; b=V0+EVPlH9Q9dMWLMYVexBLHgVVoGuATVQmgbTdbGvRtDNF5bCSXoMf/n5ZyDnNvpaD 2j5vfXLvgiS24SUwxSxGyGzgyjCgaEzuiA+WfiDffJ8ubogVVbuqukrcDZHuDJeGGwn6 adfQl1lV2wp+WC7E/nv8DPKaEcUE8PijNJPWk=
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=RdOSOUQb2/M8A9t12+XdvAF27RIdX2BO1PNNkfA8juU=; b=B3p5bx9PBeUQvnAefFBjmigMPc3fErF+PJsE4v0PZxF+Njg9jsbwhfpHV7RuDJ1Zv1 PRGQPU6V7HtqxbpknC1IXqsJHdmoc/RhHHn3aiOaRBrSTPdYrD4BjdAskJiz87mhdpzJ SKBMQ8x+avW6zf3JCF+4l+mAJaIyIjCz00xnVkAXnwJAtVKOhc51QgEFaJJpjgDXBcWU r4LWHF3WQxZUyT2lO2l7eMdegJtYsOp3VWIaEpomsrbR/oeKYENOHccGmilwn3ati7by ddCddUaqBmz1cq1sOOUgaKopAlDc8Tb2Jg4dGp+QGQweX2wo7au4k21wwHZAxw+yM5QS F3vg==
X-Gm-Message-State: APjAAAXT0A/ONV/vEWAJFUC8mWTh/LojO5TT1JM0wNZKRGmqKIFsNt7K /MA7yda7JyFANYDn+vFW3IfgUDX2I3voHptWJdL03w==
X-Google-Smtp-Source: APXvYqwIXDz+TDsJ+XLaGAqThfBNAiEo97v5o6zzWKnS2hMWlM3eli5uuxzPt32JCFOcAlmfVqvHPUFyPRd8WZeE3SI=
X-Received: by 2002:a67:2f4b:: with SMTP id v72mr3632219vsv.212.1568843413014; Wed, 18 Sep 2019 14:50:13 -0700 (PDT)
MIME-Version: 1.0
References: <156249708979.14501.13745976049183757305@ietfa.amsl.com>
In-Reply-To: <156249708979.14501.13745976049183757305@ietfa.amsl.com>
From: Nick Sullivan <nick@cloudflare.com>
Date: Wed, 18 Sep 2019 14:49:56 -0700
Message-ID: <CAFDDyk8iG0R2rT7x-t7fHkFxcYBBkf8j1-mg1xbexoh8gXts6A@mail.gmail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: gen-art@ietf.org, draft-ietf-tls-exported-authenticator.all@ietf.org, ietf@ietf.org, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000577fbc0592dad2f7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/EYgMewuAZt7ZB2o_K8BBvjmE3kc>
Subject: Re: [Gen-art] Genart last call review of draft-ietf-tls-exported-authenticator-09
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Sep 2019 21:50:18 -0000
Hello Christer, Thank you for this thorough review and for waiting so long for my reply. My responses to your comments are inline below and a PR is included here: https://github.com/tlswg/tls-exported-authenticator/pull/50 Nick On Sun, Jul 7, 2019 at 3:58 AM Christer Holmberg via Datatracker < noreply@ietf.org> wrote: > Reviewer: Christer Holmberg > Review result: Ready with Issues > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-tls-exported-authenticator-09 > Reviewer: Christer Holmberg > Review Date: 2019-07-07 > IETF LC End Date: 2019-07-16 > IESG Telechat date: Not scheduled for a telechat > > Summary: The document is well written. However, I have found some issues > that > the author may want to consider clarifying in the document. > > Major issues: N/A > > Minor issues: > > 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. > > 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. > 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. > 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. > > 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. > > Nits/editorial comments: > > 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". > > 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. 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.
- [Gen-art] Genart last call review of draft-ietf-t… Christer Holmberg via Datatracker
- Re: [Gen-art] Genart last call review of draft-ie… Nick Sullivan
- Re: [Gen-art] Genart last call review of draft-ie… Nick Sullivan
- Re: [Gen-art] Genart last call review of draft-ie… Christer Holmberg
- Re: [Gen-art] Genart last call review of draft-ie… Nick Sullivan
- Re: [Gen-art] Genart last call review of draft-ie… Christer Holmberg
- Re: [Gen-art] Genart last call review of draft-ie… Nick Sullivan
- Re: [Gen-art] Genart last call review of draft-ie… Christer Holmberg