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 protected]> wrote: > On Tue, Sep 05, 2017 at 08:04:24PM +0200, Daniel Margolis wrote: > > > 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. > > 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 69D43912A7968E0E7CF60EFD830D91 > 67746AA8C2B2BE7C43CC7E985F0846D485 > > > 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). > > 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, > > 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. > > 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. > > _______________________________________________ > Uta mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/uta >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
