It feels weird to have people object to this proposed protocol when they have done little to describe a better one, even after multiple requests for them (or anyone!) to do so.
Many of us would *love* to compare the opportunistic protocol proposal to a fully-authenticated protocol proposal, but cannot do so with short and clearly-incomplete statements about what such a protocol would entail. (I try not to speak for other people, but many people have said in the WG meetings that they support the opportunistic proposal but also want to see a fully-authenticated proposal.) The two most important areas for description (at least to me) are at least one discovery mechanism that is not subject to downgrade, and what are the risks of a fully-authenticating resolver operator sending failure responses to stubs when the same resolution requests sent to an opportunistic resolver operator would be fully resolved and encrypted. Other folks here might have other things they want to see in the fully-authenticated proposal. Without a fleshwd-out proposal for a fully-authenticated protocol to compare to, saying that this WG should not try to fulfill its charter to help encrypt recursive to authoritative traffic just seems wrong. --Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
