I have reviewed this draft and have several comments.
# Clarity about the guarantees
This draft needs to be a lot clearer about what exactly the peer is
able to infer when it receives an attestation. The closest we get
is S 10.1, which says:
We note that as a pure cryptographic protocol, attested TLS as-is
only guarantees that the Identity Key is known by the TEE. A number
of additional guarantees must be provided by the platform and/or the
TLS stack, and the overall security level depends on their existence
and quality of assurance:
* The Identity Key is generated by the TEE.
* The Identity Key is never exported or leaked outside the TEE.
* The TLS protocol, whether implemented by the TEE or outside the
TEE, is implemented correctly and (for example) does not leak any
session key material.
These properties may be explicitly promised ("attested") by the
platform, or they can be assured in other ways such as by providing
source code, reproducible builds, formal verification etc. The exact
mechanisms are out of scope of this document.
The point of having an attestation isn't to have some set of pure
cryptographic properties but rather to infer some set of security
properties. So, let's say that these were all true. What am I allowed
to infer then? One might think something like "everything that I
receive is endorsed by whatever is in the TEE" but that's not
true. For example:
- The TEE could expose a signing oracle for the Identity Key.
- The TEE could just let untrusted applications inject data
for transmission by the TLS stack.
Without more here, this seems like a primitive that will be very
hard to use. At minimum, what I would expect here is a description
of what set of properties would need to be attested to in order
to conclude that data you send to the negotiated keys is only
going to an app endorsed by the attested key and similarly that
data you receive under the negotiated keys is coming from such
an app.
# Negotiation Design
The design here seems oddly asymmetrical. Specifically:
Server -> Client Attestation:
- The client expresses its preferences in CH
- The server provides its response in CERT
Client -> Server Attestation:
- The client expresses its capabilities in CH
- The server tells the client what it wants in EE
- The client then provides its response in CERT
Why not instead have a symmetrical design for the Client -> Server
direction where the server uses CR.extensions (with the same
information that the client would have put in CH). This is
how we do ordinary client authentication.
# Certificates
You support two designs here:
- Attestation only (S 6.1)
- Attestation along with X.509 certificates (S 6.2)
The first
This adds a lot of complication to the CERT message because sometimes
you need to carry the attestation information in an extension and
sometimes it goes in the main data. That seems unfortunate because it
adds complexity.
I would suggest that instead for attestation-only use a raw public
key. This unifies the logic, in that in either case you extract the
public key for the TLS handshake from Certificate and then verify it
against the attestation_evidence in the extension.
-Ekr
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
