> On Apr 12, 2018, at 5:47 PM, Martin Thomson <martin.thom...@gmail.com> wrote:
>
> If this is indeed about adding [goo], what prevents Viktor or Paul
> from proposing a new addition to the protocol in the form of a new I-D
> that enacts the changes they wish to see?
Why publish a crippled specification that needs immediate amendments that would
require a second parallel extension to be defined and used by clients and
servers
to fix the issues in the current specification? And the time to get that second
extension would effectively delay the publication of a usable protocol.
The protocol as described prohibits denial of existence responses. Willem
acknowledged (thus far in an off-list message) that that's an oversight that
should be corrected, and such a correction is the substance of option (A).
The protocol as described does not provide any mechanism for client to
distinguish between servers that are ready to commit to the extension
and those are not. This negates applicability in applications that
exist in a world dominated by the WebPKI. Note that I also don't
advocate any magical vision of the WebPKI going away any time soon.
Indeed some of these applications (e.g. browsers) might choose
to support only *at least* WebPKI, with DANE for optional hardening
(PKIX-TA(0), PKIX-EE(1)), but the present draft provides no downgrade
protection for this use-case.
The additional commitment signal is a hint to clients, not an obligation,
it carries negligible cost, and can be finalized now. It enables more
potential applications, without going back to square-zero and doing another
year in the IETF WG process to address the gap.
Let's do the right thing and fix now. The entire cost is just a small
delay, there is zero downside after that. No imposed complexity. Just
an improved scope. We all want to get stuff published and out the door,
but let's take a *little* extra time to make sure it is not needlessly
crippled.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
