Re: [dns-privacy] Joel Jaeggli's Discuss on draft-ietf-dprive-edns0-padding-02: (with DISCUSS)

[Warren Kumari <[e-mail]>]

On Mon, Feb 29, 2016 at 4:40 PM joel jaeggli <[e-mail]> wrote:

> On 2/29/16 1:34 PM, Shane Kerr wrote:
> > Joel,
> >
> > At 2016-02-29 11:55:27 -0800
> > "Joel Jaeggli" <[e-mail]> 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
> >
>
>
>