Re: (short version) Re: Last Call: <draft-faltstrom-uri-10.txt> (The Uni

On 2/27/15 11:04 AM, Patrik Fältström 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.

In the case of SRV the situation is much the same.  You don't specify
whether to start TLS based on SRV.  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.

DNSSEC: it's not just for breakfast anymore.

Eliot

signature.asc
Description: OpenPGP digital signature