Subject: [dane] Lukewarm discussion: DANE for opportunistic TLS protocols

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 14 Feb 2014 20:00:02 +0000

Paul Hoffman (thanks) points out that there may be prior consensus
with respect to the applicability of DANE TLSA to "discovery" of
TLS enabled services.

I was not party to the original discussion of this topic, my
apologies if I am about to repeat previously discussed ideas.

The SMTP draft defines an opportunistically secure protocol.  For
inter-domain email on Internet scale, no domain has prior knowledge
of the set of peer domains (more specifically their MX hosts) that
support TLS.

Today's MTA employ TLS opportunistically, based on the offer of the
"STARTTLS" SMTP extension in the SMTP server's EHLO response.  This
offers no protection against MITM attacks (or even transient errors,
as many SMTP clients will retry in cleartext after TLS transmission
fails).

The DANE SMTP draft aims to provide a downgrade-resistant protocol
by which SMTP clients can determine (discover if you will) that a
given SMTP server support TLS and expects DANE SMTP clients to
avoid using cleartext delivery with the server.  The associated
TLSA records are used to authenticate the server to mitigate MITM
attacks that terminate TLS (rather simply suppress it).

If determining whether TLS support is required is incompatible with
DANE, I see no purpose for the SMTP draft.  We already unauthenticated
opportunistic TLS for SMTP (STARTTLS) which is vulnerable to various
downgrade attacks.  Without a secure signal to do TLS, the downgrade
attacks remain, and opportunistic TLS does not benefit from DANE.

So I hope the group can reach consensus that it is OK to use TLSA
records to discover a requirement for TLS.  This approach is not
new with the SMTP draft, it dates back to the original SRV draft
from Tony Finch, and is still stated in the revived version of that
document.

-- 
	Viktor.

---

From: James Cloos <[email-masked]>
Date: Fri, 14 Feb 2014 17:50:38 -0500

It is important to note that many (though not all) of the original
proponents only seemed to care about http, where opportunistic tls
never caught on.

Even with ipp, where existing software actually support it, the
preference seems to be to use ipps:// (on the same port as ipp://)
or https:// (on port 443) uris over using rfc2817 tls upgrade.

But even so there were voices hoping for a mechanism to stipulate that
tls SHOULD or even MUST be used for a given name+port.

My impression at the time was that the consensus not to include language
to that effect it rfc 6698 was not consensus that such a mechanism was
undesireable, but just that it wasn’t generally enough wanted to warrant
making it a part of the base specification rather than part of some more
specific followup specification.

Clearly there needs to be a way to say ‘Use TLS when contacting this
server, even though the protocol takes extra steps to do so.’  The
existence of a relevant, secure TLSA is not an unreasonable way for
specific tls communities to do so.

Even though the broader tls community may not need (or want) such a
mechanism for their servers.

Not only do I encourage rfc publication of some mix of the dane-smtp-
with-dane and dane-srv drafts, but I do not agree that either is
contrary to the consensus for publishing what is now rfc 6698.

Once the details are worked out -- progress looks good -- that also
applies to the smime and openpgp drafts.

The only real question is whether dane-srv and dane-smtp-with-dane
should be published as two rfcs or combined into one?
(I’m leaning towards two, numerically adjacent.)

-JimC
--
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 14 Feb 2014 16:02:26 -0700

> (I’m leaning towards two, numerically adjacent.)

IMHO we need two drafts, so that we properly cover non-SMTP technologies 
like IMAP and XMPP.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 14 Feb 2014 16:48:32 -0800

> (I’m leaning towards two, numerically adjacent.)

With all due respect, there are other real questions, much more significant than that one.

One of the biggest questions that needs to be asked is not whether DANE can be used for opportunistic protocols, because of course it can, but whether DANE can be used to determine whether a server at a domain name "should" be speaking TLS at the time that a client tries to connect. Viktor makes a strong case that it does for SMTP. During the early discussions of TLSA, many people thought it should not.

Viktor's view gives us good MITM protection if the DNS channel is not broken and the client knows the DNSSEC status of its query. It also causes messages to be lost if there is an operational problem or even an unexpected mis-match on the crypto desires of the client and server. It also assumes that the person running the DNS server for a name is in active contact with the person operating the SMTP server.

Personally, I don't care about MITM protection if it comes at the cost of getting more organizations to turn on opportunistic crypto. I think DANE still has an important role in that it gives the SMTP server operator a logging capability to see if there is an MITM. Others prefer more protection against MITMs even in the face of preventable communication failures.

And, to be blunt, if we think that Viktor is right about DANE for SMTP, shouldn't DANE for HTTP have the same MITM protection and operational downsides?

--Paul Hoffman

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 15 Feb 2014 02:13:32 +0000

On Fri, Feb 14, 2014 at 04:48:32PM -0800, Paul Hoffman wrote:

> Personally, I don't care about MITM protection if it comes at
> the cost of getting more organizations to turn on opportunistic
> crypto.

One quick comment, there is no conflict between opportunistic DANE
TLS and "pre-DANE" opportunistic TLS.  So I would take issue with
"at the cost of".  If anything the two are symbiotic.

The first step for an SMTP server operator towards greater channel
security is to enable STARTTLS if they have not already done that.
At that point all TLS-enabled clients (be they DANE aware or not)
will generally send email over unauthenticated TLS.

Once the server operator determines that TLS is working satisfactorily
for all clients (observed over weeks to months) he may decide to
enable DNSSEC for his domain and if that works out OK, later publish
a TLSA "3 1 1" RRset that matches his server certificate.  The
certificate will not capriciously expire causing an SMTP outage,
it will only become invalid through explicit removal from the TLSA
RRset (presumably after it is augmented by an RR matching a new
certificate which then replaces the original).

This simplified authentication protocol for SMTP is carefully
designed to avoid most operational pitfalls, and the hope is that
it will be reliable enough to be enabled by default on clients and
stable when deployed with care on servers.

All that aside, the main point is that there is NO conflict between
"pre-DANE" opportunistic TLS and DANE opportunistic TLS.  The latter
is turned on only at the request of the server operator.

As to why MTA to MTA SMTP is more special in this regard than HTTPS,
the main reason is that MTAs don't generally roam into hotels,
internet cafes, and other DNSSEC hostile environments.  Being server
infrastructure MTAs are much less likely to run into MITM false
positives due to shifting network conditions.

-- 
	Viktor.

---

From: James Cloos <[email-masked]>
Date: Sun, 16 Feb 2014 19:55:21 -0500

>>>>> "PH" == Paul Hoffman <[email-masked]> writes:

JC>> The only real question is whether dane-srv and dane-smtp-with-dane
JC>> should be published as two rfcs or combined into one?  (I’m leaning
JC>> towards two, numerically adjacent.)

PH> With all due respect, there are other real questions, much more
PH> significant than that one.

Sorry.  That paragraph does not express the tone for which I aimed.

And I should have caught that fact before posting.

-JimC

---

From: Warren Kumari <[email-masked]>
Date: Mon, 17 Feb 2014 14:54:02 -0500

