[TLS]Re: Trust Anchor Negotiation Surveillance Concerns and Risks

[Devon O'Brien]

> Yes, if one drops usecases that are valuable to simplify stuff, later
> adding mechanism for those usecases ends up more complex than if one
> had just gone with the originally more complex solution.
>
> And it might be worse than just supporting both: The features could
> interact in bad ways. For example of bad interaction, certificate
> compression versus certificate extensions.
>
> But on the other side there is excessive complexity from trying to solve
> too much (e.g, certificate policies). Or worse, complexity that does not
> serve any actual purpose (e.g., differing representations of IDNs in
> email certificates).
>

This is indeed the exact motivation behind us proposing solutions to
address the broader use case of trust anchor negotiation in TLS.


The primary purpose of trust anchor negotiation is the same as the broader
TLS parameter negotiation problem: allowing client and server to agree on a
mutually-satisfiable decision when configurations differ, but overlap.
Additionally, in a world in which trust anchor negotiation exists, there is
the possibility of improving upon existing TLS PKI pain points exacerbated
by its absence.


There are existing solutions that address a subset of these pain points.
Combining these together risks increasing complexity beyond a single more
complex solution and introduces possible undefined behavior, unexpected
failure modes, etc.


There are also solutions that are theoretically capable of solving the
broader problem, but with barriers to viable deployment (such as
certificate_authorities).


I am deeply sensitive to the pitfall of adding extensibility for
extensibility's sake and feel that the complexity of TE and TAI are a
result of different tradeoffs, of which the WG may prefer one over the
other. As David Benjamin noted, TE pushed complexity away from TLS clients
and servers and towards root programs and CAs, which are both fewer, and
have a well-formed existing relationship. TAI, on the other hand, is able
to be more simply specified at the cost of adding additional dependencies,
such as maintaining fresh and accurate DNS records.


On the whole, we hope the WG will review both proposals and let us know
which set of tradeoffs we collectively prefer so that we can standardize
and deploy a viable negotiation mechanism.


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

[TLS]Trust Anchor Negotiation Surveillance Concerns and Risks

[Devon O'Brien]

Hi all, We’ve added a document that attempts to summarize, and offer an
initial analysis of, several of the scenarios that have been raised in
on-list discussions related to the possibilities that Trust Expressions (or
more broadly, Trust Anchor Negotiation) could be used to enable
surveillance, or to make surveillance easier to achieve than with existing
solutions.

We’ve been adding to this document for some time, and while there is
overlap with the documents that Dennis has recently shared, it is not a
response to them, as it was nearly complete by the time they were posted.
Our goal is for this analysis to be complete and accurate, so we will
incorporate additional scenarios, arguments, and analysis over time based
on the ensuing discussion.

https://github.com/davidben/tls-trust-expressions/blob/main/surveillance-and-trust-anchor-negotiation.md

As with any of the other documents in the repository, we encourage you to
ask on list, or file a github issue if you feel we have missed something or
that our analysis is incorrect

We look forward to the WGs comments and hope to see those coming to
Vancouver next week.

- Devon, Bob, David
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]TLS trust expressions and certificate_authorities

[Devon O'Brien]

Hello,

I realize there has been extensive discussion about trust expressions and a
variety of hypothetical scenarios that some believe will play out should
this draft get adopted and implemented. I would like to start this out with
a clear statement: we hear these criticisms and are paying very close
attention to them in order to help ensure this working group does not ship
an irresponsible standard that causes any of the possible doomsday
scenarios sketched out. The crux of this disagreement isn’t whether the
outlined hypotheticals are bad; we are in strong agreement on this point.
Rather, the disagreement is about the causality being posited between a
rather incremental extension mechanism and these outcomes. Here, we authors
strongly disagree with the points that have been repeatedly mentioned by
some working group members and I hope that a more careful analysis of what
trust expressions actually provide over the status quo will help the
working group work past these disagreements.

I believe that, in our excitement at the opportunities that a more agile
web PKI can provide, we did ourselves and the broader community a
disservice by leaning too far into some of the far-reaching possibilities
we envision from a world with trust expressions. While we remain excited
about a more agile and less-ossified PKI, it’s now clear that such emphasis
caused the conversation to shift dramatically away from what the draft
actually says and towards a variety of opinion-based arguments about what
laws may be written by various world governments in the coming years and
decades.

Focusing on the actual draft text, the TLS trust expressions extension does
not represent any kind of major paradigm shift, primarily due to its strong
similarity to the existing certificate_authorities TLS extension. The
difference between these extensions exists not in what information is being
communicated, but rather, how concisely it’s being communicated. RFC 8446
defines the certificate_authorities extension as follows: “The
"certificate_authorities" extension is used to indicate the certificate
authorities (CAs) which an endpoint supports and which SHOULD be used by
the receiving endpoint to guide certificate selection.”

In practice, this means:

   -

   The supported certificate authorities are communicated by sending a list
   of DER-encoded distinguished names in the ClientHello and
   CertificateRequest messages
   -

   Subscribers match this set of distinguished names against their
   provisioned certificates and select one to serve
   -

   If no matching certificate exists, subscribers rely on some fallback
   heuristic for selection


To more accurately describe what TLS trust expressions does and doesn’t do,
I would like to discuss it in terms of its similarities and differences to
certificate_authorities. Defined within trust expressions is:

   1.

   A labeling and compression mechanism for the certificate_authorities TLS
   extension, also sent in the ClientHello and CertificateRequest messages, so
   that relying parties can more efficiently communicate this information to
   subscribers. With certificate_authorities, this is a list of trust anchor
   distinguished names.
   2.

   A means of distributing this label information to subscribers so that
   they can extract trust anchor information from the aforementioned labels.
   With certificate_authorities, the labels are contained within the
   certificates themselves.
   3.

   An algorithm for subscribers to match labels against a set of
   pre-provisioned TLS certificate paths. With certificate_authorities, this
   is a direct string match of listed distinguished names which must be
   searched for among provisioned certificates.
   4.

   A mechanism to account for changes in trust between when subscribers
   obtain this information (certificate issuance) and when they evaluate a
   label (a TLS connection). This isn’t defined in certification_authorities
   because it’s not needed for the direct name matching used therein.


There is no fundamental capability offered by trust expressions that isn’t
already available by certificate_authorities. When compared to
certificate_authorities, the primary obstacle being addressed by trust
expressions is the size of the message sent in (1). X.501 distinguished
names are notoriously verbose, and modern trust stores contain hundreds of
trust anchors, rendering it infeasible for relying parties to dedicate tens
of thousands of bytes in a TLS handshake to listing trust anchors. Notably,
parties that may wish for clients to signal a specific mandated CA can do
so efficiently with certificate_authorities today, as this requires sending
only a single distinguished name.

Compressing a set of trust anchor names can be done in a variety of ways,
but trust expressions does so by applying a label and version scheme to
trust stores (3), which are an existing and recognized collection of trust
anchors that are also already relying party 

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

[Devon O'Brien]

Hi Ekr,

Thanks for calling attention to the wg draft adoption process; we didn't
intend to issue a formal call (as that's reserved for wg chairs) and
hopefully didn't cause too much confusion to that effect. While we're
waiting to hear from the chairs whether they want to move this draft into
candidate for adoption status, we wanted to share our planned next steps
and gather some opinions on the mechanism and draft on list since so many
of our ad-hoc conversations on this draft happened in person over the past
couple of IETFs.

-Devon

On Mon, Apr 29, 2024 at 6:44 AM Eric Rescorla  wrote:

> Hi folks,
>
> I haven't yet formed an opinion on this document yet, but I did want to
> observe that calls for adoption are issued by the chairs, not by individual
> participants. Of course, anyone can start a thread and comments in this
> thread are information for the chairs, but if adoption does happen, it will
> be via some separate process.
>
> -Ekr
>
>
> On Sat, Apr 27, 2024 at 11:42 AM Brendan McMillion <
> brendanmcmill...@gmail.com> wrote:
>
>> Hi Devon
>>
>> I support adoption
>>
>> On Fri, Apr 26, 2024 at 7:38 PM Andrei Popov > 40microsoft@dmarc.ietf.org> 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
>>
>
___
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