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] [hrpc] Proposal for a side-meeting on services centralization at IETF 104 Prague
i've removed "dns-priv...@ietf.org" from the CC headers, at the WG chair's request. note, the main topic of this message is DNS privacy's implications. On Thursday, 14 March 2019 17:50:44 UTC Vinicius Fortuna [vee-NEE-see.oos] wrote: > Paul, I'm trying to understand your scenario. > > If you ran your own DoH server in your network (doing RDNS or whatnot), and > the DoH server is distributed to clients via DHCP + a protocol upgrade > mechanism, would that address the concerns you are listing? > > Vinicius Fortuna no. the new risk intended by DoH comes from its expected ubiquity. two of its design assumptions are wrong. one wrong assumption is that all users and apps operating inside my network deserve rdns service from third parties that is invisible to me (as network operator) and which is therefore subject to neither my surveillance nor my control. it turns out that some users are intruders and some apps are malware, and i do not want them to have the capability of invisible third party rdns. the second wrong assumption is that all on-path interferers have ill intent and do not deserve to surveil or control their network's rdns. as a parent, my interest in monitoring and control of the control plane used by my family, including rdns, is not a matter to be litigated against IETF consensus. the same thing happens at a larger scale in my corporate network. so, no DoH service i can add would have any impact on the intended risks of DoH. i may offer it anyway, for clients who can't use DoT. but for my actual purposes both a user of networks and an operator of networks, DoT is both sufficient and better. my costs to mitigate the risks intended by DoH will in some cases be cheap, like enumerating the so-called "public DNS" providers who offer it, and blocking them at my IP firewall. DoH risk mitigation costs will be much higher for me when DoH is offered by an IP that i have other business with, for example if i need access to a google API or service, and the same IP also offers DoH. there, i'll have to run a tls proxy, and break any client who tries to use outbound TCP/443 directly. many people here have mistakenly asserted that i had that risk anyway, and that this mitigation cost should already be on my ledger. this is mistaken for two reasons, both of which owe to security economics. first, because some of my networks have an outbound TCP/443 whitelist which may have included IP addresses i previously thought i could trust not to offer invisible third party rdns to intruders or malware (or children) on my network. second, because some of my networks only close the barn door after badness has passed through -- that is, the IP blacklist is amended after a detection event, since whitelisting wasn't feasible. defense that only works in the future is still quite a bit better than defense that will not work in the future. DoH, by intending to be invisible inside flows i already accept, will raise my defense costs, forever. so, the costs of proxying TCP/443 to well known IP addresses was not already on my ledger, but must be now, and will have far-reaching effects. not all agents (users and apps) inside my network are friendly and trusted, nor can they be expected to use DoH only when MDM tells them it is ok. not all network operators who monitor or control their rdns are unfriendly or untrustworthy. DoH is intended to be, and is, a security economics disaster for edge network operators. vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] RFC 2845bis and HMAC-MD5
On Thu, 14 Mar 2019 at 15:09, Tony Finch wrote: > Martin Hoffmann wrote: > > > > As such, I would like to propose to move HMAC-MD5 to optional and only > > retain SHA-1 and SHA-256 as mandatory. > > That seems sensible. There should at the very least be a reference to > RFC6151, Updated Security Considerations for the MD5 Message-Digest and > the HMAC-MD5 Algorithms. Is there any continuing justification for the special treatment of SHA-1 enshrined in the footnote to Table 1. Section 8 make abundantly clear that algorithm selection and applicable truncation is a matter of policy and agreement between client and server. Taken together with the detailed requirements in section 6.5.2.1, and the statement that a reply SHOULD be sent with a MAC at least as long as that in the corresponding request, removes the need for specific numerical length constraints to be stated in this document. IMHO the SHOULD here should become MUST, promoting this to a full requirement. The special cases identified in 6.5.1 and 6.5.2 are obviously not subject to the general policy. Security conscious users will define their policy having regard to performance and size versus strength trade-offs and weaknesses of particular algorithms about which there is no shortage of published material. Requirement Name --- Mandatory HMAC-MD5.SIG-ALG.REG.INT Optionalgss-tsig Mandatory hmac-sha1 Optionalhmac-sha224 Mandatory hmac-sha256 Optionalhmac-sha384 Optionalhmac-sha512 Table 1 SHA-1 truncated to 96 bits (12 octets) SHOULD be implemented. --Dick ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] RFC 2845bis and HMAC-MD5
On Thu, 14 Mar 2019 at 11:08, Tony Finch wrote: > Martin Hoffmann wrote: > > > > As such, I would like to propose to move HMAC-MD5 to optional and only > > retain SHA-1 and SHA-256 as mandatory. > > That seems sensible. There should at the very least be a reference to > RFC6151, Updated Security Considerations for the MD5 Message-Digest and > the HMAC-MD5 Algorithms. > Agreed. I can't remember the last time I generated an HMAC-MD5 key .. and I believe the default behaviour for most (all?) recent major distributions default to something stronger (e.g. BIND now defaults to HMAC-SHA256). Any operators needing to support old key algorithms would be free to use distributions that continue to optionally support them, or generate and distribute new keys (something that should be done periodically anyway). ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [hrpc] Proposal for a side-meeting on services centralization at IETF 104 Prague
Paul, I'm trying to understand your scenario. If you ran your own DoH server in your network (doing RDNS or whatnot), and the DoH server is distributed to clients via DHCP + a protocol upgrade mechanism, would that address the concerns you are listing? Vinicius Fortuna On Thu, Mar 14, 2019 at 1:33 AM Paul Vixie wrote: > On Thursday, 14 March 2019 00:48:53 UTC Ted Lemon wrote: > > On Mar 12, 2019, at 2:52 PM, Paul Vixie wrote: > > > please do not relegate discussions about the loss of operator control > over > > > the RDNS control plane > > > > Although it’s certainly true that DNS is used as a control plane by many > > operators, there is no standard “RDNS control plane.” ... > > i don't think lack of standardization is the same as not existing. devices > which honour the dhcp-assigned rdns service, work as expected, and as > intended. devices who ignore that setting and seek their own rdns by their > own > internal configuration, will often not work at all. > > because many of us amend our locally visible dns namespace with things > like > .corp or .home or .local, it's even more vital that devices respect the > rdns > assignment i make. the dns content i want to be visible on my network, > have to > be visible on my network. > > because many of us won't allow pirate or malware or otherwise undesired > DNS > lookups to succeed, either because we don't like the name, or we don't > like > the result of the query, or we don't like some name server that would be > involved in resolving it. the dns content i don't want to be visible on my > network, have to not be visible on my network. > > from the days before dhcp when we typed these numbers in by hand, until > now, > it has always been the expectation that rdns was part-and-parcel of local > network service. no different in that regard from dhcp or arp, neither of > which is standardized under the heading, "control plane", yet, are. > > so i think i'm not going to follow you down this terminological rabbit > hole. > the reason that internet creations of yours will work better on my network > if > you treat the rdns as part of my control plane is, because it's my network > and > that's how i operate it. you're not welcome to bypass it, nor answer dhcp > requests when you're not my dhcp server, nor answer arp requests when you > aren't the device i assigned that address to. > > you can call that tautological if you wish. but it's the life my networks > lead. external DoH providers are explicitly not welcome to provide service > to > malware or intruders who get into my network -- because rdns is part of my > control plane, and like arp and dhcp, i control it and i monitor it, for > $reasons. > > > The problem with the discussion we’ve been having about DoH and how it > > affects your “RDNS control plane” is that we’re talking past each other, > > not that the discussion should be had elsewhere. It’s fine for there to > > be a discussion, but if there is going to be a discussion, participants > > need to engage constructively, and not just fling slogans at each other.. > > i think i've flung considerably more than slogans, and, it's been > exhausting. > > vixie > > > ___ > hrpc mailing list > h...@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc > ___ 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
On Mar 14, 2019, at 10:41 AM, Ralf Weber wrote: > Well as you said it is something that will not get consensus at the IETF, so > why work on that? However as you said these RDNS control planes exist in real > life and even if there is no IETF standard for it, the IETF should consider > actual deployments when doing work and not just IETF standards IMHO and that > is what the drafts out there trying to do, bring the view of people operating > these services into the IETF. Sorry, I expressed myself fairly poorly. What I mean is that it’s important to agree on what we are talking about before we try to talk about it, because otherwise a lot of useless back-and-forth happens where one person is arguing from one set of assumptions, and another person is arguing from a different set of assumptions, and neither is able to feel heard. It can feel very political to go meta on a discussion like this, but I think it’s important for people to actually agree on what the various views are of the problem and solution spaces. That is, not agree that this problem is the correct view of the problem, or that that solution is the correct solution to a problem, but to enumerate all the views of the problem that various participants have, and enumerate all the solutions to these various problems that people are interested in. With that overview, a winnowing process is possible; without it, we just have endless non-terminal discussion. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-privacy] [Doh] New: draft-bertola-bcp-doh-clients
On 3/13/19 6:17 PM, Stephen Farrell wrote: > Those seem like unrelated (and repetitive) points, except for your > attempt to try equate (I assume) a browser using DoH with malware.> That's > the kind of overblown statement that detracts from any other > reasonable points you may make (for me at least). No, that's not quite it. My point is that lots of people who support DoH say that this cat is already out of the bag. My point is to agree with Paul and Jim and others who have noted that it's a matter of scale and legitimization as a proposed standard that *differentiates* DoH from malware. Apologies if my previous post was too wordy or repetitive, so I'll just sum it up: I question the assumption, made in these threads, that DoH affords users more control. thanks, michael ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [hrpc] Proposal for a side-meeting on services centralization at IETF 104 Prague
Moin! On 14 Mar 2019, at 10:53, Stephen Farrell wrote: 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? The experiment Mozilla did switched these 25000 users to use DoH and gave that option as the default option: https://blog.nightly.mozilla.org/2018/08/28/firefox-nightly-secure-dns-experimental-results/ I am aware of what FF/CF have done but I don't believe that was on by default. It was only for nightly users and only for users that have opted in for experiments, but it still IMHO gave a bad impression, as it was viewed by many as a plan send all future DNS traffic to Cloudflare. I still think giving a singular known option as it is the case currently if you click the Dns over HTTPs button in Firefox is a bad idea, but at least it is off per default. So long -Ralf —-- Ralf Weber ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] RFC 2845bis and HMAC-MD5
Martin Hoffmann wrote: > > As such, I would like to propose to move HMAC-MD5 to optional and only > retain SHA-1 and SHA-256 as mandatory. That seems sensible. There should at the very least be a reference to RFC6151, Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms. Tony. -- f.anthony.n.finchhttp://dotat.at/ Shetland Isles: Variable 3 or less, becoming west or southwest 4 or 5, occasionally 6 later. Moderate or rough. Showers. Moderate or good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [hrpc] Proposal for a side-meeting on services centralization at IETF 104 Prague
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. Thanks, S. PS: Apologies if there's a reference in one of the I-Ds, but I don't recall there being one for that assertion. 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] RFC 2845bis and HMAC-MD5
Hi, when looking over draft-ietf-dnsop-rfc2845bis I was hoping that it would relax the mandatory requirement for HMAC-MD5, but no such luck. Given that most protocols have either made MD5 optional or banned it outright, some modern crypto libraries have decided to drop it from their supported algorithms. It seems to me that forcing new code to include dependencies for MD5 is unnecessary. As such, I would like to propose to move HMAC-MD5 to optional and only retain SHA-1 and SHA-256 as mandatory. Kind regards, Martin ___ 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
Moin! On 13 Mar 2019, at 20:48, Ted Lemon wrote: On Mar 12, 2019, at 2:52 PM, Paul Vixie wrote: please do not relegate discussions about the loss of operator control over the RDNS control plane Although it’s certainly true that DNS is used as a control plane by many operators, there is no standard “RDNS control plane.” If you think there should be, that’s something that the IETF could conceivably work on, but it’s not something that the DoH working group is obligated to treat as a standard use of DNS. And I don’t think it’s a topic on which there is consensus in the IETF. Well as you said it is something that will not get consensus at the IETF, so why work on that? However as you said these RDNS control planes exist in real life and even if there is no IETF standard for it, the IETF should consider actual deployments when doing work and not just IETF standards IMHO and that is what the drafts out there trying to do, bring the view of people operating these services into the IETF. The problem with the discussion we’ve been having about DoH and how it affects your “RDNS control plane” is that we’re talking past each other, not that the discussion should be had elsewhere. It’s fine for there to be a discussion, but if there is going to be a discussion, participants need to engage constructively, and not just fling slogans at each other. So you are ok with having this discussion in DoH, which is good, as the DoH protocol caused some application providers to experiment with switching resolution per default away from OS and the local network provider. A lot of the exhausting thread however was about moving the discussion away from DoH. I’ll personally have the discussion anywhere, but given that the drafts have been given time in doh and people might have planned there schedule around that it should be the place. I also think Paul and others have engaged constructive in the discussion about the topic. So long -Ralf —-- Ralf Weber ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-sury-toorop-dns-cookies-algorithms-00.txt
On Tue, Mar 12, 2019 at 7:29 AM Willem Toorop wrote: > Dear DNSOP, > > A new draft has been submitted addressing the issue of DNS Cookies in > multi-vendor anycast deployments. > > DNS Cookies are currently impractical in such deployments, because one > implementation - even though it shares its secret with another > implementation - cannot validate the Server Cookies constructed by that > other implementation, because their methods for constructing Server > Cookies differ. > > This draft provides precise directions for creating Server Cookies to > align the implementations. In doing so, this draft introduces a > registry for functions suitable for Cookie construction. More > specifically, FNV and HMAC-SHA-256-64 are obsoleted and SipHash-2.4 is > introduced as a suitable function. > > Willem > > Forwarded Message > Subject: New Version Notification for > draft-sury-toorop-dns-cookies-algorithms-00.txt > Date: Mon, 11 Mar 2019 09:12:24 -0700 > From: internet-dra...@ietf.org > To: Willem Toorop , Ondrej Sury > > > A new version of I-D, draft-sury-toorop-dns-cookies-algorithms-00.txt > has been successfully submitted by Willem Toorop and posted to the > IETF repository. > > Name: draft-sury-toorop-dns-cookies-algorithms > Revision: 00 > Title: Algorithms for Domain Name System (DNS) Cookies > construction > Document date: 2019-03-11 > Group: Individual Submission > Pages: 7 > URL: > > https://www.ietf.org/internet-drafts/draft-sury-toorop-dns-cookies-algorithms-00.txt > Status: > https://datatracker.ietf.org/doc/draft-sury-toorop-dns-cookies-algorithms/ > Htmlized: > https://tools.ietf.org/html/draft-sury-toorop-dns-cookies-algorithms-00 > Htmlized: > > https://datatracker.ietf.org/doc/html/draft-sury-toorop-dns-cookies-algorithms > > > Abstract: >[RFC7873] left the construction of Server Cookies to the discretion >of the DNS Server (implementer) which has resulted in a gallimaufry >of different implementations. As a result, DNS Cookies are >impractical to deploy on multi-vendor anycast networks, because the >Server Cookie constructed by one implementation cannot be validated >by another. > >This document provides precise directions for creating Server Cookies >to address this issue. Furthermore, [FNV] is obsoleted as a suitable >Hash function for calculating DNS Cookies. [SipHash-2.4] is >introduced as a new REQUIRED Hash function for calculating DNS >Cookies. > >This document updates [RFC7873] > This document looks useful, but I have a concern: 2. Constructing a Client Cookie "If a secure pseudorandom function (like SipHash24) is used there's no need to change Client secret periodically and change the Client secret only if it has been compromised." 3. Constructing a Server Cookie "The Server Cookie is not required to be changed periodically if a secure pseudorandom function is used." I am not a cryptography expert, but the above sounds like the Client secret and Server Cookie could be left forever without changing them, which seems like a bad idea. And how would one know "if it has been compromised"? Please explain. I you meant "change every few years instead of hourly", then please say that. -- Bob Harold ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
