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