Re: DNS -> DIDs

Hey thanks for the feedback.

On 08/09/2018 06:51 PM, Christopher Lemmer Webber wrote:
> Markus Sabadello writes:
>
>> Hello CCG,
>>
>> I've been working with the Austrian domain registry nic.at on an IETF
>> draft on how to publish a DID for a domain name:
>> https://www.ietf.org/id/draft-mayrhofer-did-dns-00.txt
>>
>> We also posted this to 2 IETF lists:
>> https://mailarchive.ietf.org/arch/browse/din/
>> https://mailarchive.ietf.org/arch/browse/dnsop/
>>
>> Any feedback welcome. Perhaps we put this on the agenda for a future CCG
>> call?
>>
>> Markus
> I think it's good that you're looking into this, but...
>
>>   By referring to DIDs from the DNS, those hard to memorize identifiers
>>   can be discovered via well known, human friendly and widely
>>   established names.  This document specifies such a protocol, and
>>   describes how DIDs can be discovered on the basis of host names and
>>   email addresses.
> At first glance this seems like a big win: we can bootstrap the system
> quickly off of a naming mechanism that users are already using.  But I
> think we have to be careful here *if we tell users they can just use DNS
> as they currently use it*, for a few reasons:
>
>  - DNS brings centralization back to the system
>
>  - Usually when decentralized systems rely on DNS, they become
>    centralized again.  And since DNS isn't very secure and doesn't carry
>    the information about the cryptographic information of the target
>    along with it, usually it needs to be coupled with a CA.  Now we're
>    back to DNS + CAs again.
If we start associating DIDs with DNS names, then I am pretty sure we
should also utilize DID's cryptographic properties to replace CAs:

- This was a key assumption in the early DPKI
<https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust/blob/master/final-documents/dpki.pdf>
paper; and projects such as DNSChain
<https://github.com/okTurtles/dnschain> or Handshake
<https://handshake.org/> already provide (partial) decentralized
replacements for traditional CAs.
- Details should be discussed in another thread, but mechanisms such as
DNSSEC or DANE or TLS can be augmented to use DID-based keys and trust
models instead of traditional CAs.

>  - If we say, "don't worry, you can find my DID from my DNS record", in
>    that case is the DNS record allowed to change?  If that's true then
>    there's a good chance that applications will just rely on DNS, and
>    will in fact have to check it all the time, because users will still
>    be resolving applications via DNS which can change all the time.
Some thoughts on this:

- I believe DNS names should only ever be used for initial discovery of
a public DID; DNS names should not be stored in an addressbook or
anything like that.
- After you add the DID to an addressbook you should forget the DNS
name; but you can assign a local petname if you want.
- This should only be used for public DIDs (not for pairwise off-ledger
DIDs).
- The DID in the DNS record can and should change if (and if only) the
entity that currently owns (rents) the DNS name changes, e.g. if the DNS
name expires, is re-registered, or transfered to someone else.
- The DID should have a backreference to the DNS name to confirm that
the DNS name refers to the same entity as the DID.
- Ideally, no trust decisions should be made based on the DNS record
alone; this should only be a mechanism to discover a DID in a certain
situation.
>  - And if you're going to rely on DNS -> the DID id as your only naming
>    scheme, you probably don't need any of the complexities we're
>    building into DIDs at all.  No need for a blockchain or anything.
>    You already have a way to serve up a JSON document with all that
>    info... just serve it over HTTP.
>
> So I really caution about encouraging users to use DNS to resolve to
> DIDs in the same way we do today.
>
> But... but!  There is a way to include DNS that's much safer I think,
> and could even use the protocol you've described above.  Instead if we
> have a petnames system as described in the sadly incomplete:
>
>   https://github.com/cwebber/rebooting-the-web-of-trust-spring2018/blob/petnames/draft-documents/making-dids-invisible-with-petnames.md
>
> DNS can become one equal naming hub among many.  It isn't the definitive
> name resolution mechanism to get to an ID... it's just one mechanism
> users can use to find it.
I'm a big fan of petnames or linked local names
<https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust/blob/master/topics-and-advance-readings/linked-local-names.md>
as Christopher calls them (in XDI we even have a special syntax for
those), and I agree DNS and petnames could both be "equal" naming
mechanisms that live side by side.

But I don't think it makes sense to re-use anything from the DNS->DID
work for petnames, since petnames don't really use DNS syntax or zone
files or DNS records I think?
> Again, I think the work you put in can be utilized if we take that
> approach.  But I really think we need to be careful and not give users
> the impression that they can use DNS the way they currently do... that
> could accidentally undo all the work we're doing in this group!