Subject: [dane] I-D Action: draft-ietf-dane-smtp-with-dane-08.txt

From: [email-masked]
Date: Wed, 23 Apr 2014 20:12:28 -0700

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 Working Group of the IETF.

        Title           : SMTP security via opportunistic DANE TLS
        Authors         : Viktor Dukhovni
                          Wes Hardaker
	Filename        : draft-ietf-dane-smtp-with-dane-08.txt
	Pages           : 32
	Date            : 2014-04-23

Abstract:
   This memo describes a downgrade-resistant protocol for SMTP transport
   security between Mail 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).

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dane-smtp-with-dane/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-08

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-smtp-with-dane-08

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: Viktor Dukhovni <[email-masked]>
Date: Thu, 24 Apr 2014 03:38:25 +0000

> http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-smtp-with-dane-08

I've updated to the document to add text that describes in more
detail name checks (RFC 6125 requirements) for SMTP with opportunistic
DANE TLS.

    - Presence of DNS-IDs preempts CN-ID processing, but CN-ID is
      supported in the absence of DNS-IDs.

    - No partial-label wildcards.

    - Single label wildcards are supported in both DNS-IDs and CN-IDs.

    - Multi-label wildcards are a local policy option for the client,
      servers should not expect this to be supported.

In addition I clarified the DANE-TA(3) matching rules (no name checks,
no expiration checks).

For DANE-TA(2), servers are encouraged to stick to selector Cert(0),
because SPKI(1) does not cover potentially important TA certificate
elements.  Use of matching type Full(0) is discouraged.

Note, digest algorithm agility remains unchanged, though we may
not yet have "rough consensus" for it, we have some significant
support.

Please review the diffs.  This is also a good time to read the
entire document if you have not done that yet.  Any remaining
changes should be minor.

Spelling, grammar, clarity suggestions appreciated.  Github
pull requests would be great:

    https://github.com/vdukhovni/ietf

I'll update the HTML periodically at:

    http://vdukhovni.github.io/ietf/draft-ietf-dane-smtp-with-dane-08.html

-- 
	Viktor.

---

From: Tom Ritter <[email-masked]>
Date: Fri, 25 Apr 2014 17:57:24 -0400

That's a long one.  I have a few comments, most of them minor.  I
found only one typo.

-------------------

Section 2.2.2, Regarding the problem nameservers for
largeemailprovider.com:  If an insecure MX record is returned pointing
to largeemailprovider.com, skip TLSA lookup, because even if we got a
signed response, the insecure MX to the domain could have been
MITM-ed. Makes sense.

But I wonder if there might be a scenario where the insecure MX record
appears to be insecure, but is not actually.  In which case the TLSA
lookup would provide security.  For example, if an admin specifically
configures a mapping inside the smtpd (I think this is transport_maps
in postfix?) - this type of mapping _could_ be labeled as 'secure'
inside the data structures, because of it's origination, but this
would be more state to track through more functions.  Another example
would be locally configured DNS names (smtp_host_lookup with 'native'
in postfix?) - maybe a .local domain that resolve to public IP space
or overrides in /etc/hosts. These are securely delivered even though
they're not DNSSEC.

I agree that skipping the TLSA record after getting a public insecure
MX record cannot increase security. But I don't think it decreases it
either. I think it mainly affects latency. And there may be situations
where the smtpd cannot distinguish between 'no DNSSEC and insecure'
and 'no DNSSEC but I can trust anyway.'  So I would suggest a SHOULD
proceed with TLSA lookup instead of a SHOULD NOT, noting that it in
_most_ cases it won't actually increase security but we'll give it a
shot because it won't _hurt_ security either.

If there were mechanisms in a MTA to somehow flag a message as
'securely delivered', which I don't believe there are, they would not
apply.

-------------------

    example.com.                IN MX 0 mx1.example.com.
    example.com.                IN MX 0 mx2.example.com.

Forgive my ignorance, but these are MX records each with a 0 priority,
right?  If so, maybe make it '10' and '20' as it would be more
apparent to people like me. There are at least two places this is
used.

-------------------

These paragraphs are spread around, but say the same thing.

   The SMTP client SHOULD NOT deliver
   mail via the corresponding host unless a TLS session is negotiated
   via STARTTLS.  This is required to avoid MITM STARTTLS downgrade
   attacks.

   ...

   When at least one usable "secure" TLSA record is found, the SMTP
   client SHOULD use TLSA records to authenticate the SMTP server.
   Messages SHOULD NOT be delivered via the SMTP server if
   authentication fails, otherwise the SMTP client is vulnerable to MITM
   attacks.

