> On Apr 28, 2018, at 12:26 PM, Shumon Huque <shu...@gmail.com> wrote:
>
> 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.
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.
> 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.
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.
> 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.
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
> 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..
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.
> 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).
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.
> 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"?
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".
> 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.
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.
> In fact, the legacy crypto issue will always be a huge impediment for
> 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
> 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)?
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,
> why should PKIX not need downgrade resistance against DANE, rather than
> 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
> 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).
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.
> I won't repeat all the arguments and concerns expressed already, many
> 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
> extension (both the pinning field and a description of the associated
> behavior) appears to me to be the past of least resistance.
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.
> (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.).
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.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
