Subject: [TLS] TLS DNSSEC chain consensus text, please speak up...

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 15 May 2018 23:14:37 -0400

The present DNSSEC chain draft is subject to a downgrade attack
that strips the extension when the attacker is able to compromise
the WebPKI (obtain a fraudulent certificate from a WebPKI CA).
This limits the extension to just the use-cases (de novo
applications) in which DANE is the only supported authentication
mechanism.

While we want to see this document advance as expeditiously as
possible to address the needs of its first adopters, without
pausing to fully specify the downgrade protection that will
be needed to meet its stated objectives, and to that end accept
the lack of effective downgrade protection in the present draft
(which is being revised to remove the original unilateral pinning
described in Section 8), there is more than one way to "remove pinning".

We can omit all mention of expecting ongoing extension support, or
we can plan ahead and reserve a short (two octets would be enough) field
in the extension that initially must be zero and proscribes pinning
when seen.  This places no burden on servers or clients that have
no need for downgrade protection beyond respectively zeroing or
ignoring the new field.

The new field is sufficient to then retain the application scope
promised in its introduction:

                                         [...] 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].  It may not be relevant for many other
  applications.

There is no role here for bells/whistles like "testing" modes, because
there's no way to authenticate a "testing" mode, that'd be just another
downgrade vector.  If testing were to be a feature of DANE, the directive
would have to be in DNS (as a new DANE TLSA certificate usage for example)
and not in this extension.  Nor is there any need to cover sub-domains,
since the scope if explicitly not even a single logical host, but rather a
specific service port at that host.  It is not difficult to see that none
of the extra features beyond policy lifetime of the somewhat related "STS"
protocols apply here.  And this protocol is definitely nothing like HPKP.

All the downgrade protection needed for this extension is just an optional
commitment to operate servers which can for the agreed time, respond with
either TLSA records or denial of existence thereof, or proof that the
domain is no longer DNSSEC signed.  Once the software capability to proxy
whatever happens to be in DNS is there, it imposes no further constraints
on the domain's use or non-use of DNSSEC or DANE.

With the two bytes in the extension now, it becomes much easier later
to publish a document that describes their use for downgrade protection.
And such a document would not require a new extension or new library
code to support such a new extension.

I therefore appeal to the readers who've so far stayed silent on this
issue, to lend support to paving the way for a more broadly applicable
downgrade-resistant protocol, by supporting the inclusion of a two byte
field for that purpose.

The proposed text is at:

  https://github.com/letoams/dnssec-chain-extension/commit/11192cfbb723832c4b624f9118fc6d08393fa6da

-- 
	Viktor.

---

From: Melinda Shore <[email-masked]>
Date: Tue, 15 May 2018 20:08:46 -0800

We've had this discussion already, at terrific length.

To my knowledge it's still the case that nobody intends
to implement the proposed changes, and it's still the
case that should there be interest in implementing the
new functionality there's the option of a new extension.

At any rate this is starting to feel like abuse of process.

Melinda

-- 
Software longa, hardware brevis

PGP fingerprint: 4F68 2D93 2A17 96F8 20F2
                 34C0 DFB8 9172 9A76 DB8F

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 16 May 2018 00:22:41 -0400

> On May 16, 2018, at 12:08 AM, Melinda Shore <[email-masked]> wrote:
> 

I was simply following a security AD's suggestion from today's earlier
thread with the AD's authors and chairs:

> Therefore, if you want to make that change, you need to persuade the WG.

I still think that the WG has not had a chance to fully consider the
specific issue of reserving the two bytes as part of the present
remediation to remove the unwanted (by anyone of us) unilateral
client-side pinning.  The proposal is conservative, and does not
contradict the consensus to remove pinning for now.  It just leaves
the door open going forward, at negligible cost (two bytes on the
wire in bandwidth, and zero in implementation).

Therefore, based on the above advice, I am giving the WG the benefit
of the doubt.

-- 
	Viktor.

---

From: Melinda Shore <[email-masked]>
Date: Tue, 15 May 2018 21:18:36 -0800

On 5/15/18 8:22 PM, Viktor Dukhovni wrote:
> It just leaves

I would be grateful if you would have a consistent story on this.
Clearly, it's not just two bytes, or there wouldn't be a perceived
need for them.  It's two bytes plus the associated semantics and
processing algorithms.  In the event that anybody has an interest
in implementing something along these lines the offer to work on
an extension to support it still stands.

At any rate, this horse is long-since dead, and you're veering
into abuse-of-process territory.  Your proposal has been discussed
at length on the list, it's been discussed at length off the list,
and there is still no consensus to modify the extension to support
your use case.  And as a reminder, "Rough consensus is achieved
when all issues are addressed, but not necessarily accommodated."

Melinda

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 16 May 2018 01:34:01 -0400

