On Tue, Apr 10, 2018 at 09:48:24AM -0400, Shumon Huque wrote: > Yes. I support the publication of the document as is. > > and would like to explain my position a bit. > > I'm very sympathetic to Viktor's desire to enhance this protocol > to provide downgrade resistance against PKIX attacks, and I > generally would share that desire too. > > But I would also like to publish a document that has the solid > consensus of the community that is one of key potential target > [...]
Assertion of facts not in evidence. We're here because there is a question as to consensus (and/or process). We need to address that. The earlier consensus is not just applicable, as if it were, we would not be having this LC. Using the earlier consensus as justification is not responsive to the substantive issues, and is just not a good argument. A valid argument would be that this extension works for DPRIV, but you should consider that even for DPRIV there is a downgrade unless the client knows a priori that the server does (or does not) support this extension. > I also feel that the amount of time it has taken to finish up > this draft has significantly hurt its deployment chances. In the I'll be blunt: I do not care about how long it's taken and neither should anyone else (besides, it will take longer on the RFC-Editor queue anyways; as an RFC author myself, I know this all too well). I care about the quality of the end result, and so should you, and so should the WG, IETF, and IESG. There is bug in the spec. The bug affects DPRIV as well as other applications -- it affects any application where the client does not know a priori whether the server will or will not be using this extension. > early days of this draft there was (in my view) a window of opportunity > where some browsers had actual interest in implementing this spec. See the point that even DPRIV is affected. You might argue that your DPRIV clients will know a priori whether the server supports this extension, but that would have to be true of all DPRIV clients. > But in the intervening time, there have been enough bandaids (CT > and strengthed CAB forum requirements) applied to the WebPKI that > to many people in the web community, the risk of bad actors has been > sufficiently mitigated. But to the extent that there are still some > folks interested in this proposal, I see no benefit in proposing an > additional feature that they've stated doesn't work for them, or > that they will not use. Contradition. Then why bother with DANE and this extension? Your argument is to cancel the Internet-Draft, not to publish it as-is, yet you are also arguing to publish as-is. Pick one. > Another important facet of this debate that so far has not surfaced > on recent mailing list discussions is an assessment of the relative > benefits of webpki versus dane, and the recognition that there are > strongly divergent views on this topic. [...] This is not the subject matter of this LC. > Viktor has asserted that no-one will be motivated to deploy DANE > without protection against PKIX downgrade, because there is no > compelling enough additional gain of security. He may be right or > wrong, but I've already heard several web folks disagree with him. > [...] You're not addressing the glaring downgrade attack. > As for other applications, we've already heard from a number of > folks in the DNS over TLS camp that the draft works for them in > the current form. Most DNS over TLS clients are expected to have > explicit configuration of their resolver addresses and DANE > capabilities. "Most" != "all". To live with the downgrade you'd have to make that "all". You might want to think about all the deployment scenarios ruled out by having this bug. > Some possible ways forward I see for folks wanting to develop a version > of this spec with PKIX downgrade resistant capabilities (I've already > stated earlier, that I would be happy to participate in such efforts): > > * Develop a new spec, with a new codepoint, and let the specs compete > for adoption. > * Develop a -bis document - if we manage to get WG consensus on the > approach at a later date. > * Do something outside the protocol, and specific to applications > that want to include mechanisms to mandate DANE usage (like a HTTP > header). Needless to say, I oppose your proposal for reasons I've stated before. Two specs is not better than one, and we can count on implementors missing one. Nico -- _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
