> On Apr 20, 2018, at 12:09 AM, Joseph Salowey <j...@salowey.net> wrote: > > [Joe] This can also be done with a new extension code point that defines a > replacement extension that adds the pinning policy. This seems like viable > possibility, we are not running short on extension code points.
This looks like the lose-lose version. * The present extension loses all downgrade from original LC, and gets a reduced scope, all without a clear consensus to limit the scope or lose all downgrade protection, with the path forward on restoring it more uncertain. * No explicit do not pin signal in the present extension. * Should a second extension be defined later, clients have to signal two separate extensions, and servers have to respond with two separate extensions. Complicating implementation, all to save two bytes in the present extension, with those two bytes providing a clear do not pin signal, not pinning at this time does have consensus. * With the extra two bytes the next specification merely needs to allow new interpretations of non-zero values, with no new wire formats for anyone to implement. THe upgrade path for both clients and servers becomes simple, just extend the capabilities of an extension they may already support, or which existing code can be found. The requested 2-bytes carry no implementation burden for parties that would implement the extension without those bytes. Worst-case they'll never be used, but they do signal good-will on the part of those who want a minimal extension now to allow the follow-on specification to be developed. The close attention to the content of this document that resulted from the disparate views of its proper scope has found important issues that were missed, and corrected an unnecessary limitation (prohibition of denial of existence). Though some delay has resulted, the document is better off for it. I think it is fair to ask for good faith in return, at a negligible cost of 16 bits that might if things don't go to plan forever remain zero, but will at least explicitly signal to the client that pinning based on prior observation of the extension should not take place. Refusing to make a trivial concession to gain a broader base of support for the document, just to save two bytes does not look like an inclusive process to me. -- Viktor. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls