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.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
