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 NDSS
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 incorporate
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 suggestions
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 either
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 connect
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 t
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
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 o
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 fo
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 e
On 10/06/2014 08:44 AM, Stephane Bortzmeyer wrote:
> [Keep i...@ietf.org in the loop only if it is substantive comments on
> the WG creation, please]
>
> On Fri, Oct 03, 2014 at 10:38:35AM -0700,
> The IESG wrote
> a message of 68 lines which said:
>
>> The primary focus of this Working Group
On Thu 2014-10-23 08:45:45 -0400, Phillip Hallam-Baker
wrote:
> Which in my view means that the recursive has to be a trusted service and
> the notion of promiscuous recursive resolver use has to be stamped out.
I'm not convinced that your conclusion follows from your premise here,
Phil.
I agr
On Thu 2014-10-23 22:44:19 -0400, Phillip Hallam-Baker wrote:
> On Thu, Oct 23, 2014 at 7:50 PM, Daniel Kahn Gillmor
> wrote:
>
>> On Thu 2014-10-23 08:45:45 -0400, Phillip Hallam-Baker <
>> i...@hallambaker.com> wrote:
>>
>> > Which in my view means that
On Fri 2015-02-27 07:28:57 -0500, Stephane Bortzmeyer wrote:
> On Fri, Feb 27, 2015 at 11:53:27AM +,
> Stephen Farrell wrote
> a message of 55 lines which said:
>
>> How's about adding something like:
>>
>> 2.6 Re-identification
>
> OK for me, thanks for the text. Any advice from the WG?
On Thu 2015-02-26 08:57:19 -0500, Phillip Hallam-Baker wrote:
> On Thu, Feb 26, 2015 at 6:35 AM, Neil Cook 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, and may be usin
On Sat 2015-03-07 18:09:27 -0800, Watson Ladd wrote:
> On Sat, Mar 7, 2015 at 10:43 AM, Phillip Hallam-Baker
> wrote:
>> One hole that does raise privacy issues is Server Name Identification. If
>> you have 200 web sites on a server, you don't want to have to burn an IPv4
>> address for each one.
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 t
[ rearranging for chronological sanity ]
On Tue 2015-04-14 00:02:24 -0400, Zhiwei Yan wrote:
> [ Paul Wouters wrote: ]
>> On Tue, 14 Apr 2015, Zhiwei Yan wrote:
>>> Then why not consider the DHCP?
>>> DHCP can support client authentication and can be used to configure the RS
>>> key on the authen
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 t
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
m
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 wh
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 discu
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
>
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 s
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 i
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 syste
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' here for a reason). This would pre
On Thu 2015-11-19 05:07:42 -0500, Warren Kumari wrote:
> I also think (but am not sure) that the sender should pad with random
> stuff[0] to prevent issues with "accidental" compression. Yes, we can
> say that compression MUST be disabled, but will all implementations
> follow this? The way many pe
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 couple
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 f
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
> a second key to fallba
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 generalized the text about Non-0x00 pa
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
> out there and let Mr.
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
> wrote:
>
> > forward secrecy
> > ---
> >
> > IIUC for (b), the failing forward secrecy window is constrained by the
> >
On Mon 2016-04-11 08:52:44 -0400, Shane Kerr wrote:
> People who know more can correct me if I'm wrong, but my understanding
> is that this sort of RRset rotation is intended to work around clients
> that would always pick use first RR from an RRset. Back in the day,
> that meant that one gopher s
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
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 o
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 document.
Implement
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 recurs
orial cleanup can
be made as merge requests to https://gitlab.com/dkg/hddemux or by
private e-mail. Please send flames by private e-mail only :)
--dkg
--- Begin Message ---
A new version of I-D, draft-dkg-dprive-demux-dns-http-00.txt
has been successfully submitted by Daniel Kahn Gillmor and p
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 ti
On Thu 2017-04-27 11:28:15 +0100, Tony Finch wrote:
> Section 3.2.2 HTTP/1
>
> Is there a SP missing between the request-target and the HTTP-version in
> the diagram of the shortest possible request?
whoops, i can't believe i missed that. thanks! fixed in git:
https://gitlab.com/dkg/hddemu
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
On Thu 2017-04-27 12:17:30 -0700, Paul Hoffman wrote:
> On 27 Apr 2017, at 11:51, Christian Huitema wrote:
>
>> So maybe we could build on that, and let application register their
>> specific 24 bytes string, allowing for demux on top of TLS. That would
>> define an organized process.
>
> ...which
On Thu 2017-04-27 17:34:27 +, Hugo Maxwell Connery wrote:
> Should we mandate that all future protocols are "demuxible" from
> all previous?
fwiw, i'm not prepared to make any kind of statement anywhere near that
grand, and i'd hope that the specific proposal under discussion doesn't
hinge on
On Fri 2017-04-28 08:57:39 -0700, Joe Touch wrote:
>> -- existing HTTPS isn't going to move to a new port, which means
>> traffic on that port would be suspect to a would-be censor or a
>> pervasive monitor, right?
>
> All traffic on the Internet is already subject to censorship and
> monitoring.
On Fri 2017-04-28 09:15:18 +0100, Ray Bellis wrote:
> On 28/04/2017 08:42, Daniel Kahn Gillmor wrote:
>
>> But does the non-predictability requirement hold in stream-based DNS,
>> where the establishment of the stream itself provides at least as good
>> protection against s
On Fri 2017-04-28 08:50:44 -0700, Joe Touch wrote:
> On 4/28/2017 12:14 AM, Daniel Kahn Gillmor wrote:
>> In particular, the approach i've described in the draft only works for
>> client-speaks-first, stream-based protocols.
>
> I don't think you can assert that
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 port,
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 against
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
>
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 contain
Hi Colm--
On Wed 2017-05-03 12:26:40 -0700, Colm MacCárthaigh wrote:
> Cool idea. One concern might be compatibility with other similar
> mechanisms. For example, there are protocols such as Netscaler Client IP:
>
> https://www.citrix.com/blogs/2016/04/25/how-to-enable-client-ip-in-tcpip-option-of
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
>> to t
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 client would have to offer that
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 does
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
On Thu 2017-05-04 11:11:59 +1000, Martin Thomson wrote:
> On 4 May 2017 at 10:43, Daniel Kahn Gillmor wrote:
>> I address this in the draft section "Why not ALPN?" -- if anyone thinks
>> the text there could be improved, i'd be happy to hear suggestions for
&g
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 e
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
___
d
On Fri 2017-10-27 09:30:43 -0400, Brian Haberman wrote:
> Hi Stephane,
>
> On 10/27/17 8:55 AM, 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
Hey DPRIVE folks--
Apologies for the delay, and that this message is so long. I've tried
to reconstruct this discussion around
draft-ietf-dprive-dtls-and-tls-profiles-11 as best i can, and my
analysis follows. If i've misundertood or misanalyzed something,
please let me know.
Summary
---
I
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 cherry.
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
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 inter
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 section
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 polic
hey DPRIVE folks--
People on this list might be interested in the recent "Oblivious DNS"
work from Annie Edmundson, Paul Schmitt, and Nick Feamster:
https://freedom-to-tinker.com/2018/04/02/a-privacy-preserving-approach-to-dns/
https://odns.cs.princeton.edu/
This was presented at DNS-OARC 28 in
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
slight was
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 no
On Wed 2018-12-05 10:35:20 -0500, Brian Haberman wrote:
> I think it would be quite useful if someone were to explore the use of
> message layer security in the context of DNS. That could be one of the
> ones you listed above or it could be the work in MLS. Or even Double
> Ratchet.
>
> If any of t
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 the
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
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
> abcdefghijklmnopqrstuvwxyz789012[muks
On Fri 2018-12-14 02:28:28 +0530, Mukund Sivaraman wrote:
> A resolver can respond to several queries without performing any
> upstream queries. As an example, take RFC 6761. Nothing can be inferred
> about a query simply because it didn't result in resolution.
yep, i agree with this in a principl
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 it
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 priva
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
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 the
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 might
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
th
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 advantageou
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.
> P
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.
>
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
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 to
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 approac
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 "p
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".
Th
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,
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 sure
ached 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] Clari
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, cheap
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 repos
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, a
95 matches
Mail list logo
