On Tue, Jun 9, 2020 at 11:49 AM Robin Geuze <[email protected]> wrote: [...]
> So we are back to ideally signaling something via the parent. The only > way to do this securely and without registries having to make large > changes would be to use the DS record. The simplest way to accomplish > this would be to just add a dummy DS record with an algorithm DoT. > However, that still leaves the problem of getting some way to > authenticate the sender. We could use the methods described above, > however the problem of the initial communication remains. Stuffing the > TLSA chain into the TLS Hello would solve that, but it would be a very > complex solution to a simple problem. > > This is where our idea comes from. “Hey, if we are going to be abusing > the DS record anyway, why not put a hash of the key in there”. It is a > simple solution, it will most likely be relatively easy to implement for > registries (they only need to add a new algorithm number in some cases, > the hashing method remains the same), and the amount of code needed in a > DNSSEC resolver is minimal. It also requires no extra queries, which is > a nice bonus. > > So in summary, we think this solution is the simplest, and has the > highest chance of deployment, due to it requiring minimal effort from > all parties involved. Other solutions are definitely possible, however > this is as far as I call tell the only one, outside TLSA records in the > parent, that allows full start to finish encryption. > Hi Robin, I can certainly understand the reason for repurposing/abusing the DS record for this. I think TLSA in the child zone could be made to work though, so I think it's still worth thinking about some more. Here's my suggestion: Place the TLSA record at the zone name, i.e. at the apex of the child zone, rather than at the NS server names: _853._tcp.example.com/IN/TLSA. That solves the name authentication problem because the nameserver names aren't authenticated in the referral, but the zone name is authenticated via the signed DS RRset. We'd still want to have per server certificates/keys since if any single name server is compromised, we want to be able to surgically rekey only the compromised server without having to rekey the entire NS set. But this is easily done by having multiple TLSA records in the set - only one has to match. The initial bootstrapping problem can be addressed by using the TLS DNSSEC chain extension, which can deliver the zone's TLSA RRset on first contact, in-band in the TLS handshake. You mention the possibility of "stuffing the TLSA chain in TLS" - I wanted to make sure you knew the design work for this mechanism is already done: https://tools.ietf.org/html/draft-dukhovni-tls-dnssec-chain-01 (I do understand if people might balk at this being quite complex ..) Using the TLSA RR means that we can now support the full semantics of TLSA: EE cert, auth, local TA issued cert, or PKIX/WebPKI constraints. That leaves the secure capability discovery problem. We could still use a new DS algorithm for this - only a 1-bit signal is needed, so it minimizes the abuse, and allows the full complement of TLSA capabilities to work. Shumon Huque
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
