Re: [Uta] Uta Digest, Vol 28, Issue 16

[Viktor Dukhovni <[e-mail]>]

On Thu, Mar 24, 2016 at 06:06:25PM +0100, Daniel Margolis wrote:

> I think your thought exercise has brought you to the same place I arrived
> at. ;)
> 
> Note in particular, regarding domains "too big to do DANE", that this seems
> likely to be especially true for big hosting providers.

[ As an side, udmedia.de, transip.nl and nederhost.nl are doing
fine with hosting lots of DNSSEC customer domains with DANE-enabled
MX hosts, so I don't understand the above, but I think it is off
topic, so we can move on... ]

> A secondary problem with in-band validation is that it may increase the
> risk of an attacker turning a temporary MITM into a perma-DoS, because you
> now can't require that the policy be delivered from a server who's
> certificate SAN matches the email domain.

Indeed this is fatal.  It is the same issue that faces RFC 6186 in
the absense of DNSSEC.  There is no practical way to do WebPKI
authentication of target services in the presence of unvalidated
DNS-based indirection.  Alexey's recent email certs RFC suggests
SRV-ID, but I don't see substantial support for that as likely to
happen.

> Anyway, this is a bit of a tangent, I think, because I think we're all on
> the same page, but I've been sort of meaning to write up a list of
> motivating design concerns describing these sorts of corner cases that we
> discovered in alternate proposals; otherwise it's easy to forget *why* X
> wasn't likely to work.

In this light the well-known HTTPS URI is the glue tying the STS
policy to the domain owner in a way that works with WebPKI and
avoids DNS indirection.  Instead the STS policy constrains the
targets of the DNS indirection.

This sure ain't pretty!  I sure wish you guys would hurry up and
do DANE, but wishing it won't make it so... :-(

-- 
	Viktor.