In message <54F043F8.6090409@xxxxxxxxx>, 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@xxxxxxxxx> 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@xxxxxxx