> On May 16, 2018, at 1:18 AM, Melinda Shore <[email-masked]> wrote:
> 
> Your proposal has been discussed
> your use case.

You say that, but there are ~5 people on each side
woh've expressed an opinion on pinning one way or the other.
And the original consensus call did not even esk the question
at hand.  Rather it was whether to specify pinning or not.
Not whether to reserve space to do so later.  Subsequent
discussion has been the same echo chamber of Eric, Rirhard
and you on the one hand, and Paul, Nico and I on the other.
Perhaps at this point we might actually hear from some others.

> And as a reminder, "Rough consensus is achieved

Here I agree, but things like unaddressed downgrade attacks are
also a factor that is supposed to tilt the scales.

> an extension to support it still stands.

The story is quite consistent.  Applications that have no need
for pinning pay no cost as claimed.  Applications that need it,
can't use the present specification at all, but would be able
to at the cost of storing the pins, and requiring the extension
when pinned.  Nobody pays an extra cost they could otherwise
avoid.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 16 May 2018 12:00:57 -0400

> On May 16, 2018, at 1:34 AM, Viktor Dukhovni <[email-masked]> wrote:
> 

Melinda, I'd like to hear whether the above addresses your concern,
or whether there's a remaining issue along these lines that we've
failed to cover.  If so, it would be great to spell it out.  As
it stands, I think that the issue of additional semantics, costs,
etc. is addressed.  The only cost is the two bytes, and there is
no semantic burden in applications that don't already need pinning
to make meaningful use of the extension.

-- 
	Viktor.

---

From: Tom Ritter <[email-masked]>
Date: Wed, 16 May 2018 11:20:34 -0500

> downgrade-resistant protocol, by supporting the inclusion of a two byte

Sorry; but it's disingenuous to ask people who have stayed silent to
only speak up if they support you. I have not followed this draft due
to lack of time. I've tried to read up on the pinning issue. As I
understand it:

i) A server can send a Trust-Anchor-less cert with this extension, and
a supporting client can validate the DNSSEC chain and accept the
certificate.
ii) A server can send a chain of certs with a Trust Anchor, and since
this is how TLS on the Web works today, clients will accept the
certificate.
iii) An attacker can get a fraudulently issued certificate from a
Trust Anchor, and use that to impersonate a server who implements (i),
even though they tried to ignore the WebPKI.

To prevent the attack, Viktor and others propose allowing a server to
pin the extension for a period of time; so that clients will not
accept such an attack. They argue for allocating two bytes to specify
pinning; and say they will have a later draft that explains what they
mean.

There's a lot of emails on this topic; but I haven't seen how you
would fit the supported lifetime into a uint16. Can't be seconds (only
18 hours)... Minutes? (45 Days limit?) I would not care for anything
more complicated like some sort of double-like
reduced-precision-as-your-magnitude-increased.

I find ekr's characterization of the usage of this draft apt:

> 1. Assertive: To avoid having to engage with the WebPKI
> 2. Restrictive: To protect yourself from compromise of the WebPKI.

The objections to the uint16 solution to the concern seem to be:
a) no one's said they're going to implement that feature
b) it's more complicated for people to implement the draft
c) we can add a new extension to do pinning
d) generally pinning specifies a lot of additional fields that are not
present here (report-only mode, report-uri, includeSubDomains)
e) it's easy to brick oneself
f) it's possible for attackers to brick you
g) This draft is intended to address Use Case 1; not 2.

I am very sympathetic to the concern raised. I agree the attack is
real and considerable and it should be protected against.

I am entirely unswayed by arguments (a), (b), and (g).

