Subject: More haste, less speed.

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 6 Mar 2017 11:27:27 -0500

Specifications are moving through IETF faster than ever. Rarely is the
question asked, is this actually a good thing.

The specific reason for raising this topic is a complaint on the DNSops
list about large public resolvers failing to support DPRIV. But that is not
the only example of what I see as an anti-pattern for standards development.

1) A group identifies a security need

2) Asserting that the need is urgent and the very most important thing is
speed, a draft is cobbled together that meets the functional requirements
the group has identified.

3) Deployment stakeholders point out the practical problems they would face
implementing the draft in the current form.

4) The objections are brushed aside because of the urgent need for speed.

5) A couple of years later the draft is published as an RFC

6) A couple of years later, it is noticed than none of the essential
stakeholders have deployed.

7) Attacks on the stakeholders' lack of interest in security, gaslighting
of the individuals who raised the blocking deployment issues.

8) Further attempts to address the issue are blocked because 'what needs to
happen' is deployment of 'the standard'

9) Those people who point out that this behavior is problematic are cast
out from the tribe.

This isn't just one isolated incident. It is now a firmly established
pattern. I have seen it happen on three separate projects in the DNS area
alone. First with DNSSEC, then with DANE and now with DPRIV. And there are
real costs.

DNSSEC was deployed in .com for almost a decade late because of the refusal
to fix the NXT record issue. As a result, we lost a critical window where
deployment would have been a lot easier than it became.

DANE conflates publication of security policy with public key validation
and distribution.

And now we have DPRIV which is built with no regard for the architectural
constraints of running the large public DNS resolvers whose adoption is
essential for success.

Every time I point out that the same group of individuals are engaging in
the same behavior that caused their last proposal to fail, I am accused of
trying to re-fight old battles and what we all need to do is to ram this
next RFC through the process as fast as we possibly can because this time
we really need to do it fast.

What concerns me here is not so much the waste of time but the fact that as
long as there is a purported standard meeting some need, its existence and
failure to achieve adopted blocks attempts to solve the problem in ways
that could be acceptable to the deployment stakeholders.

So what I propose is a mechanism to formalize the raising of deployment
objections. The basic idea being that is a group decides to behave this way
and the IESG decides to let them, the fact that their proposed solution
fails to meet what key stakeholders assert are show stopper deployment
issues is noted. If the WG then produces a specification that fails to
achieve deployment, the existence of the objections can then be taken into
account when considering chartering a new group.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 6 Mar 2017 13:11:28 -0500

> On Mar 6, 2017, at 11:27 AM, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> DANE conflates publication of security policy with public key validation and distribution.

Well, by far the main obstacle to DANE deployment is not this, but comparatively low
(~0.6%) DNSSEC adoption.  Of approximately 1.5 million domains with DNSSEC for both
the domain and one of the primary MX hosts, 110 thousand (and steadily growing) have
DANE TLSA records (7% of those who can deploy, given DNSSEC constraints, have deployed).

The conflation of security policy and key distribution is a late addition to DANE in
RFC 7672.  The base specification in RFC 6698 is rather policy neutral.  So perhaps
tying the two together is in good part my fault.  And yet, despite that, there is
considerably more deployment of RFC 7672 (in SMTP) than of RFC 6698 (in HTTP, which
was its unstated primary focus).

If you feel strongly that publishing TLSA records should not imply security policy,
it is not too late to introduce a new policy specification protocol (that would
still require DNSSEC) to decouple existence of DANE TLSA records from the desired
security policy.  We could then retrofit MTAs to use the policy records when
present.  This would then require two DNS lookups where one suffices, but might
provide useful flexibility.

Do you have use-cases in which publication of DANE-EE(3) or DANE-TA(2) TLSA
records should not imply a request that sending domains use said records?

My impression is that the adoption obstacle remains operational difficulties
around DNSSEC and not missing policy hooks.

-- 
	Viktor.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 6 Mar 2017 15:12:15 -0500

> around DNSSEC and not missing policy hooks.

​Again, you are mistaken.​

​Security Policy can benefit from DNSSEC but it absolutely does not require
DNSSEC to provide value. Since the current Internet security policy is to
require no security, any policy publication mechanism adds value over the
baseline.

The reason DANE cannot progress is precisely that it is tied to DNSSEC in
such a way that instead of DANE getting itself widely deployed and becoming
a ​reason to deploy DNSSEC infrastructure, it is instead dependent on prior
deployment of DNSSEC so that it cannot succeed until after DNSSEC has been
deployed.

These arguments are not new, they have been rehearsed repeatedly and are
one of the main reasons for not tying policy to key validation. The other
being that the DNS registrars critical to deployment of DNSSEC sell DNS at
a loss and make their profit on the item DANE tries to make free of charge.
Its called a channel conflict and yes, they are show stoppers.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 6 Mar 2017 16:30:30 -0500

> On Mar 6, 2017, at 3:12 PM, Phillip Hallam-Baker <[email-masked]> wrote:
> 

I think you meant to say, that you disagree, at least in general, but that your
experience in the SMTP space is more limited, so I might be right in the SMTP case.

> ​Security Policy can benefit from DNSSEC but it absolutely does not require DNSSEC
> to provide value.

This is not true for SMTP, which is vulnerable to downgrade attacks if the security
policy is not made tamper-resistant.

> Since the current Internet security policy is to require no security, any policy
> publication mechanism adds value over the baseline.

Yes, against passive attacks, but STARTTLS is already sufficient for that.

-- 
	Viktor.

---

From: "Gary E. Miller" <[email-masked]>
Date: Mon, 6 Mar 2017 13:40:17 -0800

Yo Viktor!

On Mon, 6 Mar 2017 16:30:30 -0500
Viktor Dukhovni <[email-masked]> wrote:

> > Security Policy can benefit from DNSSEC but it absolutely does not
> > require DNSSEC to provide value.  
> 
> This is not true for SMTP, which is vulnerable to downgrade attacks
> if the security policy is not made tamper-resistant.

Please do not make the best the enemy of the merely better.  Often a
little better is good enough for now.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	[email-masked]  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can’t measure it, you can’t improve it." - Lord Kelvin

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 6 Mar 2017 17:01:11 -0500

> On Mar 6, 2017, at 4:40 PM, Gary E. Miller <[email-masked]> wrote:
> 

No need to convince me, see RFC7435.  That said, the current STARTTLS is
quite sufficient for best-effort security and is quite effective at that:

   https://www.google.com/transparencyreport/saferemail/

Roughly 84% of email to/from gmail is TLS protected, which beats the
recent milestone (IIRC reported from Mozilla HTTP telemetry) of 50%
of web traffic using TLS.

The goal of DANE TLS for SMTP is to opportunistically provide downgrade
resistance for TLS to domains that deploy DANE TLSA records for SMTP.
It is up to each domain whether to publish TLSA records for SMTP or not.
If they do, MTA-to-MTA SMTP from a DANE-enabled MTA to the destination
becomes downgrade-resistant and authenticated.

Notable early adopters in include gmx.de, web.de, posteo.de, mailbox.org,
transip.nl, domeneshop.no, comcast.net, ...

-- 
	Viktor.

---

From: Joe Touch <[email-masked]>
Date: Tue, 7 Mar 2017 11:26:06 -0800

> question asked, is this actually a good thing.

FWIW, I have been a proponent of "less is more". The forest of RFCs we
publish don't help implementers find what's important, and many often
conflict with each other (even within the BCP and standards-track).

Documents in last call should, IMO, need sufficient positive support to
move forward. Even after a WG has adopted a doc, we should still be able
to say "no" to a doc, not just "no objection".

Joe