On Sat, Jul 19, 2025 at 5:46 AM Thomas Fossati <[email protected]> wrote:
> On Fri, 18 Jul 2025 at 19:37, Eric Rescorla <[email protected]> wrote: > > I've now had a chance to look at this draft. > > Thanks! > > On this point: > > > 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. > > Essentially, we want a feature flag that the peers can negotiate > before the feature is used. > Having an upfront signal allows the peers to fall back to "normal" TLS > if one of them is not implementing expat -- provided that falling back > is still considered acceptable by the RP. > In this mode of use, no other content needs to be exchanged apart from > "I want to do expat; can you do it too?", "yes/no". > Therefore, the use of flags seemed appropriate since the "response" is > just the acknowledgement of the feature flag. > The attestation credential carried in the cmw_attestation is instead a > response to the authenticator request. > That being said, I may be misunderstanding something important. > > (Note also that this is just an initial proposal for negotiation and > that richer signals could be added to this phase in future, which > would require something entirely different from a simple flag.) > We need to separate out two distinct points. 1. RFC 9261 requires that any extension that appears in Certificate appear in the corresponding [Client]CertificateRequest if one was sent, or otherwise in ClientHello. However, you do not provide a definition for this extension in either location. This violates the rules of TLS extensions and is easily fixed by having an empty extension in the appropriate spot. 2. You can, if you want, have a separate signal that indicates willingness to do attested TLS. However, I don't believe that signal properly belongs in the TLS handshake, because the rest of the process happens in the application protocol. The signal should appear there as well. -Ekr -Ekr > cheers, t >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
