jlivingood
commented
4 years ago Making PRs to address now
Closed jlivingood closed 4 years ago
jlivingood
commented
4 years ago Making PRs to address now
jlivingood
commented
4 years ago
Core Requirements: -- differentiate between mandatory and optional (e.g. nice to have vs must have). So maybe rename section to Requirements and then split into two subsections (or Preliminary Requirements) -- Requirements bullets - make numbered list -- Maybe rename requirements to 'things we need to think about' (not much support for this) -- Add authentication (Paul emailed WG mailing list 29-Oct)
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)
There is some discussion of signaling vs. negotiation. Requirement ultimately is about "Load Shedding" or "Load Management"
Add TLS 1.3 as a mandatory requirement
In Downgrade Attacks, maybe make 853 be required but this would be in conflict with comment above on load shedding
Policies / upgrade-downgrade -- User preferences are between user and recursive -- Q is any auth RR to specify this associated with the target domain or for the TLS cert's domain? Maybe that is for protocol-dev phase and not now in requirements
Opportunistic encryption comment: does not believe opportunistic encryption is not best practice. Rather that explicitly enabled encryption with downgrade protection is best. So we can reword this. Early phase deployment to be opportunistic still seems like a possible necessity to get organic bottoms-up deployment. TBD - need to think about this more.
Add a requirement that we want to support incremental deployment
We may want to specify sets of requirements - maybe like SIP profiles or something, like 3 common ways to deploy or phases of deployment? Use the DO model from DNSSEC as a model!