Subject: [TLS] Precluding bilateral opt-in for downgrade protection.

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 27 Apr 2018 16:17:14 -0400

Over the past too many weeks we have struggled to arrive at a rough
consensus on downgrade  protection for the dnssec-chain extension.

Originally, and largely unnoticed by all, the specification described an
all too fragile approach that involved unilateral extension pinning by
the client. After I pointed this out, there was no controversy around
removing this, and I am not sad to see it go.

We've also reached consensus on adding denial of existence support, the
authors have started work on that, and perhaps some of the additional
text I'm proposing in that direction will be helpful.

The remaining issue is how to repair the gash in the specification
created by ripping out its original downgrade protection mechanism.
Though the original text was flawed the problem it attempted to address
does not go away just because we're not solving it yet.  Only
applications where the extension is mandatory get by as-is.

There is in front of us a proposal to reserve 16-bits at the front of
the extension, that can later be used as part of a future downgrade
protection mechanism.  The DNSSEC payload of the extension will be
multiple kilobytes, holding a signed TLSA RRset, and DNSKEY and DS
RRsets for multiple domains.  It is hard to argue that prepending 16
zero bits is a burden on anyone, unless one is opposed not only to
implementing downgrade protection for this extension in one's own
applications at present, but is in fact opposed to ever implementing
it, and indeed opposed to giving others that same option (offering
a non-zero extension support lifetime is of course optional, as is
acting on such an offer).

Any negotiated (non-unilateral) downgrade protection will have finite
duration, and will include such a field.  A principled stand against
16-bits of "wasted" payload, compared to the size of the included
DNSSEC chains, to block reaching a compromise on this draft suggests
a deeper opposition to any variant of downgrade protection one might
propose in a separate draft.

It would be helpful to know where opponents stand on negotiating
continued use of the extension in general and in the future.  We
are confused by their statements so far, and wonder if they are
not just generally in opposition to any negotiation of continued
support for the extension (in all applications), and whether that
might be driving their opposition to the 16 bits, whether consciously
or not.

-- 
	Viktor.

-- 
	Viktor.

---

From: Shumon Huque <[email-masked]>
Date: Sat, 28 Apr 2018 12:26:26 -0400

> might be driving their opposition to the 16 bits, whether consciously

Hi Viktor,

I am in support of doing the pinning in a new extension, and will
even help you write the draft if you like. I'm pretty sure we could
have easily done this in the time that has been taken up on list
endlessly and repetitively discussing this.

Clearly I can speak only for myself, but I strongly suspect others
in the WG will also support this (as long as it's in a separate
extension), so if you pursue this approach, I think you'll succeed
in adding this functionality, and will not be actively blocked by
others.

As far as I can assess, the reason you are getting resistance for
adding a pinning field in this spec is two fold:

First, there is no agreement that your reason for doing pinning,
i.e. that DANE needs downgrade resistance against PKIX attacks
is even valid. This can be clearly seen from various comments on
list and at IETF/London, such as the point made many times that
the original purpose of this draft was to add DANE as an additional
possible authentication mechanism in TLS, not to position it as a
mechanism that if available unconditionally trumps PKIX authentication.
If you look back at my back-and-forth answering IESG review comments,
you will observe that I had to add text to the draft that says TLS clients
can fail back to normal PKIX authentication if DANE fails for any reason
(i.e. a protocol behavior that is the opposite of downgrade resistance).
There are other comments like (paraphrasing) "What's the downgrade
problem? The only security downgrade issue I see is DNSSEC's use of
legacy crypto"?

Clearly, for most DANE proponents, an obvious goal for the protocol
would be to protect against PKIX attacks. In an ideal world, I share
that view also. But I also recognize the other views I just described,
and am willing to make compromises to get a foot in the door for DANE
first. There will always be opportunities to improve the protocol
later.

In fact, the legacy crypto issue will always be a huge impediment for
any DANE proponent in arguing against the Internet PKI. An argument
I've heard many times: Since most of the Internet PKI has moved to
2048-bit RSA or better, why would I degrade the security of my system
by moving to DANE, which in most cases is protected by 1024-bit RSA ZSK's
in the weakest part of the chain (some chains are even weaker)? And if so,
why should PKIX not need downgrade resistance against DANE, rather than
vice versa? For DANE proponents to make a stronger case, they need to
urgently solve this problem. I'm not sure how to do that quickly - it
probably involves getting ICANN to impose rules on TLDs prohibiting
weak keys (which would likely take years).

The second reason is that pinning really is a controversial feature.
And for this reason, putting it in the core spec will be difficult.
I won't repeat all the arguments and concerns expressed already, many
of which I share by the way. So moving this feature into a new optional
extension (both the pinning field and a description of the associated
behavior) appears to me to be the past of least resistance.

By continuing to argue your position, the most you can hope to achieve
is deadlock.

Shumon.

(Addendum: I did want to thank you for pushing on the issue of
explicitly allowing authenticated denial of existence chains in the
current draft. In environments where all TLS servers support this
extension, this allows the protocol to be bulletproof in a way that
satisfies even the security purist, so I'm glad it's in the core
spec.).

-- 
Shumon Huque

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 28 Apr 2018 13:40:25 -0400

> On Apr 28, 2018, at 12:26 PM, Shumon Huque <[email-masked]> wrote:
> 

I should note that substantial issues were discovered (and will
be addressed) during the consensus call, which ended Apr 18th,
and that there is not yet a revised version of the draft that
addresses these, so while the discussion back and forth has
been lengthy, it has gone on in parallel with process that
needed to take place and is ongoing.  So discussion of doing
more than removing the unilateral pinning that was present and
adding denial of existence which was needed has not as yet caused
any additional delay.

> in adding this functionality, and will not be actively blocked by

We may yet have to see how much support or opposition the follow-on
document will meet.  What continues to be puzzling is resistance to
adding a field that imposes negligible burden on the present spec,
and would clearly be included in the follow-on extension.  It might
well be the only thing that's in the follow-on extension, and so
provisioning space for it has a strong chance of simplifying the
burden on future implementations that would need only implement code
for just one extension structure instead of two.  Worst-case we have
two reserved bytes in the current extension.

> is even valid.

The reasons are an easy exercise in logic if one is to be able to
deploy DANE at all, incrementally in *any* existing WebPKI application
(say IMAP).  This was addressed weeks back when I explained that
without downgrade protection the deployment of this extension is all
cost and no benefit.  There was agreement on this point even from those
who opposed adding the downgrade protection.

> This can be clearly seen from various comments on
> mechanism that if available unconditionally trumps PKIX authentication..

Those comments are gut reactions that have not considered the issue with
care.  We must discount them.  This extension can only work as a mandatory
sole mechanism.  All other models fail the cost/benefit analysis.

Some may want to deny others the opportunity to use this extension in
additional contexts.  My reaction to that is that they are under no
obligation do use it themselves, and setting the field to zero opts
them out of such use.  Nothing I'm proposing mandates downgrade protection
for the extension.  I am just asking for it to be possible, on a mutual
opt-in basis between client and server.

> (i.e. a protocol behavior that is the opposite of downgrade resistance).

Clients can choose to do that whether or not the downgrade protection
is available, and servers can opt-out of downgrade protection.  What
we are talking about is whether downgrade protection is to be unavailable
even if both sides wanted it, and the application supported it.

I have no intention of forcing anyone to enable downgrade protection in
code they develop and support or systems and applications they deploy.
Their choice to leave it off.  My problem is with the IETF leaving a
gap in the specification that removes the option of downgrade protection.

> problem? The only security downgrade issue I see is DNSSEC's use of 

Folks who don't trust DNSSEC are unlikely to deploy the extension,
but if they do, will presumably want PKIX-EE(1) or PKIX-TA(0) so
that WebPKI is also employed.  These however require downgrade
protection.  Without downgrade protection you're stuck sometimes
trusting just DANE.

If one considers DANE to be too weak the solution is to make it
STRONGER not weaker!!!  To make it stronger you need downgrade
protection so that you can use PKIX-EE(1) and PKIX-TA(0) and
ignore DANE-EE(3) and DANE-TA(2) as "unusable".

> first. There will always be opportunities to improve the protocol

The other views are either largely irrelevant or self-contradictory.

  * Those with no plans to use this extension have little standing
    to dictate its content.

  * Those who plan to use it, but only in mandatory contexts have
    little standing to preclude other uses.

  * Those who would use this extension in opportunistic contexts
    (incremental deployment, when available), but oppose downgrade
    protection, have failed to consider the threat model and cost/benefit
    analysis in any detail:

    + If one considers DANE weak then it must not be used alone, and
      to be useful in combination with WebPKI it requires downgrade
      protection.

    + If one considers DANE strong than one should want to avoid downgrades
      to the weaker WebPKI.

> any DANE proponent in arguing against the Internet PKI.

In the context of this extension I am NOT arguing for or against the WebPKI,
nor for or against DANE.  I am arguing for a sensible definition of this
mechanism that is not crippled to handle just one deployment model (just
applications where it is mandatory, what are these applications where
the extension is to be mandatory?)

> An argument
> in the weakest part of the chain (some chains are even weaker)?

Then they should oppose the present draft, require downgrade protection
and limit their  applications to just PKIX-EE(1) and PKIX-TA(2).  The
present draft says:

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

   A TLS client making use of this specification, and which receives a
   DNSSEC authentication chain extension from a server, MUST use this
   information to perform DANE authentication of the server.

My pull request changes MUST to SHOULD and adds necessary caveats about
"unusable" TLSA records (such as perhaps DANE-EE(3) and DANE-TA(2) if
the application wants to always use *at least* WebPKI).  Another option
is to just delete this paragraph, though it would be better to then
say "MAY" and still list the proposed caveats, silence is worse than
explaining the additional considerations.

Visceral dislike of DNSSEC is not a good reason to further weaken
DNSSEC-based mechanisms.

> And if so,
> vice versa?

Indeed, hence PKIX-EE(1) and PKIX-TA(0), and potential application
profiles that support just these certificate usages, but then
(surprise!) you need downgrade protection for this extension to be
at all useful.

> For DANE proponents to make a stronger case, they need to

We are NOT arguing for or against DANE or WebPKI.  We're defining
an extension that makes it possible to obtain DANE TLSA records,
from the TLS server.  This mechanism with some rare exceptions
(greenfield applications that purportedly mandate DANE, do they?)
needs downgrade protection to be useful.

> The second reason is that pinning really is a controversial feature.

Which is why it is OPTIONAL, and disabled explicitly in the initial
draft.

> And for this reason, putting it in the core spec will be difficult.

There is no pinning in the core document, only a reserved field
that explicitly proscribes unilateral pinning.

> of which I share by the way.

Most of those arguments are substantially flawed.  Only if
one believes that downgrade protection must not be allowed
to be specified and one not only never intends to use this
extension in one's own applications, but would want to make
sure that the option to do so is not available others (be it
out of paternal considerations to save them from their own
folly?) would it make sense to oppose the reserved field.

Secondarily, one might just give up the fight or choose to
to fight another day, but then one can stay silent, it is
not a valid opposing view.

> So moving this feature into a new optional

I wish I could be confident that such a specification would
be allowed to move forward.  My fear is that the same visceral
opposition to DANE and DNSSEC would play out, and so I may as
well try to get past these now.

> By continuing to argue your position, the most you can hope to
> achieve is deadlock.

The topic is fair-game while the draft is still being revised.

> satisfies even the security purist, so I'm glad it's in the core

Thanks.  Please a look at the first commit in the pull-request.  It
covers blocks of text that I think need revision now that denial of
existence is an option.

Please also see the proposed change to the first paragraph of section 6.

-- 
	Viktor.

---

From: Shumon Huque <[email-masked]>
Date: Sat, 28 Apr 2018 14:54:32 -0400

> well try to get past these now.

I would like to explore this. Is there anyone in the working group
who would oppose such a new spec moving forward?

(Maybe the WG chairs need to ask this question officially).

Shumon

---

From: Paul Wouters <[email-masked]>
Date: Sat, 28 Apr 2018 15:01:34 -0400 (EDT)

On Sat, 28 Apr 2018, Shumon Huque wrote:

[ not going to repeat my technical arguments here, just going to comment
on process ]

> i.e. that DANE needs downgrade resistance against PKIX attacks

This is incorrect. From the replies to the consensus call on the list,
it actually weights in favour of _some_ kind of downgrade resistance.

In fact, it worries me that the consensus call outcome seems to come
from non-public voices and not from a tally of those participants on
the TLS list.

> mechanism that if available unconditionally trumps PKIX authentication.. 

This is actually upsetting. I can assure you that since the late 90's,
people were working on DNSSEC as an alternative for the webpki. I wrote
RFC 7901 as a building block for doing so, and that RFC is now the basis
of the format of the data in this document. It is an explicit goal of
_some_ people at IETF and has been for decades. What the motivation is
of the individual document editor is not relevant. Once the document
was adopted by the WG it became a document that needs to represent WG
consensus, not original author intent.

I will agree to the point that people in the webpki sphere dislike
DNSSEC and don't want to see it competing against webpki. But writing
specifications to limit alternatives is not what the IETF is about. The
two byte is too much argument is simply a strawman argument.

The "additive use case" is a completely made up concept. No one in their
right minds will want a security model of "DANE or WebPKI, whichever is
weaker".

> (i.e. a protocol behavior that is the opposite of downgrade resistance). 

No one is objecting to that text.

> problem? The only security downgrade issue I see is DNSSEC's use of 

Everyone makes mistakes, even people in the IESG. Viktor, Nico and I
have clearly explained the downgrade attack. If your argument is that
the IESG said otherwise and we should believe them, then the IESG is
wearing no clothes, unless the specific IESG individual will show us
the technical argument of why there allegedly is no downgrade attack.

