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

Nick Sullivan <> Tue, 16 July 2019 23:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E722D12002F for <>; Tue, 16 Jul 2019 16:25:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 11MmCMYlSnJ8 for <>; Tue, 16 Jul 2019 16:25:04 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::933]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1611912002E for <>; Tue, 16 Jul 2019 16:25:02 -0700 (PDT)
Received: by with SMTP id o2so8906052uae.10 for <>; Tue, 16 Jul 2019 16:25:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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: <>
In-Reply-To: <>
From: Nick Sullivan <>
Date: Tue, 16 Jul 2019 16:24:44 -0700
Message-ID: <>
To: Yaron Sheffer <>
Cc:,,, "<>" <>
Content-Type: multipart/alternative; boundary="0000000000007c5e01058dd4af42"
Archived-At: <>
Subject: Re: [TLS] Secdir last call review of draft-ietf-tls-exported-authenticator-09
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 16 Jul 2019 23:25:07 -0000


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


On Tue, Jul 16, 2019 at 12:59 PM Yaron Sheffer via Datatracker <> 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
> not to do it. Or else explain the use cases where renegotiation is still
> useful
> if there are any.