Re: [dns-privacy] DS Hacks

On 30/07/2021 17.30, Ben Schwartz wrote: It seems like there's still interest in DS hacks.  Here's how I would do a DS hack. 1. Use the VERBATIM hash from https://datatracker.ietf.org/doc/html/draft-vandijk-dnsop-ds-digest-verbatim

[dns-privacy] DDoS resiliance & DNS-over-TCP (was Root Server Operators Statement on DNS Encryption)

Bill, On 31/03/2021 22.29, Bill Woodcock wrote: On Mar 31, 2021, at 9:55 PM, Rob Sayre wrote: I still don't understand the resistance here. Some data on what the impact would be still seems like the most helpful thing to move the conversation forward. We have that:

Re: [dns-privacy] The DPRIVE WG has placed draft-hzpa-dprive-xfr-over-tls in state "Candidate for WG Adoption"

Dear Colleagues, On 29/10/2019 17.41, IETF Secretariat wrote: The DPRIVE WG has placed draft-hzpa-dprive-xfr-over-tls in state Candidate for WG Adoption (entered by Tim Wicinski) The document is available at https://datatracker.ietf.org/doc/draft-hzpa-dprive-xfr-over-tls/ I think that this

Re: [dns-privacy] Sketchy notes on DNS-over-TLS to authoritative servers

Tony, On 2018-09-10 16:48, Tony Finch wrote: Opportunistic TLS - The only mechanism we have is to probe port 853 and fall back to 53 if TLS isn't available. This is fraught with problems since in many cases firewalls will drop packets to port 853 rather than promptly

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

Alex, I think that the new way probably makes slightly more sense. So I prefer the NEW order. Cheers, -- Shane Alexander Mayrhofer: > All, > > the OPSDIR review from Joe Clarke suggests a re-ordering of the > document flow in order to better appeal to folks with operational > background. I'm

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

Paul, At 2017-07-06 18:09:51 -0700 "Paul Hoffman" wrote: > On 3 Jul 2017, at 14:29, Alexander Mayrhofer wrote: > > > i've updated the Padding Policy draft - the main change is the > > inclusion of an actual recommendation, essentially a blunt copy of > > Daniel's

Re: [dns-privacy] Padding policies draft

Alexander and all, tl;dr Lets move forward with our best guesses now. dkg's recommendations seem good, but maybe we can tweak these based on expected maximum packet sizes. [ apologies for the rambling post ] At 2017-06-12 11:38:56 + Alexander Mayrhofer

[dns-privacy] DNS over TLS for zone transfers?

Hello, I'm sorry if it has already been discussed, but has there been any work done on using TLS for AXFR/IXFR? It seems like it should be relatively straightforward, compared to the stub-to-resolver and resolver-to-authority links. While it does not seem as big of a problem either, obviously

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. >

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 <bortzme...@nic.fr> wrote: > On Wed, Dec 14, 2016 at 10:21:13AM +0100, > Shane Kerr <sh...@time-travellers.org> wrote > a message of 90 lines which said: > > > > Given that a fallback

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

Stephane, At 2016-12-13 16:41:33 +0100 Stephane Bortzmeyer <bortzme...@nic.fr> wrote: > On Tue, Dec 13, 2016 at 03:46:25PM +0100, > Shane Kerr <sh...@time-travellers.org> wrote > a message of 120 lines which said: > > > I think that TLS may be more painfu

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

Stephane, At 2016-12-13 11:59:36 +0100 Stephane Bortzmeyer wrote: > In the minutes of the Seoul meeting, we see: > > Strong hum for sticking around to work on this. > Terry (as AD): more mailing list discussion, please > > So, this email is to request this > discussion.

Re: [dns-privacy] DNS over DTLS

Tariq, At 2016-12-01 12:50:16 +0500 Tariq Saraj wrote: > My question is that, at one side "Specification for DNS over Transport > Layer Security (TLS) i.e. RFC7858" is a proposed standard now. > Whereas, on the other side in the "draft-ietf-dprive-dnsodtls-13", > The

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

