Subject: [dane] Barry Leiba's Discuss on draft-ietf-dane-smtp-with-dane-17: (with DISCUSS and COMMENT)

From: "Barry Leiba" <[email-masked]>
Date: Sun, 24 May 2015 13:41:21 -0700

Barry Leiba has entered the following ballot position for
draft-ietf-dane-smtp-with-dane-17: Discuss

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-smtp-with-dane/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Nothing fundamental here; I just have three things I'd like to sort out
before balloting "yes" on this, and they should all be easy to resolve:

1. References and terminology:
You use RFC 1034 to define "RR", and RFC 5598 to define "MSA", "MTA", and
"MUA".  And these are definitions that must be understood in order to
properly understand this document.  I think that makes those normative
references, not informative ones, and they should be changed.  (5598 is
already in the downref registry, so,there's no problem with the downref
here.)

2. Section 2.2.1 says this:

   That said, the protocol in this memo is
   an "opportunistic security" protocol, meaning that it strives to
   communicate with each peer as securely as possible, while maintaining
   broad interoperability.  Therefore, the SMTP client MAY proceed to
   use DANE TLS (as described in Section 2.2.2 below) even with MX hosts
   obtained via an "insecure" MX RRSet.  For example, when a hosting
   provider has a signed DNS zone and publishes TLSA records for its
   SMTP servers, hosted domains that are not signed may still benefit
   from the provider's TLSA records.

That makes sense.  Why doesn't the same thing apply for insecure TLSA
records?  Section 2.2 says that when TLSA records are insecure, you don't
use them, and SHOULD use pre-DANE security.  Please explain why they
shouldn't use insecure TLSA records for opportunistic encryption.

3. In Section 2.2.1:

   When DANE TLS is mandatory (Section 6) for
   a given destination, delivery MUST be delayed when the MX RRSet is
   not "secure".

This contradicts the "delivery MAY proceed" in the previous paragraph
(and it also doesn't really fit into the paragraph about logging anyway).
 If you want to restrict things, I think you should put the most
restrictive condition first, so move this sentence to the top of the
previous paragraph this way:

OLD
   If the MX RRSet (or any CNAME leading to it) is "insecure" (see
   Section 2.1.1), DANE TLS need not apply, and delivery MAY proceed via
   pre-DANE opportunistic TLS.
NEW
   If the MX RRSet (or any CNAME leading to it) is "insecure" (see
   Section 2.1.1), then if DANE TLS is mandatory (Section 6) for
   the given destination, delivery MUST be delayed.  If DANE TLS
   is not mandatory, then it need not apply, and delivery MAY proceed
   via pre-DANE opportunistic TLS.
END

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

-- Section 2.2 --

   contrast, DNSSEC validated TLSA records MUST NOT be published for
   servers that do not support TLS.  Clients can safely interpret their
   presence as a commitment by the server operator to implement TLS and
   STARTTLS.

I don't know that this needs any text changes, though perhaps a mention
of this in the Security Considerations would be good: I'm not sure how
"safely" they will be able to do that in practice.  Remember that the
people running the email severs often have no connection to the people
who will insert or remove the TLSA records from the DNS.  It's possible
that a software change in the mail servers will remove support for DANE,
and the TLSA record will not be correspondingly removed.

I'm hoping that once this really gets rolled out, that won't be a real
issue, but it could be for a while.  It might be worth saying in the
Security Considerations that such a situation needs to be avoided, and
coordination is important, to make sure it doesn't happen.  Otherwise,
according to Section 2.2, mail delivery from DANE-aware MTAs will fail.

-- Sections 2.2.1 and 2.2.2 --

In 2.2.1:
   In the absence of DNS lookup errors (Section 2.1.1), if the MX RRset
   is not "insecure" then it is "secure", and the SMTP client MUST treat
   each MX hostname as a separate non-MX destination for opportunistic
   DANE TLS (as described in Section 2.2.2).

In 2.2.2:
   This section describes the algorithm used to locate the TLSA records
   and associated TLSA base domain for an input domain that is not
   subject to MX resolution or that lacks MX records.

I find this combination unnecessarily confusing -- it starts to sound a
bit like Fizzbin
<http://en.wikipedia.org/wiki/List_of_games_in_Star_Trek#Fizzbin>.  I
know it's explained further (which is why this isn't a DISCUSS point),
but I think clarity in the introduction would help a lot.  I suggest
this, but anything similar would be equally helpful:

