On Thu, Apr 12, 2018 at 6:09 PM, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote:
> > > > 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). > As I said in a previous message, I'll support relaxing the language in the draft to permit delivery of authenticated denial chains for future applications of the protocol - I think that's just adding or modifying a couple of lines to the draft, and no wire changes. Someone actually argued to me in person that the draft could be read as not explicitly prohibiting authenticated denial (for NXDOMAIN/NODATA), but if we want to allow it, I think it's best to be crystal clear. If we can get consensus on that, then you could write a separate extension to convey the pinning information and describe the additional behavior. That in combination with the existing draft would satisfy your use case. That would in fact be an incremental addition, and not a whole new parallel protocol. Implementers that are opposed to pinning would then just ignore this second draft (and not bother with the authenticated denial part of the first draft). Since it seems pretty clear you're not going to consensus on adding pinning to the current draft, I think you should pursue this approach. And then you can try to convince implementers and deployers, now or in the future, that they need to use both extensions in combination. -- Shumon Huque
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
