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

"Martin Thomson" <mt@lowentropy.net> Sun, 17 November 2019 12:22 UTC

Return-Path: <mt@lowentropy.net>
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 602F91200F5 for <tls@ietfa.amsl.com>; Sun, 17 Nov 2019 04:22:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=UfwQE1+B; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=i/DwpFGR
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 8fdZ3kLiEi_g for <tls@ietfa.amsl.com>; Sun, 17 Nov 2019 04:22:43 -0800 (PST)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F1681200F8 for <tls@ietf.org>; Sun, 17 Nov 2019 04:22:43 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id A96E221B03 for <tls@ietf.org>; Sun, 17 Nov 2019 07:22:42 -0500 (EST)
Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Sun, 17 Nov 2019 07:22:42 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm3; bh=eADIH fi3vfCP4tugFX6kTjagoTOGu5xjCyUB+NvPO2o=; b=UfwQE1+B2Ie/QQ8Zj/dAT ER0WnOX47B9EjS83xXUdy9+ONRx9jtSbwWj/AsjSoIs3332sPiD0qz625GFVXIhF fQdsYMZeBeH+LixbvQ1fFZL7VaVsC4XYKDPcfYgSt2WnkTzQQFM/KwLtyAzWbNQW YzOP9/2hV5ex3sjx3iT30di2L6ryUNzr4C/ITasR+Z+SpCxNGUSNSspasF+ODoWV Ucd+rmdSfwHK7te9iCmjDez1MBne7kuPtRn+JfEgbmNWkcM0MhAPTBu1Ll+qTwty gO/PIsaf37ovhrKaPoN/zZuvMGPDOhnFPPyvkVMMgZeStYLPTxfljPVpCeUiXgnq g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=eADIHfi3vfCP4tugFX6kTjagoTOGu5xjCyUB+NvPO 2o=; b=i/DwpFGRWbSDhLc7cd0Ch/BztCrtAXRs5N8hwiWH6q8CtDwUyzOiU2jPW oM0WhZ2qLD9oHlL1XmGaPlHKCBtif5iGKJikhOr8oMWGLd0Lao+U09TWn40ZLiB+ k32JByMx/OiZCDdkBCBKxcWlS7eaZtPNvjEcLZhVYoWW0l8DUPh873ZgxymT0mBk +VhCxaGVzeg+pjRLriqVNe5YqGby1eZypfNpJUO8usYNPl98AmHkneE2EJ1VIXOm GzpU7K4o8nv+Gh1DAhD9kCPIrHt5SCbGGfSIYUh0n/tnSCCF50yM3VUxg2F7kLho HAxfs+Hp/HLvxA88yi/Y61xRd89xA==
X-ME-Sender: <xms:kjvRXfhaCHtVPYCk7FXXjjN2oVaRkxjNNWfrTHFzmLsdJn07_RlXjg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudeguddgudegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehl ohifvghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpehgihhthhhusgdrtghomhdpih gvthhfrdhorhhgnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhho phihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:kjvRXQSBDnIbI5xKkXl2t0XpjHNpQnzjoZFz4AZ7GpjUok5MHiYWBw> <xmx:kjvRXaFzccGSzYdjq0pRTcZP8waDqTrAATkmTAyrPFzfbk0-YVR9Lw> <xmx:kjvRXQnrm5A2SONw9z05PH6x6MiU3JviyKGP3WTVNUSFcLPShaN7CQ> <xmx:kjvRXRZjZRDC91I8WpoxcUVVB0R9zosu2h_NxcOZdGb4s76c-_Fy1w>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 54C1DE00AA; Sun, 17 Nov 2019 07:22:42 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-562-gfd0633a-fmstable-20191114v1
Mime-Version: 1.0
Message-Id: <d98d11e9-c2d5-4510-83da-12aeb53cf7b5@www.fastmail.com>
In-Reply-To: <CAFDDyk-s0jMnZy_mEAct15kwQG5cEZpyonDJxf+d9gQ6YBisGA@mail.gmail.com>
References: <156330717256.15259.2193942101748847069@ietfa.amsl.com> <CAFDDyk_xvfDFK1_G3aqr9b5J6a-62=tjpdraXHGDpeiHdk10tA@mail.gmail.com> <CAFDDyk8sOw-G72KoJ76dS_etmO3zsJ58HuAkhAysFQPG2U-R0Q@mail.gmail.com> <D8E32D23-AE51-48BD-9B01-64F73DED0BFD@gmail.com> <CAFDDyk-s0jMnZy_mEAct15kwQG5cEZpyonDJxf+d9gQ6YBisGA@mail.gmail.com>
Date: Sun, 17 Nov 2019 20:22:22 +0800
From: "Martin Thomson" <mt@lowentropy.net>
To: tls@ietf.org
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/fggKtJAlq7SFaR-SthAtHAO7reY>
Subject: Re: [TLS] =?utf-8?q?Secdir_last_call_review_of_draft-ietf-tls-export?= =?utf-8?q?ed-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: Sun, 17 Nov 2019 12:22:46 -0000

