admits that there are tradeoffs. The law (or a typical
organization's policy) does not seem to understand that.
Disclaimer: definitely not speaking for my employer.
--
Bob Harold
On Mon, Oct 27, 2014 at 3:46 AM, Stephane Bortzmeyer bortzme...@nic.fr
wrote:
Good reading about the blind spots
One minor concern:
Page 8, section 4, point 4 Use of a local DNS forwarder allows a
single active DNS-over-TLS connection allows a single active TCP connection
for DNS per client computer.
-- That sentence does not read correctly to me.
--
Bob Harold
On Thu, Oct 22, 2015 at 2:05 PM, Wessels, Duane <dwess...@verisign.com>
wrote:
>
> > On Oct 22, 2015, at 6:59 PM, Bob Harold <rharo...@umich.edu> wrote:
> >
> > The URL is not working for me, and I cannot find a working URL. Is it
> just me?
>
>
> T
asons.
>
> >
> > I think the WG should consider if the current text of saying use 0x00 is
> not good enough,
> > there are 3 options, use:
> > - 0x00
> > - cheap randomness
> > - real randomness source
> >
> > I think the m
.
pg 17, sec 7.4
I am not familiar with the details of IPSEC, but from the text it appears
to hide the port number. But does it hide the destination IP? If not, and
if most DNS resolvers have a separate IP from other services, then
"undetectability" is very low,
;
This sentence does not read well to me:
"TLS False Start [I-D.ietf-tls-falsestart] which reduces round-trips
by allowing the TLS second flight of messages (ChangeCipherSpec) to
also contain the (encrypted) DNS query. "
--
Bob Harold
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
On Thu, Aug 18, 2016 at 1:14 AM, Tirumaleswar Reddy (tireddy) <
tire...@cisco.com> wrote:
> *From:* Bob Harold [mailto:rharo...@umich.edu]
> *Sent:* Wednesday, August 17, 2016 9:13 PM
> *To:* Warren Kumari <war...@kumari.net>
> *Cc:* dns-privacy@ietf.org; draft-ietf-
implementors (based on pending research and
> > analysis).
> >
> > If we really only want one document, then probably it should start with
> > recommendations and then include the review of techniques as an
> > appendix.
>
> I happen to favour this second approach
es"), discusses the
> >implications of each of these options, and provides implementation
> >guidance.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-mayrhofer-dprive-padding-profi
> > le/
queries
are typically much smaller. So an attacker could use small padding to a
server that used "maximum-ish" padding and get amplification. I don't
think we want to pad queries to more than 288?
--
Bob Harold
> Of course, it doesn't defeat
> > anonymizing attacks, it j
ve-bcp-op-01
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-dprive-bcp-op-01
>
>
Minor nits:
5.1.5. Service options
DNS Privacy Threats:
o Unfairly disadvantaging users of the privacy service with respect
to
[RFC7858]) authoritative server by encoding
>
> it as part of its name. The fingerprint can thereafter be used to
>
> validate the certificate received from the DoT server as well as
>
> being able to discover support for DoT on the server.
>
>
6. IANA Considerations
;
6.2. TLS
Not sure that these are the right words. "surveillance" to me implies a
passive watching. Which means:
"passive surveillance" - is redundant, and
"active surveillance" - is a contradiction in terms.
I assume that "active" means sending packets to try to confuse the server
or client, which I would call an "attack" and not "surveillance".
Or am I wrong?
--
Bob Harold
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
lf, bypassing the OS (even though
I dislike this, unless the user has agreed)
- OS supports DoT but cannot reach a DoT server
- various choices, we don't need to discuss this now.
--
Bob Harold
>
>
> My view is that the OS should be taking the most secure DNS route it has
el of
caution/fear/lack-of-backbone (I am sure there are other descriptions
people would prefer).
--
Bob Harold
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
> outage notification by tools or humans.
>
> Paul
>
Thanks to everyone for the info and recommendations. I need to figure out
how to alert on validation failures, and then enable validation.
--
Bob Harold
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
quot;
"RR of this" -> "of this RR"
6.4. IP Based ACL on the Primary
"This is also possible with XoT but it must be noted that as with TCP
the implementation of such and ACL cannot be enforced"
"and ACL" -> "an ACL"
--
Bob Harold
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
n submitted directly on this I-D.
>
>
Looks good to me. One grammar nit:
3.5.1.4.2. DoH Specific Considerations
next to last paragraph
"Some implementations have, in fact, chosen restrict the use of"
change to:
"Some implementations have, in fact, chosen to restrict the use
ttps://tools.ietf.org/html/draft-ietf-dprive-early-data-00
> https://datatracker.ietf.org/doc/html/draft-ietf-dprive-early-data-00
>
>
Looks good to me, one nit:
1. Introduction
"tecniques" -> "techniques"
--
Bob Harold
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
e Trust model
"overtime" > "over time"
7.1.2. Trust Model Bootstrapping
The whole first paragraph is difficult to parse - it does not seem like
complete sentences.
7.2.2. Automated Trust Anchor Check
"to to" > "to"
But the sentence does not seem c
ions available at:
> > https://tools.ietf.org/html/draft-ietf-dprive-bcp-op-13
> > https://datatracker.ietf.org/doc/html/draft-ietf-dprive-bcp-op-13
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-dprive-bcp-op-13
om? I was expecting "doq-00".
5.5. Session Resumption and 0-RTT
Next to last paragraph, "errros" -> "errors"
6.3. Address Validation
The end of the first paragraph "to a factor 3." -> "to a factor of 3."
--
Bob Harold
_
22 matches
Mail list logo
