Re: [dns-privacy] [Technical Errata Reported] RFC9539 (7832)

Erratum 7832 in RFC 9539 is correct and should be marked as Verified. The "damping" parameter should indeed be characterized by the specific encrypted transport it is associated with. A recursive resolver that implements both DoT and DoQ may perfer to use different `damping` parameters for each

Re: [dns-privacy] [Technical Errata Reported] RFC9539 (7831)

Erratum 7831 in RFC 9539 is correct and should be marked as Verified. The "persistence" parameter should indeed be characterized by the specific encrypted transport it is associated with. A recursive resolver that implements both DoT and DoQ may perfer to use different `persistence` parameters

Re: [dns-privacy] [art] [Ext] Artart last call review of draft-ietf-dprive-unilateral-probing-12

On Thu 2023-09-07 19:38:01 -0700, Rob Sayre wrote: > On Thu, Sep 7, 2023 at 7:15 PM Paul Hoffman wrote: > >> On Sep 7, 2023, at 6:58 PM, Bron Gondwana wrote: >> >> Are you proposing a shorter value for "damping", or a note saying "1 >> day is just the suggested value, you might choose a shorter

Re: [dns-privacy] [Ext] Restarting the discussion of draft-ietf-dprive-unilateral-probing

Thanks for addressing these suggestions from Puneet, Paul. I'm not so sure about this text: On Mon 2022-09-26 22:32:32 +, Paul Hoffman wrote: > Puneet wrote: > >> Generally any NS IP with working encryption should be preferred over >> Do53. > >All resolvers currently keep NS sets and, in

Re: [dns-privacy] I-D Action: draft-ietf-dprive-unilateral-probing-00.txt

Hi Christian-- On Mon 2022-04-11 15:21:26 -0700, Christian Huitema wrote: > True. But this is easy to spoof. right, but it's even easier to spoof an ICMP Port Unreachable, which will undoubtably have the same effect on an opportunistic recursive resolver. > That could work. It would be similar

Re: [dns-privacy] I-D Action: draft-ietf-dprive-unilateral-probing-00.txt

On Sun 2022-04-10 11:57:40 -0700, Christian Huitema wrote: > But Sara has a point, we should give servers a way to control the > deployment. Authoritative servers do have a way to control deployment: they can simply refuse connections on encrypted transport. Rather than refusing arbitrary

Re: [dns-privacy] I-D Action: draft-ietf-dprive-unilateral-probing-00.txt

On Sun 2022-04-10 19:23:21 +0300, Ilari Liusvaara wrote: > Perhaps there could be separate ALPNs for recursive and authoritative > DNS service, with no distinction if authoritative service is > opportunistic or not? What would be the advantage of that distinction? would it be actionable by

Re: [dns-privacy] I-D Action: draft-ietf-dprive-unilateral-probing-00.txt

Hi Sara-- Thanks for this thoughtful and detailed review! I'm trying to do it justice, but i haven't gotten through it all yet. It's triggered a bunch of changes in the editor's copy, but I've also focused on the easy stuff first because i'm lazy :P If anyone wants to offer concrete

Re: [dns-privacy] review of dprive-unilateral-probing

Hi Alex-- thanks for this thoughtful review! I've adopted most of the changes you highlighted (until we submit a new draft to the datatracker, they can be seen in the editor's draft https://dkg.gitlab.io/dprive-unilateral-probing/), but wanted to note a few of them that I didn't fully

Re: [dns-privacy] Measurement & Padding Policy document

