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

[Eric Rescorla]

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

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

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 embrace

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]

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] I-D Action: draft-ietf-tls-keylogfile-02.txt

[internet-drafts]

Internet-Draft draft-ietf-tls-keylogfile-02.txt is now available. It is a work
item of the Transport Layer Security (TLS) WG of the IETF.

   Title:   The SSLKEYLOGFILE Format for TLS
   Author:  Martin Thomson
   Name:draft-ietf-tls-keylogfile-02.txt
   Pages:   11
   Dates:   2024-04-29

Abstract:

   A format that supports the logging information about the secrets used
   in a TLS connection is described.  Recording secrets to a file in
   SSLKEYLOGFILE format allows diagnostic and logging tools that use
   this file to decrypt messages exchanged by TLS endpoints.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-tls-keylogfile-02.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-keylogfile-02

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
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