Re: [TLS] WG Adoption for TLS Trust Expressions

[Dennis Jackson]

Hi David, Devon, Bob,

I feel much of your response talks past the issue that was raised at 
IETF 118.


The question we're evaluating is NOT "If we were in a very unhappy world 
where governments controlled root certificates on client devices and 
used them for mass surveillance, does Trust Expressions make things 
worse?".Although Watson observed that the answer to this is at least 
'somewhat', I agree such a world is already maxed at 10/10 on the 
bad worlds to live in scale and so it's not by itself a major problem in 
my view.


The actual concern is: to what extent do Trust Expressions increase the 
probability that we end up in this unhappy world of government CAs used 
for mass surveillance?


The case made earlier in the thread is that it increases the probability 
substantially because it provides an effective on-ramp for new CAs even 
if they exist entirely outside of existing root stores. Websites can 
adopt such a CA without being completely broken and unavailable as they 
would be today. Although I think it's unlikely anyone would 
independently do this, it's easy to see a website choosing to add such a 
certificate (which is harmless by itself) if a government 
incentivized or required it.  Trust Expressions also enables existing 
CAs to force-push a cert chain from a new CA to a website,  without the 
consent or awareness of the website operator, further enabling the 
proliferation of untrusted (and presumably unwanted) CAs.


These features neatly solve the key challenges of deploying a government 
CA, which as discussed at length in the thread, are to achieve enough 
legitimacy through website adoption to have a plausible case for 
enforcing client adoption. The real problem here is that you've 
(accidentally?) built a system that makes it much easier to adopt and 
deploy any new CA regardless of trust, rather than a system that makes 
it easier to deploy & adopt any new *trusted* CA. If you disagree with 
this assessment, it would be great to hear your thoughts on why. 
Unfortunately, none of the arguments in your email come close to 
addressing this point and the text in the draft pretty much tries to 
lampshade these problems as a feature.


The other side of this risk evaluation is assessing how effectively 
Trust Expressions solves real problems.


Despite a lot of discussion, I've only seen one compelling unsolved 
problem which Trust Expressions is claimed to be able to solve. That is 
the difficulty large sites have supporting very old clients with 
out-of-date root stores (as described by Kyle). This leads to sites 
using complex & brittle TLS fingerprinting to decide which certificate 
chain to send or to sites using very particular CAs designed to 
maximizecompatibility (e.g. Cloudflare's recent change).


However, it's unclearhow Trust Expressions solves either fingerprinting 
or the new trusted root ubiquity challenge. To solve the former, we're 
relying on the adoption of Trust Expressions by device manufacturers who 
historically have not been keen to adopt new TLS extensions. For the 
latter, Trust Expressions doesn't seem to solve anything. Sites / CDNs 
are still forced to either have a business arrangement with a single 
suitably ubiquitous root or to conclude multiple such arrangements 
(which come with considerable baggage) with both new and ubiquitous 
roots - in return for no concrete benefit. Ifwe had Trust 
Expressions deployed today, how would life be better for LE / Cloudflare 
or other impacted parties?


I won't detail them here, but it seems like there are simpler and more 
effective alternatives that would address the underlying problem, e.g. 
through root stores encouraging cross-signing or offering cross-signing 
services themselves and using existing techniques to avoid any impact at 
the TLS layer.


I'm struggling to see it being an even partially effective solution for 
any of the other proposed use cases. To pick an example you've 
repeatedly highlighted, can you clarify how Trust Expressions will speed 
the transition to a PQ PKI? Specifically, how much earlier do you expect 
a given site to be able to deploy a PQ cert chain in the case of TE 
adoption vs without TE adoption (and why)?


David, Devon & Bob wrote:

We acknowledge that achieving this level of agility requires a 
significant amount of design and implementation work for web servers, 
certificate automation clients/servers, and clients to support, but 
we believe the improvements called out in some of the discussions on 
this thread strongly outweigh these costs [...]


[...] We think this will drastically improve the ability to migrate 
the Internet to PQC—not just in terms of a faster timeline, but 
because trust anchor agility will enable the community to develop 
fundamentally better solutions for authentication, through reduced 
experimentation costs


I can completely understand why Trust Expressions seems to bring 
substantial benefits to *you*  (as root store operators) but I'm 

Re: [TLS] WG Adoption for TLS Trust Expressions

[David Benjamin]

Hi Dennis, thanks for your feedback.

First, you mention the issue of the possible requirement of key escrow; we
don’t feel that trust expressions make this any more or less of a threat to
the ecosystem. Were a government to require sites to escrow private keys,
it would not matter who signed them since the escrow agent would be in
possession of those private keys, and they or anyone else they give the
private key to would be in the position to compromise connections using
these keys. We hope we can set this point aside as orthogonal to the
remaining bulk of your objections.

Second, there seems to be a concern surrounding trust expressions making it
easier for root stores to diverge due to the multi-certificate model. Trust
stores already diverge today. As you’re likely aware, there are very good
reasons that root programs do not coordinate on trust decisions, so this is
not something that will change in the foreseeable future.

As root programs diverge, subscribers are (often unwittingly) forced to
choose which clients to break as they try to stay within the intersection.
This conflict also impacts root programs by pressuring against trust
changes. The users whose security would benefit from those changes
ultimately bear this cost. We don’t think that a resigned acceptance of the
sharp edges of the status quo is a compelling reason to continue forgoing
trust anchor agility, especially when we are faced with the need to
radically change the entire landscape to accommodate PQC’s large
signatures. In practice, we also don’t think this plays out such that the
long tail of clients are dragged along into security by browsers and other
modern clients. Instead, the state of the art is held back by the long tail.

The multi-certificate model empowers subscribers with the optional ability
to support divergent client trust if they choose to. As an example, one
root program could adopt new post quantum roots and provide immediate
protection for their users without waiting for the slowest or
least-resourced client/browser vendor to follow suit. Other root programs
and their clients would be unaffected by this change and could roll out the
same change on a different timeline or opt for a different approach
altogether.

By design, a multi-certificate model removes the ubiquity requirement for a
trust anchor to be potentially useful for a server operator.  Your concern
seems to be that this could be a way for governments to coerce one root
program to include specific trust anchors and increase mass surveillance.
This is an outcome that root programs, including both Chrome and Mozilla,
have fought against for many years and will continue to do so. This has
been a motivating force behind technologies like certificate transparency,
which enables detection and response to this kind of behavior (and would
continue to exist in some form regardless of trust expressions). I think we
are in agreement with the severity of these hypothetical scenarios, but
strongly disagree at the causality you are drawing between the existence of
a negotiation mechanism and this dystopian end state. In particular,
surveillance requires targeted clients to somehow trust an incorrect key
for a server. If the attacker’s CA is trusted by a client, it can already
sign bad keys. Surveillance only requires inclusion in the root store, it
does not matter whether the attacker’s CA was also useful for server
operators. Signing the correct key for a server does not help the attacker.
This is why we did not add this as a risk to the draft, however we are
happy to add a broader discussion of implications of root program
divergence to a future version.

Looking at the things we believe trust expressions does bring to the table
to improve the security of relying parties:


   -

   The ability for PKIs to transition to newer root keys, instead of
   waiting for ubiquitous adoption of a replacement by all root programs.
   -

   The ability for TLS certificate selection to be robust enough that
   selection can occur entirely within the TLS library and server software.
   Server operators can safely add certificates for new algorithms, without
   compatibility risks that some client supports the new algorithm, but not
   the particular trust anchor.
   -

   The ability to deploy PKI improvements without conflicts from differing
   requirements and schedules in individual root programs and very old clients.
   -

   The ability to support everything else that does not use trust
   expressions, even old devices that can not / will not update, without
   impacting relying parties that wish to move ahead faster.
   -

   Server operators, once software is in place, not needing to be concerned
   about new trust expressions or changes to them. The heavy lifting is
   between the root program and the CA.
   -

   The ability for server operators seamlessly to deploy certificates from
   multiple CAs for redundancy, or to straddle disparate ecosystems.


We 

Re: [TLS] WG Adoption for TLS Trust Expressions

[Eric Rescorla]

On Tue, Apr 30, 2024 at 4:30 PM Dennis Jackson  wrote:

> On 01/05/2024 00:07, Watson Ladd wrote:
>
> On Tue, Apr 30, 2024 at 3:26 PM Dennis 
> Jackson 
>  wrote:
> 
>
> Let's assuming for a moment we could a) get most of the world to use ACME (a 
> worthy but challenging goal) and b) get them to configure multiple CAs and 
> receive multiple certificates. We don't need trust expressions to be able to 
> do quick rotations - because we don't ever want to use the old CA. It's just 
> a case of swapping to the new one. There's no need for negotiation.
>
> We've already seen a serious problem with cross-signing happen, where
> Cloudflare is planning to stop using Lets Encrypt. That's because the
> cross-signed cert that let Lets Encrypt work with old Android devices
> expired, with no replacement. Having websites present one chain
> creates a lot of thorny tradeoffs. Either you present a cross-signed
> certificate, or a few, and take the bandwidth hit, or you don't and
> suffer a compatibility hit. This was manageable when signatures were
> small. When they get chonky it will be much less fun.
>
> There's a huge and unexplored design space here that does not require
> trust negotiation. I don't claim any of these ideas are optimal:
>
>- Techniques like abridged certs + cross signs let you mitigate any
>bandwidth impact for recent-ish clients. Given the older clients are going
>to be missing a lot of performance improvements anyway, this doesn't seem
>unacceptable.
>- Root Programs could introduce specific root certs they operate for
>the sole purpose of cross-signing new CAs to speed up their adoption.
>- Clients could have a TLS flag 'My Root Store is very old' which is
>set when X years without a root store update have passed. Alternatively,
>they advertise an explicit age for their root store or the TLS Flag 'My
>Root Store was updated in the past year'.
>
> Wouldn't we also get this last point as a sort of side effect of abridged
certs?

