Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Mon, 24 May 2021 at 15:52, Ben Schwartz wrote: > > For those who prefer Github's UI, I've posted Dick's diff to a branch commit > in our repository [1]. Thanks > > The diff contains a number of editorial suggestions, such as removing use of > ABNF, which we can consider separately. The key

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

For those who prefer Github's UI, I've posted Dick's diff to a branch commit in our repository [1]. The diff contains a number of editorial suggestions, such as removing use of ABNF, which we can consider separately. The key substantive change, as discussed earlier in this thread, is to make comm

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

Moin! On 21 May 2021, at 20:16, Brian Dickson wrote: > I think the handling of presentation formats and wire formats leaves much > to be desired. As others said the wire format is a pretty standard TLV format, so I don’t think there is a change needed as this sort of format is well understood. I’m

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Sat, 22 May 2021 at 17:06, Paul Hoffman wrote: > > On May 22, 2021, at 1:58 AM, Dick Franks wrote: > > > Please find attached the promised words to resolve the conflict > > between current draft and RFC1035. > > > > This is presented as a context diff. > > Where do we find the original Markdow

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On May 22, 2021, at 1:58 AM, Dick Franks wrote: > Please find attached the promised words to resolve the conflict > between current draft and RFC1035. > > This is presented as a context diff. Where do we find the original Markdown file so we can evaluate the diff? --Paul Hoffman smime.p7s Des

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

All, Please find attached the promised words to resolve the conflict between current draft and RFC1035. This is presented as a context diff. Dick Franks draft-ietf-dnsop-svcb-https.diff.gz Description: application/gzip ___ DN

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

All The WGLC has been closed. There will also be an IETF LC to raise concerns. tim On Fri, May 21, 2021 at 2:17 PM Brian Dickson wrote: > > > On Thu, May 20, 2021 at 11:29 AM Ralf Weber wrote: > >> Moin! >> >> On 20 May 2021, at 19:59, Eric Orth wrote: >> >> > A big selling point behind why

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Thu, May 20, 2021 at 11:29 AM Ralf Weber wrote: > Moin! > > On 20 May 2021, at 19:59, Eric Orth wrote: > > > A big selling point behind why we have client implementers planning to > > query HTTPS records is the expectation that this will be the only query > > type we will need to add and that

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Thu, 20 May 2021 at 03:57, Mark Andrews wrote: >8 > > > > > RFC1035 has the definition of encoding: > > A bunch of characters without any internal spaces, or > > A string beginning with " and ending with ", and anything else in between > > except " which must be escaped. > > Which doesn’t wor

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

Moin! On 20 May 2021, at 19:59, Eric Orth wrote: > A big selling point behind why we have client implementers planning to > query HTTPS records is the expectation that this will be the only query > type we will need to add and that it can be extended to handle any future > information we need for

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

