Re: [TLS] Secdir last call review of draft-ietf-tls-exported-authenticator-09
Nick Sullivan <nick@cloudflare.com> Mon, 04 November 2019 02:50 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 1CA55120981 for <tls@ietfa.amsl.com>; Sun, 3 Nov 2019 18:50:00 -0800 (PST)
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 rZC0-TzbviWs for <tls@ietfa.amsl.com>; Sun, 3 Nov 2019 18:49:55 -0800 (PST)
Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (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 59B15120958 for <tls@ietf.org>; Sun, 3 Nov 2019 18:49:54 -0800 (PST)
Received: by mail-wm1-x332.google.com with SMTP id q70so14971013wme.1 for <tls@ietf.org>; Sun, 03 Nov 2019 18:49:54 -0800 (PST)
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=2IC6GMmbJ7k7u88sWMlQMEKdPS9L3CmYKPj8Fwm3JyU=; b=NIgmuS6rzbh8f6geYJ2YkUnDVCtXFpzp6XdL++0ulJ/Maz48fFmu3UZ1V+RPOE7MPX HyKcXmAwHuWYyJe58oeXIjg2jd5FTU2e3KTFb1Zkf7cxO0+lxeOknGOI8tpt1U8DQaKy INSN6z9f0tvmxRMBKHsMPFj1ZNv20zNqyE7rY=
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=2IC6GMmbJ7k7u88sWMlQMEKdPS9L3CmYKPj8Fwm3JyU=; b=Lpf7gXnMlWooqocc1LgvJKD6592oNM2TOULWAby0chINPDfHSjnI0xO5YZRsgMk4Y7 gw033qY9WucYt6+rjd4wohgdn5Srx17N6CnsmxUAl/Mr0lH9DE3z3qoVgGuBDQ7NclMM TPyE6DracvDISF51Tvvpwl774VFH+IbM+8qZAfMQHhlh5kECyHaH8ZqNC+xIl6sBTa9J eFC1NyNAT8IJk3tS968JLMkFBh/MGO28TzONvwJHodFjP1pHEw68wo1XDUKS2Wmc1CnD nRIkL38uN9td4mKJqyVwaIjJkeLVOXwWla+PSTTL0uTr1ZGqdgFYTG0eCCMtoLjcfOEo LUdg==
X-Gm-Message-State: APjAAAU09thL1Tx52tTxk/dxoGuyra/a+29a213UzlNb4/bml/pkoeo6 l9yPrW2Sd7BBLz5IDOWAyf0zJPp5BP632N67sEhkHQ==
X-Google-Smtp-Source: APXvYqxfPNR2fEA1ymACxfVJMn+s1by5Rms2jMrkYM9/QqrZSCuxkvqAj56tHZ1nUWIA2zFVz1ZnNJhwXg+9ZpGNhGI=
X-Received: by 2002:a1c:6a1a:: with SMTP id f26mr14004188wmc.19.1572835792591; Sun, 03 Nov 2019 18:49:52 -0800 (PST)
MIME-Version: 1.0
References: <156330717256.15259.2193942101748847069@ietfa.amsl.com> <CAFDDyk_xvfDFK1_G3aqr9b5J6a-62=tjpdraXHGDpeiHdk10tA@mail.gmail.com>
In-Reply-To: <CAFDDyk_xvfDFK1_G3aqr9b5J6a-62=tjpdraXHGDpeiHdk10tA@mail.gmail.com>
From: Nick Sullivan <nick@cloudflare.com>
Date: Sun, 03 Nov 2019 18:49:36 -0800
Message-ID: <CAFDDyk8sOw-G72KoJ76dS_etmO3zsJ58HuAkhAysFQPG2U-R0Q@mail.gmail.com>
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Cc: secdir@ietf.org, draft-ietf-tls-exported-authenticator.all@ietf.org, ietf@ietf.org, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b54e4905967c5ec3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ftLqadUDY7LfkqHOBL_9I5w4fbk>
Subject: Re: [TLS] Secdir 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: Mon, 04 Nov 2019 02:50:04 -0000
Following up, Yaron, do the responses by myself and Benjamin along with the does the following PR sufficiently address your comments/concerns? https://github.com/tlswg/tls-exported-authenticator/pull/52 On Wed, Sep 18, 2019 at 4:55 PM Nick Sullivan <nick@cloudflare.com> wrote: > Hi Yaron, > > Thank you for your thorough review. My answers will be inline, and I'll > incorporate some of Ben's replies if necessary. Here's a PR with proposed > changes in response to your comments: > https://github.com/tlswg/tls-exported-authenticator/pull/52 > > On Tue, Jul 16, 2019 at 12:59 PM Yaron Sheffer via Datatracker < > noreply@ietf.org> wrote: > >> Reviewer: Yaron Sheffer >> Review result: Has Issues >> >> The document is generally clear in both its motivation and the proposed >> solution. >> >> I think it's playing a bit too liberal with TLS 1.3, in sort-of but not >> quite >> deprecating renegotiation, and in changing the IANA registry in a way that >> actually changes the protocol. Details below. >> >> Other comments: >> >> * Abstract: please reword to make it clear that it's the proof (not the >> cert) >> that is portable. > > > Proposed text here: > This document describes a mechanism in Transport Layer Security (TLS) for > peers to > provide a proof of ownership of a certificate. This proof can be exported > by one peer, transmitted out-of-band to the other peer, and verified by > the receiving peer. > > * Introduction: TLS 1.3 post-handshake auth "has the >> disadvantage of requiring additional state to be stored as part of the TLS >> state machine." Why is that an issue is practice, assuming this feature is >> already supported by TLS libraries? Also, are we in effect deprecating >> this TLS >> 1.3 feature because of the security issue of the mismatched record >> boundaries? >> > > My understanding is that post-handshake authentication as defined in the > TLS 1.3 RFC is not implemented in many (any?) TLS 1.3 libraries and some > implementors would prefer to use exported authenticators. > > * "For simplicity, the mechanisms... require", maybe a normative REQUIRE? > > I'm fine with this. > > >> * Authenticator Request: please clarify that we use the TLS 1.3 format >> even when >> running on TLS 1.2. > > Updated, though it might be a bit unnecessary. > > * Also, I suggest to change "is not encrypted with a >> handshake key" which is too specific to "is sent unencrypted within the >> normal >> TLS-protected data". > > This specific text is meant to differentiate the wire format of this > message from that of the CertificateRequest message, which is encrypted > with the handshake key. The specificity is warranted. > > * Before diving into the detailed messages in Sec. 3, it >> would be nice to include a quick overview of the message sequence. > > There are two message types and three potential sequences. I've added a > short overview. > > >> * Sec. 3: >> "SHOULD use TLS", change to MUST. There's no way it can work otherwise >> anyway. >> > As Ben noted, this could be any secure channel with equivalent security to > TLS, such as QUIC. We shouldn't forbid other secure out-of-band mechanisms. > > >> * "This message reuses the structure to the CertificateRequest message" - >> repeats the preceding paragraph. > > Fixed > > >> * Sec. 4: again, SHOULD use TLS -> MUST. > > Again, I don't see the need for a MUST here. > > >> * Is >> there a requirement for all protocol messages to be sent over a single TLS >> connection? If so, please mention it. Certainly this is true for the >> Authenticator message that must be sent over a single connection and >> cannot be >> multiplexed by the high-level protocol. I think this protocol actually >> assumes >> "nice" transport properties (no message reorder, reliability) that also >> require >> a single, clean TLS connection. > > There is no such requirement. Message ordering is managed by the > application layer protocol that utilizes exported authenticators. > > >> * Why no authenticator request for servers? >> Don't we care about replay? OTOH if the client wants to detect replays, it >> would need to keep state on received authenticators, which would be very >> messy. >> > I'm not sure I understand. It's possible to use authenticator requests for > servers. > > * 4.1: when referencing Exporters, mention this is Sec. 7.5 of [TLS1.3]. > > Added "Sec. 7.5" > > * The >> discussion of Extended Master Secret only applies to TLS 1.2 - please >> clarify >> that, plus I suggest to reword this paragraph which I find hard to parse. > > re-worded > > * >> 4.2: "the extensions are chosen from the TLS handshake." - What does it >> mean >> exactly, and how does an application even know which extensions were used >> at >> the TLS layer? Reading further, we mention "ClientHello extensions." >> Maybe the >> authenticator should also include a ClientHello message to indicate >> supported >> extensions. Assuming we can peek into ClientHello contradicts the hopeful >> "even >> if it is possible to implement it at the application layer" in Sec. 6. > > > This could be clearer. Effectively, the Certificate message in the > Authenticator needs > to be constructed in a similar manner to how a Certificate message would > be created > in a TLS handshake. Namely, it can only contain extensions that were > present in either > the client hello or a preceding CertificateRequest. > > You're right that this makes an assumption that the party creating the > Authenticator > has access to the TLS handshake state. This implies that even if the > Authenticator > is created in the application space, an additional API needs to be exposed > to share > that information. > > * 4.2.1: >> the first sentence of the section is incomplete. > > > Fixed > > >> * Can I use TLS 1.3-specific >> extensions (oid_filters) if I'm running on a TLS 1.2 connection? Is there >> a >> situation where a certificate is acceptable for TLS 1.3 connections but >> not for >> TLS 1.2 connections? > > Yes TLS 1.3-specific extensions are allowed, the CertificateRequest > message is TLS 1.3-compatible. > > >> * "using a value derived from the connection secrets" - I >> think we should recommend a specific construction here to ensure people >> do it >> securely. > > This was a suggestion from the Additional Certificates use case ( > https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs-05). > I'm not sure we should get into the details here. > > >> * 4.2.3: Are we computing HMAC(MAC-key, Hash(a || b || c || d))? If >> so, please say so. > > Yes, I'll put that in. > > * 4.2.4: "a constant-time comparison" - why is it actually >> required, what is the threat? An attacker can do very little because each >> authenticator being sent is different. > > As Ben noted, this was a safety note added during review. > > >> * 5: please say explicitly which >> messages are used in this case to construct the authenticator. > > > Re-written. > >> * 6.1: the >> "MUST" is strange in a section that's only supposed to be informative. >> Also, >> the library may provide this extension (and possibly others) without >> requiring >> it as input. > > How else do you propose wording the requirement that this API fail if the > connection doesn't support EAs? > > >> * 6.4: "The API MUST return a failure if the >> certificate_request_context of the authenticator was used in a previously >> validated authenticator." Are we requiring the library to keep previous >> contexts for replay protection? If so, please make it explicit. > > I think this can be a SHOULD based on the burden replay protection places > on the implementation. > > >> * 7.1: this is >> changing TLS 1.3 by allowing this extension in Cert Request! I think it's >> a >> really bad idea. Better to hack special support to existing libraries, >> allowing >> this specific extension for this special case, than to change the base >> protocol. Otherwise, this document should UPDATE 8446. > > > This is a good point and one that we struggled a bit with during design. > We needed to allow SNI in the CertificateRequest message because it can be > client-generated in this context. I'd be ok with creating a different > extension for this, but it's rather elegant to re-use it in this context. *I'd > like to hear some opinions from the working group* on this point > > >> * 8: I think the >> Security Considerations is the right place to talk about interaction >> between >> this protocol and TLS 1.3 (or 1.2) renegotiation. Even if we simply >> RECOMMEND >> not to do it. Or else explain the use cases where renegotiation is still >> useful >> if there are any. >> > > I'm not sure this document should be prescriptive about use cases. This > doc is providing a new capability that may be leveraged at the application > to replace the functionality of existing mechanisms, but I'm not convinced > the evaluation of the trade-offs of different mechanisms should be > contained in this document. >
- [TLS] Secdir last call review of draft-ietf-tls-e… Yaron Sheffer via Datatracker
- Re: [TLS] Secdir last call review of draft-ietf-t… Nick Sullivan
- Re: [TLS] Secdir last call review of draft-ietf-t… Benjamin Kaduk
- Re: [TLS] Secdir last call review of draft-ietf-t… Benjamin Kaduk
- Re: [TLS] Secdir last call review of draft-ietf-t… Nick Sullivan
- Re: [TLS] Secdir last call review of draft-ietf-t… Nick Sullivan
- Re: [TLS] Secdir last call review of draft-ietf-t… Yaron Sheffer
- Re: [TLS] Secdir last call review of draft-ietf-t… Nick Sullivan
- Re: [TLS] Secdir last call review of draft-ietf-t… Martin Thomson
- Re: [TLS] Secdir last call review of draft-ietf-t… Benjamin Kaduk
- Re: [TLS] Secdir last call review of draft-ietf-t… Nick Sullivan
- Re: [TLS] Secdir last call review of draft-ietf-t… Martin Thomson
- Re: [TLS] Secdir last call review of draft-ietf-t… Martin Thomson
- Re: [TLS] Secdir last call review of draft-ietf-t… Benjamin Kaduk
- Re: [TLS] Secdir last call review of draft-ietf-t… Salz, Rich
- Re: [TLS] Secdir last call review of draft-ietf-t… Nick Sullivan
- Re: [TLS] Secdir last call review of draft-ietf-t… Salz, Rich
- Re: [TLS] Secdir last call review of draft-ietf-t… Christopher Wood