On Mon, May 2, 2016 at 12:55 AM, Viktor Dukhovni <[email protected]> wrote:
> > > On May 1, 2016, at 5:00 PM, John Levine <[email protected]> wrote: > > > >> So using the domain as-is and dealing with any provisioning politics > >> looks to be the only sensible option. > > > > Not to put Daniel on the spot, but since he happens to work for one of > > the largest mail providers in the world, would it be a problem to put > > the STS stuff at URLs like these? > > > > https://google.com/.well-known/sts-policy > > https://gmail.com/.well-known/sts-policy > > > > 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). > We need to put the organizations behind this draft on the spot to > not shirk this issue. There's no free lunch. I think it is fair > to ask the email folks at the large providers to negotiate with > others in their organization to deploy this in a manner that results > in a simpler security model. > > 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? > > So either the above ".well-known", or a kludgey reserved hostname > prefix, but there's no precedent for such reservations. > > -- > 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
