Whether we use sub-domain or .well-known URL path to serve STS policies, I'm
not sure whether we can guarantee uniqueness with the resource. I think
sub-domains are better because it helps the Mail admins to control those
policies - means they can make updates to these endpoint without depending on
web admins.
I would prefer a well known sub-domain based URL endpoint, that removes the
need to stick another record in DNS. Regarding certificate validation, it is
better to validate against the STS sub-domain based URL only (not parent/email
domain).
thanks,-binuYahoo Inc.
On Monday, 2 May 2016 6:52 AM, Viktor Dukhovni <[email protected]>
wrote:
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
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
