From wolfgang.rosenauer at an-netz.de Thu Oct 1 14:35:08 2015 From: wolfgang.rosenauer at an-netz.de (Wolfgang Rosenauer) Date: Thu, 1 Oct 2015 14:35:08 +0200 Subject: DNSSEC / BIND breakage Message-ID: <560D287C.3010308@an-netz.de> Hi, one of my DNSSEC/DANE secured domains started breaking as of today and I do not fully understand why. Probably bright people here can point me to the correct resolution? I'm using bind and its auto-dnssec maintain; inline-signing yes; Also I'm not aware that my KSK and ZSK keys have any expiration date but today DNSSEC started to fail apparently because my RRSIG signatures are said to be expired. Actually my first idea is that the automatic maintenance in bind failed for some reason. So I deleted the journal and signed zone files and started over by signing the zone from scratch. This at least improved the situation a little bit according to http://dnsviz.net/d/rosenauer.org/dnssec/ But still it seems to be broken and I'm lost currently to understand what is wrong. Thanks for any pointers, Wolfgang From andreas.schulze at datev.de Thu Oct 1 15:14:08 2015 From: andreas.schulze at datev.de (Andreas Schulze) Date: Thu, 1 Oct 2015 15:14:08 +0200 Subject: DNSSEC / BIND breakage In-Reply-To: <560D287C.3010308@an-netz.de> References: <560D287C.3010308@an-netz.de> Message-ID: <560D31A0.7030708@datev.de> Am 01.10.2015 um 14:35 schrieb Wolfgang Rosenauer: > Hi, > > one of my DNSSEC/DANE secured domains started breaking as of today and I > do not fully understand why. > Probably bright people here can point me to the correct resolution? > > I'm using bind and its > auto-dnssec maintain; > inline-signing yes; > > Also I'm not aware that my KSK and ZSK keys have any expiration date but > today DNSSEC started to fail apparently because my RRSIG signatures are > said to be expired. > Actually my first idea is that the automatic maintenance in bind failed > for some reason. So I deleted the journal and signed zone files and > started over by signing the zone from scratch. This at least improved > the situation a little bit according to > http://dnsviz.net/d/rosenauer.org/dnssec/ > > But still it seems to be broken and I'm lost currently to understand > what is wrong. > > > Thanks for any pointers, > Wolfgang > there are 2 nameservers known: yaina.de. and ns.an-netz.de. according to the soa, yaina.de seem to be a secondary. I guess the zonetransfer from primary to secondary did not happen because the zone serial is still the same. compare "dig @yaina.de. rosenauer.org. ns +dnssec" with "dig @ns.an-netz.de.rosenauer.org. ns +dnssec" the primary have more and newer RRSIGs. -> everytime a resign happen the serial number must be changed. Andreas -- A. Schulze DATEV eG From andreas.schulze at datev.de Thu Oct 1 15:31:02 2015 From: andreas.schulze at datev.de (Andreas Schulze) Date: Thu, 1 Oct 2015 15:31:02 +0200 Subject: DNSSEC / BIND breakage In-Reply-To: <560D31A0.7030708@datev.de> References: <560D287C.3010308@an-netz.de> <560D31A0.7030708@datev.de> Message-ID: <560D3596.50008@datev.de> > -> everytime a resign happen the serial number must be changed. this is right, but not your problem. next try for a (maybe more correct) interpretation: the secondary serve expired RRSIGs for rosenauer.org/A,AAAA,NS,MX ( shown purple at dnsviz ) and and a nonvalidatable RRSIG for rosenauer.org/SOA ( shown red at dnsviz ) -- A. Schulze DATEV eG From ietf-dane at dukhovni.org Thu Oct 1 16:50:29 2015 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Thu, 1 Oct 2015 14:50:29 +0000 Subject: DNSSEC / BIND breakage In-Reply-To: <560D287C.3010308@an-netz.de> References: <560D287C.3010308@an-netz.de> Message-ID: <20151001145029.GE18165@mournblade.imrryr.org> On Thu, Oct 01, 2015 at 02:35:08PM +0200, Wolfgang Rosenauer wrote: > I'm using bind and its > auto-dnssec maintain; > inline-signing yes; > > Also I'm not aware that my KSK and ZSK keys have any expiration date but > today DNSSEC started to fail apparently because my RRSIG signatures are > said to be expired. Actually KSKs and ZSKs can have expiration dates, it is best to not set explicitly until you're just about ready to do key rotation. -- Viktor. Zone signing keys live in "keys" directory and must be readable by "named". To create the keys: # dnssec-keygen -r /dev/urandom -a RSASHA256 -b 2048 -3 -f KSK example.net # dnssec-keygen -r /dev/urandom -a RSASHA256 -b 1024 -3 example.net # chown named Kexample.net.+008+* After generating keys and and updating named.conf, to sign a zone: # rndc reconfig # rndc loadkeys example.net To enable NSEC3 records for signed zones: # zones="example.net" # for d in $zones; do salt=$(openssl rand -hex 8 | tr '[a-f]' '[A-F]') rndc signing -nsec3param 1 0 10 $salt $d. done Periodic sync and truncation of zone journals: # for d in $zones; do rndc sync -clean $d.; done To examine non-DNSSEC data in signed zones: # for d in $zones; do named-compilezone -jD -f raw -o - $d $d.signed | egrep -v 'IN (NSEC|RRSIG|DNSKEY|TYPE65534)|^;' done To extract DS RRs to push to the registrar: # for d in $zones; do named-compilezone -jD -f raw -o - $d $d.signed 2>/dev/null | dnssec-dsfromkey -f - $d done To change zone content, since the signed zone is compiled, we need to BUMP THE SERIAL number in the unsigned source to cause re-signing. # d=example.net # vi $d # rndc reload $d # rndc sync -clean $d At this point one can inspect the re-signed zone: # named-compilezone -jD -f raw -o - $d $d.signed ZSK key rollover notes by Carsten Strotmann: ============================================ The way I use the key dates is to specify the "retirement" and "deletion" only before the new key is generated, e.g. when the rollover starts. That way, the rollover can be postponed in time when needed Example: # cd keys # dnssec-settime -p all Kexample.net.+008+50340 Created: Wed Jan 21 09:32:35 2015 Publish: Thu Jan 22 09:32:35 2015 Activate: Sun Jan 25 09:32:35 2015 Revoke: UNSET Inactive: UNSET Delete: UNSET 28 days after activation, the rollover process starts by setting the inactivation time and creating the successor key. The inactivation interval for the old key is 10 minutes more than 2 days, This allows for a bit of time delay between the first command and the next: # dnssec-settime -I $( printf "+%dmi" $(( 2*24*60+10 )) ) -D +8d Kexample.net.+008+50340 # dnssec-keygen -r /dev/urandom -i 2d -S Kexample.net.+008+50340.key # chown named Kexample.net.+008+* # rndc loadkeys example.net By setting the inactivation time not at the creation of the key, but when the rollover starts, the process is more robust against failures of the script/process and the rollover can be postponed if needed. From mailinglisten+spamtrap at pothe.de Tue Oct 13 21:42:37 2015 From: mailinglisten+spamtrap at pothe.de (Andreas Pothe) Date: Tue, 13 Oct 2015 21:42:37 +0200 Subject: DANE broken @ addons.mozilla.org? Message-ID: <561D5EAD.6060807@pothe.de> Hi, can you confirm that addons.mozilla.org has a broken DANE entry? The DNSSEC Validator plugin in Firefox says "no DNSSEC at addons.mozilla.org" but "invalid DNSSEC signature". CU Andreas From ietf-dane at dukhovni.org Tue Oct 13 22:02:35 2015 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Tue, 13 Oct 2015 20:02:35 +0000 Subject: DANE broken @ addons.mozilla.org? In-Reply-To: <561D5EAD.6060807@pothe.de> References: <561D5EAD.6060807@pothe.de> Message-ID: <20151013200235.GZ15070@mournblade.imrryr.org> On Tue, Oct 13, 2015 at 09:42:37PM +0200, Andreas Pothe wrote: > Can you confirm that addons.mozilla.org has a broken DANE entry? No, not DANE, in fact no TLSA records published). Rather, they have DNS nameserver issues: http://dnsviz.net/d/_443._tcp.addons.mozilla.net/dnssec/ The akamai nameservers are returning non-authoritative NXDOMAIN responses with no SOA record! The responses should be authoritative and have an SOA. $ dig +nocl +nottl +noall +ans -t ns mozilla.net. | sort mozilla.net. NS ns1-240.akam.net. mozilla.net. NS ns4-64.akam.net. mozilla.net. NS ns5-65.akam.net. mozilla.net. NS ns7-66.akam.net. == ns1-240.akam.net. == ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 16722 ;; flags: qr ad cd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1 ;_443._tcp.addons.mozilla.net. IN TLSA 7ua25hcif8m3f9dn4r67o9jrq23m3es2.mozilla.net. NSEC3 1 0 1 D11356D2D2F17989 7VVRF81RVM4D4L0GND2F4P6GSI7J5U3O k9eqs0i0lqadl5cpqgag41injcinasl5.mozilla.net. NSEC3 1 0 1 D11356D2D2F17989 KBFQEIE3OI3RIEOP6DPO0ITJBJPV7Q4B CNAME RRSIG kcer05tvt52vv1u1nen7sb239uiocqth.mozilla.net. NSEC3 1 0 1 D11356D2D2F17989 KITA65J7E621QLTTVMM8PJ0L92MQ82AP A RRSIG == ns4-64.akam.net. == ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 22618 ;; flags: qr ad cd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1 ;_443._tcp.addons.mozilla.net. IN TLSA 7ua25hcif8m3f9dn4r67o9jrq23m3es2.mozilla.net. NSEC3 1 0 1 D11356D2D2F17989 7VVRF81RVM4D4L0GND2F4P6GSI7J5U3O k9eqs0i0lqadl5cpqgag41injcinasl5.mozilla.net. NSEC3 1 0 1 D11356D2D2F17989 KBFQEIE3OI3RIEOP6DPO0ITJBJPV7Q4B CNAME RRSIG kcer05tvt52vv1u1nen7sb239uiocqth.mozilla.net. NSEC3 1 0 1 D11356D2D2F17989 KITA65J7E621QLTTVMM8PJ0L92MQ82AP A RRSIG == ns5-65.akam.net. == ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 44991 ;; flags: qr ad cd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1 ;_443._tcp.addons.mozilla.net. IN TLSA 7ua25hcif8m3f9dn4r67o9jrq23m3es2.mozilla.net. NSEC3 1 0 1 D11356D2D2F17989 7VVRF81RVM4D4L0GND2F4P6GSI7J5U3O k9eqs0i0lqadl5cpqgag41injcinasl5.mozilla.net. NSEC3 1 0 1 D11356D2D2F17989 KBFQEIE3OI3RIEOP6DPO0ITJBJPV7Q4B CNAME RRSIG kcer05tvt52vv1u1nen7sb239uiocqth.mozilla.net. NSEC3 1 0 1 D11356D2D2F17989 KITA65J7E621QLTTVMM8PJ0L92MQ82AP A RRSIG == ns7-66.akam.net. == ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 11058 ;; flags: qr ad cd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1 ;_443._tcp.addons.mozilla.net. IN TLSA 7ua25hcif8m3f9dn4r67o9jrq23m3es2.mozilla.net. NSEC3 1 0 1 D11356D2D2F17989 7VVRF81RVM4D4L0GND2F4P6GSI7J5U3O k9eqs0i0lqadl5cpqgag41injcinasl5.mozilla.net. NSEC3 1 0 1 D11356D2D2F17989 KBFQEIE3OI3RIEOP6DPO0ITJBJPV7Q4B CNAME RRSIG kcer05tvt52vv1u1nen7sb239uiocqth.mozilla.net. NSEC3 1 0 1 D11356D2D2F17989 KITA65J7E621QLTTVMM8PJ0L92MQ82AP A RRSIG -- Viktor. From ietf-dane at dukhovni.org Tue Oct 13 22:19:55 2015 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Tue, 13 Oct 2015 20:19:55 +0000 Subject: DANE broken @ addons.mozilla.org? In-Reply-To: <20151013200235.GZ15070@mournblade.imrryr.org> References: <561D5EAD.6060807@pothe.de> <20151013200235.GZ15070@mournblade.imrryr.org> Message-ID: <20151013201955.GA15070@mournblade.imrryr.org> On Tue, Oct 13, 2015 at 08:02:35PM +0000, Viktor Dukhovni wrote: > On Tue, Oct 13, 2015 at 09:42:37PM +0200, Andreas Pothe wrote: > > > Can you confirm that addons.mozilla.org has a broken DANE entry? > > No, not DANE, in fact no TLSA records published). Rather, they > have DNS nameserver issues: > > http://dnsviz.net/d/_443._tcp.addons.mozilla.net/dnssec/ > > The akamai nameservers are returning non-authoritative NXDOMAIN > responses with no SOA record! The responses should be authoritative > and have an SOA. Mind you, the above is generally tolerated. The other issue reported by dnsviz is that one of the servers may have and EDNS0 UDP MTU issue. -- Viktor. From simsong at acm.org Wed Oct 14 18:25:20 2015 From: simsong at acm.org (Simson Garfinkel) Date: Wed, 14 Oct 2015 12:25:20 -0400 Subject: DANE broken @ addons.mozilla.org? In-Reply-To: <561D5EAD.6060807@pothe.de> References: <561D5EAD.6060807@pothe.de> Message-ID: > On Oct 13, 2015, at 3:42 PM, Andreas Pothe wrote: > > Hi, > > can you confirm that addons.mozilla.org has a broken DANE entry? > The DNSSEC Validator plugin in Firefox says "no DNSSEC at > addons.mozilla.org" but "invalid DNSSEC signature". Correct. There is no DNSSEC. Test # Host IP Status Test Description (? Section) 103 addons.mozilla.org FAILED Service hostname must have matching TLSA record Resolving TLSA records for hostname '_443._tcp.addons.mozilla.org' SECURE DNS CNAME lookup addons.mozilla.org = addons.dynect.mozilla.net. 102 PASSED if at any stage of recursive expansion an "insecure" CNAME record is encountered, then it and all subsequent results (in particular, the final result) MUST be considered "insecure" regardless of whether any earlier CNAME records leading to the "insecure" record were "secure". (?2.1.3) Expanding CNAME addons.mozilla.org to addons.dynect.mozilla.net. INSECURE DNS A lookup addons.dynect.mozilla.net. = 63.245.216.132 205 addons.mozilla.org 63.245.216.132 PASSED Server must have End Entity Certificate Fetching EE Certificate for addons.mozilla.org from 63.245.216.132 port 443 via https 306 a 63.245.216.132 Server EE Certificate does not PKIX Verify Checking EE Certificate 'addons.mozilla.org' against system anchors 307 a 63.245.216.132 FAILED "When name checks are applicable (certificate usage DANE-TA(2)), if the server certificate contains a Subject Alternative Name extension ([RFC5280]), with at least one DNS-ID ([RFC6125]) then only the DNS- IDs are matched against the client's reference identifiers.... The server certificate is considered matched when one of its presented identifiers ([RFC5280]) matches any of the client's reference identifiers." (?3.2.3) Hostname addons.mozilla.org does not match EE Certificate Common Name 'addons.mozilla.org' 403 addons.mozilla.org FAILED All IP addresses for a host that is TLSA protected must TLSA verify Validating TLSA records for 0 out of 1 IP addresses found for host addons.mozilla.org 405 FAILED All DNS lookups must be secured by DNSSEC 404 FAILED No HTTP DANE test may fail Were any DANE HTTP tests a hard fail? Using OpenSSL Version 1.0.2d 9 Jul 2015 > > CU > Andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: From ietf-dane at dukhovni.org Wed Oct 14 18:54:16 2015 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Wed, 14 Oct 2015 16:54:16 +0000 Subject: DANE broken @ addons.mozilla.org? In-Reply-To: References: <561D5EAD.6060807@pothe.de> Message-ID: <20151014165415.GJ15070@mournblade.imrryr.org> On Wed, Oct 14, 2015 at 12:25:20PM -0400, Simson Garfinkel wrote: > > On Oct 13, 2015, at 3:42 PM, Andreas Pothe wrote: > > > > Hi, > > > > can you confirm that addons.mozilla.org has a broken DANE entry? > > The DNSSEC Validator plugin in Firefox says "no DNSSEC at > > addons.mozilla.org" but "invalid DNSSEC signature". > > Correct. There is no DNSSEC. No, there is no outright DNSSEC problem for this domain. http://dnsviz.net/d/_443._tcp.addons.mozilla.org/dnssec/ the missing SOA record noted at that URL is optional. I'll ask Casey to update the code to only object to "bogus" SOA records, not missing SOA records. The real problem is with _443._tcp.addons.mozilla.net, where the nameservers return an invalid denial of existence, perhaps due the presence of a "*.mozilla.net" wildcard. Someone at mozilla and akamai needs to look into the nameserver problem. Finally, the test results below don't look right... > Test # Host IP Status Test Description (? Section) > 103 addons.mozilla.org FAILED Service hostname must have matching TLSA record > Resolving TLSA records for hostname '_443._tcp.addons.mozilla.org' This one is merely misleading, "FAILED" should only apply when the TLSA records don't match, or DNS lookups fail. Not publishing TLSA records is not a failure, it is rather a non-deployment (with some neutral colour not "red"). > SECURE DNS CNAME lookup addons.mozilla.org = addons.dynect.mozilla.net. > 102 PASSED if at any stage of recursive expansion an > "insecure" CNAME record is encountered, then it and all subsequent results > (in particular, the final result) MUST be considered "insecure" regardless > of whether any earlier CNAME records leading to the "insecure" record were > "secure". (?2.1.3) > Expanding CNAME addons.mozilla.org to addons.dynect.mozilla.net. > INSECURE DNS A lookup addons.dynect.mozilla.net. = 63.245.216.132 The CNAME record is "secure" but its target lies in a sub-zone that is not signed. Therefore, the TLSA record should be obtained from the original name, not the CNAME expanded name (draft-ietf-dane-ops to become RFC7671 later this week I expect). So _443._tcp.addons.mozilla.org is the TLSA RRset qname. That lookup yields authenticated denial of existence (without an SOA record, so not cacheable). > Fetching EE Certificate for addons.mozilla.org from 63.245.216.132 port 443 via https > 306 a 63.245.216.132 Server EE Certificate does not PKIX Verify This part is surely wrong, the "addons.mozilla.org" HTTPS service has a valid EV cert. I would expect it to PKIX verify given the right trust anchor: CN = DigiCert High Assurance EV Root CA OU = www.digicert.com O = DigiCert Inc C = US > Checking EE Certificate 'addons.mozilla.org' against system anchors > > 307 a 63.245.216.132 FAILED "When name checks are applicable > (certificate usage DANE-TA(2)), if the server certificate contains a > Subject Alternative Name extension ([RFC5280]), with at least one DNS-ID > ([RFC6125]) then only the DNS- IDs are matched against the client's > reference identifiers.... The server certificate is considered matched > when one of its presented identifiers ([RFC5280]) matches any of the > client's reference identifiers." (?3.2.3) This is not a DANE-TA(2) check, the domain has no TLSA records, so the text is not applicable. > Hostname addons.mozilla.org does not match EE Certificate Common Name 'addons.mozilla.org' This does not look right, clear the names are identical. > > 403 addons.mozilla.org FAILED All IP addresses for a > host that is TLSA protected must TLSA verify Validating TLSA records for > 0 out of 1 IP addresses found for host addons.mozilla.org TLSA matching is not pertinent, this domain has no TLSA records. > 405 FAILED All DNS lookups must be secured by DNSSEC That's not a failure, at most a non-deployment, and in any case not right. In this case however, sufficiently many DNS records are "secure" to allow the domain to verify via DANE too, had they published a matching TLSA RRset at the above mentioned qname. > 404 FAILED No HTTP DANE test may fail > Were any DANE HTTP tests a hard fail? No DANE tests are in scope, for lack of TLSA records. -- Viktor. From ietf-dane at dukhovni.org Thu Oct 15 05:53:10 2015 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Thu, 15 Oct 2015 03:53:10 +0000 Subject: DANE SMTP and OPS drafts now RFCs! Message-ID: <20151015035310.GM15070@mournblade.imrryr.org> After a 2 and a half year process, the DANE SMTP and DANE OPS drafts are now published IETF RFCs: https://tools.ietf.org/html/rfc7671 ----------------------------------- The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance This document clarifies and updates the DNS-Based Authentication of Named Entities (DANE) TLSA specification (RFC 6698), based on subsequent implementation experience. It also contains guidance for implementers, operators, and protocol developers who want to use DANE records. https://tools.ietf.org/html/rfc7672 ----------------------------------- SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) This memo describes a downgrade-resistant protocol for SMTP transport security between Message Transfer Agents (MTAs), based on the DNS- Based Authentication of Named Entities (DANE) TLSA DNS record. Adoption of this protocol enables an incremental transition of the Internet email backbone to one using encrypted and authenticated Transport Layer Security (TLS). It is now time to shift my attention back to implementation in TLS libraries. The community can help by promoting adoption, and making sure that your deployment stays valid at all times. Please pay close attention to: https://dane.sys4.de/common_mistakes#3 https://dane.sys4.de/common_mistakes#8 https://tools.ietf.org/html/rfc7671#section-8.1 https://tools.ietf.org/html/rfc7671#section-8.4 https://tools.ietf.org/html/rfc7672#section-3.1.1 https://tools.ietf.org/html/rfc7672#section-3.1.2 https://tools.ietf.org/html/rfc7672#section-3.1.3 Just in case you overlooked something, please always retest your domain's TLSA records after deploying fresh certificates and/or private keys. https://dane.sys4.de -- Viktor. From p at sys4.de Thu Oct 15 06:31:26 2015 From: p at sys4.de (Patrick Ben Koetter) Date: Thu, 15 Oct 2015 06:31:26 +0200 Subject: DANE SMTP and OPS drafts now RFCs! In-Reply-To: <20151015035310.GM15070@mournblade.imrryr.org> References: <20151015035310.GM15070@mournblade.imrryr.org> Message-ID: <20151015043126.GC25001@sys4.de> Congratulations Viktor! Thorough and insistent work. You've done a great job authoring these documents. p at rick * Viktor Dukhovni : > After a 2 and a half year process, the DANE SMTP and DANE OPS drafts > are now published IETF RFCs: > > https://tools.ietf.org/html/rfc7671 > ----------------------------------- > > The DNS-Based Authentication of Named Entities (DANE) Protocol: > Updates and Operational Guidance > > This document clarifies and updates the DNS-Based Authentication of > Named Entities (DANE) TLSA specification (RFC 6698), based on > subsequent implementation experience. It also contains guidance for > implementers, operators, and protocol developers who want to use DANE > records. > > https://tools.ietf.org/html/rfc7672 > ----------------------------------- > > SMTP Security via Opportunistic DNS-Based Authentication of Named > Entities (DANE) Transport Layer Security (TLS) > > This memo describes a downgrade-resistant protocol for SMTP transport > security between Message Transfer Agents (MTAs), based on the DNS- > Based Authentication of Named Entities (DANE) TLSA DNS record. > Adoption of this protocol enables an incremental transition of the > Internet email backbone to one using encrypted and authenticated > Transport Layer Security (TLS). > > It is now time to shift my attention back to implementation in TLS > libraries. The community can help by promoting adoption, and making > sure that your deployment stays valid at all times. Please pay close > attention to: > > https://dane.sys4.de/common_mistakes#3 > https://dane.sys4.de/common_mistakes#8 > https://tools.ietf.org/html/rfc7671#section-8.1 > https://tools.ietf.org/html/rfc7671#section-8.4 > https://tools.ietf.org/html/rfc7672#section-3.1.1 > https://tools.ietf.org/html/rfc7672#section-3.1.2 > https://tools.ietf.org/html/rfc7672#section-3.1.3 > > Just in case you overlooked something, please always retest your > domain's TLSA records after deploying fresh certificates and/or > private keys. > > https://dane.sys4.de > > -- > Viktor. -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstra?e 15, 81669 M?nchen Sitz der Gesellschaft: M?nchen, Amtsgericht M?nchen: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein From the.lists at mgm51.com Thu Oct 15 17:20:14 2015 From: the.lists at mgm51.com (Mike) Date: Thu, 15 Oct 2015 11:20:14 -0400 Subject: DANE SMTP and OPS drafts now RFCs! In-Reply-To: <20151015035310.GM15070@mournblade.imrryr.org> References: <20151015035310.GM15070@mournblade.imrryr.org> Message-ID: <561FC42E.10003@mgm51.com> On 10/14/2015 11:53 PM, Viktor Dukhovni wrote: > After a 2 and a half year process, the DANE SMTP and DANE OPS drafts > are now published IETF RFCs: > [snip] Congratulations! And Thank-You for your steadfast efforts. From ietf-dane at dukhovni.org Fri Oct 16 08:40:49 2015 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Fri, 16 Oct 2015 06:40:49 +0000 Subject: DNS Hosting provider issues: metaregistrar.nl resolved In-Reply-To: <20150818050222.GB24426@mournblade.imrryr.org> References: <20150119190115.GM29286@mournblade.imrryr.org> <20150120173922.GA8034@mournblade.imrryr.org> <20150126215312.GB8034@mournblade.imrryr.org> <20150129234235.GE8034@mournblade.imrryr.org> <20150202210107.GX8034@mournblade.imrryr.org> <20150204211203.GA8034@mournblade.imrryr.org> <20150204232324.GC8034@mournblade.imrryr.org> <20150318091546.GB3223@mournblade.imrryr.org> <20150806062001.GH24415@mournblade.imrryr.org> <20150818050222.GB24426@mournblade.imrryr.org> Message-ID: <20151016064048.GK21305@mournblade.imrryr.org> Another DNS hosting provider (metaregistrar.nl) has upgraded PowerDNS and no longer returns incorrect "authenticated denial of existence" responses. With a bit of luck, a few more will fix similar issues in the not too distant future. -- Viktor. From simsong at acm.org Mon Oct 26 23:52:30 2015 From: simsong at acm.org (Simson Garfinkel) Date: Mon, 26 Oct 2015 18:52:30 -0400 Subject: DANE broken @ addons.mozilla.org? In-Reply-To: <20151014165415.GJ15070@mournblade.imrryr.org> References: <561D5EAD.6060807@pothe.de> <20151014165415.GJ15070@mournblade.imrryr.org> Message-ID: Thanks again to Viktor for his assistance in helping me clarify the tester I am developing. Viktor wrote: > Finally, the test results below don't look right... > > > Test # Host IP Status Test Description (? Section) > > 103 addons.mozilla.org FAILED Service hostname must > have matching TLSA record > > Resolving TLSA records for hostname '_443._tcp.addons.mozilla.org' > > This one is merely misleading, "FAILED" should only apply when the > TLSA records don't match, or DNS lookups fail. Not publishing TLSA > records is not a failure, it is rather a non-deployment (with some > neutral colour not "red"). > I have changed test 103 to read "NON DEPLOYMENT" when there is no TLSA record for a given host. The background is now cyan. I personally feel that a domain fails the DANE test if it does not have a DANE TLSA record, but I will defer to Viktor. > > > > SECURE DNS CNAME lookup addons.mozilla.org = addons.dynect.mozilla.net. > > 102 PASSED if at any stage of recursive expansion an > > "insecure" CNAME record is encountered, then it and all subsequent > results > > (in particular, the final result) MUST be considered "insecure" > regardless > > of whether any earlier CNAME records leading to the "insecure" record > were > > "secure". (?2.1.3) > > Expanding CNAME addons.mozilla.org to addons.dynect.mozilla.net. > > INSECURE DNS A lookup addons.dynect.mozilla.net. = 63.245.216.132 > > The CNAME record is "secure" but its target lies in a sub-zone that > is not signed. Therefore, the TLSA record should be obtained from > the original name, not the CNAME expanded name (draft-ietf-dane-ops > to become RFC7671 later this week I expect). > In fact, my tester was presenting the results of a test of addons.mozilla.org *and *addons.dynect.mozilla.net. However this wasn't exactly clear that I was doing this. I was getting the TLSA record for the primary name, then seeing if there was a CNAME chain.Following RFC7671, I will now do the following: - Fully expand the CNAME to the final target. - Get the TLSA record for the corresponding expanded, target domain - If there is no TLSA record, try to initial, unexpanded, source domain. - Document all DNS lookups that result in NO_NAME. (Question: how do I tell from the getdns API if a NO_NAME response is DNSSEC authenticated?) > So _443._tcp.addons.mozilla.org is the TLSA RRset qname. That > lookup yields authenticated denial of existence (without an SOA > record, so not cacheable). > > > Fetching EE Certificate for addons.mozilla.org from 63.245.216.132 port > 443 via https > > 306 a 63.245.216.132 Server EE Certificate does not > PKIX Verify > > This part is surely wrong, the "addons.mozilla.org" HTTPS service > has a valid EV cert. I would expect it to PKIX verify given the > right trust anchor: > > CN = DigiCert High Assurance EV Root CA > OU = www.digicert.com > O = DigiCert Inc > C = US > I'm not sure what was happening before. However, this is now reporting correct. Would it be useful to have the CN, OU, O and C fields from the certificate displayed? > > > Checking EE Certificate 'addons.mozilla.org' against system anchors > > > > 307 a 63.245.216.132 FAILED "When name checks are applicable > > (certificate usage DANE-TA(2)), if the server certificate contains a > > Subject Alternative Name extension ([RFC5280]), with at least one DNS-ID > > ([RFC6125]) then only the DNS- IDs are matched against the client's > > reference identifiers.... The server certificate is considered matched > > when one of its presented identifiers ([RFC5280]) matches any of the > > client's reference identifiers." (?3.2.3) > > This is not a DANE-TA(2) check, the domain has no TLSA records, so > the text is not applicable. > This is interesting. Name checks are applicable because the certificate is served via HTTP. The only thing that makes the text not applicable is the parenthetical (certificate usage DANE-TA(2)." I will therefore remove the parenthetical and replace it with an ellipses . > > > Hostname addons.mozilla.org does not match EE Certificate Common Name ' > addons.mozilla.org' > > This does not look right, clear the names are identical. > > > > 403 addons.mozilla.org FAILED All IP addresses for a > > host that is TLSA protected must TLSA verify Validating TLSA records for > > 0 out of 1 IP addresses found for host addons.mozilla.org > > TLSA matching is not pertinent, this domain has no TLSA records. > A NON DEPLOYMENT message is now given if the domain does not have TLSA records.It now reports how many relied on and how many are secure. In this case, Validating TLSA records are found for 0 out of 1 IP addresses for host addons.mozilla.org > > > 405 FAILED All DNS lookups must be secured by DNSSEC > > That's not a failure, at most a non-deployment, and in any case > not right. In this case however, sufficiently many DNS records > are "secure" to allow the domain to verify via DANE too, had they > published a matching TLSA RRset at the above mentioned qname. > The tester determines if a DNS lookup is relied upon to reach a DANE TLSA certificate. > > > 404 FAILED No HTTP DANE test may fail > > Were any DANE HTTP tests a hard fail? > > No DANE tests are in scope, for lack of TLSA records. > Now it reports "Total HTTP TLSA Records Present: 0" To see the revised report, please visit: http://arp.simson.net/dev/dane_check.cgi/https/addons.mozilla.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From ietf-dane at dukhovni.org Tue Oct 27 05:52:20 2015 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Tue, 27 Oct 2015 04:52:20 +0000 Subject: DANE broken @ addons.mozilla.org? In-Reply-To: References: <561D5EAD.6060807@pothe.de> <20151014165415.GJ15070@mournblade.imrryr.org> Message-ID: <20151027045220.GX5570@mournblade.imrryr.org> On Mon, Oct 26, 2015 at 06:52:30PM -0400, Simson Garfinkel wrote: > > > > > Test # Host IP Status Test Description (? Section) > > > 103 addons.mozilla.org FAILED Service hostname must > > have matching TLSA record > > > Resolving TLSA records for hostname '_443._tcp.addons.mozilla.org' > > > > This one is merely misleading, "FAILED" should only apply when the > > TLSA records don't match, or DNS lookups fail. Not publishing TLSA > > records is not a failure, it is rather a non-deployment (with some > > neutral colour not "red"). > > > > I have changed test 103 to read "NON DEPLOYMENT" when there is no TLSA > record for a given host. The background is now cyan. I personally feel that > a domain fails the DANE test if it does not have a DANE TLSA record, but I > will defer to Viktor. Note that when the target is a CNAME, "non-deployment" means no TLSA record at *either* end of the CNAME chain. So if no TLSA RRs are found at the (secure) expanded CNAME, but TLSA RRs are present at the unexpanded original target name, then I would try to avoid describing this is as a "non deployment". This makes the UI a bit more tricky. "Non-deployment" is then I think a "global" condition to report near the top of the page, and the status of the original or expanded name is either "TLSA records present" or "TLSA records not present". > Following RFC7671, I > will now do the following: > > - Fully expand the CNAME to the final target. Then if and only if "secure" at each stage: > - Get the TLSA record for the corresponding expanded, target domain > - If there is no TLSA record, try to initial, unexpanded, source domain. Correct. > - Document all DNS lookups that result in NO_NAME. (Question: how do I > tell from the getdns API if a NO_NAME response is DNSSEC authenticated?) It turns out that you don't need to distinguish between "secure" and "insecure" NXDOMAIN and NODATA. Either the records don't exist, or would not be trusted even if they existed, so the status is not relevant. The security status of negative replies is only needed in order to fail when faced with "bogus" replies. Provided the library throws an exception or returns an error with "bogus" answers, you don't need to know whether negative answers are "secure" or not. > > This part is surely wrong, the "addons.mozilla.org" HTTPS service > > has a valid EV cert. I would expect it to PKIX verify given the > > right trust anchor: > > > > CN = DigiCert High Assurance EV Root CA > > OU = www.digicert.com > > O = DigiCert Inc > > C = US > > I'm not sure what was happening before. However, this is now reporting > correct. Would it be useful to have the CN, OU, O and C fields from the > certificate displayed? Nor I, ordinary non-DANE PKIX validation reports success now. As for what to display from the certificate chain, your call. If you want to provide a chain summary, perhaps issuer/subject/dates of each chain element? > > This is not a DANE-TA(2) check, the domain has no TLSA records, so > > the text is not applicable. > > This is interesting. Name checks are applicable because the certificate is > served via HTTP. HTTP is not the reason name checks are required. Name checks are also needed when doing mandatory authenticated TLS with SMTP for example. Name checks are not needed with unauthenticated (typically opportunistic) TLS and with DANE-EE(3) where they are obviated by the name to key binding in the TLSA record. Here, you're doing RFC5280 PKIX with assocaited RFC6125 name checks, so name checks are in scope. If you had DANE-EE(3) TLSA RRs for this TLS destination, you'd skip name checks when matching that TLSA record. It is even possible to have: _443._tcp.www.example.com. IN TLSA 3 1 1 _443._tcp.www.example.com. IN TLSA 2 0 1 in which case you'd skip name checks if the "3 1 1" record matches, but apply name checks to determine whether the "2 0 1" record matches. It is even possible for the "2 0 1" to match the issuer and name checks to fail, but the connection is still valid if the "3 1 1" record matches. Thus the applicability of name checks is determine on a (TLSA) record by record basis when deciding whether that particular record authenticates the server or not. Only DANE-EE(3) obviates name checks, with all the other DANE certificate usages name checks are required. Overall the report is substantially correct now. -- Viktor.