From nobody Mon Jul 7 09:28:14 2014 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A987A1A038D for ; Mon, 7 Jul 2014 09:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 gL0tTDfVxhJ5 for ; Mon, 7 Jul 2014 09:28:05 -0700 (PDT) Received: from smtp75.ord1c.emailsrvr.com (smtp75.ord1c.emailsrvr.com [108.166.43.75]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E94C1A0391 for ; Mon, 7 Jul 2014 09:28:04 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp18.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 61FCD301A49 for ; Mon, 7 Jul 2014 12:28:03 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp18.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id A9829301BCC for ; Mon, 7 Jul 2014 12:28:02 -0400 (EDT) X-Sender-Id: ogud@ogud.com Received: from [10.20.30.43] (pool-71-163-58-213.washdc.fios.verizon.net [71.163.58.213]) (using TLSv1 with cipher AES128-SHA) by 0.0.0.0:587 (trex/5.2.4); Mon, 07 Jul 2014 16:28:03 GMT From: Olafur Gudmundsson Content-Type: multipart/alternative; boundary="Apple-Mail=_50AF2E85-0086-4027-85EB-F1D64A66FC25" Date: Mon, 7 Jul 2014 12:28:00 -0400 References: <20140620070500.1B7C71801C1@rfc-editor.org> To: "dnsext@ietf.org Group" Message-Id: <886047E1-78C1-43F8-9A29-41326C18268D@ogud.com> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/mgh73FlPvUoEyoEf8zXxWqxBQNs Subject: [dnsext] Fwd: [Errata Held for Document Update] RFC3757 (4018) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 16:28:08 -0000 --Apple-Mail=_50AF2E85-0086-4027-85EB-F1D64A66FC25 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This email was not posted as it arrived after I left for vacation and = approval period expired before I got back=20 Olafur Begin forwarded message: > From: RFC Errata System > Subject: [dnsext] [Errata Held for Document Update] RFC3757 (4018) > Date: June 20, 2014 at 3:05:00 AM EDT > To: bortzmeyer@nic.fr, olaf@ripe.net, jakob@nic.se, edlewis@arin.net > Cc: rfc-editor@rfc-editor.org, dnsext@ietf.org, ted.lemon@nominum.com, = iesg@ietf.org >=20 > The following errata report has been held for document update=20 > for RFC3757, "Domain Name System KEY (DNSKEY) Resource Record (RR) = Secure Entry Point (SEP) Flag".=20 >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D3757&eid=3D4018 >=20 > -------------------------------------- > Status: Held for Document Update > Type: Editorial >=20 > Reported by: St?phane Bortzmeyer > Date Reported: 2014-06-19 > Held by: Ted Lemon (IESG) >=20 > Section: 1 >=20 > Original Text > ------------- > A SEP key either used to generate a > DS RR or is distributed to resolvers that use the key as the root of > a trusted subtree >=20 > Corrected Text > -------------- > A SEP key _is_ either used to generate a > DS RR or is distributed to resolvers that use the key as the root of > a trusted subtree >=20 > Notes > ----- > I am not a native english speaker so I may be wrong... But the first = part of the sentence without a verb puzzles me. >=20 > I know that the RFC is theorically obsolete but RFC 4034 is very short = on this secure entry point (SEP) and defers to the RFC 3757 it = obsoletes. >=20 > -------------------------------------- > RFC3757 (draft-ietf-dnsext-keyrr-key-signing-flag-12) > -------------------------------------- > Title : Domain Name System KEY (DNSKEY) Resource Record = (RR) Secure Entry Point (SEP) Flag > Publication Date : April 2004 > Author(s) : O. Kolkman, J. Schlyter, E. Lewis > Category : PROPOSED STANDARD > Source : DNS Extensions > Area : Internet > Stream : IETF > Verifying Party : IESG >=20 > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext --Apple-Mail=_50AF2E85-0086-4027-85EB-F1D64A66FC25 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii This = email was not posted as it arrived after I left for vacation and = approval period expired before I got back 

= Olafur


Begin forwarded = message:

From: = RFC Errata System = <rfc-editor@rfc-editor.org>= ;
Subject: = [dnsext] [Errata = Held for Document Update] RFC3757 (4018)
Date: June 20, 2014 at 3:05:00 AM = EDT
Cc: rfc-editor@rfc-editor.org, = dnsext@ietf.org, ted.lemon@nominum.com, iesg@ietf.org

T= he following errata report has been held for document update
for = RFC3757, "Domain Name System KEY (DNSKEY) Resource Record (RR) Secure = Entry Point (SEP) Flag". =

--------------------------------------
You may review the = report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3D3757&eid=3D4018=

--------------------------------------
Status: Held for = Document Update
Type: Editorial

Reported by: St?phane = Bortzmeyer <bortzmeyer@nic.fr>
Date Reported: = 2014-06-19
Held by: Ted Lemon (IESG)

Section: = 1

Original Text
-------------
A SEP key either used to = generate a
  DS RR or is distributed to resolvers that use = the key as the root of
  a trusted = subtree

Corrected Text
--------------
A SEP key _is_ either = used to generate a
  DS RR or is distributed to resolvers = that use the key as the root of
  a trusted = subtree

Notes
-----
I am not a native english speaker so I = may be wrong... But the first part of the sentence without a verb = puzzles me.

I know that the RFC is theorically obsolete but RFC = 4034 is very short on this secure entry point (SEP) and defers to the = RFC 3757 it = obsoletes.

--------------------------------------
RFC3757 = (draft-ietf-dnsext-keyrr-key-signing-flag-12)
-------------------------= -------------
Title =             &n= bsp; : Domain Name System KEY (DNSKEY) Resource Record (RR) Secure = Entry Point (SEP) Flag
Publication Date    : April = 2004
Author(s) =           : O. = Kolkman, J. Schlyter, E. Lewis
Category =            : = PROPOSED STANDARD
Source =             &n= bsp;: DNS Extensions
Area =             &n= bsp;  : Internet
Stream =             &n= bsp;: IETF
Verifying Party     : = IESG

_______________________________________________
dnsext = mailing = list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

= --Apple-Mail=_50AF2E85-0086-4027-85EB-F1D64A66FC25-- From nobody Tue Jul 15 14:19:06 2014 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7916A1A0078 for ; Tue, 15 Jul 2014 14:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 q6gKA-3bisyb for ; Tue, 15 Jul 2014 14:19:03 -0700 (PDT) Received: from smtp139.ord.emailsrvr.com (smtp139.ord.emailsrvr.com [173.203.6.139]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4C261B290D for ; Tue, 15 Jul 2014 14:19:02 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp30.relay.ord1a.emailsrvr.com (SMTP Server) with ESMTP id CBE3E28046F; Tue, 15 Jul 2014 17:19:01 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp30.relay.ord1a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 456F8280467; Tue, 15 Jul 2014 17:18:59 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Olafur Gudmundsson In-Reply-To: <20140620065657.708CE18001B@rfc-editor.org> Date: Tue, 15 Jul 2014 17:18:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9A36231F-BA08-4DCE-8C1F-53E57FAC90B3@ogud.com> References: <20140620065657.708CE18001B@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/Ggx-SKwnwXkxtP89yczu-DDNATk Cc: Brian Haberman , olaf@ripe.net, "dnsext@ietf.org Group" , ted.lemon@nominum.com, jakob@nic.se, edlewis@arin.net Subject: Re: [dnsext] [Editorial Errata Reported] RFC3757 (4018) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 21:19:04 -0000 Brian, (guess you are AD responsible)=20 IMHO this errata is correct and should be approved.=20 Olafur=20 On Jun 20, 2014, at 2:56 AM, RFC Errata System = wrote: > The following errata report has been submitted for RFC3757, > "Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry = Point (SEP) Flag". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D3757&eid=3D4018 >=20 > -------------------------------------- > Type: Editorial > Reported by: St=E9phane Bortzmeyer >=20 > Section: 1 >=20 > Original Text > ------------- > A SEP key either used to generate a > DS RR or is distributed to resolvers that use the key as the root of > a trusted subtree >=20 > Corrected Text > -------------- > A SEP key _is_ either used to generate a > DS RR or is distributed to resolvers that use the key as the root of > a trusted subtree >=20 > Notes > ----- > I am not a native english speaker so I may be wrong... But the first = part of the sentence without a verb puzzles me. >=20 > I know that the RFC is theorically obsolete but RFC 4034 is very short = on this secure entry point (SEP) and defers to the RFC 3757 it = obsoletes. >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC3757 (draft-ietf-dnsext-keyrr-key-signing-flag-12) > -------------------------------------- > Title : Domain Name System KEY (DNSKEY) Resource Record = (RR) Secure Entry Point (SEP) Flag > Publication Date : April 2004 > Author(s) : O. Kolkman, J. Schlyter, E. Lewis > Category : PROPOSED STANDARD > Source : DNS Extensions > Area : Internet > Stream : IETF > Verifying Party : IESG From nobody Thu Jul 17 13:20:17 2014 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD6751B27C0 for ; Thu, 17 Jul 2014 13:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 d9U-9cccY3dv for ; Thu, 17 Jul 2014 13:19:58 -0700 (PDT) Received: from smtp67.ord1c.emailsrvr.com (smtp67.ord1c.emailsrvr.com [108.166.43.67]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86BDF1B27B9 for ; Thu, 17 Jul 2014 13:19:58 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp1.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id C22023807BD for ; Thu, 17 Jul 2014 16:19:57 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp1.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 68D5538065A for ; Thu, 17 Jul 2014 16:19:56 -0400 (EDT) X-Sender-Id: ogud@ogud.com Received: from [10.20.30.43] (pool-74-96-189-180.washdc.fios.verizon.net [74.96.189.180]) (using TLSv1 with cipher AES128-SHA) by 0.0.0.0:587 (trex/5.2.4); Thu, 17 Jul 2014 20:19:57 GMT From: Olafur Gudmundsson Content-Type: multipart/alternative; boundary="Apple-Mail=_D0A2C671-635F-4C61-B728-DDB0E49865BB" Date: Thu, 17 Jul 2014 16:19:55 -0400 References: <20140717191740.CC28218044F@rfc-editor.org> To: "dnsext@ietf.org Group" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/OXvjUSOPlULjqayc91BOhlnvQWo Subject: [dnsext] Fwd: RFC 7314 on Extension Mechanisms for DNS (EDNS) EXPIRE Option X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 20:20:06 -0000 --Apple-Mail=_D0A2C671-635F-4C61-B728-DDB0E49865BB Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii FYI Olafur Begin forwarded message: > From: rfc-editor@rfc-editor.org > Subject: RFC 7314 on Extension Mechanisms for DNS (EDNS) EXPIRE Option > Date: July 17, 2014 at 3:17:40 PM EDT > To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org > Cc: drafts-update-ref@iana.org, rfc-editor@rfc-editor.org > Reply-To: ietf@ietf.org > > A new Request for Comments is now available in online RFC libraries. > > > RFC 7314 > > Title: Extension Mechanisms for DNS (EDNS) > EXPIRE Option > Author: M. Andrews > Status: Experimental > Stream: Independent > Date: July 2014 > Mailbox: marka@isc.org > Pages: 4 > Characters: 8473 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-andrews-dnsext-expire-04.txt > > URL: http://www.rfc-editor.org/rfc/rfc7314.txt > > This document specifies a method for secondary DNS servers to honour > the SOA EXPIRE field as if they were always transferring from the > primary, even when using other secondaries to perform indirect > transfers and refresh queries. > > > EXPERIMENTAL: This memo defines an Experimental Protocol for the > Internet community. It does not specify an Internet standard of any > kind. Discussion and suggestions for improvement are requested. > Distribution of this memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see http://www.rfc-editor.org/search > For downloading RFCs, see http://www.rfc-editor.org/rfc.html > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > > The RFC Editor Team > Association Management Solutions, LLC > > --Apple-Mail=_D0A2C671-635F-4C61-B728-DDB0E49865BB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii FYI 

= Olafur


Begin forwarded = message:

Subject: = RFC 7314 on = Extension Mechanisms for DNS (EDNS) EXPIRE = Option
Date: = July 17, 2014 at = 3:17:40 PM EDT
Reply-To: ietf@ietf.org

A= new Request for Comments is now available in online RFC = libraries.


       RFC = 7314

       Title: =      Extension Mechanisms for DNS (EDNS)
=             &n= bsp;      EXPIRE Option
=        Author: =     M. Andrews
=        Status: =     Experimental
=        Stream: =     Independent
=        Date: =       July 2014
=        Mailbox:    marka@isc.org
=        Pages: =      4
=        Characters: 8473
=        Updates/Obsoletes/SeeAlso: =   None

       I-D = Tag:    draft-andrews-dnsext-expire-04.txt

=        URL: =        http://www.rfc-editor.o= rg/rfc/rfc7314.txt

This document specifies a method for = secondary DNS servers to honour
the SOA EXPIRE field as if they were = always transferring from the
primary, even when using other = secondaries to perform indirect
transfers and refresh = queries.


EXPERIMENTAL: This memo defines an Experimental = Protocol for the
Internet community.  It does not specify an = Internet standard of any
kind. Discussion and suggestions for = improvement are requested.
Distribution of this memo is = unlimited.

This announcement is sent to the IETF-Announce and = rfc-dist lists.
To subscribe or unsubscribe, see
 http://www.iet= f.org/mailman/listinfo/ietf-announce
 http://ma= ilman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching = the RFC series, see http://www.rfc-editor.org/search=
For downloading RFCs, see http://www.rfc-editor.org/rfc.= html

Requests for special distribution should be addressed to = either the
author of the RFC in question, or to rfc-editor@rfc-editor.org. =  Unless
specifically noted otherwise on the RFC itself, all RFCs = are for
unlimited distribution.


The RFC Editor = Team
Association Management Solutions, = LLC



= --Apple-Mail=_D0A2C671-635F-4C61-B728-DDB0E49865BB-- From nobody Wed Jul 23 14:34:17 2014 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7E021A0B00 for ; Wed, 23 Jul 2014 14:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.201 X-Spam-Level: X-Spam-Status: No, score=0.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_BELOW2=2.154, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 2h6Rtrnm5oW6 for ; Wed, 23 Jul 2014 14:34:04 -0700 (PDT) Received: from clone.registro.br (clone.registro.br [200.160.2.4]) by ietfa.amsl.com (Postfix) with ESMTP id 14D2F1B2791 for ; Wed, 23 Jul 2014 14:34:04 -0700 (PDT) Received: by clone.registro.br (Postfix, from userid 1000) id 6D88F24BE00; Wed, 23 Jul 2014 18:34:03 -0300 (BRT) Date: Wed, 23 Jul 2014 18:34:03 -0300 From: Frederico A C Neves To: dnsext@ietf.org Message-ID: <20140723213403.GN94557@registro.br> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/NL7QhDQCD2wYFVkukUnKLlnKgLk Cc: Paul Wouters Subject: [dnsext] OPENPGPKEY RRTYPE review - Comments period ends Aug 6th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 21:34:05 -0000 Dear Colleagues, Bellow is a completed template requesting a new RRTYPE assignment under the procedures of RFC6895. This message starts a 2 weeks period for an expert review of the DNS RRTYPE parameter allocation for OPENPGPKEY specified at: http://tools.ietf.org/html/draft-ietf-dane-openpgpkey-00#section-2 If you have comments regarding this request please post them here before Aug 6th 21:00 UTC. Best Regards, Frederico Neves --begin 6895 template TLSA-- A. Submission Date: 23-07-2014 B.1 Submission Type: [x] New RRTYPE [ ] Modification to RRTYPE B.2 Kind of RR: [x] Data RR [ ] Meta-RR C. Contact Information for submitter (will be publicly posted): Name: Paul Wouters Email Address: pwouters@redhat.com International telephone number: +1-647-896-3464 Other contact handles: paul@nohats.ca D. Motivation for the new RRTYPE application. Publishing RFC-4880 OpenPGP formatted keys in DNS with DNSSEC protection to faciliate automatic encryption of emails in defense against pervasive monitoring. E. Description of the proposed RR type. http://tools.ietf.org/html/draft-ietf-dane-openpgpkey-00#section-2 F. What existing RRTYPE or RRTYPEs come closest to filling that need and why are they unsatisfactory? The CERT RRtype is the closest match. It unfortunately depends on subtyping, and its use in general is no longer recommended. It also has no human usable presentation format. Some usage types of CERT require external URI's which complicates the security model. This was discussed in the dane working group. G. What mnemonic is requested for the new RRTYPE (optional)? OPENPGPKEY H. Does the requested RRTYPE make use of any existing IANA registry or require the creation of a new IANA subregistry in DNS Parameters? If so, please indicate which registry is to be used or created. If a new subregistry is needed, specify the allocation policy for it and its initial contents. Also include what the modification procedures will be. The RDATA part uses the key format specified in RFC-4880, which itself use https://www.iana.org/assignments/pgp-parameters/pgp-parameters.xhtm This RRcode just uses the formats specified in those registries for its RRdata part. I. Does the proposal require/expect any changes in DNS servers/resolvers that prevent the new type from being processed as an unknown RRTYPE (see [RFC3597])? No. J. Comments: Currently, three software implementations of draft-ietf-dane-openpgpkey are using a private number. --end 6895 template TLSA-- From nobody Wed Jul 23 15:06:42 2014 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA28B1A016F for ; Wed, 23 Jul 2014 15:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.153 X-Spam-Level: X-Spam-Status: No, score=0.153 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FRT_BELOW2=2.154, SPF_PASS=-0.001] autolearn=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 q2R8w8Gyh2rr for ; Wed, 23 Jul 2014 15:06:39 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84E2D1A00F3 for ; Wed, 23 Jul 2014 15:06:39 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id b13so1800562wgh.22 for ; Wed, 23 Jul 2014 15:06:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type:content-transfer-encoding :content-disposition; bh=5ICJj/Lt2EU/NQST4DgXzsozo/eOhZAX4ja3k9YKySs=; b=DqhvT0gnjioWwP/mkyWMbBx1tNGDiVKAoiMf3XBzxeyGPGZt8nRw69RHHKeog/ophn ZAFFlhStNXw+LqiH4GU3l6j6rtF1BTOKU5H/aJUqrKg7edf/9dYNM3yS8X6jcF50wK7V ZG3MNIpBwEMZnxkyHmhakq3OU3PKxn7Q60gZ8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:content-type :content-transfer-encoding:content-disposition; bh=5ICJj/Lt2EU/NQST4DgXzsozo/eOhZAX4ja3k9YKySs=; b=m5czY7KaSE6MKk0xwbMwvuq2LwA8SbCMf03yYKWuglRoU7yerNwFSV1R0k8LDRYqVd O++BciKSQmX2mQVIOZTe3faYi/eNsX+SsR+lLOOI1c2YXlZbXgI82MdI+lyu1hhFMOUC Ica/M4FCmE2PxPjrpgC+ePPdyOY1m3jo08lFnsIw9uERHObwZWlXK1OFyUEPKvzjnvkf 4CaRjdtrgJ+7F3BFBf9SJ8kVyOJsexCl2e9txpgcUgPJOkZpRMEpwxbUolgTef7+vEwy v+YMdvr4mEcSK8kjiZXhYKYNgkH5+lrHZmfDgNdm5IFQa/kXQ169aRqp+vMUrTTOTO6p 5DsA== X-Gm-Message-State: ALoCoQlENPzbHIRUL/aQ0BlQ/NrgHj7VFVg5NPRbxZkKZi/mMaZxZHxnahJaSDx5J2gGKn4MBtyQ X-Received: by 10.180.20.228 with SMTP id q4mr28966656wie.74.1406153198033; Wed, 23 Jul 2014 15:06:38 -0700 (PDT) Received: from walrus.hopcount.ca (dhcp-a75a.meeting.ietf.org. [31.133.167.90]) by mx.google.com with ESMTPSA id ey16sm14428258wid.14.2014.07.23.15.06.36 for (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Jul 2014 15:06:37 -0700 (PDT) Date: Wed, 23 Jul 2014 18:06:34 -0400 From: Joe Abley To: dnsext@ietf.org, Frederico A C Neves Message-ID: In-Reply-To: <20140723213403.GN94557@registro.br> References: <20140723213403.GN94557@registro.br> X-Mailer: Airmail (237) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/fJMwKhITB0JZxUynTMb0Nb3qSlA Cc: Paul Wouters Subject: Re: [dnsext] OPENPGPKEY RRTYPE review - Comments period ends Aug 6th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 22:06:40 -0000 Hi =46red, On 23 July 2014 at 17:34:26, =46rederico A C Neves (fneves=40registro.br)= wrote: > Bellow is a completed template requesting a new RRTYPE assignment > under the procedures of R=46C6895. > =20 > This message starts a 2 weeks period for an expert review of the DNS > RRTYPE parameter allocation for OPENPGPKEY specified at: > =20 > http://tools.ietf.org/html/draft-ietf-dane-openpgpkey-00=23section-2 > =20 > If you have comments regarding this request please post them here > before Aug 6th 21:00 UTC. The specification seems clear, the motivation for the specification is ea= sy to understand, and I can think of no reason not to assign the requeste= d code-point. Two side-comment to the authors of=C2=A0draft-ietf-dane-openpgpkey-00: (1) you might consider using the phrase =22owner name=22 in the second-la= st paragraph of section 3, since referring to queries and QNAMEs in the c= ontext of publishing an RRSet seems a little clumsy. (2) given that there is already a (weak) specification for encoding an e-= mail address in a domain name in 1035's description of the RNAME field of= the SOA RDATA, it might be worth providing a reference to that and descr= ibing briefly why it is inadequate for this purpose. (It's clearly inadeq= uate, and I'm not suggesting it be used; I just think the reference would= be informative.) Joe From nobody Wed Jul 23 16:09:06 2014 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5EA1A02E0 for ; Wed, 23 Jul 2014 16:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.252 X-Spam-Level: X-Spam-Status: No, score=0.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_BELOW2=2.154, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 ippQQGtUWe7H for ; Wed, 23 Jul 2014 16:08:55 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by ietfa.amsl.com (Postfix) with ESMTP id ADBC31A0373 for ; Wed, 23 Jul 2014 16:08:53 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id B892E4BA58A; Thu, 24 Jul 2014 11:08:52 +1200 (NZST) X-Virus-Scanned: Debian amavisd-new at srsomail.office.nzrs.net.nz Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWBZbxiHdumb; Thu, 24 Jul 2014 11:08:42 +1200 (NZST) Received: from [192.168.22.129] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 876EF4B8E92; Thu, 24 Jul 2014 11:08:42 +1200 (NZST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Jay Daley In-Reply-To: <20140723213403.GN94557@registro.br> Date: Thu, 24 Jul 2014 11:08:41 +1200 Content-Transfer-Encoding: quoted-printable Message-Id: <6AB35A29-3BB0-4386-9021-DC50A15AD58E@nzrs.net.nz> References: <20140723213403.GN94557@registro.br> To: Frederico A C Neves X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/W50pFdVbmt_YpG1BDcpISKrn2ec Cc: Paul Wouters , dnsext@ietf.org Subject: Re: [dnsext] OPENPGPKEY RRTYPE review - Comments period ends Aug 6th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 23:08:57 -0000 The text contains this specification element: 3. The string "_openpgpkey" becomes the second left-most label = in the prepared domain name. without any explanation (that I can see) of a) why it is needed and b) = why openpgpkey has been chosen. =20 The only reason I can see is to support partitioning these RRs into a = separate zone but then if an admin wanted to do that they might also = want to put lots more email records there and so maybe _email would be = better. But then what about other personally identifying URIs like = those used in SIP endpoints? Umm. The rest seems like a good idea. Jay On 24/07/2014, at 9:34 am, Frederico A C Neves = wrote: > Dear Colleagues, >=20 > Bellow is a completed template requesting a new RRTYPE assignment > under the procedures of RFC6895. >=20 > This message starts a 2 weeks period for an expert review of the DNS > RRTYPE parameter allocation for OPENPGPKEY specified at: >=20 > http://tools.ietf.org/html/draft-ietf-dane-openpgpkey-00#section-2 >=20 > If you have comments regarding this request please post them here > before Aug 6th 21:00 UTC. >=20 > Best Regards, > Frederico Neves >=20 > --begin 6895 template TLSA-- > A. Submission Date: 23-07-2014 >=20 > B.1 Submission Type: [x] New RRTYPE [ ] Modification to RRTYPE > B.2 Kind of RR: [x] Data RR [ ] Meta-RR >=20 > C. Contact Information for submitter (will be publicly posted): > Name: Paul Wouters Email Address: pwouters@redhat.com > International telephone number: +1-647-896-3464 > Other contact handles: paul@nohats.ca >=20 > D. Motivation for the new RRTYPE application. >=20 > Publishing RFC-4880 OpenPGP formatted keys in DNS with DNSSEC > protection to faciliate automatic encryption of emails in > defense against pervasive monitoring. >=20 > E. Description of the proposed RR type. >=20 > http://tools.ietf.org/html/draft-ietf-dane-openpgpkey-00#section-2 >=20 > F. What existing RRTYPE or RRTYPEs come closest to filling that need > and why are they unsatisfactory? >=20 > The CERT RRtype is the closest match. It unfortunately depends on > subtyping, and its use in general is no longer recommended. It > also has no human usable presentation format. Some usage types of > CERT require external URI's which complicates the security model. > This was discussed in the dane working group. >=20 > G. What mnemonic is requested for the new RRTYPE (optional)? >=20 > OPENPGPKEY >=20 > H. Does the requested RRTYPE make use of any existing IANA registry > or require the creation of a new IANA subregistry in DNS > Parameters? If so, please indicate which registry is to be used > or created. If a new subregistry is needed, specify the > allocation policy for it and its initial contents. Also include > what the modification procedures will be. >=20 > The RDATA part uses the key format specified in RFC-4880, which > itself use = https://www.iana.org/assignments/pgp-parameters/pgp-parameters.xhtm >=20 > This RRcode just uses the formats specified in those registries > for its RRdata part. >=20 >=20 > I. Does the proposal require/expect any changes in DNS > servers/resolvers that prevent the new type from being processed > as an unknown RRTYPE (see [RFC3597])? >=20 > No. >=20 > J. Comments: >=20 > Currently, three software implementations of = draft-ietf-dane-openpgpkey > are using a private number. > --end 6895 template TLSA-- >=20 > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 linkedin: www.linkedin.com/in/jaydaley From nobody Wed Jul 23 16:13:09 2014 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D5001A011E for ; Wed, 23 Jul 2014 16:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] 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 X3ywGmroE-Oa for ; Wed, 23 Jul 2014 16:13:07 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 156F71A0174 for ; Wed, 23 Jul 2014 16:13:06 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id n12so1930704wgh.9 for ; Wed, 23 Jul 2014 16:13:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type:content-transfer-encoding :content-disposition; bh=pqojRhZ8OTm8DdDMdn1Piumvt+wEmf+MNp8cMn84MV8=; b=LttiPAdJMpgSKFaIUeKOCPk2qnWwOVpJ5RM8dEJ+g80WoJ5ysxpSaDAFv37HCXnOt2 bGOeJUdrLWyLCfpXJejdKEbmK92Kn7GOedu91TWp/rO71bTf0Xg3qLZnOshFaqt4jeL+ 2rT65wWTNqC3VEjN/qmpmrIOwbJtMqVZRqW74= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:content-type :content-transfer-encoding:content-disposition; bh=pqojRhZ8OTm8DdDMdn1Piumvt+wEmf+MNp8cMn84MV8=; b=SUMQR4PAs7mfpECZndn7twLHKXhYkt1ZiTY0Xb63bCMr2zbYVLbLXXyjUZj9ri+w2M i/yXlQAFCyZMCMzSgq/uMMP0EJl+5JJjsLV+vTOTWFwvrH0eqR5bIOYnEnDhRr1p+pZL 0wXuA3Hpgu8iE39UPByXYENoW+6ddrTQx5/5olyVdSgYGVv9Vk1uGzjBHFB1nXmJpLCY mfBrGsVMIffD6fiOypDiEPW45MMeMJ5IsCmFA610M8zRsnqsTlvKzjIQY+762IXgrMrV /kIQnzOkYXNKca0mDK0dWpH+1sN58tp5zOzIhcS/AMG2WaNVvu5SORDj5zaw6cfeeXvC b9pQ== X-Gm-Message-State: ALoCoQkCTIafEidiPdds0vtvZysqpoFMFlaI4BIQHtjXn/mGiy0dHcGcNHkXGraaj260xObwC/AZ X-Received: by 10.180.72.234 with SMTP id g10mr29047722wiv.52.1406157185576; Wed, 23 Jul 2014 16:13:05 -0700 (PDT) Received: from walrus.hopcount.ca ([2001:67c:370:176:b949:ad9a:f9e6:2f77]) by mx.google.com with ESMTPSA id fs3sm14761485wic.20.2014.07.23.16.13.03 for (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Jul 2014 16:13:04 -0700 (PDT) Date: Wed, 23 Jul 2014 19:13:01 -0400 From: Joe Abley To: Jay Daley , Frederico A C Neves Message-ID: In-Reply-To: <6AB35A29-3BB0-4386-9021-DC50A15AD58E@nzrs.net.nz> References: <20140723213403.GN94557@registro.br> <6AB35A29-3BB0-4386-9021-DC50A15AD58E@nzrs.net.nz> X-Mailer: Airmail (237) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/BOGgwH7k3YAcP_rm_RuG4xC-S4o Cc: Paul Wouters , dnsext@ietf.org Subject: Re: [dnsext] OPENPGPKEY RRTYPE review - Comments period ends Aug 6th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 23:13:08 -0000 Hi Jay, On 23 July 2014 at 19:09:06, Jay Daley (jay@nzrs.net.nz) wrote: > The text contains this specification element: > > 3. The string "_openpgpkey" becomes the second left-most label in > the prepared domain name. > > without any explanation (that I can see) of a) why it is needed and b) why openpgpkey has > been chosen. I have no skin in this game, but it seems to me that use of an underscore label is a reasonable way to avoid overloading a zone apex with yet another large RRType that would (if used) no doubt gleefully be abused by amplification monkeys. Joe From nobody Wed Jul 23 20:02:44 2014 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E56E1ADDC6 for ; Wed, 23 Jul 2014 20:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 c_y-1-0FJA-J for ; Wed, 23 Jul 2014 20:02:42 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B5181ADDB5 for ; Wed, 23 Jul 2014 20:02:42 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id 2965834948F; Thu, 24 Jul 2014 03:02:03 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 8D97C160054; Thu, 24 Jul 2014 03:11:20 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 5B39A16004E; Thu, 24 Jul 2014 03:11:20 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 225BB1AC420E; Thu, 24 Jul 2014 13:02:01 +1000 (EST) To: Joe Abley From: Mark Andrews References: <20140723213403.GN94557@registro.br> <6AB35A29-3BB0-4386-9021-DC50A15AD58E@nzrs.net.nz> In-reply-to: Your message of "Wed, 23 Jul 2014 19:13:01 -0400." Date: Thu, 24 Jul 2014 13:02:01 +1000 Message-Id: <20140724030201.225BB1AC420E@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/wOSYnllz-c2wdnL2ra5WsRokL2A Cc: Paul Wouters , dnsext@ietf.org Subject: Re: [dnsext] OPENPGPKEY RRTYPE review - Comments period ends Aug 6th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 03:02:43 -0000 In message , Joe Abley writes: > Hi Jay, > > On 23 July 2014 at 19:09:06, Jay Daley (jay@nzrs.net.nz) wrote: > > > The text contains this specification element: > > > > 3. The string "_openpgpkey" becomes the second left-most label in > > the prepared domain name. > > > > without any explanation (that I can see) of a) why it is needed and b) why > openpgpkey has > > been chosen. > > I have no skin in this game, but it seems to me that use of an underscore lab > el is a reasonable way to avoid overloading a zone apex with yet another larg > e RRType that would (if used) no doubt gleefully be abused by amplification m > onkeys. It also creates a distinct namespace for the mapped email addresses for this purpose. This is one thing the existing mbox encoding got wrong. > Joe > > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Jul 23 20:10:24 2014 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5310A1A0B07 for ; Wed, 23 Jul 2014 20:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 DEZwYLQX4rX0 for ; Wed, 23 Jul 2014 20:10:20 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by ietfa.amsl.com (Postfix) with ESMTP id 94CFA1A03C1 for ; Wed, 23 Jul 2014 20:10:19 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 0F42D4BA7A7; Thu, 24 Jul 2014 15:10:19 +1200 (NZST) X-Virus-Scanned: Debian amavisd-new at srsomail.office.nzrs.net.nz Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVzMnghWdnNx; Thu, 24 Jul 2014 15:10:07 +1200 (NZST) Received: from [192.168.22.129] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 88E0A4BBD32; Thu, 24 Jul 2014 15:10:07 +1200 (NZST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Jay Daley In-Reply-To: <20140724030201.225BB1AC420E@rock.dv.isc.org> Date: Thu, 24 Jul 2014 15:10:06 +1200 Content-Transfer-Encoding: quoted-printable Message-Id: <744FD952-8375-4053-8B1C-6CF759F2EC21@nzrs.net.nz> References: <20140723213403.GN94557@registro.br> <6AB35A29-3BB0-4386-9021-DC50A15AD58E@nzrs.net.nz> <20140724030201.225BB1AC420E@rock.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/S-FY8GnEapz6D0g32pwdhCrbFcU Cc: Paul Wouters , dnsext@ietf.org Subject: Re: [dnsext] OPENPGPKEY RRTYPE review - Comments period ends Aug 6th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 03:10:23 -0000 On 24/07/2014, at 3:02 pm, Mark Andrews wrote: >=20 > In message , Joe Abley = writes: >> Hi Jay, >>=20 >> On 23 July 2014 at 19:09:06, Jay Daley (jay@nzrs.net.nz) wrote: >>=20 >>> The text contains this specification element: >>>=20 >>> 3. The string "_openpgpkey" becomes the second left-most label in >>> the prepared domain name. >>>=20 >>> without any explanation (that I can see) of a) why it is needed and = b) why=20 >> openpgpkey has=20 >>> been chosen. >>=20 >> I have no skin in this game, but it seems to me that use of an = underscore lab >> el is a reasonable way to avoid overloading a zone apex with yet = another larg >> e RRType that would (if used) no doubt gleefully be abused by = amplification m >> onkeys. >=20 > It also creates a distinct namespace for the mapped email addresses > for this purpose. This is one thing the existing mbox encoding got > wrong. I understand that. My questions should perhaps be better put as=20 - why should there be a distinct namespace for mapped email addresses? =20= I see Joe has provided one reason (which doesn't appear to make sense to = me since a large RRType can't be 'hidden' lower down), but my point is = that there isn't a reason in the draft. - why should that distinct namespace have a 1 to 1 link with the RR that = it will contain? =20 This I think is something quite novel and worth a lot more discussion. cheers Jay >=20 >> Joe >>=20 >>=20 >> _______________________________________________ >> dnsext mailing list >> dnsext@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsext > --=20 > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 linkedin: www.linkedin.com/in/jaydaley From nobody Wed Jul 23 20:56:58 2014 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E548B1A0AEC for ; Wed, 23 Jul 2014 20:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 aPMMjqiLdWQT for ; Wed, 23 Jul 2014 20:56:55 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9D701A0217 for ; Wed, 23 Jul 2014 20:56:54 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 40FB11FCB15; Thu, 24 Jul 2014 03:56:51 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 46F91160068; Thu, 24 Jul 2014 04:06:08 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 1222A160064; Thu, 24 Jul 2014 04:06:08 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 425E81AC53EE; Thu, 24 Jul 2014 13:56:49 +1000 (EST) To: Jay Daley From: Mark Andrews References: <20140723213403.GN94557@registro.br> <6AB35A29-3BB0-4386-9021-DC50A15AD58E@nzrs.net.nz> <20140724030201.225BB1AC420E@rock.dv.isc.org> <744FD952-8375-4053-8B1C-6CF759F2EC21@nzrs.net.nz> In-reply-to: Your message of "Thu, 24 Jul 2014 15:10:06 +1200." <744FD952-8375-4053-8B1C-6CF759F2EC21@nzrs.net.nz> Date: Thu, 24 Jul 2014 13:56:48 +1000 Message-Id: <20140724035649.425E81AC53EE@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/vJRDWSEe9FpDjLsvIgr54EpGQO4 Cc: Paul Wouters , dnsext@ietf.org Subject: Re: [dnsext] OPENPGPKEY RRTYPE review - Comments period ends Aug 6th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 03:56:57 -0000 In message <744FD952-8375-4053-8B1C-6CF759F2EC21@nzrs.net.nz>, Jay Daley writes : > > On 24/07/2014, at 3:02 pm, Mark Andrews wrote: > > > > > In message , Joe Abley > > writes: > >> Hi Jay, > >> > >> On 23 July 2014 at 19:09:06, Jay Daley (jay@nzrs.net.nz) wrote: > >> > >>> The text contains this specification element: > >>> > >>> 3. The string "_openpgpkey" becomes the second left-most label in > >>> the prepared domain name. > >>> > >>> without any explanation (that I can see) of a) why it is needed and > >>> b) why openpgpkey has been chosen. > >> > >> I have no skin in this game, but it seems to me that use of an > >> underscore label is a reasonable way to avoid overloading a zone > >> apex with yet another large RRType that would (if used) no doubt > >> gleefully be abused by amplification monkeys. > > > > It also creates a distinct namespace for the mapped email addresses > > for this purpose. This is one thing the existing mbox encoding got > > wrong. > > I understand that. My questions should perhaps be better put as > > - why should there be a distinct namespace for mapped email addresses? > I see Joe has provided one reason (which doesn't appear to make sense to > me since a large RRType can't be 'hidden' lower down), but my point is > that there isn't a reason in the draft. Because it it is bad to mix foo.example.net the host with foo@example.net the email address as they are different entities. mbox did this. Both mapped to foo.example.net in the DNS. This results in overloading so you can't know which records at the name apply to which entity. Does a TXT record refer to foo.example.net or foo@example.net? > - why should that distinct namespace have a 1 to 1 link with the RR that > it will contain? > This I think is something quite novel and worth a lot more discussion. Take CERT for example. You may have may protocols that all use user@example.net but each has a different CERT record. By having different namespace for each protocol you avoid stuffing too many records at a node (we are still limited to 64k). If you want to use the same CERT for multiple services you can enter it multiple times or use CNAME to refer to a single instance. > cheers > Jay > > > > >> Joe > >> > >> > >> _______________________________________________ > >> dnsext mailing list > >> dnsext@ietf.org > >> https://www.ietf.org/mailman/listinfo/dnsext > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > > -- > Jay Daley > Chief Executive > .nz Registry Services (New Zealand Domain Name Registry Limited) > desk: +64 4 931 6977 > mobile: +64 21 678840 > linkedin: www.linkedin.com/in/jaydaley > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Jul 23 21:18:58 2014 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A10FB1A0AEE for ; Wed, 23 Jul 2014 21:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 oXk74PoOXYIu for ; Wed, 23 Jul 2014 21:18:54 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by ietfa.amsl.com (Postfix) with ESMTP id A77341A030E for ; Wed, 23 Jul 2014 21:18:53 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 34B114BBD7B; Thu, 24 Jul 2014 16:18:52 +1200 (NZST) X-Virus-Scanned: Debian amavisd-new at srsomail.office.nzrs.net.nz Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWJZWjEIjPSe; Thu, 24 Jul 2014 16:18:41 +1200 (NZST) Received: from [192.168.22.129] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id F0CCD4BBD24; Thu, 24 Jul 2014 16:18:40 +1200 (NZST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Jay Daley In-Reply-To: <20140724035649.425E81AC53EE@rock.dv.isc.org> Date: Thu, 24 Jul 2014 16:18:38 +1200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140723213403.GN94557@registro.br> <6AB35A29-3BB0-4386-9021-DC50A15AD58E@nzrs.net.nz> <20140724030201.225BB1AC420E@rock.dv.isc.org> <744FD952-8375-4053-8B1C-6CF759F2EC21@nzrs.net.nz> <20140724035649.425E81AC53EE@rock.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/tT8z1EenQD-dCalZGqlrRSbApZs Cc: Paul Wouters , dnsext@ietf.org Subject: Re: [dnsext] OPENPGPKEY RRTYPE review - Comments period ends Aug 6th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 04:18:56 -0000 On 24/07/2014, at 3:56 pm, Mark Andrews wrote: >> - why should there be a distinct namespace for mapped email = addresses? >> I see Joe has provided one reason (which doesn't appear to make sense = to >> me since a large RRType can't be 'hidden' lower down), but my point = is >> that there isn't a reason in the draft. >=20 > Because it it is bad to mix foo.example.net the host with = foo@example.net > the email address as they are different entities. mbox did this. > Both mapped to foo.example.net in the DNS. This results in = overloading > so you can't know which records at the name apply to which entity. = Does > a TXT record refer to foo.example.net or foo@example.net? Ah I see what you mean, though the hash algorithm means it's not a = straight foo to foo comparison. By using a hash nobody gets to choose = what the actual first label is, it is chosen for them by the algorithm = and so there's the possibility of collision now or future. But unless I = am missing something, the chances of someone needing a host that has the = same first label as a SHA2-224 hash are practically zero so I'm not sure = the issue is strong enough to insist on a distinct namespace . >> - why should that distinct namespace have a 1 to 1 link with the RR = that >> it will contain? >> This I think is something quite novel and worth a lot more = discussion. >=20 > Take CERT for example. You may have may protocols that all use > user@example.net but each has a different CERT record. By having > different namespace for each protocol you avoid stuffing too many > records at a node (we are still limited to 64k). If you want to > use the same CERT for multiple services you can enter it multiple > times or use CNAME to refer to a single instance. Hmm. Still thinking about that. cheers Jay >=20 >> cheers >> Jay >>=20 >>>=20 >>>> Joe >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> dnsext mailing list >>>> dnsext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dnsext >>> -- >>> Mark Andrews, ISC >>> 1 Seymour St., Dundas Valley, NSW 2117, Australia >>> PHONE: +61 2 9871 4742 INTERNET: marka@isc.org >>=20 >>=20 >> -- >> Jay Daley >> Chief Executive >> .nz Registry Services (New Zealand Domain Name Registry Limited) >> desk: +64 4 931 6977 >> mobile: +64 21 678840 >> linkedin: www.linkedin.com/in/jaydaley >>=20 >=20 > --=20 > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 linkedin: www.linkedin.com/in/jaydaley From nobody Thu Jul 24 03:06:43 2014 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE9D1A015F for ; Thu, 24 Jul 2014 03:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 0AUE3a_Bnbx7 for ; Thu, 24 Jul 2014 03:06:34 -0700 (PDT) Received: from smtp155.ord.emailsrvr.com (smtp155.ord.emailsrvr.com [173.203.6.155]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6FF41A0166 for ; Thu, 24 Jul 2014 03:06:33 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp12.relay.ord1a.emailsrvr.com (SMTP Server) with ESMTP id 3FC041000AC; Thu, 24 Jul 2014 06:06:32 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp12.relay.ord1a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id B977D10008D; Thu, 24 Jul 2014 06:06:31 -0400 (EDT) X-Sender-Id: ogud@ogud.com Received: from [10.3.14.139] ([UNAVAILABLE]. [207.164.179.98]) (using TLSv1 with cipher AES128-SHA) by 0.0.0.0:25 (trex/5.2.10); Thu, 24 Jul 2014 10:06:32 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_43A47817-E4CD-4F18-BC7A-B13E72D9D40D" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Olafur Gudmundsson In-Reply-To: <744FD952-8375-4053-8B1C-6CF759F2EC21@nzrs.net.nz> Date: Thu, 24 Jul 2014 06:06:31 -0400 Message-Id: <511E2E5F-022A-4B77-80DF-EF1B748EC7D9@ogud.com> References: <20140723213403.GN94557@registro.br> <6AB35A29-3BB0-4386-9021-DC50A15AD58E@nzrs.net.nz> <20140724030201.225BB1AC420E@rock.dv.isc.org> <744FD952-8375-4053-8B1C-6CF759F2EC21@nzrs.net.nz> To: Jay Daley X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/wYxhJbQ2QGVYXg15cI4w-oVJw1Y Cc: Paul Wouters , "dnsext@ietf.org Group" Subject: Re: [dnsext] OPENPGPKEY RRTYPE review - Comments period ends Aug 6th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 10:06:38 -0000 --Apple-Mail=_43A47817-E4CD-4F18-BC7A-B13E72D9D40D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 =20 On Jul 23, 2014, at 11:10 PM, Jay Daley wrote: >=20 > On 24/07/2014, at 3:02 pm, Mark Andrews wrote: >=20 >>=20 >> In message , Joe = Abley writes: >>> Hi Jay, >>>=20 >>> On 23 July 2014 at 19:09:06, Jay Daley (jay@nzrs.net.nz) wrote: >>>=20 >>>> The text contains this specification element: >>>>=20 >>>> 3. The string "_openpgpkey" becomes the second left-most label in >>>> the prepared domain name. >>>>=20 >>>> without any explanation (that I can see) of a) why it is needed and = b) why=20 >>> openpgpkey has=20 >>>> been chosen. >>>=20 >>> I have no skin in this game, but it seems to me that use of an = underscore lab >>> el is a reasonable way to avoid overloading a zone apex with yet = another larg >>> e RRType that would (if used) no doubt gleefully be abused by = amplification m >>> onkeys. >>=20 >> It also creates a distinct namespace for the mapped email addresses >> for this purpose. This is one thing the existing mbox encoding got >> wrong. >=20 > I understand that. My questions should perhaps be better put as=20 >=20 > - why should there be a distinct namespace for mapped email addresses? = =20 > I see Joe has provided one reason (which doesn't appear to make sense = to me since a large RRType can't be 'hidden' lower down), but my point = is that there isn't a reason in the draft. >=20 Few reasons, one not to collide with regular names (unlikely in the = first place)=20 Secondly this allows the namespace to be delegated to the E-mail = department to maintain.=20 Thirdly if you do not want to have this extra label then you can just do = the following _openpgpkey.foo.example. DNAME foo.example.=20 or=20 _openpgpkey.foo.example. DNAME _email.foo.example.=20 > - why should that distinct namespace have a 1 to 1 link with the RR = that it will contain? =20 > This I think is something quite novel and worth a lot more discussion. >=20 Good point, namespaces are cheap, but we should think about the big = picture.=20 Well we also have a Smime draft that has different namespace = =93_smimecert=94=20 maybe we should think about having only one namespace for email =93certs=94= .=20 This is a discussion that probably needs bigger review than dnsext. Olafur > cheers > Jay >=20 >>=20 >>> Joe >>>=20 >>>=20 >>> _______________________________________________ >>> dnsext mailing list >>> dnsext@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnsext >> --=20 >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: marka@isc.org >=20 >=20 > --=20 > Jay Daley > Chief Executive > .nz Registry Services (New Zealand Domain Name Registry Limited) > desk: +64 4 931 6977 > mobile: +64 21 678840 > linkedin: www.linkedin.com/in/jaydaley >=20 > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext --Apple-Mail=_43A47817-E4CD-4F18-BC7A-B13E72D9D40D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 <hat dane co-chair> 
On Jul = 23, 2014, at 11:10 PM, Jay Daley <jay@nzrs.net.nz> wrote:


On 24/07/2014, at 3:02 pm, Mark = Andrews <marka@isc.org> = wrote:


In message <etPan.53d04= 17d.71ea1109.105@walrus.hopcount.ca>, Joe Abley = writes:
Hi Jay,

On 23 July 2014 at = 19:09:06, Jay Daley (jay@nzrs.net.nz) = wrote:

The text contains this = specification element:

3. The string "_openpgpkey" becomes the = second left-most label in
the prepared domain name.

without = any explanation (that I can see) of a) why it is needed and b) why 
openpgpkey = has 
been chosen.

I have no skin in this = game, but it seems to me that use of an underscore lab
el is a = reasonable way to avoid overloading a zone apex with yet another = larg
e RRType that would (if used) no doubt gleefully be abused by = amplification m
onkeys.

It also creates a = distinct namespace for the mapped email addresses
for this purpose. =  This is one thing the existing mbox encoding = got
wrong.

I understand that.  My questions = should perhaps be better put as 

- why should there = be a distinct namespace for mapped email addresses?  
I see Joe = has provided one reason (which doesn't appear to make sense to me since = a large RRType can't be 'hidden' lower down), but my point is that there = isn't a reason in the = draft.


Few reasons, one not to = collide with regular names (unlikely in the first = place) 
Secondly this allows the namespace to be = delegated to the E-mail department to maintain. 
Thirdly = if you do not want to have this extra label then you can just do the = following
_openpgpkey.foo.example. =  DNAME foo.example. 
or 
= _openpgpkey.foo.example. DNAME = _email.foo.example. 

- why should that distinct namespace = have a 1 to 1 link with the RR that it will contain?  
This I = think is something quite novel and worth a lot more = discussion.



Good = point, namespaces are cheap, but we should think about the big = picture. 
Well we also have a Smime draft that has = different namespace =93_smimecert=94 
maybe we should = think about having only one namespace for email = =93certs=94. 

This is a discussion that = probably needs bigger review than dnsext.

= Olafur

cheers
Jay


Joe


_____________________________________________= __
dnsext mailing list
dnsext@ietf.org
https://www.ietf.or= g/mailman/listinfo/dnsext
-- 
Mark Andrews, ISC
1 = Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 = 4742 =             &n= bsp;   INTERNET: marka@isc.org


--=  
Jay = Daley
Chief Executive
.nz Registry Services (New Zealand Domain = Name Registry Limited)
desk: +64 4 931 6977
mobile: +64 21 = 678840
linkedin: www.linkedin.com/in/jaydaley<= /a>

_______________________________________________
dnsext = mailing list
dnsext@ietf.org
https://www.ietf.org= /mailman/listinfo/dnsext

= --Apple-Mail=_43A47817-E4CD-4F18-BC7A-B13E72D9D40D-- From nobody Thu Jul 24 09:19:10 2014 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F22B1A0058 for ; Thu, 24 Jul 2014 09:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] 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 W_0G8CoGuQIG for ; Thu, 24 Jul 2014 09:19:03 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 894A81A0240 for ; Thu, 24 Jul 2014 09:19:02 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id w62so2909596wes.8 for ; Thu, 24 Jul 2014 09:18:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type:content-transfer-encoding :content-disposition; bh=xP5T4KabxhanSE3w5wSHWjj219Yisqxb8fOvpadMRP4=; b=gbZdMIEFcDEUI/wTlZQ0s3EtJ1kZFIotdH8cgUDw23ppEVObqtenUzViafu9g4yUmd EeE3RxA6kDKZGUOFG1YsqLGeDBaqOOTbkLqc2AC6d5TTwOlcFx0fQ2h70MnP9skj6n8B 79WzR6ErzVGeopmCx0Lp3AVJCtwf0mA7GAyXs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:content-type :content-transfer-encoding:content-disposition; bh=xP5T4KabxhanSE3w5wSHWjj219Yisqxb8fOvpadMRP4=; b=gfLGXsoiw9ni5PU/QUxU3S/5TyIMYW8C5mv1eH18soiVPlbvEyAowiH9rFm+39geDr zwRJcFN18QUcBZqUy9SXUfUw4tEWrTpIPziSWAByNT+TR6RUhmyPMXvbGo1Cie9DAwHp q6NG8yDTLhZeKY87XAbMdgxu9V9GISsRli37rBxyfXXy+0vyauodtZjUvMgv+t9M0HrB bwgTbbREFgZpceXvgjJANBvQRclr06Mh6EsCgbSEY9ww+oo/EL7VtfacqMfaaY6PnGxk Mma6YXQ+IpSQR3fhBBqqDRusopX5XjZvuLudiI2fHw5MMc9ivTfvM8CvciCOhMxwFZiq EJ1A== X-Gm-Message-State: ALoCoQkijGzLu4zM7h/uuZR1bMe6/sVXJFp5ijNGydlZtieuIS6SQ2Q2nouCU+eSLTu0p3QPvSo/ X-Received: by 10.194.200.3 with SMTP id jo3mr13998893wjc.110.1406218739245; Thu, 24 Jul 2014 09:18:59 -0700 (PDT) Received: from walrus.hopcount.ca (dhcp-b3a2.meeting.ietf.org. [31.133.179.162]) by mx.google.com with ESMTPSA id pj6sm17092986wjb.21.2014.07.24.09.18.57 for (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Jul 2014 09:18:58 -0700 (PDT) Date: Thu, 24 Jul 2014 12:18:56 -0400 From: Joe Abley To: Jay Daley , Mark Andrews Message-ID: In-Reply-To: <744FD952-8375-4053-8B1C-6CF759F2EC21@nzrs.net.nz> References: <20140723213403.GN94557@registro.br> <6AB35A29-3BB0-4386-9021-DC50A15AD58E@nzrs.net.nz> <20140724030201.225BB1AC420E@rock.dv.isc.org> <744FD952-8375-4053-8B1C-6CF759F2EC21@nzrs.net.nz> X-Mailer: Airmail (237) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/kn-MmaYGMKstM5XziPS4puau8E0 Cc: Paul Wouters , dnsext@ietf.org Subject: Re: [dnsext] OPENPGPKEY RRTYPE review - Comments period ends Aug 6th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 16:19:05 -0000 On 23 July 2014 at 23:10:21, Jay Daley (jay=40nzrs.net.nz) wrote: > I see Joe has provided one reason (which doesn't appear to make sense t= o me since a large =20 > RRType can't be 'hidden' lower down), I was referring to the ongoing habit of choosing an apex QNAME and using = QTYPE=3DANY in a reflection attack; the more stuff you load into the apex= owner name, the bigger the amplifier. =46rom that perspective the more a= pex-related stuff you can shift to sub-layers, the worse the amplifier, t= he better the Internet. > but my point is that there isn't a reason in the draft.=C2=A0 ... and that is a fair point. Joe From nobody Thu Jul 24 09:38:23 2014 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38ED71A03D4 for ; Thu, 24 Jul 2014 09:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 jHzbxU2WNnJN for ; Thu, 24 Jul 2014 09:38:11 -0700 (PDT) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id BE54E1A03E7 for ; Thu, 24 Jul 2014 09:38:11 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id B5FD02C4063; Thu, 24 Jul 2014 09:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ZFglxlRRCai3; Thu, 24 Jul 2014 09:38:11 -0700 (PDT) Received: from gala.icir.org (gala.icir.org [192.150.187.130]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id E9B372C400A; Thu, 24 Jul 2014 09:38:10 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_F7F7EEE6-E110-4FC3-99CA-ADA944F9B412"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Nicholas Weaver In-Reply-To: Date: Thu, 24 Jul 2014 09:38:10 -0700 Message-Id: References: <20140723213403.GN94557@registro.br> <6AB35A29-3BB0-4386-9021-DC50A15AD58E@nzrs.net.nz> <20140724030201.225BB1AC420E@rock.dv.isc.org> <744FD952-8375-4053-8B1C-6CF759F2EC21@nzrs.net.nz> To: Joe Abley X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/kLy_eA_Wx6vJVwDiXm8GP5trGIw Cc: Paul Wouters , dnsext@ietf.org Subject: Re: [dnsext] OPENPGPKEY RRTYPE review - Comments period ends Aug 6th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 16:38:18 -0000 --Apple-Mail=_F7F7EEE6-E110-4FC3-99CA-ADA944F9B412 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 24, 2014, at 9:18 AM, Joe Abley wrote: >=20 >=20 > On 23 July 2014 at 23:10:21, Jay Daley (jay@nzrs.net.nz) wrote: >=20 >> I see Joe has provided one reason (which doesn't appear to make sense = to me since a large =20 >> RRType can't be 'hidden' lower down), >=20 > I was referring to the ongoing habit of choosing an apex QNAME and = using QTYPE=3DANY in a reflection attack; the more stuff you load into = the apex owner name, the bigger the amplifier. =46rom that perspective = the more apex-related stuff you can shift to sub-layers, the worse the = amplifier, the better the Internet. Attackers can (and have in the past) created their own domain that = serves a very cacheable, arbitrarily-large response. -- Nicholas Weaver it is a tale, told by an idiot, nweaver@icsi.berkeley.edu full of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc --Apple-Mail=_F7F7EEE6-E110-4FC3-99CA-ADA944F9B412 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCgAGBQJT0TZyAAoJEG2B1w+SDi/uY38P/2sp685XyxztCk5WW5wIuTC7 9Y4P30rlgztHCCS8X+RCtGDGVRgZvGQQh75H5oxmzzUOFH/odwrBT2TxhqXIAEk3 24GjLoRk/ER/hHosMSxLiJ4JYto91xTGpIGYcBgEqB51Qnp70rYlEUSAHCVjAafn 3OhQcMaf6V6hi0cYJlRyg6UrFpd/fevhsVhV65GlwHgWiw1AJXmLBuChVi+FFT3S qo0lTWVRLHLqfaXUICqU59lwvz5mrXFnV07yL5ih11xKbQcWTtBmst6ATFKfZ771 WmZrNwZVKU4pdUkX3hqCOuHMpNP9NV1/FjpVTtdgv02oF9FvBh8pZ8iF64REv0r7 nVQRXbEKYWG/pAue4rI/PtcxxHNuAqa1BNik8h8XUKbN/DI8N08H7/Zdg5jAzHFA RQSWAueuWEyPavBcA9xT4ry/nwa7sMdIm3lm/MdVDa8PquDdLU/MYyAgA3V+kIyH +RNIhzVOyWFasQlJElQK6iBNLJXEk2YzmAYD/gQWGj1xPAAFNKsJF6WLtu2FCgdm WNSagxAR3i3UcXCNpX5LvIjaEbV0rwXcBbit94HgJ0xclAHc7wT4CQCZAdrcdUe/ HHBi1S+Vlz51YohLaFST32YUM3S6Cp+M9dozlHuFp2vxdOi2fyAHldikAxhGtw4A age8FR4t4x2ZAuuPQkYz =JNob -----END PGP SIGNATURE----- --Apple-Mail=_F7F7EEE6-E110-4FC3-99CA-ADA944F9B412-- From nobody Thu Jul 24 14:07:05 2014 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 030941ABB32 for ; Thu, 24 Jul 2014 14:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_37=0.6, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 V5qyI2tHAk1e for ; Thu, 24 Jul 2014 14:07:00 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by ietfa.amsl.com (Postfix) with ESMTP id D02FA1ABB17 for ; Thu, 24 Jul 2014 14:06:59 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id DA79B4BA467; Fri, 25 Jul 2014 09:06:57 +1200 (NZST) X-Virus-Scanned: Debian amavisd-new at srsomail.office.nzrs.net.nz Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrnW2g+cTNQX; Fri, 25 Jul 2014 09:06:47 +1200 (NZST) Received: from [192.168.22.129] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 97BB54B9E8B; Fri, 25 Jul 2014 09:06:47 +1200 (NZST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Jay Daley In-Reply-To: <511E2E5F-022A-4B77-80DF-EF1B748EC7D9@ogud.com> Date: Fri, 25 Jul 2014 09:06:45 +1200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140723213403.GN94557@registro.br> <6AB35A29-3BB0-4386-9021-DC50A15AD58E@nzrs.net.nz> <20140724030201.225BB1AC420E@rock.dv.isc.org> <744FD952-8375-4053-8B1C-6CF759F2EC21@nzrs.net.nz> <511E2E5F-022A-4B77-80DF-EF1B748EC7D9@ogud.com> To: Olafur Gudmundsson X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/dc7_tI8NEcroe4EX_edkt7YiJk4 Cc: Paul Wouters , "dnsext@ietf.org Group" Subject: Re: [dnsext] OPENPGPKEY RRTYPE review - Comments period ends Aug 6th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 21:07:04 -0000 Hi Olafur >> - why should there be a distinct namespace for mapped email = addresses? =20 >=20 > Few reasons, one not to collide with regular names (unlikely in the = first place)=20 > Secondly this allows the namespace to be delegated to the E-mail = department to maintain.=20 > Thirdly if you do not want to have this extra label then you can just = do the following > _openpgpkey.foo.example. DNAME foo.example.=20 > or=20 > _openpgpkey.foo.example. DNAME _email.foo.example.=20 >=20 >> - why should that distinct namespace have a 1 to 1 link with the RR = that it will contain? =20 >> This I think is something quite novel and worth a lot more = discussion. >=20 > Good point, namespaces are cheap, but we should think about the big = picture.=20 > Well we also have a Smime draft that has different namespace = =93_smimecert=94=20 > maybe we should think about having only one namespace for email = =93certs=94.=20 >=20 > This is a discussion that probably needs bigger review than dnsext. Actually I think your DNAME example solves any issues for me. If = someone wanted to they could have _openpgpkey.foo.example. DNAME _email.foo.example. _smimecert.foo.example. DNAME _email.foo.example. which is quite neat and hopefully makes DNAME a more common RR. cheers Jay >=20 > Olafur >=20 >> cheers >> Jay >>=20 >>>=20 >>>> Joe >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> dnsext mailing list >>>> dnsext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dnsext >>> --=20 >>> Mark Andrews, ISC >>> 1 Seymour St., Dundas Valley, NSW 2117, Australia >>> PHONE: +61 2 9871 4742 INTERNET: marka@isc.org >>=20 >>=20 >> --=20 >> Jay Daley >> Chief Executive >> .nz Registry Services (New Zealand Domain Name Registry Limited) >> desk: +64 4 931 6977 >> mobile: +64 21 678840 >> linkedin: www.linkedin.com/in/jaydaley >>=20 >> _______________________________________________ >> dnsext mailing list >> dnsext@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsext --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 linkedin: www.linkedin.com/in/jaydaley From nobody Fri Jul 25 10:22:12 2014 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F08EF1A0240; Fri, 25 Jul 2014 10:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_BELOW2=2.154, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 oWX3N73IjtE3; Fri, 25 Jul 2014 10:22:09 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 2B5591A01E2; Fri, 25 Jul 2014 10:22:09 -0700 (PDT) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s6PHM83j017274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 25 Jul 2014 13:22:08 -0400 Received: from pspacek.brq.redhat.com (pspacek.brq.redhat.com [10.34.4.156]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s6PHM6sc007574 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 25 Jul 2014 13:22:07 -0400 Message-ID: <53D2923E.6080903@redhat.com> Date: Fri, 25 Jul 2014 19:22:06 +0200 From: Petr Spacek Organization: Red Hat User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dnsext@ietf.org, dane WG list , Paul Wouters References: <20140723213403.GN94557@registro.br> In-Reply-To: <20140723213403.GN94557@registro.br> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/iwMzOt3y1JviUUQAwEPg5Y9HQHA Subject: Re: [dnsext] OPENPGPKEY RRTYPE review - Comments period ends Aug 6th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 17:22:11 -0000 Hello, On 23.7.2014 23:34, Frederico A C Neves wrote: > Dear Colleagues, > > Bellow is a completed template requesting a new RRTYPE assignment > under the procedures of RFC6895. > > This message starts a 2 weeks period for an expert review of the DNS > RRTYPE parameter allocation for OPENPGPKEY specified at: > > http://tools.ietf.org/html/draft-ietf-dane-openpgpkey-00#section-2 I was asking dane-list [1] if it makes sense to publish PGP key revocation certificate in OPENPGPKEY. I haven't heard any reply to this idea yet (maybe it is too dumb idea to warrant single reply). There is one important detail to note: - OPENPGPKEY as proposed requires DNSSEC protection (it is public key). - Key revocation certificate doesn't require DNSSEC because the certificate itself is signed. I think it is worth considering support for key revocation certificates in DNS because they can be deployed even more easily and rapidly (because DNSSEC is not required). The question is if it makes sense to publish both types of data using: - Different RR type (a la OPENPGPREVOC) - The same RR type but under different _prefix (_revoc._openpgpkey?) - Under the same owner name and RR type, which would (I guess) require an additional field in OPENPGPKEY RR type Mixing keys and revocation data in single RR set will obviously result in bigger replies. The question is if client should verify always verify that the other keys of the same user were not revoked so it could make sense to send him all the data in one response. (The older key could be obtained via non-DNS means etc.) On the other hand, "_openpgpkey aware" clients could always check live data in DNS and use only keys which are present in DNS at the moment. In that case removing RR which represents particular key will have the same affect as key revocation (but only for "_openpgpkey aware" clients). Unfortunately I will not be available for next two weeks so I'm throwing the idea to mailing list without any promise to reply before 2014-08-11. [1] http://www.ietf.org/mail-archive/web/dane/current/msg06672.html -- Petr Spacek @ Red Hat From nobody Fri Jul 25 11:11:03 2014 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 317091A0426; Fri, 25 Jul 2014 11:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.254 X-Spam-Level: X-Spam-Status: No, score=0.254 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_BELOW2=2.154] autolearn=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 ytuYXjdYkMMz; Fri, 25 Jul 2014 11:11:00 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4F4F1A040C; Fri, 25 Jul 2014 11:10:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id CFC76E2034; Fri, 25 Jul 2014 14:10:58 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 08126-07; Fri, 25 Jul 2014 14:10:57 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 0FE99E2031; Fri, 25 Jul 2014 14:10:57 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id s6PIAuCa003989; Fri, 25 Jul 2014 14:10:56 -0400 From: Derek Atkins To: Petr Spacek References: <20140723213403.GN94557@registro.br> <53D2923E.6080903@redhat.com> Date: Fri, 25 Jul 2014 14:10:56 -0400 In-Reply-To: <53D2923E.6080903@redhat.com> (Petr Spacek's message of "Fri, 25 Jul 2014 19:22:06 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/fdIkVmj2tVTeNVqcGrER3LuFhQw Cc: Paul Wouters , dnsext@ietf.org, dane WG list Subject: Re: [dnsext] OPENPGPKEY RRTYPE review - Comments period ends Aug 6th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 18:11:01 -0000 Petr Spacek writes: > Hello, > > On 23.7.2014 23:34, Frederico A C Neves wrote: >> Dear Colleagues, >> >> Bellow is a completed template requesting a new RRTYPE assignment >> under the procedures of RFC6895. >> >> This message starts a 2 weeks period for an expert review of the DNS >> RRTYPE parameter allocation for OPENPGPKEY specified at: >> >> http://tools.ietf.org/html/draft-ietf-dane-openpgpkey-00#section-2 > > I was asking dane-list [1] if it makes sense to publish PGP key > revocation certificate in OPENPGPKEY. I haven't heard any reply to > this idea yet (maybe it is too dumb idea to warrant single reply). > > There is one important detail to note: > - OPENPGPKEY as proposed requires DNSSEC protection (it is public key). Note that this public key could still (theoretically) be signed. Unless DANE is specifying it differently there should be no limitation that it be *just* the public key. > - Key revocation certificate doesn't require DNSSEC because the > certificate itself is signed. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From nobody Fri Jul 25 13:32:46 2014 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFFB51A0310; Fri, 25 Jul 2014 13:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 mBraKxFWjK84; Fri, 25 Jul 2014 13:32:43 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.23.85]) (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 D64DB1A008B; Fri, 25 Jul 2014 13:32:43 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 292D61E34C; Fri, 25 Jul 2014 20:26:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1406320013; bh=/HBlrbk0AGyBqjGE96hHcOE6/Xlgyr9gHfLn9HCDqsY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ZXuN1s3AWhXnmeYKt3oMDg5mStjPAkmvs/InPn5Zi8fGCNancMUge6SDFdxGc4jIf p1NrmuTBLnvdHoMRgdypb0pvZrWWBXjVEEgdIbpN6z0xyePQyuY2Vpb+Lo9qkyULD/ KOb7X6L9k8QcTPgpQSiW5d7pZqpqWwRqfFpBMvgw= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 3C1F560021; Fri, 25 Jul 2014 20:12:20 +0000 (UTC) From: James Cloos To: Petr Spacek In-Reply-To: <53D2923E.6080903@redhat.com> (Petr Spacek's message of "Fri, 25 Jul 2014 19:22:06 +0200") References: <20140723213403.GN94557@registro.br> <53D2923E.6080903@redhat.com> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Fri, 25 Jul 2014 16:12:20 -0400 Message-ID: Lines: 23 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:140725:pspacek@redhat.com::uyv4082CjbddjwXt:000000000000000000000000000000000000000000DX/Gf X-Hashcash: 1:30:140725:dnsext@ietf.org::6FvcXPhe3XbrhWnd:00r/hr X-Hashcash: 1:30:140725:dane@ietf.org::clcXhWdAmGl7fsBi:000DYnbB X-Hashcash: 1:30:140725:pwouters@redhat.com::1bDqaRYGQqj9iu0C:00000000000000000000000000000000000000000cQsdG Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/bSDw2NdXfWs1ys_4rYyJojCKeRY Cc: Paul Wouters , dnsext@ietf.org, dane WG list Subject: Re: [dnsext] [dane] OPENPGPKEY RRTYPE review - Comments period ends Aug 6th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 20:32:44 -0000 >>>>> "PS" == Petr Spacek writes: PS> I was asking dane-list [1] if it makes sense to publish PGP key PS> revocation certificate in OPENPGPKEY. I haven't heard any reply to PS> this idea yet (maybe it is too dumb idea to warrant single reply). I must have missed that last paragraph when I replied to the other part of that mail. If one is to publish openpgp keys in dns, then also publishing related revocation certs seems reasonable. If the querier already has a path through the WoT to the revoked key, a revocation signed by that key indeed does not need a dnssec trust path, too. But if the querier does not have a WoT path, they would benefit from the dnssec path. So as you wrote a signed revocation is useful even w/o dnssec, but dnssec does benefit some. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Sun Jul 27 15:49:24 2014 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5F4F1A0A89; Sun, 27 Jul 2014 15:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.103 X-Spam-Level: X-Spam-Status: No, score=-0.103 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 2NjL3N1mjx-5; Sun, 27 Jul 2014 15:49:21 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) (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 A22521A02D1; Sun, 27 Jul 2014 15:49:21 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id E23281E26E; Sun, 27 Jul 2014 22:49:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1406501359; bh=z6SgzOM2M80UEfVl1a9XJkl6rQWThwDIRBKJVzhQlmg=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Jt/dv/7TiwOnuVUozo2YFCHdzQKQUhTuRRW3ZolZPkP4Y3QbHZkys8KbJ8vbOc9se oQfglujvRrVlM17ev7dwvK6iUmKOyRA6O+2dBCt4zc/FB2j545vv233b4eEdJSL2KH Q3YAAkdoGw13v6+5pE+mdBKtZ5MpojANUxZ6kSQo= Received: by carbon.jhcloos.org (Postfix, from userid 500) id C6A6C60021; Sun, 27 Jul 2014 22:23:11 +0000 (UTC) From: James Cloos To: Derek Atkins In-Reply-To: (Derek Atkins's message of "Fri, 25 Jul 2014 14:10:56 -0400") References: <20140723213403.GN94557@registro.br> <53D2923E.6080903@redhat.com> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Sun, 27 Jul 2014 18:23:11 -0400 Message-ID: Lines: 23 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:140727:warlord@mit.edu::JpeUjmMZW89w2UdM:0Od/kz X-Hashcash: 1:30:140727:pspacek@redhat.com::Y6Gm3Sx7BLXkI/qJ:0000000000000000000000000000000000000000003SoMI X-Hashcash: 1:30:140727:pwouters@redhat.com::qtygxFJNX5thpr85:00000000000000000000000000000000000000000Oxff2 X-Hashcash: 1:30:140727:dnsext@ietf.org::QT+T+mPug51WHDQV:0IqPkJ X-Hashcash: 1:30:140727:dane@ietf.org::Q1JVGuzbJ5kROGMu:000ADRps Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/B1uKRF2YOWKaV2n7MyoTOaRn4Yk Cc: Paul Wouters , dnsext@ietf.org, dane WG list Subject: Re: [dnsext] OPENPGPKEY RRTYPE review - Comments period ends Aug 6th X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jul 2014 22:49:23 -0000 >>>>> "DA" == Derek Atkins writes: DA> Note that this public key could still (theoretically) be signed. Unless DA> DANE is specifying it differently there should be no limitation that it DA> be *just* the public key. That is an important point; unsigned OPENPGPKEY provides similar benefits as using the key servers. Part of the motivation for OPENPGPKEY was to provide an additional trust path to the dnssec root for those who lack a existing or sufficient path through the WoT. (I think everyone agrees that a nice path through the WoT to a key with ultimate trust is better, but if you WoT path is weak or non-extant than dns can at least provide /some/ trust.) Another aspect of the motivation is to have similar discovery paths for openpgp and smime -- where a dns trust path is arguably more useful. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6