Re: Genart last call review of draft-ietf-tls-exported-authenticator-09
Nick Sullivan <nick@cloudflare.com> Thu, 10 October 2019 00:47 UTC
Return-Path: <nick@cloudflare.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC40012004C for <ietf@ietfa.amsl.com>; Wed, 9 Oct 2019 17:47:38 -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 6nihwh0cCTFU for <ietf@ietfa.amsl.com>; Wed, 9 Oct 2019 17:47:36 -0700 (PDT)
Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (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 53CCD120044 for <ietf@ietf.org>; Wed, 9 Oct 2019 17:47:36 -0700 (PDT)
Received: by mail-vs1-xe2c.google.com with SMTP id p13so2791112vso.0 for <ietf@ietf.org>; Wed, 09 Oct 2019 17:47:36 -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=zVOD4U0ew60aaYNOGjWx5+/lnjJqAGau6ovEqSGFXb8=; b=DV1W5LIjqxpxUGaJxykrmRc7ATru9JJVPQOGmK7FZt8PP6KYRCKrSiZyrhAYuAWZR2 Rzry8LnjjZEjSndyxUZDHC16fxqNtfJc+LCsB7WtN3qniS7Dal0CU2QBeJuRy+QOejdB k7F8Hbl5N4B3nOy/DgCrp/qlHVnzjTRNnlTEo=
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=zVOD4U0ew60aaYNOGjWx5+/lnjJqAGau6ovEqSGFXb8=; b=qOlYF64HG1XH3dfcDqYO2BjJgUDBujw4TeIGC2jK7nnQ+ABr9vI9pfXy+zhZC0zfuw fkrqETMgAiW2ZcgfamrGj9gVghrqhnoVhZ08QEDEo3TMSKGXLBnFP6oRPQKYzaWs+wkG 30oiGmNW1jO0PQmuixiBVDVRSCmk58cUmEXtfwWKDCwqi4j6GrwtGlx/ovYLDMWfOdwP 56f11POB7SVp16aJEapvMR6UDiBBes+7tt+wpRlnJmdXX7/j0lWP+OSLneuf1ZEN1rLj GUMGKQd0XXA77SVxdq6tvDSVG2GUWZ/HtArbGlv1M9J+110gBhmuGz0stZOvzU/njFqj mhTQ==
X-Gm-Message-State: APjAAAUJFNaLCISch2dGmvlRmUvQLNASA/tVE/IVMTsQ6JTm8BwZEifd VqU6pWMFrhbzgMrInFYnVhM+7x7UBMXNaqutW20yaw==
X-Google-Smtp-Source: APXvYqyoBXc3zuaH0EzKO1vDw85PmnKEZo5E5jJUoZEfYhoEjJE2EwbKT/gDIJrGAB7TMLsOd7q4AFemDXhXCAxc5vE=
X-Received: by 2002:a67:e1d3:: with SMTP id p19mr3587391vsl.212.1570668455149; Wed, 09 Oct 2019 17:47:35 -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>
In-Reply-To: <57E5EB36-6A59-45A7-A2F4-1E1626391742@ericsson.com>
From: Nick Sullivan <nick@cloudflare.com>
Date: Wed, 09 Oct 2019 17:47:18 -0700
Message-ID: <CAFDDyk-T_+RHDwEJ+8AQFTvZKykPxwd+A5+8xiZp22bOs48S8w@mail.gmail.com>
Subject: Re: Genart last call review of draft-ietf-tls-exported-authenticator-09
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="0000000000005506bc059483bf4c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/zgDgubaGr3Q-OfolKvvRyXXj4_c>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Oct 2019 00:47:39 -0000
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 > > >
- Genart last call review of draft-ietf-tls-exporte… Christer Holmberg via Datatracker
- Re: Genart last call review of draft-ietf-tls-exp… Nick Sullivan
- Re: Genart last call review of draft-ietf-tls-exp… Nick Sullivan
- Re: Genart last call review of draft-ietf-tls-exp… Christer Holmberg
- Re: Genart last call review of draft-ietf-tls-exp… Nick Sullivan
- Re: Genart last call review of draft-ietf-tls-exp… Christer Holmberg
- Re: Genart last call review of draft-ietf-tls-exp… Nick Sullivan
- Re: Genart last call review of draft-ietf-tls-exp… Christer Holmberg