Subject: Re: [Uta] 302 redirects (was "MTA-STS and HTTP cache control")

From: David Illsley <[email-masked]>
Date: Sun, 03 Sep 2017 13:21:00 +0000

Unfortunately, given the dispersed nature of where you have to put config,
I’m not sure there’s an easy delegation model. Even if you go to the effort
of adding a host with a redirect, you still need to update the policy id in
DNS whenever the policy changes. Similarly, you can’t simply delegate the
mta-sts zone as the policy indicator TXT record doesn’t sit in it.

On Mon, 21 Aug 2017 at 20:47, Daniel Margolis <[email-masked]> wrote:

> My point was that if you host on Microsoft, you could have
>
> https://policy.example.com <-- cert for example.com, 302s to
> policy.microsoft.com
> https://policy.microsoft.com <-- cert for microsoft.com
>
> This way you don't have to give Microsoft your cert and they don't have to
> set up SNI--but conversely, you have to set up your own 302 redirector.
> Some users may prefer this to SNI, but I don't know if it's worth the
> complexity it introduces.
>
> I do agree this brings nice simplicity.
>
> *shrug*
>
> I'm open to feedback on this. I never felt strongly about either
> direction.
>
> Dan
>
> On Mon, Aug 21, 2017 at 8:42 PM, Binu Ramakrishnan <[email-masked]>
> wrote:
>
>> My understanding is the primary purpose of a 3xx redirect is policy
>> delegation. For example my MX points to Microsoft, so use their policy.
>> This is certainly useful, however in my opinion it is less compelling use
>> case because of the following observation:
>>
>> In case of 3rd party provider model, the provider is required to host an
>> HTTPS endpoint for every hosted domain, whether for doing a 3xx redirect or
>> serving a policy. Since we need HTTPS endpoint for every domain, why not
>> serve the policy itself? If the argument is to have one policy file shared
>> by all domains, then as a provider, you may serve a shared file or reverse
>> proxy the policy file from the right server.
>>
>> From a security angle, by not supporting 3xx redirect, I think we
>> simplified the policy retrieval and have one less thing to worry about (in
>> spec and implementation).
>>
>> Thanks,
>> -binu
>>
>> ------------------------------
>> *From:* Daniel Margolis <[email-masked]>
>> *To:* [email-masked]; Binu Ramakrishnan <[email-masked]>
>> *Sent:* Sunday, 20 August 2017 10:24 AM
>> *Subject:* 302 redirects (was "MTA-STS and HTTP cache control")
>>
>> So, the *motivation* for this was simplification: if you allow 302s, you
>> have to specify a bit more clearly what the behavior is for things like a
>> 302 to a HTTP URI, max redirect depth, etc.
>>
>> In truth, though, I've never been super happy with the prohibition on
>> 302s, since it seems to make policy delegation (i.e. "My MX points to
>> Microsoft; use their policy as well") easier than having your mail provider
>> also host a policy for you using SNI. I could personally be convinced that
>> we *should* allow 302s. I seem to recall Binu felt more strongly in the
>> converse, though, so I will let him chime in and maybe correct me. ;)
>>
>> On Sun, Aug 20, 2017 at 7:17 PM, Viktor Dukhovni <[email-masked]>
>> wrote:
>>
>>
>> > On Aug 20, 2017, at 1:08 PM, Daniel Margolis <[email-masked]>
>> wrote:
>> >
>> > Policies fetched via HTTPS are only valid if the HTTP response code is
>> 200 (OK).
>> > HTTP 3xx redirects MUST NOT be followed, and HTTP caching (as specified
>> in
>> > RFC7234) MUST NOT be used.
>>
>> I forget, is non-support of redirects intended to simplify the policy
>> retrieval
>> code at the sending MTA , or is it a security concern?  I am all for
>> making
>> the service accessible to bare-bones HTTPS implementations, and so am not
>> asking
>> for redirect support, just wanted to check the motivation...  Perhaps the
>> rationale
>> should be stated in the draft?
>>
>> --
>>         Viktor.
>>
>> ______________________________ _________________
>> Uta mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/ listinfo/uta
>> <https://www.ietf.org/mailman/listinfo/uta>
>>
>>
>>
>>
>>
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>

---

From: Daniel Margolis <[email-masked]>
Date: Tue, 5 Sep 2017 15:28:13 +0200

Good point. So, the TXT record could be moved to support this case, but I'm
not sure any of this is worth it. To recap, you have a few delegation
models:

1. HTTPS: Currently only by giving a cert to your provider and having them
use SNI; hypothetically possible by 302s.
2. TXT: Currently not possible; hypothetically possible by zone delegation.

On the other hand, I don't expect policies to change any more frequently
than MX records themselves, which is why it never seemed critical to me to
support delegation. Thoughts?

On Sun, Sep 3, 2017 at 3:21 PM, David Illsley <[email-masked]>
wrote:

