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

[Nick Sullivan <[e-mail]>]

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.

On Tue, Apr 23, 2019 at 11:21 AM Benjamin Kaduk <[e-mail]> wrote:
>
> 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/?

How about:

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

> 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.


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.


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


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.

>
>
>
>    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).


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.

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

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.

>
>    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".

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

>
>
>    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.

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.

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

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

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

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.

>
>
> 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.

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...

>
>
>    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".

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.

>
>
>    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.

Agreed.

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

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

>
>
>                                        Only servers can provide an
>    authenticator without a corresponding request.  [...]
>
> This statement duplicates a requirement already stated above.

We can safely remove this line.

>
>
>    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).

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.

>
>
> 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.

How about we just remove that sentence?

>
>
> 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.

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.

>
>
>    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!

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.

>
>
> 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.

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.

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

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

>
>    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.

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

>
>
> Also, we could say something about needing to identify (by context?)
> 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).

>
>
> 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.
>

Change:
    The HMAC is computed using the authenticator hash with 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?

Ok:
   This message does not include any TLS framing.

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

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.

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

Noted.

>
>
> 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.

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

>
>
>
>    o  the connection is TLS 1.2 and the extended master secret [RFC7627]
>       was not used
>
> nit: "extension", "negotiated"

Will add.

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

Application layer.

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

Comprises. Changed.

>
> Section 6.3
>
>    The "authenticate" takes as input:
>
> nit: "API"

Will add.

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

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
>       (from 0 to 255 bytes)
>
> Why the choice?

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.

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

Yes.

>
>
>    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.

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

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

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.

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

I don't think it's necessary.

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

Yes.

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

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.

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

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