Re: dane-openpgp 2nd LC resolution

Paul Wouters <paul@nohats.ca> Sun, 13 March 2016 18:04 UTC

Return-Path: <paul@nohats.ca>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3035712D50C for <ietf@ietfa.amsl.com>; Sun, 13 Mar 2016 11:04:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.101
X-Spam-Level:
X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.001] autolearn=no autolearn_force=no
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 7f6u1eTMGSp1 for <ietf@ietfa.amsl.com>; Sun, 13 Mar 2016 11:04:40 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 703E812D711 for <ietf@ietf.org>; Sun, 13 Mar 2016 11:04:36 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3qNTKs6xNMz68 for <ietf@ietf.org>; Sun, 13 Mar 2016 19:04:33 +0100 (CET)
X-OPENPGPKEY: Message passed unmodified
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id U0ZCzJZBIg56 for <ietf@ietf.org>; Sun, 13 Mar 2016 19:04:32 +0100 (CET)
Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for <ietf@ietf.org>; Sun, 13 Mar 2016 19:04:32 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 8BB656066256; Sun, 13 Mar 2016 14:04:26 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 8BB656066256
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 874FEA3C7 for <ietf@ietf.org>; Sun, 13 Mar 2016 14:04:26 -0400 (EDT)
Date: Sun, 13 Mar 2016 14:04:26 -0400
From: Paul Wouters <paul@nohats.ca>
To: ietf@ietf.org
Subject: Re: dane-openpgp 2nd LC resolution
In-Reply-To: <20160313171101.3215.qmail@ary.lan>
Message-ID: <alpine.LFD.2.20.1603131352170.19822@bofh.nohats.ca>
References: <20160313171101.3215.qmail@ary.lan>
User-Agent: Alpine 2.20 (LFD 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/YoZ8T2udqe8JFhFq_2dVPBlggLc>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 13 Mar 2016 18:04:42 -0000

On Sun, 13 Mar 2016, John Levine wrote:

>> Has anyone laid out the perceived dangers in an easily digestible
>> format? I would be interested to see that discussion.
>
> See the discussion on this list in the first LC.  I tried to sum them
> up in one message about a week before the end.

You will also find my arguments against that summary there.

>> Given that the DNS RR in question is something the end user has to
>> explicitly request, ...
>
> Uh, what?  The DNS is under control of the domain owner, not the end
> users.  If I'm running mitmmail.com, I can publish keys for all of my
> users that I can decode on the way in.  If I'm that kind of MITM I
> might even re-encode the mail with the users' real keys if I know what
> they are, perhaps from the traditional PGP key servers.

So can the Registrar, the Registry and the root key owners, your OS
vendor, and many more. I don't see us blocking TLS or IPsec or PKIX
documents based on that.

Which is why the draft clearly states "not a replacement for Web Of
Trust". Why it has advise on what to do when keys in DNS conflict with
the local key ring. Why it says "still better to use to encrypt than
send in the clear".

> This points out one of the problems with this draft: there's no
> security model beyond the implicit DANE model that anything that's
> signed with DNSSEC must be true.

And as I replied then, the key listed can have trust signatures on them,
or you can get those trust signatures from public key servers (now you
have a key id). The draft mentions these things very clearly because
these arguments keep coming up and I've tried to accomodate things in
various rounds of LC, and you just keep rejecting with hand waving and
refusing to contribute text.

All of this has been said before, and all of this will be said again
it seems.

Paul