Warren, Thanks for taking the time to offer so much supporting detail behind your analysis.
Regarding nefarious domain operators You have identified a very real risk that we all face when we leverage a domain over which we have no real control. I trust google to not impersonate me with my personal email address, if they did they could do real harm to me. As you well know this isn't new to the payment association record. If you want good security then you have to follow good security practices which means there must be a chain of trust AND custody of the assets. Whether a third party can be trusted with a payment association is a question best answered in the same way we answer that question regarding payal, etc. Risk The shared issues with SMIMEA and OPENPGPKEY that you mention are correct, I would suggest though that if I decide to rely on those records to encrypt communicaitons there will likely be even MORE at stake than relying on PMTA for incidental receipts or even daily commerce. It is not hard to imagine information being exchanged that is far more valuable than a company's daily receipts over some finite period (the itme it takes to discover a compromise). Chair Hat/Charter Thanks for pointing that out. I fully expected some dialog on the question - I decided that the folks in this WG were the best audience to field the idea to. I hope that we will see an evolution of ideas that leverage DANE and DNSSEC to provide the security substrate for many applications, we need to find a good home for the ideas whether that is here or another WG. thanks again for everyone's time. Glen ________________________________________ From: Warren Kumari [[email protected]] Sent: Wednesday, March 11, 2015 6:46 AM To: Wiley, Glen Cc: [email protected] Subject: Re: [dane] Payment association records On Tue, Mar 10, 2015 at 6:21 PM, Wiley, Glen <[email protected]> wrote: > A few of us have put some work into an 00 draft describing a DANE like RR > that would provide an association for payment information via the DNS. The > abstract from the draft reads: > > There is no standard, interoperable method for associating Internet service > identifiers with payment information. This document specifies a means for > retrieving information sufficient for a party to render payment using > various payment networks given the recipient's email address by leveraging > the DNS to securely publish payment information in a payment association > record. A payment association record associates an Internet service > identifier such as an email address with payment information such as an > account number or Bitcoin address. > > Our draft is in the tracker: > https://tools.ietf.org/html/draft-wiley-paymentassoc-00 > And I’d like to get some feedback from folks on this to see what we can do > to make this an effective tool. > > There are a number of elements that need to be fleshed out and we have more > content in the works to address specific use cases. > > Looking forward to hearing from folks. <no hats> Personally I really like the idea -- I'm not quite sure about all the details though. I've had a few instances where people have wanted to send me money and I've had to explain that I use PayPal and my email address is [email protected] (BTW, this is accurate, if anyone feels the need to test it, feel free to send me some dosh :-)). Having a way to make that easier / more automated would be nice... I'm a little confused about a few aspects though. I happen to run my own domain, and so am in control of the DNS for that, but I'm in the tiny minority. Let's say that I use my ISP's provided email address, so I'm [email protected]. Unfortunately example.com is slightly sketchy, and has been going through some rough times financially. What's to stop example.com creating hash(224, bob)._pmta.example.com. IN PMTA <ACH_routing_for_example.com> or *._pmta.example.com. IN PMTA <ACH_routing_for_example.com> ? They could even claim that they are being helpful and collecting the money on your behalf, and if you simply send them a notarized, triplicated request, along with a $19.99 handling fee they will release this these funds to you... Yes, this is a somewhat related issue to publishing SMIMEA or OPENPGPKEY record, but this deals directly with money, and so I have more concerns about it being used abusively. -openpgpkey- also says: "Therefore, an OpenPGP key obtained via an OPENPGPKEY record can only be trusted as much as the DNS domain can be trusted, and is no substitute for in-person key verification of the "Web of Trust"" I don't really see this could be extended to verifying payment info. </no hats> <chair hat> This (unfortunately) doesn't really seem to fit within the DANE charter, which sates: The WG will specify the use of DANE for protocols that use SRV to express service location. The WG will specify DANE use for SMTP, SMIME, OPENPGP, IPSEC and other base electronic mail protocols such as (IMAP or POP). The DANE WG shall also produce a set of implementation guidance for operators and tool developers. ... DANE is not intended to be a long-lived catch-all WG for all public key distribution in DNS issues and so will generally not adopt new work items without re-chartering. I'm in no way opposed to discussing the draft here, but we'd need to first finish some other work, and then discuss if DANE wants to recharter before we could take this on as a WG item (I note that you haven't proposed it be a WG item, but wanted to head off the "DANE cannot do this because..." discussion). </ chair hat> > -- > Glen Wiley > Principal Engineer > Verisign, Inc. > (571) 230-7917 > > A5E5 E373 3C75 5B3E 2E24 > 6A0F DC65 2354 9946 C63A > > _______________________________________________ > dane mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dane > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
