Re: [dane] [openpgp] The DANE draft
Paul Wouters <paul@nohats.ca> Sun, 26 July 2015 09:11 UTC
Return-Path: <paul@nohats.ca>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C215D1B2A05; Sun, 26 Jul 2015 02:11:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 mv_koYZcSlKW; Sun, 26 Jul 2015 02:11:10 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABA621B2A01; Sun, 26 Jul 2015 02:11:09 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mfJQy3hSyz5G0; Sun, 26 Jul 2015 11:11:06 +0200 (CEST)
Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=iJKOTCBh
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 wkK7qdASboUG; Sun, 26 Jul 2015 11:11:04 +0200 (CEST)
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; Sun, 26 Jul 2015 11:11:04 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 673EE80042; Sun, 26 Jul 2015 05:11:03 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1437901863; bh=4lPqdP+S68E+CAHCLwAYtJVK7skhOozrRIqZhPgJEw0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=iJKOTCBhzCENnC0iZxVXrOcEPljuh7z7rKbygJ71IJMvrMBrieR6mDvRu1ONzTB5K 7rcTkhLjc2o2yZs6QWsu12Wbtysb2NNX382IZonS2HQcE4BVKP7HJuog7KBZgnUsQo XoLEQ11B6Ozn+5KrqrSOcTHMyLUUN61/thPWUTUw=
Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t6Q9B2RM004850; Sun, 26 Jul 2015 05:11:02 -0400
X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs
Date: Sun, 26 Jul 2015 05:11:02 -0400
From: Paul Wouters <paul@nohats.ca>
To: Phillip Hallam-Baker <phill@hallambaker.com>
In-Reply-To: <CAMm+LwiUahW0wKGa6Bo=275+LbmR2qTu6Yuwwc9irDLsc=563Q@mail.gmail.com>
Message-ID: <alpine.LFD.2.11.1507260422030.29300@bofh.nohats.ca>
References: <CAMm+LwhYdBLXM8Td8q8SCnzgwywRgMx3wNKeS_Q0JSN4Lh7rZQ@mail.gmail.com> <87si8dagiz.fsf@vigenere.g10code.de> <alpine.LFD.2.11.1507250656400.854@bofh.nohats.ca> <CAMm+LwiUahW0wKGa6Bo=275+LbmR2qTu6Yuwwc9irDLsc=563Q@mail.gmail.com>
User-Agent: Alpine 2.11 (LFD 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dane/YeK-bUQR3BfIm_NpKKFwLb5IJCM>
Cc: Werner Koch <wk@gnupg.org>, IETF OpenPGP <openpgp@ietf.org>, dane WG list <dane@ietf.org>
Subject: Re: [dane] [openpgp] The DANE draft
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dane/>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 26 Jul 2015 09:11:11 -0000
On Sat, 25 Jul 2015, Phillip Hallam-Baker wrote: > This document has not progressed "quickly". The original draft was > published in July 2013. No one is trying to rush this through > > I am quite happy waiting till 2016 or 2018. > > If it isn't done right its better not to publish at all. While a worthwhile generic goal, let's do a reality check here. We are talking about assigning a DNS RRcode for an experimental RFC for storing RFC 4880 section 5 openpgp packet types into an RDATA field at a predictable DNS QNAME entry. If that takes 5 years, the IETF will be on its way to become irrelevant, and the associated working groups will be to blame for the proliferation of more TXT type records containing non-text content. It ignores that many of the original DNSSEC architects meant for the DNS to be able to securely store signed data. > I was a bit disappointed by the process: I learned about the I-D too late > and was surprised that it started out at the OpenPGP WG mailing list (2 > years ago?) with just a few messages and then continued at the DANE list > without having notified the OpenPGP list. > > This is now the fourth time I am having this discussion with you, so I > think your representation is not entirely fair. The previous discussions > ended with you saying we should not do this and stick to the CERT record > type and me stating why I disagree with that view. > > Ummm watch your attributions, that is Werner, not me. My apologies that was not made clearer. I indeed meant to indicate I was talking to Werner. > The DANE group has been rather ineffective in getting the constituencies they purport to be > serving to buy into their proposal. Are you referring to the OPENPGPKEY document when saying "their proposal" ? The DANE working group in general has the strange effect that it is completely ignored when it writes documents to use DNSSEC based Authentication (its main charter goal!) and only when documents are getting to WGLC, do people in other areas suddenly wake up and throw on the brakes waving their expert hats around saying that the DANE working group cannot make any decisions about their protocol. I've heard in hallway talks that some people felt so attacked that they basically left the DANE working group. We had a round of PKIX people, we had a round of email people, all coming in really late into the process. It would be really helpful if people get involved earlier in the process. > Additionally, because the CERT record is a meta-container record, > support for CERT is not good because to properly parse it you need > all of openpgp and all of x509 and all of what other subtypes would > be added later on. So instead of implementing CERT records partially, > many DNS implementations just did not bother with it at all. > > All of X509 isn't a big barrier. The point is preventing needless CVE's, not adding ASN.1 parsers and X.509 parsers where not needed. If you don't think X.509 is a problem, then you haven't been paying attention to CVE's. > I am not aware of any major crypto package that doesn't have the ability to parse X.509 I am not aware of any major crypto package that did not have a number of CVE's in their X.509 code. > . Werner isn't the only person who has a PKIX package in his OpenPGP library. Actually, a quick ldd on /usr/bin/gpg* shows no libraries that I know of that do PKIX. And it would be good not to add new ones just because we are trying to save one DNS RRTYPE code point by re-using a bad idea from the past that is today basically unused (the CERT record). > The CERT record is more flexible because it also allows the use of an > indirect specification via fingerprint. > > Which is a problem not a feature. It makes the security model very > complex. > > No, the security model is complex because you are trying to use a vast, aging and vaguely > understood infrastructure with a byzantine administrative model to provide security. I am not even sure what refers to what in that sentence. DNS is a set of well maintained protocols, and RFC 4880 is solid and seeing an update now in the newly re-chartered openpgp working group. Email addresses in their current form while vast and old, aren't being obsoleted any time soon and I don't think my paul@nohats.ca address is aging. I also find it _really_ ironic that it is not the openpgp key servers that you are calling "vast, aging and vaguely understood infrastructure" because if anything is a dangerous misunderstood mess that we cannot seem to clean up, it is the current electronic garbage heap of pgp keys we can never clean up because the owners lost their keys or the keys were generated and uploaded by those not actually being the real owners of those email address specified in the openpgp key id. It is _really_ difficult to design any other method of openpgp key distribution that would be _worse_ than the current key servers. > Failing to accept that fact is one of the many reasons people are skeptical of this project and > looking for ways to work round it. And this is an actual real problem. There is no valid reason for needing to "work around" an experimental proposal that has a significant backing of people in the IETF, the mail community and opensource software writers and distributions. This document is not a protocol extension you are forced to deal even though you never wanted to. You can simply not publish OPENPGPKEY records and remain as secure as you are today. If there are real security issues or operational issues that this draft might cause, then I would love to hear those. But I've spoken with the bind implementors and others and they know how to serve big zones and big records and know how to deal with DOS attacks. They do not see this record as harmful. The latest suggested base32/split for QNAME was suggested to support the issues raised by the email and online signing communities. If you have any specific security concerns about the draft that is not addressed in the security section, let's discuss those on the list(s) and fix it. Paul
- Re: [dane] [openpgp] The DANE draft Paul Wouters
- Re: [dane] [openpgp] The DANE draft Olafur Gudmundsson
- Re: [dane] [openpgp] The DANE draft Phillip Hallam-Baker
- Re: [dane] [openpgp] The DANE draft Paul Wouters
- Re: [dane] [openpgp] The DANE draft Paul Wouters
- [dane] Is running a DANE nameserver for a TLD as … Coyo
- Re: [dane] Is running a DANE nameserver for a TLD… Viktor Dukhovni
- Re: [dane] Is running a DANE nameserver for a TLD… Coyo
- Re: [dane] [openpgp] The DANE draft Werner Koch
- Re: [dane] Is running a DANE nameserver for a TLD… Wiley, Glen
- Re: [dane] Is running a DANE nameserver for a TLD… Nico Williams
- Re: [dane] The DANE draft Simon Josefsson
- Re: [dane] [openpgp] The DANE draft Paul Wouters
- Re: [dane] [openpgp] The DANE draft Stephen Farrell
- Re: [dane] [openpgp] The DANE draft Patrick Ben Koetter
- Re: [dane] [openpgp] The DANE draft Paul Hoffman
- Re: [dane] [openpgp] The DANE draft Stephen Farrell
- Re: [dane] [openpgp] The DANE draft Carsten Strotmann
- Re: [dane] [openpgp] The DANE draft Paul Hoffman
- Re: [dane] [openpgp] The DANE draft Patrik Löhr
- Re: [dane] [openpgp] The DANE draft Viktor Dukhovni
- Re: [dane] [openpgp] The DANE draft Stephen Farrell
- Re: [dane] [openpgp] The DANE draft Daniel Kahn Gillmor
- Re: [dane] [openpgp] The DANE draft Daniel Kahn Gillmor
- Re: [dane] [openpgp] The DANE draft Paul Wouters
- Re: [dane] [openpgp] The DANE draft Jiankang Yao
- Re: [dane] [openpgp] The DANE draft Hosnieh Rafiee
- Re: [dane] [openpgp] The DANE draft Paul Wouters
- Re: [dane] [openpgp] The DANE draft Hosnieh Rafiee
- Re: [dane] [openpgp] The DANE draft Hosnieh Rafiee
- Re: [dane] [openpgp] The DANE draft Vincent Breitmoser
- Re: [dane] [openpgp] The DANE draft Stephen Farrell
- Re: [dane] [openpgp] The DANE draft Carsten Strotmann
- Re: [dane] [openpgp] The DANE draft Paul Wouters
- Re: [dane] [openpgp] The DANE draft Stephen Farrell
- Re: [dane] [openpgp] The DANE draft Viktor Dukhovni
- Re: [dane] [openpgp] The DANE draft Hosnieh Rafiee
- Re: [dane] [openpgp] The DANE draft Warren Kumari
- Re: [dane] [openpgp] The DANE draft Daniel Kahn Gillmor