Subject: [dane] Payment association records

From: "Wiley, Glen" <[email-masked]>
Date: Tue, 10 Mar 2015 22:21:45 +0000

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.
--
Glen Wiley
Principal Engineer
Verisign, Inc.
(571) 230-7917

A5E5 E373 3C75 5B3E 2E24
6A0F DC65 2354 9946 C63A

---

From: Falcon Darkstar Momot <[email-masked]>
Date: Wed, 11 Mar 2015 00:35:35 -0700

I lightly draw attention to an ancient failed internet draft for storing
substantive payment processing information in the DNS:
https://tools.ietf.org/html/draft-eastlake-card-map-08

I also draw attention for a different reason to the yet-reserved HTTP
status code 402 (https://tools.ietf.org/html/rfc7231#page-59).

--Falcon Darkstar Momot
--Shadytel

On 10/03/2015 15:21, Wiley, Glen 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.
>
> 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.
>
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

---

From: Warren Kumari <[email-masked]>
Date: Wed, 11 Mar 2015 06:46:33 -0400

On Tue, Mar 10, 2015 at 6:21 PM, Wiley, Glen <[email-masked]> 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.
>
> 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.
>

<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-masked] (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-masked]. 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>

-- 
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

---

From: "John Levine" <[email-masked]>
Date: 12 Mar 2015 21:07:23 -0000

Interesting idea.

One thing that immediately jumps out at me is that the DNS name token
that is _pmta in this draft and _smimecert in the SMIMEA draft should
really be _mailbox, since the DNS name corresponds to a mailbox, not a
particular service.  I don't think that affects the tree walk problem.

With respect to Warren's concern that a sleazy mailbox provider might
publish bogus PMTA records -- they can read your mail.  If they're
going to do that, they can steal any account for which your mailbox
gets password recovery mail, so that horse is, as they say, exfaenile.

Concretely, I have a few nits.  All the other strings I can think of
in DNS records have one-byte lengths, so I'm wondering if you actually
expect URI strings to be more than 255 bytes.

For ACH transfers, I think it needs to include a an account type for
personal/business checking/saving, but that's not a big deal.

To be a little less provincial, add a payment system selector for
IBANs.  The data is an 11 character BIC (sometimes 8 characters
followed by 3 spaces or within much of Europe, all blank) and a
variable length IBAN of up to 34 characters.

Something that we'll need to address is payment systems that handle
more than one currency.  American ACH transfers only work in US
dollars and bitcoins only in bitcoins, but IBAN transfers can handle
many different currencies.  So if you are paying me in dollars, I want
to you do an ACH transfer to my account in the US, but if you're
paying me in pounds or anything else, do an IBAN transfer to my
account in the UK.  An obvious approach is to add a three character
currency field and a flag saying whether transfers in other currencies
are OK.

If this sounds awfully complicated, yeah, payment systems are like that.

R's,
John

---

From: Mark Andrews <[email-masked]>
Date: Fri, 13 Mar 2015 12:01:07 +1100

> expect URI strings to be more than 255 bytes.

Given the record format has 16 bits for the length field I think the
answer is yes.

                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Payment Network Selector      | Preference                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | URI String Length             | URI String                    /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Association Data Type         |    Payment Association Data   /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Wiley, Glen" <[email-masked]>
Date: Fri, 13 Mar 2015 15:08:19 +0000

I took a quick look at the eastlake draft from 2001 and although I wasn't watching those discussions here are my observations:

- This was prior to the supporting work of DNSSEC and DANE which provide an established trust anchor and chain of trust.  This looks as though it was an idea before its time :)

- Their proposal used the DNS hierarchy rooted in a single TLD to locate the records.  There are significant advantages to following the more familiar model in the DNS of expecting RR sets within the domain associated with the target entity (I go to google.com to find records related to google) rather than capturing application usages within a TLD.

- Their security considerations beg the question of DNSSEC and the work being done in DPRIV!

- I suspect that some of the work in the eastlake draft may be relevant to this proposal and I want to digest it more completely to see what we might leverage.

I'd love to hear relevant thoughts form the discussions in 2001 if any of those folks are on the list.

thanks
Glen

________________________________
From: dane [[email-masked]] on behalf of Falcon Darkstar Momot [[email-masked]]
Sent: Wednesday, March 11, 2015 3:35 AM
To: [email-masked]
Subject: Re: [dane] Payment association records

I lightly draw attention to an ancient failed internet draft for storing substantive payment processing information in the DNS: https://tools.ietf.org/html/draft-eastlake-card-map-08

