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, 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] >> https://www.ietf.org/mailman/listinfo/dns-privacy >>
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
