Hi Ryan,
On 23/05/2024 19:01, Ryan Hurst wrote:
Regarding the concern about government-mandated adoption of root
certificates, I also care deeply about this issue. This is why I am
disappointed by the one-sided nature of the conversation. I see no
mechanism in this proposal that bypasses operator consent, and while
governments do and will continue to force operators to make changes
not in their interest, this proposal doesn't change that reality.
Continuing to focus on this issue in this way detracts from the more
constructive discussions happening in this thread.
The problem here is that fragmentation (which you acknowledge as a
compelling concern) combined with making it much easier to deploy new
CAs (a core goal of the draft) which together alters the power balance
between the security community and governments in rather the wrong
direction. I am not going to spend any further words on it here, but I'm
disappointed you've engaged so dismissively in what has become a long
discussion on a deeply complex topic.
The most compelling argument against Trust Expressions I see in the
thread is the potential for fragmentation. However, the current
conversation on this topic overlooks the existing fragmentation
challenges faced by site operators. The primary concern I hear from
these operators is the anxiety over changes related to cipher suites
and certificates, fearing that these changes might inadvertently break
services in exchange for security properties that their leadership
isn’t asking for. Trust Expressions, in my view, offers a net-positive
solution to this problem by allowing site operators to manage the
trust anchor portion of this risk, which they cannot do effectively today.
Is it not rather the opposite, that this draft will give server
operators an additional product space of choices and incompatibilities?
With Trust Expressions, we must anticipate that CAs will need to jump
through at least four separate hoops to provision a chain for each of
the major root stores, as well as provision a chain for any past
incompatible versions which are still popular. History does not suggest
that CAs are particularly capable of managing these considerably more
complex structures, given existing struggles with getting single chains
correct.
Worse, we cannot expect Trust Expressions to become universal in any
reasonable timeframe, meaning we still have the compatibility headache
of existing and new clients with no Trust Expressions support.
At the same time, we are seeing more embedded devices being deployed
without long-term maintenance strategies, automatic updates, or
mechanisms to manage root store lists.
Can you evidence this? The UK and the EU have passed fairly sweeping
laws over the past year to require that manufacturers provide long term
maintenance and security updates for the entire lifecycle of new digital
products [1,2]. The USA usually catches up eventually.
Better still, with the shift to PQ we have the best opportunity to adopt
the Chrome Root Program's proposal for 7 year certificates. This would
entirely fix this issue by pushing it from website operators to device
manufacturers, where it should belong anyway :-), rather than creating a
fragmented compatibility nightmare by embracing it and putting labels on
it.
Best,
Dennis
[1] https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
[2]
https://www.gov.uk/government/news/new-laws-to-protect-consumers-from-cyber-criminals-come-into-force-in-the-uki
On Thu, May 23, 2024 at 10:40 AM Watson Ladd <watsonbl...@gmail.com>
wrote:
On Thu, May 23, 2024 at 12:42 PM David Benjamin
<david...@chromium.org> wrote:
<snip>
>
> Of course, whether this property (whether servers can usefully
pre-deploy not-yet-added trust anchors), which trust expressions
does not have, even matters boils to whether a root program would
misinterpret availability in servers as a sign of CA
trustworthiness, when those two are clearly unrelated to each
other. Ultimately, the trustworthiness of CAs is a subjective
social question: do we believe this CA has *and will continue*
only sign true things? We can build measures to retroactively
catch issues like Certificate Transparency, but the key question
is fundamentally forward-looking. The role of a root program is to
make judgement calls on this question. A root program that so
misunderstands its role in this system that it conflates these two
isn't going to handle its other load-bearing responsibilities either.
As the old saw goes "past performance is no guarantee of future
results, but it sure helps". Moreover root programs have to balance
the benefits of including a CA against the costs. One of those
benefits is the number of sites that use it.
Sincerely,
Watson
>
> David
> _______________________________________________
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
--
Astra mortemque praestare gradatim
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
_______________________________________________ TLS mailing list --
tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
