[TLS]Re: WG Adoption for TLS Trust Expressions

[Dennis Jackson]

Hi David, Devon, Bob,

Response to both your recent mails below:

On Thu, May 9, 2024 at 10:45 AM David Benjamin  
wrote:
We’re particularly concerned about this server operator pain because 
it translates to security risks for billions of users. If root program 
actions cause server operator pain, there is significant pressure 
against those actions. The end result of this is that root store 
changes happen infrequently, with the ultimate cost being that user 
security cannot benefit from PKI improvements.


The claim here is that Trust Expressions is going to make it easier to 
remove CAs by reducing the pain to server operators of CA distrust? This 
seems to be incompatible with the draft's intent for CAs to provision 
the server's certificate chains without interaction with the website 
operator. Why is the CA you're distrusting ever going to voluntarily 
enable their own removal by transitioning their subscribers to a 
different CAs cert chain?


It’s hard to say exact numbers [of trust store labels / versions] at 
this stage. We can only learn with deployment experience, hence our 
desire to progress toward adoption and experimentation.
Leaving aside the concerns about what other parties may abuse this for, 
can you talk concretely about how *you* would use it? Would Chrome and 
Android Webview share the same trust expressions label? Would desktop 
Chrome and mobile Chrome? Would Chrome Canary and Chrome Release? Would 
Chrome and Chromium? Would you expose the Trust Expressions API to 
Android applications? I don't think the answer matters for the concerns 
that I'm articulating around both risks and effectiveness, but I have a 
slightly morbid**curiosity about how far through you've thought this 
proposal.


This is an important point; most modern root programs including Chrome 
 
and Mozilla  are 
trending towards increased requirements on CAs to become trusted, 
including greater agility among trust anchors. This agility reduces 
the risk of powerful, long-lived keys and allows for faster adoption 
of security improvements, but poses additional pain on subscribers who 
can only deploy one certificate to meet the needs of a set of clients 
that are changing faster than ever before.


Are those requirements truly changing faster than ever before? The vast 
majority of the pain in this space has been caused by the fact that the 
Android Root Store could only be updated by an OTA update from the OEM 
and so was effectively abandonware. I understand that Google finally 
fixed this in Android 14, released October 2023. Meanwhile, downloading 
Firefox yields a modern root store for any Android device released in 
the past 10 years (Android 5 - Lollipop, 2014).


Momentum very much seems to be pointing in the opposite direction to 
what you claim, as the old abandoned devices age out, they're being 
replaced by devices that are much easier to keep up to date. Similarly, 
various countries now have laws on the books requiring a minimum number 
of years of security updates for devices and manufacturer's are 
responding by vastly improving their supported lifetimes. This situation 
improves even further with the coming shift to PQ (described below).


There are indeed costs to fragmentation, but those costs themselves 
provide the pressure against unnecessary fragmentation. We’re not 
aware of any more limited solution that would still meet the 
requirements here. Did you mean the ones in 
https://mailarchive.ietf.org/arch/msg/tls/XXPVFcK6hq3YsdZ5D-PW9g-l8fY/


Looking at these:
- Cross-signing is a broad space. We discuss it briefly in the 
explainer 
, 
but it would need to be more concrete to be a sketch of a solution. 
Was this the option you had in mind?

Cross-signing is well understood.

The easiest case is when an already trusted CA wishes to transition to 
new key material. The CA can cross sign both the new root and the new 
intermediates as Let's Encrypt has for ISRG X1 and ISRG X2 [1]. The main 
drawback is increased certificate chain size. Adopted drafts like 
Abridged Certs [2] completely eliminate it.


The alternative use case is when a new CA wants to launch. Currently, 
it's left to the CA to negotiate with incumbents to obtain a cross 
signed certificate and many do, e.g. Let's Encrypt from IdenTrust [3], 
SSL.com from Certum [4]. If you feel that it should be made even easier, 
an argument I'm sympathetic to, that's an easy policy decision for Root 
Programs to make.


On Thu, May 9, 2024 at 10:40 AM David Benjamin  
wrote:



   Our understanding of your argument is that it will be easier for
   governments to force clients to trust a CA if a sufficient number of
   websites have deployed certificates from that CA. We just don’t
   agree with this assertion and don

[TLS]Re: Kicking off the TLS 1.3 formal analysis triage panel

[Deirdre Connolly]

Hello! We're back with some feedback from our triage panel on 8773bis.
 We had
participation from all members of the panel this time around (🎉).

Some high-level takeaways:

- agreement that more clarity in the document about the intended security
goals is needed
- support for a proper security analysis to shore up the security
arguments: for authentication properties, a Tamarin analysis may do

---

Here is a summary across all participants:

*On changes made by the 8773bis draft to TLS 1.3 and on the draft itself:*

