Re: [dns-privacy] [Step 2] More discussion needed: state your opinion

Stephane, At 2016-12-13 16:41:33 +0100 Stephane Bortzmeyer wrote: > On Tue, Dec 13, 2016 at 03:46:25PM +0100, > Shane Kerr wrote > a message of 120 lines which said: > > > I think that TLS may be more painful in the resolver-to-auth case, > >

Re: [dns-privacy] Stephen Farrell's Discuss on draft-ietf-dprive-dnsodtls-13: (with DISCUSS and COMMENT)

On Wed, Dec 14, 2016 at 07:43:28AM +, Stephen Farrell wrote a message of 317 lines which said: > > Yes, will add the above text to a new Section (named "Document > > Status") > > Great. I think it is not really necessary, the status Experimental of

Re: [dns-privacy] [Step 2] More discussion needed: state your opinion

On Wed, Dec 14, 2016 at 10:21:13AM +0100, Shane Kerr wrote a message of 90 lines which said: > > Given that a fallback to TCP/TLS is likely needed even if the > > right answer is QUIC, and given that however the WG decide to > > address server authentication and

Re: [dns-privacy] [Step 2] More discussion needed: state your opinion

On Tue, Dec 13, 2016 at 11:16:08AM -0800, Paul Hoffman wrote a message of 60 lines which said: > If what we invent has better characteristics than DTLS or TLS, that > means that the TLS WG failed to find something that we could. That > seems *incredibly* unlikely, given

Re: [dns-privacy] [Step 2] More discussion needed: state your opinion

John, At 2016-12-13 10:01:51 -0800 John Heidemann wrote: > >IIRC the idea of using IPsec was also discussed somewhere. IIRC, IPsec > >may have problems traversing NAT. It is also usually implemented by the > >kernel, which may cause deployment issues. I *want* IPsec to be an >

Re: [dns-privacy] [Step 2] More discussion needed: state your opinion

Stephane, At 2016-12-14 10:46:16 +0100 Stephane Bortzmeyer wrote: > On Wed, Dec 14, 2016 at 10:21:13AM +0100, > Shane Kerr wrote > a message of 90 lines which said: > > > > Given that a fallback to TCP/TLS is likely needed even if the > > >

Re: [dns-privacy] Stephen Farrell's Discuss on draft-ietf-dprive-dnsodtls-13: (with DISCUSS and COMMENT)

> -Original Message- > From: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie] > Sent: Wednesday, December 14, 2016 1:13 PM > To: Tirumaleswar Reddy (tireddy) ; The IESG > > Cc: tjw.i...@gmail.com; dns-privacy@ietf.org; draft-ietf-dprive- >

Re: [dns-privacy] [Step 2] More discussion needed: state your opinion

On Wed, Dec 14, 2016 at 12:37:39PM +0100, Shane Kerr wrote a message of 65 lines which said: > If only there was a way to publish information about a server's > preferences There is one: DANE (at least to express that you support - or not - TLS and DTLS). For

Re: [dns-privacy] Stephen Farrell's Discuss on draft-ietf-dprive-dnsodtls-13: (with DISCUSS and COMMENT)

Our mails overlapped and contradicted one another:-) Might be better to let chair/shepherd figure out next step? In the meantime though one thing below. On 14/12/16 14:00, Stephane Bortzmeyer wrote: > On Wed, Dec 14, 2016 at 01:50:58PM +, > Tirumaleswar Reddy (tireddy)

Re: [dns-privacy] [Step 2] More discussion needed: state your opinion

On Wed, 14 Dec 2016 12:40:25 +0100, Shane Kerr wrote: >John, > >At 2016-12-13 10:01:51 -0800 >John Heidemann wrote: > >> >IIRC the idea of using IPsec was also discussed somewhere. IIRC, IPsec >> >may have problems traversing NAT. It is also usually implemented by the >> >kernel,

Re: [dns-privacy] [Step 2] More discussion needed: state your opinion

Paul, At 2016-12-14 07:24:44 -0800 "Paul Hoffman" wrote: > > 2) Which authentication(s) to use? > >>> > >>> I really like the CGA approach, but realistically I don't think that > >>> would be accepted. If we think that it would be, then I'm all for > >>> it. >

[dns-privacy] Ben Campbell's No Objection on draft-ietf-dprive-dnsodtls-13: (with COMMENT)

Ben Campbell has entered the following ballot position for draft-ietf-dprive-dnsodtls-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to

[dns-privacy] Ben Campbell's No Objection on draft-ietf-dprive-dnsodtls-13: (with COMMENT)

Ben Campbell has entered the following ballot position for draft-ietf-dprive-dnsodtls-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to

Re: [dns-privacy] Ben Campbell's No Objection on draft-ietf-dprive-dnsodtls-13: (with COMMENT)

Hi Ben, Thanks for the review. Please see inline > -Original Message- > From: Ben Campbell [mailto:b...@nostrum.com] > Sent: Thursday, December 15, 2016 2:56 AM > To: The IESG > Cc: draft-ietf-dprive-dnsod...@ietf.org; Tim Wicinski ; >

Re: [dns-privacy] Stephen Farrell's Discuss on draft-ietf-dprive-dnsodtls-13: (with DISCUSS and COMMENT)

> -Original Message- > From: dns-privacy [mailto:dns-privacy-boun...@ietf.org] On Behalf Of > Stephen Farrell > Sent: Wednesday, December 14, 2016 7:36 PM > To: Stephane Bortzmeyer ; Tirumaleswar Reddy (tireddy) > > Cc: tjw.i...@gmail.com;

Re: [dns-privacy] Stephen Farrell's Discuss on draft-ietf-dprive-dnsodtls-13: (with DISCUSS and COMMENT)

Hi Stephen, I missed responding to following comment: > But 0RTT is replayable, which iirc is particularly dangerous > for foo/DTLS/UDP with anycast and if the attacker can see > the upstream queries from an anycast instance with an empty > cachce at which the attacker has targetted a replayed

Re: [dns-privacy] [Step 2] More discussion needed: state your opinion

On 14 Dec 2016, at 3:34, Shane Kerr wrote: IPsec seems desirable because somehow it seems better to be able to layer on top of security at the lowest level possible? Layer 3 instead of layer 4? Although I guess the only extra information we would be exposing with TLS or DTLS would be the port