[TLS] ECH-13 HRR Signal Derivation

I have two questions about the transcript for the confirmation signal for HelloRetryRequests in ECH Draft 13: 1. Should ClientHelloInner1 be replaced with a message_hash message as in TLS? 2. Is th

Re: [TLS] Securely disabling ECH

You and "SB" are in agreement. There is a middlebox terminating the TLS connection with a cert chain signed by a root which is also installed on the client. The middlebox in turn is connecting to a TLS Server whose cert chains back to a webpki root. The middlebox is handling the termination and

Re: [TLS] TLS client fingerprinting

Anecdotally, I'm aware of similar reports where TLS fingerprinting is used as part of anti-bot efforts and various projects try to work around it, e.g. curl-impersonate . David Benjamin and I spoke about this at IETF 115 and felt that randomizing t

Re: [TLS] CRYSTALS Kyber and TLS

If you have access to an uncompromised signing key, you can fix a compromised CSRNG generically without having to change the protocol. [1] Best, Dennis [1] https://datatracker.ietf.org/doc/html/rfc8937 On 19/06/2023 16:41, Bas Westerbaan wrote: I do have to add to Thom's remarks that KEMTLS (a

[TLS] Abridged Certificate Compression

la operates the Common CA Database on behalf of Apple, Microsoft, Google and other members. On 06/07/2023 23:11, internet-dra...@ietf.org wrote: A new version of I-D, draft-jackson-tls-cert-abridge-00.txt has been successfully submitted by Dennis Jackson and posted to the IETF repository. Name

Re: [TLS] Abridged Certificate Compression

On 07/07/2023 17:42, Salz, Rich wrote: I would love to get feedback from the working group on whether the draft is worth developing further. I read your document [1] and found it very interesting. Thanks Rich! I found the handling of extensions complicated, although I admit to reading tha

Re: [TLS] Abridged Certificate Compression

bPKI clients without having to write a lot of emails. I agree its not desirable to keep as a dependency in the long run. S 5.1. ISTM that there are plenty of code points available. Thanks! Best, Dennis On Thu, Jul 6, 2023 at 3:18 PM Dennis Jackson wrote: Hi all, I

Re: [TLS] Abridged Certificate Compression

com/dennisjackson/e1dccfef104cabc1e4151c47338bc9b2 [MTC] https://davidben.github.io/merkle-tree-certs/draft-davidben-tls-merkle-tree-certs.html -Original Message- From: TLS On Behalf Of Dennis Jackson Sent: Thursday, July 6, 2023 6:18 PM To: TLS List Subject: [EXTERNAL] [TLS] Abridged Certif

Re: [TLS] Abridged Certificate Compression

Thanks, -Ekr S 5.1. ISTM that there are plenty of code points available. Thanks! Best, Dennis On Thu, Jul 6, 2023 at 3:18 PM Dennis Jackson wrote: Hi all, I've submitted the draft below that describes a new TLS certificate

Re: [TLS] Abridged Certificate Compression

On 11/07/2023 01:00, Eric Rescorla wrote: My sense is that we would be better off getting the data from CCADB, as CAs will have a clear incentive to populate it, as their customers will get better performance. However, I think this is a question the WG is well suited to resolve and that we c

Re: [TLS] Abridged Certificate Compression

On 11/07/2023 15:48, Thom Wiggers wrote: I enjoyed reading this draft. I think it is well-written. Aside from some to-be-figured-out details that have already been pointed out, it seems very practical, which is rather nice. Thanks! The one thing that makes me frown a bit is the intended vers

Re: [TLS] Abridged Certificate Compression

Hi Ilari, On 10/07/2023 20:19, Ilari Liusvaara wrote: What does "Note that the connection will fail regardless even if this step is not taken as neither certificate validation nor transcript validation can succeed." mean? TLS certificate compression does not do anything special with transcript,

Re: [TLS] Abridged Certificate Compression

On 11/07/2023 21:17, Eric Rescorla wrote: I wouldn't want to 'permanently' encode the root programs, CT trusted log lists or end entity compressed extensions for example. Arguably it will be necessary to encode the database in the final RFC. Otherwise, you have what is effectively a normative

Re: [TLS] Abridged Certificate Compression

On 12/07/2023 11:01, Ilari Liusvaara wrote: On Tue, Jul 11, 2023 at 09:37:19PM +0100, Dennis Jackson wrote: TLS Certificate Compression influences the transcript for the decompressing party, as the output is the Certificate message which is used in the transcript. RFC 8879 does not alter how

Re: [TLS] Abridged Certificate Compression

On 12/07/2023 04:34, Kampanakis, Panos wrote: Thanks Dennis. Your answers make sense. Digging a little deeper on the benefit of compressing (a la Abridged Certs draft) the leaf cert or not. Definitely this draft improves vs plain certificate compression, but I am trying to see if it is worth

Re: [TLS] Abridged Certificate Compression (dictionary versioning)

On 12/07/2023 04:54, Kampanakis, Panos wrote: Hi Dennis, Appendix B.1 talks about 100-200 new ICA and 10 Root certs per year. In the past I had looked at fluctuations of CCADB and there are daily changes. When checking in the past, I did not generate the ordered list as per pass 1 on a daily

Re: [TLS] Abridged Certificate Compression (server participation)

On 12/07/2023 05:02, Kampanakis, Panos wrote: The abridged certs draft requires a server who participates and fetches dictionaries in order to make client connections faster. As Bas has pointed out before, this paradigm did not work well with OSCP staples in the past. Servers did not chose to

Re: [TLS] Abridged Certificate Compression

sical cert chains - in some cases fitting the entirety of the server's response in one packet - I agree we should measure carefully before deciding whether it be mandatory for PQ certs. Best, Dennis -Original Message----- From: Dennis Jackson Sent: Wednesday, July 12, 2

Re: [TLS] Abridged Certificate Compression

cluding the tag and length octets). *From:* TLS on behalf of Tim Hollebeek *Sent:* 12 July 2023 19:29 *To:* Kampanakis, Panos ; Dennis Jackson ; TLS List *Subject:* Re: [TLS] Abridged Certificate Compression CAUTION:

Re: [TLS] Abridged Certificate Compression (dictionary versioning)

On 13/07/2023 02:31, Kampanakis, Panos wrote: Btw, in 3.1.1 I noticed - "Remove all intermediate certificates which are not signed by root certificates still in the listing." That could eliminate some 2+ ICA cert chains. Any reason why? Whoops, that's a good spot. The intent here was just to r

Re: [TLS] RFC7924 (Cached Information Extension) Update for TLS 1.3

Hi Simon, Can you expand more on the intended use case? When would it make sense to use a RFC7924-like mechanism over TLS 1.3's session resumption? I skimmed RFC 7924 and session resumption seems strictly better as it's already widely deployed, allows for the DH handshake to be optionally el

Re: [TLS] RFC7924 (Cached Information Extension) Update for TLS 1.3

Hi Simon, On 15/08/2023 03:41, Simon Mangel wrote: We believe it to be useful in cases where the network bandwidth is severely restricted, such that one would want to keep the number of "full" handshakes as small as possible. Session resumption ticket lifetimes are limited to 7 days in TLS 1.3

Re: [TLS] Encrypted Client Hello - SNI leaks via public name?

Hi Raghu, On 06/10/2023 10:45, Raghu Saxena wrote: Specifically, I am concerned about the "public name" field in the ECHConfig. For services such as cloudflare, they can "hide" everything behind a single domain (e.g. "cloudflare-ech.com"). However, for someone who just owns a single domain (e.

Re: [TLS] FW: [EXTERNAL] New Version Notification for draft-ounsworth-lamps-pq-external-pubkeys-00.txt

Hi Mike, On 30/09/2023 23:19, Mike Ounsworth wrote: Consider the following two potential use-cases: 1. Browsers Browsers already have mechanisms to cache intermediate CA certificates. It does not seem like a big leap to also cache external public keys for the server certs of frequently-vis

Re: [TLS] [EXTERNAL] New Version Notification for draft-ounsworth-lamps-pq-external-pubkeys-00.txt

On 10/10/2023 17:53, Russ Housley wrote: Dennis: If we are going to allow a certificate to include pointers to externally stored public keys, I think a solution that works for the Web PKI and other PKI environment as well. I'm trying to understand the use case of certificates with pointers

Re: [TLS] ECH: What changed?

Hi Rich, During 117, both Firefox and Chrome were just starting to roll out ECH to release users and we had no sense of how it would go and I at least didn't feel we should progress without some deployment experience. These roll outs finished a few weeks later, see e.g [1,2] and went fairly s

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

I support adoption, and am happy to review. Best, Dennis On 06/12/2023 12:50, Salz, Rich wrote: At the TLS meeting at IETF 118 there was significant support for the draft 'TLS 1.2 is in Feature Freeze' (https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

RFC 8773 S3: > In the near term, this document describes a TLS 1.3 extension to protect today's communications from the future invention of a large-scale quantum computer by providing a strong external PSK as an input to the TLS 1.3 key schedule while preserving the authentication provided by

Re: [TLS] Key Update for TLS/DTLS 1.3

From a security perspective, this would be equivalent to having the client open a new connection to the server using a session ticket from the existing connection with psk_dhe_ke mode? I guess the ergonomics of that approach perhaps aren't as neat, but it would only require client side impleme

Re: [TLS] I-D Action: draft-ietf-tls-cert-abridge-00.txt

Hi Ilari, Thank you for the quick review. I've been integrating all of the editorial feedback in the draft (separate mail to follow to the group). Regarding your feedback: On 06/09/2023 17:46, Ilari Liusvaara wrote: Doing quick review: Section 3.1.2: - It is not clear what exactly is repla

[TLS] draft-ietf-tls-cert-abridge Update

Hi all, I wanted to give a quick update on the draft. On the implementation side, we have now landed support for TLS Certificate Compression in Firefox Nightly which was a prerequisite for experimenting with this scheme (thank you to Anna Weine). We're working on a rust crate implementing the

Re: [TLS] I-D Action: draft-ietf-tls-cert-abridge-00.txt

Hey Ilari, I think you are still misunderstanding the scheme. To clarify: On 01/03/2024 18:01, Ilari Liusvaara wrote: The unrecognized identifier issue is a bit more subtle. Suppose that a client: - Has only partial list of certificates (enough to cover the built-in trust store). - Allows a

Re: [TLS] draft-ietf-tls-cert-abridge Update

e to compress just the cert chain or the end-certificate depending on their ability to perform Pass 1 or 2 respectively. Client MUST be able to process a compressed chain or an end-entity certificate independently./ Thanks, Panos *From:* TLS *On Behalf Of * Dennis Jackson *Sent:* Friday, Ma

Re: [TLS] draft-ietf-tls-cert-abridge Update

message, I was suggesting either have it be a single label for the entire message or putting the label into the TLS1.3 Cert Compression codepoint. Best, Dennis *From:* Dennis Jackson *Sent:* Monday, March 4, 2024 10:47 AM *To:* Kampanakis, Panos ; TLS List *Subject:* RE: [EXTERNAL] [TLS] d

Re: [TLS] ML-KEM key agreement for TLS 1.3

I'd like to understand the argument for why a transition back to single schemes would be desirable. Having hybrids be the new standard seems to be a nice win for security and pretty much negligible costs in terms of performance, complexity and bandwidth (over single PQ schemes). On 07/03/202

Re: [TLS] ML-KEM key agreement for TLS 1.3

RSA the door much more quickly [1]. Best, Dennis * As in, actual security from combination of independent systems, not the mostly useless kind from using over-size primitives. [1] https://blog.cloudflare.com/how-expensive-is-crypto-anyway Best,  Bas On Thu, Mar 7, 2024 at 1:56 AM Dennis J

Re: [TLS] Working Group Last Call for ECH

+1 to shipping it. On 11/03/2024 22:00, Joseph Salowey wrote: This is the working group last call for TLS Encrypted Client Hello [1].  Please indicate if you think the draft is ready to progress to the IESG and send any comments to the list by 31 March 2024.  The comments sent by Watson Ladd t

Re: [TLS] ML-KEM key agreement for TLS 1.3

On 14/03/2024 01:41, Deirdre Connolly wrote: Oh and one more consideration: hybrid brings complexity, and presenting the pure-PQ solutions and their strictly lesser complexity (at the tradeoff of maybe taking more risk against newer schemes no matter how good we feel about their fundamental cr

Re: [TLS] Working Group Last Call for SSLKEYLOG File

I have a suggestion which keeps things technical but hopefully addresses Stephen's concern: In Security Considerations: "TLS1.3 requires the use of forward secret key exchanges (RFC 8446, 1.2, E.1). Using SSLKEYLOGFILE breaks this security property as it records the used session key and so in

Re: [TLS] I-D Action: draft-ietf-tls-cert-abridge-01.txt

a work item of the Transport Layer Security (TLS) WG of the IETF. Title: Abridged Compression for WebPKI Certificates Author: Dennis Jackson Name:draft-ietf-tls-cert-abridge-01.txt Pages: 21 Dates: 2024-03-16 Abstract: This draft defines a new TLS Certificate

Re: [TLS] TLS Impact on Network Security draft updated

RFC 791 is nearly 40 years old. RFC 4074 lists 5 forms of deviations from RFC 1034 and explains the correct behavior. RFC 7021 describes a series of objective tests of RFC 6333 and the results. The above RFCs describe objective test results and how they relate to earlier RFCs. In contrast,

Re: [TLS] TLS Impact on Network Security draft updated

ptography vihv vivc ce xhrnrw, however, the only thing that > can not be unscrambled is an egg." Best, Dennis >> On Jul 23, 2019, at 7:44 PM, Dennis Jackson >> mailto:dennis.jack...@cs.ox.ac.uk>> wrote: >> >> RFC 791 is nearly 40 years old. >> RFC 4074

Re: [TLS] TLS Impact on Network Security draft updated

On 24/07/2019 04:13, Benjamin Kaduk wrote: > On Wed, Jul 24, 2019 at 03:35:43AM +0100, Dennis Jackson wrote: >> On 24/07/2019 02:55, Bret Jordan wrote: >>> As a professional organization and part of due diligence, we need to try >>> and understand the risks and ramif

[TLS] Feedback on draft-tschofenig-tls-extended-key-update-01

A new version of this draft was published a few weeks ago with an entirely new design. Unless I missed it, the new version hasn't yet been discussed on the TLS list and I was unaware of the changes until I came to prepare for the meeting. I have quite a few concerns - I'm sorry to bring them up

Re: [TLS] TLS 1.3, Raw Public Keys, and Misbinding Attacks

Hi John, It depends what you mean by an identity. TLS1.3 ensures the peers agree on the used RPKs and it doesn't rely on any external proof of possession to achieve that property. How the peers come to trust the RPKs or their corresponding identity is of necessity left to the application - n

Re: [TLS] Adoption call for TLS Flag - Request mTLS

Hi Jonathan, My reading of RFC 7250 is the same as Mohits. Although the RFC talks about raw public keys and a new codepoint for them, it is building on RFC 6091 which defined a similar extension and the X509 codepoint. It seems fine for you to send the client_certificate_type extension with

Re: [TLS] Adoption call for TLS Flag - Request mTLS

no remaining certificate types to send in the client hello, other than the default X.509 type, it MUST omit the client_certificate_type extension in the client hello. That seems to explicitly exclude sending the single entry 0 to me. Regards, Jonathan On Thu, 4 Apr 2024, 16:43 Dennis

Re: [TLS] WG Adoption for TLS Trust Expressions

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

Re: [TLS] WG Adoption for TLS Trust Expressions

AHda5CocQ4dUDCBA&uact=5&oq=site%3Ablogs.microsoft.com+eidas&gs_lp=Egxnd3Mtd2l6LXNlcnAiHnNpdGU6YmxvZ3MubWljcm9zb2Z0LmNvbSBlaWRhc0ihE1DECljZEXABeACQAQCYAYMBoAHhA6oBAzUuMbgBA8gBAPgBAZgCAKACAJgDAIgGAZIHAKAHjgI&sclient=gws-wiz-serp>. 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 large

Re: [TLS] WG Adoption for TLS Trust Expressions

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 w

Re: [TLS] WG Adoption for TLS Trust Expressions

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 i

Re: [TLS] WG Adoption for TLS Trust Expressions

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 Tr

Re: [TLS] WG Adoption for TLS Trust Expressions

e and you've yet to identify an feature that Trust Expressions actually delivers that isn't already available through simpler, already deployed, means. On Tue, Apr 30, 2024 at 8:38 AM Dennis Jackson wrote: As mentioned above, we have such an extension already insofar as indi

Re: [TLS] WG Adoption for TLS Trust Expressions

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

Re: [TLS] Adoption Call for draft-davidben-tls-key-share-prediction

This looks great. I support adoption and am happy to implement & review. On May 3, 2024 10:05:01 PM UTC, Joseph Salowey wrote: >This is a working group call for adoption >for draft-davidben-tls-key-share-prediction. This document was presented >at IET 118 and has undergone some revision based o

Re: [TLS] WG Adoption for TLS Trust Expressions

Hi David, Devon, Bob, I feel much of your response talks past the issue that was raised at IETF 118. The question we're evaluating is NOT "If we were in a very unhappy world where governments controlled root certificates on client devices and used them for mass surveillance, does Trust Expre

[TLS]Re: WG Adoption for TLS Trust Expressions

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

[TLS]Re: WG Adoption for TLS Trust Expressions

Hi Nick, On 21/05/2024 19:05, Nick Harper wrote: [...] Perhaps there are additional ways to use Trust Expressions to censor the web that are more practical and more useful than the existing techniques that I didn't consider. There are most certainly other forms of domestic control of the Web

[TLS]Re: WG Adoption for TLS Trust Expressions

lready discussed. Trust Expressions does not, it relies either on CAs doing the legwork to keep these things working (as they already do today) or website operators to do a complex dance with multiple CAs and fingerprinting (as they already do today). On Tue, May 21, 2024 at 3:00 PM Dennis Jackson

[TLS]Re: WG Adoption for TLS Trust Expressions

Hi David, On 23/05/2024 14:07, David Adrian wrote: There is certainly a discussion to be had about how well Trust Expressions solves problems experienced by the HTTPS ecosystem and the Web PKI today. However, that requires moving past repeated, unsubstantiated claims about how Trust Expression

[TLS]Re: WG Adoption for TLS Trust Expressions

On 23/05/2024 17:41, David Benjamin wrote: On Thu, May 23, 2024 at 11:09 AM Dennis Jackson wrote This is something that I believe David Benjamin and the other draft authors, and I all agree on. You and Nick seem to have misunderstood either the argument or the draft. David

[TLS]Re: WG Adoption for TLS Trust Expressions

Hi Ryan, On 23/05/2024 19:01, Ryan Hurst wrote: Regarding the concern about government-mandated adoption of root certificates, I also care deeply about this issue. This is why I am disappointed by the one-sided nature of the conversation. I see no mechanism in this proposal that bypasses opera

[TLS]Transitioning to PQC Certificates & Trust Expressions

One of the key use cases proposed for Trust Expressions is enabling a speedy deployment of PQC Certificates. I agree this is an important use case to address, but I think a closer inspection of the existing deployment options shows that Trust Expressions does not provide any improvement or new

[TLS]Re: Transitioning to PQC Certificates & Trust Expressions

an Hurst On Mon, May 27, 2024 at 2:31 AM Dennis Jackson wrote: One of the key use cases proposed for Trust Expressions is enabling a speedy deployment of PQC Certificates. I agree this is an important use case to address, but I think a closer inspection of the existing deplo

[TLS]Re: Transitioning to PQC Certificates & Trust Expressions

ignature on a PQ root or intermediate doesn't change security for anybody, it only improves availability. Best, Dennis On Mon, May 27, 2024 at 9:51 AM Dennis Jackson wrote: Hi Ryan, On 27/05/2024 16:39, Ryan Hurst wrote: [...] Moreover, there's the lia

[TLS]Re: Transitioning to PQC Certificates & Trust Expressions

ot the chains we make :-). Best, Dennis Ryan On Mon, May 27, 2024 at 11:15 AM Dennis Jackson wrote: Hi Ryan, I wonder if the IETF mail servers are having a bad day again. I only see your reply to me, no other messages and currently the archives are only showing my initial e

[TLS]Re: Curve-popularity data?

On 02/06/2024 22:02, Filippo Valsorda wrote: Third, we learned to make key shares always ephemeral which makes invalid curve attacks irrelevant. Although using ephemeral keys does effectively prevent key recovery through invalid points, you can still use invalid points to perform confinement

[TLS]Re: Curve-popularity data?

On 03/06/2024 17:25, D. J. Bernstein wrote: I'm still puzzled as to what led to the statement that I quoted at the beginning: P 256 is the most popular curve in the world besides the bitcoin curve. And I don’t have head to head numbers, and the bitcoin curve is SEC P, but P 256 is m

[TLS]Re: Curve-popularity data?

Hi Peter, Mike Peter Gutmann wrote: Just because it's possible to rules-lawyer your way around something doesn't make it valid (I also see nothing in the spec saying a TLS 1.3 implementation can't reformat your hard drive, for example, so presumably that's OK too). The point is that P256 is a M

[TLS]Re: Curve-popularity data?

On 08/06/2024 11:07, Peter Gutmann wrote: when the dominant platform only offers 25519 then the the only option you have (unless you want to do the HRR dance) is to select that, whether you want it or not. The recently adopted Key Share Prediction draft [1] allows servers to signal which key

[TLS]Re: TLS trust expressions and certificate_authorities

Hi Devon, I'm a bit disappointed in how you've characterized the earlier discussion, but I appreciate the attempt to move the conversation on to new technical ground. I previously started a thread on the problems with the proposed uses of Trust Expressions for PQC-transition [1] in a similar

[TLS]Re: Transitioning to PQC Certificates & Trust Expressions

Hi Watson, Ilari, Watson wrote: Wait, I don't think the example's quite right (or maybe I'm just confused). How can two intermediates sign the "same" leaf? Or is the idea that we have L1' and L1 X509 Certificates with the same public key presented in the chain but signed by different intermedia

[TLS]Re: TLS trust expressions and certificate_authorities

On 12/06/2024 02:36, Nick Harper wrote: If Trust Expressions does meaningfully change the calculus compared to certificate_authorities, it does it in a way that lessens risk. The certificate_authorities extension doesn't scale support the legitimate use case of trust negotiation/advertisement

[TLS]Re: TLS trust expressions and certificate_authorities

On 11/06/2024 02:24, Devon O'Brien wrote: 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. [...] There is no fundamental c

[TLS]Re: Trust Expressions Update

On 29/06/2024 00:14, David Benjamin wrote: We have published a second, related draft, TLS Trust Anchor Identifiers. This draft outlines a separate mechanism we had considered during the design of TLS Trust Expressions, and is intended to solve many of the same problems that Trust Expressions d

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

On 20/07/2024 11:23, David Benjamin wrote: On Sat, Jul 20, 2024, 06:13 Mike Shaver wrote: In what way are these non-web systems not allowed to use other PKI models today? How would trust anchors provide that permission? If the same server serves both embedded/IoT traffic and web bro

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

On 22/07/2024 09:57, Mike Shaver wrote: I’m not informed enough to comment on the protocol elements of the specific Trust Anchor proposal, but I agree that more PKI agility will be healthy. Fundamentally, the TLS implementation community will be pushing this agility into endpoints by default

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

On 22/07/2024 11:00, Mike Shaver wrote: I’m not informed enough to comment on the protocol elements of the specific Trust Anchor proposal, but I agree that more PKI agility will be healthy. [...] Trust Anchor negotiation will require configuration of both sides, but so does cipher negotiati

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

On 22/07/2024 12:28, Ilari Liusvaara wrote: I don't see TE requiring breaking API changes on client: API that lets one add a set of (pseudo) trust anchors plus TE advertisement for those should work? I agree adding a new API for T.E. which applications could opt in to would be fine. But could

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

On 22/07/2024 16:06, Salz, Rich wrote: I agree adding a new API for T.E. which applications could opt in to would be fine. But could T.E. ever be enabled by default without breaking the existing API and requiring application changes? Yes it could. For example, you’d have to add meta-data iden

[TLS]Re: Trust Expressions Update

On 21/07/2024 18:09, Kyle Nekritz wrote: Do you see differences with trust negotiation, or in the specific negotiation mechanisms that are being proposed? Or would you have similar concerns if, say, we didn't already have named group negotiation, and were discussing adding that right now? M

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

I don't think its possible to go one API / method at a time. If we want to turn on a feature by default, it has to either be non-backwards compatible or not break any existing API. This is a problem for Trust Expressions because exposing the TLS certificate to the application is a major part o

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

On 23/07/2024 11:08, Watson Ladd wrote: Applications that don't support aren't worse off because other applications can use a newer PKI with fewer problems. The sub-thread Mike started has been specifically on whether we can bring Trust Expressions to non-browser applications by default. I do

[TLS]Discussions on Trust Anchor Negotiation at IETF 120

There has been a lot of discussion over the past few days, both in person and on the mailing list. I want to share some thoughts on those discussions before the meeting tomorrow. My impression is that there is little consensus on which problems we want to solve as a WG. Resolving this is criti

[TLS]Re: Discussions on Trust Anchor Negotiation at IETF 120

40-tls/topic/ietf-120/near/128259 -Original Message- From: Dennis Jackson Sent: Tuesday, July 23, 2024 9:51 PM To: TLS List Subject: [TLS]Discussions on Trust Anchor Negotiation at IETF 120 There has been a lot of discussion over the past few days, both in person and on the ma

[TLS]Re: Discussions on Trust Anchor Negotiation at IETF 120

On 26/07/2024 15:24, Sophie Schmieg wrote: I don't think trust anchor negotiation needs a lot more discussion, over what has happened already. All in all, I think it's a good mechanism that is fairly well defined and it's not clear to me how it would benefit from an interim. The Trust Anchor

[TLS]Re: Discussions on Trust Anchor Negotiation at IETF 120

On 26/07/2024 15:24, Sophie Schmieg wrote: I don't think trust anchor negotiation needs a lot more discussion, over what has happened already. All in all, I think it's a good mechanism that is fairly well defined and it's not clear to me how it would benefit from an interim. The Trust Anchor

[TLS]Re: Discussions on Trust Anchor Negotiation at IETF 120

On 26/07/2024 15:24, Sophie Schmieg wrote: I don't think trust anchor negotiation needs a lot more discussion, over what has happened already. All in all, I think it's a good mechanism that is fairly well defined and it's not clear to me how it would benefit from an interim. The Trust Anchor

[TLS] Re: Trust Anchor IDs and PQ

On 01/02/2025 18:00, Eric Rescorla wrote: 2. It allows clients to safely force the server to offer a PQ chain    even if the client actually is type (3). Normally it wouldn't be    safe to only advertise PQ algorithms in signature_algorithms, but    if the server advertises a PQ TA, then the cli

[TLS] Re: Adoption Call for Trust Anchor IDs

It will not come as a surprise that I oppose adoption for the reasons laid out in 'Trust is non-negotiable' [1]. The claims that Trust Negotiation can improve security or compatibility just do not stand up to scrutiny. Especially as in over a year since first introduction, there has been no cr

[TLS] Re: Trust Anchor IDs and PQ

On 04/02/2025 14:10, Bas Westerbaan wrote: I just sketched one with a signal in the certificate. You point out some valid deployment challenges, but they're far from disqualifying the approach from the start, and we should give the general direction a chance. Always worth exploring new directi

[TLS] Re: PKI dynamics and trust anchor negotiation

I don't think there's any new argument to address, so I will just offer a pointers into where these issues are discussed in 'Trust is non-negotiable'. Section 3.3 [1] looks at how trust negotiation (as an abstract mechanism) changes incentives to divergence for existing root programs, as well

[TLS] Re: Changing WG Mail List Reputation

On 14/01/2025 18:48, Filippo Valsorda wrote: Two participants sending a dozen emails in support of solution A, and six participants sending one email each in support of solution B can look a lot like there is no consensus, or that there is consensus for solution A, especially if not all object