On Fri, Feb 14, 2014 at 7:48 PM, Paul Hoffman <[email-masked]> wrote:
>> (I'm leaning towards two, numerically adjacent.)
>

And some thought that it should -- IIRC, this, like many of the early
DANE discussions was fairly heated, and the consensus was far from
unanimous.
We ended up with a number of compromises simply so that we could make
progress...

Again, IIRC there was a suggestion that the TLSA record should be able
to signal if clients may continue without TLS / perform something
analogous to HASTLS / HSTS. This could have been a single bit, or yet
another byte.
We decided not to do that, but I wonder if in light of recent
revelations we should revisit this decision. I'm not quite sure how
we'd cram this into the current record, if it should be defined in
each of the "DANE with foo" docs or if it would require yet another RR
type...

> Personally, I don't care about MITM protection if it comes at the cost of getting more organizations to turn on opportunistic crypto. I think DANE still has an important role in that it gives the S…

Or we could give the person publishing the RR the ability to specify.

> And, to be blunt, if we think that Viktor is right about DANE for SMTP, shouldn't DANE for HTTP have the same MITM protection and operational downsides?

Personally I think that it should, but I might be in the weeds here.
W

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

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 17 Feb 2014 20:21:50 +0000

On Fri, Feb 14, 2014 at 04:48:32PM -0800, Paul Hoffman wrote:

> Viktor's view gives us good MITM protection if the DNS channel
> is not broken and the client knows the DNSSEC status of its query.
> It also causes messages to be lost if there is an operational
> problem or even an unexpected mis-match on the crypto desires of
> the client and server. It also assumes that the person running the
> DNS server for a name is in active contact with the person operating
> the SMTP server.

Some comments on the above.

    - When authetication fails, the DANE SMTP draft specifies
      "delay" (aka defer, queue, ...) not bounce.  Provided the
      receving system operator fixes the server configuration in
      a reasonably timely manner, no mail is lost.

    - Crypto parameter mismatch for SMTP TLS is quite rare.  The
      only common problems are:

	* Microsoft Exchange 2003 only looks at the first 64 cipher
	  suites in the TLS client's SSL HELLO.  It has a broken
	  3DES implementation that mishandles CBC padding.  SMTP
	  clients that support TLS 1.2 typically have more 64 cipher
	  suites stronger than RC4-SHA and TLS connections to
	  Microsoft Exchange 2003 often fail after negotiating
	  3DES-CBC.  While such server are still found here and
	  there, operators of these would be foolish and unlikely
	  to publish TLSA records.

	* Some Debian "squeeze" systems have an Exim SMTP client
	  that was inadvisably patched by Debian to require 2048
	  bit or longer EDH primes.  These fail to handshake with
	  many servers that employ 1024 bit EDH primes.  These SMTP
	  clients do not implement DANE.  The patch has been reverted
	  in newer Debian releases.  When Exim supports DANE, we
	  can reasonably hope that Debian won't repeat their mistake.

    - As for "active contact", yes active contact is required after
      all to publish the TLSA record in the first place.  However,
      at tiny sites (say dukhovni.org) whose SMTP server certificate
      is long expired, but still pinned and thus valid enough for
      my MUA, "active contact" is a non-issue.  Simiarly, with
      DANE-EE(3) there is no need for "active contact" (though I
      admittedly am in "active contact" with myself).

      No "active contact is required" with DANE-TA(2).  The DNS
      folks and the folks operating the domain's CA publish new
      TLSA RRs for the latest CA keys from time time.  They issue
      new certs to the peons operating the SMTP server, these just
      work, because the TLSA RRs are CNAMEs pointing at the centrally
      managed TLSA RRset.

      Thus there are two reasonable models, that typically match
      smaller and larger organizations respectively, and don't
      impose undue operational burdens.  These are described in
      the SMTP and ops drafts.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 17 Feb 2014 20:35:20 +0000

> each of the "DANE with foo" docs or if it would require yet another RR

For what it is worth, I think that the DANE TLSA RRset is already
too much rope.   There is no need for yet more complexity.

> Or we could give the person publishing the RR the ability to specify.

They do that by publishing the RR, in the context of an application
protocol (e.g. SMTP) where DANE TLS is opportunistic.  My vote is
strongly to let the TLSA RRset stand as-is, and allow "DANE for
foo" specifications to define appropriate semantics in the context
of "foo".  In particular "discovery" would be a "foo-specific"
feature.

> > And, to be blunt, if we think that Viktor is right about DANE
> for SMTP, shouldn't DANE for HTTP have the same MITM protection
> and operational downsides?
> 

One of the key points in the introduction to the SMTP draft (please
read at least the introduction).  Is that analogies between HTTP
and SMTP are deeply flawed.

HTTP has no STARTTLS.  HTTP has a separate URI scheme for security,
which runs on a different port.

If one were to design an opportunistic downgrade-resistant upgrade
from HTTP to HTTPS, then one might consider approaches similar in
spirit to the SMTP draft, though there would difficulties.  Lack
of STARTTLS means that any secure HTTP would need a separate port,
and thus a simple detection of TLSA RRs is not sufficient.

There would likely need to be SRV records (or something similar)
for HTTP that a client would consult to determine whether a domain
supported HTTPS and on what hosts/ports before falling back to
HTTP.  Since we're not designing HTTP here, I don't think we should
discuss this any further.  It is not really relevant, other than
an observation that direct application of the SMTP draft to HTTP
is not possible.

-- 
	Viktor.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 21 Feb 2014 09:42:06 -0500

On Fri, Feb 14, 2014 at 7:48 PM, Paul Hoffman <[email-masked]> wrote:

> One of the biggest questions that needs to be asked is not whether DANE
> can be used for opportunistic protocols, because of course it can, but
> whether DANE can be used to determine whether a server at a domain name
> "should" be speaking TLS at the time that a client tries to connect. Viktor
> makes a strong case that it does for SMTP. During the early discussions of
> TLSA, many people thought it should not.
>

I argued for making DANE a security policy protocol at the start. Now you
are wondering if what you produced works as a security policy protocol. It
can but the critical mass for adoption is almost certainly too high.

DNS resource records are cheap. DNS lookups are not cheap.

DANE has a last mile problem because you can't know if the DNSSEC record
has been stripped out by an attacker or by some local network firewall.

The way to cut the Gordian knot here is to provide an efficient way to
retrieve all the information necessary to set up a request in one lookup.
That solves the last mile problem and the multiple lookup problem at the
same time.

-- 
Website: http://hallambaker.com/

---

From: Jelte Jansen <[email-masked]>
Date: Fri, 21 Feb 2014 15:46:45 +0100

On 02/21/2014 03:42 PM, Phillip Hallam-Baker wrote:
> retrieve all the information necessary to set up a request in one
> lookup. That solves the last mile problem and the multiple lookup
> problem at the same time.
> 

Something like
http://tools.ietf.org/html/draft-wouters-edns-chain-query-00
might be of interest, in that case.

Jelte

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 21 Feb 2014 07:01:16 -0800

On Feb 21, 2014, at 6:42 AM, Phillip Hallam-Baker <[email-masked]> wrote:
> DANE has a last mile problem because you can't know if the DNSSEC record has been stripped out by an attacker or by some local network firewall.

The client can know.  It starts by asking for DNSKEY for ., etc.  Because you have NSEC/NSEC3 provable denial of existence, you can know if DNSSEC records are being stripped.

In particular, the problem for this tends to be internet cafes and the like.  Home networks tend to be atrocious on the DNS proxies, but the client can usually go around them and get things directly.  Business network firewalls may restrict client DNS, but they usually operate properly and the recursive resolver itself supports DNSSEC.

Its the net cafes, hotels, etc (basically, anything with a captive portal) which combines both a crappy DNS proxy AND DNS access restrictions that is the problem.

> The way to cut the Gordian knot here is to provide an efficient way to retrieve all the information necessary to set up a request in one lookup. That solves the last mile problem and the multiple lookup problem at the same time.

Agreed, with a minor caveat.  

The only disadvantage is that on the server side you need to get this data fairly frequently, since the timeout may be fast (first expiring RRSIG on the chain of validation from . to the DANE record), which means the very rarely updating certificate store model common to web servers isn't appropriate, but that's no real-big-deal.

--
Nicholas Weaver                  it is a tale, told by an idiot,
[email-masked]                full of sound and fury,
510-666-2903                                 .signifying nothing
PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc

---

From: Paul Wouters <[email-masked]>
Date: Fri, 21 Feb 2014 10:59:58 -0500 (EST)

> The only disadvantage is that on the server side you need to get this data fairly frequently, since the timeout may be fast (first expiring RRSIG on the chain of validation from . to the DANE recor…

huh? If I put a 9999999 rrsig timeout on my TLSA signature, once you
fetched it, it is pretty irrelevant that somewhere upstream an rrsig
expired.

Are you suggesting resolvers should throw away chains of dns from the
cache once a single rrsig expires?

Paul

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 21 Feb 2014 08:24:58 -0800

> cache once a single rrsig expires?

F-yeah.  An RRSIG's validity interval should not extend beyond the validity interval of all RRSIGs needed to validate this RRSIG.  DNSSEC does not have a revocation mechanism, but in lieu of a revocation mechanism you have the much more limited validity of RRSIGs, and if the upstream authority says your DS record expires in an hour, why should you be able to override that policy?

But even if thats not the case, an non-DNS server which provides the data on demand, namely a full validation chain, needs to treat things this way, as it would not be able to provide a valid-at-the-time RRSIG: yeah, your 9999999 RRSIG might still be valid, but the captured RRSIG for the DS from the authority server also needs to be valid when it is presented to the client.

So lets take a real world case, www.isc.org:

Record		Expires
DS org		2014-02-28-000000
DNSKEY org	2014-03-10-155510
DS isc.org	2014-03-10-155510
DNSKEY isc.org	2014-03-19-230128
A www.isc.org	2014-03-19-233241

A non-DNS server which is providing a DNSSEC validation chain for www.isc.org needs to be aware of all these expiration times: there are at least 3 (and possibly 4) separate expiration intervals, all with different phase to boot.

And I'd expect the expiration times for DNSSEC records to go down, rather than up, as people realize that online signing offers some significant advantages operationally (dynamic NSEC3 lies, quick reacting DNS load balancing, etc) and the cost of online signing may have been expensive 10 years ago but is nearly free today.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 21 Feb 2014 16:38:22 +0000

> DNS resource records are cheap. DNS lookups are not cheap.

For the record, my argument for DANE as a "TLS discovery" mechanism
is strongly SMTP-specific.  I make no claims about TLS discovery
in other contexts.

In MTA to MTA SMTP:

    - There is no signficant last-mile problem.  The vast majority of
      MTAs don't globe-trot.

    - SMTP TLS security is opportunistic and sans DANE unauthenticated.
      We're using DANE to make possible an MITM downgrade-resistant
      opportunistic upgrade from cleartext to authenticated TLS.

    - SMTP is not a real-time protocol.

    - SMTP DNS lookups are not significantly latency impacting.
      Were gmail.com, for example, a DNSSEC signed zone, adding
      DANE would change the number of pre-connection DNS lookups
      for gmail.com in Postfix from 6 to 7.  The local resolver
      caches the results ammortizing the cost over multiple
      deliveries.

      In fact gmail.com is not DNSSEC signed, and the SMTP draft
      explicitly suppresses TLSA lookups in zones where MX host
      A/AAAA records turn up "insecure" responses.  Therefore, the
      cost of TLSA lookups for gmail.com with SMTP is currently
      ZERO.

      The main cost of DANE is incurred as soon as one enables a
      DNSSEC-aware recursive resolver on the MTA, whether for DANE
      or just to fend off Kaminsky cache poisoning.  After that
      TLSA is basically free.

Whatever concerns may exist for adding DANE to HTTP, do not apply
to SMTP.  It is somewhat unfortunate that the mindset around DANE
TLSA is so HTTP-centric, since DANE is a much better fit for
protocols other than HTTP.

I plead that we not break DANE for SMTP just because it is perhaps
a questionable fit for HTTP.  If we stay focused on the problem at
hand, the issue is quickly seen to be rather minor.

-- 
	Viktor.