On Fri 2018-12-14 03:30:29 +0530, Mukund Sivaraman wrote: > I don't think this way. :) I think it will not support every RFC 1035 > DNS name, but only a subset of it. It should work for every valid name, > because they are valid names and some application may want it. Why > settle for hacks when it can be designed elegantly?
It depends on what elegance you're looking for. There are ugly
real-world systems out there that can't support all kinds of new keys.
Furthermore, if you want a key digest to be bound to a specific name,
then either you incur an extra round trip (find out the name; then find
out the associated key digest) or you expect whoever ships the glue to
know how to ship additional glue cleverly. not so elegant in terms of
actual delivery.
Stuffing a digest of a key in the name is useful in binding the key to
the server directly, without having to juggle multiple different RRsets.
So i agree -- it looks like a hack, and it does have some size limits.
but i don't think those limits are plausible for anything real-world to
hit, and compared to the other inelegancies, it seems pretty promising
to me.
>> you get the key by connecting to the server and receiving it as part of
>> the server handshake.
>
> Nod. (can't help thinking that's another roundtrip, but perhaps that
> can't be avoided.)
if we're talking about DNS-over-TLS, then the server's key is going to
come down the pipe in the TLS handshake anyway, so it's no significant
extra burden to expect it there.
--dkg
signature.asc
Description: PGP signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
