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

[Paul Wouters <[e-mail]>]

On Sat, 28 Apr 2018, Shumon Huque wrote:

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

> 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 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.

> 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.. 

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".

> 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). 

No one is objecting to that text.

> 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"?

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.

> 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.

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 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,

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.

> 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).

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.

> The second reason is that pinning really is a controversial feature.
> 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.

> 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.

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
> is deadlock.

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

Paul