From nobody Wed Jul 1 03:59:55 2015 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 257021B2E0D for ; Wed, 1 Jul 2015 03:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 0cb8aiVz10Xt for ; Wed, 1 Jul 2015 03:59:52 -0700 (PDT) Received: from mail-qg0-f97.google.com (mail-qg0-f97.google.com [209.85.192.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F4071B2DF5 for ; Wed, 1 Jul 2015 03:59:52 -0700 (PDT) Received: by qgaj5 with SMTP id j5so1974270qga.1 for ; Wed, 01 Jul 2015 03:59:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:user-agent:content-type:content-id :content-transfer-encoding:mime-version; bh=DWPAlekQzgYEkhVQNDf2+RuvjQL3CaGp5Zed5NmXmfY=; b=J7T25Elvoxmiy6auZcXo2O72L5NKNRl8vkEII/YCTxlvAte0rO4OyEcld3xcNFkcU6 3T8TneOtYnqB/qlnqMVoJTBmklfuY+R6+Dh7jt1jl6Ec//2uh6czemZeXAFjXpX/Yclk 7FplyeMHF6be2rzgcvxsjw39G+aFyWbEGxvfp4nVbXCUNkMu/xTwUa1GrBAgZakrhMLp D5c8ADRIaoPM0VBgfQIhxxsTesK4XuecEFW5bpAq1mQXfKwPkPfgB3v/I2MhjYxp6R4U 9d80AhMinFTQQIzwYR8QPSoaDpu7RicwmTmclTkXoFKfDStkumpg5+5p0ZlC29XTe9pi taUA== X-Gm-Message-State: ALoCoQmQy2N4dNyZ3yox+cmUyAk1ma69MJCIuaMwuLBvbevO7G0hjDIrSPXz6dR9VpMs7G3OW3wKJhOq/ZZBpmkAm51L3hwY9Q== X-Received: by 10.55.25.12 with SMTP id k12mr53379658qkh.81.1435748391613; Wed, 01 Jul 2015 03:59:51 -0700 (PDT) Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by mx.google.com with ESMTPS id r41sm1511598qkr.0.2015.07.01.03.59.51 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 01 Jul 2015 03:59:51 -0700 (PDT) X-Relaying-Domain: verisign.com Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02 [10.173.152.206]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id t61Axnpd017907 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Jul 2015 06:59:51 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Wed, 1 Jul 2015 06:59:37 -0400 From: "Wiley, Glen" To: Paul Hoffman , Melinda Shore Thread-Topic: [dane] Deferral of SMIME draft Thread-Index: AQHQspsq+hwuYwzV6EqI+OdyRokHqJ3GHFQAgAATMYCAAAbYgIAAAf0AgAA8iQA= Date: Wed, 1 Jul 2015 10:59:36 +0000 Message-ID: References: <55935B73.2080602@gmail.com> <961A61DD-758A-4AD6-84EB-9061C5984347@vpnc.org> In-Reply-To: <961A61DD-758A-4AD6-84EB-9061C5984347@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <73CCE9A0E98F7A4FB7F77E436A137EC6@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: dane WG list Subject: Re: [dane] Deferral of SMIME draft 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 Jul 2015 10:59:54 -0000 Does this current thread provide enough evidence of interest to make progress on the draft? While there have been discussions about changes to the SMIME draft, is there anything beyond reconciling the openpgpkey and smimea locating approach that would be significant enough to warrant holding the draft up? --=20 Glen Wiley Principal Engineer Verisign, Inc. (571) 230-7917 http://vbsdcon.com A5E5 E373 3C75 5B3E 2E24 6A0F DC65 2354 9946 C63A On 6/30/15, 11:23 PM, "Paul Hoffman" wrote: >On Jun 30, 2015, at 8:16 PM, Melinda Shore >wrote: >> On 6/30/15 6:51 PM, Paul Wouters wrote: >>> I actually also do not really understand the decision, other than the >>> authors seeing a hot potato. I still believe it would be in the >>>interest >>> of both the OPENPGPKEY and the SMIMEA drafts that they continue to >>> discuss and attempt to use the same lookup mechanism. >>> iI suspect many software implementors that will implement one, will >>> also implement the other. Since it is mostly a different format for the >>> same idea, attempt to encrypt emails when a public key is advertised. >>=20 >> Yes, to all of this. I really don't understand the reasoning >> behind this decision, mostly because the only explanation given >> has been pretty perfunctory. Surely a better option right now >> would be to find additional editors. > >We have plenty of willing editors: what we need is WG interest in >reviewing (not just in asking for us to finish regardless of the open >issues). The open issue in draft-ietf-dane-smime heavily overlap with >those in draft-ietf-dane-openpgpkey, but only a very small number of >people have chimed in on the recent threads. > >Without sufficient review, there is a good chance that the protocol will >be heavily flawed. > >Note that the current issues are not the only ones for >draft-ietf-dane-smime. Eric Osterweil brought up many proposals earlier >that died because no one even commented on them. WG consensus by silence >is a good sign that not enough people care about getting the protocol >right. > >--Paul Hoffman >_______________________________________________ >dane mailing list >dane@ietf.org >https://www.ietf.org/mailman/listinfo/dane From nobody Wed Jul 1 07:54:39 2015 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 F41501A8AF0 for ; Wed, 1 Jul 2015 07:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.161 X-Spam-Level: X-Spam-Status: No, score=-0.161 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_SE=0.35, 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 zWKgWmxqvNKJ for ; Wed, 1 Jul 2015 07:54:36 -0700 (PDT) Received: from mail.zash.se (sphyrna.zash.se [IPv6:2001:470:28:559::]) (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 6097D1A8AF7 for ; Wed, 1 Jul 2015 07:54:34 -0700 (PDT) Received: from [IPv6:2001:470:def1:0:4134:eba3:597a:d5d3] (unknown [IPv6:2001:470:def1:0:4134:eba3:597a:d5d3]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: zash) by mail.zash.se (Postfix) with ESMTPSA id 1E144601F6 for ; Wed, 1 Jul 2015 16:54:31 +0200 (CEST) Message-ID: <5593FF26.2000209@zash.se> Date: Wed, 01 Jul 2015 16:54:30 +0200 From: Kim Alvefur User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: dane@ietf.org References: In-Reply-To: OpenPGP: id=3E52119EF853C59678DBBF6BADED9A77B67AD329; url=http://zash.se/~zash/pubkey.asc Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="xnS9S7HTmWVH76rV4UgVnwoSE7fquiQck" Archived-At: Subject: Re: [dane] draft: Client Certificates in TLSA records 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 Jul 2015 14:54:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xnS9S7HTmWVH76rV4UgVnwoSE7fquiQck Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, I kinda have a deployed implementation of this, for mutual server to server authentication with DANE in XMPP. I've settled on using SRV record indirection that would already be in place for srv-dane. This already has a number of deployments=B9 and thus Just Works. I experimented with something similar to the simple model in the draft before (_xmpp-server.example.com IN TLSA) but Matthew Miller (IIRC, can't find the thread now) raised an issue wrt delegation, that it gets harder to point at TLSA records hosted by a hosting provider. And it's harder to get people to deploy two sets of TLSA records at different plac= es. =B9 https://xmpp.net/reports.php#dnssecdane --=20 Kim "Zash" Alvefur --xnS9S7HTmWVH76rV4UgVnwoSE7fquiQck Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iQIcBAEBCgAGBQJVk/8mAAoJEK3tmne2etMp+6kP/2THGaXmOhX9FagXQSAOrYo5 khkooZa2BfXKpJgczAeAoi5ouy2JYecg5TpuMPzv9IQHJ1YbuJOo1ao1Z3zYNE2f c3BX1sYtg2dUUIkO9p5w6PkGl0JFV7uGEaEcb6+jDARu2xesQW8yd3h0111hlt+f PIeoFzPT/5XeqdIBP4zeWt5KKUt5ljxEBZ6d2UcWLCgUnz1HoVagWmadvuW/JBEK uVrqJf6GIl/u7t/rDwoHPh43Zps4nhtVBFfnrMjnsmsQNubMU+V8i+LGGNy+ncmd QSOHin4IkvzKvrfO4t0mk4rZkmd53UV3TlcGaEdIeHmaIDhMtF8TUhBg2jLzdnfd OmrqHZWiRD5YtUTKCYAFfWatum3GftA1JUNIIZw4vLPQBscJPc69NPwy19lu3koq WWU6UCwghK0xgdWsgN4GVInDdcJGAtK83NCGZQ8wK1sk7ELccTVATEHSbozwxNx2 /BW8tEbdIJL4/SxjIpUDHVkhWbMj629nDaDQAWvTKtreqg/HdAErfV9i/YhNL6Gw 6p0y8FNOkLxbugPi1JiGmtae84cuMakmPryXoT2GdH4zcNURAzWaIkRl1Yat4qw8 aX9r3pKH0AL5r4w5JAF/6fBpDMOODkdwM2rCzP+lZmfmDoqPQJVUCKA1lnxWn/lC WAfCTaCucP53xvmxcsuS =rzBH -----END PGP SIGNATURE----- --xnS9S7HTmWVH76rV4UgVnwoSE7fquiQck-- From nobody Wed Jul 1 08:25:05 2015 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 B07DD1A9044 for ; Wed, 1 Jul 2015 08:25:04 -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 hlVaX1OBtK6b for ; Wed, 1 Jul 2015 08:25:03 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 217381A8A9C for ; Wed, 1 Jul 2015 08:25:03 -0700 (PDT) Received: by qkhu186 with SMTP id u186so31852131qkh.0 for ; Wed, 01 Jul 2015 08:25:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=xvXkl6MEzN/1oQ0JouTIlJOlb2qzF4GAsqrFQDK95U0=; b=zfitsuPljSQ022TX9KRno+1/52btBRIsNoqsinR3wcBlMQNktLHQC12ktpX7DqrHjk ejHtc7bSaAJs400qLDlynRoWq67b02bXzRtr7Fti2nzksZbEZjm5H8VN0WA+yFxPhvEX IZj4g+cnyRXoVBIEJn5G0LXUXI57XZfqiywQxzUI0vXT6aCGTU1mt4FrvroYqafbvYzF 68aLCNGDsiUiRNIUAeu9N11vZyp4MEkRnHJjf2guiKec7eU8Ytw/6jZ8lfTruwfT4f7W MCFTGwkQNHCHKlNM2sAW2ClFvmV91JjjMfqRHb/6IYieQdJ4oqLxmlVsE/B2pkRj74Sw S+pQ== MIME-Version: 1.0 X-Received: by 10.140.109.119 with SMTP id k110mr34009014qgf.53.1435764302445; Wed, 01 Jul 2015 08:25:02 -0700 (PDT) Received: by 10.140.80.208 with HTTP; Wed, 1 Jul 2015 08:25:02 -0700 (PDT) In-Reply-To: <5593FF26.2000209@zash.se> References: <5593FF26.2000209@zash.se> Date: Wed, 1 Jul 2015 11:25:02 -0400 Message-ID: From: Shumon Huque To: Kim Alvefur Content-Type: multipart/alternative; boundary=001a1139bc503a8ad00519d1ed8b Archived-At: Cc: "" Subject: Re: [dane] draft: Client Certificates in TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: shuque@gmail.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 15:25:04 -0000 --001a1139bc503a8ad00519d1ed8b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jul 1, 2015 at 10:54 AM, Kim Alvefur wrote: > Hi, > > I kinda have a deployed implementation of this, for mutual server to > server authentication with DANE in XMPP. I've settled on using SRV > record indirection that would already be in place for srv-dane. This > already has a number of deployments=C2=B9 and thus Just Works. > Yup, I think that's a viable strategy for XMPP s2s authentication, where there are symmetrical characteristics on both sides in the form of SRV records. In the general case of client authentication (which our draft covers), this is probably not true. For example client systems may not have stable network addresses or associated address records, and might generally be moving around the network. In such cases, they need to relay their identity to the server side. Section 7 of our draft does talk about application protocol specific behavior that might take into account other client characteristics where available, but defers those details to application specific documents to define. --=20 Shumon Huque --001a1139bc503a8ad00519d1ed8b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jul 1, 2015 at 10:54 AM, Kim Alvefur <zash@zash.se> wrote:
Hi,

I kinda have a deployed implementation of this, for mutual server to
server authentication with DANE in XMPP.=C2=A0 I've settled on using SR= V
record indirection that would already be in place for srv-dane.=C2=A0 This<= br> already has a number of deployments=C2=B9 and thus Just Works.

Yup, I think that's a viable strategy for XMPP = s2s authentication, where there are symmetrical characteristics on both sid= es in the form of SRV records.

In the general case= of client authentication (which our draft covers), this is probably not tr= ue. For example client systems may not have stable network addresses or ass= ociated address records, and might generally be moving around the network. = In such cases, they need to relay their identity to the server side. Sectio= n 7 of our draft does talk about application protocol specific behavior tha= t might take into account other client characteristics where available, but= defers those details to application specific documents to define.

--=C2=A0
Shumon Huque

=
--001a1139bc503a8ad00519d1ed8b-- From nobody Wed Jul 1 08:57:52 2015 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 3E8E41A0163 for ; Wed, 1 Jul 2015 08:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.012 X-Spam-Level: X-Spam-Status: No, score=-100.012 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 oBGdLr1fV0x2 for ; Wed, 1 Jul 2015 08:57:50 -0700 (PDT) Received: from mail.tcb.net (mail.tcb.net [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 337511A006F for ; Wed, 1 Jul 2015 08:57:50 -0700 (PDT) Received: from dspam (unknown [127.0.0.1]) by mail.tcb.net (Postfix) with SMTP id D20D8302818 for ; Wed, 1 Jul 2015 15:57:49 +0000 (UTC) Received: from mail2.tcb.net (localhost [127.0.0.1]) by mail.tcb.net (Postfix) with ESMTP id AACC4302817 for ; Wed, 1 Jul 2015 09:57:49 -0600 (MDT) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 01 Jul 2015 09:57:49 -0600 From: Danny McPherson To: In-Reply-To: <961A61DD-758A-4AD6-84EB-9061C5984347@vpnc.org> References: <55935B73.2080602@gmail.com> <961A61DD-758A-4AD6-84EB-9061C5984347@vpnc.org> Message-ID: <23ee6a94948b0b7875f17c20706d7f31@tcb.net> X-Sender: danny@tcb.net User-Agent: Roundcube Webmail/0.8.2 X-DSPAM-Result: Innocent X-DSPAM-Processed: Wed Jul 1 09:57:49 2015 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689409 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 55940dfd8671986916602 X-DSPAM-Factors: 27, are+#+#+only, 0.40000, not+seen, 0.40000, list+or, 0.40000, the+#+#+won't, 0.40000, Agreed+#+#+#+seen, 0.40000, the+#+#+as, 0.40000, only+#+#+draft, 0.40000, isn't+#+#+storage, 0.40000, code+for, 0.40000, sufficient+review, 0.40000, time+danny, 0.40000, shelf+certainly, 0.40000, into+#+#+#+arbitrary, 0.40000, getting+#+#+#+Agreed, 0.40000, either+on, 0.40000, 06+#+#+#+Paul, 0.40000, or+#+#+#+or, 0.40000, them+#+consensus, 0.40000, factions+#+several, 0.40000, arguably+#+#+that's, 0.40000, put+#+storage, 0.40000, artifact+#+#+hold', 0.40000, code+#+that, 0.40000, many+#+earlier, 0.40000, that+#+Putting, 0.40000, SMIMEA+#+#+on, 0.40000, issues+#+not, 0.40000 Archived-At: Subject: Re: [dane] Deferral of SMIME draft 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 Jul 2015 15:57:51 -0000 On 2015-06-30 21:23, Paul Hoffman wrote: > Without sufficient review, there is a good chance that the protocol > will be heavily flawed. And running code, for that matter. Putting it on the shelf certainly won't help with either, methinks. > Note that the current issues are not the only ones for > draft-ietf-dane-smime. Eric Osterweil brought up many proposals > earlier that died because no one even commented on them. WG consensus > by silence is a good sign that not enough people care about getting > the protocol right. Agreed. But I've not seen silences on the SMIMEA approach either on the list, or in the working group sessions, or in the community, or in lines of code. Perhaps traffic on the list was as much an artifact of 'close hold' editing by some passionate factions on several arguably competing proposals, that's a good problem to have. The WG dialog has and will surely continue to help us form consensus -- only if this isn't put into storage for some arbitrary amount of time. -danny From nobody Wed Jul 1 09:51:00 2015 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 107A71A92EF for ; Wed, 1 Jul 2015 09:50: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, RCVD_IN_DNSWL_NONE=-0.0001] 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 habbbGzukkfv for ; Wed, 1 Jul 2015 09:50:51 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 713051A016C for ; Wed, 1 Jul 2015 09:50:51 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id A51B3284D2B; Wed, 1 Jul 2015 16:50:50 +0000 (UTC) Date: Wed, 1 Jul 2015 16:50:50 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150701165050.GL14121@mournblade.imrryr.org> References: <5593FF26.2000209@zash.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5593FF26.2000209@zash.se> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] draft: Client Certificates in TLSA records 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: Wed, 01 Jul 2015 16:50:56 -0000 On Wed, Jul 01, 2015 at 04:54:30PM +0200, Kim Alvefur wrote: > I kinda have a deployed implementation of this, for mutual server to > server authentication with DANE in XMPP. I've settled on using SRV > record indirection that would already be in place for srv-dane. This > already has a number of deployments? and thus Just Works. Only when we can expect the "client" to be a designated server for a peer domain. Such symmetry is not present in SMTP, where outbound SMTP servers are frequently different from the inbound servers for same. One might reasonably consider this pattern to not be DANE-based "client authentication". Rather it is in a sense still server authentication, with the accepting server using the original connection to authenticate a reverse channel (as well establish the identity of the client). So this is a very special case, and indeed may be well suited to XMPP, but not otherwise generally applicable. > I experimented with something similar to the simple model in the draft > before (_xmpp-server.example.com IN TLSA) but Matthew Miller (IIRC, > can't find the thread now) raised an issue wrt delegation, that it gets > harder to point at TLSA records hosted by a hosting provider. The difficulty is mostly that SRV records can specify multiple hosts, each with a separate TLSA RRset, but CNAME records from a customer domain into a server provider domain can only point to one TLSA RRset. If the SRV RRset points at just one server, there is no difficulty, but when there are many, the client's asserted identity needs to be that of the target server, not the hosted domain. Again for XMPP, since one is setting up a bidirectional channel, one wants to know that the connection is between two domains, so that messages in the reverse direction securely arrive at the right place (no impersonation of other domains by clients). For SMTP, one might grant a positive reputation or custom access to an authenticated client, and if that's a provider, the reputation or access control is properly that of the provider. With store and forward, it does not make as much sense to think of the communication as happening with the envelope sender domain. > And it's > harder to get people to deploy two sets of TLSA records at different places. Still much easier than the initial cost of spinning up DNSSEC. After that, publishing a few TLSA RRs is fairly cheap, and CNAMEs can eliminate redudancy when the same end-entity keys (or same trust anchors) are used in multiple contexts. -- Viktor. From nobody Wed Jul 1 10:47:45 2015 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 27B3B1ACED5 for ; Wed, 1 Jul 2015 10:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 yFBHOQo8fLYs for ; Wed, 1 Jul 2015 10:47:41 -0700 (PDT) Received: from mail-qg0-f100.google.com (mail-qg0-f100.google.com [209.85.192.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E7441ACE58 for ; Wed, 1 Jul 2015 10:47:41 -0700 (PDT) Received: by qgi45 with SMTP id 45so757680qgi.2 for ; Wed, 01 Jul 2015 10:47:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :content-type:mime-version; bh=RFGplUsz/49jij/wxiKNEAldRnxGp3vOmlZf7DDKyKc=; b=LnjZrjhDIL2hnhtnccazWcrxIsKBjctSrGJeAH4syVEXGK9KNqArz7bkimHPmYXoMS AeqK8YKDYsZZxFyBACymMTEPOB2zUeh4nT5uxxTRRLc3SFLXbxrFkp+PCATLAMXa+MH0 5dYOwjLQpdO2+3M0FDzuav/MGwRetdE71C9NtZEwD/h/4tw3pJqe+ognxn3gYke1RkuL Xe+11/ABdLIWINJ4N3vs/XobFDlE1VXWNmAB+Escgjq9ljpLtKtGDM7Qwk9DFGN3sP+C zMPP15cKfpwrv6KOpfMi7o7oOfF8ayOVLrjYC5kglf4+9S7D5nK0p4bj+FRtB7B1qXeR n6Xw== X-Gm-Message-State: ALoCoQkJdQe6qeeb/P3rToPnr5a8c3M88eKX+8KvXK5879mzjv+k3uRhJZm+YtTG1bI6IeWJscBmEDOkROIIokrQUGvMJLAZVw== X-Received: by 10.55.21.141 with SMTP id 13mr56810584qkv.101.1435772860528; Wed, 01 Jul 2015 10:47:40 -0700 (PDT) Received: from brn1lxmailout01.verisign.com (brn1lxmailout01.verisign.com. [72.13.63.41]) by mx.google.com with ESMTPS id q6sm1805154qkh.4.2015.07.01.10.47.40 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 01 Jul 2015 10:47:40 -0700 (PDT) X-Relaying-Domain: verisign.com Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02 [10.173.152.206]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id t61Hldb9013068 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 1 Jul 2015 13:47:39 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Wed, 1 Jul 2015 13:47:26 -0400 From: "Mankin, Allison" To: dane WG list Thread-Topic: [dane] Deferral of SMIME draft Thread-Index: AQHQspsqH0379A9juku1V27hODLSRp3GHFQAgAATMYCAAAbYgIAAAf0AgACuZgA= Date: Wed, 1 Jul 2015 17:47:26 +0000 Message-ID: References: <55935B73.2080602@gmail.com> <961A61DD-758A-4AD6-84EB-9061C5984347@vpnc.org> In-Reply-To: <961A61DD-758A-4AD6-84EB-9061C5984347@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: multipart/alternative; boundary="_000_D1B9954244916amankinverisigncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [dane] Deferral of SMIME draft 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 Jul 2015 17:47:43 -0000 --_000_D1B9954244916amankinverisigncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Another reason not to defer the SMIME draft is that those interested in the= NCCOE [*] DNS-Based Secure Email Project may benefit from the draft being = active and/or published as Experimental. NCCOE announced the project and requested interest this week: http://nccoe.nist.gov/DNSSecuredEmail/ SMIMEA is specifically included in the scope of this project: The DANE protocol will initially be used to authenticate servers and certif= icates in two roles in the DNS-Based Security for Email Project: By binding the X.509 certificates used for 1. Transport Layer Security (TLS) to DNS names verified by DNSSEC and suppo= rting the use of these certificates in the mail server-to-mail server commu= nication; 2. Secure Secure/Multipurpose Internet Mail Extensions (S/MIME) to email ad= dresses encoded as DNS names verified by DNSSEC. [*] NCCOE expands to National Cybersecurity Center of Excellence. Although= NCCOE has been formed by the US agency NIST, its projects are open to both= US and non-US participation. Allison --_000_D1B9954244916amankinverisigncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <72337A246D31194AAF5B77F47F05CE13@verisign.com> Content-Transfer-Encoding: quoted-printable
Another reason not to defer the SMIME draft is that those interested i= n the NCCOE [*] DNS-Based Secure Email Project may benefit from the draft b= eing active and/or published as Experimental.  

NCCOE announced the project and requested interest this week:  &n= bsp;



SMIMEA is specifically included in the scope of this project:

The DANE protocol will initially be used to authenticate servers and c= ertificates in two roles in the DNS-Based Security for Email Project:
By binding the X.509 certificates used for
1. Transport Layer Security (TLS) to DNS names verified by DNSSEC and = supporting the use of these certificates in the mail server-to-mail server = communication;
2. Secure Secure/Multipurpose Internet Mail Extensions (S/MIME) to ema= il addresses encoded as DNS names verified by DNSSEC. 

[*] NCCOE expands to National Cybersecurity Center of Excellence. &nbs= p;Although NCCOE has been formed by the US agency NIST, its projects are op= en to both US and non-US participation.  


Allison
--_000_D1B9954244916amankinverisigncom_-- From nobody Wed Jul 1 21:36:10 2015 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 8A6A41B2E43; Wed, 1 Jul 2015 21:36:09 -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 pTrc9QI6ND6l; Wed, 1 Jul 2015 21:36:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 937921B2E51; Wed, 1 Jul 2015 21:36:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150702043605.1778.53439.idtracker@ietfa.amsl.com> Date: Wed, 01 Jul 2015 21:36:05 -0700 Archived-At: Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-ops-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: Thu, 02 Jul 2015 04:36:09 -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-13.txt Pages : 29 Date : 2015-07-01 Abstract: This document clarifies and updates the DNS-Based Authentication of Named Entities (DANE) TLSA specification (RFC6698) 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: https://tools.ietf.org/html/draft-ietf-dane-ops-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dane-ops-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 Wed Jul 1 21:47:12 2015 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 580E51AC414; Wed, 1 Jul 2015 21:47:11 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 4fahdI5oR3gu; Wed, 1 Jul 2015 21:47:10 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E04DB1ABD3F; Wed, 1 Jul 2015 21:47:09 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id C4A52284D2B; Thu, 2 Jul 2015 04:47:08 +0000 (UTC) Date: Thu, 2 Jul 2015 04:47:08 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150702044708.GA21534@mournblade.imrryr.org> References: <20150624070841.5695.48362.idtracker@ietfa.amsl.com> <20150624140553.GG14121@mournblade.imrryr.org> <495B9A5B-51D4-4248-AE50-E367E49FB3B2@gmail.com> <20150629041632.GV14121@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150629041632.GV14121@mournblade.imrryr.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: joel jaeggli , Kathleen Moriarty , dane-chairs@ietf.org, Elwyn Davies Subject: Re: [dane] Last Call Expired: 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 Jul 2015 04:47:11 -0000 On Mon, Jun 29, 2015 at 04:16:32AM +0000, Viktor Dukhovni wrote: > I've made significant progress, but not quite done yet. I expect > I'll get through the rest of the comments by Wednesday evening at > which point I'll push a -13 version. A few hours later than promised in my timezone, but still Wednesday evening in California (and of course Hawaii). :-) This should cover AD, GEN-ART and OPS-DIR feedback. If the changes trigger further comments that need to be addressed, please let me know. Diffs at: https://www.ietf.org/rfcdiff?url1=draft-ietf-dane-ops-12&url2=draft-ietf-dane-ops-13 -- Viktor. From nobody Thu Jul 2 02:02:25 2015 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 09FF91B30C0 for ; Thu, 2 Jul 2015 02:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, 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 1zGvgrQUQwKx for ; Thu, 2 Jul 2015 02:02:23 -0700 (PDT) Received: from smtp3.strotmann.de (smtp3.strotmann.de [IPv6:2a03:4000:2:33f::5353]) (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 340D11A1A20 for ; Thu, 2 Jul 2015 02:02:23 -0700 (PDT) Received: from debian01.home.strotmann.de (unknown [IPv6:2a01:198:2b6:1000:240:caff:fea0:83b3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp3.strotmann.de (Postfix) with ESMTPS id 66F9B7FF17 for ; Thu, 2 Jul 2015 11:02:19 +0200 (CEST) Received: from MacMini3.local (unknown [IPv6:2a01:198:2b6:0:b5a0:1767:3ea6:6b84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by debian01.home.strotmann.de (Postfix) with ESMTPSA id 0A31320005C for ; Thu, 2 Jul 2015 11:02:19 +0200 (CEST) Message-ID: <5594FE19.1020005@strotmann.de> Date: Thu, 02 Jul 2015 11:02:17 +0200 From: Carsten Strotmann User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: dane@ietf.org References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ekQpa2O6mRx8fWTBL3RhC8TgfXDhJuS79" Archived-At: Subject: Re: [dane] Deferral of SMIME draft 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 Jul 2015 09:02:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ekQpa2O6mRx8fWTBL3RhC8TgfXDhJuS79 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, On 29/06/15 20:41 PM, Olafur Gudmundsson wrote: >=20 > Dear Colleagues The editors of draft-ietf-dane-smime have requested > that draft be put on hold for at least a year to see how the OPENPGP > =E2=80=9Cexperiment=E2=80=9D works out. The chairs have agreed with thi= s request. that has been coming out of the blue. The SMIME-draft shares a great deal of issues with the OPENPGPKEY draft (e.g. the local-part discussion), and my hope was that whatever changes are applied to OPENPGPKEY would be merged into the SMIME-draft as well, and both would advance. In my view, the SMIME/DANE specification is already usable ("not perfect, but good enough") once there is a decision for the local part (and as I said on the discussion on OPENPGPKEY, I'm fine with the SHA256 hashing, but also with base32 if needbe). Both drafts are important, but SMIME has more relevance to bring user-friendly encryption to mainstream users. SMIME is more widely supported in mail-clients "out-of-the-box". Postponing the work on this draft does not help with the IETF goal of making the Internet protocols more secure against pervasive monitoring (RFC 7258). The mail users out there need secure email sooner than later.= There are some ISPs here in Germany that already have running code for SMIME/DANE to go into production with that service for their customers. Not having an DNS Type code from IANA is one of the major road-blocks for going live. Going into production with SMIME/DANE with a private DNS Type (as currently used with the Thunderbird Add-on and the SMIME-Milter) would be possible, but ugly. Migrating from the private DNS type to a standard DNS type later will be work and pain for admins and users. Would it be possible to at least update the SMIME draft with the latest changes on OPENPGPKEY, and get a DNS type code for SMIMEA records from IANA, before sending the draft to sleep? (if it needs be sleeping at all, I'm not convinced about that) Carsten Strotmann --ekQpa2O6mRx8fWTBL3RhC8TgfXDhJuS79 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVlP4aAAoJEEx+gN5PbC9CjWsP/0ZyMRjCQNJVh9Wpy9iIPlyu iG3EQQL8nCbBoP+yvFD5qxWLNBvMLoFgvwQ/jEEUqW1bkkaaCday6w57wjdFHk14 MBActypjPSaQeBd0WYwSHK3VKA1u5B38H4KZgAD+rcnquriw1sNottvRKe3RnAuK VkJuQRRbxFN1HkSC6kgo9AG5sRjDAlvEEGnf9zHzod9mT+pZHEdQlZOyIiGhQclc Y3Ijr50rqLqFJ8riUh6/RQ5QrefNVfq7prNoXuF2tktpgFN5RvlNy500P0aLOomF HROQGmnj9ZHno8FuOkSCH0QBQZCeX/AjOTaq2N5CIqmummQuL8vIHDvMtIkJjmTQ G+bf5BDOcfYBzmuYYm5Y4AGZ7OUCH+w4egXbIGZ+Q6ddjIJ1CLMf8FB7gAbXnItP jHahOYcHkKpeB/hfrsnjfsR40arC0Um1uvHqeMa6ies6KhogwjkPaYDwV4EpljLz uSuQgf32JdwJLzA2ViKVj/1OkGg+VdaFxT0DxPbhZ3sYaAnVJ0DHsmus9y9FkISD TisG6Zk6nSzlfGQqdgeTee4nMJ6bAsHO5A3Fb0T9CH/Q4QUGAPCzDTSIUt9JlqmW oSANQvGVWmzbfvVB8UM5OVOpB5mZzIuRe2sinSGB3wC5wL2a+QoPfDbbM0pZIVnK 30VkcKF/14t57ylseBEG =Ryb1 -----END PGP SIGNATURE----- --ekQpa2O6mRx8fWTBL3RhC8TgfXDhJuS79-- From nobody Thu Jul 2 06:30:43 2015 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 09E9D1A87A6; Thu, 2 Jul 2015 06:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 HrljCPk6BetY; Thu, 2 Jul 2015 06:30:39 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C552D1A87AD; Thu, 2 Jul 2015 06:30:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1D1CFBE33; Thu, 2 Jul 2015 14:30:26 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WR4SqtHK488Y; Thu, 2 Jul 2015 14:30:26 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id EE66CBE2F; Thu, 2 Jul 2015 14:30:25 +0100 (IST) Message-ID: <55953CF1.1010206@cs.tcd.ie> Date: Thu, 02 Jul 2015 14:30:25 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Viktor Dukhovni , dane@ietf.org References: <20150624070841.5695.48362.idtracker@ietfa.amsl.com> <20150624140553.GG14121@mournblade.imrryr.org> <495B9A5B-51D4-4248-AE50-E367E49FB3B2@gmail.com> <20150629041632.GV14121@mournblade.imrryr.org> <20150702044708.GA21534@mournblade.imrryr.org> In-Reply-To: <20150702044708.GA21534@mournblade.imrryr.org> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: joel jaeggli , Kathleen Moriarty , dane-chairs@ietf.org, Elwyn Davies Subject: Re: [dane] Last Call Expired: 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 Jul 2015 13:30:42 -0000 On 02/07/15 05:47, Viktor Dukhovni wrote: > On Mon, Jun 29, 2015 at 04:16:32AM +0000, Viktor Dukhovni wrote: > >> I've made significant progress, but not quite done yet. I expect >> I'll get through the rest of the comments by Wednesday evening at >> which point I'll push a -13 version. > > A few hours later than promised in my timezone, but still Wednesday > evening in California (and of course Hawaii). :-) > > This should cover AD, GEN-ART and OPS-DIR feedback. > > If the changes trigger further comments that need to be addressed, > please let me know. Diffs at: > > https://www.ietf.org/rfcdiff?url1=draft-ietf-dane-ops-12&url2=draft-ietf-dane-ops-13 Thanks Viktor. I've put this on the August 5th telechat. The July 9th one is fullish already so that's the next good time, and gives folks plenty of time to check the changes. Cheers, S. > > -- > Viktor. > From nobody Thu Jul 2 07:05:46 2015 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 ECBAE1A9075 for ; Thu, 2 Jul 2015 07:05:40 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 BP8KHvR0uswz for ; Thu, 2 Jul 2015 07:05:33 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FF161A89FA for ; Thu, 2 Jul 2015 07:05:33 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 39B33284D2B; Thu, 2 Jul 2015 14:05:32 +0000 (UTC) Date: Thu, 2 Jul 2015 14:05:32 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150702140531.GC21534@mournblade.imrryr.org> References: <5594FE19.1020005@strotmann.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5594FE19.1020005@strotmann.de> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] Deferral of SMIME draft 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 Jul 2015 14:05:41 -0000 On Thu, Jul 02, 2015 at 11:02:17AM +0200, Carsten Strotmann wrote: > Would it be possible to at least update the SMIME draft with the latest > changes on OPENPGPKEY, and get a DNS type code for SMIMEA records from > IANA, before sending the draft to sleep? I don't think that's a good plan. Once the email localpart to DNS owner fqdn prefix mapping is decided, there really not much more to do for SMIMEA. * Possibly separate owner fqdn for signature-only keys vs encryption keys: _sign._mumble.example.com IN SMIMEA U S M _encrypt._mumble.example.com IN SMIMEA U S M This really should be signalled in-band in the certificate, but if conceding on this gets the draft over the line, I would be willing to accept the compromise. * Observe that encryption keys (if published and whether the labels for encryption are separate or not) need to have matching type Full(0) if encryption is to be possible with the SMIMEA record in hand. So typically the matching type would be Full(0). However, using a different matching type supports (for better or worse) a model where encryption is not possible on first contact. Encrypted mail would be possible only after the recipient replies with encryption capable keys in the signature of the reply message. * I am not inclined to budge on any attempts to build explicit "revocation" into the draft, as with TLSA, revocation needs to be via "de-publication", rather than publication of a "revocation" record. The draft should explain the lifecycle model in more detail. + New mail only passes SMIME signature validity with a key whose trust is based on a DANE SMIMEA record, only if that record is (still) present at the time the mail is received. De-publishing an SMIMEA record immediately (modulo DNS and RRSIG TTLS, ...) deauthorizes the key for signing. + Already received mail is tagged as validated by the MUA at the time the signature is first processed. Thus years or decades old mail does not become inauthentic, just because the signing key used then has since expired. + Encryption of new mail requires keys (still) valid for use at the time the mail is sent. A matching type other than Full(0) requires prior possession of the keys, which can be determined still valid via the published digest. + When using DANE-TA(2) or PKIX-TA(0) records, and an individual user's keys need to be "revoked", the user's SMIMEA record can be changed to DANE-EE(3) or PKIX-EE(3) matching a new key/certificate until the compromised certificate expires. Once the compromised certificate expires, the user can be switched back to the organization-wide SMIMEA trust-anchor record. + When using DANE-EE(3) or PKIX-EE(1) records, to "revoke" just publish a new SMIMEA association. If "revocation" and owner-label format can be settled, we should be able to settle any remaining issues. So for me, the main obstacle is still the owner-label, which is the same for both OPENPGP and SMIMEA. -- Viktor. From nobody Thu Jul 2 07:13:25 2015 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 224621A1EF2 for ; Thu, 2 Jul 2015 07:13:24 -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 z_Zlwrh98CUT for ; Thu, 2 Jul 2015 07:13:22 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF5261A1DBC for ; Thu, 2 Jul 2015 07:13:08 -0700 (PDT) Received: by wibdq8 with SMTP id dq8so74966749wib.1 for ; Thu, 02 Jul 2015 07:13:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=V1kzcB9D/lWVD6vF05PtK7FLSu6mKg9PDkX/QhGqxGA=; b=Tc8tS3TLhxeMUQ27C3lKmppgBSq5PVI24dByaiCfVrPiQOPY+rTx6etZVuKlA/Fph0 KHJsF/gfe7V5zXo6XqRP12roczI/7AHWeHG7jLZd2jEMvB6YPj7Nt2wy2hL4+cKJAJma joS4/vxslHzCTSvyqIG1B/uLnLgEa5/VxoHeYqdQ5eSCMaIFSGZftDl4MpfT8OrnRlRj +x8eBghn/Mz36cFsPWB0MWXSE0o9H1abUtYG/1nGAcije/IZf3QV9QqkG3F/06N0ooxB akQL9oaD9XS/J11y+NEms+lqR1qnyXAoEnk5XuhZ/0DnRHSx5ZlQ46x671rFZfKyOGQb b6kg== X-Received: by 10.194.123.4 with SMTP id lw4mr57759580wjb.94.1435846387675; Thu, 02 Jul 2015 07:13:07 -0700 (PDT) Received: from [172.24.250.253] ([194.29.32.131]) by mx.google.com with ESMTPSA id ju2sm8882972wid.12.2015.07.02.07.13.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 Jul 2015 07:13:06 -0700 (PDT) From: Yoav Nir Content-Type: multipart/alternative; boundary="Apple-Mail=_874BDF45-CF9F-42B8-BD1E-9D8B3A5ABF49" Message-Id: <8DE8B456-8050-491E-AAB1-7EC278380B8F@gmail.com> Date: Thu, 2 Jul 2015 17:13:01 +0300 To: dane@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) X-Mailer: Apple Mail (2.2102) Archived-At: Subject: [dane] DANE and IPsec 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 Jul 2015 14:13:24 -0000 --Apple-Mail=_874BDF45-CF9F-42B8-BD1E-9D8B3A5ABF49 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi I see that our milestones still contain a DANE with IPsec document, = although the WG has not yet discussed or adopted such a document. There is one proposed document (draft-osterweil-dane-ipsec). That one = ties DANE to opportunistic encryption. While interesting, I think we = need a far more basic document. This is what I would like to propose. IPsec as defined in RFC 4301 has a static configuration. Specifically, = there is a data structure called PAD (peer authorization database). This = structure contains a list of peers authorized to communicate with this = IPsec entity, and for each such peer the following: - protocol and method for authentication - authentication data - constraints on the types and values of IKE IDs sent. - location, such as IP address (or DNS name). For example, we might have a peer that will use IKE with certificates to = authenticate, its certificate will have an alternate name that says = =E2=80=9Cvpngw=E2=80=9D, It will send an ID payload that says =E2=80=9CVPN= Gateway=E2=80=9D and it=E2=80=99s located at 192.0.2.5. What I can see DANE doing is reducing many of those fields in the PAD to = a single field: and FQDN. So a PAD record for a peer when DANE is used = will have: - protocol and method (IKE with DANE) - FQDN: as in vpngw.example.com The IPsec entity will resolve this FQDN with DNSSEC, yielding both an IP = address and a DANE record. The DANE record can be used to identify the = certificate or raw public key used in IKE. And the document can specify = what the ID payload looks like: in all likelihood the FQDN itself is a = good idea. Similar to the way a TLS client gives the TLS server a hint = of identity using SNI, IKE has an IDr payload in the IKE_AUTH request = which should perform a similar function.=20 What do people think? =20 Yoav --Apple-Mail=_874BDF45-CF9F-42B8-BD1E-9D8B3A5ABF49 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi

I see = that our milestones still contain a DANE with IPsec document, although = the WG has not yet discussed or adopted such a document.

There is one proposed = document (draft-osterweil-dane-ipsec). That one ties DANE to = opportunistic encryption. While interesting, I think we need a far more = basic document. This is what I would like to propose.

IPsec as defined in RFC = 4301 has a static configuration. Specifically, there is a data structure = called PAD (peer authorization database). This structure contains a list = of peers authorized to communicate with this IPsec entity, and for each = such peer the following:
 - protocol and = method for authentication
 - authentication = data
 - constraints on the types and values of = IKE IDs sent.
 - location, such as IP address = (or DNS name).

For example, we might have a peer that will use IKE with = certificates to authenticate, its certificate will have an alternate = name that says =E2=80=9Cvpngw=E2=80=9D, It will send an ID payload that = says =E2=80=9CVPN Gateway=E2=80=9D and it=E2=80=99s located at = 192.0.2.5.

What = I can see DANE doing is reducing many of those fields in the PAD to a = single field: and FQDN.  So a PAD record for a peer when DANE is = used will have:
 - protocol and method (IKE = with DANE)
 - FQDN: as in vpngw.example.com

The IPsec entity will resolve this FQDN = with DNSSEC, yielding both an IP address and a DANE record. The DANE = record can be used to identify the certificate or raw public key used in = IKE. And the document can specify what the ID payload looks like: in all = likelihood the FQDN itself is a good idea. Similar to the way a TLS = client gives the TLS server a hint of identity using SNI, IKE has an IDr = payload in the IKE_AUTH request which should perform a similar = function. 

What do people think?  

Yoav

= --Apple-Mail=_874BDF45-CF9F-42B8-BD1E-9D8B3A5ABF49-- From nobody Thu Jul 2 07:34:11 2015 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 690DC1A88D1 for ; Thu, 2 Jul 2015 07:34:09 -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 HKuV89x6RF5g for ; Thu, 2 Jul 2015 07:34:07 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C08B1A88A0 for ; Thu, 2 Jul 2015 07:34:07 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mMhkj1xlWzCmS for ; Thu, 2 Jul 2015 16:34:05 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=L//G31UR X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id kUbl96-dykfV for ; Thu, 2 Jul 2015 16:34:04 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Thu, 2 Jul 2015 16:34:04 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 53EAA800B3 for ; Thu, 2 Jul 2015 10:34:03 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1435847643; bh=gqgjDVs8QuZwhsiKjbHZilPKZJVXmnxQOKregcIuSts=; h=Date:From:To:Subject:In-Reply-To:References; b=L//G31URJGoGu2IrubvrevlK9nix9o4RTSqNpZJNUPQ+JEuoy7744XavwaAlYbWIR sq/QWkcymB/wK3Vh0QnwMV/FwTpmdUbQeLc3FCxyiArnx1krBaDiyY+ZhdU8WHmtlt hB8RNa8cRh75uUJ1b3Bm5L4R9AqB88+RJn7BuX4g= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t62EY3I2020433 for ; Thu, 2 Jul 2015 10:34:03 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Thu, 2 Jul 2015 10:34:02 -0400 (EDT) From: Paul Wouters To: dane@ietf.org In-Reply-To: <20150702140531.GC21534@mournblade.imrryr.org> Message-ID: References: <5594FE19.1020005@strotmann.de> <20150702140531.GC21534@mournblade.imrryr.org> User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [dane] Deferral of SMIME draft 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 Jul 2015 14:34:09 -0000 On Thu, 2 Jul 2015, Viktor Dukhovni wrote: > So for me, the main obstacle is still the owner-label, which is > the same for both OPENPGP and SMIMEA. No one has given me feedback (positive or negative) on the "lowercase if ascii, normalise otherwise", then lookup base32/split or using hash, that was advised to me by some of the EAI people. if we do that with base32/split, I think it addresses all concerns: - no guessing / multiple lookups - works for non-ascii - works for ascii - works for online signing with smtp server integration Paul From nobody Thu Jul 2 08:00:27 2015 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 02CE61A885F for ; Thu, 2 Jul 2015 08:00:27 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 axc6Ah86sguw for ; Thu, 2 Jul 2015 08:00:25 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38EC21A8AFB for ; Thu, 2 Jul 2015 07:59:59 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 557EC284D2B; Thu, 2 Jul 2015 14:59:58 +0000 (UTC) Date: Thu, 2 Jul 2015 14:59:58 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150702145958.GD21534@mournblade.imrryr.org> References: <5594FE19.1020005@strotmann.de> <20150702140531.GC21534@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: Subject: Re: [dane] Deferral of SMIME draft 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 Jul 2015 15:00:27 -0000 On Thu, Jul 02, 2015 at 10:34:02AM -0400, Paul Wouters wrote: > On Thu, 2 Jul 2015, Viktor Dukhovni wrote: > > >So for me, the main obstacle is still the owner-label, which is > >the same for both OPENPGP and SMIMEA. > > No one has given me feedback (positive or negative) on the "lowercase if > ascii, normalise otherwise", then lookup base32/split or using hash, > that was advised to me by some of the EAI people. Works for me. I don't know which particular unicode normal form is most appropriate, but so long as you got sound advice on that I have no objections. > if we do that with base32/split, I think it addresses all concerns: > > - no guessing / multiple lookups > - works for non-ascii > - works for ascii > - works for online signing with smtp server integration If this really were to be integrated into the SMTP infrastructure for online signing, I would want a protocol over TCP that is not proxied by ISP resolvers, so the SMTP server would have a better idea of where the request is coming from. Otherwise, a large fraction of the requests would be proxied by 8.8.8.8 and friends, and rate limiting abusive clients becomes very difficult. That said, if rate limiting "dictionary attack" query patterns is not a concern, the above gives sites that don't mind the exposure more flexibility. This is not worse than the opaque hash. Of course email addresses that are too long to encode in a 255 octet owner name can't have keys, but they're unlikely to be very popular with users. -- Viktor. P.S. In the mean time PHB seems to be working on some sort of comprehensive end-to-end email architecture. Is there a possibility that his "whole elephant" approach will have more traction than adjoining DANE key management to an otherwise largely unchanged email toolchain? Has anyone looked at his work in detail (I don't recall how much has been published in detail so far). From nobody Thu Jul 2 08:03:45 2015 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 BB6751A8938 for ; Thu, 2 Jul 2015 08:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_57=0.6, 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 iI0jbrI6wMFr for ; Thu, 2 Jul 2015 08:03:44 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01F471A8971 for ; Thu, 2 Jul 2015 08:03:44 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 1C913284D2B; Thu, 2 Jul 2015 15:03:43 +0000 (UTC) Date: Thu, 2 Jul 2015 15:03:43 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150702150342.GE21534@mournblade.imrryr.org> References: <8DE8B456-8050-491E-AAB1-7EC278380B8F@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8DE8B456-8050-491E-AAB1-7EC278380B8F@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] DANE and IPsec 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 Jul 2015 15:03:44 -0000 On Thu, Jul 02, 2015 at 05:13:01PM +0300, Yoav Nir wrote: > The IPsec entity will resolve this FQDN with DNSSEC, yielding both an IP > address and a DANE record. The DANE record can be used to identify the > certificate or raw public key used in IKE. What prevents IP address hijacking (mallory.example publishes alice.example's IP address and now mallory's IPSEC keys are used to encrypt traffic to alice)? I thought that Paul Wouters is working on a more comprehensive specification, IIRC in an IPSEC working group where it can get better informed review. This is much more of an IPSEC design problem, than a DANE design problem. Once the IPSEC parts are in good shape, perhaps the document can be discussed here for any final DANE-specific issues (details of just the DANE RRset used for the document). -- Viktor. From nobody Thu Jul 2 08:09:08 2015 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 DEAF21A8A16 for ; Thu, 2 Jul 2015 08:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.41 X-Spam-Level: X-Spam-Status: No, score=-1.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_57=0.6, 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 89aq7xNGGxAE for ; Thu, 2 Jul 2015 08:09:05 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D74C1A89FE for ; Thu, 2 Jul 2015 08:09:05 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mMjW41G5yzCDj for ; Thu, 2 Jul 2015 17:09:04 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=A1UFq6ga X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 5PI5vec-IwlQ for ; Thu, 2 Jul 2015 17:09:03 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Thu, 2 Jul 2015 17:09:03 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 74A0D80042 for ; Thu, 2 Jul 2015 11:09:02 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1435849742; bh=4rRDtnimGt+f4UUIifO51aifiatJia3DMDfgL6sUEfY=; h=Date:From:To:Subject:In-Reply-To:References; b=A1UFq6garVh7M7nVW5QiFIrwiGbQsi4zGIp+7LgB3bOnc33lelKxkaoBkEdcMNrzo VoUTbgj93hhwrqOZoLX7g/1iPYsQk1yeQLl+DV27ACn0rApedIPxmhwVG2LSyCuGwV M/IyJiXPB4VLNmsG7iqdalCGpGF4KsRUwzmFPC5k= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t62F92Mm020927 for ; Thu, 2 Jul 2015 11:09:02 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Thu, 2 Jul 2015 11:09:02 -0400 (EDT) From: Paul Wouters To: dane@ietf.org In-Reply-To: <20150702150342.GE21534@mournblade.imrryr.org> Message-ID: References: <8DE8B456-8050-491E-AAB1-7EC278380B8F@gmail.com> <20150702150342.GE21534@mournblade.imrryr.org> User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dane] DANE and IPsec 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 Jul 2015 15:09:07 -0000 On Thu, 2 Jul 2015, Viktor Dukhovni wrote: >> The IPsec entity will resolve this FQDN with DNSSEC, yielding both an IP >> address and a DANE record. The DANE record can be used to identify the >> certificate or raw public key used in IKE. > > What prevents IP address hijacking (mallory.example publishes > alice.example's IP address and now mallory's IPSEC keys are used > to encrypt traffic to alice)? This is the biggest problem yes. At best, you can detect you got two different IPsec pubkeys for the same IP (say 8.8.8.8) and then you have to disconnect both to prevent encrypting to the attacker. (eg if i put in evil.nohats.ca. IN A 8.8.8.8 along with an IPSECKEY and have you trigger opportunistic IPsec to evil.nohats.ca) Of course, a layer of NAT or one-local-ip-per-remote could address that but it is extremely ugly. So we (libreswan) are still undecided. > I thought that Paul Wouters is working on a more comprehensive > specification, IIRC in an IPSEC working group where it can get > better informed review. This is much more of an IPSEC design > problem, than a DANE design problem. Yoav is one of the core IPsec people, so that's good :) > Once the IPSEC parts are in good shape, perhaps the document can > be discussed here for any final DANE-specific issues (details of > just the DANE RRset used for the document). I'm not sure if we need a new record. We could use IPSECKEY with some restrictions (gateway option must be unused) Paul From nobody Thu Jul 2 08:17:18 2015 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 63BDF1A8A82 for ; Thu, 2 Jul 2015 08:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.062 X-Spam-Level: X-Spam-Status: No, score=-2.062 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 5TVTCqLk4SOa for ; Thu, 2 Jul 2015 08:17:15 -0700 (PDT) Received: from mail.sys4.de (mail.sys4.de [194.126.158.139]) (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 482611A8A7C for ; Thu, 2 Jul 2015 08:17:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sys4.de; h= content-transfer-encoding:content-disposition:content-type :content-type:mime-version:message-id:subject:subject:from:from :date:date; s=mail201310; t=1435850233; x=1437664634; bh=Uf/SUgu 7kA4Lyf9/NaJP7YSyH43sipRoRsFZv9J5ZBw=; b=R8JWA4KQjtaR21pved2egxF BQqoa9eIyTEcNDdxDaDdO/eZPjVsUeggrCq7PpTzBBMF5Bv5b2w28yrJNNhHZ/Lc L8alEXUOceLqlK1sPGR+zT0Rf9Fdma5MgMIsLXa7J150h66NwxvZhb1iTT1uhIXr giTMuTqXktIy+8D0BrSG7qiDNWHOEUapbZErzxgdes68VLGy7tgKO6OhtcLvqCRk 09I1nZYkWfhP0oqWqQSWKk+MQLfZZxq0IeO63btX4Gme/DzmO8S2Pt81GM6D27gR +7yxJqhOnWvComQ5398BremvXaJJjNbmobNU5HD1WkIEy+ZUbufWpTjfVNZMzMg= = X-Virus-Scanned: Debian amavisd-new at mail.sys4.de Received: from sys4.de (ppp-188-174-104-198.dynamic.mnet-online.de [188.174.104.198]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sys4.de (Postfix) with ESMTPSA id 3mMjhT2cXyzcN for ; Thu, 2 Jul 2015 17:17:13 +0200 (CEST) Date: Thu, 2 Jul 2015 17:17:11 +0200 From: Patrick Ben Koetter To: dane@ietf.org Message-ID: <20150702151711.GC3764@sys4.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit Archived-At: Subject: [dane] ANN: smilla - SMIMEA aware Milter 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 Jul 2015 15:17:17 -0000 We've just released smilla, a SMIMEA aware milter. smilla implements draft-ietf-dane-smime as specified by the IETF DANE WG. The program has been written in Python. It has been in production since April 2015 at some ISPs and is considered stable. At the moment it uses a generic DNS RR. This will change once a dedicated resource record has been defined. smilla is a joined effort between sys4 and Posteo.de to demonstrate our interest in SMIMEA. You can find the source code at . FYI: smilla will be merged with Paul Wouters openpgpkey-milter. The merge already started a few weeks ago. We expect to finish it soon. The result will be released as a new project on github. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein From nobody Thu Jul 2 08:29:59 2015 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 CF46E1A8AB9 for ; Thu, 2 Jul 2015 08:29: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, RCVD_IN_DNSWL_NONE=-0.0001] 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 duYnrbX4ak_o for ; Thu, 2 Jul 2015 08:29:55 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40CBB1A8AB6 for ; Thu, 2 Jul 2015 08:29:55 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 94317284D2B; Thu, 2 Jul 2015 15:29:48 +0000 (UTC) Date: Thu, 2 Jul 2015 15:29:48 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150702152948.GF21534@mournblade.imrryr.org> References: <8DE8B456-8050-491E-AAB1-7EC278380B8F@gmail.com> <20150702150342.GE21534@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: Subject: Re: [dane] DANE and IPsec 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 Jul 2015 15:29:57 -0000 On Thu, Jul 02, 2015 at 11:09:02AM -0400, Paul Wouters wrote: > On Thu, 2 Jul 2015, Viktor Dukhovni wrote: > > >>The IPsec entity will resolve this FQDN with DNSSEC, yielding both an IP > >>address and a DANE record. The DANE record can be used to identify the > >>certificate or raw public key used in IKE. > > > >What prevents IP address hijacking (mallory.example publishes > >alice.example's IP address and now mallory's IPSEC keys are used > >to encrypt traffic to alice)? > > This is the biggest problem yes. At best, you can detect you got > two different IPsec pubkeys for the same IP (say 8.8.8.8) and > then you have to disconnect both to prevent encrypting to the attacker. I also thought that Nico had some ideas about extending the socket API so that one could associate a socket endpoint with a "domain", not an IP address, and some sort of "connection latching", but I am just repeating terms I don't fully understand. Anyway, my takeway was that this a difficult problem, and that the DNS keying records were not the difficult parts, so I think that perhaps this work is best done elsewhere. -- Viktor. From nobody Thu Jul 2 08:41:37 2015 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 A0CA01AC43D for ; Thu, 2 Jul 2015 08:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_57=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 ccpmdzrghiZp for ; Thu, 2 Jul 2015 08:41:35 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 755311AC438 for ; Thu, 2 Jul 2015 08:41:35 -0700 (PDT) Received: by wicgi11 with SMTP id gi11so77614612wic.0 for ; Thu, 02 Jul 2015 08:41:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9NmyILCQkeCeXHMz91uN+3u/a5ckhwXk6NRvDP6lZeQ=; b=NrjwScj+Gfsak7P/apeIkjp82Yu5TJfzjXVFhUXaU0NG8z67zvDUew3dWokSSMWr8t ikI7EjmxqutduV1+INRj4tNBV1IxUkvQxOexcqcZChcKRkCLJyq3cAJsgRWhGk9HJOPf CntuDRABc450/xd7ax43rPynKIymSGhh11yJbcJaRc/IR1ESIBmlQwSEtezlhEOkZQny srFg+uDVRu9zl5pQP3WuCy3Fz9nSGcSLJscxO9bpN32jqA+RnPeV6rMQV/L0T9C6qwpG YNjSJstQEARR2i8CaET5C8+EQdnATJkwK0Fb+rStX84Lv6z3BmHbCpW1PWv2BElsASqG UqOQ== X-Received: by 10.180.37.229 with SMTP id b5mr55097258wik.16.1435851694132; Thu, 02 Jul 2015 08:41:34 -0700 (PDT) Received: from yoavs-mbp.mshome.net ([176.12.136.42]) by mx.google.com with ESMTPSA id u6sm8719549wja.40.2015.07.02.08.41.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 Jul 2015 08:41:33 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Yoav Nir In-Reply-To: <20150702150342.GE21534@mournblade.imrryr.org> Date: Thu, 2 Jul 2015 18:40:45 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <5B3828FB-0D7D-43D9-A7E0-29814A7B4133@gmail.com> References: <8DE8B456-8050-491E-AAB1-7EC278380B8F@gmail.com> <20150702150342.GE21534@mournblade.imrryr.org> To: ietf-dane@dukhovni.org X-Mailer: Apple Mail (2.2102) Archived-At: Cc: dane@ietf.org Subject: Re: [dane] DANE and IPsec 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 Jul 2015 15:41:36 -0000 > On Jul 2, 2015, at 6:03 PM, Viktor Dukhovni = wrote: >=20 > On Thu, Jul 02, 2015 at 05:13:01PM +0300, Yoav Nir wrote: >=20 >> The IPsec entity will resolve this FQDN with DNSSEC, yielding both an = IP >> address and a DANE record. The DANE record can be used to identify = the >> certificate or raw public key used in IKE. >=20 > What prevents IP address hijacking (mallory.example publishes > alice.example's IP address and now mallory's IPSEC keys are used > to encrypt traffic to alice)? Not sure I follow. Mallory publishes - mallory.example.com IN A 192.0.2.5 - mallory.example.com IN TLSA .... But there=E2=80=99s also=20 - alice.example.com IN A 192.0.2.5 - alice.example.com IN TLSA .... So Mallory can push people looking for his IPsec entity to go to = Alice=E2=80=99s IPsec entity. Once there they might accept the public = key they=E2=80=99re presented with (if he has copied the contents of the = TLSA record) or not. Assuming Mallory cannot publish alice.example.com = records, where is the attack? > I thought that Paul Wouters is working on a more comprehensive > specification, IIRC in an IPSEC working group where it can get > better informed review. This is much more of an IPSEC design > problem, than a DANE design problem. Paul is working on host to host IPsec for opportunistic encryption. The = problem I would like to solve is that configuring the PAD is (1) hard, = and (2) unwieldy, because any changes to your certificate requires = updating the static configuration on all your peers. Yoav From nobody Thu Jul 2 08:45:30 2015 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 E54B41ACC81 for ; Thu, 2 Jul 2015 08:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.649 X-Spam-Level: X-Spam-Status: No, score=0.649 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35, J_CHICKENPOX_54=0.6, MIME_8BIT_HEADER=0.3, 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 fPdY2_cn2Jq7 for ; Thu, 2 Jul 2015 08:45:23 -0700 (PDT) Received: from mx.roessner-net.de (mail.roessner-net.de [193.239.107.42]) (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 C04731A005F for ; Thu, 2 Jul 2015 08:45:22 -0700 (PDT) Received: from mail.roessner-net.de (mail.roessner-net.de [193.239.107.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.roessner-net.de", Issuer "thawte DV SSL CA - G2" (verified OK)) by mx.roessner-net.de (Postfix) with ESMTPS id 3mMkJv5yMXzGpJH for ; Thu, 2 Jul 2015 17:45:19 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=roessner-network-solutions.com; s=swioBi3opho; t=1435851920; i=@roessner-network-solutions.com; bh=ByfZzAoHOXXP3sKxhjZdmMiWNVGOW03HQ+4vkxpUaOc=; h=From:Subject:Date:References:To:In-Reply-To; b=bftMgkSAGs1uvXkX8gaGxXtyyw6bDUW2+ulU0VQPvTh9jBTRcXrgs6RCzsWg2TjRj xJRvuXCXRLUMp84guiinhqZp486uFL+HAX2ODOVU6Wvap0bsc1Kc9Dvevin0M7vi8x wAtFHy1bWV3vGXiNio+euiXXzyPu9wwX6PtaCtqx+oLgVnczs6SyFptFOn7VJ0L3tP y+QDuAUhVym0AWIpg9OvjsO0XgMNw2QApkLCsDu+afHT/HJjeYbGtMtb4JXBIrn1d+ r3j1Emew+OYasuMJ18r2jQdUu5ozTPEFZVzQ73AhH47wMIEtpY1AEgHt7+93y9zEbR 8m0IXnyjpDcHA== Received: from [172.16.2.200] (static-201-106.deltasurf.de [193.239.106.201]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Christian Roessner", Issuer "RootCA (c) 2014" (verified OK)) (Authenticated sender: c@roessner.co) by mail.roessner-net.de (Postfix) with ESMTPSA id 3mMkJv2QVczMlDX for ; Thu, 2 Jul 2015 17:45:19 +0200 (CEST) From: =?utf-8?Q?Christian_R=C3=B6=C3=9Fner?= Content-Type: multipart/signed; boundary="Apple-Mail=_54AEB53F-D2B5-44DF-9A93-9DF16258D32A"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: <95A81908-E9A7-4064-A186-E626A87D4110@roessner-network-solutions.com> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) Date: Thu, 2 Jul 2015 17:45:19 +0200 References: <20150702151711.GC3764@sys4.de> To: dane In-Reply-To: <20150702151711.GC3764@sys4.de> X-Mailer: Apple Mail (2.2102) Outgoingd-Filter: Outgoingd Filter v0.4.0_m1 mail.roessner-net.de 3mMkJv2QVczMlDX Anomaly-Results: mail.roessner-net.de; rate=0% Archived-At: Subject: Re: [dane] ANN: smilla - SMIMEA aware Milter 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 Jul 2015 15:45:27 -0000 --Apple-Mail=_54AEB53F-D2B5-44DF-9A93-9DF16258D32A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > Am 02.07.2015 um 17:17 schrieb Patrick Ben Koetter : >=20 > We've just released smilla, a SMIMEA aware milter. smilla implements > draft-ietf-dane-smime as specified by the IETF DANE WG. >=20 > The program has been written in Python. It has been in production = since April > 2015 at some ISPs and is considered stable. >=20 > At the moment it uses a generic DNS RR. This will change once a = dedicated > resource record has been defined. >=20 > smilla is a joined effort between sys4 and Posteo.de to demonstrate = our > interest in SMIMEA. >=20 > You can find the source code at . >=20 > FYI: smilla will be merged with Paul Wouters openpgpkey-milter. The = merge > already started a few weeks ago. We expect to finish it soon. The = result will > be released as a new project on github. Just a little side note to the milter: As some top level DNS servers have/had problems with their firewalls = concerning generic RRs, I have modified the code to let go a mail in = plain text, if asking the DNS server results in a "serv fail=E2=80=9C. = This will be changed, once a standardized RR for SMIMEA is available. I also have set a global variable DEBUG=3DTrue, which keeps the milter = in foreground. Set it to False to get a regular daemon. As this code uses crypto routines to deal with PKCS#7, I invite people = to review the code for security concerns. When we developed the milter, we only thought about outgoing mail on the = submission port. But the milter does also great work on the incoming = side! Configuring it this way, all your mail is stored encrypted on disk = and the key is on your workstation! So SMIMEA is very interesting for = both directions of the mail transport. Further discussion on Github. Thanks Christian= --Apple-Mail=_54AEB53F-D2B5-44DF-9A93-9DF16258D32A Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIE8TCCBO0w ggPVoAMCAQICAhAFMA0GCSqGSIb3DQEBCwUAMIHeMQswCQYDVQQGEwJERTESMBAGCgmSJomT8ixk ARkWAmRlMRwwGgYKCZImiZPyLGQBGRYMcm9lc3NuZXItbmV0MQ8wDQYDVQQIDAZIZXNzZW4xEDAO BgNVBAcMB0Fsc2ZlbGQxDzANBgNVBAoMBlIuTi5TLjEeMBwGA1UECwwVQ2VydGlmaWNhdGUgQXV0 aG9yaXR5MRgwFgYDVQQDDA9Sb290Q0EgKGMpIDIwMTQxLzAtBgkqhkiG9w0BCQEWIGNAcm9lc3Nu ZXItbmV0d29yay1zb2x1dGlvbnMuY29tMB4XDTE0MDkwNzE0MDI0NloXDTI0MDkwNDE0MDI0Nlow gdAxCzAJBgNVBAYTAkRFMRIwEAYKCZImiZPyLGQBGRYCZGUxHDAaBgoJkiaJk/IsZAEZFgxyb2Vz c25lci1uZXQxDzANBgNVBAgMBkhlc3NlbjEQMA4GA1UEBwwHQWxzZmVsZDEPMA0GA1UECgwGUi5O LlMuMQ0wCwYDVQQLDARNYWlsMRswGQYDVQQDDBJDaHJpc3RpYW4gUm9lc3NuZXIxLzAtBgkqhkiG 9w0BCQEWIGNAcm9lc3NuZXItbmV0d29yay1zb2x1dGlvbnMuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAvRa6QBgHt56hf1RuKHsNkXPXTFzG0RLualxlyfsJS0nWNWFaBD7ceZ8F WhnP7ypHSyWE4aCy7BYM4n2iVDm9m8bKV5cXuSdLY3kefqSOk9+YvCLu1MqQk70BY7UReS7OUJ1r ml1v09igaYA1+4FT8Um5oXB69BMm/JxFlkJ/TEu7KQzZ++oWavezChU+tc3neP4TJ9B+e4Q3BiTW RPMzmWf1HDR9RfhU4YPT0AQpvMusYUN/QKqKgh7cCCx8fcMO7noZDCNJchKLuil8/jKznJtj8+/B mwbvHJjshv/txNxKr8Id1K7+cQMweMA6uuOiJIt9oOAcPM8UEMzFwrShvwIDAQABo4HAMIG9MAkG A1UdEwQCMAAwLAYJYIZIAYb4QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVkIENlcnRpZmljYXRlMB0G A1UdDgQWBBQkzf3k5Z/BAcTvlAu53yCIqJXMUzAfBgNVHSMEGDAWgBTgcUa1UKCapZJ6/qUWTH2C bOT9nDBCBgNVHR8EOzA5MDegNaAzhjFodHRwOi8vd3d3LnJvZXNzbmVyLW5ldHdvcmstc29sdXRp b25zLmNvbS9jcmwucGVtMA0GCSqGSIb3DQEBCwUAA4IBAQBGVbjnbP3RkXd5BStfKfyGWwNAAzrS dR1fy+tje5Zoq8t9nvxtaNnPCehyztTgUFfNaARFI5yY+z2ZaJ58NnQhSKYuZDkx/mwZkGcVbvp5 r7uDqFo42OfHej6SMIMzwKuXEgF26bKmcm4uZOouw8Ec68raEfnRY22loL8usx2yrH1qURgjSTJP PZ2Rs+2WVTWxylhLADAf7aAXTUPCx4zW6cGPYA2GR8w9ZYk74fIpPus4hs/LbBUVYtOMX6daVwkC 8xmQmcRihGo8wB5N2dH2T0fPV70HSn5GTUQ8O69ObDT8zo33dvg2w4swbWaKdn11Ywhd+HhvM+Ru bOSB+EBuMYIEYjCCBF4CAQEwgeUwgd4xCzAJBgNVBAYTAkRFMRIwEAYKCZImiZPyLGQBGRYCZGUx HDAaBgoJkiaJk/IsZAEZFgxyb2Vzc25lci1uZXQxDzANBgNVBAgMBkhlc3NlbjEQMA4GA1UEBwwH QWxzZmVsZDEPMA0GA1UECgwGUi5OLlMuMR4wHAYDVQQLDBVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkx GDAWBgNVBAMMD1Jvb3RDQSAoYykgMjAxNDEvMC0GCSqGSIb3DQEJARYgY0Byb2Vzc25lci1uZXR3 b3JrLXNvbHV0aW9ucy5jb20CAhAFMAkGBSsOAwIaBQCgggJRMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDcwMjE1NDUyMFowIwYJKoZIhvcNAQkEMRYEFOlfvrgq Mq+M+lGI0+9/+q8t3i/TMIH2BgkrBgEEAYI3EAQxgegwgeUwgd4xCzAJBgNVBAYTAkRFMRIwEAYK CZImiZPyLGQBGRYCZGUxHDAaBgoJkiaJk/IsZAEZFgxyb2Vzc25lci1uZXQxDzANBgNVBAgMBkhl c3NlbjEQMA4GA1UEBwwHQWxzZmVsZDEPMA0GA1UECgwGUi5OLlMuMR4wHAYDVQQLDBVDZXJ0aWZp Y2F0ZSBBdXRob3JpdHkxGDAWBgNVBAMMD1Jvb3RDQSAoYykgMjAxNDEvMC0GCSqGSIb3DQEJARYg Y0Byb2Vzc25lci1uZXR3b3JrLXNvbHV0aW9ucy5jb20CAhAFMIH4BgsqhkiG9w0BCRACCzGB6KCB 5TCB3jELMAkGA1UEBhMCREUxEjAQBgoJkiaJk/IsZAEZFgJkZTEcMBoGCgmSJomT8ixkARkWDHJv ZXNzbmVyLW5ldDEPMA0GA1UECAwGSGVzc2VuMRAwDgYDVQQHDAdBbHNmZWxkMQ8wDQYDVQQKDAZS Lk4uUy4xHjAcBgNVBAsMFUNlcnRpZmljYXRlIEF1dGhvcml0eTEYMBYGA1UEAwwPUm9vdENBIChj KSAyMDE0MS8wLQYJKoZIhvcNAQkBFiBjQHJvZXNzbmVyLW5ldHdvcmstc29sdXRpb25zLmNvbQIC EAUwDQYJKoZIhvcNAQEBBQAEggEAQy6VRYn1bR9ghAEyh56T4WVrnDs542376Ql7On0yEcad94um Ms/9wpAtgdxZuPzBCGy1TvB0M2HenE45wOrdovm7c2XsFLO2VjIaZEanFTbrjjzHwnkevhzdn3Vl +N3t/WM4odLzLRU8TKt0m1jVivp4j0bQmJSQ5ppIG2Wz77RlXBn65Og0QjEAzVSOBEFe1S7VnLtn emX9ty8cmahEO2GBn/F9KS/kLwDoMkXTIRHDsbjUki/SES9YmYkkObzQOejbqohMlTqBwoR6JYHb m3Ob1MFizYG2sQ8Cp2jHoM4Xn7TgdWDu+W4LCH6b9NIMbV0ZDTi6HnotrQmc4BxssAAAAAAAAA== --Apple-Mail=_54AEB53F-D2B5-44DF-9A93-9DF16258D32A-- From nobody Thu Jul 2 08:47:36 2015 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 1F5831ACCEA for ; Thu, 2 Jul 2015 08:47:35 -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 c64nUgGHZSI7 for ; Thu, 2 Jul 2015 08:47:34 -0700 (PDT) Received: from mail-ig0-f182.google.com (mail-ig0-f182.google.com [209.85.213.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D95B11ACC7F for ; Thu, 2 Jul 2015 08:47:33 -0700 (PDT) Received: by igcsj18 with SMTP id sj18so165389744igc.1 for ; Thu, 02 Jul 2015 08:47:33 -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=vcnH6wpGZlB+s2bxSz32IUE4PNzr6xr9AaMav7WAFQw=; b=lyZlY6TI2JF5ZTwWhAAt7CpVhsuf0DlAdPBVpOvVMcZvcxPUKj5njUT1b6345nowZi fo+EsgTXwD57wVzy3TZzkwDYlglSkjJCnveCobS9Kp19rPt95KjsL4GK+Fl+sXKsrG3R 74q5+CIDYjeYcHiXSAveldtb/KrM2lGKkKytNIRQ0MwpXk16mVELPDTs21wjGGZjG7I+ 5qZHjpEKqzZIZ6nJxd9dmvZES+WtHaoaQBBm25kQY3ddQlbyj4Lo7h6JAxbYGhUyvFgr 7gM0nV94e14FrSEGBbono1yOYfJWcq8KAhimn5z6Qjs6W0W/GT7XmCmehY1Ca6lNOBXT kQGw== X-Gm-Message-State: ALoCoQn5cRxfIp8kG5beizOlZcKGMpMohMzQ48gPYJsr44+jNwUktiFMKPlERyWPxWpZs/5efbLI X-Received: by 10.42.204.4 with SMTP id fk4mr12341180icb.72.1435852053366; Thu, 02 Jul 2015 08:47:33 -0700 (PDT) Received: from aither.local ([2601:282:4201:ef5b:cca2:77b0:9b88:4ca0]) by mx.google.com with ESMTPSA id j3sm1361714igx.21.2015.07.02.08.47.29 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Jul 2015 08:47:32 -0700 (PDT) Message-ID: <55955D10.20805@andyet.net> Date: Thu, 02 Jul 2015 09:47:28 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Paul Wouters , dane@ietf.org References: <5594FE19.1020005@strotmann.de> <20150702140531.GC21534@mournblade.imrryr.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dane] Deferral of SMIME draft 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 Jul 2015 15:47:35 -0000 On 7/2/15 8:34 AM, Paul Wouters wrote: > On Thu, 2 Jul 2015, Viktor Dukhovni wrote: > >> So for me, the main obstacle is still the owner-label, which is >> the same for both OPENPGP and SMIMEA. > > No one has given me feedback (positive or negative) on the "lowercase if > ascii, normalise otherwise", then lookup base32/split or using hash, > that was advised to me by some of the EAI people. What exactly do we mean by "normalise" here? I don't see anything about normalization (in the Unicode sense) in draft-ietf-dane-openpgpkey. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Thu Jul 2 08:48:08 2015 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 F1E2D1ACD0C for ; Thu, 2 Jul 2015 08:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_57=0.6, 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 Y32q0VSpH2cS for ; Thu, 2 Jul 2015 08:48:07 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17E241ACCF0 for ; Thu, 2 Jul 2015 08:48:07 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 2792A284D2B; Thu, 2 Jul 2015 15:48:00 +0000 (UTC) Date: Thu, 2 Jul 2015 15:48:00 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150702154759.GG21534@mournblade.imrryr.org> References: <8DE8B456-8050-491E-AAB1-7EC278380B8F@gmail.com> <20150702150342.GE21534@mournblade.imrryr.org> <5B3828FB-0D7D-43D9-A7E0-29814A7B4133@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5B3828FB-0D7D-43D9-A7E0-29814A7B4133@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] DANE and IPsec 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 Jul 2015 15:48:08 -0000 On Thu, Jul 02, 2015 at 06:40:45PM +0300, Yoav Nir wrote: > > What prevents IP address hijacking (mallory.example publishes > > alice.example's IP address and now mallory's IPSEC keys are used > > to encrypt traffic to alice)? > > Not sure I follow. Mallory publishes > - mallory.example.com IN A 192.0.2.5 > - mallory.example.com IN TLSA .... > > But there's also > - alice.example.com IN A 192.0.2.5 > - alice.example.com IN TLSA .... > > So Mallory can push people looking for his IPsec entity to go to Alice's > IPsec entity. No, Mallory might be able to hijack the traffic keys to 192.0.2.5 (Alice's IP address), and then MiTM the traffic in question (BGP attack or equivalent). If there's no risk of MiTM, just do anon-DH and you're done, no need for a PKI. -- Viktor. From nobody Thu Jul 2 09:34:43 2015 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 139E21AD370 for ; Thu, 2 Jul 2015 09:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.978 X-Spam-Level: X-Spam-Status: No, score=-3.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001, 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 RcEzMaltqYXP for ; Thu, 2 Jul 2015 09:34:38 -0700 (PDT) Received: from mail-oi0-f41.google.com (mail-oi0-f41.google.com [209.85.218.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 582CB1AD359 for ; Thu, 2 Jul 2015 09:34:22 -0700 (PDT) Received: by oigx81 with SMTP id x81so59895851oig.1 for ; Thu, 02 Jul 2015 09:34:21 -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:from:date :message-id:subject:to:cc:content-type; bh=3BXBdnCYwX1NLI1MtkLdApGxJ31zT0HsCOByC6cB3zw=; b=kCfv5bc6NZPgeYGl9S2cUXSyBPudGnZGOFKs3FDIkShlPJRgXFIo1y2InuVlfR5bGF 5rCvXSmOPvGkqXNTP5VzSi37h+by8DotHWcLZvUMVhEbrVkzbAskxFp+RtbqXd8UUvWV UA5J0jJWFcVoS3zh9HYdM0ptJFIDRaxd+Iu21zMzeT6M7kuPhLuiX2PgyE0fpNskqYul cgOZNFYbBqgBUAR78ACAnVPX6v4+OARQcgXMhmX35GmX/hhyWTjWzMiaP+8C34wq+uUH y9qYkRVV3yzytZxTN1J003is3DU9cTjSSt3i9cN8WgU6LE/SgRihvym/t8gup140xm6e 81VQ== X-Gm-Message-State: ALoCoQlJ+eQSscnDfFWfDpgW22BpYw0mYn6e7bgKLnGKkTrNevOGCoGVPtJjjnhNGu4mBG1tWYlj X-Received: by 10.60.145.228 with SMTP id sx4mr30503203oeb.79.1435854861658; Thu, 02 Jul 2015 09:34:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.133.17 with HTTP; Thu, 2 Jul 2015 09:33:42 -0700 (PDT) In-Reply-To: <55955D10.20805@andyet.net> References: <5594FE19.1020005@strotmann.de> <20150702140531.GC21534@mournblade.imrryr.org> <55955D10.20805@andyet.net> From: Wil Tan Date: Fri, 3 Jul 2015 02:33:42 +1000 Message-ID: To: "Peter Saint-Andre - &yet" Content-Type: multipart/alternative; boundary=047d7b5d30dafa86f10519e70216 Archived-At: Cc: Paul Wouters , dane WG list Subject: Re: [dane] Deferral of SMIME draft 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 Jul 2015 16:34:40 -0000 --047d7b5d30dafa86f10519e70216 Content-Type: text/plain; charset=UTF-8 On Fri, Jul 3, 2015 at 1:47 AM, Peter Saint-Andre - &yet wrote: > On 7/2/15 8:34 AM, Paul Wouters wrote: > >> On Thu, 2 Jul 2015, Viktor Dukhovni wrote: >> >> So for me, the main obstacle is still the owner-label, which is >>> the same for both OPENPGP and SMIMEA. >>> >> >> No one has given me feedback (positive or negative) on the "lowercase if >> ascii, normalise otherwise", then lookup base32/split or using hash, >> that was advised to me by some of the EAI people. >> > > What exactly do we mean by "normalise" here? I don't see anything about > normalization (in the Unicode sense) in draft-ietf-dane-openpgpkey. It's not in the draft; we were discussing this in Buenos Aires with Paul. I believe it was suggested that we use Unicode default case folding (Section 3.13 - http://www.unicode.org/versions/Unicode7.0.0/ch03.pdf#G33992 ). I'm not convinced that we should touch non-ASCII mailbox username. As for ASCII - the only well-known case for locale-sensitive mapping is the Turkish dotted/dotless i. If we lowercased capital I according to Turkish locale, we'd get U+0131 (small letter dotless i) which is not ASCII; see above. So my preference is to "lowercase if ascii, otherwise verbatim". .wil --047d7b5d30dafa86f10519e70216 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Fri, Jul 3, 2015 at 1:47 AM, Peter Saint-Andre - &yet <peter@andyet.= net> wrote:
On 7/2/15 8:= 34 AM, Paul Wouters wrote:
On Thu, 2 Jul 2015, Viktor Dukhovni wrote:

So for me, the main obstacle is still the owner-label, which is
the same for both OPENPGP and SMIMEA.

No one has given me feedback (positive or negative) on the "lowercase = if
ascii, normalise otherwise", then lookup base32/split or using hash, that was advised to me by some of the EAI people.

 What exactly do we mean by "normalise" here? I don't see anyt= hing about normalization (in the Unicode sense) in draft-ietf-dane-openpgpk= ey.

It's not in the draft; we were disc= ussing this in Buenos Aires with Paul.

I believe i= t was suggested that we use Unicode default case folding (Section 3.13 -=C2= =A0http://www.unicode.org/versions/Unicode7.0.0/ch03.pdf#G33992).

I'm not convinced that we should touch non-ASCII mail= box username.

As for ASCII - the only well-known c= ase for locale-sensitive mapping is the Turkish dotted/dotless i. If we low= ercased capital I according to Turkish locale, we'd get U+0131 (small l= etter dotless i) which is not ASCII; see above. So my preference is to &quo= t;lowercase if ascii, otherwise verbatim".

.w= il
--047d7b5d30dafa86f10519e70216-- From nobody Thu Jul 2 09:40:41 2015 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 6C0D51A00A1 for ; Thu, 2 Jul 2015 09:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.601 X-Spam-Level: X-Spam-Status: No, score=-4.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, 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 xV7_IPIGUQBb for ; Thu, 2 Jul 2015 09:40:38 -0700 (PDT) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAE4F1A0093 for ; Thu, 2 Jul 2015 09:40:37 -0700 (PDT) Received: by iecvh10 with SMTP id vh10so60563922iec.3 for ; Thu, 02 Jul 2015 09:40:37 -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=ChKt0/3spjZR0+Oog8Yfm5ohPRSL/r4T0MqjZ0dfk98=; b=RNQpH/9SoJyveQFd/H2Qh3Nplha373av9BMBBXs/o4tHTp+ROlVOiLFvfs3v04/LNj sqLHlpc9mnB9j08DDrZds0mZQZiRoqleibbUT11yq7LQY2VjAZHgioIOr3hk2HaOEU+U d3Pk87IgHV2pubbpHN1d0YNHeecxsKHd/bq7U1Q+oYEPZikqiMpIp7/5TZzK28tKyL3E P3VlKitA+BafqWHfazuIr6n2j5OwT3igu/xcovNGxrwMcaukQ5MdGYESoXui3f5vaer2 gsk3PZiE3SJE4oy7qL36m+HQR9LHY0SgqJKofn3C/4/RtzXChajUNIQ3ztcA+V+dH3vX cMyA== X-Gm-Message-State: ALoCoQlp8ZjWlqoiIukSL3UtBcaLkuMeqll7KYRLa0PZFpqhuX4HVX0jjbwNoaPCNQJGGvmqH01X X-Received: by 10.107.4.6 with SMTP id 6mr50715677ioe.49.1435855237191; Thu, 02 Jul 2015 09:40:37 -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 196sm4213276ioe.23.2015.07.02.09.40.35 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Jul 2015 09:40:36 -0700 (PDT) Message-ID: <55956982.9020705@andyet.net> Date: Thu, 02 Jul 2015 10:40:34 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Wil Tan References: <5594FE19.1020005@strotmann.de> <20150702140531.GC21534@mournblade.imrryr.org> <55955D10.20805@andyet.net> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Paul Wouters , dane WG list Subject: Re: [dane] Deferral of SMIME draft 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 Jul 2015 16:40:39 -0000 On 7/2/15 10:33 AM, Wil Tan wrote: > > On Fri, Jul 3, 2015 at 1:47 AM, Peter Saint-Andre - &yet > > wrote: > > On 7/2/15 8:34 AM, Paul Wouters wrote: > > On Thu, 2 Jul 2015, Viktor Dukhovni wrote: > > So for me, the main obstacle is still the owner-label, which is > the same for both OPENPGP and SMIMEA. > > > No one has given me feedback (positive or negative) on the > "lowercase if > ascii, normalise otherwise", then lookup base32/split or using hash, > that was advised to me by some of the EAI people. > > > What exactly do we mean by "normalise" here? I don't see anything > about normalization (in the Unicode sense) in > draft-ietf-dane-openpgpkey. > > > It's not in the draft; we were discussing this in Buenos Aires with Paul. > > I believe it was suggested that we use Unicode default case folding > (Section 3.13 - > http://www.unicode.org/versions/Unicode7.0.0/ch03.pdf#G33992). > > I'm not convinced that we should touch non-ASCII mailbox username. I tend to agree. > As for ASCII - the only well-known case for locale-sensitive mapping is > the Turkish dotted/dotless i. In my experience it's usually not safe to say "the only case" when it comes to internationalization. ;-) > If we lowercased capital I according to > Turkish locale, we'd get U+0131 (small letter dotless i) which is not > ASCII; see above. So my preference is to "lowercase if ascii, otherwise > verbatim". Well, locale-specific case mapping is not part of Unicode Default Case Folding, so applying the latter should be fine. See also https://datatracker.ietf.org/doc/draft-ietf-precis-mappings/ on some of these topics. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Thu Jul 2 10:04:45 2015 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 1A66E1A01CB for ; Thu, 2 Jul 2015 10:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_57=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 Sp5p5Jkzv9HO for ; Thu, 2 Jul 2015 10:04:42 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C7FF1A01BA for ; Thu, 2 Jul 2015 10:04:42 -0700 (PDT) Received: by wicgi11 with SMTP id gi11so79662757wic.0 for ; Thu, 02 Jul 2015 10:04:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=MYsd8udpUkQr6ch9rQ170t7Hh5lSGqCh1eoP9uXvLEc=; b=Zp5hF6d+5LVpvtNZhgcBsLt1MxgwbFwO6TIqvdh0b2LorKVuzYiQBw4/2zLGiB99R7 qh2mNpEVoWQf7gfKjPCjHUT86gXTGl8pLFL1lBFIDgVpQIzCt3epadkLc/TZ0je+prDx 0zWhAa0iNy5dltiiEV/xkVUpsjuTkksHimIQOxmQZBVqnMJb6J3HTcyAIM9nL2VWzYa5 W+ZfJT0fZ6rMgpHswN98ulcFlUDqxAsxuuX2hWyU6paPp78HsgovypoWGK1wtdznk+Il isDAO0yUAAByrgumSEX9N/ewrJzvavVmgcPoQ877AYWAiHTMRrvTcZrK4ysShbgmQzjY YCnw== X-Received: by 10.194.171.129 with SMTP id au1mr63581013wjc.115.1435856681195; Thu, 02 Jul 2015 10:04:41 -0700 (PDT) Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id c2sm9040244wjf.18.2015.07.02.10.04.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 Jul 2015 10:04:40 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Yoav Nir In-Reply-To: <20150702154759.GG21534@mournblade.imrryr.org> Date: Thu, 2 Jul 2015 20:04:37 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <7FAA8F9B-F0D0-43F8-B826-8A0B738A7533@gmail.com> References: <8DE8B456-8050-491E-AAB1-7EC278380B8F@gmail.com> <20150702150342.GE21534@mournblade.imrryr.org> <5B3828FB-0D7D-43D9-A7E0-29814A7B4133@gmail.com> <20150702154759.GG21534@mournblade.imrryr.org> To: dane@ietf.org X-Mailer: Apple Mail (2.2102) Archived-At: Subject: Re: [dane] DANE and IPsec 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 Jul 2015 17:04:44 -0000 > On Jul 2, 2015, at 6:48 PM, Viktor Dukhovni = wrote: >=20 > On Thu, Jul 02, 2015 at 06:40:45PM +0300, Yoav Nir wrote: >=20 >>> What prevents IP address hijacking (mallory.example publishes >>> alice.example's IP address and now mallory's IPSEC keys are used >>> to encrypt traffic to alice)? >>=20 >> Not sure I follow. Mallory publishes >> - mallory.example.com IN A 192.0.2.5 >> - mallory.example.com IN TLSA .... >>=20 >> But there's also=20 >> - alice.example.com IN A 192.0.2.5 >> - alice.example.com IN TLSA .... >>=20 >> So Mallory can push people looking for his IPsec entity to go to = Alice's >> IPsec entity. >=20 > No, Mallory might be able to hijack the traffic keys to 192.0.2.5 > (Alice's IP address), and then MiTM the traffic in question (BGP > attack or equivalent). If there's no risk of MiTM, just do anon-DH > and you're done, no need for a PKI. >=20 It=E2=80=99s the Internet. MitM is always a risk. But I=E2=80=99m still = not getting it. IPsec traffic keys are negotiated with the IKE protocol, = which provides both authentication and key exchange with D-H. How could = mallory hijack traffic keys? If Mallory doesn=E2=80=99t have the = private key that matches the public key in Alice=E2=80=99s TLSA record = ([1]) then IKE will fail. Yoav [1] I=E2=80=99m assuming here use of the same TLSA record as in TLS, but = it could be another type of record From nobody Thu Jul 2 10:08:36 2015 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 7DBDD1A020D for ; Thu, 2 Jul 2015 10:08:34 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 v8iA_FiBwa6W for ; Thu, 2 Jul 2015 10:08:33 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03E8F1A020A for ; Thu, 2 Jul 2015 10:08:33 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 72E59284D2B; Thu, 2 Jul 2015 17:08:31 +0000 (UTC) Date: Thu, 2 Jul 2015 17:08:31 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150702170831.GI21534@mournblade.imrryr.org> References: <8DE8B456-8050-491E-AAB1-7EC278380B8F@gmail.com> <20150702150342.GE21534@mournblade.imrryr.org> <5B3828FB-0D7D-43D9-A7E0-29814A7B4133@gmail.com> <20150702154759.GG21534@mournblade.imrryr.org> <7FAA8F9B-F0D0-43F8-B826-8A0B738A7533@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7FAA8F9B-F0D0-43F8-B826-8A0B738A7533@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] DANE and IPsec 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 Jul 2015 17:08:34 -0000 On Thu, Jul 02, 2015 at 08:04:37PM +0300, Yoav Nir wrote: > >> Not sure I follow. Mallory publishes > >> - mallory.example.com IN A 192.0.2.5 > >> - mallory.example.com IN TLSA .... Mallory publishes her own TLSA record for keys she possesses. > >> But there's also > >> - alice.example.com IN A 192.0.2.5 > >> - alice.example.com IN TLSA .... Alice's keys are ignored once Mallory's PAD entry for 192.0.2.5 supercedes or displaces Alices. > >> So Mallory can push people looking for his IPsec entity to go to Alice's > >> IPsec entity. No, Mallory can cause people trying to connect to Alice's IP address to use Mallory's keys. > > No, Mallory might be able to hijack the traffic keys to 192.0.2.5 > > (Alice's IP address), and then MiTM the traffic in question (BGP > > attack or equivalent). If there's no risk of MiTM, just do anon-DH > > and you're done, no need for a PKI. > > > > It's the Internet. MitM is always a risk. But I?m still not getting it. > IPsec traffic keys are negotiated with the IKE protocol, which provides > both authentication and key exchange with D-H. How could Mallory hijack > traffic keys? The IKE protocol negotiation takes place with Mallory, standing in for Alice. > If Mallory doesn't have the private key that matches the > public key in Alice's TLSA record ([1]) then IKE will fail. Alice's key is not used. -- Viktor. From nobody Thu Jul 2 11:02:11 2015 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 F15F71A1B88 for ; Thu, 2 Jul 2015 11:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 T7TFsLQgnL1D for ; Thu, 2 Jul 2015 11:02:08 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 543241A1B87 for ; Thu, 2 Jul 2015 11:02:08 -0700 (PDT) Received: by wiwl6 with SMTP id l6so204726370wiw.0 for ; Thu, 02 Jul 2015 11:02:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=Rg8Vu+qX7J0gS95/JIY7+kvx60KPFvRDKrBiRCT+7jg=; b=FVQUqQZ559qJbSo/v9Rnx6unfOkIRE4tkwLyJxFzrBIgUZ/vklqQDtyX96R1U3fkhQ V+0SS/fuxYQQ0EsZ90fHPf87A3MlMFxINo5kvvMzeTAqTjAGvfIdTQO7AX2TRAC1Zm7M IILJ9arcoUEkT/VpWDQb561nja0llA5uHnFxoqiBtKeodyYA4xNRopgddel9mIzhWe34 093Xe+vHlbF0btPxdz7pCP0haS1Ch8wuW4wyqkZ0RTQ/DwyPP/R4T8rd3IueJx+zQ/rc YWWy67OxcPP6OJXADFHalGjZ8EVq7qdPEyONME1PNpt8v7Xy10FxH7QPfzJEvi/c1rDH tFnQ== X-Received: by 10.180.39.147 with SMTP id p19mr55008199wik.15.1435860127164; Thu, 02 Jul 2015 11:02:07 -0700 (PDT) Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id ny7sm28368012wic.11.2015.07.02.11.02.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 Jul 2015 11:02:06 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Yoav Nir In-Reply-To: <20150702170831.GI21534@mournblade.imrryr.org> Date: Thu, 2 Jul 2015 21:02:03 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <99B2B3F1-78C1-46ED-9D3F-D441EAFACCF2@gmail.com> References: <8DE8B456-8050-491E-AAB1-7EC278380B8F@gmail.com> <20150702150342.GE21534@mournblade.imrryr.org> <5B3828FB-0D7D-43D9-A7E0-29814A7B4133@gmail.com> <20150702154759.GG21534@mournblade.imrryr.org> <7FAA8F9B-F0D0-43F8-B826-8A0B738A7533@gmail.com> <20150702170831.GI21534@mournblade.imrryr.org> To: dane@ietf.org X-Mailer: Apple Mail (2.2102) Archived-At: Subject: Re: [dane] DANE and IPsec 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 Jul 2015 18:02:10 -0000 > On Jul 2, 2015, at 8:08 PM, Viktor Dukhovni = wrote: >=20 > On Thu, Jul 02, 2015 at 08:04:37PM +0300, Yoav Nir wrote: >=20 >>>> Not sure I follow. Mallory publishes >>>> - mallory.example.com IN A 192.0.2.5 >>>> - mallory.example.com IN TLSA .... >=20 > Mallory publishes her own TLSA record for keys she possesses. >=20 >>>> But there's also=20 >>>> - alice.example.com IN A 192.0.2.5 >>>> - alice.example.com IN TLSA .... >=20 > Alice's keys are ignored once Mallory's PAD entry for 192.0.2.5 > supercedes or displaces Alices. Ah, I see the source of my confusion. =20 I never think of a PAD as a table indexed by IP address. The =E2=80=9Ckey=E2= =80=9D for the PAD is a peer, so in practice it might be indexed by an = internal name (such as the =E2=80=9Cconn=E2=80=9D labels in the = ipsec.conf file in all *swan implementation) or it might be indexed by = the content of the ID payload that we expect that peer to present in = IKE. There is no entry for 192.0.2.5. I=E2=80=99m suggesting that there = should be a static entry in the PAD for =E2=80=9Calice.example.com=E2=80=9D= . DNS is used to resolve this to an IP address and to a public key. = Unless mallory can affect =E2=80=9Calice.example.com=E2=80=9D entries, = the victim never gets to see his records, because she never looks for = them. Yoav From nobody Thu Jul 2 11:22:38 2015 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 262AB1A8792 for ; Thu, 2 Jul 2015 11:22:33 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 uCeW-PC62SU5 for ; Thu, 2 Jul 2015 11:22:27 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D03F1A87C2 for ; Thu, 2 Jul 2015 11:22:27 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 9E332284D2B; Thu, 2 Jul 2015 18:22:26 +0000 (UTC) Date: Thu, 2 Jul 2015 18:22:26 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150702182226.GN21534@mournblade.imrryr.org> References: <8DE8B456-8050-491E-AAB1-7EC278380B8F@gmail.com> <20150702150342.GE21534@mournblade.imrryr.org> <5B3828FB-0D7D-43D9-A7E0-29814A7B4133@gmail.com> <20150702154759.GG21534@mournblade.imrryr.org> <7FAA8F9B-F0D0-43F8-B826-8A0B738A7533@gmail.com> <20150702170831.GI21534@mournblade.imrryr.org> <99B2B3F1-78C1-46ED-9D3F-D441EAFACCF2@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <99B2B3F1-78C1-46ED-9D3F-D441EAFACCF2@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] DANE and IPsec 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 Jul 2015 18:22:33 -0000 On Thu, Jul 02, 2015 at 09:02:03PM +0300, Yoav Nir wrote: > > Alice's keys are ignored once Mallory's PAD entry for 192.0.2.5 > > supercedes or displaces Alices. > > Ah, I see the source of my confusion. > > I never think of a PAD as a table indexed by IP address. The "key" for > the PAD is a peer, so in practice it might be indexed by an internal name > (such as the "conn" labels in the ipsec.conf file in all *swan > implementation) or it might be indexed by the content of the ID payload > that we expect that peer to present in IKE. > > There is no entry for 192.0.2.5. At the end of the day though, IPSEC needs to apply policy to application traffic presented to the kernel (almost universally) via the socket API. The socket API gives the kernel a transport endpoint UDP/192.0.2.5/53, how is the kernel to decide whether to use Mallory's keys for that same address or Alice's. I think you mentioned that your design locates both the IP address and the keys from DNS, so if the peers in the PAD database turn rogue, they might subvert other peers, right? > I'm suggesting that there should be a static entry in the PAD for > "alice.example.com". DNS is used to resolve this to an IP address > and to a public key. Unless mallory can affect "alice.example.com" > entries, the victim never gets to see his records, because she never > looks for them. mallory.example is another domain in the PAD. Either domain can return IP addresses that properly belong to someone else. -- Viktor. From nobody Thu Jul 2 12:09:54 2015 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 E5F551A896D for ; Thu, 2 Jul 2015 12:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 BNVMXS784G6j for ; Thu, 2 Jul 2015 12:09:51 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D9E31A897A for ; Thu, 2 Jul 2015 12:09:51 -0700 (PDT) Received: by wiga1 with SMTP id a1so160782022wig.0 for ; Thu, 02 Jul 2015 12:09:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=431GLndbCBwLdXoAP310k7QelpNgjM9ncUa3P/HOF6c=; b=k4xRNjR6TlrpQ1q2r/Cn3tk9l5KM0f1Zn8agy5ahvmN3bCVBxQwfevfttBnZmv33Z3 0bfJjWxyYUa5AlSkJI5ozvzSJ+O2cAr7g2RwCCP7aLq4i0KEQgCUQjKztlrL3pS7eP96 8mLmO6iKuyWWL3yFDNfRk0w4mTsdi37OcdhNrCUnKR8Y4W3fKNDe9zjU+pqi4PIRbQxe drb70IMRlM3YUupbrAtkDmvDoHHtMFyZ0LP3rxBOEa5IE0pPpWfpt+DS7aPeoCoLbWMZ umHtErTL6EvaFXWm7Q2E9+NgSSc6rpYn/TUwfOUbipFYwizBRjQ1PD9znDknZ1zP5FPX GxPQ== X-Received: by 10.180.86.163 with SMTP id q3mr19685606wiz.75.1435864189920; Thu, 02 Jul 2015 12:09:49 -0700 (PDT) Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id q3sm9448650wjr.38.2015.07.02.12.09.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 Jul 2015 12:09:49 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Yoav Nir In-Reply-To: <20150702182226.GN21534@mournblade.imrryr.org> Date: Thu, 2 Jul 2015 22:09:46 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <9AE12A4B-CE74-4EDD-B8AC-CFD71175CBA1@gmail.com> References: <8DE8B456-8050-491E-AAB1-7EC278380B8F@gmail.com> <20150702150342.GE21534@mournblade.imrryr.org> <5B3828FB-0D7D-43D9-A7E0-29814A7B4133@gmail.com> <20150702154759.GG21534@mournblade.imrryr.org> <7FAA8F9B-F0D0-43F8-B826-8A0B738A7533@gmail.com> <20150702170831.GI21534@mournblade.imrryr.org> <99B2B3F1-78C1-46ED-9D3F-D441EAFACCF2@gmail.com> <20150702182226.GN21534@mournblade.imrryr.org> To: dane@ietf.org X-Mailer: Apple Mail (2.2102) Archived-At: Subject: Re: [dane] DANE and IPsec 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 Jul 2015 19:09:53 -0000 > On Jul 2, 2015, at 9:22 PM, Viktor Dukhovni = wrote: >=20 > On Thu, Jul 02, 2015 at 09:02:03PM +0300, Yoav Nir wrote: >=20 >>> Alice's keys are ignored once Mallory's PAD entry for 192.0.2.5 >>> supercedes or displaces Alices. >>=20 >> Ah, I see the source of my confusion. =20 >>=20 >> I never think of a PAD as a table indexed by IP address. The "key" = for >> the PAD is a peer, so in practice it might be indexed by an internal = name >> (such as the "conn" labels in the ipsec.conf file in all *swan >> implementation) or it might be indexed by the content of the ID = payload >> that we expect that peer to present in IKE. >>=20 >> There is no entry for 192.0.2.5. >=20 > At the end of the day though, IPSEC needs to apply policy to > application traffic presented to the kernel (almost universally) > via the socket API. The socket API gives the kernel a transport > endpoint UDP/192.0.2.5/53, how is the kernel to decide whether to > use Mallory's keys for that same address or Alice=E2=80=99s. Host to host IPsec is very rare. VPNs are far more common and the = packets don=E2=80=99t get there by a socket API. But regardless, let=E2=80=99s assume that the local address is = 198.51.100.2. So the quintuple for the connection would be (UDP, = 198.51.100.2:704, 192.0.2.5:53) The first thing a kernel does is look up with quintuple in the security = policy database (SPD). Much like the PAD, the SPD is static. So if this = quintuple is matched in the SPD, we get the tunnel endpoints (which may = or may not be the same as the addresses on the packets) from the SPD. In = this case we get that the remote endpoint is =E2=80=9Calice.example.com=E2= =80=9D. Mallory=E2=80=99s entries never make it into the (static) SPD. > I think you mentioned that your design locates both the IP address > and the keys from DNS, so if the peers in the PAD database turn > rogue, they might subvert other peers, right? I=E2=80=99ve only configured Alice. If she turns rogue, she can send me = to Mallory=E2=80=99s gateway and tell me to expect Mallory=E2=80=99s = keys. What good it would do her, I don=E2=80=99t know. >=20 >> I'm suggesting that there should be a static entry in the PAD for >> "alice.example.com". DNS is used to resolve this to an IP address >> and to a public key. Unless mallory can affect "alice.example.com" >> entries, the victim never gets to see his records, because she never >> looks for them. >=20 > mallory.example is another domain in the PAD. Either domain can > return IP addresses that properly belong to someone else. Sure, but that only makes a difference to people looking for mallory. = The protected domain of mallory=E2=80=99s IPsec host/gateway is = pre-configured. Unless we use route-based VPN, and then we=E2=80=99re as = secure as the routing protocol. Yoav From nobody Thu Jul 2 12:40:04 2015 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 5C0C71A8A47 for ; Thu, 2 Jul 2015 12:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_51=0.6, 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 wqZk7v5KZx3f for ; Thu, 2 Jul 2015 12:40:01 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C0EC1A8A46 for ; Thu, 2 Jul 2015 12:40:01 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 4CEFC284D2B; Thu, 2 Jul 2015 19:40:00 +0000 (UTC) Date: Thu, 2 Jul 2015 19:40:00 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150702194000.GR21534@mournblade.imrryr.org> References: <8DE8B456-8050-491E-AAB1-7EC278380B8F@gmail.com> <20150702150342.GE21534@mournblade.imrryr.org> <5B3828FB-0D7D-43D9-A7E0-29814A7B4133@gmail.com> <20150702154759.GG21534@mournblade.imrryr.org> <7FAA8F9B-F0D0-43F8-B826-8A0B738A7533@gmail.com> <20150702170831.GI21534@mournblade.imrryr.org> <99B2B3F1-78C1-46ED-9D3F-D441EAFACCF2@gmail.com> <20150702182226.GN21534@mournblade.imrryr.org> <9AE12A4B-CE74-4EDD-B8AC-CFD71175CBA1@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9AE12A4B-CE74-4EDD-B8AC-CFD71175CBA1@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] DANE and IPsec 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 Jul 2015 19:40:03 -0000 On Thu, Jul 02, 2015 at 10:09:46PM +0300, Yoav Nir wrote: > > At the end of the day though, IPSEC needs to apply policy to > > application traffic presented to the kernel (almost universally) > > via the socket API. The socket API gives the kernel a transport > > endpoint UDP/192.0.2.5/53, how is the kernel to decide whether to > > use Mallory's keys for that same address or Alice?s. > > Host to host IPsec is very rare. VPNs are far more common and the packets > don't get there by a socket API. The attack I had in mind is not an attack on VPNs. It is an attack on IPSEC in transport mode. If you want to use DANE as a PKI for VPN tunnel key management (where both the gateway IP and the key material are provided via DNSSEC), that should work. The hard part is the transport-mode use-case. So we were talking past each other. You were thinking tunnels, and I was thinking transport. DANE for VPN tunnels should be simple enough as you suggest, and can simplify key management. -- Viktor. From nobody Thu Jul 2 13:29:58 2015 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 BD29D1A911A for ; Thu, 2 Jul 2015 13:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, J_CHICKENPOX_51=0.6, NORMAL_HTTP_TO_IP=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 NGq-AcbA7Qlw for ; Thu, 2 Jul 2015 13:29:50 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 186BF1A916D for ; Thu, 2 Jul 2015 13:29:50 -0700 (PDT) Received: by wiar9 with SMTP id r9so112274917wia.1 for ; Thu, 02 Jul 2015 13:29:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=d3O3PKEVP5iBNWyKRgZlpcLuXaV/jrXGXIGKuWxTVYc=; b=VuZlH/EL4A6TfgEqKnK2YpG1Qh1wvdmCFRWkQ9NY9d0PCDJsv7lZ/NVdJrlnsqkvWf 2YxzSA9SKcVf4zPyGj06YG3IeR42tyg8g0rv35C1TEyOYXgy7PXsoUTUCZF8rrrzA4sx jM2pWIAf98eTDIEdGS3MNEXYIEXwWnoplJHDPNmfvU8fMqSME6p98Sb1Gb7OBPpCxKup BFdCD9fJ6CSJt9YTIi/z3uVOwGKESymd28Qxw04PwOeKrVlO+R0d736BYuP2BmgCTwjz Do5BpNLsXEp0ChYF6PWlytkFTdTKtaKspm6srtoxy/EDS/GawX59uFHYIv5JnHQ3ULPe bBww== X-Received: by 10.180.98.134 with SMTP id ei6mr54893789wib.49.1435868988893; Thu, 02 Jul 2015 13:29:48 -0700 (PDT) Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id a19sm28867084wiv.2.2015.07.02.13.29.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 Jul 2015 13:29:48 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Yoav Nir In-Reply-To: <20150702194000.GR21534@mournblade.imrryr.org> Date: Thu, 2 Jul 2015 23:29:45 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8DE8B456-8050-491E-AAB1-7EC278380B8F@gmail.com> <20150702150342.GE21534@mournblade.imrryr.org> <5B3828FB-0D7D-43D9-A7E0-29814A7B4133@gmail.com> <20150702154759.GG21534@mournblade.imrryr.org> <7FAA8F9B-F0D0-43F8-B826-8A0B738A7533@gmail.com> <20150702170831.GI21534@mournblade.imrryr.org> <99B2B3F1-78C1-46ED-9D3F-D441EAFACCF2@gmail.com> <20150702182226.GN21534@mournblade.imrryr.org> <9AE12A4B-CE74-4EDD-B8AC-CFD71175CBA1@gmail.com> <20150702194000.GR21534@mournblade.imrryr.org> To: dane@ietf.org X-Mailer: Apple Mail (2.2102) Archived-At: Subject: Re: [dane] DANE and IPsec 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 Jul 2015 20:29:51 -0000 > On Jul 2, 2015, at 10:40 PM, Viktor Dukhovni = wrote: >=20 > On Thu, Jul 02, 2015 at 10:09:46PM +0300, Yoav Nir wrote: >=20 >>> At the end of the day though, IPSEC needs to apply policy to >>> application traffic presented to the kernel (almost universally) >>> via the socket API. The socket API gives the kernel a transport >>> endpoint UDP/192.0.2.5/53, how is the kernel to decide whether to >>> use Mallory's keys for that same address or Alice?s. >>=20 >> Host to host IPsec is very rare. VPNs are far more common and the = packets >> don't get there by a socket API. >=20 > The attack I had in mind is not an attack on VPNs. It is an attack > on IPSEC in transport mode. If you want to use DANE as a PKI for > VPN tunnel key management (where both the gateway IP and the key > material are provided via DNSSEC), that should work. I agree, and I think that is something DANE can do. > The hard part is the transport-mode use-case. If the SPD entries are specific and pre-configured, the same reasoning = as for VPNs applies. Things change if you want the SPD and PAD to be = dynamic, such as reading them from DNS. There is RFC 4025 with the IPSECKEY record. So when the application = performs a DNS lookup for www.example.com, the OS could also ask for an = IPSECKEY record and get both public key and a gateway address. If we set = the gateway address to be equal to the server address, this is the = transport-mode use-case. Again, this all begins with the DNS name, so = mallory cannot do anything.=20 There are issues, though. if the application does not perform a DNS = lookup (such as if the user entered http://93.184.216.34 instead of = www.example.com) then the IPSECKEY entry is not read. RFC 4025 suggests = using reverse DNS, but we know that reverse DNS doesn=E2=80=99t work = too well. Yoav= From nobody Thu Jul 2 14:28:42 2015 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 19A181A6F07 for ; Thu, 2 Jul 2015 14:28: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, RCVD_IN_DNSWL_NONE=-0.0001] 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 J67u68JNPib8 for ; Thu, 2 Jul 2015 14:28:39 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3E511A1BCD for ; Thu, 2 Jul 2015 14:28:39 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 62617284D2B; Thu, 2 Jul 2015 21:28:38 +0000 (UTC) Date: Thu, 2 Jul 2015 21:28:38 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150702212838.GT21534@mournblade.imrryr.org> References: <20150702150342.GE21534@mournblade.imrryr.org> <5B3828FB-0D7D-43D9-A7E0-29814A7B4133@gmail.com> <20150702154759.GG21534@mournblade.imrryr.org> <7FAA8F9B-F0D0-43F8-B826-8A0B738A7533@gmail.com> <20150702170831.GI21534@mournblade.imrryr.org> <99B2B3F1-78C1-46ED-9D3F-D441EAFACCF2@gmail.com> <20150702182226.GN21534@mournblade.imrryr.org> <9AE12A4B-CE74-4EDD-B8AC-CFD71175CBA1@gmail.com> <20150702194000.GR21534@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: Subject: Re: [dane] DANE and IPsec 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 Jul 2015 21:28:41 -0000 On Thu, Jul 02, 2015 at 11:29:45PM +0300, Yoav Nir wrote: > > The hard part is the transport-mode use-case. > > If the SPD entries are specific and pre-configured, the same reasoning as > for VPNs applies. Things change if you want the SPD and PAD to be dynamic, > such as reading them from DNS. Dynamic. > There is RFC 4025 with the IPSECKEY record. So when the application performs > a DNS lookup for www.example.com, the OS could also ask for an IPSECKEY > record and get both public key and a gateway address. If we set the gateway > address to be equal to the server address, this is the transport-mode > use-case. Again, this all begins with the DNS name, so mallory cannot do > anything. Mallory can often trigger DNS lookups for her own domain, which can return IP addresses that collide with Alice's domain. How is that handled? -- Viktor. From nobody Thu Jul 2 15:02:03 2015 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 46EBA1A907C for ; Thu, 2 Jul 2015 15:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 n9kqAo1MYiK1 for ; Thu, 2 Jul 2015 15:02:01 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0D421A8F3C for ; Thu, 2 Jul 2015 15:01:47 -0700 (PDT) Received: by wiar9 with SMTP id r9so113979864wia.1 for ; Thu, 02 Jul 2015 15:01:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=zG5bAVE4oPUms6e7e3xyUOWW25IPe2ag9kP0bcunz8k=; b=WMCtLFJJaRUnf790K/3MUo35vdXgt3Nhn+NwnFkgTmhipJy85RsoZhjMB5EvRRPT/e EHYiPnZREcM0EYT2HxsVbG8EXrDLsrnN0YnnRVZ0U+J+S93+47r4D/WXLG1e7FJUOY5N ynYdMSfYNXKsHC1mCjGXlSJV8LzCyQ8vIc0ACSsIQR9/XfyL7VlRSUr1wBEaYdpF+Kja e83jv4MPw2NxOi9yN1pp5SsJNlyQV5jwVrXny65sMNIGnuU+gqlTCp5Go0EuK67gMKAT ymbeJY0VfwsRF1ycOHTNLUErrZxOAjsG7iqoiejgqsXQ+77SSINFRoJ/RW4UYo0rTz2m vGOQ== X-Received: by 10.180.84.202 with SMTP id b10mr20722642wiz.23.1435874506612; Thu, 02 Jul 2015 15:01:46 -0700 (PDT) Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id gw7sm29226684wib.15.2015.07.02.15.01.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 Jul 2015 15:01:45 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Yoav Nir In-Reply-To: <20150702212838.GT21534@mournblade.imrryr.org> Date: Fri, 3 Jul 2015 01:01:43 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150702150342.GE21534@mournblade.imrryr.org> <5B3828FB-0D7D-43D9-A7E0-29814A7B4133@gmail.com> <20150702154759.GG21534@mournblade.imrryr.org> <7FAA8F9B-F0D0-43F8-B826-8A0B738A7533@gmail.com> <20150702170831.GI21534@mournblade.imrryr.org> <99B2B3F1-78C1-46ED-9D3F-D441EAFACCF2@gmail.com> <20150702182226.GN21534@mournblade.imrryr.org> <9AE12A4B-CE74-4EDD-B8AC-CFD71175CBA1@gmail.com> <20150702194000.GR21534@mournblade.imrryr.org> <20150702212838.GT21534@mournblade.imrryr.org> To: dane@ietf.org X-Mailer: Apple Mail (2.2102) Archived-At: Subject: Re: [dane] DANE and IPsec 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 Jul 2015 22:02:02 -0000 > On Jul 3, 2015, at 12:28 AM, Viktor Dukhovni = wrote: >=20 > On Thu, Jul 02, 2015 at 11:29:45PM +0300, Yoav Nir wrote: >=20 >>> The hard part is the transport-mode use-case. >>=20 >> If the SPD entries are specific and pre-configured, the same = reasoning as >> for VPNs applies. Things change if you want the SPD and PAD to be = dynamic, >> such as reading them from DNS. >=20 > Dynamic. >=20 >> There is RFC 4025 with the IPSECKEY record. So when the application = performs >> a DNS lookup for www.example.com, the OS could also ask for an = IPSECKEY >> record and get both public key and a gateway address. If we set the = gateway >> address to be equal to the server address, this is the transport-mode >> use-case. Again, this all begins with the DNS name, so mallory cannot = do >> anything. >=20 > Mallory can often trigger DNS lookups for her own domain, which > can return IP addresses that collide with Alice's domain. How > is that handled? RFC 4025 and Wikipedia suggest mapping the IPSECKEY record to the = address through reverse DNS. I don=E2=80=99t know in what percentage of = the Internet that would work. Yoav= From nobody Thu Jul 2 15:47:49 2015 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 3FEEA1ACCDF for ; Thu, 2 Jul 2015 15:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6, 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 vUqqvhjFY5DR for ; Thu, 2 Jul 2015 15:47:47 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D78C1ACCE2 for ; Thu, 2 Jul 2015 15:47:45 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 7864D284D2B; Thu, 2 Jul 2015 22:47:44 +0000 (UTC) Date: Thu, 2 Jul 2015 22:47:44 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150702224744.GU21534@mournblade.imrryr.org> References: <20150702154759.GG21534@mournblade.imrryr.org> <7FAA8F9B-F0D0-43F8-B826-8A0B738A7533@gmail.com> <20150702170831.GI21534@mournblade.imrryr.org> <99B2B3F1-78C1-46ED-9D3F-D441EAFACCF2@gmail.com> <20150702182226.GN21534@mournblade.imrryr.org> <9AE12A4B-CE74-4EDD-B8AC-CFD71175CBA1@gmail.com> <20150702194000.GR21534@mournblade.imrryr.org> <20150702212838.GT21534@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: Subject: Re: [dane] DANE and IPsec 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 Jul 2015 22:47:48 -0000 On Fri, Jul 03, 2015 at 01:01:43AM +0300, Yoav Nir wrote: > > Mallory can often trigger DNS lookups for her own domain, which > > can return IP addresses that collide with Alice's domain. How > > is that handled? > > RFC 4025 and Wikipedia suggest mapping the IPSECKEY record to the address > through reverse DNS. I don?t know in what percentage of the Internet that > would work. Exceedingly little, it could make more sense at that point to just publish the keys under in-addr.arpa. -- Viktor. From nobody Fri Jul 3 07:07:36 2015 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 AE3F71A0041 for ; Fri, 3 Jul 2015 07:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=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 bce9Am-aVzZx for ; Fri, 3 Jul 2015 07:07:33 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48FD51A002F for ; Fri, 3 Jul 2015 07:07:33 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mNJ5b6x2Nz3mV; Fri, 3 Jul 2015 16:07:31 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=qt5Hf6Qb X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id JB1QPm01KCjF; Fri, 3 Jul 2015 16:07:30 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 3 Jul 2015 16:07:30 +0200 (CEST) Received: from [172.17.52.250] (unknown [181.31.255.10]) by bofh.nohats.ca (Postfix) with ESMTPSA id B81F780042; Fri, 3 Jul 2015 10:07:28 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1435932449; bh=OJVjvL1O380kLTb6oV8k/bUyuBXbOJjnJxxgwXck7dU=; h=References:In-Reply-To:Cc:From:Subject:Date:To; b=qt5Hf6Qbf5931DGDx7MRovbilNiWUCkjPcOtFCjETTW6Tts3wCif20uyw0sdnRI+h OmOpT8eYPCPKsgEpy63dGZE7uHd0en2ZO5gXfcQ0Yf4nMSV8M17CB8l8Od9S0gtPXA jkPEcCSxdUEwq6efB/RgpuV4poY53uJHJuWHDp+0= References: <8DE8B456-8050-491E-AAB1-7EC278380B8F@gmail.com> <20150702150342.GE21534@mournblade.imrryr.org> <5B3828FB-0D7D-43D9-A7E0-29814A7B4133@gmail.com> <20150702154759.GG21534@mournblade.imrryr.org> <7FAA8F9B-F0D0-43F8-B826-8A0B738A7533@gmail.com> <20150702170831.GI21534@mournblade.imrryr.org> <99B2B3F1-78C1-46ED-9D3F-D441EAFACCF2@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: <99B2B3F1-78C1-46ED-9D3F-D441EAFACCF2@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <1F93D3EF-975A-4F87-8565-BD2B77B46197@nohats.ca> X-Mailer: iPhone Mail (12B466) From: Paul Wouters Date: Fri, 3 Jul 2015 11:07:23 -0300 To: Yoav Nir Archived-At: Cc: "dane@ietf.org" Subject: Re: [dane] DANE and IPsec 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 Jul 2015 14:07:35 -0000 The problem is two different keys in two different domains in combination wi= th traffic hijacking. If I steal your 8.8.8.8 route, and trick you into looking up and doing IKE t= o my domain google.nohats.ca with A record 8.8.8.8, you start encrypting all= google DNS to me. That is, your applications do not know the encryption of 8= .8.8.8 is setup using ipseckey records not from google. There is a disconnec= t between system and application with IPsec that you do not have with TLS or= SSH Normally this is hard, but in coffee shop wifi it would be easy. Sent from my iPhone > On Jul 2, 2015, at 15:02, Yoav Nir wrote: >=20 >=20 >> On Jul 2, 2015, at 8:08 PM, Viktor Dukhovni wrot= e: >>=20 >> On Thu, Jul 02, 2015 at 08:04:37PM +0300, Yoav Nir wrote: >>=20 >>>>> Not sure I follow. Mallory publishes >>>>> - mallory.example.com IN A 192.0.2.5 >>>>> - mallory.example.com IN TLSA .... >>=20 >> Mallory publishes her own TLSA record for keys she possesses. >>=20 >>>>> But there's also=20 >>>>> - alice.example.com IN A 192.0.2.5 >>>>> - alice.example.com IN TLSA .... >>=20 >> Alice's keys are ignored once Mallory's PAD entry for 192.0.2.5 >> supercedes or displaces Alices. >=20 > Ah, I see the source of my confusion. =20 >=20 > I never think of a PAD as a table indexed by IP address. The =E2=80=9Ckey=E2= =80=9D for the PAD is a peer, so in practice it might be indexed by an inter= nal name (such as the =E2=80=9Cconn=E2=80=9D labels in the ipsec.conf file i= n all *swan implementation) or it might be indexed by the content of the ID p= ayload that we expect that peer to present in IKE. >=20 > There is no entry for 192.0.2.5. I=E2=80=99m suggesting that there should= be a static entry in the PAD for =E2=80=9Calice.example.com=E2=80=9D. DNS i= s used to resolve this to an IP address and to a public key. Unless mallory c= an affect =E2=80=9Calice.example.com=E2=80=9D entries, the victim never gets= to see his records, because she never looks for them. >=20 > Yoav >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From nobody Fri Jul 3 07:12:13 2015 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 60A341A00FD for ; Fri, 3 Jul 2015 07:12:12 -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 9vlrcoL1jHBW for ; Fri, 3 Jul 2015 07:12:10 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E6471A00F5 for ; Fri, 3 Jul 2015 07:12:10 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mNJBw4qTwzBCM; Fri, 3 Jul 2015 16:12:08 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=CQbHDURx X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id EcywNOhcrj00; Fri, 3 Jul 2015 16:12:07 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 3 Jul 2015 16:12:07 +0200 (CEST) Received: from [172.17.52.250] (unknown [181.31.255.10]) by bofh.nohats.ca (Postfix) with ESMTPSA id 45F1F80042; Fri, 3 Jul 2015 10:12:06 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1435932726; bh=va5cE5zZ3fbxZ1kFvvXqfVAil1FNena9u9msMbROmBU=; h=References:In-Reply-To:Cc:From:Subject:Date:To; b=CQbHDURx56dnJn3Agk/KQ9UKsrzgk/fLwloz7X1ksYWeD+Xu5JeX2SQ0sRKH7AcFj PJeQRjSh1b7I4CwvSLCFxH0L1B2C7quaU0wmJmz7o1Jdx3mBIMYOlePLmULsBNwrc4 dqf63BEtrFtik1HIB2bCXRjqRE5nrmdAoGxgmxx4= References: <8DE8B456-8050-491E-AAB1-7EC278380B8F@gmail.com> <20150702150342.GE21534@mournblade.imrryr.org> <5B3828FB-0D7D-43D9-A7E0-29814A7B4133@gmail.com> <20150702154759.GG21534@mournblade.imrryr.org> <7FAA8F9B-F0D0-43F8-B826-8A0B738A7533@gmail.com> <20150702170831.GI21534@mournblade.imrryr.org> <99B2B3F1-78C1-46ED-9D3F-D441EAFACCF2@gmail.com> <20150702182226.GN21534@mournblade.imrryr.org> <9AE12A4B-CE74-4EDD-B8AC-CFD71175CBA1@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: <9AE12A4B-CE74-4EDD-B8AC-CFD71175CBA1@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (12B466) From: Paul Wouters Date: Fri, 3 Jul 2015 11:12:03 -0300 To: Yoav Nir Archived-At: Cc: "dane@ietf.org" Subject: Re: [dane] DANE and IPsec 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 Jul 2015 14:12:12 -0000 >=20 > Host to host IPsec is very rare. But that's what we are trying to change :) >=20 > But regardless, let=E2=80=99s assume that the local address is 198.51.100.= 2. So the quintuple for the connection would be (UDP, 198.51.100.2:704, 192.= 0.2.5:53) >=20 I don't think you want a tunnel per netflow, and still the application has n= o way of knowing or verifying the entity of the destination encryption. > Unless we use route-based VPN, and then we=E2=80=99re as secure as the ro= uting protocol. Doing authnull yes, but the point of using DNSSEC is to get a firm proven gr= ip on the remote identity. Paul= From nobody Fri Jul 3 07:15:02 2015 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 1B3991A0104 for ; Fri, 3 Jul 2015 07:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.408 X-Spam-Level: X-Spam-Status: No, score=-1.408 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_51=0.6, MIME_QP_LONG_LINE=0.001, NORMAL_HTTP_TO_IP=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 QJK0IGP67l76 for ; Fri, 3 Jul 2015 07:14:59 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA0FB1A00FD for ; Fri, 3 Jul 2015 07:14:58 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mNJG93RsTzBCM; Fri, 3 Jul 2015 16:14:57 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=TyP77QjR X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id yyU6qD7x2u6N; Fri, 3 Jul 2015 16:14:55 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 3 Jul 2015 16:14:55 +0200 (CEST) Received: from [172.17.52.250] (unknown [181.31.255.10]) by bofh.nohats.ca (Postfix) with ESMTPSA id 8461580042; Fri, 3 Jul 2015 10:14:54 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1435932894; bh=GPpThN159oT0zDoFpk+a0uBBCauMyQDHQ2I5E/x3ep8=; h=References:In-Reply-To:Cc:From:Subject:Date:To; b=TyP77QjR7Dvv6wYvI37DmoMu/Mjx1WhuPBLc3RecEDXe4Dbn4YBxIOvwCbBZ3C6Vw Mdg/I/MN/nKaEwHm1e4+cdUsDleimfckZWT/4qlY+OnJ8+mRO9c/f/wL3hX/bn3QHY iHqPQ++W1+h3n3RVsjavuarak44M6KSyHfevNnnA= References: <8DE8B456-8050-491E-AAB1-7EC278380B8F@gmail.com> <20150702150342.GE21534@mournblade.imrryr.org> <5B3828FB-0D7D-43D9-A7E0-29814A7B4133@gmail.com> <20150702154759.GG21534@mournblade.imrryr.org> <7FAA8F9B-F0D0-43F8-B826-8A0B738A7533@gmail.com> <20150702170831.GI21534@mournblade.imrryr.org> <99B2B3F1-78C1-46ED-9D3F-D441EAFACCF2@gmail.com> <20150702182226.GN21534@mournblade.imrryr.org> <9AE12A4B-CE74-4EDD-B8AC-CFD71175CBA1@gmail.com> <20150702194000.GR21534@mournblade.imrryr.org> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (12B466) From: Paul Wouters Date: Fri, 3 Jul 2015 11:14:54 -0300 To: Yoav Nir Archived-At: Cc: "dane@ietf.org" Subject: Re: [dane] DANE and IPsec 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 Jul 2015 14:15:00 -0000 See my previously sent email. There is still a problem. I can explain more o= nce I have a real keyboard Sent from my iPhone > On Jul 2, 2015, at 17:29, Yoav Nir wrote: >=20 >=20 >> On Jul 2, 2015, at 10:40 PM, Viktor Dukhovni wro= te: >>=20 >> On Thu, Jul 02, 2015 at 10:09:46PM +0300, Yoav Nir wrote: >>=20 >>>> At the end of the day though, IPSEC needs to apply policy to >>>> application traffic presented to the kernel (almost universally) >>>> via the socket API. The socket API gives the kernel a transport >>>> endpoint UDP/192.0.2.5/53, how is the kernel to decide whether to >>>> use Mallory's keys for that same address or Alice?s. >>>=20 >>> Host to host IPsec is very rare. VPNs are far more common and the packet= s >>> don't get there by a socket API. >>=20 >> The attack I had in mind is not an attack on VPNs. It is an attack >> on IPSEC in transport mode. If you want to use DANE as a PKI for >> VPN tunnel key management (where both the gateway IP and the key >> material are provided via DNSSEC), that should work. >=20 > I agree, and I think that is something DANE can do. >=20 >> The hard part is the transport-mode use-case. >=20 > If the SPD entries are specific and pre-configured, the same reasoning as f= or VPNs applies. Things change if you want the SPD and PAD to be dynamic, su= ch as reading them from DNS. >=20 > There is RFC 4025 with the IPSECKEY record. So when the application perfor= ms a DNS lookup for www.example.com, the OS could also ask for an IPSECKEY r= ecord and get both public key and a gateway address. If we set the gateway a= ddress to be equal to the server address, this is the transport-mode use-cas= e. Again, this all begins with the DNS name, so mallory cannot do anything.=20= >=20 > There are issues, though. if the application does not perform a DNS lookup= (such as if the user entered http://93.184.216.34 instead of www.example.co= m) then the IPSECKEY entry is not read. RFC 4025 suggests using reverse DNS= , but we know that reverse DNS doesn=E2=80=99t work too well. >=20 > Yoav > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From nobody Fri Jul 3 07:16:35 2015 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 A65D41A00FD for ; Fri, 3 Jul 2015 07:16:33 -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 DFVi8pUzmrgI for ; Fri, 3 Jul 2015 07:16:32 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32F1D1A00E9 for ; Fri, 3 Jul 2015 07:16:32 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mNJHy6hSYzBCM; Fri, 3 Jul 2015 16:16:30 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=OHGZJUJM X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id ASTkVZA2KWRj; Fri, 3 Jul 2015 16:16:25 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 3 Jul 2015 16:16:24 +0200 (CEST) Received: from [172.17.52.250] (unknown [181.31.255.10]) by bofh.nohats.ca (Postfix) with ESMTPSA id E68D780042; Fri, 3 Jul 2015 10:16:23 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1435932984; bh=yVTDXFKTN5Xr1GFE0BxSoKebIz5wC6EFuVOFlfngpPs=; h=References:In-Reply-To:Cc:From:Subject:Date:To; b=OHGZJUJMtyG+afWPAyIaTo7lN0992o+HxnI7CF1Nbaw6RZwp8n9JJTAPeEYlD+TcT yDuSAulO25WbVBG3QHpeHOmhJT7R2RgUhcXTpwV+KJe5cmJGbQqE86r3sI3Vb4I2Mj EYa012oFqXb584a80X8SitGAeibfQczDYQvhcOFY= References: <20150702150342.GE21534@mournblade.imrryr.org> <5B3828FB-0D7D-43D9-A7E0-29814A7B4133@gmail.com> <20150702154759.GG21534@mournblade.imrryr.org> <7FAA8F9B-F0D0-43F8-B826-8A0B738A7533@gmail.com> <20150702170831.GI21534@mournblade.imrryr.org> <99B2B3F1-78C1-46ED-9D3F-D441EAFACCF2@gmail.com> <20150702182226.GN21534@mournblade.imrryr.org> <9AE12A4B-CE74-4EDD-B8AC-CFD71175CBA1@gmail.com> <20150702194000.GR21534@mournblade.imrryr.org> <20150702212838.GT21534@mournblade.imrryr.org> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (12B466) From: Paul Wouters Date: Fri, 3 Jul 2015 11:16:21 -0300 To: Yoav Nir Archived-At: Cc: "dane@ietf.org" Subject: Re: [dane] DANE and IPsec 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 Jul 2015 14:16:33 -0000 The reverse failed. It is only useful in private cloud deployments lacking o= ther types of authentication for publishing pubkeys (ldap, Kerberos , etc) Sent from my iPhone > On Jul 2, 2015, at 19:01, Yoav Nir wrote: >=20 >=20 >> On Jul 3, 2015, at 12:28 AM, Viktor Dukhovni wro= te: >>=20 >> On Thu, Jul 02, 2015 at 11:29:45PM +0300, Yoav Nir wrote: >>=20 >>>> The hard part is the transport-mode use-case. >>>=20 >>> If the SPD entries are specific and pre-configured, the same reasoning a= s >>> for VPNs applies. Things change if you want the SPD and PAD to be dynami= c, >>> such as reading them from DNS. >>=20 >> Dynamic. >>=20 >>> There is RFC 4025 with the IPSECKEY record. So when the application perf= orms >>> a DNS lookup for www.example.com, the OS could also ask for an IPSECKEY >>> record and get both public key and a gateway address. If we set the gate= way >>> address to be equal to the server address, this is the transport-mode >>> use-case. Again, this all begins with the DNS name, so mallory cannot do= >>> anything. >>=20 >> Mallory can often trigger DNS lookups for her own domain, which >> can return IP addresses that collide with Alice's domain. How >> is that handled? >=20 > RFC 4025 and Wikipedia suggest mapping the IPSECKEY record to the address t= hrough reverse DNS. I don=E2=80=99t know in what percentage of the Internet t= hat would work. >=20 > Yoav > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From nobody Fri Jul 3 09:00:48 2015 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 6D02F1B3049 for ; Fri, 3 Jul 2015 09:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.978 X-Spam-Level: X-Spam-Status: No, score=-3.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, 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 bjmNr3Kak2dW for ; Fri, 3 Jul 2015 09:00:44 -0700 (PDT) Received: from mail-oi0-f43.google.com (mail-oi0-f43.google.com [209.85.218.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6647A1B3044 for ; Fri, 3 Jul 2015 09:00:44 -0700 (PDT) Received: by oiaf66 with SMTP id f66so49012866oia.3 for ; Fri, 03 Jul 2015 09:00:43 -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=MGv5YfRF5ZwmYwp8xHjAVZlsjQPacCt9mSPu9Qg88ps=; b=Nj4vs0qRG+ubyfvOzEjtXzcmc4ox4XLONod/bwdZ7v001vGq6zlZXtxrhNP3+mk7WZ dSQBJPl4zEyhbzR1zPZmFbpkLc7Ii6d88KiqCDRUJpE0qdGmADdbZo2GojAtDNotF1Ez YMIn+EQfn4bbzOQ4C28nlM8AdjthNI9JlsgjobnH8+Bz3549c/T5zfMZgohy9UUmqhs3 20Eu6/m/X9doGgCY5YAq64cOsnkPpgzn8iKrmHPp8MVl62k/vWQmewE4e4tO2VLi20Yu c/rvLSmUB7SBuDPZ5A/meA6wIybq6avFzHcP0yEDXzWc4GTWxLs96+Zl67MnbzAiZaQT 8Mug== X-Gm-Message-State: ALoCoQmEYUIyx/ReXwI5Sp+5WaS1WeBFlPmHPVsPbgEXfPtcazoPqXD5CInDdmLfoN9jX6TeSpb6 MIME-Version: 1.0 X-Received: by 10.202.195.19 with SMTP id t19mr33843595oif.117.1435939243655; Fri, 03 Jul 2015 09:00:43 -0700 (PDT) Received: by 10.202.203.134 with HTTP; Fri, 3 Jul 2015 09:00:43 -0700 (PDT) In-Reply-To: <55956982.9020705@andyet.net> References: <5594FE19.1020005@strotmann.de> <20150702140531.GC21534@mournblade.imrryr.org> <55955D10.20805@andyet.net> <55956982.9020705@andyet.net> Date: Fri, 3 Jul 2015 12:00:43 -0400 Message-ID: From: Warren Kumari To: "Peter Saint-Andre - &yet" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Paul Wouters , dane WG list Subject: Re: [dane] Deferral of SMIME draft 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 Jul 2015 16:00:46 -0000 Thanks to everyone who offered to help author, but that's not the issue - the current authors are interested, able, and involved. Rather the issues include a lack of clear agreement on the email address processing and difficulty in getting actual review and feedback on drafts. We have quite active discussions on the ideas and concepts, but when it actually comes to review, comments and feedback on documents we often end up with silence. The email address processing solution that we have in openpgpkey is not perfect, but we think is good enough. We think that, after we have gotten some experience with how this works in openpgpkey we will be in a much better position to try solve the same issue in the SMIME document. I'll try chat more with my co-chair / the authors about betting an early allocation from IANA of a code-point. The advantage is that people can more easily test / experiment, the disadvantage (obviously) is that we may end up with differing implementations and interoperability issues in those experiments. Also, I;d like to apologize for us dropping the message on the list and then disappearing. Olafur and myself fell behind on mail because of the 4th of July / Independence Day ( https://en.wikipedia.org/wiki/Independence_Day_(United_States) for non-US folk) vacation / travel / etc. W On Thu, Jul 2, 2015 at 12:40 PM, Peter Saint-Andre - &yet wrote: > On 7/2/15 10:33 AM, Wil Tan wrote: >> >> >> On Fri, Jul 3, 2015 at 1:47 AM, Peter Saint-Andre - &yet >> > wrote: >> >> On 7/2/15 8:34 AM, Paul Wouters wrote: >> >> On Thu, 2 Jul 2015, Viktor Dukhovni wrote: >> >> So for me, the main obstacle is still the owner-label, which >> is >> the same for both OPENPGP and SMIMEA. >> >> >> No one has given me feedback (positive or negative) on the >> "lowercase if >> ascii, normalise otherwise", then lookup base32/split or using >> hash, >> that was advised to me by some of the EAI people. >> >> >> What exactly do we mean by "normalise" here? I don't see anything >> about normalization (in the Unicode sense) in >> draft-ietf-dane-openpgpkey. >> >> >> It's not in the draft; we were discussing this in Buenos Aires with Paul. >> >> I believe it was suggested that we use Unicode default case folding >> (Section 3.13 - >> http://www.unicode.org/versions/Unicode7.0.0/ch03.pdf#G33992). >> >> I'm not convinced that we should touch non-ASCII mailbox username. > > > I tend to agree. > >> As for ASCII - the only well-known case for locale-sensitive mapping is >> the Turkish dotted/dotless i. > > > In my experience it's usually not safe to say "the only case" when it comes > to internationalization. ;-) > >> If we lowercased capital I according to >> Turkish locale, we'd get U+0131 (small letter dotless i) which is not >> ASCII; see above. So my preference is to "lowercase if ascii, otherwise >> verbatim". > > > Well, locale-specific case mapping is not part of Unicode Default Case > Folding, so applying the latter should be fine. > > See also https://datatracker.ietf.org/doc/draft-ietf-precis-mappings/ on > some of these topics. > > > 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 Fri Jul 3 10:39:58 2015 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 186BB1A1B59 for ; Fri, 3 Jul 2015 10:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 jNnfTy-bxO77 for ; Fri, 3 Jul 2015 10:39:54 -0700 (PDT) Received: from mail-oi0-f99.google.com (mail-oi0-f99.google.com [209.85.218.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C8311A0383 for ; Fri, 3 Jul 2015 10:39:54 -0700 (PDT) Received: by oihr66 with SMTP id r66so1699133oih.2 for ; Fri, 03 Jul 2015 10:39:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-type:content-id:content-transfer-encoding :mime-version; bh=zgyq+Wo600fBdArt3gkXXpS2N3N4XdMexwHPaM8Evnk=; b=PxLS9ZWDwNgbbogj8xLact9vkEv4446bCrmYIIQWDWDjfrCqfOUcEMKR4C/dWIL5s8 XemLyfRO0ruZRVB0cz6oHsXram1Y5olbFnJxxlfnThCew3EfAlsdxiowh6wjIoQbM4dC kNUz2WfmpckMrTE2IamelArBW8iNB7ieewitYqgZrCG699/rKMan1PJffDyVVHPs/jNK OxqP3hMXDII3W/DTSjTdgS7msqNxVd6vMSb+ai3VaPzX9IpGBIl+yPxaQuZZricZcWGQ L8YNGbGK6uX69837MbExTl3fQBZ+1m4aiBqdm9KRS+QvZwbmrrUusYIPLjo/BIvp7Xvx dR3w== X-Gm-Message-State: ALoCoQk/ne2i7I/++uN7aVHshm9YY2S7UBa87qb0kdWEDjoIUogDosg++VNlqitcpd/JLo48t6nL7pvoinyFQ61Gl0dCdG01cA== X-Received: by 10.140.131.81 with SMTP id 78mr25511833qhd.70.1435945193694; Fri, 03 Jul 2015 10:39:53 -0700 (PDT) Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by mx.google.com with ESMTPS id f66sm3733634qkf.1.2015.07.03.10.39.53 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 03 Jul 2015 10:39:53 -0700 (PDT) X-Relaying-Domain: verisign.com Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01 [10.173.152.255]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id t63Hdqkk019866 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 Jul 2015 13:39:52 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Fri, 3 Jul 2015 13:39:34 -0400 From: "Osterweil, Eric" To: Warren Kumari Thread-Topic: [dane] Deferral of SMIME draft Thread-Index: AQHQspsqCAb5uaD+7EO5H74WvH6aXJ3IKW6AgABUugCAAAf3AIAAFIQAgAAM6wCAAAHrAIABhzOAgAAbpIA= Date: Fri, 3 Jul 2015 17:39:33 +0000 Message-ID: <7A92FA3F-CE2A-4BE7-A569-6FB059080006@verisign.com> References: <5594FE19.1020005@strotmann.de> <20150702140531.GC21534@mournblade.imrryr.org> <55955D10.20805@andyet.net> <55956982.9020705@andyet.net> In-Reply-To: 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="utf-8" Content-ID: <1F17717AC9964F47BD85A321B7EB061C@verisign.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: dane WG list Subject: Re: [dane] Deferral of SMIME draft 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 Jul 2015 17:39:57 -0000 SGV5IFdhcnJlbiwNCg0KU29tZSBjb21tZW50cyBiZWxvdzoNCg0KPiBPbiBKdWwgMywgMjAxNSwg YXQgMTI6MDAgUE0sIFdhcnJlbiBLdW1hcmkgPHdhcnJlbkBrdW1hcmkubmV0PiB3cm90ZToNCj4g DQo+IFRoYW5rcyB0byBldmVyeW9uZSB3aG8gb2ZmZXJlZCB0byBoZWxwIGF1dGhvciwgYnV0IHRo YXQncyBub3QgdGhlDQo+IGlzc3VlIC0gdGhlIGN1cnJlbnQgYXV0aG9ycyBhcmUgaW50ZXJlc3Rl ZCwgYWJsZSwgYW5kIGludm9sdmVkLg0KPiANCj4gUmF0aGVyIHRoZSBpc3N1ZXMgaW5jbHVkZSBh IGxhY2sgb2YgY2xlYXIgYWdyZWVtZW50IG9uIHRoZSBlbWFpbA0KPiBhZGRyZXNzIHByb2Nlc3Np bmcNCg0KTXkgMC4wMiBpcyB0aGF0IHRoZSBhcHByb2FjaCBiZWluZyBmb2xsb3dlZCBieSB0aGUg b3BlbnBncCBkcmFmdCAodHJ5IHNvbWV0aGluZyBhbmQgc2VlIGlmIGl0IHdvcmtzKSBpcyB2ZXJ5 IGhlbHBmdWwgZm9yIGlsbHVzdHJhdGluZyB0aGUgdXRpbGl0eSBvZiBEQU5FLiAgSXQgbG9va3Mg dG8gbWUgbGlrZSB0aGVyZSBpcyBhIGxhcmdlIGNvbnRpbmdlbnQgb2YgdGhlIHdvcmtpbmcgZ3Jv dXAgd2hvIGhhdmUgc3Bva2VuIHVwIG9uIGxpc3QgdG8gc3VwcG9ydCBmb2xsb3dpbmcgdGhpcyBz YW1lIHBhdGggd2l0aCBTTUlNRUEuDQoNCj4gYW5kIGRpZmZpY3VsdHkgaW4gZ2V0dGluZyBhY3R1 YWwgcmV2aWV3IGFuZA0KPiBmZWVkYmFjayBvbiBkcmFmdHMuIFdlIGhhdmUgcXVpdGUgYWN0aXZl IGRpc2N1c3Npb25zIG9uIHRoZSBpZGVhcyBhbmQNCj4gY29uY2VwdHMsIGJ1dCB3aGVuIGl0IGFj dHVhbGx5IGNvbWVzIHRvIHJldmlldywgY29tbWVudHMgYW5kIGZlZWRiYWNrDQo+IG9uIGRvY3Vt ZW50cyB3ZSBvZnRlbiBlbmQgdXAgd2l0aCBzaWxlbmNlLg0KDQpJIGNhbuKAmXQgcXVpdGUgZm9s bG93IHRoaXMuICBJIHRoaW5rIHRoZSBTTUlNRUEgZHJhZnQgaGFzIGhhZCBudW1lcm91cyBzdWdn ZXN0aW9ucyAoZnJvbSBpZGVhcyB0byB0ZXh0IHRvIHJ1bm5pbmcgY29kZSkuICBJZiBpdOKAmXMg aGVscGZ1bCwgSSBjYW4gc2VhcmNoIHRoZSBlbWFpbCBhcmNoaXZlcyBhbmQgcG9zdCBzb21lIGxp bmtzIHRvIHRoZXNlIGRpc2N1c3Npb25zIHRoYXQgd2VyZSBvbiBsaXN0IChub3QgdG8gbWVudGlv biB0aGUgY29tbWVudHMgYXQgdmFyaW91cyBtaWNzIGF0IHZhcmlvdXMgd2cgc2Vzc2lvbnMpLiA6 KSAgV2FzIHRoZXJlIHNvbWUgc29ydCBvZiBvdGhlciBmZWVkYmFjayB0aGF0IHdvdWxkIGJlIGJl dHRlcj8NCg0KT25lIGV4YW1wbGU6DQogIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2 ZS93ZWIvZGFuZS9jdXJyZW50L21zZzA2OTY0Lmh0bWwNCg0KSXJyZXNwZWN0aXZlIG9mIHdoZXRo ZXIgYW55IGdpdmVuIHN1Z2dlc3Rpb24gd2FzIGluY29ycG9yYXRlZCBieSB0aGUgZWRpdG9ycywg aXQgc2VlbXMgbGlrZSB0aGVyZSBoYXMgYmVlbiBhIGxvdCBvZiBzdWdnZXN0ZWQgdGV4dCBhbmQg aW50ZXJlc3QsIGltaG8uDQoNCj4gVGhlIGVtYWlsIGFkZHJlc3MgcHJvY2Vzc2luZyBzb2x1dGlv biB0aGF0IHdlIGhhdmUgaW4gb3BlbnBncGtleSBpcw0KPiBub3QgcGVyZmVjdCwgYnV0IHdlIHRo aW5rIGlzIGdvb2QgZW5vdWdoLiBXZSB0aGluayB0aGF0LCBhZnRlciB3ZSBoYXZlDQo+IGdvdHRl biBzb21lIGV4cGVyaWVuY2Ugd2l0aCBob3cgdGhpcyB3b3JrcyBpbiBvcGVucGdwa2V5IHdlIHdp bGwgYmUgaW4NCj4gYSBtdWNoIGJldHRlciBwb3NpdGlvbiB0byB0cnkgc29sdmUgdGhlIHNhbWUg aXNzdWUgaW4gdGhlIFNNSU1FDQo+IGRvY3VtZW50Lg0KDQpJIHdvdWxkIGFncmVlIHdpdGggdGhl IGBgZ29vZCBlbm91Z2jigJnigJkgc2VudGltZW50LCBhbmQgSSBlY2hvIHRob3NlIHdobyBoYXZl IHNwb2tlbiB1cCBvbiB0aGUgbGlzdCB0aGlzIHdlZWsgaW4gc2F5aW5nIHdlIHNob3VsZCBsZXQg aXQgcmlwIHNvIHdlIGNhbiBnYWluIHJlYWwgaW1wbGVtZW50YXRpb24gYW5kIGRlcGxveW1lbnQg ZXhwZXJpZW5jZSB3aXRoIHRoZSBTL01JTUUgZGVwbG95bWVudC1iYXNlLiAgSXQgZG9lcyBzZWVt IHRvIG1lIHRoYXQgdGhlIHNlbnRpbWVudCBvbiB0aGUgbGlzdCBpcyBvdmVyd2hlbG1pbmcgdG8g cHVzaCB0aGlzIGZvcndhcmQgKHJvdWdobHkgMTAgcGVvcGxlIGluIGFncmVlbWVudCB3aXRoIG1v dmluZyBhaGVhZCB3aXRoIGl0KSwgYW5kIEkgc2VlIHZlcnkgbGl0dGxlIHB1c2hpbmcgaXQgYmFj aywgcmlnaHQ/DQoNCkVyaWM= From nobody Fri Jul 3 11:33:04 2015 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 AE89F1A1B12 for ; Fri, 3 Jul 2015 11:33:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 mm8AVjLxTt9I for ; Fri, 3 Jul 2015 11:33:01 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74DD11A1ADC for ; Fri, 3 Jul 2015 11:33:01 -0700 (PDT) Received: by wicgi11 with SMTP id gi11so106465599wic.0 for ; Fri, 03 Jul 2015 11:33:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=H1W8+ILwZWKcfXXnPVqC2m0TsIXXCmFSUJUqkhKRqOw=; b=rDuDkUceXUAVmpGIPaCr5py5CdbfqPg8KarlEhi9OkoYMpZgbmqr6C0m4j7fx2Wgql qdyFokfHSsccgZP09MYN5WIxrE18nQo5mbZv5c3S19IVuSjFoq5w5hzH+LwVBfwDb/xf J/ky44DHJepxK8CrtL4A2NfsG0hSvAxzIFjeJzNK14u/YzdyiDY0b9G8z/KpwU46LIx+ iGVj8kijghqxfKJxz8PAXoVt7dZ8noQFiRuF/oZn7H0hsLBDGvaY6qLsneh4LIO0VWke +lwMUIPKmdyMbKT5QrDjcUVH+0i0J+fPenwxMy/n0RM2sZtnEExTB6cq4lzwYghrZMEK J5uQ== X-Received: by 10.194.76.132 with SMTP id k4mr69200035wjw.77.1435948380270; Fri, 03 Jul 2015 11:33:00 -0700 (PDT) Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id be9sm9487262wjb.26.2015.07.03.11.32.58 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 03 Jul 2015 11:32:59 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Yoav Nir In-Reply-To: <1F93D3EF-975A-4F87-8565-BD2B77B46197@nohats.ca> Date: Fri, 3 Jul 2015 21:32:56 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8DE8B456-8050-491E-AAB1-7EC278380B8F@gmail.com> <20150702150342.GE21534@mournblade.imrryr.org> <5B3828FB-0D7D-43D9-A7E0-29814A7B4133@gmail.com> <20150702154759.GG21534@mournblade.imrryr.org> <7FAA8F9B-F0D0-43F8-B826-8A0B738A7533@gmail.com> <20150702170831.GI21534@mournblade.imrryr.org> <99B2B3F1-78C1-46ED-9D3F-D441EAFACCF2@gmail.com> <1F93D3EF-975A-4F87-8565-BD2B77B46197@nohats.ca> To: Paul Wouters X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "dane@ietf.org" Subject: Re: [dane] DANE and IPsec 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 Jul 2015 18:33:03 -0000 > On Jul 3, 2015, at 5:07 PM, Paul Wouters wrote: >=20 > The problem is two different keys in two different domains in = combination with traffic hijacking. >=20 > If I steal your 8.8.8.8 route, and trick you into looking up and doing = IKE to my domain google.nohats.ca with A record 8.8.8.8, you start = encrypting all google DNS to me. That is, your applications do not know = the encryption of 8.8.8.8 is setup using ipseckey records not from = google. There is a disconnect between system and application with IPsec = that you do not have with TLS or SSH >=20 > Normally this is hard, but in coffee shop wifi it would be easy. Seems like a limitation of DNS security. DNSSEC can authenticate that = =E2=80=9Cmallory claimed that mallory.example.com is at 8.8.8.8=E2=80=9D, = but DNSSEC does nothing to tell me whether the claim is true. Ordinarily = you gain nothing by pointing your DNS name at a wrong IP address.=20 What you are proposing is to use DNS queries to build a reverse = directory in the SPD+PAD. You resolve mallory.example.com and get an IP = address (8.8.8.8) and a TLSA (or IPSECKEY) record. You use that to = build a database that uses the IP address as key and maps 8.8.8.8 to the = pubkey in the IPSECKEY record. So you use the value 8.8.8.8 which nobody = other than mallory vouches for, and which nobody guarantees us = uniqueness for, and you use it for a key. This fails even without malice. Suppose both www.example.com and = tools.example.com are on the same server. We can get the right identity = by using IDr in IKE_AUTH or SNI in TLS. Depending on which of these you = resolved last, you will get a mapping in the SPD from 93.184.216.34 to = one of the public keys. You will use that to initiate IKE, and you might = use the wrong one. If we really wanted secure opportunistic, we=E2=80=99d need to = authenticate claims tying IP addresses to names. Perhaps the resource = PKI from BGP security could get us there. Yoav= From nobody Fri Jul 3 12:33:47 2015 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 911D21A6FCB for ; Fri, 3 Jul 2015 12:33:46 -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 gtebDu-eVHMA for ; Fri, 3 Jul 2015 12:33:45 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAEB61A6FBB for ; Fri, 3 Jul 2015 12:33:44 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mNRKz3jbwzCmZ; Fri, 3 Jul 2015 21:33:43 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=RQvSTYF2 X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id cPfIeLkUUeUP; Fri, 3 Jul 2015 21:33:42 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 3 Jul 2015 21:33:42 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D9CF780042; Fri, 3 Jul 2015 15:33:40 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1435952020; bh=B9qQ4zEbsmRfOMkhvdu04pXklsH/tAwt6mtjmjJybZ4=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=RQvSTYF2jkAm9wO5N6Vbw/xI1n0ggJ4dPecqA1d2EUoZep2BSlEZgmZZQ/cO94ruI BwGuemh1EshtUjgc/o7QQ+PxL9+O23hWMqjtNBfzNYa9fsrgC2faNotGAfTbPwgjDW wJqm9M6RTrcv81fnzLzxRnBvYUqx316nnd0E9iz4= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t63JXeaW007592; Fri, 3 Jul 2015 15:33:40 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Fri, 3 Jul 2015 15:33:40 -0400 (EDT) From: Paul Wouters To: Yoav Nir In-Reply-To: Message-ID: References: <8DE8B456-8050-491E-AAB1-7EC278380B8F@gmail.com> <20150702150342.GE21534@mournblade.imrryr.org> <5B3828FB-0D7D-43D9-A7E0-29814A7B4133@gmail.com> <20150702154759.GG21534@mournblade.imrryr.org> <7FAA8F9B-F0D0-43F8-B826-8A0B738A7533@gmail.com> <20150702170831.GI21534@mournblade.imrryr.org> <99B2B3F1-78C1-46ED-9D3F-D441EAFACCF2@gmail.com> <1F93D3EF-975A-4F87-8565-BD2B77B46197@nohats.ca> User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: "dane@ietf.org" Subject: Re: [dane] DANE and IPsec 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 Jul 2015 19:33:46 -0000 On Fri, 3 Jul 2015, Yoav Nir wrote: > Seems like a limitation of DNS security. DNSSEC can authenticate that “mallory claimed that mallory.example.com is at 8.8.8.8”, but DNSSEC does nothing to tell me whether the claim is true. Ordinarily you gain nothing by pointing your DNS name at a wrong IP address. Yes it is. > This fails even without malice. Suppose both www.example.com and tools.example.com are on the same server. We can get the right identity by using IDr in IKE_AUTH or SNI in TLS. Depending on which of these you resolved last, you will get a mapping in the SPD from 93.184.216.34 to one of the public keys. You will use that to initiate IKE, and you might use the wrong one. No because you would either use one key for both or publish both keys in DNSSEC. > If we really wanted secure opportunistic, we’d need to authenticate claims tying IP addresses to names. Perhaps the resource PKI from BGP security could get us there. But I doubt that information will be easilly acessable to endusers. It would be nice. Paul From nobody Fri Jul 3 16:19:11 2015 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 97E4D1A906E for ; Fri, 3 Jul 2015 16:19:10 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 H-7otFWl2XNR for ; Fri, 3 Jul 2015 16:19:09 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51FF01A906F for ; Fri, 3 Jul 2015 16:19:09 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 44CD0284D2D; Fri, 3 Jul 2015 23:19:08 +0000 (UTC) Date: Fri, 3 Jul 2015 23:19:08 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150703231908.GW21534@mournblade.imrryr.org> References: <5594FE19.1020005@strotmann.de> <20150702140531.GC21534@mournblade.imrryr.org> <55955D10.20805@andyet.net> <55956982.9020705@andyet.net> 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: Subject: Re: [dane] Deferral of SMIME draft 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 Jul 2015 23:19:10 -0000 On Fri, Jul 03, 2015 at 12:00:43PM -0400, Warren Kumari wrote: > I'll try chat more with my co-chair / the authors about betting an > early allocation from IANA of a code-point. The code point MUST precede settling on the final RRDATA format. Has that been achieved? If none of the issues are relate to the RRDATA payload, then yes, get a codepoint. Otherwise, it is not a good idea to have an RRtype assignment whose syntax/semantics change. -- Viktor. From nobody Fri Jul 3 22:39:30 2015 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 1E4C91A1B8C for ; Fri, 3 Jul 2015 22:39:29 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 Kh6zJN11oozD for ; Fri, 3 Jul 2015 22:39:28 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E39B91A1B8A for ; Fri, 3 Jul 2015 22:39:27 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 53784284D2B; Sat, 4 Jul 2015 05:39:26 +0000 (UTC) Date: Sat, 4 Jul 2015 05:39:26 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150704053926.GX21534@mournblade.imrryr.org> References: <5594FE19.1020005@strotmann.de> <20150702140531.GC21534@mournblade.imrryr.org> <55955D10.20805@andyet.net> <55956982.9020705@andyet.net> <20150703231908.GW21534@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150703231908.GW21534@mournblade.imrryr.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] Deferral of SMIME draft 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: Sat, 04 Jul 2015 05:39:29 -0000 On Fri, Jul 03, 2015 at 11:19:08PM +0000, Viktor Dukhovni wrote: > On Fri, Jul 03, 2015 at 12:00:43PM -0400, Warren Kumari wrote: > > > I'll try chat more with my co-chair / the authors about betting an > > early allocation from IANA of a code-point. > > The code point MUST precede settling on the final RRDATA format. > Has that been achieved? If none of the issues are relate to the > RRDATA payload, then yes, get a codepoint. Otherwise, it is not > a good idea to have an RRtype assignment whose syntax/semantics > change. Oops, MUST NOT precede. -- Viktor. From nobody Mon Jul 6 11:58:16 2015 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 E4CE11B3035 for ; Mon, 6 Jul 2015 11:58:14 -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 DsiBVpOdfiEh for ; Mon, 6 Jul 2015 11:58:12 -0700 (PDT) Received: from mail-ob0-f179.google.com (mail-ob0-f179.google.com [209.85.214.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6490F1B3039 for ; Mon, 6 Jul 2015 11:58:12 -0700 (PDT) Received: by obbgp5 with SMTP id gp5so1154517obb.0 for ; Mon, 06 Jul 2015 11:58:11 -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=h/f1VK2NriYLFBF0FHjJ+pr+cFS4Nrpld8LJREWYORI=; b=WU7o+3i+L/mEcvVGr64N7sci3uYS6GLvrf2flQsiWmBo7kUro40sRLfqNbnNTgRQMx bGfDoCKdeLrKeh9pFcZlepObZrn4jzdjpKb4b6vZXzYZURw+PrnCzPluLlK/pzLWg/B4 KXReZePQsSNZmeKSJSyKjFZwpa4bZnhs8FxdLaezw/3yuWKm/eSjJGhh4DSMmOGpW/pf gx/pvXmX2X49sJ5Kf0Cq7D3V96hMQRY/ANQ7R4p5XkgsQ639lKi5pjw6JEyc2hY7hiji 1v4Ew4klkXOEthMUqwN1p/dwx/qVvwXF6V9vDw9r6h4N6N0RQKtY8CLFlCgWllsI9UHz UUxA== X-Gm-Message-State: ALoCoQnbjHAnNE3wvh6hr5EKRRLLHlfmwaSeqfXkTdRTjksn6LHzxd6m854cAZauePRxYBLso19z MIME-Version: 1.0 X-Received: by 10.202.195.19 with SMTP id t19mr244642oif.117.1436209091602; Mon, 06 Jul 2015 11:58:11 -0700 (PDT) Received: by 10.202.232.1 with HTTP; Mon, 6 Jul 2015 11:58:11 -0700 (PDT) Date: Mon, 6 Jul 2015 14:58:11 -0400 Message-ID: From: Warren Kumari To: "" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [dane] Draft agenda posted. 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 Jul 2015 18:58:15 -0000 Hi all, We have just posted the draft agenda for Prague. What: DANE - DNS-based Authentication of Named Entities When: Monday Afternoon session IV (18:50-19:50) Where: Congress Hall II Agenda: Administrivia Olafur / Warren 10 minutes TLS extension for DNSSEC chain Shumon Huque 15 minutes Client Certificates in DANE TLSA Records Shumon Huque / Viktor Dukhovni 15 minutes The SMIME document - local part and prefix Olafur 10 minutes 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 From nobody Wed Jul 8 14:29:30 2015 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 6D3E61A8842 for ; Wed, 8 Jul 2015 14:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.289 X-Spam-Level: X-Spam-Status: No, score=-0.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MANGLED_TEXT=2.3, RCVD_IN_DNSWL_LOW=-0.7, T_FILL_THIS_FORM_SHORT=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 4st_tzVrWamN for ; Wed, 8 Jul 2015 14:29:27 -0700 (PDT) Received: from mail-qg0-f98.google.com (mail-qg0-f98.google.com [209.85.192.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5262E1A711A for ; Wed, 8 Jul 2015 14:29:27 -0700 (PDT) Received: by qgem67 with SMTP id m67so6671706qge.1 for ; Wed, 08 Jul 2015 14:29:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:accept-language:content-language:user-agent:content-type :mime-version; bh=KRZN7EzU3iH3NobTvoO/DdS0HLXy7hopqATertvULv0=; b=caek036kgaaIfyHp21B5GPG7WzfNgAmdc+U5tcG4EDmcGEdcqjk4vzliXP9oo81kWX NCrPYrmsB0B08fln0uq08FVCeN7tNVp1JSsyRk1yWjqnfeaVTDJ5sYZpPtYFTfSCS9RY rtbybmL0NeVmShXzxXFNJW/CYbAUUe0c90TFd/sel70CVdRiZ13UZWDU9fYEz/3yZaNI EMQc1cyxbNxOgZiB3xX3Ldo+NNVpr3jbcxiy8k0NnjTkHAjOnmlelBkVuuWbS0NWcM8V pJyWvf9qxko4vqofovJKOfq7CCrW15C57CawK2gosHsl1TiqOLhYF/Gr26qQOI38d/CW Qwtw== X-Gm-Message-State: ALoCoQmYCfqX1xjsZdgLZXWwqkO13LpBdnLdzXyDBBZ8TpclT3p7z7hGjhsdy/m34xj5KjW4HU80U4FcEAJUOjTT9b4g0hbODw== X-Received: by 10.140.233.140 with SMTP id e134mr20767906qhc.63.1436390966400; Wed, 08 Jul 2015 14:29:26 -0700 (PDT) Received: from brn1lxmailout01.verisign.com (brn1lxmailout01.verisign.com. [72.13.63.41]) by smtp-relay.gmail.com with ESMTPS id 66sm838679qky.3.2015.07.08.14.29.26 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 08 Jul 2015 14:29:26 -0700 (PDT) X-Relaying-Domain: verisign.com Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01 [10.173.152.255]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id t68LTPUT001433 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 8 Jul 2015 17:29:25 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Wed, 8 Jul 2015 17:28:58 -0400 From: "Wiley, Glen" To: "dane@ietf.org" Thread-Topic: SMIMEA, record locating as in OPENPGPKEY Thread-Index: AQHQucUZQLJ74gnFAE6Y0x714gmEew== Date: Wed, 8 Jul 2015 21:28:58 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [10.173.152.4] Content-Type: multipart/alternative; boundary="_000_D1C30E7812D99gwileyverisigncom_" MIME-Version: 1.0 Archived-At: Subject: [dane] SMIMEA, record locating as in OPENPGPKEY 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 Jul 2015 21:29:29 -0000 --_000_D1C30E7812D99gwileyverisigncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable How would folks feel about updating the SMIMEA draft to use language simila= r to section 3 in the OPENPGPKEY draft: Location of the OPENPGPKEY record The DNS does not allow the use of all characters that are supported in the "local-part" of email addresses as defined in [RFC2822] and [RFC6530]. Therefore, email addres= ses are mapped into DNS using the following method: o The user name (the "left-hand side" of the email address, called the "local-part" in the mail message format definition [RFC2822] and the "local part" in the specification for internationalized Wouters Expires October 03, 2015 [Page 4] ________________________________ Internet-Draft DANE for OpenPGP public keys April 2015 email [RFC6530]) should already = be encoded in UTF-8 (or its subset ASCII). If it is written in another encoding it should be converted to UTF-8. Next, it is turned into lowercase and hashed using the SHA2-256 [RFC5754] alg= orithm, with the hash truncated to 28 octets and represented in its hexadecimal representation, to become the left-most label in the prepared domain name. Truncation comes from the right-most octets. This does not include the at symbol ("@") that separates the left and right sides of the email address. o The string "_openpgpkey" becomes the second left-most label in the prepared domain name. o The domain name (the "right-hand side" of the email address, called the "domain" in RFC 2822)= is appended to the result of step 2 to complete the prepared domain name. For example, to request an OPENPGPKEY resource record for a user whose email address is "hugh@example.com", an OPENPGPKEY query would be placed for the following QNAME: "c93f1e400f26708f98cb19d936620da35 eec8f72e57f9eec01c1afd6._openpgpkey.example.com". The corresponding RR in the example.com zone might look like (key shortened for formatting): c9[..]d6._openpgpkey.example.com. IN OPENPGPKEY 3.1.= Email address variants Mail systems usually handle variant forms of local-parts. The most common variants are upper and lower case, which are now invariably treated as equivalent. But many other variants are possible. Some systems allow and ignore "noise" characters such as dots, so local parts johnsmith and John.Smith would be equivalent. Many systems allow "extensions" such as john-ext or mary+ext where john or mary is treated as the effective local-part, and the ext is passed to the recipient for further handling. This can complicate finding the OPENPGPKEY record associated with the dynamically created email address. [RFC5321] and its predecessors have always made it clear that only the recipient MTA is allowed to interpret the local-part of an address. A client supporting OPENPGPKEY therefor MUST NOT perform any kind of mapping rules based on the email address. As the local- part is converted to lowercase before hashing, case sensitivity will not cause problems for the OPENPGPKEY lookup. -- Glen Wiley Principal Engineer Verisign, Inc. (571) 230-7917 http://vbsdcon.com A5E5 E373 3C75 5B3E 2E24 6A0F DC65 2354 9946 C63A --_000_D1C30E7812D99gwileyverisigncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <5ED4A6525E3D1E4599E5B90D9B3ABC66@verisign.com> Content-Transfer-Encoding: quoted-printable
How would folks feel about updating the SMIMEA draft to use language s= imilar to section 3 in the OPENPGPKEY draft:

 Locatio=
n of the OPENPGPKEY record

   The DNS does not allow the use of all characters that are supported
   in the "local-part" of email addresses as defined in [RFC2822] and
   [RFC6530].  Therefore,=
 email addresses are mapped into DNS using the
   following method:

   o  The user name (the "left-hand side" of the email address, c=
alled
      the "local-part" in the mail message format definition [RFC2822]
      and the "local part" in the specification for international=
ized



Wouters          =
       Expires October 03, 2015                [Page 4]
 
Internet-Draft   =
     DANE for OpenPGP public keys            April 2015


      email [RFC6530]) sh=
ould already be encoded in UTF-8 (or its subset
      ASCII).  If it is written in another encoding it should be
      converted to UTF-8.  Next, it is turned into lowercase and hashed
      using the SHA2-256 [RFC 2822) is appended to the result of step
      2 to complete the prepared domain name.

   For example, to request an OPENPGPKEY resource record for a user
   whose email address is "hugh@example.com", an OPENPGPKEY query=
 would
   be placed for the following QNAME: "c93f1e400f26708f98cb19d936620da=
35
   eec8f72e57f9eec01c1afd6._openpgpkey.example.com".  The correspondin=
g
   RR in the example.com zone might look like (key shortened for
   formatting):

   c9[..]d6._openpgpkey.example.com. IN OPENPGPKEY <base64 public key>=
;



3.1.  Email address variants


   Mail systems usually handle variant forms of local-parts.  The most
   common variants are upper and lower case, which are now invariably
   treated as equivalent.  But many other variants are possible.  Some
   systems allow and ignore "noise" characters such as dots, so l=
ocal
   parts johnsmith and John.Smith would be equivalent.  Many systems
   allow "extensions" such as john-ext or mary+ext where john=
 or mary is
   treated as the effective local-part, and the ext is passed to the
   recipient for further handling.  This can complicate finding the
   OPENPGPKEY record associated with the dynamically created email
   address.

   [RFC5321] and its predece=
ssors have always made it clear that only
   the recipient MTA is allowed to interpret the local-part of an
   address.  A client supporting OPENPGPKEY therefor MUST NOT perform
   any kind of mapping rules based on the email address.  As the local-
   part is converted to lowercase before hashing, case sensitivity will
   not cause problems for the OPENPGPKEY lookup.
-- 
Glen Wiley
Principal Engineer
Verisign, Inc.
(571) 230-7917


A5E5 E373 3C75 5B= 3E 2E24 &n= bsp;
6A0F DC65 2354 99= 46 C63A
--_000_D1C30E7812D99gwileyverisigncom_-- From nobody Wed Jul 8 14:31:49 2015 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 538BA1A876F for ; Wed, 8 Jul 2015 14:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 JjVXQUYOM260 for ; Wed, 8 Jul 2015 14:31:47 -0700 (PDT) Received: from mail-oi0-f97.google.com (mail-oi0-f97.google.com [209.85.218.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D44D71A6FF2 for ; Wed, 8 Jul 2015 14:31:46 -0700 (PDT) Received: by oigx8 with SMTP id x8so2746362oig.1 for ; Wed, 08 Jul 2015 14:31:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :user-agent:content-type:content-id:content-transfer-encoding :mime-version; bh=W50/BUO/CGA9SQ7H1FNHvzghYsxnuJlVsT7PdXa87xs=; b=VoykHvAaOWb+7N6bNvvssMGjulAsCkVyUqc5GmZqqsweyNkNQg0XrvX4Xh1fb5c2z4 MoWusL1w9PtGcemj7E3iAToUvZGwaI8WP1ziDOwD6y69zizB4mHlS5auPLl/kdm3dpmS WPNdalHo+Spjy3UsPG0V/9cldnTEB51C1bR4uo8KQ4oNh4N3dF7nS7QwV6ua/krY3531 kr5ftLXa6GTD59KY10YWY793Sl8CCwWKl5GhO9hGzRAICLTD+pVFi8Gh6O2guxm9z6ht sd6Dcz+/fssEnMI3Z2ONeiT8D7KTnKei/e0fXdx9Ej+D56bSDBPcnczSnFbG+ZgaRfQh QkMw== X-Gm-Message-State: ALoCoQllnKFOIRd6UAjZsU/7ehOKN6OQ9uPcyMIiglRhhN6cBTORIOB9id1EB7D6PayWRuvnpCc8Ry6dY63W/ieo+y3Yqjm+bg== X-Received: by 10.140.144.131 with SMTP id 125mr20497851qhq.75.1436391106273; Wed, 08 Jul 2015 14:31:46 -0700 (PDT) Received: from brn1lxmailout01.verisign.com (brn1lxmailout01.verisign.com. [72.13.63.41]) by smtp-relay.gmail.com with ESMTPS id f66sm850047qkf.1.2015.07.08.14.31.46 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 08 Jul 2015 14:31:46 -0700 (PDT) X-Relaying-Domain: verisign.com Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01 [10.173.152.205]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id t68LVj4j001698 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Jul 2015 17:31:45 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Wed, 8 Jul 2015 17:31:18 -0400 From: "Wiley, Glen" To: Warren Kumari , "" Thread-Topic: [dane] Draft agenda posted. Thread-Index: AQHQuB2uszL8soyQ4Eyvmr7p73LQ253SGsIA Date: Wed, 8 Jul 2015 21:31:18 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <54BCA56BD362F84695E57EAF8826FAB1@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [dane] Draft agenda posted. 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 Jul 2015 21:31:48 -0000 Thanks Warren. Looking forward to seeing folks at the meeting. I=B9d like to suggest that we discuss the SMIME question on the list a bit more with a goal of taking some more affirmative action on the draft in the WG meeting. --=20 Glen Wiley Principal Engineer Verisign, Inc. (571) 230-7917 http://vbsdcon.com A5E5 E373 3C75 5B3E 2E24 6A0F DC65 2354 9946 C63A On 7/6/15, 2:58 PM, "Warren Kumari" wrote: >Hi all, > >We have just posted the draft agenda for Prague. > >What: DANE - DNS-based Authentication of Named Entities >When: Monday Afternoon session IV (18:50-19:50) >Where: Congress Hall II > >Agenda: >Administrivia >Olafur / Warren >10 minutes > > >TLS extension for DNSSEC chain >Shumon Huque >15 minutes > > >Client Certificates in DANE TLSA Records >Shumon Huque / Viktor Dukhovni >15 minutes > > >The SMIME document - local part and prefix >Olafur >10 minutes > > > > > > >W > >--=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 From nobody Thu Jul 9 06:04:36 2015 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 4CA001AD376 for ; Thu, 9 Jul 2015 06:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.595 X-Spam-Level: * X-Spam-Status: No, score=1.595 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 hzcqBCDC6x3F for ; Thu, 9 Jul 2015 06:04:33 -0700 (PDT) Received: from shannon.7bits.nl (shannon.7bits.nl [IPv6:2a01:1b0:202:40::1]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A7F01AD375 for ; Thu, 9 Jul 2015 06:04:33 -0700 (PDT) Received: from [192.168.137.1] (unknown [92.71.225.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: peter) by shannon.7bits.nl (Postfix) with ESMTPSA id 1641CC1B55; Thu, 9 Jul 2015 15:04:29 +0200 (CEST) From: "Peter van Dijk" To: "dane@ietf.org" Date: Thu, 09 Jul 2015 15:04:36 +0200 Message-ID: <2A56BF41-3B75-48E1-930D-3A3C43E3385A@powerdns.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.1r5084) Archived-At: Subject: Re: [dane] SMIMEA, record locating as in OPENPGPKEY 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 Jul 2015 13:04:35 -0000 Hello Glen, On 8 Jul 2015, at 23:28, Wiley, Glen wrote: > How would folks feel about updating the SMIMEA draft to use language > similar to section 3 in the OPENPGPKEY draft: As I understand it, the SMIMEA draft, and *especially this part*, is on hold until we figure out what’s right for OPENPGPKEY, and perhaps even gain some operational experience with it. It would seem pointless to copy this language now, especially with the amount of disagreement people are having with the language as it stands now — we would just keep copying changes, better to just wait until OPENPGPKEY has settled down. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ From nobody Thu Jul 9 08:16:30 2015 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 257B81B2A54 for ; Thu, 9 Jul 2015 08:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 sBaq4tz4nu8x for ; Thu, 9 Jul 2015 08:16:25 -0700 (PDT) Received: from mail-qg0-f97.google.com (mail-qg0-f97.google.com [209.85.192.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4AC61B2A52 for ; Thu, 9 Jul 2015 08:16:24 -0700 (PDT) Received: by qgem67 with SMTP id m67so7701441qge.1 for ; Thu, 09 Jul 2015 08:16:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-type:content-id:content-transfer-encoding :mime-version; bh=KnAeBtobcVsa6z8sBgG1DmMjRBvWKp4dX18nkHRyiIs=; b=Br3y21Qjed7z0YKwzmR37oBVgTp4atXZ3my7QQltp+G0KTgKF0wHtpkSztu57rTtop ufi0cKGRgLOWcGwXkUst0pAh/kCDGnJ/YInsaduP8GfSMVXJkvE3qA27c8iBduPWCExO BEJfcP2Q0+pgvQNvFs9IWo3On99oeo7L7L7LbMnthZ7+nF2CCykcPlhTmYmOWoqxiNlk kUUfWqzHk4qIl5+1aURVeoPEvgXHLms39x390cc6DvxdZol3IRBVCTZLNsyMsTYsa168 xPKU4LcVRwyXI+h1Mytd1CkFTECjxZ2ON6C3cqxWp8pF1SZWbfFmoeRBf8pXF78Cma5A jfJw== X-Gm-Message-State: ALoCoQm4TgBoVx+hkzQOrBNMrmH41ecDU6VtuLzBH+ub3PfTdlWhOuqC7orpqrJnkPtGjZ0Tdg3MGhlLeYA4NWHm4ywwfXmJmw== X-Received: by 10.140.92.41 with SMTP id a38mr24978908qge.30.1436454984063; Thu, 09 Jul 2015 08:16:24 -0700 (PDT) Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by smtp-relay.gmail.com with ESMTPS id 66sm1517941qky.3.2015.07.09.08.16.23 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 09 Jul 2015 08:16:24 -0700 (PDT) X-Relaying-Domain: verisign.com Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02 [10.173.152.206]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id t69FGM1Z003015 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Jul 2015 11:16:23 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Thu, 9 Jul 2015 11:16:07 -0400 From: "Osterweil, Eric" To: Peter van Dijk Thread-Topic: [dane] SMIMEA, record locating as in OPENPGPKEY Thread-Index: AQHQucUZQLJ74gnFAE6Y0x714gmEe53TXyAAgAAktgA= Date: Thu, 9 Jul 2015 15:16:05 +0000 Message-ID: <84E597D7-932E-4E25-B97C-FF84267F3891@verisign.com> References: <2A56BF41-3B75-48E1-930D-3A3C43E3385A@powerdns.com> In-Reply-To: <2A56BF41-3B75-48E1-930D-3A3C43E3385A@powerdns.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="utf-8" Content-ID: <832E83DBBEFE2142AB4C8DBEDCCA2252@verisign.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "dane@ietf.org" Subject: Re: [dane] SMIMEA, record locating as in OPENPGPKEY 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 Jul 2015 15:16:27 -0000 DQo+IE9uIEp1bCA5LCAyMDE1LCBhdCA5OjA0IEFNLCBQZXRlciB2YW4gRGlqayA8cGV0ZXIudmFu LmRpamtAcG93ZXJkbnMuY29tPiB3cm90ZToNCj4gDQo+IEhlbGxvIEdsZW4sDQo+IA0KPiBPbiA4 IEp1bCAyMDE1LCBhdCAyMzoyOCwgV2lsZXksIEdsZW4gd3JvdGU6DQo+IA0KPj4gSG93IHdvdWxk IGZvbGtzIGZlZWwgYWJvdXQgdXBkYXRpbmcgdGhlIFNNSU1FQSBkcmFmdCB0byB1c2UgbGFuZ3Vh Z2Ugc2ltaWxhciB0byBzZWN0aW9uIDMgaW4gdGhlIE9QRU5QR1BLRVkgZHJhZnQ6DQo+IA0KPiBB cyBJIHVuZGVyc3RhbmQgaXQsIHRoZSBTTUlNRUEgZHJhZnQsIGFuZCAqZXNwZWNpYWxseSB0aGlz IHBhcnQqLCBpcyBvbiBob2xkIHVudGlsIHdlIGZpZ3VyZSBvdXQgd2hhdOKAmXMgcmlnaHQgZm9y IE9QRU5QR1BLRVksIGFuZCBwZXJoYXBzIGV2ZW4gZ2FpbiBzb21lIG9wZXJhdGlvbmFsIGV4cGVy aWVuY2Ugd2l0aCBpdC4gSXQgd291bGQgc2VlbSBwb2ludGxlc3MgdG8gY29weSB0aGlzIGxhbmd1 YWdlIG5vdywgZXNwZWNpYWxseSB3aXRoIHRoZSBhbW91bnQgb2YgZGlzYWdyZWVtZW50IHBlb3Bs ZSBhcmUgaGF2aW5nIHdpdGggdGhlIGxhbmd1YWdlIGFzIGl0IHN0YW5kcyBub3cg4oCUIHdlIHdv dWxkIGp1c3Qga2VlcCBjb3B5aW5nIGNoYW5nZXMsIGJldHRlciB0byBqdXN0IHdhaXQgdW50aWwg T1BFTlBHUEtFWSBoYXMgc2V0dGxlZCBkb3duLg0KDQpUbyBiZSBmYWlyLCBJIHRoaW5rIEkgY291 bnRlZCBhYm91dCAxMCBwZW9wbGUgb24gdGhlIGxpc3Qgd2hvIHVyZ2VkIHRvIHByb2NlZWQgd2l0 aCB0aGUgU01JTUVBIGRyYWZ0LiAgSW4gdGhpcyBjYXNlLCBJIHRoaW5rIHRoZSBwZXJmZWN0IGlz IHRoZSBlbmVteSBvZiB0aGUgZ29vZC4NCg0KRXJpYw== From nobody Fri Jul 10 06:14:55 2015 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 0A4041AC3B9 for ; Fri, 10 Jul 2015 06:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MANGLED_TEXT=2.3, 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 TLikS27M41DS for ; Fri, 10 Jul 2015 06:14:45 -0700 (PDT) Received: from smtp124.iad3a.emailsrvr.com (smtp124.iad3a.emailsrvr.com [173.203.187.124]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0BBD1AC3B8 for ; Fri, 10 Jul 2015 06:14:44 -0700 (PDT) Received: from smtp8.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp8.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id D868C380625; Fri, 10 Jul 2015 09:14:43 -0400 (EDT) Received: by smtp8.relay.iad3a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 8E57938053C; Fri, 10 Jul 2015 09:14:43 -0400 (EDT) X-Sender-Id: ogud@ogud.com Received: from [10.20.30.43] (pool-74-96-96-235.washdc.fios.verizon.net [74.96.96.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.4.2); Fri, 10 Jul 2015 13:14:43 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_A7BE13BB-6D41-4C45-8728-298FE932D291" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Olafur Gudmundsson In-Reply-To: Date: Fri, 10 Jul 2015 09:14:42 -0400 Message-Id: <9F25199B-FF44-49EB-BB0F-E4945C093D27@ogud.com> References: To: "Wiley, Glen" X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "dane@ietf.org" Subject: Re: [dane] SMIMEA, record locating as in OPENPGPKEY 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 Jul 2015 13:14:47 -0000 --Apple-Mail=_A7BE13BB-6D41-4C45-8728-298FE932D291 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Glen thank you for bringing this up.=20 > On Jul 8, 2015, at 5:28 PM, Wiley, Glen wrote: >=20 > How would folks feel about updating the SMIMEA draft to use language = similar to section 3 in the OPENPGPKEY draft: >=20 > Location of the OPENPGPKEY record >=20 > The DNS does not allow the use of all characters that are supported > in the "local-part" of email addresses as defined in [RFC2822 = ] and > [RFC6530 ]. Therefore, email = addresses are mapped into DNS using the > following method: >=20 > o The user name (the "left-hand side" of the email address, called > the "local-part" in the mail message format definition [RFC2822 = ] > and the "local part" in the specification for internationalized >=20 >=20 >=20 > Wouters Expires October 03, 2015 [Page = 4] > > Internet-Draft DANE for OpenPGP public keys April = 2015 >=20 >=20 > email [RFC6530 ]) should = already be encoded in UTF-8 (or its subset > ASCII). If it is written in another encoding it should be > converted to UTF-8. Next, it is turned into lowercase and = hashed > using the SHA2-256 [RFC5754 = ] algorithm, with the hash = truncated to > 28 octets and represented in its hexadecimal representation, to > become the left-most label in the prepared domain name. > Truncation comes from the right-most octets. This does not > include the at symbol ("@") that separates the left and right > sides of the email address. >=20 > o The string "_openpgpkey" becomes the second left-most label in = the > prepared domain name. So are you proposing that SMIME use the same label as OPENPGP for = looking for records ?=20 If yes then I=E2=80=99m with you, and I would even be willing = to go one step further and rename the label to _emailkey (or something = similar) >=20 > o The domain name (the "right-hand side" of the email address, > called the "domain" in RFC 2822 = ) is appended to the result of step > 2 to complete the prepared domain name. >=20 > For example, to request an OPENPGPKEY resource record for a user > whose email address is "hugh@example.com", an OPENPGPKEY query = would > be placed for the following QNAME: = "c93f1e400f26708f98cb19d936620da35 > eec8f72e57f9eec01c1afd6._openpgpkey.example.com". The = corresponding > RR in the example.com zone might look like (key shortened for > formatting): >=20 > c9[..]d6._openpgpkey.example.com. IN OPENPGPKEY >=20 >=20 > 3.1 = . = Email address variants >=20 > Mail systems usually handle variant forms of local-parts. The most > common variants are upper and lower case, which are now invariably > treated as equivalent. But many other variants are possible. Some > systems allow and ignore "noise" characters such as dots, so local > parts johnsmith and John.Smith would be equivalent. Many systems > allow "extensions" such as john-ext or mary+ext where john or mary = is > treated as the effective local-part, and the ext is passed to the > recipient for further handling. This can complicate finding the > OPENPGPKEY record associated with the dynamically created email > address. >=20 > [RFC5321 <>] and its predecessors have always made it clear that = only > the recipient MTA is allowed to interpret the local-part of an > address. A client supporting OPENPGPKEY therefor MUST NOT perform > any kind of mapping rules based on the email address. As the = local- > part is converted to lowercase before hashing, case sensitivity = will > not cause problems for the OPENPGPKEY lookup. > =E2=80=94=20 If you are willing to use the same DNS location to store SMIMEA keys = then the text in SMIME becomes even simpler =E2=80=9CSee RFC-openpgpkey[ref] for how to look up SMIMEA =E2=80=9C =20 In that case I see no reason to hold up the SMIME draft Olafur Olafur --Apple-Mail=_A7BE13BB-6D41-4C45-8728-298FE932D291 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Glen
thank you for bringing this = up. 

On = Jul 8, 2015, at 5:28 PM, Wiley, Glen <gwiley@verisign.com>= wrote:

How would folks feel about updating the SMIMEA draft to = use language similar to section 3 in the OPENPGPKEY draft:

 Location of the OPENPGPKEY =
record


   The DNS does not allow the use of all characters that are supported
   in the "local-part" of email addresses as defined in [RFC2822] and
   [RFC6530].  Therefore, email addresses are mapped into DNS =
using the
   following method:

   o  The user name (the "left-hand side" of the email address, called
      the "local-part" in the mail message format definition [RFC2822]
      and the "local part" in the specification for internationalized



Wouters        =
         Expires October 03, 2015                [Page 4]
 
Internet-Draft =
       DANE for OpenPGP public keys            April 2015


      email [RFC6530]) should already be encoded in UTF-8 (or its =
subset
      ASCII).  If it is written in another encoding it should be
      converted to UTF-8.  Next, it is turned into lowercase and hashed
      using the SHA2-256 [RFC5754] algorithm, with the hash truncated =
to
      28 octets and represented in its hexadecimal representation, to
      become the left-most label in the prepared domain name.
      Truncation comes from the right-most octets.  This does not
      include the at symbol ("@") that separates the left and right
      sides of the email address.

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

So are = you proposing that SMIME use the same label as OPENPGP for looking for = records ? 
<no-hat> If yes then I=E2=80=99m with = you, and I would even be willing to go one step further and rename the = label to  _emailkey (or something similar) = </no-hat>

   o  The domain name (the "right-hand side" of the email address,
      called the "domain" in RFC 2822) is =
appended to the result of step
      2 to complete the prepared domain name.

   For example, to request an OPENPGPKEY resource record for a user
   whose email address is "hugh@example.com", an OPENPGPKEY query would
   be placed for the following QNAME: "c93f1e400f26708f98cb19d936620da35
   eec8f72e57f9eec01c1afd6._openpgpkey.example.com".  The corresponding
   RR in the example.com =
zone might look like (key shortened for
   formatting):

   c9[..]d6._openpgpkey.example.com. IN OPENPGPKEY <base64 public =
key>



3.1.  Email address =
variants


   Mail systems usually handle variant forms of local-parts.  The most
   common variants are upper and lower case, which are now invariably
   treated as equivalent.  But many other variants are possible.  Some
   systems allow and ignore "noise" characters such as dots, so local
   parts johnsmith and John.Smith would be equivalent.  Many systems
   allow "extensions" such as john-ext or mary+ext where john or mary is
   treated as the effective local-part, and the ext is passed to the
   recipient for further handling.  This can complicate finding the
   OPENPGPKEY record associated with the dynamically created email
   address.

   [RFC5321] =
and its predecessors have always made it clear that only
   the recipient MTA is allowed to interpret the local-part of an
   address.  A client supporting OPENPGPKEY therefor MUST NOT perform
   any kind of mapping rules based on the email address.  As the local-
   part is converted to lowercase before hashing, case sensitivity will
   not cause problems for the OPENPGPKEY lookup.
=E2=80=94 

If you = are willing to use the same DNS location to store SMIMEA keys then the = text in SMIME becomes even simpler
=E2=80=9CSee = RFC-openpgpkey[ref] for how to look up SMIMEA =E2=80=9C

<hat=3Dchair> 
In that case I = see no reason to hold up the SMIME = draft
</hat=3Dchair>

   Olafur

Olafur

= --Apple-Mail=_A7BE13BB-6D41-4C45-8728-298FE932D291-- From nobody Fri Jul 10 06:28:22 2015 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 4EE841A8F51 for ; Fri, 10 Jul 2015 06:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.838 X-Spam-Level: X-Spam-Status: No, score=0.838 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35, J_CHICKENPOX_47=0.6, 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 zzFHw5ckIX1k for ; Fri, 10 Jul 2015 06:28:18 -0700 (PDT) Received: from mail.sys4.de (mail.sys4.de [IPv6:2001:1578:400:111::7]) (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 97A8B1A8F4D for ; Fri, 10 Jul 2015 06:28:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sys4.de; h= in-reply-to:content-disposition:content-type:content-type :mime-version:references:message-id:subject:subject:from:from :date:date; s=mail201310; t=1436534895; x=1438349296; bh=5Q2m6e9 PQ5UzuUy15r9YwL3o+oU4kOtovuOwkHbOWo0=; b=cej/jiTFRUJs4eIt0YSeA2+ uhflHqAoScaA/5UdiAZI4e/raw/gVPOchS3wGXVMUi8SJlVg82ExMlXLfno37l+O n4/nDrDlyDvWo5UWcDsLXP1fhou4Al9T6dQesBGQzAYhlqpNxCsEYPZ7qRR6g4e1 omdf8IueNussiwNPbjszA1KaqvVYyheKWiUgC4Y4fWPRqra5MHg/SzKeEIfbvrjw w9zPd21dc03mD8j5kPC9zcGop3LJPDecRWRYn1dXSD0aM2up8SnE21UE1L484kN1 nf5pShx1f3T4ZuMfpOEGNdf+OMQOHJ6hKgSWK8pNvSoycE30F9vRGGkmlK043Vw= = X-Virus-Scanned: Debian amavisd-new at mail.sys4.de Received: from sys4.de (mail.sys4.de [194.126.158.139]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sys4.de (Postfix) with ESMTPSA id 3mSZv335Hyz86 for ; Fri, 10 Jul 2015 15:28:15 +0200 (CEST) Date: Fri, 10 Jul 2015 15:28:14 +0200 From: Florian Kirstein To: dane@ietf.org Message-ID: <20150710132814.GA18811@sys4.de> References: <2A56BF41-3B75-48E1-930D-3A3C43E3385A@powerdns.com> <84E597D7-932E-4E25-B97C-FF84267F3891@verisign.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <84E597D7-932E-4E25-B97C-FF84267F3891@verisign.com> Archived-At: Subject: Re: [dane] SMIMEA, record locating as in OPENPGPKEY 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 Jul 2015 13:28:20 -0000 Hi, > To be fair, I think I counted about 10 people on the list who urged to proceed with the SMIMEA draft. In this case, I think the perfect is the enemy of the good. I would count myself as 11th there, but those people voted against delaying SMIMEA for another year, not for pushing without discussions. There indeed are quite some points in heavy discussion about the localpart lookup mechanism and I am pretty sure there will be an update to the OPENPGPKEY draft in this respect soon. I would wait with updating the SMIMEA draft in this respect until that point. Of course the option Olafur just mentioned, simply referencing the OPENPGPKEY standard there, also would be OK. But copy&pasting the current, possibly soon-to-be changed version, no. The more important point to advance the draft is the assignment of a RRtype. Viktor pointet out that a requirement for that is the settling on the RRDATA format. This is different for SMIMEA (more like TLSA than OPENPGPKEY) so the question would be: does anybody see any problems on that side, or can we consider that agreed? Greetings, Florian -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstrasse 15, 81669 Muenchen Sitz der Gesellschaft: Muenchen, Amtsgericht Muenchen: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein From nobody Sat Jul 11 09:43:54 2015 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 34F4A1A9005; Sat, 11 Jul 2015 09:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 BDphNiOW59vO; Sat, 11 Jul 2015 09:43:50 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5090D1A9004; Sat, 11 Jul 2015 09:43:50 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 2880E284D6A; Sat, 11 Jul 2015 16:43:49 +0000 (UTC) Date: Sat, 11 Jul 2015 16:43:49 +0000 From: Viktor Dukhovni To: Tina TSOU Message-ID: <20150711164349.GP28047@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: Cc: "draft-ietf-dane-ops.all@tools.ietf.org" , IETF Security Directorate , "iesg@ietf.org" , dane@ietf.org Subject: Re: [dane] SecDir Review of draft-ietf-dane-ops-12 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 Jul 2015 16:43:52 -0000 > * Meta: I would have liked to find (if anything, in an appendix) the > rationale for he changes being proposed by this document. Since the changes > are said to originate on operational experience, I think that codifying > the lessons (problems found, and a rationale for the workarounds). There > seems to be a bit of this throughout the document, but not for most of > the changes proposed. I'll reread the draft and see where additional rationale text might usefully be added. Specific pointers to such places, if anyone has any in mind, would be great. > * Section 4.8, page 8: > > Therefore, when a TLS client > > authenticates the TLS server via a TLSA record with usage DANE-EE(3), > > CT checks SHOULD NOT be performed. > > What are the valid reasons for performing th CT checks? If there are not > any, why not make this requirement a "MUST NOT" instead? CT checks are designed to help keep public CAs honest (detect surreptitiously misissued certificates). With DANE-EE(3), no public CA is involved, so CT (for the X.509 WebPKI) is logically out of scope. If there is some day a CT for DNSSEC (or just DANE records validated via DNSSEC), then this new CT might be applicable to keep registries from signing rogue DS RRs, rogue evidence of non-existence of DS RRs or rogue absense of delegation of a domain. The present the experimental CT does not apply to DNSSEC. Also see changes in the CT language in -13. > * Section 5.1, page 10: > > Servers SHOULD NOT rely on > > "DANE-EE(3) Cert(0) Full(0)" TLSA records to publish authentication > > data for raw public keys. I am open to MUST NOT, if that's better. Note that the impact of such inadvisable reliance, is that some clients capable of using raw public keys (but also capable of handling certificate chains) might choose to not do so. And other clients, that support only raw public keys, might go the extra mile and support extracing the public key from a "3 0 0" record, assuming they can parse X.509 certificates (part of the rationale for RPK is to allow clients to shed such code). So using "3 0 0" reduces opportunities to use RPK, and might fail to interoperate with RPK-only DANE clients that don't go the extra mile to support "3 0 0" (e.g. they may lack code to parse X.509 certificates). Is that enough reason to say "MUST NOT rely"? Is 2119 language appropriate here, we're not telling servers to not publish "3 0 0", rather we're telling them that if they do, they can't (must not) expect RPK to work. Is "MUST NOT rely" or "SHOULD NOT rely" a suitable means to say that, or should this be downcased to non-normative english text? > * Section 7, page 17: > > > Though CNAMEs are illegal on the right hand side of most indirection > > records, such as MX and SRV records, they are supported by some > > implementations. For example, if the MX or SRV host is a CNAME > > alias, some implementations may "chase" the CNAME. If they do, they > > SHOULD use the target hostname as the preferred TLSA base domain as > > described above (and if the TLSA records are found there, use the > > CNAME expanded domain also in SNI and certificate name checks). > > If CNAMES on the right hand side of most indirection records are illegal, > why trying to process them in the first place? Because this "illegal" configuration is both widely supported, and actually practiced, sometimes by accident. There are a lot of domains with boiler-plate records configured by naive registrars or users along the lines of: example.com. IN A 192.0.2.1 example.com. IN MX 0 mail.example.com. ; Note, no explicit mail.example.com RRsets *.example.com IN CNAME example.com. What this amounts to is that that the MX host for example.com is mail.example.com which is in turn a CNAME right back to example.com. Most MTAs seem to support this, RFCs notwithstanding. So the draft explains what to do when such records are supported. (A concession to the fact that MX hosts that are CNAMES are illegal in theory, but not in practice). > * Section 9, page 21: > > This order SHOULD be configurable by the MTA > > administrator. > > Please expand "MTA". Also, why make the explanation mail-specific? Fixed in -13. > * Section 13, page 26: > > The signature validity period for TLSA records should also not be too > > long. Signed DNSSEC records can be replayed by an MiTM attacker > > provided the signatures have not yet expired. > > Please expand "MiTM". This was done in the introduction, but I notice a case difference (MiTM vs MITM). This should probably be made consistent in the final version. Queued for -14. > Section 1.1, Page 4: > > difficult to host multiple Customer Domains at the same IP- > > addressed based TLS service endpoint (i.e., "secure virtual > > hosting"). > > s/addressed based/address-based/ Thanks, queued for -14. > * Section 5.1, page 9: > > > With DANE-EE(3) servers that know all the connecting clients are > > making use of DANE, they need not employ SNI > > I'm having trouble parsing this sentence... could you please take a look and tweak it if necessary? This was changed in -13: If a server uses just DANE-EE(3) TLSA records, and all its clients are DANE clients, the server need not employ SNI (i.e., they may ignore the client's SNI message) even when the server is known via multiple domain names that would otherwise require separate certificates. I notice a singular/plural mismatch above, so in -14 I've queued-up s/they may/it may/. Is the final result better? -- Viktor. From nobody Sun Jul 12 19:54:21 2015 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 CF0921ACD80; Sun, 12 Jul 2015 19:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.69 X-Spam-Level: X-Spam-Status: No, score=0.69 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 AizfT2seN91C; Sun, 12 Jul 2015 19:54:14 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8553D1ACD7B; Sun, 12 Jul 2015 19:54:14 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mV8h363c5z1H8; Mon, 13 Jul 2015 04:54:11 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=CBca+BIO X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id h2FJR7k9N15E; Mon, 13 Jul 2015 04:54:10 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 13 Jul 2015 04:54:10 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 132F780042; Sun, 12 Jul 2015 22:54:09 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1436756049; bh=KoykGpZ+3auXyfoF/MTusWD5vv79qjP1tVtmRETvXaU=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=CBca+BIOztBym8h6MSJqYz3z6tz9ONqOX3APTGKajBQQ2/TprXO7kB559NTmR4zxH ePXNeuBqbX1HZzawMy+ENau3i9o111weLwEd0tJ0bwaZSlysXVZAm0OqIcyVcmS/di gSAzsM5CzUUgISdzsW2/8F5bKm5gaCQ8ZlZWFC2Y= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t6D2s7Ya012828; Sun, 12 Jul 2015 22:54:08 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sun, 12 Jul 2015 22:54:07 -0400 (EDT) From: Paul Wouters To: Viktor Dukhovni In-Reply-To: <20150711164349.GP28047@mournblade.imrryr.org> Message-ID: References: <20150711164349.GP28047@mournblade.imrryr.org> User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "draft-ietf-dane-ops.all@tools.ietf.org" , IETF Security Directorate , "iesg@ietf.org" , dane@ietf.org, Tina TSOU Subject: Re: [dane] SecDir Review of draft-ietf-dane-ops-12 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, 13 Jul 2015 02:54:17 -0000 On Sat, 11 Jul 2015, Viktor Dukhovni wrote: >> * Section 4.8, page 8: >>> Therefore, when a TLS client >>> authenticates the TLS server via a TLSA record with usage DANE-EE(3), >>> CT checks SHOULD NOT be performed. >> >> What are the valid reasons for performing th CT checks? If there are not >> any, why not make this requirement a "MUST NOT" instead? CT auditors log EE-certs. Checking the CT logs also provides a way to signal rogue EE-certs to the original webserver via a gossip/client protocol. So I would not say Usage 3 should never check the CT logs. > CT checks are designed to help keep public CAs honest (detect > surreptitiously misissued certificates). It's a litte more than just that: Certificate transparency aims to mitigate the problem of misissued certificates by providing publicly auditable, append-only, untrusted logs of all issued certificates. The logs are publicly auditable so that it is possible for anyone to verify the correctness of each log and to monitor when new certificates are added to it. > With DANE-EE(3), no public > CA is involved, so CT (for the X.509 WebPKI) is logically out of > scope. I don't think that whether or not public/private CA's are in used in the TLSA record matters. A client that wants to confirm an EE-cert via DNSSEC _and_ CT should be able to do so. >> * Section 5.1, page 10: >>> Servers SHOULD NOT rely on >>> "DANE-EE(3) Cert(0) Full(0)" TLSA records to publish authentication >>> data for raw public keys. > > I am open to MUST NOT, if that's better. > > Note that the impact of such inadvisable reliance, is that some > clients capable of using raw public keys (but also capable of > handling certificate chains) might choose to not do so. And other > clients, that support only raw public keys, might go the extra mile > and support extracing the public key from a "3 0 0" record, assuming > they can parse X.509 certificates (part of the rationale for RPK > is to allow clients to shed such code). You keep trying to force different policies for raw public keys versus (possibly throw away) x509 container based public keys. Because we know software will only upgrade over a very long slow time, we know there is going to be a substantial amount of time when "basically" raw keys will go into a throw-away x509 container. Therefor, as I said before, it is not wise to differentiate between the two. An EE-cert could be a raw public key in disguise purely for compatibility reasons. > So using "3 0 0" reduces opportunities to use RPK, and might fail > to interoperate with RPK-only DANE clients that don't go the extra > mile to support "3 0 0" (e.g. they may lack code to parse X.509 > certificates). Is that enough reason to say "MUST NOT rely"? > > Is 2119 language appropriate here, we're not telling servers to > not publish "3 0 0", rather we're telling them that if they do, > they can't (must not) expect RPK to work. Is "MUST NOT rely" > or "SHOULD NOT rely" a suitable means to say that, or should > this be downcased to non-normative english text? No, I think you should not try to dictate the local policy behaviour. > This was changed in -13: > > If a server uses just DANE-EE(3) TLSA records, and all its clients > are DANE clients, the server need not employ SNI (i.e., they may > ignore the client's SNI message) even when the server is known via > multiple domain names that would otherwise require separate > certificates. I am confused. If DANE is only talking about how to verify a certain certificate received over TLS, I do not think this document should modify the TLS protocol with respect to SNI. It's out of scope. Paul From nobody Sun Jul 12 20:19:15 2015 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 8F2BF1A0282 for ; Sun, 12 Jul 2015 20:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 fpl6Z9nZffxr for ; Sun, 12 Jul 2015 20:19:11 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE4071A0275 for ; Sun, 12 Jul 2015 20:19:11 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 8187E284D6A; Mon, 13 Jul 2015 03:19:10 +0000 (UTC) Date: Mon, 13 Jul 2015 03:19:10 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150713031910.GH28047@mournblade.imrryr.org> References: <20150711164349.GP28047@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: Subject: Re: [dane] SecDir Review of draft-ietf-dane-ops-12 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, 13 Jul 2015 03:19:13 -0000 On Sun, Jul 12, 2015 at 10:54:07PM -0400, Paul Wouters wrote: > >>What are the valid reasons for performing th CT checks? If there are not > >>any, why not make this requirement a "MUST NOT" instead? > > CT auditors log EE-certs. Checking the CT logs also provides a way to > signal rogue EE-certs to the original webserver via a gossip/client > protocol. So I would not say Usage 3 should never check the CT logs. DANE-EE(3) certs are often self-signed, and there's no way to control the "spam" problem on the CT logs with DANE-EE(3). Furthermore such a certificate is only ever "rogue" if DNSSEC is compromised to publish rogue TLSA RRs. So the "CA" we're keeping honest is the zone signing the TLSA RRset. I don't believe we have a CT specification for that yet. > >CT checks are designed to help keep public CAs honest (detect > >surreptitiously misissued certificates). > > It's a litte more than just that: > > Certificate transparency aims to mitigate the problem of misissued > certificates by providing publicly auditable, append-only, untrusted > logs of all issued certificates. The logs are publicly auditable so > that it is possible for anyone to verify the correctness of each log > and to monitor when new certificates are added to it. Well, with DANE-EE(3) there is no X.509 trusted issuer to keep honest. With "3 1 1" an attacker can replace anything in the certificate other than the public key, giving an astronomical number of potential certificates to that match the TLSA RRset and might be logged. It makes no sense to log the "certificate" it is just excess baggage. The TLSA RRset, with DS/DNSKEY/RRSIG records all the way back to the root ZONE make a lot more sense here, but there is no CT spec for that I am aware of. > > With DANE-EE(3), no public > >CA is involved, so CT (for the X.509 WebPKI) is logically out of > >scope. > > I don't think that whether or not public/private CA's are in used in > the TLSA record matters. A client that wants to confirm an EE-cert > via DNSSEC _and_ CT should be able to do so. Perhaps if it were possible, but I am afraid it is not. > >So using "3 0 0" reduces opportunities to use RPK, and might fail > >to interoperate with RPK-only DANE clients that don't go the extra > >mile to support "3 0 0" (e.g. they may lack code to parse X.509 > >certificates). Is that enough reason to say "MUST NOT rely"? > > > >Is 2119 language appropriate here, we're not telling servers to > >not publish "3 0 0", rather we're telling them that if they do, > >they can't (must not) expect RPK to work. Is "MUST NOT rely" > >or "SHOULD NOT rely" a suitable means to say that, or should > >this be downcased to non-normative english text? > > No, I think you should not try to dictate the local policy behaviour. You're misreading the text. It is warning server operators that "3 0 0" is less suitable for serving RPK clients (if that's what the server wants) than "3 1 X" is. This is true, because clients that want to deal with just keys would have to support extracing those from a "3 0 0" RRset, where-as with "3 1 X" the key or its digest is right there. Thus no local policy is dictated, rather server operators are advised to be conservative in what they send. > >This was changed in -13: > > > > If a server uses just DANE-EE(3) TLSA records, and all its clients > > are DANE clients, the server need not employ SNI (i.e., they may > > ignore the client's SNI message) even when the server is known via > > multiple domain names that would otherwise require separate > > certificates. > > I am confused. If DANE is only talking about how to verify a certain > certificate received over TLS, I do not think this document should > modify the TLS protocol with respect to SNI. It's out of scope. You're confused. The server is free to ignore the client's SNI extension when it has a single certificate that works for all hosted domains, because clients authenticate the server via the certificate or key digest, and don't care about what name is in the certificate. We're not modifying TLS, we're explaining that the server is free to ignore the client's SNI extension. -- Viktor. From nobody Sun Jul 12 20:29:58 2015 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 220E71A0358; Sun, 12 Jul 2015 20:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 TyWCCogufohP; Sun, 12 Jul 2015 20:29:52 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEAF51A0354; Sun, 12 Jul 2015 20:29:51 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id C439E284D6A; Mon, 13 Jul 2015 03:29:50 +0000 (UTC) Date: Mon, 13 Jul 2015 03:29:50 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150713032950.GI28047@mournblade.imrryr.org> References: <20150711164349.GP28047@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: Cc: IETF Security Directorate , "iesg@ietf.org" , Tina TSOU Subject: Re: [dane] SecDir Review of draft-ietf-dane-ops-12 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, 13 Jul 2015 03:29:54 -0000 On Sun, Jul 12, 2015 at 10:54:07PM -0400, Paul Wouters wrote: > >>What are the valid reasons for performing th CT checks? If there are not > >>any, why not make this requirement a "MUST NOT" instead? > > CT auditors log EE-certs. Checking the CT logs also provides a way to > signal rogue EE-certs to the original webserver via a gossip/client > protocol. So I would not say Usage 3 should never check the CT logs. DANE-EE(3) certs are often self-signed, and there's no way to control the "spam" problem on the CT logs with DANE-EE(3). Furthermore such a certificate is only ever "rogue" if DNSSEC is compromised to publish rogue TLSA RRs. So the "CA" we're keeping honest is the zone signing the TLSA RRset. I don't believe we have a CT specification for that yet. > >CT checks are designed to help keep public CAs honest (detect > >surreptitiously misissued certificates). > > It's a litte more than just that: > > Certificate transparency aims to mitigate the problem of misissued > certificates by providing publicly auditable, append-only, untrusted > logs of all issued certificates. The logs are publicly auditable so > that it is possible for anyone to verify the correctness of each log > and to monitor when new certificates are added to it. Well, with DANE-EE(3) there is no X.509 trusted issuer to keep honest. With "3 1 1" an attacker can replace anything in the certificate other than the public key, giving an astronomical number of potential certificates to that match the TLSA RRset and might be logged. It makes no sense to log the "certificate" it is just excess baggage. The TLSA RRset, with DS/DNSKEY/RRSIG records all the way back to the root ZONE make a lot more sense here, but there is no CT spec for that I am aware of. > > With DANE-EE(3), no public > >CA is involved, so CT (for the X.509 WebPKI) is logically out of > >scope. > > I don't think that whether or not public/private CA's are in used in > the TLSA record matters. A client that wants to confirm an EE-cert > via DNSSEC _and_ CT should be able to do so. Perhaps if it were possible, but I'm afraid it is not. From the CT FAQ: Each CT log will have the power to choose which CAs it accepts certificates from. This could lead to a situation where a Root Certificate is trusted by one or more browsers, but is not permitted to submit newly issued certs to any of the trusted CT logs. How can we ensure that this sort of situation doesn't happen? We recommend that all logs accept a liberal list of CAs including at least the Apple, Microsoft and Opera roots. The CA check is for anti-spam and attribution only, so we do not foresee this becoming a problem in practice. Thus CT logs will not accept self-signed, domain-issued, ... certificates. Since CT is just keeping the public CAs honest, and DANE-EE(3) or DANE-TA(2) with a private CA do not use public CAs, CT simply does not apply. > >So using "3 0 0" reduces opportunities to use RPK, and might fail > >to interoperate with RPK-only DANE clients that don't go the extra > >mile to support "3 0 0" (e.g. they may lack code to parse X.509 > >certificates). Is that enough reason to say "MUST NOT rely"? > > > >Is 2119 language appropriate here, we're not telling servers to > >not publish "3 0 0", rather we're telling them that if they do, > >they can't (must not) expect RPK to work. Is "MUST NOT rely" > >or "SHOULD NOT rely" a suitable means to say that, or should > >this be downcased to non-normative english text? > > No, I think you should not try to dictate the local policy behaviour. You're misreading the text. It is warning server operators that "3 0 0" is less suitable for serving RPK clients (if that's what the server wants) than "3 1 X" is. This is true, because clients that want to deal with just keys would have to support extracing those from a "3 0 0" RRset, where-as with "3 1 X" the key or its digest is right there. Thus no local policy is dictated, rather server operators are advised to be conservative in what they send. > >This was changed in -13: > > > > If a server uses just DANE-EE(3) TLSA records, and all its clients > > are DANE clients, the server need not employ SNI (i.e., they may > > ignore the client's SNI message) even when the server is known via > > multiple domain names that would otherwise require separate > > certificates. > > I am confused. If DANE is only talking about how to verify a certain > certificate received over TLS, I do not think this document should > modify the TLS protocol with respect to SNI. It's out of scope. You're confused. The server is free to ignore the client's SNI extension when it has a single certificate that works for all hosted domains, because clients authenticate the server via the certificate or key digest, and don't care about what name is in the certificate. We're not modifying TLS, we're explaining that the server is free to ignore the client's SNI extension. -- Viktor. From nobody Sun Jul 12 20:37:19 2015 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 366521A036C; Sun, 12 Jul 2015 20:37:13 -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 QhMSrGZKdNio; Sun, 12 Jul 2015 20:37:12 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A64E11A036B; Sun, 12 Jul 2015 20:37:11 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mV9dd49G7z20h; Mon, 13 Jul 2015 05:37:09 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=R21MlG5w X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id cQc7989KHoBK; Mon, 13 Jul 2015 05:37:08 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 13 Jul 2015 05:37:08 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id C2BB1800EF; Sun, 12 Jul 2015 23:37:07 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1436758627; bh=wmp/36CtovY312LYOcFNVmQzhyvMqdwOPwgr/mPFxdA=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=R21MlG5wolAnJKO+w9x1l/oztwImaLZlCKWHTvom/UZVXamVbmhQ3haK0IlPvpzGF SU9g09p8OMCSI+ae/ca0h43XzHGEyg02afnGfRhvon1J+V0HM6ezJgBwMpBIN0G6DS piv3KQZ2n/nDd69u61cb/eTciofY9iRiRtT1UFjQ= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t6D3b7MH014969; Sun, 12 Jul 2015 23:37:07 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sun, 12 Jul 2015 23:37:07 -0400 (EDT) From: Paul Wouters To: dane@ietf.org In-Reply-To: <20150713032950.GI28047@mournblade.imrryr.org> Message-ID: References: <20150711164349.GP28047@mournblade.imrryr.org> <20150713032950.GI28047@mournblade.imrryr.org> User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: Tina TSOU , "iesg@ietf.org" , IETF Security Directorate Subject: Re: [dane] SecDir Review of draft-ietf-dane-ops-12 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, 13 Jul 2015 03:37:13 -0000 On Mon, 13 Jul 2015, Viktor Dukhovni wrote: >> CT auditors log EE-certs. Checking the CT logs also provides a way to >> signal rogue EE-certs to the original webserver via a gossip/client >> protocol. So I would not say Usage 3 should never check the CT logs. > > DANE-EE(3) certs are often self-signed, and there's no way to > control the "spam" problem on the CT logs with DANE-EE(3). You don't know what audit logs will use for policies. Perhaps some audit logs will be dedicated to only self-signed certs. I do not think the dane document should dictate CT behaviour. > Furthermore such a certificate is only ever "rogue" if DNSSEC is > compromised to publish rogue TLSA RRs. Not if they use a CT log for prepublishing somehow. Although that is unlikely to happen with SCT's without a CA, I still think you should not make those decisions on this document. >> I don't think that whether or not public/private CA's are in used in >> the TLSA record matters. A client that wants to confirm an EE-cert >> via DNSSEC _and_ CT should be able to do so. > > Perhaps if it were possible, but I'm afraid it is not. From the > CT FAQ: > Thus CT logs will not accept self-signed, domain-issued, ... The CT FAQ is not an IETF document. > You're misreading the text. It is warning server operators that > "3 0 0" is less suitable for serving RPK clients (if that's what We disagree on the concept of "RPK" clients. >> I am confused. If DANE is only talking about how to verify a certain >> certificate received over TLS, I do not think this document should >> modify the TLS protocol with respect to SNI. It's out of scope. > > You're confused. The server is free to ignore the client's SNI > extension when it has a single certificate that works for all hosted > domains, because clients authenticate the server via the certificate > or key digest, and don't care about what name is in the certificate. > We're not modifying TLS, we're explaining that the server is free > to ignore the client's SNI extension. How is that not modifying TLS server behaviour? Paul From nobody Sun Jul 12 21:01:07 2015 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 0132F1A1A0C; Sun, 12 Jul 2015 21:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 avyQhruVr6pw; Sun, 12 Jul 2015 21:01:00 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C7831A19E4; Sun, 12 Jul 2015 21:01:00 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 2E0A4284D6A; Mon, 13 Jul 2015 04:00:59 +0000 (UTC) Date: Mon, 13 Jul 2015 04:00:59 +0000 From: Viktor Dukhovni To: Paul Wouters Message-ID: <20150713040058.GJ28047@mournblade.imrryr.org> References: <20150711164349.GP28047@mournblade.imrryr.org> <20150713032950.GI28047@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: Cc: IETF Security Directorate , Tina TSOU , "iesg@ietf.org" , dane@ietf.org Subject: Re: [dane] SecDir Review of draft-ietf-dane-ops-12 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, 13 Jul 2015 04:01:02 -0000 On Sun, Jul 12, 2015 at 11:37:07PM -0400, Paul Wouters wrote: > >DANE-EE(3) certs are often self-signed, and there's no way to > >control the "spam" problem on the CT logs with DANE-EE(3). > > You don't know what audit logs will use for policies. Perhaps some > audit logs will be dedicated to only self-signed certs. I do not > think the dane document should dictate CT behaviour. The problem is that the CT documents are otherwise liable to dictate DANE behaviour. For example, require SCTs in DANE-EE validated certs. That would be unfortunate. This document notes that the present experimental CT in RFC 6962 is inapplicable to DANE. CT logs that record leaf certificates would be essentially useless, A rogue TLSA RRset with a "3 1 1" binding will work regardless of the certificate content, just based on the public key. A misissued TLSA RRset will bind a certificate that contains no information as to which domain was compromised. Here's a certificate with an empty subject and issuer name, what will the CT log make of that? -----BEGIN CERTIFICATE----- MIIBRjCB7aADAgECAgkAleIk6aMkXRwwCgYIKoZIzj0EAwIwADAeFw0xNTA3MTMw MzUwNTlaFw0xNTA4MTIwMzUwNTlaMAAwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNC AAR50eOHUyMeHOMJNZTIXuj4QBJRbQrOLbYIftmZwzatO3/rG5BRyuUIfTQnzAq5 3K7A1pfq4hfseiOfT6prKKIVo1AwTjAdBgNVHQ4EFgQU7GD7zL/aLrBUaQIIKksc cc6or+0wHwYDVR0jBBgwFoAU7GD7zL/aLrBUaQIIKksccc6or+0wDAYDVR0TBAUw AwEB/zAKBggqhkjOPQQDAgNIADBFAiBr51OuJXf8N4Z79rStIXCIuYm6drChz39G RBWvumsuhgIhANoW5K3bSqIFpIp2aXzH2PiiSgxnC3T9Mp5O70tXGS4L -----END CERTIFICATE----- And yet it will match _25._tcp.smtp.example.com. IN TLSA 3 1 1 20041CBFD6570C48ACD8D526572137B9090E8037D115FB3C21218D9E9992A9C2 The *only* way to do CT for DANE TLSA is to do CT for DNS, and there is no CT for DNS in RFC 6962. > >Furthermore such a certificate is only ever "rogue" if DNSSEC is > >compromised to publish rogue TLSA RRs. > > Not if they use a CT log for prepublishing somehow. Although that is > unlikely to happen with SCT's without a CA, I still think you should > not make those decisions on this document. It is not a policy decision, it is just logic. The impossible cannot be done. > >You're confused. The server is free to ignore the client's SNI > >extension when it has a single certificate that works for all hosted > >domains, because clients authenticate the server via the certificate > >or key digest, and don't care about what name is in the certificate. > >We're not modifying TLS, we're explaining that the server is free > >to ignore the client's SNI extension. > > How is that not modifying TLS server behaviour? It is not modifying the TLS protocol, servers are already free to ignore SNI and return whatever certificate chain they please. This document explains that with DANE-EE(3) this yields results that are satisfactory to the client. As for modifying TLS, we're for example mandating the transmission of self-signed roots with DANE-TA(2), and that too is within the realm of what TLS can do, we're just defining a behaviour profile that makes DANE-TA(2) work (it does not otherwise). -- Viktor. From nobody Mon Jul 13 15:10:38 2015 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 EE6321A6F30 for ; Mon, 13 Jul 2015 15:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 vH5W52osW4Dx for ; Mon, 13 Jul 2015 15:10:35 -0700 (PDT) Received: from mail-oi0-f97.google.com (mail-oi0-f97.google.com [209.85.218.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5BCC1A6F2F for ; Mon, 13 Jul 2015 15:10:34 -0700 (PDT) Received: by oizz3 with SMTP id z3so6122833oiz.3 for ; Mon, 13 Jul 2015 15:10:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :user-agent:content-type:content-id:content-transfer-encoding :mime-version; bh=tXaPEE+eXlLi+9u/ClI5q2GsTFj4cq3e9n/AKrfn+So=; b=XbEC700+ykv5mXHHLeVrqpUGiv9nTlz9osztOrR6WCcZF+jKku8sY3BZR/mOaZzzEq EqWro1E5ZZLrmhnCIVTvEsYafBTZxUSIxT5y9VeAP0m8ToAnmlaxbU8EtsLMsiF4ni2d Kr70SHk3bF16zjuoTftj17K0MvtHi68G9cgySLR0SDcOv/hA3B8hy+YIlrirINyXX2Gy j8A7W+dBCwv45NzV8eeIuSVgBYfGZvjW3Enj9ZrxHKQo0hexUED7xDkzEBYxwyTB7uUA jJfZcBtU2pOmvcGQZ+YSa6ZNAKymKC3W8PftJxxmAg6PztTXLN1eLbVblw8bA86BGHVl u/QA== X-Gm-Message-State: ALoCoQkSgkwWfyWwx3UaP/w0GV2VMmSUqLNvOAcWzOFRwPNJTxwN06YdGd+FwSNfQfHuy44e013a3rytDlTtQCEu8CLaNu/bdA== X-Received: by 10.140.48.103 with SMTP id n94mr56668170qga.8.1436825434313; Mon, 13 Jul 2015 15:10:34 -0700 (PDT) Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by smtp-relay.gmail.com with ESMTPS id 31sm5837483qkz.2.2015.07.13.15.10.34 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 13 Jul 2015 15:10:34 -0700 (PDT) X-Relaying-Domain: verisign.com Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01 [10.173.152.205]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id t6DMAX6H024749 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Jul 2015 18:10:33 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Mon, 13 Jul 2015 18:10:33 -0400 From: "Wiley, Glen" To: Peter van Dijk , "dane@ietf.org" Thread-Topic: [dane] SMIMEA, record locating as in OPENPGPKEY Thread-Index: AQHQucUZQLJ74gnFAE6Y0x714gmEe53TXyAAgAae04A= Date: Mon, 13 Jul 2015 22:10:32 +0000 Message-ID: References: <2A56BF41-3B75-48E1-930D-3A3C43E3385A@powerdns.com> In-Reply-To: <2A56BF41-3B75-48E1-930D-3A3C43E3385A@powerdns.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="Windows-1252" Content-ID: <5E1D020307950C4CAC1083440D64A614@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [dane] SMIMEA, record locating as in OPENPGPKEY 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, 13 Jul 2015 22:10:37 -0000 Thanks Peter. My hope here is that we settle the question for both as quickly as we can and move forward with both drafts. The goal in mind when I suggested that is to try to nudge folks toward settling the question. I agree that we don=B9t want to =B3keep copying changes=B2. --=20 Glen Wiley Principal Engineer Verisign, Inc. (571) 230-7917 http://vbsdcon.com A5E5 E373 3C75 5B3E 2E24 6A0F DC65 2354 9946 C63A On 7/9/15, 9:04 AM, "Peter van Dijk" wrote: >Hello Glen, > >On 8 Jul 2015, at 23:28, Wiley, Glen wrote: > >> How would folks feel about updating the SMIMEA draft to use language >> similar to section 3 in the OPENPGPKEY draft: > >As I understand it, the SMIMEA draft, and *especially this part*, is on >hold until we figure out what=B9s right for OPENPGPKEY, and perhaps even >gain some operational experience with it. It would seem pointless to >copy this language now, especially with the amount of disagreement >people are having with the language as it stands now =8B we would just >keep copying changes, better to just wait until OPENPGPKEY has settled >down. > >Kind regards, >--=20 >Peter van Dijk >PowerDNS.COM BV - https://www.powerdns.com/ > >_______________________________________________ >dane mailing list >dane@ietf.org >https://www.ietf.org/mailman/listinfo/dane From gunman85@mail.com Wed Jul 15 05:41:36 2015 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 22A2B1A8AAC for ; Wed, 15 Jul 2015 05:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.074 X-Spam-Level: * X-Spam-Status: No, score=1.074 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_LOW=-0.7, 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 9_2c2Zm35Skw for ; Wed, 15 Jul 2015 05:41:35 -0700 (PDT) Received: from mout.gmx.com (mout.gmx.com [74.208.4.200]) (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 E3B3F1A8AAB for ; Wed, 15 Jul 2015 05:41:34 -0700 (PDT) Received: from [82.127.135.44] by 3capp-mailcom-lxa06.server.lan (via HTTP); Wed, 15 Jul 2015 14:41:34 +0200 MIME-Version: 1.0 Message-ID: From: "Paul Gunman" To: dane@ietf.org Content-Type: text/html; charset=UTF-8 Date: Wed, 15 Jul 2015 14:41:34 +0200 Importance: normal Sensitivity: Normal X-Priority: 3 X-Provags-ID: V03:K0:TiFWncAJ3Habr6FTLSjws4qJMwisK0kFwgp15tBowvC azkjsGxjwpOS8mysm15S/OgSsljKF2MqEUdQAk8j99yesIFQ9f 3QDOxEwAsNm6S8ljOpTHjkMIW6woBcNFkRRgmuYwpTSZS21Qwh c3uYpq5crbq792KYDTr691WKK+TuzhKoQ1T7fK+DnEU8VnYYqK q3iEg/A+ZVZw0ioKHQAIEis9Vl2J730NW3d+j1rSNPIGZ0cB4c AyNCqHvH7yGauJj4AUlJDaX0qg8ZOz55Yhf7iZjcSM6ZeYPHHo 7QsILrZbmco++lJS3Relhwswz1v X-UI-Out-Filterresults: notjunk:1;V01:K0:jO4adQgnwis=:mbJOEKYxZnbakPgxoh5qEn fETINSS4ZuhMOjjaUG+nDIOik5HWruUzsoEChiyOu/boEwxBo3d+VQ24i/21ljOzwNuegKeYX Y/gud3EETzQ52xMHJxGH08f90USSelfSauPts7A98VaU9lI+qNSDekNL1f3nimknY/TzyNdKv rIo5FACIW8MieSpx2/uBQbYOoY+lrdPlr0bDde2wh83R+EuUZe0aTt10wQd7Vuy+NiOmyMYLs 0rAl+TR8R0pGrGatFGBoeEpFLdkwtSKsO332vOJTu60IOmFLFcaXcTg0kuH/8iySZrRel3NcZ e0gpqW4av0t1TjR2Rye+s4gOAi0yYfSgJfyECkiX2PJ21hqEch0m/1qrWQ8V5ZvD1PNZGdmPE KGj+odzG1lwI7DtM8Z2+Ew4/th4eNcrdfusqOZpJ9GSDWogmEWIzrJk+kJz5GzVM5Ve7vXzjP ycVgy8ssWw== Archived-At: Subject: [dane] Any mail plugins to validate DANE? 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, 15 Jul 2015 12:44:28 -0000
Hello,
 
I would like to know if there is any mail plugins (for Thunderbird or others), except Smaug, that could allow a client to check for SMIMEA records.
Anyone have heard of something?
 
 
Regards,
 
P.
From nobody Wed Jul 15 05:46:33 2015 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 733301A8AC1 for ; Wed, 15 Jul 2015 05:46:31 -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 Kw5iLpEsGdAy for ; Wed, 15 Jul 2015 05:46:29 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 922281A8AB3 for ; Wed, 15 Jul 2015 05:46:29 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mWdkX1z3WzD4s; Wed, 15 Jul 2015 14:46:28 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=TYX7Ppsf X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id Z_SP_wZG1Sll; Wed, 15 Jul 2015 14:46:27 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 15 Jul 2015 14:46:27 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 5A36280042; Wed, 15 Jul 2015 08:46:25 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1436964385; bh=CJyNuHl41joTuQSCjEW+/PKUymMBEv9S9RoSl0GIUT0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=TYX7PpsfCeV9SCfuK5d7T0/oWXWFSmajDTNCK9ZKfOJSV0OWkgxntI7VVOtuRbhtL nuLuTosGQHzp1cJctmCmoqav1z5RGSf9Ye6kx/uHVUMEFGb4E2fX6ds2Ik1UYtM1KL Cfz/+0vRhHS2W6a1fvUHjVW03WlGmqj7ihpF5/Fo= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t6FCkONZ000990; Wed, 15 Jul 2015 08:46:24 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Wed, 15 Jul 2015 08:46:24 -0400 (EDT) From: Paul Wouters To: Paul Gunman In-Reply-To: Message-ID: References: User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Any mail plugins to validate DANE? 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, 15 Jul 2015 12:46:31 -0000 On Wed, 15 Jul 2015, Paul Gunman wrote: > I would like to know if there is any mail plugins (for Thunderbird or others), except Smaug, that could allow a > client to check for SMIMEA records. > Anyone have heard of something? openpgpkey-milter is a sendmail/postfix milter to auto-encrypt. A thunderbird plugin or enigmail patch would be great though! Paul From nobody Wed Jul 15 08:06:48 2015 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 E83331ACD57 for ; Wed, 15 Jul 2015 08:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 8UB0V-PVyWdQ for ; Wed, 15 Jul 2015 08:06:46 -0700 (PDT) Received: from mail-qg0-f100.google.com (mail-qg0-f100.google.com [209.85.192.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D6781ACD41 for ; Wed, 15 Jul 2015 08:06:29 -0700 (PDT) Received: by qgef3 with SMTP id f3so2243336qge.0 for ; Wed, 15 Jul 2015 08:06: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:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :user-agent:content-type:mime-version; bh=jammpwuR1t7oHHCraUPF9qmMiDvecWJrV9cjJYB7ZKw=; b=TD+c+nr7XMbKw1iACjnMNDC7gBs7RknH4dpdlpmJO6diP5nLOZoTfFgbZCVqwE2md0 7tgRatI3bKM3H5GATd5VyNUublac5LUqC/U8YQIjmWV3aYpWsoxZkNMG0+YgPHMQ6kXL awhQ06mXN9wGJqLaKwsfHb21HsWb2Mxs+tUhWQGxPPKrad/ChKFHAMtrxYU+oy7Rt/yR STM4cfWx5hfPNzUWeMLkg8QB4raDD6ijBjQ5pu1wHK4k7cmEfcy1cleOHnJfFk7L8vek ULmOG3641ToBW72++DTAtqsyZKLyJsPoG+FLnUMZy7w84N8ai+IoVMPt+ohlnij0kRrJ 3ghA== X-Gm-Message-State: ALoCoQmpYb+/tOaALIYXpNSAyBCUVfsicIc8eEZpNS67XbbDIm3H70hxT+4njYNu6ksaYqinBbua6vQRspUgmrXQ6igSVPcPOA== X-Received: by 10.55.33.78 with SMTP id h75mr8798796qkh.87.1436972788609; Wed, 15 Jul 2015 08:06:28 -0700 (PDT) Received: from brn1lxmailout01.verisign.com (brn1lxmailout01.verisign.com. [72.13.63.41]) by smtp-relay.gmail.com with ESMTPS id r28sm1597390qkh.0.2015.07.15.08.06.28 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 15 Jul 2015 08:06:28 -0700 (PDT) X-Relaying-Domain: verisign.com Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01 [10.173.152.205]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id t6FF6S5F022166 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 Jul 2015 11:06:28 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Wed, 15 Jul 2015 11:06:27 -0400 From: "Wiley, Glen" To: Paul Gunman , "dane@ietf.org" Thread-Topic: [dane] Any mail plugins to validate DANE? Thread-Index: AQHQvvwCD1ZQz5fJxU2NNRVNFPBqjp3coaqA Date: Wed, 15 Jul 2015 15:06:27 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [10.173.152.4] Content-Type: multipart/alternative; boundary="_000_D1CBEEFA13DBAgwileyverisigncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [dane] Any mail plugins to validate DANE? 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, 15 Jul 2015 15:06:48 -0000 --_000_D1CBEEFA13DBAgwileyverisigncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Paul, Do you have specific feedback on smaug that could be used to improve the ap= proach? -- Glen Wiley Principal Engineer Verisign, Inc. (571) 230-7917 http://vbsdcon.com A5E5 E373 3C75 5B3E 2E24 6A0F DC65 2354 9946 C63A From: Paul Gunman > Date: Wednesday, July 15, 2015 at 8:41 AM To: "dane@ietf.org" > Subject: [dane] Any mail plugins to validate DANE? Hello, I would like to know if there is any mail plugins (for Thunderbird or other= s), except Smaug, that could allow a client to check for SMIMEA records. Anyone have heard of something? Regards, P. --_000_D1CBEEFA13DBAgwileyverisigncom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Paul,

Do you have specific feedback on smaug that could be used to improve t= he approach?
-- 
Glen Wiley
Principal Engineer
Verisign, Inc.
(571) 230-7917


A5E5 E373 3C75 5B= 3E 2E24 &n= bsp;
6A0F DC65 2354 99= 46 C63A

From: Paul Gunman <gunman85@mail.com>
Date: Wednesday, July 15, 2015 at 8= :41 AM
To: "dane@ietf.org" <dane@i= etf.org>
Subject: [dane] Any mail plugins to= validate DANE?

Hello,
 
I would like to know if there is any mail plugins (for Thunderbird or = others), except Smaug, that could allow a client to check for SMIMEA record= s.
Anyone have heard of something?
 
 
Regards,
 
P.
 --_000_D1CBEEFA13DBAgwileyverisigncom_-- From jgrier@grierforensics.com Wed Jul 15 14:53:50 2015 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 1D4391B34D5 for ; Wed, 15 Jul 2015 14:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001] 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 BI-sZ4GnK0wT for ; Wed, 15 Jul 2015 14:53:48 -0700 (PDT) Received: from winters.swishmail.com (winters.swishmail.com [208.72.56.47]) (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 4782B1B34DB for ; Wed, 15 Jul 2015 14:53:47 -0700 (PDT) Received: (qmail 35193 invoked by uid 89); 15 Jul 2015 21:53:45 -0000 Received: from unknown (HELO MONKEYWRENCH) (jgrier@grierforensics.com@74.103.14.89) by winters.swishmail.com with ESMTPSA (AES256-SHA encrypted, authenticated); 15 Jul 2015 21:53:45 -0000 From: "Jonathan Grier" To: References: <55A65850.5000100@nist.gov> In-Reply-To: <55A65850.5000100@nist.gov> Date: Wed, 15 Jul 2015 17:54:02 -0400 Message-ID: <042f01d0bf48$c30eec30$492cc490$@grierforensics.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQEhSte/D0/VdaNkJf62SnEmMBSLxQI0I4B1nypZ7UA= Content-Language: en-us Archived-At: X-Mailman-Approved-At: Thu, 16 Jul 2015 00:13:42 -0700 Subject: Re: [dane] Any mail plugins to validate DANE? 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, 15 Jul 2015 21:54:26 -0000 Paul, We have a tool in prototype to do exactly that. It's at = http://dst.grierforensics.com . There's an online form at = http://dst.grierforensics.com/#/dane , and an API you can access with = any JSON REST client at http://dst.grierforensics.com/#/api . The work is still in development and has some bugs. We're planning to = release it open source once we get the most serious ones fixed. We'll = be looking for contributors, btw! Since IANA hasn't assigned an RR type yet to SMIMEA, it uses private = type TYPE65500. Jonathan Grier -------- Original Message -------- Subject: [dane] Any mail plugins to validate DANE? Date: Wed, 15 Jul 2015 14:41:34 +0200 From: Paul Gunman To: dane@ietf.org Hello, I would like to know if there is any mail plugins (for Thunderbird or others), except Smaug, that could allow a client to check for SMIMEA records. Anyone have heard of something? Regards, P. From nobody Sun Jul 19 04:01:10 2015 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 DCC821AC426 for ; Sun, 19 Jul 2015 04:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 TZ8yO7kLJsu1 for ; Sun, 19 Jul 2015 04:01:07 -0700 (PDT) Received: from mail-qg0-f99.google.com (mail-qg0-f99.google.com [209.85.192.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07DC71AC424 for ; Sun, 19 Jul 2015 04:01:06 -0700 (PDT) Received: by qgal74 with SMTP id l74so3717956qga.2 for ; Sun, 19 Jul 2015 04:01:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:accept-language:content-language:content-type:content-id :content-transfer-encoding:mime-version; bh=dqUPyrjXXgHgKIhiAectIoRaScAMOjF/65A4QmK2jQ4=; b=Gd2Lk0ywaYKnkgaLiR7NY9b1xKU/RuUoToUSVzS4sizMRBViwqaZcXVZE/C3iCmQ7R OYTCbv41ccjGRyq44A11myYLYHr/TPuGj3997nqzu7Fo08d2Jv0/q3R17R+G666hz4o2 WHPwv8vARhFPHWYH0gZc8w27f/YpEw1XJGmnzemFnZZaeJ6W8JCcV4SNtJrFAiZIBz45 /jIbjniX5BZCdrsAz2I3/3UNBEO/rar2Ked9+1j0AQyYPeKaPeu++4Z1Qcz2gd6mMiHV +pj1CaHOOrsAYOslZpQFMt0o3jkUYX8J97Q9rrn2Zoey9Yn35qPXysFQVb5u8Vz1zOih 7y4A== X-Gm-Message-State: ALoCoQm9Nda+LuvFz0dWjF67HljmG6kfL+CdrAZdSFEoWlHRSAU0FDTaR55gfVPD2OxGaJXSJCgCcSAEv27LHDvvYSm63RzClg== X-Received: by 10.140.28.97 with SMTP id 88mr11562410qgy.69.1437303666248; Sun, 19 Jul 2015 04:01:06 -0700 (PDT) Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by smtp-relay.gmail.com with ESMTPS id 93sm193765qks.4.2015.07.19.04.01.06 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 19 Jul 2015 04:01:06 -0700 (PDT) X-Relaying-Domain: verisign.com Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02 [10.173.152.206]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id t6JB15Jg032065 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 19 Jul 2015 07:01:05 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Sun, 19 Jul 2015 07:01:05 -0400 From: "Mankin, Allison" To: "dane@ietf.org" Thread-Topic: SMIMEA draft review (was: Deferal of SMIME Draft) Thread-Index: AQHQwhI0UuDZpcP/7EaS9hU71Nb0sA== Date: Sun, 19 Jul 2015 11:01:03 +0000 Message-ID: <43237F83-0909-449D-896F-389868557184@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="utf-8" Content-ID: <43BC44EDF9C1464490A1BF10D91A4414@verisign.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [dane] SMIMEA draft review (was: Deferal of SMIME Draft) 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, 19 Jul 2015 11:01:09 -0000 SeKAmXZlIGRvbmUgYSBjYXJlZnVsIHJlYWQgb2YgZHJhZnQtaWV0Zi1kYW5lLXNtaW1lLTA4LiAg SSBmaW5kIGl0IHRvIGJlIGluIHZlcnkgZ29vZCBzaGFwZSwgYW5kIG9uIHRyYWNrIGZvciBwdWJs aWNhdGlvbiBhcyBhbiBFeHBlcmltZW50YWwuDQoNCk15IHJldmlldyBzdXJmYWNlZCBhIGZldyBt aW5vciBwb2ludHMsIGVhc3kgdG8gYWRkcmVzczoNCg0KLSBUaGUgTk9URSBGT1IgRlVUVVJFIERS QUZUUyB3YXMgYWRkZWQgYWJvdXQgYSB5ZWFyIGFnbyAoaW4gdGhlIDA1IHZlcnNpb24pIGFuZCBp biBteSB2aWV3LCB0aGUgV0cgDQogIGhhcyBpbiB0aGUgaW50ZXJ2ZW5pbmcgeWVhciBmdWxmaWxs ZWQgdGhlIHJlcXVlc3Qgb2YgdGhlIG5vdGUsIHRvIGRpc2N1c3MgYWxsIHRoZSBkaXZlcnNlIHR5 cGVzIG9mIHVzYWdlIG9mIERBTkUuDQoNCi0gSSBzdXBwb3J0IG1vZGlmeWluZyB0aGUgZHJhZnQg dG8gZm9sbG93IE9QRU5QR1BLRVkgb24gdGhlIExIUyBhcyB0aGUgd29ya2luZyBncm91cCBoYXMg ZGlzY3Vzc2VkLiAgU3VwcG9ydGluZyB0aGlzIHBvaW50LCBteSBjb2xsZWFndWVzIGltcGxlbWVu dGVkIHRoZSAwOCBkcmFmdCBleGFjdGx5IGFzIGl0IGlzDQogIGluIG91ciBwcm9vZiBvZiBjb25j ZXB0IERBTkUgcHJvdmlzaW9uaW5nIHRvb2wgWzFdIGFuZCB0aGVuIHVwZGF0ZWQgdGhlIFBvQyBm b3IgdGhpcyBJRVRGIHdpdGggdHJ1bmNhdGVkIFNIQTI1Ni4gSeKAmWQgbG92ZSB0byBzZWUgdGhp cyBzZXR0bGUgZG93biBzbyB0aGF0IHdlIGNhbiBzdXBwb3J0IHRlc3RzIGFuZA0KICBleHBlcmlt ZW50cyB3aXRoIFNNSU1FQS4gIENvcnJlc3BvbmRpbmdseSwgSeKAmWQgYmUgZ2xhZCB0byBzZWUg dGhlIFNNSU1FQSBSUiBhc3NpZ25lZC4gIEN1cnJlbnRseSB0aGUgUG9DIHVzZXMgYSBudW1iZXIg ZnJvbSB0aGUgUHJpdmF0ZSBVc2Ugc3BhY2UuDQogDQoNCi0gSW4gYWRkaXRpb24gdG8gbWF0Y2hp bmcgdGhlIGFwcHJvYWNoIG9mIE9QRU5QR1BLRVkgb24gdGhlIExIUywgaXQgd291bGQgbWFrZSBz ZW5zZSBmb3IgdGhpcyBkcmFmdCB0byBtYXRjaCB0aGUgb3RoZXIgZHJhZnQncyBsYW5ndWFnZSBv biB0aGUgc3ViamVjdCBvZiByZXNwb25zZSBsZW5ndGguDQogIEnigJlkIGxpa2UgdG8gc2VlIHRo ZSBTTUlNRSBkcmFmdCBhZG9wdCB0aGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgdGV4dCBhYm91 dCByZXNwb25zZSBzaXplIGZyb20gdGhlIE9QRU5QR1BLRVkgZHJhZnQuDQoNClRoYW5rcyENCg0K QWxsaXNvbg0KDQoNClsxXSBEQU5FIHByb3Zpc2lvbmluZyBwb3J0YWwgcHJvb2Ygb2YgY29uY2Vw dDogIGh0dHBzOi8vd3d3LmRhbmUtcHJvdmlzaW9uaW5nLnZlcmlzaWdubGFicy5jb20vDQoNCg0K DQoNCg0KDQo= From nobody Sun Jul 19 06:53:16 2015 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 793131ACF59 for ; Sun, 19 Jul 2015 06:53: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 p-4ql37Cciys for ; Sun, 19 Jul 2015 06:53:13 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0767.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:767]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3929A1ACEF6 for ; Sun, 19 Jul 2015 06:53:12 -0700 (PDT) Received: from BY2PR09MB0216.namprd09.prod.outlook.com (10.160.122.18) by BY2PR09MB0216.namprd09.prod.outlook.com (10.160.122.18) with Microsoft SMTP Server (TLS) id 15.1.219.17; Sun, 19 Jul 2015 13:52:53 +0000 Received: from BY2PR09MB0216.namprd09.prod.outlook.com ([10.160.122.18]) by BY2PR09MB0216.namprd09.prod.outlook.com ([10.160.122.18]) with mapi id 15.01.0219.018; Sun, 19 Jul 2015 13:52:53 +0000 From: "Rose, Scott" To: "dane@ietf.org" Thread-Topic: Another SMIMEA draft review Thread-Index: AQHQwicDTuK9dmk2q0ymHTgnzo2PIA== Date: Sun, 19 Jul 2015 13:52:53 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-originating-ip: [2001:67c:370:136:74b9:a60a:7520:facb] x-microsoft-exchange-diagnostics: 1; BY2PR09MB0216; 5:fP8rkz92KuD+1IworPWWbh86OBS5qbyOroJjcFuyVA8IXwSG1/Y0a52tVLwOKSvHDoKIXQ4ONm/n2FKXwvx1Qh7IqcPZfohoHbqRkfwKQr689V3antoGL4KVBuNT1OTXSPfUJDzjbimzrRP12gTy6g==; 24:617bR+KmrJDmQ4cmAxl81lBPhdVWAAU2WAi8vokxWwRX1TtvZ3DExpxRPk3SUf7Ki/XGC8kZJZ6Ikj38KFMnjUIVXoNPRZY6bYIOlS7wwQU=; 20:DAL3aknLS5KjGbeqi59Vo/94GL0DhJnOoLMKwwKYiJVremTQtzyNzYj6mj5RlFEM7ObvoaquxCahgQvSYMLLBQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR09MB0216; by2pr09mb0216: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BY2PR09MB0216; BCL:0; PCL:0; RULEID:; SRVR:BY2PR09MB0216; x-forefront-prvs: 0642A5E7BA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(16236675004)(2501003)(33656002)(19625215002)(5001920100001)(5002640100001)(50986999)(54356999)(5003600100002)(19627405001)(77156002)(450100001)(106116001)(2351001)(99286002)(229853001)(62966003)(87936001)(2656002)(110136002)(107886002)(122556002)(92566002)(5001960100002)(102836002)(77096005)(46102003)(76576001)(74316001)(40100003)(189998001)(2900100001)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR09MB0216; H:BY2PR09MB0216.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BY2PR09MB0216912C827C291A0F5F5734F0860BY2PR09MB0216namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2015 13:52:53.0559 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR09MB0216 Archived-At: Subject: [dane] Another SMIMEA draft review 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, 19 Jul 2015 13:53:15 -0000 --_000_BY2PR09MB0216912C827C291A0F5F5734F0860BY2PR09MB0216namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have read the SMIMEA -08 draft and support it being "undeterred" and put = back on track. NIST also has some (old) test code that we want to host and= have sponsored SMIMEA work in the past. Our previous work has used the fo= rmat described in the current draft. I have heard of two potential privacy concerns that the WG may want include= d in the Security Considerations section: First, if the _smimecert. is hosted by a service provider (i.e. not= the domain owner), the service provider can see who may be receiving encry= pted mail and may also learn the source IP address and other potential info= rmation. Of course, the hosting provider also knows the whole list of (has= hed) cert holders in the domain as well. Pervasive monitoring may also dis= cover this (source IP A is looking for a cert for person X in order to send= them mail), but qname-minimization may mitigate this to a degree. Second, clients looking to validate a digital signature using SMIMEA querie= s may also be signaling a read receipt. If the original sender knows the r= ecursive servers of the recipient, The sender could get an idea as to when = the receiver MUA validated the digital signature by observing SMIMEA querie= s to their domain. This isn't a showstopper IMHO as recipients with cached= digital signature certs may not send queries. To summarize as some suggested text (as a starting point at least - not hap= py with it, but it is the best my brain allows right now): ***** In addition to the zone walking vulnerability, SMIMEA aware senders and rec= eivers may also leak information when querying for SMIMEA RRs for validatin= g digital signatures and discovering a recipient's S/MIME encryption certif= icate. SMIMEA RR queries may leak information about who is planning to send= , or has receive S/MIME protected email messages. DNS privacy techniques s= uch as qname-minimization may mitigate some of the leakage. ***** Scott --_000_BY2PR09MB0216912C827C291A0F5F5734F0860BY2PR09MB0216namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I have read the SMIMEA -08 draft and support it being "undeterred&q= uot; and put back on track.  NIST also has some (old) test code that w= e want to host and have sponsored SMIMEA work in the past.  Our previo= us work has used the format described in the current draft.


I have heard of two potential privacy concerns that the WG may want incl= uded in the Security Considerations section:


First, if the _smimecert.<domain> is hosted by a service provider = (i.e. not the domain owner), the service provider can see who may be receiv= ing encrypted mail and may also learn the source IP address and other poten= tial information.  Of course, the hosting provider also knows the whole list of (hashed) cert holders in the domain = as well.  Pervasive monitoring may also discover this (source IP A is = looking for a cert for person X in order to send them mail), but qname-mini= mization may mitigate this to a degree.


Second, clients looking to validate a digital signature using SMIMEA que= ries may also be signaling a read receipt.  If the original sender kno= ws the recursive servers of the recipient, The sender could get an idea as = to when the receiver MUA validated the digital signature by observing SMIMEA queries to their domain.  This = isn't a showstopper IMHO as recipients with cached digital signature certs = may not send queries. 


To summarize as some suggested text (as a starting point at least - not = happy with it, but it is the best my brain allows right now):


*****

In addition to the zone walking vulnerability, SMIMEA aware senders and = receivers may also leak information when querying for SMIMEA RRs for valida= ting digital signatures and discovering a recipient's S/MIME encryption cer= tificate. SMIMEA RR queries may leak information about who is planning to send, or has receive S/MIME prot= ected email messages.  DNS privacy techniques such as qname-minimizati= on may mitigate some of the leakage.  


*****


Scott



--_000_BY2PR09MB0216912C827C291A0F5F5734F0860BY2PR09MB0216namp_-- From nobody Sun Jul 19 07:57:45 2015 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 EDC5D1AD35A for ; Sun, 19 Jul 2015 07:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 rEYJfHN_Be5F for ; Sun, 19 Jul 2015 07:57:42 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32F2E1AD2B2 for ; Sun, 19 Jul 2015 07:57:42 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id C4F10284D2B; Sun, 19 Jul 2015 14:57:40 +0000 (UTC) Date: Sun, 19 Jul 2015 14:57:40 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150719145740.GI28047@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: Subject: Re: [dane] Another SMIMEA draft review 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: Sun, 19 Jul 2015 14:57:44 -0000 On Sun, Jul 19, 2015 at 01:52:53PM +0000, Rose, Scott wrote: > First, if the _smimecert. is hosted by a service provider (i.e. > not the domain owner), the service provider can see who may be receiving > encrypted mail. Which they'll also learn by just looking at the zone data, if the localparts are not hashed in the final spec. I'd be more concerned above passive monitoring, because with submission over port 587 with TLS, and forward hops from the MSA to the destination also increasingly over TLS, there is often at present no cleartext exposure of the envelope recipients. With SMIMEA, passive monitoring of DNS queries will often reveal the correspondent addresses. > and may also learn the source IP address and other potential > information. That'll be less common, there will typically be iterative resolvers between the user and the authoritative nameserver. > Of course, the hosting provider also knows the whole list > of (hashed) cert holders in the domain as well. Pervasive monitoring may > also discover this (source IP A is looking for a cert for person X in > order to send them mail), but qname-minimization may mitigate this to a > degree. Query minimization does not help here, it only hides the data from operators of parent domain nameservers. Only encryption of DNS traffic (ala DNScurve and at all zone cuts from the root down) would help. > Second, clients looking to validate a digital signature using SMIMEA > queries may also be signaling a read receipt. If the original sender > knows the recursive servers of the recipient, The sender could get an idea > as to when the receiver MUA validated the digital signature by observing > SMIMEA queries to their domain. This isn't a showstopper IMHO as recipients > with cached digital signature certs may not send queries. The cache lifetimes should be relatively short (not in excess of the DNS TTLs of the TLSA RRs), so whenever there's a hiatus in email flow between two correspondents (as opposed to a flurry of immediate replies) it is quite likely that new conversations will involve new DNS lookups. > SMIMEA RR queries may leak information about who > is planning to send, or has receive S/MIME protected email messages. DNS > privacy techniques such as qname-minimization may mitigate some of the > leakage. Qname minimization does not help against passive monitoring, unless that passive monitoring is in (only) in front of the root or gTLD/ccTLD nameservers, rather than on path somewhere between author and target domain. -- Viktor. From nobody Sun Jul 19 23:04:21 2015 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 43CF21B2FE8 for ; Sun, 19 Jul 2015 23:04:20 -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 yJI6H0LDg2St for ; Sun, 19 Jul 2015 23:04:18 -0700 (PDT) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EF941B2FE6 for ; Sun, 19 Jul 2015 23:04:18 -0700 (PDT) Received: by qgy5 with SMTP id 5so68636654qgy.3 for ; Sun, 19 Jul 2015 23:04:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=f9yvhU8oh5cfzFuSqmfVM2iCxR1GjqfLoFJgYbk3eV8=; b=iajvLE3mHKvY0jDapM06480nOMTLXdJYK3G14ulVbDD/K7ZgtZNnlY7OMX2mFEVVUp Llx08Ld9Od9QqBsCGJaUJ+I+nXJgchXmg0OnUkosI4HfpA+X0peQxk8FQMcrlgFpGRHj Rqndf4a6F19nxpaizFesrbQGloFxbqjNynTu03j6Fe4t2WJLtMP5ezRmxaThYDhWHTKv 87ryd2ZJh2Ugc2XF6gGEn55Fa57gbdqRePe6YagbjfXjDh52swxf72yC0ZJU4O4Bg23x ZFXK3acSy+xmfW6CDIPo3lGrBQ3ts4fRYWIwDKwkzpHHVbvxHdGNhVa9gei5/smoGp3N AZMw== MIME-Version: 1.0 X-Received: by 10.140.132.148 with SMTP id 142mr38723483qhe.74.1437372257854; Sun, 19 Jul 2015 23:04:17 -0700 (PDT) Received: by 10.140.80.208 with HTTP; Sun, 19 Jul 2015 23:04:17 -0700 (PDT) In-Reply-To: References: Date: Mon, 20 Jul 2015 08:04:17 +0200 Message-ID: From: Shumon Huque To: "" Content-Type: multipart/alternative; boundary=001a113509a6d6ead8051b484e08 Archived-At: Subject: Re: [dane] Draft agenda posted. 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 Jul 2015 06:04:20 -0000 --001a113509a6d6ead8051b484e08 Content-Type: text/plain; charset=UTF-8 On Mon, Jul 6, 2015 at 8:58 PM, Warren Kumari wrote: > Hi all, > > We have just posted the draft agenda for Prague. > [...] FYI, for the topics below, -01 drafts were posted in case you only read the -00 versions. > TLS extension for DNSSEC chain > Shumon Huque > 15 minutes > https://tools.ietf.org/html/draft-shore-tls-dnssec-chain-extension-01 > > > Client Certificates in DANE TLSA Records > Shumon Huque / Viktor Dukhovni > 15 minutes > https://tools.ietf.org/html/draft-huque-dane-client-cert-01 -- Shumon Huque --001a113509a6d6ead8051b484e08 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jul 6, 2015 at 8:58 PM, Warren Kumari <warren@kumari.net> wrote:
Hi all,

We have just posted the draft agenda for Prague.
[...]=

FYI, for the topics below, -01 drafts were posted= in case you only read the -00 versions.
=C2=A0
TLS extension for DNSSEC chain
Shumon Huque
15 minutes

=C2=A0
=


Client Certificates in DANE TLSA Records
Shumon Huque / Viktor Dukhovni
15 minutes


--=C2=A0
Shumon Huque

--001a113509a6d6ead8051b484e08-- From nobody Mon Jul 20 00:02:30 2015 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 5FBEA1A00DF for ; Mon, 20 Jul 2015 00:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 SnuENzZbajqV for ; Mon, 20 Jul 2015 00:02:17 -0700 (PDT) Received: from mail-oi0-f98.google.com (mail-oi0-f98.google.com [209.85.218.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 717011A00DC for ; Mon, 20 Jul 2015 00:02:16 -0700 (PDT) Received: by oiho132 with SMTP id o132so7852905oih.2 for ; Mon, 20 Jul 2015 00:02:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :user-agent:content-type:content-id:content-transfer-encoding :mime-version; bh=V+FaW2ZUmRxqOHnzfrTMU10f/gorTnjs1v97j8+8Jcw=; b=Mxdf2hiJsV/b/sXaDVOOeYduyidxtUzTKaSaScQD5sEHw1TorhL6pzZCug37WFjALs Hwk9lBYv8ULBWXq5qKIm2tKl9M3YVFZZ5QfJp/GgaW/C+b3WrUjkGH+xMwilub6Gnyf0 GN9Fn9SRfcs2ci3ICJEnf8VTBS/P+bT19PrHpqKLRI6PB+mMmseK0qw/o+hc51ZBzSWF /FiHA76CS3hd6sYmq51krcuy1G+V+gMtyu348KCPwJXbSebZYCpQ3xkUI+CjGcFq8B2b VXSsb6+cOQNXZ7Lw7oKI/zbv9ECYueCA1Wgtbm6dnb7ACt65c44fRYXpWNCfQ+GmBD29 21wQ== X-Gm-Message-State: ALoCoQlxQpcgo32/jn/VgSk8uNjxOwtg6T7cmecW2XHxIdf6xVaO+K38hYdbNl+VqIEC4wFdGm1tdB+Q/ToHedXX3eozMMlVUg== X-Received: by 10.140.49.11 with SMTP id p11mr44162258qga.60.1437375735862; Mon, 20 Jul 2015 00:02:15 -0700 (PDT) Received: from brn1lxmailout01.verisign.com (brn1lxmailout01.verisign.com. [72.13.63.41]) by smtp-relay.gmail.com with ESMTPS id 1sm6597986qkx.1.2015.07.20.00.02.15 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 20 Jul 2015 00:02:15 -0700 (PDT) X-Relaying-Domain: verisign.com Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02 [10.173.152.206]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id t6K72Fjm028191 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 20 Jul 2015 03:02:15 -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 Jul 2015 03:02:15 -0400 From: "Wiley, Glen" To: "dane@ietf.org" Thread-Topic: [dane] Another SMIMEA draft review Thread-Index: AQHQwicDTuK9dmk2q0ymHTgnzo2PIJ3jJUQAgADKbYA= Date: Mon, 20 Jul 2015 07:02:14 +0000 Message-ID: References: <20150719145740.GI28047@mournblade.imrryr.org> In-Reply-To: <20150719145740.GI28047@mournblade.imrryr.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 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: Subject: Re: [dane] Another SMIMEA draft review 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 Jul 2015 07:02:21 -0000 On 7/19/15, 10:57 AM, "Viktor Dukhovni" wrote: >On Sun, Jul 19, 2015 at 01:52:53PM +0000, Rose, Scott wrote: > >> First, if the _smimecert. is hosted by a service provider (i.e. >> not the domain owner), the service provider can see who may be receiving >> encrypted mail. > >Which they'll also learn by just looking at the zone data, if the >localparts are not hashed in the final spec. Has there been any recent discussion about using a non-hashed LHS encoding? I don=B9t think there has so we probably don=B9t want to bring that question into scope here. > >I'd be more concerned above passive monitoring, because with >submission over port 587 with TLS, and forward hops from the MSA >to the destination also increasingly over TLS, there is often at >present no cleartext exposure of the envelope recipients. > >With SMIMEA, passive monitoring of DNS queries will often reveal >the correspondent addresses. Obvious but worth a reminder=8Apassive monitoring isn=B9t a problem peculia= r to the SMIMEA approach, it is an issue for all elements of the email flow that are not encrypted. > > >> and may also learn the source IP address and other potential >> information. > >That'll be less common, there will typically be iterative resolvers >between the user and the authoritative nameserver. > >> Of course, the hosting provider also knows the whole list >> of (hashed) cert holders in the domain as well. Pervasive monitoring >>may >> also discover this (source IP A is looking for a cert for person X in >> order to send them mail), but qname-minimization may mitigate this to a >> degree. > >Query minimization does not help here, it only hides the data from >operators of parent domain nameservers. Only encryption of DNS >traffic (ala DNScurve and at all zone cuts from the root down) >would help. > >> Second, clients looking to validate a digital signature using SMIMEA >> queries may also be signaling a read receipt. If the original sender >> knows the recursive servers of the recipient, The sender could get an >>idea >> as to when the receiver MUA validated the digital signature by observing >> SMIMEA queries to their domain. This isn't a showstopper IMHO as >>recipients >> with cached digital signature certs may not send queries. > >The cache lifetimes should be relatively short (not in excess of >the DNS TTLs of the TLSA RRs), so whenever there's a hiatus in >email flow between two correspondents (as opposed to a flurry of >immediate replies) it is quite likely that new conversations will >involve new DNS lookups. > >> SMIMEA RR queries may leak information about who >> is planning to send, or has receive S/MIME protected email messages. >>DNS >> privacy techniques such as qname-minimization may mitigate some of the >> leakage. > >Qname minimization does not help against passive monitoring, unless >that passive monitoring is in (only) in front of the root or >gTLD/ccTLD nameservers, rather than on path somewhere between author >and target domain. I think it is fair to say that QNM does help as it reduces the number of points at which a passive monitor can see traffic. It is an incremental improvement. > >--=20 > Viktor. > >_______________________________________________ >dane mailing list >dane@ietf.org >https://www.ietf.org/mailman/listinfo/dane From nobody Mon Jul 20 02:09:05 2015 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 CF01D1A00FA for ; Mon, 20 Jul 2015 02:09:04 -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 f90mC2YDSbUL for ; Mon, 20 Jul 2015 02:09:03 -0700 (PDT) Received: from smtp84.iad3a.emailsrvr.com (smtp84.iad3a.emailsrvr.com [173.203.187.84]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47EBC1A00E9 for ; Mon, 20 Jul 2015 02:09:03 -0700 (PDT) Received: from smtp3.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp3.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 1626F300289 for ; Mon, 20 Jul 2015 05:09:02 -0400 (EDT) Received: by smtp3.relay.iad3a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 8671930020D for ; Mon, 20 Jul 2015 05:09:00 -0400 (EDT) X-Sender-Id: ogud@ogud.com Received: from dhcp-hotel-wired-1-fb.meeting.ietf.org ([UNAVAILABLE]. [130.129.1.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.4.2); Mon, 20 Jul 2015 09:09:02 GMT From: Olafur Gudmundsson Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 20 Jul 2015 05:08:58 -0400 To: dane Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) X-Mailer: Apple Mail (2.2102) Archived-At: Subject: [dane] Discussion on OPENPGP and SMIME record location 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 Jul 2015 09:09:05 -0000 Dear Colleagues=20 This note is to stimulate discussion, on higher level design of the = these two email protocol,=20 discussion on local-part =E2=80=9Cname=E2=80=9D is a separate = discussion.=20 Right now we have two =E2=80=9Cactive=E2=80=9D email sign/encrypt = technologies, proposing to store =E2=80=9Ckeying=E2=80=9D information in = DNS,=20 When we want to do a lookup we have two design dimensions,=20 =E2=80=94 names=20 =E2=80=94 types=20 In the name space OPENPGP and SMIME are proposing two different = =E2=80=9Czones=E2=80=9D/names where keying info is stored this has = certain advantages and disadvantages.=20 Further more there have been proposals to have different =E2=80=9Czones=E2= =80=9D for sign and encrypt for SMIME.=20 Pro:=20 - easy to see if organization "supports" technology=20 - if SMIME is operated by different group than PGP then there are = no organizational conflicts Con: - To see if user X supports encrypted mail may require 2x lookups ( = i.e. in each Technology X all local part guesses) for organizations that = have users that use both PGP and SMIME - more DNS data to maintain and sign.=20 Antidode: If an organization has to support users with both types of = keys, it can publish both in one zone by using DNAME.=20 In the type space we have OPENPGPKEY and SIMIMEA types proposed and the = idea is that the contnents of the records specify usage rules.=20 We can also do this via more types.=20 We have seen arguments in the past ranging from =E2=80=9CLets ignore = this=E2=80=9D to =E2=80=9CWe MUST support organizational realities = including split views=E2=80=9D=20 Question:=20 a) do we want to merge the zones where EMAIL keying is stored ?=20 or =20 b) Do we want to reflect policies in naming?=20 c) do we want to reflect polices in types=20 d) do we want to reflect policies inside records=20 or=20 f) we can not answer this, experience will have to guide us.=20 Think about how you want to answer these questions and lets have a short = discussion in the meeting on Monday but please start discussion on the = mailing list if you feel strongly about this=20 Olafur & Warren=20 PS: if you have a speaking slot in the meeting, now is a good time to = send in slides= From nobody Mon Jul 20 02:23:40 2015 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 E99051A028A for ; Mon, 20 Jul 2015 02:23:30 -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 7bhh1Iv9c27F for ; Mon, 20 Jul 2015 02:23:25 -0700 (PDT) Received: from smtp108.iad3a.emailsrvr.com (smtp108.iad3a.emailsrvr.com [173.203.187.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0EBD1A09C9 for ; Mon, 20 Jul 2015 02:23:24 -0700 (PDT) Received: from smtp30.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp30.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 1194F3800FC; Mon, 20 Jul 2015 05:23:24 -0400 (EDT) Received: by smtp30.relay.iad3a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 7A8EF3800D4; Mon, 20 Jul 2015 05:23:23 -0400 (EDT) X-Sender-Id: ogud@ogud.com Received: from dhcp-hotel-wired-1-fb.meeting.ietf.org ([UNAVAILABLE]. [130.129.1.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.4.2); Mon, 20 Jul 2015 09:23:24 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_D3C14BF1-78D2-4CB9-9DB8-AC16CD65E1FF" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Olafur Gudmundsson In-Reply-To: <43237F83-0909-449D-896F-389868557184@verisign.com> Date: Mon, 20 Jul 2015 05:23:21 -0400 Message-Id: References: <43237F83-0909-449D-896F-389868557184@verisign.com> To: "Mankin, Allison" X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "dane@ietf.org" Subject: Re: [dane] SMIMEA draft review (was: Deferal of SMIME Draft) 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 Jul 2015 09:23:31 -0000 --Apple-Mail=_D3C14BF1-78D2-4CB9-9DB8-AC16CD65E1FF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 19, 2015, at 7:01 AM, Mankin, Allison = wrote: >=20 > I=E2=80=99ve done a careful read of draft-ietf-dane-smime-08. I find = it to be in very good shape, and on track for publication as an = Experimental. >=20 Thank you for this review, much appreciated, as chair I encourage others = to take few minutes to read and review the document.=20 > My review surfaced a few minor points, easy to address: >=20 > - The NOTE FOR FUTURE DRAFTS was added about a year ago (in the 05 = version) and in my view, the WG=20 > has in the intervening year fulfilled the request of the note, to = discuss all the diverse types of usage of DANE. This is for editors to address.=20 >=20 > - I support modifying the draft to follow OPENPGPKEY on the LHS as the = working group has discussed. Supporting this point, my colleagues = implemented the 08 draft exactly as it is > in our proof of concept DANE provisioning tool [1] and then updated = the PoC for this IETF with truncated SHA256. I=E2=80=99d love to see = this settle down so that we can support tests and > experiments with SMIMEA. Correspondingly, I=E2=80=99d be glad to see = the SMIMEA RR assigned. Currently the PoC uses a number from the = Private Use space. >=20 Getting the code assigned is a simple formality of filing a request as = specified in http://tools.ietf.org/html/rfc6895 = =20 appendix A.=20 >=20 > - In addition to matching the approach of OPENPGPKEY on the LHS, it = would make sense for this draft to match the other draft's language on = the subject of response length. > I=E2=80=99d like to see the SMIME draft adopt the Security = Considerations text about response size from the OPENPGPKEY draft. >=20 In my mind the question is rather than repeat the text how about just = reference the text explicitly, same goes for the use of LHS is there = need to repeat the definition or is=20 should explicit reference be used.=20 > Thanks! >=20 > Allison Thank you again for the review, and running code.=20 Olafur=20 --Apple-Mail=_D3C14BF1-78D2-4CB9-9DB8-AC16CD65E1FF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jul 19, 2015, at 7:01 AM, Mankin, Allison <amankin@verisign.com> wrote:

I=E2=80=99ve done a = careful read of draft-ietf-dane-smime-08.  I find it to be in very = good shape, and on track for publication as an Experimental.


Thank you for this review, much appreciated, as chair I = encourage others to take few minutes to read and review the = document. 

My review surfaced a few minor points, easy = to address:

- The NOTE FOR FUTURE DRAFTS = was added about a year ago (in the 05 version) and in my view, the WG =
 has in the intervening year fulfilled the request = of the note, to discuss all the diverse types of usage of DANE.

This is for = editors to address. 

- I support modifying the = draft to follow OPENPGPKEY on the LHS as the working group has = discussed.  Supporting this point, my colleagues implemented the 08 = draft exactly as it is
 in our proof of concept DANE = provisioning tool [1] and then updated the PoC for this IETF with = truncated SHA256. I=E2=80=99d love to see this settle down so that we = can support tests and
 experiments with SMIMEA. =  Correspondingly, I=E2=80=99d be glad to see the SMIMEA RR = assigned.  Currently the PoC uses a number from the Private Use = space.


Getting the code assigned is a simple formality of = filing a request as specified in http://tools.ietf.org/html/rfc6895 
appendix= A. 


- In addition to matching the = approach of OPENPGPKEY on the LHS, it would make sense for this draft to = match the other draft's language on the subject of response length.
 I=E2=80=99d like to see the SMIME draft adopt the = Security Considerations text about response size from the OPENPGPKEY = draft.


In my mind the question is rather than repeat the = text how about just reference the text explicitly, same goes for the use = of LHS is there need to repeat the definition or = is 
should explicit reference be = used. 


Thanks!


Allison

Thank you = again for the review, and running code. 

Olafur 

= --Apple-Mail=_D3C14BF1-78D2-4CB9-9DB8-AC16CD65E1FF-- From nobody Mon Jul 20 02:34:46 2015 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 9E8B91A1A42 for ; Mon, 20 Jul 2015 02:34:44 -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 wh6jAwQSY-9p for ; Mon, 20 Jul 2015 02:34:43 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50ACF1A1A04 for ; Mon, 20 Jul 2015 02:34:43 -0700 (PDT) Received: by qkdv3 with SMTP id v3so108404333qkd.3 for ; Mon, 20 Jul 2015 02:34:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OikOG1M4x5LWqBipuUhfu1UKEoQX8hr24nftPu+Durg=; b=kh5gPMAidP8I2BHrgQdgrCje+wCWEgLXk9iwGUc/kTqDCIwwL4t9iM713pipAc3KxK 7m0FbGzDkmDlmJXyCCKeK1dBRxXrjhMPh4T0hkjCc5Qhu+rNwkYCBKGVMjPS90rZQ7X7 7gcvT5nKkjm5GMDp27IZ6djDgsqdNdFEtmK7pdi5j+OSBppf3DblICRaiIiJoZUJZ+Ux lxHjcq9iwJbKG4FJOV866vf8O+Z6tDS2K4SbeIsVI9wqkTreeXxCf43SQSZ9H0ptE/TK i6jcohVv1nvra6iKXe/R0+S+0IrOcoIpOyKPcl0gh0A7Ymxpsr+2q7MVY6eL9oBqNlPn Gwow== MIME-Version: 1.0 X-Received: by 10.55.41.103 with SMTP id p100mr45082713qkh.39.1437384882495; Mon, 20 Jul 2015 02:34:42 -0700 (PDT) Received: by 10.140.80.208 with HTTP; Mon, 20 Jul 2015 02:34:42 -0700 (PDT) In-Reply-To: References: <43237F83-0909-449D-896F-389868557184@verisign.com> Date: Mon, 20 Jul 2015 11:34:42 +0200 Message-ID: From: Shumon Huque To: Olafur Gudmundsson Content-Type: multipart/alternative; boundary=001a1140651853a3b8051b4b3f0b Archived-At: Cc: "dane@ietf.org" Subject: Re: [dane] SMIMEA draft review (was: Deferal of SMIME Draft) 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 Jul 2015 09:34:44 -0000 --001a1140651853a3b8051b4b3f0b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jul 20, 2015 at 11:23 AM, Olafur Gudmundsson wrote: > > On Jul 19, 2015, at 7:01 AM, Mankin, Allison wrote= : > > I=E2=80=99ve done a careful read of draft-ietf-dane-smime-08. I find it = to be in > very good shape, and on track for publication as an Experimental. > > > Thank you for this review, much appreciated, as chair I encourage others > to take few minutes to read and review the document. > > I have also read this draft, and support a plan to continue work on it with the goal of publishing it as experimental. Shumon Huque --001a1140651853a3b8051b4b3f0b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jul 20, 2015 at 11:23 AM, Olafur Gudmundsson <ogud@ogud.com>= wrote:

On Jul 19, 2015= , at 7:01 AM, Mankin, Allison <amankin@verisign.com> wrote:

I=E2=80= =99ve done a careful read of draft-ietf-dane-smime-08.=C2=A0 I find it to b= e in very good shape, and on track for publication as an Experimental.
<= br>

Thank you for this review, much= appreciated, as chair I encourage others to take few minutes to read and r= eview the document.=C2=A0


<= /div>
I have also read this draft, and support a plan to continue work = on it with the goal of publishing it as experimental.

<= div>Shumon Huque

--001a1140651853a3b8051b4b3f0b-- From nobody Mon Jul 20 03:01:08 2015 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 F3F741A1AAD for ; Mon, 20 Jul 2015 03:01:06 -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 URrjEvXEEM-9 for ; Mon, 20 Jul 2015 03:01:00 -0700 (PDT) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2207A1A1AB6 for ; Mon, 20 Jul 2015 03:01:00 -0700 (PDT) Received: by igbpg9 with SMTP id pg9so33630061igb.0 for ; Mon, 20 Jul 2015 03:00:59 -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=fL8qB6V+9baAjK20vIuzv+trYCIMZ8mhqPPzmpS6AUg=; b=JvVYulsqDlZcDsGlLBlhQJBjbH4Nnf9EeukxR3k/VECCcH4le9CbDAcR3HFz2z3VDo u6u8Xqw3fOE0faqo1d0kTBeJN+Gi8zCgn1V+Lvb/RKC9iFg16R3F/MS1g5Ugd1GTpS+3 MyCoWEX9nVa57+IXQBl/et/22vZ52TYxBlLl3oyQEk0ie5b7R54xl0k4lLdCUDeNSRAV G7XD4nTa/UxZ32BUNhO0lrVxF13PkEfvPbLE/i2SoBoUmWoPFA4ArdH9EqdqbsWLgCP8 95GFL9XJ1GULMrNG3RmrZm/wruUA413OYYfR0fTzypBPhKX+e2LntxTnm0e4LMElAzGA 6tKQ== X-Received: by 10.107.47.26 with SMTP id j26mr34653136ioo.17.1437386459523; Mon, 20 Jul 2015 03:00:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.9.169 with HTTP; Mon, 20 Jul 2015 03:00:40 -0700 (PDT) In-Reply-To: References: From: Doug Montgomery Date: Mon, 20 Jul 2015 06:00:40 -0400 Message-ID: To: Olafur Gudmundsson Content-Type: multipart/alternative; boundary=001a113513b65330a7051b4b9d03 Archived-At: Cc: dane Subject: Re: [dane] Discussion on OPENPGP and SMIME record location 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 Jul 2015 10:01:07 -0000 --001a113513b65330a7051b4b9d03 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable a) not now (e.g. f), if both are headed to experimental. As you note there are ways to optimize if it turns out the type/rr conventions are the same. What would seem suboptimal at this time is to create the friction of forcing a converged approach until we fully understand the usage scenarios through experience. b,c,d) were you only referring to the SMIME vs PGP policy? Or other potential secure email usage policies. A while back, in comments on the requirement draft, we suggested the ability to convey some expected usage policies WRT email security. These seemed important enablers to us in an enterprise environment. Not sure if you are referring to those sort of polices, or just SMIME vs PGP policies. f) Given that you posed the questions as a series of alternatives .... this is the real answer. We seem to have interested parties prototyping running code for various components of both solutions. Establish a realistic, but hard, deadline to evaluate the results of the experimental phase - making it clear that further spec work is envisioned on both approaches before adopting on a standards track. dougm On Mon, Jul 20, 2015 at 5:08 AM, Olafur Gudmundsson wrote: > Dear Colleagues > > This note is to stimulate discussion, on higher level design of the these > two email protocol, > discussion on local-part =E2=80=9Cname=E2=80=9D is a separate discussion. > > Right now we have two =E2=80=9Cactive=E2=80=9D email sign/encrypt technol= ogies, proposing > to store =E2=80=9Ckeying=E2=80=9D information in DNS, > When we want to do a lookup we have two design dimensions, > =E2=80=94 names > =E2=80=94 types > > In the name space OPENPGP and SMIME are proposing two different > =E2=80=9Czones=E2=80=9D/names where keying info is stored this has certai= n advantages and > disadvantages. > Further more there have been proposals to have different =E2=80=9Czones= =E2=80=9D for sign > and encrypt for SMIME. > > Pro: > - easy to see if organization "supports" technology > - if SMIME is operated by different group than PGP then there are n= o > organizational conflicts > > Con: > - To see if user X supports encrypted mail may require 2x lookups ( > i.e. in each Technology X all local part guesses) for organizations that > have users that use both PGP and SMIME > - more DNS data to maintain and sign. > > Antidode: If an organization has to support users with both types of keys= , > it can publish both in one zone by using DNAME. > > In the type space we have OPENPGPKEY and SIMIMEA types proposed and the > idea is that the contnents of the records specify usage rules. > We can also do this via more types. > > We have seen arguments in the past ranging from =E2=80=9CLets ignore this= =E2=80=9D to =E2=80=9CWe > MUST support organizational realities including split views=E2=80=9D > > Question: > a) do we want to merge the zones where EMAIL keying is stored ? > > or > b) Do we want to reflect policies in naming? > c) do we want to reflect polices in types > d) do we want to reflect policies inside records > > or > f) we can not answer this, experience will have to guide us. > > Think about how you want to answer these questions and lets have a short > discussion in the meeting on Monday but please start discussion on the > mailing list if you feel strongly about this > > Olafur & Warren > > PS: if you have a speaking slot in the meeting, now is a good time to sen= d > in slides > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > --=20 DougM at Work --001a113513b65330a7051b4b9d03 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
a) not n= ow (e.g. f), if both are headed to experimental.=C2=A0 As you note there ar= e ways to optimize if it turns out the type/rr conventions are the same. = =C2=A0 What would seem suboptimal at this time is to create the friction of= forcing a converged approach until we fully understand the usage scenarios= through experience.

= b,c,d) were you only referring to the SMIME vs PGP policy?=C2=A0 Or other p= otential secure email usage policies.=C2=A0 A while back, in comments on th= e requirement draft, we suggested the ability to convey some expected usage= policies WRT email security.=C2=A0 These seemed important enablers to us i= n an enterprise environment. =C2=A0 Not sure if you are referring to those = sort of polices, or just SMIME vs PGP policies.

f) Given that you posed the questions as a series of = alternatives .... this is the real answer. =C2=A0 We seem to have intereste= d parties prototyping running code for various components of both solutions= .=C2=A0 Establish a realistic, but hard, deadline to evaluate the results o= f the experimental phase - making it clear that further spec work is envisi= oned on both approaches before adopting on a standards track.
dougm


On Mon, Jul 20, 2015 at 5:08 AM, Olafur Gudmund= sson <ogud@ogud.com> wrote:
De= ar Colleagues

This note is to stimulate discussion, on higher level design of the these t= wo email protocol,
discussion on local-part =E2=80=9Cname=E2=80=9D is a separate discussion.
Right now we have two =E2=80=9Cactive=E2=80=9D email sign/encrypt technolog= ies, proposing to store =E2=80=9Ckeying=E2=80=9D information in DNS,
When we want to do a lookup we have two design dimensions,
=E2=80=94 names
=E2=80=94 types

In the name space OPENPGP and SMIME are proposing two different =E2=80=9Czo= nes=E2=80=9D/names where keying info is stored this has certain advantages = and disadvantages.
Further more there have been proposals to have different =E2=80=9Czones=E2= =80=9D for sign and encrypt for SMIME.

Pro:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 - easy to see if organization "supports&qu= ot; technology
=C2=A0 =C2=A0 =C2=A0 - if SMIME is operated by different group than PGP the= n there are no organizational conflicts

Con:
=C2=A0 =C2=A0 =C2=A0- To see if user X supports encrypted mail may require = 2x lookups ( i.e. in each Technology X all local part guesses) for organiza= tions that have users that use both PGP and SMIME
=C2=A0 =C2=A0 =C2=A0- more DNS data to maintain and sign.

Antidode: If an organization has to support users with both types of keys, = it can publish both in one zone by using DNAME.

In the type space we have OPENPGPKEY and SIMIMEA types proposed and the ide= a is that the contnents of the records specify usage rules.
We can also do this via more types.

We have seen arguments in the past ranging from =E2=80=9CLets ignore this= =E2=80=9D to =E2=80=9CWe MUST support organizational realities including sp= lit views=E2=80=9D

Question:
=C2=A0a) do we want to merge the zones where EMAIL keying is stored ?

or
=C2=A0b) Do we want to reflect policies in naming?
=C2=A0c) do we want to reflect polices in types
=C2=A0d) do we want to reflect policies inside records

or
=C2=A0f) we can not answer this, experience will have to guide us.

Think about how you want to answer these questions and lets have a short di= scussion in the meeting on Monday but please start discussion on the mailin= g list if you feel strongly about this

Olafur & Warren

PS: if you have a speaking slot in the meeting, now is a good time to send = in slides
_______________________________________________
dane mailing list
dane@ietf.org
https://www.ietf.org/mailman/listinfo/dane



--
DougM at Work
--001a113513b65330a7051b4b9d03-- From nobody Mon Jul 20 03:21:59 2015 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 7DC751A1B1E for ; Mon, 20 Jul 2015 03:21:58 -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 tBLj1v1QCMS6 for ; Mon, 20 Jul 2015 03:21:56 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC8BC1A1B15 for ; Mon, 20 Jul 2015 03:21:55 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mZfHP6bj7z43Y; Mon, 20 Jul 2015 12:21:53 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=cLs2zdHG X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 5_-NNtVRLbb7; Mon, 20 Jul 2015 12:21:53 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 20 Jul 2015 12:21:53 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 4A9FF800AD; Mon, 20 Jul 2015 06:21:52 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1437387712; bh=d7qJyVE67MJbHtUJojJb9O2l/smA0FJccv07TEuc4PQ=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=cLs2zdHGTZ5LNA0g8Anq+orcY1OMvcUnYX3GkK5t/0pLmBkmN9+jDKalAADZVoq8P VmkvSIf1Va9y5Alotg0hQDGNnvACtlT6IviBU/dxHDEXylyJL+7YvpvSaSlb50jAjH WXk+t8iEnqX0l63eZLOxBJtbG4zyPgrBEvvu2TAk= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t6KALot3019668; Mon, 20 Jul 2015 06:21:51 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 20 Jul 2015 06:21:50 -0400 (EDT) From: Paul Wouters To: Olafur Gudmundsson In-Reply-To: Message-ID: References: <43237F83-0909-449D-896F-389868557184@verisign.com> User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: "dane@ietf.org" Subject: Re: [dane] SMIMEA draft review (was: Deferal of SMIME Draft) 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 Jul 2015 10:21:58 -0000 On Mon, 20 Jul 2015, Olafur Gudmundsson wrote: > - In addition to matching the approach of OPENPGPKEY on the LHS, it would make sense for this draft to match the other draft's language on the subject of response length. >  I’d like to see the SMIME draft adopt the Security Considerations text about response size from the OPENPGPKEY draft. > > In my mind the question is rather than repeat the text how about just reference the text explicitly, same goes for the use of LHS is there need to repeat the definition or is  > should explicit reference be used.  The text is small enough to copy. It is a single small paragraph. Please copy so both texts can be read and implemented without needing to cross reference. Paul From nobody Mon Jul 20 03:37:33 2015 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 740E11A1B25 for ; Mon, 20 Jul 2015 03:37:31 -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 CGcBy_GelkHZ for ; Mon, 20 Jul 2015 03:37:30 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DD6B1A1B2C for ; Mon, 20 Jul 2015 03:29:49 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mZfSX1wJxz46T; Mon, 20 Jul 2015 12:29:48 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=lZmejwVb X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id l6PKckJy9LYI; Mon, 20 Jul 2015 12:29:47 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 20 Jul 2015 12:29:47 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 8CE53800AD; Mon, 20 Jul 2015 06:29:46 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1437388186; bh=SCRLKvWxYNy0V4qO/T35VyfvsJyuuyjtc89ghUPf3VU=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=lZmejwVbCf4joZka0snivhKXwSHb+nX1By+HDKCT2d9Btg5cTZ+/+ZUcXiD7JylWe gD1aWT2ERAHUZxT0ZdtdgbaYa7xG7Ve9ClQLp0VRM8LYDoK4wVz1fjU5LAiZzu4CI7 pCCLtw7v/tx8Xm3iBG4n06cE05ddxbe4pNtOsFsc= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t6KATkOu020670; Mon, 20 Jul 2015 06:29:46 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 20 Jul 2015 06:29:46 -0400 (EDT) From: Paul Wouters To: "Wiley, Glen" In-Reply-To: Message-ID: References: <20150719145740.GI28047@mournblade.imrryr.org> User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: "dane@ietf.org" Subject: Re: [dane] Another SMIMEA draft review 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 Jul 2015 10:37:31 -0000 On Mon, 20 Jul 2015, Wiley, Glen wrote: >> Which they'll also learn by just looking at the zone data, if the >> localparts are not hashed in the final spec. > > Has there been any recent discussion about using a non-hashed LHS > encoding? I dont think there has so we probably dont want to bring > that question into scope here. There was some interested by the powerdns people for this, as they implement an online signer and could deliver custom signed responses. John Levine also prefered this approach in the past. While I think the non-hash version is uglier, I don't think that is a valid reason not to do it. >> I'd be more concerned above passive monitoring, because with >> submission over port 587 with TLS, and forward hops from the MSA >> to the destination also increasingly over TLS, there is often at >> present no cleartext exposure of the envelope recipients. >> >> With SMIMEA, passive monitoring of DNS queries will often reveal >> the correspondent addresses. > > Obvious but worth a reminderpassive monitoring isnt a problem peculiar > to the SMIMEA approach, it is an issue for all elements of the email flow > that are not encrypted. I am assuming that SMTP traffic will be TLS for the majority, either authenticated or opportunistic. So I think the concern is somewhat valid. But we did say that the hash was not a security meassure. If we are going to use it as a security meassure we might have to think about making it stronger. Paul From nobody Mon Jul 20 06:47:32 2015 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 B0B2F1A886F for ; Mon, 20 Jul 2015 06:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 5QerMYICOVM4 for ; Mon, 20 Jul 2015 06:47:27 -0700 (PDT) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74F9E1A1B62 for ; Mon, 20 Jul 2015 06:47:27 -0700 (PDT) Received: by igvi1 with SMTP id i1so76953212igv.1 for ; Mon, 20 Jul 2015 06:47:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=Z7AMk6cHrI5PO4mXtbPWcntkkXDzGJdPulCj3NLkdXU=; b=NpdFsuKmG9mttDb7ILNBF5hqmuf5Roy1TqTMYyAywubkLeC2csJhtcEvmpELI142/D jKN9cYvncNx2kIA0zoFIJVYYECv005vL1w1PeYPTEOZ+BdupHf1+YbZxoWlfGwPUn46d VTEPSeUcv1k8/yKHEl7o1DbtcRcaj3h68SxfBAAPz3/9L+8MWrJW5DgvjaQlxomaboOc MV9O8v4ntWRNlPV6rE4/5fO3YS9GusGBnNCLo5OOl2exF8s0qDnW+30kL5gofy4tsCDk uA8RAte/WhN++i4BZzud35VogGXzGOhs7HuiynpZAveXoz2sWZdSQixf4PyJw7wSP+aR B9+g== MIME-Version: 1.0 X-Received: by 10.50.49.116 with SMTP id t20mr14968342ign.70.1437400046832; Mon, 20 Jul 2015 06:47:26 -0700 (PDT) Sender: naticklamb@gmail.com Received: by 10.79.35.159 with HTTP; Mon, 20 Jul 2015 06:47:26 -0700 (PDT) In-Reply-To: References: Date: Mon, 20 Jul 2015 15:47:26 +0200 X-Google-Sender-Auth: hCUesWLdvJVW_tLjfwfyG4tE-fY Message-ID: From: Richard Lamb To: dane@ietf.org Content-Type: multipart/alternative; boundary=047d7bdca29c3119e1051b4ec73a Archived-At: Subject: [dane] Fwd: Another SMIMEA draft review 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 Jul 2015 13:47:30 -0000 --047d7bdca29c3119e1051b4ec73a Content-Type: text/plain; charset=UTF-8 I have carefully read the draft-ietf-dane-smime-08 draft as well and have found no problems with it and find it clear and concise. Being better at engineering than reading+writing, I implemented the draft in the form of on-line record generator and outlook email translator and it works. Thanks to the authors for this draft. It was easy to follow. -Rick Lamb On Sun, Jul 19, 2015 at 3:52 PM, Rose, Scott wrote: > I have read the SMIMEA -08 draft and support it being "undeterred" and > put back on track. NIST also has some (old) test code that we want to host > and have sponsored SMIMEA work in the past. Our previous work has used the > format described in the current draft. > > > I have heard of two potential privacy concerns that the WG may want > included in the Security Considerations section: > > > First, if the _smimecert. is hosted by a service provider (i.e. > not the domain owner), the service provider can see who may be receiving > encrypted mail and may also learn the source IP address and other potential > information. Of course, the hosting provider also knows the whole list of > (hashed) cert holders in the domain as well. Pervasive monitoring may also > discover this (source IP A is looking for a cert for person X in order to > send them mail), but qname-minimization may mitigate this to a degree. > > > Second, clients looking to validate a digital signature using SMIMEA > queries may also be signaling a read receipt. If the original sender knows > the recursive servers of the recipient, The sender could get an idea as to > when the receiver MUA validated the digital signature by observing SMIMEA > queries to their domain. This isn't a showstopper IMHO as recipients with > cached digital signature certs may not send queries. > > > To summarize as some suggested text (as a starting point at least - not > happy with it, but it is the best my brain allows right now): > > > ***** > > In addition to the zone walking vulnerability, SMIMEA aware senders and > receivers may also leak information when querying for SMIMEA RRs for > validating digital signatures and discovering a recipient's S/MIME > encryption certificate. SMIMEA RR queries may leak information about who is > planning to send, or has receive S/MIME protected email messages. DNS > privacy techniques such as qname-minimization may mitigate some of the > leakage. > > > ***** > > > Scott > > > > --047d7bdca29c3119e1051b4ec73a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I have carefully read the draft-ietf-dane-smime-08 d= raft as well and have found no problems with it and find it clear and conci= se.

Being better at engineering than reading+writing, I = implemented the draft in the form of on-line record generator and outlook e= mail translator and it works.

Thanks to the author= s for this draft.=C2=A0 It was easy to follow.

-Ri= ck Lamb




On Sun, Jul 19, 2015 at 3:52 PM, Rose, Scott <scott.rose@ni= st.gov> wrote:

I have read the SMIMEA -08 draft and support it being "undeterred&q= uot; and put back on track.=C2=A0 NIST also has some (old) test code that w= e want to host and have sponsored SMIMEA work in the past.=C2=A0 Our previo= us work has used the format described in the current draft.


I have heard of two potential privacy concerns that the WG may want incl= uded in the Security Considerations section:


First, if the _smimecert.<domain> is hosted by a service provider = (i.e. not the domain owner), the service provider can see who may be receiv= ing encrypted mail and may also learn the source IP address and other poten= tial information.=C2=A0 Of course, the hosting provider also knows the whole list of (hashed) cert holders in the domain = as well.=C2=A0 Pervasive monitoring may also discover this (source IP A is = looking for a cert for person X in order to send them mail), but qname-mini= mization may mitigate this to a degree.


Second, clients looking to validate a digital signature using SMIMEA que= ries may also be signaling a read receipt.=C2=A0 If the original sender kno= ws the recursive servers of the recipient, The sender could get an idea as = to when the receiver MUA validated the digital signature by observing SMIMEA queries to their domain.=C2=A0 This = isn't a showstopper IMHO as recipients with cached digital signature ce= rts may not send queries.=C2=A0


To summarize as some suggested text (as a starting point at least - not = happy with it, but it is the best my brain allows right now):


*****

In addition to the zone walking vulnerability, SMIMEA aware senders and = receivers may also leak information when querying for SMIMEA RRs for valida= ting digital signatures and discovering a recipient's S/MIME encryption= certificate. SMIMEA RR queries may leak information about who is planning to send, or has receive S/MIME prot= ected email messages.=C2=A0 DNS privacy techniques such as qname-minimizati= on may mitigate some of the leakage. =C2=A0


*****


Scott





--047d7bdca29c3119e1051b4ec73a-- From nobody Mon Jul 20 07:42:08 2015 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 330311A88FD for ; Mon, 20 Jul 2015 07:42:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, 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 SEnAxMLc9gIe for ; Mon, 20 Jul 2015 07:42:05 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.22.87]) (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 9CAE11A8954 for ; Mon, 20 Jul 2015 07:42:05 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id EE7C11E0B9; Mon, 20 Jul 2015 14:42:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1437403325; bh=ocXGVeaYPUBJ2R/hRNX4VAuCgnHrOzs+NSkbe32/VTk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=TudX201iJUsgli57AP4jZt7sGV0eDPdfGj5LJQXiEKXpGg9IuNlR7lj38Fc2LBKWA sb7GFL3IlatJEbFtLLOAT9XZs5UJPOXIWo6uADeUzwdiq8vRR8gqBnqicQLVvaxfgJ 3IeTsm43XyTpii+PijWHfMVJjItzi6/cn09aKBcs= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 36DF9106FD881; Mon, 20 Jul 2015 14:41:08 +0000 (UTC) From: James Cloos To: Olafur Gudmundsson In-Reply-To: (Olafur Gudmundsson's message of "Mon, 20 Jul 2015 05:08:58 -0400") References: User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2015 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, 20 Jul 2015 10:41:08 -0400 Message-ID: Lines: 15 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:28:150720:ogud@ogud.com::Zm5OLn3K8O9A+taj:000Co5pu X-Hashcash: 1:28:150720:dane@ietf.org::yAesgEP8l2avSPS6:00070OHc Archived-At: Cc: dane Subject: Re: [dane] Discussion on OPENPGP and SMIME record location 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 Jul 2015 14:42:07 -0000 They should be at the same place even though multiple lookups are likely to be required anyway -- not everything will fully support an ANY query. And I renew my (previously ignored) suggestion that they, along with tlsa records for client certs where the cn or other lookup -- such as a sip url or the like -- has an @ in it -- be under _at. Mapping @ to _at makes it easy to remember and easy to read. Similarrly, the function mapping the local part to a dns element also should be the same for every record type. Whatever that function should be. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Mon Jul 20 07:52:04 2015 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 4C0C71A8A0E for ; Mon, 20 Jul 2015 07:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 oHyTnfO07opC for ; Mon, 20 Jul 2015 07:52:02 -0700 (PDT) Received: from mail-qg0-f100.google.com (mail-qg0-f100.google.com [209.85.192.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0F251A896A for ; Mon, 20 Jul 2015 07:52:01 -0700 (PDT) Received: by qgy5 with SMTP id 5so2196959qgy.3 for ; Mon, 20 Jul 2015 07:52:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:user-agent:content-type:content-id :content-transfer-encoding:mime-version; bh=sMP5aFwzGkS8536jaq25JuIwW8S05pZJxZRVigfynxg=; b=lS8izUsKeZk/+zxjxDZZ2bXjIQ2loKCycak7pdeyxLPohBEdPqNdC2CPG/pkkqwNjS C6WjYKZ75XxPd59rLHCN2os2JHOuDfXRxM8W6nJfT6cFmEPN4ZKtoOlahMhifhwXqK+8 HmVKUm+YlfbSE94xJ1WXng7KvNPlRD7wfuiYjSqaE8sy7EdkCBDtfpbvoI7rz+SNcOpl RqCSdlt8SPkriYmD2hFloiP2e+u2MNIo/mvf+8ieB/B/JPOuSN3tp4LcfK5RjrC47/n/ wwQPMUIDStpkH8TV0K+Ey+5+Gd8ahhcZLfQsokh7HAByDlpGHpIghh1qTt80iUXNpL8Y zk2Q== X-Gm-Message-State: ALoCoQmQ6VJZJdP8EmgjOuJoOT04Ad8ziSat6k1REzOa5lJxvZMFJdBTGP7t3JhLZB27TlBTubl3JSnEq2LQqt4q4miz9Liu4w== X-Received: by 10.140.217.84 with SMTP id n81mr41978500qhb.100.1437403921072; Mon, 20 Jul 2015 07:52:01 -0700 (PDT) Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by smtp-relay.gmail.com with ESMTPS id p9sm900905qkh.2.2015.07.20.07.52.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 20 Jul 2015 07:52:01 -0700 (PDT) X-Relaying-Domain: verisign.com Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01 [10.173.152.205]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id t6KEpuVU031329 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 20 Jul 2015 10:51:59 -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 Jul 2015 10:51:55 -0400 From: "Wiley, Glen" To: James Cloos , Olafur Gudmundsson Thread-Topic: [dane] Discussion on OPENPGP and SMIME record location Thread-Index: AQHQwsvAX05qNEnwQkG5k5GXVtLROZ3kbva7gAACqgA= Date: Mon, 20 Jul 2015 14:51:55 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <06E4B4269D941C4E893E02D82DCBF10D@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: dane Subject: Re: [dane] Discussion on OPENPGP and SMIME record location 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 Jul 2015 14:52:03 -0000 On 7/20/15, 10:41 AM, "James Cloos" wrote: >They should be at the same place even though multiple lookups are likely >to be required anyway -- not everything will fully support an ANY query. I like the idea of using a consistent encoding for anything that uses a locator constructed forma user name. The use case for end user key material is such that multiple lookups cause far less pain than multiple lookups getting in the way of rendering a browser page. > >And I renew my (previously ignored) suggestion that they, along with >tlsa records for client certs where the cn or other lookup -- such as >a sip url or the like -- has an @ in it -- be under _at. > >Mapping @ to _at makes it easy to remember and easy to read. Does it make sense to add encoding for the @ since the hashes are unreadable? > >Similarrly, the function mapping the local part to a dns element also >should be the same for every record type. Whatever that function should >be. > >-JimC >--=20 >James Cloos OpenPGP: 0x997A9F17ED7DAEA6 > >_______________________________________________ >dane mailing list >dane@ietf.org >https://www.ietf.org/mailman/listinfo/dane From nobody Mon Jul 20 08:11:05 2015 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 3C1F81A8AC2 for ; Mon, 20 Jul 2015 08:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 I28x4Kriisxn for ; Mon, 20 Jul 2015 08:11:03 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5A0E1A8A51 for ; Mon, 20 Jul 2015 08:11:02 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id DF165284D68; Mon, 20 Jul 2015 15:11:01 +0000 (UTC) Date: Mon, 20 Jul 2015 15:11:01 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150720151101.GB28047@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: Subject: Re: [dane] Discussion on OPENPGP and SMIME record location 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 Jul 2015 15:11:04 -0000 On Mon, Jul 20, 2015 at 10:41:08AM -0400, James Cloos wrote: > They should be at the same place even though multiple lookups are likely > to be required anyway -- not everything will fully support an ANY query. > > And I renew my (previously ignored) suggestion that they, along with > tlsa records for client certs where the cn or other lookup -- such as > a sip url or the like -- has an @ in it -- be under _at. > > Mapping @ to _at makes it easy to remember and easy to read. Mnemonic value notwithstanding, the main advantage of _at is that that it is *short*. So if the namespaces are unified (segregated only by RRtype not qname), then "_at", seems like a sensible choice of generic empty non-terminal. In terms of query efficiency, if there are any MUAs out there that support both OpenPGP and SMIME, and try to find either set of keys, then a common qname that yields NXDOMAIN is likely to cached by the iterative resolver just long enough to save a full round-trip just to find out that neither set of keys exists. -- Viktor. From nobody Mon Jul 20 08:17:38 2015 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 696531A8F41 for ; Mon, 20 Jul 2015 08:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ZstXWtW5bPzG for ; Mon, 20 Jul 2015 08:17:34 -0700 (PDT) Received: from mail-qg0-f100.google.com (mail-qg0-f100.google.com [209.85.192.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D9621A8AF6 for ; Mon, 20 Jul 2015 08:17:19 -0700 (PDT) Received: by qgal74 with SMTP id l74so5044200qga.2 for ; Mon, 20 Jul 2015 08:17:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :user-agent:content-type:content-id:content-transfer-encoding :mime-version; bh=/xmuPwh3d3SgBviPwq2qX0kJLo6Cwzsc5/OBFeWwclo=; b=X67lxHZSVCnxRR6Xgk6ApxFyenprQY9aqlN7TDzL4jcXksEFSlDXCWL4RnbyFTD9GB ebpdy/fxZ3G9hJG9/yF6uin2m96AIufS896yF7mt0MAL7Cc7vCiozzi+d0WUXbRqkdhW IbDVTnks1kmPwBeZIYqqbtVfpKJeeJt2no9wspTeK54dK1ynVMZKqKXE+4It24AP73PJ Lgvl89yTMCO1+2znnPZyKZZV5PfUT2YNQEWNaj7ZqVZFMwjjL9j+n+pajFSrX6RD1F2H 7P9PGG7hpUYrBgdm7dIA5cPaZgtpe1AIwVBvXbvupOj2BlCjhD1VAwZhOY6LmJ2LXPh1 +pHQ== X-Gm-Message-State: ALoCoQmm0+BS10zoBuNXRtbqX/wnL9KrJd8pym3FKD66tMR5tc6ktU6oIOqnJLF25s6yoP2SnHA6Eq62kB9a0H/eeCVP5FRXDA== X-Received: by 10.140.28.247 with SMTP id 110mr46660223qgz.16.1437405438542; Mon, 20 Jul 2015 08:17:18 -0700 (PDT) Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by smtp-relay.gmail.com with ESMTPS id 1sm7006028qkx.1.2015.07.20.08.17.18 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 20 Jul 2015 08:17:18 -0700 (PDT) X-Relaying-Domain: verisign.com Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01 [10.173.152.255]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id t6KFHIKK001986 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 20 Jul 2015 11:17:18 -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 Jul 2015 11:17:17 -0400 From: "Wiley, Glen" To: "dane@ietf.org" Thread-Topic: [dane] Discussion on OPENPGP and SMIME record location Thread-Index: AQHQwsvAX05qNEnwQkG5k5GXVtLROZ3kbva7gABLFID//76uAA== Date: Mon, 20 Jul 2015 15:17:17 +0000 Message-ID: References: <20150720151101.GB28047@mournblade.imrryr.org> In-Reply-To: <20150720151101.GB28047@mournblade.imrryr.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <68D2B8071C8B294B8FCBED973EBD7F45@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [dane] Discussion on OPENPGP and SMIME record location 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 Jul 2015 15:17:36 -0000 After reading your response it occurs to me that James was suggesting adding _at as a label rather than encoding it in the hash - makes more sense. Having said that, I still question whether _at really helps much since humans aren=B9t likely to read/write the encoded user name. Even if we decide to not hash the user name it will need to be encoded because of special characters. On 7/20/15, 11:11 AM, "Viktor Dukhovni" wrote: >On Mon, Jul 20, 2015 at 10:41:08AM -0400, James Cloos wrote: > >> They should be at the same place even though multiple lookups are likely >> to be required anyway -- not everything will fully support an ANY query. >>=20 >> And I renew my (previously ignored) suggestion that they, along with >> tlsa records for client certs where the cn or other lookup -- such as >> a sip url or the like -- has an @ in it -- be under _at. >>=20 >> Mapping @ to _at makes it easy to remember and easy to read. > >Mnemonic value notwithstanding, the main advantage of _at is that >that it is *short*. So if the namespaces are unified (segregated >only by RRtype not qname), then "_at", seems like a sensible choice >of generic empty non-terminal. > >In terms of query efficiency, if there are any MUAs out there that >support both OpenPGP and SMIME, and try to find either set of keys, >then a common qname that yields NXDOMAIN is likely to cached by >the iterative resolver just long enough to save a full round-trip >just to find out that neither set of keys exists. > >--=20 > Viktor. > >_______________________________________________ >dane mailing list >dane@ietf.org >https://www.ietf.org/mailman/listinfo/dane From nobody Mon Jul 20 08:32:54 2015 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 9A7CB1A8AB7 for ; Mon, 20 Jul 2015 08:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 PnjvYlVSHHRw for ; Mon, 20 Jul 2015 08:32:51 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 248EB1A8AF6 for ; Mon, 20 Jul 2015 08:32:22 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 5210F284D68; Mon, 20 Jul 2015 15:32:21 +0000 (UTC) Date: Mon, 20 Jul 2015 15:32:21 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150720153221.GC28047@mournblade.imrryr.org> References: <20150720151101.GB28047@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: Subject: Re: [dane] Discussion on OPENPGP and SMIME record location 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 Jul 2015 15:32:52 -0000 On Mon, Jul 20, 2015 at 03:17:17PM +0000, Wiley, Glen wrote: > After reading your response it occurs to me that James was suggesting > adding _at as a label rather than encoding it in the hash - makes > more sense. Specifically: ._at.example.com. IN SMIMEA 3 0 0 ._at.example.com. IN OPENPGPKEY 3 0 0 are shorter than: ._smimecert.example.com. IN SMIMEA 3 0 0 ._openpgpkey.example.com. IN OPENPGPKEY 3 0 0 > Having said that, I still question whether _at really helps much since > humans aren't likely to read/write the encoded user name. Even if we > decide to not hash the user name it will need to be encoded because of > special characters. The advantage is for the administrator managing the zone, not the user querying it, and shorter labels reduce the pressure (if any) on the combined length limit of 255 for the full qname. I can't claim that this is a compelling rationale, but it makes sense to me. -- Viktor. From nobody Mon Jul 20 09:12:19 2015 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 183271A9085 for ; Mon, 20 Jul 2015 09:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.195 X-Spam-Level: X-Spam-Status: No, score=0.195 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 fmWsxtI3gurl for ; Mon, 20 Jul 2015 09:12:16 -0700 (PDT) Received: from shannon.7bits.nl (shannon.7bits.nl [89.188.0.40]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 198341A9030 for ; Mon, 20 Jul 2015 09:12:16 -0700 (PDT) Received: from [192.168.137.1] (dhcp-b448.meeting.ietf.org [31.133.180.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: peter) by shannon.7bits.nl (Postfix) with ESMTPSA id 7D555C1B55; Mon, 20 Jul 2015 18:12:14 +0200 (CEST) From: "Peter van Dijk" To: "dane@ietf.org" Date: Mon, 20 Jul 2015 18:12:12 +0200 Message-ID: In-Reply-To: References: <20150719145740.GI28047@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.1r5084) Archived-At: Subject: Re: [dane] Another SMIMEA draft review 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 Jul 2015 16:12:18 -0000 Hello, On 20 Jul 2015, at 12:29, Paul Wouters wrote: > On Mon, 20 Jul 2015, Wiley, Glen wrote: > >> Has there been any recent discussion about using a non-hashed LHS >> encoding? I don¹t think there has so we probably don¹t want to >> bring >> that question into scope here. > > There was some interested by the powerdns people for this, as they > implement an online signer and could deliver custom signed responses. > John Levine also prefered this approach in the past. Indeed - *not* doing the hashing has many potential benefits (most of which do require online signing to fully reap), and few downsides. Split base32 massively increases the potential surface area for opportunistic encryption, while hashing strictly rules out those benefits. Besides the functional benefits, base32 also is easier for debugging. So far I’ve seen two downsides to split base32 mentioned: (1) split base32 has a longer maximum length than a hash (although in practice it will actually be shorter than a hash, for most addresses) (2) privacy As Paul mentions further down this thread, if we start caring about privacy we have more work to do. > While I think the non-hash version is uglier, I don't think that is > a valid reason not to do it. I don’t think any of the options look pretty - including base32. This fate we have to accept when shoehorning things into the DNS! Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ From nobody Mon Jul 20 09:39:55 2015 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 533961ACDEA for ; Mon, 20 Jul 2015 09:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 C4-bFJBbAQi4 for ; Mon, 20 Jul 2015 09:39:53 -0700 (PDT) Received: from mail-qg0-f97.google.com (mail-qg0-f97.google.com [209.85.192.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5F171ACDB3 for ; Mon, 20 Jul 2015 09:39:52 -0700 (PDT) Received: by qgii95 with SMTP id i95so5958185qgi.0 for ; Mon, 20 Jul 2015 09:39:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :content-type:content-id:content-transfer-encoding:mime-version; bh=+3utuQtoMp8sD32/eJBtznLJZj1/voqdD9erGRtMfK8=; b=I7cLFOhNS86sffS/BovlWQX5eLUdms6rtogXOmHfv5zcZxyF0/mITXjdDG4TLESjQD W2og3KFef4Nf+fn0hmFLPzP/wEZvSQBsK6ReWVzuAmcGEzknkrbQUkaOE9Z77uWDhNjB pfDciPth9cOY9nymLgry6bQX4nUcAlueUP+2Te6WVlE/+yO14BR57jgckXqB+NJeFqrX 9qFq2+9i/08agGvSs6SZytCviHsqucr+p6jiN8ILaOkalqrKJZO2fAZRK6Ckwe1PlJgF 8eukxOrSJlVnZMpSFlnWvKxAfTqYbAz/XFojIrjPROS+MivfLoqjEn8YkgaUus7GWvFy UfPQ== X-Gm-Message-State: ALoCoQltumj7YWcR4PqfVKbSrvHasXTeHaYA5P7Cwvyv6criC3h8H0XOFyqy7G0/I5W+9+iuZENz1sLenBYXyZb7CG4/jrqE2g== X-Received: by 10.140.89.197 with SMTP id v63mr46751291qgd.97.1437410391971; Mon, 20 Jul 2015 09:39:51 -0700 (PDT) Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by smtp-relay.gmail.com with ESMTPS id 93sm1492845qks.4.2015.07.20.09.39.51 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 20 Jul 2015 09:39:51 -0700 (PDT) X-Relaying-Domain: verisign.com Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01 [10.173.152.255]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id t6KGdpHP012110 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 20 Jul 2015 12:39:51 -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 Jul 2015 12:39:50 -0400 From: "Osterweil, Eric" To: "dane@ietf.org" Thread-Topic: [dane] Discussion on OPENPGP and SMIME record location Thread-Index: AQHQwsvAwSsv5r4B8k6N87I+i8hUlp3kbvaNgABLFICAAAHAgIAABDaAgAAS2YA= Date: Mon, 20 Jul 2015 16:39:49 +0000 Message-ID: <061BA95A-60D5-4872-97D4-03D5F39AF4A9@verisign.com> References: <20150720151101.GB28047@mournblade.imrryr.org> <20150720153221.GC28047@mournblade.imrryr.org> In-Reply-To: <20150720153221.GC28047@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="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [dane] Discussion on OPENPGP and SMIME record location 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 Jul 2015 16:39:54 -0000 DQo+IE9uIEp1bCAyMCwgMjAxNSwgYXQgMTE6MzIgQU0sIFZpa3RvciBEdWtob3ZuaSA8aWV0Zi1k YW5lQGR1a2hvdm5pLm9yZz4gd3JvdGU6DQo+IA0KPiBPbiBNb24sIEp1bCAyMCwgMjAxNSBhdCAw MzoxNzoxN1BNICswMDAwLCBXaWxleSwgR2xlbiB3cm90ZToNCj4gDQo+PiBBZnRlciByZWFkaW5n IHlvdXIgcmVzcG9uc2UgaXQgb2NjdXJzIHRvIG1lIHRoYXQgSmFtZXMgd2FzIHN1Z2dlc3RpbmcN Cj4+IGFkZGluZyBfYXQgYXMgYSBsYWJlbCByYXRoZXIgdGhhbiBlbmNvZGluZyBpdCBpbiB0aGUg aGFzaCAtIG1ha2VzDQo+PiBtb3JlIHNlbnNlLg0KPiANCj4gU3BlY2lmaWNhbGx5Og0KPiANCj4g ICAgPHNvbWUtbG9jYWwtcGFydC1lbmNvZGluZz4uX2F0LmV4YW1wbGUuY29tLiBJTiBTTUlNRUEg MyAwIDAgPGxlYWYtY2VydGlmaWNhdGU+DQo+ICAgIDxzb21lLWxvY2FsLXBhcnQtZW5jb2Rpbmc+ Ll9hdC5leGFtcGxlLmNvbS4gSU4gT1BFTlBHUEtFWSAzIDAgMCA8cHVibGljLWtleXJpbmc+DQo+ IA0KPiBhcmUgc2hvcnRlciB0aGFuOg0KPiANCj4gICAgPHNvbWUtbG9jYWwtcGFydC1lbmNvZGlu Zz4uX3NtaW1lY2VydC5leGFtcGxlLmNvbS4gIElOIFNNSU1FQSAzIDAgMCA8bGVhZi1jZXJ0aWZp Y2F0ZT4NCj4gICAgPHNvbWUtbG9jYWwtcGFydC1lbmNvZGluZz4uX29wZW5wZ3BrZXkuZXhhbXBs ZS5jb20uIElOIE9QRU5QR1BLRVkgMyAwIDAgPHB1YmxpYy1rZXlyaW5nPg0KPiANCj4gDQo+PiBI YXZpbmcgc2FpZCB0aGF0LCBJIHN0aWxsIHF1ZXN0aW9uIHdoZXRoZXIgX2F0IHJlYWxseSBoZWxw cyBtdWNoIHNpbmNlDQo+PiBodW1hbnMgYXJlbid0IGxpa2VseSB0byByZWFkL3dyaXRlIHRoZSBl bmNvZGVkIHVzZXIgbmFtZS4gIEV2ZW4gaWYgd2UNCj4+IGRlY2lkZSB0byBub3QgaGFzaCB0aGUg dXNlciBuYW1lIGl0IHdpbGwgbmVlZCB0byBiZSBlbmNvZGVkIGJlY2F1c2Ugb2YNCj4+IHNwZWNp YWwgY2hhcmFjdGVycy4NCj4gDQo+IFRoZSBhZHZhbnRhZ2UgaXMgZm9yIHRoZSBhZG1pbmlzdHJh dG9yIG1hbmFnaW5nIHRoZSB6b25lLCBub3QgdGhlDQo+IHVzZXIgcXVlcnlpbmcgaXQsIGFuZCBz aG9ydGVyIGxhYmVscyByZWR1Y2UgdGhlIHByZXNzdXJlIChpZiBhbnkpDQo+IG9uIHRoZSBjb21i aW5lZCBsZW5ndGggbGltaXQgb2YgMjU1IGZvciB0aGUgZnVsbCBxbmFtZS4NCj4gDQo+IEkgY2Fu J3QgY2xhaW0gdGhhdCB0aGlzIGlzIGEgY29tcGVsbGluZyByYXRpb25hbGUsIGJ1dCBpdCBtYWtl cw0KPiBzZW5zZSB0byBtZS4NCg0KDQpBbm90aGVyIHBvaW50OiB0aGUgY2hhbmNlcyB0aGF0IGEg em9uZSBtYXkgYWxyZWFkeSB3YW50IHRvIHVzZSBgYF9hdOKAmeKAmSBmb3Igc29tZSBvdGhlciBy ZWFzb25zIChhbmQgdGh1cyBjYXVzaW5nIGEgY29sbGlzaW9uKSBhcmUgaGlnaGVyIHRoYW4gdGhl IG1vcmUgZGVzY3JpcHRpdmUgYGBfb3BlbnBncGtleSzigJnigJkgb3IgYGBfc21pbWVjZXJ04oCZ 4oCZIGxhYmVscy4gIEFzIG9mIG5vdywgaXQgc2VlbXMgdmVyeSB1bmxpa2VseSAoaW1obykgdGhh dCBhIHpvbmUgd291bGQgYWxyZWFkeSBiZSB1c2luZyB0aG9zZSBsYXR0ZXIgbGFiZWxzIGZvciBz b21ldGhpbmcgZWxzZSwgYnV0IEkgd291bGQgaGVzaXRhdGUgdG8gc2F5IHRoZSBzYW1lIGFib3V0 IHRoZSBmb3JtZXIuICBOb3QgdG8gbWVudGlvbiwgYmVpbmcgZGVzY3JpcHRpdmUgaW4gb3VyIGxh YmVscyBjb3VsZCBiZSBhZHZhbnRhZ2VvdXMgZm9yIHJlYXNvbnMgSSB0aGluayBJIGhhdmUgc2Vl biBvdGhlcnMgbWVudGlvbiBvbiB0aGUgbGlzdC4NCg0KRXJpYw== From nobody Mon Jul 20 09:42:58 2015 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 13E7B1ACD61 for ; Mon, 20 Jul 2015 09:42:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 fhZlCA6MkLIz for ; Mon, 20 Jul 2015 09:42:56 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E044B1ACE09 for ; Mon, 20 Jul 2015 09:42:55 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id BDDD6284D68; Mon, 20 Jul 2015 16:42:54 +0000 (UTC) Date: Mon, 20 Jul 2015 16:42:54 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150720164254.GF28047@mournblade.imrryr.org> References: <20150720151101.GB28047@mournblade.imrryr.org> <20150720153221.GC28047@mournblade.imrryr.org> <061BA95A-60D5-4872-97D4-03D5F39AF4A9@verisign.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <061BA95A-60D5-4872-97D4-03D5F39AF4A9@verisign.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] Discussion on OPENPGP and SMIME record location 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 Jul 2015 16:42:57 -0000 On Mon, Jul 20, 2015 at 04:39:49PM +0000, Osterweil, Eric wrote: > Another point: the chances that a zone may already want to use "_at" > for some other reasons (and thus causing a collision) are higher than the > more descriptive "_openpgpkey," or "_smimecert" labels. There's no "collision". The records are disambiguated well enough by the RRtype. Few enough domains are using "_at", to make this a concern. -- Viktor. From nobody Mon Jul 20 09:43:53 2015 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 37FBD1A9095 for ; Mon, 20 Jul 2015 09:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, 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 YGs_U79CQsZA for ; Mon, 20 Jul 2015 09:43:51 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.22.87]) (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 449A91A885A for ; Mon, 20 Jul 2015 09:43:51 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id E8A7B1E0B9; Mon, 20 Jul 2015 16:43:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1437410630; bh=E3WTkdJztoPH2w+60IlPIOsu1UPykSVUD3nfG1CbHpA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ORJlLRVgK7LzlGCYYEg4vpVg41d6CLZrNNWUs7HWSlvwC46DO902ACI9fTI7RpeB+ aAfARNI+mHLkd0MysDe9kvLLRoFmMaXDNIihbbkRDP1okTJ79yiVC/LTizoT8IAdJV yMIj5uCoeIzg4tYL+9nErjrIJMc4o5xMv4zuQDEM= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 0545A106FD881; Mon, 20 Jul 2015 16:42:31 +0000 (UTC) From: James Cloos To: "Wiley\, Glen" In-Reply-To: (Glen Wiley's message of "Mon, 20 Jul 2015 14:51:55 +0000") References: User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2015 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, 20 Jul 2015 12:42:30 -0400 Message-ID: Lines: 16 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:28:150720:gwiley@verisign.com::FpfN4IGjxANgEu+V:0000000000000000000000000000000000000000000w6t X-Hashcash: 1:28:150720:ogud@ogud.com::tCd3G/23E5JaY5ub:000AS18I X-Hashcash: 1:28:150720:dane@ietf.org::2y0Nqbqk19c9J8Lq:000JcFfe Archived-At: Cc: dane Subject: Re: [dane] Discussion on OPENPGP and SMIME record location 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 Jul 2015 16:43:52 -0000 >>>>> "WG" == Wiley, Glen writes: >> Mapping @ to _at makes it easy to remember and easy to read. WG> Does it make sense to add encoding for the @ since the hashes are WG> unreadable? Putting f(local-part) into the dns w/o some sort of separator label may increase the size of ANY requests for the apex zone enough to require edns or tcp, so some separator label SHOULD be used. And what is simpler and more efficiend than makking @ to _at? -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Mon Jul 20 10:06:13 2015 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 340D11B2C66 for ; Mon, 20 Jul 2015 10:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Goh3lRBzcEmB for ; Mon, 20 Jul 2015 10:06:06 -0700 (PDT) Received: from mail-qg0-f98.google.com (mail-qg0-f98.google.com [209.85.192.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDC151ACEAF for ; Mon, 20 Jul 2015 10:06:04 -0700 (PDT) Received: by qgal74 with SMTP id l74so5223817qga.2 for ; Mon, 20 Jul 2015 10:06:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :content-type:content-id:content-transfer-encoding:mime-version; bh=2NrFQvJw8OLLDW3jhisCeWh1smcwUYRFhiEdZ+svbc4=; b=Z7VTRmo0OSsayi2KOzWBZhteroUNemLaSeN49lPhKYF6mO9vacuBONiUy9qxp31dTM ywvidpj29AeSMtWv8gEN/ptjzWTIlsAqZ4DNvSIdktpdcp5CYfqOevlZNyCqhkvpQiAu TdC2sQnRzVNZgb4kH+UlXcS9fM+5PejF6dnw3oVPAUayP6L9/xtxZDuDG57ot/ST7srm UzYCl4aYx3yWJF1pK9B1OZnW5+5w39L/u5oeFDg3gJksl8cjzA6Ou1CIxcRe15/gSQYp woKh/W2oXwL3+2+4Up0E3PBEE5R+QAO4t74RjvsORcO8vFdQYNcJBhNw1mnlTHRqwJeC XG5w== X-Gm-Message-State: ALoCoQm53PNPZJ6vOLobkWWzUuVaNUNWuKIe9vegPTDiGYXaMK8ZXX8hq6bAlHQ8UAUXQkZviFZ0xBBCKwgMGIh8ZTf42TQSdA== X-Received: by 10.55.23.104 with SMTP id i101mr34705777qkh.23.1437411963964; Mon, 20 Jul 2015 10:06:03 -0700 (PDT) Received: from brn1lxmailout01.verisign.com (brn1lxmailout01.verisign.com. [72.13.63.41]) by smtp-relay.gmail.com with ESMTPS id 93sm1516284qks.4.2015.07.20.10.06.03 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 20 Jul 2015 10:06:03 -0700 (PDT) X-Relaying-Domain: verisign.com Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01 [10.173.152.205]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id t6KH63LE003112 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 20 Jul 2015 13:06:03 -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 Jul 2015 13:06:03 -0400 From: "Osterweil, Eric" To: "dane@ietf.org" Thread-Topic: [dane] Discussion on OPENPGP and SMIME record location Thread-Index: AQHQwsvAwSsv5r4B8k6N87I+i8hUlp3kbvaNgABLFICAAAHAgIAABDaAgAAS2YCAAADdAIAABnWA Date: Mon, 20 Jul 2015 17:06:02 +0000 Message-ID: <85A52988-93FB-4B00-84AE-97CD98D304C4@verisign.com> References: <20150720151101.GB28047@mournblade.imrryr.org> <20150720153221.GC28047@mournblade.imrryr.org> <061BA95A-60D5-4872-97D4-03D5F39AF4A9@verisign.com> <20150720164254.GF28047@mournblade.imrryr.org> In-Reply-To: <20150720164254.GF28047@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="utf-8" Content-ID: <64BBB0DD577572428851A3E54EA2F589@verisign.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [dane] Discussion on OPENPGP and SMIME record location 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 Jul 2015 17:06:08 -0000 DQo+IE9uIEp1bCAyMCwgMjAxNSwgYXQgMTI6NDIgUE0sIFZpa3RvciBEdWtob3ZuaSA8aWV0Zi1k YW5lQGR1a2hvdm5pLm9yZz4gd3JvdGU6DQo+IA0KPiBPbiBNb24sIEp1bCAyMCwgMjAxNSBhdCAw NDozOTo0OVBNICswMDAwLCBPc3RlcndlaWwsIEVyaWMgd3JvdGU6DQo+IA0KPj4gQW5vdGhlciBw b2ludDogdGhlIGNoYW5jZXMgdGhhdCBhIHpvbmUgbWF5IGFscmVhZHkgd2FudCB0byB1c2UgIl9h dCINCj4+IGZvciBzb21lIG90aGVyIHJlYXNvbnMgKGFuZCB0aHVzIGNhdXNpbmcgYSBjb2xsaXNp b24pIGFyZSBoaWdoZXIgdGhhbiB0aGUNCj4+IG1vcmUgZGVzY3JpcHRpdmUgIl9vcGVucGdwa2V5 LCIgb3IgIl9zbWltZWNlcnQiIGxhYmVscy4NCj4gDQo+IFRoZXJlJ3Mgbm8gImNvbGxpc2lvbiIu ICBUaGUgcmVjb3JkcyBhcmUgZGlzYW1iaWd1YXRlZCB3ZWxsIGVub3VnaA0KPiBieSB0aGUgUlJ0 eXBlLiAgDQoNClRoYXQgd291bGQgZGVwZW5kIG9uIGhvdyB0aGUgYWRtaW5pc3RyYXRvciBvZiB0 aGUgem9uZSBwbGFucyB0byB1c2UgdGhlaXIgb3duIG5hbWVzcGFjZS4NCg0KPiBGZXcgZW5vdWdo IGRvbWFpbnMgYXJlIHVzaW5nICJfYXQiLCB0byBtYWtlIHRoaXMNCj4gYSBjb25jZXJuLg0KDQpJ IHdvbmRlciBob3cgbWFueSBpcyBlbm91Z2ggdG8gd2FycmFudCBjb25jZXJuPyAgQWhlYWQgb2Yg dGhhdCwgSeKAmW0gdGFraW5nIHNvbWUgbWVhc3VyZW1lbnRzIHRvIHNlZSB3aGF0IEkgY2FuIG9i c2VydmUuDQoNCkVyaWM= From nobody Mon Jul 20 11:28:54 2015 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 203C41B2A9A for ; Mon, 20 Jul 2015 11:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, 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 CWOVT4cUTGvq for ; Mon, 20 Jul 2015 11:28:52 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 295541A1B12 for ; Mon, 20 Jul 2015 11:28:52 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id B4C601E0B9; Mon, 20 Jul 2015 18:28:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1437416931; bh=yFN92sRg8fiwxs1Jgh+6kUWRj5/w+Sw0itwyuTSWQ18=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=DufgAGtnw/qoM6Yb1rsAWes4dcfaWU1f9x8Mj1GySOXMduSW/N9PppnU5iLm2WxgV cbfiOhxaR2ueBVcipqjkEN4GTFB0q/fVvlJLgc/EcpfZDAYXLGlxZQrCZ9ggpdFkzk OxbrLTvQLE8rTTZn2tP3aqVRkF0okElDYYgIvRt0= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 92054106FD888; Mon, 20 Jul 2015 18:26:59 +0000 (UTC) From: James Cloos To: dane@ietf.org In-Reply-To: <20150720151101.GB28047@mournblade.imrryr.org> (Viktor Dukhovni's message of "Mon, 20 Jul 2015 15:11:01 +0000") References: <20150720151101.GB28047@mournblade.imrryr.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2015 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, 20 Jul 2015 14:26:59 -0400 Message-ID: Lines: 10 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:28:150720:dane@ietf.org::sPYIUytENVVHIklA:000KRygX X-Hashcash: 1:28:150720:ietf-dane@dukhovni.org::hYeq8ZWNQdPemWKi:00000000000000000000000000000000000000KrDGZ Archived-At: Subject: Re: [dane] Discussion on OPENPGP and SMIME record location 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 Jul 2015 18:28:53 -0000 >>>>> "VD" == Viktor Dukhovni writes: VD> Mnemonic value notwithstanding, the main advantage of _at is that VD> that it is *short*. Yes, short was one of the motivations. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Mon Jul 20 16:08:20 2015 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 4A95A1AC3D5 for ; Mon, 20 Jul 2015 16:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 7hwWwYKhYOPI for ; Mon, 20 Jul 2015 16:08:17 -0700 (PDT) Received: from mail-oi0-f99.google.com (mail-oi0-f99.google.com [209.85.218.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 892741A92AB for ; Mon, 20 Jul 2015 16:08:17 -0700 (PDT) Received: by oiho132 with SMTP id o132so9102779oih.2 for ; Mon, 20 Jul 2015 16:08:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :user-agent:content-type:content-id:content-transfer-encoding :mime-version; bh=UmPf/YpRXbjiB0HxqjJ/2I/QC23FVpnifqu/OSkWipo=; b=PwkfXhODM/8yBrsa7Da9+CQaLCoAwQfrfOUnwLWz2Gwa3b+5aJ/2bJMvYzqQaVJb66 LDDl3wO69eY9eERja86QMoINgAPvDgE2kz6L/gH6XE4myS/cTY+fsxUucdjRYeG0oiJX 4Swyw2Olc5pr9qJTuH+ICZ+HGrzLWTSdZhIrIv2DOFaTvsaboL3OFeN8WBq3Unbn3+eQ VLrcneB+5onKwK6a2cfOzNUbo08MZBGlP1mzgVDD5QnSGECO9AZGKb0wIuQQObetjQ+a 1f1+d//BVteKzYwnivWiIyvBP2iPUUWsvrQEIdcXPxY71DauagJl84/4LpwvWQ1t9yfS /cWA== X-Gm-Message-State: ALoCoQmZKXLRjsPYcSAWlxmJZo9kVLYSa5PLew70+fzc5mFR9u1s8JmyHLoZAIhO5wDAOG4m+VUp7Al2UrkrtBnEaIKySMcCLw== X-Received: by 10.140.92.241 with SMTP id b104mr1907429qge.55.1437433696805; Mon, 20 Jul 2015 16:08:16 -0700 (PDT) Received: from brn1lxmailout01.verisign.com (brn1lxmailout01.verisign.com. [72.13.63.41]) by smtp-relay.gmail.com with ESMTPS id p9sm1338120qkh.2.2015.07.20.16.08.16 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 20 Jul 2015 16:08:16 -0700 (PDT) X-Relaying-Domain: verisign.com Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01 [10.173.152.205]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id t6KN8FJu013827 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 20 Jul 2015 19:08:16 -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 Jul 2015 19:08:15 -0400 From: "Wiley, Glen" To: Peter van Dijk , "dane@ietf.org" Thread-Topic: [dane] Another SMIMEA draft review Thread-Index: AQHQwicDTuK9dmk2q0ymHTgnzo2PIJ3jJUQAgADKbYCAAH0OAIAAX6wAgAAxLQA= Date: Mon, 20 Jul 2015 23:08:14 +0000 Message-ID: References: <20150719145740.GI28047@mournblade.imrryr.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="euc-kr" Content-ID: <1185ACFEDF5A0D4AB5FAE3C8B18E1CF0@verisign.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [dane] Another SMIMEA draft review 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 Jul 2015 23:08:19 -0000 QSBmZXcgb2YgdXMgd2VyZSBjaGF0dGluZyBhZnRlciB0aGUgbWVldGluZyBhbmQgSSBzdXNwZWN0 IHRoYXQgdGhlIDY0DQpvY3RldCBsaW1pdCBmb3IgYSBsYWJlbCBpcyBnb2luZyB0byBjcmVhdGUg YSBwcm9ibGVtIHdpdGggdXNpbmcgc3BsaXQNCmJhc2UzMi4gIEl0IHNvdW5kcyBhcyB0aG91Z2gg d2Ugd291bGQgZW5kIHVwIGxpbWl0aW5nIHRoZSBMSFMgdG8gNDANCm9jdGV0cyBiZWZvcmUgdGhl IGVuY29kaW5nLg0KDQoNCg0KT24gNy8yMC8xNSwgMTI6MTIgUE0sICJQZXRlciB2YW4gRGlqayIg PHBldGVyLnZhbi5kaWprQHBvd2VyZG5zLmNvbT4gd3JvdGU6DQoNCj5IZWxsbywNCj4NCj5PbiAy MCBKdWwgMjAxNSwgYXQgMTI6MjksIFBhdWwgV291dGVycyB3cm90ZToNCj4NCj4+IE9uIE1vbiwg MjAgSnVsIDIwMTUsIFdpbGV5LCBHbGVuIHdyb3RlOg0KPj4NCj4+PiBIYXMgdGhlcmUgYmVlbiBh bnkgcmVjZW50IGRpc2N1c3Npb24gYWJvdXQgdXNpbmcgYSBub24taGFzaGVkIExIUw0KPj4+IGVu Y29kaW5nPyAgSSBkb26p9nQgdGhpbmsgdGhlcmUgaGFzIHNvIHdlIHByb2JhYmx5IGRvbqn2dCB3 YW50IHRvDQo+Pj4gYnJpbmcNCj4+PiB0aGF0IHF1ZXN0aW9uIGludG8gc2NvcGUgaGVyZS4NCj4+ DQo+PiBUaGVyZSB3YXMgc29tZSBpbnRlcmVzdGVkIGJ5IHRoZSBwb3dlcmRucyBwZW9wbGUgZm9y IHRoaXMsIGFzIHRoZXkNCj4+IGltcGxlbWVudCBhbiBvbmxpbmUgc2lnbmVyIGFuZCBjb3VsZCBk ZWxpdmVyIGN1c3RvbSBzaWduZWQgcmVzcG9uc2VzLg0KPj4gSm9obiBMZXZpbmUgYWxzbyBwcmVm ZXJlZCB0aGlzIGFwcHJvYWNoIGluIHRoZSBwYXN0Lg0KPg0KPkluZGVlZCAtICpub3QqIGRvaW5n IHRoZSBoYXNoaW5nIGhhcyBtYW55IHBvdGVudGlhbCBiZW5lZml0cyAobW9zdCBvZg0KPndoaWNo IGRvIHJlcXVpcmUgb25saW5lIHNpZ25pbmcgdG8gZnVsbHkgcmVhcCksIGFuZCBmZXcgZG93bnNp ZGVzLiBTcGxpdA0KPmJhc2UzMiBtYXNzaXZlbHkgaW5jcmVhc2VzIHRoZSBwb3RlbnRpYWwgc3Vy ZmFjZSBhcmVhIGZvciBvcHBvcnR1bmlzdGljDQo+ZW5jcnlwdGlvbiwgd2hpbGUgaGFzaGluZyBz dHJpY3RseSBydWxlcyBvdXQgdGhvc2UgYmVuZWZpdHMuIEJlc2lkZXMgdGhlDQo+ZnVuY3Rpb25h bCBiZW5lZml0cywgYmFzZTMyIGFsc28gaXMgZWFzaWVyIGZvciBkZWJ1Z2dpbmcuDQo+DQo+U28g ZmFyIEmhr3ZlIHNlZW4gdHdvIGRvd25zaWRlcyB0byBzcGxpdCBiYXNlMzIgbWVudGlvbmVkOg0K PigxKSBzcGxpdCBiYXNlMzIgaGFzIGEgbG9uZ2VyIG1heGltdW0gbGVuZ3RoIHRoYW4gYSBoYXNo IChhbHRob3VnaCBpbg0KPnByYWN0aWNlIGl0IHdpbGwgYWN0dWFsbHkgYmUgc2hvcnRlciB0aGFu IGEgaGFzaCwgZm9yIG1vc3QgYWRkcmVzc2VzKQ0KPigyKSBwcml2YWN5DQo+DQo+QXMgUGF1bCBt ZW50aW9ucyBmdXJ0aGVyIGRvd24gdGhpcyB0aHJlYWQsIGlmIHdlIHN0YXJ0IGNhcmluZyBhYm91 dA0KPnByaXZhY3kgd2UgaGF2ZSBtb3JlIHdvcmsgdG8gZG8uDQo+DQo+PiBXaGlsZSBJIHRoaW5r IHRoZSBub24taGFzaCB2ZXJzaW9uIGlzIHVnbGllciwgSSBkb24ndCB0aGluayB0aGF0IGlzDQo+ PiBhIHZhbGlkIHJlYXNvbiBub3QgdG8gZG8gaXQuDQo+DQo+SSBkb26hr3QgdGhpbmsgYW55IG9m IHRoZSBvcHRpb25zIGxvb2sgcHJldHR5IC0gaW5jbHVkaW5nIGJhc2UzMi4gVGhpcw0KPmZhdGUg d2UgaGF2ZSB0byBhY2NlcHQgd2hlbiBzaG9laG9ybmluZyB0aGluZ3MgaW50byB0aGUgRE5TIQ0K Pg0KPktpbmQgcmVnYXJkcywNCj4tLSANCj5QZXRlciB2YW4gRGlqaw0KPlBvd2VyRE5TLkNPTSBC ViAtIGh0dHBzOi8vd3d3LnBvd2VyZG5zLmNvbS8NCj4NCj5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPmRhbmUgbWFpbGluZyBsaXN0DQo+ZGFuZUBpZXRm Lm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGFuZQ0KDQo= From nobody Tue Jul 21 00:12:13 2015 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 EE89C1AD0BA for ; Tue, 21 Jul 2015 00:12:12 -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 u4CAzNitEs67 for ; Tue, 21 Jul 2015 00:12:10 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17B321A009D for ; Tue, 21 Jul 2015 00:12:10 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mbB203QhFzw1; Tue, 21 Jul 2015 09:12:08 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=GUclMKtW X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id AIhgu--P39Wi; Tue, 21 Jul 2015 09:12:07 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 21 Jul 2015 09:12:07 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id C184A800AD; Tue, 21 Jul 2015 03:12:05 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1437462725; bh=0Ol6pGgRM+giAOTlne8AZdcAlMfYNUncYfRO32k0HFM=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=GUclMKtW1+b/uCKZn0z+cclkSCrHBESElHWETrA3c3mahDr5sRmlfS6TLaU7nXsuS ZjWOHQFTb+mYdZXcfLZ/tvKzDdup2/2YYXFXwz8ErHizhgLWPTlJoUP4J4xQmUNtKZ 83yms1bDA1CWUMD0sIheXQlYI/5vfLDdmHPGNg5c= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t6L7C4RV028015; Tue, 21 Jul 2015 03:12:05 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 21 Jul 2015 03:12:04 -0400 (EDT) From: Paul Wouters To: "Wiley, Glen" In-Reply-To: Message-ID: References: <20150719145740.GI28047@mournblade.imrryr.org> User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: Peter van Dijk , "dane@ietf.org" Subject: Re: [dane] Another SMIMEA draft review 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 Jul 2015 07:12:13 -0000 On Mon, 20 Jul 2015, Wiley, Glen wrote: > A few of us were chatting after the meeting and I suspect that the 64 > octet limit for a label is going to create a problem with using split > base32. It sounds as though we would end up limiting the LHS to 40 > octets before the encoding. how so? $ ./lhs.py email string length:144 qname length:242 OBQXK3DIMFZWC5TFOJ4XMZLSPF3GK4TZOZSXE6LWMVZHS5TFOJ4XMZLSPF3G.K4TZOZSXE6LWMVZHS5TFOJ4XMZLSPF3GK4TZOZSXE6LWPFSXE6LWMVZHS5TF.OJ4XMZLSPF3GK4TZOZSXE6LWMVZHS5TFOJ4XMZLSPF3GK4TZOZSXE6LMN5XG.OZLNMFUWYYLEMRZGK43TNRXWGYLMOBQXE5A=._openpgpkey.nohats.ca. #!/usr/bin/python import sys import base64 email = "paulhasaveryveryveryveryveryveryveryveryveryveryveryveryveryveryvyeryveryveryveryveryveryveryveryveryveryverylongemailaddresslocalpart@nohats.ca" lhs, domain = email.split("@") lhs32 = base64.b32encode(lhs.strip("=")) length = len(lhs32) cur = 0 out = "" splitsize = 60 while cur < length: if length - cur < splitsize: nxt = length else: nxt = cur + splitsize out += "%s."%lhs32[cur:nxt] cur += splitsize rr = "%s_openpgpkey.%s."%(out,domain) print "email string length:%d"%len(email) print "qname length:%d"%len(rr) print rr From nobody Tue Jul 21 00:46:19 2015 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 EB28E1AD1A6 for ; Tue, 21 Jul 2015 00:46:17 -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 Z086n78Q6p_3 for ; Tue, 21 Jul 2015 00:46:17 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE79C1AD26B for ; Tue, 21 Jul 2015 00:46:06 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mbBn737ylz1KX; Tue, 21 Jul 2015 09:46:03 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=belcxZEb X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id L9r7yHIxV5VX; Tue, 21 Jul 2015 09:46:02 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 21 Jul 2015 09:46:02 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id A9535800B3; Tue, 21 Jul 2015 03:46:01 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1437464761; bh=nMzFAQN0SYwkb7EvT8bCRlRJBT4cZr1KBE+w5wDYoHY=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=belcxZEbF6VZzVk1iRvaGBLo7SgncPoqk4mEdzT1nIku9xmPZHqlF7kPyedLKeyHg RwbdZ+Lgs9l8SCUuwoUp264zPlJ9SAdlC7ZCCNjvKO0gGClpwvDntUsONTkm7Ds6bT nx+zRrFbd75/IJyQDoTqQMT4GJyp23Oen/CjOU/0= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t6L7k0j1002542; Tue, 21 Jul 2015 03:46:00 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 21 Jul 2015 03:46:00 -0400 (EDT) From: Paul Wouters To: James Cloos In-Reply-To: Message-ID: References: User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dane Subject: Re: [dane] Discussion on OPENPGP and SMIME record location 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 Jul 2015 07:46:18 -0000 On Mon, 20 Jul 2015, James Cloos wrote: > They should be at the same place even though multiple lookups are likely > to be required anyway -- not everything will fully support an ANY query. > > And I renew my (previously ignored) suggestion that they, along with > tlsa records for client certs where the cn or other lookup -- such as > a sip url or the like -- has an @ in it -- be under _at. The use of -at. is only when you would run an ANY query. As we have seen with qmail, using ANY queries for real data, as opposed to diagnosing DNS, is fraught with peril. I would not want to support the use of ANY queries, even though I see its appeal to run a single ANY query on a single user to get all their personal information. Sending a few queries at once in parallel is not really much slower, and I don't think any of these personal DNS properties discovery would be that sensitive to latency. > Similarrly, the function mapping the local part to a dns element also > should be the same for every record type. Whatever that function should be. I guess you are suggesting everyone gets their own delegation at base32/split._at.domain.com to put all their personal information in? I could see some use for that, but I would say lets first see how well OPENPGPKEY and SMIME do, and then see about creating something like this in the future. Paul From nobody Tue Jul 21 04:06:41 2015 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 447F91A00A8 for ; Tue, 21 Jul 2015 04:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 9aSGDLzPUZLv for ; Tue, 21 Jul 2015 04:06:38 -0700 (PDT) Received: from mail-qg0-f97.google.com (mail-qg0-f97.google.com [209.85.192.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80CB71A00B5 for ; Tue, 21 Jul 2015 04:06:36 -0700 (PDT) Received: by qgy5 with SMTP id 5so3514613qgy.3 for ; Tue, 21 Jul 2015 04:06:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:user-agent:content-type:content-id :content-transfer-encoding:mime-version; bh=+PtysRI/h9IzkXTt2QuMu9DtJvHGlOjGSKs+2pEOojw=; b=UfAQp6zNBTT/45v7M9UNMyUWhFehShr5lHL6Xd6KXipMpFfFW88TqJ2fnYMdko/49K y7fU8ZfSlYAWERNLgZiQOFZxMK2/pDPQX0tdlL5guZcKjoqmgOLLON9MyZYEgJrvg0VC MtqOuXvsdzwCG2iR2JXFOgGSq1YTSwyQ8HFWM1RS00RKkAgGfGr9bwsz8ym4Ztuhcfgc nZ7Fm+bhoI2CNm2Q54Dfegk0apCyy9t7FvajRD9Yj8VqLOfQ0vGMLI5qXCl1Lkogfwx8 vDK7CQR5CYvOIcYMf4qBIonoAVT3JNW8XNHfDzYtUB/0nQDLxo/23vOypDTyORXnStfp FtXg== X-Gm-Message-State: ALoCoQlBC8rR0KyaPBz/kwGkY9X/2IoOqOj49yRbY/B8DjLZ6JHM8i330s2IsLlZSy6NX6ytRmI7XwUFT47cZuVRQOuQH4Zilw== X-Received: by 10.55.43.146 with SMTP id r18mr38981114qkr.27.1437476795687; Tue, 21 Jul 2015 04:06:35 -0700 (PDT) Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by smtp-relay.gmail.com with ESMTPS id 17sm7849334qky.3.2015.07.21.04.06.35 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 21 Jul 2015 04:06:35 -0700 (PDT) X-Relaying-Domain: verisign.com Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02 [10.173.152.206]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id t6LB6Te9010615 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Jul 2015 07:06:34 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 21 Jul 2015 07:06:29 -0400 From: "Wiley, Glen" To: Paul Wouters Thread-Topic: [dane] Another SMIMEA draft review Thread-Index: AQHQwicDTuK9dmk2q0ymHTgnzo2PIJ3jJUQAgADKbYCAAH0OAIAAX6wAgAAxLQCAAMo/AP///mgA Date: Tue, 21 Jul 2015 11:06:28 +0000 Message-ID: References: <20150719145740.GI28047@mournblade.imrryr.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <702E80EFAE17EE46B784B885DE56B0B3@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Peter van Dijk , "dane@ietf.org" Subject: Re: [dane] Another SMIMEA draft review 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 Jul 2015 11:06:40 -0000 Thanks Paul. I was leaving out the =B3split=B2 part of =B3split base32=B2 = (was thinking about a split at the @ rather than the approach you captured in The draft). On 7/21/15, 3:12 AM, "Paul Wouters" wrote: >On Mon, 20 Jul 2015, Wiley, Glen wrote: > >> A few of us were chatting after the meeting and I suspect that the 64 >> octet limit for a label is going to create a problem with using split >> base32. It sounds as though we would end up limiting the LHS to 40 >> octets before the encoding. > >how so? > >$ ./lhs.py=20 >email string length:144 >qname length:242 >OBQXK3DIMFZWC5TFOJ4XMZLSPF3GK4TZOZSXE6LWMVZHS5TFOJ4XMZLSPF3G.K4TZOZSXE6LWM >VZHS5TFOJ4XMZLSPF3GK4TZOZSXE6LWPFSXE6LWMVZHS5TF.OJ4XMZLSPF3GK4TZOZSXE6LWMV >ZHS5TFOJ4XMZLSPF3GK4TZOZSXE6LMN5XG.OZLNMFUWYYLEMRZGK43TNRXWGYLMOBQXE5A=3D.= _o >penpgpkey.nohats.ca. > >#!/usr/bin/python > >import sys >import base64 > >email =3D >"paulhasaveryveryveryveryveryveryveryveryveryveryveryveryveryveryvyeryvery >veryveryveryveryveryveryveryveryverylongemailaddresslocalpart@nohats.ca" > >lhs, domain =3D email.split("@") >lhs32 =3D base64.b32encode(lhs.strip("=3D")) >length =3D len(lhs32) >cur =3D 0 >out =3D "" >splitsize =3D 60 > >while cur < length: > if length - cur < splitsize: > nxt =3D length > else: > nxt =3D cur + splitsize > > out +=3D "%s."%lhs32[cur:nxt] > cur +=3D splitsize >rr =3D "%s_openpgpkey.%s."%(out,domain) >print "email string length:%d"%len(email) >print "qname length:%d"%len(rr) >print rr > > From nobody Tue Jul 21 08:30:37 2015 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 697E91B2F33 for ; Tue, 21 Jul 2015 08:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 mGB85xZlpJgI for ; Tue, 21 Jul 2015 08:30:34 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B74F1A8A0D for ; Tue, 21 Jul 2015 08:30:34 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 59675284D2B; Tue, 21 Jul 2015 15:30:27 +0000 (UTC) Date: Tue, 21 Jul 2015 15:30:27 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150721153027.GL28047@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: Subject: Re: [dane] Discussion on OPENPGP and SMIME record location 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: Tue, 21 Jul 2015 15:30:36 -0000 On Tue, Jul 21, 2015 at 03:46:00AM -0400, Paul Wouters wrote: > >And I renew my (previously ignored) suggestion that they, along with > >tlsa records for client certs where the cn or other lookup -- such as > >a sip url or the like -- has an @ in it -- be under _at. > > The use of _at. is only when you would run an ANY query. No, because as you note, "ANY" is unworkable. Rather the proposed shared (by SMIMEA, OPENPGPKEY, ...) non-terminal has the advantage that it is shorter than the labels in either of the drafts, is more mnemonic (where data about localparts goes) and works slightly better with negative caching. > I guess you are suggesting everyone gets their own delegation at > base32/split._at.domain.com to put all their personal information in? > > I could see some use for that, but I would say lets first see how well > OPENPGPKEY and SMIME do, and then see about creating something like this > in the future. Changing, later would be a mess. If it makes sense do it now. However, to be honest I still fear that for lookups of end-to-end email crypto keys, DNS may not be the right protocol. We discussed the privacy leak issue yesterday, which is added to concerns about managing large zones and complexity of fuzzy matching. I still think that perhaps using DNSSEC to publish the transport endpoint for a lookup service that runs over TLS, and DANE to publish TLSA records for same deals with both the privacy problem, and all the encoding problems. One then defines a suitable access protocol (say HTTPS at some .well-known URL authenticated via DANE) and JSON request/response format. The server operator can query their own DNS (think HESIOD) if they like, but can also front-end LDAP, cache results, rate-limit malfeasant clients, ... We should perhaps also consider the interaction of end-to-end email encryption with first-contact filtering of spam. Many would want the initial encryption key to be the gateway key, with the recipient disclosing the true end-to-end keys only if he chooses to reply in a way that does that (the lookup service would provide only a digest of that key, and the full data of the gateway key). Perhaps, given that the drafts are slate to go out as experimental, someone who's motivated to pursue the approach I outlined should publish a draft for that experimental approach, and prototype code, and time will tell which is more applicable to real-world email. The points we seem to be stuck on (namely how to encode email addresses as qnames) seem rather insignificant by comparison. I can't say I know which model would prove more successful, but I am not yet convinced that the DNS approach is the more likely winner. -- Viktor. From nobody Tue Jul 21 09:54:02 2015 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 D3C671A8EA9 for ; Tue, 21 Jul 2015 09:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, 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 KhMUvCzedYy7 for ; Tue, 21 Jul 2015 09:53:59 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.22.87]) (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 C438A1B2FCE for ; Tue, 21 Jul 2015 09:53:55 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 10A2A1E88B; Tue, 21 Jul 2015 16:53:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1437497635; bh=GBjQHLVdhMBqcZv1DfWTLbFL1KTYD1X6pjLWYqSDEuU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ZCSKJc0yzWUXuKIdo/i7RNI5WUa/0qJddlVZneuiqJY38vNfDfD6UJio4QQ/uxt21 3Q0VV4Yr4V4D6a2akHnFrybN7//QtqlWsV/EDzm0I4CGdZQiJWsWM1YW2AtsNaOnPQ E9enYI2TNNrfUreIusnC6KFb0tanWntg6WN+vxtY= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 45E6D106FD888; Tue, 21 Jul 2015 16:50:41 +0000 (UTC) From: James Cloos To: Paul Wouters In-Reply-To: (Paul Wouters's message of "Tue, 21 Jul 2015 03:46:00 -0400 (EDT)") References: User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2015 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: Tue, 21 Jul 2015 12:50:41 -0400 Message-ID: Lines: 22 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:28:150721:paul@nohats.ca::3lMtqG3iINYNmbeq:007yePJ X-Hashcash: 1:28:150721:ogud@ogud.com::lqQDmob4/S2tOg8u:0005ZLVj X-Hashcash: 1:28:150721:dane@ietf.org::bKEdXPsjUyuUULlx:000qgUek Archived-At: Cc: dane Subject: Re: [dane] Discussion on OPENPGP and SMIME record location 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 Jul 2015 16:54:01 -0000 >>>>> "PW" == Paul Wouters writes: PW> The use of -at. is only when you would run an ANY query. Keeping them all together has more value than that. And I noted in my post that any is unlikely -- in general -- to support openpgpkey/smime/tlsa. So that clearly wasn't the motivation I noted. PW> I guess you are suggesting everyone gets their own delegation at PW> base32/split._at.domain.com to put all their personal information in? Effectively, yes. Even if the end user doesn't manage it personally, it is still easier for those who do to have a simple, for-everything pattern to follow. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Tue Jul 21 11:29:13 2015 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 45ADC1A8FD6 for ; Tue, 21 Jul 2015 11:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 NDLRkpHeI8JU for ; Tue, 21 Jul 2015 11:29:10 -0700 (PDT) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (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 945741A896A for ; Tue, 21 Jul 2015 11:29:10 -0700 (PDT) Received: from [46.33.133.68] (helo=lap.dom.ain) from_AS 51561 by wizmail.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_RC5-17-80ea82e) id 1ZHcHt-0000Lt-2R for dane@ietf.org (return-path ); Tue, 21 Jul 2015 18:29:09 +0000 To: dane@ietf.org References: <20150721153027.GL28047@mournblade.imrryr.org> From: Jeremy Harris Message-ID: <55AE8F6D.7040406@wizmail.org> Date: Tue, 21 Jul 2015 19:29:01 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20150721153027.GL28047@mournblade.imrryr.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Pcms-Received-Sender: [46.33.133.68] (helo=lap.dom.ain) Archived-At: Subject: Re: [dane] Discussion on OPENPGP and SMIME record location 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 Jul 2015 18:29:12 -0000 On 21/07/15 16:30, Viktor Dukhovni wrote: > However, to be honest I still fear that for lookups of end-to-end > email crypto keys, DNS may not be the right protocol. Also playing in this space: https://tools.ietf.org/html/draft-moore-email-addrquery-01 - an smtp extension for doing this sort of lookup. -- Cheers, Jeremy From nobody Tue Jul 21 12:19:15 2015 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 DA2F71B2A72 for ; Tue, 21 Jul 2015 12:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 iIIQKV1DYmyd for ; Tue, 21 Jul 2015 12:19:11 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33B631B2A71 for ; Tue, 21 Jul 2015 12:19:11 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 557A6284D2B; Tue, 21 Jul 2015 19:19:10 +0000 (UTC) Date: Tue, 21 Jul 2015 19:19:10 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150721191909.GR28047@mournblade.imrryr.org> References: <20150721153027.GL28047@mournblade.imrryr.org> <55AE8F6D.7040406@wizmail.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55AE8F6D.7040406@wizmail.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] Discussion on OPENPGP and SMIME record location 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: Tue, 21 Jul 2015 19:19:13 -0000 On Tue, Jul 21, 2015 at 07:29:01PM +0100, Jeremy Harris wrote: > On 21/07/15 16:30, Viktor Dukhovni wrote: > > However, to be honest I still fear that for lookups of end-to-end > > email crypto keys, DNS may not be the right protocol. > > Also playing in this space: > > https://tools.ietf.org/html/draft-moore-email-addrquery-01 > > - an smtp extension for doing this sort of lookup. Which proxies the queries via TLS through the MSA (post authentication), thus introducing no new privacy issues, since once the mail is sent, the MSA sees the envelope recipients anyway. The MSA will then proxy the request also via TLS, and ideally authenticate the request via DANE (this leg is an MTA-to-MTA SMTP operation). With a bit of work, this proposal seems promising. We also have: https://tools.ietf.org/html/draft-miller-saag-key-discovery-00 which at first glance is not a step in the right direction. -- Viktor. From nobody Wed Jul 22 09:00:58 2015 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 2A7BF1A21A4 for ; Wed, 22 Jul 2015 09:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 UM6V177EinNF for ; Wed, 22 Jul 2015 09:00:56 -0700 (PDT) Received: from smtp76.iad3a.emailsrvr.com (smtp76.iad3a.emailsrvr.com [173.203.187.76]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 000B61A219C for ; Wed, 22 Jul 2015 09:00:55 -0700 (PDT) Received: from smtp10.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp10.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 26BFB2802BF for ; Wed, 22 Jul 2015 12:00:55 -0400 (EDT) Received: from app26.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp10.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id E9D1C28055B for ; Wed, 22 Jul 2015 12:00:54 -0400 (EDT) X-Sender-Id: ogud@ogud.com Received: from app26.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.4.2); Wed, 22 Jul 2015 16:00:55 GMT Received: from ogud.com (localhost.localdomain [127.0.0.1]) by app26.wa-webapps.iad3a (Postfix) with ESMTP id 0D47E380041 for ; Wed, 22 Jul 2015 12:00:54 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: ogud@ogud.com, from: ogud@ogud.com) with HTTP; Wed, 22 Jul 2015 12:00:54 -0400 (EDT) Date: Wed, 22 Jul 2015 12:00:54 -0400 (EDT) From: "Olafur Gudmundsson" To: dane@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20150722120054000000_65517" Importance: Normal X-Priority: 3 (Normal) X-Type: html X-Auth-ID: ogud@ogud.com Message-ID: <1437580854.052529954@apps.rackspace.com> X-Mailer: webmail/11.5.4-RC Archived-At: Subject: [dane] OPENPGP and SMIME local part question 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, 22 Jul 2015 16:00:57 -0000 ------=_20150722120054000000_65517 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0A =0ADear Colleagues =0AThe sense of the room in the IETF-93 meeting was = to do do a BASE32 encoding of local part with 60 character labels, shortest= label is the left most label. If you can NOT live with this path forward n= ow is your last chance to say so. =0ABy August 1'st the chairs will instruc= t editors how to proceed. Warren & Olafur ------=_20150722120054000000_65517 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

 

=0A

Dear Colleagues 

=0A


The sense of the room in the IETF-9= 3 meeting was to do do a BASE32 encoding of local part with 60 character la= bels, 
shortest label is the left = most label. 

If you can NOT live = with this path forward now is your last chance to say so. 

= =0A


By August 1'st the chairs= will instruct editors how to proceed. 

Warren & Olafur

 ------=_20150722120054000000_65517-- From nobody Wed Jul 22 09:20:16 2015 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 260AD1A8849 for ; Wed, 22 Jul 2015 09:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 5DECf-J2DXkL for ; Wed, 22 Jul 2015 09:20:13 -0700 (PDT) Received: from mail-qg0-f97.google.com (mail-qg0-f97.google.com [209.85.192.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1938F1A877C for ; Wed, 22 Jul 2015 09:20:12 -0700 (PDT) Received: by qgal74 with SMTP id l74so8345237qga.2 for ; Wed, 22 Jul 2015 09:20:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :user-agent:content-type:mime-version; bh=n7naz8LmGiKtBxy1du9DFfDXzKslaord5DFCaFJ/Naw=; b=UwHGe/n0wb5mj79rd6UURTxQ5apx/dyYyvvowNrIsrIWBPdOuHDLCSMubTwg4rZ0oL 0i7y3AHtIHRKaBKIMM7/kqhxUxhTWaI2Ya1dKfNfjTb8gpiuw0K3Y1hFVGqWQElFHs2w voA0y6lOTRasbQVPTvP+kcRAclJDpeHgF71brse0kb6J22NfNOazNxbwDT3+8q/C1a+3 nG0xMS3YK0f5bThuVL8kNhhLyZrxz6nkTiE5GOpvrprNFBn8DxBEAal9H3pkAxpOEfCs YzRMQao8us4uaYypJk2ZwHyoA7eBIkdpfURW4UVB135usBOIAvFBARWlYbTu/91lwoTj AYJw== X-Gm-Message-State: ALoCoQlQ7nFAudo85x8+zl/J4PaHDAhMXg6tjoeTe12eng9nBhR4h4VaK59KzwrHSM3SccRgGeKLPX9kpRvjXMK5beSc0+JcuQ== X-Received: by 10.55.40.67 with SMTP id o64mr4939796qkh.33.1437582012174; Wed, 22 Jul 2015 09:20:12 -0700 (PDT) Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by smtp-relay.gmail.com with ESMTPS id 93sm636911qks.4.2015.07.22.09.20.12 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 22 Jul 2015 09:20:12 -0700 (PDT) X-Relaying-Domain: verisign.com Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02 [10.173.152.206]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id t6MGKBsU022961 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jul 2015 12:20:11 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Wed, 22 Jul 2015 12:20:10 -0400 From: "Wiley, Glen" To: Olafur Gudmundsson , "dane@ietf.org" Thread-Topic: [dane] OPENPGP and SMIME local part question Thread-Index: AQHQxJegchp5YIJM4kW4TomSqJ9w2p3nq1YA Date: Wed, 22 Jul 2015 16:20:09 +0000 Message-ID: References: <1437580854.052529954@apps.rackspace.com> In-Reply-To: <1437580854.052529954@apps.rackspace.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [10.173.152.4] Content-Type: multipart/alternative; boundary="_000_D1D53AC0159E7gwileyverisigncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [dane] OPENPGP and SMIME local part question 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, 22 Jul 2015 16:20:15 -0000 --_000_D1D53AC0159E7gwileyverisigncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am in favor of a decision and this sounds like a not terrible one :) -- Glen Wiley Principal Engineer Verisign, Inc. (571) 230-7917 http://vbsdcon.com A5E5 E373 3C75 5B3E 2E24 6A0F DC65 2354 9946 C63A From: Olafur Gudmundsson > Date: Wednesday, July 22, 2015 at 12:00 PM To: "dane@ietf.org" > Subject: [dane] OPENPGP and SMIME local part question Dear Colleagues The sense of the room in the IETF-93 meeting was to do do a BASE32 encoding= of local part with 60 character labels, shortest label is the left most label. If you can NOT live with this path forward now is your last chance to say s= o. By August 1'st the chairs will instruct editors how to proceed. Warren & Olafur --_000_D1D53AC0159E7gwileyverisigncom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
I am in favor of a decision and this sounds like a not terrible one :)=  
-- 
Glen Wiley
Principal Engineer
Verisign, Inc.
(571) 230-7917


A5E5 E373 3C75 5B= 3E 2E24 &n= bsp;
6A0F DC65 2354 99= 46 C63A

From: Olafur Gudmundsson <ogud@ogud.com>
Date: Wednesday, July 22, 2015 at 1= 2:00 PM
To: "dane@ietf.org" <dane@i= etf.org>
Subject: [dane] OPENPGP and SMIME l= ocal part question

 

Dear Colleagues 


The sense of the room in the IETF-93 meeting w= as to do do a BASE32 encoding of local part with 60 character labels, =
shortest label is the left most label. 

If you can NOT live with this path forward now= is your last chance to say so. 


By August 1'st the chairs will instruct editor= s how to proceed. 

Warren & Olafur

 --_000_D1D53AC0159E7gwileyverisigncom_-- From nobody Wed Jul 22 09:25:48 2015 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 BBCCE1A9084 for ; Wed, 22 Jul 2015 09:25:47 -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, HTML_MESSAGE=0.001, 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 nkyNvpYuzjF1 for ; Wed, 22 Jul 2015 09:25:46 -0700 (PDT) Received: from mail-qg0-f41.google.com (mail-qg0-f41.google.com [209.85.192.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA1641A86F5 for ; Wed, 22 Jul 2015 09:25:11 -0700 (PDT) Received: by qgii95 with SMTP id i95so74058446qgi.2 for ; Wed, 22 Jul 2015 09:25:11 -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=YkD7Epf0mBo6ZqefH0+TB9vwM7XVETyucRpn6Y8Ieak=; b=TRUc6Ffqkze0lZZX5kWeBF4QYVp8MnpneAMMLkcwUrvthloxw6PeNQkHyAOGDdpMZE GVV+5gE41gNz+k6Vo6spgxSpQZtWeeL6bFtSyZRkZb5FhxHBgPnqTuKL+6y4AjCANxe6 1OZu7gWTqkyPCeYQ+I9RIsbmvbXQ0p7o3hHCHxZAvvE5w9b8EjnBxni41h7XsMTb9wbi ORxhpnfjJGNJaQM8ImRntTx6IAPk10hS2UVdU0icbUfdFdYPEKC8V0lqRIaEXkXwj0pG E3EF0zdaa+mORDbyS523FhqQHWltHTmbNTXbkdNcCeEu9xiOYKybQKuzZY8Dc8HmdrVz n6cg== X-Gm-Message-State: ALoCoQkQz8fz1lY89BW7tBlUuxq7BD+ftPmwsM4kb7KQFBKcCYaRMxPwVuQzP/Kn3LoLDLuX5ZTt MIME-Version: 1.0 X-Received: by 10.55.40.230 with SMTP id o99mr5021280qko.28.1437582311054; Wed, 22 Jul 2015 09:25:11 -0700 (PDT) Received: by 10.96.8.97 with HTTP; Wed, 22 Jul 2015 09:25:10 -0700 (PDT) X-Originating-IP: [31.133.137.64] In-Reply-To: <1437580854.052529954@apps.rackspace.com> References: <1437580854.052529954@apps.rackspace.com> Date: Wed, 22 Jul 2015 18:25:10 +0200 Message-ID: From: George Michaelson To: Olafur Gudmundsson Content-Type: multipart/alternative; boundary=001a1144a4c8fc7b1f051b79366b Archived-At: Cc: dane WG list Subject: Re: [dane] OPENPGP and SMIME local part question 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, 22 Jul 2015 16:25:47 -0000 --001a1144a4c8fc7b1f051b79366b Content-Type: text/plain; charset=UTF-8 I believe incursion into the lhs@ to define behaviour is very rare. This is a moment which bears thinking about, and will incur review overhead from people. I'm in favour btw. But, (and I doubt anyone doesn't expect it) there will be questions to be asked about diving into lhs@ because its been very very uncommon. -G On Wed, Jul 22, 2015 at 6:00 PM, Olafur Gudmundsson wrote: > > > Dear Colleagues > > > The sense of the room in the IETF-93 meeting was to do do a BASE32 > encoding of local part with 60 character labels, > shortest label is the left most label. > > If you can NOT live with this path forward now is your last chance to say > so. > > > By August 1'st the chairs will instruct editors how to proceed. > > Warren & Olafur > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > > --001a1144a4c8fc7b1f051b79366b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I believe incursion into the lhs@ to define behaviour is v= ery rare. This is a moment which bears thinking about, and will incur revie= w overhead from people.

I'm in favour btw. But, (and= I doubt anyone doesn't expect it) there will be questions to be asked = about diving into lhs@ because its been very very uncommon.

<= /div>
-G

On Wed, Jul 22, 2015 at 6:00 PM, Olafur Gudmundsson <ogud@ogud.com&= gt; wrote:

=C2=A0

Dear Colleagues=C2=A0


The sense of the room in the IETF-93 meeting was to= do do a BASE32 encoding of local part with 60 character labels,=C2=A0
shortest label is the left most label.=C2=A0

If = you can NOT live with this path forward now is your last chance to say so.= =C2=A0


By August 1'st the chairs will instruct editors= how to proceed.=C2=A0

Warren & Olafur

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


--001a1144a4c8fc7b1f051b79366b-- From nobody Wed Jul 22 09:25:59 2015 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 473A31ACE69 for ; Wed, 22 Jul 2015 09:25: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 WECb_v5hh8O8 for ; Wed, 22 Jul 2015 09:25:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C4761A8A52 for ; Wed, 22 Jul 2015 09:25:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.1.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150722162514.27996.27604.idtracker@ietfa.amsl.com> Date: Wed, 22 Jul 2015 09:25:14 -0700 From: IETF Secretariat Archived-At: Subject: [dane] Milestones changed for dane WG 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: Wed, 22 Jul 2015 16:25:57 -0000 Changed milestone "Advance DANE operational guidance/errata document to IESG", set due date to August 2015 from August 2016. Changed milestone "Advance DANE SMIME document to IESG", set due date to September 2015 from August 2016. Deleted milestone "Advance DANE security model document to IESG". Deleted milestone "Advance DANE RFC6698 and DANE SRV RFC to Internet Standard". Changed milestone "Recharter or close down", set due date to January 2016 from August 2016. URL: https://datatracker.ietf.org/wg/dane/charter/ From nobody Wed Jul 22 09:37:56 2015 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 65D561A9026 for ; Wed, 22 Jul 2015 09:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 YQWnDN6kdjQh for ; Wed, 22 Jul 2015 09:37:54 -0700 (PDT) Received: from smtpcmd02111.aruba.it (smtpcmd02111.aruba.it [62.149.158.111]) by ietfa.amsl.com (Postfix) with ESMTP id BA67E1A87EA for ; Wed, 22 Jul 2015 09:37:53 -0700 (PDT) Received: from dell-tcastaldi ([31.130.224.109]) by smtpcmd02.ad.aruba.it with bizsmtp id vUdq1q01z2NEPrz01UdrDv; Wed, 22 Jul 2015 18:37:52 +0200 Date: Wed, 22 Jul 2015 18:37:52 +0200 (CEST) From: Meetecho Team To: dane@ietf.org Message-ID: <1315968767.1.1437583072450.JavaMail.tcastaldi@dell-tcastaldi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_0_1351561298.1437583072386" Archived-At: Subject: [dane] Meetecho recordings of DANE WG session 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, 22 Jul 2015 16:37:55 -0000 ------=_Part_0_1351561298.1437583072386 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, the full recording (synchronized video, audio, slides and jabber room) of the DANE WG session at IETF 93 is available at the following URL: http://ietf93.conf.meetecho.com/index.php/Recorded_Sessions#DANE In case of problems with the playout, just drop an e-mail to ietf-support@meetecho.com. For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. Cheers, the Meetecho Team ------=_Part_0_1351561298.1437583072386-- From nobody Wed Jul 22 10:10:10 2015 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 74ACD1B2BC3 for ; Wed, 22 Jul 2015 10:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, 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 NKJhTRCZ_Na6 for ; Wed, 22 Jul 2015 10:10:07 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6DB21B2C1F for ; Wed, 22 Jul 2015 10:09:28 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id B85431E88B; Wed, 22 Jul 2015 17:09:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1437584967; bh=6gpNOGcsxiWZd0ErEws/T6U4STZTGTtQcgym03NU9Ug=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=I5CsCMzzF19aSSY4fZ2Z9aH7T5j+4CuEGYUEWoHbeAevVtWyUAuopiJQa5ZhP9ZFO 1/O+QygHrUBP24oWJP4Rzon8SDcixwOFuxr4/r+9zyJs5Q+yk45z4W52e5XhMUmMJC yglSkVEfabuKpezaIS9gmof62IUA+O94fE523wGA= Received: by carbon.jhcloos.org (Postfix, from userid 500) id BC5E3106FD880; Wed, 22 Jul 2015 17:07:12 +0000 (UTC) From: James Cloos To: "Olafur Gudmundsson" In-Reply-To: <1437580854.052529954@apps.rackspace.com> (Olafur Gudmundsson's message of "Wed, 22 Jul 2015 12:00:54 -0400 (EDT)") References: <1437580854.052529954@apps.rackspace.com> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2015 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: Wed, 22 Jul 2015 13:07:12 -0400 Message-ID: Lines: 14 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:28:150722:ogud@ogud.com::LXyj588/UQ8s/tK/:000WBK5h X-Hashcash: 1:28:150722:dane@ietf.org::gEWBzj0mRpHjxKPd:000JekiB Archived-At: Cc: dane@ietf.org Subject: Re: [dane] OPENPGP and SMIME local part question 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, 22 Jul 2015 17:10:09 -0000 >>>>> "OG" == Olafur Gudmundsson writes: OG> The sense of the room in the IETF-93 meeting was to do do a BASE32 OG> encoding of local part with 60 character labels, shortest label is OG> the left most label. Since I've posted on the topic before, I'll note that I have no objection to that scheme. (Is that 60 base32-chars, or 60 chars before encoding with base32?) -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Wed Jul 22 12:17:01 2015 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 EFA361A90AD for ; Wed, 22 Jul 2015 12:16:59 -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 dQSinivlBfP1 for ; Wed, 22 Jul 2015 12:16:58 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAE6B1A903A for ; Wed, 22 Jul 2015 12:16:57 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mc63q35TrzD5k; Wed, 22 Jul 2015 21:16:55 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=fiDEK+ge X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 0zAKE2kzw7sm; Wed, 22 Jul 2015 21:16:49 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 22 Jul 2015 21:16:49 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 7F4FC800B3; Wed, 22 Jul 2015 15:16:48 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1437592608; bh=23q/xqBPpbJE7X9JQFtEVRrL5G3vGLA48GLiuboQblE=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=fiDEK+gejxLpEIr9qYky/QpzZfUDtVAksX1p/2BvmqZngk7xbvAiHKmsnHLtjhizM +oUpzDHJeKcexVPFmm+tuca+NdxqTCbSstu4W7yMoIdrg8WpEldiujZJpfeTjETqSv 1FpnmjTElBGjfAdvUA8Re1hTAoheaC//tn6lXQcM= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t6MJGkvf030046; Wed, 22 Jul 2015 15:16:47 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Wed, 22 Jul 2015 15:16:46 -0400 (EDT) From: Paul Wouters To: James Cloos In-Reply-To: Message-ID: References: <1437580854.052529954@apps.rackspace.com> User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dane@ietf.org Subject: Re: [dane] OPENPGP and SMIME local part question 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, 22 Jul 2015 19:17:00 -0000 On Wed, 22 Jul 2015, James Cloos wrote: >>>>>> "OG" == Olafur Gudmundsson writes: > > OG> The sense of the room in the IETF-93 meeting was to do do a BASE32 > OG> encoding of local part with 60 character labels, shortest label is > OG> the left most label. > > Since I've posted on the topic before, I'll note that I have no > objection to that scheme. > > (Is that 60 base32-chars, or 60 chars before encoding with base32?) 60 chars after encoding to base32, because the whole point is that a label cannot be more then 63 characters. Paul (note my earlier python script did not cut the wya Olafur posted :) From nobody Wed Jul 22 12:26:50 2015 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 9E84F1A03F9 for ; Wed, 22 Jul 2015 12:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, 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 62mEZE7BmhFw for ; Wed, 22 Jul 2015 12:26:46 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A89161A034C for ; Wed, 22 Jul 2015 12:26:46 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 582821E88B; Wed, 22 Jul 2015 19:26:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1437593206; bh=mrMX80jDE2q88FFHLJ7Ia9LNDlIWt4YI5Me229TdAas=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Yc9b5d5anjkfzy185AoPvl5JEzOAQY8GKT05quWFQJ3EJHzJ2ZppMElFuM0iAQVc7 1bkj55iD6k5xUlUxSElfkq76EiWrZGmA0f+apeYb6hx8pwMIvnQPRPgIiIDmkVR0J7 wF5pa6u4xrdPVpDpKDMn/c7G8b6JaMuwYvZKfmpU= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 1EC09106FD888; Wed, 22 Jul 2015 19:25:11 +0000 (UTC) From: James Cloos To: Paul Wouters In-Reply-To: (Paul Wouters's message of "Wed, 22 Jul 2015 15:16:46 -0400 (EDT)") References: <1437580854.052529954@apps.rackspace.com> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2015 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: Wed, 22 Jul 2015 15:25:11 -0400 Message-ID: Lines: 10 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:28:150722:paul@nohats.ca::E64MiJLGq8lPBxwJ:00Hi2Ug X-Hashcash: 1:28:150722:ogud@ogud.com::NPigyV7aiAyKduS1:000AJAJt X-Hashcash: 1:28:150722:dane@ietf.org::sBmuDXq8sCuKbZNU:00079HUT Archived-At: Cc: dane@ietf.org Subject: Re: [dane] OPENPGP and SMIME local part question 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, 22 Jul 2015 19:26:48 -0000 >>>>> "PW" == Paul Wouters writes: PW> 60 chars after encoding to base32, because the whole point is that a PW> label cannot be more then 63 characters. Yes, for some (dumb) reason I had 127 in my head instead of 63. [SIGH] -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Sat Jul 25 05:19:21 2015 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 1E9871A3BA6; Sat, 25 Jul 2015 05:19:18 -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 t78toht4CJAU; Sat, 25 Jul 2015 05:19:14 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75D941A2182; Sat, 25 Jul 2015 05:19:14 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mdmfS18XrzD7N; Sat, 25 Jul 2015 14:19:12 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=semLHouR X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id WTcDtQiz-7Cz; Sat, 25 Jul 2015 14:19:09 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sat, 25 Jul 2015 14:19:09 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 23EEC80042; Sat, 25 Jul 2015 08:19:08 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1437826748; bh=bduqX1qCre1auQuoWi77XeMBOglrR8/P4evNY6WyE/s=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=semLHouRIKQWQ8jrK3vXty8wzE9vOvJScvoAQFm/DpYjGFbpfdI1OiluY/9QXOx13 aBXYr6DQC1cfXMkXiOPiR66qPX19aDgwkHLCH3UbSjioD3+I0QewdAVupb0j/uZMoZ 1p4BTizK9WEh3qfng9yQCaIRarP9LExPAL1J6DvY= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t6PCJ4L9010246; Sat, 25 Jul 2015 08:19:04 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sat, 25 Jul 2015 08:19:04 -0400 (EDT) From: Paul Wouters To: Werner Koch In-Reply-To: <87si8dagiz.fsf@vigenere.g10code.de> Message-ID: References: <87si8dagiz.fsf@vigenere.g10code.de> User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: Phillip Hallam-Baker , dane WG list , IETF OpenPGP Subject: Re: [dane] [openpgp] The DANE draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2015 12:19:18 -0000 On Fri, 24 Jul 2015, Werner Koch wrote: PHB wrote: >> 2) If people find it does not meet OpenPGP needs, they should say so and >> have no qualms about objecting. It is much more important that there be a >> spec people use than that the document progress quickly. This document has not progressed "quickly". The original draft was published in July 2013. No one is trying to rush this through. > I was a bit disappointed by the process: I learned about the I-D too late > and was surprised that it started out at the OpenPGP WG mailing list (2 > years ago?) with just a few messages and then continued at the DANE list > without having notified the OpenPGP list. This is now the fourth time I am having this discussion with you, so I think your representation is not entirely fair. The previous discussions ended with you saying we should not do this and stick to the CERT record type and me stating why I disagree with that view. > IIRC, I send some thoughts on > this to the GnuPG list but people told me that it is too late for > changes to the I-D - so I gave up. That is not a fair representation of what happened. I have told you on the openpgpkey, on the dane list and in private emails why we do not want to use the CERT record. It is fine to disagree with that, but the reason for not going back to CERT have nothing to do with timing. It is never too late to say a certain draft has no merit and should be shot or majorly changed. I am sorry if our previous communication did not make that clear. > Here are some thoughts, anyway: > > - Why a new DNS record despite that the CERT type has PGP support for > 9 years now (RFC-4398). > > The argument for a new record is that this makes parsing easier > because there is no need to loop over the record's sub-types. I do > not consider it a valid argument because there is a need to loop > anyway because there may be several DANE records for the same key. > Adding an extra loop over the sub-types is a non-brainer and the > selection logic to find the best matching record will be the same. Using subtypes for DNS is something the DNS people in general have concluded to be a wrong idea. As stated before, even Olafur who is one of the authors of the CERT RRtype advised us not to use CERT (or subtyping in general) Additionally, because the CERT record is a meta-container record, support for CERT is not good because to properly parse it you need all of openpgp and all of x509 and all of what other subtypes would be added later on. So instead of implementing CERT records partially, many DNS implementations just did not bother with it at all. > The CERT record is more flexible because it also allows the use of an > indirect specification via fingerprint. Which is a problem not a feature. It makes the security model very complex. Specifying a fingerprint and a URI that could be http or https reduces the security of the key to the strength of the fingerprint. Did we not already ran into issues in older (v3?) keys on this issue? Adding a level of indirection where not required does reduce the security. If using https, it adds back a whole trust mechanism of CA's, or it confusingly will ignore the CAs involved in the transaction. If the http(s) service is blocked by an attacker, it is indistinguishable from a regular outage. Putting the keys into DNS without indirection avoids all these problems. I know the CERT could also store the entire certificate, but this difference then has to be explained to the user, and that is way too complicated. Compare: "The user you are trying to mail has published their OpenPGP key in DNS, do you wish to use this key to encrypt this email?" versus: "The user you are trying to mail has published their OpenPGP key fingerprint in DNS and the key was obtained over HTTP(S) on anothersite.com whose certificate was validated by ACME inc. Do you wish to use this key to encrypt this email?" And the additional: "The user you are trying to mail has published their OpenPGP key fingerprint in DNS but the URI resource anothersite.com appears to be down. do you wish to postpone this email or send it unencrypted?" > GnuPG has support for such CERT records including a script to create > them also for about 9 years. It is not widely used because most users > have no way to add records to their zone - that is the same problem > for DANE of course. CERT wasn't widely used because frankly pgp is not widely used. Also, CERT without DNSSEC makes no sense, and we are only seeing DNSSEC protected application data being deployed recently in the last few years only. We now see small email providers adding webgui elements for their users to upload their pgp key to publish in DNS. So I do believe we are seeing an uptake in "pgp keys from dns". Of course this has no relation to the CERT vs OPENPGPKEY format question. > - The I-D says about the local-part of the mail address: The I-D was left unchanged at the request of the chairs. The intention right now is to use a base32 encoding split on 60 character labels. > ... it is turned into lowercase and hashed using the SHA2-256 > [RFC5754] algorithm, with the hash truncated to 28 octets ... > > Lowercasing UTF-8 characters is not easy and a likely reasons for > interoperability problems. It would be better to only require > lowercasing ASCII characters and keep characters > 127 as they are. Yes, that was discussed on the dane list and after consultation with internationalised email address experts, this same conclusion was reached. I am not sure if we actually reached consensus about the lowercase vs using a second DNS lookup for lowercase if the first query fails to find a record. The argument here is that a client should not "guess" that Paul@nohats.ca is the same as paul@nohats.ca, but there does seem to be concensus that in practise these are the same and it should be supported either through a lowercase before base32 (for ASCII only) or be allowing the client to try both as base32 lookups. One of the main reasons here is that virtual keyboards and web form fields often automatically capitalise recognised names, and otherwise we would need to add two records (Paul and paul) for each LHS side. > - There is no hint in the RFC on how to find a key to verify a > signature. This can't be done via a mail address but requires the > fingerprint (or as of today the key-id). The draft is about finding keys based on email address. It is not meant to be the global keyserver bag for all keyids or fingerprints. If you only have a keyid and nothing else, the DNS hierarchy cannot help you. But perhaps the openpgp group can extend the signature format allowing the inclusion of an ID so this could be possible in the future? > - How shall a key be retrieved or updated after a mail account has been > closed? It should be possible to verify signatures at all times. Why should that be possible? In fact, the key could be compromised so it might lead to the wrong actions if you verified the signature. The OPENPGPKEY draft specifies one method of finding a key. What you do with it, or what the lifetime of such a key or its signatures are is completely out of scope of this key discovery mechanism. If we want to specify those kind of usage scenarions, we can revive the openpgpkey-usage draft document. But I fear everyone has their own local policies on these. > Thus another non DNS service to keep the key available needs to be > setup too (e.g. a keyserver). I disagree. If the email was sent while the mail account was still operational with OPENPGPKEY, you should have fetched and stored the key then. If the account is closed and you don't have a copy of the key, than that is your problem. If you want to have some kind of global key store for all keys ever issued, then I guess you could look at something like "transparency" for openpgp keys. But that is a out of scope for this document, just as me sending you a key without any advertising on any public key server resource and then closing my mail account is. > dissemination of revocation certificates. IPGP records could be kept > as long as the mail address has not been re-assigned. Again, that seems like a "transparency" issue. The issue of losing control of your email address, and someone else generating a new key for that email address and advertising thism, whether in DNSSEC or on keyservers, in an attempt to get encrypted email intended for you, is really not in scope here either. It might be in scope for the openpgpkey-usage document, but it seems to me to be a more generic openpgp issue, so perhaps would be better in the openpgp bis document or elsewhere. (and of course this would be no different with CERT records in DNS) > - Implementation nit: The I-D states: > > The lookup result MUST pass DNSSEC validation; if validation > reaches any state other than "Secure", the verification MUST be > treated as a failure. > > As an implementer I see no way to do this without adding a full > fledged DNSSEC resolver. There are various libraries to do this. You can look at getdns, libunbound or various other libraries. We hope you would not write your own dnssec validation code. If you do not want to link against new unknown libraries you could outsource it to a separate tool, and possibly warn the user of that. I'm happy to help you with that. >> People have been attempting to put email address related records into the >> DNS since the first drafts of the spec and none has taken off. > > That is a general problem. You need the support from the mail > providers. Of course this is a big catch22. While I have been approached by a few email providers who have or are implementing this to allow their users to publish their openpgp keys this way, the 5 big email providers business model relies on advertisement targetted specifically by reading your email. So I do not expect those email providers to have much incentives to become free binary blob relaying services. >> I do not find the idea of relying on the DNS for my keys remotely >> comforting and would not want to rely on such a record directly. The DNS >> has no persistence to it. Give me the MIT keyserver any day. > > When intending to send a mail the first time the DNS is pretty useful > because it creates an association between mail address and key. Thus > you can pick the right key and the recipient won't be annoyed by > encrypted mails they can't decrypt because the keyservers carry several > "faked" keys for their mail address. Indeed. And no one is saying you should ONLY trust the DNS. In fact, no one is saying that. The prime motivation for this document is to allow MTAs and MUAs to encrypt emails that would otherwise be send out in the clear by the user. In no way is it intended to replace the web of trust or manual key verification, and I hope implementations will ensure this point to their users. Now, one thing I _would_ like to see from the openpgp working group, is comments on content of the public key ring format that we should or should not put into the OPENPGPKEY record. The draft basically refers to the openpgp RFC, but people have wondered about some things: - What to do when there is more than one pubkey? - Should it be mandatory for the email address to appear as an ID on the key? (if yes, how to support domain wild cards) - Should any third party signatures be allowed/encourages/discouraged? - Should revoked keys be allowed? One issue during deployment for all fedora developer keys was that people do have keys that are larger than 64k and those will not fit into the DNS. There is no easy way for tools to try and reduce the signatures because it does not know which signatures carry more weight for the user. Paul From nobody Sat Jul 25 05:50:50 2015 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 718851ACC72 for ; Sat, 25 Jul 2015 05:50:48 -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 L7HETiq2VPRl for ; Sat, 25 Jul 2015 05:50:45 -0700 (PDT) Received: from smtp100.iad3a.emailsrvr.com (smtp100.iad3a.emailsrvr.com [173.203.187.100]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E639E1A903E for ; Sat, 25 Jul 2015 05:50:44 -0700 (PDT) Received: from smtp5.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp5.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 4BFA1801F7; Sat, 25 Jul 2015 08:50:43 -0400 (EDT) Received: by smtp5.relay.iad3a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id C2F5D801F5; Sat, 25 Jul 2015 08:50:39 -0400 (EDT) X-Sender-Id: ogud@ogud.com Received: from [10.20.30.43] (pool-173-66-187-177.washdc.fios.verizon.net [173.66.187.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.4.2); Sat, 25 Jul 2015 12:50:43 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Olafur Gudmundsson In-Reply-To: Date: Sat, 25 Jul 2015 08:50:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <39995A26-5F1B-4DFF-9030-9743A7A83EC8@ogud.com> References: <87si8dagiz.fsf@vigenere.g10code.de> To: Paul Wouters X-Mailer: Apple Mail (2.2102) Archived-At: Cc: Werner Koch , Phillip Hallam-Baker , dane WG list , IETF OpenPGP Subject: Re: [dane] [openpgp] The DANE draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2015 12:50:48 -0000 > On Jul 25, 2015, at 8:19 AM, Paul Wouters wrote: >=20 > On Fri, 24 Jul 2015, Werner Koch wrote: >=20 > PHB wrote: >=20 >>> 2) If people find it does not meet OpenPGP needs, they should say so = and >>> have no qualms about objecting. It is much more important that there = be a >>> spec people use than that the document progress quickly. >=20 > This document has not progressed "quickly". The original draft was > published in July 2013. No one is trying to rush this through. >=20 >> I was a bit disappointed by the process: I learned about the I-D too = late >> and was surprised that it started out at the OpenPGP WG mailing list = (2 >> years ago?) with just a few messages and then continued at the DANE = list >> without having notified the OpenPGP list. >=20 > This is now the fourth time I am having this discussion with you, so I > think your representation is not entirely fair. The previous = discussions > ended with you saying we should not do this and stick to the CERT = record > type and me stating why I disagree with that view. >=20 >> IIRC, I send some thoughts on >> this to the GnuPG list but people told me that it is too late for >> changes to the I-D - so I gave up. >=20 > That is not a fair representation of what happened. I have told you on > the openpgpkey, on the dane list and in private emails why we do not > want to use the CERT record. It is fine to disagree with that, but the > reason for not going back to CERT have nothing to do with timing. It > is never too late to say a certain draft has no merit and should be > shot or majorly changed. I am sorry if our previous communication did > not make that clear. >=20 >> Here are some thoughts, anyway: >>=20 >> - Why a new DNS record despite that the CERT type has PGP support for >> 9 years now (RFC-4398). >>=20 >> The argument for a new record is that this makes parsing easier >> because there is no need to loop over the record's sub-types. I do >> not consider it a valid argument because there is a need to loop >> anyway because there may be several DANE records for the same key. >> Adding an extra loop over the sub-types is a non-brainer and the >> selection logic to find the best matching record will be the same. >=20 > Using subtypes for DNS is something the DNS people in general have > concluded to be a wrong idea. As stated before, even Olafur who is one > of the authors of the CERT RRtype advised us not to use CERT (or > subtyping in general) I want to strongly support this point, Bulk container records like CERT = have been shown to be a bad idea is=20 every time they get used in DNS. Lets learn from experience.=20 > Additionally, because the CERT record is a meta-container record, > support for CERT is not good because to properly parse it you need > all of openpgp and all of x509 and all of what other subtypes would > be added later on. So instead of implementing CERT records partially, > many DNS implementations just did not bother with it at all. +1=20 >=20 >> The CERT record is more flexible because it also allows the use of an >> indirect specification via fingerprint. >=20 > Which is a problem not a feature. It makes the security model very > complex. Specifying a fingerprint and a URI that could be http or = https > reduces the security of the key to the strength of the fingerprint. > Did we not already ran into issues in older (v3?) keys on this issue? > Adding a level of indirection where not required does reduce the > security. >=20 > If using https, it adds back a whole trust mechanism of CA's, or it > confusingly will ignore the CAs involved in the transaction. >=20 > If the http(s) service is blocked by an attacker, it is = indistinguishable from > a regular outage. >=20 > Putting the keys into DNS without indirection avoids all these = problems. > I know the CERT could also store the entire certificate, but this > difference then has to be explained to the user, and that is way too > complicated. Compare: >=20 > "The user you are trying to mail has published their OpenPGP key in = DNS, > do you wish to use this key to encrypt this email?" >=20 > versus: >=20 > "The user you are trying to mail has published their OpenPGP > key fingerprint in DNS and the key was obtained over HTTP(S) on > anothersite.com whose certificate was validated by ACME inc. Do > you wish to use this key to encrypt this email?" >=20 > And the additional: >=20 > "The user you are trying to mail has published their OpenPGP > key fingerprint in DNS but the URI resource anothersite.com appears > to be down. do you wish to postpone this email or send it > unencrypted?" >=20 >> GnuPG has support for such CERT records including a script to create >> them also for about 9 years. It is not widely used because most = users >> have no way to add records to their zone - that is the same problem >> for DANE of course. >=20 > CERT wasn't widely used because frankly pgp is not widely used. Also, > CERT without DNSSEC makes no sense, and we are only seeing DNSSEC > protected application data being deployed recently in the last few > years only. We now see small email providers adding webgui elements > for their users to upload their pgp key to publish in DNS. So I do > believe we are seeing an uptake in "pgp keys from dns". Of course > this has no relation to the CERT vs OPENPGPKEY format question. >=20 >> - The I-D says about the local-part of the mail address: >=20 > The I-D was left unchanged at the request of the chairs. The intention > right now is to use a base32 encoding split on 60 character labels. Dane WG (which I co-chair) is trying to settle this issue by the end of = July=20 so if you have a comment please state it there.=20 >=20 >> ... it is turned into lowercase and hashed using the SHA2-256 >> [RFC5754] algorithm, with the hash truncated to 28 octets ... >>=20 >> Lowercasing UTF-8 characters is not easy and a likely reasons for >> interoperability problems. It would be better to only require >> lowercasing ASCII characters and keep characters > 127 as they are. >=20 > Yes, that was discussed on the dane list and after consultation with > internationalised email address experts, this same conclusion was > reached. I am not sure if we actually reached consensus about the > lowercase vs using a second DNS lookup for lowercase if the first > query fails to find a record. The argument here is that a client > should not "guess" that Paul@nohats.ca is the same as paul@nohats.ca, > but there does seem to be concensus that in practise these are the > same and it should be supported either through a lowercase before > base32 (for ASCII only) or be allowing the client to try both as > base32 lookups. One of the main reasons here is that virtual keyboards > and web form fields often automatically capitalise recognised names, > and otherwise we would need to add two records (Paul and paul) for > each LHS side. >=20 >> - There is no hint in the RFC on how to find a key to verify a >> signature. This can't be done via a mail address but requires the >> fingerprint (or as of today the key-id). >=20 > The draft is about finding keys based on email address. It is not = meant > to be the global keyserver bag for all keyids or fingerprints. If you > only have a keyid and nothing else, the DNS hierarchy cannot help you. >=20 > But perhaps the openpgp group can extend the signature format allowing > the inclusion of an ID so this could be possible in the future? As Paul says this is about connecting a one form of ID to a OPENPGP key=20= this can be used as additional method.=20 As a matter of fact the reason I stopped using PGP many years ago was = the difficulty in discovering someone=E2=80=99s else PGPkey, in particular there was no = way to look up based on the handles I had.=20 >=20 >> - How shall a key be retrieved or updated after a mail account has = been >> closed? It should be possible to verify signatures at all times. >=20 > Why should that be possible? In fact, the key could be compromised so > it might lead to the wrong actions if you verified the signature. >=20 > The OPENPGPKEY draft specifies one method of finding a key. What you > do with it, or what the lifetime of such a key or its signatures > are is completely out of scope of this key discovery mechanism. >=20 > If we want to specify those kind of usage scenarions, we can revive > the openpgpkey-usage draft document. But I fear everyone has their > own local policies on these. >=20 I asked the same questions and came to the following conclusion: OPENPGP via DANE/DNSSEC verification SHOULD be done when the email is = received and that information should be stored with the message. DNS lookup of a key via the method specified here provides a binding at = particular point in time.=20 For the email provider it is her choice to remove the key or revoke the = key, the net effect is the same=20 they key is not available for use after that action.=20 How this is done is depends on the software that validates the message.=20= >> Thus another non DNS service to keep the key available needs to be >> setup too (e.g. a keyserver). This is the core difference between the way Certificate world thinks and = how DNS world behaves.=20 DNS is and answer at particular point in time. Either the data exists or = does not exist. No history at all. Removal of OPENPGP is almost a revocation, addition is = =E2=80=9Cpublication=E2=80=9D.=20 >=20 > I disagree. If the email was sent while the mail account was still > operational with OPENPGPKEY, you should have fetched and stored the > key then. If the account is closed and you don't have a copy of the > key, than that is your problem. If you want to have some kind of > global key store for all keys ever issued, then I guess you could > look at something like "transparency" for openpgp keys. But that > is a out of scope for this document, just as me sending you a key > without any advertising on any public key server resource and > then closing my mail account is. >=20 >> dissemination of revocation certificates. IPGP records could be kept >> as long as the mail address has not been re-assigned. >=20 > Again, that seems like a "transparency" issue. The issue of losing > control of your email address, and someone else generating a new key > for that email address and advertising thism, whether in DNSSEC or > on keyservers, in an attempt to get encrypted email intended for you, > is really not in scope here either. It might be in scope for the > openpgpkey-usage document, but it seems to me to be a more generic > openpgp issue, so perhaps would be better in the openpgp bis document > or elsewhere. (and of course this would be no different with CERT > records in DNS) >=20 >> - Implementation nit: The I-D states: >>=20 >> The lookup result MUST pass DNSSEC validation; if validation >> reaches any state other than "Secure", the verification MUST be >> treated as a failure. >>=20 >> As an implementer I see no way to do this without adding a full >> fledged DNSSEC resolver. >=20 > There are various libraries to do this. You can look at getdns, > libunbound or various other libraries. We hope you would not write > your own dnssec validation code. If you do not want to link against > new unknown libraries you could outsource it to a separate tool, and > possibly warn the user of that. I'm happy to help you with that. >=20 >>> People have been attempting to put email address related records = into the >>> DNS since the first drafts of the spec and none has taken off. >>=20 >> That is a general problem. You need the support from the mail >> providers. >=20 > Of course this is a big catch22. While I have been approached by a few > email providers who have or are implementing this to allow their users > to publish their openpgp keys this way, the 5 big email providers > business model relies on advertisement targetted specifically by > reading your email. So I do not expect those email providers to have > much incentives to become free binary blob relaying services. >=20 >>> I do not find the idea of relying on the DNS for my keys remotely >>> comforting and would not want to rely on such a record directly. The = DNS >>> has no persistence to it. Give me the MIT keyserver any day. >>=20 >> When intending to send a mail the first time the DNS is pretty useful >> because it creates an association between mail address and key. Thus >> you can pick the right key and the recipient won't be annoyed by >> encrypted mails they can't decrypt because the keyservers carry = several >> "faked" keys for their mail address. >=20 > Indeed. And no one is saying you should ONLY trust the DNS. In fact, = no > one is saying that. The prime motivation for this document is to allow > MTAs and MUAs to encrypt emails that would otherwise be send out in = the > clear by the user. In no way is it intended to replace the web of = trust > or manual key verification, and I hope implementations will ensure = this > point to their users. >=20 >=20 > Now, one thing I _would_ like to see from the openpgp working group, = is > comments on content of the public key ring format that we should or > should not put into the OPENPGPKEY record. The draft basically refers > to the openpgp RFC, but people have wondered about some things: >=20 > - What to do when there is more than one pubkey? > - Should it be mandatory for the email address to appear as an ID > on the key? (if yes, how to support domain wild cards) > - Should any third party signatures be allowed/encourages/discouraged? > - Should revoked keys be allowed? >=20 > One issue during deployment for all fedora developer keys was that = people > do have keys that are larger than 64k and those will not fit into the > DNS. There is no easy way for tools to try and reduce the signatures > because it does not know which signatures carry more weight for the = user. >=20 > Paul Olafur=20= From nobody Sat Jul 25 09:23:17 2015 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 05C281ACCD8; Sat, 25 Jul 2015 09:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 TZ7MdrVp6FCe; Sat, 25 Jul 2015 09:23:14 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA7401AC431; Sat, 25 Jul 2015 09:23:13 -0700 (PDT) Received: by lafd3 with SMTP id d3so18550572laf.1; Sat, 25 Jul 2015 09:23:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=RuAs/0tN2VwIJjvOP4/AWH18fz3nvydFGO+mXTMgwKw=; b=s0+XYKRQjFV4p2qKEVDLdsBdLnFfAnJnEnUELZGzIASvEIlSeqCOtV4uIy+2gN20I7 SZuDSqftXasUc79A9o0UiJXYb/ftteGdPNbfrngJokonTI5b9322cV60Z/Ep8ydH5qhK ynvkEmZf+PI60/dYWfuwgOIdAcKpmK34RMWVCxppQb0wgYQxr5Xkuqg5Ckdz3wNjXMmZ qiG7v6SrDbqHCM5jb0dWO89g1qS+wCgsLK8A/An7AwioXKehK8buDCVUyGrN0OGVr4S/ wD8u+f0YB6vsx7xdSBmGOkTz2IqT5pKi/4vUGCVAjcI0GSXrFT2Aen7q9wHmkM9N3qdU KngA== MIME-Version: 1.0 X-Received: by 10.112.170.167 with SMTP id an7mr19054709lbc.103.1437841392309; Sat, 25 Jul 2015 09:23:12 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Sat, 25 Jul 2015 09:23:12 -0700 (PDT) In-Reply-To: References: <87si8dagiz.fsf@vigenere.g10code.de> Date: Sat, 25 Jul 2015 12:23:12 -0400 X-Google-Sender-Auth: MeydRE1-WGQDwcpn3_G2r3nhreM Message-ID: From: Phillip Hallam-Baker To: Paul Wouters Content-Type: multipart/alternative; boundary=001a11c368cc6e9e4a051bb5892c Archived-At: Cc: Werner Koch , IETF OpenPGP , dane WG list Subject: Re: [dane] [openpgp] The DANE draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2015 16:23:16 -0000 --001a11c368cc6e9e4a051bb5892c Content-Type: text/plain; charset=UTF-8 On Sat, Jul 25, 2015 at 8:19 AM, Paul Wouters wrote: > On Fri, 24 Jul 2015, Werner Koch wrote: > > PHB wrote: > > 2) If people find it does not meet OpenPGP needs, they should say so and >>> have no qualms about objecting. It is much more important that there be a >>> spec people use than that the document progress quickly. >>> >> > This document has not progressed "quickly". The original draft was > published in July 2013. No one is trying to rush this through I am quite happy waiting till 2016 or 2018. If it isn't done right its better not to publish at all. > I was a bit disappointed by the process: I learned about the I-D too late >> and was surprised that it started out at the OpenPGP WG mailing list (2 >> years ago?) with just a few messages and then continued at the DANE list >> without having notified the OpenPGP list. >> > > This is now the fourth time I am having this discussion with you, so I > think your representation is not entirely fair. The previous discussions > ended with you saying we should not do this and stick to the CERT record > type and me stating why I disagree with that view. Ummm watch your attributions, that is Werner, not me. The DANE group has been rather ineffective in getting the constituencies they purport to be serving to buy into their proposal. Additionally, because the CERT record is a meta-container record, > support for CERT is not good because to properly parse it you need > all of openpgp and all of x509 and all of what other subtypes would > be added later on. So instead of implementing CERT records partially, > many DNS implementations just did not bother with it at all. All of X509 isn't a big barrier. Took me a week, four days of that was writing the Assinine One compiler. I am not aware of any major crypto package that doesn't have the ability to parse X.509 certs. Werner isn't the only person who has a PKIX package in his OpenPGP library. Back in 1990 the idea of using OpenPGP to avoid the need to mess with Assinine One made arguable sense. Today its a lost cause. I stopped fighting that battle in 1995. The CERT record is more flexible because it also allows the use of an >> indirect specification via fingerprint. >> > > Which is a problem not a feature. It makes the security model very > complex. No, the security model is complex because you are trying to use a vast, aging and vaguely understood infrastructure with a byzantine administrative model to provide security. Failing to accept that fact is one of the many reasons people are skeptical of this project and looking for ways to work round it. --001a11c368cc6e9e4a051bb5892c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Jul 25, 2015 at 8:19 AM, Paul Wouters <paul@nohats.ca> wrote:
On Fri, 24 Jul 2015, Werner Ko= ch wrote:

PHB wrote:

2) If people find it does not meet OpenPGP needs, they should say so and have no qualms about objecting. It is much more important that there be a spec people use than that the document progress quickly.

 This document has not progressed "quickly". The original draft wa= s
published in July 2013. No one is trying to rush this through
<= div>
I am quite happy waiting till 2016 or 2018.=C2=A0
<= div>
If it isn't done right its better not to publish at = all.



I was a bit disappointed by the process: I learned about the I-D too late and was surprised that it started out at the OpenPGP WG mailing list (2
years ago?) with just a few messages and then continued at the DANE list without having notified the OpenPGP list.

This is now the fourth time I am having this discussion with you, so I
think your representation is not entirely fair. The previous discussions ended with you saying we should not do this and stick to the CERT record type and me stating why I disagree with that view.

Ummm watch your attributions, that is Werner, not me.
The DANE group has been rather ineffective in getting the const= ituencies they purport to be serving to buy into their proposal.
=

Additionally, becau= se the CERT record is a meta-container record,
support for CERT is not good because to properly parse it you need
all of openpgp and all of x509 and all of what other subtypes would
be added later on. So instead of implementing CERT records partially,
many DNS implementations just did not bother with it at all.

All of X509 isn't a big barrier. Took me a week, four= days of that was writing the Assinine One compiler. I am not aware of any = major crypto package that doesn't have the ability to parse X.509 certs= . Werner isn't the only person who has a PKIX package in his OpenPGP li= brary.=C2=A0

Back in 1990 the idea of using OpenPG= P to avoid the need to mess with Assinine One made arguable sense. Today it= s a lost cause. I stopped fighting that battle in 1995.



=C2=A0The CERT record is more flexible because it also allows the use of an=
=C2=A0indirect specification via fingerprint.

 Which is a problem not a feature. It makes the security model very
complex.

No, the security model is complex= because you are trying to use a vast, aging and vaguely understood infrast= ructure with a byzantine administrative model to provide security.

Failing to accept that fact is one of the many reasons peo= ple are skeptical of this project and looking for ways to work round it.
--001a11c368cc6e9e4a051bb5892c-- From nobody Sat Jul 25 15:44:24 2015 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 83EE21A6EFC for ; Sat, 25 Jul 2015 15:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 cuku0asRfHHx for ; Sat, 25 Jul 2015 15:44:22 -0700 (PDT) Received: from mail-oi0-f98.google.com (mail-oi0-f98.google.com [209.85.218.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1107B1A6EFB for ; Sat, 25 Jul 2015 15:44:21 -0700 (PDT) Received: by oibw187 with SMTP id w187so3179237oib.1 for ; Sat, 25 Jul 2015 15:44:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-type:content-id:content-transfer-encoding :mime-version; bh=yvuAS8ddZkQNTcXNX1PlKOqqOJ5LtOezX7vv/eXGyow=; b=QuC9M/y1ivUjW6x1LQ4esRrw13WmOMZN2tEf9CL0gP9YmMvJfVc0snoh1dl8u7Hmvg 3WdyWs+/mUMYv1xLnOKfn3qlM9DXlkgt0BOBkg8/cnYS3efiU/Rh93dhV+qc50iM/IlR yBVXFW60wEe9RHd0lWUwPLA3BOdGkfiKXRk6rpLkAcN+dP2POHnkS+cbTETzWcZZWwmH hnCoMIW3mzuKwf3Fx0HxXczKlt0DDcFMj1KqsokzHTK2qkhsy6SK+1Iui4LZklxCxICI w3zzcmowovhdtHBWPDDKRWmCWuOd4BOQYlUCpOW0pOYm5GPXMm9dVbIbZZYx9bT8lzyR jOXw== X-Gm-Message-State: ALoCoQl+mJ1K44g9GT2X9YaIgABibo8M2DweDS/fFlt3JUOWbg9/O++/M1gEVcTqGDuW1NMcUhsGqs3ijVZ/ArRNz979EAFK+w== X-Received: by 10.140.107.101 with SMTP id g92mr30007853qgf.58.1437864261162; Sat, 25 Jul 2015 15:44:21 -0700 (PDT) Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by smtp-relay.gmail.com with ESMTPS id r102sm4172479qkh.0.2015.07.25.15.44.20 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 25 Jul 2015 15:44:21 -0700 (PDT) X-Relaying-Domain: verisign.com Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01 [10.173.152.255]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id t6PMiJ3F021183 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 25 Jul 2015 18:44:20 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Sat, 25 Jul 2015 18:44:19 -0400 From: "Osterweil, Eric" To: Olafur Gudmundsson Thread-Topic: [dane] OPENPGP and SMIME local part question Thread-Index: AQHQxJefjVLww28TyEyTfHmWpBr2qZ3tEMcA Date: Sat, 25 Jul 2015 22:44:18 +0000 Message-ID: References: <1437580854.052529954@apps.rackspace.com> In-Reply-To: <1437580854.052529954@apps.rackspace.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="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "dane@ietf.org" Subject: Re: [dane] OPENPGP and SMIME local part question 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, 25 Jul 2015 22:44:23 -0000 DQo+IE9uIEp1bCAyMiwgMjAxNSwgYXQgMTI6MDAgUE0sIE9sYWZ1ciBHdWRtdW5kc3NvbiA8b2d1 ZEBvZ3VkLmNvbT4gd3JvdGU6DQo+IA0KPiAgDQo+IERlYXIgQ29sbGVhZ3VlcyANCj4gDQo+IFRo ZSBzZW5zZSBvZiB0aGUgcm9vbSBpbiB0aGUgSUVURi05MyBtZWV0aW5nIHdhcyB0byBkbyBkbyBh IEJBU0UzMiBlbmNvZGluZyBvZiBsb2NhbCBwYXJ0IHdpdGggNjAgY2hhcmFjdGVyIGxhYmVscywg DQo+IHNob3J0ZXN0IGxhYmVsIGlzIHRoZSBsZWZ0IG1vc3QgbGFiZWwuIA0KPiANCj4gSWYgeW91 IGNhbiBOT1QgbGl2ZSB3aXRoIHRoaXMgcGF0aCBmb3J3YXJkIG5vdyBpcyB5b3VyIGxhc3QgY2hh bmNlIHRvIHNheSBzby4gDQo+IA0KPiBCeSBBdWd1c3QgMSdzdCB0aGUgY2hhaXJzIHdpbGwgaW5z dHJ1Y3QgZWRpdG9ycyBob3cgdG8gcHJvY2VlZC4gDQoNCkp1c3QgdG8gY2xhcmlmeSwgd2XigJly ZSBub3QgdGFsa2luZyBhYm91dCBCYXNlMzJIZXggKFNlY3Rpb24gNyBvZiBodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvcmZjNDY0OCNzZWN0aW9uLTcgKSwgcmlnaHQ/ICBJIG9ubHkgYXNrIGJl Y2F1c2UgdGhlIFJGQyBwb2ludHMgb3V0IHRoYXQgYmFzZTMyaGV4IGlzIHRoZSBhbHBoYWJldCB1 c2VkIGJ5IEROU1NFQ+KAmXMgTlNFQzMgcmVjb3JkLiAgSeKAmW0gbm90IHN1cmUgaXQgbWF0dGVy cywgYnV0IHRoZSBSRkMgbWVudGlvbnM6DQoJT25lIHByb3BlcnR5IHdpdGggdGhpcyBhbHBoYWJl dCwgd2hpY2ggdGhlIGJhc2U2NCBhbmQgYmFzZTMyDQoJYWxwaGFiZXRzIGxhY2ssIGlzIHRoYXQg ZW5jb2RlZCBkYXRhIG1haW50YWlucyBpdHMgc29ydCBvcmRlciB3aGVuDQoJdGhlIGVuY29kZWQg ZGF0YSBpcyBjb21wYXJlZCBiaXQtd2lzZS4NCldvdWxkIHRoYXQgYmUgdXNlZnVsL3JlbGV2YW50 L2V0Yy4gaGVyZSB0b28/ICANCg0KSW4gZWl0aGVyIGNhc2UsIEkganVzdCB0aG91Z2h0IGl0IHdv dWxkIGJlIHdvcnRoIGNsYXJpZnlpbmcgaGVyZS4NCg0KRXJpYw== From nobody Sun Jul 26 01:21:01 2015 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 E55041A1A4B; Sun, 26 Jul 2015 01:20:59 -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 8MI1OYbM5YPg; Sun, 26 Jul 2015 01:20:58 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D7931A066C; Sun, 26 Jul 2015 01:20:58 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mfHK35Bjmz5B6; Sun, 26 Jul 2015 10:20:55 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=R9sZZhON X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id ZpBR6utdva3x; Sun, 26 Jul 2015 10:20:53 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sun, 26 Jul 2015 10:20:53 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D66D580042; Sun, 26 Jul 2015 04:20:52 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1437898852; bh=89ETkdMo9o+pLPiUD2dob0GXKyJqDeFWDQeL+LFo0fU=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=R9sZZhONBouriIUginx4bZagQXuUVb72B3S7c65MywXxxDF+3C1aRN/j7jCBVhjEu 1egkXsVaGr1HbhggGYod6473qjMfnyFXA97XAVSFWMDeRUFfiy54mv8K6xUara1mhv h+rL6zU//jhFK/5QYKtjZYnS4Rly/dmjiM1F0pvM= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t6Q8KqDl030840; Sun, 26 Jul 2015 04:20:52 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sun, 26 Jul 2015 04:20:52 -0400 (EDT) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <87bnf1hair.fsf@alice.fifthhorseman.net> User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: IETF OpenPGP , Daniel Kahn Gillmor , dane WG list Subject: Re: [dane] [openpgp] The DANE draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2015 08:21:00 -0000 On Sat, 25 Jul 2015, Phillip Hallam-Baker wrote: > On Sat, Jul 25, 2015 at 8:56 AM, Paul Wouters wrote: > > Answering phb and dkg: [note I stated my answer was to both you and dkg, and I used traditional ">" and ">>" which your email client seems to have eaten, so it is unfortunate if that causes further confusion to a lot of people's email client when reading this response] > That's not how I see it. It is surely a discovery and distribution > system for keys. But it is not a policy publication mechanism.  The > draft (carefully) does not tell you what you can or cannot do with the > key. Some people tried to propose this (mostly for smime) by having > different prefixes for _encrypt or _sign, but this was not adopted. > > Again, you don't seem to understand the spec. 'MUST USE TLS' is one of the purported benefits. Which specification are you refering to? The OPENPGPKEY specification does not say "MUST USE TLS". > Key pinning to a specific key is another. I assume you mean "key pinning to a specific user"? If so, the OpenPGP RFC already binds the public key and the various key ID's. Any such existing pinning is in the OpenPGP RFC. This draft does not modify OpenPGP in any way whatsoever. It only provides a discovery mechanism to find an openpgp key based on an email address. > Those are security policy. whether or not they are, they are not specified in this draft. > I think those should be taken out of DANE but that hasn't happened yet as far as I am aware. I don't even understand what you mean with "DANE" in this context. This draft has nothing to do with the TLSA record which _does_ do further security policy specification using Selectors and Usage types. This draft specifically does not use Selectors or Usage types and leaves all the openpgp key policies to the OpenPGP RFC options. Paul From nobody Sun Jul 26 02:11:13 2015 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 C215D1B2A05; Sun, 26 Jul 2015 02:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mv_koYZcSlKW; Sun, 26 Jul 2015 02:11:10 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABA621B2A01; Sun, 26 Jul 2015 02:11:09 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mfJQy3hSyz5G0; Sun, 26 Jul 2015 11:11:06 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=iJKOTCBh X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id wkK7qdASboUG; Sun, 26 Jul 2015 11:11:04 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sun, 26 Jul 2015 11:11:04 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 673EE80042; Sun, 26 Jul 2015 05:11:03 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1437901863; bh=4lPqdP+S68E+CAHCLwAYtJVK7skhOozrRIqZhPgJEw0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=iJKOTCBhzCENnC0iZxVXrOcEPljuh7z7rKbygJ71IJMvrMBrieR6mDvRu1ONzTB5K 7rcTkhLjc2o2yZs6QWsu12Wbtysb2NNX382IZonS2HQcE4BVKP7HJuog7KBZgnUsQo XoLEQ11B6Ozn+5KrqrSOcTHMyLUUN61/thPWUTUw= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t6Q9B2RM004850; Sun, 26 Jul 2015 05:11:02 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sun, 26 Jul 2015 05:11:02 -0400 (EDT) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <87si8dagiz.fsf@vigenere.g10code.de> User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: Werner Koch , IETF OpenPGP , dane WG list Subject: Re: [dane] [openpgp] The DANE draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2015 09:11:11 -0000 On Sat, 25 Jul 2015, Phillip Hallam-Baker wrote: > This document has not progressed "quickly". The original draft was > published in July 2013. No one is trying to rush this through > > I am quite happy waiting till 2016 or 2018.  > > If it isn't done right its better not to publish at all. While a worthwhile generic goal, let's do a reality check here. We are talking about assigning a DNS RRcode for an experimental RFC for storing RFC 4880 section 5 openpgp packet types into an RDATA field at a predictable DNS QNAME entry. If that takes 5 years, the IETF will be on its way to become irrelevant, and the associated working groups will be to blame for the proliferation of more TXT type records containing non-text content. It ignores that many of the original DNSSEC architects meant for the DNS to be able to securely store signed data. > I was a bit disappointed by the process: I learned about the I-D too late > and was surprised that it started out at the OpenPGP WG mailing list (2 > years ago?) with just a few messages and then continued at the DANE list > without having notified the OpenPGP list. > > This is now the fourth time I am having this discussion with you, so I > think your representation is not entirely fair. The previous discussions > ended with you saying we should not do this and stick to the CERT record > type and me stating why I disagree with that view. > > Ummm watch your attributions, that is Werner, not me. My apologies that was not made clearer. I indeed meant to indicate I was talking to Werner. > The DANE group has been rather ineffective in getting the constituencies they purport to be > serving to buy into their proposal. Are you referring to the OPENPGPKEY document when saying "their proposal" ? The DANE working group in general has the strange effect that it is completely ignored when it writes documents to use DNSSEC based Authentication (its main charter goal!) and only when documents are getting to WGLC, do people in other areas suddenly wake up and throw on the brakes waving their expert hats around saying that the DANE working group cannot make any decisions about their protocol. I've heard in hallway talks that some people felt so attacked that they basically left the DANE working group. We had a round of PKIX people, we had a round of email people, all coming in really late into the process. It would be really helpful if people get involved earlier in the process. > Additionally, because the CERT record is a meta-container record, > support for CERT is not good because to properly parse it you need > all of openpgp and all of x509 and all of what other subtypes would > be added later on. So instead of implementing CERT records partially, > many DNS implementations just did not bother with it at all. > > All of X509 isn't a big barrier. The point is preventing needless CVE's, not adding ASN.1 parsers and X.509 parsers where not needed. If you don't think X.509 is a problem, then you haven't been paying attention to CVE's. > I am not aware of any major crypto package that doesn't have the ability to parse X.509 I am not aware of any major crypto package that did not have a number of CVE's in their X.509 code. > . Werner isn't the only person who has a PKIX package in his OpenPGP library.  Actually, a quick ldd on /usr/bin/gpg* shows no libraries that I know of that do PKIX. And it would be good not to add new ones just because we are trying to save one DNS RRTYPE code point by re-using a bad idea from the past that is today basically unused (the CERT record). >  The CERT record is more flexible because it also allows the use of an >  indirect specification via fingerprint. > > Which is a problem not a feature. It makes the security model very > complex. > > No, the security model is complex because you are trying to use a vast, aging and vaguely > understood infrastructure with a byzantine administrative model to provide security. I am not even sure what refers to what in that sentence. DNS is a set of well maintained protocols, and RFC 4880 is solid and seeing an update now in the newly re-chartered openpgp working group. Email addresses in their current form while vast and old, aren't being obsoleted any time soon and I don't think my paul@nohats.ca address is aging. I also find it _really_ ironic that it is not the openpgp key servers that you are calling "vast, aging and vaguely understood infrastructure" because if anything is a dangerous misunderstood mess that we cannot seem to clean up, it is the current electronic garbage heap of pgp keys we can never clean up because the owners lost their keys or the keys were generated and uploaded by those not actually being the real owners of those email address specified in the openpgp key id. It is _really_ difficult to design any other method of openpgp key distribution that would be _worse_ than the current key servers. > Failing to accept that fact is one of the many reasons people are skeptical of this project and > looking for ways to work round it. And this is an actual real problem. There is no valid reason for needing to "work around" an experimental proposal that has a significant backing of people in the IETF, the mail community and opensource software writers and distributions. This document is not a protocol extension you are forced to deal even though you never wanted to. You can simply not publish OPENPGPKEY records and remain as secure as you are today. If there are real security issues or operational issues that this draft might cause, then I would love to hear those. But I've spoken with the bind implementors and others and they know how to serve big zones and big records and know how to deal with DOS attacks. They do not see this record as harmful. The latest suggested base32/split for QNAME was suggested to support the issues raised by the email and online signing communities. If you have any specific security concerns about the draft that is not addressed in the security section, let's discuss those on the list(s) and fix it. Paul From nobody Sun Jul 26 07:38:16 2015 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 8BBC01A89C7 for ; Sun, 26 Jul 2015 07:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, 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 d5_4lFeoGUmM for ; Sun, 26 Jul 2015 07:38:13 -0700 (PDT) Received: from ryujin.darkdna.net (ryujin.darkdna.net [IPv6:2600:3c00::2:ffff]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D43D1A898B for ; Sun, 26 Jul 2015 07:38:11 -0700 (PDT) Received: from localhost (unknown [IPv6:fdcf:3c00:e001::101]) by ryujin.darkdna.net (Postfix) with ESMTP id 3mfRhJ6BSzz19bW for ; Sun, 26 Jul 2015 14:38:08 +0000 (UTC) Received: from ryujin.darkdna.net ([IPv6:fdcf:3c00:e001::100]) by localhost (otohime.darkdna.net [IPv6:fdcf:3c00:e001::101]) (amavisd-new, port 10026) with ESMTP id FIP7gbJ0olhS for ; Sun, 26 Jul 2015 14:38:02 +0000 (UTC) Received: from coyo-K55VJ (pool-71-164-173-165.dllstx.fios.verizon.net [71.164.173.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ryujin.darkdna.net (Postfix) with ESMTPSA id 3mfRhB3DHQz19bV for ; Sun, 26 Jul 2015 14:38:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=darkdna.net; s=mail; t=1437921482; bh=3SH9JBkdn7SHkzvQKDyLz8gCwPebS0ypdIraDUX9Hkk=; h=Date:From:To:Subject:In-Reply-To:References; b=tkiXXCfLgGh4FEd188mKJ5A2hx74e60zVSYCVx0CXha1O+NdW4MIX53K3yXp5zS/t 8ui5IdLQUzU2kGexSvrgsvFw1a7DF3CnbW7r3T4IQbnLwkHVgHB6e5RHw2LSHkF0C0 4rQzTsQkAbghuIPaFDCyOSXllZ+BHae9TmzTzxYg= Date: Sun, 26 Jul 2015 09:38:02 -0500 From: Coyo To: dane@ietf.org Message-Id: <20150726093802.763f57e77d2810e4f4facc14@darkdna.net> In-Reply-To: References: <87si8dagiz.fsf@vigenere.g10code.de> X-Mailer: Sylpheed 3.4.2 (GTK+ 2.24.27; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: [dane] Is running a DANE nameserver for a TLD as complex as running a CA? 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, 26 Jul 2015 14:38:14 -0000 Or am I fundementally misunderstanding something? I apologize in advance if this seems like a dumb question, but I was not able to find a definitive answer. From nobody Sun Jul 26 08:18:21 2015 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 27EA31A916F for ; Sun, 26 Jul 2015 08:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 NJ2XBJfzoxRJ for ; Sun, 26 Jul 2015 08:18:18 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DAF91A906D for ; Sun, 26 Jul 2015 08:18:18 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 473DA282FB1; Sun, 26 Jul 2015 15:18:11 +0000 (UTC) Date: Sun, 26 Jul 2015 15:18:11 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150726151810.GW4347@mournblade.imrryr.org> References: <87si8dagiz.fsf@vigenere.g10code.de> <20150726093802.763f57e77d2810e4f4facc14@darkdna.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150726093802.763f57e77d2810e4f4facc14@darkdna.net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] Is running a DANE nameserver for a TLD as complex as running a CA? 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: Sun, 26 Jul 2015 15:18:20 -0000 On Sun, Jul 26, 2015 at 09:38:02AM -0500, Coyo wrote: > [ Is running a DANE nameserver for a TLD as complex as running a CA? ] > > Or am I fundementally misunderstanding something? In short no. Firstly, there's no such thing as a "DANE nameserver", rather there are nameservers authoritative for a DNSSEC signed zone that happens to include DANE records. Running a DNSSEC signed zone is not especially complex. As for the DANE records, if you have so many servers that it makes to consolidate the various TLSA records into a single trust-anchor record, and issue the servers certificates signed by that trust anchor, then you're running a CA, which is as complex as running a CA (whatever that means). If on the other hand the number of servers to manage is small enough, or you have simplified the coordination of server certificates with the publication of corresponding TLSA (or other DANE) records, then it is not like running a CA, but rather like running a public key whitepages service. -- Viktor. From nobody Sun Jul 26 08:21:29 2015 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 5CBDD1A9084 for ; Sun, 26 Jul 2015 08:21:27 -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 bhn-dduV__s8 for ; Sun, 26 Jul 2015 08:21:25 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38B801A906D for ; Sun, 26 Jul 2015 08:21:25 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mfSfB4W56zD7m; Sun, 26 Jul 2015 17:21:22 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=l6w7zDye X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 5mAbDnFXl7E0; Sun, 26 Jul 2015 17:21:20 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sun, 26 Jul 2015 17:21:20 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 2200E80042; Sun, 26 Jul 2015 11:21:19 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1437924079; bh=PxfFhmYIhe6V7zfR/JkIG4JuRUmE6Oh8ZinCh4LiPn8=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=l6w7zDyeerQmwyR5UnuKDDfFsNY3DvdHIWnW9Dc1l6xqJNdji0SJYI++vAO7I+NiY lovAp16s1z+jfZsv07WW+rbwES5Hohn1KnFNndfb2waTXfhGOGCtCrXudiwVDbIRLs CmeYjbXucUrQfi+TSFF/jKB+8USb8iH3HsT7ebLw= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t6QFLHN4000938; Sun, 26 Jul 2015 11:21:17 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sun, 26 Jul 2015 11:21:17 -0400 (EDT) From: Paul Wouters To: "Osterweil, Eric" In-Reply-To: Message-ID: References: <1437580854.052529954@apps.rackspace.com> User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: "dane@ietf.org" Subject: Re: [dane] OPENPGP and SMIME local part question 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, 26 Jul 2015 15:21:27 -0000 On Sat, 25 Jul 2015, Osterweil, Eric wrote: >> The sense of the room in the IETF-93 meeting was to do do a BASE32 encoding of local part with 60 character labels, >> shortest label is the left most label. > Just to clarify, we’re not talking about Base32Hex (Section 7 of https://tools.ietf.org/html/rfc4648#section-7 ), right? I only ask because the RFC points out that base32hex is the alphabet used by DNSSEC’s NSEC3 record. I’m not sure it matters, but the RFC mentions: > One property with this alphabet, which the base64 and base32 > alphabets lack, is that encoded data maintains its sort order when > the encoded data is compared bit-wise. > Would that be useful/relevant/etc. here too? Correct, we are talking about base32 and not base32hex encoding. The sorting does not matter for us as these are one to one lookups and we are not building any chains. > In either case, I just thought it would be worth clarifying here. We will add a reference to section 6 specifically to avoid confusion. Thanks, Paul From nobody Sun Jul 26 18:21:14 2015 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 E838A1A0033 for ; Sun, 26 Jul 2015 18:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.978 X-Spam-Level: X-Spam-Status: No, score=-3.978 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_MED=-2.3, SPF_HELO_PASS=-0.001, 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 HkTxBE3taFZ2 for ; Sun, 26 Jul 2015 18:21:11 -0700 (PDT) Received: from ryujin.darkdna.net (ryujin.darkdna.net [69.164.196.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5BE41A0030 for ; Sun, 26 Jul 2015 18:21:10 -0700 (PDT) Received: from localhost (unknown [IPv6:fdcf:3c00:e001::101]) by ryujin.darkdna.net (Postfix) with ESMTP id 3mfjyG1SZPz19bW for ; Mon, 27 Jul 2015 01:21:10 +0000 (UTC) Received: from ryujin.darkdna.net ([IPv6:fdcf:3c00:e001::100]) by localhost (otohime.darkdna.net [IPv6:fdcf:3c00:e001::101]) (amavisd-new, port 10026) with ESMTP id vTNh6zuOobdf for ; Mon, 27 Jul 2015 01:21:09 +0000 (UTC) Received: from coyo-K55VJ (pool-71-164-173-165.dllstx.fios.verizon.net [71.164.173.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ryujin.darkdna.net (Postfix) with ESMTPSA id 3mfjyF6T8Tz19bV for ; Mon, 27 Jul 2015 01:21:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=darkdna.net; s=mail; t=1437960069; bh=xfGo4S0GDoDYfLaQKsE8LxAw8AKh68ESHjqCWEIyoNI=; h=Date:From:To:Subject:In-Reply-To:References; b=TeOwwj1ej7XHuUWsYJ2q678uwqbTznbvlOaxpnVbIUGJxjR/5ZjpOpRfkUhNUG2EV 2K2U6YeSNUcX6LPSazvKLXRqCkJhwI79Uc0cQ7tUZ5IvaEzpDvffbcAOQZ7HpV77AD iay9YPiRhhuxGyjZEsRMRrhGQ2iKpep5lkisIEoE= Date: Sun, 26 Jul 2015 20:21:09 -0500 From: Coyo To: dane@ietf.org Message-Id: <20150726202109.b7fa73e07082093151ac977a@darkdna.net> In-Reply-To: <20150726151810.GW4347@mournblade.imrryr.org> References: <87si8dagiz.fsf@vigenere.g10code.de> <20150726093802.763f57e77d2810e4f4facc14@darkdna.net> <20150726151810.GW4347@mournblade.imrryr.org> X-Mailer: Sylpheed 3.4.2 (GTK+ 2.24.27; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dane] Is running a DANE nameserver for a TLD as complex as running a CA? 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 Jul 2015 01:21:14 -0000 On Sun, 26 Jul 2015 15:18:11 +0000 Viktor Dukhovni wrote: > On Sun, Jul 26, 2015 at 09:38:02AM -0500, Coyo wrote: > > > [ Is running a DANE nameserver for a TLD as complex as running a CA? ] > > > > Or am I fundementally misunderstanding something? > > In short no. Firstly, there's no such thing as a "DANE nameserver", > rather there are nameservers authoritative for a DNSSEC signed zone > that happens to include DANE records. > > Running a DNSSEC signed zone is not especially complex. > > As for the DANE records, if you have so many servers that it makes > to consolidate the various TLSA records into a single trust-anchor > record, and issue the servers certificates signed by that trust > anchor, then you're running a CA, which is as complex as running > a CA (whatever that means). > > If on the other hand the number of servers to manage is small > enough, or you have simplified the coordination of server certificates > with the publication of corresponding TLSA (or other DANE) records, > then it is not like running a CA, but rather like running a public > key whitepages service. > > -- > Viktor. Thank you, that was helpful. I greatly appreciate your wisdom. From nobody Sun Jul 26 21:20:17 2015 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 158591A889C; Sun, 26 Jul 2015 21:20:14 -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 vdbhWeQZgMRB; Sun, 26 Jul 2015 21:20:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EACD71A88BE; Sun, 26 Jul 2015 21:20:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.1.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150727042008.17161.58432.idtracker@ietfa.amsl.com> Date: Sun, 26 Jul 2015 21:20:08 -0700 Archived-At: Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-ops-14.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 Jul 2015 04:20:14 -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-14.txt Pages : 30 Date : 2015-07-26 Abstract: This document clarifies and updates the DNS-Based Authentication of Named Entities (DANE) TLSA specification (RFC6698) 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: https://tools.ietf.org/html/draft-ietf-dane-ops-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dane-ops-14 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 Sun Jul 26 23:50:27 2015 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 95E461ACE1F for ; Sun, 26 Jul 2015 23:50:25 -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=unavailable 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 z5YCXFXQ_fQp for ; Sun, 26 Jul 2015 23:50:24 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 252ED1ACE04 for ; Sun, 26 Jul 2015 23:50:24 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1ZJcEw-0002gB-JX for ; Mon, 27 Jul 2015 08:50:22 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1ZJcEL-0005g5-1d; Mon, 27 Jul 2015 08:49:45 +0200 From: Werner Koch To: Paul Wouters References: <87si8dagiz.fsf@vigenere.g10code.de> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com Mail-Followup-To: Paul Wouters , Phillip Hallam-Baker , IETF OpenPGP , dane WG list Date: Mon, 27 Jul 2015 08:49:44 +0200 In-Reply-To: (Paul Wouters's message of "Sun, 26 Jul 2015 05:11:02 -0400 (EDT)") Message-ID: <87io968587.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: Phillip Hallam-Baker , dane WG list , IETF OpenPGP Subject: Re: [dane] [openpgp] The DANE draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2015 06:50:25 -0000 On Sun, 26 Jul 2015 11:11, paul@nohats.ca said: > X.509 parsers where not needed. If you don't think X.509 is a problem, > then you haven't been paying attention to CVE's. There is a lot more X.509 code in use than OpenPGP code and thus it might be unfair to compare CVE counts. But sure, BER encoding along with all bug compatibility stuff is a mess. > Actually, a quick ldd on /usr/bin/gpg* shows no libraries that I know of > that do PKIX. And it would be good not to add new ones just because we Do it on gpgsm and dirmngr and you will find libksba [1] which provides the X.509 and CMS parser and builder. gpgsm does high level processing including validation and dirmngr takes care of CRLs and OCSP. > I also find it _really_ ironic that it is not the openpgp key servers > that you are calling "vast, aging and vaguely understood infrastructure" > because if anything is a dangerous misunderstood mess that we cannot > seem to clean up, it is the current electronic garbage heap of pgp > keys we can never clean up because the owners lost their keys or We do not want to clean that up - there is and should be no need to ever delete a public key from a public server. Unfortunatly the keyservers are also the only working solution to map mail addresses to keys/fingerprints. This is the practical problem we need to solve - not the public storage of the keys. > the keys were generated and uploaded by those not actually being the > real owners of those email address specified in the openpgp key id. What is an "owner" of a mail address? Definitely nothing a keyserver has to decide. > It is _really_ difficult to design any other method of openpgp key > distribution that would be _worse_ than the current key servers. Nope. As I menotioned: distribution is not the problem. Association of mail addresses to keys is the problem because the WoT does not really scale. > And this is an actual real problem. There is no valid reason for needing > to "work around" an experimental proposal that has a significant backing > of people in the IETF, the mail community and opensource software Experimental? I might be confused but draft-ietf-dane-openpgpkey-03 states Standards Track and Intended Status. Salam-Shalom, Werner [1] KSBA = rot13("XFON") // X-Five-O-Nine -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Mon Jul 27 05:43:37 2015 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 4D02F1B2CB2; Mon, 27 Jul 2015 05:43:35 -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 vpqHQ5YSQqi4; Mon, 27 Jul 2015 05:43:31 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6646B1B2CD1; Mon, 27 Jul 2015 05:43:31 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mg15X6r3CzDCl; Mon, 27 Jul 2015 14:43:28 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=VLrzlacm X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id SycHWEtnp6bx; Mon, 27 Jul 2015 14:43:26 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 27 Jul 2015 14:43:26 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 6D287800AD; Mon, 27 Jul 2015 08:43:25 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1438001005; bh=YioIGapDPO7ZEYDV4NIK2MOFVnKE7zy0GLwuxwhUALI=; h=Date:From:To:cc:Subject; b=VLrzlacmf9pB9fsJmLrlIKId2nLkHFTEvTyLVO6cM250+3QGBySoGZjkQPyu3ZyGf chIORak3yw6Lt8+4dp5YAgsdrW/E2shq+r6lp/SkfK/xBnckVWHX4wpfQTO1qLlg/g OQvFT19ljSGwmYIxinxSCFF56g/Een1EvCja++sI= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t6RChOSp030088; Mon, 27 Jul 2015 08:43:25 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 27 Jul 2015 08:43:24 -0400 (EDT) From: Paul Wouters To: Werner Koch Message-ID: User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Cc: IETF OpenPGP , dane WG list Subject: Re: [dane] key distribition and IETF document status 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 Jul 2015 12:43:35 -0000 On Mon, 27 Jul 2015, Werner Koch wrote: >> I also find it _really_ ironic that it is not the openpgp key servers >> that you are calling "vast, aging and vaguely understood infrastructure" >> because if anything is a dangerous misunderstood mess that we cannot >> seem to clean up, it is the current electronic garbage heap of pgp >> keys we can never clean up because the owners lost their keys or > > We do not want to clean that up - there is and should be no need to ever > delete a public key from a public server. Then you really need better tools that filter out bogus and older keys, if this has to work for average users. One of my old keys uses idea which most people couldn't even use if they fetched the older instead of newer key. >> the keys were generated and uploaded by those not actually being the >> real owners of those email address specified in the openpgp key id. > > What is an "owner" of a mail address? Definitely nothing a keyserver > has to decide. right. But at least with DNSSEC, at this moment, you know that no one can publish OPENPGPKEY records for paul@nohats.ca except those who run nohats.ca. That's already a lot more pinned down then the current key servers. If you say people can manually pick out the latest key to avoid using my old expired or forgotten keys, than it makes people more vulnerable to recently added bogus keys by others. Which is why I think this is the worst distribution/discovery mechanism. >> And this is an actual real problem. There is no valid reason for needing >> to "work around" an experimental proposal that has a significant backing >> of people in the IETF, the mail community and opensource software > > Experimental? I might be confused but draft-ietf-dane-openpgpkey-03 > states Standards Track and Intended Status. I will double check with the chairs what conclusion was reached on this. I thought at the ietf92 in Dallas it was thought to become Experimental. > Nope. As I menotioned: distribution is not the problem. > Huh? The main pool currently as 105 active servers; 108 are not > currently qualified due to operation problems or not enough sync sites. > See > > https://sks-keyservers.net/status/ > > pgp.mit.edu is just fine if you don't mind that it runs only on legacy > IP. There might be 100 of those, but those using the tools can't just let the tools find them, so if I'm on the wrong side of the Great Firewall, the only names I know of servers to use would be pgp.mit.edu, keys.pgpi.net (is that still alive even?) or pgp.surfnet.nl. for example, gpg fails: [paul@thinkpad ~]$ gpg --recv-key 0x12345678 gpg: requesting key 0x12345678 from hkp server search.keyserver.net gpgkeys: HTTP fetch error 6: Could not resolve host: search.keyserver.net So from a practical point of view, for newbies there are 0 key servers and for those who were around during Crypto War I, there are two or three key servers. Until today, I had not even heard of sks-keyservers.net, and I'm probably a long term, better than average informed security user. So in my view, distribution is a very big problem the current key servers and tools are not handling well. Note that I checked enigmail and it does seem use pool.sks-keyservers.net (also, apparently it had two different keys with ID 0x12345678) I know John Gilmore also had additional patches for gnupg to assist with keyring discovery in the same LAN, aimed at keysigning parties, but those patches were apparently reject and he has given up on this project. Having been at too many failed key signing parties, that makes me sad. Related pet peeves: you cannot use --recv-key 0x12345678 --keyserver pool.sks-keyservers.net (the order matters) I'm not smart enough to remember if it is --keyserver or --key-server or --keyservers or --key-servers, or --recvkeys or --recv-keys or --recvkey or --recv-key. Some aliases would be really nice here. Paul From nobody Mon Jul 27 06:50:36 2015 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 0E09D1B2DBD for ; Mon, 27 Jul 2015 06:50:28 -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=unavailable 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 92mT4RT1l-on for ; Mon, 27 Jul 2015 06:50:24 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 878351B2DBA for ; Mon, 27 Jul 2015 06:50:24 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1ZJinO-0002pk-Mo for ; Mon, 27 Jul 2015 15:50:22 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1ZJimd-0006mo-Im; Mon, 27 Jul 2015 15:49:35 +0200 From: Werner Koch To: Paul Wouters References: Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com Mail-Followup-To: Paul Wouters , IETF OpenPGP , dane WG list Date: Mon, 27 Jul 2015 15:49:35 +0200 In-Reply-To: (Paul Wouters's message of "Mon, 27 Jul 2015 08:43:24 -0400 (EDT)") Message-ID: <87mvyh7lsg.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IETF OpenPGP , dane WG list Subject: Re: [dane] [openpgp] key distribition and IETF document status 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 Jul 2015 13:50:28 -0000 On Mon, 27 Jul 2015 14:43, paul@nohats.ca said: > Then you really need better tools that filter out bogus and older keys, > if this has to work for average users. One of my old keys uses idea NO! There a no bogus keys. It is a desirable feature that you can't remove the keys. If you want to revoke a key or user id you upload a copy of the key with the revocation certificiate. > right. But at least with DNSSEC, at this moment, you know that no one > can publish OPENPGPKEY records for paul@nohats.ca except those who run > nohats.ca. That's already a lot more pinned down then the current key Right and it is a Good Thing. I proposed that 9 years ago [1]. > There might be 100 of those, but those using the tools can't just let > the tools find them, so if I'm on the wrong side of the Great Firewall, > the only names I know of servers to use would be pgp.mit.edu, The example from gpg's conf file template is hkp://keys.gnupg.net which is just a CNAME for the mentioned pool.sks-keyservers.net. > [paul@thinkpad ~]$ gpg --recv-key 0x12345678 > gpg: requesting key 0x12345678 from hkp server search.keyserver.net keyserver.net is a proprietary keyserver services from a Belgian(?) company. I was not aware that this server still exists; it is/was also not synced with the regular keyserver network.=20 > three key servers. Until today, I had not even heard of > sks-keyservers.net, and I'm probably a long term, better than average SKS has replaced Marc's keyserver ~12 years ago. Bascially all sites are using it and perhabs keys.pgp.mit was the last to switch a few years ago. The old commonly pool used to be subkeys.pgp.net. For some time keys.gnupg.net ran its own pool but eventually it switched to the well maintained sks-keyservers.net pool. > Note that I checked enigmail and it does seem use pool.sks-keyservers.net > (also, apparently it had two different keys with ID 0x12345678) Always use the long keyid - there are less duplicates. And of course using the fingerprint is the canonical right way of specifiying keys. > I know John Gilmore also had additional patches for gnupg to assist > with keyring discovery in the same LAN, aimed at keysigning parties, but > those patches were apparently reject and he has given up on this project. We talked about that but he did not send any patches and iirc he gave up on this. gpg's new --quick-* commands have been implemented on his request. > you cannot use --recv-key 0x12345678 --keyserver pool.sks-keyservers.net > (the order matters) gpg's requires that option come before other arguments (classic Unix style, partly done this way for compatibility with pgp 2). Thus the above is equivalent to gpg --recv-key -- 0x12345678 --keyserver pool.sks-keyservers.net and --keyserver is thus not considered an option.=20=20=20 > I'm not smart enough to remember if it is --keyserver or --key-server or $ gpg --dump-options | grep keyserv --keyserver --keyserver-options --sig-keyserver-url --default-keyserver-url Shalom-Salam, Werner [1] W. Koch, =E2=80=9CPublic key association,=E2=80=9D in GUUG Fr=C3=BChjah= rsfachgespr=C3=A4che 2006: Proceedings. K=C3=B6ln, Germany: GUUG, 2006, pp. 159=E2=80=93167. [Online]. Available: http://g10code.com/docs/pka-intro.de.pdf --=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Mon Jul 27 08:03:12 2015 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 621931B2E68; Mon, 27 Jul 2015 08:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.423 X-Spam-Level: * X-Spam-Status: No, score=1.423 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 W6JPPif3KBB2; Mon, 27 Jul 2015 08:02:59 -0700 (PDT) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 400641B2E66; Mon, 27 Jul 2015 08:02:58 -0700 (PDT) Received: by lblf12 with SMTP id f12so55446519lbl.2; Mon, 27 Jul 2015 08:02:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=bsGt2pWZQfB36Ye2jJ0b83oYi0Qrl1agbnWlT000qvk=; b=p+lFYJTQga38NgYAbxfVYiPjoZxqVZfQNy11MtoMbu/77AJkhvzOYbshVNPQcp7MvA kbYqmoYGZA6PUngIytRw5hBm2G5SzmRg+BtF3QXk02PS13sFZAM/F8VyxDopmCQopLCb 0lBUnJFGEAUJG1C+9Q4NzEROGNuuNdE/F6zf9uff1uVJNQ8Uihvxw5IOLfrG6tbouBeb ulrymgpX5OYPF/FHtOv3IcPIoPoJtKZbbT58th2CbfJA1bKEwM1HXkX1EPhPl4v2PaFc ExJtnOrUofJh28lJdhiIH0HcpVFzQ6ewr5zvuehRioAhpsa9vpGU6RcYF+7lCn1JNpd7 QN0w== MIME-Version: 1.0 X-Received: by 10.112.167.202 with SMTP id zq10mr26883850lbb.118.1438009376670; Mon, 27 Jul 2015 08:02:56 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Mon, 27 Jul 2015 08:02:56 -0700 (PDT) Date: Mon, 27 Jul 2015 11:02:56 -0400 X-Google-Sender-Auth: QqitSSf4Sy6cupiISgMnZKA_hvc Message-ID: From: Phillip Hallam-Baker To: "therightkey@ietf.org" , IETF OpenPGP , "dane@ietf.org" , smime@ietf.org Content-Type: multipart/alternative; boundary=001a11c269c2148aae051bdca6ef Archived-At: Subject: [dane] Using composite PKIs 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 Jul 2015 15:03:01 -0000 --001a11c269c2148aae051bdca6ef Content-Type: text/plain; charset=UTF-8 [Followups on therightkey please] Thinking about the discussion of the OpenPGP/DANE draft in OpenPGP in my car, I came up with a metaphor for how to approach joining different PKIs. In particular, Werner's comment that Web of Trust doesn't scale. The CA model does scale but it isn't actually much better when trying to identify private individuals rather than employees of a company since the only thing I can validate economically is an email address and that isn't a person. We can approach the problem mathematically by considering the work factor (in US$) for causing a breach. Combining Web of Trust with CA approaches and interning the assertions in an immutable blockchain like log does provide an approach that scales. The blockchain makes the workfactor time dependent. If the workfactor is $100 before an assertion is enrolled, it will be $trillions after. Combining Web of Trust and CA trust is like building a dalek out of fiberglass: Individually, the glass fiber and the epoxy are weak. But using the two in combination locks the strands of glass fibre creating a lightweight shell that can support the weight of a small truck. This part is already written up: https://datatracker.ietf.org/doc/draft-hallambaker-prismproof-trust/ The question we are facing now is how we make sense of that type of data. Which is where the car trip comes in. I am using GPS to navigate a part of the city I don't know very well. There are multiple resources at my disposal: 1) My own knowledge of the area 2) Signposts on the road 3) The GPS maps in the car 4) Offline maps via my cell phone Any one of these guides can be fallible. The GPS maps are pre big-dig (no CANBUS modem car for me) so they are out of date. Offline maps are more likely to be up to date but a malicious provider can direct specific individuals to the wrong place. The fact that there is a human in the loop actually keeps the mapping service providers accountable. Even if 99% of drivers don't know where they are going. The fact that there are roadsigns and the fact that a few do know where they are going means that if the service defects, they are likely to be caught. Using a pure online mapping service like Google Maps and a thin client means that I am always up to date but exposes all my movements to them. It also breaks if I am in Prague on a crappy AT&T data plan costing $20/Mb for international roaming. [Do the AT&T execs consider the semiotics of sending their customers a text message saying 'we are going to try to steal from you now' every time they cross an international border. Using a pure offline map like the DVDRom based system in the Honda means that nobody can track me by my use of a mapping service. It also means that the maps are ten years out of date as I don't plan on replacing the van till the child whose car seat it was built to fit has learned to drive and won't trash the transmission. The best map I have is actually an application on the phone that has downloadable maps for the whole of Europe and North America. The mapping service obviously preprocesses the maps so that the phone has as little work to do as possible. So it is a 'thick client' but not as thick as it might be. I think the key to making a composite PKI work is to approach the problem in a similar fashion. In the short term we want to be using the 'thin client' as this allows us to change how we analyze data and add new formats. When trying to develop a new protocol, agility is key. But the medium term goal is to have a thick-ish client. --001a11c269c2148aae051bdca6ef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
[Followups on therightkey please]

Think= ing about the discussion of the OpenPGP/DANE draft in OpenPGP in my car, I = came up with a metaphor for how to approach joining different PKIs. In part= icular, Werner's comment that Web of Trust doesn't scale. The CA mo= del does scale but it isn't actually much better when trying to identif= y private individuals rather than employees of a company since the only thi= ng I can validate economically is an email address and that isn't a per= son.

We can approach the problem mathematically by= considering the work factor (in US$) for causing a breach.

<= /div>
Combining Web of Trust with CA approaches and interning the asser= tions in an immutable blockchain like log does provide an approach that sca= les. The blockchain makes the workfactor time dependent. If the workfactor = is $100 before an assertion is enrolled, it will be $trillions after.=C2=A0=

Combining Web of Trust and CA trust is like build= ing a dalek out of fiberglass: Individually, the glass fiber and the epoxy = are weak. But using the two in combination locks the strands of glass fibre= creating a lightweight shell that can support the weight of a small truck.= This part is already written up:



The question we are facing now is how we ma= ke sense of that type of data. Which is where the car trip comes in.
<= div>
I am using GPS to navigate a part of the city I don'= t know very well. There are multiple resources at my disposal:
1) My own knowledge of the area
2) Signposts on the = road
3) The GPS maps in the car
4) Offline maps via my = cell phone

Any one of these guides can be fallible= . The GPS maps are pre big-dig (no CANBUS modem car for me) so they are out= of date. Offline maps are more likely to be up to date but a malicious pro= vider can direct specific individuals to the wrong place.

The fact that there is a human in the loop actually keeps the mappi= ng service providers accountable. Even if 99% of drivers don't know whe= re they are going. The fact that there are roadsigns and the fact that a fe= w do know where they are going means that if the service defects, they are = likely to be caught.

Using a pure online mapping s= ervice like Google Maps and a thin client means that I am always up to date= but exposes all my movements to them. It also breaks if I am in Prague on = a crappy AT&T data plan costing $20/Mb for international roaming. [Do t= he AT&T execs consider the semiotics of sending their customers a text = message saying 'we are going to try to steal from you now' every ti= me they cross an international border.

Using a pur= e offline map like the DVDRom based system in the Honda means that nobody c= an track me by my use of a mapping service. It also means that the maps are= ten years out of date as I don't plan on replacing the van till the ch= ild whose car seat it was built to fit has learned to drive and won't t= rash the transmission.

The best map I have is actu= ally an application on the phone that has downloadable maps for the whole o= f Europe and North America. The mapping service obviously preprocesses the = maps so that the phone has as little work to do as possible. So it is a = 9;thick client' but not as thick as it might be.


I think the key to making a composite PKI work is to appr= oach the problem in a similar fashion. In the short term we want to be usin= g the 'thin client' as this allows us to change how we analyze data= and add new formats. When trying to develop a new protocol, agility is key= . But the medium term goal is to have a thick-ish client.
--001a11c269c2148aae051bdca6ef-- From nobody Tue Jul 28 03:52:49 2015 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 E97961A889F for ; Tue, 28 Jul 2015 03:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Br-Zg8_OVKwJ for ; Tue, 28 Jul 2015 03:52:45 -0700 (PDT) Received: from mail-qg0-f100.google.com (mail-qg0-f100.google.com [209.85.192.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B884A1A889B for ; Tue, 28 Jul 2015 03:52:45 -0700 (PDT) Received: by qgii95 with SMTP id i95so6333511qgi.0 for ; Tue, 28 Jul 2015 03:52:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :user-agent:content-type:content-id:content-transfer-encoding :mime-version; bh=NqZzYqb+THkTyc39a1pylNMhS260l/9WKYhs7jG1CFs=; b=Pvycx1+g+LbeXJPAhETznKi/+bgDuys+ZJLISZf4e+3Su6T3wCf5oU2SSDTjz5PIc6 S9xirRVYuSHanlTWIAeTk/VxsroUdxhkEvT+p+m4IfJPuij8LT82xL6vJ8aEYWaetFYf eUfIcL2mOiHWiEpxl6iT58D2znQV9XIqWh1Cx/6fxWIzyQWXf4wRo32hiwFIrTixynB4 aH436Ruqu6mYdVJ2VpjTM5/pdrdV1o+5mriqmSRzadGJPSZWacWh3sx4VtJidnpTs/tp Q1eFa18DdhxYvfxm8sBs47EhX1kHDMnr3RzjCI1HftCavNk6XbyDgqZuohjQMsKEvGZF FqWw== X-Gm-Message-State: ALoCoQmeF38m2tt/MVCHGcx/7CdARCYqbSIymqPtvZMPqnRx8v7y/DqqhHhX2FYCJnj+6weMdCgR/QA+ci6j4/+YRYkj2YTKrw== X-Received: by 10.140.31.194 with SMTP id f60mr48026355qgf.23.1438080764999; Tue, 28 Jul 2015 03:52:44 -0700 (PDT) Received: from brn1lxmailout01.verisign.com (brn1lxmailout01.verisign.com. [72.13.63.41]) by smtp-relay.gmail.com with ESMTPS id 17sm6535179qky.3.2015.07.28.03.52.44 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 28 Jul 2015 03:52:44 -0700 (PDT) X-Relaying-Domain: verisign.com Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02 [10.173.152.206]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id t6SAqi6C014746 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Jul 2015 06:52:44 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 28 Jul 2015 06:52:43 -0400 From: "Wiley, Glen" To: Coyo , "dane@ietf.org" Thread-Topic: [dane] Is running a DANE nameserver for a TLD as complex as running a CA? Thread-Index: AQHQySOHhXevLnNU0EqduJTaothWpg== Date: Tue, 28 Jul 2015 10:52:43 +0000 Message-ID: References: <87si8dagiz.fsf@vigenere.g10code.de> <20150726093802.763f57e77d2810e4f4facc14@darkdna.net> In-Reply-To: <20150726093802.763f57e77d2810e4f4facc14@darkdna.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <9337229221E64E448B1FDC269CE49675@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [dane] Is running a DANE nameserver for a TLD as complex as running a CA? 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, 28 Jul 2015 10:52:48 -0000 It might help if you offered more specific points to your question. Serving DANE style records for a TLD probably doesn=B9t make much sense as those records have more meaning for a SLD. Are you asking about running a DNSSEC capable name server or serving a signed zone? --=20 Glen Wiley Principal Engineer Verisign, Inc. (571) 230-7917 http://vbsdcon.com A5E5 E373 3C75 5B3E 2E24 6A0F DC65 2354 9946 C63A On 7/26/15, 10:38 AM, "Coyo" wrote: >Or am I fundementally misunderstanding something? > >I apologize in advance if this seems like a dumb question, but I was not >able to find a definitive answer. > >_______________________________________________ >dane mailing list >dane@ietf.org >https://www.ietf.org/mailman/listinfo/dane From nobody Tue Jul 28 05:11:20 2015 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 C65811A8A28 for ; Tue, 28 Jul 2015 05:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 I5-msMfkbbbz for ; Tue, 28 Jul 2015 05:11:16 -0700 (PDT) Received: from mail-oi0-f100.google.com (mail-oi0-f100.google.com [209.85.218.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 918E21A8A29 for ; Tue, 28 Jul 2015 05:11:16 -0700 (PDT) Received: by oibo126 with SMTP id o126so6415943oib.0 for ; Tue, 28 Jul 2015 05:11:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:accept-language:content-language:user-agent:content-type :mime-version; bh=MMBIVNHzIyeSoYvB404rl6eklQQzFBnWSnm6Ow69Owg=; b=PD7CnvV+aT/JHjefE9AJOdBuGvGd8/Z3a1oelNdw1uIepFm+MawfKoZvGloMus5GEj gtQIi8zE+lhY2Lk7pAQy0fk8UYyQL61yN+EunaVQKFPreLLiq01/DZCgkAuoiw+bs8h1 UEPYqrtt6GwwYfqYdmvRvtvtYA9uMkqcGKDxeo4axzpNJQmWJm13dPk1a1Qt7dY1QXYF 9Aem7Oi89oSGKEQOi0inza1+ayg9nPUMizFDJmwxNpuOItwYfQII7o+8OGQna1ppdcrM ByUnWnejwbbUIGO7BDo4T+CcmSteJdpfXIndB1P8ZUSg9v+z2wETK9060jmKJmpet6fZ Wlzg== X-Gm-Message-State: ALoCoQkATMgd9NQsZw4Ztu6JJpow4Ng8vhU/fjI2FfZxc42bJHtXqsQoy9CeIodR9kGzQJ49Dz4AIalCt4/kXb7geHJED4m4cA== X-Received: by 10.55.27.92 with SMTP id b89mr49118393qkb.80.1438085475916; Tue, 28 Jul 2015 05:11:15 -0700 (PDT) Received: from brn1lxmailout01.verisign.com (brn1lxmailout01.verisign.com. [72.13.63.41]) by smtp-relay.gmail.com with ESMTPS id 17sm6598458qky.3.2015.07.28.05.11.15 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 28 Jul 2015 05:11:15 -0700 (PDT) X-Relaying-Domain: verisign.com Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02 [10.173.152.206]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id t6SCBF4m024024 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 28 Jul 2015 08:11:15 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 28 Jul 2015 08:11:14 -0400 From: "Wiley, Glen" To: "dane@ietf.org" Thread-Topic: clarify, are SMIMEA and OPENPGPKEY drafts experimental? Thread-Index: AQHQyS6AIgvCSAr6TE6sQwDEmFJNIQ== Date: Tue, 28 Jul 2015 12:11:14 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [10.173.152.4] Content-Type: multipart/alternative; boundary="_000_D1DCE9A1160F8gwileyverisigncom_" MIME-Version: 1.0 Archived-At: Subject: [dane] clarify, are SMIMEA and OPENPGPKEY drafts experimental? 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, 28 Jul 2015 12:11:18 -0000 --_000_D1DCE9A1160F8gwileyverisigncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Was a decision taken to make the SMIMEA and OPENPGPKEY drafts experimental = rather than standards track? -- Glen Wiley Principal Engineer Verisign, Inc. (571) 230-7917 http://vbsdcon.com A5E5 E373 3C75 5B3E 2E24 6A0F DC65 2354 9946 C63A --_000_D1DCE9A1160F8gwileyverisigncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <6A55AC4C4AC93948A9447395FEA3EC9D@verisign.com> Content-Transfer-Encoding: quoted-printable
Was a decision taken to make the SMIMEA and OPENPGPKEY drafts experime= ntal rather than standards track?
-- 
Glen Wiley
Principal Engineer
Verisign, Inc.
(571) 230-7917


A5E5 E373 3C75 5B= 3E 2E24 &n= bsp;
6A0F DC65 2354 99= 46 C63A
--_000_D1DCE9A1160F8gwileyverisigncom_-- From nobody Tue Jul 28 11:03:18 2015 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 C88CE1B2CF1 for ; Tue, 28 Jul 2015 11:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 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_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 R1VNUqYDuRQV for ; Tue, 28 Jul 2015 11:03:13 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 032211B2CF8 for ; Tue, 28 Jul 2015 11:03:09 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id 88CDF940BC; Tue, 28 Jul 2015 11:03:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=6qZ4Ih5t4Bc+wzBztO8ITUMPkNM=; b=f0ATuJ89y6r W+1lIGSFAj7kNz6duxkkhA+tD4E3IYpehjoqVnlrRdd2d1jScqQaFCPMjLQQP/xK dI7/jCDCZxRMP8so01ivmjihkm5P2bksLIxXhRFZACEKcdg20WPI1ljOUIlHoHkf kdaynQenuaA+b4jGcxpfYDBHUuvOpOZU= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPA id 09A5394079; Tue, 28 Jul 2015 11:03:07 -0700 (PDT) Date: Tue, 28 Jul 2015 13:03:07 -0500 From: Nico Williams To: "Wiley, Glen" Message-ID: <20150728180305.GA3901@localhost> References: <87si8dagiz.fsf@vigenere.g10code.de> <20150726093802.763f57e77d2810e4f4facc14@darkdna.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "dane@ietf.org" Subject: Re: [dane] Is running a DANE nameserver for a TLD as complex as running a CA? 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, 28 Jul 2015 18:03:18 -0000 On Tue, Jul 28, 2015 at 10:52:43AM +0000, Wiley, Glen wrote: > It might help if you offered more specific points to your question. > Serving DANE style records for a TLD probably doesn=B9t make much sense= as > those records have more meaning for a SLD. Are you asking about runnin= g a > DNSSEC capable name server or serving a signed zone? That was my take. DNSSEC is a PKI, so running a signed domain is like running a CA, yes. There are differences: - There's only one trust anchor for the clients (mostly), because DNSSEC has naming constraints in place from day one. - There's no CRLs and no OCSP (but stapling of DNSSEC data is possible, though still being nailed down [har]). Revocation is easy: change the keys (and wait for TTLs to pass). This does mean that you have to think carefully about what TTLs to use. - Enrollment and key rollover still need work, but that's kinda true for PKIX CAs too... Nico --=20 From nobody Tue Jul 28 11:12:06 2015 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 068001B2D34 for ; Tue, 28 Jul 2015 11:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 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_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 egGuZZDan92y for ; Tue, 28 Jul 2015 11:11:54 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id C277B1B2D1C for ; Tue, 28 Jul 2015 11:11:37 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id 613071B4058; Tue, 28 Jul 2015 11:11:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:mime-version:content-type; s= cryptonector.com; bh=gSx0rBjMANNFXAPmvxRZ1V1q8Ts=; b=B1KZtTr3LCp 2+YQ6adyOhGpzkFNs5HtX1XNGJbHK6DXL770X9nsO356M/gANEAUoxIntWdHtfeP Y/PMV1fLbV36HVNU502uQx063ZLNjNWxXFUkBjrenruNZFKA82h3v9iOkW6BPA/n ZhOXWDeTy24tFno1/ZyR8BBc98Uc1JKo= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPA id 83DED1B4059; Tue, 28 Jul 2015 11:11:32 -0700 (PDT) Date: Tue, 28 Jul 2015 13:11:31 -0500 From: Nico Williams To: dane@ietf.org Message-ID: <20150728181130.GB3901@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: [dane] Stapling DNSSEC/DANE 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, 28 Jul 2015 18:11:58 -0000 I doubt this is the right list to send this to, but might as well start here and move this elsewhere as needed. My proposal for stapling DNSSEC/DANE is as follows: - Use a DNS response whose answer is the TLSA RRset and whose additional section contains all the DNSSEC RRsets needed to validate the answer, chaining all the way to ., of course. One can already get such responses from caching validating resolvers, so producing these is easy. Validating them requires a library, but ideally we could define a protocol to speak to caching validating resolvers for validating stapled DNSSEC, my proposal for which is: - Send the stapled DNSSEC response as a query that the caching validating resolver must then respond to with an error if it does not validate, or with an answer that contains just the answer RRset (which must match the query). Caching validating resolvers would be allowed to also ignore the answer and additional RRs in the query and instead answer the question as usual. Clients would have to check the response to make sure they got the same TLSA RRset as stapled. Obviously this would work for RRs other than TLSA. Nico -- From nobody Tue Jul 28 12:17:10 2015 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 5E8851B2DF2 for ; Tue, 28 Jul 2015 12:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ps5LIr9jVuXg for ; Tue, 28 Jul 2015 12:17:07 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E03F81B2DEE for ; Tue, 28 Jul 2015 12:17:06 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 0253C284B64; Tue, 28 Jul 2015 19:17:05 +0000 (UTC) Date: Tue, 28 Jul 2015 19:17:05 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150728191705.GX4347@mournblade.imrryr.org> References: <20150728181130.GB3901@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150728181130.GB3901@localhost> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] Stapling DNSSEC/DANE 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: Tue, 28 Jul 2015 19:17:08 -0000 On Tue, Jul 28, 2015 at 01:11:31PM -0500, Nico Williams wrote: > My proposal for stapling DNSSEC/DANE is as follows: > > - Use a DNS response whose answer is the TLSA RRset and whose > additional section contains all the DNSSEC RRsets needed to validate > the answer, chaining all the way to ., of course. Except that multiple answer RRs might need validation when there are CNAMEs from the original domain to the TLSA base domain, and possible CNAMEs from the prefixed (_port._prot) TLSA base domain to the ultimate TLSA record. All the CNAME records need to be validated, not just the final TLSA RRset. > Validating them requires a library, but ideally we could define a > protocol to speak to caching validating resolvers for validating stapled > DNSSEC, my proposal for which is: > > - Send the stapled DNSSEC response as a query that the caching > validating resolver must then respond to with an error if it does not > validate, or with an answer that contains just the answer RRset > (which must match the query). > > Caching validating resolvers would be allowed to also ignore the > answer and additional RRs in the query and instead answer the > question as usual. Clients would have to check the response to make > sure they got the same TLSA RRset as stapled. > > Obviously this would work for RRs other than TLSA. The protocol would have to return AD=1 and all the RRs from the query in the answer section. -- Viktor. From nobody Tue Jul 28 12:47:35 2015 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 49E811B2DF7 for ; Tue, 28 Jul 2015 12:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 EvEIC3AoH2C1 for ; Tue, 28 Jul 2015 12:47:32 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 555591B2EDC for ; Tue, 28 Jul 2015 12:46:43 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3A291284B64; Tue, 28 Jul 2015 19:46:42 +0000 (UTC) Date: Tue, 28 Jul 2015 19:46:42 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150728194641.GZ4347@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: [dane] [OT] Deployment news (Germany is plowing ahead) 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: Tue, 28 Jul 2015 19:47:34 -0000 I've mentioned before that much of the deployment (> 30%) for DANE SMTP is in Germany. Today something unprecedented happened. My curated list of DANE SMTP domains which had grown gradually from none to ~1600 over the last 12 months, jumped by ~150 domains in one day today. Specifically, the German domain registrar UD Media, has enabled DANE for the MX hosts serving their hosted email domains. Also the Leibniz supercomputing center has enabled DANE for many of their domains. https://en.wikipedia.org/wiki/Leibniz-Rechenzentrum This follows on the heels of the recent DNSSEC-day. http://www.internetsociety.org/deploy360/blog/2015/06/wednesday-june-30-is-dnssec-day-in-germany/ I don't know what to expect going forward, but this is certainly a big change from the previous trickle of 4-5 domains per day. I might also note that my UD Media dataset is likely a substantial under-estimate, since I only detect the domains that are listed in Alexa, or tested by the domain owner at dane.sys4.de. So it looks like we're going to have a lot more email domains with published DANE TLSA RRs. Now we just need to help them all keep the data up to date. https://tools.ietf.org/html/draft-ietf-dane-ops-14#section-8.4 https://dane.sys4.de/common_mistakes -- Viktor. From nobody Tue Jul 28 15:05:28 2015 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 EDF3F1B32AE for ; Tue, 28 Jul 2015 15:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 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_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 CvSGck2mlTxv for ; Tue, 28 Jul 2015 15:05:24 -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 CAD831B324E for ; Tue, 28 Jul 2015 15:05:24 -0700 (PDT) Received: from homiemail-a108.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTP id 867992005D906; Tue, 28 Jul 2015 15:05:24 -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=Yjj3H9pFakJy2tqllsvRT/xf4U8 =; b=DGhhN0K9oT6I/2eGp8DypM7SeDuMkefHFWQQWHTz44PoRyLap5JT9gcPRPi Wa0ln+5+r+zDbrUvxCqjZic5E8icIgVoIfoU0WhuLKb+lJCwDx7VAGdodf6dBtp/ DZti7ztpmwzC+hNcfOP75tvRMBAb5swWeswXldHKSVA8ihYg= 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 96F622005D82C; Tue, 28 Jul 2015 15:05:23 -0700 (PDT) Date: Tue, 28 Jul 2015 17:05:22 -0500 From: Nico Williams To: dane@ietf.org Message-ID: <20150728220520.GD3901@localhost> References: <20150728181130.GB3901@localhost> <20150728191705.GX4347@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150728191705.GX4347@mournblade.imrryr.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [dane] Stapling DNSSEC/DANE 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, 28 Jul 2015 22:05:26 -0000 On Tue, Jul 28, 2015 at 07:17:05PM +0000, Viktor Dukhovni wrote: > On Tue, Jul 28, 2015 at 01:11:31PM -0500, Nico Williams wrote: > > > My proposal for stapling DNSSEC/DANE is as follows: > > > > - Use a DNS response whose answer is the TLSA RRset and whose > > additional section contains all the DNSSEC RRsets needed to validate > > the answer, chaining all the way to ., of course. > > Except that multiple answer RRs might need validation when there > are CNAMEs from the original domain to the TLSA base domain, and > possible CNAMEs from the prefixed (_port._prot) TLSA base domain > to the ultimate TLSA record. > > All the CNAME records need to be validated, not just the final > TLSA RRset. Sure. The CNAMEs should be in the answer section too, no? Though it'd be OK if they were in the additional section. The point is that all of them have to be in there. An alternative would be to have multiple DNS responses, one for each CNAME and one for the TLSA RRset. The latter might be necessary if 64KB is not enough to store the entire stapling. Thoughts? > > Validating them requires a library, but ideally we could define a > > protocol to speak to caching validating resolvers for validating stapled > > DNSSEC, my proposal for which is: > > > > - Send the stapled DNSSEC response as a query that the caching > > validating resolver must then respond to with an error if it does not > > validate, or with an answer that contains just the answer RRset > > (which must match the query). > > > > Caching validating resolvers would be allowed to also ignore the > > answer and additional RRs in the query and instead answer the > > question as usual. Clients would have to check the response to make > > sure they got the same TLSA RRset as stapled. > > > > Obviously this would work for RRs other than TLSA. > > The protocol would have to return AD=1 and all the RRs from the > query in the answer section. Yes. From nobody Tue Jul 28 15:16:00 2015 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 C68AC1B32CB for ; Tue, 28 Jul 2015 15:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 j7Ize-5bi6AB for ; Tue, 28 Jul 2015 15:15:58 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 393A81B32C9 for ; Tue, 28 Jul 2015 15:15:58 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 7B28C284B64; Tue, 28 Jul 2015 22:15:57 +0000 (UTC) Date: Tue, 28 Jul 2015 22:15:57 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150728221557.GB4347@mournblade.imrryr.org> References: <20150728181130.GB3901@localhost> <20150728191705.GX4347@mournblade.imrryr.org> <20150728220520.GD3901@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150728220520.GD3901@localhost> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] Stapling DNSSEC/DANE 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: Tue, 28 Jul 2015 22:15:59 -0000 On Tue, Jul 28, 2015 at 05:05:22PM -0500, Nico Williams wrote: > > All the CNAME records need to be validated, not just the final > > TLSA RRset. > > Sure. The CNAMEs should be in the answer section too, no? Yes, in the answer section. Otherwise it is difficult for the client to navigate the response from its reference identifier domain (signalled via a mandatory SNI extension) to the actual TLSA RRset in the server's answer (which may be two layers of CNAMEs away). server-name0. -> server-name1. -> ... -> server-name-N. == tlsa-base-domain. _port._proto.tlsa-base-domain. -> ... -> _ultimate._tlsa.owner-name. _ultimate._tlsa.owner-name. IN TLSA 3 1 1 Both CNAME chains and the TLSA RRset go in the answer section, all supporting RRSIG/DNSKEY/DS records are additionals. There's a draft from Shore, Huque et. al., that is evolving, ideally to spell out all the details. > be OK if they were in the additional section. The point is that all of > them have to be in there. An alternative would be to have multiple DNS > responses, one for each CNAME and one for the TLSA RRset. The latter > might be necessary if 64KB is not enough to store the entire stapling. > Thoughts? The data will need to (and I expect will) fit into 16K so, it can go into a TLS handshake message. To that end, and in any case, the extension should I think support DNS name "compression", and should be encouraged to do use it (the draft says otherwise at present). -- Viktor. From nobody Tue Jul 28 15:42:58 2015 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 3EE421B3311 for ; Tue, 28 Jul 2015 15:42:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KnpfshJhpVvo for ; Tue, 28 Jul 2015 15:42:55 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 392551B330E for ; Tue, 28 Jul 2015 15:42:55 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 32CBE20D26 for ; Tue, 28 Jul 2015 18:42:54 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Tue, 28 Jul 2015 18:42:54 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=mad.paris; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=2fX fofv6WsGD859Ms7f8w51Lnaw=; b=foU4I0XVNxhwkra/Z7ssxJyeDbwEfR0Bv0K OuOTxMBqnTRajdV+0u2iMcCMsNsbALh0V5kfA0WdhxNpuxjvkYE50/QHgHKdZv0q sgqusjzEcCrW4/wKm59K7oyawT9B8x3y7XjgbKwrPO3IkjyQkwE+Uke7ABz6OHaq upj+ynLE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=2fXfofv6WsGD859Ms7f8w51Lnaw=; b=uGvl5 wAo8YjsUdflm5NL9vC6Dq/x/kvJ2cl5SQJX91tZm7zmNSagUz5iUJaKOrwYt40Gi NK35pfsMiw1uJzqjCJbiBq6PH37XZj7a/d7PKqiPh4oD8zGCs9fVes3YbU0P6XxH G8E/LBV0qoSYe+pPFINxRwPZdyKNDOnFnMtEfw= X-Sasl-enc: odCTg7onuWYUuw2iU+ApqLv2wJn6iemW+HMcdR+xO+x5 1438123373 Received: from [192.168.1.43] (78.215.207.77.rev.sfr.net [77.207.215.78]) by mail.messagingengine.com (Postfix) with ESMTPA id CBF166800DD for ; Tue, 28 Jul 2015 18:42:53 -0400 (EDT) From: Ian Maddison Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Wed, 29 Jul 2015 00:42:52 +0200 To: dane@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) X-Mailer: Apple Mail (2.2102) Archived-At: Subject: [dane] DANE client+server authentication 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, 28 Jul 2015 22:42:57 -0000 I=E2=80=99m looking for a way to run a recursive name server on a public = IP address restricted to pre-configured roaming clients. Is, or will it be feasible to leverage DANE-TA to reliably authenticate = both the clients and server in order to run this type of service ? =E2=80=94 Ian Maddison= From nobody Tue Jul 28 16:45:18 2015 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 431551B3466 for ; Tue, 28 Jul 2015 16:45:17 -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 cY18IZG-B7aN for ; Tue, 28 Jul 2015 16:45:15 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC5931A8029 for ; Tue, 28 Jul 2015 16:45:14 -0700 (PDT) Received: by qkdg63 with SMTP id g63so4755075qkd.0 for ; Tue, 28 Jul 2015 16:45:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=wcH3a4XO69OBl3BJn9c9boL/WU5DJ1sMJ9G9TSteK/Q=; b=tjRnLFNF2sZTbim5pSddGVI7QWEh7ow/nLOz0/b1mniAT46MQjlMEtMu0PrW1ReCwG fuj85M1k+xR/F9sVTPWBoweNXqNBC5wQXUyUSTYyQP5xsDesKbnPvslwK8DWmePnIQMi Ref2uDKmVHxRsVcmyCYCaE3UBEqWuWBxa8lWZpzQpOE4u3wHRdu7kp9DH4TLRynY8ExD iCP+mP01d/HCEL/60gVOhqEUMUEP8McqkErVtGc4Omeo2Ms30yGKvk6MWtiQo8zUMtqS 2kXA5YmtjOEJEd5DmdnY/KdAbcBktYkHX5e/S15ZOh1zvx7bvd+qLaM5g0bcT7GFE+oO 4JZg== MIME-Version: 1.0 X-Received: by 10.55.31.40 with SMTP id f40mr54574546qkf.18.1438127114082; Tue, 28 Jul 2015 16:45:14 -0700 (PDT) Received: by 10.140.80.208 with HTTP; Tue, 28 Jul 2015 16:45:14 -0700 (PDT) In-Reply-To: <20150728221557.GB4347@mournblade.imrryr.org> References: <20150728181130.GB3901@localhost> <20150728191705.GX4347@mournblade.imrryr.org> <20150728220520.GD3901@localhost> <20150728221557.GB4347@mournblade.imrryr.org> Date: Tue, 28 Jul 2015 19:45:14 -0400 Message-ID: From: Shumon Huque To: "" Content-Type: multipart/alternative; boundary=001a114780b8c6ddaf051bf80fbe Archived-At: Subject: Re: [dane] Stapling DNSSEC/DANE 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, 28 Jul 2015 23:45:17 -0000 --001a114780b8c6ddaf051bf80fbe Content-Type: text/plain; charset=UTF-8 On Tue, Jul 28, 2015 at 6:15 PM, Viktor Dukhovni wrote: > On Tue, Jul 28, 2015 at 05:05:22PM -0500, Nico Williams wrote: > > > > All the CNAME records need to be validated, not just the final > > > TLSA RRset. > > > > Sure. The CNAMEs should be in the answer section too, no? > > Yes, in the answer section. Otherwise it is difficult for the > client to navigate the response from its reference identifier domain > (signalled via a mandatory SNI extension) to the actual TLSA RRset > in the server's answer (which may be two layers of CNAMEs away). > > server-name0. -> server-name1. -> ... -> server-name-N. == > tlsa-base-domain. > _port._proto.tlsa-base-domain. -> ... -> > _ultimate._tlsa.owner-name. > _ultimate._tlsa.owner-name. IN TLSA 3 1 1 > > Both CNAME chains and the TLSA RRset go in the answer section, all > supporting RRSIG/DNSKEY/DS records are additionals. There's a > draft from Shore, Huque et. al., that is evolving, ideally to spell > out all the detail. > In case others missed it, it's the following draft: https://tools.ietf.org/html/draft-shore-tls-dnssec-chain-extension-01 Debate is going on about the precise format of the chain data. The draft currently doesn't use DNS "messages", but rather wire format DNS RRs wrapped in a bit of TLS presentation syntax, but we're discussing other possibilities. If we were to use DNS messages, there is already a proposal from Paul Wouters which we might also look into: https://tools.ietf.org/html/draft-ietf-dnsop-edns-chain-query-02 I've already stated my personal preference for a chain of wire format DNS RRs that could be fed into existing DNS library functions, but I'd like to come to a consensus that is acceptable to most of the likely implementers. One concern we've heard is that some folks don't want to import a large DNS library into their application that has a whole of bunch of unnecessary code (e.g. all the DNS transport code). > > be OK if they were in the additional section. The point is that all of > > them have to be in there. An alternative would be to have multiple DNS > > responses, one for each CNAME and one for the TLSA RRset. The latter > > might be necessary if 64KB is not enough to store the entire stapling. > > Thoughts? > > The data will need to (and I expect will) fit into 16K so, it can > go into a TLS handshake message. To that end, and in any case, > the extension should I think support DNS name "compression", and > should be encouraged to do use it (the draft says otherwise at > present). > > Right, it says to uncompress the names right now. Name compression is defined in terms of pointers to offsets from the beginning of the DNS message. Since we don't currently use DNS messages, we'd have to redefine name compression to be something else, like an offset from the beginning of the chain data structure. That would probably be fine, but I wonder if it's really worth it. The size of the chain is likely going to be dominated not by domain names, but by all the DNSSEC signatures, which aren't very compressible. Another method of reducing the chain size we are considering is client side caching of RR sets and server side omission of the same. Shumon. --001a114780b8c6ddaf051bf80fbe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jul 28, 2015 at 6:15 PM, Viktor Dukhovni <ietf-dane@dukhovni.org= > wrote:
O= n Tue, Jul 28, 2015 at 05:05:22PM -0500, Nico Williams wrote:

> > All the CNAME records need to be validated, not just the final > > TLSA RRset.
>
> Sure.=C2=A0 The CNAMEs should be in the answer section too, no?

Yes, in the answer section.=C2=A0 Otherwise it is difficult for the<= br> client to navigate the response from its reference identifier domain
(signalled via a mandatory SNI extension) to the actual TLSA RRset
in the server's answer (which may be two layers of CNAMEs away).

=C2=A0 =C2=A0 =C2=A0 =C2=A0 server-name0. -> server-name1. -> ... -&g= t; server-name-N. =3D=3D tlsa-base-domain.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 _port._proto.tlsa-base-domain. -> ... -> = _ultimate._tlsa.owner-name.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 _ultimate._tlsa.owner-name. IN TLSA 3 1 1 <b= lob>

Both CNAME chains and the TLSA RRset go in the answer section, all
supporting RRSIG/DNSKEY/DS records are additionals.=C2=A0 There's a
draft from Shore, Huque et. al., that is evolving, ideally to spell
out all the detail.

In case others miss= ed it, it's the following draft:


Debate is going on about the precise format= of the chain data. The draft currently doesn't use DNS "messages&= quot;, but rather wire format DNS RRs wrapped in a bit of TLS presentation = syntax, but we're discussing other possibilities. If we were to use DNS= messages, there is already a proposal from Paul Wouters which we might als= o look into:


I&#= 39;ve already stated my personal preference for a chain of wire format DNS = RRs that could be fed into existing DNS library functions, but I'd like= to come to a consensus that is acceptable to most of the likely implemente= rs. One concern we've heard is that some folks don't want to import= a large DNS library into their application that has a whole of bunch of un= necessary code (e.g. all the DNS transport code).
=C2=A0
> be OK if they were in the additional section.=C2=A0 The point is that = all of
> them have to be in there.=C2=A0 An alternative would be to have multip= le DNS
> responses, one for each CNAME and one for the TLSA RRset.=C2=A0 The la= tter
> might be necessary if 64KB is not enough to store the entire stapling.=
> Thoughts?

The data will need to (and I expect will) fit into 16K so, it can go into a TLS handshake message.=C2=A0 To that end, and in any case,
the extension should I think support DNS name "compression", and<= br> should be encouraged to do use it (the draft says otherwise at
present).


Right, it says to uncompress the names right now= . Name compression is defined in terms of pointers to offsets from the begi= nning of the DNS message. Since we don't currently use DNS messages, we= 'd have to redefine name compression to be something else, like an offs= et from the beginning of the chain data structure. That would probably be f= ine, but I wonder if it's really worth it. The size of the chain is lik= ely going to be dominated not by domain names, but by all the DNSSEC signat= ures, which aren't very compressible.

Another = method of reducing the chain size we are considering is client side caching= of RR sets and server side omission of the same.

= Shumon.

--001a114780b8c6ddaf051bf80fbe-- From nobody Tue Jul 28 16:46:50 2015 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 77EDB1A035F for ; Tue, 28 Jul 2015 16:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_66=0.6, 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 eKkWPAJdX2lb for ; Tue, 28 Jul 2015 16:46:47 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD0831A0282 for ; Tue, 28 Jul 2015 16:46:47 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 03B9D284B64; Tue, 28 Jul 2015 23:46:46 +0000 (UTC) Date: Tue, 28 Jul 2015 23:46:46 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150728234646.GC4347@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: Subject: Re: [dane] DANE client+server authentication 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: Tue, 28 Jul 2015 23:46:49 -0000 On Wed, Jul 29, 2015 at 12:42:52AM +0200, Ian Maddison wrote: > I'm looking for a way to run a recursive name server on a public IP address > restricted to pre-configured roaming clients. > > Is, or will it be feasible to leverage DANE-TA to reliably authenticate > both the clients and server in order to run this type of service? No, not possible. And I am afraid this is not an end-user help/support forum, so this type of question belongs elsewhere, e.g. the BIND or unbound users list, or similar. -- Viktor. From nobody Tue Jul 28 16:54:27 2015 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 2CF4E1B3412 for ; Tue, 28 Jul 2015 16:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 AXCSlDvK--_G for ; Tue, 28 Jul 2015 16:54:17 -0700 (PDT) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4501B1A0372 for ; Tue, 28 Jul 2015 16:54:17 -0700 (PDT) Received: by pdbnt7 with SMTP id nt7so78461574pdb.0 for ; Tue, 28 Jul 2015 16:54:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=5DI+G4TLaNVsrUgvh9A3CwUaDKv3Mxht2aI7SUfyAog=; b=EiEg4J0D9WwFoJ1h2BVw5AwTkBZE2SmrBDfIsPgF/AU5g+26ORs25/JCX332tGv1Ep VoAiqV6kCwyCpNBn+FTTk//OpLscfyOoIV8+ixTSTCfYY43LYCWLjaosyqxbihfflQWw F0I9H5tJ63iPMlgJleB3WWD3AYgghjqDwBU3iAbjxhUQ7+1shzBJuCK25jId4lLgcUlR oyMyu3JmFglTKB6AXIdSBhoG7LaaLYgV1YCoWDbV+4rOGpteOc/gdEQS5iYd9Q+h56e2 5R3szBTW1W062mP/4T/jh2bDng3k0QPGuse5FrqLr8oxNrYwsHGDPARKrITPCZkxF1lO kLhQ== X-Received: by 10.70.135.67 with SMTP id pq3mr86690457pdb.8.1438127656922; Tue, 28 Jul 2015 16:54:16 -0700 (PDT) Received: from spandex.local (216-67-70-212-radius.dynamic.acsalaska.net. [216.67.70.212]) by smtp.gmail.com with ESMTPSA id b10sm37141426pdo.84.2015.07.28.16.54.15 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Jul 2015 16:54:15 -0700 (PDT) Message-ID: <55B81625.5010309@gmail.com> Date: Tue, 28 Jul 2015 15:54:13 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dane@ietf.org References: <20150728181130.GB3901@localhost> <20150728191705.GX4347@mournblade.imrryr.org> <20150728220520.GD3901@localhost> <20150728221557.GB4347@mournblade.imrryr.org> In-Reply-To: <20150728221557.GB4347@mournblade.imrryr.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dane] Stapling DNSSEC/DANE 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, 28 Jul 2015 23:54:21 -0000 On 7/28/15 2:15 PM, Viktor Dukhovni wrote: > The data will need to (and I expect will) fit into 16K so, it can > go into a TLS handshake message. To that end, and in any case, > the extension should I think support DNS name "compression", and > should be encouraged to do use it (the draft says otherwise at > present). Adam's original proposal included a name compression mechanism (Adam Langley wrote the initial draft a few years ago, and we've picked it up with his blessing). We decided to drop it because it adds some complexity (and the possibility of error) with questionable benefit, given that signatures are going to be the bigger consumer of space in the extension. Melinda From nobody Tue Jul 28 16:57:08 2015 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 A1E9A1A035F for ; Tue, 28 Jul 2015 16:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 cfA0DF9vheoI for ; Tue, 28 Jul 2015 16:57:05 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A17B1A0060 for ; Tue, 28 Jul 2015 16:57:05 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 7B3D3284B64; Tue, 28 Jul 2015 23:57:04 +0000 (UTC) Date: Tue, 28 Jul 2015 23:57:04 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150728235704.GD4347@mournblade.imrryr.org> References: <20150728181130.GB3901@localhost> <20150728191705.GX4347@mournblade.imrryr.org> <20150728220520.GD3901@localhost> <20150728221557.GB4347@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: Subject: Re: [dane] Stapling DNSSEC/DANE 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: Tue, 28 Jul 2015 23:57:06 -0000 On Tue, Jul 28, 2015 at 07:45:14PM -0400, Shumon Huque wrote: > > The data will need to (and I expect will) fit into 16K so, it can > > go into a TLS handshake message. To that end, and in any case, > > the extension should I think support DNS name "compression", and > > should be encouraged to do use it (the draft says otherwise at > > present). > > Right, it says to uncompress the names right now. Name compression is > defined in terms of pointers to offsets from the beginning of the DNS > message. Since we don't currently use DNS messages, we'd have to redefine > name compression to be something else, like an offset from the beginning of > the chain data structure. That would probably be fine, but I wonder if it's > really worth it. The size of the chain is likely going to be dominated not > by domain names, but by all the DNSSEC signatures, which aren't very > compressible. Well, certainly the signature and DNSKEY fields don't compress very well, but there are still lots of domain names floating around. With ECC signature algorithms (which I hope will eventually be the dominant algorithms in DNSSEC), the key and signature fields are much smaller, making it possible for name compression to make a non-trivial difference. Also if the response is in DNS wire format, it becomes easier to just punt the packet for verification to the local validating resolver (jailed inside a captive portal and fed crumbs of useful work to do by applications forwarding data from remote TLS servers). With care the server's response might already be in the form of the appropriate query (or possibly new DNS opcode), so that the client can just copy it to 127.0.0.1:53 after a quick syntax check, and wait for a response. That would be a much simpler approach than compiling DNS logic into each and every application. -- Viktor. From nobody Tue Jul 28 16:58:02 2015 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 83C971A037B for ; Tue, 28 Jul 2015 16:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 gVkqNaneowZK for ; Tue, 28 Jul 2015 16:57:59 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 717321A0060 for ; Tue, 28 Jul 2015 16:57:59 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D6337284B64; Tue, 28 Jul 2015 23:57:52 +0000 (UTC) Date: Tue, 28 Jul 2015 23:57:52 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150728235752.GE4347@mournblade.imrryr.org> References: <20150728181130.GB3901@localhost> <20150728191705.GX4347@mournblade.imrryr.org> <20150728220520.GD3901@localhost> <20150728221557.GB4347@mournblade.imrryr.org> <55B81625.5010309@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55B81625.5010309@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] Stapling DNSSEC/DANE 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: Tue, 28 Jul 2015 23:58:00 -0000 On Tue, Jul 28, 2015 at 03:54:13PM -0800, Melinda Shore wrote: > On 7/28/15 2:15 PM, Viktor Dukhovni wrote: > > The data will need to (and I expect will) fit into 16K so, it can > > go into a TLS handshake message. To that end, and in any case, > > the extension should I think support DNS name "compression", and > > should be encouraged to do use it (the draft says otherwise at > > present). > > Adam's original proposal included a name compression mechanism > (Adam Langley wrote the initial draft a few years ago, and we've > picked it up with his blessing). We decided to drop it because > it adds some complexity (and the possibility of error) with > questionable benefit, given that signatures are going to be the > bigger consumer of space in the extension. See my follow-up message. I think you should reconsider. -- Viktor. From nobody Tue Jul 28 16:59:21 2015 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 94ECC1A0382 for ; Tue, 28 Jul 2015 16:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 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_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 s9bJBM4lafsC for ; Tue, 28 Jul 2015 16:59:18 -0700 (PDT) Received: from homiemail-a111.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id E03751A037B for ; Tue, 28 Jul 2015 16:59:18 -0700 (PDT) Received: from homiemail-a111.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTP id 8115F2005E619; Tue, 28 Jul 2015 16:59:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=uQ4r/cnncdVzC6 83u3Or9Bi4g5s=; b=hsSzTmQTy7y7Y4w+kqbLjoBOVCHiE2vdoTdg7igS7SrxHo L9PJE3NoZtGopJLQDOLHGsPkduYWW63gbnwWziKVzaGt8nHN1sTrLaz6gpUp4SiI MeIzRujqmf6d8e5fP59H712TX8y2sROhv1TqZCgOHOuoKLz62WGvnZEBcVhIY= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTPA id 158EA2005E605; Tue, 28 Jul 2015 16:59:17 -0700 (PDT) Date: Tue, 28 Jul 2015 18:59:17 -0500 From: Nico Williams To: Shumon Huque Message-ID: <20150728235916.GE3901@localhost> References: <20150728181130.GB3901@localhost> <20150728191705.GX4347@mournblade.imrryr.org> <20150728220520.GD3901@localhost> <20150728221557.GB4347@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.21 (2010-09-15) Archived-At: Cc: "" Subject: Re: [dane] Stapling DNSSEC/DANE 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, 28 Jul 2015 23:59:20 -0000 On Tue, Jul 28, 2015 at 07:45:14PM -0400, Shumon Huque wrote: > In case others missed it, it's the following draft: > > https://tools.ietf.org/html/draft-shore-tls-dnssec-chain-extension-01 I had, yes. Thanks for the pointer. > Debate is going on about the precise format of the chain data. The draft > currently doesn't use DNS "messages", but rather wire format DNS RRs > wrapped in a bit of TLS presentation syntax, but we're discussing other > possibilities. If we were to use DNS messages, there is already a proposal > from Paul Wouters which we might also look into: I much prefer using DNS messages, yes. > https://tools.ietf.org/html/draft-ietf-dnsop-edns-chain-query-02 > > I've already stated my personal preference for a chain of wire format DNS > RRs that could be fed into existing DNS library functions, but I'd like to > come to a consensus that is acceptable to most of the likely implementers. A wire-format response could be fed to a library too. And to a validating resolver. The point is that the protocol to the local caching validating resolver *is* the API. That's because light-weight non-validating resolver libraries to speak to it are universally available. And because the local caching validating resolver is the best place to cache. (A caching validating resolver might find a lot of the signatures and validations thereof cached. The caching validating resolver may not want to cache stapled DNSSEC even if it's valid to avoid cache poisoning issues, but it could still pay to cache the validations.) Resolver libraries are nice, but mostly only for when one cannot ensure that there is a local caching validating resolver, or when one cannot trust it, or when one is building a local caching validator. > One concern we've heard is that some folks don't want to import a large DNS > library into their application that has a whole of bunch of unnecessary > code (e.g. all the DNS transport code). Exactly. See above. > > The data will need to (and I expect will) fit into 16K so, it can > > go into a TLS handshake message. To that end, and in any case, > > the extension should I think support DNS name "compression", and > > should be encouraged to do use it (the draft says otherwise at > > present). > > Right, it says to uncompress the names right now. Name compression is > defined in terms of pointers to offsets from the beginning of the DNS > message. Since we don't currently use DNS messages, we'd have to redefine > name compression to be something else, like an offset from the beginning of > the chain data structure. That would probably be fine, but I wonder if it's > really worth it. The size of the chain is likely going to be dominated not > by domain names, but by all the DNSSEC signatures, which aren't very > compressible. And the public keys. > Another method of reducing the chain size we are considering is client side > caching of RR sets and server side omission of the same. Sure, you can omit keys and signatures nearer to the root. Nico -- From nobody Tue Jul 28 17:03:37 2015 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 CB6E81A00E4 for ; Tue, 28 Jul 2015 17:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 OINPTWGRRG92 for ; Tue, 28 Jul 2015 17:03:35 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3C411A00EA for ; Tue, 28 Jul 2015 17:03:15 -0700 (PDT) Received: by padck2 with SMTP id ck2so77429459pad.0 for ; Tue, 28 Jul 2015 17:03:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=EpKCs3ZNEat5D+nv8ihzm7KTA4EmJhETiU6DmFn75SU=; b=JjYIsWXFKPZqq2UzEYZF4HX5PeWVyQVRCkETl5lXDa/W218mlXNTE0sMJqKMnjb0GD 8PDWKYSbKTO2Ss+UhyJhMf9c7rbodtw9IWFwtaG9uAWPcP6UMMRBMC+jl+H17LUSXiA1 PIA0Ie2+ugf+zn5YvXlKS00U3E4OJaXP9PXMBEZVGh+oCLp5z3Kzwr6W7tDLx8XtFQj7 Shca2tNEYzATLC81iS7dEP97GUOMWsXXlS6OM2wsPvbELyNIM4yl/OU1xBbaq84ikdI0 P8UmaRNmOCtJqHsM8TAK9GQLWnXGTzsAThog1rqrZkZe4IFFzvW4OpzTA3NmFRMlkxap hMdw== X-Received: by 10.66.138.40 with SMTP id qn8mr86839315pab.19.1438128194324; Tue, 28 Jul 2015 17:03:14 -0700 (PDT) Received: from spandex.local (216-67-70-212-radius.dynamic.acsalaska.net. [216.67.70.212]) by smtp.gmail.com with ESMTPSA id si3sm37347246pac.5.2015.07.28.17.03.13 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Jul 2015 17:03:13 -0700 (PDT) Message-ID: <55B81840.1030602@gmail.com> Date: Tue, 28 Jul 2015 16:03:12 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dane@ietf.org References: <20150728181130.GB3901@localhost> <20150728191705.GX4347@mournblade.imrryr.org> <20150728220520.GD3901@localhost> <20150728221557.GB4347@mournblade.imrryr.org> <55B81625.5010309@gmail.com> <20150728235752.GE4347@mournblade.imrryr.org> In-Reply-To: <20150728235752.GE4347@mournblade.imrryr.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dane] Stapling DNSSEC/DANE 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 Jul 2015 00:03:37 -0000 On 7/28/15 3:57 PM, Viktor Dukhovni wrote: > See my follow-up message. I think you should reconsider. Nothing's cast in concrete, and your point about ECC signatures is well-taken. We'll likely get a revision out by the end of August. Because this is a TLS extension we'll be working with the TLS working group, and it's not clear at this point what sort of biases they'll have that are different from the preferences of DNS experts. Melinda From nobody Tue Jul 28 17:03:46 2015 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 390841A00AE for ; Tue, 28 Jul 2015 17:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 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_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 zuzefEglmZqB for ; Tue, 28 Jul 2015 17:03:44 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 71E751A00B6 for ; Tue, 28 Jul 2015 17:03:31 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id 380D42F407A; Tue, 28 Jul 2015 17:03:31 -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=Ii3pAlQwviZO2gySMXuap4JNodc =; b=KQCGfjgqsY0Dhq5SBqXko3h/IU45gM86zPdy+PZsU9ypuX2MzDfm/1OGdnf z5o7OeEVjS6xM89Wbvgz3TYbfCRFt8LX+nxCCgo0+v7FPMDchIRVzsqPszaUP8eu ECdXiLvhf1X4mo53zkyhsjSNb1S1fu66EM+XTMVbnNhqotec= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPA id DE86D2F4065; Tue, 28 Jul 2015 17:03:30 -0700 (PDT) Date: Tue, 28 Jul 2015 19:03:30 -0500 From: Nico Williams To: dane@ietf.org Message-ID: <20150729000329.GF3901@localhost> References: <20150728181130.GB3901@localhost> <20150728191705.GX4347@mournblade.imrryr.org> <20150728220520.GD3901@localhost> <20150728221557.GB4347@mournblade.imrryr.org> <20150728235704.GD4347@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150728235704.GD4347@mournblade.imrryr.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [dane] Stapling DNSSEC/DANE 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 Jul 2015 00:03:45 -0000 On Tue, Jul 28, 2015 at 11:57:04PM +0000, Viktor Dukhovni wrote: > With care the server's response might already be in the form of > the appropriate query (or possibly new DNS opcode), so that the > client can just copy it to 127.0.0.1:53 after a quick syntax check, > and wait for a response. That would be a much simpler approach > than compiling DNS logic into each and every application. Well, relying party would have to check that the header is right (or replace it), but yes, this, exactly this. Nico -- From nobody Tue Jul 28 17:24:50 2015 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 8B1171A01A9 for ; Tue, 28 Jul 2015 17:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 fXAq-_Rjb2-j for ; Tue, 28 Jul 2015 17:24:47 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A0D41A019B for ; Tue, 28 Jul 2015 17:24:47 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id BDECB284B64; Wed, 29 Jul 2015 00:24:45 +0000 (UTC) Date: Wed, 29 Jul 2015 00:24:45 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150729002445.GF4347@mournblade.imrryr.org> References: <20150728181130.GB3901@localhost> <20150728191705.GX4347@mournblade.imrryr.org> <20150728220520.GD3901@localhost> <20150728221557.GB4347@mournblade.imrryr.org> <20150728235916.GE3901@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150728235916.GE3901@localhost> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] Stapling DNSSEC/DANE 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: Wed, 29 Jul 2015 00:24:48 -0000 On Tue, Jul 28, 2015 at 06:59:17PM -0500, Nico Williams wrote: > > Another method of reducing the chain size we are considering is client side > > caching of RR sets and server side omission of the same. > > Sure, you can omit keys and signatures nearer to the root. Only if a client with a slightly warm cache, can tell the server a list of ancestor domains (of the server domain) for which it already posesses in its cache already validated DS/DNSKEY records. But this carries some risk, as a .com server A can insert into a client's cache valid, but somewhat stale keys for .com, which can't validate the response from .com server B (signed with more fresh keys). In all likelihood, such optimization is too difficult to get right, and should be avoided. The only optimization is when a client already has recent TLSA records for the server, and just avoids asking for the extension entirely. That gets most of the benefit, with least complexity. -- Viktor. From nobody Tue Jul 28 17:36:02 2015 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 4D8EB1A03AA for ; Tue, 28 Jul 2015 17:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 xkjJTqJOPaIK for ; Tue, 28 Jul 2015 17:35:59 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E030F1A01A9 for ; Tue, 28 Jul 2015 17:35:58 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 23DEA284B64; Wed, 29 Jul 2015 00:35:58 +0000 (UTC) Date: Wed, 29 Jul 2015 00:35:58 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150729003557.GG4347@mournblade.imrryr.org> References: <20150728181130.GB3901@localhost> <20150728191705.GX4347@mournblade.imrryr.org> <20150728220520.GD3901@localhost> <20150728221557.GB4347@mournblade.imrryr.org> <55B81625.5010309@gmail.com> <20150728235752.GE4347@mournblade.imrryr.org> <55B81840.1030602@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55B81840.1030602@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] Stapling DNSSEC/DANE 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: Wed, 29 Jul 2015 00:36:00 -0000 On Tue, Jul 28, 2015 at 04:03:12PM -0800, Melinda Shore wrote: > On 7/28/15 3:57 PM, Viktor Dukhovni wrote: > > See my follow-up message. I think you should reconsider. > > Nothing's cast in concrete, and your point about ECC signatures > is well-taken. We'll likely get a revision out by the end of > August. Because this is a TLS extension we'll be working with > the TLS working group, and it's not clear at this point what > sort of biases they'll have that are different from the > preferences of DNS experts. I think that the payload of the extension really needs to be vetted by folks with DNS expertise, and the TLS WG review mostly focused on where the extension goes in the handshake, whether its payload is in the clear or not, whether (as I think should be the case) SNI is a pre-requsite to signal which domain the server starts the validation chain from, ... This is based in part on the architectural assumption that in many cases the right way to process it on the client side will be a hand-off a local DNS service. I would also posit that also on the server, obtaining the requisite payload might be obtained by constructing appropriate new requests to the local DNS service (which likely has all the relevant data in its cache). The design of the payload should not preclude delegation of the work of building it to a DNS service on either end. Of course if either initially (for lack of supporting DNS services) or through explicit design choice, some implementations prefer to do everything in an application library, so be it, they can then construct the appropriate DNS-compatible payload messages. Libraries to do so are likely not too hard to find. -- Viktor. From nobody Tue Jul 28 17:37:13 2015 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 EAFB01A0AF7 for ; Tue, 28 Jul 2015 17:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PuKkby2csf3n for ; Tue, 28 Jul 2015 17:37:10 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51D861A0470 for ; Tue, 28 Jul 2015 17:37:10 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id AEB8621A5C for ; Tue, 28 Jul 2015 20:37:09 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Tue, 28 Jul 2015 20:37:09 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=mad.paris; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=tePJswNTw0Lelzvd6jumJEP2ris=; b=REHOaD tCQ0XTY0H344J04WirldQzIB42a3j9Feir460yk0+C4jYqZGP/jlXHXDqqgXD+ry qr23gzUAycUAdR3GPQ1xt2nWqGb+7qh3ZVOu9hp/4OOXEbKoUZdTilqVwycSP5vN Hornz83tyLNDhaxEjeuer2V70dt+pT9sVwuMY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=tePJswNTw0Lelzv d6jumJEP2ris=; b=XLoOVyH3KqJ6urQQseKPxGTB8yqYyxlrCllUpC2tZmUAs70 F8PQsMBlIBhfXYJ5nhYgBdP9EDY22Q1+5SNlbuzO60vvumvZ9Kezfy3tCphhUg7i m0WVMFQRKwhfUwmcie/nECPixBT0LcO1xr/Qu+d96QAy3big4reCmoJIlwfc= X-Sasl-enc: eOVIXIPsP8xf8VoZFtXCk+7x2NQkYGirZPMhXlICOzIl 1438130229 Received: from [192.168.1.43] (78.215.207.77.rev.sfr.net [77.207.215.78]) by mail.messagingengine.com (Postfix) with ESMTPA id 5B012680130 for ; Tue, 28 Jul 2015 20:37:09 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ian Maddison In-Reply-To: <20150728234646.GC4347@mournblade.imrryr.org> Date: Wed, 29 Jul 2015 02:37:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150728234646.GC4347@mournblade.imrryr.org> To: dane@ietf.org X-Mailer: Apple Mail (2.2102) Archived-At: Subject: Re: [dane] DANE client+server authentication 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 Jul 2015 00:37:12 -0000 > On 29 Jul 2015, at 01:46, Viktor Dukhovni = wrote: >=20 > On Wed, Jul 29, 2015 at 12:42:52AM +0200, Ian Maddison wrote: >=20 >> I'm looking for a way to run a recursive name server on a public IP = address >> restricted to pre-configured roaming clients. >>=20 >> Is, or will it be feasible to leverage DANE-TA to reliably = authenticate >> both the clients and server in order to run this type of service? >=20 > No, not possible. >=20 > And I am afraid this is not an end-user help/support forum, so this > type of question belongs elsewhere, e.g. the BIND or unbound users > list, or similar. >=20 > --=20 > Viktor. Oh ok, I'm sorry about that.=20 Although I=E2=80=99ve followed this list for several years, improved = readability for one of your drafts and helped fix an an error or two, it = seems I may have missed details regarding client authentication and = would appreciate a pointer, if that=E2=80=99s not too much to ask :) From nobody Tue Jul 28 18:22:01 2015 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 AF86E1A1A98 for ; Tue, 28 Jul 2015 18:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 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_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 YtpegzqVJkVm for ; Tue, 28 Jul 2015 18:21:59 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 1937E1A1A8D for ; Tue, 28 Jul 2015 18:21:59 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id B3EE02C806E; Tue, 28 Jul 2015 18:21:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=R3BKp7XZ58JRaB xtPrz5ZrfY2iE=; b=ZIcZJA+lMIHAHY+12/4Otqn9xu+P2KyroXTlinfPNt1Kau R7Sfacuk0ahKexCMZxB1eEonnHR/nVTJ3isEUN6DH00O4nKsjBql0812T8MIY6Oa v1C65UwxbW1E85j1KQ4MTOlePPgYI2/vxBo0gMLBEJ9oro6ChHr9mjLuTV3g0= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTPA id 4DBB82C806C; Tue, 28 Jul 2015 18:21:58 -0700 (PDT) Date: Tue, 28 Jul 2015 20:21:57 -0500 From: Nico Williams To: Melinda Shore Message-ID: <20150729012156.GG3901@localhost> References: <20150728181130.GB3901@localhost> <20150728191705.GX4347@mournblade.imrryr.org> <20150728220520.GD3901@localhost> <20150728221557.GB4347@mournblade.imrryr.org> <55B81625.5010309@gmail.com> <20150728235752.GE4347@mournblade.imrryr.org> <55B81840.1030602@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55B81840.1030602@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Stapling DNSSEC/DANE 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 Jul 2015 01:22:00 -0000 On Tue, Jul 28, 2015 at 04:03:12PM -0800, Melinda Shore wrote: > On 7/28/15 3:57 PM, Viktor Dukhovni wrote: > > See my follow-up message. I think you should reconsider. > > Nothing's cast in concrete, and your point about ECC signatures > is well-taken. We'll likely get a revision out by the end of > August. Because this is a TLS extension we'll be working with > the TLS working group, and it's not clear at this point what > sort of biases they'll have that are different from the > preferences of DNS experts. Why should their biases be all that different from ours? A TLS implementor could want to implement a DNS resolver from scratch, but since they'll need to deal with DNS the protocol, why should stapling DNSSEC as a DNS response be difficult for them? Or a TLS implementor could want to use an off-the-shelf DNS implementation, in which case it wouldn't be hard to use a DNS response as the container for the stapled RRs. In the best case the TLS implementaor can just feed the response as-is (see previous posts), whereas with any other encoding there's no such best-case. Existing code would make a difference. I'm aware of AGL's stapled DNSSEC code, but that's one implementation -- it'd have to be a widely-used implementation to make that big a difference. More than that, I object to each protocol coming up with its own stapling format. Whatever is good for protocol X, ought to be good for protocol Y. A proliferation of DNSSEC stapling containers would only serve to make implementors sad. Nico -- From nobody Tue Jul 28 18:26:21 2015 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 DBCC31A1A8B for ; Tue, 28 Jul 2015 18:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 4pQE6b-ttlwW for ; Tue, 28 Jul 2015 18:26:19 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D2FB1A00FD for ; Tue, 28 Jul 2015 18:26:19 -0700 (PDT) Received: by pacan13 with SMTP id an13so79933131pac.1 for ; Tue, 28 Jul 2015 18:26:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=vYmNwp05TNSuuznMO6pbvjL73fJ7teOrwy84oDXfaB4=; b=zIiatpWfnDcfa3/OuDHGEkhg+zZQwVbptAQ9BO4gKztEFxKFYI1IZDHZMvw8W6VOQK eYmNmihVFGLuUXd2mGJR4hWg/qXVTPO1sCQBpRUJtkkEfEB8c5w5MF0/LD5n9u7uopMg XOovRcrq5Y+IIvk8xdN2zViL246MOAhcOj47rzy0UNonp9O0UeGOV/MNao0ffuXxLbJC uovQoZMs5tQLu/hvxfegsBfngtjFpKIoxbwcWJReEzSCSOmLDFbmdcMt1r39m2TRIAiy u5jiEH7tLdZq79yyg+q3RIO3YKQWO8dqDcQZLDlc1Jk0IcnWpLTIQq2uynrAcRWLn/xn QYew== X-Received: by 10.66.100.162 with SMTP id ez2mr87866841pab.10.1438133179293; Tue, 28 Jul 2015 18:26:19 -0700 (PDT) Received: from spandex.local (216-67-70-212-radius.dynamic.acsalaska.net. [216.67.70.212]) by smtp.gmail.com with ESMTPSA id bf5sm37628637pad.43.2015.07.28.18.26.17 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Jul 2015 18:26:18 -0700 (PDT) Message-ID: <55B82BB8.1060008@gmail.com> Date: Tue, 28 Jul 2015 17:26:16 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dane@ietf.org References: <20150728181130.GB3901@localhost> <20150728191705.GX4347@mournblade.imrryr.org> <20150728220520.GD3901@localhost> <20150728221557.GB4347@mournblade.imrryr.org> <55B81625.5010309@gmail.com> <20150728235752.GE4347@mournblade.imrryr.org> <55B81840.1030602@gmail.com> <20150729003557.GG4347@mournblade.imrryr.org> In-Reply-To: <20150729003557.GG4347@mournblade.imrryr.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dane] Stapling DNSSEC/DANE 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 Jul 2015 01:26:21 -0000 On 7/28/15 4:35 PM, Viktor Dukhovni wrote: > This is based in part on the architectural assumption that in many > cases the right way to process it on the client side will be a > hand-off a local DNS service. I think the primary concern about that is the possibility of introducing additional latency, given that we're trying to minimize the DANE performance hit on clients like browsers, who tend to be extremely sensitive to delay. We probably need clearer discussion about what we're trying to optimize for. But in either case, whether we're using a resolver in a DNS library or handing it off to a service, encoding the records in DNS wire format is going to be easiest for implementers. Several people have talked about writing their own bare-bones resolver that does not use an entire DNS library but I don't have any sense that that's going to be a common case. It's worth talking to people working with highly constrained devices in any event. Thanks, Melinda From nobody Tue Jul 28 18:48:44 2015 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 CEFF51B34C4 for ; Tue, 28 Jul 2015 18:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 IS4IhF9SakHk for ; Tue, 28 Jul 2015 18:48:41 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC6E21B34C3 for ; Tue, 28 Jul 2015 18:48:40 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 22DE8284D5A; Wed, 29 Jul 2015 01:48:40 +0000 (UTC) Date: Wed, 29 Jul 2015 01:48:40 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150729014840.GI4347@mournblade.imrryr.org> References: <20150728181130.GB3901@localhost> <20150728191705.GX4347@mournblade.imrryr.org> <20150728220520.GD3901@localhost> <20150728221557.GB4347@mournblade.imrryr.org> <55B81625.5010309@gmail.com> <20150728235752.GE4347@mournblade.imrryr.org> <55B81840.1030602@gmail.com> <20150729003557.GG4347@mournblade.imrryr.org> <55B82BB8.1060008@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55B82BB8.1060008@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] Stapling DNSSEC/DANE 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: Wed, 29 Jul 2015 01:48:43 -0000 On Tue, Jul 28, 2015 at 05:26:16PM -0800, Melinda Shore wrote: > On 7/28/15 4:35 PM, Viktor Dukhovni wrote: > > This is based in part on the architectural assumption that in many > > cases the right way to process it on the client side will be a > > hand-off a local DNS service. > > I think the primary concern about that is the possibility > of introducing additional latency, given that we're trying > to minimize the DANE performance hit on clients like browsers, > who tend to be extremely sensitive to delay. I expect that the latecy to reach 127.0.0.1 is quite low. And will only be incurred intermittently (client-side validated TLSA RRset cache). When I say "local DNS service", I really mean *local*. > But in either case, whether we're using a resolver > in a DNS library or handing it off to a service, encoding > the records in DNS wire format is going to be easiest for > implementers. Several people have talked about writing > their own bare-bones resolver that does not use an entire > DNS library but I don't have any sense that that's going > to be a common case. It's worth talking to people working > with highly constrained devices in any event. The question is not only whether individual RRs are in wire format (which we already agree on), but whether the entire payload is a DNS packet with all the usual headers and sections. At present the draft departs from that format, and there is some merit in considering whether that's wise. There are perhaps compelling reasons to serialize the multiple RRs differently, but I think they really ought to be *compelling* to trump the potential advantages of using the existing DNS format. The tricky bit is what DNS opcode should be in the DNS header for such a payload. Potentially, something new that constitutes a request for validation of a set of RRsets (from the answer section) via supporting RRSIG/DNSKEY/DS records (from the additional section). Nameserver implementors would then ideally support the new opcode, allowing applications to defer most of the work to the *local* (127.0.0.1, ::1) nameserver. Client libraries would then just need to parse the validated answer, to make sure that the CNAME chains are pertinent (not merely authentic), and the TLSA records match the server certificates. Support for this should ultimately (or immediately) migrate from application code to TLS toolkit code, with the application asking the TLS library to enable DANE stapling support as appropriate. (Some applications, not suffering from last-mile problems, will simply perform their own DNS lookups, often against the same 127.0.0.1 nameserver that is not locked up in a captive portal). -- Viktor. From nobody Tue Jul 28 21:50:59 2015 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 84BA91A1AC9 for ; Tue, 28 Jul 2015 21:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 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_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 ykC7sVLYCE7Y for ; Tue, 28 Jul 2015 21:50:56 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 431021A1A25 for ; Tue, 28 Jul 2015 21:50:56 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTP id B1FD91E064; Tue, 28 Jul 2015 21:50:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=DHjmklFXgcz+H+ +1aTOCOkUj51Q=; b=G24LMzC2u0CccJZZ/GpMZRFMNm5XxAZfTnVe8hsgOf1gTe labSTHLCOf1s0jN71PEDrX6+thDBKxpGqMjmL7FAwOxnXcridJtyaVsERwXiQFDn ua7z5Czt5ujg+HdbWO6m5Ht8dXYukfzGzG0yyTbhcqiKu/TMoJ8F+gTQBrRWM= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTPA id 5A9DA1E059; Tue, 28 Jul 2015 21:50:55 -0700 (PDT) Date: Tue, 28 Jul 2015 23:50:54 -0500 From: Nico Williams To: Melinda Shore Message-ID: <20150729045054.GJ3901@localhost> References: <20150728181130.GB3901@localhost> <20150728191705.GX4347@mournblade.imrryr.org> <20150728220520.GD3901@localhost> <20150728221557.GB4347@mournblade.imrryr.org> <55B81625.5010309@gmail.com> <20150728235752.GE4347@mournblade.imrryr.org> <55B81840.1030602@gmail.com> <20150729003557.GG4347@mournblade.imrryr.org> <55B82BB8.1060008@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55B82BB8.1060008@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Stapling DNSSEC/DANE 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 Jul 2015 04:50:57 -0000 On Tue, Jul 28, 2015 at 05:26:16PM -0800, Melinda Shore wrote: > I think the primary concern about that is the possibility > of introducing additional latency, given that we're trying > to minimize the DANE performance hit on clients like browsers, It's got to be roughly comparable to the WebPKI performance hit. In fact, it will be better because there is no CRL/OCSP for DNSSEC. There may be a few more signatures to check in the DNSSEC case, since it's a proper PKI, so there may be no performance difference. > who tend to be extremely sensitive to delay. We probably > need clearer discussion about what we're trying to optimize > for. But in either case, whether we're using a resolver > in a DNS library or handing it off to a service, encoding > the records in DNS wire format is going to be easiest for > implementers. Several people have talked about writing > their own bare-bones resolver that does not use an entire > DNS library but I don't have any sense that that's going > to be a common case. It's worth talking to people working > with highly constrained devices in any event. Well, I've made a barebones resolver out of the traditional BSD/ISC resolver library as a base. It's almost cheating, yes, but I spent a fair bit of time cleaning and modernizing decades-old code. My codebase still doesn't handle async resolution, but it will, and all in all it's rather simple and small -- small because it relies on a local caching, validating resolver. The hard part is all in the latter. This is not an approach everyone can take: because a local caching, validating resolver daemon is not universally guaranteed to be present. But a local caching, validating resolver ought to be always present: it's the best place for caching that can be trusted by the user. Nico -- From nobody Tue Jul 28 21:58:02 2015 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 674971A1B16 for ; Tue, 28 Jul 2015 21:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 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_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 0bH_mJaYpSyO for ; Tue, 28 Jul 2015 21:57:59 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 60F0C1A1B14 for ; Tue, 28 Jul 2015 21:57:59 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id 20DD4678071; Tue, 28 Jul 2015 21:57:59 -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=z8v+dyHYy7sESPnp16HV4QkxVP8 =; b=wkOY0sSHt9m1lZ3uVlxUyxlacdtLeVdAV3G9QSUgV53OB6v5yEsMLcn5RCR K8lzxJprkZpJVFUX7W8SImUAlcAZnDW89jiuMcsf3jLT8vQnhlcZ8bS98kxhqWcu auci38egA2Dn3h5lY55TYjwz2XBYImfBc0uaLxw/tb5qzpZA= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPA id CD069678062; Tue, 28 Jul 2015 21:57:58 -0700 (PDT) Date: Tue, 28 Jul 2015 23:57:58 -0500 From: Nico Williams To: dane@ietf.org Message-ID: <20150729045757.GK3901@localhost> References: <20150728181130.GB3901@localhost> <20150728191705.GX4347@mournblade.imrryr.org> <20150728220520.GD3901@localhost> <20150728221557.GB4347@mournblade.imrryr.org> <55B81625.5010309@gmail.com> <20150728235752.GE4347@mournblade.imrryr.org> <55B81840.1030602@gmail.com> <20150729003557.GG4347@mournblade.imrryr.org> <55B82BB8.1060008@gmail.com> <20150729014840.GI4347@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150729014840.GI4347@mournblade.imrryr.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [dane] Stapling DNSSEC/DANE 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 Jul 2015 04:58:00 -0000 On Wed, Jul 29, 2015 at 01:48:40AM +0000, Viktor Dukhovni wrote: > There are perhaps compelling reasons to serialize the multiple RRs > differently, but I think they really ought to be *compelling* to > trump the potential advantages of using the existing DNS format. Right, because firstly the DNS message format is in widespread use (understatement of the month), and secondly because anyone wishing to use DNS to the loopback resolver as the validation API will appreciate not having to re-encode the thing, and thirdly because anyone trying to obtain a stapled DANE payload will appreciate being able to use DNS to the loopback resolver as the API for obtaining it. DNS is such a stable and universal protocol that it is an API. That's a huge benefit. > The tricky bit is what DNS opcode should be in the DNS header for > such a payload. Potentially, something new that constitutes a > request for validation of a set of RRsets (from the answer section) > via supporting RRSIG/DNSKEY/DS records (from the additional section). Whatever the stapler puts in, the relying party has to check/coerce the header to be as the loopback resolver will expect. There is no need to parse the rest of the stapled response, as the local resolver daemon ought to be secure and less-privileged than the relying party. > Nameserver implementors would then ideally support the new opcode, > allowing applications to defer most of the work to the *local* > (127.0.0.1, ::1) nameserver. Yes. > Client libraries would then just need to parse the validated answer, > to make sure that the CNAME chains are pertinent (not merely > authentic), and the TLSA records match the server certificates. And note: only the header and the answer section, since the signatures will have been validated and therefore of no further interest. Nico -- From nobody Tue Jul 28 23:20:03 2015 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 2F73D1A8731 for ; Tue, 28 Jul 2015 23:20:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.061 X-Spam-Level: X-Spam-Status: No, score=-1.061 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_DE=0.35, J_CHICKENPOX_66=0.6, 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 qwbBQArXkX63 for ; Tue, 28 Jul 2015 23:19:59 -0700 (PDT) Received: from mail.sys4.de (mail.sys4.de [IPv6:2001:1578:400:111::7]) (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 669801A1BC6 for ; Tue, 28 Jul 2015 23:19:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sys4.de; h= in-reply-to:content-transfer-encoding:content-disposition :content-type:content-type:mime-version:references:message-id :subject:subject:from:from:date:date; s=mail201310; t= 1438150796; x=1439965197; bh=4HBUWyNWVekIgg1ibv/k1sHPGK22q68xMsK 53QJoyZ0=; b=gpaCrFWxbOVmTdqiMORlv4h8KyV8tYbwbtSsYsi02RfCMLK3OUN e0I16KiJT2CJCMCV7BfTbdQo0V9HHQcNX4s0CBopUt28H0yKVE777PjRyYTcCSzT MhtfZn3j7vd51PW78pNaKnGnyzvghTjmVfcN4C1c7QKw5N7q7eoy1dIPUAsIi220 E45vKkL2maVfX6y6Iu14YIry0RZ1YvuMztl3ghQgQouf+oL3Du58+0QnfjrHheLq R/X7RXPDNGJzDFWrW7MLJFQKFR+I8zsNXRxq4+wvty+4ffKrKQMuCUEluacBu+CK lwBRbdyBYw4mg3TlhB2bb5PxXDAkEwoxW2A== X-Virus-Scanned: Debian amavisd-new at mail.sys4.de Received: from sys4.de (ipbcc2bd2b.dynamic.kabel-deutschland.de [188.194.189.43]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sys4.de (Postfix) with ESMTPSA id 3mh4V43RZKzgN for ; Wed, 29 Jul 2015 08:19:56 +0200 (CEST) Date: Wed, 29 Jul 2015 08:19:55 +0200 From: Patrick Ben Koetter To: dane@ietf.org Message-ID: <20150729061955.GA9253@sys4.de> References: <20150728234646.GC4347@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Archived-At: Subject: Re: [dane] DANE client+server authentication 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 Jul 2015 06:20:01 -0000 * Ian Maddison : > > > On 29 Jul 2015, at 01:46, Viktor Dukhovni wrote: > > > > On Wed, Jul 29, 2015 at 12:42:52AM +0200, Ian Maddison wrote: > > > >> I'm looking for a way to run a recursive name server on a public IP address > >> restricted to pre-configured roaming clients. > >> > >> Is, or will it be feasible to leverage DANE-TA to reliably authenticate > >> both the clients and server in order to run this type of service? > > > > No, not possible. > > > > And I am afraid this is not an end-user help/support forum, so this > > type of question belongs elsewhere, e.g. the BIND or unbound users > > list, or similar. > > > > -- > > Viktor. > > > Oh ok, I'm sorry about that. > > Although I’ve followed this list for several years, improved readability for one of your drafts and helped fix an an error or two, it seems I may have missed details regarding client authentication and would appreciate a pointer, if that’s not too much to ask :) There's no usable client authentication at the moment. A first draft for client authentication has been published: https://datatracker.ietf.org/doc/draft-huque-dane-client-cert/ AFAIK it has also been discussed at the recent IETF meeting. That's all there is for the moment. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein From nobody Tue Jul 28 23:40:52 2015 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 1B7211ACDBB for ; Tue, 28 Jul 2015 23:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.41 X-Spam-Level: X-Spam-Status: No, score=-1.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_66=0.6, 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 azACcb77rWZa for ; Tue, 28 Jul 2015 23:40:47 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE9661A8893 for ; Tue, 28 Jul 2015 23:40:47 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mh4y56Qbxz3Fr; Wed, 29 Jul 2015 08:40:45 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=L9aKtBZg X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id TGSo4SMwsUJj; Wed, 29 Jul 2015 08:40:44 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 29 Jul 2015 08:40:44 +0200 (CEST) Received: from [10.193.4.229] (gprs29.vodafone.cz [188.95.127.238]) by bofh.nohats.ca (Postfix) with ESMTPSA id 2DD2F800B3; Wed, 29 Jul 2015 02:40:43 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1438152043; bh=XDHNuDAWY54nK272gDdo7CTrDEDVB9ctr4DwCzeWWVY=; h=References:In-Reply-To:Cc:From:Subject:Date:To; b=L9aKtBZgdWOnWNOitOiVgYHt0fX9gJPeujBVNLfdUA1kUqoj1XsMr65X3rx0fQmBD ghaYzwcUPG7zGHuVL1cwtD6wRNmWZ9t/yPSdxHtgsfresllaizkOxuCDUjAYW17kri xVAUXkylsyVt9jVrd+jdPcUQKXjBGnWvs825Vhtg= References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <2CFA2366-6BA4-4263-B224-B2C62C69511E@nohats.ca> X-Mailer: iPhone Mail (13A4305g) From: Paul Wouters Date: Wed, 29 Jul 2015 08:40:38 +0200 To: Ian Maddison Archived-At: Cc: dane@ietf.org Subject: Re: [dane] DANE client+server authentication 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 Jul 2015 06:40:49 -0000 Configure an IPsec tunnel in the clients and run IPSec on the namespaces and= block port 53 without IPSec. I actually presented a simple IKEv2 libreswan c= onfig to do song from android/iPhone=20 Sent from my iPhone > On Jul 29, 2015, at 00:42, Ian Maddison wrote: >=20 > I=E2=80=99m looking for a way to run a recursive name server on a public I= P address restricted to pre-configured roaming clients. >=20 > Is, or will it be feasible to leverage DANE-TA to reliably authenticate bo= th the clients and server in order to run this type of service ? >=20 > =E2=80=94 > Ian Maddison > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From nobody Tue Jul 28 23:45:16 2015 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 77BF61ACED4 for ; Tue, 28 Jul 2015 23:45:13 -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 nNckZEyNnsZX for ; Tue, 28 Jul 2015 23:45:12 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDAE61A1BAE for ; Tue, 28 Jul 2015 23:45:11 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mh53B2tBDz3Fr; Wed, 29 Jul 2015 08:45:10 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=FWpiaO/v X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 83UncK5TV_WL; Wed, 29 Jul 2015 08:45:08 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 29 Jul 2015 08:45:08 +0200 (CEST) Received: from [10.193.4.229] (gprs29.vodafone.cz [188.95.127.238]) by bofh.nohats.ca (Postfix) with ESMTPSA id 95E65800B3; Wed, 29 Jul 2015 02:45:07 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1438152307; bh=ZfFreN9BpnDTt6Lde2IHwHIzbi+qaxpRCjvsLxYKZyI=; h=References:In-Reply-To:Cc:From:Subject:Date:To; b=FWpiaO/vFjuTUwHisQQVYTlXxCbEoVNhmIdfa/fwrCC9KNkRzKav+9elfncZAWZ8j kpb6h3ZVKhVf2fTx0rQ7B3FV0d9fzgdzM4l97lGYnMKbgOAI4lnFqiR51FxTK5dDbV UhJaGlh4vGIH0gjjjt7uY2UQekQSP2Xgoc5wkp/M= References: <20150728181130.GB3901@localhost> Mime-Version: 1.0 (1.0) In-Reply-To: <20150728181130.GB3901@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <355779C9-2505-4CC1-9707-7D83482A4403@nohats.ca> X-Mailer: iPhone Mail (13A4305g) From: Paul Wouters Date: Wed, 29 Jul 2015 08:45:03 +0200 To: Nico Williams Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Stapling DNSSEC/DANE 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 Jul 2015 06:45:13 -0000 Sounds familiar :) https://tools.ietf.org/html/draft-ietf-dnsop-edns-chain-query-02 Sent from my iPhone > On Jul 28, 2015, at 20:11, Nico Williams wrote: > > I doubt this is the right list to send this to, but might as well start > here and move this elsewhere as needed. > > My proposal for stapling DNSSEC/DANE is as follows: > > - Use a DNS response whose answer is the TLSA RRset and whose > additional section contains all the DNSSEC RRsets needed to validate > the answer, chaining all the way to ., of course. > > One can already get such responses from caching validating resolvers, so > producing these is easy. > > Validating them requires a library, but ideally we could define a > protocol to speak to caching validating resolvers for validating stapled > DNSSEC, my proposal for which is: > > - Send the stapled DNSSEC response as a query that the caching > validating resolver must then respond to with an error if it does not > validate, or with an answer that contains just the answer RRset > (which must match the query). > > Caching validating resolvers would be allowed to also ignore the > answer and additional RRs in the query and instead answer the > question as usual. Clients would have to check the response to make > sure they got the same TLSA RRset as stapled. > > Obviously this would work for RRs other than TLSA. > > Nico > -- > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From nobody Wed Jul 29 01:39:23 2015 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 62C991B34D7 for ; Wed, 29 Jul 2015 01:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1rTceYBMepG for ; Wed, 29 Jul 2015 01:39:20 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA1F81A702F for ; Wed, 29 Jul 2015 01:39:19 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 36DC420B5D for ; Wed, 29 Jul 2015 04:39:19 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 29 Jul 2015 04:39:19 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=mad.paris; h= content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=QwQ8v ZXPfDOu5UIFp8SS+f0T/1k=; b=iHy7EtQ21/oUqnipEXtoGN1HCsWVbNaRkSl5B Ozrv78V3kAU++mrpwgd7CDGerUyjybfAN3w22vtCG9n1d1Dl/mtavT6BzdLtZ+Dr DgF+VYnq7oChUeajg3DGpgJvJdvfpUBk8DhPczOcSE4UmZYsjqcv44WiDLEEdYln ZH+jJs= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=QwQ8vZXPfDOu5UIFp8SS+f0T/1k=; b=PR9pf /eK8dr6V1nIfbpUHX/55fhZKZLsrkPIvw4xeTgfNFHNdrcrUkWVqANJeGA5l2hFB NYS73xWlRPame0wFHvbQ40ly//dNnaQ3vz8AkFAuw26Eo1kHSbUVVL0yXEI2TQUQ nvOxRdD9qR4lRVjS4ltlwwba699/jBSjSEVhUU= X-Sasl-enc: tRqdaOVT3mbcWc55EQMpcixm4zEopZUodnmS90EF9vh0 1438159158 Received: from [192.168.1.43] (78.215.207.77.rev.sfr.net [77.207.215.78]) by mail.messagingengine.com (Postfix) with ESMTPA id B8D6EC00027 for ; Wed, 29 Jul 2015 04:39:18 -0400 (EDT) From: Ian Maddison Content-Type: multipart/alternative; boundary="Apple-Mail=_8E0A1D16-4CBF-4321-B032-838D5EF33026" Message-Id: <584FD478-4EC2-4B3B-AB69-556FB092BF59@mad.paris> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) Date: Wed, 29 Jul 2015 10:39:16 +0200 References: <20150728234646.GC4347@mournblade.imrryr.org> <20150729061955.GA9253@sys4.de> To: dane@ietf.org In-Reply-To: <20150729061955.GA9253@sys4.de> X-Mailer: Apple Mail (2.2102) Archived-At: Subject: Re: [dane] DANE client+server authentication 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 Jul 2015 08:39:22 -0000 --Apple-Mail=_8E0A1D16-4CBF-4321-B032-838D5EF33026 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 29 Jul 2015, at 08:19, Patrick Ben Koetter wrote: >=20 > There's no usable client authentication at the moment. > A first draft for client authentication has been published: >=20 > https://datatracker.ietf.org/doc/draft-huque-dane-client-cert/ >=20 Thanks. Sorry, I should=E2=80=99ve been clearer, that=E2=80=99s the = draft I had in mind, namely: ...3=E2=80=A6 Clients often have dynamic or unpredictable addresses, and may=20 move around the network, so tying their identity to network addresses is not feasible or wise. The client generates (or has generated for it) a private and public key pair, and a certificate binding the name to its public key. This certificate has a corresponding TLSA record published in the DNS, which allows it to be authenticated directly via the DNS (using the DANE-TA or DANE-EE usage modes)... ...5=E2=80=A6 Hence, to address this issue generally, a client identity signaling solution will need to be devised, whereby the client indicates its DANE identity (i.e. its domain name identity and the fact that this identity has an associated TLSA record) to the server. Application specific protocol enhancements are one way to achieve this, e.g. a new SMTP command. A more general way would be to develop a new=20 TLS extension to convey this information. [Another internet draft is currently being written to define such a TLS extension to convey DANE client identity.] =E2=80=A67=E2=80=A6 A TLS Client conforming to this specification MUST have a signed DNS TLSA record published corresponding to its DNS name and X.509 certificate. The client presents this certificate in the TLS handshake with the server. The presented client certificate MUST have have the client=E2=80=99s DNS name specified either in the = Subject Alternative Name extension=E2=80=99s dNSName type, or the SRVName = type. Servers may have their own whitelisting and authorization rules for which certificates they accept. For example a TLS server may be configured to only allow TLS sessions from clients with certificate identities within a specific domain or set of domains. > AFAIK it has also been discussed at the recent IETF meeting. >=20 > That's all there is for the moment. I=E2=80=99m hoping to hear more about this going forward. --- Ian Maddison= --Apple-Mail=_8E0A1D16-4CBF-4321-B032-838D5EF33026 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 29 Jul 2015, at = 08:19, Patrick Ben Koetter <p@sys4.de> wrote:

There's = no usable client authentication at the moment.
A first = draft for client authentication has been published:

https://datatracker.ietf.org/doc/draft-huque-dane-client-cert/<= /a>


Thanks. Sorry, I should=E2=80=99ve been = clearer, that=E2=80=99s the draft I had in mind, namely:

...3=E2=80=A6

  Clients often have dynamic or = unpredictable addresses, and may 
  = move around the network, so tying their identity to network = addresses
  is not feasible or = wise.

  =  The client generates (or has generated for it) a private and = public
   key pair, and a certificate = binding the name to its public key.  This
 =  certificate has a corresponding TLSA record published in the = DNS,
   which allows it to be = authenticated directly via the DNS (using the
  =  DANE-TA or DANE-EE usage modes)...

...5=E2=80=A6=

   Hence, to address this issue = generally, a client identity signaling
  =  solution will need to be devised, whereby the client indicates = its
   DANE identity (i.e. its domain name = identity and the fact that this
   identity has = an associated TLSA record) to the server.  Application
   specific protocol enhancements are one way to = achieve this, e.g. a
   new SMTP command. =  A more general way would be to develop a new 
   TLS extension to convey this = information.

   [Another internet draft is currently being written to = define such a
   TLS extension to convey DANE = client identity.]

=E2=80=A67=E2=80=A6

   A TLS Client conforming to this = specification MUST have a signed DNS
   TLSA = record published corresponding to its DNS name and X.509
   certificate.  The client presents this = certificate in the TLS
   handshake with the = server.  The presented client certificate MUST
  =  have have the client=E2=80=99s DNS name specified either in the = Subject
   Alternative Name extension=E2=80=99s = dNSName type, or the SRVName type.

  =  Servers may have their own whitelisting and authorization rules = for
   which certificates they accept.  For = example a TLS server may be
   configured to = only allow TLS sessions from clients with certificate
 =  identities within a specific domain or set of domains.

AFAIK it has also been discussed at the recent IETF = meeting.

That's all there is for the = moment.

I=E2=80=99m hoping to hear more about = this going forward.

---
Ian Maddison
= --Apple-Mail=_8E0A1D16-4CBF-4321-B032-838D5EF33026-- From wrstuden@me.com Tue Jul 28 18:55:29 2015 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 6E6901A1BE0 for ; Tue, 28 Jul 2015 18:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_66=0.6, 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 QvWIU12vQoA5 for ; Tue, 28 Jul 2015 18:55:28 -0700 (PDT) Received: from mr11p24im-asmtp004.me.com (mr11p24im-asmtp004.me.com [17.110.78.110]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 116C61A0366 for ; Tue, 28 Jul 2015 18:55:28 -0700 (PDT) Received: from waterdeep.home.queervillage.us (ip68-6-163-116.sd.sd.cox.net [68.6.163.116]) by mr11p24im-asmtp004.me.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0NS800GBP80CIB50@mr11p24im-asmtp004.me.com> for dane@ietf.org; Wed, 29 Jul 2015 01:55:27 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151,1.0.33,0.0.0000 definitions=2015-07-29_01:2015-07-28,2015-07-28,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=2 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412110000 definitions=main-1507290033 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: William Stouder-Studenmund In-reply-to: Date: Tue, 28 Jul 2015 18:55:24 -0700 Content-transfer-encoding: quoted-printable Message-id: <8E73E3BC-8DD2-4A01-8EA1-2B40CEDF1526@me.com> References: <20150728234646.GC4347@mournblade.imrryr.org> To: Ian Maddison X-Mailer: Apple Mail (2.2102) Archived-At: X-Mailman-Approved-At: Wed, 29 Jul 2015 06:58:31 -0700 Cc: dane@ietf.org Subject: Re: [dane] DANE client+server authentication 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 Jul 2015 02:12:53 -0000 > On Jul 28, 2015, at 5:37 PM, Ian Maddison wrote: >=20 >=20 >> On 29 Jul 2015, at 01:46, Viktor Dukhovni = wrote: >>=20 >> On Wed, Jul 29, 2015 at 12:42:52AM +0200, Ian Maddison wrote: >>=20 >>> I'm looking for a way to run a recursive name server on a public IP = address >>> restricted to pre-configured roaming clients. >>>=20 >>> Is, or will it be feasible to leverage DANE-TA to reliably = authenticate >>> both the clients and server in order to run this type of service? >>=20 >> No, not possible. >>=20 >> And I am afraid this is not an end-user help/support forum, so this >> type of question belongs elsewhere, e.g. the BIND or unbound users >> list, or similar. >>=20 >> --=20 >> Viktor. >=20 >=20 > Oh ok, I'm sorry about that.=20 >=20 > Although I=E2=80=99ve followed this list for several years, improved = readability for one of your drafts and helped fix an an error or two, it = seems I may have missed details regarding client authentication and = would appreciate a pointer, if that=E2=80=99s not too much to ask :) The key issue I see is that you said =E2=80=9Croaming=E2=80=9D clients. = DANE requires the cooperation of the system administrator and the = operators of the DNS infrastructure. That=E2=80=99s great where the = server administrators work with the local DNS operators, either as they = are the same people or they work for the same company. I would not trust DNS operators of =E2=80=9Croaming=E2=80=9D clients. I = would not trust the DNS operators of a random cafe your clients are = using for connectivity. I do not know of a good way for your clients to = upload TLSA records each time the client gets an IP address nor would I = really trust what a coffee company tried to tell me was the right = certificate information for the client even IF it were plausible that = the client provided it. DANE is really great for telling a connecting agent security information = about the system it is connecting to. That would be the client and = server respectively. I think the server should just require client certs in its TLS = negotiation and decide if it likes or dislikes (trusts or doesn=E2=80=99t = trust) the certificate it gets. Take care, Bill From nobody Wed Jul 29 08:19:47 2015 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 91BD81A8905 for ; Wed, 29 Jul 2015 08:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, J_CHICKENPOX_66=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 ZD38dL8lPVQA for ; Wed, 29 Jul 2015 08:19:45 -0700 (PDT) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94DFE1A892F for ; Wed, 29 Jul 2015 07:58:15 -0700 (PDT) Received: by qgeu79 with SMTP id u79so5585196qge.1 for ; Wed, 29 Jul 2015 07:58:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FxNsU8DE3+TGQPVaJtagzBFhp4XVqPMLfI9flve5aV8=; b=tDkZbBwTCsmsdOXI4ehgcUGDohHps5reSugEAqacfAKFizxfHZRMOWTd9E3/pufVfe tyYfNdwXrtn+MDreujQLI9VrKcSEZfw5FUc45D4MoB0bb5ea66d6UQIOhiKpesN0Oquf lHc3v8C6uMoCArnPp0A5GD7aND50n9q24isjmZbK8K9hhx1UUvPZaRcFXe0BUJdxUnXV pLss5D4XjeuvKdVzNiJLnShO21lNkXiqBIHHSz699Gk6Q49q5oty9+CIC7xY2q+ONbHD nuYEMsNY9FG95obllmd+5oH6g71s34IUbmIn75Go2XHH/xG9daKl2Pa2BZwiiXUnoa4o 1D0A== MIME-Version: 1.0 X-Received: by 10.140.38.21 with SMTP id s21mr46918107qgs.10.1438181894708; Wed, 29 Jul 2015 07:58:14 -0700 (PDT) Received: by 10.140.80.208 with HTTP; Wed, 29 Jul 2015 07:58:14 -0700 (PDT) In-Reply-To: <584FD478-4EC2-4B3B-AB69-556FB092BF59@mad.paris> References: <20150728234646.GC4347@mournblade.imrryr.org> <20150729061955.GA9253@sys4.de> <584FD478-4EC2-4B3B-AB69-556FB092BF59@mad.paris> Date: Wed, 29 Jul 2015 10:58:14 -0400 Message-ID: From: Shumon Huque To: Ian Maddison Content-Type: multipart/alternative; boundary=001a11c12c40f4e6a5051c04d06b Archived-At: Cc: "" Subject: Re: [dane] DANE client+server authentication 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 Jul 2015 15:19:46 -0000 --001a11c12c40f4e6a5051c04d06b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jul 29, 2015 at 4:39 AM, Ian Maddison wrote: > > On 29 Jul 2015, at 08:19, Patrick Ben Koetter wrote: > > There's no usable client authentication at the moment. > A first draft for client authentication has been published: > > https://datatracker.ietf.org/doc/draft-huque-dane-client-cert/ > > > Thanks. Sorry, I should=E2=80=99ve been clearer, that=E2=80=99s the draft= I had in mind, > namely: > [...] > AFAIK it has also been discussed at the recent IETF meeting. > > That's all there is for the moment. > > > I=E2=80=99m hoping to hear more about this going forward. > > Yes, the draft was presented at the DANE working group meeting at IETF93 in Prague last week. This is primarily geared towards client authentication (via X.509 certificates or raw public keys) in TLS applications. It is probably not a great fit for your originally mentioned use case of authentication and access control at DNS recursive servers which don't typically use TLS today. There are plans in the pipeline to do DNS over TLS between stubs and recursive servers, but even then, there are bootstrapping, circular dependency, and configuration challenges that might not make this draft suitable for that case. For client access control to a recursive server, for now I'd suggest looking at other approaches, e.g. TSIG, IPsec, etc. If in an enterprise environment with a central authentication system, GSS-TSIG might be an option for scalable per-client authentication and access control. All of this could run over TLS in the future for privacy protection. That said, we're hoping to move the TLSA client certificates draft forward. One thing I forgot to do at IETF is to ask the working group chairs to gauge interest in adopting the draft. I will send a separate note about that on list shortly. Shumon Huque. --001a11c12c40f4e6a5051c04d06b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jul 29, 2015 at 4:39 AM, Ian Maddison <ian@mad.paris> wrote:=

=
On 29 Jul 2015, at 08:19, Patric= k Ben Koetter <p@sys4.de<= /a>> wrote:

There's no usable client authentication at the mo= ment.
A first draft for client authentication has been published:
https://datatracker.ietf.org/doc/draft-huque-dane= -client-cert/


Thanks. Sorry, I = should=E2=80=99ve been clearer, that=E2=80=99s the draft I had in mind, nam= ely:

[...]
AFAIK it has also been discussed at the recent IETF mee= ting.

That's all there is for the moment.
<= br>
I=E2=80=99m hoping to hear more about this going forwa= rd.


Yes, the dra= ft was presented at the DANE working group meeting at IETF93 in Prague last= week. This is primarily geared towards client authentication (via X.509 ce= rtificates or raw public keys) in TLS applications. It is probably not a gr= eat fit for your originally mentioned use case of authentication and access= control at DNS recursive servers which don't typically use TLS today. = There are plans in the pipeline to do DNS over TLS between stubs and recurs= ive servers, but even then, there are bootstrapping, circular dependency, a= nd configuration challenges that might not make this draft suitable for tha= t case.

For client access control to a recursive s= erver, for now I'd suggest looking at other approaches, e.g. TSIG, IPse= c, etc. If in an enterprise environment with a central authentication syste= m, GSS-TSIG might be an option for scalable per-client authentication and a= ccess control. All of this could run over TLS in the future for privacy pro= tection.

That said, we're hoping to move the T= LSA client certificates draft forward. One thing I forgot to do at IETF is = to ask the working group chairs to gauge interest in adopting the draft. I = will send a separate note about that on list shortly.

<= div>Shumon Huque.

--001a11c12c40f4e6a5051c04d06b-- From nobody Wed Jul 29 08:28:37 2015 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 38D5D1AC3E3; Wed, 29 Jul 2015 08:28:33 -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 qBr0hWk_DU2M; Wed, 29 Jul 2015 08:28:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 372441B2E28; Wed, 29 Jul 2015 08:17:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.2.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150729151728.549.85266.idtracker@ietfa.amsl.com> Date: Wed, 29 Jul 2015 08:17:28 -0700 Archived-At: Cc: dane-chairs@ietf.org, dane@ietf.org, draft-ietf-dane-ops.ad@ietf.org, draft-ietf-dane-ops.shepherd@ietf.org, draft-ietf-dane-ops@ietf.org Subject: [dane] Barry Leiba's No Objection on draft-ietf-dane-ops-14: (with COMMENT) 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: Wed, 29 Jul 2015 15:28:33 -0000 Barry Leiba has entered the following ballot position for draft-ietf-dane-ops-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dane-ops/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Editorial comments only -- most very minor, but one for Section 4 and its subsections is more substantive. -- Section 1 -- DNSSEC validated DANE TLSA records can be used to augment or replace the use of trusted public Too many cascading modifiers can make a sentence confusing (even if you were to hyphenate "DNSSEC-validated", as it should be). I suggest untangling that slightly, this way: NEW DANE TLSA records validated by DNSSEC can be used to augment or replace the use of trusted public END [RFC6698] defines three TLSA record fields with respectively 4, 2 and 3 currently specified values. There's nothing to correspond with "respectively" here (compare that with the correct use in the first paragrah of the Introduction). Try this: NEW [RFC6698] defines three TLSA record fields, the first with 4 possible values, the second with 2, and the third with 3. END -- Section 3 -- A bit of awkward wording here, and an overly long sentence, both easily fixed: OLD When a servers does support SNI, but is not configured with a certificate chain that exactly matches the client's SNI extension, SHOULD respond with some other (default or closest match) certificate chain, since clients may support more than one server name, but can only put a single name in the SNI extension. NEW When a server supports SNI but is not configured with a certificate chain that exactly matches the client's SNI extension, the server SHOULD respond with another certificate chain (a default or closest match). This is because clients might support more than one server name, but can only put a single name in the SNI extension. END -- Section 4 -- Protocol designers need to carefully consider which set of DANE certificate usages to support. I'm not sure why this (and the next sentence) is referring to "protocol designers". Is this not aimed at implementation/deployment choices? If that's not correct, who are the targets for this advice? I also find this section to be rather hard to follow -- I can't clearly figure out what the advice really is. Can you do a little reorganization here, separating the advice out from the explanation of why? I don't care whether you put the explanation first or the advice first, but it would help to have one paragraph that says, clearly and without fuss, what the recommendation is. This applies to the subsections as well. From nobody Wed Jul 29 10:01:42 2015 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 D54C21ACD74 for ; Wed, 29 Jul 2015 10:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 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_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 Ug9LX4GmwgJr for ; Wed, 29 Jul 2015 10:01:39 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 049141ACDB7 for ; Wed, 29 Jul 2015 10:01:32 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id 9FA571DE094; Wed, 29 Jul 2015 10:01:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=2fe8Ky3+Izzqgx wa1gUN8lKWt9o=; b=XHD/qkMrywYQlOrRtJLeNdnhl0HUGi+ORP/f1B7i3l0e/q JLWwTWZoQTekXJLmqcsJbKIPgxOfGBHtS6aB50rkD462e+tyS3WrayuYz3d2o3v7 r4Lm5dqlrYq6A7gr5xv9VcFrQxKaG08ePKe4enCWvEGgGd43XtG0J7snZI3sM= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPA id 2633C1DE085; Wed, 29 Jul 2015 10:01:29 -0700 (PDT) Date: Wed, 29 Jul 2015 12:01:28 -0500 From: Nico Williams To: Melinda Shore Message-ID: <20150729170127.GA20726@localhost> References: <20150728181130.GB3901@localhost> <20150728191705.GX4347@mournblade.imrryr.org> <20150728220520.GD3901@localhost> <20150728221557.GB4347@mournblade.imrryr.org> <55B81625.5010309@gmail.com> <20150728235752.GE4347@mournblade.imrryr.org> <55B81840.1030602@gmail.com> <20150729003557.GG4347@mournblade.imrryr.org> <55B82BB8.1060008@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55B82BB8.1060008@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Stapling DNSSEC/DANE 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 Jul 2015 17:01:41 -0000 On Tue, Jul 28, 2015 at 05:26:16PM -0800, Melinda Shore wrote: > I think the primary concern about that is the possibility > of introducing additional latency, given that we're trying > to minimize the DANE performance hit on clients like browsers, > who tend to be extremely sensitive to delay. [...] This is probably worth going over in some detail. Where there is no last-mile problem the client will do best to issue async DNS lookups for all the records it needs, and this will probably be faster than stapling. But the client won't always know (especially if it's mobile) when stapling is the only thing that will help, so stapling we must. When stapling is needed there is no latency hit on the server (of course), and the only latency hit on the client is a) the time to transmit the stapled data (server-to-client), b) the time to transmit the stapled data (client-to-resolver-daemon), c) the time to validate the stapled data, d) having to wait until all the stapled data is available to begin validation. (a) and (c) are present whether we staple or not, and (b) is negligible (loopback networking). There's a negligible win in not having to send requests. That leaves just (d): having to wait for the stapled data. But (d) is the same for DANE as for WebPKI/PKIX, which leaves us with... nothing that adds latency by comparison to WebPKI/PKIX. The case where client can speak DNS itself is a win compared to WebPKI/PKIX because the client can asynchronously do some of the trust chain validation work before getting the stapled data from the server. Stapling DNSSEC/DANE is no different than the server sending its certificate chain to the client and needs to be compared to just that, not just to stapling of OCSP Responses. If there's a latency hit, it will be when a sever has both, a long PKIX certificate chain and a long DNSSEC/DANE RRset chain to send (since both have to be transmitted, and the client may end up having to validate both). Operators should avoid this. In any case, I don't see how the encoding of the RRsets affects latency except that using a DNS message is a win for those who use DNS to a local resolver daemon as the validation API. Using a DNS message is neutral for all other implementors. Nico -- From nobody Wed Jul 29 10:05:20 2015 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 A56A71B2E43 for ; Wed, 29 Jul 2015 10:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 5kwVK3M3JQR1 for ; Wed, 29 Jul 2015 10:05:18 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 311071B3011 for ; Wed, 29 Jul 2015 10:05:05 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 1B155282FB1; Wed, 29 Jul 2015 17:05:05 +0000 (UTC) Date: Wed, 29 Jul 2015 17:05:05 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150729170504.GN4347@mournblade.imrryr.org> References: <20150729151728.549.85266.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150729151728.549.85266.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] Barry Leiba's No Objection on draft-ietf-dane-ops-14: (with COMMENT) 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: Wed, 29 Jul 2015 17:05:19 -0000 On Wed, Jul 29, 2015 at 08:17:28AM -0700, Barry Leiba wrote: > NEW > DANE TLSA records validated by > DNSSEC can be used to augment or replace the use of trusted public > END Thanks, done. > NEW > [RFC6698] defines three TLSA record fields, the first with 4 possible > values, the second with 2, and the third with 3. > END Thanks, done. > NEW > When a server supports SNI but is not configured with a certificate > chain that exactly matches the client's SNI extension, the server > SHOULD respond with another certificate chain (a default or closest > match). This is because clients might support more than one server > name, but can only put a single name in the SNI extension. > END Thanks, done. > -- Section 4 -- > > Protocol designers need to carefully consider which set of DANE > certificate usages to support. > > I'm not sure why this (and the next sentence) is referring to "protocol > designers". Is this not aimed at implementation/deployment choices? If > that's not correct, who are the targets for this advice? This should likely say "application protocol designers". The point being that the use of DANE TLSA RRs in a particular application (as with e.g. SMTP) can be defined (more specifically than in RFC6698 and this draft) by an application-specific standard. > I also find this section to be rather hard to follow -- I can't clearly > figure out what the advice really is. Can you do a little reorganization > here, separating the advice out from the explanation of why? I don't > care whether you put the explanation first or the advice first, but it > would help to have one paragraph that says, clearly and without fuss, > what the recommendation is. This applies to the subsections as well. Will try to clarify, this will take more time. Should the two smaller changes above be pushed as -15, while section 4 is polished? -- Viktor. From nobody Wed Jul 29 10:38:54 2015 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 785441B2ADB for ; Wed, 29 Jul 2015 10:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 K6CXbdh_fcDo for ; Wed, 29 Jul 2015 10:38:49 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC0311B2ADD for ; Wed, 29 Jul 2015 10:38:49 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 7C5E1282FB1; Wed, 29 Jul 2015 17:38:48 +0000 (UTC) Date: Wed, 29 Jul 2015 17:38:48 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150729173848.GP4347@mournblade.imrryr.org> References: <20150728181130.GB3901@localhost> <20150728191705.GX4347@mournblade.imrryr.org> <20150728220520.GD3901@localhost> <20150728221557.GB4347@mournblade.imrryr.org> <55B81625.5010309@gmail.com> <20150728235752.GE4347@mournblade.imrryr.org> <55B81840.1030602@gmail.com> <20150729003557.GG4347@mournblade.imrryr.org> <55B82BB8.1060008@gmail.com> <20150729170127.GA20726@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150729170127.GA20726@localhost> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] Stapling DNSSEC/DANE 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: Wed, 29 Jul 2015 17:38:51 -0000 On Wed, Jul 29, 2015 at 12:01:28PM -0500, Nico Williams wrote: > If there's a latency hit, it will be when a sever has both, a long PKIX > certificate chain and a long DNSSEC/DANE RRset chain to send (since both > have to be transmitted, and the client may end up having to validate > both). Operators should avoid this. This raises an interesting point. On the one hand the server cannot do much about the length of X.509 certificate chain, it is what it is, and clients may indeed need to validate "both" (the X.509 chain and its supporting TLSA records with supporting DNSSEC signatures, keys, ...). On the other hand, if the TLSA records in question are DANE-TA(2) or DANE-EE(3), then if the client's extension requesting stapled TLSA RRs can be interpreted by the server as a reliable signal that client is doing DANE-TLSA authentication, the server may well be able to "truncate" its X.509 chain to just those certificates needed to match the TLSA records. In particular, with matching DANE-EE(3) TLSA record, the server might send only the leaf certificate without any intermediate CA certificates. While with a matching DANE-TA(2) TLSA record, the server might send a chain that extends only as far as that trust-anchor certificate and no furhter. If that trust-anchor is a root CA, this is actually longer than what might have been sent with PKIX (see the draft-ietf-dane-ops section 5.2). If however, that trust-anchor is issued by some intermediate CA, then the chain required to validate ala-DANE is shorter than the PKIX chain (even sans root CA). I don't know whether it is appropriate for the extension draft to discuss such potential (bandwidth) optimizations. The code that I wrote to validate DANE chains certainly ignores any certificates beyond the leaf with DANE-EE(3) and beyond the trust-anchor with DANE-TA(2). So the optimization opportunity is there, but we'd have to declare that a client sending the extension effectively commits to using DANE and forgoes the option of using the full PKIX chain (when a shorter chain suffices for DANE, i.e. the TLSA RRs contain exclusively certificate usage DANE-EE/DANE-TA not PKIX-EE/PKIX-TA). If the optimization is "blessed", then it might even be the case that at times the leaf certificate plus TLSA RRset with evidence is shorter than the PKIX chain (if the RRSIGS are EC-based). This brings us to another point, the server can't know whether its domain is even DNSSEC-signed in the eyes of the client. The client's supported DNSSEC signature algorithms are not sent in the client's extension. Whether the server "optimize" or not, there's not much point sending a pile of TLSA RRs, and associated RRSIG/DNSKEY/DS records, if some DS RRset needed to validate the response lists no algorithms supported by the client. It might make sense to change the client portion of the extension to send a list of the client's supported DNSSEC algorithm numbers. On the other hand, clients that hand-off the validation to the local resolver (as suggested in recent threads) might not always know which algorithms are supported by that resolver. That would have to be client configuration, or something the client can ask the resolver via an EDNS option of some sort. So lots of additional fun corner cases to mull over... -- Viktor. From nobody Wed Jul 29 11:22:34 2015 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 5BB5D1A9069 for ; Wed, 29 Jul 2015 11:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 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_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 yCu-PBQq1Z2r for ; Wed, 29 Jul 2015 11:22:33 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 141D61A905B for ; Wed, 29 Jul 2015 11:22:33 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id A4932584075; Wed, 29 Jul 2015 11:22:32 -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=erJpcf15SHr3cmPmVbrsXqx6d9c =; b=xXLueYxJme3WfjrMQMHrhJGN0GSzcqYm7uu9fiCc9GlOi4/LPzFGuM08Ek7 uM74FQJrmAzJaJrzB9IFDX9Uj49p/w1ME41Sz1nwsBnMHW0pPhv243CnfUAsCjWE 56ti0MsO74nq4/oOOTR5UIvuVL9CkaY9w60IbPZpYHZ42ctE= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTPA id 5DDF0584054; Wed, 29 Jul 2015 11:22:32 -0700 (PDT) Date: Wed, 29 Jul 2015 13:22:31 -0500 From: Nico Williams To: dane@ietf.org Message-ID: <20150729182230.GA24095@localhost> References: <20150728191705.GX4347@mournblade.imrryr.org> <20150728220520.GD3901@localhost> <20150728221557.GB4347@mournblade.imrryr.org> <55B81625.5010309@gmail.com> <20150728235752.GE4347@mournblade.imrryr.org> <55B81840.1030602@gmail.com> <20150729003557.GG4347@mournblade.imrryr.org> <55B82BB8.1060008@gmail.com> <20150729170127.GA20726@localhost> <20150729173848.GP4347@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150729173848.GP4347@mournblade.imrryr.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [dane] Stapling DNSSEC/DANE 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 Jul 2015 18:22:34 -0000 On Wed, Jul 29, 2015 at 05:38:48PM +0000, Viktor Dukhovni wrote: > On Wed, Jul 29, 2015 at 12:01:28PM -0500, Nico Williams wrote: > > If there's a latency hit, it will be when a sever has both, [...] > > This raises an interesting point. > > [...optimization discussion elided...] > > I don't know whether it is appropriate for the extension draft to > discuss such potential (bandwidth) optimizations. The code that > I wrote to validate DANE chains certainly ignores any certificates > beyond the leaf with DANE-EE(3) and beyond the trust-anchor with > DANE-TA(2). An "extension" may be where the stapled DANE data goes. That doesn't mean that it's an "extension" in the sense that you're thinking. Arguably this is core functionality for TLS. Still, I'd advise for specifying and implementing this optimization, but I'd make it OPTIONAL to implement. It's only an optimization. > So the optimization opportunity is there, but we'd have to declare > that a client sending the extension effectively commits to using > DANE and forgoes the option of using the full PKIX chain (when a > shorter chain suffices for DANE, i.e. the TLSA RRs contain exclusively > certificate usage DANE-EE/DANE-TA not PKIX-EE/PKIX-TA). Yes. > If the optimization is "blessed", then it might even be the case > that at times the leaf certificate plus TLSA RRset with evidence > is shorter than the PKIX chain (if the RRSIGS are EC-based). Quite likely. Plus there's no need for OCSP stapling, nor CRL checking. So in fact DANE stapling will be a net win. > This brings us to another point, the server can't know whether its > domain is even DNSSEC-signed in the eyes of the client. The client's > supported DNSSEC signature algorithms are not sent in the client's > extension. Whether the server "optimize" or not, there's not much > point sending a pile of TLSA RRs, and associated RRSIG/DNSKEY/DS > records, if some DS RRset needed to validate the response lists no > algorithms supported by the client. > > It might make sense to change the client portion of the extension > to send a list of the client's supported DNSSEC algorithm numbers. Agreed. > On the other hand, clients that hand-off the validation to the > local resolver (as suggested in recent threads) might not always > know which algorithms are supported by that resolver. That would > have to be client configuration, or something the client can ask > the resolver via an EDNS option of some sort. Good point. Nico -- From nobody Wed Jul 29 14:12:29 2015 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 761B31B2BE9 for ; Wed, 29 Jul 2015 14:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 5qzSdrm5AqI0 for ; Wed, 29 Jul 2015 14:12:27 -0700 (PDT) Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) (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 2413D1B2BE0 for ; Wed, 29 Jul 2015 14:12:27 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id E1A9A25CA2B4 for ; Wed, 29 Jul 2015 21:12:24 +0000 (UTC) X-Virus-Scanned: amavisd-new at rozanak.com Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntOXsGfX3N-h for ; Wed, 29 Jul 2015 23:12:24 +0200 (CEST) Received: from kopoli (p200300864F13D17A146D73D34B26E621.dip0.t-ipconnect.de [IPv6:2003:86:4f13:d17a:146d:73d3:4b26:e621]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id D9FCA25CA2A0 for ; Wed, 29 Jul 2015 23:12:23 +0200 (CEST) From: "Hosnieh Rafiee" To: Date: Wed, 29 Jul 2015 23:12:21 +0200 Message-ID: <010301d0ca43$42ac44b0$c804ce10$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdDKQ0IihVYck1CeTWuYkMf4S5mhlg== Content-Language: en-us Archived-At: Subject: [dane] PKI -> what you think? 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 Jul 2015 21:12:28 -0000 Hello All, I had a presentation in SDNRG about a PKI model. It is about how to use DANE and DNSSD in different use case scenarios. Please take a look and leave me your feedback on whether or not you think it is useful. https://www.ietf.org/proceedings/93/slides/slides-93-sdnrg-3.pdf Thanks, Best, Hosnieh From nobody Wed Jul 29 14:21:26 2015 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 477451B2C8F for ; Wed, 29 Jul 2015 14:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 34dNsE_Rq_rS for ; Wed, 29 Jul 2015 14:21:24 -0700 (PDT) Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) (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 3F4B41B2C92 for ; Wed, 29 Jul 2015 14:21:19 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id DA94925CA2B4 for ; Wed, 29 Jul 2015 21:21:17 +0000 (UTC) X-Virus-Scanned: amavisd-new at rozanak.com Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LqNqt0FzpH-e for ; Wed, 29 Jul 2015 23:21:17 +0200 (CEST) Received: from kopoli (p200300864F13D17A146D73D34B26E621.dip0.t-ipconnect.de [IPv6:2003:86:4f13:d17a:146d:73d3:4b26:e621]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id 0867325CA2A0 for ; Wed, 29 Jul 2015 23:21:16 +0200 (CEST) From: "Hosnieh Rafiee" To: Date: Wed, 29 Jul 2015 23:21:14 +0200 Message-ID: <011501d0ca44$80736f20$815a4d60$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdDKRH+bNp+EM82jS3SpkXUpbmzf4Q== Content-Language: en-us Archived-At: Subject: [dane] Followup...PKI -> what you think? 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 Jul 2015 21:21:25 -0000 Followup Sorry I guess I see everything as DNSSD... :-/ I meant DDNS ... -----Original Message----- From: Hosnieh Rafiee [mailto:ietf@rozanak.com] Sent: Wednesday, July 29, 2015 11:12 PM To: 'dane@ietf.org' Subject: PKI -> what you think? Hello All, I had a presentation in SDNRG about a PKI model. It is about how to use DANE and DNSSD in different use case scenarios. Please take a look and leave me your feedback on whether or not you think it is useful. https://www.ietf.org/proceedings/93/slides/slides-93-sdnrg-3.pdf Thanks, Best, Hosnieh From nobody Wed Jul 29 14:56:57 2015 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 2D6D61B2DE1 for ; Wed, 29 Jul 2015 14:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 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_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 ckcfVQYAtz7p for ; Wed, 29 Jul 2015 14:56:54 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9431B2DE0 for ; Wed, 29 Jul 2015 14:56:54 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id D434810077; Wed, 29 Jul 2015 14:56:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=lrIFwgZ5ixUTTr v8cW8+1obHGVs=; b=ul76z9lTEKsiOH08fxQZ1ozOtSAv4+s/xsOkt6FWmwwSF9 +m7jhCZqfLj9K3CPSJ+iGCJO0TTOtTp3GN/+/tsaaNqP62UEL6SHDGkUi80MMgck siPLkfdRFcHbE24VGh7bn4a6GeizTH5o9cB16DH2a972PcjQ4UqSRAkcdR9nc= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTPA id 71F7C10060; Wed, 29 Jul 2015 14:56:53 -0700 (PDT) Date: Wed, 29 Jul 2015 16:56:52 -0500 From: Nico Williams To: Paul Wouters Message-ID: <20150729215652.GB24095@localhost> References: <20150728181130.GB3901@localhost> <355779C9-2505-4CC1-9707-7D83482A4403@nohats.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <355779C9-2505-4CC1-9707-7D83482A4403@nohats.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Stapling DNSSEC/DANE 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 Jul 2015 21:56:55 -0000 On Wed, Jul 29, 2015 at 08:45:03AM +0200, Paul Wouters wrote: > Sounds familiar :) > > https://tools.ietf.org/html/draft-ietf-dnsop-edns-chain-query-02 Excellent. Now I don't have to write that :) Now all we need is a document somewhere explaining how to use DNS (to the local caching resolver daemon) as an API. That needn't be an IETF document, of course. Nico -- From nobody Thu Jul 30 00:17:58 2015 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 40C2A1A8733 for ; Thu, 30 Jul 2015 00:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=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 1o-XjUNtXeQ0 for ; Thu, 30 Jul 2015 00:17:56 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1A741A8731 for ; Thu, 30 Jul 2015 00:17:55 -0700 (PDT) Received: by wibud3 with SMTP id ud3so9019154wib.1 for ; Thu, 30 Jul 2015 00:17:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=72QB1mOBAsHPyPsl9IrjICEwqnc3S4dzgRr75AwE03Y=; b=KKWHo+Qeexniv3ZAlAeyaWnkBwXIY9gbYUOvcATblKdpIDWGOgeL8x5leRrFAF4DIN R/7qqIpR0ixbZsbpWEPfOPL8S6K/bPgLNfiDgi/uuXGwPHBduquH86E1tKrLCyLmwQKD gLsoUGn/tQIl+M5a2WdNSyG5o9uoD/E7eo5Rca6jofLTUxlZF/3NHoqKOeznCTAs9g/a 2vviu6lkiTTjR3uRdfFoAPm+yfmP2lgsXrTCeCMx+gU1y9HSs+rd66oe8AFlJFMpq2Bz Y/nzaTKi1irTT4obWDBM8DzzBKIdFG+oPmXxK+jR/PCPPr7j0hLXE+QVognoPWAXo09U D/xQ== MIME-Version: 1.0 X-Received: by 10.194.60.226 with SMTP id k2mr81472013wjr.10.1438240674738; Thu, 30 Jul 2015 00:17:54 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.28.1.79 with HTTP; Thu, 30 Jul 2015 00:17:54 -0700 (PDT) In-Reply-To: <20150729170504.GN4347@mournblade.imrryr.org> References: <20150729151728.549.85266.idtracker@ietfa.amsl.com> <20150729170504.GN4347@mournblade.imrryr.org> Date: Thu, 30 Jul 2015 09:17:54 +0200 X-Google-Sender-Auth: 9OJb41_mJneADFnTZzz74ABgSRA Message-ID: From: Barry Leiba To: dane@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [dane] Barry Leiba's No Objection on draft-ietf-dane-ops-14: (with COMMENT) 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, 30 Jul 2015 07:17:57 -0000 Hi, Viktor; thanks for the quick response, and thanks for making the changes. >> -- Section 4 -- >> >> Protocol designers need to carefully consider which set of DANE >> certificate usages to support. >> >> I'm not sure why this (and the next sentence) is referring to "protocol >> designers". Is this not aimed at implementation/deployment choices? If >> that's not correct, who are the targets for this advice? > > This should likely say "application protocol designers". The point > being that the use of DANE TLSA RRs in a particular application > (as with e.g. SMTP) can be defined (more specifically than in > RFC6698 and this draft) by an application-specific standard. Ahhhh, of course; I get it now. Thanks for the explanation. Yes, maybe you can say "designers of DANE profiles", or "designers of DANE applications", or some such. Please pick the correct wording. >> I also find this section to be rather hard to follow -- I can't clearly >> figure out what the advice really is. Can you do a little reorganization >> here, separating the advice out from the explanation of why? I don't >> care whether you put the explanation first or the advice first, but it >> would help to have one paragraph that says, clearly and without fuss, >> what the recommendation is. This applies to the subsections as well. > > Will try to clarify, this will take more time. Of course, and many thanks for considering it. > Should the two > smaller changes above be pushed as -15, while section 4 is polished? I would say yes (revisions are cheap), but you should check with your responsible AD. Barry From nobody Thu Jul 30 03:31:27 2015 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 3A31E1A039B for ; Thu, 30 Jul 2015 03:31:27 -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 liem_NB78ijk for ; Thu, 30 Jul 2015 03:31:26 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C255E1ACCE9 for ; Thu, 30 Jul 2015 03:29:54 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mhp013QxYz3Hd for ; Thu, 30 Jul 2015 12:29:53 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=UsUxeAVG X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id ldldrHMyBwAk for ; Thu, 30 Jul 2015 12:29:52 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Thu, 30 Jul 2015 12:29:52 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D7B12800AD for ; Thu, 30 Jul 2015 06:29:51 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1438252191; bh=FIgO7I5GD9e1IoSs5YHx7cZltgMAXUn85565pNsa1Fg=; h=Date:From:To:Subject:In-Reply-To:References; b=UsUxeAVGOZ8at6OHZ6KHnz89bOhvHjL0XD1yP3Zg996d7ac4PxLIcsc5yAbWdwigJ a5IE0D8eHbnpnH2PS01M7nrb6PE/7x09KjLrlMjpkxYBIKrvs2lcP+bqQXZuMIqGTC 5Vkgo8VMIMK7XxHowZLUet/qeu+fHDzY435V29fs= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t6UATpDC003462 for ; Thu, 30 Jul 2015 06:29:51 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Thu, 30 Jul 2015 06:29:51 -0400 (EDT) From: Paul Wouters To: dane@ietf.org In-Reply-To: <20150728194641.GZ4347@mournblade.imrryr.org> Message-ID: References: <20150728194641.GZ4347@mournblade.imrryr.org> User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dane] [OT] Deployment news (Germany is plowing ahead) 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, 30 Jul 2015 10:31:27 -0000 On Tue, 28 Jul 2015, Viktor Dukhovni wrote: > I've mentioned before that much of the deployment (> 30%) for DANE > SMTP is in Germany. Today something unprecedented happened. The OPENPGPKEY deployment/coders also have a strong German component. Paul From nobody Thu Jul 30 05:31:13 2015 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 4137B1A8823 for ; Thu, 30 Jul 2015 05:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 cIFbqFvoBtc0 for ; Thu, 30 Jul 2015 05:31:05 -0700 (PDT) Received: from smtp84.iad3a.emailsrvr.com (smtp84.iad3a.emailsrvr.com [173.203.187.84]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 616F41A873A for ; Thu, 30 Jul 2015 05:31:05 -0700 (PDT) Received: from smtp11.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp11.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 85B53100450; Thu, 30 Jul 2015 08:31:04 -0400 (EDT) Received: by smtp11.relay.iad3a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 3A8B6100438; Thu, 30 Jul 2015 08:31:03 -0400 (EDT) X-Sender-Id: ogud@ogud.com Received: from [10.20.30.43] (pool-173-66-187-177.washdc.fios.verizon.net [173.66.187.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.4.2); Thu, 30 Jul 2015 12:31:04 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_0CD08E1D-F807-4434-83A1-8CEFC38CDA5F" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Olafur Gudmundsson In-Reply-To: Date: Thu, 30 Jul 2015 08:31:02 -0400 Message-Id: <7A34D467-6098-4309-97B3-E654F24B0666@ogud.com> References: To: "Wiley, Glen" X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "dane@ietf.org" Subject: Re: [dane] clarify, are SMIMEA and OPENPGPKEY drafts experimental? 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, 30 Jul 2015 12:31:11 -0000 --Apple-Mail=_0CD08E1D-F807-4434-83A1-8CEFC38CDA5F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 28, 2015, at 8:11 AM, Wiley, Glen wrote: >=20 > Was a decision taken to make the SMIMEA and OPENPGPKEY drafts = experimental rather than standards track? > =E2=80=94=20 The chairs and AD=E2=80=99s are worried that Sandards track is a = =E2=80=9Cbridge to far=E2=80=9D at this point.=20 Thus going for experimental is simpler and quicker. Document can be reclassified at later point once the experiment is a = success.=20 Olafur --Apple-Mail=_0CD08E1D-F807-4434-83A1-8CEFC38CDA5F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jul 28, 2015, at 8:11 AM, Wiley, Glen <gwiley@verisign.com>= wrote:

Was a decision taken to make the SMIMEA and OPENPGPKEY = drafts experimental rather than standards track?
=E2=80=94 
=
The chairs and AD=E2=80=99s are worried that = Sandards track is a =E2=80=9Cbridge to far=E2=80=9D at this = point. 
Thus going for experimental is simpler and = quicker.
Document can be reclassified at later point once the = experiment is a success. 

Olafur

= --Apple-Mail=_0CD08E1D-F807-4434-83A1-8CEFC38CDA5F-- From nobody Thu Jul 30 13:30:27 2015 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 C6E851ACE9E; Thu, 30 Jul 2015 13:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 ys3GFmh6fYVH; Thu, 30 Jul 2015 13:30:23 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 BDBC31ACE77; Thu, 30 Jul 2015 13:30:22 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t6UKU4PL024041 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 30 Jul 2015 22:30:05 +0200 From: Simon Josefsson To: Paul Wouters References: <87si8dagiz.fsf@vigenere.g10code.de> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:150730:ogud@ogud.com::BKQTMAmbI0+O6qYE:4u7f X-Hashcash: 1:22:150730:paul@nohats.ca::O5LAUn6/NBOzLkEr:Jjy6 X-Hashcash: 1:22:150730:wk@gnupg.org::REuC5UBXS/4ET53T:MoJq X-Hashcash: 1:22:150730:openpgp@ietf.org::Y++BJQc0ysdtvZAf:Mt3U X-Hashcash: 1:22:150730:dane@ietf.org::+bKdhcCx134st6Xs:Nvac X-Hashcash: 1:22:150730:phill@hallambaker.com::fRCIlYoSkT55G9U2:DdO+ Date: Thu, 30 Jul 2015 22:30:03 +0200 In-Reply-To: (Paul Wouters's message of "Sat, 25 Jul 2015 08:19:04 -0400 (EDT)") Message-ID: <87fv45v16c.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: Werner Koch , IETF OpenPGP , Phillip Hallam-Baker , dane WG list Subject: Re: [dane] The DANE draft 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, 30 Jul 2015 20:30:24 -0000 --=-=-= Content-Type: text/plain Paul Wouters writes: >> Here are some thoughts, anyway: >> >> - Why a new DNS record despite that the CERT type has PGP support for >> 9 years now (RFC-4398). >> >> The argument for a new record is that this makes parsing easier >> because there is no need to loop over the record's sub-types. I do >> not consider it a valid argument because there is a need to loop >> anyway because there may be several DANE records for the same key. >> Adding an extra loop over the sub-types is a non-brainer and the >> selection logic to find the best matching record will be the same. > > Using subtypes for DNS is something the DNS people in general have > concluded to be a wrong idea. As stated before, even Olafur who is one > of the authors of the CERT RRtype advised us not to use CERT (or > subtyping in general) Then I believe that community should attempt to move RFC 2538/4398 to historic. I don't believe there is sufficient consensus for doing that -- there is good use of CERT records already, although limited. > Additionally, because the CERT record is a meta-container record, > support for CERT is not good because to properly parse it you need > all of openpgp and all of x509 and all of what other subtypes would > be added later on. So instead of implementing CERT records partially, > many DNS implementations just did not bother with it at all. I disagree -- CERT can be implemented without understanding any of OpenPGP or X.509, and it is implemented by DNS software already. >> GnuPG has support for such CERT records including a script to create >> them also for about 9 years. It is not widely used because most users >> have no way to add records to their zone - that is the same problem >> for DANE of course. > > CERT wasn't widely used because frankly pgp is not widely used. Also, > CERT without DNSSEC makes no sense This is false -- CERT makes a lot of sense without DNSSEC, as OpenPGP keys can be verified through the web of trust. I don't believe comparing deployment sizes should be a deciding factor in this context, but I disagree with your notion that OpenPGP is not widely used. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJVuolLAAoJEIYLf7sy+BGdGOAH/29XBaHqu5JT5gEoX899dsdA dbvIalfTQYxjZRDAuS8sX7f/q+Sq9H7HlsbhFcWccOg0C0YplemAOOBqLzSIsta7 //jq3FuA+7ghbG0w+JfnbVy8FdS47eWjBw/AzxnMUvRuw0mOfTzoZHXchPIQ1olb pqQ4usg4oheL6G93NN08Z2ktkpCB1+QBpP1FWiOIkEh7Gk49Lz8/o9+wuw3EpveY KAI2yENmh2IVPt6srYdxcr0itTLcjCZE9oCnVhIVLIIS8MJVfwfHOqR6Oh+9o7l3 Al+QehBihbi6pPxBjHyW8UaC4hrCcHL2zUKi1ZbVZZwsJWjRSmJUrUh6hJBPtXk= =YrH9 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jul 30 22:58:58 2015 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 D21DE1B31D4 for ; Thu, 30 Jul 2015 22:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.698 X-Spam-Level: X-Spam-Status: No, score=0.698 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 Hi4hpbkLMm_B for ; Thu, 30 Jul 2015 22:58:55 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E925A1B3122 for ; Thu, 30 Jul 2015 22:58:54 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id CF452C40462 for ; Fri, 31 Jul 2015 00:58:52 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1438322332; bh=tvOnj1JMUKY0LZJxwLPcruxa1FaPeR2kPXWoic/YfPs=; h=From:To:Subject:Date:In-Reply-To:References:From; b=WxzV0M8ty8DYq1xvt4lGuE6xtI4NacnpjkjrZ6HzCzE8rzryWsMY6H9uAQdDjz/T9 jGXyehM/0MS+Py+kB96Lkm76PF5ziLHCUTsKLIDRc0kqEZWqBlkxe6fAuczrQQRB0f MciduyAo0Z/OCfiwp2fXKsCqWPL5nWSFUMxCRNA0= From: Scott Kitterman To: dane@ietf.org Date: Fri, 31 Jul 2015 01:58:51 -0400 Message-ID: <2002939.v2nzOL3up3@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-58-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <7A34D467-6098-4309-97B3-E654F24B0666@ogud.com> References: <7A34D467-6098-4309-97B3-E654F24B0666@ogud.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Archived-At: Subject: Re: [dane] clarify, are SMIMEA and OPENPGPKEY drafts experimental? 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 Jul 2015 05:58:57 -0000 On Thursday, July 30, 2015 08:31:02 AM Olafur Gudmundsson wrote: > > On Jul 28, 2015, at 8:11 AM, Wiley, Glen wrot= e: > >=20 > > Was a decision taken to make the SMIMEA and OPENPGPKEY drafts exper= imental > > rather than standards track? =E2=80=94 >=20 > The chairs and AD=E2=80=99s are worried that Sandards track is a =E2=80= =9Cbridge to far=E2=80=9D at > this point. Thus going for experimental is simpler and quicker. > Document can be reclassified at later point once the experiment is a > success. Based on previous experience, I think it's valuable to define, up front= , what=20 the experiment is and what success criteria are. What is the experimen= t=20 that's being conducted? Scott K From nobody Fri Jul 31 07:26:48 2015 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 343031A88FF for ; Fri, 31 Jul 2015 07:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 KnUNOUxncjfm for ; Fri, 31 Jul 2015 07:26:45 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 391271A88D2 for ; Fri, 31 Jul 2015 07:26:45 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BZI53382; Fri, 31 Jul 2015 14:26:43 +0000 (GMT) Received: from LHREML504-MBS.china.huawei.com ([10.125.30.107]) by lhreml403-hub.china.huawei.com ([::1]) with mapi id 14.03.0235.001; Fri, 31 Jul 2015 15:26:40 +0100 From: Hosnieh Rafiee To: "dane@ietf.org" Thread-Topic: OPENPGP --- Review draft: draft-ietf-dane-openpgpkey-03 Thread-Index: AQHQy5zqRXSD1+Ch2E+i/gyA7b5ZfA== Date: Fri, 31 Jul 2015 14:26:40 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7015D2DD4@lhreml504-mbs> References: <1437580854.052529954@apps.rackspace.com> In-Reply-To: <1437580854.052529954@apps.rackspace.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.82.134] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [dane] OPENPGP --- Review draft: draft-ietf-dane-openpgpkey-03 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 Jul 2015 14:26:48 -0000 SGksDQoNCkkgaGF2ZSByZXZpZXdlZCB0aGlzIGRyYWZ0LiBJIGhhdmUgc29tZSBxdWVzdGlvbnMg YW5kIGZlZWRiYWNrcy4uLg0KDQo+VGhlIHNlbnNlIG9mIHRoZSByb29tIGluIHRoZSBJRVRGLTkz IG1lZXRpbmcgd2FzIHRvIGRvIGRvIGEgQkFTRTMyIGVuY29kaW5nIG9mIGxvY2FsIHBhcnQgd2l0 aCA2MCBjaGFyYWN0ZXIgbGFiZWxzLMKgDQpzaG9ydGVzdCBsYWJlbCBpcyB0aGUgbGVmdCBtb3N0 IGxhYmVsLsKgDQoNCkkgd291bGQgc2VlIHRoZSB1c2Ugb2YgYmFzZTMyICh3aXRob3V0IGV4dHJh IGltcHJvdmVtZW50IHRlY2huaXF1ZXMpIGFzIGEgc2VjdXJpdHkgcmlzay4gVGhpcyBpcyBiZWNh dXNlLCBpdCBkZWNyZWFzZXMgdGhlIGVudHJvcHkgb2YgU0hBMjU2IGhhc2ggZnVuY3Rpb24gKEFz IGZhciBhcyBJIGtub3cgYmFzZWQgb24gbXkgZXhwZXJpbWVudCB3aXRoIFNIQTI1NiwgU0hBMjU2 IGFyZSBjYXNlIHNlbnNpdGl2ZSkgd2hpY2ggcmVzdWx0IGluIHBvc3NpYmxlIGF0dGFja3Mgb24g dXNlcm5hbWVzIGFuZCBmb3JnaW5nIHVzZXJuYW1lcy4gDQoNClVubGVzcyB0aGV5IHVzZSB0aGUg c2FtZSB0ZWNobmlxdWVzIHRoYXQgaXMgdXNlZCBmb3IgRE5TY3VydmUga2V5IGhhc2hpbmcuIDwg aHR0cHM6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvRE5TQ3VydmUgPiAuIEJ1dCBpZiB0aGV5IHVz ZSB0aGlzIHRlY2huaXF1ZSB0aGVuIHRoZSBzaXplIG9mIHRoZSBtZXNzYWdlIGlzIG5vIGxvbmdl ciAzMiBiZWNhdXNlIGluIHRoYXQgdGVjaG5pcXVlIGZvciBjaGFyYWN0ZXJzIHRoYXQgZG9lcyBu b3QgaGF2ZSBhbnkgYmFzZTMyIHZhbHVlLCB0aGV5IHVzZSB0aGUgY29tYmluYXRpb24gb2YgY2hh cmFjdGVycyB0aGF0IGFscmVhZHkgZXhpc3QgaW4gYmFzZTMyLiBBcyBhIHNpbXBsZSBleGFtcGxl LCBmb3IgbG93ZXIgJ2EnIHRoYXQgaXMgbm90IGluIGJhc2UzMiwgdGhleSB1c2UgJ0FCJy4gDQoN CkluIG90aGVyIHdvcmQsIHRoZSBzaXplIG9mIHRoZSAyOCBieXRlcyBoYXNoIHZhbHVlIGlzIG5v IGxvbmdlciAzMiwgYnV0IGl0IGlzIGFyb3VuZCA1MS4gQnV0IGlmIHRoZSB0aGUgc2FtZSB0ZWNo bmlxdWUgYXMgRE5TY3VydmUgaXMgdXNlZCwgaXQgaXMgYmV0dGVyIHRoYW4gYmFzZTY0IGJlY2F1 c2UgYmFzZTY0IGFsc28gZG9lc24ndCBzdXBwb3J0IGFsbCBjaGFyYWN0ZXJzIHRoYXQgZXhpc3Rz IGluIHRoZSByZXN1bHQgb2YgU0hBMjU2LiANCg0KDQpGdXJ0aGVybW9yZSwgSSBhbHNvIGRvIG5v dCB1bmRlcnN0YW5kIHRoZSByZWFzb24gd2h5IGluIHNlY3Rpb24gMyB0aGV5IGFyZSBjb252ZXJ0 aW5nIHRoZSByZXN1bHQgdG8gbG93ZXJjYXNlLiBUaGlzIGRvZXNuJ3QgYWZmZWN0IHRoZSBTSEEy NTYgcmVzdWx0LiBTaW5jZSB0aGUgdXNlcm5hbWUgaW4gZW1haWwgaXMgYWx3YXlzIGxvd2VyY2Fz ZSwgaXQgbWFrZSBzZW5zZSB0byBkbyB0aGlzIGxvd2VyY2FzZSBwcm9jZXNzIGJlZm9yZSBlbmNv ZGluZyB0byBVVEYtOCBiZWNhdXNlIHRoZSBhc3N1bXB0aW9uIGlzIHRoYXQgdGhlIGVtYWlsIGFk ZHJlc3MgaXMgYWx3YXlzIGxvd2VyY2FzZS4gVGhlcmVmb3JlLCBjb252ZXJ0aW5nIFVURi04IHJl c3VsdCB0byBsb3dlcmNhc2UganVzdCBkZWNyZWFzZSB0aGUgZW50cm9weSBvZiBTSEEyNTYgZnVu Y3Rpb24uIFRoZW4gYWxsb3dzIGF0dGFja2VyIHRvIGVhc2llciBwcm9jZWVkIHdpdGggZGljdGlv bmFyeSBhdHRhY2sgYmVjYXVzZSBpdCBjYW4ganVzdCBza2lwIG1hbnkgaW5wdXRzIHZhbHVlcyBm b3IgU0hBMjU2LiAgVGhpcyBtZWFucywgd2l0aCB0aGlzIGFwcHJvYWNoIHRoZSBwcm9iYWJpbGl0 eSBvZiBjb2xsaXNpb24gZm9yIFNIQTI1NiBpbmNyZWFzZXMuDQogDQpTbywgaW4gbXkgb3Bpbmlv biwgYmVmb3JlIGhhdmluZyBhbnkgZGVjaXNpb24sIHRoZSBhdXRob3JzIG5lZWQgdG8gYnJpbmcg c29tZSBhbmFseXNpcyBvZiBiYXNlMzIgYW5kIGJhc2U2NCBhbmQgbG93ZXJjYXNlLCB1cHBlcmNh c2UgYW5kIFNIQTI1NiBhbmQgc2hhcmUgdGhlIGFuYWx5c2lzIHNvIHRoYXQgdG8gYmUgY2xlYXIg aG93IG11Y2ggc2VjdXJpdHkgcmlzayBpdCBtaWdodCBwcm92aWRlIGZvciBlbWFpbCB1c2Vycy4N CiANCjxzbmlwPg0KDQpzaG91bGQgYWxyZWFkeSBiZSBlbmNvZGVkIGluIFVURi04IChvciBpdHMg c3Vic2V0DQogICAgICBBU0NJSSkuICBJZiBpdCBpcyB3cml0dGVuIGluIGFub3RoZXIgZW5jb2Rp bmcgaXQgc2hvdWxkIGJlDQogICAgICBjb252ZXJ0ZWQgdG8gVVRGLTguICBOZXh0LCBpdCBpcyB0 dXJuZWQgaW50byBsb3dlcmNhc2UgYW5kIGhhc2hlZA0KICAgICAgdXNpbmcgdGhlIFNIQTItMjU2 IFtSRkM1NzU0XSBhbGdvcml0aG0sDQo8L3NuaXA+DQoNClRoYW5rcywNCkJlc3QsDQpIb3NuaWVo IA0K From nobody Fri Jul 31 07:31:42 2015 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 644011A8927 for ; Fri, 31 Jul 2015 07:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 1ekrgOg74hPt for ; Fri, 31 Jul 2015 07:31:35 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B49D1A892A for ; Fri, 31 Jul 2015 07:31:29 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVS36091; Fri, 31 Jul 2015 14:31:27 +0000 (GMT) Received: from LHREML504-MBS.china.huawei.com ([10.125.30.107]) by lhreml402-hub.china.huawei.com ([10.201.5.241]) with mapi id 14.03.0235.001; Fri, 31 Jul 2015 15:31:22 +0100 From: Hosnieh Rafiee To: "dane@ietf.org" Thread-Topic: followup: OPENPGP --- Review draft: draft-ietf-dane-openpgpkey-03 Thread-Index: AQHQy52S6JkwMJFtq0WUQ5QNNsflyg== Date: Fri, 31 Jul 2015 14:31:22 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7015D2DF4@lhreml504-mbs> References: <1437580854.052529954@apps.rackspace.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.82.134] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [dane] followup: OPENPGP --- Review draft: draft-ietf-dane-openpgpkey-03 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 Jul 2015 14:31:40 -0000 Rm9sbG93dXANCkhvd2V2ZXIsIGEgZmV3IEROUyBzZXJ2ZXJzIHN1cHBvcnQgMHgyMC1CaXQgRW5j b2RpbmcsIGJ1dCB0aGlzIGFwcHJvYWNoIGlzIG5vdCBzdXBwb3J0ZWQgYnkgYmFzZTMyIHdoaWNo IGhhcyBpdHMgb3duIHNlY3VyaXR5IHJpc2suIA0KDQogVW5sZXNzLi4gd2UgZ2V0IGJhY2sgdG8g dGhlIHRlY2huaXF1ZSBmb3IgRE5TY3VydmUgdG8gYmUgYWJsZSB0byBkaWZmZXJlbnRpYXRlIGxv d2VyY2FzZSBhbmQgdXBwZXJjYXNlIGNoYXJhY3RlcnMgaW4gDQoNCg0KPCBodHRwOi8vY291cnNl cy5pc2kuamh1LmVkdS9uZXRzZWMvcGFwZXJzL2luY3JlYXNlZF9kbnNfcmVzaXN0YW5jZS5wZGY+ DQoNClRoYW5rcywNCkJlc3QsDQpIb3NuaWVoDQo= From nobody Fri Jul 31 08:31:31 2015 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 9931A1B2BCA for ; Fri, 31 Jul 2015 08:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.195 X-Spam-Level: X-Spam-Status: No, score=0.195 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 YOPKTqpdRy2d for ; Fri, 31 Jul 2015 08:31:27 -0700 (PDT) Received: from shannon.7bits.nl (shannon.7bits.nl [89.188.0.40]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6D101B2BC3 for ; Fri, 31 Jul 2015 08:31:26 -0700 (PDT) Received: from [192.168.137.1] (e163253.upc-e.chello.nl [213.93.163.253]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: peter) by shannon.7bits.nl (Postfix) with ESMTPSA id 980A4C1B55; Fri, 31 Jul 2015 17:31:23 +0200 (CEST) From: "Peter van Dijk" To: "dane@ietf.org" Date: Fri, 31 Jul 2015 17:31:22 +0200 Message-ID: <4FEE7B8C-F482-4FB8-824E-26B26D30BAD7@powerdns.com> In-Reply-To: <814D0BFB77D95844A01CA29B44CBF8A7015D2DD4@lhreml504-mbs> References: <1437580854.052529954@apps.rackspace.com> <814D0BFB77D95844A01CA29B44CBF8A7015D2DD4@lhreml504-mbs> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.1r5084) Archived-At: Subject: Re: [dane] OPENPGP --- Review draft: draft-ietf-dane-openpgpkey-03 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 Jul 2015 15:31:28 -0000 Hello Hosnieh, On 31 Jul 2015, at 16:26, Hosnieh Rafiee wrote: > Hi, > > I have reviewed this draft. I have some questions and feedbacks... > >> The sense of the room in the IETF-93 meeting was to do do a BASE32 >> encoding of local part with 60 character labels,  >> shortest label is the left most label.  > > I would see the use of base32 (without extra improvement techniques) > as a security risk. This is because, it decreases the entropy of > SHA256 hash function (As far as I know based on my experiment with > SHA256, SHA256 are case sensitive) which result in possible attacks on > usernames and forging usernames. The planned/suggested use of base32 is *instead of* SHA256. Thus, entropy is not a topic - as there is no hashing. (That said, encoding a SHA256 hash as base32 would not lose entropy. Treating a base64-encoding of SHA256 as something base32-like would lose entropy, but that’s a terrible idea for several reasons and nobody is suggesting it). Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ From nobody Fri Jul 31 09:06:45 2015 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 2BA521B2DAA for ; Fri, 31 Jul 2015 09:06:44 -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 KmQ_X_BzMrQ5 for ; Fri, 31 Jul 2015 09:06:41 -0700 (PDT) Received: from mail-ob0-f171.google.com (mail-ob0-f171.google.com [209.85.214.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E0391B2D76 for ; Fri, 31 Jul 2015 09:06:41 -0700 (PDT) Received: by obbop1 with SMTP id op1so57273321obb.2 for ; Fri, 31 Jul 2015 09:06:40 -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=FOr7BA5sJKsqbYKi12hOMpKiOEJbwMHOr/YWXUX3vIA=; b=GdpZqeOzFqt5NtoS2CZEL3qc5XN08meFSTI1ON89e2pLGXHztgUKD7NaJE5mHJh8ER gHh4AB/5PUip5P6mhpSJ0hH9YRkzvQh7ta9BKjBXcBEeCmS4hEIWC+BsvycKb18fB7Ut VjLoVWlIY9FCbYixZYqMUJaYtzOcvus1EHuMcZOYBazzNPrAIjCE+DRICt5BxL6Lcsyp sXHBwKxiqCxuU/Wk3r6C2ehRRpqqAccfM5krxi1sn1Bwi1PjvxIhFfIEBLyfcQIUAvIp XgWKPEh9/8K4chsQMnUeiPQEKlnZNbfHAzcX62GzNldp80NEcKY83OywD1x/EjRkDNBx 0K2A== X-Gm-Message-State: ALoCoQk1/yXbX7QlDok/UWQr/AWpwIVPslc+vn0QNtC+jwc1IyOUuxDx2PL8znAxh/ytkL63u1ds MIME-Version: 1.0 X-Received: by 10.60.35.98 with SMTP id g2mr4087532oej.6.1438358800789; Fri, 31 Jul 2015 09:06:40 -0700 (PDT) Received: by 10.202.232.1 with HTTP; Fri, 31 Jul 2015 09:06:40 -0700 (PDT) In-Reply-To: <2002939.v2nzOL3up3@kitterma-e6430> References: <7A34D467-6098-4309-97B3-E654F24B0666@ogud.com> <2002939.v2nzOL3up3@kitterma-e6430> Date: Fri, 31 Jul 2015 12:06:40 -0400 Message-ID: From: Warren Kumari To: Scott Kitterman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "" Subject: Re: [dane] clarify, are SMIMEA and OPENPGPKEY drafts experimental? 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 Jul 2015 16:06:44 -0000 On Fri, Jul 31, 2015 at 1:58 AM, Scott Kitterman wro= te: > On Thursday, July 30, 2015 08:31:02 AM Olafur Gudmundsson wrote: >> > On Jul 28, 2015, at 8:11 AM, Wiley, Glen wrote: >> > >> > Was a decision taken to make the SMIMEA and OPENPGPKEY drafts experime= ntal >> > rather than standards track? =E2=80=94 >> >> The chairs and AD=E2=80=99s are worried that Sandards track is a =E2=80= =9Cbridge to far=E2=80=9D at >> this point. Thus going for experimental is simpler and quicker. >> Document can be reclassified at later point once the experiment is a >> success. > > Based on previous experience, I think it's valuable to define, up front, = what > the experiment is and what success criteria are. What is the experiment > that's being conducted? > These drafts contain an untested email address local part "encoding", and expose email address information in the DNS. We have had a number of discussions on this, including people involved in the mail community, the draft authors and our AD on the correct track for these documents (for some of these discussions, please see the discussions at IETF 92 (Dallas) - the minutes capture some of it, the recordings more) and it was felt that Experimental is most appropriate. The experiment is: Does the local part "encoding" work well in practice, and will organizations and individuals be willing to publish email addresses info in the DNS? We do not have objective criteria for success, rather we wish to launch this with the understanding that the encoding may change in the future if issues are discovered. W > Scott K > > _______________________________________________ > 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 Fri Jul 31 10:13:43 2015 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 2944A1B2E9D for ; Fri, 31 Jul 2015 10:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 P4rMJPoE4xjJ for ; Fri, 31 Jul 2015 10:13:39 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BB551B2E9E for ; Fri, 31 Jul 2015 10:13:38 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVS47660; Fri, 31 Jul 2015 17:13:37 +0000 (GMT) Received: from LHREML504-MBS.china.huawei.com ([10.125.30.107]) by lhreml406-hub.china.huawei.com ([10.201.5.243]) with mapi id 14.03.0235.001; Fri, 31 Jul 2015 18:13:32 +0100 From: Hosnieh Rafiee To: "dane@ietf.org" Thread-Topic: [dane] OPENPGP --- Review draft: draft-ietf-dane-openpgpkey-03 Thread-Index: AQHQy6YZHi0LpF66HkaKyj72OSMYFZ31z+ag Date: Fri, 31 Jul 2015 17:13:31 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7015D2F28@lhreml504-mbs> References: <1437580854.052529954@apps.rackspace.com> <814D0BFB77D95844A01CA29B44CBF8A7015D2DD4@lhreml504-mbs> <4FEE7B8C-F482-4FB8-824E-26B26D30BAD7@powerdns.com> In-Reply-To: <4FEE7B8C-F482-4FB8-824E-26B26D30BAD7@powerdns.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.218.98] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [dane] OPENPGP --- Review draft: draft-ietf-dane-openpgpkey-03 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 Jul 2015 17:13:41 -0000 SGVsbG8gUGV0ZXIsDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogZGFu ZSBbbWFpbHRvOmRhbmUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFBldGVyIHZhbiBE aWprDQo+IE9uIDMxIEp1bCAyMDE1LCBhdCAxNjoyNiwgSG9zbmllaCBSYWZpZWUgd3JvdGU6DQoN Cj4gPj4gVGhlIHNlbnNlIG9mIHRoZSByb29tIGluIHRoZSBJRVRGLTkzIG1lZXRpbmcgd2FzIHRv IGRvIGRvIGEgQkFTRTMyDQo+ID4+IGVuY29kaW5nIG9mIGxvY2FsIHBhcnQgd2l0aCA2MCBjaGFy YWN0ZXIgbGFiZWxzLCBzaG9ydGVzdCBsYWJlbCBpcw0KPiA+PiB0aGUgbGVmdCBtb3N0IGxhYmVs Lg0KPiA+DQo+ID4gSSB3b3VsZCBzZWUgdGhlIHVzZSBvZiBiYXNlMzIgKHdpdGhvdXQgZXh0cmEg aW1wcm92ZW1lbnQgdGVjaG5pcXVlcykNCj4gPiBhcyBhIHNlY3VyaXR5IHJpc2suIFRoaXMgaXMg YmVjYXVzZSwgaXQgZGVjcmVhc2VzIHRoZSBlbnRyb3B5IG9mDQo+ID4gU0hBMjU2IGhhc2ggZnVu Y3Rpb24gKEFzIGZhciBhcyBJIGtub3cgYmFzZWQgb24gbXkgZXhwZXJpbWVudCB3aXRoDQo+ID4g U0hBMjU2LCBTSEEyNTYgYXJlIGNhc2Ugc2Vuc2l0aXZlKSB3aGljaCByZXN1bHQgaW4gcG9zc2li bGUgYXR0YWNrcw0KPiBvbg0KPiA+IHVzZXJuYW1lcyBhbmQgZm9yZ2luZyB1c2VybmFtZXMuDQo+ IA0KPiBUaGUgcGxhbm5lZC9zdWdnZXN0ZWQgdXNlIG9mIGJhc2UzMiBpcyAqaW5zdGVhZCBvZiog U0hBMjU2LiBUaHVzLA0KPiBlbnRyb3B5IGlzIG5vdCBhIHRvcGljIC0gYXMgdGhlcmUgaXMgbm8g aGFzaGluZy4NCj4gDQo+IChUaGF0IHNhaWQsIGVuY29kaW5nIGEgU0hBMjU2IGhhc2ggYXMgYmFz ZTMyIHdvdWxkIG5vdCBsb3NlIGVudHJvcHkuDQo+IFRyZWF0aW5nIGEgYmFzZTY0LWVuY29kaW5n IG9mIFNIQTI1NiBhcyBzb21ldGhpbmcgYmFzZTMyLWxpa2Ugd291bGQNCj4gbG9zZSBlbnRyb3B5 LCBidXQgdGhhdOKAmXMgYSB0ZXJyaWJsZSBpZGVhIGZvciBzZXZlcmFsIHJlYXNvbnMgYW5kIG5v Ym9keQ0KPiBpcyBzdWdnZXN0aW5nIGl0KS4NCj4gDQoNCk9NRy4uLiBJTU8sIGluIHRoaXMgY2Fz ZSB0aGUgYXBwcm9hY2ggd2lsbCBzYWNyaWZpY2UgdXNlcnMnIHByaXZhY3kuIElzIHRoZXJlIGFu eSB0aG91Z2h0IG9mIHNwYW1zIHRoYXQgdGhlIGVtYWlsIG93bmVycyB3b3VsZCByZWNlaXZlPyAN Cg0KV2VsbC4uIEkgZ3Vlc3MgdGhlIGRyYWZ0IHdhbnRzIHRvIHN0b3JlIHRoaXMgbWFwcGluZyBv biBhIEROUyBzZXJ2ZXIgcmlnaHQ/IEFuZCB0aGlzIEROUyBzZXJ2ZXIgaXMgYSBwdWJsaWMgb25l Li4uIHRoaXMgbWVhbnMsIHdlIGFyZSBoYW5kaW5nIG92ZXIgYWxsIGVtYWlscyB0byB0aGUgc3Bh bW1lcnMuLi4gDQoNCkkgaG9wZSBJIGFtIG5vdCBjb3JyZWN0IDotLw0KQmVzdCwNCkhvc25pZWgN CiANCg== From nobody Fri Jul 31 11:22:18 2015 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 8253E1ACD2D for ; Fri, 31 Jul 2015 11:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.261 X-Spam-Level: X-Spam-Status: No, score=-1.261 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 LoO1XTA5n84V for ; Fri, 31 Jul 2015 11:22:14 -0700 (PDT) Received: from mail.sys4.de (mail.sys4.de [194.126.158.139]) (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 AAD591ACD2C for ; Fri, 31 Jul 2015 11:22:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sys4.de; h= in-reply-to:content-disposition:content-type:content-type :mime-version:references:message-id:subject:subject:from:from :date:date; s=mail201310; t=1438366930; x=1440181331; bh=/fS3e29 hyTZaRkgWS4zr2Y/RVVzntNLyRVqKRAklWj4=; b=sWcQQaFf14d4+i5+3EV9ed0 Sto6dnZW51m2APUxNEHduUC51wnrmqMjyVk0+0UyWUILV5zTfpZPGSkc5YB9s+7v P8P91/AHsq+hV4pN9MtLv+7wSDljCeboBOtLbbguYcWV+oqBzntkuQXq23voqY0Y h+WBwG9S/t6bEHAyU0eLBLgOBqgi2Bd53ya+HFv3Qjhwu64QyvgGMjMTOhUn0SaI f1fMsqZ5VgyOfa237h4W4Pm3HU2FLEHk5beaXI3h6s/UuBtM8h/CKyfcD0yKuD1k X7d0oDq19zE274/8BTsT95++UHSwLtshwdMfKofmgo4dvJzFuloB7eaJUvZ40ig= = X-Virus-Scanned: Debian amavisd-new at mail.sys4.de Received: from sys4.de (mail.sys4.de [194.126.158.139]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sys4.de (Postfix) with ESMTPSA id 3mjcQV5xV6zX4 for ; Fri, 31 Jul 2015 20:22:10 +0200 (CEST) Date: Fri, 31 Jul 2015 20:22:09 +0200 From: Florian Kirstein To: "dane@ietf.org" Message-ID: <20150731182209.GB18811@sys4.de> References: <1437580854.052529954@apps.rackspace.com> <814D0BFB77D95844A01CA29B44CBF8A7015D2DD4@lhreml504-mbs> <4FEE7B8C-F482-4FB8-824E-26B26D30BAD7@powerdns.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4FEE7B8C-F482-4FB8-824E-26B26D30BAD7@powerdns.com> Archived-At: Subject: [dane] OPENPGP --- Privacy considerations 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 Jul 2015 18:22:16 -0000 Hi, I have done quite some research on DNSSEC zone security, NSEC and NSEC3 enumeration, attacking various zones using a GPU cluster and similar things, so I think I can judge the relevant attack vectors quite well... And indeed, there are various things to consider. In the result I am currently in strong favour of SHA instead of base, and I know of people who think base32 will make the standard much less attractive at least here in germany where privacy is a big topic - and for PGP users in general, as I expect they use PGP for a reason... We should not forget: the question is not only, if providers will publish keys for their zones, but also if clients will adopt the standard and query those keys. Both has to happen for the standard to be a success. But first my answer to: > >I would see the use of base32 (without extra improvement > >techniques) as a security risk. This is because, it decreases the > >entropy of SHA256 hash function > The planned/suggested use of base32 is *instead of* SHA256. Thus, > entropy is not a topic - as there is no hashing. I think Hosnieh was referring to the SHA256 done in the NSEC3 records, and/or the danger of harvesting the emails from the DNS. The current draft in 6.2 notes, that Email addresses "are not secret" and The hashing is not a security feature. I don't fully agree on the first sentence, but the rest is true. And also the solution: if you are worried about zone walking, using and adjusting NSEC3 or similar counter measures (white lies) is the answer, not a different input encoding. NSEC3 uses iterations and you can adjust how many (various things have to be considered there, but that's nothing special of this draft but normal DNSSEC operation) - so if there is one SHA-step more ore less to be done on the local part will add very little on the attacker side. So using base32 will NOT decrease security here in any way relevant in real life. Of course, if you use NSEC (like fedoraproject did for their openpgpkey test deployment) base32 is much worse than chopped sha - but it you are concerned about your zone data, simply don't use NSEC. So @Hosnieh: cosider using zone walking counter measures matching your paranoia level, and the SPAMMER issue should be gone. But there is a second side to consider: the DNS requests of the people sending mail. And there we (currently) don't have a (widely deployed) solution to hash or encrypt those on a DNS level. That means using base32 the emails of recipients I am sending mails to will go in clear text over the wire. And that's not good. Today many emails including their metadata at least in germany are fully encrypted from the sender to the recipient (not end to end, but on every segment) - SMTP submission using TLS and verified cert, intra-server SMTP with opportunistic TLS (vulnerable to MitM, but secure against passive attacks), IMAP with TLS and verified cert on the receiving end. And especially sending and receiving end is where pratical snooping is often possible, especially also active MitM. That means you can use your laptop in a cafe, your tablet in a hotel, and even without a VPN you can be pretty sure people around don't snoop on your mail communication. With OPENPGPKEY+Base32 deployed, they would see for EVERY mail you send the recipient in clear text. Even for the (currently 99.x%) cases, where the recipient doesn't have an openpgpkey record(!). Yes, one iteration of hash isn't a very good protection, especially for simple formed adresses. But still it is MUCH harder to snoop than clear text. Meaning: the NSA (and I with my GPU cluster) sniffing your Hotel WiFi will be able to unhash 80+% of your recipients. But the guy sitting on the table next to you with his cool $0.99 hacker-app for android or some guy fireing up wireshark for fun won't, unless he has a good rainbow table which unfortuneately (unlike for NSEC3) is pratical there. Still: attacking a hash is something completely different from simply sniffing a clear text. I have spoken to people who are really concerned by this and won't be enthusiastic about deploying this standard when it sends adresses in clear text through the net. Personally, from a privacy point of view, I'd also prefer to even see some form of iterated hashing implemented (having a record in the zone telling how many iterations or something like that), but I understand that this would be a completely new topic making things even slower, what do others think? So: a strong vote from my side to stay with chopped sha256. I still think the advantages of base32 are more theoretical and people who really want to use these advantages will have to implement own responders - if you're willing to do that you also could implement a webfinger service or similar. The OPENPGPKEY standard for DNS should be a simple way to publish the keys of your zone, and the current 03 draft provides that. Adding some paragraph about handling UTF8 (normalize, don't touch otherwise) and it's good to go. Greetings, Florian P.S.: On a side note: yes, lowercasing also weakens the attack surface of the hash. But not much, as unlike passwords the positions in which you uppercase an email are pretty obvious in real life. But actually, after many discussions with people actually using PGP regularly, I would even prefer to drop the lowercasing (possibly allowing the client to try it as second guess - will be done anyway) over using base32. -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstrasse 15, 81669 Muenchen Sitz der Gesellschaft: Muenchen, Amtsgericht Muenchen: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein