Re: [Uta] draft-brotman-mta-sts/

> > I think that tumblr.com and dyndns.org can figure out a way to > avoid delegating that particular prefix. Has there been any effort to standardize or register the "special" subdomains, e.g. something like *well-known*.domain.com? Having seen large companies fail to secure the abuse@,

Re: [Uta] draft-brotman-mta-sts/

On Wed, May 04, 2016 at 01:38:22AM +0200, Daniel Margolis wrote: > Yeah, I agree on the two points. But is it safe for us to assume that > "smtp-sts-policy" is not an untrusted host? This was our concern, given > examples like dyndns.org or tumblr.com. Of course, an attacker also has to > do DNS

Re: [Uta] draft-brotman-mta-sts/

On Tue, May 03, 2016 at 11:57:40PM +0200, Daniel Margolis wrote: > > By "TXT" resolution do you mean publishing the target URI in the > > DNS TXT record? If so, I thought that idea was abandoned. > > > It was, but only because we had been thinking we would just use a > hard-coded hostname

Re: [Uta] draft-brotman-mta-sts/

>The documentation says: > >Changed in version 3.4.3: This class now performs all the necessary > certificate >and hostname checks by default. To revert to the previous, unverified, > behavior >ssl._create_unverified_context() can be passed to the context parameter. > >So it seems

Re: [Uta] draft-brotman-mta-sts/

> On May 2, 2016, at 9:06 PM, John Levine wrote: > > Is it really that hard to look at the documentation for the python > libraries? It's right here: > https://docs.python.org/3/library/http.client.html > > By default, the https library checks the certificate chain against

Re: [Uta] draft-brotman-mta-sts/

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

Re: [Uta] draft-brotman-mta-sts/

>Cute, but likely completely insecure. I see no check that the >certificate chain is trusted. Is it really that hard to look at the documentation for the python libraries? It's right here: https://docs.python.org/3/library/http.client.html By default, the https library checks the certificate

Re: [Uta] draft-brotman-mta-sts/

Cool, thanks for sharing that, John. I should note that even we are considering fetching these policies from outside the MTA, so a script like this running in its own cron job against the last hour's unique domains could be a totally viable option. I offer this for those who were reluctant to

Re: [Uta] draft-brotman-mta-sts/

> > On 1 May 2016, at 11:29, Stephen Farrell wrote: > > > > Wouldn't the same argument tend to indicate SRV or a sub-domain are > > as troublesome, given in many enterprises, mail and DNS can be in > > different silos? After all, isn't that the core of the stated

Re: [Uta] draft-brotman-mta-sts/

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

Re: [Uta] draft-brotman-mta-sts/

> On 1 May 2016, at 11:29, Stephen Farrell wrote: > > Wouldn't the same argument tend to indicate SRV or a sub-domain are > as troublesome, given in many enterprises, mail and DNS can be in > different silos? After all, isn't that the core of the stated argument > for

Re: [Uta] draft-brotman-mta-sts/

>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?

Re: [Uta] draft-brotman-mta-sts/

On Sun, May 01, 2016 at 09:40:30PM +0200, Daniel Margolis wrote: > > If the two names in the cert aren't in the same tree, how will you > > get a CA to sign it? For example, I have a customer philiphazan.com > > whose mail is at Tucows' hostedemail.com. Who's going to get the > > cert, me or

Re: [Uta] draft-brotman-mta-sts/

On 01/05/16 02:26, John Levine wrote: >>> We talked about this at great length over dinner in Buenos Aires. >>> Demanding a web server at the same domain name used in e-mail >>> addresses is operationally a non-starter for large organizations. >> >> STS is primarily for the large email providers

Re: [Uta] draft-brotman-mta-sts/

>> We talked about this at great length over dinner in Buenos Aires. >> Demanding a web server at the same domain name used in e-mail >> addresses is operationally a non-starter for large organizations. > >STS is primarily for the large email providers authoring the draft, >for whom this is not a

Re: [Uta] draft-brotman-mta-sts/

On Sat, Apr 30, 2016 at 10:29:30PM -, John Levine wrote: > >> I'm quite uncomfortable with the bit that says you look up the policy > >> at https://policy._mta_sts.example.com/current > > > >That's surely a mistake. It should have been a ".well-known" > >URI at the domain with no prefixes. >

Re: [Uta] draft-brotman-mta-sts/

>> I'm quite uncomfortable with the bit that says you look up the policy >> at https://policy._mta_sts.example.com/current > >That's surely a mistake. It should have been a ".well-known" >URI at the domain with no prefixes. We talked about this at great length over dinner in Buenos Aires.

Re: [Uta] draft-brotman-mta-sts/

On Sat, Apr 30, 2016 at 07:37:13PM -, John Levine wrote: > I'm quite uncomfortable with the bit that says you look up the policy > at https://policy._mta_sts.example.com/current That's surely a mistake. It should have been a ".well-known" URI at the domain with no prefixes. > I have two