Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

[Viktor Dukhovni <[e-mail]>]

> On Apr 20, 2018, at 12:09 AM, Joseph Salowey <[e-mail]> 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.