Re: [secdir] Secdir last call review of draft-ietf-tls-exported-authenticator-09

Nick Sullivan <nick@cloudflare.com> Mon, 04 November 2019 02:49 UTC

Return-Path: <nick@cloudflare.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 801DE1208EC for <secdir@ietfa.amsl.com>; Sun, 3 Nov 2019 18:49:59 -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 GFUVxGsEwC7i for <secdir@ietfa.amsl.com>; Sun, 3 Nov 2019 18:49:56 -0800 (PST)
Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (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 59AB8120956 for <secdir@ietf.org>; Sun, 3 Nov 2019 18:49:54 -0800 (PST)
Received: by mail-wm1-x336.google.com with SMTP id z26so1789945wmi.4 for <secdir@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=hvwXuLot1dgR9J0fBx7NA6k3W31JADwO9wiwfqJXPkFVetz4sr4Rz9Pc/83LCH+9Ro GvdmTJD+gSdrDYn0r1Yr9EEEsgQrtTVaJ7It9KDla5muXIji5s3g6HKUstiLt6w/+pZx CmwDQt4HtI0kDUzrhzfDspAosrosnQdjdI5H0rCRInwrKUvQYa3QegRlgus0zizx0MX4 f8CO/e1dIf2+INlI4uhKLTErloxtpSk4nd1uONHleibCTYdE4K7hEdgoKEAsA+Y+nh6K 6H2F0hXhwTMvqegkkP96Z5eMj6+XpUES0amwjmx3vLXy3IfgAfoB5gHUgFAt1AOqB92/ xtcQ==
X-Gm-Message-State: APjAAAUFCW1qH+5gyXF7/aE2YDeCnqw+pvTd+3lJ7KPP0+XR1MLLww/+ cFfx6vXI0RzsZiXxqh032KYGCsAEz8zZV/qnuS4LJQ==
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, 3 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/secdir/2kFbwCn_NhccRoNJpYt-MDfdMOU>
Subject: Re: [secdir] Secdir last call review of draft-ietf-tls-exported-authenticator-09
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Nov 2019 02:50:03 -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.
>