-Ekr


>- I think there may also be some interesting ways to improve Merkle
>Tree Certs to support these use cases without needing trust negotiation but
>that'll have to wait for another thread.
>
> As far as I'm aware there is no need for cooperation in creating a
> cross-signed intermediate: it's a certificate with a public key and
> just a different signer. So Country X could force its sites to include
> that cross-signed intermediate in the grab bag handed to browsers, and
> everything would work as now. Browsers have to tolerate all sorts of
> slop there anyway. I think the sharper concern is that you could block
> traffic without the cert included.
>
> Sincerely,
> Watson Ladd
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WG Adoption for TLS Trust Expressions

[Dennis Jackson]

On 01/05/2024 00:07, Watson Ladd wrote:


On Tue, Apr 30, 2024 at 3:26 PM Dennis Jackson
  wrote:


Let's assuming for a moment we could a) get most of the world to use ACME (a 
worthy but challenging goal) and b) get them to configure multiple CAs and 
receive multiple certificates. We don't need trust expressions to be able to do 
quick rotations - because we don't ever want to use the old CA. It's just a 
case of swapping to the new one. There's no need for negotiation.

We've already seen a serious problem with cross-signing happen, where
Cloudflare is planning to stop using Lets Encrypt. That's because the
cross-signed cert that let Lets Encrypt work with old Android devices
expired, with no replacement. Having websites present one chain
creates a lot of thorny tradeoffs. Either you present a cross-signed
certificate, or a few, and take the bandwidth hit, or you don't and
suffer a compatibility hit. This was manageable when signatures were
small. When they get chonky it will be much less fun.
There's a huge and unexplored design space here that does not require 
trust negotiation. I don't claim any of these ideas are optimal:


 * Techniques like abridged certs + cross signs let you mitigate any
   bandwidth impact for recent-ish clients. Given the older clients are
   going to be missing a lot of performance improvements anyway, this
   doesn't seem unacceptable.
 * Root Programs could introduce specific root certs they operate for
   the sole purpose of cross-signing new CAs to speed up their adoption.
 * Clients could have a TLS flag 'My Root Store is very old' which is
   set when X years without a root store update have passed.
   Alternatively, they advertise an explicit age for their root store
   or the TLS Flag 'My Root Store was updated in the past year'.
 * I think there may also be some interesting ways to improve Merkle
   Tree Certs to support these use cases without needing trust
   negotiation but that'll have to wait for another thread.


As far as I'm aware there is no need for cooperation in creating a
cross-signed intermediate: it's a certificate with a public key and
just a different signer. So Country X could force its sites to include
that cross-signed intermediate in the grab bag handed to browsers, and
everything would work as now. Browsers have to tolerate all sorts of
slop there anyway. I think the sharper concern is that you could block
traffic without the cert included.

Sincerely,
Watson Ladd
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WG Adoption for TLS Trust Expressions

[Watson Ladd]

On Tue, Apr 30, 2024 at 3:26 PM Dennis Jackson
 wrote:

>
> Let's assuming for a moment we could a) get most of the world to use ACME (a 
> worthy but challenging goal) and b) get them to configure multiple CAs and 
> receive multiple certificates. We don't need trust expressions to be able to 
> do quick rotations - because we don't ever want to use the old CA. It's just 
> a case of swapping to the new one. There's no need for negotiation.

We've already seen a serious problem with cross-signing happen, where
Cloudflare is planning to stop using Lets Encrypt. That's because the
cross-signed cert that let Lets Encrypt work with old Android devices
expired, with no replacement. Having websites present one chain
creates a lot of thorny tradeoffs. Either you present a cross-signed
certificate, or a few, and take the bandwidth hit, or you don't and
suffer a compatibility hit. This was manageable when signatures were
small. When they get chonky it will be much less fun.

As far as I'm aware there is no need for cooperation in creating a
cross-signed intermediate: it's a certificate with a public key and
just a different signer. So Country X could force its sites to include
that cross-signed intermediate in the grab bag handed to browsers, and
everything would work as now. Browsers have to tolerate all sorts of
slop there anyway. I think the sharper concern is that you could block
traffic without the cert included.

Sincerely,
Watson Ladd

-- 
Astra mortemque praestare gradatim

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WG Adoption for TLS Trust Expressions

[Dennis Jackson]

On 30/04/2024 22:33, Brendan McMillion wrote:


This doesn't apply in case we're distrusting a CA because it's
failed. In 9.1 we're rotating keys. As I laid out in my initial
mail, we can already sign the new root with the old root to enable
rotation. There's no size impact to up-to-date clients using
intermediate suppression or abridged certs.


The approach you describe requires the cooperation of the CA, in 
signing the new root with the old root. My understanding is that CAs 
(especially CAs in trouble with their root program) are often 
uncooperative or absentee.
I think one of the two of us is confused. You indicated section 9.1 
which explicit describes key rotation where the operator is staying the 
same but switching to new keys which is what I responded to.  If instead 
you're talking about kicking out a CA for bad behaviour, this draft 
doesn't really help as I pointed out earlier.
It also requires the CA's customers to go through a full issuance 
cycle before they get certificates with the new root, which could take 
over a year, during which time the compromised root will still need to 
be trusted.


The distrust-after mechanism I mentioned doesn't require trusting the 
compromised root during the transition time. SCTs enable us to pin the 
valid certificate set to a fixed point in time.


