[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?