[TLS] AD review of draft-ietf-tls-exported-authenticator-08
Benjamin Kaduk <kaduk@mit.edu> Tue, 23 April 2019 18:21 UTC
Return-Path: <kaduk@mit.edu>
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 4C85A12046F; Tue, 23 Apr 2019 11:21:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 85Pk78yxxhHg; Tue, 23 Apr 2019 11:21:02 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99B0C12046D; Tue, 23 Apr 2019 11:20:59 -0700 (PDT)
Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x3NIKtYJ021761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 23 Apr 2019 14:20:57 -0400
Date: Tue, 23 Apr 2019 13:20:55 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: draft-ietf-tls-exported-authenticator.all@ietf.org
Cc: tls@ietf.org
Message-ID: <20190423182055.GC49657@kduck.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/pcROv7mM6lbPVPzw23xDiMSXyHs>
Subject: [TLS] AD review of draft-ietf-tls-exported-authenticator-08
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, 23 Apr 2019 18:21:05 -0000
Hi all, I don't think there's anything earth-shattering in here; mostly just places where we can tighten things up before it gets to a broader set of reviewers. Thanks! -Ben Abstract, Introduction Maybe s/other party/peer/? Section 1 This document provides a way to authenticate one party of a Transport Layer Security (TLS) communication to another using a certificate after the session has been established. This allows both the client and server to prove ownership of additional identities at any time after the handshake has completed. This proof of authentication can be exported and transmitted out of band from one party to be validated by the other party. We need to be careful about what exactly is being proved when, and how it synchronizes (or doesn't) with other events/data. This will be a general theme throughout... multiple identities - Endpoints that are authoritative for multiple identities - but do not have a single certificate that includes all of the identities - can authenticate with those identities over a single connection. (The RFC Editor will do two-hyphen em dashes.) I didn't go back and reread the formal analysis that Jonathan sent out, but my recollection was that the semantics around being "jointly authoritative" over multiple identities are quite subtle, and that the wording here may be doing the reader a disservice. This document intends to replace much of the functionality of renegotiation in previous versions of TLS. It has the advantages over renegotiation of not requiring additional on-the-wire changes during a connection. For simplicity, only TLS 1.2 and later are supported. Well, renegotiation does many things. We need to say why we claim that renegotiation was widely used and for what purpose(s), and only then say that we provide an alternative. Also, the wording about "previous versions of TLS" is pretty vague -- is it intended to be "prior to TLS 1.3"? Post-handshake authentication is defined in TLS 1.3, but it has the disadvantage of requiring additional state to be stored in the TLS state machine and it composes poorly with multiplexed connection protocols like HTTP/2 [RFC7540]. It is also only available for We should probably be more explicit about "composes poorly" being due to the authentication not being tied to a specific event at the higher layer (among other things). Section 3 The authenticator request is a structured message that can be exported from either party of a TLS connection. It can be transmitted to the other party of the TLS connection at the application layer. The application layer protocol used to send the authenticator SHOULD use TLS as its underlying transport to keep the request confidential. Also to indicate which TLS connection to pull key material from? This message does not include the TLS record layer and is therefore not encrypted with a handshake key. We should probably reword this -- "include the TLS record layer" is going to confuse people. It may be as simple as just adding "framing". The CertificateRequest is used to define the parameters in a request for an authenticator. The definition for TLS 1.3 is: struct { opaque certificate_request_context<0..2^8-1>; Extension extensions<2..2^16-1>; } CertificateRequest; I think we need some filler paragraph in here noting that we re-use the data structure but assign slightly different meanings to the fields ("as follows") -- otherwise it sounds like we're just repeating the whole definition including field descriptions, which we clearly are not ("[t]his value is unrelated to the certificate_request_context used in post-handshake authentication"). from pre-computing valid authenticators. This value is unrelated to the certificate_request_context used in post-handshake authentication and collisions do not need to be avoided. This text seems to invite the reader to ask "collisions between what". Perhaps we should just say "there is no need to ensure uniqueness between values used in post-handshake authentication and values used for exported authenticators". Though if we do that, maybe we want to follow up by reiterating the need for uniqueness within each class on its own. extensions: The extensions that are allowed in this structure include the extensions defined for CertificateRequest messages defined in Section 4.2. of [TLS13] and the server_name [RFC6066] extension, which is allowed for client-generated authenticator requests. Do we need to create a new "message type" for the "TLS 1.3" column in the registry (https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml) for future extensibility? Section 4 An authenticator message can be constructed by either the client or the server given an established TLS connection, a certificate, and a corresponding private key. Clients MUST NOT send an authenticator without a preceding authenticator request; for servers an authenticator request is optional. The authenticator uses the I think at this point in the document we haven't indicated what context value to use for unsolicited exported authenticators from the server. Do we want to say something here? Section 4.1 The context_value used for the exporter is empty (zero length) for all four values. The length of the exported value is equal to the When I first read this I felt a need to think through the consequences of using the empty context_value here. A statement to the effect of "the exporter value is used as a standard API to obtain a value that includes the TLS handshake transcript hash. There is no need to include additional context information at this stage, since the application-supplied context is included in the actual authenticator object" would probably alleviate the concerns of many readers. length of the output of the hash function selected in TLS for the pseudorandom function (PRF). Cipher suites that do not use the TLS PRF MUST define a hash function that can be used for this purpose or Process-wise this is not great wording, seemingly attempting to bind the specifications of (already extant?) TLS ciphers to do more work. It's probably better to phrase it like "exported authenticators cannot be used with cipher suites that do not use the TLS PRF and have not defined a hash function for this purpose". If the connection is TLS 1.2, the master secret MUST have been computed with the extended master secret [RFC7627] to avoid key synchronization attacks. Let's rephrase this as "Exported Authenticators MUST NOT be generated or accepted on connectons not using the extended master secret [RFC7627] extension, to avoid key synchronization attacks", to be very explicit about the prohibited behavior. section 4.2 If an authenticator request is present, the extensions used to guide the construction of these messages are taken from the authenticator request. Unrecognized extensions MUST be ignored. If the certificate_request_context from the authenticator request has already been used in the connection, then no authenticator should be What does "used" mean? Only servers can provide an authenticator without a corresponding request. [...] This statement duplicates a requirement already stated above. ClientHello extensions are used to determine permissible extensions in the Certificate message. I'd suggest reiterating the "negotiation" model for extensions, and that you generally can't send something in a response that you didn't receive in a request (with, of course, the hardcoded exceptions listed in the initial spec for that functionality). Section 4.2.1 In addition to "signature_algorithms" and "signature_algorithms_cert", the "server_name" [RFC6066], "certificate_authorities" (Section 4.2.4. of [TLS13]), and "oid_filters" (Section 4.2.5. of [TLS13]) extensions are used to guide certificate selection. The extensions, or others that might affect certificate selection, are taken from the authenticator request if present, or the TLS handshake if not. The text about "taken from the authenticator request if present, or the TLS handshake if not" seems to be duplicating previous discussions. Maybe go with "commonly used [to guide certifciate selection]"? We don't limit what can be used for that purpose in core spec, IIRC. I'm a little reluctant to bring this up, as it's fairly tangential to this document, but there seems to be some general disagreement in the community about whether the SNI usage model is a proper "negotiation", where the recipient has to ack the offered value in order for both parties to agree what server name is in use, versus an assertive model where the sender just says "this is who I'm trying to talk to" and decides from the received certificate whether that's the case. But it doesn't look like we have a way to echo back the accepted SNI in this message flow.... Alternative certificate formats such as [RFC7250] Raw Public Keys are not supported in this version of the specification. Even if we call out some things that aren't supported, we probably still want to explicitly state what format we do support. If an authenticator request was provided, the Certificate message MUST contain only extensions present in the authenticator request. Otherwise, the Certificate message MUST contain only extensions present in the TLS handshake. "Present in the TLS handshake" could mean SH or EE, too (but we just mean CH). Also, this is the third time we say that! Section 4.2.2 If an authenticator request is present, the signature algorithm MUST be chosen from one of the signature schemes in the authenticator request. Otherwise, the signature algorithm used should be chosen from the "signature_algorithms" sent by the peer in the TLS handshake. This text could probably be tightened up. Specifically, we mean in the CH if we are falling back to the handshake values, and I don't think we say what to do if we're using TLS 1.2 and "signature_algorithms" wasn't sent in the ClientHello. Where Hash is the hash function negotiated by TLS. If the authenticator request is not present, it is omitted from this construction (that is, it is zero length). Above, we say that this Hash could be defined on a per-ciphersuite basis post-facto; does this text need to be changed to be consistent? failed CertificateVerify validation, it may be helpful for the application to confirm that both peers share the same connection using a value derived from the connection secrets before taking a user-visible action. We may want to define a new exporter for that, here, to keep people from rolling their own custom (read: broken) scheme. Also, we could say something about needing to identify (by context?) which TLS connection to use for a given EA validation... Section 4.2.3 Maybe give the hash output a good name so we don't get confused about Hash vs. HMAC? The HMAC is computed using the same hash function using the Finished MAC Key as a key. comma after "function"? Section 4.2.4 Do we want to reiterate that the record layer framing is not used? A given authenticator can be validated by checking the validity of the CertificateVerify message given the authenticator request (if used) and recomputing the Finished message to see if it matches. "can be" is not very strong language; do we want to be more proscriptive about what needs to be done for proper validation? Also, is a constant time comparison going to be needed? Section 5 Same comments as above about a comma, and naming the Hash output. Section 6 it is possible to implement it at the application layer. TLS implementations supporting the use of exported authenticators MUST provide application programming interfaces by which clients and servers may request and verify exported authenticator messages. Some people will complain that the MUST is not enforcable by the peer. Perhaps saying why we want that property would help, though. o the connection is TLS 1.2 and the extended master secret [RFC7627] was not used nit: "extension", "negotiated" Section 6.1 The "request" API takes as input: o certificate_request_context (from 0 to 255 bytes) How do I pick this context value? Is it always going to be input from the application layer or might I need to pick something (randomly) within the TLS stack? o set of extensions to include (this MUST include signature_algorithms) It returns an authenticator request, which is a sequence of octets that includes a CertificateRequest message. "includes" or "is"/"comprises"? Section 6.3 The "authenticate" takes as input: nit: "API" o a signer (either the private key associated with the certificate, or interface to perform private key operation) for each chain If I'm doing a spontaneous server-driven EA but I have multiple possible chains I could use, is there guidance to give about who should do the picking (application vs. TLS stack) and what the choice should be? o an optional authenticator request or certificate_request_context (from 0 to 255 bytes) Why the choice? It returns either the exported authenticator or an empty authenticator as a sequence of octets. It is RECOMMENDED that the logic for selecting the certificates and extensions to include in the exporter is implemented in the TLS library. Implementing this in the TLS library lets the implementer take advantage of existing extension and certificate selection logic. Also to more easily remember what extensions were in CH, right? It is also possible to implement this API outside of the TLS library using TLS exporters. This may be preferable in cases where the application does not have access to a TLS library with these APIs or when TLS is handled independently of the application layer protocol. It's harder to remember what extensions were sent in the ClientHello in this case, though. Section 6.4 What do we do if a triggered and spontaneous EA race, w.r.t. the input to the validation process. Do we need to check the context that we're trying to validate? It returns the certificate chain and extensions and a status to indicate whether the authenticator is valid or not. If the authenticator was empty - that is, it did not contain a certificate - the certificate chain will contain no certificates. Should we say what we expect the caller to be doing with the certificate chain? Also, is an empty authenticator going to be considered "valid"? Section 8 The Certificate/Verify/Finished pattern intentionally looks like the TLS 1.3 pattern which now has been analyzed several times. In the case where the client presents an authenticator to a server, [SIGMAC] presents a relevant framework for analysis. Why is it only in that case? o This property makes it difficult to formally prove that a server is jointly authoritative over multiple certificates, rather than individually authoritative over each. I mentioned this already, but these difficulties should be mentioned earlier/throughout, and we should think about providing some usage guidance for use patterns believed to be safe. o There is no indication in the TLS layer about which point in time an authenticator was computed. Any feedback about the time of creation or validation of the authenticator should be tracked as part of the application layer semantics if required. IIUC, all we know is that it's tied to this connection, plus the semantics of whatever additional data the application put into the context field. Should we say that more explicitly?
- [TLS] AD review of draft-ietf-tls-exported-authen… Benjamin Kaduk
- Re: [TLS] AD review of draft-ietf-tls-exported-au… Nick Sullivan
- Re: [TLS] AD review of draft-ietf-tls-exported-au… Benjamin Kaduk