Re: [DNSOP] Consensus check on underscore names and draft-ietf-dnsop-rfc7816bis

On Wed, Jul 14, 2021 at 4:17 AM Petr Špaček wrote: > > On 14. 07. 21 5:13, Brian Dickson wrote: > > > > > > On Tue, Jul 13, 2021 at 10:01 AM Viktor Dukhovni > > wrote: > > > > > On 13 Jul 2021, at 6:22 am, Petr Špaček > > wrote: >

Re: [DNSOP] Consensus check on underscore names and draft-ietf-dnsop-rfc7816bis

On 14. 07. 21 5:13, Brian Dickson wrote: On Tue, Jul 13, 2021 at 10:01 AM Viktor Dukhovni > wrote: > On 13 Jul 2021, at 6:22 am, Petr Špaček mailto:pspa...@isc.org>> wrote: > > As Viktor pointed out in

Re: [DNSOP] Consensus check on underscore names and draft-ietf-dnsop-rfc7816bis

> On 13 Jul 2021, at 11:13 pm, Brian Dickson > wrote: > > For example, in evaluating the break-points when partitioning the labels to > limit the total number of queries, the sequence COULD treat any contiguous > sequence of underscore labels as if it were a single label, and then do its >

Re: [DNSOP] Consensus check on underscore names and draft-ietf-dnsop-rfc7816bis

On Tue, Jul 13, 2021 at 10:01 AM Viktor Dukhovni wrote: > > On 13 Jul 2021, at 6:22 am, Petr Špaček wrote: > > > > As Viktor pointed out in > https://mailarchive.ietf.org/arch/msg/dnsop/w7JBD4czpGKr46v-DlycGbOv9zs/ > , it seems that this problem plagues roughly tens out of 150k domains he >

Re: [DNSOP] Consensus check on underscore names and draft-ietf-dnsop-rfc7816bis

> On 13 Jul 2021, at 6:22 am, Petr Špaček wrote: > > As Viktor pointed out in > https://mailarchive.ietf.org/arch/msg/dnsop/w7JBD4czpGKr46v-DlycGbOv9zs/ , it > seems that this problem plagues roughly tens out of 150k domains he surveyed. > I think this makes further discussion about

Re: [DNSOP] Consensus check on underscore names and draft-ietf-dnsop-rfc7816bis

On 13. 07. 21 0:13, Brian Dickson wrote: On Mon, Jul 12, 2021 at 2:20 AM Petr Špaček > wrote: On 08. 07. 21 18:15, Brian Dickson wrote: > > > On Thu, Jul 8, 2021 at 7:29 AM Petr Špaček mailto:pspa...@isc.org> >

Re: [DNSOP] Consensus check on underscore names and draft-ietf-dnsop-rfc7816bis

On Mon, Jul 12, 2021 at 2:20 AM Petr Špaček wrote: > On 08. 07. 21 18:15, Brian Dickson wrote: > > > > > > On Thu, Jul 8, 2021 at 7:29 AM Petr Špaček > > wrote: > > > > On 07. 07. 21 19:54, Warren Kumari wrote: > > > Hi there all, > > > > > > I wanted

Re: [DNSOP] Consensus check on underscore names and draft-ietf-dnsop-rfc7816bis

On 08. 07. 21 18:00, Viktor Dukhovni wrote: On 8 Jul 2021, at 10:28 am, Petr Špaček wrote: With my implementer hat on, I say "no", I don't see a compelling reason to "mandate" it. Keep it at MAY/optional level and leave it to implementers to decide what's best for their implementation and

Re: [DNSOP] Consensus check on underscore names and draft-ietf-dnsop-rfc7816bis

On 08. 07. 21 18:15, Brian Dickson wrote: On Thu, Jul 8, 2021 at 7:29 AM Petr Špaček > wrote: On 07. 07. 21 19:54, Warren Kumari wrote: > Hi there all, > > I wanted to check the consensus on a point brought up during IETF LC / > OpsDir

Re: [DNSOP] Consensus check on underscore names and draft-ietf-dnsop-rfc7816bis

tl;dr: No. On Wed, 2021-07-07 at 13:54 -0400, Warren Kumari wrote: > If resolving " _ldap._tcp.ad.example.com", once you hit the _tcp label > you are quite likely in ENT territory, and some implementations > (especially those behind firewalls / middleboxes) are still broken. Then they shall

Re: [DNSOP] Consensus check on underscore names and draft-ietf-dnsop-rfc7816bis

Paul Wouters writes: > There is no distinct privacy realm here, and query minimalization > SHOULD stop, and the entire QNAME should be requested. I think this is the primary point and the proposal should go forward with the stronger wording. But... you know some future-dnsop will decide to

Re: [DNSOP] Consensus check on underscore names and draft-ietf-dnsop-rfc7816bis

