Re: [DNSOP] Resolverless DNS Side Meeting in Montreal

> Assuming that in the context of DoH reply size is not an issue, is seems to > me that this use case is already solved by DNSSEC. Just push all required > signatures, key material and DS records that allow the receiving side to > validate the additional information. > > that validates its a valid

Re: [DNSOP] Resolverless DNS Side Meeting in Montreal

Patrick McManus wrote: ... For example www.example.com pushes you a record for img1.example.com . Should you use it? no. sibling names might be delegation points. kashpureff taught us this in 1996 or so, and kaminsky reinforced that

Re: [DNSOP] Resolverless DNS Side Meeting in Montreal

>For example www.example.com pushes you a record for img1.example.com. >Should you use it? What if it is for img1.img-example.com ? Do the >relationship between these domains matter? What kind of relationship (i.e. >it could be a domain relationship, or in the context of a browser it might

Re: [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal

probably not (whatever is available will be adhoc) - its a side meeting (aka bar bof) meant to take advantage of whomever is there. It has no process value. I'll make an effort to take minutes and report out though. On Tue, Jul 10, 2018 at 9:42 AM, manu tman wrote: > > > On Mon, Jul 9, 2018

Re: [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal

> > "Are you trying to re-invent DNSSEC for people who don't want to deploy > DNSSEC?" My magic 8-ball says "signs point to Yes" On Tue, Jul 10, 2018 at 5:09 AM, Philip Homburg wrote: > >For example www.example.com pushes you a record for img1.example.com > . > >Should you use it? What

Re: [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal

On Mon, Jul 9, 2018 at 7:49 PM Patrick McManus wrote: > > *We'll do the meeting over 1 hour in the Dorchester room from 16:30 to > 17:30 on Monday July 16th.* > Will it be recorded and will there be everything set for remote participants? Manu ___

Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-attrleaf

On 7/9/2018 2:35 PM, Dick Franks wrote: On 9 July 2018 at 19:48, Dave Crocker > wrote: >8 Does this cause anyone intolerable heart-burn?  If it does, please at least explain but preferably offer something better. I do not suffer from intolerable heart-burn

Re: [DNSOP] Resolverless DNS Side Meeting in Montreal

On Tue, 10 Jul 2018, Philip Homburg wrote: For example www.example.com pushes you a record for img1.example.com. Should you use it? What if it is for img1.img-example.com ? Do the relationship between these domains matter? What kind of relationship (i.e. it could be a domain relationship,

[DNSOP] DNSOP Agenda for IETF102

All, This is mostly the agenda. The chairs reserve the right to shuffle the order of the talks. This also includes the second session on Thursday. https://datatracker.ietf.org/meeting/102/materials/agenda-102-dnsop-01 Look forward to seeing everyone in Montreal. for Benno and Suzanne, Tim

Re: [DNSOP] Call for Adoption: draft-huque-dnsop-multi-provider-dnssec

On Fri, 6 Jul 2018, Tim Wicinski wrote: This starts a Call for Adoption for: draft-huque-dnsop-multi-provider-dnssec The draft is available here: https://datatracker.ietf.org/doc/draft-huque-dnsop-multi-provider-dnssec/ I've reviewed the draft. It seems to me this is mostly a description of

Re: [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal

[as an individual] On 7/10/18 9:59 AM, Paul Wouters wrote: It seems more like an extension of the Public Suffix. Which domains can make claims about other domains. Based on the conversation that took place in DoH in Singapore, I think it's mostly *not* about this. The questions that have

Re: [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal

On Tue, 10 Jul 2018, Adam Roach wrote: On 7/10/18 9:59 AM, Paul Wouters wrote: It seems more like an extension of the Public Suffix. Which domains can make claims about other domains. Based on the conversation that took place in DoH in Singapore, I think it's mostly *not* about this. The

Re: [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal

On Jul 10, 2018, at 16:09, Adam Roach wrote: > [as an individual] > >> On 7/10/18 9:59 AM, Paul Wouters wrote: >> It seems more like an extension of the Public Suffix. Which domains can >> make claims about other domains. > > Based on the conversation that took place in DoH in Singapore, I

Re: [DNSOP] [Driu] [Doh] Resolverless DNS Side Meeting in Montreal

On 7/10/18 11:41 AM, Ted Lemon wrote: On Tue, Jul 10, 2018 at 12:34 PM, Joe Abley > wrote: > But this is really equivalent in just about every important way to sending the normal https://example.com/img/f.jpg "> along with a

Re: [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal

On 07/10/2018 01:43 PM, Dave Lawrence wrote: > In the large I agree with you, but I think there's more to it than > that. If it pushed me DNSSEC records that I could verify myself from > my own configured trust anchor, why can't I trust them then? alternately, if i know that i'm going to verify

Re: [DNSOP] [Driu] [Doh] Resolverless DNS Side Meeting in Montreal

>The ip= modifier would be a great way to arrange for something to look like >it came from a different source than its actual source. I'm sure there's >an attack surface in there somewhere. That's a rather fundamental issue. In the context of TLS, and a DNSSEC insecure zone, there are two

[DNSOP] Working Group Last Call for for draft-ietf-dnsop-rfc5011-security-considerations-12; was Publication has been requested for draft-ietf-dnsop-rfc5011-security-considerations-12

Thanks Tim - Note the changed subject line. And as you may have guessed I object to the publication of this document on the basis of quality for all the reasons previously stated.  This version of the document is actually in worse shape than the one that failed last call back in October. I

Re: [DNSOP] [Doh] [Driu] Resolverless DNS Side Meeting in Montreal

On 7/10/18 12:32 PM, Philip Homburg wrote: If we decide that TLS is strong enough to defend against these attacks, then there is no need to secure the DNS lookup, other than to reduce the risk of denial of service and for privacy reasons. Then such an ip= modifier would be fine, because the

Re: [DNSOP] [Driu] [Doh] Resolverless DNS Side Meeting in Montreal

Yes, the multi-CDN case is the scariest aspect of coalescing and the various DNS tricks we’ve been doing in recent years. The server may not be malicious, may not even be misconfigured – site X uses DNS to dynamically share load between CDNs A and F. If X decides to start moving more load to

Re: [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal

Joe Abley writes: >but collapsing the address selection back to the extent that you can > avoid name resolution at all seems like a better end goal. > > So rather than resolverless operation, think about resolutionless or > nameless, eliminating the DNS as unnecessary overhead. > > Perhaps I

Re: [DNSOP] Working Group Last Call for for draft-ietf-dnsop-rfc5011-security-considerations-12; was Publication has been requested for draft-ietf-dnsop-rfc5011-security-considerations-12

Michael StJohns writes: > I strongly object to the publication of this document as a Standards Track > document. I'll catch up on the rest of the thread later tonight (I've been gone), but I agree with MSJ here: it should be informational; it's not a protocol. -- Wes Hardaker USC/ISI

Re: [DNSOP] [Driu] [Doh] Resolverless DNS Side Meeting in Montreal

On Tue, Jul 10, 2018 at 12:34 PM, Joe Abley wrote: > > But this is really equivalent in just about every important way to > sending the normal https://example.com/img/f.jpg;> along with a > pushed DNS record that indicates that "example.com" resolves to > "192.0.2.1" -- and this latter thing is

Re: [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal

Tim Wicinski writes: > "Are you trying to re-invent DNSSEC for people who don't want to deploy > DNSSEC?" > > My magic 8-ball says "signs point to Yes" I don't grok how y'all got "trying to re-invent DNSSEC" out of this, so this is sure to be an entertaining discussion.

Re: [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal

On 7/10/18 12:55 PM, Joe Abley wrote: On Jul 10, 2018, at 18:02, Adam Roach wrote: In large part because DNS provides "a richer scheme that accommodates address families and multiple addresses with priorities". *cups hand to ear* Was that the sound of a distant desire to specify use of SRV

Re: [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal

Dave Lawrence wrote: > > In the large I agree with you, but I think there's more to it than > that. If it pushed me DNSSEC records that I could verify myself from > my own configured trust anchor, why can't I trust them then? I've been idly wondering about this from the point of view of RFC

Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-attrleaf

On 10 July 2018 at 15:32, Dave Crocker wrote: > On 7/9/2018 2:35 PM, Dick Franks wrote: >8 > >> >> If a public specification calls for the use of an >> underscore-prefixed domain name, >> the underscored name closest to the root MUST be entered into this >> registry. >> >> > Thanks. I've

Re: [DNSOP] Working Group Last Call for for draft-ietf-dnsop-rfc5011-security-considerations-12; was Publication has been requested for draft-ietf-dnsop-rfc5011-security-considerations-12

On 10 Jul 2018, at 11:35, Michael StJohns wrote: And as you may have guessed I object to the publication of this document on the basis of quality for all the reasons previously stated.  This version of the document is actually in worse shape than the one that failed last call back in October.

Re: [DNSOP] [Driu] [Doh] Resolverless DNS Side Meeting in Montreal

On Jul 10, 2018, at 17:41, Ted Lemon wrote: On Tue, Jul 10, 2018 at 12:34 PM, Joe Abley wrote: > > But this is really equivalent in just about every important way to > sending the normal https://example.com/img/f.jpg;> along with a > pushed DNS record that indicates that "example.com" resolves

Re: [DNSOP] [Driu] [Doh] Resolverless DNS Side Meeting in Montreal

On Tue, Jul 10, 2018 at 1:05 PM, Adam Roach wrote: > On 7/10/18 11:41 AM, Ted Lemon wrote: > > On Tue, Jul 10, 2018 at 12:34 PM, Joe Abley wrote: > >> > But this is really equivalent in just about every important way to >> sending the normal https://example.com/img/f.jpg;> along with >> a

Re: [DNSOP] [Driu] [Doh] Resolverless DNS Side Meeting in Montreal

On Tue, 10 Jul 2018, Ryan Sleevi wrote: That's why involving DNS is at least relevant to that discussion, especially given that publicly trusted certificates are themselves predicated on DNS. Further, considering that the CA only has to validate a DNS once per 825-day period, and can issue

Re: [DNSOP] Working Group Last Call for for draft-ietf-dnsop-rfc5011-security-considerations-12; was Publication has been requested for draft-ietf-dnsop-rfc5011-security-considerations-12

On 7/10/2018 12:34 PM, Paul Hoffman wrote: On 10 Jul 2018, at 11:35, Michael StJohns wrote: And as you may have guessed I object to the publication of this document on the basis of quality for all the reasons previously stated.  This version of the document is actually in worse shape than

Re: [DNSOP] [Driu] [Doh] Resolverless DNS Side Meeting in Montreal

I'm not suggesting that the attack surfaces couldn't be closed, and that does seem like it would be sufficient to close them. However, we've been burned by implementations not getting details like this right in the past, so that's why I brought it up. On Tue, Jul 10, 2018 at 1:05 PM, Adam Roach

Re: [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal

Paul Vixie writes: > > For example www.example.com pushes you a > > record for img1.example.com . Should you use > > it? > > no. sibling names might be delegation points. kashpureff taught us this > in 1996 or so, and kaminsky reinforced

Re: [DNSOP] Working Group Last Call on draft-ietf-dnsop-terminology-bis

Thanks to Vladimír, > From: Vladimír Čunát > "Bailiwick" definition: I have (also) seen use like "in-bailiwick > records" in the sense being in a subdomain.  I can't really judge how > common that usage is, but it has already been discussed wrt. this draft: >

Re: [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal

yes; and.. dns has always provided a point of indirection that is useful. dynamically rewriting markup might be infeasible.. and many fetch() like things are driven from script where the markup changes are not obvious or perhaps ill fitting.. and of course there are questions of cached content

Re: [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal

On Jul 10, 2018, at 18:02, Adam Roach wrote: > In large part because DNS provides "a richer scheme that accommodates address > families and multiple addresses with priorities". *cups hand to ear* Was that the sound of a distant desire to specify use of SRV for HTTP? Joe

Re: [DNSOP] SRV and HTTP

Fine by me. > On 11 Jul 2018, at 11:32 am, Mark Nottingham wrote: > > I didn't find those, but I found many others. > > I'll start collecting. How about Tuesday, say 6:45-7:45pm? > > > >> On 11 Jul 2018, at 11:30 am, Mark Andrews wrote: >> >> >> >>> On 11 Jul 2018, at 11:22 am, Mark

Re: [DNSOP] SRV and HTTP

In article <82099ded-ccb6-4cdc-bfe6-97b1ab3eb...@isc.org> you write: >1) Wildcards don’t work with prefixes. >1) is addressed by defining a new type(s) rather than using prefixes. There's over 6000 service names defined for SRV. That's a lot of rrtypes. R's, John

Re: [DNSOP] SRV and HTTP

Mark Nottingham writes: > I'll start collecting. How about Tuesday, say 6:45-7:45pm? Last session ends at 6:20 and social starts at 7, not sure how late the last bus (if any?) will be leaving the hotel. ___ DNSOP mailing list DNSOP@ietf.org

Re: [DNSOP] SRV and HTTP

Dave Lawrence writes: > Mark Nottingham writes: > > I'll start collecting. How about Tuesday, say 6:45-7:45pm? > > Last session ends at 6:20 and social starts at 7, not sure how late > the last bus (if any?) will be leaving the hotel. Nevermind, walking distance to social, under 1km. Maybe

Re: [DNSOP] SRV and HTTP

> On 11 Jul 2018, at 11:22 am, Mark Nottingham wrote: > > > >> On 11 Jul 2018, at 3:55 am, Joe Abley wrote: >> >> On Jul 10, 2018, at 18:02, Adam Roach wrote: >> >>> In large part because DNS provides "a richer scheme that accommodates >>> address families and multiple addresses with

Re: [DNSOP] SRV and HTTP - 18:30 Tuesday

Sure, with the understanding that we'll probably start a few minutes after that, given the session end at 16:20 (I'm chairing then, it usually takes a little while to get out). I've reserved Barre Oblique from 18:30 until 19:30 on Tuesday. Cheers, > On 11 Jul 2018, at 11:52 am, Dave Lawrence

Re: [DNSOP] SRV and HTTP

On Tue, Jul 10, 2018 at 11:08:37PM -0400, John Levine wrote: > There's over 6000 service names defined for SRV. That's a lot of rrtypes. But HTTP/HTTPS is the one we have by far the most problems with. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc.

Re: [DNSOP] SRV and HTTP

On 11 Jul 2018, at 3:30, Mark Andrews wrote: > I think there are three main objections. > > 1) Wildcards don’t work with prefixes. > 2) Additional data isn’t always returned it may require multiple round trips. > 3) Additional data processing doesn’t support negative responses. 4) Various

Re: [DNSOP] SRV and HTTP

I didn't find those, but I found many others. I'll start collecting. How about Tuesday, say 6:45-7:45pm? > On 11 Jul 2018, at 11:30 am, Mark Andrews wrote: > > > >> On 11 Jul 2018, at 11:22 am, Mark Nottingham wrote: >> >> >> >>> On 11 Jul 2018, at 3:55 am, Joe Abley wrote: >>> >>>

Re: [DNSOP] SRV and HTTP

> On 11 Jul 2018, at 11:51 am, Dave Lawrence wrote: > > Mark Nottingham writes: >> I'll start collecting. How about Tuesday, say 6:45-7:45pm? > > Last session ends at 6:20 and social starts at 7, not sure how late > the last bus (if any?) will be leaving the hotel. It’s a 9 minute walk (4

Re: [DNSOP] SRV and HTTP

On Tue, Jul 10, 2018 at 11:08:37PM -0400, John Levine wrote: There's over 6000 service names defined for SRV. That's a lot of rrtypes. But HTTP/HTTPS is the one we have by far the most problems with. True, and there have been some proposals for DNS records to return http parameters. It's

Re: [DNSOP] SRV and HTTP

> On 11 Jul 2018, at 1:16 pm, John R Levine wrote: > >> On Tue, Jul 10, 2018 at 11:08:37PM -0400, John Levine wrote: >>> There's over 6000 service names defined for SRV. That's a lot of rrtypes. >> >> But HTTP/HTTPS is the one we have by far the most problems with. > > True, and there have

Re: [DNSOP] SRV and HTTP

On 11 Jul 2018, at 5:16, John R Levine wrote: > It's always been my impression that the http crowd believe that the > overhead of a two DNS lookups is too slow, for some meaning of too slow. They rather stay in the space they know, HTTP resolution, and do multiple HTTP requests instead of