Perhaps the first should say behavior is defined in Section 2.3.2 (the second)?

It also seems to contradict the later paragraph in 6.1:

   Unless
   local policy specifies "audit only" or that opportunistic DANE TLS is
   not to be used for a particular destination, an SMTP client MUST NOT
   deliver mail via a server whose certificate chain fails to match at
   least one TLSA record when usable TLSA records are found for that
   server.

-------------------

It took me a good long time, but I finally found a typo (missing
period).  This was the only typo I found.

   name is based entirely on the TLSA record association The server MUST

-------------------

Section 2.3.1.3

Strong disagree with this paragraph:

   SMTP client treatment of TLSA RRs with certificate usages "PKIX-
   TA(0)" or "PKIX-EE(1)" is undefined.  For example, clients MAY (will
   likely) treat such TLSA records as unusable.

First off, I think it's inappropriate to use capital MAY in an example
about how clients might behave, immediately after saying it's
undefined. Lowercase 'may', sure, but capital implies something else.

Second off, I think it's inappropriate to suggest that clients ignore
these settings. I agree with the sentiment that it has no increase in
security.  I also bet you some large corporation or government agency
somewhere has some requirement to publish CA-validated certs only, and
thus would need to publish these usages anyway.

I think it is better said that clients SHOULD process these TLSA
records and MAY treat them as the corresponding PKIX-less variants.
(And leaving it stated that servers SHOULD NOT publish these
variants.)

-------------------

Is it really necessary to include the Reference Identifier Matching in
2.3.2.3?  It can't be referenced in another document? The behavior
seems different from what is actually valid in other contexts, and
omits some restricts as I understand them.

-------------------

   Suppose that a DANE TLS client authenticating a TLS server considers
   digest algorithm BETTER stronger than digest algorithm WORSE.

I would suggest renaming these algorithms to something like
"AlgoBetter" and rephasing it "considers a digest algorithm named
AlgoBetter to be stronger than...".  This avoids the backtracking
needed to realize that BETTER is a name, and not an emphasized
adjective.

-------------------

   If the client sends no SNI extension,
   or sends an SNI extension for an unsupported domain, the server MUST
   simply send its default certificate chain.

To me it seems it would be more appropriate to say that the server
MUST send some certificate chain, and the choice of which certificate
chain to send is left undefined.

-------------------

I can submit github PRs for these sometime next week if desired.

-tom

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 26 Apr 2014 03:34:27 +0000

> signed response, the insecure MX to the domain could have been

That's not the point of 2.2.2, the specific provider dealt with in
2.2.2, which does not get named in the RFC, but was mentioned in
prior list discussion so the issue is more concrete is:

    $ dig +adflag +noall +comment +ans -t mx nist.gov
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16582
    ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

    ;; ANSWER SECTION:
    nist.gov.     IN      MX      0 nist-gov.mail.protection.outlook.com.

The MX record is in fact in a DNSSEC signed zone, and is secure,
what is not DNSSEC signed is:

    $ dig +adflag +noall +comment +ans -t a nist-gov.mail.protection.outlook.com
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48597
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

    ;; ANSWER SECTION:
    nist-gov.mail.protection.outlook.com. 10 IN A   207.46.163.215
    nist-gov.mail.protection.outlook.com. 10 IN A   207.46.163.247
    nist-gov.mail.protection.outlook.com. 10 IN A   207.46.163.138
    nist-gov.mail.protection.outlook.com. 10 IN A   207.46.163.170

Furthermore, TLSA lookups via recursive resolvers SERVFAIL:

    $ dig +adflag +noall +comment +ans -t tlsa _25._tcp.nist-gov.mail.protection.outlook.com
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 36237
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

because, the authoritative nameservers are broken:

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

> appears to be insecure, but is not actually.

No, there is not.

> For example, if an admin specifically

A nexthop override is NOT an MX record and is considered secure,
it is locally specificied.  Such a nexthop (with many MTAs) might
still be subject to MX records, and in that case, the security of
those MX records is what matters.  I'm afraid you've got yourself
somewhat confused here...

This case is handled correctly both in Postfix and in the draft.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 26 Apr 2014 03:56:50 +0000

On Fri, Apr 25, 2014 at 05:57:24PM -0400, Tom Ritter wrote:

> Another example

Names not found via DNS at all, or found via DNS, but not in DNSSEC
signed zones are out scope for DANE.

> So I would suggest a SHOULD

For common vocabulary it may be helpful to read:

    http://tools.ietf.org/html/draft-ogud-dane-vocabulary-02

Attempting to do DANE post insecurely obtained DNS Navigation (NS,
CNAME, DNAME) or Service Specification Records (MX, SRV, ...) seems
futile.  In such a scenario is largely sufficient to just do
unauthenticated opportunistic TLS.  If there is no MiTM the outcome
is the same, and if there is an active attack, you've likely lost
by the time you've followed the insecure MX records.

Yes, if the MX hostname is a secure zone and TLSA records exist,
you're arguably "half-secure" if you use them, in that if the MX
record was not forged, then DANE TLSA closes the rest of the gap.

I cannot with a straight face log such email connections as "verified"
when they are not in fact verified.  Such a security chain that
consists of cast-iron links on one end and a piece of dental floss
on the other is certainly NOT suitable for mandatory DANE TLS (the
Postfix "dane-only" security level).

One might argue that with *opportunistic* DANE TLS, striving for
as much security as one can get might hypothetically include securing
the connection to a server that has TLSA records in a signed zone,
despite the fact that the Server Specification (MX) Records were
not secured.

In such a case, one would have to not consider any resulting
connection as secure (logging, user interface, ...), and yet one
would hypotheticall still refuse to use the connection when DANE
TLSA authentication fails.  Would this be a sensible extension of
*opportunistic* TLS in the presence of TLSA records?

About the most compelling use-case for this would be various unsigned
mom/pop domains hosted by a large provider (say Gmail).  If Gmail's
MX RRset is some day in a signed zone, and TLSA records exist, is
there sufficient value in enforced authentication of connections
to Gmail when delivering email to a domain whose MX records are
not signed?

Note, the MiTM attacker can easily divert the connection to some
unsigned MX host of his choice.

> 'securely delivered', which I don't believe there are, they would not

The Postfix SMTP client logs DANE authenticated connections as
"Verified".

    http://www.postfix.org/FORWARD_SECRECY_README.html#status

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 26 Apr 2014 04:31:58 +0000

These cover different protocol stages, the first STARTTLS downgrade,
the second certificate verification.

>    least one TLSA record when usable TLSA records are found for that

Thanks, here, there is indeed a MUST/SHOULD inconsistency.  I will
change 6.1 to SHOULD.  Explicit local policy always wins.

Fixed, staged for next update.

In that case you need to re-read sections 1.3, and 1.3.1--1.3.4,
which explain why PKIX *cannot* work for SMTP.  Wishing it otherwise
does not make it true.

> undefined. Lowercase 'may', sure, but capital implies something else.

I don't have a strong opinion about MAY vs. may in this context.
Anyone else care to comment?

> security.

No, the real problem is that these cannot be implemented interoperably.
Honouring such records will break email deliverability and nobody
will use opportunistic DANE TLS with SMTP.  An opportunistic protocol
has to be interoperable first, and secure second.

We're working on a definition of "opportunistic security" on the
"saag" mailing list.  And while some of the discussion has been a
bit heated, naturally over rather small issues, there is little
contorversy with respect to the idea that "opportunistic security"
is first and foremost highly interoperable, it is expected to just
work at whatever security level is possible with each peer.

Now "opportunistic DANE TLS" is an attempt to provide stronger
security for peers that publish DANE TLSA records, but not to the
point of supporting parameters that lead to widespread breakage.

Since PKIX & SMTP are oil and water, the opportunistic DANE TLS
protocol has to define PKIX out of scope, because PKIX only works
for sites that coordinate their settings, while opportunistic DANE
TLS kicks-in automatically on the fly.

> I also bet you some large corporation or government agency

That's nice, and yet they too send unecrypted email to most of the world,
and unauthenticated email to sites with self-signed certs, ...

Their hypothetical policies don't match the reality of SMTP.  They
can cut off their nose to spite their face, and refuse to do DANE
because DANE does not support PKIX, but they get no authentication
at all.

They can still do PKIX by hand with specific peers, just like
they've been doing (and I did for a decade at Morgan Stanley).
DANE does not trump local policy.  However SMTP TLS at Internet
scale cannot tolerate PKIX.  That's a fact I cannot legislate away.