> first. There will always be opportunities to improve the protocol

This is again not the proper argument to have. We make arguments based
on technical merit and not based on "other [political] views". The
technical points against a two byte zero value are non-existent.

> in the weakest part of the chain (some chains are even weaker)? And if so,

At this rate, this RFC won't be ready before .com is using 2048bit
ZSK's. The argument is pretty weak and ephemeral and should not be
an argument when writing RFCs.

> why should PKIX not need downgrade resistance against DANE

It already has that by simply not using DANE, which is what all current
browsers already (sadly) do. The refusal of the two byte value however,
does not reciprocate that freedom to those users who voluntarilly want
to move away from webpki towards dane-only.

> weak keys (which would likely take years).

Strawman. From what I know, Versign is already investigating the ZSK
key length for its zones. Regardless of if that would take years or not,
publishing new RFCs that for no reason prohibit moving towards this
added security is not what the IETF should be doing.

> And for this reason, putting it in the core spec will be difficult.

That is not a technical argument. And Viktor's proposal of just adding
the two bytes set to a mandatory 0 in this specification moves the
discussion of how/when to pin this extension to that other new document
that will see new (technical) discussion. So your argument here is only
in favour of those two bytes to ensure proper extension pinning
discussion happens in the new to be written specification.

> behavior) appears to me to be the past of least resistance.

The path of least resistance is not the same as rough consensus.

> By continuing to argue your position, the most you can hope to achieve

The exact same can be said of you, when you will face the inevitable
Appeal Process.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Sat, 28 Apr 2018 15:08:11 -0400 (EDT)

> (Maybe the WG chairs need to ask this question officially).

There is not much point in doing this, as everyone can "change their
mind" later when this document's process has completed.

In other words, it won't make me feel any better if no one objects now,
unless the chairs would make it a discussion to update the TLS charter
to add this work item.

And even then, the more inevitable this new work item becomes, the
more sense it makes to add the two bytes now to avoid more "designed by
committee" weirdness like one extention mandating another extension and
figuring out what it means if the mandating-extension itself vanishes.

Our two byte proposal is technically sound.

Paul

---

From: Shumon Huque <[email-masked]>
Date: Sat, 28 Apr 2018 15:28:38 -0400

> it actually weights in favour of _some_ kind of downgrade resistance.

This isn't clear to me at all. What I observe is that some folks who don't
want pinning in the draft are okay with it being an optional separate
extension (which they can ignore, but others that want it can implement).

Sadly, only a handful of people are actually participating on the list.
What you are ignoring is the many people who spoke up in person at
IETF/London against pinning. Most of those folks are not speaking up
on list now. So if we do put the pinning field in this draft, what I suspect
will happen is that it will be discussed at some future IETF TLS WG
meeting, and will be shot down, and we'll be back to square one again,
and this draft will never make progress.

Thus my pragmatic side is encouraging going in the direction of the
new extension, which I believe has more chance of success.

Shumon.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 28 Apr 2018 15:34:54 -0400

> On Apr 28, 2018, at 3:28 PM, Shumon Huque <[email-masked]> wrote:
> 

Consensus is verified on the mailing list. NOT in the room.
If we get this draft revised promptly, I would expect it to
complete the process before the next IETF in any case.

-- 
	Viktor.

---

From: Shumon Huque <[email-masked]>
Date: Sat, 28 Apr 2018 16:11:44 -0400

> consensus, not original author intent.

This is a case where clarifying the scope and limitations of the protocol
from the outset would have been helpful.

Many DNSSEC people I know who have followed this draft and
participated in the much earlier discussions around DNSSEC stapling
in certificates were acutely aware of lack of authenticated denial and
its obvious implication that there was no downgrade resistance against
PKIX. So I always assumed there was at least an implicit understanding
of the scope.

What greatly surprised me was that Viktor (and you) did not come to
this realization until a few months ago (I believe that was shortly after I
asked Viktor in private email to read the entire draft and I assume he
came upon the text that described the issue, and the possibility of
extending the protocol to include DoE later). We probably should have
put this text in much earlier versions of the draft.

Shumon

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 28 Apr 2018 16:19:03 -0400

> On Apr 28, 2018, at 4:11 PM, Shumon Huque <[email-masked]> wrote:
> 
> extending the protocol to include DoE later). 

In my case, too many of the available cycles for this document were
consumed by the necessary, but not security relevant, discussion of
the payload format, and I had no time left for take in the big picture.
I wish it were otherwise.  It would have been far better to deal with
this at the outset...

-- 
	Viktor.