Re: [TLS] Trust Expressions Follow-up

[Rob Sayre]

On Thu, Feb 29, 2024 at 4:31 PM David Benjamin 
wrote:

> Oh, I should have added: I put together an informal "explainer"-style
> document to try to describe the high-level motivations and goals a bit
> better. The format is adapted more from the web platform end [...]
>

There is a very uncharitable way to read these. I don't think we're there,
but let's not get to that point.

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

Re: [TLS] Trust Expressions Follow-up

[David Benjamin]

Oh, I should have added: I put together an informal "explainer"-style
document to try to describe the high-level motivations and goals a bit
better. The format is adapted more from the web platform end, which likes
to have separate explainer and specification documents, but it seemed a
good style for capturing, at a high level, what we're trying to accomplish.
https://github.com/davidben/tls-trust-expressions/blob/main/explainer.md

It's largely a copy of the start of this email thread, but I figured it'd
be useful to have a more canonical home for it. (We'll probably adapt some
of that text back into the draft, after some more wordsmithing.)


On Thu, Feb 29, 2024 at 7:18 PM David Benjamin 
wrote:

> Circling back to this thread, we're now looking at prototyping the TLS
> parts in BoringSSL, on both the client (Chrome) and the server side. Let us
> know if you have any thoughts on the proposal!
>
> (Nothing that would prevent us from changing details, of course. But as
> there are a lot of pieces here, we'd like to get some experience with
> things.)
>
> On Thu, Jan 25, 2024 at 5:00 PM David Benjamin 
> wrote:
>
>> Hi all,
>>
>> Now that the holidays are over, I wanted to follow up on
>> draft-davidben-tls-trust-expr and continue some of the discussions from
>> Prague:
>>
>>
>> https://davidben.github.io/tls-trust-expressions/draft-davidben-tls-trust-expr.html
>>
>>
>> https://datatracker.ietf.org/meeting/118/materials/slides-118-tls-tls-trust-expressions-00
>>
>> First, I wanted to briefly clarify the purpose of excluded_labels
>> :
>> it is primarily intended to address version skew: if the certificate is
>> known to match (example, v10) and the client says (example, v11), the
>> server doesn’t know whether v11 distrusted or retained the CA. We resolve
>> that with a combination of excluded_labels and TrustStoreStatus.
>> excluded_labels is not intended for user-specific removals. I’ve
>> reworked the Privacy Considerations
>> 
>> section to discuss this more clearly.
>>
>> Second, I wanted to take a step back and try to better articulate our
>> goals. I think the best way to look at this draft is in three parts:
>>
>> 1. A new multi-certificate deployment model (the overall goal)
>>
>> 2. Selecting certificates within that model (the TLS parts of the draft)
>>
>> 3. Provisioning certificates (the ACME parts of the draft)
>>
>> We’d most like to get consensus on the first, as it’s the most important.
>> Trust expressions are a way to achieve that goal, but we’re not attached to
>> the specific mechanism if there’s a better one. We briefly discuss this in
>> the introduction
>> ,
>> but I think it is worth elaborating here:
>>
>> The aim is to get to a more flexible and robust PKI, by allowing servers
>> to select between multiple certificates. To do this, we need a way for the
>> servers to reliably select the correct certificate to use with each client.
>> In doing so, we wish to minimize manual changes by server operators in the
>> long run. Most ongoing decisions should instead come from TLS software,
>> ACME client software, and ACME servers.
>>
>> Why does this matter? PKIs need to evolve over time to meet user security
>> needs: CAs that add net value to the ecosystem may be added, long-lived
>> keys should be rotated to reduce risk, and compromised or untrustworthy CAs
>> are removed. Even a slow-moving, mostly aligned ecosystem is still made of
>> individual decisions that roll out to individual clients. This means,
>> whether we like it or not, trust divergence is a fact of life, if for no
>> other reason than out-of-date clients in the ecosystem. These clients could
>> range from unupdatable TV set-top boxes to some IoT device to a browser
>> that could not communicate with its update service.
>>
>> Today, the mere existence of old clients limits security improvements for
>> other, unrelated clients. Consider a TLS client making some trust change
>> for user security. For availability, TLS servers must have some way to
>> satisfy it. Some server, however, may also support an older client. If the
>> server uses a single certificate, that certificate is limited to the
>> intersection of both clients.
>>
>> At the scale of the Internet, the oldest clients last indefinitely. As
>> servers consider older and older clients, that intersection becomes
>> increasingly constraining, causing availability and security to conflict.
>> As a community of security practitioners, I wish I could tell you that
>> security wins, that those servers can simply be convinced to drop the old
>> clients, and that this encourages old clients to update. I think we all
>> know this is not what happens. A

Re: [TLS] Trust Expressions Follow-up

[David Benjamin]

Circling back to this thread, we're now looking at prototyping the TLS
parts in BoringSSL, on both the client (Chrome) and the server side. Let us
know if you have any thoughts on the proposal!

(Nothing that would prevent us from changing details, of course. But as
there are a lot of pieces here, we'd like to get some experience with
things.)

On Thu, Jan 25, 2024 at 5:00 PM David Benjamin 
wrote:

