Subject: [TLS] Interim notes and draft-ietf-tls-dnssec-chain-extension next steps

From: Christopher Wood <[email-masked]>
Date: Mon, 8 Oct 2018 17:09:40 -0700

Notes from the TLS interim meeting held in September are now online
[1]. To recap, the meeting attempted to focus on three primary
questions:

1. What is the fundamental security issue? What is the purpose of this
extension?
2. Under what circumstances should DNS records received in the
extension be cached and reused for future use?
3. Is pinning required? If so, what is pinned, and at what layer(s)
should it be implemented?

Most of the time was spent on question #1. In an attempt to get to the
root cause of the disagreement amongst participants, we have since
attempted to go back to a clean  slate, gaining an understanding of
the "facts on the ground" that motivate a need for this extension and
how current technologies operate, and move forward from that common
understanding to reach a shared picture of a clear problem statement.
Once a clear problem statement is agreed upon, it should be easier to
analyze proposed solution(s) for whether they solve that problem
statement without introducing unacceptable risks into the broader
ecosystem.

To that end, here are some facts for which there seems to be consensus:

1. DANE provides two major use models. In the first model, it requires
that the server supply a certificate which would pass WebPKI
validation but must also have a CA certificate (usage 0) or EE
certificate (usage 1) which matches the TLSA record. In the second
model, the server may have a certificate or raw public key which need
not pass WebPKI validation, but either must chain to a certificate
which matches the TLSA record (usage 2) or must itself match the TLSA
record (usage 3). In the former model, the server operator still must
participate in the Web PKI, whereas in the latter model, it need not
do so.
2. Currently, DNSSEC failures are common in the last mile. Residential
routers and ISPs, might give out DNS resolvers that fail to deliver
(accurate) DNSSEC records. This makes delivery of DNSSEC (and TLSA)
records difficult. Thus, any client which must work in any network
environment cannot safely fail on DNSSEC failures (whether that
failure is overridable by the user or not) because that would result
in an unacceptable rate of failures. Further, clients have been
reluctant to implement even opportunistic use of DANE records because
of errors and latency concerns.
3. Certificate switching based on ClientHello contents is standard
practice, e.g., as is done for SNI-based certificate selection or for
servers which support multiple algorithms such as RSA and ECDSA. This
may also be used to monitor the deployment rate of this extension.

At risk of discussing a solution to the wrong (or a different)
problem, we should first settle the question about the purpose of this
draft. Once we settle on the problem(s) and determine if the proposal
adequately addresses it, we can then discuss technical details. In the
interest of moving things forward before Bangkok, we plan to timebox
these discussions as follows:

- October 8 through October 19: Discuss the problem statement. In
particular, if anyone feels the problem statement captured in the
draft introduction [2,3] or in the above "facts" is incorrect,
imprecise, or misleading, please say so, and say why (in a succinct
fashion). Questions regarding client pinning of the TLS extension, the
risks involved in doing so, and how server operators can recover from
pin DoS attacks are out of scope for this discussion.
- October 22 through November 2: Discuss the draft [2,3]. The chairs
will circulate a list of concrete questions to address before the
22nd.
- Bangkok: Discuss the draft [2,3] and open issues.
- After Bangkok: Call for consensus to continue iterating on the draft
as a WG item or abandon it, and proceed accordingly.

Best,
Chris, Joe, and Sean

[1] https://datatracker.ietf.org/doc/minutes-interim-2018-tls-01-201809141000/
[2] https://tools.ietf.org/html/draft-ietf-tls-dnssec-chain-extension-07
[3] https://github.com/vdukhovni/dnssec-chain-extension/tree/for-interim

---

From: Tom Ritter <[email-masked]>
Date: Tue, 9 Oct 2018 15:53:48 +0000

I was not at the interim, so this email comes without context of that
discussion. Apologies if this was exactly what the chairs didn't
want...

On Tue, 9 Oct 2018 at 00:10, Christopher Wood
<[email-masked]> wrote:
> fashion).

I agree with the facts presented in the email. I find the problem
statement in Section 2 of
https://tools.ietf.org/html/draft-ietf-tls-dnssec-chain-extension-07
to be imprecise.

