From nobody Tue Mar 7 08:26:58 2017 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65320129513 for ; Tue, 7 Mar 2017 08:26:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62marq2iVNec for ; Tue, 7 Mar 2017 08:26:52 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 028B81294EF for ; Tue, 7 Mar 2017 08:26:52 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3vd29P1hfSz3Gd for ; Tue, 7 Mar 2017 17:26:49 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1488904009; bh=0oLjVSQeB9gtoiIMAOL3o6AWicI6jeOq6SsqqXKPjiU=; h=Date:From:To:Subject:In-Reply-To:References; b=BK3BgC6jXSEuFlC4DqCXkl40e/f2T6M/3bzADnBBeoedgy9XULhnxJoKCvoU7TAEU /Vr6D2DF5N6MqqCeYtEwhjpTL/XBDzI4R2eVNEtN+YuJEZxg/48Jb1HUc5gHyoQ8co b/lhiawuE8bts1M+emVwsxsFjJ5lvhli1BlB3PRo= 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 gheWCL4Ti5Ci for ; Tue, 7 Mar 2017 17:26:47 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Tue, 7 Mar 2017 17:26:46 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 8AA833943A3; Tue, 7 Mar 2017 11:26:45 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 8AA833943A3 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 7585340D80EE for ; Tue, 7 Mar 2017 11:26:45 -0500 (EST) Date: Tue, 7 Mar 2017 11:26:45 -0500 (EST) From: Paul Wouters To: dane WG list In-Reply-To: <20170301050524.1063.qmail@ary.lan> Message-ID: References: <20170301050524.1063.qmail@ary.lan> User-Agent: Alpine 2.20.999 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dane] Review of draft-ietf-dane-smime-15 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 16:26:57 -0000 On Wed, 1 Mar 2017, John Levine wrote: > They're experiments. I'd think it'd be useful for the experiments to > see whether salted or unsalted hashes work better (or worse.) The experimental RFC for OPENPGPKEY is out already, and it does not support salting. So I don't know how you would experiment with that. If you are saying, since OPENPGPKEY uses unsalted, so let's pick salted for the SMIMEA experiment, I'd say that's unwise and goes against the wishes of the authors of both documents to use the same lookup method. It would also be mostly tested the operator, and no anything that goes over the wire, so it would be pretty subjective and non-statistical relevant. And I would predict the following outcome: Experiment with 1 zone: both work great! Experiment with many zones: Really happy using DNAME, so did not use salted. With fedorahosted.org, fedorapeople.org, fedoraproject.org, I was already in the latter category. Paul From nobody Tue Mar 7 10:31:31 2017 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 777051294AA for ; Tue, 7 Mar 2017 10:31:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.82 X-Spam-Level: X-Spam-Status: No, score=-0.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_DYNAMIC=1.08, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7dSUiLNC4f7 for ; Tue, 7 Mar 2017 10:31:27 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 703DA129467 for ; Tue, 7 Mar 2017 10:31:27 -0800 (PST) Received: (qmail 75254 invoked from network); 7 Mar 2017 18:31:26 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 7 Mar 2017 18:31:26 -0000 Date: 7 Mar 2017 18:31:04 -0000 Message-ID: <20170307183104.30352.qmail@ary.lan> From: "John Levine" To: dane@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: paul@nohats.ca Subject: Re: [dane] Review of draft-ietf-dane-smime-15 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 18:31:28 -0000 In article you write: >If you are saying, since OPENPGPKEY uses unsalted, so let's pick >salted for the SMIMEA experiment, I'd say that's unwise and goes >against the wishes of the authors of both documents to use the >same lookup method. I would have thought that the contents of an RFC would represent RFC consensus rather than the private preferences of the authors. R's, John From nobody Wed Mar 8 06:36:11 2017 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA5F1296B5; Wed, 8 Mar 2017 06:36:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSmzqFUjnP5d; Wed, 8 Mar 2017 06:36:02 -0800 (PST) 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 A34041296A9; Wed, 8 Mar 2017 06:36:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id F4042BE77; Wed, 8 Mar 2017 14:35:59 +0000 (GMT) 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 NYmjPq8GKI5s; Wed, 8 Mar 2017 14:35:59 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 51081BE3E; Wed, 8 Mar 2017 14:35:59 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1488983759; bh=Uu8z7VxxIRcfL9EVoVYxtCnl0fO1Gh1e0wZUphA06Zo=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=OE09aiWQM7Wgw8kAQ2bIDFp5uX039Ko7Z56ruk+vtz5g0p2CwoxECivkbnwy3N310 I/kUtvVqIexNcmyaRNEw+Jn8q4igifk8LorJUD2Dr6QWTTfaIc4ZrzWYa4lmfQkFE1 VICn5ujR1DWROjw2N0/6B/7cSgWbS2vuMvOV5A4I= To: Dale Worley , gen-art@ietf.org References: <148811824790.2888.13003369227902377285.idtracker@ietfa.amsl.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <8a3922c2-b8e4-e51b-77bc-b4db501ecaff@cs.tcd.ie> Date: Wed, 8 Mar 2017 14:35:58 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <148811824790.2888.13003369227902377285.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="pBm3GRLI28rEaQhJdL4gUVR9eMplpVQgl" Archived-At: Cc: draft-ietf-dane-smime.all@ietf.org, ietf@ietf.org, dane@ietf.org Subject: Re: [dane] Review of draft-ietf-dane-smime-15 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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 Mar 2017 14:36:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --pBm3GRLI28rEaQhJdL4gUVR9eMplpVQgl Content-Type: multipart/mixed; boundary="fmsXoULrpvAf0LwULFfE3QvUPXuSuUNks"; protected-headers="v1" From: Stephen Farrell To: Dale Worley , gen-art@ietf.org Cc: draft-ietf-dane-smime.all@ietf.org, ietf@ietf.org, dane@ietf.org Message-ID: <8a3922c2-b8e4-e51b-77bc-b4db501ecaff@cs.tcd.ie> Subject: Re: Review of draft-ietf-dane-smime-15 References: <148811824790.2888.13003369227902377285.idtracker@ietfa.amsl.com> In-Reply-To: <148811824790.2888.13003369227902377285.idtracker@ietfa.amsl.com> --fmsXoULrpvAf0LwULFfE3QvUPXuSuUNks Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, Thanks Dale for the detailed review and the discussion. I've had a read through the resulting thread and don't see anything that wasn't discussed in the WG that needs a major change (please do yell if I've missed something), so I'll leave this on the March 16th IESG telechat for IESG evaluation. (In part to try get this document done before I'm finished as an AD so we can cleanly close the dane WG:-) That said, I've not seen a response from the authors to the details below, and it'd be good to see that, so authors, please do reply to this and make any editorial changes needed. If you can do have those changes done by the end of Friday (or close-to) that'd be great so it's not changing while the IESG are reading it. Thanks, S. On 26/02/17 14:10, Dale Worley wrote: > Reviewer: Dale Worley > Review result: Ready with Nits >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at > . >=20 > Document: draft-ietf-dane-smime-15 > Reviewer: Dale R. Worley > Review Date: 2017-02-26 > IETF LC End Date: 2017-03-03 > IESG Telechat date: 2017-03-16 >=20 > Summary: This draft is basically ready for publication, but has nits > that should be fixed before publication. >=20 > * Technical points >=20 > 1. I assume that in parallel with RFC 6698, DNAME records must be > followed during SMIMEA resolution. It's not clear to me whether > CNAME > records must also be followed or how, given that SNAMEA records are > not for host names, but their grandparent node is a host name. >=20 > 2. Presumably it was deliberate not to have the first label for an > SNAMEA record be the canonical UTF-8 string for the local-part, even > though the DNS architecture (RFC 1035) seems to admit binary labels. >=20 > 3. Presumably it was deliberate to hash using SHA2-256 truncated to > 224 > bits rather than use SHA-224. >=20 > 4. Is it worth suggesting that some mechanism might be devised for > annotating an e-mail message with the canonical form of the sender's > local-part that is intended to be used to authenticate the message? > The last sentence of the 1st paragraph of section 1 suggests that > this > is deliberately out of scope for this document, but it might be worth > suggesting experimentation regarding this in section 4, which seems > to > be entirely about further experimentation. >=20 > * Editorial/Nits >=20 > Should there be an explicit statement that the resolver must follow > CNAME and DNAME records? That seems to be required by RFC 6698 > section A.2.1, but that requirement is buried rather deeply. Also, > is > CNAME following required? My vague understanding is that CNAME can > only be used to alias host names, and SMIMEA records are not for host > names (contrasting with the DANE records for TLS) -- though the > grandparent node of any SNAMEA is a host name. >=20 > Also, some adjustments of the resolution process of RFC 6698 re CNAME > records were made in RFC 7671, but this draft only mentions 7671 in > passing, in the introduction. It seems that it should be noted that > 7671 contains a lot of operational information about DANE. >=20 > 1. Introduction >=20 > There are other requirements on the MUA, such as > associating the identity in the certificate with that of the > message, > that are out of scope for this document. >=20 > "that of the message" isn't quite right, as "that" is parallel to > "the > identity", and the message doesn't itself have an identity. More > accurate would be "the purported sender of the message", as was used > in 3rd sentence of the paragraph. >=20 > 2. The SMIMEA Resource Record >=20 > ... the semantics are also the same except > where RFC 6698 talks about TLS at the target protocol for the > certificate information. >=20 > s/TLS at/TLS as/ >=20 > 3. Location of the SMIMEA 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 [RFC5322] and > [RFC6530]. >=20 > I don't have the full background on this. My memory ends at RFC > 1035: >=20 > Although labels can contain any 8 bit values in octets that make > up a > label, it is strongly recommended that labels follow the > preferred > syntax described elsewhere in this memo, which is compatible with > existing host naming conventions. >=20 > I suspect there is by now a defined way to have "UTF-8 labels".=20 > Given > that this draft doesn't use such a mechanism, there's probably a > discussion out there why just using a UTF-8 string as a label doesn't > work. It would be helpful to put a reference to that discussion > here, > because the mechanism in the draft is doing a lot of work to avoid > the > seemingly obvious mechanism. >=20 > 2. The local-part is first canonicalized using the following > rules. > If the local-part is unquoted, any whitespace (CFWS) around > dots > (".") is removed. Any enclosing double quotes are removed.=20 > Any > literal quoting is removed. >=20 > I think this could be more exactly expressed along the following > lines. Given the costs of not having this implemented exactly the > same way in all implementations, it's probably worth the extra words. >=20 > 2. The local-part is first canonicalized using the following > rules. If the local-part is unquoted, any whitespace (CFWS) > around dots (".") is removed. If the local-part is quoted, > the > enclosing double quotes, contained FWS, and the initial > backslashes of quoted-pairs are removed. (The obsolete > local-part format obs-local-part is canonicalized similarly: > CFWS around dots is removed and any word component that is a > quoted-string is canonicalized as if it was a separate > local-part.) >=20 > -- >=20 > 4. The local-part is 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. >=20 > Why use "SHA2-256 [RFC5754] algorithm, with the hash truncated to 28 > octets" rather than "SHA2-224 [RFC5754]"? (The two aren't the same, > because SHA-224 has a different IV than SHA2-256, but they seem to > have the same security properties.) Is this because implementations > will already implement SHA2-256 (for matching type 1)? >=20 > You probably want to specify hexadecimal case here. DNS is > considered > to be case-insensitive, but it's probably unwise to depend on that > fact. (Or is this known not to be a problem in DNS?) >=20 > 7. Certificate Size and DNS >=20 > The algorithm type and key > size of certificates should not be modified to accommodate this > section. >=20 > The term "algorithm type" is not defined; what is meant here? Also, > "of certificates" seems awkward; the encryption/signing algorithms > and > keys exist prior to the certificate which vouches for them. Perhaps: >=20 > A user's S/MIME encryption/signing algorithms and keys should not > be changed solely to reduce DNS RR sizes. >=20 > 9. Security Considerations >=20 > If an obtained S/MIME certificate is revoked or expired, that > certificate MUST NOT be used, even if that would result in sending > a > message in plaintext. >=20 > Shouldn't this be moved to section 6? This seems to be a > specification, but it is not contained in the definition of the > semantics. The "security considerations" section is where you would > see the explanation of the reason for this specification. >=20 > [END] >=20 >=20 >=20 --fmsXoULrpvAf0LwULFfE3QvUPXuSuUNks-- --pBm3GRLI28rEaQhJdL4gUVR9eMplpVQgl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYwBbOAAoJEC88hzaAX42irwYIAKsaW04XF3Z4n8qima2JZDCH XauRswKlVaGg+kwYXD60KDFI6bHP+iWSyXiHgvVltHMAvjGzIB1gljHLTsJkFL/D QNW2CKe+VubCx/i8SRdis0jDnopJ052AqDyCw/r/F2QwRxgtRoTehBdtOTqErEBa cRfrP/OjLfSc+G5ATfvkuitMaxHnMMZOZJBF9Za2GPCWxyt3KrRJazpMjVmUja4m iWF499N7EV53ZKPu6Pps4zyPNoJnPSUkmkfLYTEFhLPgbXRdLwJtesu/oBTGZvhl 4Mi/U4JDWIJpX/d2o2PNtM+Phhsdl4SUOARsOZ0eX3S89B9tUb1ExTbK1fBAL+M= =goyg -----END PGP SIGNATURE----- --pBm3GRLI28rEaQhJdL4gUVR9eMplpVQgl-- From nobody Thu Mar 9 14:33:32 2017 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1D5112958D; Thu, 9 Mar 2017 14:33:26 -0800 (PST) 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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6d-3GdJ02iCd; Thu, 9 Mar 2017 14:33:25 -0800 (PST) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 03D571294CD; Thu, 9 Mar 2017 14:33:24 -0800 (PST) Received: from [10.32.60.20] (142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v29MX1cT006823 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 9 Mar 2017 15:33:03 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176] claimed to be [10.32.60.20] From: "Paul Hoffman" To: "Stephen Farrell" Date: Thu, 09 Mar 2017 14:33:05 -0800 Message-ID: <29A4B86C-C922-41D5-9062-1FD1859CB0A3@vpnc.org> In-Reply-To: <8a3922c2-b8e4-e51b-77bc-b4db501ecaff@cs.tcd.ie> References: <148811824790.2888.13003369227902377285.idtracker@ietfa.amsl.com> <8a3922c2-b8e4-e51b-77bc-b4db501ecaff@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) Archived-At: Cc: gen-art@ietf.org, Dale Worley , dane@ietf.org Subject: Re: [dane] Review of draft-ietf-dane-smime-15 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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 Mar 2017 22:33:26 -0000 On 8 Mar 2017, at 6:35, Stephen Farrell wrote: > Hi, > > Thanks Dale for the detailed review and the discussion. > > I've had a read through the resulting thread and don't > see anything that wasn't discussed in the WG that needs > a major change (please do yell if I've missed something), > so I'll leave this on the March 16th IESG telechat for > IESG evaluation. (In part to try get this document done > before I'm finished as an AD so we can cleanly close the > dane WG:-) > > That said, I've not seen a response from the authors to > the details below, and it'd be good to see that, so > authors, please do reply to this and make any editorial > changes needed. If you can do have those changes done > by the end of Friday (or close-to) that'd be great so > it's not changing while the IESG are reading it. We have read the thread and see that Dale's concerns were met by Paul's "this was already discussed". We haven't see any other messages since the publication that would require a -16, but let's see what the IESG discussion teases out. --Paul Hoffman From nobody Thu Mar 9 19:19:45 2017 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C718612956B for ; Thu, 9 Mar 2017 19:19:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mt1G1ECtbG7s for ; Thu, 9 Mar 2017 19:19:43 -0800 (PST) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (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 D8B7B129549 for ; Thu, 9 Mar 2017 19:19:42 -0800 (PST) Received: from resomta-ch2-06v.sys.comcast.net ([69.252.207.102]) by resqmta-ch2-03v.sys.comcast.net with SMTP id mB5KcMlTZdEjjmB5icSrkJ; Fri, 10 Mar 2017 03:19:42 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-06v.sys.comcast.net with SMTP id mB5ecHnhgX9UpmB5fcE1ui; Fri, 10 Mar 2017 03:19:40 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v2A3Jbnk003173; Thu, 9 Mar 2017 22:19:37 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v2A3Japl003170; Thu, 9 Mar 2017 22:19:36 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: "Paul Hoffman" In-Reply-To: <29A4B86C-C922-41D5-9062-1FD1859CB0A3@vpnc.org> (paul.hoffman@vpnc.org) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 09 Mar 2017 22:19:36 -0500 Message-ID: <87varh7r93.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfLN+7wxOavLYLhJ4BAEUakESXQE3hNJMChSA3pHyWWRLqhJrlzMSTgB7g9diBbLJwHveo2FUyTSeAX4koyu/VcmRPkMqxceb9RoImAIfbpbNCdDCMdZt 8YOgZEhrFRm2pGgkWGk73jIEOCGvvgbA7BJtKSTR8iYRtAGMQQWwxmVP8wuQG4nthgEfHVFl7JErn220xSCbLVr4HA+juHqfTRUMzft1YMVPcgfORzWY1Pnp 4Sbw0e1By3iyStQLtObenQ== Archived-At: Cc: gen-art@ietf.org, dane@ietf.org Subject: Re: [dane] Review of draft-ietf-dane-smime-15 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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 Mar 2017 03:19:44 -0000 "Paul Hoffman" writes: > On 8 Mar 2017, at 6:35, Stephen Farrell wrote: >> Thanks Dale for the detailed review and the discussion. >> >> I've had a read through the resulting thread and don't >> see anything that wasn't discussed in the WG that needs >> a major change (please do yell if I've missed something), >> so I'll leave this on the March 16th IESG telechat for >> IESG evaluation. (In part to try get this document done >> before I'm finished as an AD so we can cleanly close the >> dane WG:-) >> >> That said, I've not seen a response from the authors to >> the details below, and it'd be good to see that, so >> authors, please do reply to this and make any editorial >> changes needed. If you can do have those changes done >> by the end of Friday (or close-to) that'd be great so >> it's not changing while the IESG are reading it. > > We have read the thread and see that Dale's concerns were met by Paul's > "this was already discussed". We haven't see any other messages since > the publication that would require a -16, but let's see what the IESG > discussion teases out. My interpretation is that my technical points are covered by "this was already discussed", and that Stephen was inquiring about the editorial/nits items (the "details below"). Dale From nobody Tue Mar 14 05:50:57 2017 Return-Path: X-Original-To: dane@ietf.org Delivered-To: dane@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E609127735; Tue, 14 Mar 2017 05:50:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148949585231.12655.2939086994138822730.idtracker@ietfa.amsl.com> Date: Tue, 14 Mar 2017 05:50:52 -0700 Archived-At: Cc: dane-chairs@ietf.org, draft-ietf-dane-smime@ietf.org, dane@ietf.org Subject: [dane] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-dane-smime-15=3A_=28with_COMMENT=29?= X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 12:50:52 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-dane-smime-15: 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-smime/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Minor comments: - Point 8 in the shepherd write-up is not addressed and this docuemnt has 2 IPR claims... - Intro: "Thus, the reader must be familiar with RFC 6698 before reading this document." -> That means RFC6698 must be normative. From nobody Wed Mar 15 08:10:05 2017 Return-Path: X-Original-To: dane@ietf.org Delivered-To: dane@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B0E7913163F; Wed, 15 Mar 2017 08:09:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov To: "The IESG" Cc: draft-ietf-dane-smime@ietf.org, dane-chairs@ietf.org, ogud@ogud.com, dane@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148959059871.14173.17895941451054393731.idtracker@ietfa.amsl.com> Date: Wed, 15 Mar 2017 08:09:58 -0700 Archived-At: Subject: [dane] Alexey Melnikov's No Objection on draft-ietf-dane-smime-15: (with COMMENT) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.22 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 15:09:59 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-dane-smime-15: 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-smime/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for this document. I have a small list of comments: 1) You are pointing to Unicode 5.2, which is rather old. You should reference the most recent version. 2) In Section 9.2: NSEC and NSEC3 need references. 3) In Section 11: All of your references are Informative. This is not correct, as several of the references are needed to implement or understand this specification. It doesn't matter that this document is Experimental, references needed to implement or understand the document still need to be Normative. From nobody Wed Mar 15 19:09:58 2017 Return-Path: X-Original-To: dane@ietf.org Delivered-To: dane@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EDD6129C68; Wed, 15 Mar 2017 19:09:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-dane-smime@ietf.org, dane-chairs@ietf.org, ogud@ogud.com, dane@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148963019657.14225.13317445344804850643.idtracker@ietfa.amsl.com> Date: Wed, 15 Mar 2017 19:09:56 -0700 Archived-At: Subject: [dane] Ben Campbell's No Objection on draft-ietf-dane-smime-15: (with COMMENT) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.22 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 02:09:56 -0000 Ben Campbell has entered the following ballot position for draft-ietf-dane-smime-15: 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-smime/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- There's a rather icky IPR disclosure that basically says that licensing terms won't be disclosed until they see where the draft is going. The shepherd's review doesn't mention whether the working group discussed that. Since this is experimental, it probably doesn't matter very much right now. I hope that gets some discussion prior to any attempt to promote this work to standards track. From nobody Wed Mar 15 19:52:25 2017 Return-Path: X-Original-To: dane@ietf.org Delivered-To: dane@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E45E6129C68; Wed, 15 Mar 2017 19:52:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan To: "The IESG" Cc: draft-ietf-dane-smime@ietf.org, dane-chairs@ietf.org, ogud@ogud.com, dane@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148963274393.14237.7483579153319110946.idtracker@ietfa.amsl.com> Date: Wed, 15 Mar 2017 19:52:23 -0700 Archived-At: Subject: [dane] Suresh Krishnan's No Objection on draft-ietf-dane-smime-15: (with COMMENT) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.22 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 02:52:24 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-dane-smime-15: 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-smime/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Agree with Mirja and Alexey's position about the references. At least RFC6698 needs to be normative. From nobody Thu Mar 16 04:43:06 2017 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69E82129404; Thu, 16 Mar 2017 04:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Up_4sr_hetd2; Thu, 16 Mar 2017 04:42:57 -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 4D35D129405; Thu, 16 Mar 2017 04:42:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C8268BE4D; Thu, 16 Mar 2017 11:42:51 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie 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 rYJC5iLXFNqw; Thu, 16 Mar 2017 11:42:50 +0000 (GMT) Received: from [10.87.48.75] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 07578BE2E; Thu, 16 Mar 2017 11:42:49 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1489664569; bh=4bcgk3UIzyZWo2SIYm0gbKm7Ye4AKg3hFRTOF8bUBb0=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=n0c8V7Q0yKEqWSh2wqEMNJJ+cIcejqAOAOs9CncvVtvP0YWDyboUu9EzTvd4BXQ1m W3ZGprnBHNUg0X+0v5a1KzmEqEoCv4uykHANu1zPIRwKAbvWUF9NfdmrnNqRJx9rSj 0SO6mY4fgpKYruoG5RWRoxrB87y9zA3Jjk4IfUiM= To: Ben Campbell , The IESG References: <148963019657.14225.13317445344804850643.idtracker@ietfa.amsl.com> Cc: dane-chairs@ietf.org, draft-ietf-dane-smime@ietf.org, ogud@ogud.com, dane@ietf.org From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Thu, 16 Mar 2017 11:42:48 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <148963019657.14225.13317445344804850643.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="9WODLmQbjlJVIth2HAGA5mnF4p6Qx5IVU" Archived-At: Subject: Re: [dane] Ben Campbell's No Objection on draft-ietf-dane-smime-15: (with COMMENT) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 11:42:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9WODLmQbjlJVIth2HAGA5mnF4p6Qx5IVU Content-Type: multipart/mixed; boundary="cFtCpS3GoEN4bbPjV67dfrAhIxMBG4PDL"; protected-headers="v1" From: Stephen Farrell To: Ben Campbell , The IESG Cc: dane-chairs@ietf.org, draft-ietf-dane-smime@ietf.org, ogud@ogud.com, dane@ietf.org Message-ID: Subject: Re: [dane] Ben Campbell's No Objection on draft-ietf-dane-smime-15: (with COMMENT) References: <148963019657.14225.13317445344804850643.idtracker@ietfa.amsl.com> In-Reply-To: <148963019657.14225.13317445344804850643.idtracker@ietfa.amsl.com> --cFtCpS3GoEN4bbPjV67dfrAhIxMBG4PDL Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Ben, On 16/03/17 02:09, Ben Campbell wrote: > Ben Campbell has entered the following ballot position for > draft-ietf-dane-smime-15: No Objection >=20 > 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.) >=20 >=20 > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.ht= ml > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dane-smime/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > There's a rather icky IPR disclosure that basically says that licensing= > terms won't be disclosed until they see where the draft is going.=20 Yeah, this same "tell ya later, maybe" situation has hit other drafts in the last year or so, regrettably from the same source. Fully agreeing about the icckiness, I did explicitly ask about this in my AD review [1] and we gave participants a week or so to object to progressing and none did as you can see from that thread. Cheers, S. [1] https://www.ietf.org/mail-archive/web/dane/current/msg08511.html > The > shepherd's review doesn't mention whether the working group discussed > that. Since this is experimental, it probably doesn't matter very much > right now. I hope that gets some discussion prior to any attempt to > promote this work to standards track. >=20 >=20 --cFtCpS3GoEN4bbPjV67dfrAhIxMBG4PDL-- --9WODLmQbjlJVIth2HAGA5mnF4p6Qx5IVU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYyno4AAoJEC88hzaAX42iBmkH/2oDsXEgE6/fZ+NP0VGuniVU GInUMETLwvTeilfxG456hmDfccYXrZj5B68LoHtyQnTJvZX+AaOnaduKSu2BLpbR Z9vDNZdPxwYnr+pPdlPQxl7P3ECfB6S26m1G8aUqzaumQDNwDuqLQt4bFxoqC/Co O2AdXzoZFB5txTrJdT9MwLoJzp3pS60BYQlqWHpiahQ6syKYjeFShk4AvnHgskeC W9sorWyt/odpCp0viuR5szgTki0BNoSLEcAAk76KXK2cMDOFxr7ZREhlG0+C5/6v tfftFme7ief1+JRk8NKm9/4+8nLkP1tSYpcmbqEoXelZWu6cxgpNVSZcr1VlaVE= =X608 -----END PGP SIGNATURE----- --9WODLmQbjlJVIth2HAGA5mnF4p6Qx5IVU-- From nobody Thu Mar 16 06:36:46 2017 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D79FA1294EC; Thu, 16 Mar 2017 06:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.696 X-Spam-Level: X-Spam-Status: No, score=-4.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0SCYjUnK3Tqe; Thu, 16 Mar 2017 06:36:44 -0700 (PDT) Received: from smtp100.iad3a.emailsrvr.com (smtp100.iad3a.emailsrvr.com [173.203.187.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 317591294E4; Thu, 16 Mar 2017 06:36:44 -0700 (PDT) Received: from smtp37.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp37.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 37DF33ECD; Thu, 16 Mar 2017 09:36:41 -0400 (EDT) X-Auth-ID: ogud@ogud.com Received: by smtp37.relay.iad3a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 6C48F5E41; Thu, 16 Mar 2017 09:36:29 -0400 (EDT) X-Sender-Id: ogud@ogud.com Received: from [26.54.226.93] ([UNAVAILABLE]. [172.56.7.25]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:465 (trex/5.7.12); Thu, 16 Mar 2017 09:36:41 -0400 Date: Thu, 16 Mar 2017 13:02:35 +0100 User-Agent: K-9 Mail for Android In-Reply-To: <148963019657.14225.13317445344804850643.idtracker@ietfa.amsl.com> References: <148963019657.14225.13317445344804850643.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----RGYJEDINVJ9VH7VC3CQRQ0TFV3QRL8" Content-Transfer-Encoding: 7bit To: Ben Campbell ,The IESG CC: draft-ietf-dane-smime@ietf.org,dane-chairs@ietf.org,dane@ietf.org From: =?ISO-8859-1?Q?=D3lafur_Gudmundsson?= Message-ID: Archived-At: Subject: Re: [dane] Ben Campbell's No Objection on draft-ietf-dane-smime-15: (with COMMENT) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 13:36:46 -0000 ------RGYJEDINVJ9VH7VC3CQRQ0TFV3QRL8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The working group discussed this and decided to move forward=2E=20 =C3=93lafur On March 16, 2017 3:09:56 AM GMT+01:00, Ben Campbell w= rote: >Ben Campbell has entered the following ballot position for >draft-ietf-dane-smime-15: No Objection > >When responding, please keep the subject line intact and reply to all >email addresses included in the To and CC lines=2E (Feel free to cut this >introductory paragraph, however=2E) > > >Please refer to >https://www=2Eietf=2Eorg/iesg/statement/discuss-criteria=2Ehtml >for more information about IESG DISCUSS and COMMENT positions=2E > > >The document, along with other ballot positions, can be found here: >https://datatracker=2Eietf=2Eorg/doc/draft-ietf-dane-smime/ > > > >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > >There's a rather icky IPR disclosure that basically says that licensing >terms won't be disclosed until they see where the draft is going=2E The >shepherd's review doesn't mention whether the working group discussed >that=2E Since this is experimental, it probably doesn't matter very much >right now=2E I hope that gets some discussion prior to any attempt to >promote this work to standards track=2E --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E ------RGYJEDINVJ9VH7VC3CQRQ0TFV3QRL8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable The working group discussed this and decided to mo= ve forward=2E


