On 29/07/15 19:00, Paul Hoffman wrote: > On 29 Jul 2015, at 10:48, Stephen Farrell wrote: > >>> Basically, the DNS stack will not know whether or not it is running >>> under TLS/DTLS when the query and reply are formed; TLS/DTLS will be >>> opportunistic. So, to be safe, the DNS client or server will be forced >>> to add padding even when it is not needed, and thus make every message >>> longer. >> >> I don't get that. Surely at most 1 query or response will be sent >> when in such a state of ignorance, after which the application layer >> can easily know if a TLS session exists. We are after all still >> talking about stub<->recursive still, right? > > We are not defining an API, so there is no way for the application layer > to know what it is running under.
Eh? There may be some implementations like that but I'd be very surprised if, when dprive is done, most implementations don't have an is_doing_dprive() call they can make use of in application layer code. Sure if you're running over IPsec that's a problem, but it hasn't been for TLS consuming applications that I know. > >> >>> We don't know how much padding is required to prevent analysis for >>> particular query/response pairs, and thus need to add lots of >>> random-length padding to each message to prevent the analysis. >> >> I also don't get that. I agree we're not sure how to best use >> padding. But we can define the simple bit of protocol needed now >> and then after folks figure out how best to use it we could have >> some more recommendations to make. And those might end up being >> context dependent. So I see no need to mandate something wasteful >> now. > > That would be fine. What I worry about is that people will say "we can > pad; people tell us to pad liberally; we will pad liberally". It would > be great for the spec to say "probably don't do this much until more > research has been done". That'd be fine if we can't do better by the time we're publishing that RFC text, yes. S. > > --Paul Hoffman > > _______________________________________________ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy > > _______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
