Discussion:
Still interested in recursive-to-authoritative
(too old to reply)
Paul Hoffman
2018-05-16 20:03:36 UTC
Permalink
While we wait for the charter update, I'd still like to find out who is
interested in pursuing draft-bortzmeyer-dprive-resolver-to-auth.
Personally, I think it is a good start on an important topic, but I
don't hear others supporting it on the list...

--Paul Hoffman
Stephen Farrell
2018-05-16 20:06:05 UTC
Permalink
Post by Paul Hoffman
While we wait for the charter update, I'd still like to find out who is
interested in pursuing draft-bortzmeyer-dprive-resolver-to-auth.
Personally, I think it is a good start on an important topic, but I
don't hear others supporting it on the list...
I do. But I don't implement a recursive or run a large
authoritative. I do run some teeny-weeny authoritative
servers, and would definitely deploy on those whenever
possible.

S.
Post by Paul Hoffman
--Paul Hoffman
_______________________________________________
dns-privacy mailing list
https://www.ietf.org/mailman/listinfo/dns-privacy
Gene Hightower
2018-05-16 20:55:43 UTC
Permalink
[
] I'd still like to find out who is interested in pursuing
draft-bortzmeyer-dprive-resolver-to-auth.
I am.

Of course, I am just some guy; not a mover or shaker in any sense.

I can write C code and would be willing to contribute to any FLOSS
resolvers to support this.
Sara Dickinson
2018-05-23 16:28:14 UTC
Permalink
Post by Gene Hightower
[
] I'd still like to find out who is interested in pursuing
draft-bortzmeyer-dprive-resolver-to-auth.
I am.
Of course, I am just some guy; not a mover or shaker in any sense.
I can write C code and would be willing to contribute to any FLOSS
resolvers to support this.
We did create a basic patch back in 2015 to add TLS to NSD - it can be found here:
https://portal.sinodun.com/stash/projects/TDNS/repos/dns-over-tls_patches/browse

I’ve been meaning to work on porting this to the latest NSD for a while now but if anyone else wants to take a look at this then feel free.

Sara.
A. Schulze
2018-05-23 20:56:40 UTC
Permalink
Post by Sara Dickinson
https://portal.sinodun.com/stash/projects/TDNS/repos/dns-over-tls_patches/browse
I’ve been meaning to work on porting this to the latest NSD for a while now but if anyone else wants to take a look at this then feel free.
Hello Sara,

the attached version work with the latest NSD 4.1.21.
It compiles and nsd run for a very first test here.

But as the patch was manually re-applied diff by diff I'm not sure I've done everything right.
Wouter will have more "context" at the patched code paths. Review is required.

Anyway: thanks for pointing to that work, Sara!

Andreas
Lanlan Pan
2018-05-24 18:12:21 UTC
Permalink
Support, :-)


*”Encryption does not protect against a rogue server that will capture you
requests and use them for evil purposes.It must therefore be combined with
data minimization techniques.“*
Post by Paul Hoffman
While we wait for the charter update, I'd still like to find out who is
interested in pursuing draft-bortzmeyer-dprive-resolver-to-auth.
Personally, I think it is a good start on an important topic, but I
don't hear others supporting it on the list...
--Paul Hoffman
_______________________________________________
dns-privacy mailing list
https://www.ietf.org/mailman/listinfo/dns-privacy
--
臎瀌 Best Regards

朘蓝兰 Pan Lanlan
Sara Dickinson
2018-05-25 15:08:44 UTC
Permalink
BH> What I will ask now is that those who are interested in the current
BH> draft to start providing detailed reviews …
I’ve read the draft again - comments below.
The draft asks whether tls 1.3 should be the minimum version.
It would be better for this document to specify >= 1.2. It will be much
easier in the short term to add 1.2 support to existing machines than 1.3
and that would allow much more real testing during the draft state.
I agree with this. At this stage TLS 1.2 is much more practical and I think just referencing BCP7525 is enough.
The happy eyeballs reference looks to be the right thing to do.
Section 3: I’d like to see a bit more discussion around this proposal:
"A resolver working in opportunistic mode should try ports 53 and 853 in parallel.”

