Subject: [Din] Fwd: New Version Notification for draft-mayrhofer-did-dns-01.txt

From: Alexander Mayrhofer <[email-masked]>
Date: Fri, 8 Feb 2019 14:58:38 +0100

FYI,

i've submitted a new revision of the DID-DNS draft (publishing
Decentralized Identifiers in the DNS). The major changes in this
revision are:

- The registration for the _did Label is now performed via the Global
Underscore Name registry (see draft-ietf-dnsop-attrleaf, currently in
RFC editor queue)
- The experimental "email" method uses _mailto._did as scope selector
(rather than plain _did). This allows for clean seperation of other
future services using the scheme.

Feedback highly appreciated,
Alex

---------- Forwarded message ---------
From: <[email-masked]>
Date: Fri, Feb 8, 2019 at 2:52 PM
Subject: New Version Notification for draft-mayrhofer-did-dns-01.txt
To: Dimitrij Klesev <[email-masked]>, Alexander Mayrhofer
<[email-masked]>, Markus Sabadello
<[email-masked]>

A new version of I-D, draft-mayrhofer-did-dns-01.txt
has been successfully submitted by Alexander Mayrhofer and posted to the
IETF repository.

Name:           draft-mayrhofer-did-dns
Revision:       01
Title:          The Decentralized Identifier (DID) in the DNS
Document date:  2019-02-08
Group:          Individual Submission
Pages:          7
URL:
https://www.ietf.org/internet-drafts/draft-mayrhofer-did-dns-01.txt
Status:         https://datatracker.ietf.org/doc/draft-mayrhofer-did-dns/
Htmlized:       https://tools.ietf.org/html/draft-mayrhofer-did-dns-01
Htmlized:       https://datatracker.ietf.org/doc/html/draft-mayrhofer-did-dns
Diff:           https://www.ietf.org/rfcdiff?url2=draft-mayrhofer-did-dns-01

Abstract:
   This document specifies the use of the URI Resource Record Type to
   publish Decentralized Identifiers (DIDs) in the DNS.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 15 Feb 2019 10:37:14 +0100

On Fri, Feb 08, 2019 at 02:58:38PM +0100,
 Alexander Mayrhofer <[email-masked]> wrote 

> Feedback highly appreciated,

I think that it is an important work because it brings the power of
the DNS to many other identifier systems. So, I support it.

May be more examples could help people figure out the use cases? "My
Bitcoin address is at foobar.example" and then the Bitcoin software
would query _did.foobar.example and get
<did:bitcoin:1NZc7FJ7eHJgRMRSrmncJJM9bPnusJeuR6>.

I note that there exists already non-standard (and probably not really
deployed) solutions in that space, some specific to a TLD
<https://www.nominet.uk/domain-names-unlock-new-potential-on-blockchain/>
<http://domainincite.com/23273-my-brain-explodes-trying-to-understand-mmxs-new-blockchain-deal-for-luxe>

Regarding draft -01: it seems OK to me. The only problem I find:

> particularly the concerns around downgrade attacks when the record
> is not signed

Why downgrade attacks specifically? Without DNSSEC, a lot of attacks
are possible.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 15 Feb 2019 13:46:56 -0500 (EST)

On Fri, 15 Feb 2019, Stephane Bortzmeyer wrote:

> Subject: Re: [Din] Fwd: New Version Notification for
>     draft-mayrhofer-did-dns-01.txt

I think this document should be Experimental and not Standards Track?

The reference to 7929 should be normative, not informative, since
you actually need to read a secion of 7929 to implement this document.

I'm not sure if one should use _did.example.com for host names and
_mailto._did.example.com for email addresses. I would keep that at
the same level, eg:

_hostname._did.example.com
_mailto._did.example.com

This technically also allows one to separate the two DNS zones more
clearly (and could even be managed by a different group)

I'm really on the fence for this document. On the one hand, it is good
to have a memorable decentralized identifier, but on the other hand if
you rely on DNS (and DNSSEC), is this identifier really still
decentralised in the "we don't trust the USG or Verisign" way ?

I guess if you interpret it as a migration strategy away from DNS, it is okay.

Paul

---

From: Melinda Shore <[email-masked]>
Date: Fri, 15 Feb 2019 10:47:26 -0900

> decentralised in the "we don't trust the USG or Verisign" way ?

I think the question of whether or not to provide
decentralized identifiers and whether or not this proposal
delivers on the "decentralized" claim is out of our hands,
as the core spec (which has a lot of additional problems)
comes out of the W3C.  I think the IETF's involvement is
probably limited to their use of DNS in the resolution
process.

Melinda

p.s. and it's probably worth pointing out that this work is
being done in a W3C community group, so until it looks like
it's actually going to be published as a WC3 spec I'm not
sure I'd like to see IETF working group resources being
spent on this.

