search

tls-attestation / draft-tls-attestation

7 stars 1 forks source link

Change design of channel binder #64

Closed ionut-arm closed 4 months ago

ionut-arm commented 4 months ago

The previous definition of the channel binder made us of the Early Exporter, which does not have enough entropy to ensure the binder's design goals.

A new secret is defined as part of the TLS key schedule, to serve as the base for a new exporter. This should, hopefully, fulfill the goals of our binder.

ionut-arm commented 4 months ago

the nonce carried in CH / SH is not the "final" nonce that is generated by the binder. It's just a seed for the exporter

Yes and no, but maybe we should agree on this separately. It's only used as the seed for the exporter in cases where the attestation evidence isn't key evidence, because if you have key attestation the signature in CertificateVerify is enough to link the two protocols. The binder is only used when we're carrying platform attestation only (at least as per current draft). I'll change the negotiation part to make it clear, but maybe we want to agree if the exporter is used any time evidence is generated.

will adjust the length of the "final" nonce to the length advertised by the attester

Good point, let me fix that.

thomas-fossati commented 4 months ago

the nonce carried in CH / SH is not the "final" nonce that is generated by the binder. It's just a seed for the exporter

Yes and no, but maybe we should agree on this separately. It's only used as the seed for the exporter in cases where the attestation evidence isn't key evidence, because if you have key attestation the signature in CertificateVerify is enough to link the two protocols. The binder is only used when we're carrying platform attestation only (at least as per current draft). I'll change the negotiation part to make it clear, but maybe we want to agree if the exporter is used any time evidence is generated.

OK, let's make this a separate discussion.

thomas-fossati commented 4 months ago

the nonce carried in CH / SH is not the "final" nonce that is generated by the binder. It's just a seed for the exporter

Yes and no, but maybe we should agree on this separately. It's only used as the seed for the exporter in cases where the attestation evidence isn't key evidence, because if you have key attestation the signature in CertificateVerify is enough to link the two protocols. The binder is only used when we're carrying platform attestation only (at least as per current draft). I'll change the negotiation part to make it clear, but maybe we want to agree if the exporter is used any time evidence is generated.

OK, let's make this a separate discussion.

Opened #65 to track this. 🚢 it!

yogeshbdeshpande commented 4 months ago

@ionut-arm I have not been following Handshake binder much, but just a question: Does this PR needs a change to show the New Handshake generation in the Message Sequences of BG Check in this document, or in the IoT Device Onboarding, and other use case documented here ...?

ionut-arm commented 4 months ago

@ionut-arm I have not been following Handshake binder much, but just a question: Does this PR needs a change to show the New Handshake generation in the Message Sequences of BG Check in this document, or in the IoT Device Onboarding, and other use case documented here ...?

I wouldn't think so, because those flows are predicated on key attestation, which doesn't require this binder. We'd only need changes if the attester sends an x509, and alongside a platform attestation token, but I don't think we have a diagram of that.