> (And leaving it stated that servers SHOULD NOT publish these

No, clients SHOULD NOT process these records, as they will lead to
widespread email outages and much disappointment for publishers of
such records.

Yes, it is necessary to describe RFC 6125-style semantics for this
new SMTP with TLS protocol.  And yes it needs to be different from
prior documents which only ever covered MUA to MTA submission at
best.

> needed to realize that BETTER is a name, and not an emphasized

Sure, makes sense, staging for next update.

I guess that makes sense, staging for next update.

> I can submit github PRs for these sometime next week if desired.

I'll take of it.  Thanks.

-- 
	Viktor.

---

From: [email-masked] (Martin Rex)
Date: Sat, 26 Apr 2014 07:32:50 +0200 (CEST)

>     ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

The authoritative nameservers return a perfectly valid and reasonable
response, in full conformance with STD13.

But in case that _all_ authoritative nameserver do return NOTIMP,
then the recursive resolver is broken, because it is erroneously
turning a crystal-clear STD13-compliant permanent failure into a
temporary failure.

-Martin

---

From: James Cloos <[email-masked]>
Date: Sat, 26 Apr 2014 09:39:19 -0400

>>>>> "VD" == Viktor Dukhovni <[email-masked]> writes:

VD> I don't have a strong opinion about MAY vs. may in this context.
VD> Anyone else care to comment?

His reasoning for may is sound.

-JimC
--
James Cloos <[email-masked]>         OpenPGP: 0x997A9F17ED7DAEA6

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 26 Apr 2014 18:46:44 +0000

> response, in full conformance with STD13.

[ This particular nit-pick sub-thread is of no practical consequence,
  just a bit of pontification by all concerned, including me. Whether
  the authoritative nameservers are broken, or every resolver is broken
  is immaterial, the TLSA query needs to be suppressed either way. ]

And yet they're broken.  The query domain does not in fact exist,
and the right response is NXDOMAIN.  Had it existed, since the
servers are authoritative, the right response would be "NODATA"
(no error code and an empty answer section).

> turning a crystal-clear STD13-compliant permanent failure into a

We've been through this before:

    http://www.ietf.org/mail-archive/web/dane/current/msg06199.html

and containing thread.  I only brought it up again to bring Tom
Ritter up to speed.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 27 Apr 2014 20:12:58 +0000

On Thu, Sep 05, 2013 at 02:57:24PM -0700, Ian Fette (????????) wrote:

> Let's say that you want to know a-priori if an email will be sent over TLS.
> Three german companies are doing this already ("Email made in germany"
> campaign between web.de, gmx, and t-online) where they show their users
> distinguishing UI if the mail is being sent "securely". It's an interesting
> to see how that would work out, and personally I find it a very difficult
> UI challenge to communicate something meaningful that won't be
> misinterpreted, but anyhow... (2) gives you a signal that you could
> potentially pass on to a user, and then the user can potentially make a
> decision about whether or not they want to send the email. I think it needs
> a bit more thinking and UX studies as to whether or not this is a good
> idea, but having a signal like that does enable such use cases.
> 
> It also provides a signal that services can potentially cache as to whether
> the recipient believes their STARTTLS support is reliable or not. E.g. if
> we see such a record and don't see STARTTLS, we may decide to bounce (or
> hold) the message until we see STARTTLS again. If we've seen that record
> and it disappears as well as STARTTLS support disappearing, that might be a
> stronger signal that there's a potential MITM attack or strangeness than
> simply seeing STARTTLS disappear alone.
> 
> Basically, it's extra information, which opens up a few possibilities, and
> although it doesn't itself prevent an active MITM who is capable of DNS
> cache poisoning, it does provide extra information for use in heuristics
> and doesn't "hurt".

I am reconsidering this issue, see below:

On Sat, Apr 26, 2014 at 03:56:50AM +0000, Viktor Dukhovni wrote:

> [...]

So given that with SMTP we have an "opportunistic DANE TLS" protocol,
and that opportunistic security strives to connect to each peer
with at the advertised security capabilities of that peer, perhaps
indeed opportunistic DANE TLS with SMTP should attemt to pick up
the pieces and perform DANE authenticated delivery to MX hosts with
DNSSEC validated TLSA records, even when the MX (SSR) records were
"insecure".  We don't have enough operational experience with
opportunistic DANE TLS to determine whether such a policy would
be a net gain.

We could add a "SHOULD" to encourage implementations to employ DANE
with MX hosts that "happen to have" signed TLSA RRs, even after
"insecure" MX RRs.  Provided we state that this should be configurable,
and may be revised if operational experience proves it to be a mistake.

The resulting connection should not be represented as a secure
delivery to the next-hop domain, but may be *unambiguously*
represented as a secure connection to the MX host in question.

Anyone wish to support or oppose such a change in draft?

-- 
	Viktor.

---

From: Tom Ritter <[email-masked]>
Date: Tue, 29 Apr 2014 19:22:35 -0400

> Anyone wish to support or oppose such a change in draft?

I support, obviously.

-tom