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

Nick Sullivan <nick@cloudflare.com> Tue, 16 July 2019 23:25 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 E722D12002F for <tls@ietfa.amsl.com>; Tue, 16 Jul 2019 16:25:06 -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 11MmCMYlSnJ8 for <tls@ietfa.amsl.com>; Tue, 16 Jul 2019 16:25:04 -0700 (PDT)
Received: from mail-ua1-x933.google.com (mail-ua1-x933.google.com [IPv6:2607:f8b0:4864:20::933]) (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 1611912002E for <tls@ietf.org>; Tue, 16 Jul 2019 16:25:02 -0700 (PDT)
Received: by mail-ua1-x933.google.com with SMTP id o2so8906052uae.10 for <tls@ietf.org>; Tue, 16 Jul 2019 16:25:02 -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=IJ5quSlIh0Uk0v35w2gsZ7a+TH3iS05tbcSi7VJNxvA=; b=ZyjY2tV9gINWH7fJbo0agWBN7ep5MSu2nw1piO5TE7SO/f0u6IVRAQ2nhANnqYiVQZ b9otd9hZz2jmf6n8kP+zq8nsZb7Y0E1XAt853NwU3VGHXCRHE1zPRw2jy2+s+JXQjv4r yhh0ttY4uHzvbLcfU8TzcTaWQcW2TvxRCKr2I=
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=IJ5quSlIh0Uk0v35w2gsZ7a+TH3iS05tbcSi7VJNxvA=; b=k8nuQyzkUoZrgiBxaantZeo31SYXbHWLRNsa9G8OHruJvojelnlnxQwlkp+sU/kPSv esbRy+dzwONCEBXWOdJ9XbkpI09cbhm/sOz5UPpAvh4mLEwZW5RxS+Tka/E8uvGmCZ1q kWtAFC3gCJpWE9/r5GUaYZyqscPnLJQqkNxCH0IlJs0ZRwL580UnrC0WS2HT/Q8kYysf 9iW8d//RUDFbV8ma4ocOksSWQffFyUqUg8JS8A1MPqTi0wKUXrJEXsjyHYBxgygCSv7j 1opPn8R+8tgwsjUe+xSg2llpvZANi+SDoawSEAbp8TYHRFsQVUZuCGWoSpACsi2ejgRX 4emQ==
X-Gm-Message-State: APjAAAUF7HhH5WVRRbfqI0/BAOVG3JYSUEMBk9aUrClyFn5uGUWe2con bnGxJfsqJrWFNKAoU/DkuU8eO8C94SuWqMcsLYSd0Q==
X-Google-Smtp-Source: APXvYqydOPyUSnSAK5dq/vyORDgrMNbeiRyOli6DC+trreoDds0FAv3NhoKxDcip9n0qDJNBPcWuMt52H6DtCejutNo=
X-Received: by 2002:ab0:64c4:: with SMTP id j4mr21992256uaq.97.1563319500284; Tue, 16 Jul 2019 16:25:00 -0700 (PDT)
MIME-Version: 1.0
References: <156330717256.15259.2193942101748847069@ietfa.amsl.com>
In-Reply-To: <156330717256.15259.2193942101748847069@ietfa.amsl.com>
From: Nick Sullivan <nick@cloudflare.com>
Date: Tue, 16 Jul 2019 16:24:44 -0700
Message-ID: <CAFDDyk8_cYG8=deBoxRghFkrASswKZGoR8KaH120YscgWXXOaA@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="0000000000007c5e01058dd4af42"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/yee-ekmI33v_6s9GJbZUJfe2CNs>
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: Tue, 16 Jul 2019 23:25:07 -0000

Yaron,

Thank you for this review. I'm going to internalize it, come up with
potential ways forward and get back to you soon.

Best,
Nick

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. * 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?
> * "For simplicity, the mechanisms... require", maybe a normative REQUIRE? *
> Authenticator Request: please clarify that we use the TLS 1.3 format even
> when
> running on TLS 1.2. * 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". * Before diving into the detailed messages in Sec. 3,
> it
> would be nice to include a quick overview of the message sequence. * Sec.
> 3:
> "SHOULD use TLS", change to MUST. There's no way it can work otherwise
> anyway.
> * "This message reuses the structure to the CertificateRequest message" -
> repeats the preceding paragraph. * Sec. 4: again, SHOULD use TLS -> MUST.
> * 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. * 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.
> * 4.1: when referencing Exporters, mention this is Sec. 7.5 of [TLS1.3]. *
> 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. *
> 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. *
> 4.2.1:
> the first sentence of the section is incomplete. * 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? * "using a value derived from the connection secrets"
> - I
> think we should recommend a specific construction here to ensure people do
> it
> securely. * 4.2.3: Are we computing HMAC(MAC-key, Hash(a || b || c || d))?
> If
> so, please say so. * 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. * 5: please say explicitly which
> messages are used in this case to construct the authenticator. * 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. * 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. *  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. * 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.
>
>