=C3=93lafur

On March 16, 2017 3:09:56 AM= GMT+01:00, Ben Campbell <ben@nostrum=2Ecom> wrote:
Ben Campbell has entered the following ballot positi=
on for
draft-ietf-dane-smime-15: No Objection

When respondi=
ng, please keep the subject line intact and reply to all
email address=
es included in the To and CC lines=2E (Feel free to cut this
introduct=
ory paragraph, however=2E)


Please refer to https://www=2E=
ietf=2Eorg/iesg/statement/discuss-criteria=2Ehtml
for more informa=
tion about IESG DISCUSS and COMMENT positions=2E


The docum=
ent, along with other ballot positions, can be found here:
https://datatra=
cker=2Eietf=2Eorg/doc/draft-ietf-dane-smime/




COMMENT:


There's a rather icky IPR disclosu=
re that basically says that licensing
terms won't be disclosed until t=
hey see where the draft is going=2E The
shepherd's review doesn't ment=
ion whether the working group discussed
that=2E Since this is experime=
ntal, it probably doesn't matter very much
right now=2E I hope that ge=
ts some discussion prior to any attempt to
promote this work to standa=
rds track=2E



--
Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E ------RGYJEDINVJ9VH7VC3CQRQ0TFV3QRL8-- From nobody Thu Mar 16 10:09:51 2017 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96B001273E2 for ; Thu, 16 Mar 2017 10:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.741 X-Spam-Level: X-Spam-Status: No, score=-1.741 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mLb_9Kle5fbv for ; Thu, 16 Mar 2017 10:09:46 -0700 (PDT) Received: from mail-ot0-x22a.google.com (mail-ot0-x22a.google.com [IPv6:2607:f8b0:4003:c0f::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 93436120227 for ; Thu, 16 Mar 2017 10:09:46 -0700 (PDT) Received: by mail-ot0-x22a.google.com with SMTP id i1so63198306ota.3 for ; Thu, 16 Mar 2017 10:09:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=N5a7SYBMuxUFKPTAWK6NoA9VLJ0xQbcUi6eOXWbmdcI=; b=EFNuT5K8cOgmM1SKBYmNm+efJhg0L/f5k2Lvsf0tSeAM7ARngppQwMaRsE62i9XqiZ HpztrcAHJjMu3PEnKpr92Yvl/YzNSs7iAwkXzMqK1gkCFksRDzfEILpYENLvVv7bhOiy HoSv8VNxDTy9ati+/2otPLM3CnJzt8Q6CI4vO/TcYxhwuXI0g/6yAAveWnj1ceID0e+K 3n/wE1k74QMF3aufau96tjyacsnyH3tI9lV+qdCAMFZCHKPOoHjRUdWF5lLR6CLMRVDv d9Kk0wLX/B+cn8U6TnVoBTR/Qehw/IEUChc68Hp8yWVc8lRndGZ/dxmvLXMjBeepTdSQ uDhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=N5a7SYBMuxUFKPTAWK6NoA9VLJ0xQbcUi6eOXWbmdcI=; b=ZSwpGEdbyoGkK3O+xe8pPx7CAf3yyTLBaqLrlzsb5ctK6LG7co8qCjiikpxp1Zmgjj dUym3Cio3CIkyNF+9QQE6OVNFSbwxt//3h53I7HiH01vODVYp3rNUn57CpB2eE5GX/6i nvabXR7ixzBwtu/rdVTvOd2aEYxo9d0yfFO8De059Gj4OZeVN/lOPuXYctEjaF05SrRx xm1nGGf0+D6sBf1nW6cM7rGGXgdDfVOajFshOVpn0Amf0EhoZ6FWzgJhphmTQE5mfswI C7hspkyB/cO/wNA7Mslg+Z6Lwc8Hmio4d357Ds6qOt3VuLPJKRktIyjSHqx0z+wcuZWa KauA== X-Gm-Message-State: AFeK/H2Bv3d9HjN2ST/k3e/u+Lpk7TwmwHXK3GB+FA4sP/K1Wj8hJ/ce4OG17Zv2JPevoavwWHYDM3RlzEKnMPm/ X-Received: by 10.157.11.229 with SMTP id 92mr4947740oth.85.1489684185705; Thu, 16 Mar 2017 10:09:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.41.226 with HTTP; Thu, 16 Mar 2017 10:09:44 -0700 (PDT) From: Wei Chuang Date: Thu, 16 Mar 2017 10:09:44 -0700 Message-ID: To: trans@ietf.org, dane@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a1142ef02bd0357054adc200f" Archived-At: Subject: [dane] CT for DNSSEC X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 17:09:49 -0000 --001a1142ef02bd0357054adc200f Content-Type: multipart/alternative; boundary=001a1142ef02b80dbe054adc20f6 --001a1142ef02b80dbe054adc20f6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi folks, I saw there was significant interest in exploring CT for DNSSEC back in 2014 of which a draft draft-zhang-trans-ct-dnssec was created. It seems to have quieted down since. I believe the motivation is still there which is to prevent a parent zone from potentially misbehaving and spoofing the child zone. Is there still interest in this? From the list archives, I can't see what the issues were though I'm guessing one of them was respecifying the DS resource record to use a SCT which might have caused compatibility concerns. (But please correct me if I'm wrong) Other than that, the draft seems pretty reasonable. Were there other concerns? thanks, -Wei --001a1142ef02b80dbe054adc20f6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Hi folks,

I saw there was significant interest in exploring CT for DNSSEC back in 2014 of which a draft draft-zhang-trans-ct-dnssec was created.  It seems to have quieted down since.  I believe the motivation is still there which is to prevent a parent zone from potentially misbehaving and spoofing the child zone.  Is there still interest in this?  From the list archives, I can't see what the issues were though I'm guessing one of them was respecifying the DS resource record to use a SCT which might have caused compatibility concerns.  (But please correct me if I'm wrong)  Other than that, the draft seems pretty reasonable.  Were there other concerns?

thanks,
-Wei  
--001a1142ef02b80dbe054adc20f6-- --001a1142ef02bd0357054adc200f Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMZN1N4N3KNCF5ZBTQMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTAyNjE4NDI0NVoXDTE3MDQy NDE4NDI0NVowIjEgMB4GCSqGSIb3DQEJAQwRd2VpaGF3QGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDiNpZ5E2IqcxktrcD1X5jWksphe1Ur882fsZM99Y4hiVugSVOb zIZIxoh3ckmGpUFyK1un6AU9Rxq9GSSkRskGAaSGrGcy7ncPi7Z1NlOJN25oXFmzituZsZeYIs0S QqT9hlDpLGc95r1CpsuTlaIB8m9Uvi+H6sGecVb2TOuGbRViQIWWf5GWk2AlJYhBFyJv7regqVa8 v3fx6SLkn/hIzBQf7xpVJzG6kAa09ZE0LoPdp5YV+Hv38EqDOWjm+g6Qbh1NADhdGpbmQDp9kdlm 6WZjCMwryQukdCypLKI2BPa08F18LZktaQNlJ2s7VxDJj2ozxomeBpSK6rxSxLAjAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRF3ZWloYXdAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFIMwgx+nNfYP3NyOZfiHYydFyNdQMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAO0J2vGX8ye90RegS3 HS+OE2hGEdDYJlR+S9ZSpla5AC9eejUKUc9JZR3y0ocGeQ3FQyXjM5/azBblqz/ajAbj2Fxuge45 SdRXrItDhAGWtQNl3utu2Uhf4y3re4ZRjApnhEBBX1l0E2BJuHf8MmqMhVU70Ko6Lk3lyPxnBeWo Q3tG2He3CNCkq/SDImq9vf8CNoxKxEkCP+kI+/NaCh5peLygU1h7Dc0ryWAcrxRWn8GUeEOg28MI vpwttw54cNR4YJYJVuiXCNc6PqkT/JxCiMvHS1woXJuET6QZSPtpNtvhNu90sV68Q7b2m6Vp8QTn xbzoEIHhiQWIcfphXjbeMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMZN1N4N3K NCF5ZBTQMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCDkMu8j/55wvvscg3Tg3Cwg rHV7mIJ/SWzSivNj6RvI2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzAzMTYxNzA5NDZaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEA2tTj0ncb7wAx1o5/lbe45u9tP1W9aJfupS6iIgaq hPYCqgGts7fZkHG8y1EGlnK6wEYL9mr1/34R7VHz5fVSZcrY1M4blWHnKJMen5CGgwKyknky07he 42gCECBGWE6i4/nWfwWfvJtSzi/OU9nYorfC8ORzCsKxdJL5TSqRMmWwq4zgjnzTRI28IeufZhp9 8s5o9d79z4K4fTICohfsmDu1CRMPIONN+03wr/W72U60A1ZE0P+F8tR+CfMrDPHwvWVl/V0nzkof BgxG8ZbmypDoA88USTjHYcHeC4P9rGLfUCyYT4XSDNZMN3zjDReLodkKiK8RXc9PA18cx5yhgA== --001a1142ef02bd0357054adc200f-- From nobody Thu Mar 16 10:25:21 2017 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 218121296C4; Thu, 16 Mar 2017 10:25: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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7dJX4f7OcmW; Thu, 16 Mar 2017 10:25:12 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 865FF127843; Thu, 16 Mar 2017 10:25:12 -0700 (PDT) Received: from [10.32.60.31] (142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v2GHP2ro022144 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 16 Mar 2017 10:25:03 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176] claimed to be [10.32.60.31] From: "Paul Hoffman" To: "Wei Chuang" Cc: trans@ietf.org, dane@ietf.org Date: Thu, 16 Mar 2017 10:25:08 -0700 Message-ID: <455EC3FC-9140-40D3-88F8-77990B7C7DD0@vpnc.org> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [dane] CT for DNSSEC X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 17:25:14 -0000 On 16 Mar 2017, at 10:09, Wei Chuang wrote: > I saw there was significant interest > in > exploring > CT for DNSSEC back in 2014 of which a draft > draft-zhang-trans-ct-dnssec > was > created. > It seems to have quieted down since. I believe the motivation is > still > there which is to prevent a parent zone from potentially misbehaving > and > spoofing the child zone. Is there still interest in this? From the > list > archives, I can't see what the issues were though I'm guessing one of > them > was respecifying the DS resource record to use a SCT which might have > caused compatibility concerns. (But please correct me if I'm wrong) > Other > than that, the draft seems pretty reasonable. Were there other > concerns? There were two separate issues that got conflated at the time: - Seeing evidence that a parent had spoofed DNSSEC keys for a child. A transcript of the DS records in the parent is sufficient as long as the child doesn't have relying parties create islands of trust (which is relatively rare these days). - Seeing evidence that a parent had spoofed any resource records for a child. A transcript of the NS records in the parents is a good start, although what is really needed is a transcript of everything that is seen for the child. In both cases, having transcripts from various DNS looking glasses around the Internet would give greater assurance of the integrity of the transcript. --Paul Hoffman From nobody Thu Mar 16 16:00:51 2017 Return-Path: X-Original-To: dane@ietf.org Delivered-To: dane@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9069B129B79; Thu, 16 Mar 2017 16:00:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dane@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148970524954.14117.10405123693312259288@ietfa.amsl.com> Date: Thu, 16 Mar 2017 16:00:49 -0700 Archived-At: Subject: [dane] I-D Action: draft-ietf-dane-smime-16.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.22 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 23:00:50 -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 of the IETF. Title : Using Secure DNS to Associate Certificates with Domain Names For S/MIME Authors : Paul Hoffman Jakob Schlyter Filename : draft-ietf-dane-smime-16.txt Pages : 11 Date : 2017-03-16 Abstract: This document describes how to use secure DNS to associate an S/MIME user's certificate with the intended domain name, similar to the way that DNS-Based Authentication of Named Entities (DANE), RFC 6698, does for TLS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-smime/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dane-smime-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dane-smime-16 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 Thu Mar 16 17:17:00 2017 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22004129B6F; Thu, 16 Mar 2017 17:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHz4Y4LNeDl1; Thu, 16 Mar 2017 17:16:57 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 DB8AD1296ED; Thu, 16 Mar 2017 17:16:57 -0700 (PDT) Received: from [10.32.60.31] (142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v2H0GfxQ056545 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 16 Mar 2017 17:16:42 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176] claimed to be [10.32.60.31] From: "Paul Hoffman" To: "The IESG" Cc: dane@ietf.org, "Stephen Farrell" Date: Thu, 16 Mar 2017 17:16:48 -0700 Message-ID: In-Reply-To: <148970524954.14117.10405123693312259288@ietfa.amsl.com> References: <148970524954.14117.10405123693312259288@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-16.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 00:16:59 -0000 Greetings. We think that this version of the draft deals with all the issues raised in the IESG balloting (other than the IPR issue, which is beyond our control). --Paul Hoffman On 16 Mar 2017, at 16:00, internet-drafts@ietf.org wrote: > 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 of the IETF. > > Title : Using Secure DNS to Associate Certificates > with Domain Names For S/MIME > Authors : Paul Hoffman > Jakob Schlyter > Filename : draft-ietf-dane-smime-16.txt > Pages : 11 > Date : 2017-03-16 > > Abstract: > This document describes how to use secure DNS to associate an > S/MIME > user's certificate with the intended domain name, similar to the > way > that DNS-Based Authentication of Named Entities (DANE), RFC 6698, > does for TLS. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dane-smime/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-dane-smime-16 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dane-smime-16 > > > 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/ > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From nobody Fri Mar 17 01:54:57 2017 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEFC7126BF6; Fri, 17 Mar 2017 01:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yk5aqApHS75Q; Fri, 17 Mar 2017 01:54:47 -0700 (PDT) Received: from e-mailfilter02.sunet.se (e-mailfilter02.sunet.se [IPv6:2001:6b0:8:2::202]) (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 7F791126B72; Fri, 17 Mar 2017 01:54:46 -0700 (PDT) Received: from smtp1.nordu.net (smtp1.nordu.net [IPv6:2001:948:4:6::32]) by e-mailfilter02.sunet.se (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id v2H8sgWZ010061 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 17 Mar 2017 09:54:43 +0100 Received: from flogsta (smtp.adb-centralen.se [IPv6:2001:6b0:8::129]) (authenticated bits=0) by smtp1.nordu.net (8.14.7/8.14.7) with ESMTP id v2H8sdei000524 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 17 Mar 2017 08:54:42 GMT From: Linus Nordberg To: Wei Chuang Cc: trans@ietf.org, dane@ietf.org Organization: Sunet References: Date: Fri, 17 Mar 2017 09:54:46 +0100 In-Reply-To: (Wei Chuang's message of "Thu, 16 Mar 2017 10:09:44 -0700") Message-ID: <878to4qo4p.fsf@nordberg.se> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: CanIt (www . roaringpenguin . com) X-Scanned-By: MIMEDefang 2.74 X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-nordu-net:default, nordu-net:default, base:default, @@RPTN) X-p0f-Info: os=unknown unknown, link=Ethernet or modem X-CanIt-Geo: ip=2001:6b0:8::129; country=SE; latitude=59.3247; longitude=18.0560; http://maps.google.com/maps?q=59.3247,18.0560&z=6 X-CanItPRO-Stream: outbound-nordu-net:outbound (inherits from outbound-nordu-net:default, nordu-net:default, base:default) X-Canit-Stats-ID: 0aSUUSGCU - 86c8624a5734 - 20170317 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter02.sunet.se: 2001:6b0:8::129 is neither permitted nor denied by domain linus@sunet.se) receiver=e-mailfilter02.sunet.se; client-ip=2001:6b0:8::129; envelope-from=; helo=smtp1.nordu.net; identity=mailfrom Archived-At: Subject: Re: [dane] [Trans] CT for DNSSEC X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 08:54:51 -0000 Wei Chuang wrote Thu, 16 Mar 2017 10:09:44 -0700: > spoofing the child zone. Is there still interest in this? From the list > archives, I can't see what the issues were though I'm guessing one of them > was respecifying the DS resource record to use a SCT which might have > caused compatibility concerns. (But please correct me if I'm wrong) Other > than that, the draft seems pretty reasonable. Were there other concerns? I'm still interested in logging things DNSSEC. The test log set up at the IETF Berlin hackathon [0] is still running [1]. We lack a client for submission. Protocol deviations from draft-zhang-trans-ct-dnssec-03 are summarized in [2]. [0] https://lists.sunet.se/pipermail/dnssec-transparency/2016-July/000049.html [1] curl -A "" -x socks4a://127.0.0.1:9050/ -s http://teowuafdvio2mip5.onion/dt/v1/get-sth | json_pp --8<---------------cut here---------------start------------->8--- { "tree_head_signature" : "BAMARjBEAiA48+vqfg2O3ZbVYvlMxof2dzLwJ09gPtdY3FGtq1LbaAIgXWD4qfCOh38JzCz52E1B1cdkI+8+gHitA1DNMC4Zl2g=", "timestamp" : 1489739801931, "tree_size" : 1, "sha256_root_hash" : "OQFz17e1piHRfRRsAG3QkweRuq/jyrjViq+vZbkyY+I=" } --8<---------------cut here---------------end--------------->8--- [2] https://git.nordu.net/?p=user/linus/catlfish.git;a=blob_plain;f=README-dnssec.md;hb=refs/heads/dnssec2 From nobody Fri Mar 17 09:31:49 2017 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28B441294EC for ; Fri, 17 Mar 2017 09:31:48 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZnZYRmq4eJQ for ; Fri, 17 Mar 2017 09:31:46 -0700 (PDT) Received: from mail-ot0-x22b.google.com (mail-ot0-x22b.google.com [IPv6:2607:f8b0:4003:c0f::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 6B2641294E9 for ; Fri, 17 Mar 2017 09:31:46 -0700 (PDT) Received: by mail-ot0-x22b.google.com with SMTP id i1so97176446ota.3 for ; Fri, 17 Mar 2017 09:31:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pyPV9SrY1JzazSysydhDGqhwtbE9RPPpP0klwsUnTjc=; b=Bc2Vgs7kOLEE66ROjrAF3XAj1jegs8yBW+Kt+0waoyeiqs+qacdfQe21X9muVScup9 ijpHpOQAwmlXTvYDWEkkHjHKJ9/wFjv7zLcN6/8VDHGeCfESEbcS3EIcM0Sa8hWJc7mF Tg98KIZmiyEfsxdg8KalcTc/+48+cNlamZc5hLwClYQ8Iak7I1gPaIJ98Zn9PhU1BTZf W5+z21PFy+EG+BKmJFo+vBo03ZqmEm+f2CqigoEK3Og2Hii3ySFhcCXKsA4iAPS+cZ6G AKCai3CUz7zQQwaY+p/fE7iNhAwuFfFQoCenSMkxS3ahFzhS/pQ+dYSE7EjprYDPohzX egwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pyPV9SrY1JzazSysydhDGqhwtbE9RPPpP0klwsUnTjc=; b=ieFpeRhf1Vn5n5xtwXDEzegcDxaL9A1Xtc9Moa3VCVj/w6QflTGBdotKa4otloP9xt NR7AWE2g+DFYlLb5Ggb90xe+GN351wtlXHri5qDZXpS5a9BXA1v1l0e3x2PelR0l3QP5 p1x9NwTTXDFkh0gLQGmb22+mPs8JMqAL6GxJ/6T+KxDDFVjE7BwRMuBCKVPFX+1ft/1a vU4LW2sIP9GhGMLqqo2cBDgdQuv/tp8/d2aelCjdgdLCenpdpT/x00yO5TLuXWe9l6r4 L/EduaaR4kdy1OBNRKI5BFTn+Q2ysBuhwYl5Qk8Bhg1vAwwX63spHjiUU3rLIJ8t/LKk CVvA== X-Gm-Message-State: AFeK/H1w9g+wBtmQGbQw3t70mQvr5PdFasoqguGS/6YQ+VQ33CzZB1TEp5zIT4oczYHiHXFksyeRXbhtKqGcaWZL X-Received: by 10.202.178.138 with SMTP id b132mr8568195oif.101.1489768305631; Fri, 17 Mar 2017 09:31:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.41.226 with HTTP; Fri, 17 Mar 2017 09:31:44 -0700 (PDT) In-Reply-To: <455EC3FC-9140-40D3-88F8-77990B7C7DD0@vpnc.org> References: <455EC3FC-9140-40D3-88F8-77990B7C7DD0@vpnc.org> From: Wei Chuang Date: Fri, 17 Mar 2017 09:31:44 -0700 Message-ID: To: Paul Hoffman Cc: trans@ietf.org, dane@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a113ce0b0acd609054aefb691" Archived-At: Subject: Re: [dane] CT for DNSSEC X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 16:31:48 -0000 --001a113ce0b0acd609054aefb691 Content-Type: multipart/alternative; boundary=001a113ce0b0a8053e054aefb630 --001a113ce0b0a8053e054aefb630 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On Thu, Mar 16, 2017 at 10:25 AM, Paul Hoffman wrote: > On 16 Mar 2017, at 10:09, Wei Chuang wrote: > > I saw there was significant interest >> in exploring >> CT for DNSSEC back in 2014 of which a draft draft-zhang-trans-ct-dnssec >> was created. >> It seems to have quieted down since. I believe the motivation is still >> there which is to prevent a parent zone from potentially misbehaving and >> spoofing the child zone. Is there still interest in this? From the list >> archives, I can't see what the issues were though I'm guessing one of them >> was respecifying the DS resource record to use a SCT which might have >> caused compatibility concerns. (But please correct me if I'm wrong) >> Other >> than that, the draft seems pretty reasonable. Were there other concerns? >> > > There were two separate issues that got conflated at the time: > > - Seeing evidence that a parent had spoofed DNSSEC keys for a child. A > transcript of the DS records in the parent is sufficient as long as the > child doesn't have relying parties create islands of trust (which is > relatively rare these days). > > - Seeing evidence that a parent had spoofed any resource records for a > child. A transcript of the NS records in the parents is a good start, > although what is really needed is a transcript of everything that is seen > for the child. > Is this because you're worried about the parent removing evidence of DNSSEC for the child in the spoofing scenario? If the parent tries to spoof with DNSSEC for the child I would assume that seeing the DS SCT's in the log, that is sufficient to find evidence of spoofing. That said I think it could be helpful to log NS as well for forensics. One issue with logging all records seen is if webmail providers publish SMIMEA there will be a potentially overwhelming number of records logged, and a very large change rate. Another issue is privacy of such records. > > In both cases, having transcripts from various DNS looking glasses around > the Internet would give greater assurance of the integrity of the > transcript. I agree that would a good idea. -Wei > > --Paul Hoffman > --001a113ce0b0a8053e054aefb630 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit


On Thu, Mar 16, 2017 at 10:25 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
On 16 Mar 2017, at 10:09, Wei Chuang wrote:

I saw there was significant interest
 <http://blog.huque.com/2014/07/dnssec-key-transparency.html> in exploring
CT for DNSSEC back in 2014 of which a draft draft-zhang-trans-ct-dnssec
 <https://tools.ietf.org/html/draft-zhang-trans-ct-dnssec-03> was created.
It seems to have quieted down since.  I believe the motivation is still
there which is to prevent a parent zone from potentially misbehaving and
spoofing the child zone.  Is there still interest in this?  From the list
archives, I can't see what the issues were though I'm guessing one of them
was respecifying the DS resource record to use a SCT which might have
caused compatibility concerns.  (But please correct me if I'm wrong)  Other
than that, the draft seems pretty reasonable.  Were there other concerns?

There were two separate issues that got conflated at the time:

- Seeing evidence that a parent had spoofed DNSSEC keys for a child. A transcript of the DS records in the parent is sufficient as long as the child doesn't have relying parties create islands of trust (which is relatively rare these days).

- Seeing evidence that a parent had spoofed any resource records for a child. A transcript of the NS records in the parents is a good start, although what is really needed is a transcript of everything that is seen for the child.

Is this because you're worried about the parent removing evidence of DNSSEC for the child in the spoofing scenario?  If the parent tries to spoof with DNSSEC for the child I would assume that seeing the DS SCT's in the log, that is sufficient to find evidence of spoofing.  That said I think it could be helpful to log NS as well for forensics.

One issue with logging all records seen is if webmail providers publish SMIMEA there will be a potentially overwhelming number of records logged, and a very large change rate.  Another issue is privacy of such records.  
 

In both cases, having transcripts from various DNS looking glasses around the Internet would give greater assurance of the integrity of the transcript.

I agree that would a good idea.
 
-Wei



--Paul Hoffman

--001a113ce0b0a8053e054aefb630-- --001a113ce0b0acd609054aefb691 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMZN1N4N3KNCF5ZBTQMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTAyNjE4NDI0NVoXDTE3MDQy NDE4NDI0NVowIjEgMB4GCSqGSIb3DQEJAQwRd2VpaGF3QGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDiNpZ5E2IqcxktrcD1X5jWksphe1Ur882fsZM99Y4hiVugSVOb zIZIxoh3ckmGpUFyK1un6AU9Rxq9GSSkRskGAaSGrGcy7ncPi7Z1NlOJN25oXFmzituZsZeYIs0S QqT9hlDpLGc95r1CpsuTlaIB8m9Uvi+H6sGecVb2TOuGbRViQIWWf5GWk2AlJYhBFyJv7regqVa8 v3fx6SLkn/hIzBQf7xpVJzG6kAa09ZE0LoPdp5YV+Hv38EqDOWjm+g6Qbh1NADhdGpbmQDp9kdlm 6WZjCMwryQukdCypLKI2BPa08F18LZktaQNlJ2s7VxDJj2ozxomeBpSK6rxSxLAjAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRF3ZWloYXdAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFIMwgx+nNfYP3NyOZfiHYydFyNdQMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAO0J2vGX8ye90RegS3 HS+OE2hGEdDYJlR+S9ZSpla5AC9eejUKUc9JZR3y0ocGeQ3FQyXjM5/azBblqz/ajAbj2Fxuge45 SdRXrItDhAGWtQNl3utu2Uhf4y3re4ZRjApnhEBBX1l0E2BJuHf8MmqMhVU70Ko6Lk3lyPxnBeWo Q3tG2He3CNCkq/SDImq9vf8CNoxKxEkCP+kI+/NaCh5peLygU1h7Dc0ryWAcrxRWn8GUeEOg28MI vpwttw54cNR4YJYJVuiXCNc6PqkT/JxCiMvHS1woXJuET6QZSPtpNtvhNu90sV68Q7b2m6Vp8QTn xbzoEIHhiQWIcfphXjbeMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMZN1N4N3K NCF5ZBTQMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCAR4jYbMMMNkJ0KKA3HhKv9 D6jGyy8v2ZdiaZ+HCxikIzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzAzMTcxNjMxNDVaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAA4ESZh7svAIaNM/tDxaWIkS1XRKIFPE6Q0QpwxKT PAB+akDdlBgJ30qSCuzZEN6UXxh3HEJqHBCn+Ny5lJdCBHYkqNRNx13SMVjSTo742+CwY4DVifjR U6icUuYvVHUf8DNhxAUOdff4ksZBOokFPFdc+vudRzmdPmlbaqx6PceIwEV0dSLEjDdBDGSLDdg5 9KOHcuiaPUEeNp0xFRWdErDOsYz/OB7NhZjxz5zAN3l1lEiEyx8jhZXHIkBMLXhTYLhSDl6VJhEC ILLOpAbQbP9Hi/YyrdN087Qs9BMhscXTBfh9xTf5ykBKgqZb98T/PEM5eDzAtpa5WmWkwDPUWw== --001a113ce0b0acd609054aefb691-- From nobody Fri Mar 17 09:34:48 2017 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CBCF1294FC for ; Fri, 17 Mar 2017 09:34:43 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E_MRAqq7Q2wx for ; Fri, 17 Mar 2017 09:34:41 -0700 (PDT) Received: from mail-ot0-x230.google.com (mail-ot0-x230.google.com [IPv6:2607:f8b0:4003:c0f::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 CB0A41294CA for ; Fri, 17 Mar 2017 09:34:40 -0700 (PDT) Received: by mail-ot0-x230.google.com with SMTP id i1so97272148ota.3 for ; Fri, 17 Mar 2017 09:34:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Qbwo/rmE1tvZJuO3Wb5NNsGTv3ctE5cK5MqnMeKw0Ow=; b=HUPyBYOXiv+aa59m1Wykynb1lnZYJ90AlutV1NIgZ3crjaSEIYJjti1gsUM5/pVecy 6su5kzInwJx1x3PDGgkLXcPVqUxacqXRsTzky3cfmBfLUDlQecQSSJLAD9+jEb2G6Q1V pVUrfzdr2oKPTrHTO7BN2GD5NZ5droH+imA8DMx/GaW7ILMMh62qAS+Y8MmHnDiRpDID 4Gc5GWwyfnfMG11SnTGYmQEU3Yesscu3Dec+89uxXQuj3Ins52DAaw6CRay3EHa9Pyw2 HK+7J0HInOo2pZ2UyoIQEcnXh8CXTDRbpidFU3KHowTQP2HG3EiVS/prmAA6+VQatoUc zpFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Qbwo/rmE1tvZJuO3Wb5NNsGTv3ctE5cK5MqnMeKw0Ow=; b=SJCjy6twhE9xy4t97jWk3V/OtvoToGTVSLyOvUcUbZzp0/3aihwFVGNTNzmDn9h6Nq ee54Iu90EGCuVvMN3HGQ6x4wDFjgloe7FrkGS6jvvHE7VOnw7oiyyiGZb/jKfPWOkdms ngwaR2VgWpIA3+E0U0hgr/bMnq08/pV4sPm2rqfa1pXuz83qmrFImKlJ8l1WIfkzulXJ UMZJBct587oM7Oe0+AxHzerPK8+j20SFnbe6DqUaC6a49E9pUNX80oqY+dDmMCJF2Jqw yu2LUbottrNmyjngw0wiEB8Uu3ahuhzxikYmYeanamRSvgSkG97H1fCq5owPO/LhwIC7 E3KQ== X-Gm-Message-State: AFeK/H1QpPNpNeZkdqAoOMQjW9atRLiCorlx9097WoWcMOfDozSNpusPedStKZqhgSEbE5WRwOEVYb7U7KeDWjoE X-Received: by 10.202.0.141 with SMTP id 135mr7488750oia.166.1489768479990; Fri, 17 Mar 2017 09:34:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.41.226 with HTTP; Fri, 17 Mar 2017 09:34:39 -0700 (PDT) In-Reply-To: <878to4qo4p.fsf@nordberg.se> References: <878to4qo4p.fsf@nordberg.se> From: Wei Chuang Date: Fri, 17 Mar 2017 09:34:39 -0700 Message-ID: To: Linus Nordberg Cc: trans@ietf.org, dane@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a1137a09a11917f054aefc1e3" Archived-At: Subject: Re: [dane] [Trans] CT for DNSSEC X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 16:34:44 -0000 --001a1137a09a11917f054aefc1e3 Content-Type: multipart/alternative; boundary=001a1137a09a0cc16d054aefc120 --001a1137a09a0cc16d054aefc120 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On Fri, Mar 17, 2017 at 1:54 AM, Linus Nordberg wrote: > Wei Chuang wrote > Thu, 16 Mar 2017 10:09:44 -0700: > > > spoofing the child zone. Is there still interest in this? From the list > > archives, I can't see what the issues were though I'm guessing one of > them > > was respecifying the DS resource record to use a SCT which might have > > caused compatibility concerns. (But please correct me if I'm wrong) > Other > > than that, the draft seems pretty reasonable. Were there other concerns? > > I'm still interested in logging things DNSSEC. The test log set up at > the IETF Berlin hackathon [0] is still running [1]. Oh cool. Taking a look. Did things just pause due to benign neglect? -Wei > We lack a client for > submission. > Protocol deviations from draft-zhang-trans-ct-dnssec-03 are summarized > in [2]. > > [0] https://lists.sunet.se/pipermail/dnssec-transparency/ > 2016-July/000049.html > [1] curl -A "" -x socks4a://127.0.0.1:9050/ -s > http://teowuafdvio2mip5.onion/dt/v1/get-sth | json_pp > --8<---------------cut here---------------start------------->8--- > { > "tree_head_signature" : "BAMARjBEAiA48+vqfg2O3ZbVYvlMxof2dzLwJ09gPtdY > 3FGtq1LbaAIgXWD4qfCOh38JzCz52E1B1cdkI+8+gHitA1DNMC4Zl2g=", > "timestamp" : 1489739801931, > "tree_size" : 1, > "sha256_root_hash" : "OQFz17e1piHRfRRsAG3QkweRuq/jyrjViq+vZbkyY+I=" > } > --8<---------------cut here---------------end--------------->8--- > [2] https://git.nordu.net/?p=user/linus/catlfish.git;a=blob_ > plain;f=README-dnssec.md;hb=refs/heads/dnssec2 > --001a1137a09a0cc16d054aefc120 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit


On Fri, Mar 17, 2017 at 1:54 AM, Linus Nordberg <linus@sunet.se> wrote:
Wei Chuang <weihaw@google.com> wrote
Thu, 16 Mar 2017 10:09:44 -0700:

> spoofing the child zone.  Is there still interest in this?  From the list
> archives, I can't see what the issues were though I'm guessing one of them
> was respecifying the DS resource record to use a SCT which might have
> caused compatibility concerns.  (But please correct me if I'm wrong)  Other
> than that, the draft seems pretty reasonable.  Were there other concerns?

I'm still interested in logging things DNSSEC. The test log set up at
the IETF Berlin hackathon [0] is still running [1].

Oh cool.  Taking a look.  

Did things just pause due to benign neglect?  

-Wei
 
We lack a client for
submission. 

Protocol deviations from draft-zhang-trans-ct-dnssec-03 are summarized
in [2].

[0] https://lists.sunet.se/pipermail/dnssec-transparency/2016-July/000049.html
[1] curl -A "" -x socks4a://127.0.0.1:9050/ -s http://teowuafdvio2mip5.onion/dt/v1/get-sth | json_pp
--8<---------------cut here---------------start------------->8---
{
   "tree_head_signature" : "BAMARjBEAiA48+vqfg2O3ZbVYvlMxof2dzLwJ09gPtdY3FGtq1LbaAIgXWD4qfCOh38JzCz52E1B1cdkI+8+gHitA1DNMC4Zl2g=",
   "timestamp" : 1489739801931,
   "tree_size" : 1,
   "sha256_root_hash" : "OQFz17e1piHRfRRsAG3QkweRuq/jyrjViq+vZbkyY+I="
}
--8<---------------cut here---------------end--------------->8---
[2] https://git.nordu.net/?p=user/linus/catlfish.git;a=blob_plain;f=README-dnssec.md;hb=refs/heads/dnssec2

--001a1137a09a0cc16d054aefc120-- --001a1137a09a11917f054aefc1e3 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMZN1N4N3KNCF5ZBTQMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTAyNjE4NDI0NVoXDTE3MDQy NDE4NDI0NVowIjEgMB4GCSqGSIb3DQEJAQwRd2VpaGF3QGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDiNpZ5E2IqcxktrcD1X5jWksphe1Ur882fsZM99Y4hiVugSVOb zIZIxoh3ckmGpUFyK1un6AU9Rxq9GSSkRskGAaSGrGcy7ncPi7Z1NlOJN25oXFmzituZsZeYIs0S QqT9hlDpLGc95r1CpsuTlaIB8m9Uvi+H6sGecVb2TOuGbRViQIWWf5GWk2AlJYhBFyJv7regqVa8 v3fx6SLkn/hIzBQf7xpVJzG6kAa09ZE0LoPdp5YV+Hv38EqDOWjm+g6Qbh1NADhdGpbmQDp9kdlm 6WZjCMwryQukdCypLKI2BPa08F18LZktaQNlJ2s7VxDJj2ozxomeBpSK6rxSxLAjAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRF3ZWloYXdAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFIMwgx+nNfYP3NyOZfiHYydFyNdQMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAO0J2vGX8ye90RegS3 HS+OE2hGEdDYJlR+S9ZSpla5AC9eejUKUc9JZR3y0ocGeQ3FQyXjM5/azBblqz/ajAbj2Fxuge45 SdRXrItDhAGWtQNl3utu2Uhf4y3re4ZRjApnhEBBX1l0E2BJuHf8MmqMhVU70Ko6Lk3lyPxnBeWo Q3tG2He3CNCkq/SDImq9vf8CNoxKxEkCP+kI+/NaCh5peLygU1h7Dc0ryWAcrxRWn8GUeEOg28MI vpwttw54cNR4YJYJVuiXCNc6PqkT/JxCiMvHS1woXJuET6QZSPtpNtvhNu90sV68Q7b2m6Vp8QTn xbzoEIHhiQWIcfphXjbeMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMZN1N4N3K NCF5ZBTQMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCDUIlITEsRov5vDDLGs/myh 8/zkNApTXGMOu23FppAVXjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzAzMTcxNjM0NDBaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAqfIflXrjEHNg44Sd7jDQ0gNFClq51akofvM/S4nr dDc+yJ8cOPqRUd9ItfTs2MiFaAiriCw+c5ImCqZZbk0ngp1DUGoSDWeA/Wx2hUZYufJTgp43c+Dz o/ukkQtFzIgKvYSjQDz3t9dht34c9zH4iGPwlMisBgXEGTx6lMAHUlm9vN3dil+kLhRBZ17CxBM/ cTeOfuTGvlsR9LkJYsTcaZ2CAtwwgltJvMqCl65tUrnWdkQYccMkL7VQkGqYA8+ZHdfjOGcDbBP2 VDgSkg11B5hqt7oxJ4Q1kFa/N4UBdL7btRrPHoB/GCTiJzMxEUKZF5tDspYUBKodxTYpxETghg== --001a1137a09a11917f054aefc1e3-- From nobody Fri Mar 17 11:20:14 2017 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 112D312706D; Fri, 17 Mar 2017 11:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DM9WpxKhWnHW; Fri, 17 Mar 2017 11:20:10 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 5E979124D68; Fri, 17 Mar 2017 11:20:10 -0700 (PDT) Received: from [10.32.60.17] (142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v2HIK0uI006297 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 17 Mar 2017 11:20:01 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176] claimed to be [10.32.60.17] From: "Paul Hoffman" To: "Wei Chuang" Cc: trans@ietf.org, dane@ietf.org Date: Fri, 17 Mar 2017 11:20:06 -0700 Message-ID: In-Reply-To: References: <455EC3FC-9140-40D3-88F8-77990B7C7DD0@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [dane] CT for DNSSEC X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 18:20:12 -0000 On 17 Mar 2017, at 9:31, Wei Chuang wrote: > On Thu, Mar 16, 2017 at 10:25 AM, Paul Hoffman > wrote: > >> On 16 Mar 2017, at 10:09, Wei Chuang wrote: >> >> I saw there was significant interest >>> in >>> exploring >>> CT for DNSSEC back in 2014 of which a draft >>> draft-zhang-trans-ct-dnssec >>> was >>> created. >>> It seems to have quieted down since. I believe the motivation is >>> still >>> there which is to prevent a parent zone from potentially misbehaving >>> and >>> spoofing the child zone. Is there still interest in this? From the >>> list >>> archives, I can't see what the issues were though I'm guessing one >>> of them >>> was respecifying the DS resource record to use a SCT which might >>> have >>> caused compatibility concerns. (But please correct me if I'm wrong) >>> Other >>> than that, the draft seems pretty reasonable. Were there other >>> concerns? >>> >> >> There were two separate issues that got conflated at the time: >> >> - Seeing evidence that a parent had spoofed DNSSEC keys for a child. >> A >> transcript of the DS records in the parent is sufficient as long as >> the >> child doesn't have relying parties create islands of trust (which is >> relatively rare these days). >> >> - Seeing evidence that a parent had spoofed any resource records for >> a >> child. A transcript of the NS records in the parents is a good start, >> although what is really needed is a transcript of everything that is >> seen >> for the child. >> > > Is this because you're worried about the parent removing evidence of > DNSSEC > for the child in the spoofing scenario? No, this is because the parent can spoof any data for the child. It is unrelated to DNSSEC. > If the parent tries to spoof with > DNSSEC for the child I would assume that seeing the DS SCT's in the > log, > that is sufficient to find evidence of spoofing. That said I think it > could be helpful to log NS as well for forensics. Transcripts are useful even when the logged data is not cryptographic. > One issue with logging all records seen is if webmail providers > publish > SMIMEA there will be a potentially overwhelming number of records > logged, > and a very large change rate. Don't log what you can't log due to scale. > Another issue is privacy of such records. Sure, but there are unpredictable privacy issues with lots of DNS record data. It's not possible for us to predict what will and will not be considered private information now or in the future for anyone other than ourselves. >> In both cases, having transcripts from various DNS looking glasses >> around >> the Internet would give greater assurance of the integrity of the >> transcript. > > > I agree that would a good idea. --Paul Hoffman From nobody Fri Mar 17 11:46:42 2017 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB546129406; Fri, 17 Mar 2017 11:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CsbjOFX-7Ugw; Fri, 17 Mar 2017 11:46:32 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B217128AB0; Fri, 17 Mar 2017 11:46:32 -0700 (PDT) Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 516B17A32F1; Fri, 17 Mar 2017 18:46:31 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Viktor Dukhovni In-Reply-To: Date: Fri, 17 Mar 2017 14:46:28 -0400 Cc: IETF DANE Mailinglist Content-Transfer-Encoding: quoted-printable Message-Id: <1DA6DC8F-CA06-4453-96E6-D8D257555437@dukhovni.org> References: <455EC3FC-9140-40D3-88F8-77990B7C7DD0@vpnc.org> To: trans@ietf.org X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [dane] CT for DNSSEC X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 18:46:34 -0000 > On Mar 17, 2017, at 2:20 PM, Paul Hoffman = wrote: >=20 >> Is this because you're worried about the parent removing evidence of = DNSSEC >> for the child in the spoofing scenario? >=20 > No, this is because the parent can spoof any data for the child. It is = unrelated to DNSSEC. With qname minimization, the parent will first need to deny an NS RRset for the child, and those DOE records are better candidates for logging than routine non-NS queries. So logging can be limited to NS/DS queries, but that still leaves us with the problem of how to avoid logging non-existence of NS/DS for all the sundry leaf nodes. The public suffix list might be a useful resource here... --=20 Viktor. From nobody Mon Mar 20 11:24:21 2017 Return-Path: X-Original-To: dane@ietf.org Delivered-To: dane@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 86344128D2E; Mon, 20 Mar 2017 11:23:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.47.2 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , dane-chairs@ietf.org, draft-ietf-dane-smime@ietf.org, dane@ietf.org, rfc-editor@rfc-editor.org, ogud@ogud.com, stephen.farrell@cs.tcd.ie MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <149003423854.25005.16070871053071588395.idtracker@ietfa.amsl.com> Date: Mon, 20 Mar 2017 11:23:58 -0700 Archived-At: Subject: [dane] Document Action: 'Using Secure DNS to Associate Certificates with Domain Names For S/MIME' to Experimental RFC (draft-ietf-dane-smime-16.txt) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.22 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 18:23:59 -0000 The IESG has approved the following document: - 'Using Secure DNS to Associate Certificates with Domain Names For S/MIME' (draft-ietf-dane-smime-16.txt) as Experimental RFC This document is the product of the DNS-based Authentication of Named Entities Working Group. The IESG contact persons are Stephen Farrell and Kathleen Moriarty. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-smime/ Technical Summary: This document proposes a method to publish and "locate" S/MIME keys via DNS. The goal of this approach is to make it easier to find S/MIME keys for email addresses. The document reuses a "method" from RFC7929 to convert email-address into a special normal form. that is limited but is expected to cover many cases. The S/MIME DNS record specified has been allocated by an Expert Review. While the method inherited from RFC7929 has some detractors, this is an experimental document, and that should not block the publication. Working Group Summary: The main issues that the WG has discussed are a) is it a good idea to publish email addresses in DNSSEC signed zone? b) is the role of the normalization from strictly a normalization or an obfuscation as well? The consensus of the WG is that as the publication is by the zone owner it is an opt-in policy, there is no requirement for adoption thus the issue need to be addressed in the light of each organizations polices, i.e this is not a protocol issue. There is working group consensus to advance this document. During AD review, the WG confirmed that they are ok to proceed even though the current IPR declaration (still!) says that licensing will be provided "later" Document Quality: This document is of high quality, and editors have been real good at making the document better. This document stands on the shoulders of RFC 7929 Personnel: Document Shepherd is Olafur Gudmundsson Responsible AD is Stephen Farrell From nobody Mon Mar 20 15:39:01 2017 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4A11293FF for ; Mon, 20 Mar 2017 15:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8bARRxXuB7D for ; Mon, 20 Mar 2017 15:38:50 -0700 (PDT) Received: from mail-ot0-x230.google.com (mail-ot0-x230.google.com [IPv6:2607:f8b0:4003:c0f::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 88449124B0A for ; Mon, 20 Mar 2017 15:38:50 -0700 (PDT) Received: by mail-ot0-x230.google.com with SMTP id x37so141945865ota.2 for ; Mon, 20 Mar 2017 15:38:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=okc7vQZGEZRHVLdxCBXF8dXyZ3JA67luP0SWOS4u2YQ=; b=UKNlnE3mI9S1r6z0kDQeQLWjaxxM9lCaorLwh1auLhfuiUztrEU1AT5sFdFwmyx25v jfl6qkVOTcpBe3dcaZ0VyVtY4d6iaryXGgQ44kXC01UZ6yzOYE5Vp3AeHedvaj73fcnK jbSphw2dspw4mQi0Lg/9XcgaYza16AVh1etznINZAvWqrp6L/+MH0pehFWke/PTk+jkA nN8ZkV/rLnOB6t7aep8hxGMgotnfx/wTtn1/bzkxqfsiMF1cqo86w45FnHz0hQWF7SZH j25wGy9DqQP5jqxaooC2dtuFOlyIbt1QsJxeUjJ94F4IriVO91G31v5POVI/TG/fmSRY 3D8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=okc7vQZGEZRHVLdxCBXF8dXyZ3JA67luP0SWOS4u2YQ=; b=KDxMo2HqZheCi7gmnjx9GN7YBLgrpecXFji21BjlngxsRx+WjmNWOTXIa23xd4LXy/ ccto16NhTCnJZ7uJKPbU6kiEVCFpNCITXsHPseCv7kcKsqvvtzq74lb0lJ8JcISDtc3d VVvx9aMPTxXbKoJFEhfAG+VHdPxsqnaqPPH3wZ3pfWSxs3j3k5qdxP66LU1yQVvfzlxU km4RC8xILa6Rd1L98bdJDCQqcqNHzitS6J2ZbeoqhpLfaYX2lKLf4qx5fw68HGpQVhQU ZzdE02RwkVYGPVaaWJeVj/WOwkjH9fVWUxZZbtu6L00jukM0WsXa5fomokDf0xJ4F4HF qhSw== X-Gm-Message-State: AFeK/H16iGvRYftpHaY8yP/hBvT4T3EquPWZGpyDKJx0NZxF7NDCPhEruetHPtvyg46b8NVM3Ki5+Eez12UK5Zgx X-Received: by 10.157.56.61 with SMTP id i58mr14948959otc.247.1490049529815; Mon, 20 Mar 2017 15:38:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.41.226 with HTTP; Mon, 20 Mar 2017 15:38:49 -0700 (PDT) In-Reply-To: References: <455EC3FC-9140-40D3-88F8-77990B7C7DD0@vpnc.org> From: Wei Chuang Date: Mon, 20 Mar 2017 15:38:49 -0700 Message-ID: To: Paul Hoffman Cc: trans@ietf.org, dane@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a113be8f6f0882c054b313016" Archived-At: Subject: Re: [dane] CT for DNSSEC X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.22 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 Mar 2017 22:38:53 -0000 --001a113be8f6f0882c054b313016 Content-Type: multipart/alternative; boundary=001a113be8f6ec7bb7054b313032 --001a113be8f6ec7bb7054b313032 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On Fri, Mar 17, 2017 at 11:20 AM, Paul Hoffman wrote: > On 17 Mar 2017, at 9:31, Wei Chuang wrote: > One issue with logging all records seen is if webmail providers publish >> SMIMEA there will be a potentially overwhelming number of records logged, >> and a very large change rate. >> > > Don't log what you can't log due to scale. Just a note of caution: Sometimes that might be hard to determine a priori deployment, and then the cause of cessation of logging might be inadvertently interpreted as malicious. It might be best to statically define which records are expected to be logged. > > Another issue is privacy of such records. >> > > Sure, but there are unpredictable privacy issues with lots of DNS record > data. It's not possible for us to predict what will and will not be > considered private information now or in the future for anyone other than > ourselves. Logging may defeat the privacy mechanism that SMIMEA and OPENPGPKEY naming scheme uses to prevent bulk disclosure of keys i.e. sec 7.4 in RFC7929. Much depends on the log implementation though. -Wei --001a113be8f6ec7bb7054b313032 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit


On Fri, Mar 17, 2017 at 11:20 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
On 17 Mar 2017, at 9:31, Wei Chuang wrote:
One issue with logging all records seen is if webmail providers publish
SMIMEA there will be a potentially overwhelming number of records logged,
and a very large change rate.

 Don't log what you can't log due to scale.

Just a note of caution: Sometimes that might be hard to determine a priori deployment, and then the cause of cessation of logging might be inadvertently interpreted as malicious.  It might be best to statically define which records are expected to be logged.
 

Another issue is privacy of such records.

 Sure, but there are unpredictable privacy issues with lots of DNS record data. It's not possible for us to predict what will and will not be considered private information now or in the future for anyone other than ourselves.

Logging may defeat the privacy mechanism that SMIMEA and OPENPGPKEY naming scheme uses to prevent bulk disclosure of keys i.e. sec 7.4 in RFC7929.  Much depends on the log implementation though.

-Wei
 
--001a113be8f6ec7bb7054b313032-- --001a113be8f6f0882c054b313016 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMZN1N4N3KNCF5ZBTQMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTAyNjE4NDI0NVoXDTE3MDQy NDE4NDI0NVowIjEgMB4GCSqGSIb3DQEJAQwRd2VpaGF3QGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDiNpZ5E2IqcxktrcD1X5jWksphe1Ur882fsZM99Y4hiVugSVOb zIZIxoh3ckmGpUFyK1un6AU9Rxq9GSSkRskGAaSGrGcy7ncPi7Z1NlOJN25oXFmzituZsZeYIs0S QqT9hlDpLGc95r1CpsuTlaIB8m9Uvi+H6sGecVb2TOuGbRViQIWWf5GWk2AlJYhBFyJv7regqVa8 v3fx6SLkn/hIzBQf7xpVJzG6kAa09ZE0LoPdp5YV+Hv38EqDOWjm+g6Qbh1NADhdGpbmQDp9kdlm 6WZjCMwryQukdCypLKI2BPa08F18LZktaQNlJ2s7VxDJj2ozxomeBpSK6rxSxLAjAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRF3ZWloYXdAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFIMwgx+nNfYP3NyOZfiHYydFyNdQMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAO0J2vGX8ye90RegS3 HS+OE2hGEdDYJlR+S9ZSpla5AC9eejUKUc9JZR3y0ocGeQ3FQyXjM5/azBblqz/ajAbj2Fxuge45 SdRXrItDhAGWtQNl3utu2Uhf4y3re4ZRjApnhEBBX1l0E2BJuHf8MmqMhVU70Ko6Lk3lyPxnBeWo Q3tG2He3CNCkq/SDImq9vf8CNoxKxEkCP+kI+/NaCh5peLygU1h7Dc0ryWAcrxRWn8GUeEOg28MI vpwttw54cNR4YJYJVuiXCNc6PqkT/JxCiMvHS1woXJuET6QZSPtpNtvhNu90sV68Q7b2m6Vp8QTn xbzoEIHhiQWIcfphXjbeMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMZN1N4N3K NCF5ZBTQMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCCpyfftbQhDa4oWWIvlnGt4 6KSQXqnbCjUmo/smSFGhsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzAzMjAyMjM4NTBaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAQDDR9oXjtB7E/h2Ow1b9jrqocC3T+s4XpiWv+DqK ZAe1zDyqDeJTiNtGFyWOLuzXfSpsLlDKVS96k02pNs7CVkoQjwEMK+RcfLcFFXVIr9Pbva68I996 PJJ0a0RhRozCvlfmwwsOVZa5VIg+ZK+PpNVPymgxAWy33hvrOKkrC/96UCpvdx0iHQA7Kil7iKz8 9vqvaqBsmQQDrq/LwCGRfm6kPruwHuZKD31LsTHxnqfvnrKPVHpNBNcD0abP9dyBiIjbgdS2MzYw b3TwV6DCd76/LM0e35AdhHy84nRPBDtBBoPsHodLLpg+JG1BuCVfvOmOnUODCccLDXeW4Jmt+w== --001a113be8f6f0882c054b313016-- From nobody Mon Mar 20 15:43:26 2017 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 957A912940A for ; Mon, 20 Mar 2017 15:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QkfJmymvjZNe for ; Mon, 20 Mar 2017 15:43:22 -0700 (PDT) Received: from mail-ot0-x233.google.com (mail-ot0-x233.google.com [IPv6:2607:f8b0:4003:c0f::233]) (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 60E17129406 for ; Mon, 20 Mar 2017 15:43:22 -0700 (PDT) Received: by mail-ot0-x233.google.com with SMTP id x37so141995665ota.2 for ; Mon, 20 Mar 2017 15:43:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gDcRzWQoSAq1B9gXpijFx6XNnVxsXdZ7E90t1y3wKW4=; b=hVQs1MTzu/jz6Ve+nIQ168o/djObkVUm0nV9dqx/YOu1TjMOcHxZ74qtdzr5nWxPOW 0cLoGz9odEeEmyHIBNmDUXbM/SDONBx2K/BCqpDFUmDkdwiQRkdmB6grsev5rkPbgKB+ 1Xsv2leRuysaNfJjtJhj83ycwmVMLBuFcEz8+7zH+YQZealOY837FGzIc9FQroVv5llq 95KKIYat+lZbQAFUoWyOe2tFncBQ2e35qL1y2f9cVGgz7hiGJX50CcVuGOawgkdiyj83 r+Z3MoCEcmH9L5bPGf1c+NnUALy0jP5v+rLBxWumOTKi9CWzauaObMgpqj9F7MagrVk2 HBHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gDcRzWQoSAq1B9gXpijFx6XNnVxsXdZ7E90t1y3wKW4=; b=iW7Bv09oA4yU4z1CgzjhwjuEtQCUOyH4ZVAHGHmAH9HhIlMrJMdAHUN+V8ktCa3nmu E6N+lwbFScgUPS+mW4j3cqId8Zu9RfRwtw4kf3Gb1bhXwp9GZawZ/IuHziE7XxbruQMn X4C5dPtwFTGCT0U4cc+7ZmzG4vrO4b8TZ4jdIafuJ8ZuvXC/FdsV06Y1r3f5DuB06aLt tr7MfODh29ilRRsLvYUeif9fHXICMdG0Bkslhe1B1IvT2J8jMOJ75KE638YvWiHFRvhF Erxrs0z2exxW+1+gFVYhl1PJySBg+P/VPAGJ/3SMTAvBuP+ryAM3LkBq39o9JzRae1la K3MA== X-Gm-Message-State: AFeK/H12FwoSg0Uc5mqAcbVvWeUykMx/s1bvoz+oiLN5IFUXfDVcKPUF+8cP15x4l1sybdt65V9l2imkQQVCT9ey X-Received: by 10.157.15.147 with SMTP id d19mr14923765otd.233.1490049801694; Mon, 20 Mar 2017 15:43:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.41.226 with HTTP; Mon, 20 Mar 2017 15:43:20 -0700 (PDT) In-Reply-To: <1DA6DC8F-CA06-4453-96E6-D8D257555437@dukhovni.org> References: <455EC3FC-9140-40D3-88F8-77990B7C7DD0@vpnc.org> <1DA6DC8F-CA06-4453-96E6-D8D257555437@dukhovni.org> From: Wei Chuang Date: Mon, 20 Mar 2017 15:43:20 -0700 Message-ID: To: Viktor Dukhovni Cc: trans@ietf.org, IETF DANE Mailinglist Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a113d196a247694054b314154" Archived-At: Subject: Re: [dane] [Trans] CT for DNSSEC X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.22 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 Mar 2017 22:43:25 -0000 --001a113d196a247694054b314154 Content-Type: multipart/alternative; boundary=001a113d196a20fbbc054b3141b5 --001a113d196a20fbbc054b3141b5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On Fri, Mar 17, 2017 at 11:46 AM, Viktor Dukhovni wrote: > > > On Mar 17, 2017, at 2:20 PM, Paul Hoffman wrote: > > > >> Is this because you're worried about the parent removing evidence of > DNSSEC > >> for the child in the spoofing scenario? > > > > No, this is because the parent can spoof any data for the child. It is > unrelated to DNSSEC. > > With qname minimization, the parent will first need to deny an NS > RRset for the child, and those DOE records are better candidates > for logging than routine non-NS queries. Can you expand on how the the DOE record (which I assumes means denial-of-existance) could work with an adversarial parent? The only approach I can think of is some sort of UI support which isn't very compelling. (Perhaps monitors but alas I not really up-to-date where things are at with monitors and gossip) > So logging can be limited > to NS/DS queries, but that still leaves us with the problem of how > to avoid logging non-existence of NS/DS for all the sundry leaf > nodes. The public suffix list might be a useful resource here... > I agree. -Wei > > -- > Viktor. > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --001a113d196a20fbbc054b3141b5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit


On Fri, Mar 17, 2017 at 11:46 AM, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:

> On Mar 17, 2017, at 2:20 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
>
>> Is this because you're worried about the parent removing evidence of DNSSEC
>> for the child in the spoofing scenario?
>
> No, this is because the parent can spoof any data for the child. It is unrelated to DNSSEC.

With qname minimization, the parent will first need to deny an NS
RRset for the child, and those DOE records are better candidates
for logging than routine non-NS queries.

Can you expand on how the the DOE record (which I assumes means denial-of-existance) could work with an
adversarial parent?

The only approach I can think of is some sort of UI support which isn't very compelling.  (Perhaps monitors
but alas I not really up-to-date where things are at with monitors and gossip)
 
  So logging can be limited
to NS/DS queries, but that still leaves us with the problem of how
to avoid logging non-existence of NS/DS for all the sundry leaf
nodes. The public suffix list might be a useful resource here...

I agree.

-Wei
 

--
        Viktor.

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

--001a113d196a20fbbc054b3141b5-- --001a113d196a247694054b314154 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMZN1N4N3KNCF5ZBTQMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTAyNjE4NDI0NVoXDTE3MDQy NDE4NDI0NVowIjEgMB4GCSqGSIb3DQEJAQwRd2VpaGF3QGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDiNpZ5E2IqcxktrcD1X5jWksphe1Ur882fsZM99Y4hiVugSVOb zIZIxoh3ckmGpUFyK1un6AU9Rxq9GSSkRskGAaSGrGcy7ncPi7Z1NlOJN25oXFmzituZsZeYIs0S QqT9hlDpLGc95r1CpsuTlaIB8m9Uvi+H6sGecVb2TOuGbRViQIWWf5GWk2AlJYhBFyJv7regqVa8 v3fx6SLkn/hIzBQf7xpVJzG6kAa09ZE0LoPdp5YV+Hv38EqDOWjm+g6Qbh1NADhdGpbmQDp9kdlm 6WZjCMwryQukdCypLKI2BPa08F18LZktaQNlJ2s7VxDJj2ozxomeBpSK6rxSxLAjAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRF3ZWloYXdAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFIMwgx+nNfYP3NyOZfiHYydFyNdQMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAO0J2vGX8ye90RegS3 HS+OE2hGEdDYJlR+S9ZSpla5AC9eejUKUc9JZR3y0ocGeQ3FQyXjM5/azBblqz/ajAbj2Fxuge45 SdRXrItDhAGWtQNl3utu2Uhf4y3re4ZRjApnhEBBX1l0E2BJuHf8MmqMhVU70Ko6Lk3lyPxnBeWo Q3tG2He3CNCkq/SDImq9vf8CNoxKxEkCP+kI+/NaCh5peLygU1h7Dc0ryWAcrxRWn8GUeEOg28MI vpwttw54cNR4YJYJVuiXCNc6PqkT/JxCiMvHS1woXJuET6QZSPtpNtvhNu90sV68Q7b2m6Vp8QTn xbzoEIHhiQWIcfphXjbeMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMZN1N4N3K NCF5ZBTQMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCBiv5w2bo+hjqTbVErfHTBD L6oUGk4Vdrf5IU1TX3QKvjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzAzMjAyMjQzMjFaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAPKCh3tsXo5rD3qcz3t2NSEeQldXvGiHBiSQsGWmS PfbdzpKoao2B5BxLf2cXih71G7v09xg8Ai4iaGc4E9cIkb/AHVj5DOsVYFadBea2HRuw/WVAAeQ+ bdzhzkbygvNTy1TxP0UpKHmlwXbEmTJ2Sd92rjdt1y7neT1Dbm9xXRF/jYUA/R5Rc1h/bFd/Fpzb naIAvBCoEcSKpoVRnxmpxHJAPKVuJgPPodxvJXIv2RwW4ODjoITOkPflNjFWU62Pbh6GotIJIla6 D2C9aWjofzgqjRPhPZHn8e5sV8xYohAFyxRWmrgi7ad26GT5marjTW8AHMB1euvpBBFP/1TXRw== --001a113d196a247694054b314154-- From nobody Mon Mar 20 16:01:07 2017 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80387127077; Mon, 20 Mar 2017 16:01:00 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wXIy7ARaWSY9; Mon, 20 Mar 2017 16:00:58 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A40F6126D85; Mon, 20 Mar 2017 16:00:58 -0700 (PDT) Received: from [172.31.30.83] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id BD8047A32F1; Mon, 20 Mar 2017 23:00:57 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Viktor Dukhovni In-Reply-To: Date: Mon, 20 Mar 2017 19:00:56 -0400 Cc: IETF DANE Mailinglist Content-Transfer-Encoding: 7bit Message-Id: <9FC39E28-4285-40F8-8FE9-283FA83B1A0A@dukhovni.org> References: <455EC3FC-9140-40D3-88F8-77990B7C7DD0@vpnc.org> <1DA6DC8F-CA06-4453-96E6-D8D257555437@dukhovni.org> To: trans@ietf.org X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [dane] [Trans] CT for DNSSEC X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.22 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 Mar 2017 23:01:00 -0000 > On Mar 20, 2017, at 6:43 PM, Wei Chuang wrote: > >>> No, this is because the parent can spoof any data for the child. >>> It is unrelated to DNSSEC. >> >> With qname minimization, the parent will first need to deny an NS >> RRset for the child, and those DOE records are better candidates >> for logging than routine non-NS queries. > > Can you expand on how the the DOE record (which I assumes means > denial-of-existence) could work with an adversarial parent? Yes, DOE is denial of existence. When the child sends NS queries as part of qname minimization a negative response (no NS records) will include signed NSEC(3) records to that effect, signed by the parent zone. These are candidates for logging. An insecure positive response will include NSEC(3) records proving the non-existence of the DS RRset (possibly via the opt-out flag). These can also be logged. A secure positive response, can also be logged, and the follow-up query for any associated DS records will again either yields an answer that can be logged, or DOE that can be logged. The key question is how to avoid logging ridiculous volumes of data that can DoS any log service and also disclose too much. Hence the suggestion to consider using the PSL as a cut-off mechanism. One would also not log NXDOMAIN responses to NS, which might allow parent domains to lie about non-existence, but is surely necessary to guard against filling logs with junk. There are likely many issues this fails to consider, but I think that's a reasonable starting point to explore further. -- Viktor. From nobody Tue Mar 21 10:33:16 2017 Return-Path: X-Original-To: dane@ietf.org Delivered-To: dane@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AACFE129B88; Tue, 21 Mar 2017 10:33:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF Announcement List" Cc: ogud@ogud.com, warren@kumari.net, dane@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.48.00 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ietf@ietf.org Message-ID: <149011759560.3514.17598713136353277030.idtracker@ietfa.amsl.com> Date: Tue, 21 Mar 2017 10:33:15 -0700 Archived-At: Subject: [dane] WG Action: Conclusion of DNS-based Authentication of Named Entities (dane) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.22 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 17:33:16 -0000 The DNS-based Authentication of Named Entities (dane) working group in the Security Area has concluded. The IESG contact persons are Stephen Farrell and Kathleen Moriarty. The mailing list will remain open. > Hi all, > > Now that the last pending DANE document has been approved we're > closing the WG as planned. We'll finish processing of that document as > usual. > > I'd like to thank the chairs and authors for all their fine work > over the last few years. > > Regards, > Stephen. From nobody Thu Mar 23 16:12:23 2017 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2A8A1292D3 for ; Thu, 23 Mar 2017 16:12:21 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPO9TQvKgQ4w for ; Thu, 23 Mar 2017 16:12:20 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::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 CF467127B31 for ; Thu, 23 Mar 2017 16:12:19 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id f11so6792794qkb.0 for ; Thu, 23 Mar 2017 16:12:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=AeMV5Mej/Vvg33VisXarjriTtVFfWSbIZYXqtcxbZzE=; b=PWX5+u14wfQxATYnJ4I2QkU+pkv/FtmILNZ6cfhZDbQ8AvAUVruQzqyOZmm/TCCaOT N7hrgJbi0LzEk7dfpyfQKhjOPDy6QjG5s6rJXg+8/5pxqg0oVffAM56lWDujjiRBAH5v ta5IRa5JiAJAUJnlCVgvt1tGyqiXTQAhQ9dJxSxaED41LKBIiXwzdwNtFA69suEOZ30k C+vZA68YD9Gp5Zv6DhaAcTRmNXsJC2mhm1shIJt/GTSQrUvHhvFhNR/mShyvo/zc/0X8 DRjfFKQ2TuRx+wEuD3SuiH4Du7V1c+kkpOl+ZzWaQE/pTxYREl0aeWLKgzARK/84a9ja z9Mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=AeMV5Mej/Vvg33VisXarjriTtVFfWSbIZYXqtcxbZzE=; b=uFS7XcHYTLtPOWU3VfK1ZHO4I15eAMhQUOqj19x+6t2ac4SeN2kBrqCt/JunE/mdIL Mw8DlYIgUgo6xW7fC4ewlMi2nU2oafaFT3b/9hT8W1FKXhed1wa/hoGqzRd1hrbdFIAV kTN78fgAptbNqfFlKCj6XoX+QqPN6VABV50dS115myaLrFmlmxy1c8cNJqSB/SdV1DIN GOSjBcHegrJ5U6HDqPlWwkhWPyeh4PRxP1MriQzN9KH9g1qw1txyG+XyGpDMQbNZLUo9 ycifnkvts3id/GKrhjFy1AKP1BlJ6fePOGgvJuAm7Yh6P0hvyYk5Q5VQbeHgW9YVjv+R xKyw== X-Gm-Message-State: AFeK/H14Cki7o6Rc4WqdiM5IIl67Rh4P+ABN+2IEFAqyEa5v1/ZR4eyI4bqce7LMZ+hSypA9OGCLxXNUeGqGLCoC X-Received: by 10.55.20.217 with SMTP id 86mr4521631qku.35.1490310738542; Thu, 23 Mar 2017 16:12:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.177.11 with HTTP; Thu, 23 Mar 2017 16:11:38 -0700 (PDT) In-Reply-To: <149011759560.3514.17598713136353277030.idtracker@ietfa.amsl.com> References: <149011759560.3514.17598713136353277030.idtracker@ietfa.amsl.com> From: Warren Kumari Date: Fri, 24 Mar 2017 00:11:38 +0100 Message-ID: To: "" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [dane] WG Action: Conclusion of DNS-based Authentication of Named Entities (dane) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.22 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, 23 Mar 2017 23:12:22 -0000 On Tue, Mar 21, 2017 at 6:33 PM, IESG Secretary wrote: > The DNS-based Authentication of Named Entities (dane) working group in > the Security Area has concluded. The IESG contact persons are Stephen > Farrell and Kathleen Moriarty. > > The mailing list will remain open. I'd like to quickly thank the working group participants for all of their hard work over the years. We sent ~9,600 emails (or ~1400 threads :-)), and published 8 documents (including draft-ietf-dane-smime). We also had some fun, made some friends, and learnt a lot. We are now seeing deployment in the mail world, and I think that we can be proud of what we've accomplished... Thanks again, W > >> Hi all, >> >> Now that the last pending DANE document has been approved we're >> closing the WG as planned. We'll finish processing of that document as >> usual. >> >> I'd like to thank the chairs and authors for all their fine work >> over the last few years. >> >> Regards, >> Stephen. -- 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 Thu Mar 23 16:20:21 2017 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66BF31292FD for ; Thu, 23 Mar 2017 16:20:19 -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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b2G4T9NUBpzu for ; Thu, 23 Mar 2017 16:20:17 -0700 (PDT) Received: from mail.witmond.nl (mail.wtmnd.nl [80.100.189.3]) by ietfa.amsl.com (Postfix) with ESMTP id B1F501293E1 for ; Thu, 23 Mar 2017 16:20:16 -0700 (PDT) Received: from [10.1.2.6] (unknown [10.1.2.6]) by mail.witmond.nl (Postfix) with ESMTPSA id 4FD00C0573 for ; Thu, 23 Mar 2017 23:20:15 +0000 (UTC) To: dane@ietf.org From: Guido Witmond X-Enigmail-Draft-Status: N1111 Message-ID: <967f5637-8b52-c71e-6f5a-e2f6dbf19632@witmond.nl> Date: Fri, 24 Mar 2017 00:20:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="x0fAKG5QSEpmEFjhC5V84c5MEqveiUgNd" Archived-At: Subject: [dane] Choice of PXIX-TA or DANE-TA X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.22 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, 23 Mar 2017 23:20:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --x0fAKG5QSEpmEFjhC5V84c5MEqveiUgNd Content-Type: multipart/mixed; boundary="------------65535B9491EDD540AF7DAEEA" This is a multi-part message in MIME format. --------------65535B9491EDD540AF7DAEEA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, I've this web site for which I've enabled a Let's Encrypt server certificate. Now I have the choice of either PKIX-TA (TLSA 0 x y) or DANE-DA (TLSA 2 x y) records, or both. My main question is: What's the value of choosing one above the other? If I chose PKIX-TA, it means that a client who doesn't have the Let's Encrypt root certificate in their CA-store won't accept my certificate/si= te. On the other hand, if I chose DANE-TA, are there any clients who won't accept my certificate/site because it might not be part of the clients list of vakid CA's? Browsing the web, I hardly see any pages argue for PKIX-TA (0 x y) TLSA records. Is the consensus that DANE-TA is sufficient to make clients accept my site when the records match the site? In other words: which one (PKIX-TA or TLSA-TA) to chose? Cheers, Guido Witmond --------------65535B9491EDD540AF7DAEEA Content-Type: application/pgp-keys; name="0x2568D466.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x2568D466.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2 mQINBE1ZRIwBEAChXBlnDaYeekA6yGFkiEimNhuZ+I08b9qQM6B0PtKKzIVga8Yt NW+sTks9jgDV/aFhzD4jYAqwDJ4UMfuYlXKw8fyM2W9KkN6h16ja9+FnvWzxiFGa zgbyXxA69AMR7Z8PQ1WfukXAFsevmWabrB4jRxKo+kz/BTfQoF8hN+aqt5pVHvlt fmxVhJIdyfqyFIIM5cmDVFTmEeowqfXiP/youQP3+zRDYyDaQqFvTQIYfRwkE/SM uVTxFwlVqgmiHbwIjpVVONOqikwoKP7qsN4Gz1CyINTR47FeKFeq1R1YD/s8CezV /FF0Nhl/D7BAr8l6RVKCUmEPMgm+Jq3a4PFCEeOr00Ay3GO1gCwOVGiaz5vgblN2 2aoOdD3pqs3hMzQUeO7mT7dKt97IPd7QxTcWv5T8gbyR9dd3GnvrqI6JEJ1x1nK1 RSOw+Abv0DbM/Ej2K2tSsvPYbebIcTDWqf3+TRbcpfVTBi4tJhY+ohrPH+gRo2IN JwnVNAqIiz63yoMK6zHIcCBQaGNRQJynr2z9k7sQsGKGJAhbwISww2KiR48iUCP/ e7JfxqWWV5416GovnpMDD6gWn5UEl0XZwqPaxrYrGt5otyFpU8WLyQJ4Qr7tSmk9 fDI+/KjquG+jCx2v+FR3uDdWyBhI9PzK9J8A7emC/yaAf0qadiNqFgP+BQARAQAB tCBHdWlkbyBXaXRtb25kIDxndWlkb0B3aXRtb25kLm5sPokCOwQTAQIAJQIbAwYL CQgHAwIGFQgCCQoLBBYCAwECHgECF4AFAlIi/MQCGQEACgkQc93waCVo1GYDmxAA i8T4NIOjY9pfgGcnlhS1xVgmvuJXJmcteLoJQVpshujnYNX7Rz5PvBupA66RdFpm oi6OIwMnAfWWUK9tnKiw/nl+Uki2SV3bnlg07UiKRy/Zk7bxk/t7DQVSGN2bg0RQ dHwFc0qc5JfF2RR9rH9zrDbbBvwTmGqMUnFFLTqWHb1VYjQsZp+7z8syUN5BZhVg eoQBneSOSOPKCrOMTmOttlTOuijqkvxFw/1n4VoLLEs2AnwDDm2X+46/BlQoHxvz wY7Q6hF6unXdKD/AWn9FmMvKtB9md4kPMcpLQ2LhFqq0oWjP6Pn5Ic0p/OikIyNl m+bnba7KZ36p0he9Ckm1gQiH03UrDzwc/Y6MBKRIeP4BlOBumYZMOvoLIu4teByW X4RzEw/jT21f9g8i4zUbJTGT4n38ZSurcTRGW5ufNCojg1cOsvh134zY5FmXYUt4 myrpgrlhYqXUcOPGuMx7zjGkQjNLXt1t8VyGPqHTxVnKZKscto6rkrBsYjj4CIJh 6YdodwEUw1J+e4qq2c3C1J8cyQH7Qnpbs7dkC57yVWZc4aW0K1TwP2lNs73af7jZ gWAv7CYE7BkwndQQYIUyaYm0PepbmO9aEXqTiDEFDAZqeKoTa91VLApgWsaYH3CL QVY/Sa06YXh/YCYN9Eeu5Y5Gkz5obIImW+lwLnsyaP6JAjgEEwECACIFAk6hocIC GwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEHPd8GglaNRmbtEP/R9Xiimr V8yE6PjHLeh5NohrZ4vhFYo6kJyn168yKQUzDu/GDQbRsA6PUrKrWyQge1cOuGBA HXJPxxuIfuceOWMf9nCYIWeFvqr/TlzMArZQcWSPqOKrX6LVCh37wcEts1LVPmr9 bwAwqFpyy86EU81q5fpbbyC2UGUFH7pYW4/ZFuB9XxpHJh2A7I6UDZRamVVFHHTl eJSqMWexwfLM6ZaM+MDuJ8cBZ3TK5cljYyrq35Bp7stUhbvg6KrTT80cEGRbZUWD /JNcCNy3QWl2eVfjVPnJ/hjP8dxK94UDdNd2Z/h5o00Y8AUeBbpmpqxODL5HBnkS g9rWDmzX0UClrrR7l2Qix/5gydMFPc2oK09pRtqj5JNkqGHZHWrzNmiKmbn4YCge +5DOetZtAQsyMNiSJp1MsTuUBLypVGwRU3eNYJZOchs26h4iztWPWRexY3WKFpH3 PDSKk/+Xlu7fgWKGC7pEA9om8ozg09V4FJM1QB75H7Y7AdFXYz9jIdjhFJNlC7pN fnwaTGs7nFKO7k54FcBv37HEm2HXoj2GRBP5Pa56jCYk6iRyGDiLjc/Ze3VUcVZz R30XHBLltV7CqXT8rYZlpeYTofxdoZFFSt4QhvI3EhFQY1VTu67Q9CbppLKHbQEj PVUMAvhY4XiX/3TcYnH+eV5m2ipMHu0W/8H7uQINBE1ZRIwBEADlcs8ETrz0ZYhC Cz7KqSZGpVMbKr1uJ3HAhMOSTa1v7fGXFeZ5ZSIs8kk+QUuYjstsaAwjcoK13wPR 2qomqIIP56YM0faFyFXlSSS18Oh6l2qes4hagyXNNZNqJ4F9V9g8XVKHHw0SY/F3 izdM8rvkzmeAfeQZudXjZevwmrpa6Ks0Esd5wcJfu+Tu4XEDgeCk0X97zP05ZZq5 KPb2iwW8aqRfBtenPPlvddGDAI816EcKhxuEnK2q6hnGxTLv81GTgYUMvAw39XUj wKcTK6npVMT669stz34ly7+RiHobTfeJG9QUqCYkDej/VtlSIWzO2f6HOtFzFmN1 lpCDCKVkNRAjsV72mZ2e6dfIYgsDCHoonWU91AK7i6Qe5Ll9NsCopiW/6+FKPOMo SoLsOlp5BkPkVn75Z1KpjjaqqJVNp652X4qqfGv6t3vWdo++3czjMBeL5Tg31Gxu wpxua8lnTw5n4taGk9PpndT3cOdtJZH/BJfVEoabHhhn/MinQL/TgGoxGC2oyPag ec6xdBNdzNLNv86UGlpZqIDg3J7lrcBW56WcWw3C2QbC/Y+kYXAj8h7U6xHiG3fX DaqvDiuXJbWsQkKlp2MFch7y7DaqP9cz4sbVZBhPBm621mBrYpPKSrUJ9KCxbmgP aw92UNJd1LVWKOqs33owdAsu3yRRcQARAQABiQIfBBgBAgAJBQJNWUSMAhsMAAoJ EHPd8GglaNRmtj4P/3BQVb9e0JnTldL5Zu0ZaWMKRk/OlZhzH6MDc3iVGquAqY72 5QkBdl8vShE9y/SiySaDSlNQBMtI1xeS6o2oV4Wzh2jspHC5GHUcvrxIcIDoPm2j lcZqOvgwdxOUfgWxUH6RxfcbJRLan684drCKxk5SD6qQGN6BFF3pvGTc/eFv4BuS WtwIYYRKHYlJpBSlMxJkqN75QHB0ZKqqXuQCmqgUlPYyc6qOcWJSYIAY62EOJxHw RKRM3tjSUrZ3swvZ7ERdLamIMfegGMxZp0+M6yy9FaiLiXr14WB/5dHT0CXJ1wJD gw8XxjVIjE1rgUnkhCiPAzEe+vexoCXoH4XQMarUFO+cSbAsGtO7nQygDDh1uX32 OaiciCBN9K5R/7wm13mjH8d3+PbPgmsm70IWBzjFXIcW9YX09XXnFfM2MAHTpfPD jzdsIgw56GjZWEGbmw7KNWrYJ5run3+ffGyoldmabTI7nwVtvSuY0k4StwzDOBQ3 X6sSzVt3dir3LMklS7obR64ruMQ8Dl9KcMdieNJZdFsfppv+vLW/Mdr1Ay0lTu7X nIUqCyVOM+T9FpBUb++1gmvH9q2fDsW6gMQa5sc2qFslKp/FUG9t6HX/I/cHlKQ3 w7k3W6wQmvx+yeHLOE7QTgaxEfzTUMXAm4pddlrYGnZn/hQfPGuf/BL/NXF2 =3D5lY2 -----END PGP PUBLIC KEY BLOCK----- --------------65535B9491EDD540AF7DAEEA-- --x0fAKG5QSEpmEFjhC5V84c5MEqveiUgNd 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 iQIcBAEBCAAGBQJY1FguAAoJEHPd8GglaNRm98MQAJQEnMU5Ihtw4hB5sziPEFAx Al+qhs3dy1DizgEzhn6Q/Xkz0JJglbLjAEJsYgEKZIRhN12jEhCxsAJ6iacUvOkJ HEKY4CBkQWwoYyCQ8OX1Weeycxao5G7hGBMgMI86m2VXU/ZI5rtrnNl76X4ch6H/ DrMkdfit1i/kv5+iV5eHCw7id/31P93DNZOf2pIgUR39xUeqHQjimVH/RPvyJWf4 F/XWwgmTElDDYE6sqQOTqfETnYlA+RqGz9PcA3rE5WEz92NQ4z4RklsKFaS+AQdv v0HMdYkp++CrIN+2/2masolexuITydLSjSYECvpjHPRVGPkI8iHa2mj7s5Y3O9U1 fFJbm6C1fktlhZw7UULM24B52Q3CtN3YoHy/9ZOaTdT9QaatngUmLalG2HNTAlLy 8L/JtoxO4XAetRY5ZSomrt6cgEL4UiqvE8zag2fpIlNK2/4BeV9ZitWrRS6YjlpY czgIsJadt1HKJe+uv3134YvNRDWBKkO3vdN/HC5XiS8yFhIJUn1TEB2/znXZ2LjL UXUdMbPvm3SZwc6Xr68ycdYctLHRt4okEfAHCWvwvGZ+X1sn4B/LBwCpix3ifeQE BE0oE9eaxDcF37d/qD5QSUkXHHHrWNzLkHz4Cuhl5J9js64o+1sOIdxnYCS2fh2C N+QsvXj3ZS0vjUsQUhFI =RO23 -----END PGP SIGNATURE----- --x0fAKG5QSEpmEFjhC5V84c5MEqveiUgNd-- From nobody Wed Mar 29 07:33:13 2017 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A69DF129474 for ; Wed, 29 Mar 2017 07:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Ku8fvJWDp89 for ; Wed, 29 Mar 2017 07:33:05 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::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 E84FE12953D for ; Wed, 29 Mar 2017 07:33:04 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id z204so19783372vkd.1 for ; Wed, 29 Mar 2017 07:33:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OdU5jWePux8YPa9k+GrP/buXK2KM9V+/ybJMXtOWZHw=; b=IHmCVoQsfPWmzRphTRLgT8d7o60yTuvSpXqMB4CgRngy0+lc/L0c3oIdj2+c85j8Fw uLbRNp1CGUraIB52c/0RmqsPGe7QIcwPXc7xtH+0L7nSxNtJ+mER5LE6gXe8qCFsgknB WCh8ZJPUvpyCB0DUQeONw5K1sm1oZliXJcOVuCEy9cwP3OWi0d+LwvxN4irfYvX64uY6 mgZ049gWHWfWOD47gTXTkWnqNVH9FwgfMemi/eHc0c36JEtVd3FMn4Ltd5XGmn/OfriZ ClW5cxTEKUASHgpy4wzObl4/PT4Ol7omeKc27FPMtQ0RYJ5hjMiA3kHjl53QpgrRMEut 1/1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OdU5jWePux8YPa9k+GrP/buXK2KM9V+/ybJMXtOWZHw=; b=URrQw3E8DSr9nklEBLez6NM07JMQy1/OdaeoaXO11eRUlFsD+29B1+vXNi1Cv3bSOv /4YEiunELkD0e4jNFPaUt/u6vjMQjCqh7xUGb9ZGZixCJs2yI7p/hHYxTc0trtzWMMTA Mw9Khm2mmZwC/tfaec4HBbUnpX3adTOP6sitFejBA9gPP2t6g0WzWn90wP3WuohSJ8tr /cNTbEjp7tX3Jgk4P64v88m1mBTO5F96F01gWdVZJaIj+CAqxbpkPRbFisuNTkIYKt2w GsJx81WB1TcA0UGVSRoumttpdIy5KFYvbxR6RaYPQlFjTyT0GvfP6EVXHYrwuV8ndIPf RqAg== X-Gm-Message-State: AFeK/H055cEDpnlbQK8QxTYuf5Q31yLEG/aCxx6XuVoqd2upyg7IYe+XXg3LJwQSEFbuDajJH1HTbgWIZePLE6+0 X-Received: by 10.159.49.81 with SMTP id n17mr350521uab.178.1490797983570; Wed, 29 Mar 2017 07:33:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.8.6 with HTTP; Wed, 29 Mar 2017 07:33:02 -0700 (PDT) In-Reply-To: <9FC39E28-4285-40F8-8FE9-283FA83B1A0A@dukhovni.org> References: <455EC3FC-9140-40D3-88F8-77990B7C7DD0@vpnc.org> <1DA6DC8F-CA06-4453-96E6-D8D257555437@dukhovni.org> <9FC39E28-4285-40F8-8FE9-283FA83B1A0A@dukhovni.org> From: Wei Chuang Date: Wed, 29 Mar 2017 09:33:02 -0500 Message-ID: To: Viktor Dukhovni Cc: trans@ietf.org, IETF DANE Mailinglist Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="f403045ddecc465c77054bdf7477" Archived-At: Subject: Re: [dane] [Trans] CT for DNSSEC X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.22 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 Mar 2017 14:33:08 -0000 --f403045ddecc465c77054bdf7477 Content-Type: multipart/alternative; boundary=f403045ddecc3efcbe054bdf749b --f403045ddecc3efcbe054bdf749b Content-Type: text/plain; charset=UTF-8 Thanks very much Viktor that explanation of NSEC(3). Just one follow up idea: On Mon, Mar 20, 2017 at 6:00 PM, Viktor Dukhovni wrote: > > > On Mar 20, 2017, at 6:43 PM, Wei Chuang wrote: > > > >>> No, this is because the parent can spoof any data for the child. > >>> It is unrelated to DNSSEC. > >> > >> With qname minimization, the parent will first need to deny an NS > >> RRset for the child, and those DOE records are better candidates > >> for logging than routine non-NS queries. > > > > Can you expand on how the the DOE record (which I assumes means > > denial-of-existence) could work with an adversarial parent? > > Yes, DOE is denial of existence. When the child sends NS queries > as part of qname minimization a negative response (no NS records) > will include signed NSEC(3) records to that effect, signed by the > parent zone. These are candidates for logging. > Understood now I think. > The key question is how to avoid logging ridiculous volumes of > data that can DoS any log service and also disclose too much. > +1 as this is logging NSEC(3) would make the logging rate proportional to all RR churn. Let put out an idea to attempt to mitigate this. (And apologies ahead of time if this is obviously wrong as I'm pretty new at DNS/DNSSEC) For this, the main thing this is trying to track is the existence of DS and its DOE. Why not create an explicit Non-existence of DS (NDS) RR that gets logged along with DS and NS? The effect is then is that every NS will then have either a DS or NDS RR. Then the rate of logging becomes proportional to max of NS and DS changes. I suspect NDS won't have the same enumeration problems as the NSEC(3) since lacks next-signed link, and is paired with an NS record anyways. Also NDS does not change NSEC(3) behavior DOE behavior. (To be complete there could be a policy declaration mechanism for this but that's details). -Wei --f403045ddecc3efcbe054bdf749b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks very much Viktor that explanation of NSEC(3).=C2=A0= Just one follow up idea:

On Mon, Mar 20, 2017 at 6:00 PM, Viktor Dukhovni <ietf-da= ne@dukhovni.org> wrote:

> On Mar 20, 2017, at 6:43 PM, Wei Chuang <weihaw@google.com> wrote:
>
>>> No, this is because the parent can spoof any data for the chil= d.
>>> It is unrelated to DNSSEC.
>>
>> With qname minimization, the parent will first need to deny an NS<= br> >> RRset for the child, and those DOE records are better candidates >> for logging than routine non-NS queries.
>
> Can you expand on how the the DOE record (which I assumes means
> denial-of-existence) could work with an adversarial parent?

Yes, DOE is denial of existence.=C2=A0 When the child sends NS queries
as part of qname minimization a negative response (no NS records)
will include signed NSEC(3) records to that effect, signed by the
parent zone.=C2=A0 These are candidates for logging.
<= br>
Understood now I think.


The key question is how to avoid logging ridiculous volumes of
data that can DoS any log service and also disclose too much.

+1 as this is logging NSEC(3) would make the logging= rate proportional to all RR churn.
=C2=A0
Let put out = an idea to attempt to mitigate this. =C2=A0(And apologies ahead of time if = this is obviously wrong as I'm pretty new at DNS/DNSSEC) =C2=A0 For thi= s, the main thing this is trying to track is the existence of DS and its DO= E.=C2=A0 Why not create an explicit Non-existence of DS (NDS) RR that gets = logged along with DS and NS?=C2=A0 The effect is then is that every NS will= then have either a DS or NDS RR. =C2=A0 Then the rate of logging becomes p= roportional to max of NS and DS changes.=C2=A0 I suspect NDS won't have= the same enumeration problems as the NSEC(3) since lacks next-signed link,= and is paired with an NS record anyways.=C2=A0 Also NDS does not change NS= EC(3) behavior DOE behavior. =C2=A0(To be complete there could be a policy = declaration mechanism for this but that's details).

-Wei
--f403045ddecc3efcbe054bdf749b-- --f403045ddecc465c77054bdf7477 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMAQEwAHyjxWs8sJNjMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDMyNTE4NDI0N1oXDTE3MDky MTE4NDI0N1owIjEgMB4GCSqGSIb3DQEJAQwRd2VpaGF3QGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDf/V6s9+sy7fHvy6Z2bKp63d5w85JpcZW9SebsKdycSAUATqgb Gvo6SYD4qMWY3mR+O3LHmJ6WoHqr9xEd7uZ5JxxpfjGhe3MqgS5JaXuKn34q4li1EdMk8F7MB0FD 6VFzmd2OYPpKF8f3d8oyqQUHPnZvoOqCVlO4+fHapq+Rz9++cSI1UbK7KX/kOsi1q+tNEVGP1oVC Cmy/1WK7EEGMOLo2K48AS9T3IP15I1hn/Sj4vVJrpW0rzvRpahOxWKo7SqLcwSRvDvKNue5di7iQ eVceAPcahROEy4P20dimQXpxTVyjQG8wz75b4hwykEgPruaXn1J1usP830/0Tet5AgMBAAGjggFu MIIBajAcBgNVHREEFTATgRF3ZWloYXdAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFF4Fc4YKhOL19j17oEbz6tlaKO/DMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCPihhAVF7RDXtgpruF 0d7ukFX3Ki/I7JD6lTgEGdekylp4bPtLcnIZKM5+JhwalsTbInvGVI6e3VlIyVIOonCf+lIxwC0A enfp52lsFIy12dunCtSJckTlT9LYuxSK5sA4krofdq0ZtSxJ3y8CYHzzolTGaEPqf2BhIpboO4QI zEaRD8w652Rjfo/zP+yI+qYXzACs8erQN0B+8+hT/7Ir8NQcOztDBlNey/ynwE+p1/85y8IHPR8Y Ssm0jF6cpyP/WDat2BbKzT0O1XuZF24UCNxasGcYjYuz3a2+JwQEfSFyFVu/lslEsd8Ehcd9siGL t+pE4LJq0i8cDdnBhWcIMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMAQEwAHyj xWs8sJNjMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCBl5cpHSbIQqa/RxVzhv6eU U35TVLumAimo0M+mD7k09DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzAzMjkxNDMzMDRaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAKqxf0wC2A8vq2sFCu5R/p6NMHtFnf/gHMfLTg5fL XcZbil8R7gEQqvE3vmPJElEktabKDFJtiImGnRGWSj8vUUcFpyvkqfJuBpPZyzllvdk3wtEfgQPk O7uNEHsLzmd84ZXAu4kGmk18Nta+ht3bdsDfsMk9iYRVKFeTziNqaiC+aZIfjscjYHLiWBJlrUOo 1gKqvbEf8tUZP6vJKCDzF5Heoc5U5oWt7GbL2Km+3Z/umdX5TctXBxSZ5Hgj823bJ5MJsp1PMUly c19BkuTNjGrgw2suuHCvP5GOp5lHG66XHNFquica96O3D+JhQLu0/WY+ASeHs9sLd1frUJBkLg== --f403045ddecc465c77054bdf7477-- From nobody Wed Mar 29 08:18:46 2017 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E345127599; Wed, 29 Mar 2017 08:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3drPfO664MML; Wed, 29 Mar 2017 08:18:43 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D73712954A; Wed, 29 Mar 2017 08:11:42 -0700 (PDT) Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 5749C7A32F1; Wed, 29 Mar 2017 15:11:41 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Viktor Dukhovni In-Reply-To: Date: Wed, 29 Mar 2017 11:11:40 -0400 Cc: dane@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <455EC3FC-9140-40D3-88F8-77990B7C7DD0@vpnc.org> <1DA6DC8F-CA06-4453-96E6-D8D257555437@dukhovni.org> <9FC39E28-4285-40F8-8FE9-283FA83B1A0A@dukhovni.org> To: trans@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [dane] [Trans] CT for DNSSEC X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.22 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 Mar 2017 15:18:45 -0000 > On Mar 29, 2017, at 10:33 AM, Wei Chuang wrote: >=20 > Why not create an explicit Non-existence of DS (NDS) RR that gets = logged along with DS and NS? This is not needed, the NSEC/NSEC3 RRs already serve that role. For NSEC records (RFC4034), an unsigned delegation looks like: example.com. IN NS ns1.example.com. example.com. IN NSEC examplf.com NS example.com. IN RRSIG NSEC ... this proves that NS (or other depending on the content of the type bitmap of the NSEC record) records exist for example.com, but DS records do not. With NSEC3 (rfc5155), and the "opt-out" bit the situation can be more complex because the answer may not establish the existence of example.com. Instead we may get an existence proof for the closest encloser (ancestor domain) and proof that "example.com" is not signed, but no proof of its existence. This means that to avoid spam, a log might want to independently verify the existence of the insecure delegation by repeating the query, so as to avoid storing data for non-existent domains with the insecure NXDOMAIN modified to NOERROR with made up NS records. --=20 Viktor. From nobody Thu Mar 30 21:36:03 2017 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE39B127977 for ; Thu, 30 Mar 2017 21:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHS14Yuyci-z for ; Thu, 30 Mar 2017 21:36:00 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00CC9129546 for ; Thu, 30 Mar 2017 21:35:56 -0700 (PDT) Received: from [192.168.1.161] (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id BC4537A32F1 for ; Fri, 31 Mar 2017 04:35:55 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) From: Viktor Dukhovni Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Reply-To: IETF DANE Mailinglist Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <2BDE206F-A032-4A5A-BA30-65A5F3AF7944@dukhovni.org> Date: Fri, 31 Mar 2017 00:35:55 -0400 To: IETF DANE Mailinglist X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [dane] FYI: Cloudmark DANE support X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.22 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 Mar 2017 04:36:02 -0000 https://blog.cloudmark.com/2017/03/27/dane-and-email-security/ --=20 Viktor. DANE and Email Security Mon, 27 Mar 2017 Andrew Conway The forthcoming Cloudmark Security Platform for Email 5.2 will include support for DNS-Based Authentication of Named Entities (DANE), a new protocol that enables increased security for email communications. In this article we=E2=80=99ll look at how DANE works, how it can contribute to a more secure email environment, and how it is starting to gain acceptance. ... DANE does not stop all possibility of email compromise, but it does drastically reduce the surface for man in the middle attacks. By including DANE in Cloudmark Security Platform for Email 5.2, we are pleased to be able to contribute to more secure email communications for our clients and their users.