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

Alexander Mayrhofer <alex.mayrhofer.ietf@gmail.com> Mon, 18 February 2019 14:14 UTC

Return-Path: <alex.mayrhofer.ietf@gmail.com>
X-Original-To: din@ietfa.amsl.com
Delivered-To: din@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 768A8130F1D for <din@ietfa.amsl.com>; Mon, 18 Feb 2019 06:14:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-rdjhog1gxj for <din@ietfa.amsl.com>; Mon, 18 Feb 2019 06:14:20 -0800 (PST)
Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7078712941A for <din@irtf.org>; Mon, 18 Feb 2019 06:14:20 -0800 (PST)
Received: by mail-lj1-x235.google.com with SMTP id z25so6659405ljk.8 for <din@irtf.org>; Mon, 18 Feb 2019 06:14:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ho9vcddmU3HRwJCS+3N+h0qAJZHT5qftlioC/ynCTB4=; b=V5EZX+yIqVNFCvoSPJid3SEFP0WmsShcPDIilwzMKIO9FuSKwmoiyXK6cH+PKBX4gj 52K+4EC3SgSniwcr+TYLWnYStlY6+rjFKPEJn5cJtWTe/IL1WHa/5qW+WC0p8HgfPE4D 8QCUck7g5cNFfNBLWEVI/3n16SwvfR6cMM3EFHHRVqOSPC5fBTufjemmR24aF7n4CHmJ TWsPsBuhIDPgAw4ptgOUY6csl9ZQGVfLrWv6fZPfht5GNGOdUEKlG6wolOF/Aop6IH6z 29EozyNrWb4LwiS9M1C82GrdPy3R7RJflaARh4Ann+h2SkChWe1yMQ0u2H7dfF1epKLl WNTw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ho9vcddmU3HRwJCS+3N+h0qAJZHT5qftlioC/ynCTB4=; b=e88+GD9QqdNywU/G3US2Hr6wbJQPJq34/paOt5Qu8szxTV0bTjOlufk29qs9EKRwi9 WEaYFSMGhotpqEP7rF6wIphB4ssyKZspJzLxFu3UR1uTMfWyRl+pup8Y0XohA4jOWKlN EAbCUIRQTzipJj/ynv7viCwwYs43e2lWE0k+p6Rc+s+PEtQUtYvvsIGc9wli6+AL6ORi vws1WNtwu7EuqaSm75PC/9x6vvJ/tAwKOvVdWRW621BYA2nRe9lX79rku5fEZ7bAd9O+ P+8DkYzJpIXmXz92k3VI3J4/ihMO6qHal4mBqTuX5Qil71/AkwCQWxZ80oYEe0kxFChd FPFQ==
X-Gm-Message-State: AHQUAuZjaEnZcKIipGNDxxXl1EW7mCFSNMlYObXw31Nu4sQ7wvYwXbZm kVH/DjtKCSfDJuARPO9NRtYXzlKMMgEG/nLzK10=
X-Google-Smtp-Source: AHgI3IZImlAD9XgP7ShpqK1vjOabjDDJGjamdIqEYzlPRj2gqTj72VsOrW/CRKAVl2cb5/YPNSncuutbk5MhVY8Gy30=
X-Received: by 2002:a2e:4d7:: with SMTP id a84mr11701209ljf.86.1550499258613; Mon, 18 Feb 2019 06:14:18 -0800 (PST)
MIME-Version: 1.0
References: <154963392249.31188.16873618915255886209.idtracker@ietfa.amsl.com> <CAHXf=0r0DqC_XHw-2=h4ZkH5SgjzTjPMuML3GjxtQbe6so3=vw@mail.gmail.com> <20190215093714.t23ulbslbg52t2dp@nic.fr> <alpine.LRH.2.21.1902151339410.28436@bofh.nohats.ca>
In-Reply-To: <alpine.LRH.2.21.1902151339410.28436@bofh.nohats.ca>
From: Alexander Mayrhofer <alex.mayrhofer.ietf@gmail.com>
Date: Mon, 18 Feb 2019 15:14:07 +0100
Message-ID: <CAHXf=0qgxxRdVm6wwA6xs=5vVjEvFL5G9YLmxhqT9RZKn95uwg@mail.gmail.com>
To: Paul Wouters <paul@nohats.ca>
Cc: Stephane Bortzmeyer <bortzmeyer@nic.fr>, IETF DNSOP WG <dnsop@ietf.org>, din@irtf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/din/1zlnz885nEpYBKn6IuyHfOsQ0Jo>
Subject: Re: [Din] Fwd: New Version Notification for draft-mayrhofer-did-dns-01.txt
X-BeenThere: din@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" <din.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/din>, <mailto:din-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/din/>
List-Post: <mailto:din@irtf.org>
List-Help: <mailto:din-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/din>, <mailto:din-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Feb 2019 14:14:23 -0000

Paul,

On Fri, Feb 15, 2019 at 7:47 PM Paul Wouters <paul@nohats.ca> wrote:
> 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.

> The reference to 7929 should be normative, not informative, since
> 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.

> 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

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.

> This technically also allows one to separate the two DNS zones more
> 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?

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

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