NEW
   In the absence of DNS lookup errors (Section 2.1.1), if the MX RRset
   is not "insecure" then it is "secure", and the SMTP client MUST treat
   each MX hostname as described in Section 2.2.2.
END

NEW
   This section describes the algorithm used to locate the TLSA records
   and associated TLSA base domain for an input domain that is not
   subject to MX resolution, that represents a hostname from a secure MX
   RRset, or that lacks MX records.
END

That latter ordering matches the order of the bullet list, and I think
that's useful for making the text understandable.  You might also
re-think the title for Section 2.2.2, but I think that's less important.

-- Section 2.2.3 --

   If the ultimate response is a "secure" TLSA RRSet, then the candidate
   TLSA base domain will be the actual TLSA base domain and the TLSA
   RRSet will constitute the TLSA records for the destination.  If none
   of the candidate TLSA base domains yield "secure" TLSA records then
   delivery MAY proceed via pre-DANE opportunistic TLS.  SMTP clients
   MAY elect to use "insecure" TLSA records to avoid STARTTLS downgrades
   or even to skip SMTP servers that fail authentication, but MUST NOT
   misrepresent authentication success as either a secure connection to
   the SMTP server or as a secure delivery to the intended next-hop
   domain.

When SMTP clients elect to use insecure TLSA records, this text implies,
but doesn't make it completely clear, that they should only do that after
checking all candidates.  It would be good to be clear: check all
candidates, stopping at the first secure TLSA.  If no candidates produce
secure TLSA, then you MAY use an insecure one, or you MAY use pre-DANE
TLS.  Is that right?

In general, I strongly encourage you to review Section 2.2.3 and make
sure that it reads smoothly to someone who's not already familiar with
the DANE SMTP work.  I'm not sure the organization of the thoughts in
this section is very good as it's currently written.

-- Section 3.1 --

   In summary, we RECOMMEND the use of either "DANE-EE(3) SPKI(1)
   SHA2-256(1)" or "DANE-TA(2) Cert(0) SHA2-256(1)" TLSA records
   depending on site needs.

But later, in Section 3.1.1, you specifically single out the former:

   TLSA records published for SMTP servers SHOULD, in most cases, be
   "DANE-EE(3) SPKI(1) SHA2-256(1)" records.

To be more consistent in your advice, I suggest changing the advice in
3.1 thus:

NEW
   In summary, we RECOMMEND the use of "DANE-EE(3) SPKI(1)
   SHA2-256(1)", with "DANE-TA(2) Cert(0) SHA2-256(1)" TLSA
   records as a second choice, depending on site needs. See
   the following two subsections for more details.
END

If that's not the advice you mean to give, then something is unclear.

-- Section 3.1.1 --

   Similarly, the expiration date of the server certificate MUST be
   ignored, the validity period of the TLSA record key binding is
   determined by the validity interval of the TLSA record DNSSEC
   signature.

Editorial: "Similarly" to what?  I'd remove the word.  Also, the comma
after "ignored" needs to be a colon (or a semicolon, but I think a colon
is better here; the comma splice is just wrong).

   With DANE-EE(3) servers need not employ SNI (may ignore the client's
   SNI message) even when the server is known under independent names

Editorial: This needs a comma after "DANE-EE(3)", and would do well with
"they" before "may ignore").

-- Section 3.1.1 --

   Such servers MUST either publish DANE-TA(2)
   records for an intermediate certificate or MUST instead use DANE-
   EE(3) TLSA records.

The first "MUST" should be moved one word later, after "either" (or else
the second "MUST" should be removed).

