Alex
Why don't you propose some text, as we have a bandwidth delay product with you.
thanks tim On 11/17/15 5:30 PM, Alex Mayrhofer wrote:
Hello, Jumping into this thread late, sorry. Anyways, my proposal: - I think we should stick with requiring 0x00 padding (I am avoiding the term 'payload' here for a reason). This would prevent the abuse as a covert channel, is easily understood and implementable, and should not have any significant performance impact during creation of a message. - In the sense of "be conservative what you send, be liberal what to accept" I'm fine to change to text to require (recommend?) a Responder to ignore the contents. Which means that a malformed padding will never (rarely?) trigger an error response. However, my feeling is that we should still allow a "strict Responder" to indicate an error. That boils down to text like "a Responder MUST/SHOULD (?) ignore the contents of Padding" - I'd go for SHOULD, and subsequently keep the definition to use FORMERR if a strict Responder wishes to indicate an error - Further, I understand that TLS level compression is discouraged for DNS anyways ( I'm not an expert in this field, but that's what I understood what dkg said in our initial hallway discussion in Praha), so I'd stick with 0x00. If we find out this is really a problem, we can always define a padding with more sophisticated contents which Updates or Obsoletes this document. Requiring that a Responder ignores the contents would create forward compatibility on the Responder end. I'm more than happy to propose text if th WG agrees with the above summary :-) Alex (from mobile, sorry for brevity and typos) ---- Stephen Farrell schrieb ---- On 17/11/15 01:43, Daniel Kahn Gillmor wrote: > On Mon 2015-11-16 16:20:21 -0500 <tel:21 -0500>, Stephen Farrell wrote: >> I agree that that is clearly the opinion in the TLS WG today. I'm >> less sure I agree that's correct - my fear is that it's being driven >> maybe too much by browsers and the web, where the conclusion is >> valid. > > Well, certainly for a system-wide (or application-wide) arbitrary DNS > client it's the same risk. Similar but not quite the same. Cookies are the main likely target of CRIME but a DPRIVE equivalent can only target the (non-inserted) QNAME (or is there more?), which hasn't quite got the same kind of sensitivity. > We have no way of knowing how many avenues > there are for attackers to be able to make the user make certain DNS > requests to their preferred privacy-preserving resolver. Sure. I would guess the introduction of DPRIVE will change the attack surface and new attacks will be discovered. (Timing may well prove a fertile ground I would guess.) > And since we expect (D)TLS channels to be kept open and reused, that > attacker-controlled data will be touching the same deflate dictionary > that the ostensibly private queries are using. This is the same > scenario as CRIME and BREACH, no? Depends. It is unclear to me why padding doesn't help here, if applied after compression. (Mind you, at that point I don't know why one is bothering with compressing;-) > >>> Any attempt at compression needs to happen at the application layer >>> itself with full knowledge of the risks and tradeoffs. >> >> FWIW, I don't agree with the above, I think it's generalising too >> much from the browser use-case. > > The point here is that if you don't know how the application layer mixes > attacker-controlled data with data that needs to be confidential, TLS > can't possibly do compression safely. But what is the application layer for a system wide stub resolver? Your argument would also imply DNS/DPRIVE can't do compression either. > So while i agree with you that there could be (non-browser) applications > that clearly never mix any attacker-controlled data with > sensitive/private data on the same TLS channel, the only way to know > whether you're in such a state is by reasoning about it *at the > application layer*, which is why that's where the decisions about > compression need to be made. We don't agree about that. I don't think I've seen a convincing argument that's the *only* way to know. (E.g. always emitting fixed size packets in a single write and sending some cover traffic now and then when there's any compression in play would also seem to help, no?) But that's off topic for this list I guess, and may get too complicated before it'd get useful enough. > > anyway, i'm glad we agree on the outcome :) Yep - isn't the entire discussion of compression for DNS pretty moot anyway? It's not clear to me what compressible plaintext there is where compression would be a real benefit. Cheers, S. > > --dkg > > _______________________________________________ > dns-privacy mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/dns-privacy > _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
