Hi Paul, On 6/1/2015 6:38 PM, Paul Wouters wrote: > On Mon, 1 Jun 2015, Stephan Bosch wrote: > >>> While that would be nice, the problem is how you authenticate that to >>> your ISP or mail hoster, DNS hoster or DNS webgui interface. >> >> Well, I suppose using the same credentials used to read/send e-mail? >> For this, I am assuming the mail hoster is the same entity that >> controls the domain and can freely modify the >> _openpgpkey.mail.domain.tld zone. So this would mean that a DNS >> update results from a user's key publication request, as received >> from a yet-to-devise protocol that is authenticated using SASL with >> the same credentials as IMAP/POP3 and SMTP-submission. It could even >> be done from within those protocols with some extension, e.g. using >> IMAP METADATA. > > While this works, you have now reduced the openpgpkey security to an > email password. Anyone with that password can now replace the > openpgpkey of the user. While it is a good starting point, there would > have to be more to secure it, for instance replacing could require > a signing by the old key of the new key (or manual intervention using > support@isp)
I think manual intervention is best avoided if at all possible. We could devise this new protocol (or whatever) as only a standard entry point for submitting a new key. What happens after submission does not strictly need to be standard. It could then involve some side-channel like sms or snailmail with some sort of (PIN) code and some subsequent confirmation, so that the key is only posted to the DNS once this provider-specific procedure is completed successfully. Submitting the final PIN code (or whatever) could also be part of the new protocol. So, then only the means by which this code is conveyed would be left unspecified. Also, if security requirements are less high, this secondary verification stage could be omitted, relying solely on the SASL authentication. This kind of procedure is used quite often already in the field for various types web services, and I think it could help here as well. >> I hope there is some common ground to be found. Otherwise, I fear >> this new technology could fail in terms of user/MUA adoption. Getting >> the key out there should be as easy as possible. > > Agreed. And I think it would be useful to write another document on an > SMTP/IMAP extension for doing so. Same story for S/MIME of course. > I don't think it should go into the existing OPENPGPKEY DNS/DANE draft. > I agree. >> Yes, but all of this would be provider-specific, which I think is bad. > > Agreed it is terrible, but you'd want the openpgpkey to be somehow more > secure than an email password (reset). Yes. Regards, Stephan. _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
