Re: F34 Change proposal: DNS Over TLS (System-Wide Change)
On Fri, Oct 9, 2020 at 12:31 pm, Paul Wouters wrote: The main use case of DNS-over-TLS is to bypass untrustworthy DNS, which often means the local DHCP provided DNS of the coffeeshop/hotel. The importance of doing DNS-over-TLS to your local ISP is pretty minor compare to the security and privacy conerns raised of the current systemd-resolved implementation and default configuration. To avoid any misunderstanding, this change does nothing to bypass untrustworthy DNS. It only works if your DNS is trustworthy, and even then, impact is limited. From my proposed release notes: "Be aware that Fedora can only encrypt traffic between you and your DNS server, and then only if supported by your DNS server. For example, if you are connected to a home router, the DNS between your laptop and your router will be encrypted if supported by your router, but this change has no impact on what happens between your router and your ISP unless your router is running Fedora and your ISP supports DoT." ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F34 Change proposal: DNS Over TLS (System-Wide Change)
On Thu, 8 Oct 2020, Michael Catanzaro wrote: On Thu, Oct 8, 2020 at 1:28 pm, Paul Wouters wrote: I agree for two reasons. One, the FESCO decision to postpone making systemd-resolvd the default resolver. I would like to ensure this change happens properly and securely for f34. Well it's too late, since we are now in final freeze. FESCo reaffirmed the systemd-resolved change just last week I was not aware of this. I've left a comment in the FESCO issue. It is unfortunately that the issue provides no information why FESCO made this decision, other than vote tally about why it rejected it. I would appreciate it if FESCO would clarify their argumentation for this decision. Clearly it is very disappointing to me that we are accepting such a security and standards compliance degradation, especially without a plan to address that for f34. , so it's clearly not going to be postponed. I agree that this DNSSEC problem with systemd-resolved is unfortunate, and I'm sure the systemd developers would appreciate help fixing it. This assumes the issues reported are seen as bugs and not features by the systemd developers. I have no seen such agreement on the security and privacy issues I have reported. Anyway, the best time to deal with this would have been six months ago, when the change was proposed This was reported 5 years ago in a physical meeting. Scolding me now for not reporting this 6 months ago is not a proper justification, and in fact sounds more like victim blaming. Here is my counter proposal for this f34 feature. It is clearly now 6 months in advance of f34 that some of us reported a number of systemd-resolved related problems. Let's get these fixed before adding new systemd-resolved features in f34. That is, it is far more appropriate to have a f34 feature of "fix security and RFC standards comforming bugs in systemd-resolved" than it is to just add more new features without addressing the previous feature that has significant security bugs. Even if the main goal of such a feature is to force the systemd-resolved developers to focus on a security and privacy commitment before adding new features. That's why we did this in two parts. F33: systemd-resolved. F34: DoT. We could have done them both at once. It looks like the f33 feature did not get done properly at once, so I am glad we did not do both features as once. If we do this feature for f34 while there were serious issues reporting in the f33 feature, then basically we would _still_ be doing these two features at the same time. So in your own words, you are agreeing with me that the f33 feature should be cleaned up before doing this f34 scheduled feature. So yes, put this feature in f35 and create a f34 feature to cleanup the f33 feature. That would show that the issues we have been reported are taken seriously and address my concern that moving forward with this feature will cause my issues to never get addressed. Second, we really need any DNS-over-TLS to not break DNSSEC. If we are going to outsource validation to a remote endpoint via DNS-over-TLS, instead of using the local resolver or the local ISP resolver, then data authenticity becomes eveb more important. And DNS-over-TLS only provides transport security, not data origin authenticity. Look, I really don't understand, sorry. How is this in any way related to DNSSEC? I think this has zero relation to DNSSEC. The main use case of DNS-over-TLS is to bypass untrustworthy DNS, which often means the local DHCP provided DNS of the coffeeshop/hotel. The importance of doing DNS-over-TLS to your local ISP is pretty minor compare to the security and privacy conerns raised of the current systemd-resolved implementation and default configuration. What Fedora needs is for the DNS resolution to re-stabilize, and to not add more features while there are several security issues at play. Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F34 Change proposal: DNS Over TLS (System-Wide Change)
On 10/8/20 2:24 PM, Björn Persson wrote: Michael Catanzaro wrote: On Thu, Oct 8, 2020 at 1:28 pm, Paul Wouters wrote: I agree for two reasons. One, the FESCO decision to postpone making systemd-resolvd the default resolver. I would like to ensure this change happens properly and securely for f34. Well it's too late, since we are now in final freeze. FESCo reaffirmed the systemd-resolved change just last week, so it's clearly not going to be postponed. I agree that this DNSSEC problem with systemd-resolved is unfortunate, and I'm sure the systemd developers would appreciate help fixing it. Anyway, the best time to deal with this would have been six months ago, when the change was proposed The DNSsec problem was brought up by Florian Weimer and Tom Hughes six months ago, when the change was proposed. Fesco or the change owners could have chosen to "deal with" the problem then, if they cared about DNSsec. You Michael replied to Florian and called DNSsec-aware clients "a quite specialized use-case", so you can't claim that you were unaware of the issue. "It's too late" rings hollow coming from someone who had the chance to do something when it wasn't too late. Björn Persson Or how about we stick to the Friends Foundation and not make it personal? -- Erich Eickmeyer Maintainer Fedora Jam ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F34 Change proposal: DNS Over TLS (System-Wide Change)
Michael Catanzaro wrote: > On Thu, Oct 8, 2020 at 1:28 pm, Paul Wouters wrote: > > I agree for two reasons. One, the FESCO decision to postpone making > > systemd-resolvd the default resolver. I would like to ensure this > > change happens properly and securely for f34. > > Well it's too late, since we are now in final freeze. FESCo reaffirmed > the systemd-resolved change just last week, so it's clearly not going > to be postponed. I agree that this DNSSEC problem with systemd-resolved > is unfortunate, and I'm sure the systemd developers would appreciate > help fixing it. Anyway, the best time to deal with this would have been > six months ago, when the change was proposed The DNSsec problem was brought up by Florian Weimer and Tom Hughes six months ago, when the change was proposed. Fesco or the change owners could have chosen to "deal with" the problem then, if they cared about DNSsec. You Michael replied to Florian and called DNSsec-aware clients "a quite specialized use-case", so you can't claim that you were unaware of the issue. "It's too late" rings hollow coming from someone who had the chance to do something when it wasn't too late. Björn Persson pgp9q1oKjfcMf.pgp Description: OpenPGP digital signatur ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F34 Change proposal: DNS Over TLS (System-Wide Change)
On Thu, Oct 8, 2020 at 1:28 pm, Paul Wouters wrote: I agree for two reasons. One, the FESCO decision to postpone making systemd-resolvd the default resolver. I would like to ensure this change happens properly and securely for f34. Well it's too late, since we are now in final freeze. FESCo reaffirmed the systemd-resolved change just last week, so it's clearly not going to be postponed. I agree that this DNSSEC problem with systemd-resolved is unfortunate, and I'm sure the systemd developers would appreciate help fixing it. Anyway, the best time to deal with this would have been six months ago, when the change was proposed I am still trying to use this setup on my f33 with DNSSEC enabled for systemd-resolved, and do still seem to have issues that I'm going through to see if these are related to DNS or not. I feel we should have this working solidly first, before we are adding more options and features into the mix. That's why we did this in two parts. F33: systemd-resolved. F34: DoT. We could have done them both at once. Second, we really need any DNS-over-TLS to not break DNSSEC. If we are going to outsource validation to a remote endpoint via DNS-over-TLS, instead of using the local resolver or the local ISP resolver, then data authenticity becomes eveb more important. And DNS-over-TLS only provides transport security, not data origin authenticity. Look, I really don't understand, sorry. How is this in any way related to DNSSEC? I think this has zero relation to DNSSEC. Are you assuming that we're going to ignore DHCP-provided DNS and hardcode 1.1.1.1 or 8.8.8.8? The change page says we will not do that. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F34 Change proposal: DNS Over TLS (System-Wide Change)
On Thu, 8 Oct 2020, Petr Menšík wrote: I would like to request pausing any new systemd-resolved features system-wide, until its current bugs and deficiencies are resolved sufficiently. I agree for two reasons. One, the FESCO decision to postpone making systemd-resolvd the default resolver. I would like to ensure this change happens properly and securely for f34. I am still trying to use this setup on my f33 with DNSSEC enabled for systemd-resolved, and do still seem to have issues that I'm going through to see if these are related to DNS or not. I feel we should have this working solidly first, before we are adding more options and features into the mix. Second, we really need any DNS-over-TLS to not break DNSSEC. If we are going to outsource validation to a remote endpoint via DNS-over-TLS, instead of using the local resolver or the local ISP resolver, then data authenticity becomes eveb more important. And DNS-over-TLS only provides transport security, not data origin authenticity. Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F34 Change proposal: DNS Over TLS (System-Wide Change)
I would like to request pausing any new systemd-resolved features system-wide, until its current bugs and deficiencies are resolved sufficiently. And no, repeating that non-sense again, saying DNSSEC is only the server stuff nobody needs on desktop, would not count as fixed bug. Every TLS endpoint needs certificate. DNS has also signatures on zone data, which should be verified even over encrypted channel. Visit [1] to read more about difference between the two terms. And how they go along each other. In our view, current systemd-resolved has brought many regressions into F33. Let's wait with its new features, users can enable DNS over TLS any time already. Fix please years old issues first. 1. https://blog.apnic.net/2018/08/20/dnssec-and-dns-over-tls/ Best Regards, Petr On 9/29/20 10:29 PM, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/DNS_Over_TLS > > == Summary == > Fedora will attempt to use DNS over TLS (DoT) if supported by > configured DNS servers. > > == Owner == > * Name: [[User:catanzaro|Michael Catanzaro]] > * Email: > * Name: [[User:Zbyszek|Zbigniew Jędrzejewski-Szmek]] > * Email: > > == Detailed Description == > > We will build systemd with `-Ddefault-dns-over-tls=opportunistic` to > protect DNS queries against passive network attackers. An active > network attacker can trivially subvert this protection, but we cannot > make DoT mandatory because other operating systems do not do so and > many (or most?) DNS servers do not support it. DoT will only be used > if the configured DNS server supports it and if it is not blocked by > an active network attacker. > > Note that DoT is different from DNS over HTTPS (DoH). In particular, > DoT is not an anti-censorship tool like DoH. It does not look like > regular HTTPS traffic, and it can be blocked by network administrators > if desired, so it should not be a problem for corporate networks. > > > == Benefit to Fedora == > > DNS queries are encrypted and private by default, if the user's ISP > supports DoT. Most probably don't, but users who manually configure a > custom DNS server (e.g. Cloudflare or Google) will automatically > benefit from DNS over TLS. > > == Scope == > * Proposal owners: change meson flags in systemd.spec > * Other developers: N/A (nothing should be required) > * Release engineering: [https://pagure.io/releng/issue/9772 #9772] (a > check of an impact with Release Engineering is needed) > * Policies and guidelines: N/A (nothing should be required) > * Trademark approval: N/A (not needed for this Change) > * Alignment with Objectives: Nope > > == Upgrade/compatibility impact == > DoT will be enabled automatically on upgrade to F34. If DoT is > unsupported, systemd-resolved will fall back to unencrypted DNS, so > there should be no compatibility impact. > > == How To Test == > Load any website in a web browser. If you succeed, then name > resolution probably works. > > Try using `resolvectl query fedoraproject.org` to see that resolvectl > still works. > > Bonus points: set your DNS server to 1.1.1.1 or 8.8.8.8, then use > Wireshark to see if your DNS is really encrypted or not. > > == User Experience == > Users should not notice any difference in behavior. > > == Dependencies == > No dependencies. > > == Contingency Plan == > > * Contingency mechanism: revert the change > * Contingency deadline: can be done at any time, before F34 beta > freeze would be best > * Blocks release? No > * Blocks product? No > > == Documentation == > See the section `DNSOverTLS=` in the manpage `resolved.conf(5)` > > == Release Notes == > systemd-resolved now enables DNS over TLS (DoT) support by default, in > opportunistic mode. DoT will be used only if supported by your DNS > server, and provides only best-effort encryption to protect against > passive network observers. For compatibility with existing DNS > servers, systemd-resolved will fall back to unencrypted DNS if DoT > does not appear to be supported, reducing the security benefit. If you > wish to manually configure systemd-resolved to prevent fallback to > unencrypted DNS, set `DNSOverTLS=yes` in `/etc/systemd/resolved.conf`. > Note that DoT is different than DNS over HTTPS (DoH) in that it does > not use HTTPS and is therefore easy to distinguish from HTTPS traffic. > > -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
F34 Change proposal: DNS Over TLS (System-Wide Change)
https://fedoraproject.org/wiki/Changes/DNS_Over_TLS == Summary == Fedora will attempt to use DNS over TLS (DoT) if supported by configured DNS servers. == Owner == * Name: [[User:catanzaro|Michael Catanzaro]] * Email: * Name: [[User:Zbyszek|Zbigniew Jędrzejewski-Szmek]] * Email: == Detailed Description == We will build systemd with `-Ddefault-dns-over-tls=opportunistic` to protect DNS queries against passive network attackers. An active network attacker can trivially subvert this protection, but we cannot make DoT mandatory because other operating systems do not do so and many (or most?) DNS servers do not support it. DoT will only be used if the configured DNS server supports it and if it is not blocked by an active network attacker. Note that DoT is different from DNS over HTTPS (DoH). In particular, DoT is not an anti-censorship tool like DoH. It does not look like regular HTTPS traffic, and it can be blocked by network administrators if desired, so it should not be a problem for corporate networks. == Benefit to Fedora == DNS queries are encrypted and private by default, if the user's ISP supports DoT. Most probably don't, but users who manually configure a custom DNS server (e.g. Cloudflare or Google) will automatically benefit from DNS over TLS. == Scope == * Proposal owners: change meson flags in systemd.spec * Other developers: N/A (nothing should be required) * Release engineering: [https://pagure.io/releng/issue/9772 #9772] (a check of an impact with Release Engineering is needed) * Policies and guidelines: N/A (nothing should be required) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: Nope == Upgrade/compatibility impact == DoT will be enabled automatically on upgrade to F34. If DoT is unsupported, systemd-resolved will fall back to unencrypted DNS, so there should be no compatibility impact. == How To Test == Load any website in a web browser. If you succeed, then name resolution probably works. Try using `resolvectl query fedoraproject.org` to see that resolvectl still works. Bonus points: set your DNS server to 1.1.1.1 or 8.8.8.8, then use Wireshark to see if your DNS is really encrypted or not. == User Experience == Users should not notice any difference in behavior. == Dependencies == No dependencies. == Contingency Plan == * Contingency mechanism: revert the change * Contingency deadline: can be done at any time, before F34 beta freeze would be best * Blocks release? No * Blocks product? No == Documentation == See the section `DNSOverTLS=` in the manpage `resolved.conf(5)` == Release Notes == systemd-resolved now enables DNS over TLS (DoT) support by default, in opportunistic mode. DoT will be used only if supported by your DNS server, and provides only best-effort encryption to protect against passive network observers. For compatibility with existing DNS servers, systemd-resolved will fall back to unencrypted DNS if DoT does not appear to be supported, reducing the security benefit. If you wish to manually configure systemd-resolved to prevent fallback to unencrypted DNS, set `DNSOverTLS=yes` in `/etc/systemd/resolved.conf`. Note that DoT is different than DNS over HTTPS (DoH) in that it does not use HTTPS and is therefore easy to distinguish from HTTPS traffic. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
F34 Change proposal: DNS Over TLS (System-Wide Change)
https://fedoraproject.org/wiki/Changes/DNS_Over_TLS == Summary == Fedora will attempt to use DNS over TLS (DoT) if supported by configured DNS servers. == Owner == * Name: [[User:catanzaro|Michael Catanzaro]] * Email: * Name: [[User:Zbyszek|Zbigniew Jędrzejewski-Szmek]] * Email: == Detailed Description == We will build systemd with `-Ddefault-dns-over-tls=opportunistic` to protect DNS queries against passive network attackers. An active network attacker can trivially subvert this protection, but we cannot make DoT mandatory because other operating systems do not do so and many (or most?) DNS servers do not support it. DoT will only be used if the configured DNS server supports it and if it is not blocked by an active network attacker. Note that DoT is different from DNS over HTTPS (DoH). In particular, DoT is not an anti-censorship tool like DoH. It does not look like regular HTTPS traffic, and it can be blocked by network administrators if desired, so it should not be a problem for corporate networks. == Benefit to Fedora == DNS queries are encrypted and private by default, if the user's ISP supports DoT. Most probably don't, but users who manually configure a custom DNS server (e.g. Cloudflare or Google) will automatically benefit from DNS over TLS. == Scope == * Proposal owners: change meson flags in systemd.spec * Other developers: N/A (nothing should be required) * Release engineering: [https://pagure.io/releng/issue/9772 #9772] (a check of an impact with Release Engineering is needed) * Policies and guidelines: N/A (nothing should be required) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: Nope == Upgrade/compatibility impact == DoT will be enabled automatically on upgrade to F34. If DoT is unsupported, systemd-resolved will fall back to unencrypted DNS, so there should be no compatibility impact. == How To Test == Load any website in a web browser. If you succeed, then name resolution probably works. Try using `resolvectl query fedoraproject.org` to see that resolvectl still works. Bonus points: set your DNS server to 1.1.1.1 or 8.8.8.8, then use Wireshark to see if your DNS is really encrypted or not. == User Experience == Users should not notice any difference in behavior. == Dependencies == No dependencies. == Contingency Plan == * Contingency mechanism: revert the change * Contingency deadline: can be done at any time, before F34 beta freeze would be best * Blocks release? No * Blocks product? No == Documentation == See the section `DNSOverTLS=` in the manpage `resolved.conf(5)` == Release Notes == systemd-resolved now enables DNS over TLS (DoT) support by default, in opportunistic mode. DoT will be used only if supported by your DNS server, and provides only best-effort encryption to protect against passive network observers. For compatibility with existing DNS servers, systemd-resolved will fall back to unencrypted DNS if DoT does not appear to be supported, reducing the security benefit. If you wish to manually configure systemd-resolved to prevent fallback to unencrypted DNS, set `DNSOverTLS=yes` in `/etc/systemd/resolved.conf`. Note that DoT is different than DNS over HTTPS (DoH) in that it does not use HTTPS and is therefore easy to distinguish from HTTPS traffic. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