This draft is substantially better than that. It normalizes websites 
having multiple certificates from different CAs. In a future world 
with widespread adoption of Trust Expressions and ACME, a root could 
be distrusted immediately without warning and nothing would break 
because websites would transparently switch to their alternate CA.


This deployment model is completely unrealistic and even if it were 
practical, would be achieved with ACME alone without trust expressions.


This is predicated on the assumption that either the vast majority of 
websites will configure their ACME client with multiple CAs or that the 
distrusted CA actively provision replacement certificates from an 
alternative CA. It's unclear why websites will want to maintain an 
account with a CA they are not actively using for the extremely rare 
event that their primary will be distrusted over-night. Alternately, 
it's unclear why a CA would cooperate in its removal, they have 
literally zero incentive to make their own removal easier.


Let's assuming for a moment we could a) get most of the world to use 
ACME (a worthy but challenging goal) and b) get them to configure 
multiple CAs and receive multiple certificates. We don't need trust 
expressions to be able to do quick rotations - because we don't ever 
want to use the old CA. It's just a case of swapping to the new one. 
There's no need for negotiation.


During the very very long period in which this is being incrementally 
deployed by clients and servers, Trust Expressions is still 
substantially better than the approach you describe because it creates 
the possibility for clients to negotiate away from a compromised CA 
where possible (i.e., even if a website operator has taken no action 
but presents multiple certificates, a client can choose a certificate 
with a non-compromised root).


This is a repeat of the same point. It's a fantasy to expect that 
website operators are going to establish accounts with multiple CAs on 
the off chance of a catastrophic distrust. It is literally twice as much 
work. In terms of the what the distrust is actually trying to achieve, 
we actively want folks to stop using bad certificates from the bad CA 
and in that sense, the pain is an essential part of the process in 
improving security for everyone.


Again, as a reminder, distrust-after based on SCT dates largely 
eliminates the need for overnight distrust decisions. We can already 
remove bad CAs gracefully without having to trust them during their 
deprecation period.


As has been mentioned, it takes a very long time for TLS extensions to 
gain adoption by a broad set of client implementations, server 
implementations, and website operators. If we built an extension that 
just said "I have an accurate clock, you can send me short-lived 
certificates" then it would need adoption by client implementations, 
server implementations, and website operators, and this would take a 
long time. Trust Expressions creates a happy path where 1.) clients 
indicate support for a feature by trusting a fancy new CA, and 2.) 
website operators support that feature simply by configuring their 
ACME client to get a certificate from that CA. Changing the server 
implementation isn't necessary. This happy path seems quite nice and 
useful to me


There's a few huge problems with this:

1) Most of the interesting things we want to do require changes to 
server implementations, so this doesn't help much.


2) It's extremely questionable that CAs should have the power to 
reconfigure servers without the server operator actively opting in.


3) One of the extremely questionable acts 

Re: [TLS] WG Adoption for TLS Trust Expressions

[David Benjamin]

Hi all. Thanks for the discussion! While we're digesting it all, one quick
comment regarding the feedback in Prague:

>From talking with folks at the meeting, it seemed part of this was due to a
misunderstanding. Trust expressions are not intended to capture per-user
customizations to root stores, as that has a number of issues. The intent
was to capture only what is implied by the browser + version. (Or the
analog for other kinds of TLS deployments. More precisely, base it on your
desired anonymity set.) We rewrote the privacy considerations

section after that meeting in response to this, to try to make that clearer.

On Tue, Apr 30, 2024 at 5:34 PM Brendan McMillion <
brendanmcmill...@gmail.com> wrote:

> This doesn't apply in case we're distrusting a CA because it's failed. In
>> 9.1 we're rotating keys. As I laid out in my initial mail, we can already
>> sign the new root with the old root to enable rotation. There's no size
>> impact to up-to-date clients using intermediate suppression or abridged
>> certs.
>>
>
> The approach you describe requires the cooperation of the CA, in signing
> the new root with the old root. My understanding is that CAs (especially
> CAs in trouble with their root program) are often uncooperative or
> absentee. It also requires the CA's customers to go through a full issuance
> cycle before they get certificates with the new root, which could take over
> a year, during which time the compromised root will still need to be
> trusted.
>
> This draft is substantially better than that. It normalizes websites
> having multiple certificates from different CAs. In a future world with
> widespread adoption of Trust Expressions and ACME, a root could be
> distrusted immediately without warning and nothing would break because
> websites would transparently switch to their alternate CA. During the very
> very long period in which this is being incrementally deployed by clients
> and servers, Trust Expressions is still substantially better than the
> approach you describe because it creates the possibility for clients to
> negotiate away from a compromised CA where possible (i.e., even if a
> website operator has taken no action but presents multiple certificates, a
> client can choose a certificate with a non-compromised root).
>
> If we want to say that, we should have an extension that actually says you
>> have an accurate clock.
>>
>
> As has been mentioned, it takes a very long time for TLS extensions to
> gain adoption by a broad set of client implementations, server
> implementations, and website operators. If we built an extension that just
> said "I have an accurate clock, you can send me short-lived certificates"
> then it would need adoption by client implementations, server
> implementations, and website operators, and this would take a long time.
> Trust Expressions creates a happy path where 1.) clients indicate support
> for a feature by trusting a fancy new CA, and 2.) website operators support
> that feature simply by configuring their ACME client to get a certificate
> from that CA. Changing the server implementation isn't necessary. This
> happy path seems quite nice and useful to me
>
>
> On Tue, Apr 30, 2024 at 8:38 AM Dennis Jackson  40dennis-jackson...@dmarc.ietf.org> wrote:
>
>> As mentioned above, we have such an extension already insofar as
>> indicating support for Delegated Credentials means indicating a desire for
>> a very short credential lifetime and an acceptance of the clock skew risks.
>>
>> Given how little use its seen, I don't know that its a good motivation
>> for Trust Expressions.
>> On 30/04/2024 16:33, Eric Rescorla wrote:
>>
>>
>>
>> On Tue, Apr 30, 2024 at 8:29 AM Watson Ladd 
>> wrote:
>>
>>> On Tue, Apr 30, 2024 at 8:25 AM Eric Rescorla  wrote:
>>> >
>>> >
>>> > On the narrow point of shorter lifetimes, I don't think the right way
>>> to advertise that you have an accurate clock is to advertise that you
>>> support some set of root certificates.
>>> >
>>> > If we want to say that, we should have an extension that actually says
>>> you have an accurate clock.
>>>
>>> That says you *think* you have an accurate clock.
>>>
>>
>> Quite so. However, if servers gate the use of some kind of short-lived
>> credential
>> on a client signal that the client thinks it has an accurate clock
>> (however that
>> signal is encoded) and the clients are frequently wrong about that, we're
>> going
>> to have big problems.
>>
>> -Ekr
>>
>>
>>
>>
>>> Sincerely,
>>> Watson
>>>
>>> --
>>> Astra mortemque praestare gradatim
>>>
>>
>> ___
>> TLS mailing listTLS@ietf.orghttps://www.ietf.org/mailman/listinfo/tls
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
> ___
> TLS mailing 

Re: [TLS] WG Adoption for TLS Trust Expressions

[Brendan McMillion]

>
> This doesn't apply in case we're distrusting a CA because it's failed. In
> 9.1 we're rotating keys. As I laid out in my initial mail, we can already
> sign the new root with the old root to enable rotation. There's no size
> impact to up-to-date clients using intermediate suppression or abridged
> certs.
>

The approach you describe requires the cooperation of the CA, in signing
the new root with the old root. My understanding is that CAs (especially
CAs in trouble with their root program) are often uncooperative or
absentee. It also requires the CA's customers to go through a full issuance
cycle before they get certificates with the new root, which could take over
a year, during which time the compromised root will still need to be
trusted.

