On 4/10/2017 11:43 PM, Alexander Mayrhofer wrote: > > Hello Christian, > > > > great to see this – i remember when i mentioned QUIC as an option > during the DNS-over-HTTP Bar BoF in Seoul i got quite a few weird > looks :). I like this. It looks like a logical choice somewhere > „between“ TLS and DTLS. > > > > I have some background on Section 6.5 (Padding) – back when we > specified DNS over TLS, we had a similar discussion whether to pad on > the DNS or the transport (TLS, in that case) layer. We decided in that > case that padding on the DNS layer is preferred, since it allows for > greater control by the application. This was actually the reason RFC > 7830 was created in the first place. > > > > The situation might be different for QUIC as there’s a tighter > coupling between transport and application, though padding on the DNS > layer would allow re-using the ongoing research and specification work > in DPRIVE. (Disclaimer: I know little about the current state of such > research for QUIC). > > > The situation is different in QUIC, because a single QUIC packet may carry several DNS packets, using separate STREAM-DATA frames to carry the content of different streams. Of course, the DNS application does not know whether the QUIC transport will in fact pack data from several streams in a single packet, so what we need here is some kind of API contract.
The efficient solution would be to instruct the transport to perform a particular padding strategy, similar to the padding strategies developed for DNS. This would cover many applications, not just DNS. Failing that, padding at the DNS layer has the advantage of being easy to implement. -- Christian Huitema
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