Whether or not something is imprecise is often only discoverable in
hindsight, given disagreements about it. That seems to be the case
here.

Specifically, it does not state if the intent of the draft is to
enable a *server* to limit authentication of itself to this mechanism.
It only talks about enabling a client to authenticate the server.
Basically the draft doesn't say if it's supposed to specify a pinning
mechanism or not. Since it omits it, my assumption would be that it
_would_ not and _should_ not specify a pinning mechanism. (If it did
specify a pinning mechanism, then the draft is solving a problem not
explained in the introduction.)

-tom

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 9 Oct 2018 15:18:38 -0400

> On Oct 8, 2018, at 8:09 PM, Christopher Wood <[email-masked]> wrote:
> 

1. Some applications that would take advantage of DANE cannot do
   so because they can't use DNSSEC directly.  Either because of
   last-mile problems or perhaps out of latency considerations
   (though often the lookups can be made in parallel).

2. The stated purpose of the draft, per its introduction, is to
   enable such applications to obtain the requisite DNSSEC records
   in-band from the TLS server, thereby avoid both problems in (1).
   As noted by Richard Barnes, this even also resolves potential
   UKS attacks in some protocols, that inherent in DANE without
   certificate name checks, as with raw public keys, or the advice
   of RFC7671 Section 5.1

   https://tools.ietf.org/html/draft-ietf-tls-dnssec-chain-extension-07#section-2

<quote>
   This draft describes a new TLS [RFC5246] [TLS13] extension for
   transport of a DNS record set serialized with the DNSSEC signatures
   [RFC4034] needed to authenticate that record set.  The intent of this
   proposal is to allow TLS clients to perform DANE Authentication
   [RFC6698] [RFC7671] of a TLS server without performing additional DNS
   record lookups and incurring the associated latency penalty.  It also
   provides the ability to avoid potential problems with TLS clients
   being unable to look up DANE records because of an interfering or
   broken middlebox on the path between the client and a DNS server
   [HAMPERING].  And lastly, it allows a TLS client to validate the
   server's DANE (TLSA) records itself without needing access to a
   validating DNS resolver to which it has a secure connection.

   This mechanism is useful for TLS applications that need to address
   the problems described above, typically web browsers or SIP/VoIP
   [RFC3261] and XMPP [RFC7590]. [...]
</quote>

3. The draft's intended scope is not and should not limited to
   *just* "green field" applications such as DPRIVE, where use of
   the extension might be always mandatory, or otherwise based on
   static local policy for designated peers.

4. Without static client policy, existing applications (e.g. web
   browsers), can't know a-prior which servers are expected to
   support the extension and which are not.

5. Absent such knowledge, they're vulnerable to stripping of the
   extension on first contact, by an attacker able to provide valid
   WebPKI credentials (unchanged status quo ante for majority of
   servers).

6. Let's Encrypt certificates are both cost and hassle free.  For
   a an existing application service (not "green field") there's
   no substantive disincentive to having a WebPKI certificate that
   ensures interoperability with a majority clients that will at
   least initially, and perhaps indefinitely, support only WebPKI.

7. If the WebPKI were sufficiently secure to preclude any concerns
   about (5), then there'd be no need to bother with DANE.  Nobody
   would ever use a BGP MiTM attack to demonstrate domain control
   (run a server on port 80, respond to an intercepted email to
   "admin@", forge unsigned DNS replies, ...).

8. If on the other hand, back in the real world, one has legitimate
   concerns about the security of DV certificate issuance (knowing
   that compromise of the DNS registrar account used to manage
   DNSSEC records also necessarily compromises ACME), then one might
   actually want one's DANE TLSA records to securely restrict the
   acceptable certificate chains to match the these records in a
   manner that is not trivially downgraded to the ability to obtain
   a WebPKI certificate.

9. Not only is the extension subject to stripping by an adversary
   that subverts DV certificate issuance, thereby eliminating all
   of its benefits when not enforced by client policy (a-priori
   static pinning), it still carries costs in the form of needing
   to keep any TLSA records correct or else risk failure when clients
   that support the extension see non-matching certificates.

