On Mon, May 02, 2016 at 07:06:42AM +0200, Daniel Margolis wrote:
> > > My impression from the converstation in B.A. was that it'd be
> > > a big problem.
>
> Probably the most likely answer is that it would be easier than deploying
> DNSSEC and harder than deploying at a custom host. For us it's probably
> doable; for some organizations I would imagine it to be substantially
> harder (if, for example, their email domain doesn't have an HTTPS presence
> today).
So far, that sounds like "doable" to me. If a sub-domain turns
out to be critically important, then despite lack of precedent it
should be a fixed prefix name that is a valid hostname. The prefix
might not be "reserved" exclusively for STS, but would be unlikely
to be used for another purpose in practice. Think "www.", "ftp.",
...
Organizations that delegate arms-length sub-domains would need to
be careful about delegating that particular prefix to an unstrusted
sub-entity, or ceding control of the content published at
"https:<prefix>.<parent-email-domain>". Then path component of
the URI would still need to be well-known (fixed).
> > SRV is very much not "webby". HTTPS libraries don't do SRV lookups,
> > or else when asked to connect to a hostname resolved via SRV outside
> > the library, will authenticate the insecurely obtained target name.
>
> Just to be clear, your point is not really that doing SRV or TXT resolution
> of the policy server's hostname is a problem; it's that short of overriding
> some HTTPS library's certificate matching, we would be potentially matching
> a cert for (say) "sts_policy.example.com", which removes some of the
> intended guarantees of "certificate matches the email domain," right?
Yes, that's my point, and with SRV indirection that derived hostname
would be obtained from an insecure source (unauthenticated DNS).
By "TXT" resolution do you mean publishing the target URI in the
DNS TXT record? If so, I thought that idea was abandoned.
[ FWIW, that hypothetical hostname can't have any "_" characters
in it and remain a valid hostname. ]
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
