Re: [dns-privacy] [Ext] Intermediate proposal (what I was saying at the mic)

[Brian Dickson <[e-mail]>]

On Tue, Aug 3, 2021 at 1:55 PM Paul Hoffman <[e-mail]> wrote:

> On Aug 3, 2021, at 1:34 PM, Ben Schwartz <bemasc=
> [e-mail]> wrote:
> >
> > In my view,
> >
> > 1. We should provide guidance on how to do unauthenticated DoT/Q using
> default-port probing, like we used to have in
> https://datatracker.ietf.org/doc/html/draft-ietf-dprive-opportunistic-adotq-00
> .
> >
> > 2. Publishing a SVCB record should indicate support for authenticated
> encryption.  Nameservers that don't support authenticated encryption can
> offer opportunistic encryption based on default-port probing.
> >
> > 3. We should allow nameservers to indicate support for authentication
> via common PKI, DANE, or both.
> >
> > 4. SVCB and TLSA records are a firm promise, but resolver behavior is
> always up to the operator.  They can choose whether to "fail closed", skip
> authentication, fall back to UDP, etc.
>
> If the WG is going to go to DS in the parent to have a signed signaling
> response, it would make sense that the signal in the child have an
> identical format. If we go with that, I'd rather see CDS be used in the
> child instead of SVCB.
>
> I like using #4 as a way to bridge the two use cases (well, the stated
> unauthenticated use case and whatever fully-authenticated use case
> eventually gets published). That way, resolvers that have the
> unauthenticated use case have more reliable ways to get the signal, and
> also can get a signal for DoH.
>

Some (IMNSHO) important observations, and recommendation for direction on
these:

   - SVCB in the name server name's zone is where the signalling belongs
   (on what transports are supported, per NS name, as well as authenticated or
   not, etc)
   - TTL on DS is controlled by the parent zone, and may not be appropriate
   for risky changes, thus not a good place for signalling
   - DS is a good place to protect the glue (NS records themselves, plus
   glue A and AAAA records) - in fact, it is the only viable solution for that
      - DS for the NS needs to scale according the NS RDATA, not the owner
      names, so the DS per zone should not include the zone name (too
esoteric to
      discuss/debate this point, I think)
   - Signaling transport should be SHOULD, just to avoid port probing.
      - Opportunistic authentication is different from opportunistic period
      - It is better to signal transport and whether it is authenticated
      (in once place, the SVCB record)
   - The parent DS is per zone, not per name server, so that is NOT where
   transport/opportunistic signaling belongs (e.g. changing those MUST NOT be
   per zone)
   - There is a separate DS for the name server's names' zone, of course...
      - That is where the glue A/AAAA records can be added to protect the
      resolution needed for querying for SVCB records
   - I don't think there is any reason to specifically support unsigned
   name server name zones
      - You need signed data to protect the information needed to get to TLS
      - It's integrity, not privacy, that is needed at this step
      - The first query to the NS name's zone cannot be TLS yet, because
      the info for TLS isn't available yet (catch 22)
   - TLSA allows signaling of WebPKI as an optional required validation
   over the certificate in the TLSA record (types 0/1 vs 2/3 IIRC).
      - Optional validation != optional WebPKI
      - You can have a signal that says "mandatory validation using TLSA
      but not WebPKI"
      - That signal could instead be, "mandatory validation using both TLSA
      and WebPKI"
      - Both are downgrade resistant
   - SVCB would signal DNS operators intent for failure mode
      - E.g. opportunistic (fail to fallback) vs mandatory (fail hard),
      subject to resolver's own policies (which could ignore DNS operator's
      signal)
   - If you require a signed zone anyway, and are going to do TLS (that's
   what we are discussing), then *requiring* TLSA records (with or without
   WebPKI) is a very easy thing to justify
      - Reminder: just because type 2/3 records don't require WebPKI
      validation, does not mean you can't use CA issued certs for those
      - It just means the validation avoids having to do WebPKI stuff.
      - DNSSEC signatures protect the cert fingerprint (EE or parental) in
      all cases
   - TL;DR: registrant zone gets DS with protection over NS RDATA; name
   server name delegation is similarly protected; name server name resolution
   at some point depends on glue A/AAAA which also get DS protection; name
   server name has SVCB and TLSA records; SVCB signals opportunistic or not;
   TLS validation via WebPKI is signaled via TLSA; deployments and roll-back
   are handled strictly in the name server name's zone (including use of
   appropriate TTL values during deployment/rollback)

Resolvers can still work with this even if they don't do DNSSEC validation.
They do lose downgrade protection, but can still resolve fine.

Resolvers that do DNSSEC validation are protected against downgrade, IFF
the DNS operator has elected to signal hard failure. This protects against
MITM on both DNS and transport (TLS).

Brian