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

[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

[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

[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

[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
>> https://www.ietf.or

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: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

[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

[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

[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

[TLS] Opsdir early review of draft-ietf-tls-wkech-04

[Tim Chown via Datatracker]

Reviewer: Tim Chown
Review result: Not Ready

Hi,

I have reviewed this document as an early Operations Directorate review.

The document defines a well-known URI that can be used to inform an
authoritative DNS server of an origin's service bindings, for cases where an
API to perform the function is not available.

As per the recent DNS and ART reviews, and even by the author's admission in
the list discussion that I've read, the document is not ready for publication.

The writing style is currently rather note form and thus quite hard to follow.
The idea does seem to have merit, but the text is quite loose in places at the
moment, uses terminology like "split mode" that could be more clearly
explained, and is vague on issues like handling unknown keys returned in JSON.

There's not much I can add beyond what's already been said in the ART and DNS
reviews, but I believe there's scope for the work to be progressed successfully
and I'd encourage the author's to do so.

Tim



___
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, brows

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

[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 l

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] Opsdir early review of draft-ietf-tls-wkech-04

[Stephen Farrell]

Thanks Tim,

I'll take your review as confirming the others then and
will work on addressing those issues next week or two.

Cheers,
S.

On 30/04/2024 17:07, Tim Chown via Datatracker wrote:

Reviewer: Tim Chown
Review result: Not Ready

Hi,

I have reviewed this document as an early Operations Directorate review.

The document defines a well-known URI that can be used to inform an
authoritative DNS server of an origin's service bindings, for cases where an
API to perform the function is not available.

As per the recent DNS and ART reviews, and even by the author's admission in
the list discussion that I've read, the document is not ready for publication.

The writing style is currently rather note form and thus quite hard to follow.
The idea does seem to have merit, but the text is quite loose in places at the
moment, uses terminology like "split mode" that could be more clearly
explained, and is vague on issues like handling unknown keys returned in JSON.

There's not much I can add beyond what's already been said in the ART and DNS
reviews, but I believe there's scope for the work to be progressed successfully
and I'd encourage the author's to do so.

Tim





OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
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 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

[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

[TLS] I-D Action: draft-ietf-tls-rfc8447bis-09.txt

[internet-drafts]

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

   Title:   IANA Registry Updates for TLS and DTLS
   Authors: Joe Salowey
Sean Turner
   Name:draft-ietf-tls-rfc8447bis-09.txt
   Pages:   18
   Dates:   2024-04-30

Abstract:

   This document updates the changes to TLS and DTLS IANA registries
   made in RFC 8447.  It adds a new value "D" for discouraged to the
   recommended column of the selected TLS registries.

   This document updates the following RFCs: 3749, 5077, 4680, 5246,
   5705, 5878, 6520, 7301, and 8447.

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

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

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

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