On Thu, 8 Oct 2020, Michael Catanzaro wrote:
On Thu, Oct 8, 2020 at 1:28 pm, Paul Wouters <paul@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
