Subject: [dane] srv-09 comments

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 16 Feb 2015 17:01:23 +0000

[ Note, I've read only the changes from -08, not the whole document. ]

Section 3.4 (Impact on TLA Usage) second bullet:

  Revert change from -08 to -09.  The -08 language:

    If the TLSA response is "insecure", then the client SHALL proceed ...

  was correct, the -09 language opens the door to downgrade attacks:

    If the TLSA lookup fails, then the client SHALL proceed as if the ... 

Section 3.1 (Srv Query):

  Quote:

    If the lookup result is "insecure" (or no SRV records are located),
    this protocol does not apply and the client SHOULD fall back to its
    non-DNSSEC, non-DANE (and possibly non-SRV) behavior.  If the SRV
    lookup fails because the RRset is "bogus", the client MUST abort its
    attempt to connect to the desired service.

  Note that *any* SRV lookup error, not just "bogus" needs to
  trigger connection failure.  Timeout, SRVFAIL, ... all of these
  are potential downgrade attacks.  Here, error is in the sense of
  section 2.1.1 of the SMTP draft (NXDOMAIN either "secure" or
  "insecure" is NOT an error).

  In light of that, the parenthetical comment "(or no SRV records
  are located)" should perhaps be made more precise.

    (or the lookup result is a denial of existence, whether "secure" or
     "insecure", but is not a lookup error)

  Also please update your xml2rfc reference cache, the SMTP draft
  reference should be to version 13.

-- 
	Viktor.

---

From: ⌘ Matt Miller <[email-masked]>
Date: Mon, 16 Feb 2015 10:35:44 -0700

Thanks for the feedback!  More inline ...

> If the TLSA lookup fails, then the client SHALL proceed as if the 

The original language did not account for the lack of records, but I
can see how this is too permissive.  Perhaps the following is more
acceptable (replacing the last two bullets in dane-srv-09)?

   o  If the TLSA response is "bogus" or "indeterminate" (or the lookup
      fails for reasons other than no records), then the client MUST
      NOT connect to the target server (the client can still use other
      SRV targets).

   o  If the TLSA response is "insecure" (or no TLSA records exist),
      then the client SHALL proceed as if the target server had no TLSA
      records.  It MAY connect to the target server with or without
      TLS, subject to the policies of the application protocol or
      client implementation.

> lookup fails because the RRset is "bogus", the client MUST abort
> its attempt to connect to the desired service.
> 

The parenthetical is meant to account for the lack of SRV records, but
I can see how that might be too permissive.  Is the following more
acceptable?

   If the SRV lookup fails because the RRset is "bogus" (or the lookup
   fails for reasons other than no records), the client MUST abort its
   attempt to connect to the desired service.  If the lookup result is
   "insecure" (or no SRV records exist), this protocol does not apply
   and the client SHOULD fall back to its non-DNSSEC, non-DANE (and
   possibly non-SRV) behavior.

> reference should be to version 13.

Thanks for the catch.  I'll force a cache refresh.

- -- 
- - m&m

Matt Miller < [email-masked] >
Cisco Systems, Inc.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 16 Feb 2015 18:08:13 +0000

On Mon, Feb 16, 2015 at 10:35:44AM -0700, ? Matt Miller wrote:

> > [...]

Much better and basically correct, provided that it is clear that
"indeterminate" is the 4035 (not 4033) definition, and the phrase
"fails for reasons other than no records" is sufficiently clear to
the document's audience.  It is a somewhat informal phrase...

In the SMTP draft ([1] below my signature) "no records" (be it
NOERROR with ancount==0 or NXDOMAIN) is defined as a non-error (a
successful empty result).  Your taxonomy is different, but my guess
is that the text is good enough.

[ Is denial of existence of a success or a failure?  How many
  angels can dance on the head of a pin? ... ]

----
Question to the WG at large:

    Anyone see any room for confusion about the meaning of the
    proposed text?
----

>    possibly non-SRV) behavior.

Thanks.  Looks fine, provided the "fails for reasons other than no
records" bit is clear enough to the world at large.

