I have not reviewed all these drafts thoroughly, since I am a slacker, and so what follows is mainly a reaction to presentations and not a detailed reading of the text. So, in no particular order (hence numbering):
8. draft-hzhwm-start-tls-for-dns-00, TO not protected It seems like a potential problem that the TO bit is not protected. A middlebox could strip TO in one or both directions and prevent TLS from ever being established. To both ends of the transaction, this seems indistinguishable from the case where the other end just doesn't support TO. A secure assertion around TO seems necessary. See 3b(ii). 3. draft-hzhwm-start-tls-for-dns-00, address to name mapping not 1:1 It seems like the nameserver name needs to correspond to some data in a certificate in order to confirm that the certificate being presented by the other end is authentic. It's possible in the DNS for many nameserver names (NS RDATA) to correspond to the same physical server. How does a server receiving a query know which certificate to present? 7. draft-hzhwm-start-tls-for-dns-00, not specified for UDP I am personally a fan of investigating ways in which opportunistically-persistent pools of TCP connections between DNS clients and servers could be used as an alternative to today's UDP spray, which as we know has a habit of bouncing off the urinal wall and making a mess of other peoples' shoes. I think we are some distance from understanding the operational implications of this, however, and it seems like a shame to gate this privacy proposal on that problem being solved. Pretty sure Duane called this out already, but I mention it again if for no other reason than to subject everybody to a toilet metaphor. 4. draft-wijngaards-dnsop-confidentialdns-00, let's use EDNS0 It solved some (not all) response size concerns for DNSSEC to have the DO bit specified in the EDNS0 header, since you then can't ask for a secure response without supporting EDNS0 and hence larger buffer sizes. Encrypted data (with padding) is also going to lead to larger responses; the same benefits might apply. 17. draft-wijngaards-dnsop-confidentialdns-00, architectural considerations In the past when there was a desire to change the message format semantics, the OPT pseudo-RR was specified. If we consider this an established architectural approach, then we might consider that this proposal is also changing message format semantics; perhaps encryption of the various sections in the DNS message could be signalled through a similar pseudo-RR as an alternative to hiding encrypted data within a standard-format RRType (which seems a bit ugly). Perhaps it's worth re-casting this proposal as an EDNS0 option, or even as an EDNS1. EDNS0 options are hop-by-hop. It's not obvious this is what we need, since that makes every intermediate DNS server a potential interception point. But perhaps that's ok anyway, if we imagine the 80% solution involves stub -> resolver -> authority where each arrow is a separate privacy domain anyway. 3b(ii). draft-wijngaards-dnsop-confidentialdns-00, ability to assert capabilities using DNSSEC The ability of a zone manager to assert the capabilities of the authoritative servers for that zone, and sign that assertion with DNSSEC, seems like a strength of this proposal in the sense that a client can gain confidence in the availability of a secure channel to an authoritative server, and can plausibly reject responses that suggest that the server is not capable for fear that they have been injected by an intermediary. Joe _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