This draft is substantially better than that. It normalizes websites having
multiple certificates from different CAs. In a future world with widespread
adoption of Trust Expressions and ACME, a root could be distrusted
immediately without warning and nothing would break because websites would
transparently switch to their alternate CA. During the very very long
period in which this is being incrementally deployed by clients and
servers, Trust Expressions is still substantially better than the approach
you describe because it creates the possibility for clients to negotiate
away from a compromised CA where possible (i.e., even if a website operator
has taken no action but presents multiple certificates, a client can choose
a certificate with a non-compromised root).

If we want to say that, we should have an extension that actually says you
> have an accurate clock.
>

As has been mentioned, it takes a very long time for TLS extensions to gain
adoption by a broad set of client implementations, server implementations,
and website operators. If we built an extension that just said "I have an
accurate clock, you can send me short-lived certificates" then it would
need adoption by client implementations, server implementations, and
website operators, and this would take a long time. Trust Expressions
creates a happy path where 1.) clients indicate support for a feature by
trusting a fancy new CA, and 2.) website operators support that feature
simply by configuring their ACME client to get a certificate from that CA.
Changing the server implementation isn't necessary. This happy path seems
quite nice and useful to me


On Tue, Apr 30, 2024 at 8:38 AM Dennis Jackson  wrote:

> As mentioned above, we have such an extension already insofar as
> indicating support for Delegated Credentials means indicating a desire for
> a very short credential lifetime and an acceptance of the clock skew risks.
>
> Given how little use its seen, I don't know that its a good motivation for
> Trust Expressions.
> On 30/04/2024 16:33, Eric Rescorla wrote:
>
>
>
> On Tue, Apr 30, 2024 at 8:29 AM Watson Ladd  wrote:
>
>> On Tue, Apr 30, 2024 at 8:25 AM Eric Rescorla  wrote:
>> >
>> >
>> > On the narrow point of shorter lifetimes, I don't think the right way
>> to advertise that you have an accurate clock is to advertise that you
>> support some set of root certificates.
>> >
>> > If we want to say that, we should have an extension that actually says
>> you have an accurate clock.
>>
>> That says you *think* you have an accurate clock.
>>
>
> Quite so. However, if servers gate the use of some kind of short-lived
> credential
> on a client signal that the client thinks it has an accurate clock
> (however that
> signal is encoded) and the clients are frequently wrong about that, we're
> going
> to have big problems.
>
> -Ekr
>
>
>
>
>> Sincerely,
>> Watson
>>
>> --
>> Astra mortemque praestare gradatim
>>
>
> ___
> TLS mailing listTLS@ietf.orghttps://www.ietf.org/mailman/listinfo/tls
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WG Adoption for TLS Trust Expressions

[Stephen Farrell]

Hiya,

Having read the draft and the recent emails, I fully agree with
Dennis' criticisms of this approach. I think this is one that'd
best be filed under "good try, but too many downsides" and left
at that.

Cheers,
S.

On 30/04/2024 00:20, Dennis Jackson wrote:
When this work was presented at IETF 118 in November, several 
participants (including myself, Stephen Farrell and Nicola Tuveri) came 
to the mic to highlight that this draft's mechanism comes with a serious 
potential for abuse by governments (meeting minutes 
).


Although the authors acknowledged the issue in the meeting, no changes 
have been made since to either address the problem or document it as an 
accepted risk. I think its critical one of the two happens before this 
document is considered for adoption.


Below is a brief recap of the unaddressed issue raised at 118 and some 
thoughts on next steps:


Some governments (including, but not limited to Russia 
, Kazakhstan , Mauritius ) have previously established national root CAs in order to enable mass surveillance and censorship of their residents' web traffic. This requires trying to force residents to install these root CAs or adopt locally developed browsers which have them prepackaged. This is widely regarded as a bad thing (RFC 7258 ).


Thankfully these efforts have largely failed because these national CAs 
have no legitimate adoption or use cases. Very few website operators 
would voluntarily use certificates from a national root CA when it means 
shutting out the rest of the world (who obviously do not trust that root 
CA) and even getting adoption within the country is very difficult since 
adopting sites are broken for residents without the national root cert.


