On Sat, Apr 28, 2018 at 3:01 PM, Paul Wouters <p...@nohats.ca> wrote:
> On Sat, 28 Apr 2018, Shumon Huque wrote: > > This can be clearly seen from various comments on >> list and at IETF/London, such as the point made many times that >> the original purpose of this draft was to add DANE as an additional >> possible authentication mechanism in TLS, not to position it as a >> mechanism that if available unconditionally trumps PKIX authentication.. >> > > This is actually upsetting. I can assure you that since the late 90's, > people were working on DNSSEC as an alternative for the webpki. I wrote > RFC 7901 as a building block for doing so, and that RFC is now the basis > of the format of the data in this document. It is an explicit goal of > _some_ people at IETF and has been for decades. What the motivation is > of the individual document editor is not relevant. Once the document > was adopted by the WG it became a document that needs to represent WG > consensus, not original author intent. > This is a case where clarifying the scope and limitations of the protocol from the outset would have been helpful. Many DNSSEC people I know who have followed this draft and participated in the much earlier discussions around DNSSEC stapling in certificates were acutely aware of lack of authenticated denial and its obvious implication that there was no downgrade resistance against PKIX. So I always assumed there was at least an implicit understanding of the scope. What greatly surprised me was that Viktor (and you) did not come to this realization until a few months ago (I believe that was shortly after I asked Viktor in private email to read the entire draft and I assume he came upon the text that described the issue, and the possibility of extending the protocol to include DoE later). We probably should have put this text in much earlier versions of the draft. Shumon
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