Bricking (e) and (f) is a real concern. While web browsers have a
mechanism to automatically resolve bricked sites in significant
situations (it's not a pleasent one, it's a whole browser update)
non-browsers do not. Presumably forward-thinking developers would make
it realtively easy for admins to do so ('run this command' or delete
the line from this .txt file') - it still requires administrative
action and there's a long tail where that won't happen.

I am most swayed by (d). I think any pinning mechanism needs a report
only mode and a reporting mechanism. The comment

> downgrade vector.

Seems to miss the point of a testing mode: it's not for when you're
attacked; it's so you can confirm your deployment isn't messed up in
some unanticipated way. I only partially agree that a testing mode in
DANE makes sense - in the same way that a testing mode for HTTPS makes
sense. When deploying HTTPS (no HSTS, no HPKP) we rely on tools like
SSL Labs to tell us that our cipher configuration doesn't brick Java 6
and we're sending the right intermediates. A Report Mode for clients
might be able to tell us the same information. I don't fault DANE for
not doing this any more than I fault HTTPS. HSTS' failure to do was
covered up by CSP. But we should repeat the mistake because we made it
before and things eventually seemed to work out.

Painfully, there is no effort for pinning in this WG. There's
draft-sheffer-tls-pinning-ticket which looks quite clever to me; but
it looks like it was last discussed in early 2017 and no clear support
for it emerged. An argument could be made that if we're going to have
a pinning extension, it should work for all forms of key agreement in
TLS: Certificate, DNSSEC, Raw Public Key, PSK (maybe? that might not
make sense.) That argument would effectively make the work of such an
extension a few orders of magnitude as great and probably kill the
effort.

On the balance, I support adding the two bytes.

I would argue that the top-most or bottom-most bit should be used as a
testing bit (0 = Testing, 1 = Enforcement), and that the draft (or a
second draft) specifying the policy should add a generic
problem-reporting extension that allows one to post a description of
errors encountered. But these arguments do not hinge my support of two
bytes.

I have no expectation or opinion about how this should affect WG
proceedings. There was a Last Call, I don't know IETF process where
there's disagreement like this, people are arguing about what
constitutes consensus, I don't know if this email 'counts'.

-tom

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 16 May 2018 12:34:27 -0400

> On May 16, 2018, at 12:20 PM, Tom Ritter <[email-masked]> wrote:
> 

Thanks for responding, and sorry to frame the request as "please
support", I've previously tried to careful and ask people to
respond with their comments whatever they might be, and should
have done so this time too.

> errors encountered. But these arguments do not hinge my support of two

For the record, the reason that we're confident that two bytes are
enough is that DNS TTLs already take care of sub-hour continuity
for any provided TLSA records.  So units of hours are natural, and
make 16 bits quite sufficient.

We've given the need for other pinning properties from other STS-like
protocols some thought, and it turns out that none apply.  IN particular
a testing mode is not possible with this extension.  Such a testing mode
would itself be a downgrade attack.  Any testing mode for DANE would
have to be specified as a new element type for the TLSA RRset to be
authenticated via DNSSEC, not as a WebPKI-authenticated element of this
extension.

The extension is a channel to deliver security-relevant data
from DNS, and the pin when specified, would just pin support
to continue to provide the channel.  The STS-analogy is the
closest available but it is not a faithful one, the requirements
here are much simpler.

-- 
	Viktor.

---

From: Christian Huitema <[email-masked]>
Date: Wed, 16 May 2018 18:59:33 +0100

> make 16 bits quite sufficient.

The way I understand it, your proposal is not so much to "reserve 16
bits" but rather to "include a 16 bit field defined as the pinning time
in hours". Or maybe, "reserve 16 bits as set to zero on send and ignored
on receive" in the current TLS DNSSEC draft, let it be published as RFC,
and publish very soon a draft that defines the 16 bit field as the
pinning time in hours, and presumably explains how to avoid the usual
pitfalls of pinning. Do I understand correctly?

-- Christian Huitema

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 16 May 2018 14:14:03 -0400

> On May 16, 2018, at 1:59 PM, Christian Huitema <[email-masked]> wrote:
> 

Yes, with the slightly more precise semantics you mention of
"set to zero on send and ignored on receive" and zero means "do
not pin".  This is we expect better then just reserving an undefined
field.

-- 
	Viktor.

---

From: Christian Huitema <[email-masked]>
Date: Wed, 16 May 2018 11:38:00 -0700

> not pin".  This is we expect better then just reserving an undefined

Did you publish the proposed pinning draft already? That would certainly
help clarifying the issue.

-- Christian Huitema

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 16 May 2018 15:04:58 -0400

> On May 16, 2018, at 2:38 PM, Christian Huitema <[email-masked]> wrote:
> 

Only the proposed text defining the interim 16-bit field.  The follow-on
specification has not yet been written.  It has not to date been clear
that this would be helpful.  A downgrade-protection extension could be
written now, but it'd a rather different document if the two bytes are not
present in this extension, so we're been waiting for the dust to settle.

Is there sufficient interest in seeing such a write-up at this time?

If that's what we're really doing, we could just bite the bullet and
produce the final document now, with the downgrade protection built-in,
revisiting the previous consensus around deferring that work.  So I'm
reluctant to bring the details of the follow-on work into this discussion,
if that's not what we're doing.

-- 
	Viktor.

---

From: Melinda Shore <[email-masked]>
Date: Wed, 16 May 2018 13:43:50 -0800

We really need to get this published, and in the interest of
making progress I will not block the addition of two bytes
to the extension.  I am highly reassured by Viktor's suggestion
that they will never be used, as unused fields with murky
semantics have never been shown to be a problem in IETF
protocols.  (<- I don't actually believe that, but hey).
I disagree with adding these bytes but I can learn to live
with it.

Something that actually is a concern is that we now have
a working demonstration that refusal to compromise is an
effective strategy and that DOSing a document is a good
option if you can't otherwise convince other working group
participants.  This, however, is a problem for the chairs
and the IESG.

So, onward.

Melinda