>> This way you don't have to give Microsoft your cert and they don't have
>> to set up SNI--but conversely, you have to set up your own 302 redirector.
>>> So, the *motivation* for this was simplification: if you allow 302s,
>>> you have to specify a bit more clearly what the behavior is for things like
>>> a 302 to a HTTP URI, max redirect depth, etc.
>>>
>>> On Sun, Aug 20, 2017 at 7:17 PM, Viktor Dukhovni <[email-masked]
>>> > wrote:
>>>
>>>
>>> > HTTP 3xx redirects MUST NOT be followed, and HTTP caching (as
>>> specified in
>>> the service accessible to bare-bones HTTPS implementations, and so am
>>> not asking
>>> for redirect support, just wanted to check the motivation...  Perhaps
>>> the rationale

---

From: "Brotman, Alexander" <[email-masked]>
Date: Tue, 5 Sep 2017 14:51:52 +0000

Quick conversation with some DNS folks, and they say that we can publish a TXT record at the apex of a delegated sub-domain.  CNAMEs would not be allowed, but A/TXT should be okay.

--
Alex Brotman
Sr. Engineer, Anti-Abuse
Comcast

From: Uta [mailto:[email-masked]] On Behalf Of Daniel Margolis
Sent: Tuesday, September 05, 2017 9:28 AM
To: David Illsley <[email-masked]>
Cc: [email-masked]; Binu Ramakrishnan <[email-masked]>
Subject: Re: [Uta] 302 redirects (was "MTA-STS and HTTP cache control")

Good point. So, the TXT record could be moved to support this case, but I'm not sure any of this is worth it. To recap, you have a few delegation models:

1. HTTPS: Currently only by giving a cert to your provider and having them use SNI; hypothetically possible by 302s.
2. TXT: Currently not possible; hypothetically possible by zone delegation.

On the other hand, I don't expect policies to change any more frequently than MX records themselves, which is why it never seemed critical to me to support delegation. Thoughts?

On Sun, Sep 3, 2017 at 3:21 PM, David Illsley <[email-masked]<mailto:[email-masked]>> wrote:
Unfortunately, given the dispersed nature of where you have to put config, I’m not sure there’s an easy delegation model. Even if you go to the effort of adding a host with a redirect, you still need to update the policy id in DNS whenever the policy changes. Similarly, you can’t simply delegate the mta-sts zone as the policy indicator TXT record doesn’t sit in it.

On Mon, 21 Aug 2017 at 20:47, Daniel Margolis <[email-masked]<mailto:[email-masked]>> wrote:
My point was that if you host on Microsoft, you could have

https://policy.example.com <-- cert for example.com<http://example.com>, 302s to policy.microsoft.com<http://policy.microsoft.com>
https://policy.microsoft.com <-- cert for microsoft.com<http://microsoft.com>

This way you don't have to give Microsoft your cert and they don't have to set up SNI--but conversely, you have to set up your own 302 redirector. Some users may prefer this to SNI, but I don't know if it's worth the complexity it introduces.

*shrug*

I'm open to feedback on this. I never felt strongly about either direction.

Dan

On Mon, Aug 21, 2017 at 8:42 PM, Binu Ramakrishnan <[email-masked]<mailto:[email-masked]>> wrote:
My understanding is the primary purpose of a 3xx redirect is policy delegation. For example my MX points to Microsoft, so use their policy. This is certainly useful, however in my opinion it is less compelling use case because of the following observation:

In case of 3rd party provider model, the provider is required to host an HTTPS endpoint for every hosted domain, whether for doing a 3xx redirect or serving a policy. Since we need HTTPS endpoint for every domain, why not serve the policy itself? If the argument is to have one policy file shared by all domains, then as a provider, you may serve a shared file or reverse proxy the policy file from the right server.

From a security angle, by not supporting 3xx redirect, I think we simplified the policy retrieval and have one less thing to worry about (in spec and implementation).

Thanks,
-binu

________________________________
From: Daniel Margolis <[email-masked]<mailto:[email-masked]>>
To: [email-masked]<mailto:[email-masked]>; Binu Ramakrishnan <[email-masked]<mailto:[email-masked]>>
Sent: Sunday, 20 August 2017 10:24 AM
Subject: 302 redirects (was "MTA-STS and HTTP cache control")

So, the motivation for this was simplification: if you allow 302s, you have to specify a bit more clearly what the behavior is for things like a 302 to a HTTP URI, max redirect depth, etc.

In truth, though, I've never been super happy with the prohibition on 302s, since it seems to make policy delegation (i.e. "My MX points to Microsoft; use their policy as well") easier than having your mail provider also host a policy for you using SNI. I could personally be convinced that we should allow 302s. I seem to recall Binu felt more strongly in the converse, though, so I will let him chime in and maybe correct me. ;)

On Sun, Aug 20, 2017 at 7:17 PM, Viktor Dukhovni <[email-masked]<mailto:[email-masked]>> wrote:

> On Aug 20, 2017, at 1:08 PM, Daniel Margolis <[email-masked]<mailto:[email-masked]>> wrote:
>
> Policies fetched via HTTPS are only valid if the HTTP response code is 200 (OK).
> HTTP 3xx redirects MUST NOT be followed, and HTTP caching (as specified in

I forget, is non-support of redirects intended to simplify the policy retrieval
code at the sending MTA , or is it a security concern?  I am all for making
the service accessible to bare-bones HTTPS implementations, and so am not asking
for redirect support, just wanted to check the motivation...  Perhaps the rationale
should be stated in the draft?

--
        Viktor.

______________________________ _________________
Uta mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/ listinfo/uta<https://www.ietf.org/mailman/listinfo/uta>

_______________________________________________
Uta mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/uta

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 5 Sep 2017 12:03:51 -0400

> On Sep 5, 2017, at 10:51 AM, Brotman, Alexander <[email-masked]> wrote:
> 

DNS delegation is much too complex for this purpose.  Far simpler:

DNS:
    example.com. IN MX 0 mx1.provider.net.
    example.com. IN MX 0 mx2.provider.net.
    _mta-sts.example.com. IN CNAME _mta-sts.provider.net.

HTTP:
C:  GET https://mta-sts.example.com/.well-known/mta-sts.txt HTTP/1.1
C:  Host: mta-sts.example.com

S: 302 Get thee to a punnery
   Location: https://mta-sts.provider.net/.well-known/mta-sts.txt

-- 
	Viktor.

---

From: Daniel Margolis <[email-masked]>
Date: Tue, 5 Sep 2017 20:04:24 +0200

I had it in my head that a CNAME could only point to an A or AAAA, but I
can't find anything like that in the RFC at a quick glance, so perhaps I
made that up.

But it sounds like you'd still prefer 302s rather than SNI (i.e. rather
than having the mta-sts.example.com host record point to provider.net and
have them have an HTTPS cert for that identity). Which isn't unreasonable,
I think; people may not have a "policy.example.com"-only certificate and/or
may not want to give one to the provider and/or the provider may not want
to do SNI for all their customers.

Any other opinions on this? I think it is relatively easy to switch both
the text and the code to support redirects, so I don't have a strong
feeling myself.

On Tue, Sep 5, 2017 at 6:03 PM, Viktor Dukhovni <[email-masked]>
wrote:

> > Quick conversation with some DNS folks, and they say that we can publish
> a TXT record at the apex of a delegated sub-domain.  CNAMEs would not be
> allowed, but A/TXT should be okay.
>

---

From: David Illsley <[email-masked]>
Date: Tue, 5 Sep 2017 21:22:12 +0100

I'd totally missed the opportunity to use the CNAME for the TXT record as
well. Different people will have different things they're worried about,
but for me being able to:

DNS:
    example.com. IN MX 0 mx1.provider.net.
    example.com. IN MX 0 mx2.provider.net.
    _mta-sts.example.com. IN CNAME _mta-sts.provider.net.
      mta-sts.example.com. IN CNAME mta-sts.provider.net.

would work fine, and be much simpler than setting up a mta-sts host.

David

On Tue, Sep 5, 2017 at 7:04 PM, Daniel Margolis <[email-masked]>
wrote:

> I think; people may not have a "policy.example.com"-only certificate
> and/or may not want to give one to the provider and/or the provider may not
> want to do SNI for all their customers.
>
>> > Quick conversation with some DNS folks, and they say that we can
>> publish a TXT record at the apex of a delegated sub-domain.  CNAMEs would
>> not be allowed, but A/TXT should be okay.
>>

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 5 Sep 2017 21:19:11 +0000

> can't find anything like that in the RFC at a quick glance, so perhaps I

You've made that up.  CNAMEs alias all the records for a single
node in the DNS tree to corresponding records at some other node
(sometimes recursively).  It is quite common, for example, to have
CNAMES for TLSA records:

 $ dig +noall +nosplit +ans +nocl +nottl -t tlsa _25._tcp.mx01.domeneshop.no
 _25._tcp.mx01.domeneshop.no. CNAME mx._dane.domeneshop.no.
 mx._dane.domeneshop.no. TLSA 3 1 1 69D43912A7968E0E7CF60EFD830D9167746AA8C2B2BE7C43CC7E985F0846D485

> have them have an HTTPS cert for that identity).

To be clear, I am by no means a fan of needing to support redirect
chasing in the MTA STS policy retrieval code.  That said however,
as a hypothetical user of STS, I truly despise having anything to
do with the key management headaches of third-party SNI.  So if
you want to support delegation to the provider, then a customer
who, like me, hates SNI should be able to operate a tiny HTTPS
server that serves a redirect to the provider's policy URL.

> Which isn't unreasonable,

Your call.  However if configure-and-forget (with occasional updates
of one's own redirect server certificate, but no constant coordination
with the provider) delegation is important, then redirect support
is likely needed.

-- 
	Viktor.

---

From: Daniel Margolis <[email-masked]>
Date: Wed, 6 Sep 2017 16:16:56 +0200

Agreed. Binu, what are your thoughts on this? As Viktor said, I'm leaning
towards supporting redirects--as an implementor, it's a little extra work
(not much!) and seems to make usage much easier for many people in the
future.

On Tue, Sep 5, 2017 at 11:19 PM, Viktor Dukhovni <[email-masked]>
wrote:

> and/or