Hello Stephen, thank you for your extensive coverage of the draft.
On 3 Jun 2015, at 22:41, Stephen Farrell wrote:
Stuff I'd like to chat about before starting IETF LC: (1) Given the email-addr-in-DNS issues with this, would this not be better as experimental? I think the WG did consider that, but I forget, and in any case even if you did, I want to ask again, to be sure to be sure:-) My concern is that we not end up arguing against other folks who may want to standardise some form(s) of key server on the basis that this is *the* standard way to do it. One way to handle that would be for this to be experimental and for us to see if it gets deployed or not. Another could be to just say in the text that this proposed standard is one way of distributing keys, but that others can be equally valid.
Even experimental seems a bit strong for a lookup method that has seen so much debate without serious improvement. The hashing method is poorly specified, and stronger text would not help - we are still preventing lookups in case of lower/uppercase differences, subadresses (peter+foo), dot insertion (gmail).
Let me emphasize that: the draft is, in its current form, undeployable for Google Mail. While I don't expect that they want to, this is a strong signal that the draft is broken.
I have strong objections to the texts "Both of these issues have been refuted" and "There is not much more we can do at this point to address it." under question 6 in http://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/shepherdwriteup/; similar "this is the best we can do"-language in other sections seem equally wrong. I also never got the feeling that WG consensus on the full content of the draft was "strong" but I may be mistaken here.
Better methods than hashing have been proposed. For example, split base32 is better in every way (and, as a bonus, actually deployable, unlike the hashing method) except perhaps address privacy concerns (which the draft explicitly dismisses in section 6.2 anyway). However, the split base32. has been shot down because, and I quote, "I do not understand the advantage of base32 in the QNAME." No other arguments have been put forward.
Moving the draft forward in its current form, onto Standards Track, would be a mistake. Moving it forward as Experimental would be somewhat better, but I suggest using even stronger language explaining that this RFC only defines an RRtype, keeping the lookup mechanism as no more than a weak suggestion.
While personally I feel split base32 would be fine to use in an RFC (be it Experimental or Standards Track), your point of 'not end up arguing against other folks' is valid, and in that case one could consider removing all lookup text from the RFC, and making it just about the RRtype.
- section 5: is "recommended" there meant as a 2119 thing? If so, it's usually better in uppercase.
The mention of TCP here, as in 6.1, is a weird operational sidestep for this document. DNS operators know about big records and responses, and can deal with them accordingly, without singling out specific RRtypes.
Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