On Mon 2022-04-04 11:10:00 +0100, Sara Dickinson wrote: >> On 25 Mar 2022, at 07:46, Alexander Mayrhofer >> wrote: >> Daniel, do you still have the paper from the link mentioned above? > > (The paper does not seem to be available but for reference a set of slides > presented on this work at

Re: [dns-privacy] please adopt draft-dkgjsal-dprive-unilateral-probing as a WG work item Re: New Version Notification for draft-dkgjsal-dprive-unilateral-probing-02.txt

Hi Peter, DPRIVE folks-- On Thu 2022-02-03 11:03:35 +0100, Peter van Dijk wrote: > Speaking only for myself: some of the parts still seem too prescriptive > to me (but I know I haven't been clear on what parts!). Examples: 4.3.1 > seems too focused on some specific load balancer implementations,

Re: [dns-privacy] New Version Notification for draft-dkgjsal-dprive-unilateral-probing-02.txt

Hi folks, just a note explaining what's changed in the unilateral-probing draft: On Wed 2022-01-26 08:28:34 -0800, internet-dra...@ietf.org wrote: > A new version of I-D, draft-dkgjsal-dprive-unilateral-probing-02.txt > has been successfully submitted by Joey Salazar and posted to the > IETF

Re: [dns-privacy] Tsvart last call review of draft-ietf-dprive-dnsoquic-08

On Thu 2022-01-27 13:17:39 +, Sara Dickinson wrote: > I’ve had a first pass at a PR making RFC8467 normative here: > https://github.com/huitema/dnsoquic/pull/143 Modulo a few minor editorial nits (which i've noted on this PR), i support this change as well. Padding defenses are simple,

Re: [dns-privacy] Will unilateral-probing "poison the well"?

change to address it. Joey and I are trying to push out a draft -02 soon, and it should be included in that revision. --dkg From 0e05878a7814100a994e38515a33f3dc280b0354 Mon Sep 17 00:00:00 2001 From: Daniel Kahn Gillmor Date: Tue, 25 Jan 2022 11:08:11 -0500 Subject: [PATCH] Clarify th

Re: [dns-privacy] Fwd: New Version Notification for draft-dkgjsal-dprive-unilateral-probing-01.txt

On Thu 2021-12-16 10:37:53 -0800, Ben Schwartz wrote: > In my view, a correct implementation here would simply provide the TLS > stack with an IP address and no validation identity, so there is no > way for the TLS stack to retrieve an ECHConfig. That would be a reasonable implementation, for

Re: [dns-privacy] Fwd: New Version Notification for draft-dkgjsal-dprive-unilateral-probing-01.txt

Hi Ben-- On Mon 2021-12-13 08:34:22 -0800, Ben Schwartz wrote: > The terminology section says > >* "unilateral" means capable of opportunistic probing deployment > without external coordination with any of the other parties > > To my eye, that excludes any way of delivering ECHConfigs,

Re: [dns-privacy] Will unilateral-probing "poison the well"?

On Fri 2021-12-10 20:11:59 -0500, Robert Evans wrote: > This should ideally be replaced with "resolvers discovering TLS support > solely via unilateral probing MUST NOT perform ANY authentication or > validation whatsoever on the TLS certificate(s) presented by the > authoritative name server".

[dns-privacy] Will unilateral-probing "poison the well"?

One of the concerns raised at IETF 112 about draft-dkgjsal-dprive-unilateral probing was that unilateral probing by recrusive resolvers might "poison the well" and discourage authoritative servers from deploying encrypted transport. For example, in jabber, Erik Nygren commented: "TOFU has a big

Re: [dns-privacy] Signaling with TLSA records

On Thu 2021-12-09 19:17:53 -0500, Robert Evans wrote: > Resolvers can probe for these records today as a signal for > fully-authenticated ADoT support and fallback to opportunistic TLS via > unilateral probing or unencrypted transport when not found. (This turns out > to be exactly the same

Re: [dns-privacy] Fwd: New Version Notification for draft-dkgjsal-dprive-unilateral-probing-01.txt

Hi Ben-- Thanks for the prompt review and feedback! On Thu 2021-12-09 16:14:36 -0500, Ben Schwartz wrote: > The SNI guidance looks good to me. > > I find it confusing to mention ECH in this draft. ECH can never be used > with this specification, because there is (by definition) no SVCB record

Re: [dns-privacy] Comments on draft-dkgjsal-dprive-unilateral-probing

On Mon 2021-11-22 11:27:50 -0500, Ben Schwartz wrote: > On Fri, Nov 19, 2021 at 6:48 PM Daniel Kahn Gillmor > wrote: > ... > >> To avoid incurring additional minor timeouts for such a recursive >> resolver, the pool operator should either: >> > > Nit: Th

Re: [dns-privacy] Comments on draft-dkgjsal-dprive-unilateral-probing

On Thu 2021-11-11 16:16:24 +, Jim Reid wrote: >> On 11 Nov 2021, at 15:28, Christian Huitema wrote: >> >> It is not uncommon to see upgrades being rolled out at different times to >> different servers in the farm. Opportunistic strategies and probing >> strategies have to deal with that. >

Re: [dns-privacy] Why MUST EDNS(0) Padding option only appear once?

On Mon 2021-11-01 18:56:59 +0100, Vladimír Čunát wrote: > I don't think it's possible to leak more privacy by doing that. Assuming > an encrypted channel, only the overall length of the DNS message should > matter. This is my intuition as well, though i haven't done any deep analysis on it. >

[dns-privacy] Why MUST EDNS(0) Padding option only appear once?

Hi DPRIVE folks-- RFC 7830 (The EDNS(0) Padding Option) says: > The "Padding" option MUST occur at most, once per OPT meta-RR (and > hence, at most once per message). Over on https://github.com/PowerDNS/pdns/issues/10884 there's some discussion of a case where it would be technically

[dns-privacy] scope of authoritative signalling [Was: Re: [Ext] Intermediate proposal (what I was saying at the mic)]

On Thu 2021-08-05 11:06:12 -0700, Brian Dickson wrote: >- SVCB in the name server name's zone is where the signalling belongs >(on what transports are supported, per NS name, as well as authenticated or >not, etc) I'm agnostic about the mechanism specifically, but i am curious as to

Re: [dns-privacy] Alternative signalling propsals

On Fri 2018-12-14 22:58:09 +, Stephen Farrell wrote: > I'm probably exposing my lack of DNS-clue, but I wonder if it > is/isn't possible to embed a "like/want/offer privacy" signal > in the DNS protocol, rather than in the data carried by the > protocol? (Regardless of whether the latter

Re: [dns-privacy] Alternative signalling propsals

On Fri 2018-12-14 17:43:44 -0500, Paul Wouters wrote: > We fixed that with tls-dnssec-chain :P > > I'll leave it up to others to wonder why and how this did not move > forward, and is now going via ISE. > > Sorry for the side-track of this discussion. This isn't sidetrack at all, it was one of

Re: [dns-privacy] Issues with encoding keys in nameserver DNS names

On Fri 2018-12-14 19:12:41 +0100, A. Schulze wrote: > Am 11.12.18 um 06:38 schrieb Mukund Sivaraman: >> There was some discussion in last night's meeting about encoding keys in >> the DNS name of a nameserver, similar to DNSCurve. There are at least >> some issues with it: >> 1...4 > > 5. Encoding

Re: [dns-privacy] Use of separate caches for plain and secure transports

On Fri 2018-12-14 11:47:58 -0800, Christopher Wood wrote: > On Dec 14, 2018, 10:47 AM -0800, Wes Hardaker , wrote: >> [And, no, we shouldn't go down the road of "privacy requires you disable >> the cache"] > > Would you mind elaborating on this comment? As you observe, caches are > harmful to

Re: [dns-privacy] Issues with encoding keys in nameserver DNS names

On Fri 2018-12-14 03:30:29 +0530, Mukund Sivaraman wrote: > I don't think this way. :) I think it will not support every RFC 1035 > DNS name, but only a subset of it. It should work for every valid name, > because they are valid names and some application may want it. Why > settle for hacks when

Re: [dns-privacy] Issues with encoding keys in nameserver DNS names

Hi Mukund-- thanks for your prompt followup! On Fri 2018-12-14 02:22:12 +0530, Mukund Sivaraman wrote: > The trailing '='s are part of the base32 encoding. > > [muks@naina ~]$ echo -n > "MFRGGZDFMZTWQ2LKNNWG23TPOBYXE43UOV3HO6DZPI3TQOJQGEZA" | base32 -d >

Re: [dns-privacy] Use of separate caches for plain and secure transports

Hi Mukund-- On Tue 2018-12-11 11:13:39 +0530, Mukund Sivaraman wrote: > During last night's meeting, there was talk about use of a split-cache - > one with answers learned from plain transports and another with answers > learned via secure transports. I think i was the one that mentioned that

Re: [dns-privacy] Issues with encoding keys in nameserver DNS names

On Tue 2018-12-11 11:08:06 +0530, Mukund Sivaraman wrote: > 1. The RDATA of an NS record has to be a hostname, so it would limit the > amount of data that can be encoded within the NSDNAME. As an example, > base32 encoding is not possible. why is base32 encoding not possible for a hostname? just

Re: [dns-privacy] Opsdir last call review of draft-ietf-dprive-padding-policy-04

On Thu 2018-04-12 10:11:34 +0200, Alexander Mayrhofer wrote: > I think it totally depends on the viewpoint (operational vs. > "research-oriented"). Please share your preferred option - keep with > CURRENT or restructure for NEW. I prefer NEW (i like having the recommendation up front) but would

Re: [dns-privacy] Oblivious DNS

On Mon 2018-04-09 13:20:28 -0400, Daniel Kahn Gillmor wrote: > People on this list might be interested in the recent "Oblivious DNS" > work from Annie Edmundson, Paul Schmitt, and Nick Feamster gah, i left off Jennifer Rexford from the list of researchers -- no sli

Re: [dns-privacy] Last Call:

On Wed 2018-03-21 04:11:40 -0700, DraftTracker Mail System wrote: > Last Call Request has been submitted for > > > https://datatracker.ietf.org/doc/draft-ietf-dprive-padding-policy/ Yay, i'm glad to see this reach LC! one NIT to deal with before publication: in §4.3: Disadvantage: This

Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement

On Tue 2017-11-14 12:04:19 +0100, Sara Dickinson wrote: > This draft is now ready to progress once a -12 version is available. I > just want to circle back round to summarise the fact that the only > proposed difference that will be in the -12 version compared to -11 is > the following (in

Re: [dns-privacy] Why is draft-ietf-dprive-dtls-and-tls-profiles still blocked?

On Fri 2017-10-27 15:55:10 +0200, Stephane Bortzmeyer wrote: > The datatracker tells us that draft-ietf-dprive-dtls-and-tls-profiles > has a DISCUSS "This needs to be updated to indicate that the client > MUST NOT offer 7250 unless it has a preconfigured SPKI, otherwise > you're going to have

Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement

On Mon 2017-10-30 13:11:41 +, Sara Dickinson wrote: > I really do think a description there of the trade-offs of DNSSEC > validation are warranted I agree that a discussion of the tradeoffs involved in DNSSEC validation of the opportunistic meta-query is warranted. I just come to a different

Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement

On Mon 2017-10-30 07:19:36 -0400, Paul Wouters wrote: > Just to be clear. DNSSEC provides authentication of data. TLS provides > privacy of data. Both are needed so I am against this proposed change > to remove DNSSEC validation as a requirement. DNSSEC is part of the > core DNS. It's not a

Re: [dns-privacy] dprive (bar) BoF?

On Mon 2017-10-23 06:14:36 +, Alexander Mayrhofer wrote: > since we're not scheduled for a session in Singapore - would anybody > be interested in meeting up for a bar BoF during the meeting? eg. a > lunch break? I'd be interested. --dkg ___

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener

Thanks to everyone for their useful feedback and commentary. I've just uploaded draft-dkg-dprive-demux-dns-http-03, which attempts to include the insights that people have shared here. Most significantly, it drastically tightens the scope of the draft by focusing on HTTP/1.x only and explicitly

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02]

On Thu 2017-05-04 11:11:59 +1000, Martin Thomson wrote: > On 4 May 2017 at 10:43, Daniel Kahn Gillmor <d...@fifthhorseman.net> wrote: >> I address this in the draft section "Why not ALPN?" -- if anyone thinks >> the text there could be improved, i'd be happy

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02]

On Wed 2017-05-03 20:49:22 -0400, Patrick McManus wrote: > the http/1 share of https:// traffic is dwindling fast. Its down to about > 1/3 of https for me. So if you're looking to hide in a big pool, that's a > shrinking segment. 1/3 of https traffic is still huge collateral damage to inflict, if

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02]

On Wed 2017-05-03 20:37:21 -0400, Patrick McManus wrote: >> is the draft you and Paul are working on different than >> ietf-dnsop-dns-wireformat-http ? Can they be reconciled? > > its a superset of that -more aligned with HTTP than that draft, but it can > also carry wireformat. > > your work

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02]

On Thu 2017-05-04 10:21:20 +1000, Martin Thomson wrote: > On 4 May 2017 at 10:14, Mike Bishop wrote: >> It's ALPN. At first blush, I would pick a different ALPN token for >> h2+DNS and define it as a new, derivative protocol. > > For DKG to realize his goal, every

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02]

Hi Alex-- On Wed 2017-05-03 17:34:47 -0600, Alex Rousskov wrote: > On 05/03/2017 05:17 PM, Daniel Kahn Gillmor wrote: >> The idea of the demuxing stage is that a server that opts into this would >> put the demuxing *before* the HTTP/1 server implementation gets access >> t

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02]

On Wed 2017-05-03 15:13:43 -0400, Patrick McManus wrote: > I forgot to mention another potential challenge with the demux approach - > h2 is not client send first.. typically both sides send SETTINGS > simultaneously.. and its important to the server not to hold those back > .5RTT as it can

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02]

On Wed 2017-05-03 12:35:52 -0700, Roy T. Fielding wrote: > I see no reason to suggest that spraying DNS on an HTTP connection would > be interoperable. HTTP/1.x has a tradition (good or bad) of allowing > robust parsing of bad messages, which means no analysis of DNS uniqueness > can guard

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02]

Hi Patrick-- On Wed 2017-05-03 14:57:24 -0400, Patrick McManus wrote: > My initial response is that legacy HTTP/1 implementations will sink you by > scanning for stuff that looks like HTTP in your stream - even if the > leading bytes don't match the production those RFCs required (and HTTP/1.0 >

[dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02]

Hi HTTP folks-- I've just pushed a revision to a recent individual submission about a technique for hiding DNS traffic that makes use of HTTP: https://datatracker.ietf.org/doc/draft-dkg-dprive-demux-dns-http/ It describes how a TLS server can offer both HTTPS and DNS-over-TLS on the same

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt]

Hi Joe-- Thanks for the feedback! On Thu 2017-04-27 10:13:54 -0700, Joe Touch wrote: > Speaking as an IANA ports team reviewer: > > IMO this document needs to UPDATE the HTTPS specification. The draft isn't strictly about HTTPS, though that context is certainly a prime motivating factor. It's

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-00.txt]