-- 
	Viktor.

[1] SMTP draft section 2.1.1 (middle of page 10):

   There is an important non-failure condition we need to highlight in
   addition to the obvious case of the DNS client obtaining a non-empty
   "secure" or "insecure" RRset of the requested type.  Namely, it is
   not an error when either "secure" or "insecure" non-existence is
   determined for the requested data.  When a DNSSEC response with a
   validation status that is either "secure" or "insecure" reports
   either no records of the requested type or non-existence of the query
   domain, the response is not a DNS error condition.  The DNS client
   has not been left without an answer; it has learned that records of
   the requested type do not exist.

---

From: ⌘ Matt Miller <[email-masked]>
Date: Mon, 16 Feb 2015 14:48:19 -0700

On 2/16/15 11:08 AM, Viktor Dukhovni wrote:
>>> Revert change from -08 to -09.  The -08 language: [...]
>> 
>> The original language did not account for the lack of records,
>> but I can see how this is too permissive.  Perhaps the following
>> is more acceptable (replacing the last two bullets in
>> dane-srv-09)?
>> 
>> o  If the TLSA response is "bogus" or "indeterminate" (or the
>> lookup fails for reasons other than no records), then the client
>> MUST NOT connect to the target server (the client can still use
>> other SRV targets).
>> 
>> o  If the TLSA response is "insecure" (or no TLSA records
>> exist), then the client SHALL proceed as if the target server had
>> no TLSA records.  It MAY connect to the target server with or
>> without TLS, subject to the policies of the application protocol
>> or client implementation.
> 
> successful empty result).  Your taxonomy is different, but my
> guess is that the text is good enough.
> 
> ---- Question to the WG at large:
> 
> Anyone see any room for confusion about the meaning of the proposed
> text? ----
> 
>> The parenthetical is meant to account for the lack of SRV
>> records, but I can see how that might be too permissive.  Is the
>> following more acceptable?
>> 
>> If the SRV lookup fails because the RRset is "bogus" (or the
>> lookup fails for reasons other than no records), the client MUST
>> abort its attempt to connect to the desired service.  If the
>> lookup result is "insecure" (or no SRV records exist), this
>> protocol does not apply and the client SHOULD fall back to its
>> non-DNSSEC, non-DANE (and possibly non-SRV) behavior.
> 

I'll submit -10 presently.

Thanks again,

- -- 
- - m&m

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 17 Feb 2015 17:01:33 -0500

Matt, thank you for updating the draft based on last call comments. 
I have verified that you seem to have addressed all the comments that I noted. 
I like the new definitions you added they add clarity, thanks. 

But I noticed some “strange language” 
I section 3.1 you say in paragraph 2: 
For this specification to apply, the entire DNS RRset that is returned MUST be “secure” … 

Well the word entire is redundant if you are talking about single DNS RRset, 
BUT I think there are missing words i.e. the sentence should be:

For this specification to apply, the entire chain of  DNS RRset(s) that is returned MUST be “secure” …
 
If the second interpretation is right some minor word-smithing in paragraph 3 is also needed. 

Olafur as document Shepard 

> On Feb 16, 2015, at 4:48 PM, ⌘ Matt Miller <[email-masked]> wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> Matt Miller < [email-masked] <mailto:[email-masked]> >
> Cisco Systems, Inc.

---

From: ⌘ Matt Miller <[email-masked]>
Date: Tue, 17 Feb 2015 15:05:36 -0700

On 2/17/15 3:01 PM, Olafur Gudmundsson wrote:
>  I have verified that you seem to have addressed all the comments
> that I noted. I like the new definitions you added they add
> clarity, thanks.
> 
> But I noticed some “strange language” I section 3.1 you say in
> paragraph 2: For this specification to apply, the entire DNS RRset
> that is returned MUST be “secure” …
> 
> Well the word entire is redundant if you are talking about single
> DNS RRset, BUT I think there are missing words i.e. the sentence
> should be:
> 