However, this draft provides a ready-made solution to this adoption 
problem: websites can be forced to adopt the national CA in addition to, 
rather than replacing, their globally trusted cert. This policy can even 
be justified in terms of security from the perspective of the 
government, since the national CA is under domestic supervision (see 
https://last-chance-for-eidas.org). This enables a gradual roll out by 
the government who can require sites to start deploying certs from the 
national CA in parallel with their existing certificates without any 
risk of breakage either locally or abroad, solving their adoption problem.


Conveniently, post-adoption governments can also see what fraction of 
their residents' web traffic is using their national CA via the 
unencrypted trust expressions extension, which can inform their 
decisions about whether to block connections which don't indicate 
support for their national CA and as well advertising which connections 
they can intercept (using existing methods like mis-issued certs, key 
escrow) without causing a certificate error. This approach also scales 
so multiple countries can deploy national CAs with each being able to 
surveil their own residents but not each others.


Although this may feel like a quite distant consequence of enabling 
trust negotiation in TLS, the on-ramp is straightforward:


  * Support for trust negotiation gets shipped in browsers and servers
    for ostensibly good reasons.
  * A large country or federation pushes for recognition of their
    domestic trust regime as a distinct trust store which browsers must
    advertise. Browsers agree because the relevant market is too big to
    leave.
  * Other countries push for the same recognition now that the dam is
    breached.
  * Time passes and various local cottage industries of domestic CAs are
    encouraged out of national interest and government enabled rent
    seeking.
  * One or more countries start either withholding certificates for
    undesirable sites, blocking connections which don't use their trust
    store, requiring key escrow to enable interception, etc etc.

Besides the above issue which merits some considered discussion, I would 
also suggest fleshing out the use cases & problems that this draft is 
trying to solve.


Firstly because its not clear why simpler solutions don't suffice. For 
example, backwards compatible root key rotation could solved by signing 
the new root with the old root, then using existing drafts like 
intermediate suppression or abridged certs to eliminate the overhead of 
both certs for up to date clients. This would largely eliminate the 
problems raised around support for old devices.


Secondly the current proposal requires a fairly substantial amount of 
coordination between server operators, ACME vendors, CAs, 

Re: [TLS] WG Adoption for TLS Trust Expressions

[Eric Rescorla]

On Tue, Apr 30, 2024 at 8:37 AM Dennis Jackson  wrote:

> As mentioned above, we have such an extension already insofar as
> indicating support for Delegated Credentials means indicating a desire for
> a very short credential lifetime and an acceptance of the clock skew risks.
>
I agree that DC implicitly says "I think I have an accurate clock". I think
that given
the design of DC it was probably right to merge the "I support DCs" and "I
think
my clock is good enough to support DCs" semantics, but I don't think it's
at all
as natural to do that in the case of CAs, which, after all, could support
both short
and long-lived certificates. As I said earlier, I think the right way to do
that is
with an orthogonal extension [0]



Given how little use its seen, I don't know that its a good motivation for
> Trust Expressions.
>
I agree with you about this.

-Ekr

[0] I also don't think (not that you suggested it) that one should infer
from the client
advertising support for DCs that it has an accurate enough clock for every
purpose.

On 30/04/2024 16:33, Eric Rescorla wrote:
>
>
>
> On Tue, Apr 30, 2024 at 8:29 AM Watson Ladd  wrote:
>
>> On Tue, Apr 30, 2024 at 8:25 AM Eric Rescorla  wrote:
>> >
>> >
>> > On the narrow point of shorter lifetimes, I don't think the right way
>> to advertise that you have an accurate clock is to advertise that you
>> support some set of root certificates.
>> >
>> > If we want to say that, we should have an extension that actually says
>> you have an accurate clock.
>>
>> That says you *think* you have an accurate clock.
>>
>
> Quite so. However, if servers gate the use of some kind of short-lived
> credential
> on a client signal that the client thinks it has an accurate clock
> (however that
> signal is encoded) and the clients are frequently wrong about that, we're
> going
> to have big problems.
>
> -Ekr
>
>
>
>
>> Sincerely,
>> Watson
>>
>> --
>> Astra mortemque praestare gradatim
>>
>
> ___
> TLS mailing listTLS@ietf.orghttps://www.ietf.org/mailman/listinfo/tls
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WG Adoption for TLS Trust Expressions

[Dennis Jackson]

As mentioned above, we have such an extension already insofar as 
indicating support for Delegated Credentials means indicating a desire 
for a very short credential lifetime and an acceptance of the clock skew 
risks.


Given how little use its seen, I don't know that its a good motivation 
for Trust Expressions.


On 30/04/2024 16:33, Eric Rescorla wrote:



On Tue, Apr 30, 2024 at 8:29 AM Watson Ladd  wrote:

On Tue, Apr 30, 2024 at 8:25 AM Eric Rescorla  wrote:
>
>
> On the narrow point of shorter lifetimes, I don't think the
right way to advertise that you have an accurate clock is to
advertise that you support some set of root certificates.
>
> If we want to say that, we should have an extension that
actually says you have an accurate clock.

That says you *think* you have an accurate clock.


Quite so. However, if servers gate the use of some kind of short-lived 
credential
on a client signal that the client thinks it has an accurate clock 
(however that
signal is encoded) and the clients are frequently wrong about that, 
we're going

to have big problems.

-Ekr




Sincerely,
Watson

-- 
Astra mortemque praestare gradatim



___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WG Adoption for TLS Trust Expressions

[Dennis Jackson]

On 30/04/2024 16:13, Brendan McMillion wrote:


Of course this is possible in theory, there are no standards
police, but this argument overlooks the gargantuan technical and
economic costs of deploying this kind of private extension. You'd
need to convince a diverse population of implementers on both the
client and server side to adopt and enable your thing.


I don't believe my hypothetical private extension would need to be 
adopted by any servers, just clients. And due to power laws, adoption 
by one or two clients would provide visibility into a substantial 
section of Internet traffic.
This is just an observation that unilateral actions taken by major 
players can screw things up for many people. It's true, but it has 
little bearing on what we're weighing up here.


Can you expand on how this draft enables the more rapid distrust
of failed CAs?


 This is described in more detail in section 9.1 of the draft. 
Currently we have the problem that, as long as any older RP relies on 
a given root, subscribers have to keep using it, which means newer RPs 
have to keep trusting it.


This doesn't apply in case we're distrusting a CA because it's failed. 
In 9.1 we're rotating keys. As I laid out in my initial mail, we can 
already sign the new root with the old root to enable rotation. There's 
no size impact to up-to-date clients using intermediate suppression or 
abridged certs.




I'm confused by this remark. Are there clients which would
tolerate a certificate if only it had a longer lifetime? Is there
any circumstance in which you would have both a long-life and
short-life certificate available, and you would prefer to serve
the long-life cert?


 Yes, especially when you push to shorter and shorter lifetimes (say, 
1 day, 1 hour), you start to have the issue that not all clients will 
have sufficiently accurate clocks to verify them. Clients with 
accurate clocks can advertise support for a root that issues 
short-lived certs while clients that don't will not advertise support 
for this root, and with TE we can support both.


Firefox already supports Delegated Credentials for exactly this use case 
and which addresses clock skew, but DCs have never seen much use as far 
as I know. In any case, this is an already solved problem.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WG Adoption for TLS Trust Expressions

[Eric Rescorla]

On Tue, Apr 30, 2024 at 8:29 AM Watson Ladd  wrote:

> On Tue, Apr 30, 2024 at 8:25 AM Eric Rescorla  wrote:
> >
> >
> > On the narrow point of shorter lifetimes, I don't think the right way to
> advertise that you have an accurate clock is to advertise that you support
> some set of root certificates.
> >
> > If we want to say that, we should have an extension that actually says
> you have an accurate clock.
>
> That says you *think* you have an accurate clock.
>

Quite so. However, if servers gate the use of some kind of short-lived
credential
on a client signal that the client thinks it has an accurate clock (however
that
signal is encoded) and the clients are frequently wrong about that, we're
going
to have big problems.

-Ekr




> Sincerely,
> Watson
>
> --
> Astra mortemque praestare gradatim
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WG Adoption for TLS Trust Expressions

[Watson Ladd]

On Tue, Apr 30, 2024 at 8:25 AM Eric Rescorla  wrote:
>
>
> On the narrow point of shorter lifetimes, I don't think the right way to 
> advertise that you have an accurate clock is to advertise that you support 
> some set of root certificates.
>
> If we want to say that, we should have an extension that actually says you 
> have an accurate clock.

That says you *think* you have an accurate clock.

Sincerely,
Watson

-- 
Astra mortemque praestare gradatim

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WG Adoption for TLS Trust Expressions

[Eric Rescorla]

On Tue, Apr 30, 2024 at 8:14 AM Brendan McMillion <
brendanmcmill...@gmail.com> wrote:

> Of course this is possible in theory, there are no standards police, but
>> this argument overlooks the gargantuan technical and economic costs of
>> deploying this kind of private extension. You'd need to convince a diverse
>> population of implementers on both the client and server side to adopt and
>> enable your thing.
>>
>
> I don't believe my hypothetical private extension would need to be adopted
> by any servers, just clients. And due to power laws, adoption by one or two
> clients would provide visibility into a substantial section of Internet
> traffic.
>
> Can you expand on how this draft enables the more rapid distrust of failed
>> CAs?
>>
>
>  This is described in more detail in section 9.1 of the draft. Currently
> we have the problem that, as long as any older RP relies on a given root,
> subscribers have to keep using it, which means newer RPs have to keep
> trusting it.
>
> I'm confused by this remark. Are there clients which would tolerate a
>> certificate if only it had a longer lifetime? Is there any circumstance in
>> which you would have both a long-life and short-life certificate available,
>> and you would prefer to serve the long-life cert?
>>
>
>  Yes, especially when you push to shorter and shorter lifetimes (say, 1
> day, 1 hour), you start to have the issue that not all clients will have
> sufficiently accurate clocks to verify them. Clients with accurate clocks
> can advertise support for a root that issues short-lived certs while
> clients that don't will not advertise support for this root, and with TE we
> can support both.
>

On the narrow point of shorter lifetimes, I don't think the right way to
advertise that you have an accurate clock is to advertise that you support
some set of root certificates.

If we want to say that, we should have an extension that actually says you
have an accurate clock.

-Ekr



> On Tue, Apr 30, 2024 at 3:57 AM Dennis Jackson  40dennis-jackson...@dmarc.ietf.org> wrote:
>
>> Hi Brendan, Bas,
>> On 30/04/2024 05:17, Brendan McMillion wrote:
>>
>> It seems like, with or without this extension, the path is still the
>> same: you'd need to force a browser to ship with a government-issued CA
>> installed. Nothing about this makes that easier. It /is/ somewhat nice to
>> already have a way to signal that a given client does/doesn't support the
>> government CA -- but you could just as easily do this with a simple
>> extension from the private range, so I'm not sure that was a big blocker.
>>
>> On 30/04/2024 09:13, Bas Westerbaan wrote:
>>
>> No need for a new extension: a government can use a specific signature
>> algorithm for that (say, a national flavour of elliptic curve, or a
>> particular PQ/T hybrid).
>>
>> Of course this is possible in theory, there are no standards police, but
>> this argument overlooks the gargantuan technical and economic costs of
>> deploying this kind of private extension. You'd need to convince a diverse
>> population of implementers on both the client and server side to adopt and
>> enable your thing. This draft if widely implemented as-is would effectively
>> solve that problem for governments by removing a huge architectural
>> roadblock. This is the power of the IETF and why decisions about what TLS
>> extensions to adopt are important. Mark Nottingham has a longer piece
>>  on this view.
>>
>> On 30/04/2024 05:17, Brendan McMillion wrote:
>>
>> On the other hand, this draft solves a number of existing security
>> issues, by allowing more rapid distrust of failed CAs,
>>
>> Can you expand on how this draft enables the more rapid distrust of
>> failed CAs?
>>
>> The roadblock to faster distrust has always been how quickly subscribers
>> of the failed CA are able to migrate. ACME makes this process much easier,
>> but still requires server operators to reconfigure their ACME clients. This
>> draft doesn't improve that situation.
>>
>> An effective technique long-used by Microsoft and Mozilla when
>> distrusting CAs is to ship a distrust-certs-issued-after signal rather than
>> an immediate distrust of all issued certificates. This allows server
>> operators to gradually migrate in line with their usual schedule of
>> certificate renewals rather than forcing a flag day on the world. I
>> understand that at least one further major root program is looking at
>> supporting the same feature.
>>
>> by allowing clients to signal support for short-lived certificates, etc.
>>
>> I'm confused by this remark. Are there clients which would tolerate a
>> certificate if only it had a longer lifetime? Is there any circumstance in
>> which you would have both a long-life and short-life certificate available,
>> and you would prefer to serve the long-life cert?
>>
>


> Best,
>> Dennis
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> 

Re: [TLS] WG Adoption for TLS Trust Expressions

[Brendan McMillion]

>
> Of course this is possible in theory, there are no standards police, but
> this argument overlooks the gargantuan technical and economic costs of
> deploying this kind of private extension. You'd need to convince a diverse
> population of implementers on both the client and server side to adopt and
> enable your thing.
>

I don't believe my hypothetical private extension would need to be adopted
by any servers, just clients. And due to power laws, adoption by one or two
clients would provide visibility into a substantial section of Internet
traffic.

Can you expand on how this draft enables the more rapid distrust of failed
> CAs?
>

 This is described in more detail in section 9.1 of the draft. Currently we
have the problem that, as long as any older RP relies on a given root,
subscribers have to keep using it, which means newer RPs have to keep
trusting it.

I'm confused by this remark. Are there clients which would tolerate a
> certificate if only it had a longer lifetime? Is there any circumstance in
> which you would have both a long-life and short-life certificate available,
> and you would prefer to serve the long-life cert?
>

 Yes, especially when you push to shorter and shorter lifetimes (say, 1
day, 1 hour), you start to have the issue that not all clients will have
sufficiently accurate clocks to verify them. Clients with accurate clocks
can advertise support for a root that issues short-lived certs while
clients that don't will not advertise support for this root, and with TE we
can support both.

On Tue, Apr 30, 2024 at 3:57 AM Dennis Jackson  wrote:

> Hi Brendan, Bas,
> On 30/04/2024 05:17, Brendan McMillion wrote:
>
> It seems like, with or without this extension, the path is still the same:
> you'd need to force a browser to ship with a government-issued CA
> installed. Nothing about this makes that easier. It /is/ somewhat nice to
> already have a way to signal that a given client does/doesn't support the
> government CA -- but you could just as easily do this with a simple
> extension from the private range, so I'm not sure that was a big blocker.
>
> On 30/04/2024 09:13, Bas Westerbaan wrote:
>
> No need for a new extension: a government can use a specific signature
> algorithm for that (say, a national flavour of elliptic curve, or a
> particular PQ/T hybrid).
>
> Of course this is possible in theory, there are no standards police, but
> this argument overlooks the gargantuan technical and economic costs of
> deploying this kind of private extension. You'd need to convince a diverse
> population of implementers on both the client and server side to adopt and
> enable your thing. This draft if widely implemented as-is would effectively
> solve that problem for governments by removing a huge architectural
> roadblock. This is the power of the IETF and why decisions about what TLS
> extensions to adopt are important. Mark Nottingham has a longer piece
>  on this view.
>
> On 30/04/2024 05:17, Brendan McMillion wrote:
>
> On the other hand, this draft solves a number of existing security issues,
> by allowing more rapid distrust of failed CAs,
>
> Can you expand on how this draft enables the more rapid distrust of failed
> CAs?
>
> The roadblock to faster distrust has always been how quickly subscribers
> of the failed CA are able to migrate. ACME makes this process much easier,
> but still requires server operators to reconfigure their ACME clients. This
> draft doesn't improve that situation.
>
> An effective technique long-used by Microsoft and Mozilla when distrusting
> CAs is to ship a distrust-certs-issued-after signal rather than an
> immediate distrust of all issued certificates. This allows server operators
> to gradually migrate in line with their usual schedule of certificate
> renewals rather than forcing a flag day on the world. I understand that at
> least one further major root program is looking at supporting the same
> feature.
>
> by allowing clients to signal support for short-lived certificates, etc.
>
> I'm confused by this remark. Are there clients which would tolerate a
> certificate if only it had a longer lifetime? Is there any circumstance in
> which you would have both a long-life and short-life certificate available,
> and you would prefer to serve the long-life cert?
>
> Best,
> Dennis
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WG Adoption for TLS Trust Expressions

[Loganaden Velvindron]

On Tue, 30 Apr 2024 at 03:20, Dennis Jackson
 wrote:
>
> When this work was presented at IETF 118 in November, several participants 
> (including myself, Stephen Farrell and Nicola Tuveri) came to the mic to 
> highlight that this draft's mechanism comes with a serious potential for 
> abuse by governments (meeting minutes).
>
> Although the authors acknowledged the issue in the meeting, no changes have 
> been made since to either address the problem or document it as an accepted 
> risk. I think its critical one of the two happens before this document is 
> considered for adoption.
>
> Below is a brief recap of the unaddressed issue raised at 118 and some 
> thoughts on next steps:
>
> Some governments (including, but not limited to Russia, Kazakhstan, 
> Mauritius) have previously established national root CAs in order to enable 
> mass surveillance and censorship of their residents' web traffic. This 
> requires trying to force residents to install these root CAs or adopt locally 
> developed browsers which have them prepackaged. This is widely regarded as a 
> bad thing (RFC 7258).

In the case of Mauritius, It was a proposal. There was public debate
and the overwhelming majority of Mauritians rejected the proposal from
the ICTA in 2021.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WG Adoption for TLS Trust Expressions

[Dennis Jackson]

Hi Brendan, Bas,

On 30/04/2024 05:17, Brendan McMillion wrote:
It seems like, with or without this extension, the path is still the 
same: you'd need to force a browser to ship with a government-issued 
CA installed. Nothing about this makes that easier. It /is/ somewhat 
nice to already have a way to signal that a given client does/doesn't 
support the government CA -- but you could just as easily do this with 
a simple extension from the private range, so I'm not sure that was a 
big blocker.

On 30/04/2024 09:13, Bas Westerbaan wrote:

No need for a new extension: a government can use a specific signature 
algorithm for that (say, a national flavour of elliptic curve, or a 
particular PQ/T hybrid).


Of course this is possible in theory, there are no standards police, but 
this argument overlooks the gargantuan technical and economic costs of 
deploying this kind of private extension. You'd need to convince a 
diverse population of implementers on both the client and server side to 
adopt and enable your thing. This draft if widely implemented as-is 
would effectively solve that problem for governments by removing a huge 
architectural roadblock. This is the power of the IETF and why decisions 
about what TLS extensions to adopt are important. Mark Nottingham has a 
longer piece  on this 
view.


On 30/04/2024 05:17, Brendan McMillion wrote:

On the other hand, this draft solves a number of existing security 
issues, by allowing more rapid distrust of failed CAs,


Can you expand on how this draft enables the more rapid distrust of 
failed CAs?


The roadblock to faster distrust has always been how quickly subscribers 
of the failed CA are able to migrate. ACME makes this process much 
easier, but still requires server operators to reconfigure their ACME 
clients. This draft doesn't improve that situation.


An effective technique long-used by Microsoft and Mozilla when 
distrusting CAs is to ship a distrust-certs-issued-after signal rather 
than an immediate distrust of all issued certificates. This allows 
server operators to gradually migrate in line with their usual schedule 
of certificate renewals rather than forcing a flag day on the world. I 
understand that at least one further major root program is looking at 
supporting the same feature.



by allowing clients to signal support for short-lived certificates, etc.
I'm confused by this remark. Are there clients which would tolerate a 
certificate if only it had a longer lifetime? Is there any circumstance 
in which you would have both a long-life and short-life certificate 
available, and you would prefer to serve the long-life cert?


Best,
Dennis

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WG Adoption for TLS Trust Expressions

[Bas Westerbaan]

On Tue, Apr 30, 2024 at 6:17 AM Brendan McMillion <
brendanmcmill...@gmail.com> wrote:

> but you could just as easily do this with a simple extension from the
> private range, so I'm not sure that was a big blocker.
>

No need for a new extension: a government can use a specific signature
algorithm for that (say, a national flavour of elliptic curve, or a
particular PQ/T hybrid).
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WG Adoption for TLS Trust Expressions

[Brendan McMillion]

Hi Dennis

Admittedly, I'm not understanding how this extension enables government
coercion. It seems like, with or without this extension, the path is still
the same: you'd need to force a browser to ship with a government-issued CA
installed. Nothing about this makes that easier. It /is/ somewhat nice to
already have a way to signal that a given client does/doesn't support the
government CA -- but you could just as easily do this with a simple
extension from the private range, so I'm not sure that was a big blocker.

On the other hand, this draft solves a number of existing security issues,
by allowing more rapid distrust of failed CAs, by allowing clients to
signal support for short-lived certificates, etc.

On Mon, Apr 29, 2024 at 6:06 PM Dennis Jackson  wrote:

> Thanks , I
> 
> am
> 
> aware
> .
>
> On 30/04/2024 01:39, S Moonesamy wrote:
>
> Hi Dennis,
> At 04:20 PM 29-04-2024, Dennis Jackson wrote:
>
> Thankfully these efforts have largely failed because these national CAs
> have no legitimate adoption or use cases. Very few website operators would
> voluntarily use certificates from a national root CA when it means shutting
> out the rest of the world (who obviously do not trust that root CA) and
> even getting adoption within the country is very difficult since adopting
> sites are broken for residents without the national root cert.
>
>
> There are ways to promote adoption of a government-mandated CA.  The
> stumbling point is usually browser vendors, e.g.
> https://blog.mozilla.org/netpolicy/files/2021/05/Mozillas-Response-to-the-Mauritian-ICT-Authoritys-Consultation.pdf
>
> I see that you already mentioned BCP 188.
>
> Regards,
> S. Moonesamy
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WG Adoption for TLS Trust Expressions

[Dennis Jackson]

Thanks , I 
 
am 
 
aware 
. 



On 30/04/2024 01:39, S Moonesamy wrote:

Hi Dennis,
At 04:20 PM 29-04-2024, Dennis Jackson wrote:
Thankfully these efforts have largely failed because these national 
CAs have no legitimate adoption or use cases. Very few website 
operators would voluntarily use certificates from a national root CA 
when it means shutting out the rest of the world (who obviously do 
not trust that root CA) and even getting adoption within the country 
is very difficult since adopting sites are broken for residents 
without the national root cert.


There are ways to promote adoption of a government-mandated CA. The 
stumbling point is usually browser vendors, e.g. 
https://blog.mozilla.org/netpolicy/files/2021/05/Mozillas-Response-to-the-Mauritian-ICT-Authoritys-Consultation.pdf


I see that you already mentioned BCP 188.

Regards,
S. Moonesamy
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WG Adoption for TLS Trust Expressions

[S Moonesamy]

Hi Dennis,
At 04:20 PM 29-04-2024, Dennis Jackson wrote:
Thankfully these efforts have largely failed because these national 
CAs have no legitimate adoption or use cases. Very few website 
operators would voluntarily use certificates from a national root CA 
when it means shutting out the rest of the world (who obviously do 
not trust that root CA) and even getting adoption within the country 
is very difficult since adopting sites are broken for residents 
without the national root cert.


There are ways to promote adoption of a government-mandated CA.  The 
stumbling point is usually browser vendors, e.g. 
https://blog.mozilla.org/netpolicy/files/2021/05/Mozillas-Response-to-the-Mauritian-ICT-Authoritys-Consultation.pdf


I see that you already mentioned BCP 188.

Regards,
S. Moonesamy 


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WG Adoption for TLS Trust Expressions

[Dennis Jackson]

When this work was presented at IETF 118 in November, several 
participants (including myself, Stephen Farrell and Nicola Tuveri) came 
to the mic to highlight that this draft's mechanism comes with a serious 
potential for abuse by governments (meeting minutes 
). 



Although the authors acknowledged the issue in the meeting, no changes 
have been made since to either address the problem or document it as an 
accepted risk. I think its critical one of the two happens before this 
document is considered for adoption.


Below is a brief recap of the unaddressed issue raised at 118 and some 
thoughts on next steps:


Some governments (including, but not limited to Russia 
, 
Kazakhstan 
, 
Mauritius 
) 
have previously established national root CAs in order to enable mass 
surveillance and censorship of their residents' web traffic. This 
requires trying to force residents to install these root CAs or adopt 
locally developed browsers which have them prepackaged. This is widely 
regarded as a bad thing (RFC 7258 
).


Thankfully these efforts have largely failed because these national CAs 
have no legitimate adoption or use cases. Very few website operators 
would voluntarily use certificates from a national root CA when it means 
shutting out the rest of the world (who obviously do not trust that root 
CA) and even getting adoption within the country is very difficult since 
adopting sites are broken for residents without the national root cert.


However, this draft provides a ready-made solution to this adoption 
problem: websites can be forced to adopt the national CA in addition to, 
rather than replacing, their globally trusted cert. This policy can even 
be justified in terms of security from the perspective of the 
government, since the national CA is under domestic supervision (see 
https://last-chance-for-eidas.org). This enables a gradual roll out by 
the government who can require sites to start deploying certs from the 
national CA in parallel with their existing certificates without any 
risk of breakage either locally or abroad, solving their adoption problem.


Conveniently, post-adoption governments can also see what fraction of 
their residents' web traffic is using their national CA via the 
unencrypted trust expressions extension, which can inform their 
decisions about whether to block connections which don't indicate 
support for their national CA and as well advertising which connections 
they can intercept (using existing methods like mis-issued certs, key 
escrow) without causing a certificate error. This approach also scales 
so multiple countries can deploy national CAs with each being able to 
surveil their own residents but not each others.


Although this may feel like a quite distant consequence of enabling 
trust negotiation in TLS, the on-ramp is straightforward:


 * Support for trust negotiation gets shipped in browsers and servers
   for ostensibly good reasons.
 * A large country or federation pushes for recognition of their
   domestic trust regime as a distinct trust store which browsers must
   advertise. Browsers agree because the relevant market is too big to
   leave.
 * Other countries push for the same recognition now that the dam is
   breached.
 * Time passes and various local cottage industries of domestic CAs are
   encouraged out of national interest and government enabled rent
   seeking.
 * One or more countries start either withholding certificates for
   undesirable sites, blocking connections which don't use their trust
   store, requiring key escrow to enable interception, etc etc.

Besides the above issue which merits some considered discussion, I would 
also suggest fleshing out the use cases & problems that this draft is 
trying to solve.


Firstly because its not clear why simpler solutions don't suffice. For 
example, backwards compatible root key rotation could solved by signing 
the new root with the old root, then using existing drafts like 
intermediate suppression or abridged certs to eliminate the overhead of 
both certs for up to date clients. This would largely eliminate the 
problems raised around support for old devices.


Secondly the current proposal requires a fairly substantial amount of 
coordination between server operators, ACME vendors, CAs, browsers and 
browser providers and its unclear whether there are enough incentives in 
place to actually see the folk deploy the technology in an effective 
way. Sketching out a couple of key deployment scenarios and what 
fraction of each population would need to 

Re: [TLS] WG Adoption for TLS Trust Expressions

[Watson Ladd]

On Tue, Apr 23, 2024 at 1:39 PM Devon O'Brien
 wrote:
>
> After sharing our first draft of TLS Trust Expressions and several 
> discussions across a couple  IETFs, we’d like to proceed with a call for 
> working group adoption of this draft. We are currently prototyping trust 
> expressions in BoringSSL & Chromium and will share more details when 
> implementation is complete.
>
>
> As we mentioned in our message to the mailing list from January, our primary 
> goal is to produce a mechanism for supporting multiple subscriber 
> certificates and efficiently negotiating which to serve on a given TLS 
> connection, even if that ends up requiring significant changes to the draft 
> in its current state.
>
>
> To that end, we’re interested in learning whether wg members support adoption 
> of this deployment model and the currently-described certificate negotiation 
> mechanism or if they oppose adoption (and why!).

We absolutely need to solve the problem and the draft is a good starting point.

>
>
> Thanks!
>
> David, Devon, and Bob
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



-- 
Astra mortemque praestare gradatim

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WG Adoption for TLS Trust Expressions

[Kyle Nekritz]

I think it’s very important we provide a standard to efficiently solve this 
problem. Without one, I think it’s nearly inevitable that server operators will 
have to deploy complex ClientHello fingerprinting logic for certificate 
selection to maintain widespread client compatibility (which also may only be 
feasible for large operators, and will harm the TLS ecosystem), and that we 
will be adding roadblocks to deployment of more modern trust stores.

There’s still details to work out, but I support adoption of the draft as a 
good starting point.

Kyle Nekritz

From: TLS  On Behalf Of Devon O'Brien
Sent: Tuesday, April 23, 2024 4:37 PM
To: tls@ietf.org
Cc: Bob Beck 
Subject: [TLS] WG Adoption for TLS Trust Expressions

After sharing our first draft of TLS Trust Expressions and several discussions 
across a couple IETFs, we’d like to proceed with a call for working group 
adoption of this draft. We are currently prototyping trust expressions in 
BoringSSL &
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
ZjQcmQRYFpfptBannerEnd

After sharing our first draft of TLS Trust 
Expressions<https://datatracker.ietf.org/doc/draft-davidben-tls-trust-expr/> 
and several discussions across a couple  IETFs, we’d like to proceed with a 
call for working group adoption of this draft. We are currently prototyping 
trust expressions in BoringSSL & Chromium and will share more details when 
implementation is complete.


As we mentioned in our message to the mailing list from January, our primary 
goal is to produce a mechanism for supporting multiple subscriber 
certificates<https://github.com/davidben/tls-trust-expressions/blob/main/explainer.md>
 and efficiently negotiating which to serve on a given TLS connection, even if 
that ends up requiring significant changes to the draft in its current state.


To that end, we’re interested in learning whether wg members support adoption 
of this deployment model and the currently-described certificate negotiation 
mechanism or if they oppose adoption (and why!).


Thanks!

David, Devon, and Bob

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WG Adoption for TLS Trust Expressions

[Ilari Liusvaara]

On Tue, Apr 23, 2024 at 01:37:26PM -0700, Devon O'Brien wrote:
> After sharing our first draft of TLS Trust Expressions
>  and
> several discussions across a couple  IETFs, we’d like to proceed with a
> call for working group adoption of this draft. We are currently prototyping
> trust expressions in BoringSSL & Chromium and will share more details when
> implementation is complete.
> 
> As we mentioned in our message to the mailing list from January, our
> primary goal is to produce a mechanism for supporting multiple subscriber
> certificates
> 
> and efficiently negotiating which to serve on a given TLS connection, even
> if that ends up requiring significant changes to the draft in its current
> state.

The negotiation mechanism mostly looks OK. Might need a few tweaks,
e.g.:

- Sorting the TrustExpressionList in some canonical order, to simplify
  TLS server a bit.
- Adding record type to TrustExpression for future extension (with
  unknown trust expressions ignored).


The subscriber side is far more challenging. The core issue is that
applications act as middlemen between ACME client and TLS library,
and those are very variable bunch.

There currently is no way of passing the information required, so
some application changes will be required. The issue is application
limitations that would require drastic changes, which are discouraged,
to remove.

Examples of application limitations that might be very hard to fix:

- Application selects one subscriber certificate to use.
- Application selects some fixed (unchangeable by ACME client) N
  subscriber certificates, and then the TLS library selects among
  those. 

And there are very popular applications that are like this.


However, even with fixed subscriber certificate, it is still valuable
to be able to select among available issuer chains. Some can be
significantly smaller than the others (e.g., 1119 bytes vs. 701 bytes
vs. 0 bytes). Things get even more lopsided with post-quantum
certificates.


This would lead to model where the certificate files have:

- Subscriber certificate
- Default issuer chain
- Alternate issuer chains, together with negotiation data.

The application would then pass these to the TLS library, which would
perform the final merging of data across possible subscriber
certificates, and then perform subscriber selection and issuer chain
selection from available candidates.


And even if alternate issuer chains seem to be associated with the
issuer, there is a subtle issue: Name constraints can differ among
possible issuer chains. This can happen due to:

- explicit name constraints present in some intermediates but not
  others. This has happened, and led to divergent name constraints.
- Root programs imposing implicit name constraints on roots. This
  has also happened (but I don't know if this has led to divergent
  name constriants).


> To that end, we’re interested in learning whether wg members support
> adoption of this deployment model and the currently-described certificate
> negotiation mechanism or if they oppose adoption (and why!).

The bar to clear for adoption is "good starting point", which this seems
to be, even if the details of mechanism do not work out (as detailed
above).




-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] WG Adoption for TLS Trust Expressions

[Devon O'Brien]

After sharing our first draft of TLS Trust Expressions
 and
several discussions across a couple  IETFs, we’d like to proceed with a
call for working group adoption of this draft. We are currently prototyping
trust expressions in BoringSSL & Chromium and will share more details when
implementation is complete.

As we mentioned in our message to the mailing list from January, our
primary goal is to produce a mechanism for supporting multiple subscriber
certificates

and efficiently negotiating which to serve on a given TLS connection, even
if that ends up requiring significant changes to the draft in its current
state.

To that end, we’re interested in learning whether wg members support
adoption of this deployment model and the currently-described certificate
negotiation mechanism or if they oppose adoption (and why!).

Thanks!

David, Devon, and Bob
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls