On Thu 2017-04-27 12:17:30 -0700, Paul Hoffman wrote: > On 27 Apr 2017, at 11:51, Christian Huitema wrote: > >> So maybe we could build on that, and let application register their >> specific 24 bytes string, allowing for demux on top of TLS. That would >> define an organized process. > > ...which would not work at all for DNS, one of the two protocols being > discussed here: the first two bytes are *supposed* to be > non-predictable.
itym (zero-based) octets 2 and 3 are *supposed* to be non-predictable,
since the first two bytes of stream-based DNS are the message length,
which is definitely *not* supposed to be non-predictable.
Out of curiosity, though: is the DNS message ID supposed to be
non-predictable for stream-based DNS as well?
My understanding of the message id is that it was originally intended to
allow servers and clients to identify and associate queries and
responses that already share the same 5-tuple (transport protocol,
source addr, source port, destination addr, destination port). That
initial intent doesn't require non-predictability, just good bookkeeping
:)
But I know that a subsequent requirement for non-predictability of the
DNS query message ID has arisen as a defense against off-path spoofed
DNS responses: an unpredictable message ID in the query increases the
entropy that an off-path spoofer attacker needs to guess from ~16 bits
(UDP port only) to ~32 bits (UDP port + message ID).
But does the non-predictability requirement hold in stream-based DNS,
where the establishment of the stream itself provides at least as good
protection against spoofed responses? If it holds in cleartext
stream-based DNS, does it also hold for encrypted, streamed DNS, where
the channel itself provides significantly *better* protection against
spoofed responses.
(again, i'm not arguing that exisiting clients *should* change their
message id selection for purposes of this draft; i don't think they need
to! But i'm wondering if the transport layer(s) we're talking about
actually obviate the typical need for strong message ID randomizaton)
--dkg
signature.asc
Description: PGP signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