The above is discussed in Ben Kaduk's proposed additions to the
security considerations back on Jun 1.

a. There are other gaps in the document.

	i. Failure to explain that when the server caches DNS data
	   for multiple responses, it must decrement TTLs when
	   transmitting "aged" data to clients.

	ii. Failure to adequately explain interactions with virtual
	    hosting

	iii. Failure to mandate SNI, or to convey the server port
	     in the client extension to deal with DNAT.

	iv.  Pointless ordering constraints on the DNS RRsets, that
	     don't work well when CNAME and DNAME records are involved.

So before we discuss remedies, I'd like to hear whether there's
substantive disagreement with the above statement of the problem.
A discussion of remedies if we don't yet agree on the problem at
hand would likely lead to much miscommunication.

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Wed, 10 Oct 2018 13:54:15 -0500

> 1. What is the fundamental security issue? What is the purpose of this

Broad utility vs. narrow utility.  As specified the extension is only of
use to clients that can mandate it and hard-fail when it is not
supported.

We are asking for Motherhood and Apple Pie.

Who could disagree?!  And yet many do.  There is a reason for that.

>From the concall and off-list exchanges I believe that the disagreement
with Motherhood and Apple Pie stems from a belief that we can't get them
at an acceptable price.  People have been traumatized by the HPKP
experience and want nothing like it -- and *this* sure is something I
believe we *all* agree on at this time.

Therefore I propose that we put the cart before the horse.

I propose that we start by showing that the proposed Motherhood and
Apple Pie feature is indeed cheap and risk-free, and not HPKP redux.

If we can examine that statement, that the proposal is cheap and
risk-free, and if we can come to agreement on that, then agreement that
we should aim for broad utility will surely follow.

Otherwise, and if no one else has an alternative cheap-and-risk-free
Motherhood and Apple Pie proposal, then we can safely reject broad
utility.

   HPKP is a *footgun*.

Any attempt to add new footguns like HPKP must be rejected.

> extension be cached and reused for future use?

The payload contents are DNS responses.  They may be cached, or not, as
usual.  The choice of transport does not affect this.

> should it be implemented?

