Re: [TLS] [EXTERNAL] Re: WG Adoption for TLS Trust Expressions

[Brendan McMillion]

Hi Devon

I support adoption

On Fri, Apr 26, 2024 at 7:38 PM Andrei Popov  wrote:

> I support adoption.
>
> Cheers,
>
> Andrei
>
> -Original Message-
> From: TLS  On Behalf Of Watson Ladd
> Sent: Friday, April 26, 2024 7:13 PM
> To: Devon O'Brien 
> Cc: tls@ietf.org; Bob Beck 
> Subject: [EXTERNAL] Re: [TLS] WG Adoption for TLS Trust Expressions
>
> On Tue, Apr 23, 2024 at 1:39 PM Devon O'Brien  40google@dmarc.ietf.org> 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%2Fmailman%2Flistinfo%2Ftls&data=05%7C02%7CAndrei.Popov%40micr
> > osoft.com%7C6ca75aa932344f322d9f08dc665fa375%7C72f988bf86f141af91ab2d7
> > cd011db47%7C1%7C0%7C638497808164901299%7CUnknown%7CTWFpbGZsb3d8eyJWIjo
> > iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%
> > 7C&sdata=2n8iljUXBtb4Jf%2FZTqN2Nl5j81WoatTYA64c5%2FRoH0A%3D&reserved=0
>
>
>
> --
> 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
>
___
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

[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
> <https://www.mnot.net/blog/2023/11/01/regulators> 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

[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

[TLS]Re: TLS Trust Expressions risks

[Brendan McMillion]

>
> What point in this process depends on Trust Expressions - that is to say,
> at what point does a browser decide that the government CA is acting
> differently enough from the other CAs in its root store that it’s willing
> to fragment or bifurcate its trust store, and after that point, how does
> the politics play out that mandating this CA’s trust is still somehow
> legitimate?


I'll assert that many people consider eavesdropping by their own government
to be legitimate, and eavesdropping by foreign governments to be
illegitimate. The point at which a browser would need to make a decision
about bifurcating its trust store or pulling out of a country, is the
moment a government-controlled CA starts mis-issuing certificates. Without
TE, browsers have no ability to bifurcate their trust store, and servers
have no ability to support a bifurcated client base. So without TE, the
decision must be to pull out of the country, as this is the only
technically expedient solution which is acceptable to most people. With TE,
browsers /can/ bifurcate their trust store, and servers /can/ support a
bifurcated client base. So a decision to pull out of the country, rather
than bifurcate, is simply malicious.

It's also worth pointing out that the security benefits of TE (i.e.,
allowing rapid distrust of roots) come from gracefully handling client
fragmentation that's the result of time-since-last-update, not
fragmentation that's a result of different codebases. It may be worth
thinking about how to rework the proposal to reflect that


On Fri, May 24, 2024 at 2:46 PM Watson Ladd  wrote:

> On Fri, May 24, 2024 at 2:16 PM Nick Harper  wrote:
> >
> > On Fri, May 24, 2024 at 10:14 AM Dennis Jackson  40dennis-jackson...@dmarc.ietf.org> wrote:
> >>
> >> Hi David,
> >>
> >> The certification chains issued to the server by the CA comes tagged
> with a list of trust stores its included in. The named trust stores are
> completely opaque to the server. These chains and names may not be trusted
> by any client nor approved by any server, they are issued solely by the CA
> as opaque labels. These chains sit on the server and will not be used
> unless a client connects with the right trust store label but obviously can
> easily be scanned for by anyone looking to check how pervasively deployed
> the alternate trust store is.
> >>
> >> Do you dispute any part of that? Most of what you wrote went off on a
> completely different tangent.
> >>
> >> 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.
> >>
> >> Again, my primary concern here is not around the behavior of individual
> root stores, this is not relevant to the concern I'm trying to communicate
> to you. I know folks from all of the major root stores have great faith in
> their judgement and technical acumen.
> >>
> >> My concern is that Trust Expressions upsets a fragile power balance
> which exists outside of the individual root stores. There is an eternal war
> between governments pushing to take control of root stores and the security
> community pushing back. This battle happens in parliaments and governments,
> between lawmakers and officials, not within root stores and their
> individual judgement largely does not matter to this war. The major
> advantages we as the security community have today are that:
> >>
> >> a) These attempts to take control for surveillance are nakedly
> obvious to the local electorate because crappy domestic roots have no
> legitimate purpose because they can never achieve any real adoption.
> >>
> >> b) If a root store were to bow to pressure and let in a root CA
> used for interception, every other country has an interest in preventing
> that. An international WebPKI means that we are either all secure, or all
> insecure, together.
> >>
> >> Trust Expressions, though intended to solve completely different
> problems, will accidentally eradicate both of these advantages. Firstly, it
> provides a nice on ramp for a new domestic trust store, mostly through the
> negotiation aspect but also through the CA pre-distribution. Secondly, by
> enabling fragmentation along geographic boundaries whilst maintaining
> availability of websites. Without Trust Expressions, we cannot balkanize
> TLS. With Trust Expressions, we can and we know people who want to (not
> anyone in this thread).
> >>
> >> If you still do not understand this wider context within which all of
> our work sits, I do not think further discussion between you and I is going
> to help matters.
> >>
> >> I would suggest we focus our discussion on the use cases of Trust
> Expressions and how exactly it would work in practice - these concerns I
> shared earlier in the thread are solely technical and operational and

