[DNSOP] Re: [EXT] Re: New Version Notification for draft-nottingham-public-resolver-errors-01.txt
> Il 26/02/2025 08:20 CET Mark Nottingham ha > scritto: > > The intent is not to scale to that degree -- indeed, that would be considered > a failure, because it would indicate widespread censorship on the Internet. > Instead, it's to selectively surface legally mandated censorship when it > impacts 'large' services (such as public resolvers) to raise user awareness > and reduce confusion. This depends on the definition of "censorship", and also on whether you envisage this system only for EDE 17 (user-requested blocking) or also for EDE 16 and 15, which should be used for law-mandated and operator's-own-initiative blocking. In any case, a lot of countries mandate some kind of blocking (the USA might join the list soon, apparently - see the new FADPA proposal), and AFAIK there are many ISPs that proactively block phishing etc, so, in case of success, I would expect the number of resolver operators that need an operator ID to be at least in the thousands, perhaps an order of magnitude more. On the other hand, most ISPs could be too "low tech" to use this mechanism, so the list might be kept short by lack of adoption. > > possibly the browsers should focus on controlling what kind of message is > > presented to the users, rather than who is sending it. > > If you have a means of doing so without increasing the risk of arbitrary > censorship that *isn't* legally mandated, I'm very receptive. I need to understand your threat model, then. Are you concerned about someone injecting phishing URLs as fake blocking messages? If so, perhaps the best solution would be to implement some kind of content-based and metadata-based heuristics that would also help against any other phishing attempt (not sure how well this could work, of course, but somehow browsers could use the same sources of abusive domain lists that ISPs employ, or AI). On the other hand, are you concerned about resolvers blocking arbitrary stuff? In this case, I think that making "censorship" (however defined) visible to the end-user by showing the ISP's message that says "censored" would actually help countering it, as it could create end-user outrage and motivate the end-user to change resolver or ISP. If the browser ignores the message and just lets the connection drop, the user will think that "the Internet doesn't work" and not do much. In the end, this draft is about showing the resolver's message or not, not about accepting the resolver's blocking or not - unless what you imagine is that browsers will "re-resolve" blocked domains when they come from unknown/untrusted sources but not when they come from a trusted resolver. > From my standpoint, it's necessary to have some party making a judgement call > about who is using this mechanism responsibly, and while I share your > discomfort with concentration of power, browser vendors are well placed for > this, experienced in making such calls, already in place, and seemingly > distant from any significant conflict of interest (at least as far as I can > see). I think that any government's viewpoint on this point would be dramatically different from yours :) In the EU, we just had a EUCJ ruling that Google cannot legally exclude from Android Auto third party apps on the grounds that they do not meet their unilaterally imposed requirements, if this alters market competition. In cases where the browser maker is also a significant player in the resolver market, the conflict of interest is obvious. In cases where the browser is recognized as a gatekeeper service, in the EU there also are constraints on what it can do. Personally, I think that the only party that should decide whether to trust whatever comes from their resolver is the end-user, rather than an intermediary. If you don't trust a resolver or dislike its policies, just pick another one; if you continue using it, then it would be better for you to receive the information made available by the resolver you use. So my threat model is just about an attacker faking the DNS response, not about a malicious resolver. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: Fwd: New Version Notification for draft-nottingham-public-resolver-errors-01.txt
> Il 22/02/2025 01:40 WET Mark Nottingham ha > scritto: > > > Hi DNS folk, > > See draft below for an update based upon feedback received. Note that the > short name of the draft isn't really accurate any more, since some of the > feedback was that this could/should be potentially applicable to other > resolvers too. > Was there any consideration of the potential workload that this model would put on IANA? If each resolver of the planet (or even just each resolver run by an entity that provides Internet connectivity services to end-users) had to register and get a resolver ID, the registry could become quite sizeable - but perhaps this would not be an issue. In general, I am not too convinced by this proposal. Authenticating these error messages a little better through the registry + URI (domain name) control mechanism could be a positive thing, but only if it does not contribute to the gatekeeping of user communication by the browsers. In fact, at the end of section 1 the draft states clearly that the mechanism will allow web browsers to decide which resolver operators (ISPs etc) will be allowed to show explanatory messages to end-users when enacting filters, and this is yet another centralization of control into the browser oligopoly. I see the potential risk in enabling any resolver to show arbitrary messages to users, but possibly the browsers should focus on controlling what kind of message is presented to the users, rather than who is sending it. Also, if in the end the deciding element for the trust is the domain name in the URI, then the registry does not add much to it, unless IANA is expected to do some trustability checks on applicants before adding their entry. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com mailto:vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: Working Group Last Call draft-ietf-dnsop-structured-dns-error
> Il 26/10/2024 22:10 CEST Benno Overeinder ha scritto: > > If you believe this draft is ready for publication as an RFC, please > state your support. Conversely, if you feel the document isn’t ready > for publication, please provide your concerns and reasoning. I support publication (with an additional, optional language tag if the authors are ok with it and we can still sneak it in). Ciao, -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-explicit-forged-answer-signal-00.txt
> Il 11/01/2024 03:50 CET Lanlan Pan ha scritto: > > > Thanks Paul. > > Paul Wouters 于2024年1月10日周三 23:01写道： > > As I've said during the discussions on RBL and an updated version for > > RBL, if these things are done "for the user", the best thing is to put > > the censored answer in the authority section. This way ignorant clients > > keep working with the censor, but knowledgable clients can DNSSEC validate > > the censorship using the original answer and optionally present a choice > > to the enduser. It also prevents censorship forced against the user's > > interest. eg it makes this properly optin (eg compliant with RFC 8890) > > The explicit faked answer signal: > - In Format 1, it follows EDE, in additional section. > - In Format 2 , it is an TXT RR, in authority section (same as faked answer). > I will revise it. > > Knowledgable client can make its own reaction, if it gets a explicit signal > that it has received a faked answer. > This can mitigate the HTTP cookies leak, especially on NXDOMAIN redirection > case. I'm not against this, but I don't see which kind of resolver operator would want to use it. There are only two possibilities: 1. the forging is made cooperatively, to protect the user themself, so the user actually asked the resolver to block certain destinations and send back a pointer to an error page; in this case, the client has no reason to try any of the circumvention strategies you describe in section 5, and doing this could actually endanger the user; 2. the forging is made adversarially, to protect other users from whatever this particular user is trying to do with the Internet; in this case, the server has no reason to tell the client that something special is happening, as it needs to prevent the client from circumventing the block; so it will not add any signal to the answer. Even in case 2, resolvers who want to be more transparent and don't want to forge any answer could just say no + EDE 15-18, at least when that will be supported by browsers. Can you see a use case that would motivate people to implement this new mechanism? -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-structured-dns-error: suberr registration policy
> Il 18/04/2023 15:54 CEST Benjamin Schwartz ha scritto: > > > > > On Tue, Apr 18, 2023 at 7:49 AM Ralf Weber mailto:d...@fl1ger.de> wrote: > > > Moin! > > > > On 18 Apr 2023, at 13:11, Benjamin Schwartz wrote: > > > > > The draft's opening words are "DNS filtering is widely deployed for > > > network > > > security". This is true, but by far the "widest" deployment of DNS > > > filtering is for authoritarian national censorship, to prevent citizens > > > from engaging with forbidden ideas. > > > > Do you have any data to back this claim up? > > > > According to Freedom House, 64% of Internet users "live in countries where > political, social, or religious content was blocked", and "51% live in > countries where access to social media platforms was temporarily or > permanently restricted". > (https://freedomhouse.org/report/freedom-net/2022/countering-authoritarian-overhaul-internet) > In my experience, DNS-based censorship is used for a majority of these > blocks (often in concert with other methods). > Ok, so now you just need to prove that that all those countries are "authoritarian" and that all blocking of social media or other content is "censorship". This really depends on the report's definition of "political, social or religious" - if a country blocks nazi or terrorist propaganda or CSAM or social fake news or the unauthorized streaming of movies, is that classified as "censorship of social and political content"? Many here would disagree, or at least find that censorship highly desirable. But, more usefully: there is wide disagreement across the planet and even within the Internet community on what constitutes "censorship". I do not think that it is acceptable for the IETF to withhold standardization that is useful for those who provide filtering systems, and do so on policy grounds. Who ever gave the IETF the authority to decide whether country X or operator Y should be allowed to block certain types of content? Also, in practical terms, the real authoritarian countries won't bother anyway, but not having a way to provide meaningful information in reasonable filtering contexts (e.g. blocking illegal content in a European country) will just damage end users without reducing the extent of filtering in any way. At the same time, your objections on how hard it is to agree on categorizations are valid. Of course any explanation of reasons for filtering that comes from a resolver should be taken at face value and at the same time presented as only worth as the trust one puts in one's resolver. Users are not required to believe or agree with the explanation, but it would still be useful for them to know it, especially in the many cases in which the filtering was actually requested by the user (e.g. parental controls). It may actually help them in evaluating the reliability of the service and choosing whether to continue using it or not. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com mailto:vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: Structured Data for Filtered DNS
> Il 22/01/2023 21:36 CET Tim Wicinski ha scritto: > > If you work for someone who is interested in this, please let us know. > If you work for someone who has customers interested in this, please let us > know. > If you plan on implementing this (or not!), please let us know. > We definitely plan to implement this in the PowerDNS platform once it's done. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com mailto:vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Possible alt-tld last call?
> Il 20/10/2022 10:15 CEST Eliot Lear ha scritto: > > As a matter of practicality, a registry surely will be form. It is > simply a matter of whether the IANA will host it. If the IANA does not > host it, then by shifting it elsewhere this group is actually weakening > the IANA function, and that would be sad. But IANA is not the registry for everything under the sun, it is the registry for things that fall under the purview of the IETF and are part of IETF standards. If we agree that names under .alt do not belong to and at the IETF, then it makes no sense for IANA to register them, nor this would be a wound to its role. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Possible alt-tld last call?
> Il 17/10/2022 08:44 CEST Eliot Lear ha scritto: > > Let's please leave Internet lawyering to lawyers. If people want a > legal opinion on this draft, the IETF does have resources for that. > > [...] > > No matter what we say in the ALT draft, someone could burden the IETF > with a new draft. People do so every day. If it gains sufficient > support, it would have to be at least considered, no matter the topic. > And again, I suspect most of these sorts of documents are more likely to > flow to the ISE or perhaps a future IRTF RG. As the current ISE, that > is a burden I would gladly bear, because there is the opportunity to > help the Internet community, including the IETF and ICANN. > > I also have no problem rejecting trivial or bad proposals. Well, I'm just waiting for the request to register amazon.alt. (or xxx.alt, or ru[ssia].alt, or .alt, which some people will do just for fun) Unless, of course, you mean that the ISE will adjudicate trademarks, define which strings are offensive and determine whether an applicant has the right to use the name of a country or geographical entity, thus deciding whether a proposal is "trivial or bad" or not. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [EXT] Re: draft-schanzen-gns and draft-ietf-dns-alt-tld
> Il 08/08/2022 12:16 CEST Independent Submissions Editor (Eliot Lear) > ha scritto: > > I caution against those approaches that would set such a high bar that they > would require researchers to fork out hundreds of thousands of dollars on > application fees alone plus who knows how much else for, as someone else > wrote, an uncertain outcome. They'll simply go elsewhere. That in itself > would encourage squatting (or whatever you want to call it). The benefits of > avoiding squatting accrue not only to those researchers, but to those who use > their technology, and others as well. > I apologize for being the nasty guy with the colourful language (by the way, again, this is not a technical discussion but a policy one), but given the above, I would really like to hear your answer to these questions: 1) Why should these people get for free something which everybody else is required to pay $200'000 for? 2) You are basically saying that we should give these people a $200'000 house for free and make it the best house we can offer, or else they will just ignore the rules and squat the one they like the most. Do you really think that we should yield to this kind of reasoning? -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com mailto:vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [EXT] Re: draft-schanzen-gns and draft-ietf-dns-alt-tld
> Il 04/08/2022 14:37 CEST Schanzenbach, Martin ha > scritto: > > You are trying to kill it using, what, political arguments? Yes. There is nothing technical in this discussion. We are not arguing over wire formats or algorithms, we are arguing about names and ways to gain control over them, i.e. policy. Indeed, many outside of the IETF think that the IETF does not even have the authority to approve anything like what you are proposing. (Don't mention .onion, it was a mistake.) > Is the DNS namespace and its billion dollar industry so fragile that it > cannot handle experimental alternative domain name resolution mechanisms that > may be used for resolve "DNS-compatible" names as well? If your proposal: 1. does not allow the creation of new DNS names (TLDs or others) outside of the established registration policies; 2. does not allow to redefine, redirect or control names that already exist in the DNS namespace; then it is an "alternative domain name resolution mechanism". If it allows any of the two functions above, and as I understand it does, and does so in a way that can be shared across the global Internet, then it is not a resolution mechanism but a namespace expansion and even a new name creation policy, and also it does potentially fragment the Internet. > And if the IETF is, as you insinuate, some kind of guardian of that industry > that relies on the existing infrastructure, what chances would any proposal > have going through the respective processes in the future? Zero. But you seem to think that the IETF is required to approve whatever proposal it receives, and it is not, even in the independent submission stream. Still, you seem to miss my general point, which is not about what I may think of your objectives (indeed, I hate centralization as well, though this is one of the few centralized arrangements for which there are valid reasons). My point is that you cannot plan a revolution and at the same time ask parts of the system that you are trying to overturn to rubberstamp it. If you want the stamps, then you have to turn the revolution into an evolution and accept some compromises, such as "!gns" or whatever else. It may actually be a more productive strategy in the long term. If you want a revolution, then you have to be prepared to fight against the system. I easily see people in several (non-EU) countries getting the police at their door if they start using your system for the purposes that you declare right at the top of your draft. That's just how the world works. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-schanzen-gns and draft-ietf-dns-alt-tld
> Il 04/08/2022 08:40 CEST Martin Schanzenbach ha > scritto: > > Anyway, going to ICANN in order to collect a TLD is not a reasonable process > for > publishing our draft. > We would not even know what the process would be (after the RFC? before > writing it? While writing it? What if ICANN denies a request? All the > work is moot?) > Similarly using "www.example.com!gns" et al. is not a reasonable change. > As that impairs usability and is incompatible with applications that > expect domain names. The problem is that your entire project is conceptually and politically flawed. If you want to establish an alternative namespace to the DNS, then you should not use DNS-compatible names. If you want to establish a different way to create or redefine actual DNS names in a non-local, shareable way, like your draft seems to do for "example.pet", then you are going to break the uniqueness of the Internet and you should be damned. If you want to establish a different way to resolve actual DNS names, then you should come here and propose a revision of the DNS protocol, or an entire new protocol to replace it, and have it standardized by the IETF, or rejected if the community disagrees with you. Also, if you think that your project requires a valid TLD in the existing DNS namespace, then you should get one following the same procedures as everybody else, which means either applying for a string to ICANN, or getting an IETF Standards Action specification as required by RFC 6761 section 4. An independent RFC would not meet these requirements, and I do not see why the ISE should ever publish it, except to create more confusion and more arguments. More generally speaking, the DNS today is both a several billion dollars industry and a fundamental, regulated instrument for the political and socioeconomical stability of the entire world, way more than it is an IETF protocol. People are free to introduce politically motivated attempts to disrupt the current balance, but they should not expect cooperation, not any well-behaved global institution should provide any. Even if some of us may individually like the idea, as an institution the IETF is part of a bigger arrangement that it cannot unilaterally challenge without losing its face. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSOP Document Adoption Poll (June 2022)
> Il 12/07/2022 15:02 Tim Wicinski ha scritto: > > Our Poll answers are "Adopt Now","Adopt Not Now", and "Don't Adopt" > We mapped these responses to 1, 0, -1 (no answer is also 0). > > > Final Results: > > * draft-sahib-domain-verification-techniques, 14 > * draft-dwmtwc-dnsop-caching-resolution-failures, 13 > * draft-rebs-dnsop-svcb-dane, 12 > draft-klh-dnsop-rfc8109bis, 7 > draft-wing-dnsop-structured-dns-error-page, 2 > draft-dulaunoy-dnsop-passive-dns-cof, -2 > It would be useful to get the full results, to be able to tell between these two cases: 1. some drafts did not get many points because very few people are interested in them (so mostly zeroes and a few ones); 2. some drafts did not get many points because several people are interested in them but several others actively oppose their adoption (so both ones and minus ones). This would help the authors in deciding whether changes in the draft (or better information about its usefulness) could lead to adoption, or whether the work is not welcome here and should move elsewhere. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com mailto:vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] updated to draft-wing-dnsop-structured-dns-error-page-01
> Il 10/11/2021 17:17 Petr Špaček ha scritto: > > 1. Input from browser vendors > - > I believe we really really _really_ need input from end-client vendors, > most importantly Google Chrome and Safari. Is there any indication that > they might be interested? If not, why? I don't want to speak for them (I don't know if they are on this list, but they definitely are on ADD) but in past discussions around this concept they recognized its potential usefulness (apart maybe from a specific browser which seems to have a principle stance against DNS filters) but were concerned about the security of the mechanism, i.e. the risk that it could be used to present to the user a phishing or misleading page, either by an attacker or by the network itself, with the risk of the user not realizing that this is not their intended destination but a page generated by someone else. This explains many of the restrictions and requirements in the document, including the restriction to encrypted DNS connections. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons
> Il 01/01/2021 19:42 Stephen Farrell ha scritto: > > > Hiya, > > On 01/01/2021 17:58, Paul Hoffman wrote: > > The WG has already adopted the revised GOST document as a WG item; > > what you are proposing (if the current use is negligible) would be in > > the opposite direction. > I wasn't "proposing" that, just posing it as a possible > option that might or might not be sensible to consider > depending on the facts relating to usage if/when we can > get 'em. Absent usage information, I'm not at all sure > whether or not any change from the status quo is warranted. We could ask the proponents of new algorithms for information on current or expected usage. However, if adoption is relevant to any kind of decision on what to do with an algorithm proposal, this should better be formalized somewhere and applied evenly to all algorithms that may appear in the future. Personally, I think that some expectation of adoption would be useful not to clutter the list of algorithms, but the threshold should be quite low. Also, as the IETF is the global SDO for DNS, it should make sure to encompass the needs of all Internet communities around the world. If a local community wants or needs for any reason to use a "globally non-standard" algorithm, there should be ways for this to happen without asking them to prove adoption of that algorithm on a global scale. Eric's points on fragmentation, implementation burden, potential incompatibilities are valid, but they should play out at usage level, not at the standardization one. We should just make it clear to proponents that adopting a rare algorithm may make them incompatible with the rest of the planet, but whether this is acceptable or not is up to them - and they may even not have a choice, due to non-technical factors which won't be affected by whether we recognize the algorithm or not. In this regard, having an intermediate "supported but not globally recommended" classification level, with lower procedural barriers, seems like a useful thing to me. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Meeting feedbacks/summary on draft-bretelle-dnsop-recursive-iprange-location
> Il 20/11/2020 18:49 Brian Dickson ha > scritto: > > But let's not get distracted by that in the short term, where direct use > of resolver geo has real value. > Also, legal/jurisdiction issues depend on geography and not on network topology. As data localization and privacy protection issues around resolvers are growing in importance, a systematic way of knowing which jurisdiction applies to a resolver may (hypothetically, with no immediate use cases right now) become useful. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com mailto:vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-svcb-https: HTTPS RRtype versus STS
> Il 26/10/2020 08:41 Ralf Weber ha scritto: > > I also think that any list hardcoded in browser/OS deployments is a bad > idea for a long term solution (that include auto upgrades of DoH servers > ;-) and it looks like STS has already shown that. DNS being an > distributed mechanism is far better suited as it does not require an > update of the end device. In fact, this "client-side hardcoded list vs TOFU discovery vs dynamic discovery via DNS" discussion - also addressed by the post - comes up quite often in a number of different places (HTTPS, DoH, DANE/MTA-STS...). I also think that dynamic discovery is better and is the only solution fully in line with the decentralized nature of the Internet, but I see the performance and security advantages of hardcoding some values that are known to be valid and stable (e.g., in the case of HTTPS, Google could do that for their own properties). Perhaps a general analysis and best practice document on this topic could be useful. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Question regarding RFC 8499
> Il 07/08/2020 12:02 Michael De Roover ha scritto: > > > > Personally I don't > > > see anything controversial in it. > > > > I suspect you haven’t suffered structural racisms because if the > > colour of your skin and because of what happened to your grand > > parents ? > On a more personal note, my great-grandparents died in the gas chambers > in the second World War. The only reason why I'm even alive is because > one of them survived - my great-grandmother. So if I may, I do take > offense on this. Well clearly in 2020 I can take offense on just about > anything. Apologizing in advance for the procedural remark, can I ask what's the point of discussing text in an already released document? If anyone is unhappy with that, they should just propose another draft that updates/obsoletes that document. Also, at this point in time, there is no IETF policy or community consensus yet on the mandatory replacement of any term, so the decision on that stands with the authors of each document and ultimately with the group that needs to get to consensus on the document. Anyone is free to propose a new draft that uses "master/slave" or a new terminology document that specifies those terms for some use cases. Then, we will see if it ever gets consensus (I doubt so). However, I also find it inappropriate that people that disagree with that change, generally for reasons of clarity and backwards-compatibility that have nothing to do with racism, are immediately accused of being insensitive or even sympathetic to racism (moreover, racism against a specific ethnicity in a specific country, even if some participants almost never met any person from that ethnicity and country in their whole life, let alone discriminated them). This also has to stop, as it does not lead to any useful discussion. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-reddy-dnsop-error-page-00.txt
> Il 09/07/2020 08:53 tirumal reddy ha scritto: > > > > > Regarding section 4, in DPRIVE (on draft bcp-op) we have > recently been told that the IETF does not recommend in its best practices > anything which is not strictly technical (in that case, it was about > communicating to users the jurisdiction under which DNS resolution is > provided): > > > > > > https://mailarchive.ietf.org/arch/msg/dns-privacy/rJ7R3OBUyySfEyJgwhoxs1DNGuc/ > > > > So I would assume that that section is out of scope as well, and I > > would remove it. > > > > > > My understanding is the "jurisdiction" is out of scope but not RPS (see > https://tools.ietf.org/html/draft-ietf-dprive-bcp-op-12#section-6) > Sure, those three points were agreed with Alissa as the scope of any statement that might be described in the best practice: o Relates _only_ to matters around to the technical operation of DNS privacy services, and not on any other matters. o Does not attempt to offer an exhaustive list for the contents of an RPS. o Is not intended to form the basis of any legal/compliance documentation. So I would take that as guidance here as well: I don't think we can say whether it should contain regulatory information, redress measures etc. (though that would indeed be advisable). Also, in Italy the ISP, when blocking websites by court order, is required to show a page which is exactly defined by law and by the public authority that "seized" the website (e.g. https://www.startmag.it/wp-content/uploads/butac.png ) - it is not allowed to change it in any way. I would expect that to happen in other countries as well. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com mailto:vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-reddy-dnsop-error-page-00.txt
> Il 08/07/2020 09:37 tirumal reddy ha scritto: > > > Hi all, > > This draft https://tools.ietf.org/html/draft-reddy-dnsop-error-page-00 > discusses a method to return an URL that explains the reason the DNS query > was filtered. It is useful for HTTPS enabled domain names blocked by DNS > firewalls for non-managed devices in Enterprise and Home networks. The error > page URL is returned along with the "Forged Answer" extended error code > defined in ietf-dnsop-extended-error. > > Comments and suggestions are welcome. > This would be actually useful in real world use cases, together with the new EDE codes, so it would benefit from standardization. Regarding section 4, in DPRIVE (on draft bcp-op) we have recently been told that the IETF does not recommend in its best practices anything which is not strictly technical (in that case, it was about communicating to users the jurisdiction under which DNS resolution is provided): https://mailarchive.ietf.org/arch/msg/dns-privacy/rJ7R3OBUyySfEyJgwhoxs1DNGuc/ So I would assume that that section is out of scope as well, and I would remove it. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com mailto:vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] definitions of "public DNS Service"
> Il 22/05/2020 18:59 Tony Finch ha scritto: > > I think despite what Paul H. said this is already covered in RFC 8499: > >Open resolver: A full-service resolver that accepts and processes > queries from any (or nearly any) client. This is sometimes also > called a "public resolver", although the term "public resolver" is > used more with open resolvers that are meant to be open, as > compared to the vast majority of open resolvers that are probably > misconfigured to be open. Open resolvers are discussed in > [RFC5358]. I think this definition is good - perhaps what we need is just to agree to use "open resolver" instead of "public resolver". If you wanted to convey the nuance that it's not just open, but open on purpose and meant to attract users from the entire Internet, you could add "global": "open global resolver". Or, as an alternative, you could use the term "platform", which is increasingly being used to identify Internet-wide global companies that provide multiple consumer services. "Platform resolver" would also convey the idea that these resolvers are going to be distributed and ubiquitously available. "Cloud resolver" could have a similar meaning. But, as for any terminological bikeshedding effort, you cannot force others to use the "most correct" term, so it's possibly just a waste of time. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Client Validation - filtering validation?
> Il 28/04/2020 04:34 Brian Dickson ha > scritto: > > I've been thinking about whether/how a provider of filtering service > (directly or indirectly) could be explicitly trusted to provide filtered > "answers". > >From time to time, I've also been thinking that something like this would be >useful and that we should start working on it. It would introduce more >security and transparency and address many of the non-technical concerns >around DNS filtering. There could even be a mechanism in which the user picks >a specialized provider of filtering rules, and then tells whatever resolver >they are using to apply those rules, all through authenticated secure >communication. More generally speaking, I think that it would be very beneficial to Internet end-users if the discussion around [DNS] filtering in the technical community moved from "is filtering good or evil?" to "filtering is a fact of life, how can we make it work better?". -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com mailto:vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Privacy and DNSSEC
> Il 25/04/2020 08:23 Vladimír Čunát ha > scritto: > > Still, note that for some consumers the secure transport may be an > argument to drop validating DNSSEC themselves. If they choose some DNS > provider that they trust with privacy (it might be their ISP), it seems not a > huge leap to trust them with DNS integrity as well (say, the provider doing > DNSSEC validation). Especially as today "regular users" don't get that much > benefit from validation, mostly relying on https/tls. > In any case, for most users today DNSSEC validation is done by the resolver and not on their device, and in that case the length of the leap you mention is zero: you already have to take the resolver's word for the fact that the result of DNSSEC validation really was what the resolver tells you, so there is no additional security in knowing that the resolver says that it did DNSSEC validation and it was ok. There is for the resolver, of course, but this means that the resolver can evaluate independently how to trust the results that it gets for its queries; it could rely on DNSSEC, or it could rely on some form of authentication of the authoritatives (e.g. ADo* and/or PKI), or on any other existing or new mechanism. > > Some of them also want a variant of DNS filtering, which still clashes > with validation a bit (if done *after* filtering). > Which is one more reason why clients might prefer "trust whatever the secure resolver says" to "trust the DNSSEC information that the resolver puts in your results". DNSSEC and DNS filtering are incompatible by design, and if you have to choose among the two, many users will prefer the latter. Of course, this changes if we go into the "resolverless" mode envisaged by a couple of the ADD drafts, or in the currently rare case when the client is not a stub and does full resolution directly (the two things are IMHO architecturally equivalent). In that case, the client's security would really benefit from doing DNSSEC validation directly. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com mailto:vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-extended-error-14: (with DISCUSS and COMMENT)
> Il 23/04/2020 20:14 Warren Kumari ha scritto: > > On Thu, Apr 23, 2020 at 5:04 AM Vittorio Bertola > wrote: > > > > Indeed, thinking at the possible use case for those error codes, it would > > make sense for the forwarder to forward them to the final user. Perhaps we > > can fix the language to make this clear? E.g., instead or "the server being > > directly talked to", "the server actually resolving the queries" or > > something like that? > > In my view your proposed text is simple, clear, and addresses the issue... Well, to be honest, picky people might argue that also the forwarder, while normally only relaying queries and replies, might sometimes decide to filter one and thus apply the codes. If one felt the need to explicitly allow this case, the text could be "the server resolving or forwarding the queries". In any case, the meaning of the codes should be clear enough that people understand when their use makes sense... hopefully. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-extended-error-14: (with DISCUSS and COMMENT)
> Il 22/04/2020 19:15 Benjamin Kaduk via Datatracker ha > scritto: > > -- > DISCUSS: > -- > > Sections 4.16 and 4.17 have some discussion that suggests that the > respective extended errors apply only to the current "local hop" of a DNS > query, and thus should not be propagated by a resolver/forwarder as part of > a response. If so, this would be at odds with the discussion in Section 3 > that leaves such bhavior as merely "implementation dependent" (giving some > MAY-level options). I'm not sure what the intent is, here, so let's talk > about whether there's anything that should change. Indeed, thinking at the possible use case for those error codes, it would make sense for the forwarder to forward them to the final user. Perhaps we can fix the language to make this clear? E.g., instead or "the server being directly talked to", "the server actually resolving the queries" or something like that? -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] On Powerbind
> Il 15/04/2020 02:24 Paul Wouters ha scritto: > > And we might disagree about the value of enforcment. But as I tried > to explain during the meeting, the value added is not for our little > community of engineers that trust each other. It is for people at large > to not need to trust some cabal and who do not trust ICANN, Verisign > or the USG. Personally, I do not have a strong opinion on this draft - if some people want it, why not. However I am a bit perplexed by this kind of motivation, as it seems misinformed on the current state of governance arrangements around the DNS. For example, the USG has been out of the loop for a while, though the .org quarrel has shown interesting ways in which the General Attorney of California can get back into it as long as ICANN is still incorporated there. Also, I don't completely get why anyone would want to use a domain name in a TLD whose operator they distrust so much that they think that the operator could attack the zones it delegated. I see better value in the proposal as a way to counter potential attacks to delegated zones that could happen if the operator were ever compromised. Anyway, I have a preemptive bikeshedding request: if this thing proceeds, please find another name that does not sound like a confusing portmanteau of two of the most widely used resolver implementations :-) -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Consensus suggestion for EDE and the TC bit
> Il 3 dicembre 2019 05:12 Puneet Sood ha > scritto: > > I would support text like the above in section 3.4 to remind operators > not to put very long text in the EXTRA-TEXT field. Thinking at how that field could be used in practice for a use case that we have in mind, I think it would be structured and contain pointer(s?) to more detailed information, under the form of URL(s). As long as it can keep a couple of average-length URLs and some shorter things, I think it will be ok. Also, independently from whether I like this or not, I expect this type of advanced use cases to require DoH as a transport protocol - I don't see clients trusting this information if received from an unauthenticated resolver over a cleartext connection. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error
> Il 28 settembre 2019 01:41 Wes Hardaker ha scritto: > > + Response: Those three codes were supplied in a previous comment > round and they are supposed to indicate policies being applied from > different sources. Can you check the new text of them to see if > they are more understandable now? I think there was an editorial glitch, so now you have two errors #17 and no #18 - 3.19 should become #18 again. Regarding the substance, I think that the text is reasonably clear; especially the difference between #15 and #18-aka-3.19 (which was the subject of Stephane's comment) is that in #15 the resolver is blocking the specific queried name while in #18 the resolver is blocking the specific client, and I think that this is still a useful distinction to make. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Re: draft-ietf-dnsop-extended-error and combinations of EDEs and RCODEs
> Il 12 settembre 2019 16:52 Paul Hoffman ha scritto: > > Proposal: add the following sentence to the end of the abstract: "Extended > error information does not change the processing of RCODEs." > > Proposal: add to the end of the Introduction: Applications MUST NOT change > the processing of RCODEs in messages based on extended error codes. But isn't the foremost motivation of this document to allow the client to tell between SERVFAIL due to DNSSEC validation failure and SERVFAIL due to resolver issues, and try another resolver in the latter case but not in the former? How would this not be "changing the processing of RCODEs in messages based on extended error codes"? Or do you mean that the stub resolver library can do that, but not the application that is calling it? But what do you do when the two things are in fact the same, e.g. with DoH clients? -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-08.txt
> Il 10 agosto 2019 20:57 Wes Hardaker ha scritto: > > 4) Now that this has had multiple implementations (though they'll need > to change after the packet format and code changes [that they > requested]), this is likely ready for last call after passing through > the document for nits and addressing any last comments raised. Given some recent discussions on the ADD list, I think that it could make sense to add a third error code for DNS filtering. Currently, the draft has these two: 4.16. Extended DNS Error Code 15 - Blocked The resolver attempted to perfom a DNS query but the domain is blacklisted due to a security policy implemented on the server being directly talked to. 4.17. Extended DNS Error Code 16 - Censored The resolver attempted to perfom a DNS query but the domain was blacklisted by a security policy imposed upon the server being talked to. Note that how the imposed policy is applied is irrelevant (in- band DNS somehow, court order, etc). There is however a third case, which is "blocked by user request". The three cases differ on who made the decision to filter, i.e.: - code 15 is for when the recursor blocks stuff that its own operator dislikes; - code 16 is for when the recursor blocks stuff that public authorities dislike; - the third code would be for when the recursor blocks stuff that the user (the entity that acquired the service) dislikes, e.g. for parental control, destinations not suitable for work, etc. There was also some discussion on whether these error codes could be accompanied by a URL that the client device can use to display a human-readable explanation to the user, which would be a cleaner solution than the current practice of giving to the client a positive response, but with the IP address of a local web server instead of the original one (a practice that doesn't work well with HTTPS anyway). This has many security caveats, and could only work with an authenticated, trusted resolver (which is anyway true of the above error codes in themselves, since an adversarial recursor could just lie on the reason for blocking or even on the fact that it is actually blocking something). It is really too early to say whether this could work or whether it would actually be implemented, and also, on transports other than DoH, I'm not sure if applications could ever access this information. Still, perhaps a note on whether EXTRA-TEXT could bear structured information for certain error codes, and how this mechanism could be later defined, could be useful. (Happy to propose text if this makes sense.) -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Please review and provide feedback -- draft-stw-6761ext
> Il 24 agosto 2019 00:35 Warren Kumari ha scritto: > > There was also some discussions with Jacob (or perhaps Alec) saying > that if this had existed when they started, they probably would have > used onion.alt instead of .onion. > > Whether or not people would *actually* have used it is unknowable, but: > 1: at least now they *do* have the option and > 2: in the future we can point at this instead of just having to agree > that they didn't have an option other than squatting. I am in favour of trying this: it is simple and it won't do much harm if it fails, but it addresses a few of the problem cases specified in RFC8244 section 3 (I'd say #7, #8, and parts of #5 and #9). Of course it doesn't address the problem of people who do not know or do not care, they will just continue making up TLDs and using them - though some kind of information and peer pressure effort whenever these cases arise could have some effect, as a practical alternative would now exist. Perhaps, as a guideline either here or somewhere in a future revision of RFC6761 (i.e. here), application developers should be told that before asking for a special use TLD they SHOULD/MUST experiment with a name under .alt, and prove the existence of some running code, adoption and success before moving to a TLD (and plan their implementations since the beginning so that such a move can actually be done). This would act in two ways: it would avoid wasting energy on discussing abstract special use TLD proposals that seem a great idea to some while others claim that they'll never work, and it would encourage people with successful .alt subdomains to move to a special use TLD to get the benefit of guaranteed non-collision, if they see merit in it. This is also why not having a registry under .alt makes sense. Having one would make .alt second-level domains almost a functional duplicate of special use TLDs, raising the bar to get them and making special use TLDs only better in vanity/shortness, which would lead the IETF to have to deal mostly with vanity TLD applications. (Also, you have "handing" instead of "handling" once in 4.1.1 and twice in 4.1.2.) -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Request for adoption: draft-sah-resolver-information
On Fri, 12 Jul 2019, Paul Wouters wrote: > > I find the term "security policy", a bit unnerving here. A DNS server > is either secure (and tells the truth), or it is not secure (and tells > lies). There is no "better". Some people say lying is more "secure for the > user", but that can really only come from a pre-existing configuration, > not a random DNS server offered by your random local network. > > I think the better term here is "privacy policy". We kind of assume > all DoH severs are "secure" (at least for their transport, see above) > but we feel we can trust some DoH servers more than others for privacy. No, it is really about security, but in a broader sense. Some resolvers will lie to you when you try to access a known malicious destination, e.g. a website which hosts malware or phishing, or, if "you" are a bot, your command and control server. This would be "insecure" by your definition above, but in reality it makes the whole Internet access experience more secure. In this scenario, a "better" security policy by a resolver is one using a list of filtered destinations that is more precise, more timely updated, more localized, more tailored to your own needs (including the fact that some resolvers allow each individual user of the local network to choose a different filtering policy, or none at all). So the user might indeed want to use a resolver that employs a better security policy, or even the resolver with which they have a contract to provide a specific security policy, which, in the case of ISPs, will usually be the one advertised by the local network. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Proposal: Whois over DNS
> Il 9 luglio 2019 16:36 John Bambenek > ha scritto: > > > I agree with pretty much everything else Jim said, but really this seems > > like the core issue: this seems like a proposal in the wrong venue. > > If the proposal is to create a standard by which to put contact > information into DNS records, what venue would you suggest? You could try with ETSI... Seriously, the IETF in the past has already decided not to standardize certain technologies, as they could easily have been used to gain access to personal information and identify/track people on a mass scale, even with the blessing of law enforcement authorities and with the purpose of legitimate investigation activities. It would be weird now to work on a mechanism that could easily be used to coerce people to self-identify themselves in a global, public, automatically scrapable database to facilitate similar investigations. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Proposal: Whois over DNS
> Il 9 luglio 2019 00:01 John Bambenek > ha scritto: > > > Like I said, I’m ok with someone lying to me. Its easy to detect > and easy to deal with. For instance, in DNS a mailserver could > query these records, see phone number is set to 00 and > then just reject email from said domain. With existing whois that > was never possible, due to rate limiting. At first sight, your proposal looked ok - if someone wants to publish their information voluntarily, why not? But then I read this and now I am seriously concerned: it looks like this is explicitly being designed to penalize registrants that care about their privacy and choose not to publish information about themselves (or publish fake information, which used to be the only practical way in the old mandatory Whois times). > The domain registrant system issue was easy to solve. Make > private domain registrations free for everyone who wanted it. > That solution was rejected out of hand be registries and > registrars at ICANN. Likely because they want the system to die > entirely. Differentiated access sounds nice, but those who govern > such things have made clear it will the differentiation is “do > you have a court order”. I’ve been party to those discussions and > my view is that the multi-stakeholder model isn’t going to work. Your frustrations are understandable, and personally I hope that ICANN manages to set up a usable differentiated access system soon and I even contributed some ideas to it. However, basically what you are saying is that you are not happy with the result of the policy development process in the proper place (i.e. ICANN), so you are now trying to use the IETF to bypass that consensus. Is this really the right thing to do for the IETF? > The fundamental issue is voluntary interconnection. If you want > to connect to me, I should have a programmatic way to get > something about you to make that decision. You can publish > nothing if you want, or publish fake info. And I can do what I > want with it. I understand this viewpoint, I'm not saying it does not make sense, but this looks too much like the email authentication stuff that has made it increasingly difficult to run independent mail servers and still get your messages accepted by the big platforms. If between "you" and "the entity that wants to connect to you" there is a fundamental difference in size and power, this becomes a way for you to force the other party into whatever you want - it is not a peer relationship any more. So, before proceeding with this (if ever), some thoughts should be given to potential centralizing effects and how to deal with them. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Verifying TLD operator authorisation
Il 20 giugno 2019 00:28 Nick Johnson ha scritto: I think I addressed this upthread: If someone has the ability to change a zone's DNS records and generate valid DNSSEC signatures for them (which we will be requiring and verifying), they're sufficiently 'in control' of the zone that I'm comfortable treating them as the authorised user. If someone malicious has that control, the TLD owner has much larger problems. I hate being the engineer that sold his soul to the dark side of policy talks, and also it's not fully clear what you want to do after establishing this technical link between ICANN's root and your alternative namespace, but I would really recommend you to have someone competent make a proper legal/policy analysis of your plans. For example, if after adding existing ICANN-rooted TLDs under ENS your users will be able to perform anything resembling a domain registration or transfer, that is likely to be highly regulated by ICANN contracts and/or, for ccTLDs in several countries, by national laws; breaking those rules could expose you and the registry to serious issues. If you add that this has to do with "blockchain" - a politically sensitive and vaguely regulated topic in many parts of the world - the likelihood of politicians discovering this, not understanding it and screaming at the registry, for example, is definitely not zero. Also, checking technical proof of control of a zone is not a legally valid way to conclude a contract with its owner, and you'd be much better off if you had a legally authorized representative of the registry sign an appropriate piece of paper with you (or at least go through T&Cs in a web procedure). Otherwise, in case of problems, the registry could claim that they never actually consented to this and that you basically hacked them with the unauthorized help of one of their suppliers or employees. Regards, -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchangevittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New draft for consideration:
> Il 24 marzo 2019 alle 7.42 Paul Hoffman ha scritto: > > > Greetings again. As y'all have seen over the past few weeks, the discussion > of where DNS resolution should happen and over what transports has caused > some people to use conflicting terms. As a possible solution to the > terminology problems, I am proposing a few abbreviations that people can use > in these discussions. The draft below, if adopted by the DNSOP WG, would > update RFC 8499 with a small set of abbreviations. I don't know if these terms are already defined somewhere else, but the distinction that I've found most useful in the DoH discussion is "local resolver" (i.e. the one provided on/by the local network the user connects to) vs "remote resolver" (i.e. any other resolver, requiring traffic to go beyond the Internet access provider's network). Some of the issues happen, and already happen today, as soon as the user adopts a remote resolver, even with plain old DNS. I agree that another set of problems derives instead from applications using a resolver different than the one configured in the operating system, which may or may not be the local resolver. So it's fine to define a couple of terms like "DaT" and "DaO", though I don't really like these two acronyms :-) In my draft I introduce the terms "network-level name resolution", "application-level name resolution" and "application-level resolver selection". They are not acronyms, but I think they would be more understandable in a discussion than more and more acronyms. (I don't even like "Do53", I think "unencrypted DNS" or "plain DNS" is just clearer.) Ciao, -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
> Il 24 marzo 2019 alle 22.42 Patrick McManus ha scritto: > > > On Sun, Mar 24, 2019 at 10:31 PM Brian Dickson < > brian.peter.dick...@gmail.com mailto:brian.peter.dick...@gmail.com > wrote: > > > > > > > > This is important for network operators in identifying encrypted > > DNS traffic, > > > > > > not all clients acknowledge a network's right to do such things at all > times. And of course it would be useful to tell the difference between policy > and a RST injection attack. > > If the client does acknowledge the network has the right to set policy - > then the policy can be set on the client using existing configuration > mechanisms that allow the client to differentiate between authorized > configuration and perhaps less-authorized folks identifying their DNS > traffic. This is well worn ground in the HTTP space. > Let's say I just bought a new smart TV that can browse the Internet, but I don't want my kids to be able to access inappropriate websites from it. Or, let's say I actually like the fact that my operator filters out malware destinations at the DNS level and I want my new TV to have that protection as well. In today's "plain DNS" world, I choose a DNS resolver that provides that kind of filters for me, I set it up on my router, and my router pushes it to my smart TV via DHCP. What is the "existing configuration mechanism" that allows me to set this policy in the DoH world, i.e. if the TV came equipped with applications preconfigured to use their own remote resolver via DoH? As a minimum, I would have to open all the applications and configure them one by one to use my desired resolver, and repeat this for every device connected to my network - while in the current situation this is all automated after I configure the resolver once on my router. But applications like Firefox might completely refuse to use the resolver I want, advertised by my router on my behalf, because it does not support DoH, or it does but is not on their list of "trusted resolvers". And Javascript bits in the pages I visit might use DoH to pre-encoded servers without even offering me any configuration. Regards, -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com mailto:vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator
> Il 22 marzo 2019 alle 4.40 Christian Huitema ha scritto: > > Much of the debate is on the second point. One position is that users should > be forced to trust the DNS resolver provided by the local infrastructure. > Another position is that users have the right to apply their own policy and > decide which server they will trust, based on some configuration. I think this is a mischaracterization of the debate, which actually started because of a third position that you don't mention: Mozilla's public statement that in the future they will force (or, at least, make as a default - clarification requests haven't solved the doubt yet) Firefox users to use a remote resolver chosen within a shortlist that they will manage. There are some people advocating that in some cases people should have to use the local resolver so that the local network can monitor them and apply policies, but that's always been limited to private / corporate / high security networks. I don't think anyone has ever proposed that all users be always required to use a local resolver, full stop; though, if DoH deployment continues this way, I do see some governments - even in Europe - trying to go in that direction, either by mandating the use of in-country resolvers or by passing GDPR-style legislation that requires any global operator to apply national DNS policies when serving their citizen, or be fined for 4% of their revenues. In the end, I think that everyone should agree on the principle of user choice (which is actually the first recommendation in my draft). There will then be some discussion on whether the local resolver should continue being the silent default or not; though I note that the opposite policy, i.e. letting each application pick its own default resolver, creates a fragmented mess of a network and makes it much harder for the user to implement any practical choice. But anything different than "users are fully in charge as far as they want" is IMHO dangerous and unmanageable. Regards, -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [hrpc] Proposal for a side-meeting on services centralization at IETF 104 Prague
> Il 20 marzo 2019 alle 8.29 Stephane Bortzmeyer ha scritto: > > I modified the title of the meeting > <https://trac.ietf.org/trac/ietf/meeting/wiki/104sidemeetings> because > there is obviously no consensus on the problem or on the > agenda. Anyway, a room is reserved if people want to meet on > wednesday. Given that this is not going to happen in the doh session on Tuesday, perhaps the meeting on Wednesday could start with the presentation of the three drafts. If the meeting on Tuesday gets to some preliminary ideas on work to do, we could then work out some plans among those that want to contribute. Regards, -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator
> Il 20 marzo 2019 alle 12.38 Joe Abley ha scritto: > > Seems to me that there's a middle ground within sight here. > > Standardise this privacy mechanism, and specify (with reasoning) that it > should be implemented such that the existence of the channel (but not the > content) can be identified as distinct from other traffic by third parties. > Maybe specify use of a different port number, as was done with DoT. > > Those who choose to ignore that direction and create a covert channel using > port 443 instead will do so. Nothing much we can do to stop that today (I > guarantee it is already happening). The future is not really different. This is actually the recommendation in section 4.6 of my draft :-) And I agree, it looks like the only possible and reasonable compromise between the two viewpoints. Regards, -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator
> Il 15 marzo 2019 alle 19.36 Ted Hardie ha scritto: > > As was pointed out in many groups, trusting the local infrastructure is > extremely problematic in nomadic cases as the local infrastructure can often > be infected, ill-maintained. or hostile by design. Given the extremely high > percentage of users who are now on the Internet by mobile devices which roam > and opportunistically use WiFi, ignoring this reality would not make sense. > Does anyone have data on this "extremely high"? I am not challenging that the problem exists, though, in my experience of the last couple of years in Europe, the sudden availability of cheap Europe-wide mobile data plans means that people using the Internet from a smartphone tend to use random wi-fi networks less, and to stick to the network of their mobile operator when traveling (I would love to hear about other places). In any case, what's problematic in that trade-off is the non sequitur that since "trusting the local infrastructure is extremely problematic in nomadic cases" then we design technical solutions that never trust the local infrastructure in any case - or even actively try to circumvent it. This is just wrong, and does not consider that there are indeed many very common device use cases in which being nomadic is a rare exception (such as my mother's laptop) or does not happen at all (such as a desktop PC on a corporate network). Perhaps letting the user bless the networks they trust would be a better approach. Regards, -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com mailto:vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [hrpc] Proposal for a side-meeting on services centralization at IETF 104 Prague
> Il 14 marzo 2019 alle 15.53 Stephen Farrell ha > scritto: > > Hiya, > On 14/03/2019 14:41, Ralf Weber wrote: > > the DoH protocol caused some application providers to experiment with > > switching resolution per default away from OS and the local network provider > > I wasn't aware that some application provider was doing this > as their default (assuming that's what "per default" means). > Can you provide details? > > I am aware of what FF/CF have done but I don't believe that > was on by default. What caused all this fuss is that they did not turn it on by default, but they publicly said they "would like" to do it in the future, here (at the end, "what is the status"): https://hacks.mozilla.org/2018/05/a-cartoon-intro-to-dns-over-https/ and also here, more or less at half the text, they say "Firefox does not *yet* use DoH by default" (asterisks are mine): https://blog.nightly.mozilla.org/2018/06/01/improving-dns-privacy-in-firefox/ Mozilla also had several calls with concerned parties in which they were asked to clarify, and they confirmed that while they are considering all the feedback, this is still in their plans for the future. So we are not all having hallucinations here :-) and even if Mozilla decided to announce that their plans are changed and that idea is now off the table, which has not happened yet, now everyone is aware that this could be done by any application at any time in the future; so, speaking from a policy perspective, it would be nice to agree (if possible) that that is a bad idea, at least if certain conditions are not met, and record that consensus somewhere. It would not prevent anyone from doing something else if they want, but that's true of any standard; but it would at least provide some guidance for well behaved application makers. Regards, -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [dns-privacy] New: draft-bertola-bcp-doh-clients
> Il 13 marzo 2019 alle 4.39 Christian Huitema ha scritto: > > On 3/12/2019 7:56 PM, Vittorio Bertola wrote: > > The reaction I got from some policy people when I mentioned this kind of > > arguments going on here is "when did the IETF get the mandate to decide for > > everyone that content filtering by intermediaries is always bad? This is > > matter for competition / telco / human rights legislation, and will vary > > country by country." > > The mirror image of that statement is, "when did intermediaries get a > mandate to filter content?" When a regularly elected government, having sovereignty over them and their users, told them that they can / should / must do it. Note that I don't particularly like this practice (I'm currently busy in the battle against Article 13 in the EU), I'm just trying to sort out everyone's role in this discussion. Regards, -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [dns-privacy] New: draft-bertola-bcp-doh-clients
> Il 12 marzo 2019 alle 19.56 Christian Huitema ha > scritto: > > You are saying that whoever happens to control part of the network path > is entitled to override the user choices and impose their own. Really? > As Stephane wrote, that may be legit in some circumstances, but much > more questionable in others, such as a hotel Wi-Fi attempting to decide > what sites I could or could not access. The reaction I got from some policy people when I mentioned this kind of arguments going on here is "when did the IETF get the mandate to decide for everyone that content filtering by intermediaries is always bad? This is matter for competition / telco / human rights legislation, and will vary country by country." To quote what you wrote in another message: > There is a lot of difference between what can be imposed in a > police state and what looks legitimate in a user agreement in a > free country. And I sure hope that we maintain that difference. A > good result of that discussion would be to clarify these > differences. Do you really think that this is the IETF's job? Deciding "what looks legitimate in a user agreement in a free country" (and presumably, also what tells "a police state" from "a free country") and enforcing such decision via technical measures? Ciao, -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-privacy] [Doh] New: draft-bertola-bcp-doh-clients
> Il 13 marzo 2019 alle 3.20 Raymond Burkholder ha > scritto: > > It appears to me that there is considerable support for DoH, meaning > there is support for non-interference. I think there is support within the IETF, but "non-interference" on DNS has lots of implications at the legal, business, policy and political levels, which implies that there are many more stakeholders than the technical community, and these stakeholders have never been asked what they think of this. This is part of the discussion that needs to happen to get to broad consensus on DoH deployment models, as opposed to a technical arms race to enable/stop DoH between the Web people on one side and the security, ISP and government people on the other. > How would the requirements of each group be recognized? The simplest > would be to not proceed with DoH. My draft attempts exactly to promote a discussion to find the conditions (if any exist) under which DoH could be deployed broadly without making any stakeholder group [too] unhappy. Regards, -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Proposal for a side-meeting on services centralization at IETF 104 Prague
> Il 12 marzo 2019 alle 10.01 Stephane Bortzmeyer ha > scritto: > > > On Mon, Mar 11, 2019 at 06:57:03PM +0100, > Vittorio Bertola wrote > a message of 18 lines which said: > > > Moreover, centralization is not the only Do*-related problem > > category that has been raised (my draft alone lists eight others). > > IMHO, this is precisely the biggest problem with these three drafts: > they accumulate a lot of unrelated rants, They are not unrelated, they are all effects of the same thing and you cannot deal with them separately, as some practices that would address one of the problems could worsen some of the others. Also, the fact that some of these are not problems for you does not imply that they are not problems for others, and if you want to get consensus, you have to address everyone's concerns and not just yours. Also, the reason why this is a difficult problem is exactly that it affects many things at once. It is fine to break down the analysis into single issues, but when it comes to what to do next, if you start several parallel work threads without any clear coordination plan, you will just end up with several conflicting proposals. So, rather than focusing on any specific entry of the list of issues, I think that the most urgent thing to discuss would be where to have the discussion (so that we can stop crossposting entire threads to four groups) and how to organize it (objectives, working items etc.). Ciao, -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Proposal for a side-meeting on services centralization at IETF 104 Prague
> Il 11 marzo 2019 alle 18.02 Stephane Bortzmeyer ha > scritto: > > It was suggested Reference necessary to have a > side meeting in Prague at IETF 104. I propose monday, 1400-1600 in > Tyrolka. The proposal is at > <https://trac.ietf.org/trac/ietf/meeting/wiki/104sidemeetings>. You > are welcome to agree/disagree/meet in a bar instead. Why not in the Wednesday timeslot that was specifically set aside for side meetings? Also, I'm wondering whether a 40-people room is enough (may be, may be not). Moreover, centralization is not the only Do*-related problem category that has been raised (my draft alone lists eight others). So the focus of the meeting should be on whether, where and how to deal with all of them, though some of them may later be deemed off mission for the IETF. But first of all we need to agree on a venue and process. Ciao, -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator
> Il 10 marzo 2019 alle 20.15 Ask Bjørn Hansen ha scritto: > > > > > > > On Mar 9, 2019, at 10:48 PM, Warren Kumari < > war...@kumari.net mailto:war...@kumari.net > wrote: > > > > Also, I think that this topic would be better discussed in the > > DNSOP WG - the DoH charter ( https://datatracker.ietf.org/wg/doh/about/) > > talks about: > > "The primary focus of this working group is to develop a mechanism > > that > > provides confidentiality and connectivity between DNS clients > > (e.g., operating > > system stub resolvers) and recursive resolvers." > > > > > > I agree with this (and everything else you said). > > The new topics that are coming up all seem like they’d fit better in > DNSOP or DPRIVE. > For the sake of completeness, I will mention that I have also just posted a draft that tries to address the issues deriving from the adoption of encrypted DNS protocols, under the form of a best practice document for client applications: https://mailarchive.ietf.org/arch/msg/dns-privacy/3ryu5BxcjRJO1-zeRXJaKIcIDUY I decided that dprive was the right place for it, and I will briefly present it there, but I agree that the first discussion (even in a side meeting in Prague, if there is interest) would be where to deal with the topic within the IETF, and to which extent; it would make sense to have a single coordinated discussion rather than multiple parallel ones. Regards, -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com mailto:vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] extension of DoH to authoritative servers
> Il 12 febbraio 2019 alle 22.00 Ted Lemon ha scritto: > > What I am trying to point out is that the situation with DoH is a symptom of > the problem you are not talking about, not the only instance of it. > You seem to be asserting that DoH is special among all other misuses of port > 443. But you haven’t explained why it is special. This is what I was > trying to tease out with my initial response to what you said. Well, DoH has a couple of very special features: - it affects name resolution, which is the initial step for almost everything you do over the Internet; - apparently, it will be deployed by default to the entire mankind or so. It is quite different than some smart users or some specific applications using HTTPS (or VPNs) to bypass the local network operator and/or the local jurisdiction. In technical terms it might not be different, but in business, policy and political terms this makes all the difference. Ciao, -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Re: New draft for helping browsers use the DoH server associated with a resolver
> Il 24 agosto 2018 alle 17.26 Vladimír Čunát ha > scritto: > > > Still, personally I'd probably prefer to choose someone from a list of > providers, as we might have quite a lot soon, and "I" might trust some of the > names already, and the handshake will then verify that the name matches. While having users in charge might in the end be the best thing to balance all the conflicting interests and threat mitigation needs, I am not sure that putting the user in front of a list of all the existing DoH resolution providers (thousands? hundreds of thousands?) is a great idea. In terms of user experience, to allow users to make an informed choice, the list would need to provide users with information on the policy of each server (see the current draft in DPRIVE) and it would end up being pretty hard to lay out and use in a meaningful way. Also, if you can't even find a way to transmit securely to the user device the information on the single DoH resolver that serves the local network, how can you maintain and transmit securely an updated list of all the existing DoH providers? On the other hand, you could imagine that the application, or the OS, could create its own shortlist of "approved" DoH resolvers and transmit it securely from its own servers, or include it in the application's installation procedure. But this would open up significant policy/legal issues in terms of antitrust and fair competition among DoH providers. I'm not saying that there's no way to do it properly, but it is not as simple as it looks. In the end, the policy of having your names resolved by default by a local server on your access network, while leaving you free to configure a different resolver that you find out-of-band if you want to, emerged over 30 years because it makes a lot of sense. I still have to hear a compelling technical or policy reason for the attempt to change this default and turn DNS resolution into yet another over-the-top service subject to global competition and market consolidation, other than "there are some big companies that would like to resolve the names for the whole world because they can gain from the data they would gather". Regards, -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft for dynamic discovery of secure resolvers
> Il 21 agosto 2018 alle 19.36 David Conrad ha scritto: > > Vittorio, > > > Perhaps I’m misunderstanding: are you saying the folks who provide resolution > services in a DoH world would have incentive to not follow basic security > measures? The definition of what is safe for browsing and what is not is highly local - each network and each country have their policies. How could a QuadX operator implement a filter that fits the needs of the entire planet? (Unless we imagine a model in which the DoH operator receives policies from networks and countries and applies them depending on where the request is coming from.) Also, network operators have a direct interest in implementing security measures to prevent threats from spreading to more devices on their network. What's the incentive for a centralized DoH operator to spend money and time in security filters? Regards, -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft for dynamic discovery of secure resolvers
> Il 22 agosto 2018 alle 7.18 Doug Barton ha scritto: > On 08/21/2018 09:19 AM, Vladimír Čunát wrote: > > Ehm, we somehow forgot that this thread is supposed to be about DHCP, so > > that's only the "uninteresting" case where you do trust the ISP and want > > to use their DNS over a secure channel:-D > > This perspective that users "trust" their network environment is deeply > flawed. Users don't understand how any of this stuff works, and we > should not be making any decisions with that as a premise. But we should also not make the premise that the user does not trust the network environment. It really depends on the situation. Also, there are cases in which the user perhaps does not trust his network, but his network has the right to enforce policies on the user: think at the employees on a corporate network. We should be making this enforcement easier, not harder - for example, adding ways for the network operator to communicate to DoH operators that certain restrictions have to be put in place for the users of its network. Moreover, even if the user does not trust his network and has the right to do something about this, you cannot also assume that he trusts his application maker or his destination website operator more than he trusts his network. Actually, if you define trust in terms of expectations, until now the users that understand what we are talking about expect their network operator to provide the resolver, not the application maker. The real problem here is that you cannot establish a trust model that is always valid, and the trust model that applies to a situation can be opposite to the model applying to another one, without any automatable way to distinguish among the two. This is also what makes this issue so thorny. You can decide that, in the end, the only way to get out of this is to entrust the user with the choice of who to trust, though, as you say, many users will not be able to make an informed choice. Or you can entrust the network operator or the DoH server operator: it is more likely to make competent choices, but in some cases might not make them in the user's interest, though in some cases it also has the right, or even the legal duty, to make choices that users dislike. All in all, I see no easy way to find a model and a policy that work in all cases. Regards, -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft for dynamic discovery of secure resolvers
> Il 21 agosto 2018 alle 16.47 Philip Homburg ha > scritto: > > > > If I got it well, what you are trying to bypass is your ISP's > > security filter that prevents you from connecting to malware or to > > illegal content (e.g. intellectual property violations and the > > likes). > > As a user, I think there is little reason to trust an ISP. > > If you take a mobile device, do you trust every hotel, bar, etc. where you > may connect to the wifi? Are they all competent? Are you sure none of them > will > violate your privacy? Sure, roaming at hotels and cafes is a good use case for encrypted DNS, though for many people it is not the typical Internet access situation (not everyone travels to conferences all the time). Most people here in Europe either access the Internet at home or at work through DSL or fiber, or access it on their mobile phone using the mobile operator's data network. In fact, roaming wi-fi connections, while still relevant (especially for international tourists), are getting less and less used, since everyone now gets several gigabytes of EU-wide mobile data per month included with their base mobile fee. Still, I'm all in favour of encrypting and authenticating DNS connections when you are in that situation. However, this should not be done in a way that breaks many other use cases. > If you have only a few ISPs to chose from, do you trust that ISP? How many browsers can I choose from? Definitely many less than the possible ISPs, and not a single one from the jurisdiction I live in. > There are many ISPs that try to do the right thing for their customers. > There are quite a few ISPs that have court orders to do things that go > against the interests of their customers. Yes, but that's the law. I still don't get how is it possible that the IETF is releasing a technology openly designed to allow people to break the law. In my part of the world, this is ethically unacceptable, and possibly also illegal. > And the are quite a few ISPs that are positively evil. > > You need to have options in case you can't trust the ISP. Why would you ever use an ISP that you don't trust and that is positively evil? > > build a sort of "nuclear bomb" protocol > > that, if widely adopted, will destroy most of the existing practices > > in the DNS "ecosystem" > > There is no reason why DoH has to be deployed as a 'nuclear bomb'. Ok, this is the real issue. There is no reason why, but this is how it is being deployed, starting with Mozilla. And I have yet to see a statement from the DoH community that Mozilla's idea of making DoH the default and disregarding whatever resolver is being configured in the system via DHCP is not a good one. Actually, during the discussions in Montreal there were people talking about centralized DNS operators paying the browser makers to get their DNS traffic, and then monetizing it to get back the money. How can this be presented as "more privacy" is baffling. Perhaps what we are missing is just a set of policy guidelines on how DoH should be deployed by operators and application developers, though I do not know how you could then enforce them. > Hosts can still default to using the resolvers offered by DHCP only switching > to public resolvers when directed by the user. No, they can't, if the application defaults to its own resolvers, possibly not even letting the user choose different resolvers unless they click into three-level-deep configuration menus. > The big difference is that when the user does decide to bypass the ISP's > resolvers, there will be no way for the ISP to interfere. Good luck explaining that to several hundred governments that rely on mandatory DNS filters to enforce gambling, hate speech and pornography regulation. Regards, -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft for dynamic discovery of secure resolvers
> Il 21 agosto 2018 alle 5.47 John Levine ha scritto: > * - When I talk to security people at mail providers, they have > endless tales of people who take the mail out of their spam folder and > click on the links, you know, just in case it was filtered wrong. If > you know it's bad stuff, you don't want the users to see it at all. It's true, and there is an additional consideration to this: the users that do so are not just damaging themselves, but everyone else, by spreading the infections and becoming attack vectors. I understand why some people are conceptually irked by the idea that the ISP can decide on its own to make something unreachable to them, but they should understand that most Internet users are not technically savvy, often not savvy at all, and this threatens the Internet as a whole. Regards, -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft for dynamic discovery of secure resolvers
> Il 20 agosto 2018 alle 20.11 Paul Vixie ha scritto: > the DOH people should be told not to proceed to draft > standard until their design accommodates the needs of network operators. This is, honestly, what I'd have expected the "IETF leadership" (IESG, IAB...) to say: this new protocol would have a significant impact on how the Internet works, there are conflicting views in different parts of the IETF community and a lot of non-technical concerns outside of it, please work on it until everyone is happy. But possibly I don't understand how the IETF works yet. Regards, -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft for dynamic discovery of secure resolvers
> Il 20 agosto 2018 alle 18.51 Ted Lemon ha scritto: > > > > So I cannot immediately recall cases in which a network operator in Europe > > is filtering out things that a user wants and can lawfully access. But you > > mention that your network operator is spoofing the DNS and stifling your > > freedom of expression, so I guess it is censoring legitimate websites - > > this is bad, of course, but can you tell me which operator, and which > > websites? It would help my understanding of your use case. > > No, it's not bad. It's the service they offer, and it's fine that they > offer it. I think it's the right default. It's also fine that I choose to > bypass it. If I got it well, what you are trying to bypass is your ISP's security filter that prevents you from connecting to malware or to illegal content (e.g. intellectual property violations and the likes). I also imagine that your ISP is doing some transparent proxying/scanning so that you cannot simply bypass this filter by configuring a different resolver in your OS, right? (which, by the way, is the simple solution to your problem that is already available and widely used across the world - see the famous picture of people painting 8.8.8.8 on walls in Turkey) If so, I can accept your use case: a smart user, knowing what he is doing, does not want anyone else to sanitize his queries for him. But I don't see why the best solution to your use case - which is quite a minority case, though easily overrepresented in a technical environment - is to build a sort of "nuclear bomb" protocol that, if widely adopted, will destroy most of the existing practices in the DNS "ecosystem" (I'm using the word that was being used at ICANN's DNS Symposium in Montreal), including the basic security measures that protect the 99.9% of the users who are not technically smart. Perhaps it would have been enough for you to have a discussion with your ISP and get them to give you an opt-out, which is entirely possible with today's DNS filtering techniques - or to just change to another ISP. Anyway, this looks to me a lot like a policy issue, rather than a technical one; and the more I get into this discussion, the more DoH looks like "the IETF against the world's governments and ISPs" - not a good thing, IMHO. > Yes, and if we come up with a solution that allows both situations to be > securely communicated to the end user device, and allows the end user to make > an informed decision about whether or not to use the service with these > restrictions in place, I'm okay with that, and I think it's appropriate for > the IETF to do it. What I am arguing is that we should actually describe > how to do that, and not just hack together a solution without thinking about > that. I would be fine with this approach and happy to work on it, as long as there is an agreement by the DoH/browsers community that DoH will not be deployed to the general public until this missing piece is completed and implemented. Otherwise it would just be a waste of time. Regards, -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft for dynamic discovery of secure resolvers
> Il 20 agosto 2018 alle 17.55 Ted Lemon ha scritto: > > I am entirely within my rights to use DoH whether the network operator likes > it or not. It is not illegal for me to do so, and if I did so, it would not > be so that I could violate the law—it would be so that I could protect my > privacy and avoid DNS spoofing that returns forged answers, which I consider > to be a security threat, and which I am fairly certain my network operator > does. > > It is certainly true that in some cases, someone using DoH would be violating > a network operator policy that is enforceable, or would be violating the law. > But that is by no means the most common case, and it does you no credit to > pretend otherwise. Can you substantiate this statement with data / details? Because I only know cases in which: a) ISPs filter out content on behalf of the local government due to legal requirements/court orders; b) ISPs filter out content on request by the user, e.g. for parental control; in the UK, ISPs are actually required by law to provide this service to the user, that can then decide whether to activate it or not and even what to filter out; c) ISPs filter out threats such as botnets, compromised websites distributing malware, etc - this does not entail any freedom of speech consideration and contributes to everyone's security. In many European countries network operators are selling b)+c) (see for example https://securenet.vodafone.com/ ) and people are actively buying the service, so they explicitly want this kind of filtering (and will not be able to continue getting it if their browser redirects their DNS queries somewhere else); and if you do not want it, you just don't buy it. As for a), possibly users do not want it, but it is still mandated by law. So I cannot immediately recall cases in which a network operator in Europe is filtering out things that a user wants and can lawfully access. But you mention that your network operator is spoofing the DNS and stifling your freedom of expression, so I guess it is censoring legitimate websites - this is bad, of course, but can you tell me which operator, and which websites? It would help my understanding of your use case. Finally, note that *in your country* it may be your right to use DoH to tamper with what your network operator is doing, but this may not be true in other countries. In fact, deploying any technology that circumvents security measures that network operators are required to implement by law might be illegal in itself. In the end, the DNS is a very complex policy subject (see the mess that ICANN is) with lots of stakeholders and conflicting views, and IMHO such a deep change in its architecture and "ecosystem" would require much more caution and a much broader discussion going well beyond the IETF. Regards, -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft for dynamic discovery of secure resolvers
> Il 19 agosto 2018 alle 19.02 Doug Barton ha scritto: > And Jason, you missed a threat model, which is users who want to bypass their > ISP's resolver. I think that there should be a lot more attention to this "use case" in this discussion. It seems to me that the designers of DoH have in their minds a romantic picture of the dissident in some authoritarian country trying to escape censorship and save her own life, so that being able to bypass the local ISP, obviously run by evil government cronies, would be a good thing. However, in most of the world, the reality is that the biggest motivation for people to try bypassing the ISP's resolver is to access illegal Web content that has been filtered out at the DNS level, such as unauthorized gambling websites, illegal pornography, "free" football live streams (which are usually full of malware), etc. - not to mention bots trying to contact their command and control server without incurring into RPZ-based filtering. If I accepted Ted Lemon's point that publishing a proposed standard (like DoH) implies active endorsement by the IETF, I would wonder why the IETF is actively endorsing a standard that will make this much easier. > I agree that encrypting from the CMTS to the local resolver isn't that > valuable, since (unless I'm missing something) the ISP is the only one > that can see that traffic, and they'll be able to log/manipulate the > resolver already. So it's unlikely that an ISP would deploy DOH or DOT > in the first place, so the idea of a DHCP option to support it isn't > necessarily relevant in that environment. That doesn't mean it's not > relevant elsewhere. Well, if I were an ISP, I'd rush to deploy DoH on my consumer resolver so to deprive the browser makers of the excuse "we are redirecting by default your DNS traffic to us because we encrypt it and your ISP does not". I agree that technically speaking there is not a lot of need for this, but DoH (more precisely: the upcoming deployment of DoH in the browsers) is mostly a business and marketing issue, not a technical one. Regards, -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
