Hi Alan and Alan, Thanks for writing this draft. Even though the intent here is abundantly clear and this email risks me being drawn into the toxic mess of the related discussion, I found this draft to provoke an interesting thought.
Though the current design is for a two octet commitment that narrowly addresses one particular extension, it seems that - like the must-staple design - there is an opportunity here. We have potential downgrade attacks on a range of extensions, not just the identified one. For instance, failing to provide the extended master secret extension represents a fairly significant regression in capabilities that could be indicative of an attack. The same for renegotiation info, SCT, and others. I thought supported_versions might be a valid use, but I'm not 100% sure there. The extension could reference itself though. A commitment to continue to provide a particular feature - as identified via its extension - would be a potentially useful capability. Of course, this would need to squarely address the potential for a service to take itself out in the way that such commitments tend to. It also needs to address the scope of the commitment in more than just time. This isn't trivial when you consider that a server can be considered valid for multiple identities. The current draft doesn't really do either topic justice. Having this indicator expire when you get an authenticated denial of existence seems odd. Why not just update the lifetime when the connection is successful unconditionally? Finally, I don't see any value in the "if you use that then you must use this" text in the draft, but that's likely just a consequence of the other discussion. Cheers, Martin _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
