Re: [DNSOP] Last Call: (The ALT Special Use Top Level Domain) to Proposed Standard

On Tue, Mar 14, 2023, at 09:44, Mark Nottingham wrote: > I do wonder whether 'alt' is appropriate -- 'alternative' begs the > question of 'alternative to what?' and the answer is a technical detail > that most Internet users are blissfully unaware of. It seems to me that > it'd be better to

Re: [DNSOP] Breaking the logjam that is draft-ietf-dnsop-svcb-https

On Fri, Feb 24, 2023, at 05:03, Christopher Wood wrote: > +1 to this plan. Once the ECH content is removed from this draft, the > authors of draft-ietf-tls-esni will work to incorporate it there as > necessary. Warren's proposed plan is good. I'm less sure about the various options for

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

On Thu, Sep 8, 2022, at 13:29, Brian Dickson wrote: > If no AliasMode record was processed, then $QNAME would be the origin > name PLUS the prefix(es) of type attrleaf ( underscore thingies). Those > won't be legitimate A/ owner names (and shouldn't exist), and if a > client did that it

[DNSOP] HSTS on receiving a signed HTTPS record (was: Questions / concerns with draft-ietf-dnsop-svcb-https ...)

On Wed, Aug 31, 2022, at 18:39, Brian Dickson wrote: > One additional suggested addition to the end of section 3.1 is: >>If DNS responses are cryptographically protected, and at least >>one HTTPS AliasMode record has been received successfully, >>clients MAY apply Section 9.5 (HSTS

Re: [DNSOP] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

On Wed, Aug 24, 2022, at 08:30, Stephen Farrell wrote: > Currently chromium and firefox disagree on whether ECH is > setup correctly for one of my test pages I'm fairly confident that that is a bug on the Firefox end. The person looking into it has been on leave, but as far as I can tell the

Re: [DNSOP] IANA Policy for SVCB

I agree with Tommy. Selecting an expert who is able to recognize when wider review might help is a far lower bar than the one Ray suggests might be necessary. On Wed, Mar 23, 2022, at 05:29, Tommy Pauly wrote: > If this space is not extensible from non-IETF RFCs, we’ll have missed > the mark.

Re: [DNSOP] IANA Policy for SVCB

On Wed, Mar 23, 2022, at 02:45, Murray S. Kucherawy wrote: > On Mon, Mar 21, 2022 at 2:20 AM Ben Schwartz > wrote: >> [...] any individual I-D is considered a qualified specification as soon as >> it is uploaded to the Datatracker. > > Do you have a reference that asserts this? An I-D that

Re: [DNSOP] IANA Policy for SVCB

I favour #3 over #2 on the basis that you can't reasonably put the "how to convert" text into a registry. On Mon, Mar 21, 2022, at 20:19, Ben Schwartz wrote: > Hi DNSOP, > > The latest draft of the SVCB specification says [1] > >> Entries in this registry are subject to a First Come First

[DNSOP] HTTPS upgrades (was Re: Benjamin Kaduk's Discuss on draft-ietf-dnsop-svcb-https-08: (with DISCUSS and COMMENT))

On Wed, Mar 2, 2022, at 14:18, Benjamin Kaduk via Datatracker wrote: > This (mostly implicit) requirement is a potential barrier for adoption of > the HTTPS RRtype, and while the precondition is very often going to be > satisfied, I wanted to get a sense for whether we should make the >

[DNSOP] SVCB/HTTPS, ECH, and AltSvc

Hey, I've just opened https://github.com/MikeBishop/dns-alt-svc/issues/326 It's a bit long and I won't repeat it here, but I don't think that the current state of the document is good with respect to its handling of ECH and alternative services. ___

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

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

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

Re: [DNSOP] SVCB without A/AAAA records at the service name

oudflare has the only current large-scale deployment of > HTTPS records. > > On Tue, Jan 19, 2021 at 10:00 PM Ben Schwartz wrote: > > > > > > On Tue, Jan 19, 2021 at 7:40 PM Martin Thomson wrote: > >> On Wed, Jan 20, 2021, at 09:17, Ben Schwartz wrote: >

Re: [DNSOP] SVCB without A/AAAA records at the service name

On Wed, Jan 20, 2021, at 09:17, Ben Schwartz wrote: > As I noted in that discussion, the client generally doesn't know in > advance that they aren't needed. I am asserting that the client very much knows. Indeed, it has to know. If we define a new protocol that relies on SVCB and that

Re: [DNSOP] SVCB without A/AAAA records at the service name

On Wed, Jan 20, 2021, at 02:09, Ben Schwartz wrote: > I think #288 is quite "specific" about what happens in that case. > (Whether it's "sensible" is a separate question.) Sorry, I was talking mostly about #299, which has the problem I identified. The problem with #288 is that it doesn't say

Re: [DNSOP] SVCB without A/AAAA records at the service name

On Sat, Jan 16, 2021, at 06:01, Ben Schwartz wrote: > FWIW, I think this is really an editorial question. ... > https://github.com/MikeBishop/dns-alt-svc/pull/288 ... > https://github.com/MikeBishop/dns-alt-svc/pull/289 Neither of these work for me. Both do the same thing in different ways.

[DNSOP] SVCB without A/AAAA records at the service name

As requested (I'm not engaged here enough to understand the terms of engagement, so my apologies for using an interaction form I'm accustomed to), moving discussion from https://github.com/MikeBishop/dns-alt-svc/issues/287 to here: The SVCB draft basically mandates a fallback to A/. I

[DNSOP] Fwd: [TLS] Authenticating incompatible protocols

a rough draft. My initial thinking was that this was general enough that TLS is the right venue, but I can also see reasons for having some discussion here. - Original message - From: Martin Thomson To: t...@ietf.org Subject: [TLS] Authenticating incompatible protocols Date: Tuesday, July

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

On Fri, Jun 19, 2020, at 01:30, Paul Hoffman wrote: > It might be better, and faster, for this WG to adopt a one-paragraph > draft that makes the DS registry "RFC required", like the other > DNSSEC-related registries. I think you mean "Specification Required". RFC required has the same net

Re: [DNSOP] Call for Adoption: draft-belyavskiy-rfc5933-bis

On Wed, Jun 17, 2020, at 04:49, Dmitry Belyavsky wrote: > I don't think there are good or bad time periods to adopt nation-wide > crypto profiles. For me, the difference between the GOST profile and > hypothetical Korean or German profile is close to zero, and if anybody > brings such a profile

Re: [DNSOP] RDBD (Related Domains By DNS)

On Wed, Mar 4, 2020, at 06:11, Brotman, Alex wrote: > https://datatracker.ietf.org/doc/draft-brotman-rdbd/ As I think I mentioned before, there is similar work going on at higher layers of the stack. See https://github.com/krgovind/first-party-sets That work acknowledges a number of things,

[DNSOP] QUIC and udp options

On Fri, Feb 14, 2020, at 05:56, Paul Vixie wrote: > something of this form will likely be created, in order to support quic, a > new > udp based transport protocol which is expected to be used by http/3. Not wanting to distract from Paul's request for consideration of the UDP options draft.

Re: [DNSOP] RDBD draft updated

There's an interesting (web-only) effort looking at a similar problem: https://github.com/krgovind/first-party-sets There, the goal is to establish commonality for the purposes of sharing state (and fate). A great counter-example in that case is the relationship between github.com and

Re: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-12.txt

> Abstract: >This document reserves a string (ALT) to be used as a TLD label in >non-DNS contexts. It also provides advice and guidance to developers >developing alternative namespaces. In discussion, the alternative name .arc was proposed as short for "alternative resolution

Re: [DNSOP] [Ext] Call for Adoption: draft-sah-resolver-information

On Sun, Aug 4, 2019, at 00:37, Paul Hoffman wrote: > > I think that I might have said this before, but I don't think that asking > > an HTTP server about a DNS server is the right solution. > > It is not "the" right solution, but it is one of them. That's why there > is also a DNS-based

Re: [DNSOP] Call for Adoption: draft-sah-resolver-information

On Sat, Aug 3, 2019, at 01:04, Tim Wicinski wrote: > This starts a Call for Adoption for draft-sah-resolver-information I think that I might have said this before, but I don't think that asking an HTTP server about a DNS server is the right solution. If this is information about the operation

Re: [DNSOP] re original_transport indicator

On Sat, Apr 7, 2018 at 9:29 AM, Paul Vixie wrote: > my original design added an http header, which was seen as even worse. > someone suggested adding to the content-type, and i went along with it even > though there is no difference in actual type of actual content. A header

Re: [DNSOP] re original_transport indicator

+1 to this. And maybe there is an outcome that doesn't need this parameter. I probably misunderstood some of the expectations people have for the parameter. With the benefit of time and sleep, it's possible that I now understand the disconnect. My model of content-type - and by extension its

Re: [DNSOP] [Doh] [Ext] Re: Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

On Thu, Apr 5, 2018 at 2:42 AM, Paul Vixie wrote: > that would be low fidelity. i need to run clients whose internet experience > will not be influenced by middleboxes. So don't include the middlebox in your communications. It's all the rage nowadays.

Re: [DNSOP] [Ext] Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

On Tue, Apr 3, 2018 at 11:27 PM, Paul Hoffman wrote: > Martin: Are you saying that you want DOH to remove the optional parameter > from the application/dns-udpwireformat registration? If so, what do you > propose for the DNSOP WG? Right now, abandon

Re: [DNSOP] [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

> > On 3 April 2018 at 15:33, Martin Thomson <martin.thom...@gmail.com> wrote: >> >> This is intended to do what? Indicate where the response came from? >> Why does the client care? > > To keep the proxy (API client and server) transparent and bypass the > middleb

Re: [DNSOP] [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

This is intended to do what? Indicate where the response came from? Why does the client care? I assume that it doesn't apply to requests, or that would get into draft-bellis-dnsop-xpf territory. BTW, you really need to drop UDP from the media type name now.

Re: [DNSOP] [Curdle] WGLC on draft-ietf-curdle-dnskey-eddsa-01

On 4 November 2016 at 09:11, Salz, Rich wrote: > I think the issue about signature contexts first, and mainly, came up with > TLS which generates a variety of private key material based on shared secret > info, and the concern that those different keys could be used for >

Re: [DNSOP] [Curdle] WGLC on draft-ietf-curdle-dnskey-eddsa-01

On 3 November 2016 at 14:55, Daniel Migault wrote: > The version to be reviewed is > https://tools.ietf.org/html/draft-ietf-curdle-dnskey-eddsa-01 Does this use Ed25519 or Ed25519ctx? It describes a context string, which Ed25519 throws away.

Re: [DNSOP] Possible issues with DNS over HTTP wire format draft

Thanks for starting the discussion Shane. On 8 August 2016 at 23:41, Shane Kerr wrote: > My own feeling is that this should be > enough; apparently the recommendation to require TLS was made in the > HTTP/2 working group and rejected, so I am not sure that we need to >