-- 
Software longa, hardware brevis

PGP key fingerprint  4F68 2D93 2A17 96F8 20F2
                     34C0 DFB8 9172 9A76 DB8F

---

From: Alexander Mayrhofer <[email-masked]>
Date: Mon, 18 Feb 2019 15:00:54 +0100

Stephane, all,

[I feel cautious about continuing to cross-post this to dnsop as well
as dinrg - however, it does apply to both areas, so i'll keep both
groups in for now]

> the DNS to many other identifier systems. So, I support it.

Thanks - great to hear. I'm hearing that DIDs are being used in more
and more situations, so i think it makes sense to define that
"bridging" protocol between the two "worlds.

> <did:bitcoin:1NZc7FJ7eHJgRMRSrmncJJM9bPnusJeuR6>.

I will add more examples in the next revision. We also need to include
an example for the "email address" use case.

> <http://domainincite.com/23273-my-brain-explodes-trying-to-understand-mmxs-new-blockchain-deal-for-luxe>

I'm aware of the .luxe initiative, however, i haven't yet seen any
technical specifications about how the connection between DNS and
Blockchains is performed. If anybody has a pointer, i'd definitely
appreciate it.

The other alternative proposal i've found is https://openalias.org/ -
scroll down for their definition of the TXT record. They don't use
DIDs as far as i understand, though.

> Why downgrade attacks specifically? Without DNSSEC, a lot of attacks

I agree, that section requires some rewording. I'm referring to the
language in the OpenPGP DANE RFC here. I'm happy to work on more text,
and open to suggestions :)

best,
Alex

---

From: Alexander Mayrhofer <[email-masked]>
Date: Mon, 18 Feb 2019 15:14:07 +0100

Paul,

> I think this document should be Experimental and not Standards Track?

I was torn when i did the first revision of this. I think it depends
on the stability of Decentralized Identifiers themselves. Once that
schema becomes widely used, i think any protocol that connects the DNS
and DIDs should be Standards Track. But i leave that up to "higher
forces" as soon as i find a suitable "home WG" for that.

> you actually need to read a secion of 7929 to implement this document.

Agreed. I've considered replacing the "instruction diff" to OpenPGP
with a full description in the document itself. The idea to use that
scheme in email came in quite late before i wrote -00, so that section
also reflects some laziness. With the "two label" hierarchy introduced
in -01, i think a full description would be better anyways. Well do so
in -02. Which, in turn, would allow the 7929 reference to stay
informative.

> _hostname._did.example.com

I'd love to have a discussion about semantics of both options at some
point. Maybe we can do a short meeting during IETF104? I know there
are many ways to do that, and personally i'm not sure which way would
be the "right" one.

> clearly (and could even be managed by a different group)

Yep, introduces a zone cut. Then again, i'm not sure what (if we
introduce that schema above) the semantics of a record right unter
_did would be.. Or would that be disallowed?

> decentralised in the "we don't trust the USG or Verisign" way ?

The identifier is still fully decentralized, the method of discovery
probably not. I've also heard that from folks from the Self Sovereign
Identity community... However, they are seeking ways for people to
discover DIDs. Commonly used are QR codes, but everyone is aware that
replacing the QR code on an ATM machine would create an easy of "real
world" phishing, so other methods of discovery are definitely worth
investigating.

> I guess if you interpret it as a migration strategy away from DNS, it is okay.

Note that we could also create a "full loop" of verification. The DID
document published behind a DID could include a link back to the
domain name. I've not investigated that further, though, but it's an
interesting area.

So, would you be interested to discuss this in Prague?

best,
Alex

---

From: Alexander Mayrhofer <[email-masked]>
Date: Mon, 18 Feb 2019 15:17:37 +0100

> probably limited to their use of DNS in the resolution

I do agree. We provide the "link" from an IETF protocol to a protocol
developed in another SDO.

> sure I'd like to see IETF working group resources being

Yes, exactly, this is a community group work right now. However, i do
understand that the "upgrade" to a working group is currently
underway.

best,
Alex

---

From: Paul Wouters <[email-masked]>
Date: Fri, 22 Feb 2019 10:03:02 -0500 (EST)

> forces" as soon as i find a suitable "home WG" for that.

My idea was that if this is an IRTF document, not a DNSOP document, that
it cannot be standards track? But I might be wrong about this.

> with a full description in the document itself.

that would be better, but with an informative reference so indeed people
know this is the "common way" of doing this and not custom to this
document.

> _did would be.. Or would that be disallowed?

I would avoid putting something there directly, yes.

> So, would you be interested to discuss this in Prague?

Sure. I will also be in Prague the week before at NetDev.

Paul