I see the obvious latency win here but the downside with this mode (as currently described) is that it _always_ leaks the query in cleartext so it seems to defeat the point of using TLS. Unless the should (SHOULD?) here is allowing for resolver behaviour where it has some cached knowledge of this authoritative's capabilities and so could choose to probe all addresses over 853 before falling back to 53? If so I think that should be spelled out more clearly.

I’d always seen opportunistic as ‘try for the best but be willing to fallback to the worst case’ which isn’t exactly the same as ‘happy eyeballs’ which I see as try everything in parallel?
If it is a concern that the same authoritative name servers are used
for ordinary DNS and for encrypted DNS,
I don't know that should be, but if so it probably should discuss why
some may find it to be a concern.
Is this related to the monitoring/data retention/privacy policies by the operator? In other words that the concern is they treat all the data as if it were unencrypted….
I think we should discuss whether an EDNS option to signal a successful
authentication or failure really is out of scope, as the draft says.
Interesting yes, but rogue or broken clients could easily send false responses so I’m unsure of how useful this is? What would the specific use case be?


One other comment - in RFC8310 there is discussion of the possible attacks on meta queries (used here to obtain the TLSA records) - it seems the same concerns apply here too and should be mentioned in the Security Considerations?

Regards

Sara.
Ted Hardie
2018-05-25 17:18:30 UTC
Permalink
Post by Sara Dickinson
The happy eyeballs reference looks to be the right thing to do.
"A resolver working in opportunistic mode should try ports 53 and 853 in
parallel.”
In addition to the privacy concern that Sara makes below (and with which I
agree), it's actually not what the current specification of Happy Eyballs
says. RFC 8305 says instead:

Once the list of addresses received up to this point has been
constructed, the client will attempt to make connections. In order
to avoid unreasonable network load, connection attempts SHOULD NOT be
made simultaneously.

Presuming we treat the "address" here as a tuple of IP address and port and
give a preference for 853 in the sorting algorithm, you'd end up starting
with it and then going to 53 only after the default delay expired.

I think that's better than concurrent attempts on several fronts.

regards,

Ted
Post by Sara Dickinson
I see the obvious latency win here but the downside with this mode (as
currently described) is that it _always_ leaks the query in cleartext so it
seems to defeat the point of using TLS. Unless the should (SHOULD?) here is
allowing for resolver behaviour where it has some cached knowledge of this
authoritative's capabilities and so could choose to probe all addresses
over 853 before falling back to 53? If so I think that should be spelled
out more clearly.
I’d always seen opportunistic as ‘try for the best but be willing to
fallback to the worst case’ which isn’t exactly the same as ‘happy
eyeballs’ which I see as try everything in parallel?
If it is a concern that the same authoritative name servers are used
for ordinary DNS and for encrypted DNS,
I don't know that should be, but if so it probably should discuss why
some may find it to be a concern.
Is this related to the monitoring/data retention/privacy policies by the
operator? In other words that the concern is they treat all the data as if
it were unencrypted
.
I think we should discuss whether an EDNS option to signal a successful
authentication or failure really is out of scope, as the draft says.
Interesting yes, but rogue or broken clients could easily send false
responses so I’m unsure of how useful this is? What would the specific use
case be?
One other comment - in RFC8310 there is discussion of the possible attacks
on meta queries (used here to obtain the TLSA records) - it seems the same
concerns apply here too and should be mentioned in the Security
Considerations?
Regards
Sara.
_______________________________________________
dns-privacy mailing list
https://www.ietf.org/mailman/listinfo/dns-privacy
James Cloos
2018-05-25 22:13:47 UTC
Permalink
JC>> The happy eyeballs reference looks to be the right thing to do.

SD> Section 3: I’d like to see a bit more discussion around this proposal:
SD> "A resolver working in opportunistic mode should try ports 53 and 853 in parallel.”

SD> I see the obvious latency win here but the downside with this mode (as
SD> currently described) is that it _always_ leaks the query in cleartext
SD> so it seems to defeat the point of using TLS.

I read thru my reply again, and I think this was the only point I didn't
properly consider. But testing shows that a short timeout is required
to ensure that auth's which do not support 853 do not dos resolvers
which try it.

-JimC
--
James Cloos <***@jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6
Loading...