Thanks for the catch!  The intent is the second interpretation.

I'll get an update (which will be revision -11) out soon.

- -- 
- - m&m

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 17 Feb 2015 23:12:12 +0000

On Tue, Feb 17, 2015 at 05:01:33PM -0500, Olafur Gudmundsson wrote:

> For this specification to apply, the entire DNS RRset that is returned MUST be ?secure? ? 
> 
> For this specification to apply, the entire chain of  DNS RRset(s) that is returned MUST be ?secure? ?
>  

Yes, if indeed there is a "chain" (of CNAME/DNAME RRs) leading from
the query domain to the owner domain of the answer records then
the entire chain must be "secure".  IIRC this much is already
said elsewhere in the draft.

Note that with security-aware non-validating stub-resolvers that
trust the AD-bit from a validating iterative resolver (presumably
one to which they have a secure communications path) the "chain"
issue is largely handled by that upstream resolver.  The upstream
resolver will return AD=0 if any link in the chain is insecure.

With for non-validating security-aware stub resolvers the application
need only worry about "chains" if multiple resolver queries are
required to get from the query domain to the final answer (i.e.
the iterative resolver returns one or more CNAME, but not the
final answer, and the application has to retstart with the
final CNAME).

Thus, for example, Postfix has code to chase CNAMEs by asking the
resolver multiple times, and in *that* case it makes sure that the
final AD bit is the "AND" of the AD bits of all the replies received.
That code is rarely exercised, since in practice most iterative
resolvers do the CNAME chasing internally before returning multiple
CNAME RRs and the final answer in a single response.

This creates an interesting edge-case for testing whether individual
MX hosts (or SRV target hosts) live in a signed zone (that's the
purpose of the A/AAAA queries in the SRV and SMTP drafts that
gate the applicability of TLSA lookups):

	; example.com is a signed zone
	;
	example.com. IN MX 0 mail.example.com.
	mail.example.com. IN CNAME mail.example.net.
	_25._tcp.mail.example.com. IN TLSA 3 1 1 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

	; example.net is an "insecure" zone:
	;
	mail.example.net. IN A 192.0.2.1

When a query for the "A" records of "mail.example.com." is
sent to a validating iterative resolver, the response has
a CNAME RR, an "A" RR and AD=0.  However the query domain
is actually "secure", the reason for "AD=0" is that the CNAME
points into an "insecure" zone.

To accomodate this edge-case, when the A/AAAA record returns
an insecure CNAME, Postfix sends a second query:

	mail.example.com. IN CNAME ?

and if that yields "AD=1", TLSA records are still requested:

	_25._tcp.mail.example.com. IN TLSA ?

and used if returned (with AD=1).

Now this case is atypical, because with MX and SRV records the
target host is supposed to never be a CNAME (though it is in a
small fraction of cases).  So this issue legitimately arises only
for email domains that have no MX RRs and use just A records to
publish the available SMTP server(s).  Nevertheless many MTAs
tolerate MX hostnames that are aliases.

Therefore the SMTP draft in section 2.2.2 (which covers the A/AAAA
record lookup rationale and processing logic) says:

   [  ... Cases for possible replies to A/AAAA queries ... ]

   Insecure CNAME:   The input domain is a CNAME alias, but the ultimate
      network address RRset is "insecure" (see Section 2.1.1).  If the
      initial CNAME response is also "insecure", DANE TLS does not
      apply.  Otherwise, this case is treated just like the non-CNAME
      case above, where a search is performed for a TLSA record with the
      original input domain as the candidate TLSA base domain.

This type of detail is how the SMTP draft go to be 33 pages, while
the SRV draft is noticeably shorter. :-)

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 17 Feb 2015 18:46:13 -0500 (EST)

> and used if returned (with AD=1).

Why does postfix care about the security of the A/CNAME results before
asking for TLSA records?

Why isn't it asking for TLSA records, and if those are secure, don't
care about the AD bit for the A/AAAA/CNAME.

As long as whatever insecure A/CNAME/AAAA address has the right
certificate you were looking for.

Paul

---

From: Mark Andrews <[email-masked]>
Date: Wed, 18 Feb 2015 11:06:20 +1100

In message <[email-masked]>, Paul Wouters w
> care about the AD bit for the A/AAAA/CNAME.

Because there are idiots that design nameservers, firewalls and
scrubbing services that think asking for TLSA records is a good
reason to drop the query.  Looking at the result of the MX/A/AAAA
query and using that to determine if the TLSA query should be
performed reduces the number of queries that encounter such idiocy.

MX/A/AAAA are rarely dropped.

> _______________________________________________
> 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: Viktor Dukhovni <[email-masked]>
Date: Wed, 18 Feb 2015 00:18:43 +0000

> Why does postfix care about the security of the A/CNAME results before

Because "nist.gov" would otherwise receive no email:

    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18665
    ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
    ;nist.gov.              IN MX
    nist.gov.               MX      0 nist-gov.mail.protection.outlook.com.

    ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 53098
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
    ;_25._tcp.nist-gov.mail.protection.outlook.com. IN TLSA

The nameservers for the unsigned zone of nist.gov's MX hosts are
allergic to TLSA queries.  They return "NOTIMPL" instead of:

    ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 28627
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
    ;_25._tcp.nist-gov.mail.protection.outlook.com. IN A

You can try it for yourself

    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37877
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
    ;mail.protection.outlook.com. IN        NS
    mail.protection.outlook.com. NS ns1-proddns.glbdns.o365filtering.com.
    mail.protection.outlook.com. NS ns2-proddns.glbdns.o365filtering.com.

    $ dig +norecur +dnssec +noall +comment +qu -t tlsa _25._tcp.nist-gov.mail.protection.outlook.com. @ns1-proddns.glbdns.o365filtering.com.
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 19776
    ;; flags: qr; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

    ;; WARNING: EDNS query returned status FORMERR - retry with '+nodnssec +noedns'

    $ dig +norecur +nodnssec +noedns +noall +comment -t tlsa _25._tcp.nist-gov.mail.protection.outlook.com. @ns1-proddns.glbdns.o365filtering.com.
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOTIMP, id: 56709
    ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

This was discussed quite some time ago, and has been in the SMTP
draft since.  The domain "nist.gov" is not a comprehensive list of
problem domains.  The SMTP draft avoids sending queries for "exotic"
RR-types to "minimal" nameservers that don't support DNSSEC.

> care about the AD bit for the A/AAAA/CNAME.

Because those queries would all too often spuriously fail, and with
"discovery" of TLS support (opportunistic DANE TLS), would lead to
loss of connectivity, since the failures are indistinguishable from
downgrade attacks.

-- 
	Viktor.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 18 Feb 2015 12:01:43 +1100

See also https://tools.ietf.org/html/draft-andrews-dns-no-response-issue-07

6.  Response Code Selection

   Choosing the correct response code when fixing a nameserver is
   important.  Just because a type is not implemented does not mean that
   NOTIMP is the correct response code to return.  Response codes need
   to be chosen considering how clients will handle them.

   For unimplemented opcodes NOTIMP is the expected response code.

   In general, for unimplemented type codes Name Error (NXDOMAIN) and
   NOERROR (no data) are the expected response codes.  A server is not
   supposed to serve a zone which contains unsupported types ([RFC1034])
   so the only thing left is return if the QNAME exists or not.  NOTIMP
   and REFUSED are not useful responses as they force the clients to try
   all the authoritative servers for a zone looking for a server which
   will answer the query.

   Meta queries type may be the exception but these need to be thought
   about on a case by case basis.

   If you support EDNS and get a query with a unsupported EDNS version
   the correct response is BADVERS [RFC6891].

   If you do not support EDNS at all FORMERR and NOTIMP are the expected
   error codes.  That said a minimal EDNS server implementation just
   requires parsing the OPT records and responding with a empty OPT
   record.  There is no need to interpret any EDNS options present in
   the request as unsupported options are expected to be ignored
   [RFC6891].