Hi Jan-- On Wed 2017-04-26 11:05:33 +0200, Jan Včelák wrote: > thank you for writing this down. The draft is great. And it's awesome > that it's accompanied with an actual running code. thanks! and thanks for the quick review :) > A have just a few notes after reading the draft for the first

Re: [dns-privacy] DNS over DTLS

On Fri 2016-12-02 01:22:40 -0500, Tariq Saraj wrote: > Thanks for your detailed reply, the point I am trying to highlight is the > changes in TCP for DNS which is "TCP out of order packet delivery, i.e. the > OOOP". I think you're referring to "out of order processing" for DNS requests by a

Re: [dns-privacy] Call for Adoption: draft-mayrhofer-dprive-padding-profile

On Fri 2016-11-18 13:42:08 +0900, Warren Kumari wrote: > This starts a Call for Adoption for draft-mayrhofer-dprive-padding-profile. [...] > Please also indicate if you are willing to contribute text, review, etc. As i said in the meeting Friday, I support WG adoption of this

Re: [dns-privacy] ENDS0 Padding Profile: Rough first draft

Thanks for https://tools.ietf.org/html/draft-mayrhofer-dprive-padding-profile-00, Alex! On Tue 2016-11-01 07:09:28 -0400, Hugo Connery wrote: > The list of strategies looks great.  Perhaps you could mention > the "pad the message to the maximum possible message length" > explicitly as a sub-case

