On Fri 2017-04-28 09:15:18 +0100, Ray Bellis wrote:
> On 28/04/2017 08:42, Daniel Kahn Gillmor wrote:
>
>> 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.
>
> What if the stream is being unwrapped before it reaches the eventual
> destination, e.g. a hypothetical TLS endpoint that forwards the
> received queries over UDP ?
>
> Who's responsibility is it to make sure those forwarded queries can't be
> spoofed?
hm, good point. If the UDP endpoint is spoofable/injectable (e.g. over
an untrusted network) I'd say that the thing converting from a stream to
a UDP stream is at fault -- it doesn't know what assumptions the client
is making about the transport.
> It's a stretch, I know, but the point is to make us consider how
> removing security features might have unintended consequences upstream.
yep, if we decide to explicitly discourage non-predictability for the
client in this context (i don't think we need to), then the Security
Considerations should mention for the server that it should *not* assume
that the message IDs are unpredictable, and so shouldn't do things like
forward the packets over a link that doesn't have the same protections.
--dkg
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