If clients keep no state at all (about the DANE extension) between TLS
handshakes, then the extension can be stripped off (or the client
redirected to a server that won't provide it).  This is the source of
the observation about broad vs. narrow utility.

Now, we cannot, indeed MUST NOT, pin anything that would make this like
HPKP.  Otherwise we'd have a footgun for sure!

That means:

 - MUST NOT pin *any facts* about how the server is to be authenticated!

   Meaning:

    - MUST NOT pin public key material  (private keys get lost, rotated)
    - MUST NOT pin EE certs             (same reason)
    - MUST NOT pin TLSA RRset RDATAs    (same reason)
    - MUST NOT pin intermediate certs   (operator might need to switch CAs)
    - MUST NOT pin trust anchors        (same answer)
    - MUST NOT pin TLSA RRset existence (zone might stop being signed)
    - MUST NOT pin whether the server's RRsets are signed (same)

    - MUST NOT pin any other authentication facts not listed above

That's a pretty extreme list of must-not-pin items.

ALSO: whatever state is kept -whatever is pinned-, the pin must be
      trivial for server operators to clear.

There is only one thing that's left to could get pinned: whether the
server supports the extension, with an expiration time on the pin.

We need to demonstrate that pinning server support for the extension
does not a footgun make.  That's on us.

The test for whether we have a footgun is: can the server operator clear
the client pins trivially in the event of a screwup?  If the server
operator can clear the pins trivially, then we have no footgun.

Well, we have 1 way to set the pin, and 3 ways to clear it.  There must
be methods for clearing the pin that are no more difficult to execute
than setting the pin.

To set the pin:
 - the client MUST have requested the extension
 - the server MUST respond with the extension
 - the server MUST have TLSA RRs and a valid DNSSEC chain
 - the client MUST have authenticated the server per-DANE using the
   attached chain
 - the server MUST have advertised a non-zero pin time

To clear the pin:

 - method #1: Same as setting the pin, server advertises a zero pin time.

 - method #2: Unpublish TLSA RRs or unsign the zone, therefore the
              server MUST send an authenticated denial of existence
              (DoE) back to the client.

              The client then MUST clear the pin after authenticating
              the DoE regardless of whether it successfully
              authenticates the server.

              (Recall that the fact of a zone's not being signed can
              itself be proved in DNSSEC, thus, no longer signing the
              zone leads to authenticated denial of existence.)

 - method #3: Same as method #2, but the client can independently check
              DNS if the server somehow does not support the extension.

              This only works for clients that can reach the DNS, but
              that would be e.g., most browsers, most of the time.  That
              is, this works for clients for which this extension
              functions as an optimization.

              Clients that cannot reach the DNS directly were likely
              ones like DPRIV that want to hard-fail on server
              non-support for the extension anyways.

Because there is a method for clearing the pin involving only local
configuration (#1) no different from setting the pin, and because there
is a method for clearing the pin involving only DNS change control (#2
and #3), including one (#3) where the server need not even support the
extension that it needed to set the pin in the first place...

...there is clearly no footgun: the server operator can clear the pin at
will with less -and in no case more- effort than it took to get the pin
set in the first place.

Now, to be fair there was also discussion of a denial of service attack.

In the DoS attack an attacker who thoroughly compromises the server can
install the extension, set the pin, then uninstall the extension and
watch the server operator suffer.  This also applies to HPKP, and it
never happened, but the HPKP footgun was fired, so the DoS threat in not
realistic just based on experience.  But also, the DoS requires such a
thorough compromise of the server as to make the DoS concern the
operator's least concern.

But suppose the DoS threat weighs heavily on everyone's mind!  Clearly,
if server support for the extension is universal, then the DoS threat
vanishes.

Therefore we offer a mitigation for the DoS case: slow ramped client-
side scaling of advertised pin times.  That is, initially the maximum
advertised pin time could be just hours, and it could stay that way for
N years, then quickly ramp up to a maximum in the range of a few years.
That is, we can make pinning something that comes into force only enough
time into the future that anyone suffering from a DoS before then need
only wait a short amount of time, and anyone suffering from a DoS after
then need only enable a by-then-universally-supported extension.

Surely client-side pin scaling based on time since the extension's
publication as RFC is enough to dismiss the DoS concern entirely.

Thus we have neither footgun nor DoS concerns.

Yes, we can haz Motherhood and Apple Pie.

Q.E.D.

Nico
--

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 16 Oct 2018 18:16:22 -0400

Hi all--

I'm disappointed in how long this WG is taking to get
draft-ietf-tls-dnssec-chain-extension out the door.

I agree with both Tom and Viktor that the current draft seems to be
misaligned between the goals and the stated scope.

I wanted the draft to be done by now because i think it will be useful
in "greenfield" scenarios -- ones where the use case itself can mandate
the extension without negotiation, but i understand Viktor's point that
without any sort of negotiated pinning mechanism, the draft is probably
not useful for non-greenfield scenarios (without pinning the existence
of the extension, it cannot reduce the attack surface represented by the
CAs, and instead only represents an additional vector of attack).

I can understand why people want to be able to make this useful for
non-greenfield scenarios, but it appears that we're hung up on the
pinning details.  I actually don't think that extension pinning needs to
be particularly hard, and i don't think it's as dangerous as HPKP's
pinning, but i won't go too far into the weeds here.  Just a quick
summary of my understanding:

 * The existence of a pin only requires that the service operator
   maintain the ability to respond to this extension in the future -- it
   doesn't require specific keys, or even the use of DANE itself.  It is
   not nearly as large a risk as HPKP's pins were.

 * Pinning fears are based on two scenarios: (a) footgun, where the
   service operator makes a mistake, or (b) a malicious pin is set by an
   adversary who has owned your domain.  (a) is overwhelmingly more
   common, and is what we should focus on.  In the (a) scenario, the
   admin has already deployed the extension, so there is no risk.  The
   (b) scenario only matters if a service cannot deploy the extension as
   intended, which is more of a chicken/egg problem of deployment and
   implementation.  I don't think that's a huge risk but if we really
   want to try to cover it, i think there are ways that we could
   minimize it as well.

That said, it sounds like negotiating the details of how to do this
pinning is the main blocker, and i'm sick of this proposal being blocked
(because i want it for "greenfield" implementations last year).

So one way forward would be to complete this extension without the
pinning (explicitly acknowledging that it will not be useful for
non-greenfield implementations on its own) and get it out the door.
Then we can subsequently create a new extension that is only a
"how-to-pin-dnssec-chain-extension".

This is an approach that would expose at the protocol layer the ugly
truth about how hard it is to get something through the IETF process,
but if it helps to break the impasse, i'd be all for it.  I'm willing to
provide text for why this is only useful for greenfield implementations,
if asked.

Alternately, if people could agree on a simple and clear pinning scheme
that we could get out the door all in one piece, i'd be happy with that
too.

I will be sad if we manage to not get anything at all completed for
another year.

   --dkg, tired of waiting

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 16 Oct 2018 19:29:19 -0400

> On Oct 16, 2018, at 6:16 PM, Daniel Kahn Gillmor <[email-masked]> wrote:
> 
> Just a quick summary of my understanding:
> 

Thanks, that summary looks quite accurate.

> (because i want it for "greenfield" implementations last year).

To be fair, the present delays date back to just March/April.  Until
that time the draft was blocking waiting for TLS 1.3 to be finished
first.  So it has only been a few months.

> "how-to-pin-dnssec-chain-extension".

At this point, I think that would be a mistake. The draft still needs
much work.  Though pinning has been a blocker, it has many other smaller
defects that have to be addressed, now that it is back for revision.

The draft fails to specify correct semantics for SNI, and leaves out
the port number from the client extension, but it is needed.

The draft fails to explain the server's responsibility to decrement
RRset TTLs if the server is providing previous cached data.

The draft fails to describe how virtual hosting should be handled.
The RRset ordering is unnecessary, and complicates the exposition.

Bottom line, there isn't a document that can (or at least should)
land back in the IESG queue with minimal changes.  It needs a bunch
of changes, and so we should really also resolve the pinning issue,
it is NOT that difficult.  It has been a series of misperceptions
all along.

> that we could get out the door all in one piece, i'd be happy with that

The proposed extension lifetime field is all it takes, there is no
feasibility or need for a testing mode (because there's no way to
authenticate such a mode, or else we again lose downgrade protection,
and the analogy with HTTP STS is imperfect, and does not carry over).

There's also no need for "reporting URIs", failure signaling is
much better done in-band, via a suitable TLS alert.

All that's left to iron out is the maximum duration for the pin
lifetime, and whether we need to gradually scale it up as a function
of RFC lifetime, giving sites more protection from hijack DoS (if
that's really considered important enough to complicate the design).

-- 
	Viktor.

---

From: "John Levine" <[email-masked]>
Date: 16 Oct 2018 21:07:19 -0400

Hi from DNS land.

>   want to try to cover it, i think there are ways that we could

Something like "require DANE certs until time N" should be plenty.

Remember that you can also unpin by publishing a signed NXDOMAIN or
NODATA.  Since you need to have DNSSEC working to get the pin in the
first place, that doesn't seem unduly onerous.

If your system goes totally kerflooie and your DNS was signed
yesterday and for some reason you can't sign it today, you have a
problem, but that doesn't sound like a very likely problem.  It it
does happen, it's as likely as not an attack in which case you'd want
attempts to unpin to fail.

R's,
John

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 16 Oct 2018 20:15:15 -0500

> misaligned between the goals and the stated scope.

I also agree that there is some misalignment of this nature.

My attempt at a root cause analysis would be that the current text in
the Introduction is essentially saying "let clients in bad networks do
DANE", but "doing DANE" is a fairly nebulous thing, and if different
people are focusing on "doing DANE" in different ways, we can get into
conflict about whether a specific proposed mechanism advances our
particular goals.

So what is "doing DANE", then?  In the course of the on-list, off-list,
side meeting and interim discussions, I've benefited greatly from
hearing from a lot of experts, and I deeply appreciate the patience and
persistence that the participants thereof have shown in working to
advance a document in this space.  It was not always easy, but I think
we are making progress.

In the context of this discussion, I propose that DANE is a way to allow
a TLS server operator[1] to indicate to a TLS client information about
how the server would like to be authenticated.  The practical effect of
this new source of information depends on what the client would be doing
*without* the DANE information, though, since we have this large
deployed base that is currently not doing DANE but could do DANE in the
future.  If we want to analyze the (security and other) properties of
adding DANE, we must consider both the starting point and the end state.

I suggest that if we limit the stated scope from an open-ended "doing
DANE" to also state which cases of "doing DANE" we have analyzed
(leaving open the possibility for future analysis to confirm the
mechanisms we define as usable in other cases), then we can get a clear
answer on whether the proposed mechanism meets the requirements of each
listed case, without introducing negative externalities for either the
protocol participants or the Internet as a whole.  This is not to
exclude the "greenfield" case, of course -- a list of cases to consider
might include things like:

- client does not currently exist, and insists on receiving DANE records
  via TLS extension; server wants to use TLSA with PKIX-{TA,EE}

- client does not currently exist, and insists on receiving DANE records
  via TLS extension; server wants to use TLSA with DANE-{TA,EE}

- client currently accepts "Web PKI" certificates but is willing to do
  DANE; server wants to use TLSA with PKIX-{TA,EE}

- client currently accepts "Web PKI" certificates but is willing to do
  DANE; server wants to use TLSA with DANE-{TA,EE}

- client currently will opportunistically accept any certificate but is
  willing to apply DANE restrictions; server wants to use TLSA with
  DANE-{TA,EE}

- client currently will opportunistically accept any certificate but is
  willing to apply DANE restrictions; server wants to use TLSA with
  PKIX-{TA,EE}

where I separate out the DANE- and PKIX- usage values since they may
require a separate security analysis.  (If they don't; great, we can
consolidate them in the document.)

I don't think we would necessarily need to come to consensus on which of
these cases are "most important", so long as we can provide a mechanism
that will satisfy the requirements of all cases that we want to list in
the document.

> CAs, and instead only represents an additional vector of attack).

Right -- if the client is currently willing to do Web PKI (or worse), an
attacker that can get a bogus Web PKI (or self-signed) certificate could
keep the client ignorant of the true server's preference and get the
client to errenously complete a handshake.  We would like a way to
deprive the attacker of such a capability, though in at least some
situations we cannot do so with 100% reliability.  We could perhaps have
a success criteria for this TLS extension (as a security mechanism),
that it both:

(1) provides a channel for DANE records that is reliable in the absence of
    an attack

and

(2) reduces the ability of an attacker to cause the client to ignore the
    server's authentication preference

I think that just meeting the above two conditions could provide enough
value to merit publishing, even without attempting to add something
like:

(3) allows the client to realistically hard-fail connections where DNSSEC
    validation returns bogus or indeterminate.

Getting (1) is probably trivial (though with middleboxes you never
know), and it seems fairly clear that a pinning scheme can provide (2).
(3) is more subjective and may be hard for us to make any definitive
statements about, hence my proposal to exclude it for now.

-Ben

[1] I feel comfortable consolidating the TLS server operator with the
maintainer of the DNS entr(y|ies) for that server, since the TLSA entries
must reflect the operational reality of the TLS server, and if the two
entities are in conflict either can trivially cause an outage.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 16 Oct 2018 21:24:04 -0400

> On Oct 16, 2018, at 9:07 PM, John Levine <[email-masked]> wrote:
> 

To be clear the "require DANE certs" above only holds so long as the
TLSA records remain published.  Since providing proof of non-existence
clears the pin, what's really pinned is the extension (and even then,
many clients will be able to recover by making independent DNS lookups).

So there's no discord here between "require DANE certs" and "just
pin the extension", the two are equivalent, because the former
really means "require the extension and if signed TLSA records are
present require DANE, else, with valid denial of existence, clear
the pin".

So regardless of how we frame it, the behaviour after first contact is
the same, that is:

  * Apply DANE in a downgrade-resistant manner when published
  * Drop pins and revert to default behaviour given valid denial of
    existence.

So far, no substantive issues have been noted with the proposed pinning
approach to downgrade resistance (which bears no resemblance to HPKP).

All that remains is agreement on a maximum time limit (by setting the time
unit to max_time/2^16), and perhaps some sort of gradual scaling up of
that limit (if concerns about hijacking before the extension is widely
available in server software are deemed sufficiently compelling).

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 17 Oct 2018 01:46:20 -0400 (EDT)

> (because i want it for "greenfield" implementations last year).

Imagine how sick I will be when I try to do this later in a separate
docment, where the WG might not even accept it as a WG item. I am not
confident enough that pinning would be resolved in a later document at
all, leaving me with my use case dead in the water forever.

So for me it is useful to have the pressure of release for those people
who have a greenfield application to want this to happen to push for
resolving the downgrade attack. It forces the parties to the table to
resolve the conflict. But also, we already had a suggestion on how
to postpone the pinning solution to another document, but to do that
sanely this document needed some placeholder or else you end up with
a pinning extension that pins itself _and_ another extension, or a
placeholder for the meaning of a pin, and both situations were deemed
worse then just working out everything in one document. So in effect
we already tried what you are proposing.

Finally, as Viktor said, our discussions offlist an onlist, found
other issues. While Viktor and I are happy to write text to fix these
other issues in the document, it seems we are currently stuck in a
role of spending a lot of effort writing text, only to see no new
draft version on even the things everyone agrees on, such as denial
of existence. Since Viktor and I put in a lot of effort to write text
that isn't being accepted or rejected, we don't feel very motivated
to fix all these other things we found.

In my opinion, this document needs more active authors proposing and
writing text. It seems none of the original authors is willing or
able to do this anymore. If nothing has changed at the next IETF, I
have planned to propose adding one or two new authors to the document
to try and get it unstuck.

I also want to note that Ben has done a very admirable job of talking
to everyone and moving towards consensus.

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 17 Oct 2018 02:38:54 -0400

> all, leaving me with my use case dead in the water forever.

Agreed, but at the same time in DKG's response, beyond the frustration
with the process, I see real signs of potential progress in the
form of broad agreement with the points we'ev made about the need
for and the nature of the proposed pinning approach.

So frankly, barring strong evidence to the contrary, I think we're
finally seeing an emerging consensus in support of the proposed
approach, be it so long as the deadlock is ultimately resolved.

Well, if rough consensus emerges for a non-deadlocked pinning design,
with no substantive unaddressed objections, then the deadlock goes
away, and we get to move forward to writing the consensus text,
with a bit of the usual bikeshedding, and will soon be done.

-- 
	Viktor.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 17 Oct 2018 06:18:27 -0700

I'm responding to Ben here, because I think it's worth adding some clarity.
However, I want to flag that I'm going to be rather short on time for the
next
few week and not able to spend a lot of time replying to traffic on this
topic. Even more than usual, non-response to some point does not
necessarily indicate agreement.

> (1) provides a channel for DANE records that is reliable in the absence of

I think this alone would be worthwhile -- and is the purpose I have always
had
in mind for the draft.

>     validation returns bogus or indeterminate.

I'm not sure I see a meaningful difference between (2) and (3), given
that the mechanism for (2) is likely (3).

> know), and it seems fairly clear that a pinning scheme can provide (2).

Yes, the question is whether such a scheme is worth the other costs that
it imposes (in particular, hostile pinning, and in the version that people
have currently proposed, the ability to break yourself by inconsistent
deployments, though that's at least conceivable fixable). In case it's
not clear, I don't agree with Viktor's "no substantial issues have been
raised" claim.

-Ekr

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 17 Oct 2018 09:40:25 -0500

> I think this alone would be worthwhile -- and is the purpose I have always

It's interesting to hear that, as I seem to recall a lot of discussion
about how a security mechanism that folds in the presence of an attack
... isn't really a security mechanism.

So while I could concoct a few scenarios in which just (1) would be
*useful*, the main one that comes to mind isn't really a security
mechanism, but would rather be part of a reporting mechanism for seeing
what kind of DANE penetration is possible.  Well, and I guess any case
where the client has some other reason to expect to see this extension
and choke if it's absent, such as a "greenfield" case or
application-level pinning.  So I'm curious what kind of use case(s) you had
in mind for just the transport aspect.

> that the mechanism for (2) is likely (3).

Mostly I'm just claiming that the "realistically" in (3) is weasel-words
that we don't need to get involved with at the protocol level.  Whether
or not to hard-fail is an application decision that we don't need to
mandate.

> not clear, I don't agree with Viktor's "no substantial issues have been

Seeing as you are busy the next few weeks, perhaps I can ask the chairs
to go through the email history and summarize these substantial issues
that have been raised -- I am not confident that I could reproduce them
from memory, myself.

-Ben

---

From: Sean Turner <[email-masked]>
Date: Wed, 17 Oct 2018 11:10:50 -0400

> On Oct 17, 2018, at 10:40, Benjamin Kaduk <[email-masked]> wrote:
> 

We will do that and more.  It will not be done tomorrow though.

spt

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 17 Oct 2018 11:24:49 -0400

> On Oct 17, 2018, at 9:18 AM, Eric Rescorla <[email-masked]> wrote:

> I think this alone would be worthwhile -- and is the purpose I have always had
> in mind for the draft.

Well, a security mechanism that "works in the absence of attack" looks
rather pointless to me.  Cleartext transmission with no authentication
also works in the absence of attack, and yet does not a security mechanism
make.  The -07 draft covers only the use-cases where the extension is
mandatory (pin interval of "from now and forever"), all the other use-cases
fail.

> I don't agree with Viktor's "no substantial issues have been
> raised" claim.

Then, please raise them!  Just saying "hostile pinning, QED" is
not a substantial issue.  We've argued in detail that:

1.  This was never the real problem with e.g. HPKP, and the credible
    concern is footgun, not "hostile pinning".  We've shown that footgun
    is not a substantive problem here.

2.  We've also argued that even with "hostile pinning" the domain owner
    recovers if he is able to deploy the extension (unlike never known
    keys with HPKP).  And clients that can do real DNSSEC lookups can
    always pay the extra latency, and if necessary do DNS over TLS to
    1.1.1.1, et. al. to get around last-mile barriers, and thus clear
    any unauthorized pins even prior to server-side extension support.
    
3.  And, frankly, I find hostile pinning not a credible threat, and to
    the extent that it yields client-visible side-effects of major prior
    compromise, I see any resulting tamper-evidence as a feature, not a
    bug.
    
4.  Lastly, if nevertheless the "hostile pinning" concern is what makes
    or breaks consensus on this draft, then we're OK with introducing
    exponential scaling-up (over time) of max pin TTL, which will keep
    it reasonably low until the last few years of the scaling horizon.

From where I stand, mere repetition of "hostile pinning QED" frankly no
longer counts as a responsive objection. :-(

Likewise, mere repetition of a claimed benefit from downgradable DANE
signalling, without explaining why or how this is useful, is also not
a substantive argument to support a claim that the use-cases are served
without downgrade protection.  Which additional attacks does such
signalling militate, beyond those already handled by WebPKI?  There
would need to be a use-case where:

	* The extension is not mandatory.
        * Just WebPKI alone does not protect the server.
        * WebPKI + downgradable DANE signal protects the server.

I've not seen any such use-case.

-- 
	Viktor.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 17 Oct 2018 14:48:47 -0700

> in mind for just the transport aspect.

Given that you just described at least two use cases, I feel like you've
answered
your own question here.

-Ekr

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 18 Oct 2018 15:12:58 -0500

> Given that you just described at least two use cases, I feel like you've

Hardly.  In particular, I was asking what *you* had in mind -- my
listing was intended to be more of a "straw man" sort of thing.

-Ben