Re: [dns-privacy] DPRIVE client with captive portal

On Mon 2016-08-08 21:41:20 -0400, Dan Wing wrote: > Thanks. I searched that document, but my search terms were inadequate to > find the necessary text. patches welcome are for changes to draft-ietf-dprive-dtls-and-tls-profiles that would have matched your search terms :) --dkg

Re: [dns-privacy] DNS + 0-RTT

On Wed 2016-04-06 11:08:55 -0300, Colm MacCárthaigh wrote: > On Wed, Apr 6, 2016 at 6:03 AM, Daniel Kahn Gillmor <d...@fifthhorseman.net> > wrote: > > > forward secrecy > > --- > > > > IIUC for (b), the failing forward secrecy window is cons

Re: [dns-privacy] DNS + 0-RTT

On Tue 2016-04-05 14:07:27 -0300, Tim Wicinski wrote: > As many of you are aware, with the TLS1.3 spec, there is some security > concerns around DNS+TLS1.3 0-RTT. dkg put together some threat models > and instead of forwarding some long thread, I figure I would put this >

Re: [dns-privacy] I-D Action: draft-ietf-dprive-edns0-padding-02.txt

On Mon 2016-01-25 12:26:59 -0500, Alex Mayrhofer wrote: > This version addresses comments received since the publication of the > last draft version, including the WGLC comments. > > The only bigger change is that (in line with the comments received) > I've

