In message <54F043F8(_dot_)6090409(_at_)cisco(_dot_)com>, Eliot Lear writes:
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--37wX9j2rj3rvIoUsDT9HVLKQlhR047phw
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
On 2/27/15 11:04 AM, Patrik F=C3=A4ltstr=C3=B6m wrote:
On 27 Feb 2015, at 10:56, Eliot Lear <lear(_at_)cisco(_dot_)com> wrote:
Given a slightly modified example from your document:
$ORIGIN example.net.
_http._web IN URI 10 1 "httpS://www.example.com/"
If the intent here is to declare an equivalence between
http://example.com and https://www.example.com the problem is that
absent DNSSEC one is subject to a downgrade attack. Thus a browser
cannot trust the equivalence.
Absolutely!
I get that, completely.
I wanted to know what is so special about URI that SRV and MX do _not_ =
have.
Truthfully I do not think there is a substantial difference, although
the form of attack varies slightly.
In the case of MX, the security properties (whether or not to use TLS)
do not explicitly change, although as you know, Patrik, it is possible
an attacker could divert someone's email with a low weight MX such that
STARTTLS is not offered, or if it is offered, it is for another
certificate. We have no standard defense to indicate that STARTTLS is
required at the MX level.
And that is coming "_25._tlsa" and it uses DNSSEC to prevent the
downgrade. Whether your MTA uses STARTTLS or not is another matter
but we can prevent downgrade attacks from succeeding.
In the case of SRV the situation is much the same. You don't specify
whether to start TLS based on SRV.
With SRV it depends on the protocol using SRV perhaps on concert
with TLSA. As for the name needed to presented in the TLS negotiation
that depends on the protocol.
But in the case of URI, if the
returned URI is intended to contain https: and yet an attacker somehow
prevents that from happening, no TLS is started. There is no easy
workaround for this sort of attack (or the others) because the traffic
is redirected to a perhaps-faux service.
URI really is the same as MX, SRV, CNAME. DNSSEC prevents it being
changed / removed. The rest is up to the protocol that is using it.
Sometimes the original name is used and sometimes the target name
is used. It also requires the client to do the right things.
For MX we have a single protocol and the leap-of-faith step of the
MX record is cleaned up using DNSSEC. There more to securing a
SMTP session but that too depends on DNSSEC.
For SRV we have multiple protocols and multiple models. The
leap-of-faith steps based on the SRV content are cleanup using
DNSSEC. SRV couldn't possible enumerate all the additional steps
need which is why SRV said that each protocol needs to describe how
to use SRV and retrofits need to document how to use SRV.
URI is similar to SRV. It is being introduced late. Existing
protocol need to document how to use it. New protocols need to
document how to use it. That usage will vary according to the
protocol. That said how you secure the contents of the records is
to use DNSSEC.
DNSSEC: it's not just for breakfast anymore.
Eliot
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka(_at_)isc(_dot_)org