I also draw attention for a different reason to the yet-reserved HTTP status code 402 (https://tools.ietf.org/html/rfc7231#page-59).

--Falcon Darkstar Momot
--Shadytel

A5E5 E373 3C75 5B3E 2E24
6A0F DC65 2354 9946 C63A

_______________________________________________
dane mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dane

---

From: "Wiley, Glen" <[email-masked]>
Date: Fri, 13 Mar 2015 15:18:07 +0000

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-masked]]
Sent: Wednesday, March 11, 2015 6:46 AM
To: Wiley, Glen
Cc: [email-masked]
Subject: Re: [dane] Payment association records

<no hats>

<chair hat>

</ chair hat>

---

From: "Wiley, Glen" <[email-masked]>
Date: Fri, 13 Mar 2015 16:00:48 +0000

John,

In the PMTA draft I offered the same locator approach as SMIMEA, however also mention that that is one of many possible means for locating the record.  It is not hard to image use cases in which a recipient would want to expose multiple payment associations that don't necessarily correspond to a mailbox.

URI length:  I initially wrote URI length as a one byte value however I was thinking about some of the REST entry points that I have seen that are pretty long.  I am not married to a two byte length, just trying to anticipate the use cases - I am open to input from folks.

IBAN sounds like a good idea.  One of the things we wrestled with is do we write a completely generic draft that has no specific payment networks and then handle each payment network as a separate draft or do we take the approach that we ended up with and specify two examples to provide a concrete grounding for the record (simialr to the approach taken with TLSA).  We decided that showing a crypto currency and non-crypto currency use case would get things rolling then subsequent payment networks could be added outside the draft.  Do you feel IBAN should be an exemplar?

I agree that we should add a few more fields - fully expect this to morph from 00 to 00+ that way :)

Glen

________________________________________
From: John Levine [[email-masked]]
Sent: Thursday, March 12, 2015 5:07 PM
To: [email-masked]
Cc: Wiley, Glen
Subject: Re: [dane] Payment association records

Interesting idea.

R's,
John

---

From: "John R Levine" <[email-masked]>
Date: 13 Mar 2015 13:04:49 -0400

> In the PMTA draft I offered the same locator approach as SMIMEA, however 
> also mention that that is one of many possible means for locating the 
> record.  It is not hard to image use cases in which a recipient would 
> want to expose multiple payment associations that don't necessarily 
> correspond to a mailbox.

There's two separate questions here -- one is what name to use in the DNS, 
and the other is what sort of RR to put there.  My point is that if the 
name corresponds to a hashed mailbox, the sensible name is 
<hash>._mailbox.domain, regardless of what RRs one uses.  If you want to 
publish PMTA records that don't correspond to a mailbox, that's no 
problem, use the same record with different names.  For obvious reasons, 
it would not be great to have some _pmta names being mailboxes and some 
being something else.

> Do you feel IBAN should be an exemplar?

Yes, both because it's very widely used, and it brings in the important 
issue of payment systems that handle multiple currencies.  I think you'll 
find that ACH and Bitcoin are fairly unusual in that they are each single 
currency.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: "Wiley, Glen" <[email-masked]>
Date: Tue, 17 Mar 2015 13:10:22 +0000

>it would not be great to have some _pmta names being mailboxes and some

I see what you are driving at.  Locating records becomes more uniform in
the
case of identifiers that map directly to email.

One of the points we made in the draft was that hashed email user names is
a
Possible but not exclusive means for locating the payment association.  It
Certainly helps reduce friction between parties but I would like to not
Constrain future use cases, I can imagine other locating mechanisms that
are
Tied to something other than an email address.

One question for the WG then is whether it makes sense to take your
suggestion
To the other records under discussion (SMIME, OPENPGPKEY).

>find that ACH and Bitcoin are fairly unusual in that they are each single

Thanks for highlighting that issue.  We¹ll probably use that in a future
Version of the draft.

---

From: "John R Levine" <[email-masked]>
Date: 17 Mar 2015 09:20:08 -0400

> One of the points we made in the draft was that hashed email user names 
> is a Possible but not exclusive means for locating the payment 
> association.  It Certainly helps reduce friction between parties but I 
> would like to not Constrain future use cases, I can imagine other 
> locating mechanisms that are Tied to something other than an email 
> address.

That's no problem, just use a different name for a different locator, 
e.g., 123456._duns.domain if you wanted to look up by DUNS number.

Regards,

---

From: "Wiley, Glen" <[email-masked]>
Date: Tue, 17 Mar 2015 15:23:00 +0000

>e.g., 123456._duns.domain if you wanted to look up by DUNS number.

Exactly, although I suspect you could even loose the _<type> label as
well.  You could use something like

	weekendsubscription.mynewspaper.com