Re: [dns-privacy] 2nd WGLC for draft-ietf-dprive-dns-over-tls-02.

On Wed 2015-12-09 18:12:41 -0500, Christian Huitema wrote: > However, I am a bit skeptical of some of the requirement to provide > "two or more pins" for each server. This assumes a specific model of > out-of-band provisioning, and it also assumes that servers always have >

Re: [dns-privacy] I-D Action: draft-ietf-dprive-edns0-padding-01.txt

tl;dr: It's not this simple, and we should not try to use this draft to specify padding policy. below are some pointers about why it's not so simple. If you want to make a separate draft about padding policy, i'm happy to have that discussion there, but please don't hold this mechanism draft up

Re: [dns-privacy] I-D Action: draft-ietf-dprive-edns0-padding-01.txt

On Tue 2015-11-24 07:19:47 -0500, Alex Mayrhofer wrote: > I've submitted a new version of the EDNS0 padding draft. The only major > change is that it does now allow for non-0x00 padding octets. I think > this was the (rough) consensus of the respective WG list discussion. Thanks Alex! a

Re: [dns-privacy] Non-zero padding (was EDNS0 padding with non-0 MUST respond with FORMERR?)

On Wed 2015-11-18 15:45:51 -0500, Stephane Bortzmeyer wrote: > On Wed, Nov 18, 2015 at 11:30:53AM +1300, > Alex Mayrhofer wrote > a message of 207 lines which said: > >> - I think we should stick with requiring 0x00 padding (I am avoiding >> the term 'payload'

Re: [dns-privacy] Non-zero padding (was EDNS0 padding with non-0 MUST respond with FORMERR?)

On Mon 2015-11-16 11:32:57 -0500, Shane Kerr wrote: > Probably a paragraph saying "turn off TLS compression" is a better > approach than trying to figure out how to defeat the compression? yes, please. The consensus of the TLS WG is that compression simply does not belong at the TLS layer, that

Re: [dns-privacy] Non-zero padding (was EDNS0 padding with non-0 MUST respond with FORMERR?)

On Mon 2015-11-16 16:20:21 -0500, Stephen Farrell wrote: > I agree that that is clearly the opinion in the TLS WG today. I'm > less sure I agree that's correct - my fear is that it's being driven > maybe too much by browsers and the web, where the conclusion is > valid. Well, certainly for a

Re: [dns-privacy] Call for Adoption: draft-mayrhofer-edns0-padding

On Tue 2015-11-03 21:54:27 +0900, Tim Wicinski wrote: > During the meeting on Monday, it was obvious the Working Group wanted to > make this an official EDNS option. We reached out to the author and > while he is traveling for an extended period of time, he is happy to > work on edits (with a

Re: [dns-privacy] Direction of draft-mayrhofer-edns0-padding

Hi folks-- On Wed 2015-07-29 09:41:10 -0400, Paul Hoffman wrote: On 29 Jul 2015, at 5:28, Alexander Mayrhofer wrote: I'm working through my notes from the DPRIVE session regarding the EDNS0 Padding option. My takeaway was as follows: - Generally, this seems to be a reasonable idea That

Re: [dns-privacy] draft-mayrhofer-edns0-padding

On Thu 2015-07-23 18:50:14 +0200, Alexander Mayrhofer wrote: I had a discussion with Daniel Khan Gillmor today, and we talked about his proposal to specify a padding option in TLS so that message-size based correlation attacks on encrypted DNS packets could be prevented. We continued

Re: [dns-privacy] Call For Adoption: draft-wing-dprive-dnsodtls

On Wed 2015-05-20 10:03:27 -0400, Tim Wicinski wrote: During the previous Call for Adoption a number of participants expressed interest in adopting this work. WG members felt it needed some improvements, but thought it had potential. The authors addressed the issues and feel it meets what

Re: [dns-privacy] I-D Action: draft-ietf-dprive-start-tls-for-dns-00.txt

On Tue 2015-05-12 14:40:12 -0400, Simon Josefsson wrote: What I'm basically wondering, and advocating, is if perhaps one method would be sufficient. This would reduce complexity on the protocol and implementation level. I agree that a single mechanism would be cleaner, but perhaps the two

[dns-privacy] draft-ietf-dprive-start-tls-for-dns-00 comments

Hi all-- Thanks for the start-tls-for-dns draft! i'm happy to see it. I have a few pieces of feedback below... -- A structural nit: the draft has no Table of Contents -- can you update whatever drafting toolchain you're using to include one? they're helpful for people trying to navigate

Re: [dns-privacy] Starting call for adoptions for the 3 documents

On Thu 2015-04-09 10:36:17 -0400, Phillip Hallam-Baker wrote: As I see it, there are two sub-problems: 1) How does a client discover and establish a binding to a DPRIV service? 2) What transport/sessions(s) are supported for queries? Before answering either, I think it is pretty clear that

Re: [dns-privacy] (re-)identifying from sets of queries (was Re: Start of WGLC for draft-ietf-dprive-problem-statement - please review.)

On Fri 2015-02-27 07:28:57 -0500, Stephane Bortzmeyer bortzme...@nic.fr wrote: On Fri, Feb 27, 2015 at 11:53:27AM +, Stephen Farrell stephen.farr...@cs.tcd.ie wrote a message of 55 lines which said: How's about adding something like: 2.6 Re-identification OK for me, thanks for the

Re: [dns-privacy] Moving things along...

On Thu 2015-02-26 08:57:19 -0500, Phillip Hallam-Baker wrote: On Thu, Feb 26, 2015 at 6:35 AM, Neil Cook neil.c...@noware.co.uk wrote: Whilst I don’t deny that ISPs are using middelboxes for things like advertising etc, it should also be pointed out that many ISPs are concerned about security,