<div dir="ltr">On Sat, Nov 23, 2013 at 1:37 PM, Michal 'vorner' Vaner <span dir="ltr"><<a href="mailto:vorner@vorner.cz" target="_blank">vorner@vorner.cz</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello<br>
<div class="im"><br>
On Fri, Nov 22, 2013 at 10:07:51AM +0000, Dave Cridland wrote:<br>
>  - If an attacker removes the record by fiddling with the DNS, then they<br>
> can mount an MITM attack. Note that they can also fiddle the DNS into<br>
> redirecting the connection too. It's not clear if this makes things any<br>
> harder than before.<br>
><br>
>  - If an attacker adds in a TLSA record, this could act as a denial of<br>
> service.<br>
><br>
> On reflection, I'm not sure if this is actually an overall benefit, but I<br>
> thought I'd throw the idea out.<br>
<br>
</div>I didn't read the RFC, but my impression was that it mandated TLSA is always<br>
signed by DNSSEC. So, the right thing should probably be to ignore and warn<br>
about unsigned TLSA records, not to honor them.<br></blockquote><div><br></div><div>Yes, that'd be the spec's preference.</div><div><br></div><div>What I'm wondering is whether an initiator could use the presence of a TLSA record to decide not to consider falling back to XEP-0220. In other words, whether a domain could use them to assert that it has a valid certificate.</div>
<div><br></div><div>The spec doesn't say so - the spec is heavily geared toward HTTPS, where opportunistic encryption constructs, as are used in XMPP, don't really exist at all.</div><div><br></div><div>Dave.</div>
</div></div></div>