Subject: Re: [dane] [dns-operations] DNSSEC DANE testing

From: sandoche BALAKRICHENAN <[email-masked]>
Date: Thu, 18 Oct 2012 09:44:21 +0200

Hi Paul,

        I have deliberately added a bogus RRSIG record to
"https://dane-broken.rd.nic.fr". But the firefox add-on seems to
successfully validate mentioning "the domain is secured by DNSSEC".

Sandoche.

On 09/12/2012 10:44 PM, Paul Wouters wrote:
> On Wed, 12 Sep 2012, Marco Davids (SIDN) wrote:
>
>> On 08/23/12 20:02, Paul Wouters wrote:
>>
>>> I put up the xpi as well, you can grab it at:
>>> http://people.redhat.com/pwouters/mozilla-extval-0.7.xpi
>>
>> I like it.
>>
>> However, there might be room for improvent in the wording of the the
>> messages.
>>
>> I deliberately broke the TLSA record (https://forfun.net/) and the
>> message is (in green):
>>
>> "Domainname is secured by DNSSEC and the certificate is validated by
>> CA."
>>
>> Both true, but as a paranoid user, I would have appreciated a little bit
>> more information, like:
>>
>> "... but the certificate did not pass a DANE check"
>>
>> (or something similar)
>
> It should do that. When I check your domain it tells me there is no TLSA
> record, but I checked all name servers and it is there (and incorrect)
>
> I'll add it on my TODO list :)
>
> Paul
> _______________________________________________
> dns-operations mailing list
> [email-masked]
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

---

From: Mark Andrews <[email-masked]>
Date: Fri, 19 Oct 2012 08:56:05 +1100

> successfully validate mentioning "the domain is secured by DNSSEC".

Well the TLSA is secure.   As long as that matches the CERT returned it *is*
secured even if the RRSIG on the A RRset is broken.

; <<>> DiG 9.10.0pre-alpha <<>> _443._tcp.dane-broken.rd.nic.fr tlsa +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52053
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;_443._tcp.dane-broken.rd.nic.fr. IN	TLSA

;; ANSWER SECTION:
_443._tcp.dane-broken.rd.nic.fr. 1 IN	TLSA	3 0 1 6E013C54DF90D42D3C016E1AC9EB21E6DA45403D3A5AE9B2D8F21FC3 600D409C
_443._tcp.dane-broken.rd.nic.fr. 1 IN	RRSIG	TLSA 5 6 1 20130415134103 20121017134103 24975 dane-broken.rd.nic.fr. UFaeHhxVp8zy1tpcR049JqGEvNZrmDLkpgoo63v4gvEtwLp0KRbSBL5J vVlNnz8s5Uk68i8diY/zGt1epP72C2S6C3AUHKdYZiwvxBQwd34Sawna jZMjfAkXEH5z9cjkk1AVm0ReRPs9kbVc0iPDLcH+z21VJBZyFmloOflM EXU=

;; Query time: 838 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Oct 19 08:49:24 2012
;; MSG SIZE  rcvd: 288

> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Warren Kumari <[email-masked]>
Date: Thu, 18 Oct 2012 18:43:38 -0400

> secured even if the RRSIG on the A RRset is broken.

Ooooh… This is an interesting case (which I personally hadn't considered)... 

This all makes sense, but "feels" odd… Not proposing that we do anything, but it did make me blink….

W

--
After you'd known Christine for any length of time, you found yourself fighting a desire to look into her ear to see if you could spot daylight coming the other way.

    -- (Terry Pratchett, Maskerade)

---

From: Mark Andrews <[email-masked]>
Date: Fri, 19 Oct 2012 09:52:06 +1100

In message <[email-masked]>, Warren Kumari wri
tes:
> >=20
> >>=20
> >>=20
> >=20
> > Well the TLSA is secure.   As long as that matches the CERT returned =
> it *is*
> Ooooh=85 This is an interesting case (which I personally hadn't =
> considered)...=20
> 
> This all makes sense, but "feels" odd=85 Not proposing that we do =
> anything, but it did make me blink=85.

It also helps w/ DNS64.  You don't need to care if the AAAA lookups
are forged or not for https connections as long as you get to a
server which presents the correct certificate and passes the
handshake.  You do need to care for http connection.

Mark

---

From: Ben Laurie <[email-masked]>
Date: Fri, 19 Oct 2012 11:08:23 +0100

> This all makes sense, but "feels" odd… Not proposing that we do anything, but it did make me blink….

Feels right to me - who cares what the address is if they have the right cert?

---

From: [email-masked] (Martin Rex)
Date: Fri, 19 Oct 2012 12:59:38 +0200 (CEST)

Warren Kumari wrote:
> 
> Mark Andrews <[email-masked]> wrote:
>> 
>> sandoche BALAKRICHENAN writes:
>>> Hi Paul,
>>> 
> Ooooh? This is an interesting case (which I personally hadn't considered)... 
> 
> This all makes sense, but "feels" odd? Not proposing that we do
> anything, but it did make me blink?.

Somehow I can not follow your discussion.
What exactly do you mean by "added a bogus RRSIG record"?

If the DNSSEC signature on the TLSA record can _not_ be verified,
then the Browser MUST NOT flag the Server as being DANE-verified.

When the server cert has been issued from a public CA, and the
zone is either without DNSSEC or verifiably without TLSA record
for the server, then the browser is doing a regular TLS handshake
and traditional (rfc2818 section 3.1) server endpoint identification.

Certs from private CAs or self-signed certs must continue to
result in the scary-page.

-Martin

---

From: Tony Finch <[email-masked]>
Date: Fri, 19 Oct 2012 12:13:21 +0100

> anything, but it did make me blink….

This came up when I was working on the SRV/MX drafts. The SRV indirection
needs to be secure, and the TLSA needs to be secure, but that's it.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

---

From: Mark Andrews <[email-masked]>
Date: Sat, 20 Oct 2012 00:00:39 +1100

> What exactly do you mean by "added a bogus RRSIG record"?

The A and SOA signatures were broken, not the TLSA.
 
> then the Browser MUST NOT flag the Server as being DANE-verified.
 
It could be verified.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 19 Oct 2012 18:30:08 -0400 (EDT)

>> then the Browser MUST NOT flag the Server as being DANE-verified.

Of course, in my case, I could not reach the server because my DNSSEC
capable resolver could not get a proper A record. When going "insecure",
I could reach it, but then it flags red because _you_ are not using a
DNSSEC resolver, and it does mistakenly claim "domainname is secured
by DNSSEC", which with a broken A record is not the case.

I'll work on fixing this.

Paul