The draft adds an extension to negotiate a handshake using both a PSK and
certificates for authentication. The draft makes specific claims around PQ
confidentiality if the PSK is secret and forward secrecy when the PSK is
destroyed. The claims the draft makes around authentication based on the
PSK aren't clear to me on the first reading and would likely need some
refinement prior to analysis.

I think the draft could be a little more precise in what it's trying to
achieve, which would also help the security arguments.

I agree that the draft could be clearer on what the security goals it's
trying to achieve are.

The language in Section 7 about the assumptions on the PRF is not quite
right:

> This extension provides the desired protection for the session secrets,
as long as HMAC with the selected hash function is a pseudorandom function
(PRF) [GGM1986].

It should actually be assuming the dual PRF security of HMAC, since the TLS
key schedule uses the PSK and other chaining inputs sometimes in the first
input of HMAC, sometimes in the second.

the informal security arguments in some related documents (eg
https://datatracker.ietf.org/doc/html/rfc9257,
https://www.rfc-editor.org/rfc/rfc9258.html ) seem much better worked out.

More clarity about the exact claimed additional security is required.

I found the RFC unclear on how the extension should be used in subsequent
sessions. They wrote: "Since the "tls_cert_with_extern_psk" extension is
intended to be used only with initial handshakes,…”. So let’s say you use
the extension in a first session with an external PSK + cert. Must the PSK
generated from that session ticket be used in subsequent sessions with
their extension , i.e. cert + psk, or can it go back to “normal mode”, i.e.
psk only without cert? I’m not sure how this behaves specially w.r.t. to
their goal of being safe against CRQC.

*Does the draft invalidate the previous security analyses?*

Yes. Although the draft has an informal sketch that it doesn't make the key
derivation in a particular handshake 'worse', this doesn't immediately rule
out any awkward cross-handshake interactions.

This is a reasonable extension to TLS 1.3 and can be done in a way that
does not affect the existing security guarantees of the protocol. I am
curious whether using such a PSK breaks the privacy guarantees of ECH, and
whether those two extensions are compatible.

The extension's "security argument" in the extension's text is invalid: it
is not obvious that this extension only improves security. I don't
immediately see how it would degrade base TLS security, though a proper
analysis would make me more confident; I'd be wondering how the "context"
of this particular mode is clearly separate from (preventing message
confusion), and carried through (transcript/state towards e.g.
resumption/post-handshake authentication), w.r.t. other modes. It could
well be that in the presence of an active attacker, the new mode doesn't
offer *additional* security because of its interaction with similar modes.
In such a case, the extension would offer little benefit.

*Does the change merit an updated analysis?*

I think so. Although I like to think the TLS1.3 key derivation is pretty
robust, it's hard to think through the various types of handshake and how
they could be composed by an attacker - especially when the PSK might be
used in multiple modes by multiple parties.

The main question to ask, other than whether this extension breaks prior
analyses, is what are the new guarantees it provides: that will indeed
require new analysis.

I see much more need for analysis when it comes to the authentication
properties of the PSK (psk/cert combination), whereas the secrecy (assuming
authentication is a non-goal) is much more straightforward.

I agree with the above.

I'd delineate between confidentiality and authentication, and then be clear
about to what extent hybrid security is being expected:

- For confidentiality: I guess hybrid confidentiality is desired, meaning
that session keys are secure if either the external PSK is unbroken, or
ECDH is unbroken (and if the ephemeral key exchange is actually hybrid
traditional+PQ, then it's actually a 3-way hybrid)

- For authentication: Is there a desire for a hybrid authentication
property based on the external PSK?  Or is one only relying on the public
key certificate 

[TLS]Re: HTTPS-RR and TLS

[Stephen Farrell]

Hiya,

On 09/05/2024 00:01, David Benjamin wrote:

Actually, I think one thing that could help is one of your drafts! One

barrier with trying to use HTTPS RR for TLS problems is keeping the DNS and
TLS sides in sync on the server deployment. Prior to ECH, this hasn't been
done before, so I wouldn't expect any deployments to have a robust path
from their TLS configuration to their DNS records.


draft-ietf-tls-wkech seems like a good model for this, but it is

currently written specifically for ECH. What are your thoughts on
generalizing that document to cover other cases as well?

https://github.com/sftcd/wkesni/issues/14


Thanks for making that GH issue. I'm fine with discussing
details there, and have no problem if the draft is more useful
if it's more generic, but have a question for the broader group
that may be better asked here:

What HTTPS RR parameters do we expect will see regular changes,
and controlled by whom?

It seems fairly clear that ECHConfig values will be changed
often, e.g. hourly, which I think motivates the wkech thing,
but I'm unclear how often other bits of HTTPS RRs might
change and who may be in charge of those in real deployments.

My mental picture is something like:

what, changes how often, controlled by whom
ech, maybe hourly, client-facing server admin
alpn, rarely, client-facing server admin
tls-supported-groups, rarely, client-facing server admin
ipXhints, unpredictable, DNS admin?

Does that look kinda right? Are there other things to
consider now?

Ta,
S.





OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org