> Hi all,
>
> Now that the holidays are over, I wanted to follow up on
> draft-davidben-tls-trust-expr and continue some of the discussions from
> Prague:
>
>
> https://davidben.github.io/tls-trust-expressions/draft-davidben-tls-trust-expr.html
>
>
> https://datatracker.ietf.org/meeting/118/materials/slides-118-tls-tls-trust-expressions-00
>
> First, I wanted to briefly clarify the purpose of excluded_labels
> :
> it is primarily intended to address version skew: if the certificate is
> known to match (example, v10) and the client says (example, v11), the
> server doesn’t know whether v11 distrusted or retained the CA. We resolve
> that with a combination of excluded_labels and TrustStoreStatus.
> excluded_labels is not intended for user-specific removals. I’ve reworked
> the Privacy Considerations
> 
> section to discuss this more clearly.
>
> Second, I wanted to take a step back and try to better articulate our
> goals. I think the best way to look at this draft is in three parts:
>
> 1. A new multi-certificate deployment model (the overall goal)
>
> 2. Selecting certificates within that model (the TLS parts of the draft)
>
> 3. Provisioning certificates (the ACME parts of the draft)
>
> We’d most like to get consensus on the first, as it’s the most important.
> Trust expressions are a way to achieve that goal, but we’re not attached to
> the specific mechanism if there’s a better one. We briefly discuss this in
> the introduction
> ,
> but I think it is worth elaborating here:
>
> The aim is to get to a more flexible and robust PKI, by allowing servers
> to select between multiple certificates. To do this, we need a way for the
> servers to reliably select the correct certificate to use with each client.
> In doing so, we wish to minimize manual changes by server operators in the
> long run. Most ongoing decisions should instead come from TLS software,
> ACME client software, and ACME servers.
>
> Why does this matter? PKIs need to evolve over time to meet user security
> needs: CAs that add net value to the ecosystem may be added, long-lived
> keys should be rotated to reduce risk, and compromised or untrustworthy CAs
> are removed. Even a slow-moving, mostly aligned ecosystem is still made of
> individual decisions that roll out to individual clients. This means,
> whether we like it or not, trust divergence is a fact of life, if for no
> other reason than out-of-date clients in the ecosystem. These clients could
> range from unupdatable TV set-top boxes to some IoT device to a browser
> that could not communicate with its update service.
>
> Today, the mere existence of old clients limits security improvements for
> other, unrelated clients. Consider a TLS client making some trust change
> for user security. For availability, TLS servers must have some way to
> satisfy it. Some server, however, may also support an older client. If the
> server uses a single certificate, that certificate is limited to the
> intersection of both clients.
>
> At the scale of the Internet, the oldest clients last indefinitely. As
> servers consider older and older clients, that intersection becomes
> increasingly constraining, causing availability and security to conflict.
> As a community of security practitioners, I wish I could tell you that
> security wins, that those servers can simply be convinced to drop the old
> clients, and that this encourages old clients to update. I think we all
> know this is not what happens. Availability almost always beats security. The
> result of this conflict is not that old clients get updates, it is that
> newer clients cannot improve user security. It takes just one important
> server with one important old client to jam everything, with user
> security paying the cost.
>
> We wish to remove this conflict with certificate negotiation, analogous to
> TLS version negotiation and cipher suite negotiation. Certificate
> negotiation, via trust expressions, means security improvements in new
> clients do not conflict with availability for older clients. Servers can,
> with the aid of their ACME servers, deliver different chains to different
> clients as needed.
>
> Now, some of these problems can be addressed with cross-signs between
> CAs, but this is a partial solution at 

Re: [TLS] tls@ietf119: agenda requests

[Jonathan Hoyland]

Hi Sean,

I would like to speak briefly on my draft TLS flag that signals client
support for mTLS [1], and if possible to have a call for adoption.

I would need ~5 mins.

Regards,

Jonathan

[1] https://datatracker.ietf.org/doc/html/draft-jhoyla-req-mtls-flag-01

On Thu, 29 Feb 2024, 16:05 Sean Turner,  wrote:

> The TLS WG is meeting at IETF 119 for 2 hours on Tuesday, March 19, 2024
> from 0930-1130 (local time) [0] in the Plaza Terrace Room [2]. The chairs
> would like to solicit input from the WG for agenda topics. Please send your
> agenda topics request and an estimate for how much time you will need to
> tls-cha...@ietf.org. Please note that we will prioritize existing WG
> items. Please also review the guidance for TLS WG presenters that can be
> found at [2].
>
> Cheers,
> Chris, Joe, and Sean
>
> [0] https://datatracker.ietf.org/meeting/119/agenda
> [1]
> https://datatracker.ietf.org/meeting/119/floor-plan?room=plaza-terrace-room
> [2] https://github.com/tlswg/tlswg-wiki/blob/master/FAQ.md
> ___
> 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] tls@ietf119: I-D submission deadline

[Sean Turner]

Hi! Friendly reminder that the I-D submission deadline for IETF 119 is [1]:

2024-03-04 (Monday) Internet-Draft submission cut-off (for all Internet-Drafts, 
including -00) by UTC 23:59. Upload using the I-D Submission Tool [2]

Cheers,
spt

[1] https://datatracker.ietf.org/meeting/important-dates/
[2] https://datatracker.ietf.org/submit/
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] tls@ietf119: agenda requests

[Sean Turner]

The TLS WG is meeting at IETF 119 for 2 hours on Tuesday, March 19, 2024 from 
0930-1130 (local time) [0] in the Plaza Terrace Room [2]. The chairs would like 
to solicit input from the WG for agenda topics. Please send your agenda topics 
request and an estimate for how much time you will need to tls-cha...@ietf.org. 
Please note that we will prioritize existing WG items. Please also review the 
guidance for TLS WG presenters that can be found at [2].

Cheers,
Chris, Joe, and Sean

[0] https://datatracker.ietf.org/meeting/119/agenda
[1] https://datatracker.ietf.org/meeting/119/floor-plan?room=plaza-terrace-room
[2] https://github.com/tlswg/tlswg-wiki/blob/master/FAQ.md
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls