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 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