Warren, At 2016-11-18 13:42:08 +0900 Warren Kumari wrote: > This starts a Call for Adoption for draft-mayrhofer-dprive-padding-profile. > > The draft is available here: > https://datatracker.ietf.org/doc/draft-mayrhofer-dprive-padding-profile/ > > Please review this draft

Re: [dns-privacy] EDNS0 Padding - "profiles"?

Alexander, At 2016-07-22 08:05:16 + Alexander Mayrhofer wrote: > We're now seeing the first implementations of padding, and I've had > lots of discussions around what strategy to apply when padding. The > questions which arise during implementation are typically:

[dns-privacy] Encrypting XFR (was Recharter discussion?)

Robert, At 2016-06-11 01:29:09 -0400 Robert Edmonds <edmo...@mycre.ws> wrote: > Shane Kerr wrote: > > I'm basically thinking that the next step is encrypting the > > resolver-to-authority session, right? Steps beyond that to increase > > privacy are much tricker, s

[dns-privacy] Recharter discussion? (was DPRIVe Agenda requests for Berlin)

Tim, The standards work of securing the stub to resolver is done enough that the focus on that has shifted to experimental implementations and operational issues. Is it time to think about a re-charter to explicitly list other work? (Alternately this group could be shut down and one or more new

Re: [dns-privacy] Spencer Dawkins' Yes on draft-ietf-dprive-edns0-padding-02: (with COMMENT)

Spencer, At 2016-02-29 20:38:34 -0800 "Spencer Dawkins" wrote: > Thanks for producing this draft. I do have one question about this text: > >The PADDING octets SHOULD be set to 0x00. Other values MAY be used; >for example, in cases where there is a

Re: [dns-privacy] Joel Jaeggli's Discuss on draft-ietf-dprive-edns0-padding-02: (with DISCUSS)

Joel, At 2016-02-29 11:55:27 -0800 "Joel Jaeggli" wrote: > > This is just something I want to discuss, it's not an objection... > > At this point we say: > >Implementations therefore >SHOULD avoid using this option if the DNS transport is not encrypted. > > If you

Re: [dns-privacy] DNS PRIVate Exchange

Tariq, At 2016-01-13 16:58:03 +0500 Tariq Saraj wrote: > I am working on my MS(InfoSec) Final Thesis "Lightweight solution > for confidentiality in DNS". > I just want to raise an issue about DNS confidentiality. > Encryption is only strong when we don't know about

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

Alex, At 2015-11-24 13:19:47 +0100 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

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

Olafur, At 2015-11-16 10:28:08 -0500 Olafur Gudmundsson <o...@ogud.com> wrote: > > On Nov 16, 2015, at 8:41 AM, Andreas Gustafsson <g...@araneus.fi> wrote: > > > > Shane Kerr wrote: > >> Andreas Gustafsson <g...@araneus.fi> wrote: > >>&

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

Andreas, At 2015-11-15 20:27:34 +0200 Andreas Gustafsson wrote: > > I'm also wondering if there might be scenarios where the messages are > compressed before encryption. If that is the case, padding with zeros > is of limited value because they will mostly compress away, and

Re: [dns-privacy] EDNS0 padding with non-0 MUST respond with FORMERR? (was Call for Adoption: draft-mayrhofer-edns0-padding)

Alex, At 2015-11-15 21:33:25 +1300 Alex Mayrhofer wrote: > > On Fri, 06 Nov 2015 10:43:10 +1300 > > Alex Mayrhofer wrote: > > ... > > > This might have been your intent, but I read it the same as Ashu did. > > Ok, I

Re: [dns-privacy] DNSoDTLS fragmentation/reassembly shim [was Re: review of draft-ietf-dprive-dnsodtls-01]

Dan, On Fri, 9 Oct 2015 10:07:54 -0700 Dan Wing wrote: > On 05-Oct-2015 03:48 pm, Ted Hardie wrote: > > That said, the shim layer proposal seems at first glance to a > > pretty simple extension of the multiplexing mechanics already > > described. That