-- Section 3.1.3 --

   Note, this section applies to MTA-to-MTA SMTP on port 25.

Earlier, in 2.2.3, you note that "the destination TCP port is typically
25, but this may be different with custom routes specified by the MTA
administrator".  I don't think you mean for this section not to apply in
the latter case, so I suggest changing this to, "Note, this section
applies to MTA-to-MTA SMTP, which is normally on port 25."

   Nothing is lost since the
   PKIX certificate usages cannot aid SMTP TLS security, they can only
   impede SMTP TLS interoperability.

Editorial: You need a comma after "lost", and the existing comma needs to
be a semicolon.

The last paragraph of the section is missing a final period.

-- Section 6 --

   Administrators of mail servers that employ mandatory DANE TLS, need
   to carefully monitor their mail logs and queues.

Nit: the comma should be removed.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 25 May 2015 02:04:30 +0000

> already in the downref registry, so,there's no problem with the downref

No objections from me.  If nobody else objects, I'll move these to
normative in a few days.

>    broad interoperability.? Therefore, the SMTP client MAY proceed to
>    obtained via an "insecure" MX RRSet.? For example, when a hosting

If I recall correctly, the working group was concerned about diluting
the otherwise clear position that TLSA should not be used without
DNSSEC.

In the context this draft alone, the main reason to avoid using
TLSA records from insecure zones, is that lookups of such records
are prone to failures (with long timeouts while trying all NS
records) against "bare-bones" nameservers that support neither
DNSSEC nor TLSA records.

When the MX RRset is secure, but the A/AAAA records are insecure,
no TLSA lookup takes place.  I think that proceeding with (soft-fail)
TLSA lookups when the MX RRset is insecure invites implementation
errors.

>    via pre-DANE opportunistic TLS.

Thanks, this is a big improvement.  Perhaps the "MAY proceed" should
probably also be clarified.  The intention is to note the possibility
of using pre-DANE TLS (which is not required, cleartext is also
allowed).  It is not the intention of this text to make using the
MX host optional.  Delivery, with or without TLS, MUST be attempted.

So perhaps better still:

    NEW
       If the MX RRSet (or any CNAME leading to it) is "insecure" (see
       Section 2.1.1), then if DANE TLS is mandatory (Section 6) for
       the given destination, delivery MUST be delayed.  If DANE TLS
       is not mandatory, then DANE does not apply and delivery proceeds
       with pre-DANE opportunistic TLS (perhaps even in cleartext).
    END

> -- Section 2.2 --
> 
>    ... DNSSEC validated TLSA records MUST NOT be published for
> "safely" they will be able to do that in practice.

Indeed the "safely" is the result of the server mandate, and also the
problems servers will incur when they mess up, once this protocol is
adopted sufficiently widely.  So "safely" is somewhat forward-looking.
Should such a note be in "Security" or "Operational" considerations?
And is it really needed?

> according to Section 2.2, mail delivery from DANE-aware MTAs will fail.

We're on the same page, the only question is whether this is
sufficiently obvious to avoid needing to explain it.

>    RRset, or that lacks MX records.

Much better, thanks.  When would you like to see a new version with
these changes?  (I am guessing I should wait for any additional IESG
comments?)

> You might also

I see what you mean, but nothing obvious comes to mind.  Is "Post-MX"
better than "Non-MX"?

>    the SMTP server or as a secure delivery to the intended next-hop

Thanks for highlighting this.  The same fix as above for "MAY
proceed via pre-DANE opportunistic TLS" should likely be applied
here.

> checking all candidates.

Yes.  There are at most two choices (before and after CNAME
expansion).  The expansion is tried first, and if that is not
secure, and there was in fact CNAME indirection, the origin MUST
be tried.  If the origin is secure, that MUST be used.

I can tweak this text for more clarity.

> It would be good to be clear: check all

Yes, and that "last" MAY, is really a "free to use TLS the old
way", but in any case MUST use the destination with whatever security
you can get.  No skipping of insecure MX hosts.  Adherence to MX
preference first, channel security second.