I think that I am OK with the CertificateRequest-like concept (c).  The idea that CertificateRequest might be used from client to server (a) is something that I think we might be willing to consider in the fullness of time, but for now I think that it is probably best to avoid making retroactive changes to 8446.  But I really do think that this is really just a narrower representation of ClientHello that only includes just the bits that apply to certificate selection.

(Moved to TLS@)

On Sun, Nov 17, 2019, at 16:42, Nick Sullivan wrote:
> Hi Yaron,
> 
> Thanks for reminding me about the codepoint issue. It's a sticky one.
> 
> As far as I see it, there are three options:
> 
> a) Change the document to UPDATE RFC 8446
> This feels like a heavyweight option and may complicate things since it 
> will mean that SNI is allowed but undefined for CertificateVerify in 
> the TLS handshake.
> 
> b) Ask for a new extension point for SNI sent in a client-generated 
> authenticator request.
> This has the downside of not scaling to future client hello extensions 
> that could be useful in exported authenticator requests -- it forces 
> the definition of a new code point for each new extension.
> 
> c) Explicitly state that the CertificateRequest-like construction in 
> client-generated exported authenticator requests is a new type of 
> message (analogous to a ClientHello) and clarify the rules about which 
> extensions can be used when it is client-generated (specifically, say 
> that any extension supported in CH is allowed)
> This is my preferred solution.
> 
> I'm interested to hear what the working group thinks, and I'll happily 
> present the options at IETF 106 if there's time.
> 
> Best,
> Nick
> 
> On Mon, Nov 4, 2019 at 6:20 PM Yaron Sheffer <yaronf.ietf@gmail.com>; wrote:
> > Hi Nick,____
> 
> > __ __
> 
> > Apologies for not responding on time.____
> 
> > __ __
> 
> > I may be missing some follow-on discussions, but:____
> 
> > __ __
> 
> >  * Ben suggested that we mention that QUIC is also an option, even if informatively, in addition to the “SHOULD use TLS” statement.____
> >  * I think we left my question re: back-fitting this protocol into the IANA TLS registry open. Quoting: ____
> > __ __
> 
> > YS: 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.____
> 
> > __ __
> 
> > NS: 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____
> 
> > __ __
> 
> > BK: Or, since extension codepoints are cheap, just use a new codepoint.____
> 
> > __ __
> 
> > Thanks,____
> 
> >  Yaron____
> 
> > __ __
> 
> > *From: *Nick Sullivan <nick@cloudflare.com>;
> > *Date: *Monday, November 4, 2019 at 04:49
> > *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>;
> > *Subject: *Re: Secdir last call review of draft-ietf-tls-exported-authenticator-09____
> 
> > __ __
> 
> > 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.____
>