On Tue, Aug 3, 2021 at 1:55 PM Paul Hoffman <[email protected]> wrote:
> On Aug 3, 2021, at 1:34 PM, Ben Schwartz <bemasc= > [email protected]> 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
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