On Thu, Jul 8, 2021 at 7:29 AM Petr Špaček wrote: > On 07. 07. 21 19:54, Warren Kumari wrote: > > Hi there all, > > > > I wanted to check the consensus on a point brought up during IETF LC / > > OpsDir review of draft-ietf-dnsop-rfc7816bis. > > > > Please see: > > >

Re: [DNSOP] Consensus check on underscore names and draft-ietf-dnsop-rfc7816bis

> On 8 Jul 2021, at 10:28 am, Petr Špaček wrote: > > With my implementer hat on, I say "no", I don't see a compelling reason to > "mandate" it. Keep it at MAY/optional level and leave it to implementers to > decide what's best for their implementation and use-cases. Just wanted to check what

Re: [DNSOP] Consensus check on underscore names and draft-ietf-dnsop-rfc7816bis

On 07. 07. 21 19:54, Warren Kumari wrote: Hi there all, I wanted to check the consensus on a point brought up during IETF LC / OpsDir review of draft-ietf-dnsop-rfc7816bis. Please see: https://mailarchive.ietf.org/arch/msg/last-call/fuDyx2as6QsK8CT_7Nvci5d7XQQ/ and

Re: [DNSOP] Consensus check on underscore names and draft-ietf-dnsop-rfc7816bis

Warren Kumari wrote: > > Viktor is suggesting that QNAME Minimization should be stopped when > you run into an underscore ("_") label, instead of this being worded > as a potential, optional mechanism. This sounds sensible to me. We have some _underscore delegations, because our VOIP phone

Re: [DNSOP] Consensus check on underscore names and draft-ietf-dnsop-rfc7816bis

On Wed, 7 Jul 2021, Warren Kumari wrote: "Another potential, optional mechanism for limiting the number of queries is to assume that labels that begin with an underscore (_) character do not represent privacy-relevant administrative boundaries. For example, if the QNAME is

Re: [DNSOP] Consensus check on underscore names and draft-ietf-dnsop-rfc7816bis

On Wed, Jul 07, 2021 at 08:46:17PM +0200, Peter Thomassen wrote: > Especially because of the last reason above, I tend towards MAY. > > However, I would endorse SHOULD / RECOMMENDED if the wording is > changed such that "skipping a split" is done "up to the lowest-level" > underscore label. In

Re: [DNSOP] Consensus check on underscore names and draft-ietf-dnsop-rfc7816bis

On 7/7/21 7:54 PM, Warren Kumari wrote: Obviously there is a tradeoff here -- privacy vs deployment. 1: while it's **possible** that there is a delegation point at the underscore label, (IMO) it is unlikely. If there is no delegation, you will simply be coming back to the same server again and

Re: [DNSOP] Consensus check on underscore names and draft-ietf-dnsop-rfc7816bis

I am with Victor on the use of RECOMMENDED. On Wed, Jul 7, 2021 at 2:01 PM Viktor Dukhovni wrote: > On Wed, Jul 07, 2021 at 01:54:37PM -0400, Warren Kumari wrote: > > > Viktor is suggesting that QNAME Minimization should be stopped when > > you run into an underscore ("_") label, instead of

Re: [DNSOP] Consensus check on underscore names and draft-ietf-dnsop-rfc7816bis

On Wed, Jul 7, 2021 at 10:55 AM Warren Kumari wrote: > Hi there all, > > I wanted to check the consensus on a point brought up during IETF LC / > OpsDir review of draft-ietf-dnsop-rfc7816bis. > > Please see: > > https://mailarchive.ietf.org/arch/msg/last-call/fuDyx2as6QsK8CT_7Nvci5d7XQQ/ > and >

Re: [DNSOP] Consensus check on underscore names and draft-ietf-dnsop-rfc7816bis

On Wed, Jul 07, 2021 at 01:54:37PM -0400, Warren Kumari wrote: > Viktor is suggesting that QNAME Minimization should be stopped when > you run into an underscore ("_") label, instead of this being worded > as a potential, optional mechanism. > > Obviously there is a tradeoff here -- privacy vs

Re: [DNSOP] Consensus check on underscore names and draft-ietf-dnsop-rfc7816bis

On Wed, Jul 07, 2021 at 01:54:37PM -0400, Warren Kumari wrote: > ... > > What does the WG think? Does the privacy win of getting this deployed > and enabled sooner outweigh the potential small leak if there *is* a > delegation inside the _ territory of the name? +1. > Should the advice above be

[DNSOP] Consensus check on underscore names and draft-ietf-dnsop-rfc7816bis

Hi there all, I wanted to check the consensus on a point brought up during IETF LC / OpsDir review of draft-ietf-dnsop-rfc7816bis. Please see: https://mailarchive.ietf.org/arch/msg/last-call/fuDyx2as6QsK8CT_7Nvci5d7XQQ/ and https://mailarchive.ietf.org/arch/msg/dnsop/_H4aM5AquCSRlz0Pz3ncwl7Plpk/