Hiya, On 29/07/15 18:05, Paul Hoffman wrote: > On 29 Jul 2015, at 9:23, Daniel Kahn Gillmor wrote: > >> In the TLS WG, the broad consensus is that if padding is possible at the >> application layer, that is the right place to pad. > > That will teach me to stop going to the TLS WG. :-)
And this one may teach me to try harder to get to dprive:-) > >> The rationale >> concerns countermeasures to traffic analysis -- in particular, the >> application layer has much more knowledge than the TLS layer about what >> its traffic generally looks like. traffic analysis countermeasures are >> subtle and closely tied to existing patterns of usage. TLS is an >> abstraction that is intentionally removed from what the application >> layer does. >> >> Also, there is no padding mechanism available in TLS at the moment :) >> i'm trying to get one into TLS 1.3 for those application layers that >> have nowhere to pad, and i could conceivably write up an extension to >> TLS 1.2. But even having that mechanism, you'd need to be able to set >> policy about when to pad and by how much. >> >> So from the thinking and work i've done on this, padding at the >> application layer is preferable where possible. Paul, you say you have >> many reasons for wanting to do it in TLS -- can you explain some of >> those a bit more? I want to make sure i'm not missing anything vital. > > 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 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. > This > seems wasteful. Instead, if the TLS stack could add the padding, it > would only happen when needed. > > But I understand the problem of "we don't even have that now" and "we > don't know when we will have it". The draft in question is trivial to > implement, but configuring it (with the length per query or response) > seems impossible without adding large amounts. Again, I'm not that pessimistic. My guess is that implementers will figure out effective ways to pad. We don't need to tell them everything about that here and now. 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