[TLS]Re: TLS Trust Expressions risks

[Brendan McMillion]

>
> In your latest message [5], I understand the context of governments
> pushing for inclusion of certain roots with varying degrees of legitimacy.
> I don’t see the on-ramp for CA pre-distribution being meaningfully
> different with Trust Expressions compared to certificate_authorities.
>

Sorry, I meant to address this point as well. The difference between TE and
the certificate_authorities extension, is that there's less widespread
server support for the latter. You might compel a browser to bifurcate and
advertise the certificate_authorities extension, but pushing out
server-side support would be a substantial challenge. Not speaking for
Google, but I believe their intention /is/ to put in the substantial work
to make server-side TE support ubiquitous, such that it would be a minor
ACME config change

On Fri, May 24, 2024 at 4:00 PM Brendan McMillion <
brendanmcmill...@gmail.com> wrote:

> What point in this process depends on Trust Expressions - that is to say,
>> at what point does a browser decide that the government CA is acting
>> differently enough from the other CAs in its root store that it’s willing
>> to fragment or bifurcate its trust store, and after that point, how does
>> the politics play out that mandating this CA’s trust is still somehow
>> legitimate?
>
>
> I'll assert that many people consider eavesdropping by their own
> government to be legitimate, and eavesdropping by foreign governments to be
> illegitimate. The point at which a browser would need to make a decision
> about bifurcating its trust store or pulling out of a country, is the
> moment a government-controlled CA starts mis-issuing certificates. Without
> TE, browsers have no ability to bifurcate their trust store, and servers
> have no ability to support a bifurcated client base. So without TE, the
> decision must be to pull out of the country, as this is the only
> technically expedient solution which is acceptable to most people. With TE,
> browsers /can/ bifurcate their trust store, and servers /can/ support a
> bifurcated client base. So a decision to pull out of the country, rather
> than bifurcate, is simply malicious.
>
> It's also worth pointing out that the security benefits of TE (i.e.,
> allowing rapid distrust of roots) come from gracefully handling client
> fragmentation that's the result of time-since-last-update, not
> fragmentation that's a result of different codebases. It may be worth
> thinking about how to rework the proposal to reflect that
>
>
> On Fri, May 24, 2024 at 2:46 PM Watson Ladd  wrote:
>
>> On Fri, May 24, 2024 at 2:16 PM Nick Harper  wrote:
>> >
>> > On Fri, May 24, 2024 at 10:14 AM Dennis Jackson > 40dennis-jackson...@dmarc.ietf.org> wrote:
>> >>
>> >> Hi David,
>> >>
>> >> The certification chains issued to the server by the CA comes tagged
>> with a list of trust stores its included in. The named trust stores are
>> completely opaque to the server. These chains and names may not be trusted
>> by any client nor approved by any server, they are issued solely by the CA
>> as opaque labels. These chains sit on the server and will not be used
>> unless a client connects with the right trust store label but obviously can
>> easily be scanned for by anyone looking to check how pervasively deployed
>> the alternate trust store is.
>> >>
>> >> Do you dispute any part of that? Most of what you wrote went off on a
>> completely different tangent.
>> >>
>> >> 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.
>> >>
>> >> Again, my primary concern here is not around the behavior of
>> individual root stores, this is not relevant to the concern I'm trying to
>> communicate to you. I know folks from all of the major root stores have
>> great faith in their judgement and technical acumen.
>> >>
>> >> My concern is that Trust Expressions upsets a fragile power balance
>> which exists outside of the individual root stores. There is an eternal war
>> between governments pushing to take control of root stores and the security
>> community pushing back. This battle happens in parliaments and governments,
>> between lawmakers and officials, not within root stores and their
>> individual judgement largely does not matter to this war. The major
>> advantages we as the security co

