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

Sent from my iPhone > On Feb 29, 2016, at 16:53, Mark Andrews wrote: > > > If you want warn fuzzies then say MUST NOT otherwise it is just > noise. > > You can't enforce it. Do you throw away clear text packets with > the option in the request / response? Adding it won't

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

On Mon, Feb 29, 2016 at 4:40 PM joel jaeggli wrote: > On 2/29/16 1:34 PM, Shane Kerr wrote: > > Joel, > > > > At 2016-02-29 11:55:27 -0800 > > "Joel Jaeggli" wrote: > >> > >> This is just something I want to discuss, it's not an objection... > >> > >> At this

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

Joel, At 2016-02-29 11:55:27 -0800 "Joel Jaeggli" 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

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

On 29/02/16 21:10, Barry Leiba wrote: > Is there a difference between what it says ("if the DNS transport is > not encrypted") and what you said ("in the clear")? Depends on what one means by DNS transport I guess. I don't recall whether the WG had chatted about that. > Would there be a >

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

>> 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