On Mon, Feb 29, 2016 at 4:40 PM joel jaeggli <[email protected]> wrote:
> On 2/29/16 1:34 PM, Shane Kerr wrote: > > Joel, > > > > At 2016-02-29 11:55:27 -0800 > > "Joel Jaeggli" <[email protected]> wrote: > >> > >> This is just something I want to discuss, it's not an objection... > >> > >> At this point we say: > >> > >> Implementations therefore > >> SHOULD avoid using this option if the DNS transport is not encrypted. > >> > >> If you did allow this on unencrypted dns transport this seems like it > >> serves as a utility function for DNS amplification. > >> > >> Wouldn't it be better to say MUST NOT? > >> > >> e.g. this is exclusively for use with TLS / DTLS supporting sessions? > > > > If the concern is amplification, then this is independent of > > encryption. Unencrypted TCP or even DNS cookies should address the > > concern, the same as they do for any large response. > > > > In the interests of simplicity I think your suggestion of making it a > > MUST NOT makes sense though. Perhaps a sentence explaining the > > motivation for such a strong recommendation is beneficial in that case. > > > > Something like: > > > > The use of the EDNS(0) Padding provides only a benefit when DNS > > packets are not transported in clear text. Further, it is possible > > EDNS(0) Padding may make DNS amplification attacks easier. > > Implementations therefore MUST NOT use this option if the DNS > > transport is not encrypted. > > > > Personally I would be happy if the definition of "DNS transport" > > remains vague in the hopes of covering everything. ;) > > I like this proposal just fine, if we're not violating the assumptions > of any of the participants... > <nh> <aol> Me too! </aol> </nh> W P.S: yes, that *was* fun! > > thanks > joel > > > Cheers, > > > > -- > > Shane > > > > >
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