Moin! On 20 May 2021, at 3:32, Brian Dickson wrote: > (There's a reason I'm not suggesting making SVCB non-extensible, or > touching any aspect of the SVCB thing itself.) > > Note that more ALPN values are supported, and how those are > defined/used/etc are really not relevant to the structure (wi

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

> On 20 May 2021, at 12:31, Brian Dickson wrote: > > > > On Wed, May 19, 2021 at 7:15 PM Mark Andrews wrote: > > > > On 20 May 2021, at 11:52, Paul Wouters wrote: > > > > On Wed, 19 May 2021, Ben Schwartz wrote: > > > >> So long as there are no registered protocol identifiers containing

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Wed, May 19, 2021 at 7:15 PM Mark Andrews wrote: > > > > On 20 May 2021, at 11:52, Paul Wouters wrote: > > > > On Wed, 19 May 2021, Ben Schwartz wrote: > > > >> So long as there are no registered protocol identifiers containing "," > or "\\", zone file implementations MAY > >> disallow these

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

> On 20 May 2021, at 11:52, Paul Wouters wrote: > > On Wed, 19 May 2021, Ben Schwartz wrote: > >> So long as there are no registered protocol identifiers containing "," or >> "\\", zone file implementations MAY >> disallow these characters instead of implementing the `value-list` escaping >>

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Wed, 19 May 2021, Ben Schwartz wrote: So long as there are no registered protocol identifiers containing "," or "\\", zone file implementations MAY disallow these characters instead of implementing the `value-list` escaping procedure. Sorry, an implementor cannot predict the future of the

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

All I'd like to circle around as chair and call this discussion illuminating. I do feel that there is rough consensus to keep with the current format. The discussion here has gone down the path of wholesale redesign. We call the WGLC closed for now. The authors have an updated document to publish

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Thu, May 20, 2021, at 11:32, Brian Dickson wrote: > Is it one of those things that are "Well, we think we might need > something", or is it "We already know something we need"? The former is definitely a factor. Though you might reasonably say that defining another HTTPSv2 codepoint is feasi

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Wed, May 19, 2021 at 5:52 PM Martin Thomson wrote: > On Thu, May 20, 2021, at 10:35, Brian Dickson wrote: > > I was under the impression that the extensibility is for the SVCB type, > > and not strictly needed for HTTPS. > > It is absolutely needed for HTTPS. > I'm not saying I doubt you, but

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Wed, May 19, 2021 at 6:15 PM Martin Thomson wrote: > On Thu, May 20, 2021, at 11:08, Paul Wouters wrote: > > This discussion should be around reasonable and secure wire and > > presentation formats, not about "but we already deployed this". > > It should surely be taken into account if changin

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Thu, May 20, 2021, at 11:08, Paul Wouters wrote: > This discussion should be around reasonable and secure wire and > presentation formats, not about "but we already deployed this". > It should surely be taken into account if changing at this point > gives enough benefits, but the idea of changin

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Thu, 20 May 2021, Martin Thomson wrote: I also want to add to what Tommy (P) said about deployment. We've deployed the current wire format (that's what you get when you assign a codepoint people!) Changes would have serious implications. It looks like the early code point was assigned a

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Thu, May 20, 2021, at 10:35, Brian Dickson wrote: > I was under the impression that the extensibility is for the SVCB type, > and not strictly needed for HTTPS. It is absolutely needed for HTTPS. I also want to add to what Tommy (P) said about deployment. We've deployed the current wire for

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Wed, May 19, 2021 at 5:15 PM Erik Nygren wrote: > > > On Wed, May 19, 2021 at 7:01 PM Brian Dickson < > brian.peter.dick...@gmail.com> wrote: > >> >> >> On Wed, May 19, 2021 at 3:00 PM Brian Dickson < >> brian.peter.dick...@gmail.com> wrote: >> >>> >>> >>> On Wed, May 19, 2021 at 2:50 PM Paul

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Wed, May 19, 2021 at 7:01 PM Brian Dickson wrote: > > > On Wed, May 19, 2021 at 3:00 PM Brian Dickson < > brian.peter.dick...@gmail.com> wrote: > >> >> >> On Wed, May 19, 2021 at 2:50 PM Paul Hoffman >> wrote: >> >>> Are these still just idle ideas you are tossing out (as you indicated >>> ea

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Wed, May 19, 2021 at 3:00 PM Brian Dickson wrote: > > > On Wed, May 19, 2021 at 2:50 PM Paul Hoffman > wrote: > >> Are these still just idle ideas you are tossing out (as you indicated >> earlier), or meant to be serious proposals? If the latter, what is the >> significant improvement over th

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

If you split presentation format records into one record per SvcParam, that necessitates either changing the wire format to match or structuring the presentation and wire formats fundamentally differently with a translation to merge those records into a single record for the wire format. What the

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Wed, May 19, 2021 at 2:50 PM Paul Hoffman wrote: > Are these still just idle ideas you are tossing out (as you indicated > earlier), or meant to be serious proposals? If the latter, what is the > significant improvement over the current draft? I ask because it feels like > you are suggesting m

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

> On May 19, 2021, at 2:37 PM, Erik Nygren wrote: > >  > > >> On Wed, May 19, 2021 at 5:12 PM Tommy Pauly wrote: >> >> >>> On May 19, 2021, at 1:34 PM, Brian Dickson >>> wrote: >>> >>> >>> >>> On Wed, May 19, 2021 at 7:49 AM Tommy Pauly wrote: I wanted to chime in on this discu

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

Are these still just idle ideas you are tossing out (as you indicated earlier), or meant to be serious proposals? If the latter, what is the significant improvement over the current draft? I ask because it feels like you are suggesting moving the inherent complexity of the semantics of SCVB arou

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Wed, May 19, 2021 at 5:12 PM Tommy Pauly wrote: > > > On May 19, 2021, at 1:34 PM, Brian Dickson > wrote: > > > > On Wed, May 19, 2021 at 7:49 AM Tommy Pauly wrote: > >> I wanted to chime in on this discussion as a client-side implementor who >> has already widely deployed support for SVCB/H

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

Given the request below to preserve the current wire format for both HTTPS and SVCB, I think this raises some interesting options and questions: - My understanding of SVCB is that it is intended to be the "parent" type for both HTTPS and other future "mappings" over SVCB. - HTTPS is the f

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

> On May 19, 2021, at 1:34 PM, Brian Dickson > wrote: > > > > On Wed, May 19, 2021 at 7:49 AM Tommy Pauly > wrote: > I wanted to chime in on this discussion as a client-side implementor who has > already widely deployed support for SVCB/HTTPS. > > The current form

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Wed, May 19, 2021 at 7:49 AM Tommy Pauly wrote: > I wanted to chime in on this discussion as a client-side implementor who > has already widely deployed support for SVCB/HTTPS. > > The current format, where the parameters are structured as a list within a > single RR, is certainly simpler and

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

I wanted to chime in on this discussion as a client-side implementor who has already widely deployed support for SVCB/HTTPS. The current format, where the parameters are structured as a list within a single RR, is certainly simpler and less error prone for processing. Much of the information co

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Tue, May 18, 2021 at 2:35 PM Paul Wouters wrote: > On Tue, 18 May 2021, Ben Schwartz wrote: > > > That's essentially correct. A client that only supports the default > ALPN has no use for the "alpn" SvcParam. > > Does the "default ALPN" mean "no support for the ALPN extension" ? Or > does it

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Tue, 18 May 2021, Ben Schwartz wrote: That's essentially correct.  A client that only supports the default ALPN has no use for the "alpn" SvcParam. Does the "default ALPN" mean "no support for the ALPN extension" ? Or does it mean "Supports ALPN with the default " ? If so, what is

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Mon, May 17, 2021 at 3:48 PM Ben Schwartz wrote: > On Mon, May 17, 2021 at 2:46 PM Brian Dickson < > brian.peter.dick...@gmail.com> wrote: > >> I re-read (several times) the current -05 version of the draft. I found >> it difficult to follow and understand several aspects of the "automatically

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Mon, May 17, 2021 at 2:46 PM Brian Dickson wrote: > I re-read (several times) the current -05 version of the draft. I found it > difficult to follow and understand several aspects of the "automatically > mandatory", "mandatory", and mandatory usage in the document, both > syntactically and sem

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Mon, May 17, 2021 at 5:36 PM Ben Schwartz wrote: > > > On Sat, May 15, 2021 at 12:48 PM Brian Dickson < > brian.peter.dick...@gmail.com> wrote: > >> >> >> On Thu, May 13, 2021 at 10:25 AM Ben Schwartz wrote: >> >>> >>> >>> On Thu, May 13, 2021 at 12:51 AM Brian Dickson < >>> brian.peter.dick.

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

Here is a slightly deeper dive into this alternative scheme (for zone file/presentation and wire format), in terms of both the encoding, and the specification document itself (and as a result, the IANA components). I re-read (several times) the current -05 version of the draft. I found it difficul

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Sat, May 15, 2021 at 8:00 AM Erik Nygren wrote: > On Wed, May 12, 2021 at 4:44 PM Brian Dickson < > brian.peter.dick...@gmail.com> wrote: > >> >> Having multiple AliasMode records within an RRset (with either the same >> or different Priority) would provide an avenue for dealing with resolutio

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Thu, May 13, 2021 at 10:25 AM Ben Schwartz wrote: > > > On Thu, May 13, 2021 at 12:51 AM Brian Dickson < > brian.peter.dick...@gmail.com> wrote: > >> >> >> On Wed, May 12, 2021 at 9:33 PM Ben Schwartz wrote: >> >>> On Wed, May 12, 2021 at 7:14 PM Brian Dickson < >>> brian.peter.dick...@gmail.

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Wed, May 12, 2021 at 4:44 PM Brian Dickson wrote: > > Having multiple AliasMode records within an RRset (with either the same or > different Priority) would provide an avenue for dealing with resolution > failure - which is one of the main reasons for any CDN customer to use > multiple CDNs, i

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Fri, May 14, 2021 at 5:47 PM John Levine wrote: > It appears that Brian Dickson said: > >I said you weren't going to like it. > > No disagreement there. > > >I think it should be taken as a safe assumption, that for the vast > majority > >of end users, they will either be using some kind of

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

It appears that Brian Dickson said: >I said you weren't going to like it. No disagreement there. >I think it should be taken as a safe assumption, that for the vast majority >of end users, they will either be using some kind of UI (good, bad, or >ugly) that is (eventually) aware of the relevant

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Thu, May 13, 2021 at 10:50 AM Ben Schwartz wrote: > > > On Thu, May 13, 2021 at 3:56 AM libor.peltan wrote: > >> Hi all, >> >> just my comment: >> >> Perhaps complexity is subjective. The important thing is that the >> standard be reasonably implementable. I hope that the list of published

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

Pushing text processing onto the client does not reduce the complexity; it just moves it to people who are less likely to be reading DNSOP. Notably, it moves that responsibility to a place where typical text processing errors are far more dangerous, and malicious inputs are far more likely. I s

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Thu, 13 May 2021, Ben Schwartz wrote: SVCB's key=value zone-file format is borrowed straight from DNS-SD (RFC 6763); it is not new to DNS users. Hey, wait a minute. DNS-SD just sticks the "key=value" strings as-is into text fields. Now that I look closer, I see what Brian's objection is a

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Thu, May 13, 2021 at 3:56 AM libor.peltan wrote: > Hi all, > > just my comment: > > Perhaps complexity is subjective. The important thing is that the > standard be reasonably implementable. I hope that the list of published > implementations [3] will serve as convincing evidence that the cur

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

Hi all, just my comment: Perhaps complexity is subjective.  The important thing is that the standard be reasonably implementable.  I hope that the list of published implementations [3] will serve as convincing evidence that the current draft is sufficient in that regard. --Ben I agree that

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Wed, May 12, 2021 at 9:33 PM Ben Schwartz wrote: > On Wed, May 12, 2021 at 7:14 PM Brian Dickson < > brian.peter.dick...@gmail.com> wrote: > >> It is demonstrably more likely that a complex parser will have problems, >> than something that combines data from simple RRs in simple RRsets will >>

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

(The history of SMTP is, I think, a good poster child for this, with MX, A, , plus DNSSEC and TLSA support in the clients, which are email transport things, not merely DNS things.) Not really. MX and A mean different things, and it is useful and common for an SMTP server to be pointed to v

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Wed, May 12, 2021 at 3:32 PM Eric Orth wrote: > > > On Wed, May 12, 2021 at 6:21 PM John Levine wrote: > >> It appears that Joe Abley said: >> >> Agreed that there is no such issue with either wire format if all >> parties in the ecosystem are bug-free and RFC-compliant. >> > >> >Do you kno

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

> On 13 May 2021, at 07:46, Joe Abley wrote: > > On 12 May 2021, at 17:39, John Levine wrote: > >> It appears that Joe Abley said: >> >>> Do you know of an example of a DNS authoritative or recursive server that >>> does return truncated RRSets in the ANSWER section? >> >> A lot return

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On 12 May 2021, at 17:39, John Levine wrote: > It appears that Joe Abley said: > >> Do you know of an example of a DNS authoritative or recursive server that >> does return truncated RRSets in the ANSWER section? > > A lot return truncated glue in the ADDITIONAL section. Are we sure that >

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

It appears that Joe Abley said: >> Agreed that there is no such issue with either wire format if all parties in >> the ecosystem are bug-free and RFC-compliant. > >Do you know of an example of a DNS authoritative or recursive server that does >return truncated RRSets in the ANSWER section? A l

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Wed, May 12, 2021 at 4:44 PM Brian Dickson wrote: > > > On Wed, May 12, 2021 at 12:28 PM Eric Orth 40google@dmarc.ietf.org> wrote: > >> >> I also oppose allowing multiple aliases within an RRSet. This would >> allow aliasing trees, unreasonably exploding the complexity/performance >> sco

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On 12 May 2021, at 17:03, Eric Orth wrote: > On Wed, May 12, 2021 at 4:28 PM Brian Dickson > wrote: > >> Responses including partial RRsets are as unlikely (and as illegal) as a >> response to a query for SVCB being a TXT record saying "I'm a teapot". > > Agreed that there is no such issue

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Wed, May 12, 2021 at 4:28 PM Brian Dickson wrote: > > > On Wed, May 12, 2021 at 12:28 PM Eric Orth 40google@dmarc.ietf.org> wrote: > >> I have no strong opinions on any of the discussions regarding escaping in >> presentation mode because I don't have much involvement in dealing with >> p

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Wed, May 12, 2021 at 12:28 PM Eric Orth wrote: > > I also oppose allowing multiple aliases within an RRSet. This would allow > aliasing trees, unreasonably exploding the complexity/performance scope of > query followup logic in stubs and recursives. In practice, I don't think > this would ac

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Wed, May 12, 2021 at 12:28 PM Eric Orth wrote: > I have no strong opinions on any of the discussions regarding escaping in > presentation mode because I don't have much involvement in dealing with > presentation mode of DNS records. The client I work with parses wire > format directly into it

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

I have no strong opinions on any of the discussions regarding escaping in presentation mode because I don't have much involvement in dealing with presentation mode of DNS records. The client I work with parses wire format directly into its internal structures. >From my wire-format-only perspectiv

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Tue, 2021-05-11 at 18:26 +0200, libor.peltan wrote: > > May I be wrong, but I think that name, type, class and TTL are not repeated > in one RRSet with multiple RData. Not in wire format and not necessarily even > in zonefile. (?) Zone files allow you to leave some of those out on subsequent

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Tue, May 11, 2021 at 4:16 PM Ben Schwartz wrote: > > > On Tue, May 11, 2021 at 4:13 PM Brian Dickson < > brian.peter.dick...@gmail.com> wrote: > ... > >> What is the difference between >> >> foo.example.com HTTPS 0 foo.example.net >> >> and >> >> foo.example.com HTTPS 1 foo.example.net >> >> (

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Tue, May 11, 2021 at 4:00 PM Ben Schwartz wrote: > > > On Tue, May 11, 2021 at 3:44 PM Brian Dickson < > brian.peter.dick...@gmail.com> wrote: > >> >> >> On Tue, May 11, 2021 at 2:49 PM Ben Schwartz wrote: >> >>> >>> >>> On Tue, May 11, 2021 at 2:31 PM Brian Dickson < >>> brian.peter.dick...@

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Tue, May 11, 2021 at 2:49 PM Ben Schwartz wrote: > > > On Tue, May 11, 2021 at 2:31 PM Brian Dickson < > brian.peter.dick...@gmail.com> wrote: > ... > >> Another way to put it is, the SvcParameters are actually bound to the >> TargetName, not the owner name of the HTTPS record, and the Web/CDN

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Tue, May 11, 2021 at 11:12 AM Ben Schwartz wrote: > > > On Tue, May 11, 2021 at 10:32 AM Joe Abley wrote: > >> On 11 May 2021, at 12:32, Ben Schwartz wrote: >> >> > On Tue, May 11, 2021 at 9:20 AM Joe Abley wrote: >> >> On 11 May 2021, at 12:08, Ben Schwartz > 40google@dmarc.ietf.org> w

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Tue, May 11, 2021 at 10:32 AM Joe Abley wrote: > On 11 May 2021, at 12:32, Ben Schwartz wrote: > > > On Tue, May 11, 2021 at 9:20 AM Joe Abley wrote: > >> On 11 May 2021, at 12:08, Ben Schwartz 40google@dmarc.ietf.org> wrote: > >> .. > >>> * It saves at least 11 bytes of overhead per pa

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On 11 May 2021, at 12:32, Ben Schwartz wrote: > On Tue, May 11, 2021 at 9:20 AM Joe Abley wrote: >> On 11 May 2021, at 12:08, Ben Schwartz >> wrote: >> .. >>> * It saves at least 11 bytes of overhead per parameter by avoiding >>> repetition of >>> the name, type, class, TTL, and inter-pair

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Tue, May 11, 2021 at 9:41 AM Dick Franks wrote: > All, > > As part of a side discussion, I was admonished for my rather flippant > approach to a significant security issue and failure to explain > clearly how it manifests itself.. > > On Sun, 9 May 2021 at 13:01, Dick Franks wrote: > >8 > > >

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

All, As part of a side discussion, I was admonished for my rather flippant approach to a significant security issue and failure to explain clearly how it manifests itself.. On Sun, 9 May 2021 at 13:01, Dick Franks wrote: >8 > > Pre-processing of '\\,' into the RFC1035 standard '\,' is > superfic

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Tue, May 11, 2021 at 9:20 AM Joe Abley wrote: > Hi Ben, > > On 11 May 2021, at 12:08, Ben Schwartz > wrote: > .. > * It saves at least 11 bytes of overhead per parameter by avoiding > repetition of > the name, type, class, TTL, and inter-pair binding ID. > > > ... but it inflates response

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

Hi Ben, Dne 11. 05. 21 v 18:08 Ben Schwartz napsal(a): On Tue, May 11, 2021 at 3:31 AM libor.peltan > wrote: If there really is a strong reason for putting multiple key-value records into one RData (instead of one RRSet), it should be described somewhe

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

Hi Ben, On 11 May 2021, at 12:08, Ben Schwartz wrote: > OK, I've proposed text documenting the reasoning here: > https://github.com/MikeBishop/dns-alt-svc/pull/323/files > . I definitely appreciate the effort, since I think I agree th

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On 11. 05. 21 1:59, Brian Dickson wrote: IMNSHO, it'll be faster to discard any existing parsing code, and embrace this as the Zone File format (and wire format) going forward. I think that would imply burning the currently allocated RRtype code pair and requesting a new pair from IANA.  Not u

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

Hi all, this is actually not the first time someone has come with this issue: https://mailarchive.ietf.org/arch/browse/dnsop/?gbt=1&index=WxZLxeJF3vSHiOG0jGm8kek5ajI If there really is a strong reason for putting multiple key-value records into one RData (instead of one RRSet), it should be d

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Mon, May 10, 2021 at 9:58 AM Ben Schwartz wrote: > I don't support breaking the SvcParams into separate RRs across the > RRSet. This would be an extremely inefficient encoding in wire format, and > would conflict with the usual understanding of resource records as > independently meaningful a

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On May 10, 2021, at 4:14 PM, Mark Andrews wrote: > Actually, the process problem is that record format keeps changing AFTER the > code point has been assigned and the record format THEORETICALLY been FIXED. Mark makes an excellent point, one that people in the DNS world routinely forget. --Pa

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

> On 11 May 2021, at 08:46, Paul Hoffman wrote: > > On May 10, 2021, at 9:56 AM, Ben Schwartz > wrote: >> >> I don't support breaking the SvcParams into separate RRs across the RRSet. >> This would be an extremely inefficient encoding in wire format, and would >> conflict with the usual

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

Hiya, Without commenting on the rest of the discussion (though I do agree with those who made the point that optimising for those writing zone files here is better than for those parsing zone files)... On 10/05/2021 17:56, Ben Schwartz wrote: It would also require a dramatic rewrite of a speci

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On May 10, 2021, at 9:56 AM, Ben Schwartz wrote: > > I don't support breaking the SvcParams into separate RRs across the RRSet. > This would be an extremely inefficient encoding in wire format, and would > conflict with the usual understanding of resource records as independently > meaningfu

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

> On 11 May 2021, at 02:56, Ben Schwartz > wrote: > > I don't support breaking the SvcParams into separate RRs across the RRSet. > This would be an extremely inefficient encoding in wire format, and would > conflict with the usual understanding of resource records as independently > meani

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Mon, 10 May 2021, Ben Schwartz wrote: It would also require a dramatic rewrite of a specification that is now widely deployed. The IETF is not a rubber-stamp factory for corporate proposals though. The tendency for corporation to bring up something at the IETF that is "too far gone" for m

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Mon, 10 May 2021, Joe Abley wrote: $ORIGIN example.com @ SVCB 1 foo key6="\032\001\013\184\000\000\000\000\000\000\000\000,\000" ; a.k.a. ipv6hint=2001:db8::5c5c:2c00 A zone owner/editor would never even think of typing in IP addresses like that. Right, but an attacker

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Mon, 2021-05-10 at 16:43 +0200, Pieter Lexis wrote: > Hi Dick, > > On 5/10/21 1:02 PM, Dick Franks wrote: > > My objection is narrowly focussed on the escape mechanism, nothing > > more. Changing the delimiter is neither necessary nor relevant. > > > > I am happy to contribute the necessary w

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

Hi Ben, On 10 May 2021, at 12:56, Ben Schwartz wrote: > I don't support breaking the SvcParams into separate RRs across the RRSet. > This would be an extremely inefficient encoding in wire format, I think that assertion may well be worth challenging, and... > and would conflict with the usua

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

Hi Pieter, On 10 May 2021, at 11:23, Pieter Lexis wrote: > You then invite the following issues: > > Clients need to match the tuple (ownername + prio + target) and get all > data from all matched rrsets, whereas now you get all that data in one > piece of rdata. Inviting that issue is also a

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

Hi Joe, On 5/10/21 1:42 AM, Joe Abley wrote: > On May 9, 2021, at 19:27, Paul Hoffman wrote: > >> If I'm wrong about this being as good as it can be, there must be an item >> delimiter that is better than a comma. I am not thinking creatively enough >> to figure out what might be better than a

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

Hi Dick, On 5/10/21 1:02 PM, Dick Franks wrote: > My objection is narrowly focussed on the escape mechanism, nothing > more. Changing the delimiter is neither necessary nor relevant. > > I am happy to contribute the necessary words. If you have the words to fix this issue that would need to cha

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Mon, 10 May 2021 at 00:28, Paul Hoffman wrote: > > On May 9, 2021, at 11:26 AM, Paul Wouters wrote: > > This is all pretty terrible. I agree with Tim that we should not inflict > > this onto the users. Or perhaps we can already pre-allocate some CVE > > numbers for the security issues this w

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On May 10, 2021, at 05:42, Pieter Lexis wrote: >> On 5/9/21 2:01 PM, Dick Franks wrote: >> Pre-processing of '\\,' into the RFC1035 standard '\,' is >> superficially attractive, but also fraught with danger. >> >> A parser could have some fun with this one: >> >>$ORIGIN example.com >>@

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

Hi Dick, On 5/9/21 2:01 PM, Dick Franks wrote: > Pre-processing of '\\,' into the RFC1035 standard '\,' is > superficially attractive, but also fraught with danger. > > A parser could have some fun with this one: > > $ORIGIN example.com > @ SVCB 1 foo > key6="\032\001\013\184\000\000

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Mon, 10 May 2021 at 00:42, Joe Abley wrote: > > On May 9, 2021, at 19:27, Paul Hoffman wrote: > > > If I'm wrong about this being as good as it can be, there must be an item > > delimiter that is better than a comma. I am not thinking creatively enough > > to figure out what might be better

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On May 9, 2021, at 19:27, Paul Hoffman wrote: > If I'm wrong about this being as good as it can be, there must be an item > delimiter that is better than a comma. I am not thinking creatively enough to > figure out what might be better than a comma. I'd be happy to hear proposals > for a bette

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On May 9, 2021, at 11:26 AM, Paul Wouters wrote: > This is all pretty terrible. I agree with Tim that we should not inflict this > onto the users. Or perhaps we can already pre-allocate some CVE numbers for > the security issues this will generate. > > Keep the record simple, we are not going f

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On May 9, 2021, at 08:02, Dick Franks wrote: > >  >$ORIGIN example.com >@ SVCB 1 foo > key6="\032\001\013\184\000\000\000\000\000\000\000\000,\000" >; a.k.a. ipv6hint=2001:db8::5c5c:2c00 This is all pretty terrible. I agree with Tim that we should not inflict this onto th

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Fri, 7 May 2021 at 16:52, Paul Hoffman wrote: > > On May 7, 2021, at 3:21 AM, Pieter Lexis wrote: > > For PowerDNS, we treat the parsing of SVCParams as a two-step process. > > First we use the normal rfc1035 character decoder on the full SVCParam > > value, after which we apply the value-list

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On May 7, 2021, at 3:21 AM, Pieter Lexis wrote: > For PowerDNS, we treat the parsing of SVCParams as a two-step process. > First we use the normal rfc1035 character decoder on the full SVCParam > value, after which we apply the value-list parser. The former parses > 'foo\\,bar' into 'foo\,bar' tha

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

I was rethinking my initial concerns, and needed to talk it out with others. After going back over it with folks smarter than myself, it's more obvious to me that when the need for escaping inputs will be more of an exception. My concern is focused not so much on implementers (sorry) but the opera

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Fri, 7 May 2021 at 11:21, Pieter Lexis wrote: > >8 > > I can see how this might be confusing to those writing zone contents and > would support a solution that either prohibits comma's in SVCParam list > values or a different value separator that is not allowed to be embedded > in values. Tim

  1   2   >