From nobody Wed Oct 1 04:50:19 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C24C1A031F for ; Wed, 1 Oct 2014 04:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 6lZmQkXU3ebs for ; Wed, 1 Oct 2014 04:50:12 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0630.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:630]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 581C81A0324 for ; Wed, 1 Oct 2014 04:50:12 -0700 (PDT) Received: from BLUPR06MB243.namprd06.prod.outlook.com (10.242.191.154) by BLUPR06MB242.namprd06.prod.outlook.com (10.242.191.142) with Microsoft SMTP Server (TLS) id 15.0.1044.10; Wed, 1 Oct 2014 11:49:48 +0000 Received: from BLUPR06MB243.namprd06.prod.outlook.com ([169.254.7.32]) by BLUPR06MB243.namprd06.prod.outlook.com ([169.254.7.32]) with mapi id 15.00.1044.008; Wed, 1 Oct 2014 11:49:48 +0000 From: Dan York To: Jakob Schlyter Thread-Topic: [dane] Meeting in Hawaii? Thread-Index: AQHP2e1N0sxoKa3TGEiYsJUk3FqZjZwYjveAgAKYx4A= Date: Wed, 1 Oct 2014 11:49:48 +0000 Message-ID: <4C36FDC5-12D2-48C1-A3D5-7AA4090E98C8@isoc.org> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [2604:6000:9fc0:53:801e:5527:2cfe:8df6] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB242; x-forefront-prvs: 0351D213B3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(199003)(189002)(24454002)(377454003)(64706001)(110136001)(20776003)(86362001)(31966008)(46102003)(19580395003)(80022003)(19580405001)(10300001)(85852003)(21056001)(83716003)(92566001)(97736003)(92726001)(107046002)(2656002)(33656002)(54356999)(76176999)(19617315012)(50986999)(101416001)(87936001)(85306004)(105586002)(106116001)(106356001)(77096002)(36756003)(4396001)(82746002)(15975445006)(99396003)(76482002)(16236675004)(95666004)(99286002)(120916001)(104396001)(3826002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB242; H:BLUPR06MB243.namprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_4C36FDC512D248C1A3D57AA4090E98C8isocorg_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org Archived-At: http://mailarchive.ietf.org/arch/msg/dane/EXa7D7HkRx3LUhH0Kzvv-RdAJmA Cc: "" Subject: Re: [dane] Meeting in Hawaii? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 11:50:15 -0000 --_000_4C36FDC512D248C1A3D57AA4090E98C8isocorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Warren, (and everyone else) On Sep 29, 2014, at 4:10 PM, Jakob Schlyter > wrote: On 27 sep 2014, at 02:52, Warren Kumari > wrote: Please let us know if you'd really like to meet, and open issues on documents that need discussing. Also, if you have a doc, we'd like it revised *soon*. All the authors of the various drafts on DANE for email (S/MIME and OpenPGP= ) will be there, and we will have discussions on the list beforehand. Given= this, I for one, hope we can meet and flesh out any details left on this t= opic. To Jakob's point, we're going to have a significant number of the DANE-rela= ted authors and implementors all together at IETF and I think a general top= ic of "What Else Do We Need To Do For DANE For Email" could be a good discu= ssion topic. While we have this great big "DANE brain trust" all in one location (and al= so coming in remotely), I would be interested in having (and would be willi= ng to lead, if necessary) a discussion around "What Else Do We Need To Do T= o Get DANE More Widely Deployed". Now that we are seeing actual deployment= and usage, are there things we have learned that can guide us in accelerat= ing the deployment of DANE? We've captured a good bit of implementation guidance in Viktor and Wes' htt= ps://tools.ietf.org/html/draft-ietf-dane-ops-06 and so perhaps a review of = that document would help, but I'm also interested in questions like: - what roadblocks are people running into with implementing DANE? (outside= of the broader issue of getting DNSSEC validation and signing more widely = available) - are there more "Using DANE with " types of documents that we can or = should create? (and who is willing to do so) - have we seen areas where more standardization would help? - are there some good examples/case studies of DANE implementations that we= could perhaps capture as informational RFCs? (the Jabber community's impl= ementation comes to mind) - are there places where it would be helpful if there were reference implem= entations of DANE support? For example, DANE for email got a boost when Vi= ktor added it to postfix. Are there other commonly-used open source projec= ts where the addition of DANE support would help move deployment along? (= I'm NOT saying that the DANE WG would be involved with these implementation= s... but brainstorming together and identifying a list could help other peo= ple and groups (ex. Internet Society, Verisign Labs, NLNet Labs) advocate a= nd perhaps fund efforts to get that DANE support added.) - are there test tools that need to be developed? or existing ones that nee= d to be better promoted? are there interop tests we can arrange? I realize some of this may seem outside our charter, but if I look at the c= harter, it includes these phrases: ----- The DANE WG shall also produce a set of implementation guidance for operators and tool developers. The group may also create documents that describe how protocol entities can discover and validate these bindings in the execution of specific applications. This work would be done in coordination with the IETF Working Groups responsible for the protocols. The group may in addition encourage interoperability testing and document the results of such testing. ----- So I do see a good bit of this covered under that. The end result I'd like to see out of this discussion would be: - guidance for the WG on what, if any, additional documents we need to crea= te (and identification of who might write them) - potential interoperability testing - guidance to WG members and other organizations on how we can get DANE mor= e widely deployed Obviously I have an interest in this because I'm employed by the Internet S= ociety in large part to do whatever possible to accelerate the deployment o= f DNSSEC (and IPv6 and... ), but this really means that I'm here for *you* = all to help do what needs to be done. I'd definitely appreciate a sense of= the group about what we can all collectively do to make DANE more widely u= sed. Certainly we can have some of this discussion on the list... but in a= f2f meeting we can have a much more engaged discussion. So if we have time on the agenda and you all feel it would be appropriate, = I'd like to have a discussion along these lines. I'm not sure we need 2 hours though - 1,5 hours should be enough. I'm also not sure we need 2 hours... although this discussion I outlined ab= ove could wind up occupying some time. Dan --_000_4C36FDC512D248C1A3D57AA4090E98C8isocorg_ Content-Type: text/html; charset="us-ascii" Content-ID: <85BB8323B44A1443B660FB0203DD0262@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Warren, (and everyone else)

On Sep 29, 2014, at 4:10 PM, Jakob Schlyter <jakob@kirei.se> wrote:

On 27 sep 2014, at 02:52, Warren Kumari <warren@kumari.net> wrote:

Please let us know if you'd really like to meet, = and open issues on
documents that need discussing. Also, if you have a doc, we'd like it
revised *soon*.

All the authors of the various drafts on DANE for email (S/MIME and OpenPGP= ) will be there, and we will have discussions on the list beforehand. Given= this, I for one, hope we can meet and flesh out any details left on this t= opic.

To Jakob's point, we're going to have a significant number of the DANE= -related authors and implementors all together at IETF and I think a genera= l topic of "What Else Do We Need To Do For DANE For Email" could = be a good discussion topic.

While we have this great big "DANE brain trust" all in one l= ocation (and also coming in remotely), I would be interested in having (and= would be willing to lead, if necessary) a discussion around "What Els= e Do We Need To Do To Get DANE More Widely Deployed".  Now that we are seeing actual deployment and usage, are there things= we have learned that can guide us in accelerating the deployment of DANE?<= /div>

We've captured a good bit of implementation guidance in Viktor and Wes= ' https= ://tools.ietf.org/html/draft-ietf-dane-ops-06 and so perhaps a rev= iew of that document would help, but I'm also interested in questions like:

- what roadblocks are people running into with implementing DANE? &nbs= p;(outside of the broader issue of getting DNSSEC validation and signing mo= re widely available)

- are there more "Using DANE with <foo>" types of docu= ments that we can or should create? (and who is willing to do so)

- have we seen areas where more standardization would help?

- are there some good examples/case studies of DANE implementations th= at we could perhaps capture as informational RFCs?  (the Jabber commun= ity's implementation comes to mind)

- are there places where it would be helpful if there were reference i= mplementations of DANE support?  For example, DANE for email got a boo= st when Viktor added it to postfix.  Are there other commonly-used ope= n source projects where the addition of DANE support would help move deployment along?   (I'm NOT saying that the = DANE WG would be involved with these implementations... but brainstorming t= ogether and identifying a list could help other people and groups (ex. Inte= rnet Society, Verisign Labs, NLNet Labs) advocate and perhaps fund efforts to get that DANE support added.)

- are there test tools that need to be developed? or existing ones tha= t need to be better promoted?  are there interop tests we can arrange?=

I realize some of this may seem outside our charter, but if I look at = the charter, it includes these phrases:
-----
The
DANE WG shall also produce a set = of implementation guidance 
for operators and tool developers= .

<big snip>

The group may also create documents that describe how protocol
entities can discover and validate these bindings in the execution
of specific applications. This work would be done in coordination
with the IETF Working Groups responsible for the protocols.

The group may in addition encourage interoperability testing and 
document the results of such testing.
-----

So I do see a good bit of this covered under that.

The end result I'd like to see out of this discussion would be:

- guidance for the WG on what, if any, additional documents we need to= create (and identification of who might write them)
- potential interoperability testing
- guidance to WG members and other organizations on how we can get DAN= E more widely deployed

Obviously I have an interest in this because I'm employed by the Inter= net Society in large part to do whatever possible to accelerate the deploym= ent of DNSSEC (and IPv6 and... ), but this really means that I'm here for *= you* all to help do what needs to be done.  I'd definitely appreciate a sense of the group about what w= e can all collectively do to make DANE more widely used.  Certainly we= can have some of this discussion on the list... but in a f2f meeting we ca= n have a much more engaged discussion.

So if we have time on the agenda and you all feel it would be appropri= ate, I'd like to have a discussion along these lines.

I'm not sure we need 2 hours though - 1,5 hours s= hould be enough.

I'm also not sure we need 2 hours... although this discussion I outlin= ed above could wind up occupying some time.

Dan
--_000_4C36FDC512D248C1A3D57AA4090E98C8isocorg_-- From nobody Wed Oct 1 09:37:29 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 911CC1A1ACC for ; Wed, 1 Oct 2014 09:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.987 X-Spam-Level: X-Spam-Status: No, score=0.987 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FREEMAIL_FROM=0.001, MALFORMED_FREEMAIL=1.487, 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 385tcniSvxcF for ; Wed, 1 Oct 2014 09:37:27 -0700 (PDT) Received: from mr11p24im-asmtp002.me.com (mr11p24im-asmtp002.me.com [17.110.78.42]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06AA21ACE88 for ; Wed, 1 Oct 2014 09:37:27 -0700 (PDT) Received: from [17.114.110.91] (unknown [17.114.110.91]) by mr11p24im-asmtp002.me.com (Oracle Communications Messaging Server 7u4-27.10(7.0.4.27.9) 64bit (built Jun 6 2014)) with ESMTPSA id <0NCR00G7VY5XLK00@mr11p24im-asmtp002.me.com> for dane@ietf.org; Wed, 01 Oct 2014 16:37:10 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52,1.0.28,0.0.0000 definitions=2014-10-01_06:2014-10-01,2014-10-01,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1410010161 From: William Stouder-Studenmund Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Date: Wed, 01 Oct 2014 09:37:08 -0700 Message-id: To: dane@ietf.org MIME-version: 1.0 (Mac OS X Mail 8.0 \(1985.3\)) X-Mailer: Apple Mail (2.1985.3) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/ylTpPIy6rJ1O-U970U0HwfRgA14 Subject: [dane] List of incidents that DANE would have blocked? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 16:37:27 -0000 I learned about DANE recently and was excitedly talking to some = operations friends of mine about it. Some of them work in shops that = aren=E2=80=99t using DNSSEC yet, and DANE=E2=80=99s requirement of it = would trigger push-back from management. *I* think they should be doing = DNSSEC, but I=E2=80=99m not management. Making a case for DANE means = making a case for DNSSEC. I get that DANE can detect a large class of MITM attacks. Saying that = isn=E2=80=99t as convincing as handing over a list of, =E2=80=9CDANE is = designed to stop this, DANE would have stopped that one,=E2=80=9D and so = on. If the answer is lurking in the list archives, feel free to just point = me at a date and I=E2=80=99ll look at that too. Take care, Bill= From nobody Wed Oct 1 19:01:53 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC8301A8875 for ; Wed, 1 Oct 2014 19:01:50 -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 cQNfuSEOHrZh for ; Wed, 1 Oct 2014 19:01:49 -0700 (PDT) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CF141A0007 for ; Wed, 1 Oct 2014 19:01:49 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id rp18so1619198iec.41 for ; Wed, 01 Oct 2014 19:01:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=/LSCp4wOQIqxaU5KdGeKl5HtvpzkJsDHugu28oRLbik=; b=gvpjOQe0VD6YwsT+JBYJDc2VM6yerD/dRJ9Osc6ZLYPX3gk0fUe7Q5Q04gE+aPzg5w m6Q9Qwx8EjW5pqYfbftWun16SioxaPldVN8ulY1a4NDHA+8yqElcG8c25iqb2VXAVijM c61GbSB2E2tEC/7+jnHQ+pyOxHJ13rRWuo1hrk+vV3nQGk3sAnBggwf238b6YU8cGVGp Lkq5MN0jzH6KRvQZvv7SalyshIFXxKBMkEYX8F6lAOZB2JHCP7TytEzJdow7WfxdfGpL IRKHTR8NmHUxc/H7rHyI5zX/oiE5SA3QqGum0s9Ut/0Ef3/B1I+1gF7EatfDiKJqOxHH 51LA== X-Gm-Message-State: ALoCoQmABImU+bPQpU5a12pDyyz8JN5Q+fOafcxsmYW4uHxz80IjQbGs75Umm1CoRJ2dZ8sNyL1t X-Received: by 10.50.7.73 with SMTP id h9mr7095263iga.43.1412215308712; Wed, 01 Oct 2014 19:01:48 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id hg4sm26739igb.15.2014.10.01.19.01.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 01 Oct 2014 19:01:48 -0700 (PDT) Message-ID: <542CB20B.4020803@andyet.net> Date: Wed, 01 Oct 2014 20:01:47 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/9F2JWIavhMo3mN66XddhGirj9d8 Subject: [dane] DNS errors text X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 02:01:51 -0000 Section 2.1 of draft-ietf-dane-smtp-with-dane has some thorough text on DNS errors. Viktor suggested that draft-ietf-dane-srv needs the same text. I would strongly prefer NOT to have the same text in two documents for various reasons. When I mentioned this to the chairs, they suggested moving the text from the SMTP document to the SRV document since it is more generic. I don't really care where it lives, I just want it to be in one place. What do WG participants think? Peter -- Peter Saint-Andre https://andyet.com/ From nobody Wed Oct 1 19:13:28 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5321A8882 for ; Wed, 1 Oct 2014 19:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.647 X-Spam-Level: X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-2.3] 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 GrmPQjFAalhO for ; Wed, 1 Oct 2014 19:13:22 -0700 (PDT) Received: from proper.com (Hoffman.Proper.COM [207.182.41.81]) (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 D631F1A887A for ; Wed, 1 Oct 2014 19:13:22 -0700 (PDT) Received: from [10.20.30.90] (142-254-17-87.dsl.dynamic.fusionbroadband.com [142.254.17.87]) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id s922DIRg028223 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 1 Oct 2014 19:13:20 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 142-254-17-87.dsl.dynamic.fusionbroadband.com [142.254.17.87] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Paul Hoffman In-Reply-To: <542CB20B.4020803@andyet.net> Date: Wed, 1 Oct 2014 19:13:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7D2E911A-9D78-4242-A61D-7704DE4A60D4@vpnc.org> References: <542CB20B.4020803@andyet.net> To: Peter Saint-Andre - &yet X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/nLnf4FccWMGghhbxNCw6nUJcltE Cc: "" Subject: Re: [dane] DNS errors text X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 02:13:25 -0000 On Oct 1, 2014, at 7:01 PM, Peter Saint-Andre - &yet = wrote: > Section 2.1 of draft-ietf-dane-smtp-with-dane has some thorough text = on DNS errors. Viktor suggested that draft-ietf-dane-srv needs the same = text. I would strongly prefer NOT to have the same text in two documents = for various reasons. When I mentioned this to the chairs, they suggested = moving the text from the SMTP document to the SRV document since it is = more generic. I don't really care where it lives, I just want it to be = in one place. What do WG participants think? As long as the SMTP document points to the SRV document for the errors, = it's fine to have it live in the SRV document. --Paul Hoffman= From nobody Wed Oct 1 20:18:07 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8699A1A0034 for ; Wed, 1 Oct 2014 20:18:04 -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] 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 EPZydcTS6kq8 for ; Wed, 1 Oct 2014 20:18:02 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF08E1A000A for ; Wed, 1 Oct 2014 20:18:02 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 822C42AB2B5; Thu, 2 Oct 2014 03:18:00 +0000 (UTC) Date: Thu, 2 Oct 2014 03:18:00 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141002031800.GU13254@mournblade.imrryr.org> References: <542CB20B.4020803@andyet.net> <7D2E911A-9D78-4242-A61D-7704DE4A60D4@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7D2E911A-9D78-4242-A61D-7704DE4A60D4@vpnc.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/CdWzEAV77cIAq3y75G-arqK0A0M Subject: Re: [dane] DNS errors text X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 03:18:04 -0000 On Wed, Oct 01, 2014 at 07:13:17PM -0700, Paul Hoffman wrote: > On Oct 1, 2014, at 7:01 PM, Peter Saint-Andre - &yet wrote: > > > Section 2.1 of draft-ietf-dane-smtp-with-dane has some thorough text on DNS errors. Viktor suggested that draft-ietf-dane-srv needs the same text. I would strongly prefer NOT to have the same text in two documents for various reasons. When I mentioned this to the chairs, they suggested moving the text from the SMTP document to the SRV document since it is more generic. I don't really care where it lives, I just want it to be in one place. What do WG participants think? > > As long as the SMTP document points to the SRV document for the > errors, it's fine to have it live in the SRV document. The main issue that comes to mind is that the SRV draft is at present silent about whether DANE security is opportunistic or mandatory. Some of the error text is IIRC specific to the opportunistic mode of operation, because this comes more ways to attempt to mount downgrade attacks. I don't think the SRV draft should sit on the fence with respect to opportunistic use. It probably needs to describe both modes of operation explicitly. Otherwise, yes I have no problem importing the DNS error handling by referehce, but I also see little disadvantage to simply repeating the text, one stop shopping is easier on the reader. -- Viktor. From nobody Wed Oct 1 20:40:00 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E95CD1A0055 for ; Wed, 1 Oct 2014 20:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.758 X-Spam-Level: * X-Spam-Status: No, score=1.758 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 yuHGyNSprqIk for ; Wed, 1 Oct 2014 20:39:56 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 982811A004E for ; Wed, 1 Oct 2014 20:39:56 -0700 (PDT) Received: from mx1.yitter.info (unknown [50.189.173.0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 809378A035 for ; Thu, 2 Oct 2014 03:39:54 +0000 (UTC) Date: Wed, 1 Oct 2014 23:39:49 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20141002033948.GB14726@mx1.yitter.info> References: <542CB20B.4020803@andyet.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <542CB20B.4020803@andyet.net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/6v6x8zmSL7MK8HYsSQCiYd4CRr0 Subject: Re: [dane] DNS errors text X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 03:39:58 -0000 On Wed, Oct 01, 2014 at 08:01:47PM -0600, Peter Saint-Andre - &yet wrote: > Section 2.1 of draft-ietf-dane-smtp-with-dane has some thorough text on DNS > errors. Well, yes, but once again I've been caught asleep at the wheel. I know I participated in early work on some of the text below, but apparently threads got away from me that I should have attended to. I object pretty strongly to this: To avoid much repetition in the text below, we will pause to explain the handling of "bogus" or "indeterminate" DNSSEC query responses. These are not necessarily the result of a malicious actor; they can, for example, occur when network packets are corrupted or lost in transit. Therefore, "bogus" or "indeterminate" replies are equated in this memo with lookup failure. While I agree that neither bogus nor interdeterminate responses are necessarily the result of a malicious actor, I am not sure why this should be "equated with" lookup failure. (I'm even more dubious that they're the result of corrupted or lost network packets -- that sounds to me rather more like something that would be handled by the regular DNS mechanisms for this sort of thing, including DNS retries with a smaller EDNS buffer size or reversion to TCP. But never mind that). I'm ok if the idea is just to say this: For the purposes contemplated by this memo, neither bogus nor indeterminate answers are acceptable. Therefore, this memo uses ah analagous strategy to that used by DNSSEC when a validating iterative resolver responds to a stub: SERVFAIL when positive validation fails. The difference in the present case lies in treating bogus and indeterminate as the same thing -- what might be called a 'strongly valid' bias. This is required in order to derive further security properties from the answer received from DNS." There are some other DNS errors in the same section: When a DNSSEC response with a validation status that is either "secure" or "insecure" reports either no records of the requested type or non-existence of the query domain, the response is not a DNS error condition. This is strictly false. The "no records of the requested type" is what is called a NODATA response, and is defined in RFC 2308. It's not an RCODE. But a response of "non-exstence of the query domain" is, if I understand it, an RCODE==3 ("Name Error" or "NXDOMAIN") response, which is certainly an "error" condition in pure DNS terms. For practical purposes in an application, it is quite possibly true that "NODATA" and "NXDOMAIN" -- presuming that they're both provably secure responses, or that you've decided to accept an opt-out proof -- are the same thing. But we don't need to mischaracterise how DNSSEC works in this text (whatever draft it lands in). This isn't exactly true either: Security-aware stub resolvers will, of course, also signal DNS lookup errors in other cases, for example when processing a "ServFail" RCODE, which will not have an associated DNSSEC status. A stub that gets a SERVFAIL, but that is itself validating, is in a perfectly good position to retry with CD=1. If it gets an answer at that point, and yet cannot validate itself, then that is in fact a DNSSEC status: bogus. Otherwise, it's SERVFAIL, which could mean anything. This is underdetermined, but not completely indeterminate. I suggest reading RFC 6840, especially the bits in appendices B and C. Olafur and I both had several painful discussions (independently and together) about that document, and it'd be useful to understand how the interaction of stubs, CD, TA preferences, and failed upstream validation could be made clearer. Instead of A lookup error is thus a failure to obtain the relevant RRset if it exists, or to determine that no such RRset exists when it does not. I suggest For the purposes of this memo, a "lookup error" is either a failure to obtain securely the relevant RRset (if that RRset exists), or to determine securely that no such RRset exists (if it does not). This is a broader meaning than is sometimes used for "lookup error". If you wanted to make the definition cleaner, you could define "secure lookup error" instead. Or something like that. This might help, because sometimes "lookup failure" and "lookup error" seem to be treated the same, and sometimes we have "DNS lookup failure", which appears to be different but I bet actually isn't. I hope this helps rather than hinders. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed Oct 1 23:03:44 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E8291A00C9 for ; Wed, 1 Oct 2014 23:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 br1sdy9gfpP5 for ; Wed, 1 Oct 2014 23:03:41 -0700 (PDT) Received: from smtp100.ord1c.emailsrvr.com (smtp100.ord1c.emailsrvr.com [108.166.43.100]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A57B1A00C6 for ; Wed, 1 Oct 2014 23:03:41 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp5.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id D1AFD180260; Thu, 2 Oct 2014 02:03:40 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp5.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 7CFC21800E2; Thu, 2 Oct 2014 02:03:39 -0400 (EDT) X-Sender-Id: ogud@ogud.com Received: from [10.0.1.52] ([UNAVAILABLE]. [208.72.142.196]) (using TLSv1 with cipher AES128-SHA) by 0.0.0.0:465 (trex/5.2.13); Thu, 02 Oct 2014 06:03:40 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Olafur Gudmundsson In-Reply-To: Date: Thu, 2 Oct 2014 02:03:37 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <87DFEBA9-634D-4D91-BCD6-58F48BDC60B7@ogud.com> References: To: William Stouder-Studenmund X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/xPmVto-xkFWCZiqKbWnQ0EzvrSs Cc: dane@ietf.org Subject: Re: [dane] List of incidents that DANE would have blocked? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 06:03:43 -0000 Bill,=20 short answer.=20 Dane is about placing high value information in the DNS,=20 with out DNSSEC that is non-sensical.=20 Yes we had this discussion a long time ago (most of second half of = 2011), the deciding point was around November 2011.=20 starting with this message:=20 http://www.ietf.org/mail-archive/web/dane/current/msg03748.html and this one is a followup to gather consensus http://www.ietf.org/mail-archive/web/dane/current/msg03864.html Olafur On Oct 1, 2014, at 12:37 PM, William Stouder-Studenmund = wrote: > I learned about DANE recently and was excitedly talking to some = operations friends of mine about it. Some of them work in shops that = aren=92t using DNSSEC yet, and DANE=92s requirement of it would trigger = push-back from management. *I* think they should be doing DNSSEC, but = I=92m not management. Making a case for DANE means making a case for = DNSSEC. >=20 > I get that DANE can detect a large class of MITM attacks. Saying that = isn=92t as convincing as handing over a list of, =93DANE is designed to = stop this, DANE would have stopped that one,=94 and so on. >=20 > If the answer is lurking in the list archives, feel free to just point = me at a date and I=92ll look at that too. >=20 > Take care, >=20 > Bill > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From nobody Thu Oct 2 05:09:27 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03E671A1B92 for ; Thu, 2 Oct 2014 05:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_NONE=-0.0001, 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 ot3ajnHGBBSO for ; Thu, 2 Oct 2014 05:09:17 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0078.outbound.protection.outlook.com [207.46.100.78]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B44DE1A1ADC for ; Thu, 2 Oct 2014 05:09:06 -0700 (PDT) Received: from BLUPR06MB243.namprd06.prod.outlook.com (10.242.191.154) by BLUPR06MB243.namprd06.prod.outlook.com (10.242.191.154) with Microsoft SMTP Server (TLS) id 15.0.1044.10; Thu, 2 Oct 2014 12:09:05 +0000 Received: from BLUPR06MB243.namprd06.prod.outlook.com ([169.254.7.32]) by BLUPR06MB243.namprd06.prod.outlook.com ([169.254.7.230]) with mapi id 15.00.1044.008; Thu, 2 Oct 2014 12:09:05 +0000 From: Dan York To: IETF DANE Mailinglist Thread-Topic: Google Chromium team closes DNSSEC/DANE as a WontFix Thread-Index: AQHP3jmpJRdChrQOoUuKuR51p2lBzA== Date: Thu, 2 Oct 2014 12:09:05 +0000 Message-ID: <65B99B57-FDCB-4E0A-A65A-21F80B67C205@isoc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [74.75.92.114] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB243; x-forefront-prvs: 03524FBD26 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(189002)(199003)(10300001)(85306004)(76482002)(107046002)(19617315012)(20776003)(21056001)(82746002)(92566001)(16236675004)(15975445006)(110136001)(31966008)(107886001)(99396003)(101416001)(66066001)(97736003)(229853001)(85852003)(64706001)(19580395003)(120916001)(54356999)(77096002)(33656002)(4396001)(86362001)(106356001)(50986999)(2656002)(83716003)(106116001)(99286002)(87936001)(95666004)(80022003)(46102003)(92726001)(105586002)(36756003)(104396001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB243; H:BLUPR06MB243.namprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_65B99B57FDCB4E0AA65A21F80B67C205isocorg_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org Archived-At: http://mailarchive.ietf.org/arch/msg/dane/-VCKkEVI4wHrpWEzZKNobfSPNfQ Subject: [dane] Google Chromium team closes DNSSEC/DANE as a WontFix X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 12:09:19 -0000 --_000_65B99B57FDCB4E0AA65A21F80B67C205isocorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It seems we may not be seeing DANE / DNSSEC support in Google Chrome anytim= e soon. This ticket was just closed as a WontFix: https://code.google.com/p/chromium/issues/detail?id=3D50874#c22 As the ticket says (in part): ----- Closing this out as WontFix, as there are no plans. DNSSEC and DANE (types 2/3) do not measurably raise the bar for security co= mpared to alternatives, and can be negative for security. DNSSEC+DANE (types 0/1) can be accomplished via HTTP Public Key Pinning to = the same effect, and with a much more reliable and consistent delivery mech= anism. While not desiring to stifle discussion, we've continued to evaluate the se= curity and usability benefits and costs of DNSSEC and DANE, and will contin= ue to do so, but for now, this is neither something we plan to implement no= r would support landing. ----- Any thoughts? Dan --_000_65B99B57FDCB4E0AA65A21F80B67C205isocorg_ Content-Type: text/html; charset="us-ascii" Content-ID: <65C618785F4CF343981FEC05C1204C6E@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
It seems we may not be seeing DANE / DNSSEC support in Google Chrome a= nytime soon. This ticket was just closed as a WontFix:

https://code.google.com/p/chromium/issues/detail?id=3D50874#c22

As the ticket says (in part):
-----
Closing this out as WontFix, as there are no plans.
<snip>
DNSSEC and DANE (types 2/3) do not measurably raise the bar for securi= ty compared to alternatives, and can be negative for security.
DNSSEC+DANE (types 0/1) can be accomplished via HTTP Public Key Pi= nning to the same effect, and with a much more reliable and consistent deli= very mechanism.

While not desiring to stifle discussion, we've continued to evaluate t= he security and usability benefits and costs of DNSSEC and DANE, and will c= ontinue to do so, but for now, this is neither something we plan to impleme= nt nor would support landing.
-----

Any thoughts?

Dan

--_000_65B99B57FDCB4E0AA65A21F80B67C205isocorg_-- From nobody Thu Oct 2 07:41:41 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61C751A039A for ; Thu, 2 Oct 2014 07:41:38 -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] 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 SwukARM8rMFM for ; Thu, 2 Oct 2014 07:41:35 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 228CE1A0377 for ; Thu, 2 Oct 2014 07:41:35 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id EED882AB2A7; Thu, 2 Oct 2014 14:41:32 +0000 (UTC) Date: Thu, 2 Oct 2014 14:41:32 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141002144132.GW13254@mournblade.imrryr.org> References: <542CB20B.4020803@andyet.net> <20141002033948.GB14726@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141002033948.GB14726@mx1.yitter.info> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/j2m7rot-M1rZrhQXXeiUsnonmhg Subject: Re: [dane] DNS errors text X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 14:41:38 -0000 On Wed, Oct 01, 2014 at 11:39:49PM -0400, Andrew Sullivan wrote: > I object pretty strongly to this: > > To avoid much repetition in the text below, we will pause to explain > the handling of "bogus" or "indeterminate" DNSSEC query responses. > These are not necessarily the result of a malicious actor; they can, > for example, occur when network packets are corrupted or lost in > transit. Therefore, "bogus" or "indeterminate" replies are equated > in this memo with lookup failure. > > While I agree that neither bogus nor interdeterminate responses are > necessarily the result of a malicious actor, I am not sure why this > should be "equated with" lookup failure. Data integrity errors are errors. DNSSEC detects more data integrity failures than legacy DNS. It is important to tell application developers that e.g. "bogus", "srvfail" and lookup timeouts can and should be treated identically. > (I'm even more dubious that they're the result of corrupted or lost network > packets The quoted claim is that they "can be", not that they are. Note, that 4035 "indeterminate" can happen due to lost packets, while "bogus" likely cannot. > I'm ok if the idea is just to say this: > > For the purposes contemplated by this memo, neither bogus nor > indeterminate answers are acceptable. Therefore, this memo uses > an analagous strategy to that used by DNSSEC when a validating > iterative resolver responds to a stub: SERVFAIL when positive > validation fails. The difference in the present case lies in > treating bogus and indeterminate as the same thing -- what might > be called a 'strongly valid' bias. This is required in order to > derive further security properties from the answer received from > DNS." The draft is not for nameserver developers, it is for SMTP server developers. The above is far less clear than the original. For the purpose of an SMTP with DANE implementation ordinary DNS lookup errors and validation errors are indistinguishable, provided NXDOMAIN is not treated as an error (DNSSEC secures denial of existence). > There are some other DNS errors in the same section: > > When a DNSSEC response with a > validation status that is either "secure" or "insecure" reports > either no records of the requested type or non-existence of the query > domain, the response is not a DNS error condition. For the purposes of SMTP with DANE (or other DANE applications), the text applies as written. This draft is not a DNSSEC draft. > This is strictly false. The "no records of the requested type" is > what is called a NODATA response, and is defined in RFC 2308. It's > not an RCODE. But a response of "non-exstence of the query domain" > is, if I understand it, an RCODE==3 ("Name Error" or "NXDOMAIN") > response, which is certainly an "error" condition in pure DNS terms. It is not an error condition for DANE with SMTP. Authenticated denial of existence is a valid outcome. > For practical purposes in an application, it is quite possibly true > that "NODATA" and "NXDOMAIN" -- presuming that they're both provably > secure responses, or that you've decided to accept an opt-out proof -- > are the same thing. Exactly! This draft is focused on telling application developers how handle DNSSEC queries in a way that avoids downgrade attacks. The text is correct as written. > But we don't need to mischaracterise how DNSSEC > works in this text (whatever draft it lands in). We're not explaining how DNSSEC works, we're explaining how to use it. Deliberately simplifying away inessential differences that can easily confuse application developers, and simplifying later exposion, by defining "lookup error" comprehensively. > This isn't exactly true either: > > Security-aware stub resolvers will, of course, also signal DNS lookup > errors in other cases, for example when processing a "ServFail" > RCODE, which will not have an associated DNSSEC status. > > A stub that gets a SERVFAIL, but that is itself validating, is in a > perfectly good position to retry with CD=1. If it gets an answer at > that point, and yet cannot validate itself, then that is in fact a > DNSSEC status: bogus. Otherwise, it's SERVFAIL, which could mean > anything. This is underdetermined, but not completely indeterminate. These nuances are out of scope. At the end of the day, the text explains to DANE implementors who are not DNSSEC experts how to interact with DNS in a downgrade resistant manner. > Instead of > > A lookup error is thus a failure to obtain the relevant RRset if it > exists, or to determine that no such RRset exists when it does not. > > I suggest > > For the purposes of this memo, a "lookup error" is either a > failure to obtain securely the relevant RRset (if that RRset > exists), or to determine securely that no such RRset exists (if it > does not). This is a broader meaning than is sometimes used for > "lookup error". This is wrong, because "insecure" responses are also acceptable from "opted out" zones. > I hope this helps rather than hinders. Mostly the latter I think. Our audience is not DNSSEC implementors, it is DANE (SMTP or broader) application developers, and the less said about DNSSEC internals the better. The goal is for developers to understand that DNSSEC-related errors and just like other errors, with exactly one exception, NXDOMAIN is not a lookup error. It signals the non-existence of the query domain, which from an application perspective is a perfectly normal condition. Yeah, sure, DNS nameserver developers may prefer a different mindset, but that would needlessly complicate the exposition to application developers. -- Viktor. From nobody Thu Oct 2 09:15:58 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F9551A877D for ; Thu, 2 Oct 2014 09:15:55 -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] 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 0ZjHOTtr4_yG for ; Thu, 2 Oct 2014 09:15:50 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63BA31A1A92 for ; Thu, 2 Oct 2014 09:15:48 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 717972AB2A7; Thu, 2 Oct 2014 16:15:41 +0000 (UTC) Date: Thu, 2 Oct 2014 16:15:41 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141002161541.GE13254@mournblade.imrryr.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/hs0o8lhxbXP8s67MtzzUnLvGel0 Subject: Re: [dane] List of incidents that DANE would have blocked? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 16:15:55 -0000 On Wed, Oct 01, 2014 at 09:37:08AM -0700, William Stouder-Studenmund wrote: > Making a case for DANE means making a case for DNSSEC. Yes. > I get that DANE can detect a large class of MITM attacks. No, DANE can public associations between service end-points and public key material. Protecting against MITM attacks is a matter for the protocols that use that key material. DNSSEC hardens the lookups of that key material against MITM attacks. > Saying that > isn't as convincing as handing over a list of, "DANE is designed to stop > this, DANE would have stopped that one," and so on. DANE can enable opportunistic security protocol designs that are capable of resisting MITM attacks. This is in use with SMTP and XMPP. DANE for the web is some time away. None of the browsers are planning DANE support at this time. My hope is that at some point in the future the new "h2" URI scheme will support opportunistic DANE TLS, rather than just opportunistic unauthenticated encryption. DANE replacing public CAs with "https" seems unlikely so long as there is perceived value in "EV" certificates. -- Viktor. From nobody Thu Oct 2 10:21:25 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA3D1A8A04 for ; Thu, 2 Oct 2014 10:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.413 X-Spam-Level: X-Spam-Status: No, score=-0.413 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, MALFORMED_FREEMAIL=1.487, 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 gEdqxOJlhXpf for ; Thu, 2 Oct 2014 10:21:23 -0700 (PDT) Received: from mr11p24im-asmtp002.me.com (mr11p24im-asmtp002.me.com [17.110.78.42]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FC651A89EF for ; Thu, 2 Oct 2014 10:21:23 -0700 (PDT) Received: from [17.114.110.91] (unknown [17.114.110.91]) by mr11p24im-asmtp002.me.com (Oracle Communications Messaging Server 7u4-27.10(7.0.4.27.9) 64bit (built Jun 6 2014)) with ESMTPSA id <0NCT00L6MUVE1670@mr11p24im-asmtp002.me.com> for dane@ietf.org; Thu, 02 Oct 2014 17:21:22 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52,1.0.28,0.0.0000 definitions=2014-10-02_05:2014-10-02,2014-10-02,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1410020170 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 8.0 \(1985.3\)) From: William Stouder-Studenmund In-reply-to: <20141002161541.GE13254@mournblade.imrryr.org> Date: Thu, 02 Oct 2014 10:21:13 -0700 Content-transfer-encoding: 7bit Message-id: References: <20141002161541.GE13254@mournblade.imrryr.org> To: dane@ietf.org X-Mailer: Apple Mail (2.1985.3) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/0bxyIfZYtYnb9vaxAid5thpxGD4 Subject: Re: [dane] List of incidents that DANE would have blocked? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 17:21:24 -0000 > On Oct 2, 2014, at 9:15 AM, Viktor Dukhovni wrote: > > On Wed, Oct 01, 2014 at 09:37:08AM -0700, William Stouder-Studenmund wrote: > >> Making a case for DANE means making a case for DNSSEC. > > Yes. > >> I get that DANE can detect a large class of MITM attacks. > > No, DANE can public associations between service end-points and > public key material. Protecting against MITM attacks is a matter > for the protocols that use that key material. DNSSEC hardens the > lookups of that key material against MITM attacks. > >> Saying that >> isn't as convincing as handing over a list of, "DANE is designed to stop >> this, DANE would have stopped that one," and so on. > > DANE can enable opportunistic security protocol designs that are > capable of resisting MITM attacks. This is in use with SMTP and > XMPP. Thank you! These are the things I was hoping to hear. > DANE for the web is some time away. None of the browsers are > planning DANE support at this time. My hope is that at some point > in the future the new "h2" URI scheme will support opportunistic > DANE TLS, rather than just opportunistic unauthenticated encryption. > > DANE replacing public CAs with "https" seems unlikely so long as > there is perceived value in "EV" certificates. Take care, Bill From nobody Thu Oct 2 10:21:39 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FED01A8A23 for ; Thu, 2 Oct 2014 10:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.412 X-Spam-Level: X-Spam-Status: No, score=-0.412 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MALFORMED_FREEMAIL=1.487, 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 zMcIW-s3XJ1D for ; Thu, 2 Oct 2014 10:21:30 -0700 (PDT) Received: from mr11p24im-asmtp002.me.com (mr11p24im-asmtp002.me.com [17.110.78.42]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 240011A8A1F for ; Thu, 2 Oct 2014 10:21:30 -0700 (PDT) Received: from [17.114.110.91] (unknown [17.114.110.91]) by mr11p24im-asmtp002.me.com (Oracle Communications Messaging Server 7u4-27.10(7.0.4.27.9) 64bit (built Jun 6 2014)) with ESMTPSA id <0NCT00L6MUVE1670@mr11p24im-asmtp002.me.com> for dane@ietf.org; Thu, 02 Oct 2014 17:21:29 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52,1.0.28,0.0.0000 definitions=2014-10-02_05:2014-10-02,2014-10-02,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1410020170 Content-type: multipart/alternative; boundary="Apple-Mail=_41F9EE18-04A2-4CB8-9609-3390DC27B299" MIME-version: 1.0 (Mac OS X Mail 8.0 \(1985.3\)) From: William Stouder-Studenmund In-reply-to: <87DFEBA9-634D-4D91-BCD6-58F48BDC60B7@ogud.com> Date: Thu, 02 Oct 2014 10:21:28 -0700 Message-id: References: <87DFEBA9-634D-4D91-BCD6-58F48BDC60B7@ogud.com> To: Olafur Gudmundsson X-Mailer: Apple Mail (2.1985.3) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/dzagnD2V6SEp0QGver8gviyZ4W8 Cc: dane@ietf.org Subject: Re: [dane] List of incidents that DANE would have blocked? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 17:21:31 -0000 --Apple-Mail=_41F9EE18-04A2-4CB8-9609-3390DC27B299 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On Oct 1, 2014, at 11:03 PM, Olafur Gudmundsson wrote: >=20 > Bill,=20 > short answer.=20 >=20 > Dane is about placing high value information in the DNS,=20 > with out DNSSEC that is non-sensical.=20 >=20 > Yes we had this discussion a long time ago (most of second half of = 2011), the deciding point was around November 2011.=20 > starting with this message:=20 > http://www.ietf.org/mail-archive/web/dane/current/msg03748.html >=20 > and this one is a followup to gather consensus > http://www.ietf.org/mail-archive/web/dane/current/msg03864.html = Thank you! Take care, Bill --Apple-Mail=_41F9EE18-04A2-4CB8-9609-3390DC27B299 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Oct 1, 2014, at 11:03 PM, Olafur Gudmundsson <ogud@ogud.com> = wrote:

Bill, =
short answer.

Dane is about = placing high value information in the DNS,
with out = DNSSEC that is non-sensical.

Yes we had = this discussion a long time ago (most of second half of  2011), the = deciding point was around November 2011.
starting with = this message:
http://www.ietf.org/mail-archive/web/dane/current/msg03748.html=

and this one is a followup to gather = consensus
http://www.ietf.org/mail-archive/web/dane/current/msg03864.html=

Thank = you!

Take care,

Bill

= --Apple-Mail=_41F9EE18-04A2-4CB8-9609-3390DC27B299-- From nobody Thu Oct 2 13:56:35 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ADBF1A87C5 for ; Thu, 2 Oct 2014 13:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 BOATyM7H2C0i for ; Thu, 2 Oct 2014 13:56:32 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 711E91A879F for ; Thu, 2 Oct 2014 13:56:31 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id gi9so3189558lab.5 for ; Thu, 02 Oct 2014 13:56:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=qWO0qJpu8OQuWDXqcuqRrBzZ90JQjzb4lnMDi/8Or8g=; b=to18QRaarTsl8RSI7MfhXV1lMrxxL2M/d98fbcjB/Ei7DJIo4C0LAqpcUcUfP4Atqd 6XrSjocluGkkPpFZsi4lOgFfa6e70c1lWNHSC21H9U/VecAvQQuK3Xq1sZ8sYxhRiMgZ FoVZnGOU5jEiyus3fjoDpKFTJ+PSKxDB0wvzMwTBKuC3OaaPV0ucCYsY8aIoY1veTC6q NNKRKWFjbq8Ojp4kmRwOJcx4TuXjvHyycmNlioGok1xbhsetvLEUhOOxP4ZP2QJconlL IgMPytMrjdtmJvdlMpWUC3oMRs79E74+dY8QSGtZ2MAZ/CiwxR+jRKVFJuQL2Qg7Zfm7 JhVQ== X-Received: by 10.152.42.173 with SMTP id p13mr1228469lal.23.1412283389745; Thu, 02 Oct 2014 13:56:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.88.134 with HTTP; Thu, 2 Oct 2014 13:56:09 -0700 (PDT) In-Reply-To: References: <273F9612-13AF-4CB8-B15C-912AAD04C738@verisign.com> From: Doug Montgomery Date: Thu, 2 Oct 2014 16:56:09 -0400 Message-ID: To: Paul Hoffman Content-Type: multipart/alternative; boundary=001a11c34e48c4a019050476d9bd Archived-At: http://mailarchive.ietf.org/arch/msg/dane/V2Dtgp_uc6GscyAtpBVFegKCuXk Cc: dane WG list Subject: Re: [dane] draft-ietf-dane-smime X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 20:56:34 -0000 --001a11c34e48c4a019050476d9bd Content-Type: text/plain; charset=UTF-8 I am a little confused as to why we seem to couple the use case of key discovery and distribution in TLS to the use case for email/network-identity. These seem to be very different use cases to me. I looked back at two years of data. My own, mid-size (3K staff) organization revokes on average 165 net-identities a month. We also create about that number, less you think we are withering away. Having a scalable, simple, but definitive way to indicate that a previously valid email-identity/certificate is no longer valid within a given domain is a useful feature that doesn't seem to have an analog use case in TLS. As far as I know we have never revoked our TLS cert ... I know of other industry sectors attempting to develop rather complex pub/sub architectures to signal changes in status of email identities from large mailbox providers to other users/uses of the ID. Overly coupling the use cases and requirements between these uses seems to be a red herring to me. Maybe we should turn the question around and ask for an explanation why the use cases for TLS should impact the requirements for SMIMEA? dougm On Tue, Sep 30, 2014 at 4:53 PM, Paul Hoffman wrote: > On Sep 29, 2014, at 5:26 AM, Osterweil, Eric > wrote: > > > Based on our implementation experience we would like to suggest that the > following text (taken from Scott Rose's email: > http://www.ietf.org/mail-archive/web/dane/current/msg06180.html ) be > incorporated into the current version of the draft-ietf-dane-smime > document. We are sending text (below), but at a high-level, the text > outlines a few useful additions: > > > > 1 - Usage #4 (reject) is likely to be very important. This could either > emphasize the difference between saying, ``don't use this cert for this > operation,'' and ``this cert is universally revoked'' or be used to > selectively override an organization-wide TA for certain employees that > have left the organization. > > > > 2 - The certificate access field (Section 2.1.4) would enable alternate > discovery mechanisms that could help aid incremental deployment and > transition schemes. For example, while cutting over to a DANE solution, > some enterprises may want to transition users from (say) AD to DANE, and > this field would enable that. > > > > 3 - The ``_encr'' and ``_sign'' labels are excellent additions to the > management of zone sizes and lookup sizes. Rather than querying for all > keys and then locally selecting from them, I (as an RP) likely already know > which of these I want, and I should be able to look them up separately in > DANE (and owners should be able to manage them separately in DANE). > > > > If anyone objects, please let us know. > > Jakob and I think that the three additions are unneeded here, and make the > draft diverge quite far from the TLSA format without significant value. In > specific: > > 1) This usage type is at least as applicable to TLS as it is to S/MIME. We > haven't seen anything indicating much use of certificate revocation > anywhere and, where we have seen it, it is much more common in TLS. If the > authors really want this feature, it should be an update to TLSA, which > SMIMEA could then adopt. > > 2) Making the record format for SMIMEA different than that of TLSA for > this feature seems like a bad idea. Alternate discovery mechanisms might be > important, but they will be just as important for TLS as they are for > S/MIME. The functionality that the authors want could be added to TLSA by > adding new Matching Type fields such as "Hash and NAPTR", "Hash and URI", > and so on. The latter is part of IKEv2 (although the feature is generally > considered not useful). If the authors really want this feature, it should > be an update to TLSA, which SMIMEA could then adopt. > > 3) There is absolutely no indication that zone size or response size is > important to SMIMEA, certainly not relative to the added complexity for > clients, servers, and operators. Currently, the RSA certs for SMIME from > common CAs are for both signing and encrypting, so this added complexity > won't buy current users anything. In the future when we are all (hopefully) > using elliptic curve keys, the zone size and response size will be so much > smaller than they are now that this change will appear as an > over-optimization that adds complexity. > > When these ideas were brought to the WG earlier this year, we didn't hear > any significant support. Given that both of us feel that the proposed > changes make the document harder to implement, we would want to see much > wider support before we adopt them. > > --Paul Hoffman and Jakob Schlyter > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > > -- DougM at Work --001a11c34e48c4a019050476d9bd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am a little confused as to why we seem to couple the use= case of key discovery and distribution in TLS to the use case for email/ne= twork-identity. =C2=A0 These seem to be very different use cases to me.
I looked back at two years of data. =C2=A0 My own, mid-size= (3K staff) organization revokes on average 165 net-identities a month.=C2= =A0 We also create about that number, less you think we are withering away.= =C2=A0 =C2=A0

Having a scalable, simple, but defi= nitive way to indicate that a previously valid email-identity/certificate i= s no longer valid within a given domain is a useful feature that doesn'= t seem to have an analog use case in TLS. =C2=A0 =C2=A0 As far as I know we= have never revoked our TLS cert ...=C2=A0

I know = of other industry sectors attempting to develop rather complex pub/sub arch= itectures to signal changes in status of email identities from large mailbo= x providers to other users/uses of the ID. =C2=A0=C2=A0

Overly coupling the use cases and requirements between these uses see= ms to be a red herring to me. =C2=A0 =C2=A0Maybe we should turn the questio= n around and ask for an explanation why the use cases for TLS should impact= the requirements for SMIMEA?

dougm

=

On Tu= e, Sep 30, 2014 at 4:53 PM, Paul Hoffman <paul.hoffman@vpnc.org>= ; wrote:
On Sep 2= 9, 2014, at 5:26 AM, Osterweil, Eric <eosterweil@verisign.com> wrote:

> Based on our implementation experience we would like to suggest that t= he following text (taken from Scott Rose's email: ht= tp://www.ietf.org/mail-archive/web/dane/current/msg06180.html ) be inco= rporated into the current version of the draft-ietf-dane-smime document.=C2= =A0 We are sending text (below), but at a high-level, the text outlines a f= ew useful additions:
>
> 1 - Usage #4 (reject) is likely to be very important.=C2=A0 This could= either emphasize the difference between saying, ``don't use this cert = for this operation,'' and ``this cert is universally revoked'&#= 39; or be used to selectively override an organization-wide TA for certain = employees that have left the organization.
>
> 2 - The certificate access field (Section 2.1.4) would enable alternat= e discovery mechanisms that could help aid incremental deployment and trans= ition schemes.=C2=A0 For example, while cutting over to a DANE solution, so= me enterprises may want to transition users from (say) AD to DANE, and this= field would enable that.
>
> 3 - The ``_encr'' and ``_sign'' labels are excellent a= dditions to the management of zone sizes and lookup sizes.=C2=A0 Rather tha= n querying for all keys and then locally selecting from them, I (as an RP) = likely already know which of these I want, and I should be able to look the= m up separately in DANE (and owners should be able to manage them separatel= y in DANE).
>
> If anyone objects, please let us know.

Jakob and I think that the three additions are unneeded here, and ma= ke the draft diverge quite far from the TLSA format without significant val= ue. In specific:

1) This usage type is at least as applicable to TLS as it is to S/MIME. We = haven't seen anything indicating much use of certificate revocation any= where and, where we have seen it, it is much more common in TLS. If the aut= hors really want this feature, it should be an update to TLSA, which SMIMEA= could then adopt.

2) Making the record format for SMIMEA different than that of TLSA for this= feature seems like a bad idea. Alternate discovery mechanisms might be imp= ortant, but they will be just as important for TLS as they are for S/MIME. = The functionality that the authors want could be added to TLSA by adding ne= w Matching Type fields such as "Hash and NAPTR", "Hash and U= RI", and so on. The latter is part of IKEv2 (although the feature is g= enerally considered not useful). If the authors really want this feature, i= t should be an update to TLSA, which SMIMEA could then adopt.

3) There is absolutely no indication that zone size or response size is imp= ortant to SMIMEA, certainly not relative to the added complexity for client= s, servers, and operators. Currently, the RSA certs for SMIME from common C= As are for both signing and encrypting, so this added complexity won't = buy current users anything. In the future when we are all (hopefully) using= elliptic curve keys, the zone size and response size will be so much small= er than they are now that this change will appear as an over-optimization t= hat adds complexity.

When these ideas were brought to the WG earlier this year, we didn't he= ar any significant support. Given that both of us feel that the proposed ch= anges make the document harder to implement, we would want to see much wide= r support before we adopt them.

--Paul Hoffman and Jakob Schlyter

_______________________________________________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane




--
DougM at= Work
--001a11c34e48c4a019050476d9bd-- From nobody Thu Oct 2 14:00:55 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEE991ACD78 for ; Thu, 2 Oct 2014 14:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.786, 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 KOXf1p5AleuF for ; Thu, 2 Oct 2014 14:00:50 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) (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 065961ACD6A for ; Thu, 2 Oct 2014 14:00:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:content-type:mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=6Ds+GQUL2EYbVJypKBqEeh42Jq9dzo6KVxz4/HusOBQ=; b=DXgZLvcv7nlz0zs0k8ZLbDAiVZJntFLQrN1ZsBOwqsfJvpkBLrl3DhBNFD1ORytlU7W2LsxLn3wjN SjtV8+PkN9cmGX3/aL8oJOX7l2MmPTnrMVFYLGHXIndySLcHBreoWzIFm28rklFBT4ljPwDYmYbyqV vDiPwSxnJa7qu7sY= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Thu, 2 Oct 2014 23:00:34 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Jakob Schlyter In-Reply-To: Date: Thu, 2 Oct 2014 23:00:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <273F9612-13AF-4CB8-B15C-912AAD04C738@verisign.com> To: Doug Montgomery X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/B-qFEvloMfD8cqhKlThiK1aOuy4 Cc: Paul Hoffman , dane WG list Subject: Re: [dane] draft-ietf-dane-smime X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 21:00:54 -0000 On 2 okt 2014, at 22:56, Doug Montgomery wrote: > Having a scalable, simple, but definitive way to indicate that a = previously valid email-identity/certificate is no longer valid within a = given domain is a useful feature that doesn't seem to have an analog use = case in TLS. If you trust in DANE, and the certificate is no longer published in DNS, = it is not valid - no revocation is needed. If you do not trust in DANE, normal/legacy revocation procedures = (OCSP/CRL) applies. my 0.01=80, jakob From nobody Thu Oct 2 14:05:44 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0875B1ACD67 for ; Thu, 2 Oct 2014 14:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 wJeK_TQqvir9 for ; Thu, 2 Oct 2014 14:05:37 -0700 (PDT) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 419491ACD61 for ; Thu, 2 Oct 2014 14:05:37 -0700 (PDT) Received: by mail-lb0-f181.google.com with SMTP id l4so2966438lbv.26 for ; Thu, 02 Oct 2014 14:05:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=JipHSkcxxypcEQ7VWkE/9NDVabPz/ViykDpWW999lIA=; b=ff43l93wdHfo8txO9G3irmajjCqCTfg5V0lA1pE2vGovqhiJegSi6KRuMeF4S7AqNm LtHYt/xL2uMiBkksnaKxoAKEjuy5NGGQnF0/kasR3+sVQuoRwm53qsOrMNY1L5WA0Q8c OG9BJrDNXorcG3StpCKGeghnGPJDM0KaBSa72kW6WaIPf8hogLBggPH3UDUwwNsbffgJ iPqb9q/UnnNMGtZnECLgTqhtFuQR55mXAO7Hs1OZQjmDYJJiBD0C8UlrKw5JgC1PtxKs 29hUIyOGSH+gS71xnNKR4tBx/wSOsegyklfkGSf38OFkNvUb0OGrM3EJcSd/vaDYhvnH n83A== X-Received: by 10.152.197.35 with SMTP id ir3mr1359763lac.82.1412283935069; Thu, 02 Oct 2014 14:05:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.88.134 with HTTP; Thu, 2 Oct 2014 14:05:14 -0700 (PDT) In-Reply-To: References: <273F9612-13AF-4CB8-B15C-912AAD04C738@verisign.com> From: Doug Montgomery Date: Thu, 2 Oct 2014 17:05:14 -0400 Message-ID: To: Jakob Schlyter Content-Type: multipart/alternative; boundary=001a11341542459bbf050476faa0 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/3FkbB37uqAKPIf7ONo5j1ZvMyFE Cc: Paul Hoffman , dane WG list Subject: Re: [dane] draft-ietf-dane-smime X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 21:05:40 -0000 --001a11341542459bbf050476faa0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable And how is that definitively distinguishable from that email identity never having a CERT in DANE in the first place? dougm On Thu, Oct 2, 2014 at 5:00 PM, Jakob Schlyter wrote: > On 2 okt 2014, at 22:56, Doug Montgomery wrote: > > > Having a scalable, simple, but definitive way to indicate that a > previously valid email-identity/certificate is no longer valid within a > given domain is a useful feature that doesn't seem to have an analog use > case in TLS. > > If you trust in DANE, and the certificate is no longer published in DNS, > it is not valid - no revocation is needed. > If you do not trust in DANE, normal/legacy revocation procedures > (OCSP/CRL) applies. > > my 0.01=E2=82=AC, > > jakob > > --=20 DougM at Work --001a11341542459bbf050476faa0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
And how is that definitively distinguishable from that ema= il identity never having a CERT in DANE in the first place?

<= div>dougm

On Thu, Oct 2, 2014 at 5:00 PM, Jakob Schlyter <jakob@kirei.se> wrote:
On 2 okt 201= 4, at 22:56, Doug Montgomery <do= ugm.work@gmail.com> wrote:

> Having a scalable, simple, but definitive way to indicate that a previ= ously valid email-identity/certificate is no longer valid within a given do= main is a useful feature that doesn't seem to have an analog use case i= n TLS.

If you trust in DANE, and the certificate is no longer published in = DNS, it is not valid - no revocation is needed.
If you do not trust in DANE, normal/legacy revocation procedures (OCSP/CRL)= applies.

my 0.01=E2=82=AC,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 jakob




--
DougM at Wor= k
--001a11341542459bbf050476faa0-- From nobody Thu Oct 2 15:12:23 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D20A1A03D0 for ; Thu, 2 Oct 2014 15:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.647 X-Spam-Level: X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-2.3] 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 OmSLGGe-rCjI for ; Thu, 2 Oct 2014 15:12:16 -0700 (PDT) Received: from proper.com (Hoffman.Proper.COM [207.182.41.81]) (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 051C91A023E for ; Thu, 2 Oct 2014 15:12:15 -0700 (PDT) Received: from [10.20.30.90] (142-254-17-87.dsl.dynamic.fusionbroadband.com [142.254.17.87]) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id s92MCBcc011960 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 2 Oct 2014 15:12:13 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 142-254-17-87.dsl.dynamic.fusionbroadband.com [142.254.17.87] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Paul Hoffman In-Reply-To: Date: Thu, 2 Oct 2014 15:12:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <09E89369-55B5-4013-A8A1-D905C966997C@vpnc.org> References: <273F9612-13AF-4CB8-B15C-912AAD04C738@verisign.com> To: Doug Montgomery X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/ocZqYEozHLxoupqhdKytNx-3A7M Cc: dane WG list Subject: Re: [dane] draft-ietf-dane-smime X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 22:12:21 -0000 On Oct 2, 2014, at 1:56 PM, Doug Montgomery = wrote: > I am a little confused as to why we seem to couple the use case of key = discovery and distribution in TLS to the use case for = email/network-identity. These seem to be very different use cases to = me. >=20 > I looked back at two years of data. My own, mid-size (3K staff) = organization revokes on average 165 net-identities a month. This is literally the first data I have seen that indicated that email = certs were revoked for other than far edge cases. (I'm assuming that you = are equating "net-identities" and email certs...) Thanks for the data. But, having said that, NIST isn't a typical organization. The fact that = you revoke more than half of your S/MIME certs per year is surprising to = me, but that may be because I am not familiar with the policies you = used. > As far as I know we have never revoked our TLS cert ...=20 Right: TLS certs are rarely revoked. This can be seen by looking at the = CRLs from major CAs. However, looking in those same CRLs shows nearly no = S/MIME certs revoked either. > I know of other industry sectors attempting to develop rather complex = pub/sub architectures to signal changes in status of email identities = from large mailbox providers to other users/uses of the ID.=20 This seems different from what you said above. In a pub/sub = architecture, there is no reason to revoke the old cert when an = individual gets a new identity because the individual still controls the = private key of the earlier identity. In other pub/sub systems I have = seen, they use short-lived (~1 month) certs and issue new ones for = "continuing" usage, so no revocation is needed. > Overly coupling the use cases and requirements between these uses = seems to be a red herring to me. Maybe we should turn the question = around and ask for an explanation why the use cases for TLS should = impact the requirements for SMIMEA? Or, based on what Jakob and I suggested, why shouldn't features that are = needed for either use case be shared? > On Thu, Oct 2, 2014 at 5:00 PM, Jakob Schlyter wrote: > On 2 okt 2014, at 22:56, Doug Montgomery wrote: >=20 > If you trust in DANE, and the certificate is no longer published in = DNS, it is not valid - no revocation is needed. If you do not trust in = DANE, normal/legacy revocation procedures (OCSP/CRL) applies. On Oct 2, 2014, at 2:05 PM, Doug Montgomery = wrote: > And how is that definitively distinguishable from that email identity = never having a CERT in DANE in the first place? >=20 It completely depends on whether the enterprise is using SMIMEA for = certificate discovery or key distribution. Our draft explicitly states = that it is aimed at the latter, but allows the former. Given that the = use case in the introduction is for keys, not certificates, the lack of = presence in the DNS makes the key invisible. This is not to say that TLSA/SMIME should not have the feature of = carrying "this certificate was revoked" information; the WG may want = that. But it seems weird, at least to me, that this feature could be = considered only for S/MIME. --Paul Hoffman= From nobody Thu Oct 2 15:46:53 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1735D1ACEB8 for ; Thu, 2 Oct 2014 15:46:52 -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] 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 x-fE0ayV-huZ for ; Thu, 2 Oct 2014 15:46:50 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 669041ACED9 for ; Thu, 2 Oct 2014 15:46:50 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 6CF9A2AB2D6; Thu, 2 Oct 2014 22:46:48 +0000 (UTC) Date: Thu, 2 Oct 2014 22:46:48 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141002224648.GO13254@mournblade.imrryr.org> References: <273F9612-13AF-4CB8-B15C-912AAD04C738@verisign.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/DIugnyNuOo1Dp5J5MWmdcEyxq9U Subject: Re: [dane] draft-ietf-dane-smime X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 22:46:52 -0000 On Thu, Oct 02, 2014 at 05:05:14PM -0400, Doug Montgomery wrote: > And how is that definitively distinguishable from that email identity never > having a CERT in DANE in the first place? It is not, but identities can have multiple associated certificates, and in fact need to do so during key rotation. The proposal seems to suggest a revocation of the "identity" rather than a particular key and this seems to be operating at the wrong granularity. Ignoring everything but the CU with usage 4 eliminates the option of revoking key "A" while publishing a replacement key "B". Explicit revocation is not a good idea in DANE, the DNS publishes a sufficiently current state of the world, not a stale assertion with a one year TTL. It is I think a mistake to ask where the handbrake goes on a boat, when one happens to be more familiar with cars. In any case if CU=4 is to be a DANE revocation record, it should have a meaningful selector, matching type and association data. It shold be an explicit revocation of just the matching certificate or public key (whether it be associated with a trust-anchor or an end-entity). -- Viktor. From nobody Thu Oct 2 16:07:32 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1490F1ACE39 for ; Thu, 2 Oct 2014 16:07:31 -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] 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 8cQOnCl6rA5Y for ; Thu, 2 Oct 2014 16:07:29 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B3001ACEF9 for ; Thu, 2 Oct 2014 16:07:25 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 0C6162AB2D6; Thu, 2 Oct 2014 23:07:25 +0000 (UTC) Date: Thu, 2 Oct 2014 23:07:24 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141002230724.GP13254@mournblade.imrryr.org> References: <273F9612-13AF-4CB8-B15C-912AAD04C738@verisign.com> <09E89369-55B5-4013-A8A1-D905C966997C@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <09E89369-55B5-4013-A8A1-D905C966997C@vpnc.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/-vUQu0Ytxgwl79xad3R_yjewS2E Subject: Re: [dane] draft-ietf-dane-smime X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 23:07:31 -0000 On Thu, Oct 02, 2014 at 03:12:09PM -0700, Paul Hoffman wrote: > This is not to say that TLSA/SMIME should not have the feature of carrying > "this certificate was revoked" information; the WG may want that. But it > seems weird, at least to me, that this feature could be considered only > for S/MIME. There is an underlying difference that may drive a need for DANE revocation in SMIME, while DANE revocation remains pointless with TLS. * With TLS communication is real-time, and keys authenticate data in motion. There is no need to revoke keys held by the server yesterday once they are no longer published as valid today. * SMIME encrypts data at rest. It is not uncommon to access messages long after the initial delivery. If a signing key was valid at the time at which the message was initially received, the message is authentic. Which raises an interesting problem. Since the proposed TLSA RR does carry a revocation start time, it invalidates *all* past traffic, also covering the time at which the key was not invalid or compromised. To handle revocation correctly with SMIME, the revocation RR would need a more structured association data (to include a revocation start time). Note that there is little need to revoke non-signature keys, just don't deliver email to the no longer affiliated recipient. In fact removing all email encryption keys for a particular recipient risks rather unpleasant consequences for email security when sensitive email is sent to multiple recipients. There may be MUAs that as a result send cleartext to at least that recipient or perhaps all recipients. [ Apple's mail.app automatically enables least common denominator security when sending mail to multiple recipients, so email is only encrypted when encryption keys are available for all recipients. So one would have to be ever vigilant when composing email, to make sure the security indicators are set to one's satisfaction. ] -- Viktor. From nobody Thu Oct 2 16:30:24 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE281ACF9C for ; Thu, 2 Oct 2014 16:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-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 DuFeIQRxTbZi for ; Thu, 2 Oct 2014 16:30:19 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B3F91A8823 for ; Thu, 2 Oct 2014 16:30:19 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id DFF6C2AB2A7; Thu, 2 Oct 2014 23:30:17 +0000 (UTC) Date: Thu, 2 Oct 2014 23:30:17 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141002233017.GQ13254@mournblade.imrryr.org> References: <4C36FDC5-12D2-48C1-A3D5-7AA4090E98C8@isoc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C36FDC5-12D2-48C1-A3D5-7AA4090E98C8@isoc.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/tzQlsSO2rhOwLVYTbpPZCeyJRYs Subject: Re: [dane] Meeting in Hawaii? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 23:30:22 -0000 On Wed, Oct 01, 2014 at 11:49:48AM +0000, Dan York wrote: > All the authors of the various drafts on DANE for email (S/MIME > and OpenPGP) will be there, and we will have discussions on the > list beforehand. Given this, I for one, hope we can meet and flesh > out any details left on this topic. FWIW, I will not be present. > To Jakob's point, we're going to have a significant number of > the DANE-related authors and implementors all together at IETF and > I think a general topic of "What Else Do We Need To Do For DANE > For Email" could be a good discussion topic. I am at Frankfurt Airport after a trip to speak about DANE at the DENIC registrar technical conference. You may be aware that the most substantial DANE deployments are for now in Germany, and this is likely to continue through the rest of 2014, with additional .de deployments, with little progress elsewhere. [ Many SMTP domains with TLSA RRs are listed at: https://www.tlsa.info/statistics/best_results though this site may not actually be checking that the servers actually have a matching certificate chain, rather it looks like it just checks for the presence of DNSSEC validated TLSA RRs. Ironically, the site's HTTPS server has an expired stapled OCSP response at the moment. ] It seems that DNSSEC deployment *is* by far the main obstacle. Registrars need to support DS RRs and ideally be able to host DNSSEC domains. Unlike registries looking after one or a handful of domains, registrars host thousands to millions of domains. One of the issues raised at the DENIC meeting, is that DNSSEC-capable nameserver software that scales well to very large zone counts is by no means abundant. Reportedly only PowerDNS comes close, and at least some registrars are reluctant to put all the eggs in one basket and rely on just a single software platform. So if there is anything that can be done to spur deployment of additional scalable nameservers, that would be great. Of course there is also impedance at the consumer end, with a lot of cable-modems and the like acting as DHCP server + DNS proxy, but not supporting DNSSEC. Once DNSSEC is working, the actual DANE deployment is rather a lot simpler. Just publish some TLSA RRs and implement the right key-rotation strategy. For now, only Postfix implements DANE outbound (inbound any MTA will do, all the DANE-specific code is on the client). Adoption beyond .de would be greatly advanced if at least one large email provider published TLSA RRs and/or implemented DANE outbound. Gmail, Microsoft Office365, Yahoo, AOL, should at least seriously consider plans towards SMTP with opportunistic DANE TLS. If you can do anything to prod the right people, that would be great. Beyond SMTP, it would be great to get some early design work underway for opportunistic DANE TLS with "h2" (HTTP). I don't see DANE adoption for HTTPS any time soon (at least not until EV certs go out of style). DANE can however substantially harden opportunistic security with HTTP, provided last-mile is under control. This runs into the "last-mile" problem for DNSSEC. Where are we with that? I explained to the DENIC registrars how DANE simplifies virtual hosting, obviates CRLs and improves effectiveness of "revocation" (de-publishing bad data from DNS). These are good features for HTTP to have, but we seem to be no closer to DANE for HTTP. In the pipeline we have just Exim, some XMPP software, and more German domains. > - are there places where it would be helpful if there were > reference implementations of DANE support? For example, DANE for > email got a boost when Viktor added it to Postfix. Are there other > commonly-used open source projects where the addition of DANE > support would help move deployment along? Well, Sendmail support would also be nice. But more importantly some of the closed MTAs would probably be more important: * Microsoft Exchange * Ironport, Barracuda and similar appliances * Gmail, Yahoo, AOL, Office365, ... Of course having reasonably feature-complete support for DANE in TLS toolkits would really help. This is why I've joined the OpenSSL team, with a mission to work on integrated DANE support, once some of the more urgent priorities in OpenSSL are resolved. It would be helpful to have sound DANE support in NSS, GnuTLS, PolarSSL, ... provided these were designed and implemented with care and are not just incomplete prototypes. In particular, I don't have the cycles to design-review/code-review all DANE implementations, but such reviews are likely necessary. Yes, testing can find many classes of bugs, and a DANE test-suite would be useful. -- Viktor. From nobody Thu Oct 2 17:36:25 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 102ED1ACFB6 for ; Thu, 2 Oct 2014 17:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 5iyKIUh9iOHz for ; Thu, 2 Oct 2014 17:36:21 -0700 (PDT) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32C9D1ACFB3 for ; Thu, 2 Oct 2014 17:36:21 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id z12so235006wgg.25 for ; Thu, 02 Oct 2014 17:36:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ZMc0Hfg8B7pifSa/SmR7WPxIBOctA+repxROexI8y9Y=; b=AMwwmmScN/564RzPvCvn7i0x9FOjLVcIz4GSaPSSpol22lBCmq8PLSBC+UKbge+D86 D/SjaFxo/F16sBCN6paFEqlI6+bb3LljXxxWem7Quyw1U61/tF/Ie15z+HHwUS4rX1t+ brNbrtv1aK3NrC57VhMzEfHRj2sCwhlgmEBHVSSTmIbUl2QYRzqA7lA1cuYeGJHy+uwm 2sm2pHmlFFKsQ4nZnj6J7u1hj9ZRLz/442xyjKCeGMJiQHN4dMRJDXuKixIeI00nLFyA /jX9cMpX65tVjdFpiYopEEA9cqRcQljHpgLuy5AKA2RViwsDBnylotbTla541kF/TyRd zpbg== X-Gm-Message-State: ALoCoQn0Ea7gWgRLVVhmnTgdMrZ1r3oiB3zyUHjlAye13rRkDAGEgpwJOdrcLWTxi4EkkbRYdpXd MIME-Version: 1.0 X-Received: by 10.180.210.231 with SMTP id mx7mr8140013wic.42.1412296579754; Thu, 02 Oct 2014 17:36:19 -0700 (PDT) Received: by 10.194.119.233 with HTTP; Thu, 2 Oct 2014 17:36:19 -0700 (PDT) In-Reply-To: <4C36FDC5-12D2-48C1-A3D5-7AA4090E98C8@isoc.org> References: <4C36FDC5-12D2-48C1-A3D5-7AA4090E98C8@isoc.org> Date: Thu, 2 Oct 2014 20:36:19 -0400 Message-ID: From: Warren Kumari To: Dan York Content-Type: multipart/alternative; boundary=001a11c25d32f44655050479eb20 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/KUCyWUWEXVxmxnkssNTS3IrPh9E Cc: "" Subject: Re: [dane] Meeting in Hawaii? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 00:36:24 -0000 --001a11c25d32f44655050479eb20 Content-Type: text/plain; charset=UTF-8 On Wednesday, October 1, 2014, Dan York wrote: > Warren, (and everyone else) > > On Sep 29, 2014, at 4:10 PM, Jakob Schlyter > wrote: > > On 27 sep 2014, at 02:52, Warren Kumari > wrote: > > Please let us know if you'd really like to meet, and open issues on > documents that need discussing. Also, if you have a doc, we'd like it > revised *soon*. > > > All the authors of the various drafts on DANE for email (S/MIME and > OpenPGP) will be there, and we will have discussions on the list > beforehand. Given this, I for one, hope we can meet and flesh out any > details left on this topic. > > > To Jakob's point, we're going to have a significant number of the > DANE-related authors and implementors all together at IETF and I think a > general topic of "What Else Do We Need To Do For DANE For Email" could be a > good discussion topic. > > While we have this great big "DANE brain trust" all in one location (and > also coming in remotely), I would be interested in having (and would be > willing to lead, if necessary) a discussion around "What Else Do We Need To > Do To Get DANE More Widely Deployed". Now that we are seeing actual > deployment and usage, are there things we have learned that can guide us in > accelerating the deployment of DANE? > > We've captured a good bit of implementation guidance in Viktor and Wes' > https://tools.ietf.org/html/draft-ietf-dane-ops-06 and so perhaps a > review of that document would help, but I'm also interested in questions > like: > > - what roadblocks are people running into with implementing DANE? > (outside of the broader issue of getting DNSSEC validation and signing > more widely available) > > - are there more "Using DANE with " types of documents that we can > or should create? (and who is willing to do so) > > - have we seen areas where more standardization would help? > > - are there some good examples/case studies of DANE implementations that > we could perhaps capture as informational RFCs? (the Jabber community's > implementation comes to mind) > > - are there places where it would be helpful if there were reference > implementations of DANE support? For example, DANE for email got a boost > when Viktor added it to postfix. Are there other commonly-used open source > projects where the addition of DANE support would help move deployment > along? (I'm NOT saying that the DANE WG would be involved with these > implementations... but brainstorming together and identifying a list could > help other people and groups (ex. Internet Society, Verisign Labs, NLNet > Labs) advocate and perhaps fund efforts to get that DANE support added.) > > - are there test tools that need to be developed? or existing ones that > need to be better promoted? are there interop tests we can arrange? > > I realize some of this may seem outside our charter, but if I look at > the charter, it includes these phrases: > ----- > The > DANE WG shall also produce a set of implementation guidance > for operators and tool developers. > > > > The group may also create documents that describe how protocol > entities can discover and validate these bindings in the execution > of specific applications. This work would be done in coordination > with the IETF Working Groups responsible for the protocols. > > The group may in addition encourage interoperability testing and > document the results of such testing. > ----- > > So I do see a good bit of this covered under that. > > The end result I'd like to see out of this discussion would be: > > - guidance for the WG on what, if any, additional documents we need to > create (and identification of who might write them) > - potential interoperability testing > - guidance to WG members and other organizations on how we can get DANE > more widely deployed > > Obviously I have an interest in this because I'm employed by the > Internet Society in large part to do whatever possible to accelerate the > deployment of DNSSEC (and IPv6 and... ), but this really means that I'm > here for *you* all to help do what needs to be done. I'd definitely > appreciate a sense of the group about what we can all collectively do to > make DANE more widely used. Certainly we can have some of this discussion > on the list... but in a f2f meeting we can have a much more engaged > discussion. > > So if we have time on the agenda and you all feel it would be > appropriate, I'd like to have a discussion along these lines. > > I'm not sure we need 2 hours though - 1,5 hours should be enough. > > > I'm also not sure we need 2 hours... although this discussion I outlined > above could wind up occupying some time. > > Great -- we'll meet. I'll chat with Olafur re: 1.5h vs 2h. It is nice to see that there is this much interest / desire to meet -- a cynical reader might assume that this was all a nasty, but clever ploy to get folk to promise to rev docs, and come up with interesting topics... but we are not that inventive / evil :-P > Dan > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf --001a11c25d32f44655050479eb20 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wednesday, October 1, 2014, Dan York <york@isoc.org> wrote:
Warren, (and everyone else)

On Sep 29, 2014, at 4:10 PM, Jakob Schlyter <jako= b@kirei.se> wrote:

On 27 sep 2014, at 02:52, Warren Kumari <warren@kumari.net> wrote:

Please let us know if you'd really like to me= et, and open issues on
documents that need discussing. Also, if you have a doc, we'd like it revised *soon*.

All the authors of the various drafts on DANE for email (S/MIME and OpenPGP= ) will be there, and we will have discussions on the list beforehand. Given= this, I for one, hope we can meet and flesh out any details left on this t= opic.

To Jakob's point, we're going to have a significant number of = the DANE-related authors and implementors all together at IETF and I think = a general topic of "What Else Do We Need To Do For DANE For Email"= ; could be a good discussion topic.

While we have this great big "DANE brain trust" all in one l= ocation (and also coming in remotely), I would be interested in having (and= would be willing to lead, if necessary) a discussion around "What Els= e Do We Need To Do To Get DANE More Widely Deployed". =C2=A0Now that we are seeing actual deployment and usage, are there things= we have learned that can guide us in accelerating the deployment of DANE?<= /div>

We've captured a good bit of implementation guidance in Viktor and= Wes'=C2=A0https://tools.ietf.org/html/draft-ietf-dane-ops-06= =C2=A0and so perhaps a review of that document would help, but I'm also interested in questions like:

- what roadblocks are people running into with implementing DANE? =C2= =A0(outside of the broader issue of getting DNSSEC validation and signing m= ore widely available)

- are there more "Using DANE with <foo>" types of docu= ments that we can or should create? (and who is willing to do so)

- have we seen areas where more standardization would help?

- are there some good examples/case studies of DANE implementations th= at we could perhaps capture as informational RFCs? =C2=A0(the Jabber commun= ity's implementation comes to mind)

- are there places where it would be helpful if there were reference i= mplementations of DANE support?=C2=A0 For example, DANE for email got a boo= st when Viktor added it to postfix.=C2=A0 Are there other commonly-used ope= n source projects where the addition of DANE support would help move deployment along? =C2=A0 (I'm NOT saying that = the DANE WG would be involved with these implementations... but brainstormi= ng together and identifying a list could help other people and groups (ex. = Internet Society, Verisign Labs, NLNet Labs) advocate and perhaps fund efforts to get that DANE support added.)

- are there test tools that need to be developed? or existing ones tha= t need to be better promoted? =C2=A0are there interop tests we can arrange?=

I realize some of this may seem outside our charter, but if I look at = the charter, it includes these phrases:
-----
The
DANE WG shall also produce a set of impleme= ntation guidance=C2=A0
for operators and tool developers.

<big snip>

The group may also create documents that describe how protocol
entities can discover and validate these bindings in the execution
of specific applications. This work would be done in coordination
with the IETF Working Groups responsible for the protocols.

The group may in addition encourage interoperability testing and=C2=A0
document the results of such testing.
-----

So I do see a good bit of this covered under that.

The end result I'd like to see out of this discussion would be:

- guidance for the WG on what, if any, additional documents we need to= create (and identification of who might write them)
- potential interoperability testing
- guidance to WG members and other organizations on how we can get DAN= E more widely deployed

Obviously I have an interest in this because I'm employed by the I= nternet Society in large part to do whatever possible to accelerate the dep= loyment of DNSSEC (and IPv6 and... ), but this really means that I'm he= re for *you* all to help do what needs to be done.=C2=A0 I'd definitely appreciate a sense of the group about wh= at we can all collectively do to make DANE more widely used.=C2=A0 Certainl= y we can have some of this discussion on the list... but in a f2f meeting w= e can have a much more engaged discussion.

So if we have time on the agenda and you all feel it would be appropri= ate, I'd like to have a discussion along these lines.

I'm not sure we need 2 hours though - 1,5 hou= rs should be enough.

I'm also not sure we need 2 hours... although this discussion I ou= tlined above could wind up occupying some time.


Great -- we'll meet. I'= ;ll chat with Olafur re: 1.5h vs 2h.

It is nice to= see that there is this much interest / desire to meet --=C2=A0a cynical re= ader might assume that this was all a nasty, but clever=C2=A0ploy to get fo= lk to promise to rev docs, and come up with interesting topics... but we ar= e not that inventive / evil=C2=A0:-P

= =C2=A0
Dan


--
I don't think the execution is relevant whe= n it was obviously a bad idea in the first place.
This is like putting r= abid weasels in your pants, and later expressing regret at having chosen th= ose particular rabid weasels and that pair of pants.
=C2=A0 =C2=A0---maf=
--001a11c25d32f44655050479eb20-- From nobody Thu Oct 2 18:02:08 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6EF1ACFB7 for ; Thu, 2 Oct 2014 18:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bl3KQLHVQ5Jy for ; Thu, 2 Oct 2014 18:02:06 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 529B61A884C for ; Thu, 2 Oct 2014 18:02:06 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 71B0320012 for ; Thu, 2 Oct 2014 21:07:51 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 98FB863AED; Thu, 2 Oct 2014 21:02:05 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 8A83363AEC for ; Thu, 2 Oct 2014 21:02:05 -0400 (EDT) From: Michael Richardson To: dane@ietf.org In-Reply-To: <20141002233017.GQ13254@mournblade.imrryr.org> References: <4C36FDC5-12D2-48C1-A3D5-7AA4090E98C8@isoc.org> <20141002233017.GQ13254@mournblade.imrryr.org> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/dane/v7uIjlxbYW43Fu7NJBtRNeEb2ek Subject: Re: [dane] Meeting in Hawaii? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 01:02:07 -0000 --=-=-= Viktor Dukhovni wrote: > It seems that DNSSEC deployment *is* by far the main obstacle. > Registrars need to support DS RRs and ideally be able to host DNSSEC > domains. Unlike registries looking after one or a handful of > domains, registrars host thousands to millions of domains. One of > the issues raised at the DENIC meeting, is that DNSSEC-capable > nameserver software that scales well to very large zone counts is > by no means abundant. Reportedly only PowerDNS comes close, and > at least some registrars are reluctant to put all the eggs in one > basket and rely on just a single software platform. Is it a question of the signing infrastructure, or the publication infrastructure? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVC31jYCLcPvd0N1lAQKPewf/agZ5q+XpsF+LTT9mgKacrQlFmuhS3jVb qtcYPllHurrcZoZtO86fgRiqf9eZxr/8FY9M5gIVks64VFJ8H7S5Gf8WlF+/eya0 OqK3S5NeHeCAArsPlWnt0+BvIi1KpivZJ1jU2gkLee+XoMyTC6BUxzTVZsVvV0wg lac/kdfYus9pfAHGNvMTb59zS+28qoLDfmJXFF8imDJUndIiqlbr1/pBvXv2oa2W R26Ph+e/LUF/JmCXDqp5B39895v/jYFs257t7WuBLTuYqsdvYFnVQiTRuYpbYAd/ L3KeM1nePAx8SE14ifMXEmXO8PMPrlRZfD2x+UngmMs2krnoysDXCg== =IPz6 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Oct 2 19:12:01 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D5AE1ACFCD for ; Thu, 2 Oct 2014 19:11:59 -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] 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 gOuONmwgH-Zg for ; Thu, 2 Oct 2014 19:11:57 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 758C81A8883 for ; Thu, 2 Oct 2014 19:11:57 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 859F32AB2D6; Fri, 3 Oct 2014 02:11:56 +0000 (UTC) Date: Fri, 3 Oct 2014 02:11:56 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141003021156.GR13254@mournblade.imrryr.org> References: <4C36FDC5-12D2-48C1-A3D5-7AA4090E98C8@isoc.org> <20141002233017.GQ13254@mournblade.imrryr.org> <21940.1412298125@sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <21940.1412298125@sandelman.ca> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/uyugJGQpNK69r2SFHHF_OFn10IE Cc: Jens Wagner Subject: Re: [dane] Meeting in Hawaii? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 02:11:59 -0000 On Thu, Oct 02, 2014 at 09:02:05PM -0400, Michael Richardson wrote: > > Viktor Dukhovni wrote: > > It seems that DNSSEC deployment *is* by far the main obstacle. > > Registrars need to support DS RRs and ideally be able to host DNSSEC > > domains. Unlike registries looking after one or a handful of > > domains, registrars host thousands to millions of domains. One of > > the issues raised at the DENIC meeting, is that DNSSEC-capable > > nameserver software that scales well to very large zone counts is > > by no means abundant. Reportedly only PowerDNS comes close, and > > at least some registrars are reluctant to put all the eggs in one > > basket and rely on just a single software platform. > > Is it a question of the signing infrastructure, or the publication > infrastructure? I don't understand the issues in detail. Perhaps Jens Wagner will respond. -- Viktor. From nobody Fri Oct 3 02:38:40 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4D881AD009 for ; Fri, 3 Oct 2014 02:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.948 X-Spam-Level: X-Spam-Status: No, score=0.948 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_DE=0.35, J_CHICKENPOX_45=0.6, 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 4UKjq444vCVU for ; Fri, 3 Oct 2014 02:38:38 -0700 (PDT) Received: from triangulum.uberspace.de (triangulum.uberspace.de [95.143.172.227]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF1131A0233 for ; Fri, 3 Oct 2014 02:38:37 -0700 (PDT) Received: (qmail 4659 invoked from network); 3 Oct 2014 09:38:34 -0000 Received: from localhost (HELO www.bartschnet.de) (127.0.0.1) by triangulum.uberspace.de with SMTP; 3 Oct 2014 09:38:34 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Fri, 03 Oct 2014 11:38:33 +0200 From: Rene Bartsch To: IETF DANE Mailinglist In-Reply-To: References: Message-ID: <570ff050aaf87884e5d2d81a2f6ecf2a@triangulum.uberspace.de> X-Sender: ietf@bartschnet.de User-Agent: Roundcube Webmail/1.0.1 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/1x_WE_-KQ0cObSQnpkWRvVjPdzc Subject: Re: [dane] =?utf-8?q?List_of_incidents_that_DANE_would_have_blocked?= =?utf-8?q?=3F?= X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 09:38:39 -0000 Am 2014-10-01 18:37, schrieb William Stouder-Studenmund: > I learned about DANE recently and was excitedly talking to some > operations friends of mine about it. Some of them work in shops that > aren’t using DNSSEC yet, and DANE’s requirement of it would trigger > push-back from management. Primary nameservers like BIND or PowerDNS generate DNSSEC-resource records automagically. All you need to do is to handover your DSKEY/ZSK to your domain registry periodically. Usually you just have to Copy&Paste the new keys into your registrar's web-interface per quarter, half-year or year. Even my private domains are secured with DNSSEC/DANE by using a DNS-operator with managed DNSSEC. I only generate the TLSA-RRs myself when I change the TLS-certs every two years. As a quick-start I suggest to use Shumon Huque's web-generator for TLSA-RRs (https://www.huque.com/bin/gen_tlsa). To reduce effort of changing TLSA-RRs when changing the TLS-certificate you can use CNAMES and wildcard-RRs pointing to ONE single TLSA-RR. For client-side I suggest a warning message in your shops to encourage users to install the CZNIC DNSSEC/TLSA Validator web browser add-on (https://www.dnssec-validator.cz/). Renne -- Best regards, Rene Bartsch, B. Sc. Informatics From nobody Fri Oct 3 02:47:26 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F2E81AD004 for ; Fri, 3 Oct 2014 02:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.948 X-Spam-Level: X-Spam-Status: No, score=0.948 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_DE=0.35, J_CHICKENPOX_64=0.6, 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 EL0aFshBDmA8 for ; Fri, 3 Oct 2014 02:47:21 -0700 (PDT) Received: from triangulum.uberspace.de (triangulum.uberspace.de [95.143.172.227]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13B7D1AD003 for ; Fri, 3 Oct 2014 02:47:20 -0700 (PDT) Received: (qmail 16555 invoked from network); 3 Oct 2014 09:47:19 -0000 Received: from localhost (HELO www.bartschnet.de) (127.0.0.1) by triangulum.uberspace.de with SMTP; 3 Oct 2014 09:47:19 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 03 Oct 2014 11:47:17 +0200 From: Rene Bartsch To: IETF DANE Mailinglist In-Reply-To: <65B99B57-FDCB-4E0A-A65A-21F80B67C205@isoc.org> References: <65B99B57-FDCB-4E0A-A65A-21F80B67C205@isoc.org> Message-ID: X-Sender: ietf@bartschnet.de User-Agent: Roundcube Webmail/1.0.1 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/NryU2N9wn5RVfkg0GLlNH6snxaI Subject: Re: [dane] Google Chromium team closes DNSSEC/DANE as a WontFix X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 09:47:25 -0000 Am 2014-10-02 14:09, schrieb Dan York: > It seems we may not be seeing DANE / DNSSEC support in Google Chrome > anytime soon. This ticket was just closed as a WontFix: > > https://code.google.com/p/chromium/issues/detail?id=50874#c22 [1] > > As the ticket says (in part): > ----- > > Closing this out as WontFix, as there are no plans. > > DNSSEC and DANE (types 2/3) do not measurably raise the bar for > security compared to alternatives, and can be negative for security. > DNSSEC+DANE (types 0/1) can be accomplished via HTTP Public Key > Pinning to the same effect, and with a much more reliable and > consistent delivery mechanism. > > While not desiring to stifle discussion, we've continued to evaluate > the security and usability benefits and costs of DNSSEC and DANE, and > will continue to do so, but for now, this is neither something we plan > to implement nor would support landing. > ----- > > Any thoughts? > > Dan It seems Google wants to become the one and only authority by certificate pinning to control whose certificates are accepted instead of leaving the choice to the domain owner. This also obstructs the transition to free self-signed certificates for non-commercial domains. In my opinion the certificate should be linked to the domain by the domain infrastructure -> DNSSEC. Please comment https://bugzilla.mozilla.org/show_bug.cgi?id=1077323 to encourage Mozilla to implement DANE. This would also improve security when downloading Firefox updates/addons. -- Best regards, Rene Bartsch, B. Sc. Informatics From nobody Fri Oct 3 08:54:26 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9AF71A0337 for ; Fri, 3 Oct 2014 08:54:24 -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] 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 Y48K29dxD0_S for ; Fri, 3 Oct 2014 08:54:23 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CE991A033D for ; Fri, 3 Oct 2014 08:54:23 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id C749D2AB2A7; Fri, 3 Oct 2014 15:54:21 +0000 (UTC) Date: Fri, 3 Oct 2014 15:54:21 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141003155421.GZ13254@mournblade.imrryr.org> References: <65B99B57-FDCB-4E0A-A65A-21F80B67C205@isoc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <65B99B57-FDCB-4E0A-A65A-21F80B67C205@isoc.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/KX-EUqp9SS6Aty7BgFCamy4lIhE Subject: Re: [dane] Google Chromium team closes DNSSEC/DANE as a WontFix X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 15:54:25 -0000 On Thu, Oct 02, 2014 at 12:09:05PM +0000, Dan York wrote: > It seems we may not be seeing DANE / DNSSEC support in Google > Chrome anytime soon. This ticket was just closed as a WontFix: > > Any thoughts? I'm not surprised with respect to HTTPS. I'd however like to eventually see DANE support in the new opportunistic security HTTP. Perhaps a dialogue can be opened up with the browser developer community to understand the pros and cons and what it would take to make opportunistic DANE TLS with HTTP2 a realistic option. (Is it all about the DNSSEC last mile? Something else?) -- Viktor. From nobody Fri Oct 3 12:27:54 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 521371A6FB3 for ; Fri, 3 Oct 2014 12:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 2IGpKGCP2a7p for ; Fri, 3 Oct 2014 12:27:52 -0700 (PDT) Received: from homiemail-a108.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id A9E511A1A15 for ; Fri, 3 Oct 2014 12:27:52 -0700 (PDT) Received: from homiemail-a108.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTP id 8BF7720058D82 for ; Fri, 3 Oct 2014 12:27:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:references:mime-version:content-type :in-reply-to; s=cryptonector.com; bh=C6nsYqhgBK6/JuHJtE6Y2aGSeFc =; b=yvwIDpQOROYHSQrVOexe/bTaMftVSGcc6YnNAcp7WCTGkrj8rnuTkpZU/BL DyTqV3zHYdcbjhB+gEnmqzjKUWrTXzMN9PdSO+Qrh6QlGG8oz/0sCcICYb2HJBgu pCohKN9JI3vxXzNGdL8Zui6/xPFTv9r7Be4ld1gKB1yTnuUM= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTPA id 5414920058D81 for ; Fri, 3 Oct 2014 12:27:52 -0700 (PDT) Date: Fri, 3 Oct 2014 14:27:51 -0500 From: Nico Williams To: dane@ietf.org Message-ID: <20141003192750.GE4981@localhost> References: <65B99B57-FDCB-4E0A-A65A-21F80B67C205@isoc.org> <20141003155421.GZ13254@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141003155421.GZ13254@mournblade.imrryr.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/2aMRneufJfhJtJbIARaPBaesqo8 Subject: Re: [dane] Google Chromium team closes DNSSEC/DANE as a WontFix X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 19:27:53 -0000 On Fri, Oct 03, 2014 at 03:54:21PM +0000, Viktor Dukhovni wrote: > On Thu, Oct 02, 2014 at 12:09:05PM +0000, Dan York wrote: > > It seems we may not be seeing DANE / DNSSEC support in Google > > Chrome anytime soon. This ticket was just closed as a WontFix: > > > > Any thoughts? > > I'm not surprised with respect to HTTPS. But I am surprised at the contents. > I'd however like to eventually see DANE support in the new > opportunistic security HTTP. Perhaps a dialogue can be opened up Yes, H2 creates a great new opportunity. > with the browser developer community to understand the pros and > cons and what it would take to make opportunistic DANE TLS with > HTTP2 a realistic option. (Is it all about the DNSSEC last mile? > Something else?) +1 Nico -- From nobody Fri Oct 3 13:45:50 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11BBA1A03A5 for ; Fri, 3 Oct 2014 13:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-0.7] 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 K4n9s_KfqCLJ for ; Fri, 3 Oct 2014 13:45:48 -0700 (PDT) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F19EE1A1A59 for ; Fri, 3 Oct 2014 13:45:45 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id cc10so2472151wib.2 for ; Fri, 03 Oct 2014 13:45:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/eaZrTFEm8+/YcYc6Kgkc0EX8YbP+pr4oRyhcs3HLFY=; b=d1UOM+22Bus1v5Ww3UbagdrMGFrLEDPe950JQMz6oyHuMZ0cm/6FM8OIFqGWuOii1L rHULumHfHrSVjBFZgyT0hF5Cao3AtF5sw25WecLcEYeX4JWl+5QdymFjokmrvJOZYL3T 4A0p7gVi4oC+EPot+4gdYmzNEGMJ+MAn0w46tg7MwIfs2UccstX6OBqLYhOTq89MNSOS Mnxy/Ig8NRAak9+r5/lmsPJ3g8+CuTXFHotYcjb81W2gs/iq1sFE4ZWBzibnWgizs6Ue osmQI04fhyxR167AuCUZFAxzzYOMAMb5krTzaAKX2x+CdmrfBmCm6HohUIbfQdcZRk0r 3Bdg== X-Gm-Message-State: ALoCoQkIw6Ez8WuWsgzPnE5BqcZMj67+ynGHjpgz2CjHRrxR45ZyX5e7/XDzfXmapvS3HUCe5dhV MIME-Version: 1.0 X-Received: by 10.194.24.169 with SMTP id v9mr10684394wjf.114.1412369144520; Fri, 03 Oct 2014 13:45:44 -0700 (PDT) Received: by 10.194.119.233 with HTTP; Fri, 3 Oct 2014 13:45:44 -0700 (PDT) In-Reply-To: <570ff050aaf87884e5d2d81a2f6ecf2a@triangulum.uberspace.de> References: <570ff050aaf87884e5d2d81a2f6ecf2a@triangulum.uberspace.de> Date: Fri, 3 Oct 2014 16:45:44 -0400 Message-ID: From: Warren Kumari To: Rene Bartsch Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dane/HxvrZDWjwXWlstLqO38H7rdu6sM Cc: IETF DANE Mailinglist Subject: Re: [dane] List of incidents that DANE would have blocked? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 20:45:49 -0000 On Fri, Oct 3, 2014 at 5:38 AM, Rene Bartsch wrote: > Am 2014-10-01 18:37, schrieb William Stouder-Studenmund: >> >> I learned about DANE recently and was excitedly talking to some >> operations friends of mine about it. Some of them work in shops that >> aren=E2=80=99t using DNSSEC yet, and DANE=E2=80=99s requirement of it wo= uld trigger >> push-back from management. > > > Primary nameservers like BIND or PowerDNS generate DNSSEC-resource record= s > automagically. Yup. > All you need to do is to handover your DSKEY/ZSK to your > domain registry periodically. Yup. > Usually you just have to Copy&Paste the new > keys into your registrar's web-interface per quarter, half-year or year. Which gets annoying *really* fast. May I introduce you to RFC7344 - Automating DNSSEC Delegation Trust Maintenance (http://tools.ietf.org/html/rfc7344) Ask your favorite name server vendor to implement this -- basically it automates rolling over of your keys, by having the old key introduce the new one. W > Even my private domains are secured with DNSSEC/DANE by using a DNS-opera= tor > with managed DNSSEC. I only generate the TLSA-RRs myself when I change th= e > TLS-certs every two years. > > As a quick-start I suggest to use Shumon Huque's web-generator for TLSA-R= Rs > (https://www.huque.com/bin/gen_tlsa). To reduce effort of changing TLSA-R= Rs > when changing the TLS-certificate you can use CNAMES and wildcard-RRs > pointing to ONE single TLSA-RR. For client-side I suggest a warning messa= ge > in your shops to encourage users to install the CZNIC DNSSEC/TLSA Validat= or > web browser add-on (https://www.dnssec-validator.cz/). > > > Renne > > > -- > Best regards, > > Rene Bartsch, B. Sc. Informatics > > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Sat Oct 4 07:56:43 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7FAD1A1A25 for ; Sat, 4 Oct 2014 07:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 JbdskFpZidos for ; Sat, 4 Oct 2014 07:56:40 -0700 (PDT) Received: from smtp68.ord1c.emailsrvr.com (smtp68.ord1c.emailsrvr.com [108.166.43.68]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EE051A0364 for ; Sat, 4 Oct 2014 07:56:39 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp1.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id B0051380D7D for ; Sat, 4 Oct 2014 10:56:38 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp1.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 608F8380D7B for ; Sat, 4 Oct 2014 10:56:38 -0400 (EDT) X-Sender-Id: ogud@ogud.com Received: from [10.0.1.52] ([UNAVAILABLE]. [208.72.142.196]) (using TLSv1 with cipher AES128-SHA) by 0.0.0.0:465 (trex/5.2.13); Sat, 04 Oct 2014 14:56:38 GMT From: Olafur Gudmundsson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Sat, 4 Oct 2014 10:56:37 -0400 To: "dane@ietf.org list" 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/dane/Cj1j0rSPDFU4ui7-8JHYihhW0rc Subject: [dane] DANE agenda @IETF-91 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 14:56:42 -0000 Dear Colleagues=20 please send us chairs items that you want to propose for the agenda by = email to dane-chairs@tools.ietf.org=20 thanks Olafur & Warren=20 From nobody Sun Oct 5 14:01:57 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FDB81A000A for ; Sun, 5 Oct 2014 14:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 7gJAbA52T4f5 for ; Sun, 5 Oct 2014 14:01:53 -0700 (PDT) Received: from internal-mail-out1.ispapi.net (internal-mail-out1.ispapi.net [93.190.234.74]) by ietfa.amsl.com (Postfix) with ESMTP id 3CCD91A0007 for ; Sun, 5 Oct 2014 14:01:53 -0700 (PDT) Received: from internal-mail-relay1.sls.de.hexonet.net (mx.hexonet.net [10.190.234.71]) by internal-mail-out1.ispapi.net (Postfix) with ESMTP id BD04D10400F1 for ; Sun, 5 Oct 2014 21:01:51 +0000 (UTC) Envelope-to: dane@ietf.org Received: from p5dd44a1a.dip0.t-ipconnect.de ([93.212.74.26]:53251 helo=[192.168.2.120]) by internal-mail-relay1.sls.de.hexonet.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XaswB-0005rb-JK for dane@ietf.org; Sun, 05 Oct 2014 21:01:51 +0000 Message-ID: <5431B1BE.2030008@hexonet.net> Date: Sun, 05 Oct 2014 23:01:50 +0200 From: Jens Wagner User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: dane@ietf.org References: <4C36FDC5-12D2-48C1-A3D5-7AA4090E98C8@isoc.org> <20141002233017.GQ13254@mournblade.imrryr.org> <21940.1412298125@sandelman.ca> <20141003021156.GR13254@mournblade.imrryr.org> In-Reply-To: <20141003021156.GR13254@mournblade.imrryr.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 93.212.74.26 X-SA-Exim-Mail-From: jwagner@hexonet.net Archived-At: http://mailarchive.ietf.org/arch/msg/dane/wsVvi39Vw00AV4aKSxvPDhmF464 Subject: Re: [dane] Meeting in Hawaii? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2014 21:01:55 -0000 Hi Viktor, Hi Michael, > On Thu, Oct 02, 2014 at 09:02:05PM -0400, Michael Richardson wrote: >> Viktor Dukhovni wrote: >> > It seems that DNSSEC deployment *is* by far the main obstacle. >> > Registrars need to support DS RRs and ideally be able to host DNSSEC >> > domains. Unlike registries looking after one or a handful of >> > domains, registrars host thousands to millions of domains. One of >> > the issues raised at the DENIC meeting, is that DNSSEC-capable >> > nameserver software that scales well to very large zone counts is >> > by no means abundant. Reportedly only PowerDNS comes close, and >> > at least some registrars are reluctant to put all the eggs in one >> > basket and rely on just a single software platform. >> >> Is it a question of the signing infrastructure, or the publication >> infrastructure? > I don't understand the issues in detail. Perhaps Jens Wagner will > respond. It's a question of the publication infrastructure. Right now, PowerDNS is the only (open source) DNS server supporting both DNSSEC and large zone counts (unlike the typical registry setup, where you manage a small number of huge zonefiles). As a registrar, we allow our customers to add, remove and update DNS zones, and all those updates get pushed to our publication infrastructure immediately (~4 seconds delay). Those updates should not interfere with the resolution of other zones. Also, to prevent DNS outages caused by attacks and other reasons, we do not want to rely on a single vendor solution, so we use MyDNS and PowerDNS together (both implement database backed, cached responses). However, MyDNS never implemented DNSSEC (and is sort of abandoned), BIND10/Bundy is (was?) not production ready, and others like YADIFA and Knot are optimized for TLD operations only. So our options are: - run DNS using PowerDNS only (works perfectly, but SPOF) - implement DNSSEC into MyDNS ourselves - wait for Bundy (or another product) to become production ready Do you have any suggestions? Best regards, - jens From nobody Sun Oct 5 19:05:47 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A32131A02D8 for ; Sun, 5 Oct 2014 19:05:44 -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] 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 I_qCjiissGvL for ; Sun, 5 Oct 2014 19:05:43 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D3931A02D9 for ; Sun, 5 Oct 2014 19:05:43 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 4245C2AB24B; Mon, 6 Oct 2014 02:05:41 +0000 (UTC) Date: Mon, 6 Oct 2014 02:05:41 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141006020540.GP13254@mournblade.imrryr.org> References: <4C36FDC5-12D2-48C1-A3D5-7AA4090E98C8@isoc.org> <20141002233017.GQ13254@mournblade.imrryr.org> <21940.1412298125@sandelman.ca> <20141003021156.GR13254@mournblade.imrryr.org> <5431B1BE.2030008@hexonet.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5431B1BE.2030008@hexonet.net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/Fd3ZPlJ7TWL-rpztvMwWYKRpBsU Subject: Re: [dane] Meeting in Hawaii? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 02:05:44 -0000 On Sun, Oct 05, 2014 at 11:01:50PM +0200, Jens Wagner wrote: > >I don't understand the issues in detail. Perhaps Jens Wagner will > >respond. > > It's a question of the publication infrastructure. > > Right now, PowerDNS is the only (open source) DNS server supporting both > DNSSEC and large zone counts (unlike the typical registry setup, where you > manage a small number of huge zonefiles). Can you shed a bit more light on the ways in which BIND/unbound/... are not entirely suitable to serving a very large dynamic number of zones? What are the main obstacles? Does, for example, BIND take too long to start/reload? Is adding a new zone too disruptive? Something else? -- Viktor. From nobody Mon Oct 6 01:22:43 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F11591A1B6A for ; Mon, 6 Oct 2014 01:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.386 X-Spam-Level: X-Spam-Status: No, score=-0.386 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_RHS_DOB=1.514] 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 kjs3F9ICfVHc for ; Mon, 6 Oct 2014 01:22:40 -0700 (PDT) Received: from internal-mail-out1.ispapi.net (internal-mail-out1.ispapi.net [93.190.234.74]) by ietfa.amsl.com (Postfix) with ESMTP id 991DC1A1B69 for ; Mon, 6 Oct 2014 01:22:40 -0700 (PDT) Received: from internal-mail-relay1.sls.de.hexonet.net (mx.hexonet.net [10.190.234.71]) by internal-mail-out1.ispapi.net (Postfix) with ESMTP id 739BF104012B for ; Mon, 6 Oct 2014 08:22:39 +0000 (UTC) Envelope-to: dane@ietf.org Received: from dslb-188-097-251-024.188.097.pools.vodafone-ip.de ([188.97.251.24]:48999 helo=[192.168.52.112]) by internal-mail-relay1.sls.de.hexonet.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Xb3Z1-00082z-9O for dane@ietf.org; Mon, 06 Oct 2014 08:22:39 +0000 Message-ID: <5432514F.80403@hexonet.net> Date: Mon, 06 Oct 2014 10:22:39 +0200 From: Jens Wagner User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: dane@ietf.org References: <4C36FDC5-12D2-48C1-A3D5-7AA4090E98C8@isoc.org> <20141002233017.GQ13254@mournblade.imrryr.org> <21940.1412298125@sandelman.ca> <20141003021156.GR13254@mournblade.imrryr.org> <5431B1BE.2030008@hexonet.net> <20141006020540.GP13254@mournblade.imrryr.org> In-Reply-To: <20141006020540.GP13254@mournblade.imrryr.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 188.97.251.24 X-SA-Exim-Mail-From: jwagner@hexonet.net Archived-At: http://mailarchive.ietf.org/arch/msg/dane/4V7VTKi7X5b4Uf2BjvZLjfh1yJc Subject: Re: [dane] Meeting in Hawaii? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 08:22:42 -0000 Am 06.10.2014 um 04:05 schrieb Viktor Dukhovni: > On Sun, Oct 05, 2014 at 11:01:50PM +0200, Jens Wagner wrote: > >>> I don't understand the issues in detail. Perhaps Jens Wagner will >>> respond. >> It's a question of the publication infrastructure. >> >> Right now, PowerDNS is the only (open source) DNS server supporting both >> DNSSEC and large zone counts (unlike the typical registry setup, where you >> manage a small number of huge zonefiles). > Can you shed a bit more light on the ways in which BIND/unbound/... > are not entirely suitable to serving a very large dynamic number > of zones? > > What are the main obstacles? Does, for example, BIND take too long > to start/reload? Is adding a new zone too disruptive? Something > else? According to http://unbound.net/ , Unbound is a validating, recursive, and caching DNS resolver. So it cannot be used as an auth nameserver. BIND9 itself takes too long to reload, when e.g. adding new zones, and also needs to load everything into memory. BIND9 + DLZ patches would work (http://bind-dlz.sourceforge.net/), but it has a low performance (iirc, it uses the DB driver for all queries then, and does not use in memory caches). I found some data here: http://www.sanog.org/resources/sanog14/sanog14-devdas-dns-scalability.pdf Basically, we are looking for nameservers, that: 1. allow you to add, remove and update zones online, anytime 2. do not 'stutter' or even stop resolving while getting updated, no matter if single records are updated, or new zones added 3. do not need to keep all zones and records in memory 4. support DNSSEC + NSEC3 5. use internal caching for performance reasons PowerDNS provides all of the above, BIND9+DLZ does everything but 5., MyDNS does everything but 4. (and is outdated). Most servers that are written for TLDs fail at 2. and or 3. Do you know any other products? Still hope for BIND10/Bundy. Best, - jens From nobody Mon Oct 6 06:45:43 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F2201A6F39 for ; Mon, 6 Oct 2014 06:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.386 X-Spam-Level: X-Spam-Status: No, score=-0.386 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_RHS_DOB=1.514] 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 N-Kg5gIYQgU3 for ; Mon, 6 Oct 2014 06:45:40 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FE951A6F83 for ; Mon, 6 Oct 2014 06:45:39 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 08A9A2AAC96; Mon, 6 Oct 2014 13:45:39 +0000 (UTC) Date: Mon, 6 Oct 2014 13:45:38 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141006134538.GT13254@mournblade.imrryr.org> References: <4C36FDC5-12D2-48C1-A3D5-7AA4090E98C8@isoc.org> <20141002233017.GQ13254@mournblade.imrryr.org> <21940.1412298125@sandelman.ca> <20141003021156.GR13254@mournblade.imrryr.org> <5431B1BE.2030008@hexonet.net> <20141006020540.GP13254@mournblade.imrryr.org> <5432514F.80403@hexonet.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5432514F.80403@hexonet.net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/HB3j20Vbqtj4vBLk05VGzgbs528 Subject: Re: [dane] Meeting in Hawaii? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 13:45:42 -0000 On Mon, Oct 06, 2014 at 10:22:39AM +0200, Jens Wagner wrote: > >What are the main obstacles? Does, for example, BIND take too long > >to start/reload? Is adding a new zone too disruptive? Something > >else? > > According to http://unbound.net/ , Unbound is a validating, recursive, and > caching DNS resolver. So it cannot be used as an auth nameserver. Sorry, should have said "nsd". I assume same issues as BIND... > Basically, we are looking for nameservers, that: > > 1. allow you to add, remove and update zones online, anytime > 2. do not 'stutter' or even stop resolving while getting updated, no matter > if single records are updated, or new zones added > 3. do not need to keep all zones and records in memory > 4. support DNSSEC + NSEC3 > 5. use internal caching for performance reasons > > PowerDNS provides all of the above, BIND9+DLZ does everything but 5., MyDNS > does everything but 4. (and is outdated). > Most servers that are written for TLDs fail at 2. and or 3. Do you know any > other products? Still hope for BIND10/Bundy. Thanks, that's roughly the level of detail I was looking for. -- Viktor. From nobody Mon Oct 6 07:01:39 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 169B21A6F92 for ; Mon, 6 Oct 2014 07:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.209 X-Spam-Level: X-Spam-Status: No, score=0.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HOST_MISMATCH_NET=0.311] 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 0TOkVEmHmYfy for ; Mon, 6 Oct 2014 07:01:36 -0700 (PDT) Received: from csgate3.strotmann.de (cstrotm-1-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:f1d::2]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F0251A6F9E for ; Mon, 6 Oct 2014 07:00:56 -0700 (PDT) Received: from csmobile4.home.strotmann.de (unknown [IPv6:2001:5c0:1400:a::839]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by csgate3.strotmann.de (Postfix) with ESMTPSA id 98FF850ED; Mon, 6 Oct 2014 16:00:48 +0200 (CEST) Date: Mon, 6 Oct 2014 16:00:50 +0200 From: Carsten Strotmann To: Jens Wagner Message-ID: <20141006160050.2dc3cd2b@csmobile4.home.strotmann.de> In-Reply-To: <5432514F.80403@hexonet.net> References: <4C36FDC5-12D2-48C1-A3D5-7AA4090E98C8@isoc.org> <20141002233017.GQ13254@mournblade.imrryr.org> <21940.1412298125@sandelman.ca> <20141003021156.GR13254@mournblade.imrryr.org> <5431B1BE.2030008@hexonet.net> <20141006020540.GP13254@mournblade.imrryr.org> <5432514F.80403@hexonet.net> X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.24; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/aZkAIo-3q74cTxCS7UI_5zdrtyc Cc: dane@ietf.org Subject: Re: [dane] Meeting in Hawaii? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 14:01:38 -0000 Hello Jens, Jens Wagner writes: > > Basically, we are looking for nameservers, that: > > 1. allow you to add, remove and update zones online, anytime > 2. do not 'stutter' or even stop resolving while getting updated, no > matter if single records are updated, or new zones added > 3. do not need to keep all zones and records in memory > 4. support DNSSEC + NSEC3 > 5. use internal caching for performance reasons NSD, BIND9 and Knot should all satisfy the above, except for 3. YADIFA might also, but I have no experience with it so far. Is memory really an issue these days? Microsoft WinDNS 2012R2 satisfies all points above, but has other issues (no support for TLSA-RRs). > > PowerDNS provides all of the above, BIND9+DLZ does everything but 5., > MyDNS does everything but 4. (and is outdated). > Most servers that are written for TLDs fail at 2. and or 3. Do you > know any other products? Still hope for BIND10/Bundy. Bundy-DNS would be an alternative satisfying all your requirements, but it might not be "polished" enough in its current state. Bundy-DNS today does not have full-time developers, no sponsor and is moving slow. Please contact me off-list if you (or anyone) is interested to testdrive Bundy-DNS or change the situation for the Bundy-DNS project. -- Carsten Strotmann Email: cas@strotmann.de Blog:strotmann.de From nobody Mon Oct 6 08:00:09 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39CCA1A00B8 for ; Mon, 6 Oct 2014 08:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.787 X-Spam-Level: X-Spam-Status: No, score=-2.787 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.786, 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 FRw7Mqu4H_G0 for ; Mon, 6 Oct 2014 08:00:00 -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 326E61A00C2 for ; Mon, 6 Oct 2014 08:00:00 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 1FAE31E2C1; Mon, 6 Oct 2014 14:59:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1412607599; bh=FgWk6PsGAWhGZRAl+2esjBH6sXuUtymY4kbQK6+ZR/Y=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=m00NeOCr8KHIfT+Uv9z7EFtmzz9qspN3lR6rjlaL02qgtI95PhNeT3NqZtB/TOX1z mqddHUOL3FxviV4EzxHHAQTcs6b9hkvgeC/PRyxer0MZm+RmoOoCMIDJeaK962aKB/ 1sE7rGQrHM//oHrx2ADYZiPmo29yuNiV+TvFTU6c= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 9C08C60023; Mon, 6 Oct 2014 14:59:41 +0000 (UTC) From: James Cloos To: Jens Wagner In-Reply-To: <5431B1BE.2030008@hexonet.net> (Jens Wagner's message of "Sun, 05 Oct 2014 23:01:50 +0200") References: <4C36FDC5-12D2-48C1-A3D5-7AA4090E98C8@isoc.org> <20141002233017.GQ13254@mournblade.imrryr.org> <21940.1412298125@sandelman.ca> <20141003021156.GR13254@mournblade.imrryr.org> <5431B1BE.2030008@hexonet.net> 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: Mon, 06 Oct 2014 10:59:41 -0400 Message-ID: Lines: 15 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:28:141006:jwagner@hexonet.net::bTU3gCMWkdmyGJdp:000000000000000000000000000000000000000004SjP6 X-Hashcash: 1:28:141006:dane@ietf.org::Riv8DM/ToHLXrLWM:00004quI Archived-At: http://mailarchive.ietf.org/arch/msg/dane/Fr401TRL5_4Qh7wCSNcpNA1l2d0 Cc: dane@ietf.org Subject: Re: [dane] Meeting in Hawaii? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 15:00:04 -0000 >>>>> "JW" == Jens Wagner writes: JW> - run DNS using PowerDNS only (works perfectly, but SPOF) I find that using power as a hidden master and nsd as the advertized auths works very well. Nsd is very efficient. And one can use sql replication w/ or w/o heartbeat to have live backups for the hidden master. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Tue Oct 7 05:25:36 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A32441A1BBC for ; Tue, 7 Oct 2014 05:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 Nt0SPzsWw3rz for ; Tue, 7 Oct 2014 05:25:33 -0700 (PDT) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 455C01A1BAA for ; Tue, 7 Oct 2014 05:25:33 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id n3so7690299wiv.9 for ; Tue, 07 Oct 2014 05:25:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=6mLBjxmcAQDOIUikZtxzQ1h0xCO39KSsxk6xokhTI0Y=; b=YqFd0JsaRx1jCMmHAlMN1XiGGK4NO7atySRArs9piOhLEhlh/sNUGQ0vyftFGFajae NHufJcQEBfBGRj/G53/gSvScMa/YoIYdhB3wyAa1U/qi2PPdN/7wnA5kt7iab25uNcAz UOoNXd9tbhR64+tCnrfBNN+mUmMpyofIAvu3XP4IIbzM3CgbIvCnO3g0Ym9ul4ko5ew0 CsIeKttrIxKPYJUK9yQgU240OtLStc/DP+f6M892YTnR/xRa8roB3TEHm9c8hr/2oUH6 MBzwUiWXtxrfRw1GNdwvUbvMNlPEnqRQDq8YBbzmDwjNBG4c0+WNXjcxkfvQK45vn/m8 kdxQ== X-Gm-Message-State: ALoCoQnpDPaU3AsEKfmHmWFzUTuwYZp5DVo88AdkgRC+NQjsZFdjZNQyngWtIDHFu5oE6bU0fkUy MIME-Version: 1.0 X-Received: by 10.180.38.15 with SMTP id c15mr9082297wik.65.1412684731878; Tue, 07 Oct 2014 05:25:31 -0700 (PDT) Received: by 10.194.190.197 with HTTP; Tue, 7 Oct 2014 05:25:31 -0700 (PDT) Date: Tue, 7 Oct 2014 08:25:31 -0400 Message-ID: From: Warren Kumari To: "" Content-Type: multipart/alternative; boundary=e89a8f6433229facda0504d44bd9 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/Udnc92d4ek0r-HbZV-6fp2lzfbc Subject: [dane] Requests for agenda time... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 12:25:34 -0000 --e89a8f6433229facda0504d44bd9 Content-Type: text/plain; charset=UTF-8 Hi all, A reminder to please send us your requests for agenda time for the upcoming meeting. We give priority to documents that have outstanding issues, then those that have gotten a lot of discussion. W -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf --e89a8f6433229facda0504d44bd9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all,

A reminder to please send us your=C2=A0requests for=C2=A0agenda time= for the upcoming meeting.

We give priority to documen= ts that have outstanding issues, then those that have gotten a lot of discu= ssion.

W


--
I don&#= 39;t think the execution is relevant when it was obviously a bad idea in th= e first place.
This is like putting rabid weasels in your pants, and lat= er expressing regret at having chosen those particular rabid weasels and th= at pair of pants.
=C2=A0 =C2=A0---maf
--e89a8f6433229facda0504d44bd9-- From nobody Tue Oct 7 13:59:33 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 835D91A8862 for ; Tue, 7 Oct 2014 13:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.786, 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 jubgTA5lz06s for ; Tue, 7 Oct 2014 13:59:25 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) (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 0F3721A86E2 for ; Tue, 7 Oct 2014 13:59:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:content-type:mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=1gPZFvBstEpWIyLgpq4F8nagjbdm+qu5Lg6jlhctcRE=; b=mqvusxCMNi+EpGihkjrTv7RXh5q8mjaHTiBvApyRro5Gl4EC0tLq07pKofGbgnDOqFTo5J4daO3J/ RZeHrvvvaBKMRBWXevTdxxubOKsnNcSl5x7FQGhnHgAdZjxETqk7TXSrA8bfruu0j2Bhqv7A3I+gJe imgF09iCKkpY3pnI= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Tue, 7 Oct 2014 22:59:06 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Jakob Schlyter In-Reply-To: Date: Tue, 7 Oct 2014 22:59:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <90B9C1BF-9FEB-4E40-849D-CCD7F1DDDABB@kirei.se> References: To: Warren Kumari X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/NV1KCBERg8f1Yw_Pa__POvMMkA4 Cc: "" Subject: Re: [dane] Requests for agenda time... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 20:59:28 -0000 On 7 okt 2014, at 14:25, Warren Kumari wrote: > A reminder to please send us your requests for agenda time for the = upcoming meeting. >=20 > We give priority to documents that have outstanding issues, then those = that have gotten a lot of discussion. I'd like to request at least 30 minutes for the S/MIME issues. jakob From nobody Tue Oct 7 14:30:33 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A8161A879E for ; Tue, 7 Oct 2014 14:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 EAOrwA7AgHYV for ; Tue, 7 Oct 2014 14:30:30 -0700 (PDT) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 928D81A8797 for ; Tue, 7 Oct 2014 14:30:29 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id cc10so9182969wib.7 for ; Tue, 07 Oct 2014 14:30:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qMcsWbBnFcQebjRcEApwAaEwcCzO99ABUEhnmH4TINo=; b=icLusizV512pO53e0NBlqV//0X1r3L1xIAInE9hpVBpBfPL7DXUBeXzlweHnyFXzgr PVIqwrkC7HyI7uk+6AdZBrcSP4sg4UCoriZibvB8LrGA3W5zph94A3zCHjAx/iXM8F8H y+mdFJUmIXFI6fr7F3JorM1leJRpfYpPyrFm11UZAZ8CXnEK0dTxjD5B20x/P+EWN49J JdTqz6amc7630nz25bOSbL4sbv4UE9vJr0vceMH+GFrxgcpl5TvOZdn2re+eHNYzfSfU QmgdOTDQ3hs0kryVsvEWbo4PkjnwmomkonSZrFL8XgblhqKOMFx+XYWRGH2F1G/cpPEx BNUA== X-Gm-Message-State: ALoCoQl3Zh/1CiDheQrlO+GHNBdxNb33IGHNFbChwjV0oG0XPdz+J8sv5tF4rtbYksUH3kjbt1dR MIME-Version: 1.0 X-Received: by 10.194.86.34 with SMTP id m2mr7819498wjz.23.1412717428079; Tue, 07 Oct 2014 14:30:28 -0700 (PDT) Received: by 10.194.190.197 with HTTP; Tue, 7 Oct 2014 14:30:28 -0700 (PDT) In-Reply-To: <90B9C1BF-9FEB-4E40-849D-CCD7F1DDDABB@kirei.se> References: <90B9C1BF-9FEB-4E40-849D-CCD7F1DDDABB@kirei.se> Date: Tue, 7 Oct 2014 17:30:28 -0400 Message-ID: From: Warren Kumari To: Jakob Schlyter Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/8rnc8dKLQNlX-Gs7ezEVLwpc3Ns Cc: "" Subject: Re: [dane] Requests for agenda time... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 21:30:31 -0000 On Tue, Oct 7, 2014 at 4:59 PM, Jakob Schlyter wrote: > On 7 okt 2014, at 14:25, Warren Kumari wrote: > >> A reminder to please send us your requests for agenda time for the upcoming meeting. >> >> We give priority to documents that have outstanding issues, then those that have gotten a lot of discussion. > > I'd like to request at least 30 minutes for the S/MIME issues. > Done! Hey everyone, see how easy that was? W > jakob > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Tue Oct 7 18:45:43 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9782C1A8AEE for ; Tue, 7 Oct 2014 18:45:40 -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 TSQ42D5OE6LI for ; Tue, 7 Oct 2014 18:45:39 -0700 (PDT) Received: from mail-ob0-f176.google.com (mail-ob0-f176.google.com [209.85.214.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E73621A8AE8 for ; Tue, 7 Oct 2014 18:45:38 -0700 (PDT) Received: by mail-ob0-f176.google.com with SMTP id m8so6638439obr.7 for ; Tue, 07 Oct 2014 18:45:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=kisfZRr+sgR1ps+nPIXu0UBhqJErk6ICfW+K1PIXcxQ=; b=R+RXh/v1jPJ8FOJMKCPXWFr1xBsrwJjrv4Xbi3XOCkrvPYTB3wgzOnM8t0sE6qIlEp 6VZPGOd9RVNnmpHJ0mogiy3sc4Ff3k56YS8P4HhTIwmcRy5km6xZxcrL5yOibsvRxkRf UVq/pPhF2joI9TqH3WGlheeiK50FQkiyZtf5KP6K2wwtMLcQFNmkrdYz4YsqpMPbjOp8 yV3M3Rem0jELD0QY4u1tWY8rUxFd/BjdyZeGNoabcgHIlCStJSooU5Kyw6tWEtceY0Jx /MEF2V7Qacbau+DMQ2PbXH+WZioA8tvco55nSy0l7c/nqdXfUAYeCo6qerncjSG7Wdhz +jjg== X-Gm-Message-State: ALoCoQmuRVfJ/D/QE6AAQAVv3D6M1yGnUVdJVWwZZ9/SvtYcC69fwWCEDqNSdT2gxXwNI2aWzNJt X-Received: by 10.182.103.165 with SMTP id fx5mr8625382obb.61.1412732738341; Tue, 07 Oct 2014 18:45:38 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id jo2sm13106819oeb.16.2014.10.07.18.45.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 Oct 2014 18:45:37 -0700 (PDT) Message-ID: <54349740.2060208@andyet.net> Date: Tue, 07 Oct 2014 19:45:36 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dane@ietf.org References: <90B9C1BF-9FEB-4E40-849D-CCD7F1DDDABB@kirei.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/8eZF707LQlY28_gb7_bYmfim1ZI Subject: Re: [dane] Requests for agenda time... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 01:45:40 -0000 On 10/7/14, 3:30 PM, Warren Kumari wrote: > On Tue, Oct 7, 2014 at 4:59 PM, Jakob Schlyter wrote: >> On 7 okt 2014, at 14:25, Warren Kumari wrote: >> >>> A reminder to please send us your requests for agenda time for the upcoming meeting. >>> >>> We give priority to documents that have outstanding issues, then those that have gotten a lot of discussion. >> >> I'd like to request at least 30 minutes for the S/MIME issues. >> > > Done! > > Hey everyone, see how easy that was? Matt Miller and I would like to request 15 minutes for dane-srv (he will be in Hawaii but I can join remotely). We will also submit an updated version before the cutoff date. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Wed Oct 8 07:07:07 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F05B1A1AE8 for ; Wed, 8 Oct 2014 07:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 PKLPblpuzXEo for ; Wed, 8 Oct 2014 07:07:01 -0700 (PDT) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E94BD1A1AE9 for ; Wed, 8 Oct 2014 07:07:00 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id hi2so10672105wib.9 for ; Wed, 08 Oct 2014 07:06:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=o4PiQuKGf/qHnBeQN/dpsjsmbne1ehIInPuVqWmoQJs=; b=EmwEsosoWbpCxDBzXstl4X3pdLGDAtGv0fJF0dH/f8He3g4G8kNj1uW2roFdy0bpCs l+7vjskSfzSVDqbFvbx+ByKksNw9lQhST4OdN4BI1Uo0/fnlqTvkrhBCmKH8cd8xCkeh K7sv6hJ2Y635hFXHpiPMcpn/JiRy/Sy4rZTZ/PJVNVWuWA48ZOXG+M+JAYek9k75U4n4 ZX4yyrMcvHSTnfCKJ4LPb99Mmu41giPcqFfR4IjSM+ofjaIkhVSCPWepHFLd2kKwTW0g O5kV24Bnb9VJvcG1awUU4IdaHnPgC93l8YguO7P8WlppJdCirZzZHKBRejFtSqpufWiS PABw== X-Gm-Message-State: ALoCoQl8CBXx2ihrxgbwpElzqsf/S5EQbgh6qeps4FluN25YUd0WgJnCIrH0Nh9+jqiWhjNaplNN MIME-Version: 1.0 X-Received: by 10.180.86.41 with SMTP id m9mr5734831wiz.65.1412777219495; Wed, 08 Oct 2014 07:06:59 -0700 (PDT) Received: by 10.194.190.197 with HTTP; Wed, 8 Oct 2014 07:06:59 -0700 (PDT) In-Reply-To: <54349740.2060208@andyet.net> References: <90B9C1BF-9FEB-4E40-849D-CCD7F1DDDABB@kirei.se> <54349740.2060208@andyet.net> Date: Wed, 8 Oct 2014 10:06:59 -0400 Message-ID: From: Warren Kumari To: "Peter Saint-Andre - &yet" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/9w0g8eNBbJmzZlXaWYJ3HofvBQU Cc: "" Subject: Re: [dane] Requests for agenda time... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 14:07:06 -0000 On Tue, Oct 7, 2014 at 9:45 PM, Peter Saint-Andre - &yet wrote: > On 10/7/14, 3:30 PM, Warren Kumari wrote: >> >> On Tue, Oct 7, 2014 at 4:59 PM, Jakob Schlyter wrote: >>> >>> On 7 okt 2014, at 14:25, Warren Kumari wrote: >>> >>>> A reminder to please send us your requests for agenda time for the >>>> upcoming meeting. >>>> >>>> We give priority to documents that have outstanding issues, then those >>>> that have gotten a lot of discussion. >>> >>> >>> I'd like to request at least 30 minutes for the S/MIME issues. >>> >> >> Done! >> >> Hey everyone, see how easy that was? > > > Matt Miller and I would like to request 15 minutes for dane-srv (he will be > in Hawaii but I can join remotely). Done! > We will also submit an updated version > before the cutoff date. > Promise? W > Peter > > -- > Peter Saint-Andre > https://andyet.com/ > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Wed Oct 8 07:18:28 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 523FF1A1B1D for ; Wed, 8 Oct 2014 07:18:24 -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 2ShgCjrv8hpA for ; Wed, 8 Oct 2014 07:18:21 -0700 (PDT) Received: from mail-oi0-f46.google.com (mail-oi0-f46.google.com [209.85.218.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 114171A1B1B for ; Wed, 8 Oct 2014 07:18:20 -0700 (PDT) Received: by mail-oi0-f46.google.com with SMTP id h136so7619706oig.5 for ; Wed, 08 Oct 2014 07:18:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=PkS9vbflGK75vzaJge+hn9tLG7mI0ZdV9lUENGcngYM=; b=nAK1V4q5UQAaMdUxA/oI3b82LwVfXwnw8Pt/ue/pin6WAsyYPpN6FjXls5OAmv73Qp CvNnxqwh1ZLEOleWEIqAuso3DaFsl4VsvaZ/DiSri2qk0Ns/J7oSDAEN1SLmuhgn8loY WNEb+p0OQjahd/BKixb6t96Tce8oS4sUxkJ3N+UwiY67vT5Xjj/JV8F70saPd261U2vQ oJdr9JK15lktQ17ULML7eXrzt7yq063E1MxLqQwNNxeKQAHVchYQcXNvE7e8BKalqlwt TpE3FuYIDGGSZqSyyuGnlvK2qWHXU4FGTdYqVwJed/BDk43ieO1XQJiV6jlbKSSYkmrK Smfw== X-Gm-Message-State: ALoCoQnLCjpEIFuDOjRL+zBWcBbyEW/fEOvjeu6bf7AKFcvFJnPg8cU8vbz5qV91BoKdd0gbyVqT X-Received: by 10.60.97.137 with SMTP id ea9mr12496349oeb.12.1412777899353; Wed, 08 Oct 2014 07:18:19 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id c3sm123871obf.14.2014.10.08.07.18.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 Oct 2014 07:18:18 -0700 (PDT) Message-ID: <543547A9.90707@andyet.net> Date: Wed, 08 Oct 2014 08:18:17 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Warren Kumari References: <90B9C1BF-9FEB-4E40-849D-CCD7F1DDDABB@kirei.se> <54349740.2060208@andyet.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/DNURpaYjfHeIMgWmMrvJbp_IXBo Cc: "" Subject: Re: [dane] Requests for agenda time... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 14:18:24 -0000 On 10/8/14, 8:06 AM, Warren Kumari wrote: > On Tue, Oct 7, 2014 at 9:45 PM, Peter Saint-Andre - &yet > wrote: >> On 10/7/14, 3:30 PM, Warren Kumari wrote: >>> >>> On Tue, Oct 7, 2014 at 4:59 PM, Jakob Schlyter wrote: >>>> >>>> On 7 okt 2014, at 14:25, Warren Kumari wrote: >>>> >>>>> A reminder to please send us your requests for agenda time for the >>>>> upcoming meeting. >>>>> >>>>> We give priority to documents that have outstanding issues, then those >>>>> that have gotten a lot of discussion. >>>> >>>> >>>> I'd like to request at least 30 minutes for the S/MIME issues. >>>> >>> >>> Done! >>> >>> Hey everyone, see how easy that was? >> >> >> Matt Miller and I would like to request 15 minutes for dane-srv (he will be >> in Hawaii but I can join remotely). > > Done! > >> We will also submit an updated version >> before the cutoff date. >> > > Promise? Yes, that's a promise! We plan to meet IRL next Friday to iron out some details. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Wed Oct 8 07:19:16 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60FAC1A1B1B for ; Wed, 8 Oct 2014 07:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 NSw53OC08k-z for ; Wed, 8 Oct 2014 07:19:10 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0077.outbound.protection.outlook.com [207.46.100.77]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D8D51A1B16 for ; Wed, 8 Oct 2014 07:19:07 -0700 (PDT) Received: from BLUPR06MB244.namprd06.prod.outlook.com (10.242.191.153) by BLUPR06MB066.namprd06.prod.outlook.com (10.242.187.145) with Microsoft SMTP Server (TLS) id 15.0.1044.10; Wed, 8 Oct 2014 14:19:05 +0000 Received: from BLUPR06MB243.namprd06.prod.outlook.com (10.242.191.154) by BLUPR06MB244.namprd06.prod.outlook.com (10.242.191.153) with Microsoft SMTP Server (TLS) id 15.0.1044.10; Wed, 8 Oct 2014 14:18:59 +0000 Received: from BLUPR06MB243.namprd06.prod.outlook.com ([169.254.7.191]) by BLUPR06MB243.namprd06.prod.outlook.com ([169.254.7.191]) with mapi id 15.00.1044.008; Wed, 8 Oct 2014 14:18:59 +0000 From: Dan York To: Warren Kumari Thread-Topic: [dane] Requests for agenda time... Thread-Index: AQHP4inPVRUBx6+Qtk+wj7OxNzZB9ZwlHsKAgAAIvgCAARnFAA== Date: Wed, 8 Oct 2014 14:18:59 +0000 Message-ID: References: <90B9C1BF-9FEB-4E40-849D-CCD7F1DDDABB@kirei.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [74.75.92.114] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB244;UriScan:; x-forefront-prvs: 0358535363 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(199003)(24454002)(377454003)(53754006)(189002)(106116001)(83716003)(85852003)(101416001)(107046002)(120916001)(105586002)(50986999)(77096002)(99286002)(76176999)(31966008)(15202345003)(85306004)(99396003)(2656002)(19617315012)(66066001)(80022003)(86362001)(92566001)(97736003)(46102003)(95666004)(64706001)(76482002)(87936001)(82746002)(21056001)(4396001)(36756003)(106356001)(16236675004)(110136001)(15395725005)(54356999)(20776003)(19580405001)(33656002)(19580395003)(122556002)(92726001)(40100002)(15975445006)(104396001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB244; H:BLUPR06MB243.namprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:3; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_CAA2A0A40C334CE697FF22297CB5F7C6isocorg_" MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB066; X-OriginatorOrg: isoc.org Archived-At: http://mailarchive.ietf.org/arch/msg/dane/kmInZSu2sX4ljt__AafaSNOICzQ Cc: "" Subject: Re: [dane] Requests for agenda time... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 14:19:13 -0000 --_000_CAA2A0A40C334CE697FF22297CB5F7C6isocorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Warren, On Oct 7, 2014, at 5:30 PM, Warren Kumari > wrote: On Tue, Oct 7, 2014 at 4:59 PM, Jakob Schlyter > wrote: On 7 okt 2014, at 14:25, Warren Kumari > wrote: A reminder to please send us your requests for agenda time for the upcoming= meeting. Hey everyone, see how easy that was? Per the email I sent to the list earlier, I'll go ahead and request some ti= me at the end of the DANE WG session to discuss questions around how we can= further the deployment of DANE and get more people using the documents we'= ve created in this WG. Questions such as (but not limited to): ------- - what roadblocks are people running into with implementing DANE? (outside= of the broader issue of getting DNSSEC validation and signing more widely = available) are there lessons we can feed back into our process of developi= ng DANE-related standards? - are there more "Using DANE with " types of documents that we can or = should create? (and who is willing to do so?) - are there some good examples/case studies of DANE implementations that we= could perhaps capture as informational RFCs? (the Jabber community's impl= ementation comes to mind) - are there places where it would be helpful if there were reference implem= entations of DANE support? For example, DANE for email got a boost when Vi= ktor added it to postfix. Are there other commonly-used open source projec= ts where the addition of DANE support would help move deployment along? - are there test tools that need to be developed? or existing ones that nee= d to be better promoted? are there interop tests we can arrange? ------- I don't have this in the form of an I-D document because they are more open= -ended questions for discussion. (But if you want me to throw it in a quick= I-D for the purpose of having a link on the agenda, I can do so.) I also = don't feel a need to lead this discussion and would be glad to defer to you= and/or Olafur if you would prefer to do so. Dan -- Dan York Senior Content Strategist, Internet Society york@isoc.org +1-802-735-1624 Jabber: york@jabber.isoc.org Skype: danyork http://twitter.com/danyork http://www.internetsociety.org/deploy360/ --_000_CAA2A0A40C334CE697FF22297CB5F7C6isocorg_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Warren,

On Oct 7, 2014, at 5:30 PM, Warren Kumari <warren@kumari.net> wrote:

On Tue, Oct 7, 2014 at 4:59 PM, Jakob Schlyter &l= t;jakob@kirei.se> wrote:
On 7 okt 2014, at 14:25, Warren Kumari <warren@kumari.net> wrote:

A reminder to please send us your requests for ag= enda time for the upcoming meeting.

Hey everyone, see how easy that was?

Per the email I sent to the list earlier, I'll go ahead and request so= me time at the end of the DANE WG session to discuss questions around how w= e can further the deployment of DANE and get more people using the document= s we've created in this WG.  Questions such as (but not limited to):
-------
- what roadblocks are people running into with implementing DANE? &nbs= p;(outside of the broader issue of getting DNSSEC validation and signing mo= re widely available)  are there lessons we can feed back into our proc= ess of developing DANE-related standards?

- are there more "Using DANE with <foo>" types of docu= ments that we can or should create? (and who is willing to do so?)

- are there some good examples/case studies of DANE implementations th= at we could perhaps capture as informational RFCs?  (the Jabber commun= ity's implementation comes to mind)

- are there places where it would be helpful if there were reference i= mplementations of DANE support?  For example, DANE for email got a boo= st when Viktor added it to postfix.  Are there other commonly-used ope= n source projects where the addition of DANE support would help move deployment along?  

- are there test tools that need to be developed? or existing ones tha= t need to be better promoted?  are there interop tests we can arrange?=
-------

I don't have this in the form of an I-D document because they are more= open-ended questions for discussion. (But if you want me to throw it in a = quick I-D for the purpose of having a link on the agenda, I can do so.) &nb= sp;I also don't feel a need to lead this discussion and would be glad to defer to you and/or Olafur if you would pr= efer to do so.

Dan

--
Dan York
Senior Content Strategist, Internet Socie= ty
york@iso= c.org   +1-802-735-1624
Skype: danyork   http://twitter.com/danyork

--_000_CAA2A0A40C334CE697FF22297CB5F7C6isocorg_-- From shmick@riseup.net Thu Oct 9 08:37:00 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB2BF1A6F0E for ; Thu, 9 Oct 2014 08:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.787 X-Spam-Level: X-Spam-Status: No, score=-2.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 bsJdvzoThcDf for ; Thu, 9 Oct 2014 08:36:59 -0700 (PDT) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (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 90F901A1B61 for ; Thu, 9 Oct 2014 08:36:53 -0700 (PDT) Received: from plantcutter.riseup.net (plantcutter-pn.riseup.net [10.0.1.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "Gandi Standard SSL CA" (not verified)) by mx1.riseup.net (Postfix) with ESMTPS id 813964584A for ; Thu, 9 Oct 2014 08:36:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1412869010; bh=ujsexggoIRGQl8kYQagc8MRWIN21R5lHexER/Qs0e5c=; h=Date:From:To:Subject:From; b=CWLbZh/pGyyEe6Df5MQNRGwZitNI8DiqdKLydoKW7hH7y20rRL9NOfvRXZky5p9n8 6AE2FT00+p6iLTaxpbjwQwee/g7YYyjIWk/ezurHE8NLWRc//5Sjy6c45rVR4hANPJ fRJUqyFaz9zAwQ5tAQFz2/A3oV1yYBPy5eCm0mgQ= Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: shmick) with ESMTPSA id CC71620196 Message-ID: <5436AB8A.2090202@riseup.net> Date: Fri, 10 Oct 2014 02:36:42 +1100 From: "shmick@riseup.net" MIME-Version: 1.0 To: dane@ietf.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.98.4 at mx1 X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/dane/6yI-r1wK2r6S9bEoMJj6Q4Z373I Subject: [dane] dual use of TLSA RR X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 15:46:55 -0000 is it possible & legal to incorporate 2 TLSA RRs in a zone file the following way for the same protocol/port ie. 25: assume postfix has setup 2 certs; an RSA and ECDSA if it's possible how would a particular TLSA RR be chosen ? is it based upon negotiated cipher ? From nobody Thu Oct 9 09:27:57 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1731A8547 for ; Thu, 9 Oct 2014 09:27:56 -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] 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 KH20EatfYEVu for ; Thu, 9 Oct 2014 09:27:54 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D8C21A6F86 for ; Thu, 9 Oct 2014 09:27:54 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 8F44D2AAC8A; Thu, 9 Oct 2014 16:27:52 +0000 (UTC) Date: Thu, 9 Oct 2014 16:27:52 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141009162752.GS13254@mournblade.imrryr.org> References: <5436AB8A.2090202@riseup.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5436AB8A.2090202@riseup.net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/RLrwRreFOLatDjDeder17DCQEr8 Subject: Re: [dane] dual use of TLSA RR X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 16:27:56 -0000 On Fri, Oct 10, 2014 at 02:36:42AM +1100, shmick@riseup.net wrote: > is it possible & legal to incorporate 2 TLSA RRs in a zone file the > following way for the same protocol/port ie. 25: Yes, absolutely. Multiple TLSA RRs can and will appear in a TLSA RRset, either as a result of key rotation in progress, or because there are multiple keys valid at the same time. > Assume postfix has setup 2 certs; an RSA and ECDSA > > If it's possible how would a particular TLSA RR be chosen? Each TLSA RRs is compared against the server's chain until one matches. > Is it based upon negotiated cipher? No, generally the TLSA RR does not signal a particular public key algorithm. With matching type Full(0) one could infer the algorithm from public key, but in practice it is easier to just compare the bits regardless. -- Viktor. From nobody Fri Oct 10 08:19:54 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 937B01A1A0A for ; Fri, 10 Oct 2014 08:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.387 X-Spam-Level: X-Spam-Status: No, score=-1.387 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 UZQnd60G6re2 for ; Fri, 10 Oct 2014 08:19:50 -0700 (PDT) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (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 D309B1A0383 for ; Fri, 10 Oct 2014 08:19:49 -0700 (PDT) Received: from berryeater.riseup.net (berryeater-pn.riseup.net [10.0.1.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "Gandi Standard SSL CA" (not verified)) by mx1.riseup.net (Postfix) with ESMTPS id 868025437B for ; Fri, 10 Oct 2014 08:19:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1412954389; bh=nBG1qkBSv4Hxo0j5N2HwbglQ7BLXKU6dat3L19BLVg8=; h=Date:From:To:Subject:References:In-Reply-To:From; b=EcmcCezHzb5AdxZ/4+MOPBPCV5ABwlIBJjdY15ZDDJ15HCCIkAN9wf3pRISw8mRMW u9oxB9+VzMBdA7Cvy/Su2/wK1ALkrjHdihY7uIpxx1wZ3e6dVth8p1Cjh1cULljwQb Qv853Gq4z+hZUnHDbpYw4G4XFDf0D8n4oZ8Q73g8= Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: shmick) with ESMTPSA id 3106F42C72 Message-ID: <5437F908.4050000@riseup.net> Date: Sat, 11 Oct 2014 02:19:36 +1100 From: "shmick@riseup.net" MIME-Version: 1.0 To: dane@ietf.org References: <5436AB8A.2090202@riseup.net> <20141009162752.GS13254@mournblade.imrryr.org> In-Reply-To: <20141009162752.GS13254@mournblade.imrryr.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.98.4 at mx1 X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/dane/w2IHsNQIdjTOjNc3ykl1ecmCxcM Subject: Re: [dane] dual use of TLSA RR X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 15:19:52 -0000 thanks, Viktor Dukhovni wrote: > On Fri, Oct 10, 2014 at 02:36:42AM +1100, shmick@riseup.net wrote: > >> is it possible & legal to incorporate 2 TLSA RRs in a zone file the >> following way for the same protocol/port ie. 25: > > Yes, absolutely. Multiple TLSA RRs can and will appear in a TLSA > RRset, either as a result of key rotation in progress, or because > there are multiple keys valid at the same time. i signed my zonefile ok and have the following: _25._tcp.ns1.example.net. IN CNAME tlsa311._dane.example.net. tlsa311._dane.example.net. IN TLSA 3 1 1 4e02a17b48f8dd3fb451871222278d248c3f51ea5f25ec2e06f65096c80391b0 ; ECC tlsa311._dane.example.net. IN TLSA 3 1 1 9ff5a335ddb86c368a9b3fc49d1a81f738d57f8f8f96c973e87513bbf24532c3 ; RSA im waiting for confirmation from somebody that they see "Verified TLS conn..." > >> Assume postfix has setup 2 certs; an RSA and ECDSA >> >> If it's possible how would a particular TLSA RR be chosen? > > Each TLSA RRs is compared against the server's chain until one > matches. > >> Is it based upon negotiated cipher? > > No, generally the TLSA RR does not signal a particular public key > algorithm. With matching type Full(0) one could infer the algorithm > from public key, but in practice it is easier to just compare the > bits regardless. > From nobody Fri Oct 10 08:27:54 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32D1D1A1A1D for ; Fri, 10 Oct 2014 08:27:53 -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] 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 pE3obv1IWpqq for ; Fri, 10 Oct 2014 08:27:51 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB60D1A1A3F for ; Fri, 10 Oct 2014 08:27:51 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id B10272AB2A7; Fri, 10 Oct 2014 15:27:50 +0000 (UTC) Date: Fri, 10 Oct 2014 15:27:50 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141010152750.GY13254@mournblade.imrryr.org> References: <5436AB8A.2090202@riseup.net> <20141009162752.GS13254@mournblade.imrryr.org> <5437F908.4050000@riseup.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5437F908.4050000@riseup.net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/u1wWA18c3XZ1k9oKSFiovJHJ91s Subject: Re: [dane] dual use of TLSA RR X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: some-other-list@example.net List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 15:27:53 -0000 On Sat, Oct 11, 2014 at 02:19:36AM +1100, shmick@riseup.net wrote: > i signed my zonefile ok and have the following: > > _25._tcp.ns1.example.net. IN CNAME tlsa311._dane.example.net. > > tlsa311._dane.example.net. IN TLSA 3 1 1 > 4e02a17b48f8dd3fb451871222278d248c3f51ea5f25ec2e06f65096c80391b0 ; ECC > > tlsa311._dane.example.net. IN TLSA 3 1 1 > 9ff5a335ddb86c368a9b3fc49d1a81f738d57f8f8f96c973e87513bbf24532c3 ; RSA Note this thread is no longer on topic for DANE WG discussion (if it ever was). This is an IEF working group, not a help forum. You can ask routine operational questions on postfix-users or a DNS users list (if there is one). > im waiting for confirmation from somebody that they see "Verified TLS > conn..." Rather unlikely, with the domain name obfuscated as example.net. -- Viktor. From nobody Fri Oct 10 11:04:29 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED1AE1A90B3 for ; Fri, 10 Oct 2014 11:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Vts6fOg2cEq1 for ; Fri, 10 Oct 2014 11:04:25 -0700 (PDT) Received: from exprod6og109.obsmtp.com (exprod6og109.obsmtp.com [64.18.1.23]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A489E1A006B for ; Fri, 10 Oct 2014 11:04:23 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob109.postini.com ([64.18.5.12]) with SMTP ID DSNKVDgfp89vXtPrrlgDO8WymWQ0owahUedA@postini.com; Fri, 10 Oct 2014 11:04:24 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id s9AI4MWp022382 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 10 Oct 2014 14:04:22 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Fri, 10 Oct 2014 14:04:22 -0400 From: "Osterweil, Eric" To: Warren Kumari Thread-Topic: [dane] Requests for agenda time... Thread-Index: AQHP4inQVanNG7AtVUm3v+kE+QAu45wp5/aA Date: Fri, 10 Oct 2014 18:04:21 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/signed; boundary="Apple-Mail=_BC13242B-E125-4D65-A457-B96D167EB668"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/Qbn1IUIZ2KFQH7OeOBkAge5qggM Cc: "" Subject: Re: [dane] Requests for agenda time... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 18:04:27 -0000 --Apple-Mail=_BC13242B-E125-4D65-A457-B96D167EB668 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I=92d like to request some time to do a very quick preso about our = DANE+S/MIME prototype. Eric On Oct 7, 2014, at 8:25 AM, Warren Kumari wrote: > Hi all, >=20 > A reminder to please send us your requests for agenda time for the = upcoming meeting. >=20 > We give priority to documents that have outstanding issues, then those = that have gotten a lot of discussion. >=20 > W >=20 >=20 > --=20 > I don't think the execution is relevant when it was obviously a bad = idea in the first place. > This is like putting rabid weasels in your pants, and later expressing = regret at having chosen those particular rabid weasels and that pair of = pants. > ---maf > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane --Apple-Mail=_BC13242B-E125-4D65-A457-B96D167EB668 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN7DCCBmAw ggVIoAMCAQICEHaFyweo4MwP0sVNjzk1sxIwDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ug b25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDYwNzAwMDAwMFoXDTIxMDYwNjIzNTk1OVowgckxCzAJ BgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50 ZWMgVHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVk aWF0ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQC3+D8MK4MjIIWmTUkBUTra3VAzvuMEpDo+o2FmTDTC6HRwdUmlt0ns3bOSnN15DeK5+rg5PL6F 44zvbXmjprcIv5xMvj6YjqzbfJor7AUoMF8pGzNNRNVw6FYimaY+nUJb6yOnY50tLLAuPxjzKc0a NomEksdXcFtwheY4oXxQ4zc4iGVba8s5KgSxgqoZBP+gfz+j25FFdmaja/OFI15O2YVddaegFffB AHTg5cqUQmWawjd6i6hQrL+XdGd30TKnr43Lk6klQrQwGnQK4iUQEMt0Z1UPyxT8QVAKpHxNCwv5 Bak1+UWnMfGAu6LJPs52OeEq/3ZQ5+hRIt8tz7gzAgMBAAGjggI/MIICOzASBgNVHRMBAf8ECDAG AQH/AgEAMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzMu Y3JsMA4GA1UdDwEB/wQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRVmVyaVNpZ25NUEtJ LTItNTYwHQYDVR0OBBYEFNhIKahfKheS4vqee+9vYIP4uLjcMIHwBgNVHSMEgegwgeWhgdCkgc0w gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczghBhcMtJjF+YRSnnsKbZUFt6MDQGCCsG AQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AudmVyaXNpZ24uY29tMGwGA1UdIARl MGMwYQYLYIZIAYb4RQEHFwIwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9j cHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwDQYJKoZIhvcNAQEF BQADggEBAKYqmwdAyez/s4joRdo00RcPKC23pYVnMc3B5tUphjis4vBZGwzhoUXOJHjvacGwTGGi SNloT7r+dVQ3ulhp6sF2pTZC6p5meJAg2ZVqJHlUzd5aGoo7rhiVctAl2NJGvjQwp4Ce8VbOIB5s Z8lNT3mHieIugNae7SZhZaID0MXi8yi5K0lpgmfs1ek0pC7cYiKkhU1I42oClPLN/eRnyEm8qtXH 5zzeh7EQa10HXBnka6D0T5nL3LVbDMwy+WrkdMAqWDd5s/vNwzRv4XbdEAcAY4sHTicXkkebDr7e DROFEfyiL2V9zDqsHlRrVmfE7qWHIiMXK3BWw/Gud1wnwTkwggeEMIIGbKADAgECAhBcCMgDVFpl hwRR0TZyMUgoMA0GCSqGSIb3DQEBBQUAMIHJMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50 ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxNTAzBgNVBAsT LENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMUMwQQYDVQQDEzpT eW1hbnRlYyBDbGFzcyAyIFNoYXJlZCBJbnRlcm1lZGlhdGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5 MB4XDTE0MDQxMDAwMDAwMFoXDTE1MDQxMDIzNTk1OVowczEmMCQGCSqGSIb3DQEJARYXZW9zdGVy d2VpbEB2ZXJpc2lnbi5jb20xGDAWBgNVBAMMD09zdGVyd2VpbCwgRXJpYzEWMBQGA1UECwwNRU5U RVJQUklTRSBJVDEXMBUGA1UECgwOVmVyaVNpZ24sIEluYy4wggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCmK2/yLaprGu39usXztz6N7uLYDoKN4MNaDFGGj1eYfMkIfb6LDoYBs9qcnINg 8in4NxGwVQGIJU5AE/1wHe/V1qavpHEO2mVxRq94cBF0P8ETPpM1yhwBhU4QKhjNEDj9wov8RXzO hjqPy/uknZvBxfobQx22vhnEKpf7QEN0zfLDJON3tyYwsnrFZkmop4ni4ANI7ev5uqcI05ED7vSh K9AHAVjzjr2QvtmvqHAkOnpHgqkWJWhuw4f9Gx+8LmbC3tl8oxF7+E7WEwKTQG56BV0uR6PN/o0S O7VSbDCZyNoxxrjzw+CesWsigi2NvC5DnhkKlxP+JSfJxMDu+7MDAgMBAAGjggO7MIIDtzAMBgNV HRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIFoDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDBDAdBgNVHQ4E FgQUVoVKaC1xEPB9EWKq3dWrwskIufkwUAYDVR0RBEkwR4EXZW9zdGVyd2VpbEB2ZXJpc2lnbi5j b22gLAYKKwYBBAGCNxQCA6AeDBxlb3N0ZXJ3ZWlsQHZjb3JwLmFkLnZyc24uY29tMB8GA1UdIwQY MBaAFNhIKahfKheS4vqee+9vYIP4uLjcMIIBcQYIKwYBBQUHAQEEggFjMIIBXzAnBggrBgEFBQcw AYYbaHR0cDovL3BraS1vY3NwLnN5bWF1dGguY29tMIIBMgYIKwYBBQUHMAKGggEkbGRhcDovL2Rp cmVjdG9yeS52ZXJpc2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMiUyMFNo YXJlZCUyMEludGVybWVkaWF0ZSUyMENlcnRpZmljYXRlJTIwQXV0aG9yaXR5JTJDT1UlMjAlM0Ql MjBDbGFzcyUyMDIlMjBNYW5hZ2VkJTIwUEtJJTIwSW5kaXZpZHVhbCUyMFN1YnNjcmliZXIlMjBD QSUyQ09VJTIwJTNEJTIwU3ltYW50ZWMlMjBUcnVzdCUyME5ldHdvcmslMkNPJTIwJTNEJTIwU3lt YW50ZWMlMjBDb3Jwb3JhdGlvbiUyQ0MlMjAlM0QlMjBVUz9jQUNlcnRpZmljYXRlO2JpbmFyeTBd BgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vcGtpLWNybC5zeW1hdXRoLmNvbS9jYV8wN2JiN2Q2NDc3 Y2Y0ZjZiZTk2YWYxYjM2Y2FiZDMxNi9MYXRlc3RDUkwuY3JsMGwGA1UdIARlMGMwYQYLYIZIAYb4 RQEHFwIwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9jcHMwKAYIKwYBBQUH AgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwQgYJKoZIhvcNAQkPBDUwMzAKBggqhkiG 9w0DBzALBglghkgBZQMEAQIwCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBKjAsBgpghkgBhvhFARAD BB4wHAYSYIZIAYb4RQEQAQICAQGL8cYJFgYyNDc2NjQwOQYKYIZIAYb4RQEQBQQrMCkCAQAWJGFI UjBjSE02THk5d2Eya3RjbUV1YzNsdFlYVjBhQzVqYjIwPTANBgkqhkiG9w0BAQUFAAOCAQEAXFTS ZEP9la6QYPlo6ybMEEpxVOADx082WRGtrYoU9ZEaC2IlxmwI9JprNfBlIy8FtyJAuWKBbe9/XKJF cukb2HNS0httHUIcSTfMEsAyc99/ba/SoMlhtvko/nCvx5brzhpQwop6AgMv9v5V7F1GUFO7db8L LSs1gIZYI8IeudznJOQGUBFGe0aJhA4cD/3OIZyItWpNtn94i1GJUFPMjYhGcy/r0fUQY/KFLwOi M6bT/m1RwAJKJI/mON/OshdzylAYqKOPoFTJD4qrbrpij1r1+e1VHKklAxTd+nOg9J1L0yRwlEDS 1boeOxqNXGnEYAa54k0ZWPh+8dFemteaLjGCBE0wggRJAgEBMIHeMIHJMQswCQYDVQQGEwJVUzEd MBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5l dHdvcmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBMUMwQQYDVQQDEzpTeW1hbnRlYyBDbGFzcyAyIFNoYXJlZCBJbnRlcm1lZGlhdGUgQ2VydGlm aWNhdGUgQXV0aG9yaXR5AhBcCMgDVFplhwRR0TZyMUgoMAkGBSsOAwIaBQCgggJDMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MTAxMDE4MDQyMVowIwYJKoZIhvcN AQkEMRYEFM2SI1e2XKx9uc9nWVzDqW4CGCspMIHvBgkrBgEEAYI3EAQxgeEwgd4wgckxCzAJBgNV BAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMg VHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1 YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVkaWF0 ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCEFwIyANUWmWHBFHRNnIxSCgwgfEGCyqGSIb3DQEJEAIL MYHhoIHeMIHJMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAd BgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQ S0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMUMwQQYDVQQDEzpTeW1hbnRlYyBDbGFzcyAyIFNo YXJlZCBJbnRlcm1lZGlhdGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5AhBcCMgDVFplhwRR0TZyMUgo MA0GCSqGSIb3DQEBAQUABIIBAJa0NQh0a2u7wWgWLBXo3SPXfsrT6jp8I3GMFcrQDNBT2n8GXuem v/TsS1zWNl4pFBoTABV+PF93FMaVAhiKdUIBNgQAQSuD5VMh07o+hfCHyNB2lSd7SylZ7/HZZBbC wkz7XlhAQElEnzgIruXrDyHiSus+wWHzNatoFgukRa/glJx+OlbJu/2aoVxp8ZudNv7TsjLmwi/P PGyXkoVMfNG2vKfudizJVc8HfeLMLUmAjaiD415/wIn1i8Gr4Du58TXSuy97cXhSFfum49fqn7TB IgaHGUrWmlHbcW+blz4zCeJoN6jserm50dsyO3syrBVlfQnN4QgrrNrAczgZD7UAAAAAAAA= --Apple-Mail=_BC13242B-E125-4D65-A457-B96D167EB668-- From nobody Sat Oct 11 12:21:51 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 295911A875A for ; Sat, 11 Oct 2014 12:21:51 -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 v-K1V3VnX4lL for ; Sat, 11 Oct 2014 12:21:49 -0700 (PDT) Received: from smtp124.ord1c.emailsrvr.com (smtp124.ord1c.emailsrvr.com [108.166.43.124]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC8411A8759 for ; Sat, 11 Oct 2014 12:21:48 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp8.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 260CF805A2 for ; Sat, 11 Oct 2014 15:21:48 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp8.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id BCE788059C for ; Sat, 11 Oct 2014 15:21:46 -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:465 (trex/5.2.13); Sat, 11 Oct 2014 19:21:48 GMT From: Olafur Gudmundsson Content-Type: multipart/alternative; boundary="Apple-Mail=_03B8E1B9-F999-45D8-8FE7-2DB1A145583B" Date: Sat, 11 Oct 2014 15:21:45 -0400 References: <20141010224612.18122.99758.idtracker@ietfa.amsl.com> To: "dane@ietf.org list" 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/dane/6WUmkM1OSfLTs-3psbDl_CKvp78 Subject: [dane] Fwd: IETF 91 Preliminary Agenda X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2014 19:21:51 -0000 --Apple-Mail=_03B8E1B9-F999-45D8-8FE7-2DB1A145583B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 The =93semi-final=94 agenda has been posted=20 we currently have 2 hour slot at 13:00 on Wed.=20 Olafur Begin forwarded message: > From: IETF Agenda > Subject: IETF 91 Preliminary Agenda > Date: October 10, 2014 at 6:46:12 PM EDT > To: IETF Announcement List > Cc: ietf@ietf.org > Reply-To: ietf@ietf.org, IETF Agenda >=20 >=20 > The IETF 91 Preliminary Agenda has been posted. The final agenda will = be published on Friday, October 17th, 2014.=20 >=20 > https://datatracker.ietf.org/meeting/91/agenda.html=20 > https://datatracker.ietf.org/meeting/91/agenda.txt=20 >=20 > More information regarding IETF 91 in Honolulu, Hawaii is located = here: https://www.ietf.org/meeting/91/index.html >=20 > Thank you!=20 >=20 > IETF Secretariat >=20 --Apple-Mail=_03B8E1B9-F999-45D8-8FE7-2DB1A145583B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

The =93semi-final=94 agenda has been = posted 
we currently have 2 hour slot at 13:00 on = Wed. 

= Olafur


Begin forwarded = message:

From: = IETF Agenda <agenda@ietf.org>
Subject: IETF 91 Preliminary = Agenda
Date: = October 10, 2014 at = 6:46:12 PM EDT
To: = IETF Announcement = List <ietf-announce@ietf.org>
<= /span>
Reply-To: ietf@ietf.org, IETF Agenda <agenda@ietf.org>

The IETF 91 Preliminary Agenda has been posted. The final = agenda will be published on Friday, October 17th, 2014.

https://datat= racker.ietf.org/meeting/91/agenda.html
https://datatr= acker.ietf.org/meeting/91/agenda.txt

More information = regarding IETF 91 in Honolulu, Hawaii is located here: https://www.ietf.org/m= eeting/91/index.html

Thank you!

IETF = Secretariat


= --Apple-Mail=_03B8E1B9-F999-45D8-8FE7-2DB1A145583B-- From nobody Wed Oct 15 22:47:04 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E505C1A6F0A for ; Wed, 15 Oct 2014 22:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.134 X-Spam-Level: * X-Spam-Status: No, score=1.134 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, LOTS_OF_MONEY=0.001, 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 rTviqyLA7uHS for ; Wed, 15 Oct 2014 22:47:00 -0700 (PDT) Received: from gateway15.websitewelcome.com (gateway15.websitewelcome.com [69.93.154.23]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F7411A026E for ; Wed, 15 Oct 2014 22:47:00 -0700 (PDT) Received: by gateway15.websitewelcome.com (Postfix, from userid 5007) id A8B58A9123EF1; Thu, 16 Oct 2014 00:46:59 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway15.websitewelcome.com (Postfix) with ESMTP id 8730BA9123EC9 for ; Thu, 16 Oct 2014 00:46:59 -0500 (CDT) Received: from [173.73.121.234] (port=50645 helo=[192.168.1.7]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Xedtq-0000Pj-MH; Thu, 16 Oct 2014 00:46:59 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: Date: Thu, 16 Oct 2014 01:46:55 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <67BDE5B6-58C7-4E0B-8CB4-045E51027D85@ieca.com> References: <273F9612-13AF-4CB8-B15C-912AAD04C738@verisign.com> To: "" , draft-ietf-dane-smime@tools.ietf.org X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 173.73.121.234 X-Exim-ID: 1Xedtq-0000Pj-MH X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.7]) [173.73.121.234]:50645 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/dane/Wk5jk_jFlbVTqBQhq3AjJw0_Aso Subject: Re: [dane] draft-ietf-dane-smime X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 05:47:03 -0000 Apologies for coming to this late and for this being so long. On Sep 30, 2014, at 16:53, Paul Hoffman wrote: > On Sep 29, 2014, at 5:26 AM, Osterweil, Eric = wrote: >=20 > When these ideas were brought to the WG earlier this year, we didn't = hear any significant support. Given that both of us feel that the = proposed changes make the document harder to implement, we would want to = see much wider support before we adopt them. >=20 > --Paul Hoffman and Jakob Schlyter I guess we know where the authors stand on making the changes ;) Anyway, put me in the camp that wants to continue the discussion about = the possibility of making changes to support the proposed changes to the = SMIMEA spec. WRT: > 1) This usage type is at least as applicable to TLS as it is to = S/MIME. We haven't seen anything indicating much use of certificate = revocation anywhere and, where we have seen it, it is much more common = in TLS. If the authors really want this feature, it should be an update = to TLSA, which SMIMEA could then adopt. >=20 > 2) Making the record format for SMIMEA different than that of TLSA for = this feature seems like a bad idea. Alternate discovery mechanisms might = be important, but they will be just as important for TLS as they are for = S/MIME. The functionality that the authors want could be added to TLSA = by adding new Matching Type fields such as "Hash and NAPTR", "Hash and = URI", and so on. The latter is part of IKEv2 (although the feature is = generally considered not useful). If the authors really want this = feature, it should be an update to TLSA, which SMIMEA could then adopt. Two parts: 1) Comparing the use of revocation of TLS certificates to S/MIME = certificates is an interesting way to start because what you say is = obviously true; TLS is so much more widely deployed compared to S/MIME = (everybody uses TLS - enterprises and some nerds use S/MIME) so of = course you=92re going to see it much more in/for TLS. I=92d love to = know the split between TLS versus S/MIME certificates issued by big box = CAs and how often the associated CRLs get checked but I=92m sure that=92s = proprietary (please somebody prove me wrong). 2) I want to push back on the statement above about changing TLSA first = and this bit that followed later in the thread: On Oct 02, 2014, at 18:12, Paul Hoffman wrote: > On Oct 2, 2014, at 1:56 PM, Doug Montgomery = wrote: >=20 >> Overly coupling the use cases and requirements between these uses = seems to be a red herring to me. Maybe we should turn the question = around and ask for an explanation why the use cases for TLS should = impact the requirements for SMIMEA? >=20 > Or, based on what Jakob and I suggested, why shouldn't features that = are needed for either use case be shared? The idea that the proponents of these changes need to go change the TLSA = spec because you think it applies to both seems a little bit excessive. = If you think the changes apply to both, then great feel free to go and = propose those changes get made in the TLSA spec; I see no reason to = burden the proponents of these changes with that job. WRT rarity: On Oct 02, 2014, at 18:12, Paul Hoffman wrote: > On Oct 2, 2014, at 1:56 PM, Doug Montgomery = wrote: >=20 >> As far as I know we have never revoked our TLS cert ...=20 >=20 > Right: TLS certs are rarely revoked. This can be seen by looking at = the CRLs from major CAs. However, looking in those same CRLs shows = nearly no S/MIME certs revoked either. There might be other reasons to dismiss usage #4 (reject) but we = shouldn't do so based on your assertion that there=92s no revocation of = TLS or S/MIME certs because I believe revocation happens more than = rarely. Rarely to me means I=92d have a really hard time finding some = revoked certs. I took the bait and went and looked at some CRLs (my hastily gathered = small sample is later) - was this your ploy all along? If not, I=92d be = curious to know what you=92re looking at to motivate your statement. = What I=92m looking at seems to indicate that TLS certificate revocation = happens certainly more than on rare occasions. I also got my hands on = some CRLs with S/MIME certificates on =91em that also seem to indicate = it=92s also not so rare to revoke S/MIME/ID certificates (also later). Note: This might be stating the obvious but looking at the exact same = CRLs might not give you what you=92re looking for in terms of finding = revoked TLS and S/MIME certificates: 1) the CA has to put all the = revoked certificates on the same CRL and they don=92t always do that in = fact it looks like many don't that based on the CRL=92s issuer name; CRL = issuer names include =93EV=94, =93SSL=94, etc. for TLS-only CRLs and = =93Individual=94, =93Personal=94, etc. for S/MIME-only certificates, 2) = some of the big box CAs only do TLS certificates so of course you=92re = not going to see any S/MIME certificates on the CRL, and 3) you can=92t = tell by looking at CRL entry what the certificate=92s KU or EKU is = because the entries only contain the serial number, revocation date, and = maybe if you=92re lucky a revocation reason (you might be able to infer = from the reason code but you kinda gotta guess what=92s on the CRL based = on the name of the CRL issuer or if you dig a little farther based on = the certificate=92s CP/CPS - I mostly assumed based on the CRL issuer = name). Before the data first a couple of disclaimers: - I don=92t name names for obvious reasons. - The CRLs are all from public facing TLS servers. So all of this in = some fashion or another is reproducible. - I made sure to not use duplicate CRLs from the same provider by = looking at the AKI if present and issuer name if not. - To find the CRLs, it wasn=92t as easy as following some links to the = CA=92s repo and downloading them; it is that easy for root and = intermediate CA certificates but not for CRLs and not for EE = certificates. Maybe I=92m doing it wrong =85 anyway, to get them I had = to go to https enabled websites, click on the browser bar, inspect the = certificate, scroll to the CRLDP extension, ctrl-c/v the URI to the CRL = into firefox, then use dumpasn1 (still works like a champ) on the = downloaded CRL to look at the number of entries. I then went to the SEQ = after the thisUpdate/nextUpdate lines, divided the number next to the = SEQ by what seemed to be the average size of each entry, and got an = approximate # of entries on the CRL. See [1] for some interesting = observations. Also, if you=92re looking at the CRL=92s pointed to in = those CA certificates you can find in the repo you=92re looking at the = wrong CRL - the CRLs pointed to from CA certificates are ARLs disguised = as CRLs. - Other folks were more high tech and ran scripts that looked at a lot = more CRLs than my manual method. I included their results after my = plodding results. And, now for some data on CRLs for TLS certificates: - Started with search engines: two of =91em run their own CAs so it=92s = unsurprising they contain few entries (8 & ~50) and another uses a = managed service and that CRL has well more =85 like ~51K. The CRL with = ~51K entries includes entries back to 2010 and according to the = description of the Root CA only TLS certificates are issued by CA = subordinates to it so all of those ~51K are TLS certificates. I went to = another one - they don=92t offer https:// :( - A non-US news organization: there=92s ~400 entries covering just this = year. - A non-US bank: ~5.2K entries with three years worth of revoked = certificates (no reason codes). I went to another on a different = continent and found the same CRL so new data. I went to a third (on the = same continent as the 1st) and got a CA from what I wouldn=92t consider = one of the typical US big box CAs and found a CRL with ~35 entries from = 2014 - no reason codes. - A non-US tech company: ~10K revoked certs over 4 years with no reason = codes. Another one on a different continent: ~1.8K entries spanning 3 = years - reason codes too codes 5, 4, 3, and 1 (in descending order of = apperance). - =46rom a couple of the larger hosting sites: one runs their own CA and = it has ~280 entries - all in one year and all but one reason code is 5, = another doesn=92t run their own CA and the CRL in their certificate has = ~2.8K entries but no reason codes (all in 2014), another one has an = empty CRL, another one has a CRL with ~500. And now for more comprehensive data: Eric Osterweil has some data that can be found here: http://secspider.verisignlabs.com/heartbleed/ Richard Barnes had some too: scan of CRLDPs in ~450 different CRLs: 1.4M entries, median entries per CRL: 390, average # of entries 3.2K This doesn=92t seem so rare. Onto S/MIME: On Oct 02, 2014, at 18:12, Paul Hoffman wrote: >> I looked back at two years of data. My own, mid-size (3K staff) = organization revokes on average 165 net-identities a month. >=20 > This is literally the first data I have seen that indicated that email = certs were revoked for other than far edge cases. (I'm assuming that you = are equating "net-identities" and email certs...) Thanks for the data. >=20 > But, having said that, NIST isn't a typical organization. The fact = that you revoke more than half of your S/MIME certs per year is = surprising to me, but that may be because I am not familiar with the = policies you used. I=92m just as surprised by the # of revoked certificates compared to the = # of employees, but I=92m also not surprised that the $14.95 and free = S/MIME cert CA=92s CRLs are empty or at least close to it: 19 entries = (covering 8 years), ~180 entries (covering two years). There=92s little = incentive for those that have been issued $14.95 or free certificates to = ask for them to be revoked especially since most of the changes I see = are cessation of operation (I quit, I got fired, etc.). I think we should be looking at the managed service CA=92s CRLs or large = enterprise CA CRLs instead because there at least there=92s policies = that are much more likely to get enforced (you quit they revoke your = cert). Then again, you have to dig a little deeper to find these CRLs = by CLRDPs in certificates with signed messages. Here=92s some CRLs from = managed PKIs (employee #s from wikipedia) picked from S/MIME messages = sent to an IETF ML: - ~120K employees: ~125K entries spread out over 3 years. Of the = reasons that appear superseded shows up the most then affiliation = changed. - ~100K employees: ~5K entries so far this year. No reason codes. - ~25K employees firm has ~36.5K entries covering the last three years. = Not a lot of reason codes but there are 57 key compromise and 244 = superseded reasons listed. - (a University) ~18K students & ~2.5K staff: ~1.9K entries spread out = over 3 years. No reason codes. - An org (don=92t know how many people work there - wikipedia failed = me):~1.7K entries. No reason codes. Only one of the above is what I=92d consider a traditional = USG-affiliated org - and it=92s not the CRL with the most entries. NIST #s might be out of whack but I=92m not sure how atypical it is for = organizations that actually issue certificates to revoke those = certificates. Again, I=92m all for debating whether we should define a =93revoke" = usage and how it works but dismissing the request based on data that to = me shows the exact opposite of your observation seems wrong to me and I = hope others. WRT: > 3) There is absolutely no indication that zone size or response size = is important to SMIMEA, certainly not relative to the added complexity = for clients, servers, and operators. Currently, the RSA certs for SMIME = from common CAs are for both signing and encrypting, so this added = complexity won't buy current users anything. In the future when we are = all (hopefully) using elliptic curve keys, the zone size and response = size will be so much smaller than they are now that this change will = appear as an over-optimization that adds complexity. Four points here: - On the certificate size, you=92re right that EC certificates will be = smaller than their RSA-based brethren. I pulled a RSA-based TLS = certificate from a US bank it=92s about ~2Kbytes. An EC-based TLS = certificate, which I thought based on the name in the cert was a porn = site - not - it=92s a bakery, is about ~1Kbytes - an S/MIME cert would = be the same size. - On whether it buys current users anything because RSA-based S/MIME = certificates are for both sig+enc, of course it=92s not going to buy = them anything for my persona-non-validated certificates they don=92t = offer the ability to get just one usage. Also, some do in fact issue = separate certs. I don=92t think you can lump all the users together. - On the future, the part you didn=92t mention is that EC-based = certificates might not specify both digital signature and = transport/agreement. The TLS EC certificates I=92m seeing only include = only sig. Whether the S/MIME certs follow suite - I don=92t think you = can say authoritatively they will or won=92t unless you=92re a CA who is = issuing them. If the certificates include both KUs then yeah EC certs = are about half of RSA certs - but if not then two of =91em is about the = same as one RSA cert. - Finally on complexity, what=92s proposed is definitely more than = what=92s there now but how much more complex it is I think is in the = eyes of the beholder. spt [1] 1) One of the other thing to note for CRLs that span more than one = year is that the number of revocations seem to be increasing. I could = speculate as to why but maybe we can leave that for another thread. 2) = Some of the bigger CRLs are bigger not entirely based on the # of = entries it=92s also because they used longer serial #s and included = reasons codes - a 64MByte CRL had ~300 entries. 3) Interesting to note = that in the EC-based cert the spki+(sig+alg id) is like 89+(73+10) = octets - could save another 80 octets by not including a subject name = and just using the SAN.= From nobody Thu Oct 16 07:58:48 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 921951A1BDA for ; Thu, 16 Oct 2014 07:58:41 -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, LOTS_OF_MONEY=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 h7WhGxgsuPIn for ; Thu, 16 Oct 2014 07:58:36 -0700 (PDT) Received: from smtp68.ord1c.emailsrvr.com (smtp68.ord1c.emailsrvr.com [108.166.43.68]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC0D11A1A75 for ; Thu, 16 Oct 2014 07:58:35 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp9.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 2EAF1380E15; Thu, 16 Oct 2014 10:58:35 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp9.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 7ECB4380E1C; Thu, 16 Oct 2014 10:58:32 -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:465 (trex/5.2.13); Thu, 16 Oct 2014 14:58:35 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Olafur Gudmundsson In-Reply-To: <67BDE5B6-58C7-4E0B-8CB4-045E51027D85@ieca.com> Date: Thu, 16 Oct 2014 10:58:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <273F9612-13AF-4CB8-B15C-912AAD04C738@verisign.com> <67BDE5B6-58C7-4E0B-8CB4-045E51027D85@ieca.com> To: Sean Turner X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/R8SWGDHAWppQYLsD-ZlXdV-3VNc Cc: draft-ietf-dane-smime@tools.ietf.org, "" Subject: Re: [dane] draft-ietf-dane-smime X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 14:58:41 -0000 =20 Thank you Sean=20 for supplying numbers and reasons to consider all the points.=20 Wg members, please start giving feedback on this tread as to going = forward,=20 should we in the S/MIME DANE documents explicitly support =93policy = expression=94 or=20 reject it.=20 =20 =20 to me one question to answer is:=20 If X@Y sends S/MIME signed message to DANE WG on January 20=92th 2016.=20= X@Y leaves Y on Feb 15=92th 2016.=20 Is there any value in being able to validate the signature when a = document editor gets around to read the message March 15 2016 while updating the document referenced in the email to meet the ID = deadline for IETF-95 ?=20 Olafur On Oct 16, 2014, at 1:46 AM, Sean Turner wrote: > Apologies for coming to this late and for this being so long. >=20 > On Sep 30, 2014, at 16:53, Paul Hoffman wrote: >=20 >> On Sep 29, 2014, at 5:26 AM, Osterweil, Eric = wrote: >>=20 >> When these ideas were brought to the WG earlier this year, we didn't = hear any significant support. Given that both of us feel that the = proposed changes make the document harder to implement, we would want to = see much wider support before we adopt them. >>=20 >> --Paul Hoffman and Jakob Schlyter >=20 > I guess we know where the authors stand on making the changes ;) >=20 > Anyway, put me in the camp that wants to continue the discussion about = the possibility of making changes to support the proposed changes to the = SMIMEA spec. >=20 > WRT: >=20 >> 1) This usage type is at least as applicable to TLS as it is to = S/MIME. We haven't seen anything indicating much use of certificate = revocation anywhere and, where we have seen it, it is much more common = in TLS. If the authors really want this feature, it should be an update = to TLSA, which SMIMEA could then adopt. >>=20 >> 2) Making the record format for SMIMEA different than that of TLSA = for this feature seems like a bad idea. Alternate discovery mechanisms = might be important, but they will be just as important for TLS as they = are for S/MIME. The functionality that the authors want could be added = to TLSA by adding new Matching Type fields such as "Hash and NAPTR", = "Hash and URI", and so on. The latter is part of IKEv2 (although the = feature is generally considered not useful). If the authors really want = this feature, it should be an update to TLSA, which SMIMEA could then = adopt. >=20 >=20 > Two parts: >=20 > 1) Comparing the use of revocation of TLS certificates to S/MIME = certificates is an interesting way to start because what you say is = obviously true; TLS is so much more widely deployed compared to S/MIME = (everybody uses TLS - enterprises and some nerds use S/MIME) so of = course you=92re going to see it much more in/for TLS. I=92d love to = know the split between TLS versus S/MIME certificates issued by big box = CAs and how often the associated CRLs get checked but I=92m sure that=92s = proprietary (please somebody prove me wrong). >=20 > 2) I want to push back on the statement above about changing TLSA = first and this bit that followed later in the thread: >=20 > On Oct 02, 2014, at 18:12, Paul Hoffman wrote: >=20 >> On Oct 2, 2014, at 1:56 PM, Doug Montgomery = wrote: >>=20 >>> Overly coupling the use cases and requirements between these uses = seems to be a red herring to me. Maybe we should turn the question = around and ask for an explanation why the use cases for TLS should = impact the requirements for SMIMEA? >>=20 >> Or, based on what Jakob and I suggested, why shouldn't features that = are needed for either use case be shared? >=20 > The idea that the proponents of these changes need to go change the = TLSA spec because you think it applies to both seems a little bit = excessive. If you think the changes apply to both, then great feel free = to go and propose those changes get made in the TLSA spec; I see no = reason to burden the proponents of these changes with that job. >=20 > WRT rarity: >=20 > On Oct 02, 2014, at 18:12, Paul Hoffman wrote: >=20 >> On Oct 2, 2014, at 1:56 PM, Doug Montgomery = wrote: >>=20 >>> As far as I know we have never revoked our TLS cert ...=20 >>=20 >> Right: TLS certs are rarely revoked. This can be seen by looking at = the CRLs from major CAs. However, looking in those same CRLs shows = nearly no S/MIME certs revoked either. >=20 >=20 > There might be other reasons to dismiss usage #4 (reject) but we = shouldn't do so based on your assertion that there=92s no revocation of = TLS or S/MIME certs because I believe revocation happens more than = rarely. Rarely to me means I=92d have a really hard time finding some = revoked certs. >=20 > I took the bait and went and looked at some CRLs (my hastily gathered = small sample is later) - was this your ploy all along? If not, I=92d be = curious to know what you=92re looking at to motivate your statement. = What I=92m looking at seems to indicate that TLS certificate revocation = happens certainly more than on rare occasions. I also got my hands on = some CRLs with S/MIME certificates on =91em that also seem to indicate = it=92s also not so rare to revoke S/MIME/ID certificates (also later). >=20 > Note: This might be stating the obvious but looking at the exact same = CRLs might not give you what you=92re looking for in terms of finding = revoked TLS and S/MIME certificates: 1) the CA has to put all the = revoked certificates on the same CRL and they don=92t always do that in = fact it looks like many don't that based on the CRL=92s issuer name; CRL = issuer names include =93EV=94, =93SSL=94, etc. for TLS-only CRLs and = =93Individual=94, =93Personal=94, etc. for S/MIME-only certificates, 2) = some of the big box CAs only do TLS certificates so of course you=92re = not going to see any S/MIME certificates on the CRL, and 3) you can=92t = tell by looking at CRL entry what the certificate=92s KU or EKU is = because the entries only contain the serial number, revocation date, and = maybe if you=92re lucky a revocation reason (you might be able to infer = from the reason code but you kinda gotta guess what=92s on the CRL based = on the name of the CRL issuer or if you dig a little farther based on = the certificate=92s CP/CPS - I mostly assumed based on the CRL issuer = name). >=20 > Before the data first a couple of disclaimers: >=20 > - I don=92t name names for obvious reasons. >=20 > - The CRLs are all from public facing TLS servers. So all of this in = some fashion or another is reproducible. >=20 > - I made sure to not use duplicate CRLs from the same provider by = looking at the AKI if present and issuer name if not. >=20 > - To find the CRLs, it wasn=92t as easy as following some links to the = CA=92s repo and downloading them; it is that easy for root and = intermediate CA certificates but not for CRLs and not for EE = certificates. Maybe I=92m doing it wrong =85 anyway, to get them I had = to go to https enabled websites, click on the browser bar, inspect the = certificate, scroll to the CRLDP extension, ctrl-c/v the URI to the CRL = into firefox, then use dumpasn1 (still works like a champ) on the = downloaded CRL to look at the number of entries. I then went to the SEQ = after the thisUpdate/nextUpdate lines, divided the number next to the = SEQ by what seemed to be the average size of each entry, and got an = approximate # of entries on the CRL. See [1] for some interesting = observations. Also, if you=92re looking at the CRL=92s pointed to in = those CA certificates you can find in the repo you=92re looking at the = wrong CRL - the CRLs pointed to from CA certificates are ARLs disguised = as CRLs. >=20 > - Other folks were more high tech and ran scripts that looked at a lot = more CRLs than my manual method. I included their results after my = plodding results. >=20 > And, now for some data on CRLs for TLS certificates: >=20 > - Started with search engines: two of =91em run their own CAs so it=92s = unsurprising they contain few entries (8 & ~50) and another uses a = managed service and that CRL has well more =85 like ~51K. The CRL with = ~51K entries includes entries back to 2010 and according to the = description of the Root CA only TLS certificates are issued by CA = subordinates to it so all of those ~51K are TLS certificates. I went to = another one - they don=92t offer https:// :( >=20 > - A non-US news organization: there=92s ~400 entries covering just = this year. >=20 > - A non-US bank: ~5.2K entries with three years worth of revoked = certificates (no reason codes). I went to another on a different = continent and found the same CRL so new data. I went to a third (on the = same continent as the 1st) and got a CA from what I wouldn=92t consider = one of the typical US big box CAs and found a CRL with ~35 entries from = 2014 - no reason codes. >=20 > - A non-US tech company: ~10K revoked certs over 4 years with no = reason codes. Another one on a different continent: ~1.8K entries = spanning 3 years - reason codes too codes 5, 4, 3, and 1 (in descending = order of apperance). >=20 > - =46rom a couple of the larger hosting sites: one runs their own CA = and it has ~280 entries - all in one year and all but one reason code is = 5, another doesn=92t run their own CA and the CRL in their certificate = has ~2.8K entries but no reason codes (all in 2014), another one has an = empty CRL, another one has a CRL with ~500. >=20 > And now for more comprehensive data: >=20 > Eric Osterweil has some data that can be found here: > http://secspider.verisignlabs.com/heartbleed/ >=20 > Richard Barnes had some too: scan of CRLDPs in ~450 > different CRLs: 1.4M entries, median entries per CRL: 390, > average # of entries 3.2K >=20 > This doesn=92t seem so rare. >=20 > Onto S/MIME: >=20 > On Oct 02, 2014, at 18:12, Paul Hoffman wrote: >=20 >>> I looked back at two years of data. My own, mid-size (3K staff) = organization revokes on average 165 net-identities a month. >>=20 >> This is literally the first data I have seen that indicated that = email certs were revoked for other than far edge cases. (I'm assuming = that you are equating "net-identities" and email certs...) Thanks for = the data. >>=20 >> But, having said that, NIST isn't a typical organization. The fact = that you revoke more than half of your S/MIME certs per year is = surprising to me, but that may be because I am not familiar with the = policies you used. >=20 >=20 > I=92m just as surprised by the # of revoked certificates compared to = the # of employees, but I=92m also not surprised that the $14.95 and = free S/MIME cert CA=92s CRLs are empty or at least close to it: 19 = entries (covering 8 years), ~180 entries (covering two years). There=92s = little incentive for those that have been issued $14.95 or free = certificates to ask for them to be revoked especially since most of the = changes I see are cessation of operation (I quit, I got fired, etc.). >=20 > I think we should be looking at the managed service CA=92s CRLs or = large enterprise CA CRLs instead because there at least there=92s = policies that are much more likely to get enforced (you quit they revoke = your cert). Then again, you have to dig a little deeper to find these = CRLs by CLRDPs in certificates with signed messages. Here=92s some CRLs = from managed PKIs (employee #s from wikipedia) picked from S/MIME = messages sent to an IETF ML: >=20 > - ~120K employees: ~125K entries spread out over 3 years. Of the = reasons that appear superseded shows up the most then affiliation = changed. >=20 > - ~100K employees: ~5K entries so far this year. No reason codes. >=20 > - ~25K employees firm has ~36.5K entries covering the last three = years. Not a lot of reason codes but there are 57 key compromise and = 244 superseded reasons listed. >=20 > - (a University) ~18K students & ~2.5K staff: ~1.9K entries spread out = over 3 years. No reason codes. >=20 > - An org (don=92t know how many people work there - wikipedia failed = me):~1.7K entries. No reason codes. >=20 > Only one of the above is what I=92d consider a traditional = USG-affiliated org - and it=92s not the CRL with the most entries. >=20 > NIST #s might be out of whack but I=92m not sure how atypical it is = for organizations that actually issue certificates to revoke those = certificates. >=20 > Again, I=92m all for debating whether we should define a =93revoke" = usage and how it works but dismissing the request based on data that to = me shows the exact opposite of your observation seems wrong to me and I = hope others. >=20 > WRT: >=20 >> 3) There is absolutely no indication that zone size or response size = is important to SMIMEA, certainly not relative to the added complexity = for clients, servers, and operators. Currently, the RSA certs for SMIME = from common CAs are for both signing and encrypting, so this added = complexity won't buy current users anything. In the future when we are = all (hopefully) using elliptic curve keys, the zone size and response = size will be so much smaller than they are now that this change will = appear as an over-optimization that adds complexity. >=20 > Four points here: >=20 > - On the certificate size, you=92re right that EC certificates will be = smaller than their RSA-based brethren. I pulled a RSA-based TLS = certificate from a US bank it=92s about ~2Kbytes. An EC-based TLS = certificate, which I thought based on the name in the cert was a porn = site - not - it=92s a bakery, is about ~1Kbytes - an S/MIME cert would = be the same size. >=20 > - On whether it buys current users anything because RSA-based S/MIME = certificates are for both sig+enc, of course it=92s not going to buy = them anything for my persona-non-validated certificates they don=92t = offer the ability to get just one usage. Also, some do in fact issue = separate certs. I don=92t think you can lump all the users together. >=20 > - On the future, the part you didn=92t mention is that EC-based = certificates might not specify both digital signature and = transport/agreement. The TLS EC certificates I=92m seeing only include = only sig. Whether the S/MIME certs follow suite - I don=92t think you = can say authoritatively they will or won=92t unless you=92re a CA who is = issuing them. If the certificates include both KUs then yeah EC certs = are about half of RSA certs - but if not then two of =91em is about the = same as one RSA cert. >=20 > - Finally on complexity, what=92s proposed is definitely more than = what=92s there now but how much more complex it is I think is in the = eyes of the beholder. >=20 > spt >=20 > [1] 1) One of the other thing to note for CRLs that span more than one = year is that the number of revocations seem to be increasing. I could = speculate as to why but maybe we can leave that for another thread. 2) = Some of the bigger CRLs are bigger not entirely based on the # of = entries it=92s also because they used longer serial #s and included = reasons codes - a 64MByte CRL had ~300 entries. 3) Interesting to note = that in the EC-based cert the spki+(sig+alg id) is like 89+(73+10) = octets - could save another 80 octets by not including a subject name = and just using the SAN. > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From nobody Thu Oct 16 08:18:11 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD3C71A1BF3 for ; Thu, 16 Oct 2014 08:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.361 X-Spam-Level: X-Spam-Status: No, score=-1.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 OHso_8NI_clU for ; Thu, 16 Oct 2014 08:18:03 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) (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 5F8511A1BF2 for ; Thu, 16 Oct 2014 08:18:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:content-type:mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=ZwRLvn9IzDVg1fOOlLcODSr/PtF8REwXtWf+dPTF5ZA=; b=nTgBGi65jgNCW8BPG2M+Ah6decVr1qZxcuzhGUx8JArb4l1TMw89y+oJymvzw+465pPHtI9qinua2 j33STfjJ+qKB/qmUtCvODqJovlZDz3pp0Zyz8/TRG0e+T0X6gHBqZyD3rmfP+g+OOvpBfug54buRUC O068z7pRFN/zJ9kc= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Thu, 16 Oct 2014 17:17:51 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Jakob Schlyter In-Reply-To: Date: Thu, 16 Oct 2014 17:17:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <62F1DB86-59B4-4165-9AEE-82A829B6A9A9@kirei.se> References: <273F9612-13AF-4CB8-B15C-912AAD04C738@verisign.com> <67BDE5B6-58C7-4E0B-8CB4-045E51027D85@ieca.com> To: =?windows-1252?Q?=D3lafur_Gu=F0mundsson?= X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/v-UGBt2BLKaXXNlnmHpzq-nVt7E Cc: draft-ietf-dane-smime@tools.ietf.org, "" Subject: Re: [dane] draft-ietf-dane-smime X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 15:18:07 -0000 On 16 okt 2014, at 16:58, Olafur Gudmundsson wrote: > If X@Y sends S/MIME signed message to DANE WG on January 20=92th = 2016.=20 > X@Y leaves Y on Feb 15=92th 2016.=20 >=20 > Is there any value in being able to validate the signature when a = document editor gets around to read the message March 15 2016 while = updating the document referenced in the email to meet the ID deadline = for IETF-95 ?=20 You basically want to know if certificate C was valid at time T. A CRL = might tell you when a certificate was revoked, whereas OCSP does not. = Neither of the proposals discussed in this group so far would help you = with that either. Paul and I advocate that SMIMEA will only tell you if a given = certificate is valid in real time (or in the proximity of). Others say = an explicit revoked flag would be useful. I believe your question is interesting, but I suspect it is out of scope = for this group. If a given certificate is not valid, you can always go = back to a CRL (if one exists) and find out when it was revoked. jakob From nobody Fri Oct 17 07:46:52 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DCC11A0047 for ; Fri, 17 Oct 2014 07:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.647 X-Spam-Level: X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-2.3] 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 7HHHFpuQ2RAX for ; Fri, 17 Oct 2014 07:46:50 -0700 (PDT) Received: from proper.com (Hoffman.Proper.COM [207.182.41.81]) (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 278A31A001B for ; Fri, 17 Oct 2014 07:46:50 -0700 (PDT) Received: from [10.0.0.122] (rrcs-67-52-105-34.west.biz.rr.com [67.52.105.34]) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id s9HEkje6013288 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 17 Oct 2014 07:46:47 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host rrcs-67-52-105-34.west.biz.rr.com [67.52.105.34] claimed to be [10.0.0.122] Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Paul Hoffman In-Reply-To: <67BDE5B6-58C7-4E0B-8CB4-045E51027D85@ieca.com> Date: Fri, 17 Oct 2014 07:46:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3473729E-BC37-48DB-9ACD-FB872CB666DE@vpnc.org> References: <273F9612-13AF-4CB8-B15C-912AAD04C738@verisign.com> <67BDE5B6-58C7-4E0B-8CB4-045E51027D85@ieca.com> To: Sean Turner X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/hqlImFxfG_eVzlpRorzfnxCKzmc Cc: "" Subject: Re: [dane] draft-ietf-dane-smime X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 14:46:51 -0000 On Oct 15, 2014, at 10:46 PM, Sean Turner wrote: > The idea that the proponents of these changes need to go change the = TLSA spec because you think it applies to both seems a little bit = excessive. If you think the changes apply to both, then great feel free = to go and propose those changes get made in the TLSA spec; I see no = reason to burden the proponents of these changes with that job. Nor do I see a reason for the proponents to burden us with making the = changes here if there is no support for them. As you probably saw, = another WG member pointed out that there were significant technical = issues with the wording of the revocation proposal. If we incorporate = that into the S/MIME draft, that draft will get delayed while the = proponents get their wording right. A better process would be for the proponents to offer a standalone draft = for the idea that will be an extension that would be usable to both TLSA = and SMIMEA and any other documents that come later. --Paul Hoffman= From nobody Fri Oct 17 08:04:55 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24B551A014F for ; Fri, 17 Oct 2014 08:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 d5JLxPi3CSsS for ; Fri, 17 Oct 2014 08:04:51 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A8DA1A01AA for ; Fri, 17 Oct 2014 08:04:51 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 55B652AB2B5; Fri, 17 Oct 2014 15:04:49 +0000 (UTC) Date: Fri, 17 Oct 2014 15:04:49 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141017150448.GV20066@mournblade.imrryr.org> References: <273F9612-13AF-4CB8-B15C-912AAD04C738@verisign.com> <67BDE5B6-58C7-4E0B-8CB4-045E51027D85@ieca.com> <62F1DB86-59B4-4165-9AEE-82A829B6A9A9@kirei.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <62F1DB86-59B4-4165-9AEE-82A829B6A9A9@kirei.se> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/BvOZKV-1l8zxXkd7ARS8Na6RyKs Subject: Re: [dane] draft-ietf-dane-smime X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 15:04:54 -0000 On Thu, Oct 16, 2014 at 05:17:49PM +0200, Jakob Schlyter wrote: > > If X@Y sends S/MIME signed message to DANE WG on January 20th 2016. > > X@Y leaves Y on Feb 15th 2016. > > > > Is there any value in being able to validate the signature when a document > > editor gets around to read the message March 15 2016 while updating the > > document referenced in the email to meet the ID deadline for IETF-95 ? > > You basically want to know if certificate C was valid at time T. A CRL > might tell you when a certificate was revoked, whereas OCSP does not. > Neither of the proposals discussed in this group so far would help you > with that either. Perhaps some of you have seen the recent comments by Jerry Leichter on Perry's cryptography list in the thread about HP revoking their software signing certificate. The problem with revocation of signing certificates for "data at rest" is rather deep. We simply don't have correct semantics for this at present. Revocation that invalidates messages older than the revocation event is rather sub-optimal. With email, the MUA and/or mailstore should validate messages when they first arrive, and record the validity of the signature at that point. With validity frozen at time of arrival, it is largely sufficient to remove the ability of obsolete keys to sign new mail and delist them as valid keys for receiving new encrypted mail. > Paul and I advocate that SMIMEA will only tell you if a given certificate > is valid in real time (or in the proximity of). Others say an explicit > revoked flag would be useful. I concur, subsequent revocation of already received and at the time accepted as valid mail is too little too late. It has in most cases already been acted on (for better or for worse) at time of arrival. -- Viktor. From nobody Mon Oct 20 08:30:07 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0842C1A1B7F for ; Mon, 20 Oct 2014 08:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 WRr-8a5MTTOM for ; Mon, 20 Oct 2014 08:30:04 -0700 (PDT) Received: from exprod6og115.obsmtp.com (exprod6og115.obsmtp.com [64.18.1.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC4C51A6EF0 for ; Mon, 20 Oct 2014 08:23:58 -0700 (PDT) Received: from brn1lxmailout02.vcorp.ad.vrsn.com ([72.13.63.42]) (using TLSv1) by exprod6ob115.postini.com ([64.18.5.12]) with SMTP ID DSNKVEUpDkkVpoBbkWKSzMA/w2XhBcFpjIW5@postini.com; Mon, 20 Oct 2014 08:24:01 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by brn1lxmailout02.vcorp.ad.vrsn.com (8.13.8/8.13.8) with ESMTP id s9KFNvY4023995 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 20 Oct 2014 11:23:57 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Mon, 20 Oct 2014 11:23:56 -0400 From: "Osterweil, Eric" To: Paul Hoffman Thread-Topic: [dane] draft-ietf-dane-smime Thread-Index: AQHP2+CXduy9obN06UaH3lWvHXXI5ZwabJwAgBgn4ICAAikmgIAEwWkA Date: Mon, 20 Oct 2014 15:23:57 +0000 Message-ID: References: <273F9612-13AF-4CB8-B15C-912AAD04C738@verisign.com> <67BDE5B6-58C7-4E0B-8CB4-045E51027D85@ieca.com> <3473729E-BC37-48DB-9ACD-FB872CB666DE@vpnc.org> In-Reply-To: <3473729E-BC37-48DB-9ACD-FB872CB666DE@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/8srQx7rMqMfASVIJKvIHplzUvps Cc: "" Subject: Re: [dane] draft-ietf-dane-smime X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 15:30:06 -0000 On Oct 17, 2014, at 10:46 AM, Paul Hoffman wrote: > On Oct 15, 2014, at 10:46 PM, Sean Turner wrote: >=20 >> The idea that the proponents of these changes need to go change the TLSA= spec because you think it applies to both seems a little bit excessive. I= f you think the changes apply to both, then great feel free to go and propo= se those changes get made in the TLSA spec; I see no reason to burden the p= roponents of these changes with that job. >=20 > Nor do I see a reason for the proponents to burden us with making the cha= nges here if there is no support for them. As you probably saw, another WG = member pointed out that there were significant technical issues with the wo= rding of the revocation proposal. If we incorporate that into the S/MIME dr= aft, that draft will get delayed while the proponents get their wording rig= ht. Hey Paul, TLS and S/MIME use pretty different security models (session vs. object sec= urity), so necessarily coupling the RRs doesn=92t seem to make sense. In a= ddition, to echo what others have already said on the list, I really don=92= t think it is reasonable to gate updates to the SMIMEA proposal on updating= TLSA. > A better process would be for the proponents to offer a standalone draft = for the idea that will be an extension that would be usable to both TLSA an= d SMIMEA and any other documents that come later. Just by looking at the list, it seems like there are a number of voices tha= t disagree with you on this. Also, isn=92t the SMIMEA work still an evolvi= ng draft? What else does one need besides: articulated rationale, proposed= requirements, operational data, suggested text, and running code from mult= iple people in order to support suggested revisions? Please accept the pro= posed SMIMEA changes into the SMIMEA draft so that we can make progress on = this work. Thank you, Eric= From nobody Mon Oct 20 08:30:10 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 086551A1B92 for ; Mon, 20 Oct 2014 08:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 dEY6Z1SlJ0ZP for ; Mon, 20 Oct 2014 08:30:06 -0700 (PDT) Received: from exprod6og121.obsmtp.com (exprod6og121.obsmtp.com [64.18.1.237]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 951751A6ED9 for ; Mon, 20 Oct 2014 08:24:09 -0700 (PDT) Received: from brn1lxmailout02.vcorp.ad.vrsn.com ([72.13.63.42]) (using TLSv1) by exprod6ob121.postini.com ([64.18.5.12]) with SMTP ID DSNKVEUpGfe7u+K1xkLBx6cuNEgDcvN+CCcd@postini.com; Mon, 20 Oct 2014 08:24:09 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by brn1lxmailout02.vcorp.ad.vrsn.com (8.13.8/8.13.8) with ESMTP id s9KFO8KP024000 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 20 Oct 2014 11:24:08 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Mon, 20 Oct 2014 11:24:08 -0400 From: "Osterweil, Eric" To: "" Thread-Topic: [dane] draft-ietf-dane-smime Thread-Index: AQHP2+CXduy9obN06UaH3lWvHXXI5ZwabJwAgBgn4ICAAJoaAIAABWiAgAGOs4CABLxngA== Date: Mon, 20 Oct 2014 15:24:07 +0000 Message-ID: References: <273F9612-13AF-4CB8-B15C-912AAD04C738@verisign.com> <67BDE5B6-58C7-4E0B-8CB4-045E51027D85@ieca.com> <62F1DB86-59B4-4165-9AEE-82A829B6A9A9@kirei.se> <20141017150448.GV20066@mournblade.imrryr.org> In-Reply-To: <20141017150448.GV20066@mournblade.imrryr.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="Windows-1252" Content-ID: <0E28CE5F1BBAA94D84D38F6AFA92E5BF@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/9sbMTbAaljO6O3kAIhfmErwoVNc Subject: Re: [dane] draft-ietf-dane-smime X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 15:30:08 -0000 On Oct 17, 2014, at 11:04 AM, Viktor Dukhovni wrot= e: > On Thu, Oct 16, 2014 at 05:17:49PM +0200, Jakob Schlyter wrote: >=20 >>> If X@Y sends S/MIME signed message to DANE WG on January 20th 2016.=20 >>> X@Y leaves Y on Feb 15th 2016.=20 >>>=20 >>> Is there any value in being able to validate the signature when a docum= ent >>> editor gets around to read the message March 15 2016 while updating the >>> document referenced in the email to meet the ID deadline for IETF-95 ? >>=20 >> You basically want to know if certificate C was valid at time T. A CRL >> might tell you when a certificate was revoked, whereas OCSP does not. >> Neither of the proposals discussed in this group so far would help you >> with that either. >=20 > Perhaps some of you have seen the recent comments by Jerry Leichter > on Perry's cryptography list in the thread about HP revoking their > software signing certificate. The problem with revocation of > signing certificates for "data at rest" is rather deep. We simply > don't have correct semantics for this at present. >=20 > Revocation that invalidates messages older than the revocation > event is rather sub-optimal. >=20 > With email, the MUA and/or mailstore should validate messages when > they first arrive, and record the validity of the signature at that > point. With validity frozen at time of arrival, it is largely > sufficient to remove the ability of obsolete keys to sign new mail > and delist them as valid keys for receiving new encrypted mail. >=20 >> Paul and I advocate that SMIMEA will only tell you if a given certificat= e >> is valid in real time (or in the proximity of). Others say an explicit >> revoked flag would be useful. >=20 > I concur, subsequent revocation of already received and at the time > accepted as valid mail is too little too late. It has in most > cases already been acted on (for better or for worse) at time of > arrival. For what it=92s worth, I think the proposed text was exactly inline with wh= at you both are suggesting. The suggestion was a way to help enterprises e= xpress their needs (under some circumstances) a little more cleanly in DNS.= For example, a single DANE TA could be used to authorized all of an organ= ization=92s S/MIME users, and selective ``user-no-longer-valid'' (i.e. revo= cation) entries could override this. This could definitely allow for the f= act that the S/MIME cert of a ``user-no-longer-valid'' employee was once va= lid, but not at the time of querying DNS. As you both point out (I believe= ), this is different than other notions of revocation. I think we are all on the same page, and perhaps the text was not clear eno= ugh? Maybe it's also possible there was some misunderstanding from the pro= tracted email discussion? The revocation discussion (IIRC) really had to d= o with an assertion that TLS did not have revocation needs. Eric From nobody Mon Oct 20 08:54:55 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C35BE1A1AFD for ; Mon, 20 Oct 2014 08:54:51 -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] 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 vIlvrGPSWWxl for ; Mon, 20 Oct 2014 08:54:44 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BB981A0369 for ; Mon, 20 Oct 2014 08:54:25 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 4CC632AB2B5; Mon, 20 Oct 2014 15:54:23 +0000 (UTC) Date: Mon, 20 Oct 2014 15:54:23 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141020155423.GF19158@mournblade.imrryr.org> References: <273F9612-13AF-4CB8-B15C-912AAD04C738@verisign.com> <67BDE5B6-58C7-4E0B-8CB4-045E51027D85@ieca.com> <62F1DB86-59B4-4165-9AEE-82A829B6A9A9@kirei.se> <20141017150448.GV20066@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/xHaX1Qi93gRP9uuOusMeCVfbSis Subject: Re: [dane] draft-ietf-dane-smime X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 15:54:51 -0000 On Mon, Oct 20, 2014 at 03:24:07PM +0000, Osterweil, Eric wrote: > For example, a single DANE TA could be used to authorized all of an > organization?s S/MIME users, and selective ``user-no-longer-valid'' (i.e. > revocation) entries could override this. The preferred way to "revoke" a DANE-TA(2) binding for a single end-entity is to publish a DANE-EE(3) binding for that entity until the previously issued certificate has expired. Where normally one would have: _smimea._dane.example.com. 1H IN SMIMEA 2 0 1 {blob} .example.com. 1H IN CNAME _smimea._dane.example.com. .example.com. 1H IN CNAME _smimea._dane.example.com. .... .example.com. 1H IN CNAME _smimea._dane.example.com. When the keys for entity42 are compromised, you publish: .example.com. 1H IN SMIME 3 1 1 {blob} (or perhaps "3 0 0" instead of "3 1 1" if that's more appropriate for SMIME). Once the compromised certificate has expired back to: .example.com. 1H IN CNAME _smimea._dane.example.com. This is fine for validating sender presented chains. When looking for a recipient key to encrypt to, an end-entity binding is unavoidable. > I think we are all on the same page, and perhaps the text was not clear > enough? Maybe it's also possible there was some misunderstanding from > the protracted email discussion? The revocation discussion (IIRC) really > had to do with an assertion that TLS did not have revocation needs. My view is that revocation is not terribly useful without accurate signalling of when something was revoked, and whether the revocation applies to content validated prior to the revocation. Just publishing a binary "revoked" bit in DNS would I think be a mistake (do more harm than good). With SMIME used so little, there has been little investment in figuring out how to do revocation correctly. Reasoning by analogy with interactive protocols encrypting data in motion is deeply flawed when applied to data at rest. -- Viktor. From nobody Mon Oct 20 08:55:31 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBB881A1AE1 for ; Mon, 20 Oct 2014 08:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.647 X-Spam-Level: X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-2.3] 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 Zd4ERHNtKhMt for ; Mon, 20 Oct 2014 08:55:24 -0700 (PDT) Received: from proper.com (Hoffman.Proper.COM [207.182.41.81]) (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 744AD1A1AFD for ; Mon, 20 Oct 2014 08:54:52 -0700 (PDT) Received: from [10.20.30.90] (50-1-50-141.dsl.dynamic.fusionbroadband.com [50.1.50.141]) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id s9KFsogQ083508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Oct 2014 08:54:51 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-1-50-141.dsl.dynamic.fusionbroadband.com [50.1.50.141] claimed to be [10.20.30.90] Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Paul Hoffman In-Reply-To: Date: Mon, 20 Oct 2014 08:54:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <63BF3336-C9B8-4D16-BEB7-D42EFBB7A113@vpnc.org> References: <273F9612-13AF-4CB8-B15C-912AAD04C738@verisign.com> <67BDE5B6-58C7-4E0B-8CB4-045E51027D85@ieca.com> <3473729E-BC37-48DB-9ACD-FB872CB666DE@vpnc.org> To: Eric Osterweil X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/jJpmN7rX8nwaNFGmQYO-HdiLv4g Cc: "" Subject: Re: [dane] draft-ietf-dane-smime X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 15:55:27 -0000 On Oct 20, 2014, at 8:23 AM, Osterweil, Eric = wrote: > TLS and S/MIME use pretty different security models (session vs. = object security) Sure, but how is that difference relevant here? DANE is about = distributing certificates and keying information through DNS: it is = agnostic to the security model. > , so necessarily coupling the RRs doesn=92t seem to make sense. =20 It has so far in the WG. The WG asked us early on to make as few changes = as possible to the TLSA definition. > In addition, to echo what others have already said on the list, I = really don=92t think it is reasonable to gate updates to the SMIMEA = proposal on updating TLSA. Fully agree, and that's not what I was proposing. The two changes that = you have proposed (revocation indication and alternate sources for = getting the information) can be done as new values to the existing RR = subfields. Doing so would make what you want usable for both SMIMEA and = TLSA. Proposals to make those changes can trivially be done as = stand-alone Internet Drafts. >> A better process would be for the proponents to offer a standalone = draft for the idea that will be an extension that would be usable to = both TLSA and SMIMEA and any other documents that come later. >=20 > Just by looking at the list, it seems like there are a number of = voices that disagree with you on this. =20 Where "a number" means "two", and even they didn't actually disagree = about creating standalone drafts, simply that the assumption that the = use cases might be different. > Also, isn=92t the SMIMEA work still an evolving draft? =20 Yes, of course. > What else does one need besides: articulated rationale, proposed = requirements, operational data, suggested text, and running code from = multiple people in order to support suggested revisions? =20 Consensus in the WG. That may seem anathema to you, but it's the way = that the IETF works. --Paul Hoffman= From nobody Mon Oct 20 09:02:46 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 042F01A03A5 for ; Mon, 20 Oct 2014 09:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.647 X-Spam-Level: X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-2.3] 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 ffTCVPUmECok for ; Mon, 20 Oct 2014 09:02:42 -0700 (PDT) Received: from proper.com (Hoffman.Proper.COM [207.182.41.81]) (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 4C6CF1A1BB1 for ; Mon, 20 Oct 2014 09:01:58 -0700 (PDT) Received: from [10.20.30.90] (50-1-50-141.dsl.dynamic.fusionbroadband.com [50.1.50.141]) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id s9KG1uNs083776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Oct 2014 09:01:57 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-1-50-141.dsl.dynamic.fusionbroadband.com [50.1.50.141] claimed to be [10.20.30.90] Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Paul Hoffman In-Reply-To: Date: Mon, 20 Oct 2014 09:01:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <273F9612-13AF-4CB8-B15C-912AAD04C738@verisign.com> <67BDE5B6-58C7-4E0B-8CB4-045E51027D85@ieca.com> <62F1DB86-59B4-4165-9AEE-82A829B6A9A9@kirei.se> <20141017150448.GV20066@mournblade.imrryr.org> To: Eric Osterweil X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/OSozZaWZz61DLk5PH3m6svmCmgY Cc: "" Subject: Re: [dane] draft-ietf-dane-smime X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 16:02:44 -0000 On Oct 20, 2014, at 8:24 AM, Osterweil, Eric = wrote: > I think we are all on the same page, and perhaps the text was not = clear enough? =20 I'm with Jakob and Viktor: the text is ill-specified. You are inventing = a new revocation mechanism without enough semantics for a relying party = to use it in a concrete manner. You also don't say how to use your new = revocation information when it conflicts with other revocation = information for the same keying material, such as CRLs and OCSP staples = for the same certificate. > Maybe it's also possible there was some misunderstanding from the = protracted email discussion? The revocation discussion (IIRC) really = had to do with an assertion that TLS did not have revocation needs. Did anyone assert that? If so, please point it out. People asserted that = revocation happens rarely for TLS certificates. --Paul Hoffman= From nobody Mon Oct 20 09:08:28 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE5F21A1BDE for ; Mon, 20 Oct 2014 09:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 x__vBb33EK5K for ; Mon, 20 Oct 2014 09:08:21 -0700 (PDT) Received: from exprod6og115.obsmtp.com (exprod6og115.obsmtp.com [64.18.1.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4750B1A0369 for ; Mon, 20 Oct 2014 09:06:58 -0700 (PDT) Received: from brn1lxmailout01.verisign.com ([72.13.63.41]) (using TLSv1) by exprod6ob115.postini.com ([64.18.5.12]) with SMTP ID DSNKVEUzIUXTKofQfHYXS56iKiPbiH6o+kb3@postini.com; Mon, 20 Oct 2014 09:06:59 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id s9KG6ura005347 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 20 Oct 2014 12:06:57 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Mon, 20 Oct 2014 12:06:56 -0400 From: "Osterweil, Eric" To: Paul Hoffman Thread-Topic: [dane] draft-ietf-dane-smime Thread-Index: AQHP2+CXduy9obN06UaH3lWvHXXI5ZwabJwAgBgn4ICAAikmgIAEwWkAgAAIngCAAANjAA== Date: Mon, 20 Oct 2014 16:06:56 +0000 Message-ID: References: <273F9612-13AF-4CB8-B15C-912AAD04C738@verisign.com> <67BDE5B6-58C7-4E0B-8CB4-045E51027D85@ieca.com> <3473729E-BC37-48DB-9ACD-FB872CB666DE@vpnc.org> <63BF3336-C9B8-4D16-BEB7-D42EFBB7A113@vpnc.org> In-Reply-To: <63BF3336-C9B8-4D16-BEB7-D42EFBB7A113@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/O38luJOwslwygFHZXxRa3UjgxOs Cc: "" Subject: Re: [dane] draft-ietf-dane-smime X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 16:08:24 -0000 On Oct 20, 2014, at 11:54 AM, Paul Hoffman wrote: > On Oct 20, 2014, at 8:23 AM, Osterweil, Eric wr= ote: >=20 >> TLS and S/MIME use pretty different security models (session vs. object = security) >=20 > Sure, but how is that difference relevant here? DANE is about distributin= g certificates and keying information through DNS: it is agnostic to the se= curity model. The relevant information needed during distribution would seem to vary base= d on the security model (as evidenced by this thread). Actually, that=92s = been one of the main points of this thread. >> , so necessarily coupling the RRs doesn=92t seem to make sense. =20 >=20 > It has so far in the WG. The WG asked us early on to make as few changes = as possible to the TLSA definition. Paul, we are all part of the working group. This is the the working group.= I feel like I must be missing some nuanced distinction you have in mind b= etween working group discussions (like this one) and some other arbitration= ? >> In addition, to echo what others have already said on the list, I really= don=92t think it is reasonable to gate updates to the SMIMEA proposal on u= pdating TLSA. >=20 > Fully agree, and that's not what I was proposing. The two changes that yo= u have proposed (revocation indication and alternate sources for getting th= e information) Paul, these were not my proposals. These were proposed by Scott Rose. I s= aw merit in them and when they seemed to be dismissed out of hand I voiced = my support. Also, the proposal included the _encr + _sign labels. > can be done as new values to the existing RR subfields. Doing so would ma= ke what you want usable for both SMIMEA and TLSA. Proposals to make those c= hanges can trivially be done as stand-alone Internet Drafts. But we are still roughing out this draft. This would seem to be a good opp= ortunity to try and get things write in the initial work. >>> A better process would be for the proponents to offer a standalone draf= t for the idea that will be an extension that would be usable to both TLSA = and SMIMEA and any other documents that come later. >>=20 >> Just by looking at the list, it seems like there are a number of voices = that disagree with you on this. =20 >=20 > Where "a number" means "two", and even they didn't actually disagree abou= t creating standalone drafts, simply that the assumption that the use cases= might be different. I think this thread is devolving. The number is greater than two, and revi= ewing the posts of this thread should corroborate the higher level of inter= est. >> Also, isn=92t the SMIMEA work still an evolving draft? =20 >=20 > Yes, of course. >=20 >> What else does one need besides: articulated rationale, proposed require= ments, operational data, suggested text, and running code from multiple peo= ple in order to support suggested revisions? =20 >=20 > Consensus in the WG. That may seem anathema to you, but it's the way that= the IETF works. Paul, what constituted ``the WG=92=92 in your mind?=20 Eric= From nobody Mon Oct 20 09:10:03 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7F7A1A0A6A for ; Mon, 20 Oct 2014 09:09:57 -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] 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 JklsJc9SpPSF for ; Mon, 20 Oct 2014 09:09:52 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DC141A0360 for ; Mon, 20 Oct 2014 09:08:40 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 458262AB2B5; Mon, 20 Oct 2014 16:08:33 +0000 (UTC) Date: Mon, 20 Oct 2014 16:08:33 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141020160832.GG19158@mournblade.imrryr.org> References: <273F9612-13AF-4CB8-B15C-912AAD04C738@verisign.com> <67BDE5B6-58C7-4E0B-8CB4-045E51027D85@ieca.com> <62F1DB86-59B4-4165-9AEE-82A829B6A9A9@kirei.se> <20141017150448.GV20066@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/jQMx-MsCtx77uWD4H7cRbYhrE1c Subject: Re: [dane] draft-ietf-dane-smime X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 16:09:57 -0000 On Mon, Oct 20, 2014 at 09:01:56AM -0700, Paul Hoffman wrote: > > Maybe it's also possible there was some misunderstanding from > > the protracted email discussion? The revocation discussion (IIRC) > > really had to do with an assertion that TLS did not have revocation > > needs. > > Did anyone assert that? If so, please point it out. People asserted that revocation happens rarely for TLS certificates. I've been known to say that with DANE TLSA, explicit revocation is superseded by publishing an updated TLSA record. Don't know whether that was ever in the context the revocation discussion in question. Of course that only applies to situations in which DANE is always used. DANE is of no help when the verifier is using "traditional" PKI. -- Viktor. From nobody Mon Oct 20 09:11:16 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F3FF1A1B4D for ; Mon, 20 Oct 2014 09:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtXcaYhDFVDK for ; Mon, 20 Oct 2014 09:11:07 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 265621A1B28 for ; Mon, 20 Oct 2014 09:10:21 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id DC39780055; Mon, 20 Oct 2014 12:10:19 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1413821419; bh=tyZ4hZAoltduCJ+8+y5bnPy6ZKSax0xQuHEiPGCuAQg=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=qJPjZsfXu7X4FITdTs6FTDL+dR8uI+6zsWprDtVFXxaXFbDg9wmvgxYAR6zMytLyI pye/y50IGU7vznTJs2onlxSpS+gN0qCkcPEN3TnyZ1fgIStU7XvY2Qr+smgU/rQscz 7Ax54JuLtKpoFjQ77FF86j6ROM52DMngIxfr1O1E= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s9KGAIbu008885; Mon, 20 Oct 2014 12:10:19 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 20 Oct 2014 12:10:18 -0400 (EDT) From: Paul Wouters To: "Osterweil, Eric" In-Reply-To: Message-ID: References: <273F9612-13AF-4CB8-B15C-912AAD04C738@verisign.com> <67BDE5B6-58C7-4E0B-8CB4-045E51027D85@ieca.com> <62F1DB86-59B4-4165-9AEE-82A829B6A9A9@kirei.se> <20141017150448.GV20066@mournblade.imrryr.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: http://mailarchive.ietf.org/arch/msg/dane/Vn23m0KQEn3N-oAPN1NK196Emww Cc: "" Subject: Re: [dane] draft-ietf-dane-smime X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 16:11:14 -0000 On Mon, 20 Oct 2014, Osterweil, Eric wrote: > For what it’s worth, I think the proposed text was exactly inline with what you both are suggesting. The suggestion was a way to help enterprises express their needs (under some circumstances) a little more cleanly in DNS. For example, a single DANE TA could be used to authorized all of an organization’s S/MIME users, and selective ``user-no-longer-valid'' (i.e. revocation) entries could override this. This could definitely allow for the fact that the S/MIME cert of a ``user-no-longer-valid'' employee was once valid, but not at the time of querying DNS. As you both point out (I believe), this is different than other notions of revocation. For email addresses that are no longer valid, we have an SMTP error code that prevents delivery. The SMIME and OPENPGPKEY records are not substitutes for "is a valid email user" and it would needlessly complicate the records. Paul From nobody Mon Oct 20 09:59:15 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8AD81A6F57 for ; Mon, 20 Oct 2014 09:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 YA-RfxK_14pn for ; Mon, 20 Oct 2014 09:59:08 -0700 (PDT) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BBBF1A6FC3 for ; Mon, 20 Oct 2014 09:46:18 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id n3so6896738wiv.3 for ; Mon, 20 Oct 2014 09:46:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=l50bekaMAKalKMBAG9lixBMhkV/j4ePsHMQc9KeaJus=; b=dylT2B1glcpko3FQ0SHJ4rP22+r/xdxHWDIBnBNUPPfxSoRY6/0BTTP7akb1fTLsuK vzLARW95fuRfodshpyL0aSHRINNeXogF8S1lR+/ETeEctk6/K5qSjzJfhIGeYS6byIWT UjQDTue6m6ezQZnhMhqjfi/Xlu+wUvheI89fQ2+HI+8CTMT8qkQhFdPTDJzwPvbyX4CQ tdWY8r4Wyo/kDA6Lj0gddRORAP/BKH17E+8jeUGuabq0TQKxRMlY9HMMAlkCTxZ00lUj hczFL0zyrxunhSpViSn5M36svcGCSN6qGP5qwTIpl0YQbU6NsmLqOKAXxH5kMg41rb/D YM7w== X-Gm-Message-State: ALoCoQm7kROpCdBlFJS52M4gwEDVXhBmINUWRW29l08YGYb9mnfbyjYmqqofJf0E175nNiF2yljh MIME-Version: 1.0 X-Received: by 10.180.104.229 with SMTP id gh5mr21499650wib.42.1413823576446; Mon, 20 Oct 2014 09:46:16 -0700 (PDT) Received: by 10.194.77.134 with HTTP; Mon, 20 Oct 2014 09:46:16 -0700 (PDT) In-Reply-To: References: <273F9612-13AF-4CB8-B15C-912AAD04C738@verisign.com> <67BDE5B6-58C7-4E0B-8CB4-045E51027D85@ieca.com> <3473729E-BC37-48DB-9ACD-FB872CB666DE@vpnc.org> <63BF3336-C9B8-4D16-BEB7-D42EFBB7A113@vpnc.org> Date: Mon, 20 Oct 2014 09:46:16 -0700 Message-ID: From: Warren Kumari To: "Osterweil, Eric" Content-Type: multipart/alternative; boundary=f46d04428d180cd9910505dd7421 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/nsvMQacRrF8-rOVXTfvgn-U6VdM Cc: Paul Hoffman , "" Subject: Re: [dane] draft-ietf-dane-smime X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 16:59:13 -0000 --f46d04428d180cd9910505dd7421 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable [top post at random place in thread ] I'd like everyone to take a breath and step back for a minute. I'd like to (off list) arrange a call with Paul and Eric so we can summarize this to be as concise as possible and then get the WG consensus *on the actual points under discussion*... W On Monday, October 20, 2014, Osterweil, Eric wrote: > > On Oct 20, 2014, at 11:54 AM, Paul Hoffman > wrote: > > > On Oct 20, 2014, at 8:23 AM, Osterweil, Eric > wrote: > > > >> TLS and S/MIME use pretty different security models (session vs. objec= t > security) > > > > Sure, but how is that difference relevant here? DANE is about > distributing certificates and keying information through DNS: it is > agnostic to the security model. > > The relevant information needed during distribution would seem to vary > based on the security model (as evidenced by this thread). Actually, > that=E2=80=99s been one of the main points of this thread. > > >> , so necessarily coupling the RRs doesn=E2=80=99t seem to make sense. > > > > It has so far in the WG. The WG asked us early on to make as few change= s > as possible to the TLSA definition. > > Paul, we are all part of the working group. This is the the working > group. I feel like I must be missing some nuanced distinction you have i= n > mind between working group discussions (like this one) and some other > arbitration? > > >> In addition, to echo what others have already said on the list, I > really don=E2=80=99t think it is reasonable to gate updates to the SMIMEA= proposal > on updating TLSA. > > > > Fully agree, and that's not what I was proposing. The two changes that > you have proposed (revocation indication and alternate sources for gettin= g > the information) > > Paul, these were not my proposals. These were proposed by Scott Rose. I > saw merit in them and when they seemed to be dismissed out of hand I voic= ed > my support. Also, the proposal included the _encr + _sign labels. > > > can be done as new values to the existing RR subfields. Doing so would > make what you want usable for both SMIMEA and TLSA. Proposals to make tho= se > changes can trivially be done as stand-alone Internet Drafts. > > But we are still roughing out this draft. This would seem to be a good > opportunity to try and get things write in the initial work. > > >>> A better process would be for the proponents to offer a standalone > draft for the idea that will be an extension that would be usable to both > TLSA and SMIMEA and any other documents that come later. > >> > >> Just by looking at the list, it seems like there are a number of voice= s > that disagree with you on this. > > > > Where "a number" means "two", and even they didn't actually disagree > about creating standalone drafts, simply that the assumption that the use > cases might be different. > > I think this thread is devolving. The number is greater than two, and > reviewing the posts of this thread should corroborate the higher level of > interest. > > >> Also, isn=E2=80=99t the SMIMEA work still an evolving draft? > > > > Yes, of course. > > > >> What else does one need besides: articulated rationale, proposed > requirements, operational data, suggested text, and running code from > multiple people in order to support suggested revisions? > > > > Consensus in the WG. That may seem anathema to you, but it's the way > that the IETF works. > > Paul, what constituted ``the WG=E2=80=99=E2=80=99 in your mind? > > Eric > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf --f46d04428d180cd9910505dd7421 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable [top post at random place in thread ]

I'd like every= one to take a breath and=C2=A0step back for a minute. I'd like to (off = list)=C2=A0arrange a call with Paul and Eric so we can summarize this to be= as concise as possible and then get the WG consensus *on the actual points= under discussion*...

W

On Mon= day, October 20, 2014, Osterweil, Eric <eosterweil@verisign.com> wrote:

On Oct 20, 2014, at 11:54 AM, Paul Hoffman <paul.ho= ffman@vpnc.org> wrote:

> On Oct 20, 2014, at 8:23 AM, Osterweil, Eric <dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane


--
I don't think the execution is releva= nt when it was obviously a bad idea in the first place.
This is like put= ting rabid weasels in your pants, and later expressing regret at having cho= sen those particular rabid weasels and that pair of pants.
=C2=A0 =C2=A0= ---maf
--f46d04428d180cd9910505dd7421-- From nobody Mon Oct 20 10:04:45 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9394C1A6FED for ; Mon, 20 Oct 2014 10:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Xk-jwKnbgf5Y for ; Mon, 20 Oct 2014 10:04:40 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0089.outbound.protection.outlook.com [65.55.169.89]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 967411A1B07 for ; Mon, 20 Oct 2014 09:52:27 -0700 (PDT) Received: from BLUPR06MB243.namprd06.prod.outlook.com (10.242.191.154) by BLUPR06MB866.namprd06.prod.outlook.com (10.141.26.153) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Mon, 20 Oct 2014 16:52:25 +0000 Received: from BLUPR06MB243.namprd06.prod.outlook.com (10.242.191.154) by BLUPR06MB243.namprd06.prod.outlook.com (10.242.191.154) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Mon, 20 Oct 2014 16:52:21 +0000 Received: from BLUPR06MB243.namprd06.prod.outlook.com ([169.254.7.100]) by BLUPR06MB243.namprd06.prod.outlook.com ([169.254.7.100]) with mapi id 15.00.1054.004; Mon, 20 Oct 2014 16:52:21 +0000 From: Dan York To: Paul Hoffman Thread-Topic: Deployment considerations - Re: [dane] draft-ietf-dane-smime Thread-Index: AQHP2+CXduy9obN06UaH3lWvHXXI5ZwaKY4AgBgn4ICAAikmgIAEwWaAgAAIoACAABARAA== Date: Mon, 20 Oct 2014 16:52:21 +0000 Message-ID: References: <273F9612-13AF-4CB8-B15C-912AAD04C738@verisign.com> <67BDE5B6-58C7-4E0B-8CB4-045E51027D85@ieca.com> <3473729E-BC37-48DB-9ACD-FB872CB666DE@vpnc.org> <63BF3336-C9B8-4D16-BEB7-D42EFBB7A113@vpnc.org> In-Reply-To: <63BF3336-C9B8-4D16-BEB7-D42EFBB7A113@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [74.75.92.114] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB243;UriScan:; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 03706074BC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(24454002)(189002)(199003)(377454003)(77096002)(2656002)(33656002)(54356999)(40100003)(92726001)(92566001)(76176999)(20776003)(85852003)(50986999)(80022003)(120916001)(19617315012)(99286002)(46102003)(122556002)(4396001)(99396003)(36756003)(85306004)(93886004)(95666004)(87936001)(110136001)(229853001)(15202345003)(76482002)(83716003)(106116001)(105586002)(101416001)(66066001)(230783001)(15975445006)(21056001)(31966008)(86362001)(97736003)(106356001)(82746002)(107046002)(19580395003)(16236675004)(19580405001)(64706001)(15395725005)(104396001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB243; H:BLUPR06MB243.namprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:3; A:3; LANG:en; Content-Type: multipart/alternative; boundary="_000_BCC05ED4DA7840B6A1DE8CDFA3CBE04Disocorg_" MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB866; X-OriginatorOrg: isoc.org Archived-At: http://mailarchive.ietf.org/arch/msg/dane/hJ5CSfEIO42tl9NGegw0PhO5TCo Cc: "" Subject: [dane] Deployment considerations - Re: draft-ietf-dane-smime X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 17:04:43 -0000 --_000_BCC05ED4DA7840B6A1DE8CDFA3CBE04Disocorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Oct 20, 2014, at 11:54 AM, Paul Hoffman > wrote: On Oct 20, 2014, at 8:23 AM, Osterweil, Eric > wrote: , so necessarily coupling the RRs doesn=92t seem to make sense. It has so far in the WG. The WG asked us early on to make as few changes as= possible to the TLSA definition. This is a key point to me. If we are to make DANE truly successful and get= DANE-related records out there widely, they need to be *easily* deployed o= ut there. Right now, for a great number of people out there, their experie= nce of adding DNS records is to go to their DNS hosting provider (or very o= ften their DNS *registrar* that is also doing the DNS hosting for them) and= enter in DNS records through some form of web interface. One of the challenges we *already* face is to get those DNS hosting provide= rs to add support for TLSA records. I just went to the "domain manager" fo= r an extremely larger registrar/hosting provider and looked at the list of = DNS records that I can add as a user: A, CNAME, MX, TXT, SPF, SRV, AAAA, N= S. No TLSA. No option I saw to edit the zone file directly. Until we can get that large DNS registrar/hosting provider to add support f= or TLSA records to the management GUI, all the people using them can't use = DANE. Given the zillion other things they want to do, I would suspect th= at it's going to take some good number of customers asking to get them to d= o so. And that's just *one* DNS hosting provider. I think it's going to be hard enough to get DNS hosting providers to add th= e TLSA record to their list of supported record types, let alone asking the= m to *also* add the SMIMEA record to the list of supported record types. B= UT... if SMIMEA is basically a renamed TLSA, then you can make that argumen= t to them "it's just the same fields you have for TLSA but with a different= name". If they have already added TLSA support, adding SMIMEA can be just= a case of re-using the code. However, if SMIMEA adds more fields then it= means the DNS hosting providers have to develop new code... and so the cas= e has to be made to all of them about why they should add yet-another-recor= d-type to their GUIs. Personally, I think it would be great if every "DANE-like" usage would just= use the TLSA record... then we have to only fight that battle once to get = it added into configuration/management GUIs. But if we are to create oth= er TLSA-like records to have different names, let's at least please keep th= em the same so that we can get them all more easily deployed. My 2 cents, Dan -- Dan York Senior Content Strategist, Internet Society york@isoc.org +1-802-735-1624 Jabber: york@jabber.isoc.org Skype: danyork http://twitter.com/danyork http://www.internetsociety.org/deploy360/ --_000_BCC05ED4DA7840B6A1DE8CDFA3CBE04Disocorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: <037FEBCC23B4FC4A8FAF0A47E12F087D@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable

On Oct 20, 2014, at 11:54 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:

On Oct 20, 2014, at 8:23 AM, Osterweil, Eric <= eosterweil@verisign.com> = wrote:

, so necessarily coupling the RRs doesn=92t seem = to make sense.  

It has so far in the WG. The WG asked us early on to make as few changes as= possible to the TLSA definition.

This is a key point to me.  If we are to make DANE truly successf= ul and get DANE-related records out there widely, they need to be *easily* = deployed out there.  Right now, for a great number of people out there= , their experience of adding DNS records is to go to their DNS hosting provider (or very often their DNS *registrar* t= hat is also doing the DNS hosting for them) and enter in DNS records throug= h some form of web interface.

One of the challenges we *already* face is to get those DNS hosting pr= oviders to add support for TLSA records.  I just went to the "dom= ain manager" for an extremely larger registrar/hosting provider and lo= oked at the list of DNS records that I can add as a user:  A, CNAME, MX, TXT, SPF, SRV, AAAA, NS.   No TLSA. &n= bsp;No option I saw to edit the zone file directly.   

Until we can get that large DNS registrar/hosting provider to add supp= ort for TLSA records to the management GUI, all the people using them can't= use DANE.    Given the zillion other things they want to do, I w= ould suspect that it's going to take some good number of customers asking to get them to do so.   And that's ju= st *one* DNS hosting provider.

I think it's going to be hard enough to get DNS hosting providers to a= dd the TLSA record to their list of supported record types, let alone askin= g them to *also* add the SMIMEA record to the list of supported record type= s.  BUT... if SMIMEA is basically a renamed TLSA, then you can make that argument to them "it's just th= e same fields you have for TLSA but with a different name".  If t= hey have already added TLSA support, adding SMIMEA can be just a case of re= -using the code.   However, if SMIMEA adds more fields then it means the DNS hosting providers have to develop new code...= and so the case has to be made to all of them about why they should add ye= t-another-record-type to their GUIs.

Personally, I think it would be great if every "DANE-like" u= sage would just use the TLSA record... then we have to only fight that batt= le once to get it added into configuration/management GUIs.    Bu= t if we are to create other TLSA-like records to have different names, let's at least please keep them the same so that we can g= et them all more easily deployed.

My 2 cents,
Dan

--
Dan York
Senior Content Strategist, Internet Socie= ty
york@iso= c.org   +1-802-735-1624
Skype: danyork   http://twitter.com/danyork


--_000_BCC05ED4DA7840B6A1DE8CDFA3CBE04Disocorg_-- From nobody Mon Oct 20 11:29:14 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B84921A8AA7 for ; Mon, 20 Oct 2014 11:29:08 -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] 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 cCx9tn4hWiOK for ; Mon, 20 Oct 2014 11:29:06 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2C761A9008 for ; Mon, 20 Oct 2014 11:29:06 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 9380A2AAC8A; Mon, 20 Oct 2014 18:29:05 +0000 (UTC) Date: Mon, 20 Oct 2014 18:29:05 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141020182905.GH19158@mournblade.imrryr.org> References: <273F9612-13AF-4CB8-B15C-912AAD04C738@verisign.com> <67BDE5B6-58C7-4E0B-8CB4-045E51027D85@ieca.com> <3473729E-BC37-48DB-9ACD-FB872CB666DE@vpnc.org> <63BF3336-C9B8-4D16-BEB7-D42EFBB7A113@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/0V2d5JbbUZXFqfeD5cs3aPM7QeM Subject: Re: [dane] Deployment considerations - Re: draft-ietf-dane-smime X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 18:29:08 -0000 On Mon, Oct 20, 2014 at 04:52:21PM +0000, Dan York wrote: > Personally, I think it would be great if every "DANE-like" usage > would just use the TLSA record... then we have to only fight that > battle once to get it added into configuration/management GUIs. > But if we are to create other TLSA-like records to have different > names, let's at least please keep them the same so that we can get > them all more easily deployed. I empathise with the sentiment, but there's a bit more to a friendly DANE record UI than the RDATA format. For TLSA, the UI would have an entry box for the port number, and radio buttons for the protocol (tcp/udp/...). For SMIMEA there would be a text field for the address localpart, which used to enter the address. If (as is almost always the case) the DNS zone is mastered from some sort of underlying database, one might even want to store the address (for friendlier search, ...) while using its sha224 hash in the SMIME label. So there may be *some* code re-use, but doing it right will likely require custom code for any additional record types with a TLSA-like RDATA. -- Viktor. From nobody Mon Oct 20 15:18:15 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CAFB1ACF05 for ; Mon, 20 Oct 2014 15:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 ydmFPID8BzRW for ; Mon, 20 Oct 2014 15:18:10 -0700 (PDT) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7ADC71ACEFE for ; Mon, 20 Oct 2014 15:18:10 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id fb4so8450858wid.6 for ; Mon, 20 Oct 2014 15:18:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=w7W8DwASCAZ0RXsPwm9VaDR4FtJ6MQSACy/GaTYdwx4=; b=hWIPvoX0LLtvpmcc7xSqM745zAXvrS7OcwrRr396tklhBHDRXQdXSW2F460hDaAmfF FEo4O6+QsxCdYmqFCse2v0bjHd4vjFZeoxA/cSj7IxizLBCFjYmXSXkWlUo/xZF/yKge QabMLIlF1aqLKT6B18UPsnUEG33mt+M6qkctrC5MINU7dLz1Xw73um6ME3Z7oTgyMSAN gWltKMqVXEGa5la3vOGwzdWjSXlFrek5UcxlS68dhEpGR8iv6Wo82R3OQMansrTM5Uyt wNLtnWkZSqxrkUrZlKpmElxUQjh8GgEnCimYeYWCBNKd2ahMccp9gQaLp1pn4YiyRGsv BkwA== X-Gm-Message-State: ALoCoQnV5inEJhY0J8FKm94cMAzgWS1MWlH6Vt9LjD6AOQ8lUwnvt9hKgB1yxEHpnxCCFUB67OQl MIME-Version: 1.0 X-Received: by 10.194.63.229 with SMTP id j5mr14371001wjs.23.1413843488871; Mon, 20 Oct 2014 15:18:08 -0700 (PDT) Received: by 10.194.77.134 with HTTP; Mon, 20 Oct 2014 15:18:08 -0700 (PDT) In-Reply-To: References: <273F9612-13AF-4CB8-B15C-912AAD04C738@verisign.com> <67BDE5B6-58C7-4E0B-8CB4-045E51027D85@ieca.com> <3473729E-BC37-48DB-9ACD-FB872CB666DE@vpnc.org> <63BF3336-C9B8-4D16-BEB7-D42EFBB7A113@vpnc.org> Date: Mon, 20 Oct 2014 15:18:08 -0700 Message-ID: From: Warren Kumari To: "Osterweil, Eric" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dane/7Z7GZ8WoNw4TBI7ue0-ejyceM60 Cc: Paul Hoffman , "" Subject: Re: [dane] draft-ietf-dane-smime X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 22:18:13 -0000 On Mon, Oct 20, 2014 at 9:46 AM, Warren Kumari wrote: > [top post at random place in thread ] > > I'd like everyone to take a breath and step back for a minute. I'd like t= o > (off list) arrange a call with Paul and Eric so we can summarize this to = be > as concise as possible and then get the WG consensus *on the actual point= s > under discussion*... > To help us focus the discussion and help us get make progress, we will be putting this conversation on hold, and discussing the requirements document - draft-osterweil-dane-ent-email-reqs-00. Eric will review the doc, revise it if necessary (along with his co-chairs) and then either post it or let us know that it is still up to date and then we'll discuss it and the requirements. This should let us make progress on this doc... Thanks to everyone for being willing to discuss this in a civil manner... w > W > > > On Monday, October 20, 2014, Osterweil, Eric > wrote: >> >> >> On Oct 20, 2014, at 11:54 AM, Paul Hoffman wrote= : >> >> > On Oct 20, 2014, at 8:23 AM, Osterweil, Eric >> > wrote: >> > >> >> TLS and S/MIME use pretty different security models (session vs. obje= ct >> >> security) >> > >> > Sure, but how is that difference relevant here? DANE is about >> > distributing certificates and keying information through DNS: it is ag= nostic >> > to the security model. >> >> The relevant information needed during distribution would seem to vary >> based on the security model (as evidenced by this thread). Actually, th= at=E2=80=99s >> been one of the main points of this thread. >> >> >> , so necessarily coupling the RRs doesn=E2=80=99t seem to make sense. >> > >> > It has so far in the WG. The WG asked us early on to make as few chang= es >> > as possible to the TLSA definition. >> >> Paul, we are all part of the working group. This is the the working >> group. I feel like I must be missing some nuanced distinction you have = in >> mind between working group discussions (like this one) and some other >> arbitration? >> >> >> In addition, to echo what others have already said on the list, I >> >> really don=E2=80=99t think it is reasonable to gate updates to the SM= IMEA proposal >> >> on updating TLSA. >> > >> > Fully agree, and that's not what I was proposing. The two changes that >> > you have proposed (revocation indication and alternate sources for get= ting >> > the information) >> >> Paul, these were not my proposals. These were proposed by Scott Rose. = I >> saw merit in them and when they seemed to be dismissed out of hand I voi= ced >> my support. Also, the proposal included the _encr + _sign labels. >> >> > can be done as new values to the existing RR subfields. Doing so would >> > make what you want usable for both SMIMEA and TLSA. Proposals to make = those >> > changes can trivially be done as stand-alone Internet Drafts. >> >> But we are still roughing out this draft. This would seem to be a good >> opportunity to try and get things write in the initial work. >> >> >>> A better process would be for the proponents to offer a standalone >> >>> draft for the idea that will be an extension that would be usable to= both >> >>> TLSA and SMIMEA and any other documents that come later. >> >> >> >> Just by looking at the list, it seems like there are a number of voic= es >> >> that disagree with you on this. >> > >> > Where "a number" means "two", and even they didn't actually disagree >> > about creating standalone drafts, simply that the assumption that the = use >> > cases might be different. >> >> I think this thread is devolving. The number is greater than two, and >> reviewing the posts of this thread should corroborate the higher level o= f >> interest. >> >> >> Also, isn=E2=80=99t the SMIMEA work still an evolving draft? >> > >> > Yes, of course. >> > >> >> What else does one need besides: articulated rationale, proposed >> >> requirements, operational data, suggested text, and running code from >> >> multiple people in order to support suggested revisions? >> > >> > Consensus in the WG. That may seem anathema to you, but it's the way >> > that the IETF works. >> >> Paul, what constituted ``the WG=E2=80=99=E2=80=99 in your mind? >> >> Eric >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane > > > > -- > I don't think the execution is relevant when it was obviously a bad idea = in > the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair of > pants. > ---maf --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Mon Oct 20 16:11:27 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39C741ACD85 for ; Mon, 20 Oct 2014 16:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.311 X-Spam-Level: X-Spam-Status: No, score=-6.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yo178IAgFTjC for ; Mon, 20 Oct 2014 16:11:10 -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 CB8061ACFBB for ; Mon, 20 Oct 2014 16:09:09 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id 2D0163493BE; Mon, 20 Oct 2014 23:09:07 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id D2BD9160069; Mon, 20 Oct 2014 23:12:14 +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 7C4B6160068; Mon, 20 Oct 2014 23:12:14 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id D062A221CDAB; Tue, 21 Oct 2014 10:09:04 +1100 (EST) To: Dan York From: Mark Andrews References: <273F9612-13AF-4CB8-B15C-912AAD04C738@verisign.com> <67BDE5B6-58C7-4E0B-8CB4-045E51027D85@ieca.com> <3473729E-BC37-48DB-9ACD-FB872CB666DE@vpnc.org> <63BF3336-C9B8-4D16-BEB7-D42EFBB7A113@vpnc.org> In-reply-to: Your message of "Mon, 20 Oct 2014 16:52:21 -0000." Date: Tue, 21 Oct 2014 10:09:04 +1100 Message-Id: <20141020230904.D062A221CDAB@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/dane/W6hsPfvwAQaeGP4-avK3sUnoigw Cc: Paul Hoffman , "" Subject: Re: [dane] Deployment considerations - Re: draft-ietf-dane-smime X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 23:11:25 -0000 In message , Dan York writes: > > > On Oct 20, 2014, at 11:54 AM, Paul Hoffman > > wrote: > > On Oct 20, 2014, at 8:23 AM, Osterweil, Eric > > wrote: > > , so necessarily coupling the RRs doesn't seem to make sense. > > It has so far in the WG. The WG asked us early on to make as few changes > as possible to the TLSA definition. > > This is a key point to me. If we are to make DANE truly successful and > get DANE-related records out there widely, they need to be *easily* > deployed out there. Right now, for a great number of people out there, > their experience of adding DNS records is to go to their DNS hosting > provider (or very often their DNS *registrar* that is also doing the DNS > hosting for them) and enter in DNS records through some form of web > interface. > > One of the challenges we *already* face is to get those DNS hosting > providers to add support for TLSA records. I just went to the "domain > manager" for an extremely larger registrar/hosting provider and looked at > the list of DNS records that I can add as a user: A, CNAME, MX, TXT, > SPF, SRV, AAAA, NS. No TLSA. No option I saw to edit the zone file > directly. > > Until we can get that large DNS registrar/hosting provider to add support > for TLSA records to the management GUI, all the people using them can't > use DANE. Given the zillion other things they want to do, I would > suspect that it's going to take some good number of customers asking to > get them to do so. And that's just *one* DNS hosting provider. > > I think it's going to be hard enough to get DNS hosting providers to add > the TLSA record to their list of supported record types, let alone asking > them to *also* add the SMIMEA record to the list of supported record > types. BUT... if SMIMEA is basically a renamed TLSA, then you can make > that argument to them "it's just the same fields you have for TLSA but > with a different name". If they have already added TLSA support, adding > SMIMEA can be just a case of re-using the code. However, if SMIMEA adds > more fields then it means the DNS hosting providers have to develop new > code... and so the case has to be made to all of them about why they > should add yet-another-record-type to their GUIs. > > Personally, I think it would be great if every "DANE-like" usage would > just use the TLSA record... then we have to only fight that battle once > to get it added into configuration/management GUIs. But if we are to > create other TLSA-like records to have different names, let's at least > please keep them the same so that we can get them all more easily > deployed. This is one of the reasons we wrote "named-rrchecker". It is a simple tool that can list out the records types it supports so you can dynamically build a list of named record types to use along side TYPE#####. The currently supported type list is: A NS MD MF CNAME SOA MB MG MR NULL WKS PTR HINFO MINFO MX TXT RP AFSDB X25 ISDN RT NSAP NSAP-PTR SIG KEY PX GPOS AAAA LOC NXT EID NIMLOC SRV ATMA NAPTR KX CERT A6 DNAME APL DS SSHFP IPSECKEY RRSIG NSEC DNSKEY DHCID NSEC3 NSEC3PARAM TLSA HIP CDS CDNSKEY SPF UINFO UID GID UNSPEC NID L32 L64 LP EUI48 EUI64 URI CAA DLV It will also parse the matching records using presentation format if that is known and unknown record format and emit the record in unknown record format and/or presentation format if that has been defined. Unknown record format means you don't have to update the name servers everytime you update named-rrchecker. This is suitable to be added to any master file or to be used as input to nsupdate. The presentation format is useful for displaying to the user what they just entered cleaned up / converted from unknown record format. You don't need to update web forms to add new types. You just update named-rrchecker periodically and the front end picks up support for the new RR type. Mark > My 2 cents, > Dan > > -- > Dan York > Senior Content Strategist, Internet Society > york@isoc.org +1-802-735-1624 > Jabber: york@jabber.isoc.org > Skype: danyork http://twitter.com/danyork > > http://www.internetsociety.org/deploy360/ -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Oct 21 14:45:48 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA111A87A7 for ; Tue, 21 Oct 2014 14:45:47 -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 IChOojvgJI6z for ; Tue, 21 Oct 2014 14:45:45 -0700 (PDT) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1FE41A87A5 for ; Tue, 21 Oct 2014 14:45:45 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id rl12so2187203iec.37 for ; Tue, 21 Oct 2014 14:45:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ZKrQY0MQIq3bKLPkT1oTUul/OyxSKy5e9Y+NwDZCpbQ=; b=J8EIkM5TJtoQcCapD3xsTJu6OPBbZBI9aaAQQNGSsqvs8sGsodxzTJR8mF6sMOycvu jflkBs0UiMQSseDSSAvPAsl/9UNZxRNBZbnenZPBvizJ7vUuY6+pFv9VVUgFbM1xDN1d fjGG+yrfEH1WOY2DTjBY4LsKQKcTYH5rrXOB2CdNb8aIZNCjXyNlwUHa++tuBE+qZyQh TVO0M3ZNfXCy4aUbut7Dz49WNZukqAttsfBdm9PyNbZ46/QE2kzCpH7QqRmlLQpvgH+Q IS08TEpbaA/puZwcPeTITu92P3lXUHJs50kl4waErM/1m8gi/xHmJe074qlXa6ukovvI 6vIQ== X-Gm-Message-State: ALoCoQkrmTVV0LlwAeanyWwdVVfMuLYY744We6G2nvzXvYr9TNdCotV75ohDzP/bTdQGaRnQsCvx X-Received: by 10.42.49.8 with SMTP id u8mr779623icf.39.1413927944801; Tue, 21 Oct 2014 14:45:44 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id b4sm6648415iod.37.2014.10.21.14.45.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 21 Oct 2014 14:45:44 -0700 (PDT) Message-ID: <5446D406.6000502@andyet.net> Date: Tue, 21 Oct 2014 15:45:42 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Paul Hoffman References: <542CB20B.4020803@andyet.net> <7D2E911A-9D78-4242-A61D-7704DE4A60D4@vpnc.org> In-Reply-To: <7D2E911A-9D78-4242-A61D-7704DE4A60D4@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/A9f47Vs3ynt0fNA7as0SPDdHTOE Cc: "" Subject: Re: [dane] DNS errors text X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 21:45:47 -0000 On 10/1/14, 8:13 PM, Paul Hoffman wrote: > On Oct 1, 2014, at 7:01 PM, Peter Saint-Andre - &yet wrote: > >> Section 2.1 of draft-ietf-dane-smtp-with-dane has some thorough text on DNS errors. Viktor suggested that draft-ietf-dane-srv needs the same text. I would strongly prefer NOT to have the same text in two documents for various reasons. When I mentioned this to the chairs, they suggested moving the text from the SMTP document to the SRV document since it is more generic. I don't really care where it lives, I just want it to be in one place. What do WG participants think? > > As long as the SMTP document points to the SRV document for the errors, it's fine to have it live in the SRV document. Matt and I talked about this, and we're more comfortable with having this text live in the SMTP document and pointing there from the SRV document. Viktor cares more and knows more about this topic than the dane-srv authors, so we think it's best to leave things as-is. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Tue Oct 21 15:01:24 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 556431A8821; Tue, 21 Oct 2014 15:01:20 -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] 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 K3Wmwv0lGv_o; Tue, 21 Oct 2014 15:01:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F68A1A8827; Tue, 21 Oct 2014 15:01:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141021220118.26102.13809.idtracker@ietfa.amsl.com> Date: Tue, 21 Oct 2014 15:01:18 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/1Cofr4qnv2aRYKsDp2ekYm6PfKA Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-srv-08.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 22:01:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF. Title : Using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records Authors : Tony Finch Matthew Miller Peter Saint-Andre Filename : draft-ietf-dane-srv-08.txt Pages : 13 Date : 2014-10-21 Abstract: The DANE specification (RFC 6698) describes how to use TLSA resource records in the DNS to associate a server's host name with its TLS certificate, where the association is secured with DNSSEC. However, application protocols that use SRV records (RFC 2782) to indirectly name the target server host names for a service domain cannot apply the rules from RFC 6698. Therefore this document provides guidelines that enable such protocols to locate and use TLSA records. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-srv/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dane-srv-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-srv-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Oct 25 22:56:55 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60C9B1A1BD4; Sat, 25 Oct 2014 22:56:53 -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] 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 JCR5r1emX9Js; Sat, 25 Oct 2014 22:56:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 634051A1BDF; Sat, 25 Oct 2014 22:56:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141026055651.8385.72359.idtracker@ietfa.amsl.com> Date: Sat, 25 Oct 2014 22:56:51 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/r3hTZfpuOlmnXAhR0lr4XtjMJ_Y Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-ops-07.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 05:56:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF. Title : Updates to and Operational Guidance for the DANE Protocol Authors : Viktor Dukhovni Wes Hardaker Filename : draft-ietf-dane-ops-07.txt Pages : 29 Date : 2014-10-25 Abstract: This memo clarifies and updates the DNS-Based Authentication of Named Entities (DANE) TLSA specification based on subsequent implementation experience. It also contains guidance for implementers, operators and protocol developers who want to make use of DANE records. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-ops/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dane-ops-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-ops-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Oct 25 23:03:12 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEAAC1A1B97; Sat, 25 Oct 2014 23:03:07 -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] 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 sbPxJASm9Vya; Sat, 25 Oct 2014 23:03:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D3DFA1A6F66; Sat, 25 Oct 2014 23:03:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141026060303.6189.59468.idtracker@ietfa.amsl.com> Date: Sat, 25 Oct 2014 23:03:03 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/skrwztvTrq_zopXTn53315KDMNU Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-smtp-with-dane-13.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 06:03:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF. Title : SMTP security via opportunistic DANE TLS Authors : Viktor Dukhovni Wes Hardaker Filename : draft-ietf-dane-smtp-with-dane-13.txt Pages : 33 Date : 2014-10-25 Abstract: This memo describes a downgrade-resistant protocol for SMTP transport security between Mail Transfer Agents (MTAs) based on the DNS-Based Authentication of Named Entities (DANE) TLSA DNS record. Adoption of this protocol enables an incremental transition of the Internet email backbone to one using encrypted and authenticated Transport Layer Security (TLS). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-smtp-with-dane/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-smtp-with-dane-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 27 13:47:20 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 619311A8769; Mon, 27 Oct 2014 13:47:01 -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] 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 2OzgeDzwiBx8; Mon, 27 Oct 2014 13:47:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4231A1A3B; Mon, 27 Oct 2014 13:47:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: paul.hoffman@vpnc.org,jakob@kirei.se X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027204700.21058.56247.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 13:47:00 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/iOBwACwfkuYghDv6JBwSiCZvMNI Cc: dane@ietf.org, Kathleen.Moriarty.ietf@gmail.com, ipr-announce@ietf.org Subject: [dane] IPR Disclosure: Verisign Inc.'s Statement about IPR related to draft-ietf-dane-smime-07 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 20:47:01 -0000 Dear Paul E. Hoffman, Jakob Schlyter: An IPR disclosure that pertains to your Internet-Draft entitled "Using Secure DNS to Associate Certificates with Domain Names For S/MIME" (draft-ietf-dane- smime) was submitted to the IETF Secretariat on 2014-10-27 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2468/). The title of the IPR disclosure is "Verisign Inc.'s Statement about IPR related to draft-ietf-dane-smime-07.""); The IETF Secretariat From nobody Mon Oct 27 15:56:14 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CBFE1A19E4 for ; Mon, 27 Oct 2014 15:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 I5KO7qoQwjFV for ; Mon, 27 Oct 2014 15:56:02 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0099.outbound.protection.outlook.com [207.46.100.99]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9929F1A1BF0 for ; Mon, 27 Oct 2014 15:55:34 -0700 (PDT) Received: from BLUPR06MB243.namprd06.prod.outlook.com (10.242.191.154) by BLUPR06MB244.namprd06.prod.outlook.com (10.242.191.153) with Microsoft SMTP Server (TLS) id 15.1.6.9; Mon, 27 Oct 2014 22:55:31 +0000 Received: from BLUPR06MB243.namprd06.prod.outlook.com ([169.254.7.249]) by BLUPR06MB243.namprd06.prod.outlook.com ([169.254.7.249]) with mapi id 15.01.0006.000; Mon, 27 Oct 2014 22:55:31 +0000 From: Dan York To: IETF DANE Mailinglist Thread-Topic: New Version Notification for draft-york-dane-deployment-observations-00.txt Thread-Index: AQHP8jjOFMsq3jadb06FZXJoaiV9rA== Date: Mon, 27 Oct 2014 22:55:31 +0000 Message-ID: References: <20141027225310.29285.24437.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [2604:6000:9fc0:53:801e:5527:2cfe:8df6] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB244; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 0377802854 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(377454003)(2473001)(377424004)(199003)(189002)(82746002)(19580405001)(95666004)(77096002)(16601075003)(15975445006)(83716003)(101416001)(19580395003)(50986999)(120916001)(99286002)(99396003)(230783001)(21056001)(16236675004)(14971765001)(87936001)(76482002)(40100003)(122556002)(85306004)(85852003)(15202345003)(54356999)(92566001)(92726001)(19617315012)(107886001)(64706001)(107046002)(2656002)(110136001)(31966008)(46102003)(36756003)(106356001)(33656002)(97736003)(4396001)(106116001)(80022003)(86362001)(105586002)(20776003)(76176999)(104396001)(3826002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB244; H:BLUPR06MB243.namprd06.prod.outlook.com; FPR:; MLV:ovrnspm; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_F0C0FC32FAA74D07A23059A538754BCDisocorg_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org Archived-At: http://mailarchive.ietf.org/arch/msg/dane/yyPStDhVbDz_SwmVAiOmBViURec Subject: [dane] Fwd: New Version Notification for draft-york-dane-deployment-observations-00.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 22:56:08 -0000 --_000_F0C0FC32FAA74D07A23059A538754BCDisocorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Since I had put in a request for agenda time at IETF 91 to potentially talk= about if there were any lessons from DANE deployment that could be fed bac= k into the standards process, I did throw together a quick draft... Feedback is very definitely welcome... I'm not intending anything with this= document other than using it as a catalyst for discussions. Dan Begin forwarded message: From: > Subject: New Version Notification for draft-york-dane-deployment-observatio= ns-00.txt Date: October 27, 2014 6:53:10 PM EDT To: Dan York >, "york@isoc.org" > A new version of I-D, draft-york-dane-deployment-observations-00.txt has been successfully submitted by Dan York and posted to the IETF repository. Name: draft-york-dane-deployment-observations Revision: 00 Title: DANE Deployment Observations Document date: 2014-10-27 Group: Individual Submission Pages: 4 URL: http://www.ietf.org/internet-drafts/draft-york-dane-deploym= ent-observations-00.txt Status: https://datatracker.ietf.org/doc/draft-york-dane-deployment= -observations/ Htmlized: http://tools.ietf.org/html/draft-york-dane-deployment-obser= vations-00 Abstract: This document provides some observations about the deployment of the DANE protocol to date and some questions for discussion on the DANE mailing list and potentially at the IETF 91 meeting of the DANE Working Group. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_F0C0FC32FAA74D07A23059A538754BCDisocorg_ Content-Type: text/html; charset="us-ascii" Content-ID: <5654499FC388FE4C8E1ECA0B5C508A14@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Since I had put in a request for agenda time at IETF 91 to potentially talk= about if there were any lessons from DANE deployment that could be fed bac= k into the standards process, I did throw together a quick draft...

Feedback is very definitely welcome... I'm not intending anything with= this document other than using it as a catalyst for discussions.

Dan


Begin forwarded message:

From: <<= a href=3D"mailto:internet-drafts@ietf.org">internet-drafts@ietf.org>=
Subject: Ne= w Version Notification for draft-york-dane-deployment-observations-00.txt
Date: Octob= er 27, 2014 6:53:10 PM EDT
To: Dan Y= ork <york@isoc.org>, "york@isoc.org" <york@isoc.org>


A new version of I-D, draft-york-dane-deployment-observations-00.txt
has been successfully submitted by Dan York and posted to the
IETF repository.

Name: draft-york-dane-= deployment-observations
Revision: 0= 0
Title: DANE Deployment= Observations
Document date: 2014-10-27
Group: Individual Subm= ission
Pages: 4
URL:            http://www.ietf.org/internet-drafts/draft-york-dane-deploym= ent-observations-00.txt
Status:         https://= datatracker.ietf.org/doc/draft-york-dane-deployment-observations/
Htmlized:       http://tools.ietf.org/= html/draft-york-dane-deployment-observations-00


Abstract:
  This document provides some observations about the deployment o= f the
  DANE protocol to date and some questions for discussion on the = DANE
  mailing list and potentially at the IETF 91 meeting of the DANE=
  Working Group.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--_000_F0C0FC32FAA74D07A23059A538754BCDisocorg_-- From nobody Mon Oct 27 16:32:40 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 768D91A802B for ; Mon, 27 Oct 2014 16:32:35 -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] 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 BQ21vcdL4PUb for ; Mon, 27 Oct 2014 16:32:26 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DAC81A7035 for ; Mon, 27 Oct 2014 16:32:26 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 0041D2AB219; Mon, 27 Oct 2014 23:32:23 +0000 (UTC) Date: Mon, 27 Oct 2014 23:32:23 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141027233223.GL19158@mournblade.imrryr.org> References: <20141027225310.29285.24437.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/stWdvq7m1I8ig0qZ-WHjKC4ZKE0 Subject: Re: [dane] Fwd: New Version Notification for draft-york-dane-deployment-observations-00.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 23:32:36 -0000 On Mon, Oct 27, 2014 at 10:55:31PM +0000, Dan York wrote: > Since I had put in a request for agenda time at IETF 91 to > potentially talk about if there were any lessons from DANE deployment > that could be fed back into the standards process, I did throw > together a quick draft... > > Feedback is very definitely welcome... I'm not intending anything > with this document other than using it as a catalyst for discussions. I periodically data-mine domains that have deployed DANE TLSA for SMTP and have used one of the testing sites that keeps a public log of tested domains (users can opt-out of the public log, but many don't). Out of ~280 domains that have TLSA RRs, 10 or so had erroneous records: * Some records did not bear any relation to either the certificate or the public key of anything in the server's certificate chain. In some cases this was after a key rotation without the pre-requisite DNS updates. * Some domains got the usage or selector wrong. For example, "2 1 1" instead of "3 1 1" or "3 0 1" instead of "3 1 1", with the associated data otherwise be correct. * Some domains have usage "1", even though this is not compatible with SMTP. Less serious is that some domains publish only "3 1 2" records, even though in 6698 only SHA2-256 is a "MUST IMPLEMENT" so presumably SHA2-512 might not always work (likely rare in practice). Finally, some domains have bleeding edge elliptic curve DNSKEY RRs (P-384 which is algorithm 14 IIRC), which at least my validating resolver does not support, so they appear unsigned. Perhaps insufficient guidance on BCP algorithms for DNSSEC. I've reached out to Shumon Huque, and he updated his site to generate "3 1 1" records by default, and added a reference to the SMTP draft at the foot of the page. What would be even more helpful is a site that not only tests DNSSEC validation and checks for the presence of TLSA RRs, but also connects to the domain's MX hosts and reports whether the TLSA RRs match reality! I may end up partnering with some folks to build this, but if anyone wants to do it for us, that would be great. A 3-4% error rate in deploying TLSA records is too high, we need better deployment validation tools. And more prominent guidance to pick just either of "2 0 1" or "3 1 1" for SMTP. I'm also considering releasing a tool that validates a server's off-line chain file against an off-line TLSA RRset. This would allow folks to test before they break their server, rather than immediately after. -- Viktor. From nobody Mon Oct 27 16:36:42 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 529F41A86E7; Mon, 27 Oct 2014 16:36:37 -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] 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 EKwM8fkNglDQ; Mon, 27 Oct 2014 16:36:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D18C1A854D; Mon, 27 Oct 2014 16:36:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027233634.2254.98590.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 16:36:34 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/MQl6hGiCzxVKDnAlaUlUbmZs2Ck Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-openpgpkey-usage-01.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 23:36:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF. Title : Best Common Practise for using OPENPGPKEY records Author : Paul Wouters Filename : draft-ietf-dane-openpgpkey-usage-01.txt Pages : 8 Date : 2014-10-27 Abstract: The OPENPGPKEY DNS Resource Record can be used to match an email address to an OpenPGP key. This document specifies a Best Common Practise ("BCP") for email clients, MUA's and MTA's for using the OPENPGPKEY DNS Resource Record. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey-usage/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dane-openpgpkey-usage-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-openpgpkey-usage-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 27 16:36:51 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC8E1A86FF; Mon, 27 Oct 2014 16:36:43 -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] 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 ONL-MYWiq9gT; Mon, 27 Oct 2014 16:36:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 50D121A86EC; Mon, 27 Oct 2014 16:36:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027233636.24734.41333.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 16:36:36 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/qOcPUxbqthqbNIvV-LxLmbm7VCQ Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-openpgpkey-01.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 23:36:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF. Title : Using DANE to Associate OpenPGP public keys with email addresses Author : Paul Wouters Filename : draft-ietf-dane-openpgpkey-01.txt Pages : 8 Date : 2014-10-27 Abstract: OpenPGP is a message format for email (and file) encryption, that lacks a standarized lookup mechanism to obtain OpenPGP public keys. This document specifies a standarized method for securely publishing and locating OpenPGP public keys in DNS using a new OPENPGPKEY DNS Resource Record. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dane-openpgpkey-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-openpgpkey-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Oct 29 09:18:51 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6A0A1A1AE9 for ; Wed, 29 Oct 2014 09:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-N9yir54M5G for ; Wed, 29 Oct 2014 09:18:48 -0700 (PDT) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F80E1A1AE3 for ; Wed, 29 Oct 2014 09:18:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id EDBD9602D7; Wed, 29 Oct 2014 17:18:43 +0100 (CET) X-Virus-Scanned: amavisd-new at stroeder.com Received: from srv1.stroeder.com ([127.0.0.1]) by localhost (srv1.stroeder.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCcYlx_Fm10J; Wed, 29 Oct 2014 17:18:39 +0100 (CET) Received: from [10.1.0.2] (unknown [10.1.0.2]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client CN "michael@stroeder.com", Issuer "StartCom Class 1 Primary Intermediate Client CA" (verified OK)) by srv1.stroeder.com (Postfix) with ESMTPS id 4D56960279; Wed, 29 Oct 2014 16:18:39 +0000 (UTC) Message-ID: <5451135E.5080307@stroeder.com> Date: Wed, 29 Oct 2014 17:18:38 +0100 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26.1 MIME-Version: 1.0 To: Dan York , IETF DANE Mailinglist References: <20141027225310.29285.24437.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070201020701070603060908" Archived-At: http://mailarchive.ietf.org/arch/msg/dane/8VZ_ZIyYBBAfOyiWS5cHMX40qTI Subject: Re: [dane] Fwd: New Version Notification for draft-york-dane-deployment-observations-00.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 16:18:50 -0000 This is a cryptographically signed message in MIME format. --------------ms070201020701070603060908 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dan York wrote: > Since I had put in a request for agenda time at IETF 91 to potentially = talk > about if there were any lessons from DANE deployment that could be fed = back > into the standards process, I did throw together a quick draft... >=20 > Feedback is very definitely welcome... I'm not intending anything with = this > document other than using it as a catalyst for discussions. IMO lack of really secure DNSSEC support is *the* major blocker. So I dis= agree with your comment at the end of section 2. And I have some personal security concerns about the DNSSEC auto-signing = many sites seem to implement and the security of registry (web) interfaces. I'= m pretty sure attackers will go that route just like they attacked registry= (web) interfaces of X.509-based PKI implementations. Also I don't like inventing a bunch of DNS RR types for different purpose= s. Ciao, Michael. --------------ms070201020701070603060908 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMgTCC BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6 qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95 m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy 6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9 sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t 5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGRTCCBS2gAwIBAgIDC01QMA0GCSqGSIb3DQEB BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTQwOTIzMjA0NzU1 WhcNMTUwOTI0MjIwNTE4WjBfMRkwFwYDVQQNExA2TTJZN2k5ekR0ZTZqVXcwMR0wGwYDVQQD DBRtaWNoYWVsQHN0cm9lZGVyLmNvbTEjMCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRl ci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKcgfT19Tn3u/h+Di7CoUk M9TFAdX2rGt8z9ze95K0/JiXQmiuooesP6F8I1n5OjLrk031/287bpaecugMX4UTYORCLrWJ OArmNlOvl0kbVZCSTr3xQ1Y7zuVRYFFhiJQzvALd6TYTSvNH32ojETh0b3DCzX0Xcoom803y 0xPKg/DlWTDirHZJbnhYQEzHugJcEhk88MPyi+V53q8NXB5VJphcVRuTFsolHzsyyKHfgFr5 wzlIAdA1DXWNpImMV6ptCdeN/ScRKe+jRchyRz3DbjTDeNyC7pvlIhAEja+/lNoi/u8qo2TS j5wZz02cLDn/EP84AH0CP+oNxro2F4cJAgMBAAGjggLaMIIC1jAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFOPPUGEQ tk7fMQl+ZlDgj5zo0JciMB8GA1UdIwQYMBaAFFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB8GA1Ud EQQYMBaBFG1pY2hhZWxAc3Ryb2VkZXIuY29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEE AYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGlj eS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRo ZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBw b2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBs aWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6Ap oCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEB BIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3Mx L2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMv c3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAB8HJ30IRnmli5Frde4TnF4mgikOiXbYDWYga 5GrFoEUi6aaYOhiv+1WAWh3/d69Ak75p3xPnCmihjjbYeQc3hrVQju6MIpxT8+tBLGa/bwAC yXgWj8idjWdIWMzLxjCPcQb4R2PVmkKTNNE0ZmMFrpSPtRjtRbvWRhxJ0IF7y9z1mLfo6cca RdE5YiKLfAEosMRmrGSfDQKP1NPLmXKWVjPIeS7hpcsM+GJitPOFaLCBibB5ou9b/KphWwdG lby53Oo6vrG9RVy5GZ8xMQ0ztFKVFlXDb7n4j7OfuOo6utQs7UU/sujlw+KWwylIw7Cgmc8t CA1m9c48U7pVoMI5ujGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2ln bmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBD bGllbnQgQ0ECAwtNUDAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xNDEwMjkxNjE4MzhaMCMGCSqGSIb3DQEJBDEWBBTRTdNORSvD Mn1qYZLhbgPunsE3czBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQME AQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIH MA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQIDC01QMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFy eSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMLTVAwDQYJKoZIhvcNAQEBBQAEggEAGUK8I9Ph zRy5P2w6pdg9KBhFOnmjQ3r4TsJfmzXYsCz0WSoC93CbzuQj2a/VdEG9EEEyEyLY55k36ho3 xZdvUIY2t8vffpUpKj9Ia8kCMf2cjbZ6Noqu43MMKzy8hzSTmCQWJjXqpUuHCzVfHB0ltDdT 12on6hsV6IujV5+u5TRoJcIYEFhn/J+hPojnbw68IZAbxuzUDcebWER7Q/8O3nZeKIfh3+bl nss2fguvmnqcskF5KUHRboj/V3m4M1jgD0XMwaZ5W8/kmXJUjJgQWkh7gNnzj8Q1pFVd0VOG GRzezgxBh9xPJC8th2C+06wBOqmM/dhc85D1HR+HUj85UQAAAAAAAA== --------------ms070201020701070603060908-- From nobody Fri Oct 31 07:47:28 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0AE21A903E for ; Fri, 31 Oct 2014 07:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.079 X-Spam-Level: X-Spam-Status: No, score=-3.079 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URI_HEX=1.122] 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 2Xbkmyv-uX4a for ; Fri, 31 Oct 2014 07:47:22 -0700 (PDT) Received: from exprod6og110.obsmtp.com (exprod6og110.obsmtp.com [64.18.1.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C15B1A9067 for ; Fri, 31 Oct 2014 07:47:22 -0700 (PDT) Received: from brn1lxmailout01.verisign.com ([72.13.63.41]) (using TLSv1) by exprod6ob110.postini.com ([64.18.5.12]) with SMTP ID DSNKVFOg+TERfjCdo6q8ZMso6pyrNT+rj4QN@postini.com; Fri, 31 Oct 2014 07:47:22 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id s9VElK8T032296 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 31 Oct 2014 10:47:20 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Fri, 31 Oct 2014 10:47:20 -0400 From: "Osterweil, Eric" To: dane WG list Thread-Topic: [dane] draft-ietf-dane-smime Thread-Index: AQHP2+CXduy9obN06UaH3lWvHXXI5ZxKvpuA Date: Fri, 31 Oct 2014 14:47:19 +0000 Message-ID: <39C76846-F695-435D-9A5C-6989D06E9573@verisign.com> References: <273F9612-13AF-4CB8-B15C-912AAD04C738@verisign.com> In-Reply-To: <273F9612-13AF-4CB8-B15C-912AAD04C738@verisign.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="Windows-1252" Content-ID: <77546F13CBEF0C4BB25504C5BBBA4F28@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/VVOVTFpt2HKFwpc21zOuubKes7s Subject: Re: [dane] draft-ietf-dane-smime X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 14:47:27 -0000 Hey again everyone, The thread has calmed down a little bit, and I just wanted to add one more = attempt to find a middle-ground to this thread: the initial message (below)= included suggested text. Later in the thread, there were some suggested m= odifications. Thanks to all of those who spent time thinking about this an= d offered suggestions! I=92ve taken a couple of minutes to incorporate fee= dback, and here is some revised suggested text: On Sep 29, 2014, at 8:26 AM, Osterweil, Eric wrot= e: > Hey everyone, >=20 > Based on our implementation experience we would like to suggest that the = following text (taken from Scott Rose's email: http://www.ietf.org/mail-arc= hive/web/dane/current/msg06180.html ) be incorporated into the current vers= ion of the draft-ietf-dane-smime document. We are sending text (below), bu= t at a high-level, the text outlines a few useful additions: >=20 > 1 - Usage #4 (reject) is likely to be very important. This could either = emphasize the difference between saying, ``don't use this cert for this ope= ration,'' and ``this cert is universally revoked'' or be used to selectivel= y override an organization-wide TA for certain employees that have left the= organization. >=20 > 2 - The certificate access field (Section 2.1.4) would enable alternate d= iscovery mechanisms that could help aid incremental deployment and transiti= on schemes. For example, while cutting over to a DANE solution, some enter= prises may want to transition users from (say) AD to DANE, and this field w= ould enable that. >=20 > 3 - The ``_encr'' and ``_sign'' labels are excellent additions to the man= agement of zone sizes and lookup sizes. Rather than querying for all keys = and then locally selecting from them, I (as an RP) likely already know whic= h of these I want, and I should be able to look them up separately in DANE = (and owners should be able to manage them separately in DANE). . . . 2.1. SMIMEA RDATA Fields The RDATA for the SMIMEA RR consists of a one-octet certificate usage field, a one-octet selector field, a one-octet matching type field, a one-octet certificate access field, and the certificate association data field. 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cert. Usage | Selector | Matching Type | Cert. Access | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / Certificate Association Data / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.1.1. The Certificate Usage Field A one-octet value, called "certificate usage", specifies the provided association that will be used to validate the certificate. This value will be defined in a new IANA registry in order to make it easier to add additional certificate usages in the future. Four of the initial usages defined in this document are similar to the first four TLSA [RFC6698] certificate usages. The certificate usage values are: 0 or PKIX-CA -- PKIX-CA is used to specify a CA certificate, or the public key of such a certificate, that MUST be found in any of the PKIX certification paths for the user. This certificate usage is sometimes referred to as "CA constraint" because it limits which CA can be used to issue certificates for a given user. The presented certificate MUST pass PKIX certification path validation, and a CA certificate that matches the SMIMEA record MUST be included as part of a valid certification path. Because this certificate usage allows both trust anchors and CA certificates, the certificate might or might not have the basicConstraints extension present. 1 or PKIX-EE -- PKIX-EE is used to specify an end entity certificate, or the public key of such a certificate, that MUST be matched with the end entity certificate for the SMIME user. This certificate usage is sometimes referred to as "user certificate constraint" because it limits which end entity certificate can be used by a given user. The target user certificate MUST pass PKIX certification path validation and MUST match the SMIMEA record. 2 or DANE-TA -- DANE-TA is used to specify a certificate, or the public key of such a certificate, that MUST be used as the trust anchor when validating the SMIME user certificate. This certificate usage is sometimes referred to as "trust anchor assertion" and allows a domain name administrator to specify a new trust anchor -- for example, if the domain issues its own certificates under its own CA that is not expected to be in the end users' collection of trust anchors. The target user certificate MUST pass PKIX certification path validation, with any certificate matching the SMIMEA record considered to be a trust anchor for this certification path validation. 3 or DANE-EE -- DANE-EE is used to specify a certificate, or the public key of such a certificate, that MUST match the SMIME user's certificate. This certificate usage is sometimes referred to as "domain-issued certificate" because it allows for a domain name administrator to issue certificates for a domain without involving a third-party CA. The target user certificate MUST match the SMIMEA record. The difference between certificate usage 1 and certificate usage 3 is that certificate usage 1 requires that the certificate pass PKIX validation, but PKIX validation is not tested for certificate usage 3. 4 or REJECT -- REJECT is used by the domain owner to assert that at the time of querying the DNS, this user's certificate MUST be=20 considered invalid for the requested function (i.e. signature or encrypt= ion). =20 This is a stronger assertion than a failed certificate validation check. Possible usage scenarios include de-authorizing stale employee credentia= ls by selectively overriding TAs that are used to authorize entire organiza= tions. The certificate usages defined in this document explicitly only apply to PKIX-formatted certificates in DER encoding [ITU.X690.2002]. If SMIME allows other formats later, or if extensions to this RR type are made that accept other formats for certificates, those certificates will need their own certificate usage values. 2.1.2. The Selector Field A one-octet value, called "selector", specifies which part of the SMIME certificate presented by the server will be matched against the association data. This value will be defined in a new IANA registry. The selectors defined in this document are: 0 or CERT -- Full certificate: the Certificate binary structure as defined in [RFC5280]. 1 or SPKI -- SubjectPublicKeyInfo: DER-encoded binary structure as defined in [RFC5280]. (Note that the use of "selector" in this document is completely unrelated to the use of "selector" in DomainKeys Identified Mail (DKIM) [RFC6376].) 2.1.3. The Matching Type Field A one-octet value, called "matching type", specifies how the certificate association is presented. This value will be defined in a new IANA registry. The types defined in this document are: 0 or Full -- Exact match on selected content 1 or SHA2-256 -- SHA-256 hash of selected content [RFC6234] 2 or SHA2-512 -- SHA-512 hash of selected content [RFC6234] If the SMIMEA record's matching type is a hash, having the record use the same hash algorithm that was used in the signature in the certificate (if possible) will assist clients that support a small number of hash algorithms. 2.1.4. Certificate Access Field This one octet value indicates an alternative method for certificate discovery. Some domain owners may not want to publish user certificates via DNS but may want to use the DNS to advertise the means to access them. If full user certificates are not included in the Certificate Association Data this field MAY be used to indicate how the user's certificate can be obtained. The RDATA certificate association data MUST be used to validate certificates obtained by the alternative method. 0 or NO: No alternative method advertised. 1 or NAPTR : NAPTR record available. The same domain name used for this SMIMEA request MAY be used again with type NAPTR [RFC3403] to retrieve the URI for certificate access. 2 or WF: X.509 certificates available in WebFinger [RFC7033]. 2.1.5. The Certificate Association Data Field This field specifies the "certificate association data" to be matched. These bytes are either raw data (that is, the full certificate or its SubjectPublicKeyInfo, depending on the selector) for matching type Full (0), or the hash of the raw data for matching types SHA2-256 (1) and SHA2-512 (2). The data refers to the certificate in the association, not to the ASN.1 Certificate object. For certificate usage type REJECT (4) at least one byte of data is REQUIRED but the value MUST be ignored. 2.2. SMIMEA RR Presentation Format The presentation format of the RDATA portion (as defined in [RFC1035]) is as follows: o The certificate usage field MUST be represented either as a certificate usage mnemonic or an 8-bit unsigned integer. o The selector field MUST be represented either as a selector field mnemonic or an 8-bit unsigned integer. o The matching type field MUST be represented either as a matching type mnemonic or an 8-bit unsigned integer. o The certificate access field MUST be represented either as a certificate access mnemonic or an 8-bit unsigned integer. o The certificate association data field MUST be represented as a string of hexadecimal characters. Whitespace is allowed within the string of hexadecimal characters, as described in [RFC1035]. Where practical, the mnemonic form SHOULD be used in order to provide clarity. 2.3. SMIMEA RR Examples In the following examples, the domain name is formed using the rules in Section 3. An example of a hashed (SHA2-256) association of a Full PKIX-CA certificate in the PKIX validation path of a certificate used to validate a signed S/MIME message. No alternative certificate access is advertised. 1c190a039a9c355fba9eb653eb52cd64e2fbe76db2588fc5a2b5c5d4._sign._smimecer= t.example.com. IN SMIMEA ( 0 0 1 0 d2abde240d7cd3ee6b4b28c54df034b9 7983a1d16e8a410e4561cb106618e971 ) Alternatively 1c190a039a9c355fba9eb653eb52cd64e2fbe76db2588fc5a2b5c5d4._sign._smimecer= t.example.com. IN SMIMEA ( PKIX-CA FULL SHA2-256 NO d2abde240d7cd3ee6b4b28c54df034b9 7983a1d16e8a410e4561cb106618e971 ) An example resource record providing Full self-signed encryption certificate: 1c190a039a9c355fba9eb653eb52cd64e2fbe76db2588fc5a2b5c5d4._encr._smimecer= t.example.com. IN SMIMEA ( DANE-EE Cert Full NO 30820307308201efa003020102020... ) An example of resource record invalidating all digital signatures by identified user: 1c190a039a9c355fba9eb653eb52cd64e2fbe76db2588fc5a2b5c5d4._sign._smimecer= t.example.com. IN SMIMEA ( REJECT Cert Full NO 00 ) ... 3. Domain Names for S/MIME Certificate Associations SMIMEA domain names include function and user labels. The purpose is to identify the function specific certificate if a user has multiple certificates. Alias MAY be used if a user has a common certificate for both functions ... 3.1. Domain Name Preparation Domain names are prepared for requests in the following manner. 1. The user name (the "left-hand side" of the email address, called the "local-part" in the mail message format definition [RFC5322] and the "local part" in the specification for internationalized email [RFC6530]), is encoded with Base32 [RFC4648], to become the left-most label in the prepared domain name. This does not include the "@" character that separates the left and right sides of the email address. 2. The second left-most label is the function specific label segment. It is selected based on the S/MIME function the MUA is performing. Values are: "_encr" for obtaining or validating a certificate or public key to be used to encrypt a message. "_sign" for certificate validation data to verify a digital signature. For certificate use cases XXXX-EE (1 and 3) the function specific label SHOULD be consistent with the Key Usage field (defined in section 4.2.1.3 of [RFC5280]) of the associated certificate. 3. The string "_smimecert" becomes the third left-most label in the prepared domain. The function specific label segment is separate to enable delegation of a single _smimecert zone cut. 4. The domain name (the "right-hand side" of the email address, called the "domain" in [RFC5322]) is appended to the result of step 3 to complete the prepared domain name. ... 3.2. Domain Name Examples Example 1. Signature certificate verification: to request an SMIMEA resource record to verify a signature certificate for a user whose address is "alice@example.com", you would use: "df7f0c341e185f1073a2caef0d37a8b6a11fac62f46beaf459532bb0._sign._s= mimecert.example.com" Example 2. Encryption key discovery: to request an SMIMEA resource record for encrypting an email to user "bob@example.com" you would use: "550c233eeabd0f03bb42b99956efa56cdadaef7d346a04e351ac1b7a._encr._s= mimecert.example.com" 4. Use of SMIMEA Records in SMIME SMIMEA records are used to publish user certificates or validate user certificates acquired by other means. Typically these use cases are associated with message encryption and signature validation processes respectively. Section 2.1 of this document defines the mandatory matching rules for the data. Where possible, consistency with [RFC6698] is maintained. 4.1. Usable Certificate Associations An implementation of this protocol makes a DNS query for SMIMEA records, validates these records using DNSSEC, and uses the resulting SMIMEA records and validation to modify S/MIME message processing behavior. Determining whether an SMIMEA RRSet can be used MUST be based on the DNSSEC validation state (as defined in [RFC4035]). o An SMIMEA RRSet whose DNSSEC validation state is secure MUST be used as a certificate association for S/MIME unless a local policy would prohibit the use of the specific certificate association in the secure SMIMEA RRSet. o If the DNSSEC validation state on the response to the request for the SMIMEA RRSet is bogus then the RRSet MUST be disregarded and considered unusable. Additional SMIMEA queries may be initiated. o If the DNSSEC validation state is indeterminate or insecure then the SMIMEA RRSet MUST be disregarded and considered unusable. MUAs that rely on another entity to perform the DNSSEC signature validation SHOULD use a secure mechanism between themselves and the validator. Examples of secure transports to other hosts include TSIG [RFC2845], SIG(0) [RFC2931], and IPsec [RFC6071]. Note that it is not sufficient to use secure transport to a DNS resolver that does not do DNSSEC signature validation. If a certificate association contains a certificate usage, selector, or matching type that is not understood by the MUA, that certificate association MUST be considered unusable. If the comparison data for a certificate is malformed, the certificate association MUST be considered unusable. If a certificate association contains a matching type or certificate association data that uses a cryptographic algorithm that is considered too weak for the MUA's local policy, the certificate association MUST be considered unusable. If a MUA receives zero usable certificate associations from a DNS request or from its cache, it processes S/MIME requests in the normal fashion without any input from the SMIMEA records. If a MUA performing certificate validation receives one or more usable certificate associations then it MUST attempt to match each certificate association with the user's certificate until a successful match is found. If no certificate associations match then the certificate MUST be considered invalid. If a MUA makes an SMIMEA request for an encryption certificate and the response includes more than one valid certificate, the certificate with the most recent "Not Before" data SHOULD be selected. [ Are there better criteria? ] ... 6. IANA Considerations 6.1. SMIMEA RRtype This document uses a new DNS RR type, SMIMEA, whose value will be allocated by IANA from the Resource Record (RR) TYPEs subregistry of the Domain Name System (DNS) Parameters registry. 6.2. SMIMEA Certificate Usage Registry This document creates a new registry, "SMIMEA Certificate Usages". The registry policy is "RFC Required". The initial entries in the registry are: +-------+----------+--------------------------------+-------------+ | Value | Mnemonic | Short Description | Reference | +-------+----------+--------------------------------+-------------+ | 0 | PKIX-CA | CA constraint | [this doc] | | 1 | PKIX-EE | Service certificate constraint | [this doc] | | 2 | DANE-TA | Trust anchor assertion | [this doc] | | 3 | DANE-EE | Domain-issued certificate | [this doc] | | 4 | REJECT | Invalid Certificate or User | [this doc] | | 5-254 | | Unassigned | | | 255 | PrivCert | Reserved for Private Use | [this doc] | +-------+----------+--------------------------------+-------------+ Applications to the registry can request specific values that have yet to be assigned. 6.3. SMIMEA Selectors This document creates a new registry, "TLSA Selectors". The registry policy is "Specification Required". The initial entries in the registry are: +-------+----------+--------------------------+-------------+ | Value | Mnemonic | Short Description | Reference | +-------+----------+--------------------------+-------------+ | 0 | Cert | Full certificate | [this doc] | | 1 | SPKI | SubjectPublicKeyInfo | [this doc] | | 2-254 | | Unassigned | | | 255 | PrivSel | Reserved for Private Use | [this doc] | +-------+----------+--------------------------+-------------+ Applications to the registry can request specific values that have yet to be assigned. 6.4. SMIMEA Matching Types This document creates a new registry, "SMIMEA Matching Types". The registry policy is "Specification Required". The initial entries in the registry are: +-------+-----------+--------------------------+-------------+ | Value | Mnemonic | Short Description | Reference | +-------+-----------+--------------------------+-------------+ | 0 | Full | No hash used | [this doc] | | 1 | SHA2-256 | 256 bit hash by SHA2 | [this doc] | | 2 | SHA2-512 | 512 bit hash by SHA2 | [this doc] | | 3-254 | | Unassigned | | | 255 | PrivMatch | Reserved for Private Use | [this doc] | +-------+-----------+--------------------------+-------------+ Applications to the registry can request specific values that have yet to be assigned. 6.5. Certificate Access Field This document creates a new registry, "SMIMEA Certificate Access". The registry policy is "Specification Required". The initial entries in the registry are: +-------+-----------+---------------------------+-------------+ | Value | Mnemonic | Short Description | Reference | +-------+-----------+---------------------------+-------------+ | 0 | NO | No Alternative Advertised | [this doc] | | 1 | NAPTR | NAPTR | [this doc] | | 2 | WF | WebFinger | [this doc] | | 3-254 | | Unassigned | | | 255 | PrivUse | Reserved for Private Use | [this doc] | +-------+-----------+---------------------------+-------------+ Applications to the registry can request specific values that have yet to be assigned. From nobody Fri Oct 31 08:25:55 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA5601A906B for ; Fri, 31 Oct 2014 08:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.888 X-Spam-Level: X-Spam-Status: No, score=-0.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01, URI_HEX=1.122] 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 GaaDhx1eICtv for ; Fri, 31 Oct 2014 08:25:47 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FB341A9040 for ; Fri, 31 Oct 2014 08:25:47 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id E435380055; Fri, 31 Oct 2014 11:25:45 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1414769145; bh=aOk/ZY9IwU4UKtNV/42fVYn1uiJHzOUZSjt/fU4W/uI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=DfEcSL57lkMsSch2ZELcbMe8RiWP7YXCApYk8ZAW/lGn9I1MHoYeKU9LRxg896JkT wle8kD6EESROWg8IzP0WqcYjeIBwD3Dtb1m1gnjS5X0AD1MrLt23gJceKTpzWKQsUU zXbRIRW0nmB7OJcKSCEv/hsgLjR3CZhPwPa/I06A= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s9VFPjdv015947; Fri, 31 Oct 2014 11:25:45 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Fri, 31 Oct 2014 11:25:45 -0400 (EDT) From: Paul Wouters To: "Osterweil, Eric" In-Reply-To: <39C76846-F695-435D-9A5C-6989D06E9573@verisign.com> Message-ID: References: <273F9612-13AF-4CB8-B15C-912AAD04C738@verisign.com> <39C76846-F695-435D-9A5C-6989D06E9573@verisign.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: http://mailarchive.ietf.org/arch/msg/dane/Kz1hkRV_dpxpLsIRN-aEYZGnRzM Cc: dane WG list Subject: Re: [dane] draft-ietf-dane-smime X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 15:25:52 -0000 On Fri, 31 Oct 2014, Osterweil, Eric wrote: > Hey again everyone, > > The thread has calmed down a little bit, and I just wanted to add one more attempt to find a middle-ground to this thread: the initial message (below) included suggested text. Later in the thread, there were some suggested modifications. Thanks to all of those who spent time thinking about this and offered suggestions! I’ve taken a couple of minutes to incorporate feedback, and here is some revised suggested text: The problem has not gone away though. It would help if you could state publicly whether any of your suggestions might fall under planned or actual IPR by Versign? If so, a statement with license conditions compatible with the IETF process would be useful. Without any such statements, I'm even feeling uncomfortable reading anything you wrote, let alone accepting any contributions from members of your company. So as it stands, I am against any of your suggestions, without having read them. Paul > > On Sep 29, 2014, at 8:26 AM, Osterweil, Eric wrote: > >> Hey everyone, >> >> Based on our implementation experience we would like to suggest that the following text (taken from Scott Rose's email: http://www.ietf.org/mail-archive/web/dane/current/msg06180.html ) be incorporated into the current version of the draft-ietf-dane-smime document. We are sending text (below), but at a high-level, the text outlines a few useful additions: >> >> 1 - Usage #4 (reject) is likely to be very important. This could either emphasize the difference between saying, ``don't use this cert for this operation,'' and ``this cert is universally revoked'' or be used to selectively override an organization-wide TA for certain employees that have left the organization. >> >> 2 - The certificate access field (Section 2.1.4) would enable alternate discovery mechanisms that could help aid incremental deployment and transition schemes. For example, while cutting over to a DANE solution, some enterprises may want to transition users from (say) AD to DANE, and this field would enable that. >> >> 3 - The ``_encr'' and ``_sign'' labels are excellent additions to the management of zone sizes and lookup sizes. Rather than querying for all keys and then locally selecting from them, I (as an RP) likely already know which of these I want, and I should be able to look them up separately in DANE (and owners should be able to manage them separately in DANE). > > . . . > > 2.1. SMIMEA RDATA Fields > > The RDATA for the SMIMEA RR consists of a one-octet certificate usage > field, a one-octet selector field, a one-octet matching type field, a > one-octet certificate access field, and the certificate association > data field. > > 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Cert. Usage | Selector | Matching Type | Cert. Access | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > / / > / Certificate Association Data / > / / > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > 2.1.1. The Certificate Usage Field > > A one-octet value, called "certificate usage", specifies the provided > association that will be used to validate the certificate. This > value will be defined in a new IANA registry in order to make it > easier to add additional certificate usages in the future. Four of > the initial usages defined in this document are similar to the first > four TLSA [RFC6698] certificate usages. The certificate usage values > are: > > 0 or PKIX-CA -- PKIX-CA is used to specify a CA certificate, or > the public key of such a certificate, that MUST be found in any of > the PKIX certification paths for the user. This certificate usage > is sometimes referred to as "CA constraint" because it limits > which CA can be used to issue certificates for a given user. The > presented certificate MUST pass PKIX certification path > validation, and a CA certificate that matches the SMIMEA record > MUST be included as part of a valid certification path. Because > this certificate usage allows both trust anchors and CA > certificates, the certificate might or might not have the > basicConstraints extension present. > > 1 or PKIX-EE -- PKIX-EE is used to specify an end entity > certificate, or the public key of such a certificate, that MUST be > matched with the end entity certificate for the SMIME user. This > certificate usage is sometimes referred to as "user certificate > constraint" because it limits which end entity certificate can be > used by a given user. The target user certificate MUST pass PKIX > certification path validation and MUST match the SMIMEA record. > > 2 or DANE-TA -- DANE-TA is used to specify a certificate, or the > public key of such a certificate, that MUST be used as the trust > anchor when validating the SMIME user certificate. This > certificate usage is sometimes referred to as "trust anchor > assertion" and allows a domain name administrator to specify a new > trust anchor -- for example, if the domain issues its own > certificates under its own CA that is not expected to be in the > end users' collection of trust anchors. The target user > certificate MUST pass PKIX certification path validation, with any > certificate matching the SMIMEA record considered to be a trust > anchor for this certification path validation. > > 3 or DANE-EE -- DANE-EE is used to specify a certificate, or the > public key of such a certificate, that MUST match the SMIME user's > certificate. This certificate usage is sometimes referred to as > "domain-issued certificate" because it allows for a domain name > administrator to issue certificates for a domain without involving > a third-party CA. The target user certificate MUST match the > SMIMEA record. The difference between certificate usage 1 and > certificate usage 3 is that certificate usage 1 requires that the > certificate pass PKIX validation, but PKIX validation is not > tested for certificate usage 3. > > 4 or REJECT -- REJECT is used by the domain owner to assert that > at the time of querying the DNS, this user's certificate MUST be > considered invalid for the requested function (i.e. signature or encryption). > This is a stronger assertion than a failed certificate validation check. > Possible usage scenarios include de-authorizing stale employee credentials > by selectively overriding TAs that are used to authorize entire organizations. > > The certificate usages defined in this document explicitly only apply > to PKIX-formatted certificates in DER encoding [ITU.X690.2002]. If > SMIME allows other formats later, or if extensions to this RR type > are made that accept other formats for certificates, those > certificates will need their own certificate usage values. > > 2.1.2. The Selector Field > > A one-octet value, called "selector", specifies which part of the > SMIME certificate presented by the server will be matched against the > association data. This value will be defined in a new IANA registry. > The selectors defined in this document are: > > 0 or CERT -- Full certificate: the Certificate binary structure as > defined in [RFC5280]. > > 1 or SPKI -- SubjectPublicKeyInfo: DER-encoded binary structure as > defined in [RFC5280]. > > (Note that the use of "selector" in this document is completely > unrelated to the use of "selector" in DomainKeys Identified Mail > (DKIM) [RFC6376].) > > 2.1.3. The Matching Type Field > > A one-octet value, called "matching type", specifies how the > certificate association is presented. This value will be defined in > a new IANA registry. The types defined in this document are: > > 0 or Full -- Exact match on selected content > > 1 or SHA2-256 -- SHA-256 hash of selected content [RFC6234] > > 2 or SHA2-512 -- SHA-512 hash of selected content [RFC6234] > > If the SMIMEA record's matching type is a hash, having the record use > the same hash algorithm that was used in the signature in the > certificate (if possible) will assist clients that support a small > number of hash algorithms. > > 2.1.4. Certificate Access Field > > This one octet value indicates an alternative method for certificate > discovery. Some domain owners may not want to publish user > certificates via DNS but may want to use the DNS to advertise the > means to access them. If full user certificates are not included in > the Certificate Association Data this field MAY be used to indicate > how the user's certificate can be obtained. The RDATA certificate > association data MUST be used to validate certificates obtained by > the alternative method. > > 0 or NO: No alternative method advertised. > > 1 or NAPTR : NAPTR record available. The same domain name used > for this SMIMEA request MAY be used again with type NAPTR > [RFC3403] to retrieve the URI for certificate access. > > 2 or WF: X.509 certificates available in WebFinger [RFC7033]. > > 2.1.5. The Certificate Association Data Field > > This field specifies the "certificate association data" to be > matched. These bytes are either raw data (that is, the full > certificate or its SubjectPublicKeyInfo, depending on the selector) > for matching type Full (0), or the hash of the raw data for matching > types SHA2-256 (1) and SHA2-512 (2). The data refers to the > certificate in the association, not to the ASN.1 Certificate object. > For certificate usage type REJECT (4) at least one byte of data is > REQUIRED but the value MUST be ignored. > > 2.2. SMIMEA RR Presentation Format > > The presentation format of the RDATA portion (as defined in > [RFC1035]) is as follows: > > o The certificate usage field MUST be represented either as a > certificate usage mnemonic or an 8-bit unsigned integer. > > o The selector field MUST be represented either as a selector field > mnemonic or an 8-bit unsigned integer. > > o The matching type field MUST be represented either as a matching > type mnemonic or an 8-bit unsigned integer. > > o The certificate access field MUST be represented either as a > certificate access mnemonic or an 8-bit unsigned integer. > > o The certificate association data field MUST be represented as a > string of hexadecimal characters. Whitespace is allowed within > the string of hexadecimal characters, as described in [RFC1035]. > > Where practical, the mnemonic form SHOULD be used in order to provide > clarity. > > 2.3. SMIMEA RR Examples > > In the following examples, the domain name is formed using the rules > in Section 3. > > An example of a hashed (SHA2-256) association of a Full PKIX-CA > certificate in the PKIX validation path of a certificate used to > validate a signed S/MIME message. No alternative certificate access > is advertised. > > 1c190a039a9c355fba9eb653eb52cd64e2fbe76db2588fc5a2b5c5d4._sign._smimecert.example.com. IN SMIMEA ( > 0 0 1 0 d2abde240d7cd3ee6b4b28c54df034b9 > 7983a1d16e8a410e4561cb106618e971 ) > > Alternatively > > 1c190a039a9c355fba9eb653eb52cd64e2fbe76db2588fc5a2b5c5d4._sign._smimecert.example.com. IN SMIMEA ( > PKIX-CA FULL SHA2-256 NO d2abde240d7cd3ee6b4b28c54df034b9 > 7983a1d16e8a410e4561cb106618e971 ) > > An example resource record providing Full self-signed encryption > certificate: > > 1c190a039a9c355fba9eb653eb52cd64e2fbe76db2588fc5a2b5c5d4._encr._smimecert.example.com. IN SMIMEA ( > DANE-EE Cert Full NO 30820307308201efa003020102020... ) > > An example of resource record invalidating all digital signatures by > identified user: > > 1c190a039a9c355fba9eb653eb52cd64e2fbe76db2588fc5a2b5c5d4._sign._smimecert.example.com. IN SMIMEA ( > REJECT Cert Full NO 00 ) > > ... > > 3. Domain Names for S/MIME Certificate Associations > > SMIMEA domain names include function and user labels. The purpose is > to identify the function specific certificate if a user has multiple > certificates. Alias MAY be used if a user has a common certificate > for both functions > > ... > > > 3.1. Domain Name Preparation > > Domain names are prepared for requests in the following manner. > > 1. The user name (the "left-hand side" of the email address, called > the "local-part" in the mail message format definition [RFC5322] > and the "local part" in the specification for internationalized > email [RFC6530]), is encoded with Base32 [RFC4648], to become the > left-most label in the prepared domain name. This does not > include the "@" character that separates the left and right sides > of the email address. > > 2. The second left-most label is the function specific label > segment. It is selected based on the S/MIME function the MUA is > performing. Values are: > > "_encr" for obtaining or validating a certificate or public > key to be used to encrypt a message. > > "_sign" for certificate validation data to verify a digital > signature. > > For certificate use cases XXXX-EE (1 and 3) the function specific > label SHOULD be consistent with the Key Usage field (defined in > section 4.2.1.3 of [RFC5280]) of the associated certificate. > > 3. The string "_smimecert" becomes the third left-most label in the > prepared domain. The function specific label segment is separate > to enable delegation of a single _smimecert zone cut. > > 4. The domain name (the "right-hand side" of the email address, > called the "domain" in [RFC5322]) is appended to the result of > step 3 to complete the prepared domain name. > > ... > > 3.2. Domain Name Examples > > Example 1. Signature certificate verification: to request an SMIMEA > resource record to verify a signature certificate for a user whose > address is "alice@example.com", you would use: > > "df7f0c341e185f1073a2caef0d37a8b6a11fac62f46beaf459532bb0._sign._smimecert.example.com" > > Example 2. Encryption key discovery: to request an SMIMEA resource > record for encrypting an email to user "bob@example.com" you would > use: > > "550c233eeabd0f03bb42b99956efa56cdadaef7d346a04e351ac1b7a._encr._smimecert.example.com" > > 4. Use of SMIMEA Records in SMIME > > SMIMEA records are used to publish user certificates or validate user > certificates acquired by other means. Typically these use cases are > associated with message encryption and signature validation processes > respectively. Section 2.1 of this document defines the mandatory > matching rules for the data. Where possible, consistency with > [RFC6698] is maintained. > > 4.1. Usable Certificate Associations > > An implementation of this protocol makes a DNS query for SMIMEA > records, validates these records using DNSSEC, and uses the resulting > SMIMEA records and validation to modify S/MIME message processing > behavior. > > Determining whether an SMIMEA RRSet can be used MUST be based on the > DNSSEC validation state (as defined in [RFC4035]). > > o An SMIMEA RRSet whose DNSSEC validation state is secure MUST be > used as a certificate association for S/MIME unless a local policy > would prohibit the use of the specific certificate association in > the secure SMIMEA RRSet. > > o If the DNSSEC validation state on the response to the request for > the SMIMEA RRSet is bogus then the RRSet MUST be disregarded and > considered unusable. Additional SMIMEA queries may be initiated. > > o If the DNSSEC validation state is indeterminate or insecure then > the SMIMEA RRSet MUST be disregarded and considered unusable. > > MUAs that rely on another entity to perform the DNSSEC signature > validation SHOULD use a secure mechanism between themselves and the > validator. Examples of secure transports to other hosts include TSIG > [RFC2845], SIG(0) [RFC2931], and IPsec [RFC6071]. Note that it is > not sufficient to use secure transport to a DNS resolver that does > not do DNSSEC signature validation. > > If a certificate association contains a certificate usage, selector, > or matching type that is not understood by the MUA, that certificate > association MUST be considered unusable. If the comparison data for > a certificate is malformed, the certificate association MUST be > considered unusable. > > If a certificate association contains a matching type or certificate > association data that uses a cryptographic algorithm that is > considered too weak for the MUA's local policy, the certificate > association MUST be considered unusable. > > If a MUA receives zero usable certificate associations from a DNS > request or from its cache, it processes S/MIME requests in the normal > fashion without any input from the SMIMEA records. > > If a MUA performing certificate validation receives one or more > usable certificate associations then it MUST attempt to match each > certificate association with the user's certificate until a > successful match is found. If no certificate associations match then > the certificate MUST be considered invalid. > > If a MUA makes an SMIMEA request for an encryption certificate and > the response includes more than one valid certificate, the > certificate with the most recent "Not Before" data SHOULD be > selected. [ Are there better criteria? ] > > ... > > 6. IANA Considerations > > 6.1. SMIMEA RRtype > > This document uses a new DNS RR type, SMIMEA, whose value will be > allocated by IANA from the Resource Record (RR) TYPEs subregistry of > the Domain Name System (DNS) Parameters registry. > > 6.2. SMIMEA Certificate Usage Registry > > This document creates a new registry, "SMIMEA Certificate Usages". > The registry policy is "RFC Required". The initial entries in the > registry are: > > +-------+----------+--------------------------------+-------------+ > | Value | Mnemonic | Short Description | Reference | > +-------+----------+--------------------------------+-------------+ > | 0 | PKIX-CA | CA constraint | [this doc] | > | 1 | PKIX-EE | Service certificate constraint | [this doc] | > | 2 | DANE-TA | Trust anchor assertion | [this doc] | > | 3 | DANE-EE | Domain-issued certificate | [this doc] | > | 4 | REJECT | Invalid Certificate or User | [this doc] | > | 5-254 | | Unassigned | | > | 255 | PrivCert | Reserved for Private Use | [this doc] | > +-------+----------+--------------------------------+-------------+ > > > Applications to the registry can request specific values that have > yet to be assigned. > > 6.3. SMIMEA Selectors > > This document creates a new registry, "TLSA Selectors". The registry > policy is "Specification Required". The initial entries in the > registry are: > > +-------+----------+--------------------------+-------------+ > | Value | Mnemonic | Short Description | Reference | > +-------+----------+--------------------------+-------------+ > | 0 | Cert | Full certificate | [this doc] | > | 1 | SPKI | SubjectPublicKeyInfo | [this doc] | > | 2-254 | | Unassigned | | > | 255 | PrivSel | Reserved for Private Use | [this doc] | > +-------+----------+--------------------------+-------------+ > > > Applications to the registry can request specific values that have > yet to be assigned. > > 6.4. SMIMEA Matching Types > > This document creates a new registry, "SMIMEA Matching Types". The > registry policy is "Specification Required". The initial entries in > the registry are: > > +-------+-----------+--------------------------+-------------+ > | Value | Mnemonic | Short Description | Reference | > +-------+-----------+--------------------------+-------------+ > | 0 | Full | No hash used | [this doc] | > | 1 | SHA2-256 | 256 bit hash by SHA2 | [this doc] | > | 2 | SHA2-512 | 512 bit hash by SHA2 | [this doc] | > | 3-254 | | Unassigned | | > | 255 | PrivMatch | Reserved for Private Use | [this doc] | > +-------+-----------+--------------------------+-------------+ > > > Applications to the registry can request specific values that have > yet to be assigned. > > 6.5. Certificate Access Field > > This document creates a new registry, "SMIMEA Certificate Access". > The registry policy is "Specification Required". The initial entries > in the registry are: > > +-------+-----------+---------------------------+-------------+ > | Value | Mnemonic | Short Description | Reference | > +-------+-----------+---------------------------+-------------+ > | 0 | NO | No Alternative Advertised | [this doc] | > | 1 | NAPTR | NAPTR | [this doc] | > | 2 | WF | WebFinger | [this doc] | > | 3-254 | | Unassigned | | > | 255 | PrivUse | Reserved for Private Use | [this doc] | > +-------+-----------+---------------------------+-------------+ > > > Applications to the registry can request specific values that have > yet to be assigned. > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > From nobody Fri Oct 31 10:11:26 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D0971A0043 for ; Fri, 31 Oct 2014 10:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.21 X-Spam-Level: X-Spam-Status: No, score=-99.21 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] 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 I-jDZtwEimSN for ; Fri, 31 Oct 2014 10:11:20 -0700 (PDT) Received: from mail.tcb.net (mail.tcb.net [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3A71A00E1 for ; Fri, 31 Oct 2014 10:11:19 -0700 (PDT) Received: from dspam (unknown [127.0.0.1]) by mail.tcb.net (Postfix) with SMTP id 3F6E03000AC for ; Fri, 31 Oct 2014 17:11:19 +0000 (UTC) Received: from mail2.tcb.net (localhost [127.0.0.1]) by mail.tcb.net (Postfix) with ESMTP id 19F303000A1; Fri, 31 Oct 2014 11:11:19 -0600 (MDT) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 31 Oct 2014 11:11:19 -0600 From: Danny McPherson To: In-Reply-To: References: <273F9612-13AF-4CB8-B15C-912AAD04C738@verisign.com> <39C76846-F695-435D-9A5C-6989D06E9573@verisign.com> Message-ID: <6c8f72bc0e8882c8fc1f30572171183f@tcb.net> X-Sender: danny@tcb.net User-Agent: Roundcube Webmail/0.8.2 X-DSPAM-Result: Innocent X-DSPAM-Processed: Fri Oct 31 11:11:19 2014 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689409 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 5453c2b78671731720394 X-DSPAM-Factors: 27, Rest+assured, 0.40000, useful+#+#+#+discussion, 0.40000, not+#+#+#+there, 0.40000, license+conditions, 0.40000, are+#+#+of, 0.40000, are+#+#+of, 0.40000, Wouters+wrote, 0.40000, appropriate+#+#+aware, 0.40000, Perhaps+#+them, 0.40000, I'm+even, 0.40000, said+#+welcome, 0.40000, that+are, 0.40000, said+#+#+to, 0.40000, I'm+#+#+uncomfortable, 0.40000, to+#+the, 0.40000, to+#+the, 0.40000, concerns+you, 0.40000, not+doing, 0.40000, 25+#+Wouters, 0.40000, clear+consequences, 0.40000, useful+#+#+this, 0.40000, members+#+#+#+Rest, 0.40000, follow+those, 0.40000, lot+of, 0.40000, with+license, 0.40000, yourself+#+#+#+you, 0.40000, useful+#+#+#+statements, 0.40000 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/3lGfamYlkI6iDAno7HJidvve2OQ Cc: dane@ietf.org Subject: Re: [dane] draft-ietf-dane-smime X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 17:11:24 -0000 On 2014-10-31 09:25, Paul Wouters wrote: > The problem has not gone away though. It would help if you could > state > publicly whether any of your suggestions might fall under planned or > actual IPR by Versign? If so, a statement with license conditions > compatible with the IETF process would be useful. Without any such > statements, I'm even feeling uncomfortable reading anything you > wrote, > let alone accepting any contributions from members of your company. Rest assured Verisign is going to follow the IETF IPR disclosure procedures in the way that our experts in this area deem appropriate - we're well aware there are clear consequences of not doing so -- and there are a lot of folks here that are trying to do the right thing. That said, you're welcome to follow those procedures yourself if something concerns you. > So as it stands, I am against any of your suggestions, without having > read them. Perhaps give them a read such you can have an informed position and useful contribution for this discussion? :-) Kind regards, -danny From nobody Fri Oct 31 10:28:45 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF41A1A0102 for ; Fri, 31 Oct 2014 10:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.778 X-Spam-Level: X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URI_HEX=1.122] 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 y_s_Iug8LnpX for ; Fri, 31 Oct 2014 10:28:41 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F6E71A001C for ; Fri, 31 Oct 2014 10:28:41 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 7E08A2AAD9C; Fri, 31 Oct 2014 17:28:40 +0000 (UTC) Date: Fri, 31 Oct 2014 17:28:40 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141031172840.GM19103@mournblade.imrryr.org> References: <273F9612-13AF-4CB8-B15C-912AAD04C738@verisign.com> <39C76846-F695-435D-9A5C-6989D06E9573@verisign.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <39C76846-F695-435D-9A5C-6989D06E9573@verisign.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/GS6zrML1v0YpTCH5Of1RA6c8LGw Subject: Re: [dane] draft-ietf-dane-smime X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 17:28:43 -0000 On Fri, Oct 31, 2014 at 02:47:19PM +0000, Osterweil, Eric wrote: > 4 or REJECT -- REJECT is used by the domain owner to assert that at > the time of querying the DNS, this user's certificate MUST be considered > invalid for the requested function (i.e. signature or encryption). > This is a stronger assertion than a failed certificate validation check. > Possible usage scenarios include de-authorizing stale employee > credentials by selectively overriding TAs that are used to authorize > entire organizations. Which certificate is being invalidated? Why is this needed? What's wrong with publishing a "3 1 1" association with an impossible key? $ openssl dgst -sha256 2.1.4. Certificate Access Field > > This one octet value indicates an alternative method for certificate > discovery. Some domain owners may not want to publish user > certificates via DNS but may want to use the DNS to advertise the > means to access them. If full user certificates are not included in > the Certificate Association Data this field MAY be used to indicate > how the user's certificate can be obtained. The RDATA certificate > association data MUST be used to validate certificates obtained by > the alternative method. > > 0 or NO: No alternative method advertised. > > 1 or NAPTR : NAPTR record available. The same domain name used > for this SMIMEA request MAY be used again with type NAPTR > [RFC3403] to retrieve the URI for certificate access. > > 2 or WF: X.509 certificates available in WebFinger [RFC7033]. Once this field is not "NO", what is the meaning of the associated data field carried with such a record? Is it still providing a valid DANE association? If so, when would one also need to use the "alternative access"? If not, how is this a DANE SMIMEA record? At the very least changing the semantics of the associated data should lead to a new selector or usage, but more likely an entirely separate DNSSEC validated record, at which point the application can just query for these alternative records if it sees fit. Why does SMIMEA need to explicitly signal the use of other mechanisms? -- Viktor.