Re: [DNSOP] New Version Notification for draft-rebs-dnsop-svcb-dane-00.txt

[Viktor Dukhovni <[e-mail]>]

On Wed, Dec 22, 2021 at 03:52:22PM -0500, Ben Schwartz wrote:

[ Sorry about the delayed response, on the road since Dec 24th... ]

> I don't want this draft to become an omnibus update to RFC 7671.  My goal
> is to produce a short draft that is basically parallel to RFC 7673.
> 
> If you want to pursue a broader revamp of DANE, I think that could be
> valuable, but I don't think it needs to be connected to this.

Understood, but at least now you're aware of the outstanding "loose
ends".  To the extent that they're relevant to your draft, it may be
appropriate to make any necessary adjustments.

> > So this is different from the situation with MX (and IIRC SRV) records,
> > so perhaps CNAMEs will be much more common in this context?
> 
> I think it's too early to predict the popular deployment strategies here.
> Also, SVCB + TLSA is "green field" territory, so it's up to us what we want
> to allow.

OK, so do you think that following CNAMEs to find TLSA RRs at the
expanded target name is a good idea in this context?  If not, I think
it would be reasonable to diverge from 7671 on this detail.

> > It is very much *NOT* an optimisation.  Rather it is an essential
> > element of robustness of the protocol in the face of the reality
> > of the DNS ecosystem:
> >
> >     - For DANE to be useful it must not be trivially subject to
> >       downgrade by not responding to TLSA records, returning REFUSED,
> >       NOTIMP, SERFVAIL or bogus replies.
> >
> >     - However, many unsigned zones are served by functionally limited
> >       to mostly-broken load-balancers that just know how to return
> >       A/AAAA records and not much else.
> >
> >     - When you send a TLSA query to such a nameserver, you often end
> >       up with a lookup failure, rather than a valid "insecure" denial
> >       of existence (proof of an insecure delegation at some parent
> >       node + insecure NODATA or NXDOMAIN).
> >
> >     - For DANE to avoid downgrades, TLSA query SERVFAIL needs to lead
> >       to connection failure.
> >
> > This is why the "optimisation" in question is in fact an essential
> > element of 7671.
> >
> 
> If it's an essential element of 7671, maybe it should be mentioned in 7671!

If this is only discussed in 7672, mea culpa...

> I think this is an interesting workaround, but I'm not sure it will be
> necessary here.  SVCB is to a large extent a "green field" territory, which
> may exclude a lot of buggy legacy systems.  Also, SVCB specifically renders
> this kind of misbehavior into a hard-fail condition already [1], and
> large-scale experiments have confirmed that this does not result in a
> significant error rate.
> 
> [1]
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-08#section-3.1

The largest known (to me) cluster of poor beviour with TLSA lookups is
*.mail.protection.outlook.com, where TLSA queries return NOTIMP.
Perhaps no similar issue is present in the targets of interest here.

Things are indeed simpler if the workaround is not needed.

> > No, I am talking about a situation where AD=0 despite the fact that the
> > original name is in a signed zone, because the target of the CNAME
> > lookup is not in a signed zone:
> >
> >     ; signed zone
> >     www.secure.example. IN CNAME www.insecure.example.
> >     www.secure.example. IN RRSIG CNAME 13 3 ...
> >     _443._tcp.www.secure.example. IN TLSA 2 1 1 ...
> >     _443._tcp.www.secure.example. IN RRSIG TLSA 13 5 ...
> >
> >     ; unsigned zone
> >     www.insecure.example. IN A 192.0.2.1
> >
> > An "A" record query for "www.secure.example" via recursive resolver will
> > return an insecure answer" with AD=0:
> >
> >     www.secure.example. IN CNAME www.insecure.example.
> >     www.insecure.example. IN A 192.0.2.1
> >
> > but there are in fact signed TLSA records for the qname.
> 
> Yes, so the client issues a query for TLSA at
> _443._tcp.www.secure.example.  This seems like the standard RFC 7671 CNAME
> handling.  There is no need for the client to issue a query with
> QTYPE="CNAME".

Once the work-around is not needed, then indeed the "QTYPE=CNAME" query
is also not needed to determine whether the unexpanded zone is signed.

If the workaround is needed, then the CNAME query comes into play.

-- 
    Viktor.