IETF-106 Discussion Topics

[jlivingood]

Potential topics authors wish to raise for discussion at IETF-106:

1 - WebPKI (CA) or DANE (TLSA)? Or both options?
2 - Allow fallback to Do53 or not? Or allow the domain owner to signal or user/client to signal whether fallback can occur?
3 - Is support for ADoT on a per nameserver basis or a per domain basis (so some domains on a NS may support while others may not)?
4 - Are the certificates based on NS IP address or name?
5 - DNSSEC support - MUST, SHOULD, or not mentioned?

[jlivingood]

6 - Are there any gaps in section 4, Threat Model and Problem Statement?
7 - Provisioning impacts - operators and vendors say implementation
must be zero-provisioning. What does that mean and how should
that be articulated as a requirement?
8 - Signaling: Provide some method to signal not just binary support
DoT / do not support to allow for certain QTYPES or whatever to
use DoT while others may not (e.g. an auth server may want to say
in high load that some low risk or low priority queries fallback
to unencrypted comms). Is this signaling or negotiation? Perhaps
the requirement is ultimately about "Load Shedding" or "Load
Management".
9 - Rather than say DNS privacy methods should we specifically say no
ECS (or not fine-grained ECS), and to do QNAME minimization?
10 - Is signaling good and/or necessary?

[jlivingood]

On Q 1 - See https://datatracker.ietf.org/meeting/104/materials/slides-104-dprive-dot-for-insecure-delegations-01.pdf - especially the grid in slide 11 (last slide). From https://tools.ietf.org/html/draft-bretelle-dprive-dot-for-insecure-delegations-00

On signaling - See https://tools.ietf.org/html/draft-levine-dprive-signal-01

[jlivingood]

Raw notes from 106:

threat model -

• Attacker w/access to all traffic out of scope? EKR does not agree.

DoT always required?

• YES
• Maybe other equivalent secure transports (DoH, DoQ)
• Rephrase to require secure transport
• Per Ben also explain pros/cons of diff privacy prot practices at each layer of lookup

Trust anchor/authority: Should this depend only on the DNS, such as DANE, or also on Certification Authorities?

• Choices: out of band, DANE/DNS, PKI/CA
• Key point is referential integrity (per EKR - good re-wording)
• Note circular dependency risks (list potential dependencies and say not to break these)
• Must be simple enough to be (externally) analyzable & diagnosable
• Should we look at happy eyeballs to see if we can learn from that?
• Would be nice a la happy eyeballs to retain some data for a period of time / subsequent queries

Downgrade Prevention & Preferences: Should the user (e.g. stub, app, resolver) be able to say only ever use DoT and never downgrade? Or should the authoritative domain be the only one? Or should both be permitted and let the app/stub decide what to do based on that info?

• Domain must specify 53 or DoT or both or only DoT if avail
• look at rfc7762
• fallback logic/requirements needed
• how to deal w/happy eyeballs for auth server
• disc & advert of non-downgradable protocols

Discovery: What requirements do we have for a recursive to determine availability of encryption on an authoritative server? (e.g. loose coupling vs. whitelists are okay)

• Has to be in dns, signed, linked to nameserver
• use dns

high level

• recommended/mandatory is important discussion to happen next
• solutions can happen then in parallel
• major missing - zones whose NSs are not all controlled by one org (eg CDNs)
• DANE from apex recommended over delegation glue