[TLS]Re: TLS Trust Expressions risks

[Brendan McMillion]

>
> Even with ubiquitous server-side TE support and servers configured with
> both a ubiquitous chain and a government-issued chain, it seems to me this
> government push for use of their CA requires a change to server TLS stacks
> to prefer the government CA chain since both will match the client's
> advertised trust stores. Mandating this server behavior change seems to me
> like a heavier lift than just a minor config change.
>

The part of the spec you quoted says: if multiple certs match, choose any.
When TE is rendered in actual code, why do you assume that there will be no
configurable or easily-gameable way to make sure the government CA
always wins?

On Fri, May 24, 2024 at 5:15 PM Nick Harper  wrote:

>
>
> On Fri, May 24, 2024 at 2:27 PM Brendan McMillion <
> brendanmcmill...@gmail.com> wrote:
>
>> In your latest message [5], I understand the context of governments
>>> pushing for inclusion of certain roots with varying degrees of legitimacy.
>>> I don’t see the on-ramp for CA pre-distribution being meaningfully
>>> different with Trust Expressions compared to certificate_authorities.
>>>
>>
>> Sorry, I meant to address this point as well. The difference between TE
>> and the certificate_authorities extension, is that there's less widespread
>> server support for the latter. You might compel a browser to bifurcate and
>> advertise the certificate_authorities extension, but pushing out
>> server-side support would be a substantial challenge. Not speaking for
>> Google, but I believe their intention /is/ to put in the substantial work
>> to make server-side TE support ubiquitous, such that it would be a minor
>> ACME config change
>>
>
> The degree of server support is an important consideration. Even with
> ubiquitous server-side TE support and servers configured with both a
> ubiquitous chain and a government-issued chain, it seems to me this
> government push for use of their CA requires a change to server TLS stacks
> to prefer the government CA chain since both will match the client's
> advertised trust stores. Mandating this server behavior change seems to me
> like a heavier lift than just a minor config change. I don't have a good
> sense of how it compares to the difficulty of configuring a server stack to
> use the certificate_authorities extension. It appears that at least OpenSSL
> has support for the certificate_authorities extension (
> https://github.com/openssl/openssl/issues/13453), though the application
> using OpenSSL needs to implement the certificate selection. With TE, I
> imagine that certificate selection will happen inside the TLS stack or a TE
> library closely tied to the TLS stack.
>
> I wonder if there are ways to make it harder for a server to choose the
> "bad" cert and easier to choose the "good" cert, but this seems like a
> social/political problem rather than a technical one.
>
> On Fri, May 24, 2024 at 2:46 PM Watson Ladd  wrote:
>
>> To be clear, in Denis's scenario Ebonia requires all servers to obtain
>> a cert from Honest Ahmed's
>> (https://bugzilla.mozilla.org/show_bug.cgi?id=647959) Ebonian Secure
>> CA. Server operators who complain that this will break clients are
>> told that it will have a trust expression that currently isn't used,
>> but government inspectors will use it to see if the cert is installed.
>> Then in step 2 they use the number of certs issued to bolster the
>> argument for inclusion. I don't see how Trust Expressions isn't making
>> this scenario easier.
>>
>
> Sure, the Ebonian government could mandate that all servers get a cert
> from Honest Achmed, and provide a specific Ebonia trust store label for the
> servers to match against. However, the only time the server would use that
> cert chain is when the government inspectors send the Ebonian trust store
> label to check if the cert is installed. In step 2 when Ebonia uses the
> number of certs from Honest Achmed as part of their argument, it matters
> what that count is. Is it the number of certs issued, number of certs
> servers are "willing to use" (that's not very well defined), number of
> certs that servers are actually using? Of course Ebonia will choose
> whatever suits them best, but it also depends where that number came from
> and how it was obtained. For example, Ebonia can get a large number of
> certs issued by Honest Achmed without Trust Expressions by having Honest
> Achmed generate a cert for every cert it sees in CT logs (with the Honest
> Achmed leaf using the same public key as in the logged leaf certs so that
> they're technically usable by the server). I i

[TLS] Re: Cases against trust negotiation

[Brendan McMillion]

I'm not sure that this is a productive framing: "we’re really asking for a
verdict on trust negotiation as a mechanism". Trust anchor negotiation is
already deployed. It takes the form of chain building, cross signing,
and/or client fingerprinting. At the interim, the presenters went through
many of their past experiences where this system has not worked very well.
There was general consensus that /something/ should change to improve the
situation. So the question is whether that "something" should be a deeper
reconsideration of the "chain building" approach, or an incremental
improvement on it.

Specifically on the point of "most of the arguments in favor of trust
negotiation seem to depend on cross signing not being a thing" -- cross
signing was briefly discussed at the interim, with the conclusion being
that the necessary client-side logic was too often implemented in a buggy
or unreliable way. If the wg decides to pursue an incremental improvement
of chain building, we'd need to accept that baggage and have a plan to
improve chain building's reliability.

Happy holidays

On Sat, Dec 21, 2024 at 5:27 AM Martin Thomson  wrote:

> Hi,
>
> This took a while to pull together, but Dennis has just published a fairly
> comprehensive look at the question of trust negotiation:
>
>
> https://datatracker.ietf.org/doc/draft-jackson-tls-trust-is-nonnegotiable/
>
> This is a response to the proposal to improve trust negotiation in TLS, in
> particular draft-beck-tls-trust-anchor-ids-03. There’s been a lot of bits
> spilled on this topic already, generating far more heat than light.  It is
> an important question to examine though, albeit one that is broader than we
> typically engage with here.
>
> The conclusion in the draft, one that I support, is that trust negotiation
> in TLS is not worth it. It’s not just that fundamental changes to the
> system aren’t really justified, it’s that the change will do more harm than
> good.
>
>
> There seem to be three broad goals being considered for trust negotiation:
>
> 1. Make it easier for site operators to find compatible certificates.
> 2. Make it easier for root programs to implement security improvements.
> 3. Smooth the transition to post-quantum certificates.
>
> Trust negotiation allows sites to split the client population up.  Each
> can then be addressed with different certificates, according to different
> policies.  Divide and conquer. However, it’s unclear how this approach
> could actually improve security. Meanwhile, it seems to have as much
> potential to harm compatibility through fragmentation as it does to help
> it.
>
> In the recent interim, the PQ certificate deployment thing was identified
> as a bit of a distraction.  Or maybe PQ was a shiny reason to care about
> what is really a fairly mundane set of operational problems.
>
> The most compelling problem here seems to be that some clients aren’t
> being updated with new trust anchors.  (No really, stop doing that. The
> Internet is so hostile that updating isn’t a choice; it’s a necessity.)
> Anyhow, being able to segment that population of clients off seems like it
> would make it easier for clients and root programs to implement new
> policies without having to worry about compatibility, while giving site
> operators the ability to give old and new clients different certificates.
>
>
> Dennis’s analysis lays out how this isn’t a straight win-win situation as
> proponents claim. Rather, the two constituencies are in competition and
> enabling negotiation shifts a lot of the responsibility for the operational
> work of maintaining compatibility. CAs and root program operators do less
> work; website operators do more.
>
> For all that the system is a source of constant pain for some people,
> that’s because it is an important system.  That system strikes a balance
> between the equities of multiple groups: end users, website operators, CAs,
> and client developers/root program operators.  I list these in this order
> in the spirit of the priority of constituencies [1] as I believe applies to
> this domain.  That order reflects the size of each group and the technical
> resources they can deploy, recognizing that larger groups with lower
> resources are less able to deal with operational complexity.
>
> Shifting compatibility work onto site operators is not the right answer
> when there are so many more of them, with far less ability to deal with
> these complexities.  Big operators might win out, but small ones will not,
> even if automation might eventually help. This is partly due to the need to
> coordinate closely with DNS configuration in the proposed design. The
> design is as fair an approach as any I can conceive of, but we’ve already
> seen how hard that coordination is with ECH [2].
>
> That’s rough, because any benefits that come from negotiation require lots
> of deployment.  Otherwise, clients that want to distrust a CA can’t be sure
> that a site that doesn’t support negotiation uses tha

[TLS] Re: Adoption Call for Trust Anchor IDs

[Brendan McMillion]

I support adoption

I still like the framing I gave in my last email: The current solution to
trust anchor agility is path building / cross-signing. So the question is
whether an incremental improvement on path building is feasible, or if
Something Else is needed. I firmly believe that path building is
unsalvageable. In addition to the interim discussions, this blog post [1]
by Ryan Sleevi was very convincing to me. The TAI draft says that path
building MAY be disabled, I would obviously make this MUST.

1.
https://medium.com/@sleevi_/path-building-vs-path-verifying-the-chain-of-pain-9fbab861d7d6

On Wed, Jan 15, 2025 at 2:11 PM Ryan Hurst  wrote:

> As someone with experience building and managing many CAs, running a root
> program, and building out platform technology to enable TLS use cases, I
> believe this work is important and fully support its adoption. Today’s
> manual, out-of-band management of trust anchors not only holds the web back
> but also unnecessarily exposes users to trust anchors that are not
> essential for enabling TLS on the web. This proposal provides a credible
> path to address this lack of agility. While it’s clear that this
> slow-moving and fragile approach is already problematic, it will only
> become more challenging as time goes on. As with all specifications,
> adoption remains the key challenge, but I believe this draft offers a
> practical solution to these issues without disrupting existing systems.
>
> Ryan Hurst
>
> On Wed, Jan 15, 2025 at 8:00 AM Joseph Salowey  wrote:
>
>> At the trust tussle Interim in October we had consensus that the working
>> group was interested in working on the following problem:
>>
>> “Avoid client trust conflicts by enabling servers to reliably and
>> efficiently support clients with diverse trust anchor lists, particularly
>> in larger PKIs where the existing certificate_authorities extension is not
>> viable”
>>
>> After IETF 121, we asked for submissions for possible working group
>> adoption as a starting point for this work. We received two submissions:
>>
>> [1] Trust Anchor Identifiers, draft-beck-tls-trust-anchor-ids-03
>> 
>>
>> [2] Trust is non-negotiable, draft-jackson-tls-trust-is-nonnegotiable-00
>> 
>>
>> [1] defines a new protocol mechanism, while [2] provides an explanation
>> of why the mechanism in [1] may not be needed and may be problematic. Since
>> the second draft does not define a protocol mechanism we are not
>> considering it for adoption, but we request that working group members
>> review both documents and use [2] as input into determining whether we
>> should adopt [1] as a working group item.  Adoption as a working group item
>> means the working group has change control over and can modify it as
>> necessary; an adopted document is only a starting point.  Please respond to
>> this thread if you think the document should be adopted as a working group
>> item. If you think the document is not appropriate for adoption please
>> indicate why.  This adoption call will close on February 7, 2025.  Also
>> please remember to maintain professional behavior and keep the discussion
>> focused on technical issues.
>>
>>
>> Thanks,
>>
>>
>> Sean, Deirdre and Joe
>>
>> ___
>> 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

[TLS] Fwd: New Version Notification for draft-mcmillion-tls-transparency-revocation-00.txt

[Brendan McMillion]

Hi tls@

I'd like to share a document I've been working on for a while, forwarded
below. It essentially is a stab at what Certificate Transparency would look
like if it were built on top of Key Transparency. This document primarily
covers the TLS extension and the operation of the TLS server, while the
in-depth description of the transparency protocol is left to the keytrans
protocol document.

Since the system is built on KT, it allows website operators to efficiently
audit the certificates that have been issued for their domains, and this
remains secure regardless of any amount of collusion by trusted parties. It
also provides fast, fail-closed revocation.

Let me know your thoughts, and if you generally feel we should continue to
develop this document. Thank you!

-- Forwarded message -
From: 
Date: Sun, Jun 29, 2025 at 9:13 AM
Subject: New Version Notification for
draft-mcmillion-tls-transparency-revocation-00.txt
To: Brendan McMillion , Dennis Jackson <
i...@dennis-jackson.uk>, Devon O'Brien 


A new version of Internet-Draft
draft-mcmillion-tls-transparency-revocation-00.txt has been successfully
submitted by Brendan McMillion and posted to the
IETF repository.

Name: draft-mcmillion-tls-transparency-revocation
Revision: 00
Title:Reliable Transparency and Revocation Mechanisms
Date: 2025-06-29
Group:Individual Submission
Pages:44
URL:
https://www.ietf.org/archive/id/draft-mcmillion-tls-transparency-revocation-00.txt
Status:
https://datatracker.ietf.org/doc/draft-mcmillion-tls-transparency-revocation/
HTML:
https://www.ietf.org/archive/id/draft-mcmillion-tls-transparency-revocation-00.html
HTMLized:
https://datatracker.ietf.org/doc/html/draft-mcmillion-tls-transparency-revocation


Abstract:

   This document describes reliable mechanisms for the publication and
   revocation of Transport Layer Security (TLS) certificates.  This
   reliability takes several forms.  First, it provides browsers a
   strong guarantee that all certificates they accept are truly
   published and unrevoked at the time they're accepted.  Second, it
   allows operators to monitor for mis-issuances related to their
   websites in a highly efficient way without relying on third-party
   services.  Third, it provides a high degree of operational redundancy
   to minimize the risk of cascading outages.



The IETF Secretariat
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org