> this section is very good as it's currently written.

Noted.  How should I communicate any proposed revisions?

>    SHA2-256(1)" or "DANE-TA(2) Cert(0) SHA2-256(1)" TLSA records

Indeed, these two are a sufficient best-practice set to cover all
needs.

>    "DANE-EE(3) SPKI(1) SHA2-256(1)" records.

The vast majority of sites should (and do in fact among the early
adopters) stick to usage DANE-EE(3), the DANE-TA(2) case is for
select sites with an internal PKI (private CA) and lots of servers.

>    the following two subsections for more details.

This works.  Thanks.

> is better here; the comma splice is just wrong).

Will do.

> "they" before "may ignore").

Thanks.

> the second "MUST" should be removed).

Thanks, no problem.

> applies to MTA-to-MTA SMTP, which is normally on port 25."

Thanks.  Indeed that's the correct formulation.

> The last paragraph of the section is missing a final period.

No worries.

> Nit: the comma should be removed.

Thanks.

-- 
	Viktor.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 25 May 2015 19:17:09 -0400

> On May 24, 2015, at 10:04 PM, Viktor Dukhovni <[email-masked]> wrote:
> 
Fine by me 

> the otherwise clear position that TLSA should not be used without

Barry, the working went down this path at one point and it turns quickly into a quicksand of special cases. 
For that reason we are not in base documents allowing TLSA w/o DNSSEC, 
Same goes for Service Records (SRV + MX) as if those are forged there is no value in TLSA for the forged 
servers. 
IMHO we should hold SRV and MX records to the same standard and IESG has blessed the SRV doc with
DNSSEC MUST, so I will object strongly to any attempt to lower the requirements. 

> TLSA lookups when the MX RRset is insecure invites implementation

+1 

>       with pre-DANE opportunistic TLS (perhaps even in cleartext).

+1 

> Should such a note be in "Security" or "Operational" considerations?

IMHO this just stating the obvious, it is harmless from a security perspective. 
If something like this is needed then maybe we need "TLSA for Dummies” statement. 
  DANE for SMTP requires the following: 
       - SMTP servers MUST support SSL, zone with MX record MUST be DNSSEC signed, 
       - at least one zone with mail server names MUST be DNSSEC signed, and the mail server name  MUST have TLSA records below it at  _xxx._smtp.<mail-server> 

> sufficiently obvious to avoid needing to explain it.

Agree, 

> these changes?  (I am guessing I should wait for any additional IESG

+1

> I can tweak this text for more clarity.

+1

>> Nit: the comma should be removed.

Thanks Barry and Victor for careful review any good response 

Olafur

---

From: Mark Andrews <[email-masked]>
Date: Tue, 26 May 2015 10:03:37 +1000

In message <[email-masked]>, Olafur Gudmundsson 
> DNSSEC MUST, so I will object strongly to any attempt to lower the 

In addition it is just plain pointless to do the lookup.

If the A/AAAA is insecure the TLSA lookup will be insecure due to
there being not DNSSEC trusted path the TLSA node.  You can't prove
whether the server was supposed to offer STARTTLS or not.  Faked
answers can "prove" either assertion.

You don't get a viable trust anchor if you do get back a TLSA record
as the answer will be insecure.  SMTP servers can already be
configured to accept CERTS where you don't have a trust anchor for
that server if you just want to have a encrypted stream to stop
casual snooping of traffic and the server happens to say it supports
STARTTLS.

> > records) against "bare-bones" nameservers that support neither

The main reason for not doing the lookup is that it is pointless
(see above).  The very much secondary reason for not doing the
lookup is that there is a very small percentage of servers that
mishandle TLSA lookups.  SMTP servers are going to have to handle
these broken servers once they get secure A/AAAA responses.

draft-andrews-dns-no-response-issue is looking at the issues of
servers that don't respond or respond incorrectly.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Mon, 25 May 2015 20:31:23 -0400 (EDT)

On Tue, 26 May 2015, Mark Andrews wrote:

> there being not DNSSEC trusted path the TLSA node.

I don't understand this. Wether the A/AAA is spoofed or someone
with sufficient power to redirect routing of that range to them
is the same thing. So even if the A/AAAA were trusted by DNSSEC,
you don't know if you are talking to the real or rogue servers
in that IP.

>  You can't prove
> whether the server was supposed to offer STARTTLS or not.

Yes you can? The presence of TLSA means you MUST do STARTTLS,
and not downgrade to plaintext. Sure, it can be spoofed but
you're not posting anything signed with DNSSEC, you're not
losing any security here?

>  Faked answers can "prove" either assertion.

Sure. Not signing will not help against active attacks. But publishing
unsigned could help you agaisnt passive attacks.

> casual snooping of traffic and the server happens to say it supports

That is true. You don't win much by an out-of-band insecure TLSA lookup.

> these broken servers once they get secure A/AAAA responses.

If broken servers are indistinguishable from an attack, then it is
an attack, and things should break. (yes spoken without operator hat on)

>>> TLSA lookups when the MX RRset is insecure invites implementation

I don't like that because I would like to be able to publish TLSA
records in my nohats.ca zone pointing to some mail service I use
that uses certificates but are not themselves dnssec signed. eg:

nohats.ca. IN MX 5 mail.insecure-bigmail.com.
nohats.ca. IN TLSA <blob>

As for insecure TLSA records themselves, while I would prefer we
would use them in a better-than-nothing sense, I am more fearful of
implementations just not bothering or forgetting to check for DNSSEC
and blindly trusting these. So I think it is more clear to just say
ignore insecure TLSA records.

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 26 May 2015 01:28:12 +0000

On Mon, May 25, 2015 at 08:31:23PM -0400, Paul Wouters wrote:

> I don't understand this.

Let's make it specific.  If the zone containing

    smtp.example.com. IN A 192.0.2.1

is unsigned (whether because example.com is unsigned, or because
"smtp.example.com" is itself a delegated 'insecure' zone), then
it is exceedingly unlikely (a miracle) if somehow the associated
TLSA RRset:

    _25._tcp.smtp.example.com. IN TLSA 3 1 1 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

is "secure".  For that to happen, there would have to be an explicit
DNSSEC trust-anchor for either "_tcp.smtp.example.com" or
"_25._tcp.example.com" configured in the validating resolver.

Since that's going to happen basically "never", the client just
assumes the inevitable outcome, and avoids the lookup.

The canonical problem case is "nist.gov".  Their zone is signed
and MX lookups yield a "secure" result:

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

If address record lookups that lead to "insecure" answers:

    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2284
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
    nist-gov.mail.protection.outlook.com. A 207.46.163.247
    nist-gov.mail.protection.outlook.com. A 207.46.163.170
    nist-gov.mail.protection.outlook.com. A 207.46.163.138

are not used to infer that "TLSA" is also "insecure" and thus to
suppress TLSA lookups, then TLSA lookups fail, and to avoid
"downgrade" attacks no mail is delivered to "nist.gov".

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

Such failures would make deployment of DANE TLS for SMTP unattractive
to MTA administrators.  The proposed language (implemented in
Postfix and Exim) avoids this problem.  We've discussed this before.

> Wether the A/AAA is spoofed or someone
> is the same thing.

The A/AAAA lookups serve to discover whether the zone with the
server name is signed.  We don't actually care whether the address
records are secure.  We could query for any other record that
"bare-bones" nameservers don't mishandle, but since the A
records will be needed anyway, we use those.

> nohats.ca. IN TLSA <blob>

This does you no good anyway, because queries for TLSA records with
MX and SRV services are made for the "_<port>._tcp.<target host>"
NOT "_<port>._tcp.<service domain>".  Nor are you particulary likely
to reliably publish accurate TLSA records for a server operated by
a third party.  Inevitably they'll make changes on their end, and
your mail will stop.  So this is not an option.

> ignore insecure TLSA records.

I think we agree on that.

-- 
	Viktor.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 26 May 2015 11:33:12 +1000

In message <[email-masked]>, Paul Wouters wr
> you don't know if you are talking to the real or rogue servers

If the A/AAAA result is secure you do the TLSA lookup.
 
> losing any security here?

If the answer is INSECURE you can't prove the TLSA exists.  The
MUST only applies if you get a SECURE response to the TLSA record
which will not happen if the A/AAAA response is insecure.

> unsigned could help you agaisnt passive attacks.

And you can tell the difference how?

Spoofed affirmative TLSA responses can lead to a DoS if they are
accepted either because the server does not offer STARTTLS or the
TLSA does not match the CERT offered.

> nohats.ca. IN TLSA <blob>

Which no SMTP client will lookup.  Much better to write to their
support@ address and say you are moving your email to someone that
supports TLSA if they don't add the records with <reasonable period>
them carry through with the threat if they don't.  There is nothing
stopping any SMTP service operator configuring and signing TLSA
records other than pigheadedness on the part of the operator.

> ignore insecure TLSA records.

Except they are not better-than-nothing.  Using them requires that
you deal with the failure modes of dealing with them.  They introduce
their own new threats.  They also don't enhance security.

Ignoring them doesn't prevent opportunic use of STARTTLS.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 25 May 2015 21:40:09 -0400 (EDT)

> which will not happen if the A/AAAA response is insecure.

I forgot the whole level of indirection looking up the TLSA at the
mail server names instead of the domain zone itself. I never liked
these but I understand why it's the least worst solution.

Thanks Mark and Viktor for explaining it to me, again....  :)

Paul

---

From: Mark Andrews <[email-masked]>
Date: Tue, 26 May 2015 12:19:14 +1000

In message <[email-masked]>, Viktor Dukhovni writ
>     ;_25._tcp.nist-gov.mail.protection.outlook.com. IN TLSA

The servers for outlook.com also don't handle EDNS version negotiation
or unknown EDNS options.  ISC is intending to ship BIND 9.11.0 with
DNS COOKIES enabled by default.  There is going to be more pain
than just TLSA lookups once that happens.  See the following report
for all the EDNS compliance errors with the servers for outlook.com.

	https://ednscomp.isc.org/ednscomp/6840acd09c

Yes, Microsoft were informed months ago that their servers are not
EDNS compliant and that what we intend to ship servers that won't
work with the servers they are using.

Fixing these bugs should take less than 5 minutes for a developer
of the nameservers Microsoft are using.  They are trivial compliance
bugs.

Add:
	/* If the EDNS version is != 0 send BADVERS as the error code. */
	if (opt != NULL && ((opt->ttl >> 16) & 0xff) != 0) {
		send_error(rcode = BADVERS);
		return;
	}

Remove:

	if (opt != NULL && opt->rdlen != 0) {
		send_error(rcode = FORMERR);
		return;
	}

As unknown EDNS options are supposed to be ignored.

Reconfigure the firewall to ignore EDNS version in the opt record
on 3 of the servers.

Fixing the TLSA issue is also similar.  It should result in a NOERROR
no data response.  Stop sending NOTIMP on unknown types that are
not reserved for META queries.  The handling of non meta query types
was documented over a decade ago.  The servers are capable of sending
valid NOERROR no data responses which this mx response demonstrates.

; <<>> DiG 9.11.0pre-alpha <<>> +noedns mx _25._tcp.nist-gov.mail.protection.outlook.com @ns2-proddns.glbdns.o365filtering.com +norec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56970
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;_25._tcp.nist-gov.mail.protection.outlook.com. IN MX

;; AUTHORITY SECTION:
mail.protection.outlook.com. 3600 IN	SOA	ns1-proddns.glbdns.o365filtering.com. hostmaster.o365filtering.com. 2013010801 3600 600 86400 3600

;; Query time: 188 msec
;; SERVER: 207.46.100.42#53(207.46.100.42)
;; WHEN: Tue May 26 12:13:19 EST 2015
;; MSG SIZE  rcvd: 190

It's not like sending the wrong response code is a new issue.  We
have CERT advisories issued in the past for just such misbehaviour
(NXDOMAIN in response to AAAA queries).

Is it going to require someone writing up a CERT advisary for load
balancer vendors to fix their broken servers?

> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

---

From: Barry Leiba <[email-masked]>
Date: Mon, 25 May 2015 22:58:01 -0400

Quick response for tonight, with a fuller one on Tuesday, NY time:
Thanks for the responses, Viktor and Olafur.  Between the two, you've
explained what I need for DISCUSS point 2.  Tomorrow I'll clear the
DISCUSS completely and give a better email response (short version:
all is good on all comments, and thanks).

As to when to post a revised I-D: my preference is always "early and
often", but you should check with Stephen, as he's the responsible AD.

Barry

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 26 May 2015 11:34:45 +0100

> often", but you should check with Stephen, as he's the responsible AD.

If you're ready to post before close-of-business Tuesday
please do so. Otherwise holding until Friday after the
telechat is fine.

S.

---

From: Barry Leiba <[email-masked]>
Date: Tue, 26 May 2015 08:44:51 -0400

Time for a proper reply now.  I've already cleared the DISCUSS and
recorded the resolution in the tracker comments, but I didn't have it
re-send the message (this will serve for that).  I'm adding the IESG
list back to the CC on this reply.  Anything I don't mention is stuff
we agree on that needs no further comment.  And thanks for considering
all my comments and addressing them.

Olafur further adds:
> Barry, the working went down this path at one point and it turns quickly into
> a quicksand of special cases.  For that reason we are not in base documents
> allowing TLSA w/o DNSSEC, Same goes for Service Records (SRV + MX)
> as if those are forged there is no value in TLSA for the forged servers.
> IMHO we should hold SRV and MX records to the same standard and IESG
> has blessed the SRV doc with DNSSEC MUST, so I will object strongly to
> any attempt to lower the requirements.

I'm happy with the explanation (and that the issue was discussed by
the working group, so I've removed this comment entirely.  Thanks for
the discussion.

>        with pre-DANE opportunistic TLS (perhaps even in cleartext).

Yes, that looks great, so keep that one.  Thanks for further tweaking it.

> sufficiently obvious to avoid needing to explain it.

You're probably right, and this is entirely up to your judgment.  If
you see anything you think is worth adding, fine; if not, that's also
fine.

> I see what you mean, but nothing obvious comes to mind.  Is "Post-MX"

Hm.  Yes, perhaps.  Again, to your judgment on this, including not
making any change if that's what you think best.

> preference first, channel security second.

Thanks... whatever you decide will be fine.

> Noted.  How should I communicate any proposed revisions?

No need to communicate them explicitly: I trust you to review it and
do what you can to organize it.  This was (and is) a non-blocking
comment.  Thanks in advance for giving it another look.

Barry

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 26 May 2015 13:37:04 +0000

> please do so. Otherwise holding until Friday after the

OK, I think I beat the deadline.  I hope the result meets
expectations:

    https://www.ietf.org/rfcdiff?url1=draft-ietf-dane-smtp-with-dane-17&url2=draft-ietf-dane-smtp-with-dane-18

If there's anything I missed, or goofed up, let me know, I'll fix
it after the telechat.

-- 
	Viktor.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 26 May 2015 14:38:30 +0100

> If there's anything I missed, or goofed up, let me know, I'll fix

Thanks Viktor, I'll ask Barry if he has time to check the diff
matches his comments.

Cheers,
S.

---

From: Barry Leiba <[email-masked]>
Date: Tue, 26 May 2015 10:20:42 -0400

> If there's anything I missed, or goofed up, let me know, I'll fix

No goofs that I see, and it looks like everything's covered.  Thanks
again for the responses, and for the quick turnaround.

Barry