Re: [DNSOP] Last Call: (The ALT Special Use Top Level Domain) to Proposed Standard
This seems fine. 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 choose something meaningful to users. That said, I struggle to suggest anything specific, and we have plenty of examples of seemingly-relative names still working in practice -- e.g., 'New York.' Cheers, > On 14 Mar 2023, at 1:21 am, The IESG wrote: > > > The IESG has received a request from the Domain Name System Operations WG > (dnsop) to consider the following document: - 'The ALT Special Use Top Level > Domain' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits final > comments on this action. Please send substantive comments to the > last-c...@ietf.org mailing lists by 2023-04-10. Exceptionally, comments may > be sent to i...@ietf.org instead. In either case, please retain the beginning > of the Subject line to allow automated sorting. > > Abstract > > > This document reserves a TLD label, "alt" to be used in non-DNS > contexts. It also provides advice and guidance to developers > developing alternative namespaces. > > [ This document is being collaborated on in Github at > <https://github.com/wkumari/draft-wkumari-dnsop-alt-tld>. The most > recent version of the document, open issues, etc should all be > available here. The authors (gratefully) accept pull requests. ] > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/ > > > No IPR declarations have been submitted directly on this I-D. > > > > > > _______ > IETF-Announce mailing list > ietf-annou...@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce -- Mark Nottingham https://www.mnot.net/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Last Call: (Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)) to Proposed Standard
Some things I noticed: * Section 6.1 -- the semantics of 'no-default-alpn' are not actually specified anywhere, as far as I can see; the reader has to infer them from context. * Section 8 -- 'This section specifies the mapping for HTTPS and HTTP.' It would be good if the HTTP Semantics document were referenced here. * Section 8.2.1 -- 'clients are encouraged to offer additional ALPNs that they support.' I think you mean services, not clients. * Section 8.2.2 -- 'The DNS resolution process is treated as an untrusted channel that learns only the QNAME, and is prevented from mounting any attack beyond denial of service.' a) saying that the DNS resolution process is prevented from mounting any attack is a bit odd; perhaps 'being used as a channel for an attack'? b) what about downgrade (as discussed in security considerations)? * Section 8.3 -- ' If present, the HTTPS record's TargetName and port override the alt-authority.' a) The process for applying this override isn't specified; it has to be inferred from the example, and it's not clear for what purposes the override is in effect. b) This effectively changes the Alt-Svc processing, so that implies this document updates that RFC. * Section 8.2 -- ' • HTTPS over TCP to alt.example:443 (Consistent with both Alt-Svc and its HTTPS record)' Probably clearer to say 'HTTP/2' rather than 'HTTPS' here. * Section 8.3 -- ' • HTTP/3 to alt3.example:9443 (Consistent with both Alt-Svc and its HTTPS record)' Clearer to say '(Consistent with HTTP record and not conflicting with Alt-Svc)' * Section 8.3 -- 'The following connection attempts would be allowed only if the client does not support ECH,' Is it *support* or *use*? * Section 8.5 -- 'By publishing a usable HTTPS RR, the server operator indicates that all useful HTTP resources on that origin are reachable over HTTPS' a) What does 'that origin' refer to? http://example.com and https://example.com are two separate origins. b) If I understand the intent correctly here, it means that sites where http:// and https:// are intentionally different won't be able to deploy this record. While they're in the minority, they do exist, so this needs to be carefully considered for impact on deployability (both of the record and protocols that depends upon it). If it remains, this limitation needs to be documented more prominently. * Section 8.6 -- Use of the phrase 'HTTP-based protocols' is going to conflict with the meaning established in BCP56bis. Choose something else? Cheers, -- Mark Nottingham https://www.mnot.net/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] Proposal for a side-meeting on services centralization at IETF 104 Prague
Hi, I'm already starting to pile up conflicts on Wednesday. I'm also very conscious that we had a side meeting about similar issues in Singapore (IIRC), and didn't make much progress at all in that time. Are we going to be able to productively use two hours for this? Could we come up with a more focused agenda and just use an hour? Cheers, > On 12 Mar 2019, at 7:57 pm, Stephane Bortzmeyer wrote: > > On Mon, Mar 11, 2019 at 01:59:25PM -0400, > Allison Mankin wrote > a message of 94 lines which said: > >> Perfect idea, very good use of the Wednesday slot. > > New date and place registered at > <https://trac.ietf.org/trac/ietf/meeting/wiki/104sidemeetings>, > wednesday, Karlin 1/2, 1500 to 1700. (Note there is registry lock side > meeting just before, for domain name industry people.) > > ___ > Doh mailing list > d...@ietf.org > https://www.ietf.org/mailman/listinfo/doh -- Mark Nottingham https://www.mnot.net/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Accounting for Special Use Names in Application Protocols
I like it; will append to the issue. Thanks. > On 5 Feb 2019, at 11:50 am, Joe Abley wrote: > > Hi Mark, > > On 4 Feb 2019, at 19:30, Mark Nottingham wrote: > >> I've modified that slightly to come up with this proposal: >> >> """ >> HTTP and HTTPS URIs rely on some name resolution mechanism(s) to interpret >> the authority field and ultimately convert it into an identifier (typically, >> IPv4 or IPv6 addresses). Often, this is DNS [ref]. >> >> When DNS is consulted for resolution of the authority field, this >> specification requires adherence to the requirements that all registered >> special use names [RFC6761] place upon applications; if they are not >> honoured, security, privacy and interoperability issues may be encountered. >> """ >> >> Make sense? > > I confess I have not being following this thread as closely as perhaps I > should, but the text above strikes me as odd. > > RFC 6761 describes a registry of special *domain names* -- it's talking about > the namespace, not the resolution protocol. In some cases the registry > directs applications to use different resolution protocols (protocols other > than the DNS) to look things up. The LOCAL and ONION domains are examples. > It's the contents of the registry that are important, not that subset of > initial registry contents that are specified in RFC 6761, as I think Tony > pointed out. > > The text you suggested could suggest that an application should consult the > DNS for a name that ends in LOCAL and simultaneously satisfy the requirements > implied by LOCAL's presence in the Special-Use Domain Name registry, which > include not using the DNS. This doesn't seem particularly clear. > > Since I've been staring out of the window for the rest of the thread thinking > vaguely about lunch it seems a bit presumptuous to suggest alternative text, > but perhaps something like this would be better: > > --- > Resolution of the authority field MUST adhere to any special requirements > documented in the Special-Use Domain Names registry [ref] which might specify > that some protocol other than DNS be used for resolution for names within a > particular domain. If those special requirements are not honoured diligently, > security, privacy and interoperability problems might well result. > > For example, consider the authority field EXAMPLE.LOCAL, intended to resolve > to an address on a local, private network using the Multicast DNS resolution > protocol [RFC6762]. If the DNS was used as a resolution protocol, the > existence of the local-scope name EXAMPLE.LOCAL and this particular instance > of its use might be revealed to third-party DNS servers; there is also a risk > that attacks on the DNS system outside the local network could cause the > EXAMPLE.LOCAL name to be resolved to an external, third-party address with > attendant risks to privacy and security for higher-layer protocols and the > application itself. Such risks are avoided by ensuring that resolution of > names in the LOCAL domain are only attempted by the application using the > Multicast DNS protocol. > --- > > > Joe > -- Mark Nottingham https://www.mnot.net/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Accounting for Special Use Names in Application Protocols
I've modified that slightly to come up with this proposal: """ HTTP and HTTPS URIs rely on some name resolution mechanism(s) to interpret the authority field and ultimately convert it into an identifier (typically, IPv4 or IPv6 addresses). Often, this is DNS [ref]. When DNS is consulted for resolution of the authority field, this specification requires adherence to the requirements that all registered special use names [RFC6761] place upon applications; if they are not honoured, security, privacy and interoperability issues may be encountered. """ Make sense? Thanks, > On 9 Jan 2019, at 1:23 pm, Brian Dickson > wrote: > > > On Tue, Jan 8, 2019 at 4:21 AM Tony Finch wrote: > Brian Dickson wrote: > > > I think it might be good to scope the 6761 issue, with something like the > > following: > > [SNIP] > > > > I.e. it is necessary to recognize all special use names, and necessary to > > > not resolve such names via DNS. > > That's going too far: special-use domain names must have specific > instructions to application authors, which might say not to use the > DNS or might say to use the DNS as usual. > > Hi, Tony, > You are, of course, right. I think what I meant was, for the specific case of > .onion, (what I said), > and for the general case, (what you said). I.e. wherever an RFC for specific > special use name exists, > as linked by the IANA registry, those particular instructions MUST be > followed, especially if not following > those rules might/would break things (like the case of .onion vs DNS). > > Brian > > > David Schinazi's comment on the GitHub issue about referring to the IANA > registry is good, and perhaps more useful than referring to RFCs directly. > > Tony. > -- > f.anthony.n.finchhttp://dotat.at/ > Trafalgar: Northeast 3 or 4, increasing 5 at times. Moderate. Fair. Good. -- Mark Nottingham https://www.mnot.net/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Accounting for Special Use Names in Application Protocols
Hi DNSOP, In the HTTPWG, we have an open issue about how to account for .onion in HTTP URL processing: https://github.com/httpwg/http-core/issues/10 Our discussion led us to believe we'd do better to have a general statement about special-use names when dereferencing HTTP URLs. It's possible such text might end up here: https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#http.uri along with the following section on HTTPS, and of course in Security Considerations. Do folks have thoughts about what it should say, and would any one be willing to help? Cheers, P.S. I haven't CC'd the HTTP WG to avoid issues with cross-posting; I'll point the WG at discussion here. -- Mark Nottingham https://www.mnot.net/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] SRV and HTTP - 18:30 Tuesday (room change)
Room change - we're now in Square Dorchester (the bigger room). Cheers, > On 10 Jul 2018, at 10:25 pm, Mark Nottingham wrote: > > 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 wrote: >> >> 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 still though >> shifting it a little earlier, like 18:30. >> >> _______ >> DRIU mailing list >> d...@ietf.org >> https://www.ietf.org/mailman/listinfo/driu > > -- > Mark Nottingham https://www.mnot.net/ > > -- Mark Nottingham https://www.mnot.net/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 wrote: > > 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 still though > shifting it a little earlier, like 18:30. > > ___ > DRIU mailing list > d...@ietf.org > https://www.ietf.org/mailman/listinfo/driu -- Mark Nottingham https://www.mnot.net/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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: >>> >>> 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? >>> >> >> I recently did some digging on this topic, and can try to characterise what >> the issues / objections are. > > 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. > > All of these issues are trivially easy to fix. It just require willingness > to implement. > > 1) is addressed by defining a new type(s) rather than using prefixes. > 2) is addressed by getting recursive servers to fill in missing additional > data before returning. Named has code in review for this for SRV as proof of > concept. > 3) is addressed by adding some signalling between the client and recursive > server to indicate if the additional section is complete or not. > > >> Would people be interested in a (hopefully brief) side meeting to discuss >> and maybe come to a shared understanding of the problem space? >> >> Cheers, >> >> -- >> Mark Nottingham https://www.mnot.net/ >> >> _______ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org -- Mark Nottingham https://www.mnot.net/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Some thoughts on special-use names, from an application standpoint
he name held back. > > I don't entirely see these reasons emerging. I see the opposite. I see > expediency from apps communities, seeking to use .magic tricks to avoid > cost explicitly in their layer, but at a cost of polluting the public > commons. What *exactly* is the cost? Everything you have brought up above (excepting "architecture") is regarding the potential impact upon applications -- impact that was considered and accepted by the people doing the registration of .onion. How does this affect DNS itself? And, are you really saying that anything that hasn't gone through ICANN is by definition "pollution"? Very thought-provoking analogy between Internet naming and enclosure there, BTW. > I am pretty firmly in the camp which says the revision of the RFC should be > complete: we stop doing this, and people who want names go into ICANN > process to establish them. That's certainly a choice that can be made, but it seems pretty unilateral -- just as much as (for example) the W3C deciding that HTTP URLs in browsers don't always use DNS as a root of naming and setting up an overlay registry (as is seemingly already contemplated by the HTTP and URL specs). I'd hope that we could work together as a community to find some agreement here, rather than going straight to absolutist positions. Cheers, -- Mark Nottingham https://www.mnot.net/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Some thoughts on special-use names, from an application standpoint
RFC7230 Section 2.7.1 says this about hostnames in HTTP URLs: """ If host is a registered name, the registered name is an indirect identifier for use with a name resolution service, such as DNS, to find an address for that origin server. """ ... which builds on how RFC3986 Section 3.2.2 talks about hostnames in URLs and URIs: """ The presence of a host subcomponent within a URI does not imply that the scheme requires access to the given host on the Internet. In many cases, the host syntax is used only for the sake of reusing the existing registration process created and deployed for DNS, thus obtaining a globally unique name without the cost of deploying another registry. However, such use comes with its own costs: domain name ownership may change over time for reasons not anticipated by the URI producer. In other cases, the data within the host component identifies a registered name that has nothing to do with an Internet host. We use the name "host" for the ABNF rule because that is its most common purpose, not its only purpose. """ So, the Web architecture already has baked in a notion of multiple mechanisms for location within a single name space. Indeed, the flexibility of multiple location mechanisms might be required to address issues like domain name ownership changes. Given this context, I was disturbed to hear the design team presentation in Yokohama suggest that we "remove the value of a top-level domain" as a potential solution (around 49:30 in the meetecho recording). To me, this fundamentally misses the point; the value of a single naming root with flexible location is a community good, and cannot be removed just to make life easier for DNSOPS. The impact goes far beyond DNS. In the ensuing discussion, Andrew Sullivan's comments (at around 58:00) made the most sense to me. The problems that draft-adpkja-dnsop-special-names identifies (e.g., "what technical criteria should the evaluation body use to examine the merit of an application for such a reserved name/protocol switch", "With regard to the actual choice of name, [RFC6761] is silent") are already handled by our normal processes, where we invest technical authority to judge in bodies like the IESG, and document an appeals process. It's also far from clear that we *need* to have only one path to a new special-use name (as section 6.2.1 seems to desire). While I appreciate that the .onion discussion was a prolonged headache for DNSOP, and that perhaps in the future other venues should be used, deciding how to handle the general issue of naming based upon its impact on *one* location protocol community doesn't seem appropriate. If this effort is to do more than make modest clarifications to RFC6761, I'd suggest that we consider moving it elsewhere. Kind regards, P.S. The draft begins: """ In recent years, using the last label of a domain name (aka TLD) as switch to indicate how to treat name resolution has been experimented using the framework of [RFC6761]. """ This framing is incorrect. RFC6761 is a Proposed Standard, not Experimental. -- Mark Nottingham https://www.mnot.net/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Last Call: draft-ietf-dnsop-onion-tld-00.txt (The .onion Special-Use Domain Name) to Proposed Standard
Kevin, On 11 Aug 2015, at 6:54 am, Darcy Kevin (FCA) kevin.da...@fcagroup.com wrote: In retrospect, the definition of the “http” and “https” schemes (i.e. RFC 7230) should have probably enumerated clearly which name registries were acceptable for those schemes, so that the following language from RFC 7320 (a BCP) could be invoked against any attempt by an app – Onion or anyone else -- to inject their own unique brand of “specialness” into the interpretation of the Authority component of their URIs: Scheme definitions define the presence, format and semantics of an authority component in URIs; all other specifications MUST NOT constrain, or define the structure or the semantics for URI authorities, unless they update the scheme registration itself. 7230 casually mentions DNS and “network host table” as name registries that can potentially be used for “http” and/or “https”, but never implies that those 2 constitute the only members of the set. If both injecting “specialness” into the URI, and updating the “https” scheme itself, were viewed as unavailable or unappealing options, then Onion – and anyone else who follows the same path – would be left with no other choice but to define their own scheme. I think that would be a bad outcome indeed. Viewing this as injecting specialness into the URI is counter to the clear examples that Alec just gave of non-HTTP-based (and, indeed, non-URI-based) uses of .onion. So, I can't imagine what end such restrictions would serve, except as a (fairly artificial) way to frustrate the registration of .onion. I'd also point out that such an approach might place procedural barriers in place of getting .onion or something similar recognised, it would not significantly hinder its deployment — as evidenced by .onion itself. Regards, -- Mark Nottingham https://www.mnot.net/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List - Please move discussion to dnsop
While this thread isn't necessarily off-topic for ietf-http-wg list, it's more relevant IMO to dnsop, and cross-posted high-volume discussions tend to be distracting. So, please try to move discussion onto the dnsop list (I've set Reply- To accordingly). Thanks, -- Mark Nottingham http://www.mnot.net/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
