Viktor Dukhovni:
> On Tue, Feb 14, 2023 at 01:25:39PM -0500, Wietse Venema wrote:
> > Viktor Dukhovni:
> > > On Tue, Feb 14, 2023 at 01:01:05PM -0500, Wietse Venema wrote:
> > >
> > > > > Fiction aside, the use-cases look reasonable to me. I haven't thought
> > > > > through of what downgrade (from e.g. DANE) are introduced by the
> > > > > various
> > > > > (optional) fallback controls. If they do introduce potential
> > > > > downgrades, a brief note to that effect may be warranted in the docs.
> > > >
> > > > There is no implied downgrade. SRV is really like MX, with weights
> > > > and ports added. As long as the port info is propagated properly,
> > > > TLSA will just work, and connection caching will maintain separation
> > > > of traffic streams that should be distinct.
> > >
> > > What I had in mind was (optionally?) ignoring SRV lookup failure, rather
> > > than deferring delivery. If there are TLSA records for the SRV targets,
> > > but none for the fallback delivery method, then we possibly get a
> > > downgrade by ignoring lookup failure...
> >
> > But that problem already exists when a domain has some MX targets with
> > TLSA records and some MX targets without TLSA?
>
> There's a difference in my mind between operators not implementing
> security across the entire service (as above), and clients switching to
> an alternate service in response transient impedence in the expected
> one.
In the unlikely case that example.com has both MX and SRV records,
a fall back from SRV to MX (disabled by default) would still query
example.com DNS. It's not like they switch to a completely different
provider.
> But there the distincition is indeed subtle. As I mentioned, I haven't
> analysed what issues if any arise, and what documentation may be needed.
Wietse
