Peter, > On Jun 9, 2015, at 7:13 AM, Peter van Dijk <[email protected]> > wrote: > > 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). >
This is a strong statement, I have a problem with your word "preventing" . My reading of the draft is that mail sender can perform the Hash() operation on any name she/he has/guesses for the receiver, and looks each one up in until a match is found or the sender gives up. Right now we do not really know if this will scale, some think it will, some do not think it will thus the experimental status. The fundamental problem is the mess called "email addresses" we are not the right forum to solve that problem. > 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. Well another strong statement, while for scale reason I may agree with you. But google has shown over the years that they can address scaling issues in many different ways. So while they may balk at this one they may select another mechanism that makes no sense for small operators. Just because we may suspect some operators may or may not be able to deploy something absent of a statement from them we are just speculating. John Levine in a followup message was trying to calculate the size of a gmail PGP zone file, and I agree with him it would be big but on-line signing like PowerDNS provides could address that issue, with a large backend DB. > > 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. The chairs can only go by what they hear either in public or private when judging consensus. Most of the objections I heard during the discussion on this draft were related to output format of the Hash function rather than the technique of the hashing. In my mind that was addressed by the editor, If I’m mistaken I happy to correct myself. > > 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. The argument here is hash has fixed length, the base32 encoding of long email name is broken into multiple tables. If email people tell us that that is better than what is proposes we will listen. > > 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. what the document status is not a big deal, RRtype needs a RFC. > > 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. We had that discussion early on, and the argument was how do I find it was asked. So while a replacement of this document may define a better solution we do not at this point know if that exists. A failure of deployment would be a good indicator. > >> - 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. > Good question I will leave this to the editor to address > Kind regards, Thanks for starting a good discussion now lets hope others chime in. Olafur > -- > Peter van Dijk > PowerDNS.COM BV - https://www.powerdns.com/ > > __
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
