Subject: [TLS] AD review of draft-ietf-tls-exported-authenticator-08

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 23 Apr 2019 13:20:55 -0500

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?

---

From: Nick Sullivan <[email-masked]>
Date: Mon, 29 Apr 2019 14:09:14 -0700

Ben,

Thank you for the thorough review. I've added responses/comments inline and
a PR to the spec https://github.com/tlswg/tls-exported-authenticator/pull/46.
Feel free to respond in the PR for specific changes or on this thread for
structural comments.

> Maybe s/other party/peer/?

How about:

This document provides a way to authenticate one party of a Transport
Layer Security (TLS) communication to its peer using a certificate

> wording here may be doing the reader a disservice.

Here's a suggested edit:
can authenticate with those identities over a single connection ->
can authenticate additional identities over a single connection

Jonathan's analysis showed that the protocol provides "joint
authentication" between the certificate used in the handshake and one added
as an EA. It does not provide "joint authentication" between two EAs.
That's a subtle point, but I think it maps cleanly to this text.

> it intended to be "prior to TLS 1.3"?

Very good point.

How about:
  Versions of TLS prior to TLS 1.3 used renegotiation as a way to enable
  post-handshake client authentication given an existing TLS connection.
  The mechanism described in this document may be used to replace the
  post-handshake authentication functionality provided by renegotiation.
  Unlike renegotiation, exported Authenticator-based post-handshake
  authentication does not require any on-the-wire changes.  For simplicity,
  only TLS 1.2 and later are supported.

> layer (among other things).

How about:
   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.  Furthermore, the authentication boundaries of TLS
   1.3 post-handshake authentication align with TLS record boundaries,
   which are often not aligned with the authentication boundaries of the
   higher-layer protocol. For example, multiplexed connection protocols
   like HTTP/2 [RFC7540] do not have a notion of which TLS record
   a given message is a part of.

> Also to indicate which TLS connection to pull key material from?

How about:
   The authenticator request is a structured message that can be
   created by either party of a TLS connection using data exported
   from that connection.

> going to confuse people.  It may be as simple as just adding "framing".

How about:
   This message does not include any TLS framing and is
   not encrypted with a handshake key.

> up by reiterating the need for uniqueness within each class on its own.

I think it's important to note that this *is* a recap of the
CertificateRequest
message in TLS 1.3. Maybe it would be clear if the same or similar
description
was used.

How about an introduction:
   This message reuses the structure to the CertificateRequest message in
[TLS13].
   The uniqueness requirements of the certificate_request_context apply
   only to CertificateRequest messages that are used as part of
authenticator requests.
   There is no impact if the value of a certificate_request_context used in
an authenticator
   request matches the value of a certificate_request_context in the
handshake or
   in a post-handshake message.

And then a shorter description:
   message.  A certificate_request_context value MUST be unique for
   each authenticator request within the scope of a connection
   (preventing replay and context confusion).  The
   certificate_request_context SHOULD be chosen to be unpredictable
   to the peer (e.g., by randomly generating it) in order to prevent
   an attacker who has temporary access to the peer's private key
   from pre-computing valid authenticators.

> (
https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml
)
> for future extensibility?

This should support the same extensions supported by the corresponding
messages in TLS.

> Do we want to say something here?

Sure. We can say that it is chosen by the server here, then later the
uniqueness requirement is stated. Text:
   corresponding private key.  Clients MUST NOT send an authenticator
   without a preceding authenticator request; for servers an
   authenticator request is optional.  For authenticators that do not
correspond
   to authenticator requests, the certificate_request_context is chosen by
   the server.

> object" would probably alleviate the concerns of many readers.

Good addition. How about:
   The context_value used for the exporter is empty (zero length) for
   all four values.  There is no need to include additional context
   information at this stage since the application-supplied context
  is included in the authenticator itself. The length of the exported
  value is equal to the...

> a hash function for this purpose".

Good simplification, I'll take it:
   length of the output of the hash function selected in TLS for the
   pseudorandom function (PRF).  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. Call this hash function the
authenticator hash.

The last line was added to make references to this hash easier.

> about the prohibited behavior.

Agreed.

>    already been used in the connection, then no authenticator should be

How about:
   If the peer creating the certificate_request_context has already created
or
   correctly validated an authenticator with the same value, then no
authenticator

> This statement duplicates a requirement already stated above.

We can safely remove this line.

> initial spec for that functionality).

Not sure the right way to word this. Here's a shot:
   ClientHello extensions are used to determine permissible extensions
   in the Certificate message.  This follows the general model for
   extensions in TLS in which extensions can only be included
   as part of a Certificate message if they were previously sent as
   part of a CertificateRequest message or ClientHello message.

> don't limit what can be used for that purpose in core spec, IIRC.

How about we just remove that sentence?

> want to explicitly state what format we do support.

Let's use:
   Only the X509 certificate type in [TLS13] is supported.
   Alternative certificate formats such as [RFC7250] Raw Public Keys are
   not supported in this version of the specification.

> mean CH).  Also, this is the third time we say that!

If we're not exactly repeating anymore since the earlier statement only
applies to extensions, and this to the certificate itself. I'll re-word to
make sure it's specific to the Certificate message:
   If an authenticator request is present, the signature algorithm MUST be
chosen
   from one of the signature schemes present in the authenticator request.
Otherwise, the
   signature algorithm used should be chosen from the
"signature_algorithms" sent
   by the peer in the TLS ClientHello.

> say what to do if we're using TLS 1.2 and "signature_algorithms" wasn't

Proposed change:
   Otherwise, the signature algorithm used should be chosen
   from the "signature_algorithms" sent by the peer in the ClientHello of
the TLS
   handshake. There are no available signature algorithms, then no
   authenticator should be constructed.

> basis post-facto; does this text need to be changed to be consistent?

Yes. Change:
    Where Hash is the authenticator hash defined in section 4.1.

> rolling their own custom (read: broken) scheme.

Hmm. Maybe that should be a separate spec? I'm not sure we should add
additional mechanisms of this sort into this spec.

> which TLS connection to use for a given EA validation...

I'm not sure we need to be prescriptive about this. It should be clear
which connection is used from the validate/authenticate API (noticed this
was missing and added it in the PR).

>    The HMAC is computed using the same hash function using the Finished

Change:
    The HMAC is computed using the authenticator hash with the Finished MAC
Key as a key.

> Do we want to reiterate that the record layer framing is not used?

Ok:
   This message does not include any TLS framing.

> about what needs to be done for proper validation?

Sure:
   An authenticator is valid if the CertificateVerify message is correctly
constructed given the authenticator request (if
   used) and the Finished message matches the expected value.  When
validating an authenticator, a constant-time
   comparison SHOULD be used.
> Also, is a constant time comparison going to be needed?

Yes, I think so. Otherwise, some bits of the correct finished message may
leak.

> Same comments as above about a comma, and naming the Hash output.

Noted.

> Perhaps saying why we want that property would help, though.

Good point. I think a SHOULD is more appropriate because the existence of
the API is not enforceable by the peer.

> nit: "extension", "negotiated"

Will add.

> the application layer or might I need to pick something (randomly)

Application layer.

> "includes" or "is"/"comprises"?

Comprises. Changed.

>    The "authenticate" takes as input:

Will add.

> picking (application vs. TLS stack) and what the choice should be?

I don't think TLS provides any guidance, I don't think we need to either.

>    o  an optional authenticator request or certificate_request_context

This could be phrased better. The authenticator needs a
certificate_request_context, so you can send it explicitly (spontaneous) or
extract it from the authenticator request. Removing optional fixes this.

> Also to more easily remember what extensions were in CH, right?

Yes.

> It's harder to remember what extensions were sent in the ClientHello in

Right. There might be a need for another API to expose the set of client
hello extensions that were present.

> to the validation process.  Do we need to check the context that we're

Do you mean if they both have the same context should this API fail for the
second one? We don't explicitly fail if the context is repeated here. We
should spell out what happens:
   The API MUST return a failure if the certificate_request_context of the
authenticator was used in a
   previously validated authenticator.

> Should we say what we expect the caller to be doing with the certificate

I don't think it's necessary.

> Also, is an empty authenticator going to be considered "valid"?

Yes.

> Why is it only in that case?

I guess it covers both. How about:
   The Certificate/Verify/Finished pattern intentionally looks like the
   TLS 1.3 pattern which now has been analyzed several times. For example,
   [SIGMAC] presents a relevant framework for analysis.

> context field.  Should we say that more explicitly?

Yes. I like that phrasing. At the end of the paragraph before the bullets:
   Authenticators are independent and unidirectional.  There is no explicit
state change
   inside TLS when an authenticator is either created or validated.  The
application in
   possession of a validated authenticator can rely on any semantics
associated with data
   in the certificate_request_context.

Nick