I've now had a chance to look at this draft. At a high level I have the same concerns I expressed over draft-fossati-tls-attestation, which is to say that it unclear what actual security properties that attestation provides. This draft is even more vague about this question. I appreciate that these properties are dependent on the precise configuration of the peer endpoint, and so there are presumably some specific assertions which need to appear in the attestation that describe that configuration, but I think the responsibility of this kind of draft is to explain what the implications of various choices are.
In terms of the integration with TLS, I don't think the negotiation structure is quite right. Specifically, you indicate support for this mechanism with a CMW_Attestation flag in CH, which is then acknowledged in EE, but then you provide the actual data in a different extension (cmw_attestation) in Certificate. There are two problems here: 1. You can't use flags this way. 2. CH is generally not the right place. For point 1, draft-ietf-tls-tlsflags explicitly prohibits the use of a flag to signal an actual extension: For a flag that does require a response, the only proper response is the same flag in a flags extension. This extension MUST NOT be used to specify extensions where the response is a proper extension with content. On point 2, here is what S 5.2 of RFC 9261 says: ClientHello extensions are used to determine permissible extensions in the server's unsolicited Certificate message in order to follow the general model for extensions in (D)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. This ensures that the recipient will be able to process such extensions. As you are sending CertificateRequest and/or ClientCertificateRequest, that is where the offer has to appear. IOW, the correct design is to define only one extension, "cmw_attestation", which appears in CertificateRequest or ClientCertificateRequest respectively. One more editorial point: you repeatedly refer to this as "post-handshake", but that's more properly used to refer to the mechanism in S 4.6.2 of RFC 8446. This mechanism isn't in TLS at all, but rather in the application protocol but bound to TLS. -Ekr
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
