[TLS] ECH-13 HRR Signal Derivation

[Dennis Jackson]

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 the entire HelloRetryRequest (with overwritten placeholder value) 
included in the transcript or is the HRR only included up to the end of 
the placeholder value?


I had assumed 1. yes and 2. the entire HRR, but an off-list conversation 
left me unsure.


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

Re: [TLS] Securely disabling ECH

[Dennis Jackson]

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-encryption of the client's traffic.


In any case, SB's question was about whether this would trigger the ECH 
retry behavior (yes, since it appears to the client as though the 
middlebox is the server) and whether at least one client already 
implemented it (yes, Firefox).


Best,
Dennis

On 10/10/2022 14:04, Salz, Rich wrote:


  * In other words, the middlebox serves a cert to the client that is
cryptographically valid for the said public name of the client
facing server.

The only way that happens is if the middlebox **terminates the TLS 
connection**  In this case it is like my client<>cdn<>origin picture.  
The middlebox cannot present a certificate and then hand-off a 
connection to the server.


I must not be getting something important to you.


___
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] TLS client fingerprinting

[Dennis Jackson]

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 the order of client hello extensions (subject to the PSK 
coming last) was a natural solution. Compared to a fixed order, this 
ensures lazy middleboxes don't assume a particular extension is always 
in the same position and so cause breakage in a future version.


Chrome 110 releases to stable next week and has TLS Client Hello 
Extension Permutation 
 enabled by default. 
We have a patch  
ready to go for this in Firefox as well, which we plan to land in the 
coming months.


There are still plenty of other fingerprinting vectors which this won't 
address of course, but it is one step along the way.


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

Re: [TLS] CRYSTALS Kyber and TLS

[Dennis Jackson]

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.k.a. AuthKEM) offers 
an advantage here. If the private key of the leaf cert is not 
compromised (for instance when it was generated elsewhere), then the 
attacker Stephan describes cannot learn the shared secret.



On Mon, Jun 19, 2023 at 5:02 PM Thom Wiggers  wrote:

Hi all,

The attack that is described by Stephan is something that we
considered while we were initially designing KEMTLS (in the
papers, we also covered the ephemeral key exchange). I'll quickly
write what we were thinking of and why we did not choose to do
anything similar to what Stephan proposes.

I will be correcting for the misunderstanding in the document put
forward by Stephan, which suggests that Kyber is an asymmetric
encryption scheme. Encapsulation and Decapsulation should not be
confused with encryption and decryption, which are not part of the
public API of Kyber and will not be part of the NIST standard as
far as I'm aware.

I believe we can summarize the argument as follows: in the
straightforward replacement of ECDH by a KEM, the client generates
a keypair and the server (through the encapsulate operation)
computes a shared secret and a ciphertext. If either the secret
key or the shared secret are made public, for example, due to an
implementation flaw of either keygen or encapsulation, then the
ephemeral handshake key is no longer secret.

Bas correctly points out that this is not different from ECDH,
where compromise of one of the two exponents leads to shared
secret computation, but that in itself shouldn't necessarily be a
reason not to investigate if we can do better.

But, in my view, the proposed defense and the argument put forward
assumes that the flaw that affects encapsulation does not affect
the key generation (or vice versa); in particular, in the scenario
of the broken server-side random number generator it seems
far-fetched that the busted random number generator or
implementation flaw affecting encapsulation won't *also* affect
the keygen (or in other scenarios such as side-channel
vulnerabilities, decapsulate) operation of the server. This, in my
view, makes the additional security offered by the additional key
exchange very marginal.

The reason why we were investigating this issue was a bit
different: having two KEM key exchanges gives the server more
control to ensure that there will be at least one
freshly-generated KEM keypair in the mix. This could improve the
forward secrecy for handshakes (modeled via secret key exposure)
in which the client just re-uses the ephemeral keypair every
single time. But we also saw this as not significant enough to
suffer the additional, significant transmission requirement of
another full Kyber key exchange. Hopefully, we now have enough
experience with evaluating implementations of TLS to find and fix
these sorts of key-reuse flaws more easily, earlier, and in
automated ways [1]. And again, this is the same situation with
ECDH today.

Cheers,

Thom Wiggers
PQShield

[1] see e.g. https://github.com/tls-attacker/TLS-Scanner. Relying
on implementers not to make mistakes is a dangerous game, but I do
believe that it needs to factor into the cost/benefit analysis.

PS: for marketing reasons I oppose comparisons between the
post-quantum KEM schemes (which are primitives that easily can be
used in fully ephemeral ways) and RSA key wrapping (which pretty
much exclusively refers to the much-derided non-forward-secure RSA
transport in TLS-old). ;-)

Op ma 19 jun 2023 om 16:01 schreef Stephan Mueller
:

Am Montag, 19. Juni 2023, 15:56:57 CEST schrieb Scott Fluhrer
(sfluhrer):

Hi Scott,

> I do not believe that Müller is correct - we do not intend
use the Kyber CPA
> public key encryption interface, but instead the Kyber CCA
KEM interface.
> And, with that interface, the server does contribute to the
shared secret:
>
> The shared secret that Kyber KEM (round 3) generates on
success is:
>
> KDF( G( m || H(pk)) || H(c) )
>
> where:
>       - m is the hash of a value that the server selects
>       - pk is the public key selected by the client
>       - c is the server's keyshare
>       - H is SHA3-256, G is SHA3-512, KDF - SHAKE-256
> Note that this formula includes a value (pk) that is
selected solely by the
> client; hence we cannot say that this value contains only
  

[TLS] Abridged Certificate Compression

[Dennis Jackson]

Hi all,

I've submitted the draft below that describes a new TLS certificate 
compression scheme that I'm calling 'Abridged Certs' for now. The aim is 
to deliver excellent compression for existing classical certificate 
chains and smooth the transition to PQ certificate chains by eliminating 
the root and intermediate certificates from the bytes on the wire. It 
uses a shared dictionary constructed from the CA certificates listed in 
the CCADB [1] and the associated extensions used in end entity 
certificates.


Abridged Certs compresses the median certificate chain from ~4000 to 
~1000 bytes based on a sample from the Tranco Top 100k. This beats 
traditional TLS certificate compression which produces a median of ~3200 
bytes when used alone and ~1400 bytes when combined with the outright 
removal of CA certificates from the certificate chain. The draft 
includes a more detailed evaluation.


There were a few other key considerations. This draft doesn't impact 
trust decisions, require trust in the certificates in the shared 
dictionary or involve extra error handling. Nor does the draft favor 
popular CAs or websites due to the construction of the shared 
dictionary. Finally, most browsers already ship with a complete list of 
trusted intermediate and root certificates that this draft reuses to 
reduce the client storage footprint to a few kilobytes.


I would love to get feedback from the working group on whether the draft 
is worth developing further.


For those interested, a few issues are tagged DISCUSS in the body of the 
draft, including arrangements for deploying new versions with updated 
dictionaries and the tradeoff between equitable CA treatment and the 
disk space required on servers (currently 3MB).


Best,
Dennis

[1] Mozilla 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:   draft-jackson-tls-cert-abridge
Revision:   00
Title:  Abridged Compression for WebPKI Certificates
Document date:  2023-07-06
Group:  Individual Submission
Pages:  19
URL:
https://www.ietf.org/archive/id/draft-jackson-tls-cert-abridge-00.txt
Status: https://datatracker.ietf.org/doc/draft-jackson-tls-cert-abridge/
Html:   
https://www.ietf.org/archive/id/draft-jackson-tls-cert-abridge-00.html
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-jackson-tls-cert-abridge


Abstract:
This draft defines a new TLS Certificate Compression scheme which
uses a shared dictionary of root and intermediate WebPKI
certificates.  The scheme smooths the transition to post-quantum
certificates by eliminating the root and intermediate certificates
from the TLS certificate chain without impacting trust negotiation.
It also delivers better compression than alternative proposals whilst
ensuring fair treatment for both CAs and website operators.  It may
also be useful in other applications which store certificate chains,
e.g.  Certificate Transparency logs.

   



The IETF Secretariat




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

Re: [TLS] Abridged Certificate Compression

[Dennis Jackson]

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 
that part very quickly.

How much simpler would things be if the identifier were just a SHA256 hash of 
the CA, perhaps truncated?  You send an array of (url, timestamp) as an 
extension, and then the server just sends the digest of its cert chain, perhaps 
even its own cert.


So this draft is doing two different things: building the dictionaries 
in a fair way and then specifying how to use them as part of the 
existing TLS Certificate Compression extension. Implementations only 
care about the second part which only involves a bit of string 
substitution and a call to ZStd. They don't have to know or care about 
how the dictionaries were built or do any new kind of negotiation.


I don't follow your comment about the handling of extensions, the code 
doing the compression and decompression isn't aware of what an extension 
is or handling them specially, its just swapping strings.  In order to 
compress the larger strings which issuers add to end entity certificates 
(e.g. OCSP & CRL URLs, practice statements), the dictionary does include 
some extensions made by each issuer, but these are just concatenated 
binary strings.


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] Abridged Certificate Compression

[Dennis Jackson]

Thank you for the comments. I'll fix most of them - responses inline for 
the rest:


On 07/07/2023 17:38, Eric Rescorla wrote:


S 3.1.2.
   7.  Order the list by the date each certificate was included in the
       CCADB, breaking ties with the lexicographic ordering of the
       SHA256 certificate fingerprint.

Would it be simpler to just sort by the hash?
Possibly a premature optimization, but I was thinking that if a new 
version only included new certificates, it'd be nice to only have to 
append the new data to the existing dictionaries. I haven't yet worked 
out if that's actually going to deliver anything useful though.


       1.  If so, replace the opaque cert_data member of
           CertificateEntry with its adjusted three byte identifier and
           copy the CertificateEntry structure with corrected lengths to
           the output.

It seems like this is not injective in the face of certificates
whose length is greater than or equal to 0xff. That's probably
not a problem, but I think you should make it clear and have some
way to manage it.


If the length is corrected, isn't the only risk a collision with a 
certificate which is exactly three bytes and starts with 0xff?



S 3.2.1
How much value are you getting from the CT logs? It seems like
additional complexity. I agree with your comment about having
this submitted to CCADB.


It seemed the fairest repeatable way to check whether a CA was offering 
certificates to WebPKI 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've submitted the draft below that describes a new TLS certificate
compression scheme that I'm calling 'Abridged Certs' for now. The
aim is
to deliver excellent compression for existing classical certificate
chains and smooth the transition to PQ certificate chains by
eliminating
the root and intermediate certificates from the bytes on the wire. It
uses a shared dictionary constructed from the CA certificates
listed in
the CCADB [1] and the associated extensions used in end entity
certificates.

Abridged Certs compresses the median certificate chain from ~4000 to
~1000 bytes based on a sample from the Tranco Top 100k. This beats
traditional TLS certificate compression which produces a median of
~3200
bytes when used alone and ~1400 bytes when combined with the outright
removal of CA certificates from the certificate chain. The draft
includes a more detailed evaluation.

There were a few other key considerations. This draft doesn't impact
trust decisions, require trust in the certificates in the shared
dictionary or involve extra error handling. Nor does the draft favor
popular CAs or websites due to the construction of the shared
dictionary. Finally, most browsers already ship with a complete
list of
trusted intermediate and root certificates that this draft reuses to
reduce the client storage footprint to a few kilobytes.

I would love to get feedback from the working group on whether the
draft
is worth developing further.

For those interested, a few issues are tagged DISCUSS in the body
of the
draft, including arrangements for deploying new versions with updated
dictionaries and the tradeoff between equitable CA treatment and the
disk space required on servers (currently 3MB).

Best,
Dennis

[1] Mozilla 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:         draft-jackson-tls-cert-abridge
> Revision:     00
> Title:                Abridged Compression for WebPKI Certificates
> Document date:        2023-07-06
> Group:                Individual Submission
> Pages:                19
> URL:
https://www.ietf.org/archive/id/draft-jackson-tls-cert-abridge-00.txt
> Status:
https://datatracker.ietf.org/doc/draft-jackson-tls-cert-abridge/
> Html:
https://www.ietf.org/archive/id/draft-jackson-tls-cert-abridge-00.html
> Htmlized:
https://datatracker.ietf.org/doc/html/draft-jackson-tls-cert-abridge
>
>
> Abstract:
>     This draft defines a new TLS Certificate Compression scheme
which
>     uses a shared dictionary of root and intermediate WebPKI
>     certificates.  The scheme smooths the transition to post-quantum
>     certificates by eliminating the root and interm

Re: [TLS] Abridged Certificate Compression

[Dennis Jackson]

Hi Panos,

On 08/07/2023 02:49, Kampanakis, Panos wrote:

Hi Dennis,

This is an interesting draft.

Thanks!


The versioned dictionary idea for ICA and Root CAs especially was something I 
was considering for the ICA Suppression draft [1] given the challenges brought 
up before about outages with stale dictionary caches.

Btw, if we isolated the ICA and Root CA dictionary, I don't think you need pass 
1, assuming the parties can agree on a dictionary version. They could just 
agree on the dictionary and be able to build the cert chain, but providing the 
identifiers probably simplifies the process. This could be simplified further I 
think.


Ah I hadn't seen, thank you for the link to [1].

I thought a bit about suppressing pass 1 as well but I don't think its 
desirable.


A key selling point of the current Abridged Certs draft is that it can 
be enabled by default without the risk of connection failures or 
requiring retries, even if the server / client fall out of date. This 
keeps the deployment story very simple as you can just turn it on 
knowing it can only make things better and never make things worse.


Suppressing Pass 1 could be used to reduce the storage requirements on 
the server but then the server wouldn't know whether a particular ICA 
was in the dictionary and so the operator would have to configure that, 
leading to the same kind of error handling flows as in the CA Cert 
Suppression draft. Similarly, the bytes on the wire saving isn't 
significant and it would make it harder to use Abridged Certs in other 
contexts as it would no longer be a lossless compression scheme.



I also think one thing missing from the draft is how the client negotiates this 
compression with the server as the CertificateCompressionAlgorithms from 
RFC8879 will not be the same.


Sorry I'm afraid I don't follow.

Abridged Certs would negotiated just the same as any other certificate 
compression algorithm. The client indicates support by including the 
Abridged Certs identifier in its Certificate Compression extension in 
the ClientHello (along with the existing algorithms like plain Zstd). 
The server has the choice of whether to use it in its 
CompressedCertificate message. If a new version of Abridged Certs were 
minted in a few years with newer dictionaries then it would have its own 
algorithm identifier and would coexist with or replace the existing one.



About the end-entity compression, I wonder if compression, decompression 
overhead is significant and unbalanced. RFC8879 did not want to introduce a DoS 
threat by offering a cumbersome compression/decompression. Any data on that?


Abridged Certs is just a thin wrapper around Zstd which is already 
deployed as TLS Certificate Compression algorithm, so the same 
considerations apply. According to Facebook's numbers [ZSTD], 
decompression is more than 4x faster than Brotli and insensitive to the 
compression level used. TLS Certificate Compression schemes aren't 
sensitive to compression speed as it can be done once and cached at 
startup, but I ran a benchmark [COMPARE] using both the maximum and 
minimal Zstd compression levels and the outcome was within 100 bytes, so 
servers wanting to do just-in-time compression can use a minimal level 
without difficulty. I hope to have some proper benchmarks using a Rust 
implementation by the end of the week.



About your data in section 4, I think these are classical cert chains and it 
looks to be they improve 0.5-1KB from RFC8879 compression.
They are classical cert chains but I think you might be misreading the 
table. The improvement over regular TLS Certificate Compression is 1KB 
at the 5th percentile, 2.2 KB at the 50th percentile and 2.5 KB at the 
95th percentile.

In a WebPKI Dilithium2 cert with 2 SCTs the end-entity cert size will amount to ~7-8KB. 
85% of that will be the "random" Dilithium public key and signatures which will 
not get much compression. So, do we get any benefit from compressing 7-8KB certs to 
6-7KB? Is it worth the compression/decompression effort?


A 2.5 KB saving gives back a whole Dilithium2 signature, which I think 
is fair to say is substantial.


The overall size of a PQ end-entity cert is still uncertain and may not 
be as large as your calculation. If proofs of inclusion were used 
instead of SCTs, as suggested in Merkle Tree Certs [MTC], then each 
SCT-equivalent would be under 1 KB. Abridged Certs would then be saving 
around 2.5 KB of a 6 KB certificate, fitting the entire chain in roughly 
4KB. So we'd be shipping a full PQ cert chain without any size inflation 
on today's uncompressed classical chains.


Best,
Dennis

[ZSTD] https://github.com/facebook/zstd

[COMPARE] 
https://gist.github.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

Re: [TLS] Abridged Certificate Compression

[Dennis Jackson]

On 07/07/2023 21:28, Eric Rescorla wrote:



S 3.2.1
How much value are you getting from the CT logs? It seems like
additional complexity. I agree with your comment about having
this submitted to CCADB.


It seemed the fairest repeatable way to check whether a CA was
offering certificates to WebPKI clients without having to write a
lot of emails. I agree its not desirable to keep as a dependency
in the long run.

Can you elaborate on the concern here? I.e., is it that we will 
overinclude or underinclude if we just use CCADB?


Sorry, this answer came out garbled. Using CT gives two things:

1) There are large extensions in end-entity certs which are specific to 
the issuer and change little between certs. For example, the URLs for 
OCSP, CRL and the practice statement are typically the same. Using CT 
logs lets me pull out an example of each extension for that CA without 
having to write a bunch of mails to ask them to produce them in the 
right format.


2) I don't personally have concerns about the dictionary size and would 
prefer to include every CA. However, if someone were to have strong 
feelings about this then using CT to measure popularity is much fairer 
than say scanning popular domains from the Tranco list or whatever.


In the long term, I hope this could just be removed and ideally the CA's 
themselves provide a fixed size binary blob via CCADB that they'd like 
compressed out of their certs.


Best,
Dennis



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
compression scheme that I'm calling 'Abridged Certs' for now.
The aim is
to deliver excellent compression for existing classical
certificate
chains and smooth the transition to PQ certificate chains by
eliminating
the root and intermediate certificates from the bytes on the
wire. It
uses a shared dictionary constructed from the CA certificates
listed in
the CCADB [1] and the associated extensions used in end entity
certificates.

Abridged Certs compresses the median certificate chain from
~4000 to
~1000 bytes based on a sample from the Tranco Top 100k. This
beats
traditional TLS certificate compression which produces a
median of ~3200
bytes when used alone and ~1400 bytes when combined with the
outright
removal of CA certificates from the certificate chain. The draft
includes a more detailed evaluation.

There were a few other key considerations. This draft doesn't
impact
trust decisions, require trust in the certificates in the shared
dictionary or involve extra error handling. Nor does the
draft favor
popular CAs or websites due to the construction of the shared
dictionary. Finally, most browsers already ship with a
complete list of
trusted intermediate and root certificates that this draft
reuses to
reduce the client storage footprint to a few kilobytes.

I would love to get feedback from the working group on
whether the draft
is worth developing further.

For those interested, a few issues are tagged DISCUSS in the
body of the
draft, including arrangements for deploying new versions with
updated
dictionaries and the tradeoff between equitable CA treatment
and the
disk space required on servers (currently 3MB).

Best,
Dennis

[1] Mozilla 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:         draft-jackson-tls-cert-abridge
> Revision:     00
> Title:                Abridged Compression for WebPKI
Certificates
> Document date:        2023-07-06
> Group:                Individual Submission
> Pages:                19
> URL:
https://www.ietf.org/archive/id/draft-jackson-tls-cert-abridge-00.txt
> Status:
https://datatracker.ietf.org/doc/draft-jackson-tls-cert-abridge/
> Html:
https://www.ietf.org/archive/id/draft-jackson-tls-cert-abridge-00.html
> Htmlized:
https://datatracker.ietf.org/doc/html/draft-jackson-tls-cert-abridge
>
>
> Abstract:
>     This dr

Re: [TLS] Abridged Certificate Compression

[Dennis Jackson]

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 could adopt the document as-is and sort this out later.


Thanks, I filed #7 
 
to keep track of this.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Abridged Certificate Compression

[Dennis Jackson]

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 versioning 
scheme. I don't think consuming identifiers is a problem, but perhaps 
we can pre-define the code points and variables for the next, say, 
N=0xff years? Then the versioning mechanism is set for the foreseeable 
future.


I like the reduction of bookkeeping but I think we would need to work 
out which parts of the construction to make dynamic with an IANA 
registry. I wouldn't want to 'permanently' encode the root programs, CT 
trusted log lists or end entity compressed extensions for example.


I don't really have a sense of what the idiomatic IETF solution is for 
this problem, so I settled for seemed like the least commitment method 
in the draft.



(You could even say that we wrap the code points after N years).


I don't know whether there'll be interest in using this scheme outside 
TLS (e.g. reducing storage / bandwidth costs in CT) but if there is then 
we'll probably want identifiers which are unambiguous over long timescales.


Best,
Dennis

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

Re: [TLS] Abridged Certificate Compression

[Dennis Jackson]

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, so transcript validation should
always succeed.


TLS Certificate Compression influences the transcript for the 
decompressing party, as the output is the Certificate message which is 
used in the transcript. So if the Certificate message is incorrectly 
formatted, then the the decompressing party will likely bail when 
passing it to the TLS library. Even if they succeed and try to use it in 
a transcript calculation, the compressing party's transcript includes 
the uncompressed certificate directly and so will differ.



And are there zstd decoders that can reuse output buffer in oneshot
decompression for lookback? The zstd command line tool manual page
mentions default 128MB memory limit for decompression. I presume
mostly for lookback. Such limit is way too large.
Zstd is already supported without a dictionary for TLS Certificate 
Compression so others with deployment experience may be able to give an 
authoritative answer. That said, Facebook's Zstd implementation is 
permissively licensed, used in the Linux Kernel and their discussion 
here  suggests much 
smaller limits are fine.

And an alternative idea:

[...]

1) Where if next certificate in chain is also not found, zstd uses
empty dictionary. Otherwise it uses dictionary associated with the
next certificate in chain.

[...]

This allows dictionaries to be specific to CA, avoiding tradeoffs
between CAs.


Interesting idea! Can you share more about the motivation for using many 
small dictionaries rather than a single combined one? Is it purely for 
supporting memory constrained devices? We can already ensure that each 
CA contributes an equal number of bytes to the pass 2 dictionary.


One drawback is that some of the data isn't unique to a particular 
issuer (e.g. the CT log ids) and so would either have to be handled in 
its own pass or be included as redundant data in each individual 
dictionary.


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

Re: [TLS] Abridged Certificate Compression

[Dennis Jackson]

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 reference to the
contents of the CCADB.

I haven't thought through this completely, but I mention it because it
may affect the rest of the design decisions if we end up with the
WG having to produce the database.


To clarify: I'm fine with encoding things permanently in an RFC for use 
with a specific code point. I just wouldn't want to do that for multiple 
future code points to be used in future years since predicting 
developments is inherently hard.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Abridged Certificate Compression

[Dennis Jackson]

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 transcript is computed in any way.


Firstly, all extensions added to the ClientHello influence the 
transcript as the body of the CH message is included in the transcript.


Secondly, RFC 8879 specifies a CompressedCertificate message which is 
the result of applying the negotiated compression algorithm to the 
original Certificate message. The receiver of the CompressedCertificate 
message will decompress it and include the resulting Certificate message 
in their transcript. Consequently, for one party use of RFC 8879 will 
influence the transcript.



An extension altering computation of transcript would be truly
extraordinary.


You might find 6.1.5 and 7.2 of 
https://datatracker.ietf.org/doc/draft-ietf-tls-esni/ an interesting 
read :-).


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

Re: [TLS] Abridged Certificate Compression

[Dennis Jackson]

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 the complexity 
of pass 2. So, section 4 shows a 2.5KB improvement over plain compression which 
would be even more significant for Dilithium certs, but I am trying to find if 
the diff between ICA suppression/Compression vs ICA 
suppression/Compression+leaf compression is significant. [/n]

I am arguing that the table 4 numbers would be much different when talking 
about Dilithium certs because all of these numbers would be inflated and any 
compression would have a small impact. Replacing a CA cert (no SCTs) with a 
dictionary index would save us ~4KB (Dilithium2) or 5.5KB (Dilithium3). That is 
significant. [/n]

Compressing the leaf (of size 8-9KB (Dilithium2) or 11-12 KB (Dilithium 3)) 
using any mechanism would trim down ~0.5-1KB compared to not compressing. That 
is because the PK and Sig can't be compressed and these account for most of the 
PQ leaf cert size. So, I am trying to see if pass 2 and compression of the leaf 
cert benefit us much.


I think there's a fairly big difference between suppressing CA certs in 
SCA and compressing CA certs with pass 1 of this draft. But I do agree 
its fair to ask if pass 2 is worth the extra effort.


The performance benefit isn't purely in the ~1KB saved, its whether it 
brings the chain under the QUIC amplification limit or shaves off an 
additional packet and so avoids a loss+retry. There's essentially no 
difference in implementation complexity, literally just a line of code, 
so the main tradeoff is the required disk space on the client & server.


Best,
Dennis

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

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

[Dennis Jackson]

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 basis to confirm it, but I confirmed the fluctuations. The commits in 
https://github.com/FiloSottile/intermediates/commits/main  show it too. Given 
that, I am wondering if CCADB is not that stable. Are you confident that ICA 
dictionaries (based on CCADB) won't materially change often?


I checked the historical data for the last few years to ballpark a rate 
of 100-200 new intermediates per year. A uniform distribution of 
arrivals would mean 2 to 4 changes a week, which matches Filippo's 
commit frequency [1]. In practice Filippo's commits include removals 
(which we don't care about) and batched additions (which we do), but the 
numbers seem about right.


In terms of impact, the question is how much usage do those new ICAs see 
in their first year. If we expect websites to adopt them equally likely 
as existing ICAs then they should make up <5% of the population. I think 
in practice they see much slower adoption and so the impact is even 
lower, for example a reasonable proportion are vanity certificates with 
limited applicability or intended to replace an existing cert in the 
future. If we wanted to confirm this we could build the abridged cert 
dictionaries for '22 and then use CT to sample the cert chains used by 
websites that year. I'll see if I can find the time to put that together.


If there was an appetite for a faster moving dictionary, we could use 
the scheme I sketched in the appendix to the draft. But I think we 
should try to avoid that complexity if we can.


Best,
Dennis

[1] https://github.com/FiloSottile/intermediates/graphs/commit-activity

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

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

[Dennis Jackson]

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 actively participate and go fetch them.

Are we confident that servers would deploy the dictionary fetching mechanism to 
benefit their connecting clients?


I think OCSP staples is quite a bit different from this draft. OCSP 
Staples requires the server to fetch new data from the CA every day or 
week. It's inherently hard to do this reliably, especially with the 
large number of poor quality or poorly maintained OCSP servers and the 
large fraction of operators who do not want their servers making 
outbound connections. Besides these barriers I don't think the benefit 
was huge as clients already cached OCSP responses for up to a week so at 
most it was speeding up one connection per client per week (this was 
before network partitioning in browsers) and at worst it was breaking 
your website entirely.


In contrast, this draft aims to speed up every connection that isn't 
using session tickets, cause no harm if its misconfigured or out of date 
and be slow moving enough that the dictionaries can be shipped as part 
of a regular software release and so suitable for anyone willing to 
update their server software once a year (or less). Similarly, these 
updates aren't going to involve code changes, just changes to the static 
dictionaries, so they are suitable for backporting or ESR releases.


It would definitely be good to hear from maintainers or smaller 
operators if they have concerns though!


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

Re: [TLS] Abridged Certificate Compression

[Dennis Jackson]

On 12/07/2023 19:23, Kampanakis, Panos wrote:


One more argument for making pass 2 optional or allowing for just pass 1 
dictionaries is that if we are not talking about WebPKI we don't have the 
luxury of CT logs. But we would still want to option of compressing / omitting 
the ICAs by using CCADB.


Using the CT logs to extract the end-entity extensions is a bit of a 
stop-gap measure. I think in the long run we'd like to add a field to 
the CCADB where CAs could provide their own compression data (up to some 
budget).


Whilst I think pass 2 has a marked improvement for classical 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, 2023 12:39 PM
To: Kampanakis, Panos ; TLS List 
Subject: RE: [EXTERNAL][TLS] Abridged Certificate Compression

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.



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
the complexity of pass 2. So, section 4 shows a 2.5KB improvement over
plain compression which would be even more significant for Dilithium
certs, but I am trying to find if the diff between ICA
suppression/Compression vs ICA suppression/Compression+leaf
compression is significant. [/n]

I am arguing that the table 4 numbers would be much different when
talking about Dilithium certs because all of these numbers would be
inflated and any compression would have a small impact. Replacing a CA
cert (no SCTs) with a dictionary index would save us ~4KB (Dilithium2)
or 5.5KB (Dilithium3). That is significant. [/n]

Compressing the leaf (of size 8-9KB (Dilithium2) or 11-12 KB (Dilithium 3)) 
using any mechanism would trim down ~0.5-1KB compared to not compressing. That 
is because the PK and Sig can't be compressed and these account for most of the 
PQ leaf cert size. So, I am trying to see if pass 2 and compression of the leaf 
cert benefit us much.

I think there's a fairly big difference between suppressing CA certs in SCA and 
compressing CA certs with pass 1 of this draft. But I do agree its fair to ask 
if pass 2 is worth the extra effort.

The performance benefit isn't purely in the ~1KB saved, its whether it brings the 
chain under the QUIC amplification limit or shaves off an additional packet and so 
avoids a loss+retry. There's essentially no difference in implementation 
complexity, literally just a line of code, so the main tradeoff is the required 
disk space on the client & server.

Best,
Dennis



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

Re: [TLS] Abridged Certificate Compression

[Dennis Jackson]

On 13/07/2023 10:13, Rob Stradling wrote:

How about also including in the shared dictionary the SHA-256 hashes 
of the public keys of all the known CTv1 logs, so that the 32-byte 
LogID field of each SCT will be compressed?


This is already step 2 of the shared dictionary construction :-) (link 
<https://www.ietf.org/archive/id/draft-jackson-tls-cert-abridge-00.html#section-3.2.1-4>). 




Best,
Dennis



FWIW, RFC9162 (CTv2) tackles the same SCT bloat by changing the LogID 
type from a (32-byte) SHA-256 hash of the log's public key to a 
(minimum 4-byte) DER-encoded OID (excluding 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: This email originated from outside of the organization. Do 
not click links or open attachments unless you recognize the sender 
and know the content is safe.



SCTs have always seemed surprisingly large to me, and it has always seemed
like there should be a more compact representation that has the same 
security
properties, but I've never found the time to look more closely at it.  
If someone
does have the time, figuring out how to reduce the size of SCTs would 
be quite

helpful.

-Tim

> -Original Message-
> From: TLS  On Behalf Of Kampanakis, Panos
> Sent: Wednesday, July 12, 2023 2:23 PM
> To: Dennis Jackson ; TLS List
> 
> Subject: Re: [TLS] Abridged Certificate Compression
>
> > The performance benefit isn't purely in the ~1KB saved, its 
whether it brings
> the chain under the QUIC amplification limit or shaves off an 
additional packet
> and so avoids a loss+retry. There's essentially no difference in 
implementation
> complexity, literally just a line of code, so the main tradeoff is 
the required disk

> space on the client & server.
>
> Fair. I would add one more tradeoff which is pulling the end-entity 
certs in the
> CT window for pass 2. This is an one time cost for each dictionary 
version, so

> maybe not that bad.
>
> Regardless, would compressing the leaf bring us below the QUIC 3.6KB
> threshold for Dilithium 2 or 3 certs whereas not suppressing would 
keep us
> above? I think it is not even close if we are talking WebPKI. 
Without SCTs,
> maybe compressing could keep us below 4KB for Dilithium 2 leaf 
certs. But
> even then, if we add the CertVerify signature size we will be well 
over 4KB.

>
> Additionally, would compressing the leaf bring us below the 9-10KB 
threshold
> that Bas had tested to be an important inflection point? For WebPKI, 
it may
> the 8-9KB cert below 9KB if we add the CertVerify signature size. 
Maybe not. It
> would need to tested. For Dilithium 3, maybe compression could 
render the

> 11-12KB cert below 9KB if we got lucky, maybe not, but if we add the
> CertVerify signature we won’t make it. For non-WebPKI, they will 
already be

> below 9-10KB.
>
> So, I am arguing that we can't remain below the QUIC threshold by
> compressing the leaf Dilithium cert. And we could remain below the 
9-10KB
> only for Dilithium2 leaves.  I could be proven wrong if you have 
implemented

> it.
>
> One more argument for making pass 2 optional or allowing for just pass 1
> dictionaries is that if we are not talking about WebPKI we don't 
have the
> luxury of CT logs. But we would still want to option of compressing 
/ omitting

> the ICAs by using CCADB.
>
>
>
>
> -Original Message-
> From: Dennis Jackson 
> Sent: Wednesday, July 12, 2023 12:39 PM
> To: Kampanakis, Panos ; TLS List 
> Subject: RE: [EXTERNAL][TLS] Abridged Certificate Compression
>
> CAUTION: This email originated from outside of the organization. Do 
not click

> links or open attachments unless you can confirm the sender and know the
> content is safe.
>
>
>
> 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
> > the complexity of pass 2. So, section 4 shows a 2.5KB improvement over
> > plain compression which would be even more significant for Dilithium
> > certs, but I am trying to find if the diff between ICA
> > suppression/Compression vs ICA suppression/Compression+leaf
> > compression is significant. [/n]
> >
> > I am arguing that the table 4 numbers would be much different when
> > talking about Dilithium certs because all of these numbers would be
> > inflated an

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

[Dennis Jackson]

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 remove any 
intermediates which no longer chained back to trusted roots, so I'll fix 
the wording.___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Dennis Jackson]

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 
elided and has the exact same storage requirements (some space required 
on the client, none required on the server).


Best,
Dennis

On 12/08/2023 06:58, Simon Mangel wrote:

tl;dr: We plan on updating RFC 7924 for TLS 1.3 and would like to check
whether there is interest in the TLS wg.

The TLS Cached Information extension [RFC7924] has not seen significant
adoption since its specification.
However, we still believe it to be an interesting candidate in upcoming
IoT application scenarios.


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

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

[Dennis Jackson]

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
[RFC8446, sec. 4.6.1], and are often configured to be even shorter
[Sy2018Tracking, sec. 5.1.2].


Two observations:

   1. The reason ticket lifetimes are often shorter than 7 days is
   because they can be used to track user visits. Caching end-entity
   certificates as in RFC 7924 over a long period of time is
   problematic for the same reason.

   2. Although each individual session ticket lifetime is capped at 7
   days, you can resume a TLS 1.3 session within the 7 day window and
   receive new session tickets over that connection and so extend the
   resumption window up till the certificate lifetime (subject to the
   tracking risk in (1)).

So if you aren't concerned about tracking and you expect to make at 
least one connection per week, session resumption is strictly better.


If you're making fewer than one connection a week, RFC 7924 is better, 
but then you're saving at most 52 handshakes per year per device (as the 
max certificate lifetime is ~1 year), so I'd argue the implementation 
benefit is pretty small.


And if you're concerned about tracking then neither RFC 7924 nor long 
term session ticket renewal is appropriate.


Best,
Dennis


As X.509 certificates (as the most interesting type of cached object)
typically have a much longer validity period, the idea is to further
bring down the frequency of "full" handshakes (including the server
certificate chain) by either opting to uses RFC7924 instead of session
resumption, or even combining the two techniques.
When combining the two, the full TLS handshake after a session
resumption ticket has expired could then be made more efficient using
the cached Certificate and/or CertificateRequest message, at the cost
of a second client-side cache.

Best wishes,
Simon


References
[RFC8446] The Transport Layer Security (TLS) Protocol Version 1.3,
https://datatracker.ietf.org/doc/html/rfc8446
[Sy2018Tracking] Tracking Users across the Web via TLS Session
Resumption,https://doi.org/10.1145/3274694.3274708___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Dennis Jackson]

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.g. "hub.com"), what would the 
"suggested value" be?


Section 6.1.7 implies it should NOT be an IPv4 address. If I do not 
wish to leak the real domain, is it "acceptable" to use something like 
"fakedomain.com"?
The server needs to be able to answer a TLS connection for the ECH 
public name or you risk an outage if the ECHConfigs get out of sync as 
then clients will get a TLS error page if they can't get through to the 
public name.


If the public_name leaks domain in anyway, I think it would be quite 
unfortunate, at least for bypassing DPI-blocks. From what I 
understand, the purpose of public_name is only if the server doesn't 
support ECH, but if a client retrieved an ECHConfig, why shouldn't the 
client just skip this field? I fear it will become a situation like 
the initial SNI extension - even when websites do not need it, 
browsers' TLS stacks send it anyway, causing leakage.


For instance, in India, a popular website, let's call it "hub.com", is 
blocked via SNI. However, the website itself does NOT rely on SNI, It 
is possible to open a pure TLS connection to it via IP, it serves the 
TLS cert for "hub.com" so the handshake can be completed, and then the 
website will load as normal. I verified this by manually using 
"openssl s_client", WITHOUT SNI. But since Firefox/Chrome will always 
send SNI, the ISPs can block it.


If the server can answer with the correct certificate without SNI, then 
it must be the only site hosted at that IP. This means that the ISP can 
also just block the IP without any collateral damage. The same thing is 
true if ECH connections didn't expose an SNI at all, they'd stick out 
and could be blocked for that reason.


I would describe ECH primarily as a technology for improving privacy. 
Unfortunately, I don't think it's any kind of silver bullet for 
censorship resistance.


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] FW: [EXTERNAL] New Version Notification for draft-ounsworth-lamps-pq-external-pubkeys-00.txt

[Dennis Jackson]

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-visited websites. (yes, 
yes, I know that the idea of caching server public keys runs counter 
to the desire for the Internet to move to 14-day certs. Shrug)


I think a bigger objection would be that caching the public keys is a 
tracking vector and seems a bit redundant if the browser and server can 
do session resumption instead (with less storage overhead).


2. Mutual-auth TLS within a cluster

Consider a collection of docker containers within a kubernetes 
cluster. Consider that each container has a local volume mount of a 
read-only database of the public keys of all containers in the 
cluster. Then container-to-container mutual-auth TLS sessions could 
use much smaller certificates that contain references to public key 
objects in the shared database, instead of the large PQ public keys 
themselves.


You could easily used abridged certs here, just with an enterprise 
specific dictionary rather than the external public keys. That would let 
you reduce the entire certificate chain to a few bytes, without having 
to implement any key fetching logic in the TLS client. Would you be 
interested in that? It would be easy enough to have a generic IETF draft 
for abridged certs schemes and then a particular draft defining the 
WebPKI instantiation. I think Panos may also be interested in a similar 
enterprise use case?


I'm a little confused on why caching the public key independently of the 
certificate is a good idea. It seems like a recipe for encouraging 
people to issue new certificates without rolling new public keys, which 
would not be great for security.


Best,
Dennis


---

*Mike*Ounsworth

*From:*Spasm  *On Behalf Of *Mike Ounsworth
*Sent:* Saturday, September 30, 2023 5:16 PM
*To:* 'LAMPS' 
*Cc:* John Gray ; Markku-Juhani O. Saarinen 
; David Hook 
*Subject:* [lamps] FW: [EXTERNAL] New Version Notification for 
draft-ounsworth-lamps-pq-external-pubkeys-00.txt


Hi LAMPS! This is both a new draft announcement, and a request for a 
short (5 min?) speaking slot at 118. Actually, this is not a new 
draft. Back in 2021 Markku and I put forward a draft for External 
Public Key -- draft-ounsworth-pq-external-pubkeys-00


Hi LAMPS!

This is both a new draft announcement, and a request for a short (5 
min?) speaking slot at 118.


Actually, this is not a new draft. Back in 2021 Markku and I put 
forward a draft for External Public Key -- 
draft-ounsworth-pq-external-pubkeys-00 (the only reason this is an -00 
is because I included "lamps" in the draft name). The idea is that 
instead of a putting the full public key in a cert, you just put a 
hash and pointer to it:


ExternalValue ::= SEQUENCE {

location GeneralName,

hashAlg  AlgorithmIdentifier,

hashVal  BIT STRING

   }

That allows super small PQ certs in cases where you can pass the 
public key blob through some out-of-band mechanism.


Here's the mail list discussion from 2021:

https://mailarchive.ietf.org/arch/msg/spasm/yv7mbMMtpSlJlir8H8_D2Hjr99g/ 



It turns out that BouncyCastle has implemented this at the request of 
one of their customers as a way around megabyte sized Classic McEliece 
certs; it is especially useful for usecases where clients have a way 
to fetch-and-cache or be pre-provisioned with its peer's public keys 
out-of-band. As such, Entrust and KeyFactor are reviving this draft.


We suspect this might also be of interest to the TLS WG, but I will 
start a separate thread on the TLS list.


---

*Mike*Ounsworth

*From:*internet-dra...@ietf.org 
*Sent:* Saturday, September 30, 2023 5:12 PM
*To:* D. Hook ; John Gray 
; Markku-Juhani O. Saarinen 
; John Gray ; Markku-Juhani 
Saarinen ; Mike Ounsworth 
*Subject:* [EXTERNAL] New Version Notification for 
draft-ounsworth-lamps-pq-external-pubkeys-00.txt


A new version of Internet-Draft 
draft-ounsworth-lamps-pq-external-pubkeys-00. txt has been 
successfully submitted by Mike Ounsworth and posted to the IETF 
repository. Name: draft-ounsworth-lamps-pq-external-pubkeys Revision: 
00 Title: External


A new version of Internet-Draft
draft-ounsworth-lamps-pq-external-pubkeys-00.txt has been successfully
submitted by Mike Ounsworth and posted to the
IETF repository.
Name: draft-ounsworth-lamps-pq-external-pubkeys
Revision: 00
Title:    External Keys For Use In Internet X.509 Certificates
Date: 2023-09-30
Group:    Individual Submission
Pages:    9
URL: 
https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ounsworth-lamps-pq-external-pub

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

[Dennis Jackson]

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 to 
externally stored public keys. What's the value in splitting these 
objects? If you're going to cache a public key, why not cache the whole 
certificate?


The suggestion of Abridged Certs is just one way to do that caching. If 
the external fetching via URL is the key feature - you could define a 
certificate compression scheme which compresses and decompresses a 
certificate to a URL.


I skimmed the LAMPS list as well, but I did not see any discussion of 
the rationale there.



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

Re: [TLS] ECH: What changed?

[Dennis Jackson]

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 
smoothly, and today its deployed at 100% in both Firefox and Chrome, 
with ECH GREASEing enabled as well.


Best,
Dennis

[1] https://blog.mozilla.org/en/products/firefox/encrypted-hello/

[2] https://chromestatus.com/feature/6196703843581952

On 14/11/2023 15:02, Salz, Rich wrote:


So IETF 118 it appears that the TLS ECH draft is headed for WGLC.  
What changed since at IETF 117 it wasn’t ready and we needed more 
“something”. (I asked if we had measurable criteria and we did not.)



___
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] Adoption call for 'TLS 1.2 Feature Freeze'

[Dennis Jackson]

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/ 
) 
 This call is to confirm this on the list.  Please indicate if you 
support the adoption of this draft and are willing to review and 
contribute text. If you do not support adoption of this draft please 
indicate why.  This call will close on December 20, 2023.


As the co-author, I support this and am willing to continue working on 
it as needed.



___
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] Call to Move RFC 8773 from Experimental to Standards Track

[Dennis Jackson]

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 the existing certificate and digital signature mechanisms.


I don't see anything specifically alarming about the design, but I'm 
very uncomfortable about any standards-track document making a strong 
security claim like this  if its not backed by some kind of formal 
analysis.


The document could also be a bit more explicit on the security 
properties it achieves and when e.g. that it breaks down once a 
large-scale QC is actually available, that clients & servers need to 
reject connections which do not negotiate the extension to actually 
benefit from its protection.


On the issue of tracking via external PSKs - it's easy to imagine a 
scheme where client and server divide time into epochs and derive 
per-epoch keys to prevent tracking between epochs. I'm sure there must 
be some prior art that could be referenced as a recommendation?


Best,
Dennis

On 29/11/2023 15:51, Joseph Salowey wrote:
RFC 8773 (TLS 1.3 Extension for Certificate-Based Authentication with 
an External Pre-Shared Key) was originally published as experimental 
due to lack of implementations. As part of implementation work for the 
EMU workitem draft-ietf-emu-bootstrapped-tls which uses RFC 8773 there 
is ongoing implementation work. Since the implementation status of RFC 
8773 is changing, this is a consensus call to move RFC 8773 to 
standards track as reflected in 
[RFC8773bis](https://datatracker.ietf.org/doc/draft-ietf-tls-8773bis). 
This will also help avoid downref for the EMU draft.  Please indicate 
if you approve of or object to this transition to standards track 
status by December 15, 2023.


Thanks,

Joe, Sean, and Deirdre

___
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] Key Update for TLS/DTLS 1.3

[Dennis Jackson]

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 implementation changes and no spec or 
server-side changes to deploy.


Best,
Dennis

On 04/01/2024 11:42, Tschofenig, Hannes wrote:


Hi all,

we have just submitted a draft that extends the key update 
functionality of TLS/DTLS 1.3.


We call it the “extended key update” because it performs an ephemeral 
Diffie-Hellman as part of the key update.


The need for this functionality surfaced in discussions in a design 
team of the TSVWG. The need for it has, however, already been 
discussed years ago on the TLS mailing list in the context of 
long-lived TLS connections in industrial IoT environments.


Unlike the TLS 1.3 Key Update message, which is a one-shot message, 
the extended Key Update message requires a full roundtrip.


Here is the link to the draft:

https://datatracker.ietf.org/doc/draft-tschofenig-tls-extended-key-update/

I am curious what you think.

Ciao
Hannes


___
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] I-D Action: draft-ietf-tls-cert-abridge-00.txt

[Dennis Jackson]

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 replaced if cert_data is known.
   Obviously overriding the length field would be more compact, but it
   also can be interpreted as replacing the value, wasting 3 bytes.

   (Reminds me of RFC 8879, which is not clear about similar things.)

- CertificateEntry and Certificate length fields are just waste of
   space, since both can be recovered in other ways when decoding.

- RFC 8879 does not allow ignoring unrecognized three-byte identifiers.
   Instead, the connection MUST be terminated with bad_certificate alert.

   This has consequence that any client that can ever add a custom trust
   anchor via any means must have the complete certificate list (whereas
   partial list would be enough if no custom trust anchors can ever be
   added).

   And I find the last comment about transcript validation failing very
   scary.


I've improved the language in the draft to clarify exactly how this pass 
works. A TLS1.3 Certificate Message carrying X509 is structured as follows:


  struct {
  opaque cert_data<1..2^24-1>;
  Extension extensions<0..2^16-1>;
  } CertificateEntry;

  struct {
  opaque certificate_request_context<0..2^8-1>;
  CertificateEntry certificate_list<0..2^24-1>;
  } Certificate;

When compressing during this first pass, we're going to be swapping the 
opaque cert_data fields for short three byte identifiers and correcting 
the lengths. The extension and certificate_request_context fields are 
not going to be adjusted. Pass 2 is then going to compress the result 
with ZStd with a provided dictionary.


When we're decompressing, after the ZStd pass, we're going to use the 
length fields to parse the message and replace any recognized three byte 
identifiers with the corresponding certificate, again leaving the 
extensions and the certificate_request_context untouched.


I hope that clarifies why transmitting the lengths is necessary. 
Regarding the decompression errors, I've updated the draft to say that 
decompression must fail and the correct alert sent if the length fields 
are incorrect as you suggested. I've filed an issue to discuss the case 
of unrecognized identifiers specifically [1].


Regarding the general security considerations, I want to clarify the 
situation. At the point we receive a Certificate (or a 
CompressedCertificate) message in TLS1.3, we don't know who we're 
talking to, the point of the message is to provide that information. 
Obviously, a peer can send any payload it likes in a Certificate message 
already, it's the job of the receiver to parse the Certificate message 
and establish whether it trusts the presented certificate (chain).


Using Certificate Compression with any scheme (including this draft) 
doesn't change the fundamentals. The result of decompressing the message 
is handled exactly like a Certificate message. So with the exception of 
memory safety bugs during decompression, there is no additional attack 
surface. An attacker can already send arbitrary content in a Certificate 
message and so implementations receiving a Certificate message already 
have to be able to robustly validate it. Any attack which somehow 
leveraged the decompression aspect is also possible by the attacker just 
sending the output of the decompression directly as a Certificate 
message. Nothing in this draft changes the situation from existing uses 
of Certificate Compression.




Section 3.2.:

- Using alternate scheme could result drastically reduced implementation
   complexity.

   Furthermore, one can't even use standard zstd decoder with this due to
   security reasons. One needs special one (but seems like reference zstd
   library ships that as alternative API).


Can you clarify what you mean by this? The standard zstd decoder works fine.


Section 3.2.1.:

- I suspect that having CA-specific dictionaries would make it much
   easier to be equitable and improve compression.

   Then I don't think the dictionary construction method is good:
  
   * Using just one certificate is very dubious.

   * It is more optimal to consider byte substrings with no structure.


This is tracked in [2] and [3]. Depending on the experimental data we 
get when evaluating [3], we might omit pass 2 entirely.




Section 3.2.1.1.:

- Caching monolithic compression from startup does not work because of
   extension fields.

   For caching to work, one would have to compress the certificate
   entries independently and leave the extension fields in between
   uncompressed.
The draft currently preserves the extension fields. Existing TLS 
Certificate Compression APIs perform the caching at the level of the 
entire message and so the cache is only used if t

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

[Dennis Jackson]

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 current draft and expect to start 
experimenting with abridged certs in Firefox (with a server-side 
partner) ahead of IETF 120.


On the editorial side, I've addressed the comments on presentation and 
clarification made since IETF 117 which are now in the editors copy - 
there's an overall diff here [1] and atomic changes here [2] . There are 
two small PRs I've opened addressing minor comments by Ben Schwarz on 
fingerprinting considerations [3] and Jared Crawford on the ordering of 
certificates [4]. Feedback is welcome via mail or on the PRs directly.


Best,
Dennis

[1] 
https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-tls-cert-abridge&url_2=https://tlswg.github.io/draft-ietf-tls-cert-abridge/draft-ietf-tls-cert-abridge.txt


[2] https://github.com/tlswg/draft-ietf-tls-cert-abridge/commits/main/

[3] https://github.com/tlswg/draft-ietf-tls-cert-abridge/pull/21/files

[4] https://github.com/tlswg/draft-ietf-tls-cert-abridge/pull/19/files
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Dennis Jackson]

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 an admin to add a new trust anchor, or to override validation
   error.

Then such client can get into situation where server sends chain that
should be valid, but instead references a certificate the client does
not have. Which is a hard error.


As laid out in 3.1, this draft works with a fixed list of certificates. 
Clients cannot use the scheme if they are not willing to have a full 
list of the certificates. Clients can trust a superset or subset of 
roots that are present on the list, any certificates not in the fixed 
pass 1 list are simply not compressed in that pass. A key goal of this 
draft is not to risk any breakage (unlike with suppressing intermediates).


If you have any editorial feedback on where you think this part of the 
draft is unclear, suggestions are welcome. I'm not sure where you've got 
the idea that only partial lists of certificates are possible.


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

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

[Dennis Jackson]

Hi Panos,

On 02/03/2024 04:09, Kampanakis, Panos wrote:


Hi Dennis,

I created a git issue 
https://github.com/tlswg/draft-ietf-tls-cert-abridge/issues/23 but I 
am pasting it here for the sake of the discussion:


What does the client do if the server only does Pass 1 and compresses 
/ omits the chain certs but does not compress the end-entity certs 
(Pass 2)?


The client should be fine with that. It should be able to reconstruct 
the chain and used the uncompressed end-entity cert. It should not 
fail the handshake. I suggest the Implementation Complexity Section to 
say something like


I can see two different ways to handle it. Either as you suggest, we 
have it be a runtime decision and we just prefix the compressed form 
with a byte to indicate whether pass 2 has been used. Alternatively, we 
can define two codepoints, (pass 1 + pass 2, pass 1).


I'd like to experiment with both operations and measure what the real 
world difference is first, then we can make a decision on how to 
proceed. There's also been more interest in the non-webpki use case than 
I expected, so that needs to factor in to whichever option we pick.


Best,
Dennis

/> Servers MAY chose 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, March 1, 2024 8:03 AM
*To:* TLS List 
*Subject:* [EXTERNAL] [TLS] draft-ietf-tls-cert-abridge Update

*CAUTION*: This email originated from outside of the organization. Do 
not click links or open attachments unless you can confirm the sender 
and know the content is safe.


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 current draft and expect to 
start experimenting with abridged certs in Firefox (with a server-side 
partner) ahead of IETF 120.


On the editorial side, I've addressed the comments on presentation and 
clarification made since IETF 117 which are now in the editors copy - 
there's an overall diff here [1] and atomic changes here [2] . There 
are two small PRs I've opened addressing minor comments by Ben Schwarz 
on fingerprinting considerations [3] and Jared Crawford on the 
ordering of certificates [4]. Feedback is welcome via mail or on the 
PRs directly.


Best,
Dennis

[1] 
https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-tls-cert-abridge&url_2=https://tlswg.github.io/draft-ietf-tls-cert-abridge/draft-ietf-tls-cert-abridge.txt 
<https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-tls-cert-abridge&url_2=https://tlswg.github.io/draft-ietf-tls-cert-abridge/draft-ietf-tls-cert-abridge.txt>


[2] https://github.com/tlswg/draft-ietf-tls-cert-abridge/commits/main/

[3] https://github.com/tlswg/draft-ietf-tls-cert-abridge/pull/21/files

[4] https://github.com/tlswg/draft-ietf-tls-cert-abridge/pull/19/files
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Dennis Jackson]

Hi Panos,

On 05/03/2024 04:14, Kampanakis, Panos wrote:


Hi Dennis,

> I can see two different ways to handle it. Either as you suggest, we 
have it be a runtime decision and we just prefix the compressed form 
with a byte to indicate whether pass 2 has been used. Alternatively, 
we can define two codepoints, (pass 1 + pass 2, pass 1).


> I'd like to experiment with both operations and measure what the 
real world difference is first, then we can make a decision on how to 
proceed. There's also been more interest in the non-webpki use case 
than I expected, so that needs to factor in to whichever option we pick.


Maybe these will not matter for the scenario I am considering. Let’s 
say the client advertised support for draft-ietf-tls-cert-abridge. And 
the server sent back
- CompressedCertificate which includes the 2 identifiers for the ICA 
and RootCA from Pass 1.


- uncompressed, traditional CertificateEnty of the end-entity certificate

Or it sent back

- uncompressed, traditional CertificateEnties for the  ICA and RootCA 
certs


- CompressedCertificate which includes the ZStandard compressed (based 
on the Pass2 dictionary) end-entity cert


My point is that nothing should prevent the client from being able to 
handle these two scenarios and normative language should point that 
out. Any software that can parse certs in compressed form, ought to be 
able to parse them in regular form if the server did not support Pass1 
(CA cers were not available for some reason) or Pass2 (eg. if CT Logs 
were not available for some reason).


Am I overseeing something?

Yes I think so. TLS1.3 Certificate Compression applies to the entire 
Certificate Message, not individual CertificateEntries in that message. 
Those individual entries don't currently carry identifiers about what 
type they are, their type is negotiated earlier in the 
EncryptedExtensions extension.


So to handle this as you propose, we'd need to define a type field for 
each entry to specify whether that particular entry had undergone a 
particular pass (or both). In my 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] draft-ietf-tls-cert-abridge Update

*CAUTION*: This email originated from outside of the organization. Do 
not click links or open attachments unless you can confirm the sender 
and know the content is safe.


Hi Panos,

On 02/03/2024 04:09, Kampanakis, Panos wrote:

Hi Dennis,

I created a git issue
https://github.com/tlswg/draft-ietf-tls-cert-abridge/issues/23 but
I am pasting it here for the sake of the discussion:

What does the client do if the server only does Pass 1 and
compresses / omits the chain certs but does not compress the
end-entity certs (Pass 2)?

The client should be fine with that. It should be able to
reconstruct the chain and used the uncompressed end-entity cert.
It should not fail the handshake. I suggest the Implementation
Complexity Section to say something like

I can see two different ways to handle it. Either as you suggest, we 
have it be a runtime decision and we just prefix the compressed form 
with a byte to indicate whether pass 2 has been used. Alternatively, 
we can define two codepoints, (pass 1 + pass 2, pass 1).


I'd like to experiment with both operations and measure what the real 
world difference is first, then we can make a decision on how to 
proceed. There's also been more interest in the non-webpki use case 
than I expected, so that needs to factor in to whichever option we pick.


Best,
Dennis

/> Servers MAY chose 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  <mailto:tls-boun...@ietf.org>
*On Behalf Of *Dennis Jackson
*Sent:* Friday, March 1, 2024 8:03 AM
*To:* TLS List  <mailto:tls@ietf.org>
*Subject:* [EXTERNAL] [TLS] draft-ietf-tls-cert-abridge Update

*CAUTION*: This email originated from outside of the organization.
Do not click links or open attachments unless you can confirm the
sender and know the content is safe.

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 current
draft and expect to start experimenting with abridged certs in
Firefox (with a server-side partner) ahead of IETF 120.

On the edi

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

[Dennis Jackson]

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/2024 00:31, Watson Ladd wrote:

On Wed, Mar 6, 2024, 10:48 AM Rob Sayre  wrote:

On Wed, Mar 6, 2024 at 9:22 AM Eric Rescorla  wrote:



On Wed, Mar 6, 2024 at 8:49 AM Deirdre Connolly  
wrote:

Can you say what the motivation is for being "fully post-quantum" rather than 
hybrid?

Sure: in the broad scope, hybrid introduces complexity in the short-term that 
we would like to move off of in the long-term - for TLS 1.3 key agreement this 
is not the worst thing in the world and we can afford it, but hybrid is by 
design a hedge, and theoretically a temporary one.


My view is that this is likely to be the *very* long term.


Also, the ship has sailed somewhat, right? Like Google Chrome, Cloudflare, and 
Apple iMessage already have hybrids shipping (I'm sure there many more, those 
are just really popular examples). The installed base is already very big, and 
it will be around for a while, whatever the IETF decides to do.

People can drop support in browsers fairly easily especially for an
experimental codepoint. It's essential that this happen: if everything
we (in the communal sense) tried had to be supported in perpetuity, it
would be a recipe for trying nothing.


thanks,
Rob

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

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


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

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

[Dennis Jackson]

On 07/03/2024 03:57, Bas Westerbaan wrote:

We think it's worth it now, but of course we're not going to keep 
hybrids around when the CRQC arrives.


Sure, but for now we gain substantial security margin* against 
implementation mistakes, advances in cryptography, etc.


On the perf/cost side, we're already making a large number of 
sub-optimal choices (use of SHA-3, use of Kyber in TLS rather than a CPA 
scheme, picking 768 over 512, etc), we can easily 'pay' for X25519 if 
you really wanted. I think if handshake cycles really mattered then we'd 
have shown 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 Jackson 
 wrote:


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/2024 00:31, Watson Ladd wrote:
> On Wed, Mar 6, 2024, 10:48 AM Rob Sayre  wrote:
>> On Wed, Mar 6, 2024 at 9:22 AM Eric Rescorla  wrote:
>>>
>>>
>>> On Wed, Mar 6, 2024 at 8:49 AM Deirdre Connolly
 wrote:
>>>>> Can you say what the motivation is for being "fully
post-quantum" rather than hybrid?
>>>> Sure: in the broad scope, hybrid introduces complexity in the
short-term that we would like to move off of in the long-term -
for TLS 1.3 key agreement this is not the worst thing in the world
and we can afford it, but hybrid is by design a hedge, and
theoretically a temporary one.
>>>
>>> My view is that this is likely to be the *very* long term.
>>
>> Also, the ship has sailed somewhat, right? Like Google Chrome,
Cloudflare, and Apple iMessage already have hybrids shipping (I'm
sure there many more, those are just really popular examples). The
installed base is already very big, and it will be around for a
while, whatever the IETF decides to do.
> People can drop support in browsers fairly easily especially for an
> experimental codepoint. It's essential that this happen: if
everything
> we (in the communal sense) tried had to be supported in
perpetuity, it
> would be a recipe for trying nothing.
>
>> thanks,
>> Rob
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

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

Re: [TLS] Working Group Last Call for ECH

[Dennis Jackson]

+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 to the list [2] on 17 February 2024 will 
be considered last call comments.


Thanks,

Joe, Deirdre, and Sean

[1] https://datatracker.ietf.org/doc/draft-ietf-tls-esni/
[2] https://mailarchive.ietf.org/arch/msg/tls/XUCFuNBSQfSJclkhLW-14DZ0ETg/



___
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] ML-KEM key agreement for TLS 1.3

[Dennis Jackson]

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 cryptographic 
foundations) is worthwhile in my opinion.


On Wed, Mar 13, 2024 at 9:39 PM Deirdre Connolly 
 wrote:


[...] Shaking out all the negotiation decisions is desirable as
well as 'drawing the rest of the owl' for the pure PQ option
implied in the negotiation (are we going to copy the same ~1000
bytes for the PQ and hybrid name groups, when sharing an ephemeral
KEM keypair?).

This is an argument that supporting PQ-only and PQ-hybrid simultaneously 
will be more complex than just PQ-hybrids and require further changes at 
the TLS layer.


Given we've already paid the (minimal) complexity cost of hybrids and 
switching to PQ-only seems strictly less secure, I'm really struggling 
to see the motivation at this point in time. Once we're in a position to 
remove the classical key exchanges from TLS entirely because we know 
they're ineffective, switching to PQ-only might then have more benefit 
since we could retire a lot of old code.




For CNSA 2.0, it is cited not as a compatibility _requirement_ of
TLS, but a note that a non-trivial segment of users of standard
TLS that have been traditionally compliant will not be in a few
years, and they will come knocking anyway. This is trying to skate
where the puck is going.

But also, the fact that CNSA 2.0 explicitly requires ML-KEM _only_
key agreement in the next ~6-9 years is a strong vote of
confidence in any protocol doing this at all, so, TLS wouldn't be
out on a limb to support this, basically.

I don't have a strong opinion on whether this should be
Recommended = Y.

On Wed, Mar 13, 2024 at 6:42 PM Eric Rescorla  wrote:



On Wed, Mar 13, 2024 at 2:36 PM Rebecca Guthrie
 wrote:

Greetings Deirdre and TLS,

I read through draft-connolly-tls-mlkem-key-agreement-00
(and

https://github.com/dconnolly/draft-connolly-tls-mlkem-key-agreement/blob/main/draft-connolly-tls-mlkem-key-agreement.md)
and I have a few comments. First, though, I want to say
thank you for writing this draft. I'll echo some of what
has already been voiced on this thread and say that, while
some plan to use composite key establishment, it makes
sense to also specify the use of standalone ML-KEM in TLS
1.3 as another option. Other WGs (lamps and ipsecme) have
already begun to specify the use of standalone FIPS 203,
204, and 205 in various protocols. With respect to this
draft, there is certainly interest from National Security
System vendors in using standalone ML-KEM-1024 in TLS 1.3
for CNSA 2.0 compliance (as CNSA 2.0 does not require nor
recommend hybrid solutions for security).


I wanted to address this CNSA 2.0 point, as I've now seen it
brought up a couple of times.

The IETF, together with the IRTF, needs to make an independent
judgement on whether using PQ-only algorithms is advisable,
and if we do not think so, then we should not standardize
them, regardless of what CNSA 2.0 requires. The supported
groups registry policies are designed explicitly to allow
people to register non Standards Track algorithms, so nothing
precludes the creation of an ML-KEM only code point if some
vendors find that necessary, without the IETF standardizing
them or marking them as Recommended=Y.
-Ekr



A few specific comments:

1. In Section 1.1 (or Introduction - Motivation in the
github version), I would suggest that the second sentence
("Having a fully post-quantum...") is not needed, i.e.
that there need not be a justification for why it is
necessary to specify how to use ML-KEM in TLS 1.3 (vs.
hybrid). It could be appropriate to contextualize the
specification of ML-KEM w.r.t the advent of a CRQC, though
I also don't think that is necessary. As an example, we
can compare to the Introduction in
draft-ietf-lamps-cms-kyber-03.

2. Section 3 (Construction on github) currently reads, "We
align with [hybrid] except that instead of joining ECDH
options with a KEM, we just have the KEM as a NamedGroup."
I think it is a more useful framing to base this
specification (for the use of a standalone algorithm) off
of RFC 8446 instead of the draft spec for a hybrid
solution. I understand wanting to align the approach with
th

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

[Dennis Jackson]

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 invalidates many of the security claims made 
in RFC 8446. If SSLKEYLOGFILE is in use, the transferred data does not 
benefit from the security protections offered by RFC 8446 and systems 
using SSLKEYLOGFILE cannot be considered compliant with RFC 8446 or 
offering similar security to the protocol outlined in that draft."


I don't think the wording there is quite right, but I do think the 
Security Considerations should clearly call out the impact on forward 
secrecy and RFC 8446 in general and so dissuade use.


Best,
Dennis

On 12/03/2024 23:07, Eric Rescorla wrote:



On Tue, Mar 12, 2024 at 4:04 PM Stephen Farrell 
 wrote:



I'll argue just a little more then shut up...

On 12/03/2024 22:55, Martin Thomson wrote:
>
>> Sorry also for a late suggestion, but how'd we feel about adding
>> some text like this to 1.1?
>>
>> "An implementation, esp. a server, emitting a log file such as this
>> in a production environment where the TLS clients are unaware that
>> logging is happening, could fall afoul of regulatory requirements
>> to protect client data using state-of-the-art mechanisms."

> I agree with Ekr.  That risk is not appreciably changed by the
> existence of a definition for a file format.
I totally do consider our documenting this format increases
the risk that production systems have such logging enabled,
despite our saying "MUST NOT." So if there's a way to further
disincentivise doing that, by even obliquely referring to
potential negative consequences of doing so, then I'd be for
doing that. 



Aside from this particular case, I don't think technical specifications
should "obliquely" refer to things. Technical specifications should be
clear.

-Ekr

Hence my suggestion.

S.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Dennis Jackson]

Just tagging editorial changes which where shared on the list a couple 
of weeks ago [1] to avoid document expiry.


No discussion is planned at IETF 119.

Best,
Dennis

On 16/03/2024 14:09, internet-dra...@ietf.org wrote:

Internet-Draft draft-ietf-tls-cert-abridge-01.txt is now available. It is 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 Compression scheme which
uses a shared dictionary of root and intermediate WebPKI
certificates.  The scheme smooths the transition to post-quantum
certificates by eliminating the root and intermediate certificates
from the TLS certificate chain without impacting trust negotiation.
It also delivers better compression than alternative proposals whilst
ensuring fair treatment for both CAs and website operators.  It may
also be useful in other applications which store certificate chains,
e.g.  Certificate Transparency logs.

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

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

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

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


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

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

[Dennis Jackson]

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, this document offers a 
speculative and subjective discussion of possible future impact.


I do not believe there is any precedent supporting publication.


Best,
Dennis

> On Tue, Jul 23, 2019, 3:47 PM Filippo Valsorda  
> >;
> wrote:
>
> > Before any technical or wording feedback, I am confused as to the nature
> > of this document. It does not seem to specify any protocol change or
> > mechanism, and it does not even focus on solutions to move the web further.
> >
> > Instead, it looks like a well edited blog post, presenting the perspective
> > of one segment of the industry. (The perspective seems to also lack
> > consensus, but I believe even that is secondary.) Note how as of
> > draft-camwinget-tls-use-cases-05 there are no IANA considerations, no
> > security considerations, and no occurrences of any of the BCP 14 key words
> > (MUST, SHOULD, etc.).
> >
> > Is there precedent for publishing such a document as an RFC?
> >
>
> I was going to say RFC 691 but no, it recommends changes to the protocol
> (as well as being quite amusing). RFC 4074 comes close describing bad
> behavior without an explicit plea to stop doing it, but has a security
> considerations section. RFC 7021 describes the impact of a particular
> networking technique on applications.
>
> So there is precedent.
>
> Sincerely,
> Watson

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

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

[Dennis Jackson]

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 ramifications on the deployments of our
> solutions. This means, understanding exactly how the market uses and
> needs to use the solutions we create. When we remove or change some
> technology, we should try hard to provide a work around. If a work
> around is not possible, we need to cleanly document how these changes
> are going to impact the market so it can prepare. This is the
> responsible and prudent thing to do in a professional organization like
> the IETF. 
> 

The IETF is for development of Internet Standards. If you want to
publish your (subjective) analysis of how a particular standard is going
to impact your market segment, there are any number of better venues:
trade magazines, industry associations, your company website, etc.

> The draft that Nancy and others have worked on is a great start to
> documenting how these new solutions are going to impact organizational
> networks. Regardless of whether you like the use-cases or regulations
> that some organizations have, they are valid and our new solutions are
> going to impact them. 

This isn't a question of quality. The IETF simply doesn't publish
documents of this nature (to my knowledge).

> Thanks,
> Bret
> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
> "Without cryptography 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 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, this document offers a 
>> speculative and subjective discussion of possible future impact.
>>
>>
>> I do not believe there is any precedent supporting publication.
>>
>>
>> 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] TLS Impact on Network Security draft updated

[Dennis Jackson]

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 ramifications on the deployments of our
>>> solutions. This means, understanding exactly how the market uses and
>>> needs to use the solutions we create. When we remove or change some
>>> technology, we should try hard to provide a work around. If a work
>>> around is not possible, we need to cleanly document how these changes
>>> are going to impact the market so it can prepare. This is the
>>> responsible and prudent thing to do in a professional organization like
>>> the IETF. 
>>>
>>
>> The IETF is for development of Internet Standards. If you want to
>> publish your (subjective) analysis of how a particular standard is going
>> to impact your market segment, there are any number of better venues:
>> trade magazines, industry associations, your company website, etc.
> 
> Actually, the Independent stream of the RFC series is purpose-built for
> individual commentary on the consequences of a particular standard
> [including in a particular segment], and would be superior (at least in
> my opinion) to any of the venues you list.  (See RFC 4846.)  But I
> believe the current ISE asks authors to try fairly hard to publish their
> work in the IETF before accepting it to the Indepndent stream.

I was thinking of 'published by the IETF' to mean the IETF stream.
Publishing in the Independent stream, without any proper review,
consensus or claim of fitness is a different matter altogether.

>>> The draft that Nancy and others have worked on is a great start to
>>> documenting how these new solutions are going to impact organizational
>>> networks. Regardless of whether you like the use-cases or regulations
>>> that some organizations have, they are valid and our new solutions are
>>> going to impact them. 
>>
>> This isn't a question of quality. The IETF simply doesn't publish
>> documents of this nature (to my knowledge).
> 
> The IETF can publish whatever there is IETF consensus to publish.  (And
> a little bit more, besides, though that is probably not relevant to the
> current discussion.)
> 
> I don't have a great sense of what you mean by "documents of this
> nature".  If you were to say "the IETF does not publish speculative and
> subjective discussion of possible future impact", I'd be fairly likely
> to agree with you (but I have also seen a fair bit of speculation get
> published).  

This was my intended meaning.

I'd feel rather differently about "the IETF does not
> publish objective analysis of the consequences of protocol changes on
> previously deployed configurations", and would ask if you think a
> document in the latter category is impossible for the TLS 1.2->1.3
> transition.  (My understanding is that the latter category of document
> is the desired proposal, regardless of the current state of the draft in
> question.)

The authors initiated this discussion by stating their draft was stable
and requesting publication. Consequently, I think it must be judged on
the current state, rather than the desired outcome.

Even considering your more generous interpretation... the objective
discussion is only 3 out of 15 pages and none of the 5 claims appears to
be correct. (As others have pointed out).

Best,
Dennis

> -Ben
> 
> 

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

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

[Dennis Jackson]

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 so close to the meeting.


Firstly, the draft as specified does not achieve the claimed security goal:


Security Considerations:

To perform public key encryption the sender needs to have access to 
the public key of the recipient. This document makes the assumption 
that the public key in the exchanged end-entity certificate can be 
used with the HPKE KEM. The use of HPKE, and the recipients long-term 
public key, in the ephemeral-static Diffie-Hellman exchange provides 
perfect forward secrecy of the ongoing connection and demonstrates 
possession of the long-term secret key.


An ephemeral-static Diffie-Hellman exchange does not provide forward 
secrecy. If the attacker can compromise the endpoint with the static 
public key, they can decrypt all previously transmitted ciphertexts to 
this peer and so recover all past keys, violating forward secrecy. This 
wasn't an issue in the old draft where ephemeral-ephemeral DH exchanges 
were used.


Secondly, I think there is some confusion about what forward secrecy is. 
Forward secrecy means that compromise in the future will not enable the 
decryption of past messages. The existing KeyUpdate mechanism in TLS1.3 
achieves forward secrecy by ratcheting forwards the used keys and 
throwing away the old ones. So no changes are required to TLS1.3 to 
enjoy forward secrecy in long-lived connections, just do the existing 
key update and be sure to throw away the old keys correctly.



Introduction:

If a traffic secret (referred as application_traffic_secret_N) has 
been compromised, an attacker can passively eavesdrop on all future 
data sent on the connection, including data encrypted with 
application_traffic_secret_N+1, application_traffic_secret_N+2, etc.


This is not forward secrecy but post-compromise security (PCS) [1] 
(sometimes called Backwards Secrecy as it is the complement of Forward 
Secrecy). As the draft identifies, a fresh key exchange is needed to 
ensure PCS. However, as mentioned earlier in the PFS case, this key 
exchange needs to be with freshly generated ephemeral keys. It does no 
good to use an existing static key since the attacker might have already 
compromised it.


Finally, I'm really not sure about the decision to mix the TLS and 
Application layers by having the application carry the HPKE ciphertexts. 
This seems rather complex and likely to go wrong. The original version 
of this draft where the key exchange was carried in the extended key 
update message seems much simpler to implement and easier to analyse.


If the authors do want to go with some kind of application specific key 
exchange, I would suggest rethinking this draft as purely a way to bring 
entropy into the TLS1.3 key exchange, a TLS1.3 Key Importer if you will. 
This would work by having the application to signal to the TLS1.3 layer 
that a key was ready to be imported (with a particular key-id and key 
material). The TLS library would communicate this to the peer with a 
message similar to the one currently defined in the draft carrying the 
key-id. The new key material would be mixed to the current secret in 
when the peer confirmed it had also been passed the key id and material 
by its application. The details about some kind of application layer key 
exchange would then need to go in a different document and use 
ephemeral-ephemeral exchange as highlighted.


Given the complexities around the use of middleboxes which may not be 
available to the peers, it might be necessary to use an exported 
authenticator so the applications could confirm they were sharing a 
single TLS connection and not two duct-taped together (which would be 
unable to successfully import new keys). This seems like a like of 
complexity compared to the initial draft.


Best,
Dennis

[1] https://eprint.iacr.org/2016/221.pdf

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

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

[Dennis Jackson]

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 - not dissimilar to how the 
application has to decide which root certificates to trust and whether 
the leaf certificate is appropriate for the intended connection (e.g. 
browsers extract the valid identities from the SAN).


Best,
Dennis

On 28/03/2024 15:22, John Mattsson wrote:


Hi,

I looked into what RFC 8446(bis) says about Raw Public Keys. As 
correctly stated in RFC 8446, TLS 1.3 with signatures and certificates 
is an implementation of SIGMA-I:


SIGMA does however require that the identities of the endpoints 
(called A and B in [SIGMA]) are included in the messages. This is not 
true for TLS 1.3 with RPKs and TLS 1.3 with RPKs is therefore not 
SIGMA. TLS 1.3 with RPKs is vulnerable to what Krawczyk’s SIGMA paper 
calls misbinding attacks:


“This attack, to which we refer as an “identity misbinding attack”, 
applies to many seemingly natural and intuitive protocols. Avoiding 
this form of attack and guaranteeing a consistent binding between a 
session key and the peers to the session is a central element in the 
design of SIGMA.”


“Even more significantly we show here that the misbinding attack 
applies to this protocol in any scenario where parties can register 
public keys without proving knowledge of the corresponding signature key.”


As stated in Appendix E.1, at the completion of the handshake, each 
side outputs its view of the identities of the communicating parties. 
On of the TLS 1.3 security properties are “Peer Authentication”, which 
says that the client’s and server’s view of the identities match. TLS 
1.3 with PRKs does not fulfill this unless the out-of-band mechanism 
to register public keys proved knowledge of the private key. RFC 7250 
does not say anything about this either.


I think this needs to be clarified in RFC8446bis. The only reason to 
ever use an RPK is in constrained IoT environments. Otherwise a 
self-signed certificate is a much better choice. TLS 1.3 with 
self-signed certificates is SIGMA-I.


It is worrying to find comments like this:

“I'd like to be able to use wireguard/ssh-style authentication for my 
app. This is possible currently with self-signed certificates, but the 
proper solution is RFC 7250, which is also part of TLS 1.3.”


https://github.com/openssl/openssl/issues/6929

RPKs are not the proper solution.

(Talking about misbinding, does RFC 8446 say anything about how to 
avoid selfie attacks where an entity using PSK authentication ends up 
talking to itself?)


Cheers,

John Preuß Mattsson

[SIGMA] https://link.springer.com/chapter/10.1007/978-3-540-45146-4_24


___
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] Adoption call for TLS Flag - Request mTLS

[Dennis Jackson]

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 
the single entry 0 (X509). You also have the option of using a value 
assigned for private use (224 and up) for your specific use case of 
indicating a search engine crawler willing to provide a client cert.


Best,
Dennis

On 04/04/2024 11:17, Jonathan Hoyland wrote:

Hi all,

Thanks for the feedback here.

With respect to RFC 7250, as I mentioned earlier on list, there seen 
to be two issues. First it changes the semantics of the extension 
slightly, and second the RFC explicitly excludes x.509 certs.


IIUC the semantics of the extension are "I have a weird client cert", 
not "I have a client cert".


With respect to whether this needs to be a working group item, I'm not 
particularly averse to this being an independent document if that's 
where the WG thinks it should go.
In my opinion, however, there are two things that it would be good to 
get input from the TLS WG on.


One, this is a change from all previous versions of TLS in which the 
client cannot induce auth, does enabling this break anyone's assumptions?


Two, I'd like a low flag number because it saves bytes on the wire, 
but there is a discussion to be had as to how common this flag will be 
versus other flags.
(Non-attack) Bot traffic is very common, but it's not the majority of 
traffic by any means.


Regards,

Jonathan



On Thu, 4 Apr 2024, 01:17 Christopher Patton, 
 wrote:


It would be great to here from Jonathan (the author) if RFC 7250
is already sufficient for this use case.

On Tue, Apr 2, 2024 at 10:23 PM Mohit Sethi  wrote:

Please see my earlier comment regarding this draft:
https://mailarchive.ietf.org/arch/msg/tls/g3tImSVXO8AEmPH1UlwRB1c1TLs/

In summary: the functionality of this draft is already
achievable by
using the client_certificate_type extension defined in RFC 7250:
https://datatracker.ietf.org/doc/html/rfc7250 with certificate
type
value = 0:

https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#tls-extensiontype-values-3.

The table in section 4.2 of RFC8446 even mentions that the
extension can
be included in the ClientHello:
https://datatracker.ietf.org/doc/html/rfc8446#section-4.2,
thereby
ensuring that the server sends a CertificateRequest message in
response
to the ClientHello received.

OpenSSL already implements this extension since it was needed for
support raw public keys (RPKs).

As stated earlier: if it is indeed the case that the
client_certificate_type extension is suitable for the
use-case, then
perhaps it is preferable to not have a separate flag.
Otherwise, it
would make the state machine at the server more complicated (for
example: handling a ClientHello with both the mTLS flag and the
client_certificate_type extension.

Therefore, like Ekr, I am mildly negative on adopting this
document but
for different reasons.

--Mohit

On 4/3/24 00:52, Sean Turner wrote:
> At the IETF 119 TLS session there was some interest in the
mTLS Flag I-D

(https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-jhoyla-req-mtls-flag%2F&data=05%7C02%7Cmohit.sethi%40aalto.fi%7C42877de6d3d64135e49e08dc534a463b%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638476825681199391%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=ERzWFcuBlAfobNyGCcgKDhCl9wex9LOQ%2F3yPYC7idfU%3D&reserved=0

);
also, see previous list discussions at [0]. This message is to
judge consensus on whether there is sufficient support to
adopt this I-D.  If you support adoption and are willing to
review and contribute text, please send a message to the
list.  If you do not support adoption of this I-D, please send
a message to the list and indicate why.  This call will close
on 16 April 2024.
>
> Thanks,
> Deirdre, Joe, and Sean
>
> [0]

https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm

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

[Dennis Jackson]

Ah, I wonder what the motivation was for it being a MUST rather than a 
SHOULD.


That still leaves open sending a private use value - which would allow 
you to de-conflict with others uses.



On 04/04/2024 17:11, Jonathan Hoyland wrote:

Hi Dennis,

RFC 7250 Section 4.1 says:
If the client has 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 Jackson, 
 wrote:


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 the single entry 0 (X509). You also have the option
of using a value assigned for private use (224 and up) for your
specific use case of indicating a search engine crawler willing to
provide a client cert.

Best,
Dennis

On 04/04/2024 11:17, Jonathan Hoyland wrote:

Hi all,

Thanks for the feedback here.

With respect to RFC 7250, as I mentioned earlier on list, there
seen to be two issues. First it changes the semantics of the
extension slightly, and second the RFC explicitly excludes x.509
certs.

IIUC the semantics of the extension are "I have a weird client
cert", not "I have a client cert".

With respect to whether this needs to be a working group item,
I'm not particularly averse to this being an independent document
if that's where the WG thinks it should go.
In my opinion, however, there are two things that it would be
good to get input from the TLS WG on.

One, this is a change from all previous versions of TLS in which
the client cannot induce auth, does enabling this break anyone's
assumptions?

Two, I'd like a low flag number because it saves bytes on the
wire, but there is a discussion to be had as to how common this
flag will be versus other flags.
(Non-attack) Bot traffic is very common, but it's not the
majority of traffic by any means.

Regards,

Jonathan



On Thu, 4 Apr 2024, 01:17 Christopher Patton,
 wrote:

It would be great to here from Jonathan (the author) if RFC
7250 is already sufficient for this use case.

On Tue, Apr 2, 2024 at 10:23 PM Mohit Sethi  wrote:

Please see my earlier comment regarding this draft:

https://mailarchive.ietf.org/arch/msg/tls/g3tImSVXO8AEmPH1UlwRB1c1TLs/

In summary: the functionality of this draft is already
achievable by
using the client_certificate_type extension defined in
RFC 7250:
https://datatracker.ietf.org/doc/html/rfc7250 with
certificate type
value = 0:

https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#tls-extensiontype-values-3.

The table in section 4.2 of RFC8446 even mentions that
the extension can
be included in the ClientHello:
https://datatracker.ietf.org/doc/html/rfc8446#section-4.2,
thereby
ensuring that the server sends a CertificateRequest
message in response
to the ClientHello received.

OpenSSL already implements this extension since it was
needed for
support raw public keys (RPKs).

As stated earlier: if it is indeed the case that the
client_certificate_type extension is suitable for the
use-case, then
perhaps it is preferable to not have a separate flag.
Otherwise, it
would make the state machine at the server more
complicated (for
example: handling a ClientHello with both the mTLS flag
and the
client_certificate_type extension.

Therefore, like Ekr, I am mildly negative on adopting
this document but
for different reasons.

--Mohit

On 4/3/24 00:52, Sean Turner wrote:
> At the IETF 119 TLS session there was some interest in
the mTLS Flag I-D

(https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-jhoyla-req-mtls-flag%2F&data=05%7C02%7Cmohit.sethi%40aalto.fi%7C42877de6d3d64135e49e08dc534a463b%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638476825681199391%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=ERzWFcuBlAfobNyGCcgKDhCl9wex9LOQ%2F3yPYC7idfU%3D&reserved=0

<https://eur01.safelinks

Re: [TLS] WG Adoption for TLS Trust Expressions

[Dennis Jackson]

When this work was presented at IETF 118 in November, several 
participants (including myself, Stephen Farrell and Nicola Tuveri) came 
to the mic to highlight that this draft's mechanism comes with a serious 
potential for abuse by governments (meeting minutes 
). 



Although the authors acknowledged the issue in the meeting, no changes 
have been made since to either address the problem or document it as an 
accepted risk. I think its critical one of the two happens before this 
document is considered for adoption.


Below is a brief recap of the unaddressed issue raised at 118 and some 
thoughts on next steps:


Some governments (including, but not limited to Russia 
, 
Kazakhstan 
, 
Mauritius 
) 
have previously established national root CAs in order to enable mass 
surveillance and censorship of their residents' web traffic. This 
requires trying to force residents to install these root CAs or adopt 
locally developed browsers which have them prepackaged. This is widely 
regarded as a bad thing (RFC 7258 
).


Thankfully these efforts have largely failed because these national CAs 
have no legitimate adoption or use cases. Very few website operators 
would voluntarily use certificates from a national root CA when it means 
shutting out the rest of the world (who obviously do not trust that root 
CA) and even getting adoption within the country is very difficult since 
adopting sites are broken for residents without the national root cert.


However, this draft provides a ready-made solution to this adoption 
problem: websites can be forced to adopt the national CA in addition to, 
rather than replacing, their globally trusted cert. This policy can even 
be justified in terms of security from the perspective of the 
government, since the national CA is under domestic supervision (see 
https://last-chance-for-eidas.org). This enables a gradual roll out by 
the government who can require sites to start deploying certs from the 
national CA in parallel with their existing certificates without any 
risk of breakage either locally or abroad, solving their adoption problem.


Conveniently, post-adoption governments can also see what fraction of 
their residents' web traffic is using their national CA via the 
unencrypted trust expressions extension, which can inform their 
decisions about whether to block connections which don't indicate 
support for their national CA and as well advertising which connections 
they can intercept (using existing methods like mis-issued certs, key 
escrow) without causing a certificate error. This approach also scales 
so multiple countries can deploy national CAs with each being able to 
surveil their own residents but not each others.


Although this may feel like a quite distant consequence of enabling 
trust negotiation in TLS, the on-ramp is straightforward:


 * Support for trust negotiation gets shipped in browsers and servers
   for ostensibly good reasons.
 * A large country or federation pushes for recognition of their
   domestic trust regime as a distinct trust store which browsers must
   advertise. Browsers agree because the relevant market is too big to
   leave.
 * Other countries push for the same recognition now that the dam is
   breached.
 * Time passes and various local cottage industries of domestic CAs are
   encouraged out of national interest and government enabled rent
   seeking.
 * One or more countries start either withholding certificates for
   undesirable sites, blocking connections which don't use their trust
   store, requiring key escrow to enable interception, etc etc.

Besides the above issue which merits some considered discussion, I would 
also suggest fleshing out the use cases & problems that this draft is 
trying to solve.


Firstly because its not clear why simpler solutions don't suffice. For 
example, backwards compatible root key rotation could solved by signing 
the new root with the old root, then using existing drafts like 
intermediate suppression or abridged certs to eliminate the overhead of 
both certs for up to date clients. This would largely eliminate the 
problems raised around support for old devices.


Secondly the current proposal requires a fairly substantial amount of 
coordination between server operators, ACME vendors, CAs, browsers and 
browser providers and its unclear whether there are enough incentives in 
place to actually see the folk deploy the technology in an effective 
way. Sketching out a couple of key deployment scenarios and what 
fraction of each population would need to embrace

Re: [TLS] WG Adoption for TLS Trust Expressions

[Dennis Jackson]

Thanks <https://last-chance-for-eidas.org/>, I 
<https://security.googleblog.com/2023/11/qualified-certificates-with-qualified.html> 
am 
<https://www.google.com/search?q=site%3Aapple.com+eidas+-podcast+-music+-store&sca_esv=30517ea669904188&ei=QEMwZvmdAc2lhbIPpY6Q4AY&ved=0ahUKEwj5vZ7x3uiFAxXNUkEAHSUHBGwQ4dUDCBA&uact=5&oq=site%3Aapple.com+eidas+-podcast+-music+-store&gs_lp=Egxnd3Mtd2l6LXNlcnAiK3NpdGU6YXBwbGUuY29tIGVpZGFzIC1wb2RjYXN0IC1tdXNpYyAtc3RvcmVI2RBQmAVY7A9wAXgAkAEAmAHCAaABlQSqAQM1LjG4AQPIAQD4AQGYAgCgAgCYAwCIBgGSBwCgB44C&sclient=gws-wiz-serp> 
aware 
<https://www.google.com/search?q=site%3Ablogs.microsoft.com+eidas&sca_esv=30517ea669904188&tbs=cdr%3A1%2Ccd_min%3A1%2F1%2F2021&ei=okMwZoivKbCMhbIP1vOquAg&ved=0ahUKEwiIiKSg3-iFAxUwRkEAHda5CocQ4dUDCBA&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 largely failed because these national 
CAs have no legitimate adoption or use cases. Very few website 
operators would voluntarily use certificates from a national root CA 
when it means shutting out the rest of the world (who obviously do 
not trust that root CA) and even getting adoption within the country 
is very difficult since adopting sites are broken for residents 
without the national root cert.


There are ways to promote adoption of a government-mandated CA. The 
stumbling point is usually browser vendors, e.g. 
https://blog.mozilla.org/netpolicy/files/2021/05/Mozillas-Response-to-the-Mauritian-ICT-Authoritys-Consultation.pdf


I see that you already mentioned BCP 188.

Regards,
S. Moonesamy
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[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

[Dennis Jackson]

to 
reconfigure servers without the server operator actively opting in.


3) One of the extremely questionable acts that a CA might be 
incentivised to do is provision a certificate chain from a domestic 
government operated CA alongside the intended one. Helpfully bypassing 
the need to convince website operators to use them.


This 3rd problem is exactly what I've been highlighting. If you're 
trying to build a domestic government controlled PKI, you run into a 
huge adoption challenge:


 * No website wants to change to use your government controlled PKI,
   because the user's don't support it and the rest of the world won't
   ever have it, so the site is effectively blocked.
 * There's no legitimate reason for a user to want to install the
   government controlled root, because there's no sites that are using.

This draft very neatly solves that challenge. You can provision a large 
number of sites with the government cert chain with little work. You 
don't even need consent if you use the CA method as you described. Those 
sites remain available to both local and international visitors so they 
don't really mind unless they're the kind of site with strong opinions 
about internet privacy. You can start to push your domestic users onto 
using your domestic root store with the argument that a) its locally 
supervised so its great and b) loads of local sites already support it. 
Later, you have the latitude to start misbehaving or blocking traffic 
that doesn't advertise your root store.


Reading between the lines, you seem like a person who would not 
ordinarily be in favour of trusting CAs with TLS configuration 
decisions, or making it easier to spin up a CA and so increasing the 
number of trusted CAs in the world, or having a fragmented PKI along 
national borders. This draft directly enables all three 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
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


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WG Adoption for TLS Trust Expressions

[Dennis Jackson]

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] Adoption Call for draft-davidben-tls-key-share-prediction

[Dennis Jackson]

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 on feedback since then.
>The current draft is available here:
>https://datatracker.ietf.org/doc/draft-davidben-tls-key-share-prediction/.
>Please read the document and indicate if and why you support or do not
>support adoption as a TLS working group item. If you support adoption
>please, state if you will help review and contribute text to the document.
>Please respond to this call by May 20, 2024.
>
>Thanks,
>
>Joe, Deidre, and Sean
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WG Adoption for TLS Trust Expressions

[Dennis Jackson]

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 Expressions make things 
worse?".Although Watson observed that the answer to this is at least 
'somewhat', I agree such a world is already maxed at 10/10 on the 
bad worlds to live in scale and so it's not by itself a major problem in 
my view.


The actual concern is: to what extent do Trust Expressions increase the 
probability that we end up in this unhappy world of government CAs used 
for mass surveillance?


The case made earlier in the thread is that it increases the probability 
substantially because it provides an effective on-ramp for new CAs even 
if they exist entirely outside of existing root stores. Websites can 
adopt such a CA without being completely broken and unavailable as they 
would be today. Although I think it's unlikely anyone would 
independently do this, it's easy to see a website choosing to add such a 
certificate (which is harmless by itself) if a government 
incentivized or required it.  Trust Expressions also enables existing 
CAs to force-push a cert chain from a new CA to a website,  without the 
consent or awareness of the website operator, further enabling the 
proliferation of untrusted (and presumably unwanted) CAs.


These features neatly solve the key challenges of deploying a government 
CA, which as discussed at length in the thread, are to achieve enough 
legitimacy through website adoption to have a plausible case for 
enforcing client adoption. The real problem here is that you've 
(accidentally?) built a system that makes it much easier to adopt and 
deploy any new CA regardless of trust, rather than a system that makes 
it easier to deploy & adopt any new *trusted* CA. If you disagree with 
this assessment, it would be great to hear your thoughts on why. 
Unfortunately, none of the arguments in your email come close to 
addressing this point and the text in the draft pretty much tries to 
lampshade these problems as a feature.


The other side of this risk evaluation is assessing how effectively 
Trust Expressions solves real problems.


Despite a lot of discussion, I've only seen one compelling unsolved 
problem which Trust Expressions is claimed to be able to solve. That is 
the difficulty large sites have supporting very old clients with 
out-of-date root stores (as described by Kyle). This leads to sites 
using complex & brittle TLS fingerprinting to decide which certificate 
chain to send or to sites using very particular CAs designed to 
maximizecompatibility (e.g. Cloudflare's recent change).


However, it's unclearhow Trust Expressions solves either fingerprinting 
or the new trusted root ubiquity challenge. To solve the former, we're 
relying on the adoption of Trust Expressions by device manufacturers who 
historically have not been keen to adopt new TLS extensions. For the 
latter, Trust Expressions doesn't seem to solve anything. Sites / CDNs 
are still forced to either have a business arrangement with a single 
suitably ubiquitous root or to conclude multiple such arrangements 
(which come with considerable baggage) with both new and ubiquitous 
roots - in return for no concrete benefit. Ifwe had Trust 
Expressions deployed today, how would life be better for LE / Cloudflare 
or other impacted parties?


I won't detail them here, but it seems like there are simpler and more 
effective alternatives that would address the underlying problem, e.g. 
through root stores encouraging cross-signing or offering cross-signing 
services themselves and using existing techniques to avoid any impact at 
the TLS layer.


I'm struggling to see it being an even partially effective solution for 
any of the other proposed use cases. To pick an example you've 
repeatedly highlighted, can you clarify how Trust Expressions will speed 
the transition to a PQ PKI? Specifically, how much earlier do you expect 
a given site to be able to deploy a PQ cert chain in the case of TE 
adoption vs without TE adoption (and why)?


David, Devon & Bob wrote:

We acknowledge that achieving this level of agility requires a 
significant amount of design and implementation work for web servers, 
certificate automation clients/servers, and clients to support, but 
we believe the improvements called out in some of the discussions on 
this thread strongly outweigh these costs [...]


[...] We think this will drastically improve the ability to migrate 
the Internet to PQC—not just in terms of a faster timeline, but 
because trust anchor agility will enable the community to develop 
fundamentally better solutions for authentication, through reduced 
experimentation costs


I can completely understand why Trust Expressions seems to bring 
substantial benefits to *you*  (as root store operators) but I'm m

[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: WG Adoption for TLS Trust Expressions

[Dennis Jackson]

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 that I didn't consider. From my 
analysis, if I were a government looking to enable surveillance and 
domestic control of the Web, I don't see Trust Expressions as 
something that unlocks new options or makes existing techniques 
easier/more reliable. It is at most something to keep in mind as 
technology evolves. Maybe I'm not very imaginative, and you've 
imagined much more interesting ways a government might surveil the web 
or attempt to control it using Trust Expressions.


This thread is now 40+ messages deep and I guess you might have not seen 
much of the previous discussion. I actually agree with much of your 
analysis, but it focused on the wrong question, as I wrote earlier in 
this thread:


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 Expressions make 
things worse?" Although Watson observed that the answer to this is at 
least 'somewhat', I agree such a world is already maxed at 10/10 on 
the bad worlds to live in scale and so it's not by itself a major 
problem in my view.


The actual concern is: to what extent do Trust Expressions increase 
the probability that we end up in this unhappy world of government CAs 
used for mass surveillance?


On 21/05/2024 19:05, Nick Harper wrote:


I'd be interested to hear details on what those are.

Messages [1,2,3,4] of this thread lay out these details at length.

Besides these concerns which are unaddressed so far, much of the recent 
discussion has focused on establishing what problem(s) Trust Expressions 
actually solves and how effective a solution it actually is.


Looking forward to your thoughts on either or both aspects.

Best,
Dennis

[1] https://mailarchive.ietf.org/arch/msg/tls/LaUJRHnEJds2Yfc-t-wgzkajXec/

[2] https://mailarchive.ietf.org/arch/msg/tls/zwPvDn9PkD5x9Yw1qul0QV4LoD8/

[3] https://mailarchive.ietf.org/arch/msg/tls/9AyqlbxiG7BUYP0UD37253MeK6s/

[4] https://mailarchive.ietf.org/arch/msg/tls/fxM4zkSn0b8zOs59xlH6uy8P7cE/



___
TLS mailing list --tls@ietf.org
To unsubscribe send an email totls-le...@ietf.org___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: WG Adoption for TLS Trust Expressions

[Dennis Jackson]

mitted had 
Trust Expressions been used instead.


A compressed intermediate certificate in Abridged Certs occupies two 
bytes on the wire. Somewhat smaller than the Trust Expressions extension 
:-).


The server-side storage space required is negligible, 34 bytes per 
intermediate certificate (32 byte hash, 2 byte identifier). The 
client-side storage space required is 2 bytes per intermediate 
certificate (since we already ship the full set of intermediates to 
clients). The dictionary format has also been ordered to support 
multiple versions without needing to store the redundant data. So in 
short, much less than the multiple extra certificate chains that Trust 
Expressions demands.


The second example is when a new CA wants to launch. The existing 
mechanism requires a new entrant to the space to make a business deal 
with one of its potential competitors to be able to usefully enter the 
market. This sounds like a bug, not a feature, of the system.


Firstly, Trust Expressions also requires these business deals. Website 
Operators need both a chain from the new CA and an existing trusted CA. 
This requires either the subscriber to have a business relationship with 
the existing CA, or the new CA to have a business relationship with them.


Secondly, unlike Trust Expressions, cross signing actually solves this. 
Further, root store operators can encourage cross signing if they so wish.




In [12], you suggest that Trust Expressions encourages CA operators to 
more slowly transition to a PQC PKI, and that this is undesirable. In 
the transition to a PQC PKI, there will be experiments with different 
approaches, and different CA operators may choose different approaches 
to implement on different schedules. The incentive for CA operators to 
move quickly instead of waiting for others to pave the way is to meet 
the demand of servers that want PQC certs early.
We're not worried about the CAs at the front of the pack, who will look 
to innovate no matter what. We're worried about the CAs that make up the 
long tail.


 Servers that use trust expressions can be more confident that they 
are using a certificate chain trusted by their diverse set of clients 
(and monitor which trust expressions they don't support so they can 
adjust their certificate order configuration to close gaps if they 
want to support those clients).


What do you mean by 'more confident'? They already know whether the 
chain is accepted or not based on whether the connection goes through. 
You seem to be imagining that having to maintain relationships with 
multiple CAs to be present in multiple trust stores is a feature for 
website operators, rather than a huge burden. Best case is that they 
will do much as they do today and simply pick one CA which is 
ubiquitous, so Trust Expressions doesn't help.


CA operators benefit by being able to issue certs from their new roots 
sooner without needing to wait for ubiquity or having server operators 
complain that they don't work.
Only by carrying out a business agreement with a more widely trusted CA, 
just as they would for a cross sign.


Root programs benefit by being able to more easily make changes with 
less risk of breakage (e.g. policy changes like root key lifetimes, 
and breakage due to the inability for servers to provide a set of 
certificates that both old and new clients can build valid paths for).


Cross Signing actually solves both of these problems as we've already 
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 
 wrote:



Although Watson observed that the answer to this is at least
'somewhat', I agree such a world is already maxed at 10/10 on the
bad worlds to live in scale and so it's not by itself a major
problem in my view.


I don't see Watson saying that in any of his messages [5] [6] [7].

On 01/05/2024 00:07, Watson Ladd wrote:


I think the sharper concern is that you could block traffic without the cert 
included.

Watson can of course speak for himself in this matter.___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: WG Adoption for TLS Trust Expressions

[Dennis Jackson]

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 Expressions enables government 
surveillance, something has been repeatedly debunked by multiple 
people in this thread, all of whom are attempting to discuss in good 
faith. And yet, each time someone does this, you change the shape of 
your argument, claim there is more nuance that no one except you can 
see, and describe some easily debunked partial scenario that you 
believe to be worse.


This is, politely, hogwash and a rather shabby attempt to portray this 
as a one-sided discussion.


I have presented a single consistent argument about how Trust 
Expressions solves a key deployment challenge for parties trying to 
perform this kind of abuse. This argument has not changed over the 
course of the thread, as I noted in my latest reply to Nick, this was 
just a summary of the previous discussion.


This argument has been supported by others in the thread, in particular 
by Stephen Farrell:


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. 


Meanwhile, the four loudest voices who deny there are legitimate 
concerns around this proposal all work for the same team at Google and 
have announced their intent to prototype this technology already [1].


The majority of the participants in this thread have engaged with these 
discussions with curiosity and have yet to voice any conclusion. I am 
sure they will do so when they have made up their minds.


My personal reading has been that folks who have engaged in the 
discussion would agree there is both reasonable concern about how 
effective T.E. is at solving the problems it claims to and that the 
risks of abuse cannot be dismissed as easily as the authors would like.


It may be worth taking a step back, and considering if the people you 
have worked with for nearly a decade or more, and who have been 
instrumental in improving TLS over the years, have truly suddenly 
decided to pivot to attempting to backdoor mass surveillance through 
the IETF.


I have noted throughout that this is a complex topic which reasonable 
people may disagree on. I have a great deal of respect for the authors 
who I know are acting out of genuine intent to improve the world. We 
simply disagree on whether the proposed design is likely to effective at 
solving the problems it sets out and how seriously it could be abused by 
others.




A few replies relating to surveillance are inline.

-dadrian

> I think we have to agree that Trust Expressions enables websites to 
adopt new CA chains regardless of client trust and even builds a 
centralized mechanism for doing so. It is a core feature of the design.


No one has to agree to this because you have not backed this claim at 
all. Nick sent two long emails explaining why this was not the case, 
both of which you have simply dismissed [...]


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 Benjamin, writing on behalf of Devon and Bob as well:

By design, a multi-certificate model removes the ubiquity requirement 
for a trust anchor to be potentially useful for a server operator.


[...]

Server operators, once software is in place, not needing to be 
concerned about new trust expressions or changes to them. The heavy 
lifting is between the root program and the CA.

From the Draft (Section 7):

Subscribers SHOULD use an automated issuance process where the CA 
transparently provisions multiple certification paths, without changes 
to subscriber configuration.
The CA can provision whatever chains it likes without the operator's 
involvement. These chains do not have to be trusted by any clients. This 
is a centralized mechanism which allows one party (the CA) to ship 
multiple chains of its choice to all of its subscribers. This obviously 
has beneficial use cases, but there are also cases where this can be abused.


Can you explain, specifically, the government and site action that you 
expect that will result in surveillance, keeping in mind that ACME 
_already_ allows the CA to provide a bundle of untrusted 
intermediates? What is the chain of events here? What are the actions 
you see taken by a government, a CA, site owners, and root programs?


CA provided intermediates doesn't offer any long term transition without 
Trust Expressions. You could absolutely stuff the domestic CA in there 
on some short term basis, but you're never going to be able to take out 
the WebPKI recognized intermediate (for all the folks connecting without 
the domestic CA). As a resu

[TLS]Re: WG Adoption for TLS Trust Expressions

[Dennis Jackson]

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 Benjamin, writing on behalf of Devon and Bob as well:


By design, a multi-certificate model removes the ubiquity
requirement for a trust anchor to be potentially useful for a
server operator.

[...]

Server operators, once software is in place, not needing to be
concerned about new trust expressions or changes to them. The
heavy lifting is between the root program and the CA.

From the Draft (Section 7):


Subscribers SHOULD use an automated issuance process where the CA
transparently provisions multiple certification paths, without
changes to subscriber configuration.

The CA can provision whatever chains it likes without the
operator's involvement. These chains do not have to be trusted by
any clients. This is a centralized mechanism which allows one
party (the CA) to ship multiple chains of its choice to all of its
subscribers. This obviously has beneficial use cases, but there
are also cases where this can be abused.


Hi Dennis,

Since you seem to be trying to speak on my behalf, I'm going to go 
ahead and correct this now. This is not true. I think you have 
misunderstood how this extension works. [...]



Hi David,

The certification chains issued to the server by the CA comes tagged 
with a list of trust stores its included in. The named trust stores are 
completely opaque to the server. These chains and names may not be 
trusted by any client nor approved by any server, they are issued solely 
by the CA as opaque labels. These chains sit on the server and will not 
be used unless a client connects with the right trust store label but 
obviously can easily be scanned for by anyone looking to check how 
pervasively deployed the alternate trust store is.


Do you dispute any part of that? Most of what you wrote went off on a 
completely different tangent.


Of course, whether this property (whether servers can usefully 
pre-deploy not-yet-added trust anchors), which trust expressions does 
not have, even matters boils to whether a root program would 
misinterpret availability in servers as a sign of CA trustworthiness, 
when those two are clearly unrelated to each other.


Again, my primary concern here is not around the behavior of individual 
root stores, this is not relevant to the concern I'm trying to 
communicate to you. I know folks from all of the major root stores have 
great faith in their judgement and technical acumen.


My concern is that Trust Expressions upsets a fragile power balance 
which exists outside of the individual root stores. There is an eternal 
war between governments pushing to take control of root stores and the 
security community pushing back. This battle happens in parliaments and 
governments, between lawmakers and officials, not within root stores and 
their individual judgement largely does not matter to this war. The 
major advantages we as the security community have today are that:


    a) These attempts to take control for surveillance are nakedly 
obvious to the local electorate because crappy domestic roots have no 
legitimate purpose because they can never achieve any real adoption.


    b) If a root store were to bow to pressure and let in a root CA 
used for interception, every other country has an interest in preventing 
that. An international WebPKI means that we are either all secure, or 
all insecure, together.


Trust Expressions, though intended to solve completely different 
problems, will accidentally eradicate both of these advantages. Firstly, 
it provides a nice on ramp for a new domestic trust store, mostly 
through the negotiation aspect but also through the CA pre-distribution. 
Secondly, by enabling fragmentation along geographic boundaries whilst 
maintaining availability of websites. Without Trust Expressions, we 
cannot balkanize TLS. With Trust Expressions, we can and we know people 
who want to (not anyone in this thread).


If you still do not understand this wider context within which all of 
our work sits, I do not think further discussion between you and I is 
going to help matters.


I would suggest we focus our discussion on the use cases of Trust 
Expressions and how exactly it would work in practice - these concerns I 
shared earlier in the thread are solely technical and operational and 
you and I might be able to make better progress towards a common 
understanding.


Best,
Dennis
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: WG Adoption for TLS Trust Expressions

[Dennis Jackson]

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 operator consent, and while 
governments do and will continue to force operators to make changes 
not in their interest, this proposal doesn't change that reality. 
Continuing to focus on this issue in this way detracts from the more 
constructive discussions happening in this thread.
The problem here is that fragmentation (which you acknowledge as a 
compelling concern) combined with making it much easier to deploy new 
CAs (a core goal of the draft) which together alters the power balance 
between the security community and governments in rather the wrong 
direction. I am not going to spend any further words on it here, but I'm 
disappointed you've engaged so dismissively in what has become a long 
discussion on a deeply complex topic.


The most compelling argument against Trust Expressions I see in the 
thread is the potential for fragmentation. However, the current 
conversation on this topic overlooks the existing fragmentation 
challenges faced by site operators. The primary concern I hear from 
these operators is the anxiety over changes related to cipher suites 
and certificates, fearing that these changes might inadvertently break 
services in exchange for security properties that their leadership 
isn’t asking for. Trust Expressions, in my view, offers a net-positive 
solution to this problem by allowing site operators to manage the 
trust anchor portion of this risk, which they cannot do effectively today.


Is it not rather the opposite, that this draft will give server 
operators an additional product space of choices and incompatibilities? 
With Trust Expressions, we must anticipate that CAs will need to jump 
through at least four separate hoops to provision a chain for each of 
the major root stores, as well as provision a chain for any past 
incompatible versions which are still popular. History does not suggest 
that CAs are particularly capable of managing these considerably more 
complex structures, given existing struggles with getting single chains 
correct.


Worse, we cannot expect Trust Expressions to become universal in any 
reasonable timeframe, meaning we still have the compatibility headache 
of existing and new clients with no Trust Expressions support.


At the same time, we are seeing more embedded devices being deployed 
without long-term maintenance strategies, automatic updates, or 
mechanisms to manage root store lists.


Can you evidence this? The UK and the EU have passed fairly sweeping 
laws over the past year to require that manufacturers provide long term 
maintenance and security updates for the entire lifecycle of new digital 
products [1,2]. The USA usually catches up eventually.


Better still, with the shift to PQ we have the best opportunity to adopt 
the Chrome Root Program's proposal for 7 year certificates. This would 
entirely fix this issue by pushing it from website operators to device 
manufacturers, where it should belong anyway :-), rather than creating a 
fragmented compatibility nightmare by embracing it and putting labels on 
it.


Best,
Dennis

[1] https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
[2] 
https://www.gov.uk/government/news/new-laws-to-protect-consumers-from-cyber-criminals-come-into-force-in-the-uki





On Thu, May 23, 2024 at 10:40 AM Watson Ladd  
wrote:


On Thu, May 23, 2024 at 12:42 PM David Benjamin
 wrote:

>
> Of course, whether this property (whether servers can usefully
pre-deploy not-yet-added trust anchors), which trust expressions
does not have, even matters boils to whether a root program would
misinterpret availability in servers as a sign of CA
trustworthiness, when those two are clearly unrelated to each
other. Ultimately, the trustworthiness of CAs is a subjective
social question: do we believe this CA has *and will continue*
only sign true things? We can build measures to retroactively
catch issues like Certificate Transparency, but the key question
is fundamentally forward-looking. The role of a root program is to
make judgement calls on this question. A root program that so
misunderstands its role in this system that it conflates these two
isn't going to handle its other load-bearing responsibilities either.

As the old saw goes "past performance is no guarantee of future
results, but it sure helps". Moreover root programs have to balance
the benefits of including a CA against the costs. One of those
benefits is the number of sites that use it.

Sincerely,
Watson

>
> David
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to 

[TLS]Transitioning to PQC Certificates & Trust Expressions

[Dennis Jackson]

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 functionality over existing, already widely deployed 
solutions.


In particular, having each CA cross-sign their new PQC root with their 
existing classical root. This does not require any new functionalities 
or code changes in TLS clients or servers, does not require coordination 
between CAs / Root Programs / Clients and does not impose any 
performance impact on the connection (perhaps surprisingly).


The rest of this message details the Trust Expressions proposal for a 
PQC transition and compares the security and performance to existing 
solutions.


*The Trust Expressions Proposal for the PQC Transition
*When we come to transition to PQC Certificates, the various Root 
Programs will include various PQC Roots and start distributing them to 
their clients. They will also configure their clients to start 
advertising the relevant PQC / hybrid signature algorithms in their 
signature_algorithms_cert TLS Extensions. TLS Servers will decide 
whether to send their classical chain or their PQC chain according to 
this extension.


The Trust Expressions authors plus quite a few folks on the list have 
stated that this approach will require us to wait for all major root 
programs to accept a given PQC Root and then for that PQC root to be 
ubiquitously supported by all clients which also advertise PQC Signature 
Support. Otherwise, we might send our new PQ Chain to a client who only 
has an older set of PQ Roots, which would cause a connection failure. 
This wait could take a long time, even a year or more.


Trust Expressions proposes that by having clients indicate their trust 
store label and version, we can mostly skip waiting for ubiquity. 
Through the Trust Expression's negotiation, we can be sure that we only 
send the PQC Root Certificate Chain to clients that have already updated 
to trust it. Meanwhile, clients that don't have PQC Signature support or 
do support the signatures but don't have the new PQC root will continue 
to receive the old classical chain and not enjoy any PQ Authentication.


*The Existing Alternative
*I believe this argument for the use of Trust Expressions overlooks 
existing widely available deployment options for PQC Certificates, which 
mean that we do not need to wait for multiple root stores to include new 
PQC certs or for them to become ubiquitous in clients. We will see how 
we can achieve the exact same properties as Trust Expressions (no 
waiting for ubiquity, no connection failures and PQ-Auth for all clients 
with the PQ Root) without the need for any new designs or deployments.


When CAs create roots with new signature algorithms (e.g. ECDSA Roots), 
it is common practice to cross-sign the new root with the existing root 
(e.g. an RSA Root). This is the approach taken by Let's Encrypt today, 
who have an older RSA Root (ISRG X1) and a newer ECDSA Root (ISRG X2). 
X2 is cross signed by X1, and each of the new ECDSA Intermediates are 
also cross-signed by X1 [1]. In the context of RSA vs ECDSA, this isn't 
especially interesting because there's a purely a tradeoff between a 
smaller chain (ECDSA/X2) vs a more ubiquity (RSA/X1). However, we'll see 
this approach has much more substantial benefits with PQC Signatures.


When the time comes to ship a PQC Root (which we'll call X3 for 
convenience), we'll make some PQC Intermediates (F1, F2, F3). We will 
also cross sign these intermediates with our X2 (ECDSA) Root which we'll 
call H1, H2, H3. So both F1 and H1 are certificates on the same 
intermediate PQC Public Key, with F1 having a PQC signature and H1 a 
ECDSA signature from their respective roots.


When we provision servers with their certificate chains, we'll provision 
the PQC Chain as their leaf (PQC Public Key + PQC Signature), plus both 
F1 and H1. Clients that don't indicate support PQC Signatures in their 
signature_algorithms_cert extension will receive the usual classical 
chain. Clients that support PQC and have the new root will verify the 
leaf + F1 and so enjoy PQ-Auth. Clients that support PQC and don't have 
the new root will verify the leaf and H1 and not receive PQ-Auth.


This achieves identical properties to Trust Expressions in terms of 
client security and doesn't involve any waiting for PQC Root Ubiquity or 
Root Store Approval. The only impact is the extra certificate in the 
chain. Happily, we can cut the overhead of H1 to be a mere 32 bytes with 
existing TLS Certificate Compression Algorithms like zlib / zstd / 
brotli (since H1 and F1 encode the same PQC Public Key). This is tiny 
compared to the necessary PQC Public Key and Signature already in the 
chain. With new schemes like Abridged Certs, we can go even further and 
replace all but t

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

[Dennis Jackson]

Hi Ryan,

On 27/05/2024 16:39, Ryan Hurst wrote:


[...]

Moreover, there's the liability issue: a CA that cross-signs another 
CA exposes its business to distrust based on the practices of the CA 
it cross-signs.


[...]

As someone who has both provided said cross-signs and received them I 
really don't see them as the silver bullet others seem to in this thread.


This thread is purely talking about cross-signs between two roots 
operated by the same CA, which is the case when an existing CA with 
classical root is generating a new PQ root.


This is completely standard practice, as exemplified by Let's Encrypt, 
DigiCert and Sectigo's pages describing their cross signs between the 
roots they operate [1,2,3]. There are no commercial relationships or 
sensitivities involved because the same organization controls both the 
signing and the cross-signed root.


I guess you assumed the alternative scenario where the roots belong to 
two different CAs. The standard terminology of referring to both as a 
cross-sign is regrettably vague.


Best,
Dennis

[1] Let's Encrypt X2 is cross signed by Let's Encrypt X1 
https://letsencrypt.org/certificates/


[2] Digicert G5 by the Digicert Global Root CA 
https://knowledge.digicert.com/tutorials/install-the-digicert-g5-cross-signed-root-ca-certificate


[3] Sectigo UserTrust is cross signed by Sectigo AAA 
https://support.sectigo.com/articles/Knowledge/Sectigo-Chain-Hierarchy-and-Intermediate-Roots




Ryan 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 deployment options shows that Trust Expressions
does not provide any improvement or new functionality over
existing, already widely deployed solutions.

In particular, having each CA cross-sign their new PQC root with
their existing classical root. This does not require any new
functionalities or code changes in TLS clients or servers, does
not require coordination between CAs / Root Programs / Clients and
does not impose any performance impact on the connection (perhaps
surprisingly).

The rest of this message details the Trust Expressions proposal
for a PQC transition and compares the security and performance to
existing solutions.

*The Trust Expressions Proposal for the PQC Transition
*When we come to transition to PQC Certificates, the various Root
Programs will include various PQC Roots and start distributing
them to their clients. They will also configure their clients to
start advertising the relevant PQC / hybrid signature algorithms
in their signature_algorithms_cert TLS Extensions. TLS Servers
will decide whether to send their classical chain or their PQC
chain according to this extension.

The Trust Expressions authors plus quite a few folks on the list
have stated that this approach will require us to wait for all
major root programs to accept a given PQC Root and then for that
PQC root to be ubiquitously supported by all clients which also
advertise PQC Signature Support. Otherwise, we might send our new
PQ Chain to a client who only has an older set of PQ Roots, which
would cause a connection failure. This wait could take a long
time, even a year or more.

Trust Expressions proposes that by having clients indicate their
trust store label and version, we can mostly skip waiting for
ubiquity. Through the Trust Expression's negotiation, we can be
sure that we only send the PQC Root Certificate Chain to clients
that have already updated to trust it. Meanwhile, clients that
don't have PQC Signature support or do support the signatures but
don't have the new PQC root will continue to receive the old
classical chain and not enjoy any PQ Authentication.

*The Existing Alternative
*I believe this argument for the use of Trust Expressions
overlooks existing widely available deployment options for PQC
Certificates, which mean that we do not need to wait for multiple
root stores to include new PQC certs or for them to become
ubiquitous in clients. We will see how we can achieve the exact
same properties as Trust Expressions (no waiting for ubiquity, no
connection failures and PQ-Auth for all clients with the PQ Root)
without the need for any new designs or deployments.

When CAs create roots with new signature algorithms (e.g. ECDSA
Roots), it is common practice to cross-sign the new root with the
existing root (e.g. an RSA Root). This is the approach taken by
Let's Encrypt today, who have an older RSA Root (ISRG X1) and a
newer ECDSA Root (ISRG X2). X2 is cross signed by X1, and each of
the new ECDSA Intermediates are also cross-si

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

[Dennis Jackson]

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 email [1] with no replies.


[1] https://mailarchive.ietf.org/arch/browse/tls/

On 27/05/2024 18:51, Ryan Hurst wrote:
However, doing so with a hybrid chain weakens the security of the 
chain to the security properties of the certificate and keys being 
used for the cross-signing.


I don't think there's any such thing as the security of the chain. Only 
the security of the *verifier* of the chain. If they trust a classical 
root, they can't do better than classical security. If they trust only 
PQ roots, it doesn't matter how many extraneous classical certs are in 
the chain if there's a valid PQ path from leaf to a known PQ root or 
intermediate. In both cases, the having a classical signature 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 liability issue: a CA that cross-signs
another CA exposes its business to distrust based on the
practices of the CA it cross-signs.

[...]

As someone who has both provided said cross-signs and received
them I really don't see them as the silver bullet others seem to
in this thread.


This thread is purely talking about cross-signs between two roots
operated by the same CA, which is the case when an existing CA
with classical root is generating a new PQ root.

This is completely standard practice, as exemplified by Let's
Encrypt, DigiCert and Sectigo's pages describing their cross signs
between the roots they operate [1,2,3]. There are no commercial
relationships or sensitivities involved because the same
organization controls both the signing and the cross-signed root.

I guess you assumed the alternative scenario where the roots
belong to two different CAs. The standard terminology of referring
to both as a cross-sign is regrettably vague.

Best,
Dennis

[1] Let's Encrypt X2 is cross signed by Let's Encrypt X1
https://letsencrypt.org/certificates/

[2] Digicert G5 by the Digicert Global Root CA

https://knowledge.digicert.com/tutorials/install-the-digicert-g5-cross-signed-root-ca-certificate

[3] Sectigo UserTrust is cross signed by Sectigo AAA

https://support.sectigo.com/articles/Knowledge/Sectigo-Chain-Hierarchy-and-Intermediate-Roots



Ryan 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 deployment options shows
that Trust Expressions does not provide any improvement or
new functionality over existing, already widely deployed
solutions.

In particular, having each CA cross-sign their new PQC root
with their existing classical root. This does not require any
new functionalities or code changes in TLS clients or
servers, does not require coordination between CAs / Root
Programs / Clients and does not impose any performance impact
on the connection (perhaps surprisingly).

The rest of this message details the Trust Expressions
proposal for a PQC transition and compares the security and
performance to existing solutions.

*The Trust Expressions Proposal for the PQC Transition
*When we come to transition to PQC Certificates, the various
Root Programs will include various PQC Roots and start
distributing them to their clients. They will also configure
their clients to start advertising the relevant PQC / hybrid
signature algorithms in their signature_algorithms_cert TLS
Extensions. TLS Servers will decide whether to send their
classical chain or their PQC chain according to this extension.

The Trust Expressions authors plus quite a few folks on the
list have stated that this approach will require us to wait
for all major root programs to accept a given PQC Root and
then for that PQC root to be ubiquitously supported by all
clients which also advertise PQC Signature Support.
Otherwise, we might send our new PQ Chain to a client who
only has an older set of PQ Roots, which would cause a
connection failure. This wait could take a long time, even a
year or more.

Trust Expressions proposes that by having clients indicate
their trust store label and version, we can mostly skip
waiting for ubiquity. Throug

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

[Dennis Jackson]

Hi Ryan,

On 27/05/2024 19:23, Ryan Hurst wrote:
I don't understand your position on the verifier, the faith one can 
put in the chain of signatures is only the faith appropriate for the 
weakest signature. As such if a classical key is used to sign a PQ 
chain, an attacker would go after the classical signature ignoring the 
others.


That's not quite right.

Let's imagine we have a leaf public key L1, a PQ Public Key M1 and a 
Classical Public Key N1 and use <- to indicate 'signed by'. Consider the 
certificate chains:


    (1) L1 <- M1

    (2) N1 -> L1 <- M1  (N1 and M1 are both intermediates signing the 
same leaf)


    (3) L1 <- M1 <- N1 (N1 cross-signs M1).

Have we made things worse in (2) by adding a classical signature? No. 
Any verifier that would output accept on (1), will also output accept on 
(2) without even checking N1. So we cannot have made security worse for 
anyone that would accept (1). The opposite is also true, anyone that 
would trust N1 will not need to verify M1. So (2) strictly improves 
availability without reducing security for anyone. (This was my proposed 
design in the initial mail).


For (3), we still have the property that anyone that would output accept 
on (1) would output accept on (3) without checking N1, so security for 
PQ users has not been reduced at all. The reverse direction for whether 
we hurt classical users requires us to trust that M1 is at least as 
secure as N1 - otherwise we're hurting security for the folks that trust 
N1 but not M1. In the context where M1 is a PQ-Hybrid and N1 is 
classical and both are operated by the same CA, this is perfectly fine. 
(This was my alternate design in the initial mail).


The important nuance is this: we can *add* as many certificates / 
signatures as we like to the leaf node of a chain in order to improve 
availability without hurting security. We can also extend PQ chains with 
classical roots, without degrading the security of PQ users in any way.


As a further thought experiment. Imagine we had a fully PQ PKI setup and 
established, then some attacker used their quantum computer to break a 
classical root and start adding a classical signature to all our secure 
PQ chains. This action would not impact security for any client which 
only trusted PQ signatures. They simply don't care about the classical 
signature and the attacker can't produce any new chains. For clients 
which did trust the classical signing algorithm, they're doomed no 
matter what, because the attacker can just make valid chains of their 
choice.


Security all comes down to roots and signatures the verifiers accepts, 
not 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 email [1] with no replies.

[1] https://mailarchive.ietf.org/arch/browse/tls/

On 27/05/2024 18:51, Ryan Hurst wrote:

However, doing so with a hybrid chain weakens the security of the
chain to the security properties of the certificate and keys
being used for the cross-signing.


I don't think there's any such thing as the security of the chain.
Only the security of the *verifier* of the chain. If they trust a
classical root, they can't do better than classical security. If
they trust only PQ roots, it doesn't matter how many extraneous
classical certs are in the chain if there's a valid PQ path from
leaf to a known PQ root or intermediate. In both cases, the having
a classical signature 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 liability issue: a CA that cross-signs
another CA exposes its business to distrust based on the
practices of the CA it cross-signs.

[...]

As someone who has both provided said cross-signs and
received them I really don't see them as the silver bullet
others seem to in this thread.


This thread is purely talking about cross-signs between two
roots operated by the same CA, which is the case when an
existing CA with classical root is generating a new PQ root.

This is completely standard practice, as exemplified by Let's
Encrypt, DigiCert and Sectigo's pages describing their cross
signs between the roots they operate [1,2,3]. There are no
commercial relationships or sensitivities involved because
the same organization controls both the signing and the
cross-signed roo

[TLS]Re: Curve-popularity data?

[Dennis Jackson]

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 attacks on an otherwise prime order curve.


This was used by Eli Biham and Lior Neumann to break Bluetooth pairing 
standard back in 2018 [1]. The Bluetooth standard previously said 
implementers could choose to do full point validation or always use 
ephemeral keys, and folks opted for the less complex choice. This isn't 
a clear separator between X25519 and P-256 though, since X25519 would 
also need to reject small order points in order to avoid the same attack.


Best,
Dennis

[1] 
https://biham.cs.technion.ac.il/BT/bt-fixed-coordinate-invalid-curve-attack.pdf 



(Also summarized in 7.2 of Prime Order Please 
https://eprint.iacr.org/2019/526.pdf)
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: Curve-popularity data?

[Dennis Jackson]

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 most popular curve on the internet. So
certificates, TLS, handshakes, all of that is like 70 plus percent
negotiated with the P 256 curve.

Maybe the TLS co-chair has a comment?


On 03/06/2024 22:19, D. J. Bernstein wrote:

As I said, the statement is from one of the current TLS co-chairs, a
month before the co-chair appointment. The position as co-chair adds to
the importance of ensuring accurate information.


Dan, this is unsavory conduct. We are here to have reasoned, impersonal 
discussions. Please see in particular the second guideline for conduct 
at the IETF (RFC 7154).


Trying to call out an individual for a comment made informally, in some 
other corner of the internet, some time ago, is rather unbecoming of you 
and looks as though you're trying to use the working group's time and 
energy to settle a playground squabble. Especially when the referenced 
comment was unconnected to any active discussion within the WG or 
decisions made by the chairs.


Your thread has raised two technical & impersonal questions relevant to 
the TLS WG. Let's keep the focus on them:


1) What cryptographic algorithms are popularly used with TLS today?

2) Does this popularity matter for deciding which PQ hybrids to 
standardize in TLS?
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: Curve-popularity data?

[Dennis Jackson]

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 MTI algorithm and Chrome doesn't provide any MTI
keyex in its client hello, making it a noncompliant TLS 1.3 implementation.


As Nick quoted from the spec:


A TLS-compliant application MUST support key exchange with secp256r1 (NIST 
P-256)
Chrome advertises support for P-256 in the supported groups extension. 
As a factual matter, Chrome can successfully connect to a site that only 
implements support for P-256. I cannot find any basis for Peter's claims 
in the spec.


Ekr wrote:


One more thing: we are finalizing RFC 8446-bis right now, so if there is
WG consensus to require that clients offer all MTI curves in the 
key_shares

of their initial CH, then that would be a straightforward text change.


I think we are closer to going in the other direction and allow TLS1.3 
spec-compliant implementations aiming at post-quantum support to drop 
support for P-256 entirely.


Best,
Dennis

On 05/06/2024 14:34, Peter Gutmann wrote:

Mike Shaver  writes:


You mentioned in another message that some embedded TLS implementations also
omit MTI support for code size or attack surface reasons.

They don't omit MTI support, they *only* support MTI (think Grigg's Law,
"there is only one mode and that is secure").  So when faced with an
implementation that doesn't, they can't talk to each other.


do you have any sense of why Chrome chose to omit this MTI support?

I suspect it's just because Google does whatever Google wants to (see e.g.
https://fy.blackhats.net.au/blog/2024-04-26-passkeys-a-shattered-dream/,
section "The Warnings").  This may not be politically expendient to say out
loud :-).

Peter.
___
TLS mailing list --tls@ietf.org
To unsubscribe send an email totls-le...@ietf.org___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: Curve-popularity data?

[Dennis Jackson]

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 shares they'd like to see.


[1] 
https://datatracker.ietf.org/doc/draft-davidben-tls-key-share-prediction/
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: TLS trust expressions and certificate_authorities

[Dennis Jackson]

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 effort to move the conversation on. It would be good to see a 
response from the TE authors to that thread.


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 capability offered by trust expressions that 
isn’t already available by certificate_authorities.


I think the above captures the main thrust of your argument in this 
thread, but it seems like quite a flawed analysis. If T.E. does not 
offer any new capabilities over certificate_authorities, then there is 
no point in standardizing it at all. Conversely, arguments that T.E. is 
a much more effective mechanism for deploying trust negotiation than 
certificate_authorities undermines the claim that T.E. doesn't introduce 
new risks that merit discussion.


In terms of the differences between the existing certificate_authorities 
extension and Trust Expressions, I want to enumerate a few:


Firstly, certificate_authorities is impractical at any kind of scale 
because it requires listing the distinguished name of every CA in the 
ClientHello (as you noted). This makes the size blowup is a huge 
impediment to actually using it for anything other than in a private PKI 
setting e.g. for indicating which client_certs a server would like to see.


Secondly, certificate_authorities is very poorly supported today. TLS 
libraries typically ignore it e.g. OpenSSL requires custom callbacks to 
integrate it [2] - I couldn't find anything actually calling this 
function. Neither BoringSSL nor NSS support it in ClientHellos as far as 
can tell.


Thirdly, certificate_authorities doesn't have any of the machinery 
necessary to orchestrate deploying it. Trust Expressions envisions ACME 
/ TLS Servers implementations and CAs cooperating to distribute these 
trust labels to subscribers without requiring them to do any 
configuration themselves.


Trust Expressions proposes to solve all of these drawbacks with 
certificate_authorities. The first is achieved by replacing the long 
list of distinguished names with a single identifier. The second is to 
ship support across servers and clients and make sure it is well 
exercised and indeed required. The third is to ensure that CAs can 
deliver multiple certificate chains to clients and that clients can 
transparently select between them based on a trust label.


Consequently, T.E. does meaningfully change the calculus over 
certificate_authorities and so there are number of active threads 
discussing the risks of enabling trust negotiation and evaluating how it 
can be abused.


Best,
Dennis

[1] https://mailarchive.ietf.org/arch/msg/tls/b_S23Rk0yvleoT3D0BGUTYFut80/

[2] https://github.com/openssl/openssl/issues/13453

On 11/06/2024 02:24, Devon O'Brien wrote:


Hello,


I realize there has been extensive discussion about trust expressions 
and a variety of hypothetical scenarios that some believe will play 
out should this draft get adopted and implemented. I would like to 
start this out with a clear statement: we hear these criticisms and 
are paying very close attention to them in order to help ensure this 
working group does not ship an irresponsible standard that causes any 
of the possible doomsday scenarios sketched out. The crux of this 
disagreement isn’t whether the outlined hypotheticals are bad; we are 
in strong agreement on this point. Rather, the disagreement is about 
the causality being posited between a rather incremental extension 
mechanism and these outcomes. Here, we authors strongly disagree with 
the points that have been repeatedly mentioned by some working group 
members and I hope that a more careful analysis of what trust 
expressions actually provide over the status quo will help the working 
group work past these disagreements.



I believe that, in our excitement at the opportunities that a more 
agile web PKI can provide, we did ourselves and the broader community 
a disservice by leaning too far into some of the far-reaching 
possibilities we envision from a world with trust expressions. While 
we remain excited about a more agile and less-ossified PKI, it’s now 
clear that such emphasis caused the conversation to shift dramatically 
away from what the draft actually says and towards a variety of 
opinion-based arguments about what laws may be written by various 
world governments in the coming years and decades.



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 cer

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

[Dennis Jackson]

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 intermediates, and
the verifier figures out which one to use for the key exchange. (Yes,
this is really nitpicky, but there is a distinction between keys and
certs here that matters when counting bytes). Also the intermediates
aren't the roots, and I don't think we're relaxing that rule for
purposes of this discussion.
Yes, the L1, M1 and N1 are public keys rather than certificates in the 
example I sketched. I was trying to explain more around how particular 
signatures impacted the overall security (or didn't), rather than the 
concrete use case in my initial message.



So in case (3) we'd send L1, M1, M1' where M1' is signed by the root
N1, and M1 by some PQ root. In case (2) I'm not sure how this would
work: the end entity cert must be first, but you're requiring two
different ones (with the same key), and I don't know a way to find M1
and N1 from that single cert.
Yeah, in case (2) in practice we'd want two intermediate certificates 
rather than two end-entity certificates as I sketched in the first mail, 
but I felt having the extra identical signature hop in both examples 
might be confusing from the security perspective.

Anyway your point remains valid: cross-signing doesn't hurt clients
that only trust the new algorithm.


:-)

Just to make sure things are clear, I've laid out the certificate chains 
from my initial message again.


We have a new PQC root X3, plus an existing classical root X2.

*Option 1*
We create a new PQC Public Key  M1 and produce two intermediate 
certificates for this public key, over X2 and X3 and use them to produce:


 * L1 := User's Leaf key signed by M1.
 * F1 := M1 signed by X3
 * H1 := M1 signed by X2

The certificate chain is then: L1 + F1 + H1.

Benefits:

 * PQ Security for clients that have X3
 * Classical Security and backwards compatibility for clients that only
   have X2
 * Existing TLS Certificate Compression mechanisms like brotli will
   compress out the excess bytes (the repetition of M1) so overall the
   only size increase is the 32 byte ECDSA X2 signature.

Drawback: Relies on Clients doing the bare minimum of chain building. 
Interestingly you can choose whether its PQ clients or classical clients 
that need the chain building support by deciding whether to send F1 or 
H1 first in the order.


*Option 2
*We cross sign X3 with X2 and use that to build a single longer chain:

 * L1 := User's Leaf Key signed by M1
 * F1 := M1 signed by X3
 * X3' := X3 signed by X2.

The certificate chain is then L1 + F1 + X3'

Benefits:

 * PQ security for clients that have X3
 * Classical Security and backwards compatibility for clients that only
   have X2
 * No chain building support needed

Drawback: You need Abridged Certs or AIA chasing (already deployed in 
Chrome) to avoid paying the byte cost of X3'.


@Ilari - I think the size increase is much less than you might think, 
only 32 bytes for Option 1 and this is assuming no use of Abridged 
Certs, which would make either option completely free. Assuming we 
deployed Abridged Certs, then Option 2 has no size increase on today and 
does not need any path building support in clients.


Best,
Dennis

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: TLS trust expressions and certificate_authorities

[Dennis Jackson]

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 that Trust Expressions 
supports, but this problem doesn't exist for certificate_authorities 
advertising a single government CA. In your first example of how 
certificate_authorities differs from Trust Expressions, you've given 
an example of how Trust Expressions is less risky than 
certificate_authorities.


You can't argue that T.E. contains the functionality of 
certificate_authorities as a subset, then conclude that having 
additional functionalities makes it less risky. You would need to argue 
the exact opposite, that T.E. doesn't contain the bad functionalities of 
certificate_authorities. The risk associated with abuse of a feature is 
not in any way diluted by tacking on good use cases.




The complexity of deploying certificate_authorities for the government 
CA "risky" use case is much less than it is for Trust Expressions. The 
"risky" use case requires clients advertise the name of the CA, and it 
requires servers to be able to match a name in the 
certificate_authorities extension against one of its multiple 
certificates. This deployment has no machinery with CAs, ACME servers, 
or root programs publishing manifests. When you say 
certificate_authorities doesn't have any of the machinery necessary, 
that's because it doesn't need any such machinery, as Devon explained 
in point 4. In the "risky" use case, Trust Expressions requires the 
government to implement or compel more actions than it would with 
certificate_authorities. Starting with the clients, it would need to 
compel root programs to manage and publish an additional trust store 
manifest (or manage its own trust store manifest and compel 
advertisement of that as part of compelling trust). It would also need 
to have its CA (and the CA's ACME server) support the government trust 
store in its CertificatePropertyList. It looks like there's a lot more 
compulsion involved in this government-forced trust use case when the 
government uses Trust Expressions instead of certificate_authorities.


I wonder what such a trust store manifest would look like... [1] [2]. 
There's at least one large player out there with a list of CAs ready to 
go and all the necessary machinery in place.


[1] https://eidas.ec.europa.eu/efda/tl-browser/#/screen/home

[2] 
https://eidas.ec.europa.eu/efda/swagger-ui/index.html#/api-browser-controller/getTrustedList
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: TLS trust expressions and certificate_authorities

[Dennis Jackson]

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 capability offered by trust expressions that 
isn’t already available by certificate_authorities. When compared to 
certificate_authorities, the primary obstacle being addressed by trust 
expressions is the size of the message sent in (1). X.501 
distinguished names are notoriously verbose, and modern trust stores 
contain hundreds of trust anchors, rendering it infeasible for relying 
parties to dedicate tens of thousands of bytes in a TLS handshake to 
listing trust anchors. Notably, parties that may wish for clients to 
signal a specific mandated CA can do so efficiently with 
certificate_authorities today, as this requires sending only a single 
distinguished name.


There are a number of issues with this argument. The first and most 
important is that you are misunderstanding and so misrepresenting the 
concerns that are being raised.


We have been discussing on the list whether Trust Expressions enables 
bad actors (in particular, governments) to establish their own root 
programs and get users and websites to adopt them. This is a distinct 
scenario from the case you addressed where a government demands the 
inclusion of a specific single government CA. Although both are equally 
bad for the security and privacy of users.


As previously discussed on the list, government root programs are much 
more dangerous proposals than the forced inclusion of specific CAs 
because they appear to have legitimate purposes in the eyes of 
lawmakers. Proposals to mandate the inclusion of a single government CA 
in existing root stores are as transparently evil as the plot of the 
average bond villain. The community understands there is no legitimate 
reason a government should force inclusion of their CA and so infers the 
actual use case will be mass surveillance or censorship.


The more attractive route for governments is to argue that they are 
establishing a domestic root store (or 'trust regime'). The government 
will establish a regulator to manage the scheme and approve the suitable 
CAs. These domestic root stores are argued to enable digital 
sovereignty, break free of control by American big tech and help build 
the local cybersecurity industry. Despite being dressed up in this 
clothing, they are just as effective tools for surveillance and 
censorship as forcing a CA into an existing root store would be.


One of the key differences between Trust Expressions and the 
certificate_authorities extension is that T.E. is a very effective tool 
for establishing a new trust store and indeed has been designed with 
this goal in mind (see bold text below). It is not only the fact that 
T.E. compresses the certificate_authorities extension that enables this 
outcome. Another key design decision is letting the CA decide which root 
stores a website should support, without needing a decision or approval 
from the website operator.


The second issue with the argument that Trust Expressions does not 
introduce new risks is that the certificate_authorities extension only 
exists on paper rather than in running code. If a government were to try 
to pass some legislation which used the certificate_authorities 
extension, they would be completely unable to enact it in practice. This 
is because support in TLS libraries is practically non-existent. Most of 
those I surveyed did not have any support, a couple had support but only 
for client certificates. I was unable to find any library or webserver 
which supports certificate_authorities in the client_hello although 
presumably one exists.  As the certificate_authorities extension has 
been standardized for 6 years now and support is still so limited, I'm 
not especially concerned that will change in the future.


I also want to be clear that there is no danger in writing down ideas 
like the certificate_authorities extension or Trust Expressions. 
Governments are capable of these ideas even if they tend to execute them 
with limited technical competence. The danger entirely comes from 
whether running code, out there in the real world, actually supports 
these features. Governments, even powerful federations, would find it 
impossible to force certificate_authorities or Trust Expressions into 
popular TLS stacks if the community were against it. But if we ship 
these features to the entire web, they can (and will) be abused.


Summing up:

 * Certificate_authorities does not enable the creation of domestic
   root stores, trust expressions does by solving their adoption
   problem (expanded on here [1])
 * Domestic root stores have the same (or worse) harms than simply
   mandating a government CA in existing root stores.
 * Domestic root stores are much more likely to be su

[TLS]Re: Trust Expressions Update

[Dennis Jackson]

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 does. Some 
of the feedback we received about TLS Trust Expressions renewed our 
interest in this approach.


I’ve reviewed the Trust Anchors draft and although I understand the 
motivation for an alternative to Trust Expressions, I feel many of the 
same concerns with Trust Expressions around effectiveness, complexity 
and risk of abuse apply equally to the Trust Anchors design.


I’ve produced two documents to outline these concerns and summarize 
mailing list conversation so far. The first [1] tackles the concerns 
about the risks of abuse and the second [2] tackles issues with the 
proposed use cases. I hope both are useful for folks wanting to come up 
to speed on the discussion on the mailing list ahead of the meeting next 
week.


We are planning to add a further document on detailed risk scenarios, 
as best as we can articulate them, regarding the “surveillance and 
possible future legislation” discussions on the list. This document 
isn’t quite ready but we will follow up with the list when it is. 


I hope the mentioned summary [1] of the risks and concerns around Trust 
Expressions and Trust Anchors will be useful if you’re still planning to 
produce your own document tackling these issues. It covers the key 
concerns that were discussed on the mailing list, in particular, the 
risks of fragmenting the WebPKI, the risks of abuse for building 
domestic root programs for surveillance, and the impact of on client 
privacy by exposing the client’s root store.


We added a PKI transition strategies document with a more detailed 
discussion of some transition scenarios, and how various alternatives 
we have considered apply to them:


I’ve tried to develop this discussion in my comments on the use cases 
[2]. In brief, although both drafts are positioned as solving a broad 
range of problems, I feel that many of the problems are quite minor and 
largely not well motivated. Further, examining the proposed use cases in 
detail suggests that both drafts rely on quite optimistic assumptions 
about deployment that will not be possible to satisfy in practice.


I do think managing the transition to a Post-Quantum WebPKI is perhaps 
the most interesting problem, but as discussed in the linked comments, I 
don’t think Trust Expressions or Trust Anchors offers an improvement 
over much simpler alternatives which are already widely supported and so 
do not incur the complex implementation, operational and organizational 
challenges of these proposals.


I’m also concerned that some of your comments in the explainer either 
misunderstand or misrepresent the existing approaches like Abridged 
Certificate Compression which functions quite differently to the way you 
claim.


For those heading to Vancouver, safe travels and see you next week!

Best,
Dennis


[1] 
https://github.com/dennisjackson/trust-negotiation-comments/blob/main/concerns-and-risks.md


[2] 
https://github.com/dennisjackson/trust-negotiation-comments/blob/main/comments-on-usecases.md


___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Dennis Jackson]

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 browser 
traffic, but we aim for the two to use different PKIs, the server 
needs to arrange to serve different certificates to each. To do that, 
we need trust anchor negotiation story.


I'm not sure you're talking about the same systems as Mike.

We've seen a number of recent incidents where CAs have delayed 
revocation of mis-issued certificates for 'critical' services that are 
not accessible on the public web [1]. The vast majority of these 
services could already migrate to a private PKI today but they simply 
don't have adequate incentives to make the small investment necessary. 
How would Trust Expressions or Trust Anchors change that?


Even for the tiny fraction of IoT services that have the misfortune to 
be on the public web and also popular with browsers. I don't understand 
why you think Trust Anchor Negotiation is a competitive solution.


The operator can choose at any time to start migrating their IoT devices 
to a new URL which is not shared with browser clients and uses a private 
PKI. This has the same outcome as T.E. / T.A., without needing to ship a 
new TLS library to the IoT devices. How would you sell an investment in 
deploying and operating Trust Anchors or Trust Expressions to these 
companies?


I feel a lot of the conversation on the benefits of these proposals is 
being derailed by the large number of use cases you're jumping between.


It might be very be productive to take Rich's suggestion on focusing on 
one or two key problems that you want to solve and invest some time in 
explaining how your proposals handle the critical aspects around 
adoption. Some key questions would be: Who are we asking to deploy these 
designs? What is the incentive for them to do the necessary work?


This doesn't mean you have to abandon the other use cases, but I think 
one or two well-explained use cases covering the key details would be 
much more persuasive to the WG than the current barrage of 9 or 10 use 
cases which leave more questions than they answer [2].


Best,
Dennis

[1] e.g Entrust and Chunghwa Telecom

[2] See also my previous comments 
https://github.com/dennisjackson/trust-negotiation-comments/blob/main/comments-on-usecases.md


___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Dennis Jackson]

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, which means that it would take 
active divergence by a system implementor to create the sort of TBTF 
systems that impede trust changes today.


I would like to hear from the authors (or others in the TLS 
implementation community) if they think Trust Expressions / Trust 
Anchors can be pushed into non-browser endpoints by default and the work 
they think would be required to achieve it?


I think I see how, with substantial investment, an application like a 
browser could adopt these designs. I'm not sure I can see a TLS library 
ever being able to offer it by default.


Best,
Dennis
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Dennis Jackson]

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 negotiation and so forth, and I think that it will be 
fine for a library to come with “sane, web-like” defaults, and then 
provide a mechanism for configuring alternative policies when desired.


I think reading the drafts would be really valuable. Unfortunately the 
necessary changes are not as simple as anything like cipher selection.


For example, Trust Anchors requires the TLS Library to have access to 
additional DNS records, which either the application needs to provide or 
the TLS Library needs to fetch itself - neither seem viable by default. 
Both drafts also require other breaking API changes on client and server.


This would let modern clients like browsers continue to tend to the 
web PKI, without the opposing force of such possible disruptions. From 
my experience with root programs, this would be a very welcome capability!


I would love to hear more about these possible disruptions you feel are 
a factor> Speaking as someone who is involved in a root program 
currently, I don't understand how Trust Anchor Agility would enable 
anything for us - discussed at more length here [2].


Best,
Dennis

[2] 
https://github.com/dennisjackson/trust-negotiation-comments/blob/main/comments-on-usecases.md 

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Dennis Jackson]

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 T.E. ever be enabled by default without 
breaking the existing API and requiring application changes?


For example, applications which access the server certificate via a 
callback or after handshake completion are going to be surprised by 
anything non-X.509 and also likely differ in policy from the system 
trust store (making any use of the system root store's trust expression 
label by default quite troubling).


Similar issues apply for where applications configure the TLS 
certificate validation policy in advance, ship their own root store 
(even if its say a copy of an existing one) or hook up a custom 
certificate validation library.



Server-side both require much more extensive API changes. However, I
think that it is feasible to add support without breaking API changes
(by extending certificate loading to support alternate issuer chains).


A similar picture seems to apply here. Adding a new API is fine but then 
needs server-side applications to opt in to using it. Otherwise 
overloading existing file / directory mechanisms might be possible if 
there's not too many fussy applications out there which are going to barf.


I'm pretty pessimistic about these API issues (Hyrum's Law etc) but I 
haven't had much exposure to OpenSSL's APIs from the perspective of 
other clients / servers - so curious if you do see a way to enable it by 
default without changing existing applications.


Best,
Dennis
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Dennis Jackson]

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 identifying the 
‘directory of certs’ that are typically used so that it could become a 
named trust store. Assume that’s a fixed filename, like 
“trust-store-id.txt” or something. Then when you specify that 
directory (e.g., via [1]) it could look for the fixed filename and 
send that identifying information.


I agree that having a library like OpenSSL auto-discover the necessary 
metadata in the system root store is definitely possible. My concern is 
about breakage with the other parts of the API exposed to applications 
which will prevent T.E. from being able to be offered by default - 
meaning applications will have to opt-in via a new API.


The Trust Expression's extension is trying to convey accurate 
information about which certificates are acceptable (which is controlled 
by the application) and may change the certificate which is received 
(which is visible to the application). So I don't see how Trust 
Expression's could be enabled by default without breaking applications 
or the semantics of the Trust Expression's extension. Some examples:


 * Some applications will set their own certificate verification
   callback (SSL_CTX_set_cert_verify_callback). A Trust Expression's
   label cannot be sent with these connections because OpenSSL doesn't
   know what the policy is going to be that the application applies.
   Sending the T.E. label is informing the serve 'I will accept any
   certificate suitable for this root store'.
 * Some applications will use the default certificate verifier in
   OpenSSL, but then access the certificate chain via
   SSL_get_peer_cert_chain or similar functions for getting specific
   metadata. The application might then do further checks which OpenSSL
   is unaware of. If so, the Trust Expression's label from the system
   store cannot be used without making the label inaccurate.
 * Some applications will do use the default checks on the certificate,
   but access the certificate chain to consume / log / display the
   information elsewhere. It's likely these functions are going to
   expect a 'normal' X.509 cert chain but one of the use cases of Trust
   Expressions is to enable non-X509 certificate payloads or shorter
   chains.

I think the second and third cases are particularly critical. OpenSSL 
cannot know during the handshake whether the application is going to 
later call SSL_get_peer_cert_chain / SSL_get_peer_certificate and then 
make a decision about whether to tear down the connection. For example, 
the application may do its own pinning and check whether the issuer is 
acceptable.


In this case, if OpenSSL sent the Trust Expression extension with the 
label by default, it would be actively harmful, since the Trust 
Expression extension is telling the server "I will accept any cert valid 
in this root store" but in actuality the application is performing 
pinning. This would make the extension useless for the proposed use 
cases around handling pinning gracefully and giving server's confidence 
to migrate CAs.


So my conclusion is that TLS libraries are never going to be able to 
offer T.E. by default. Instead applications would have to opt in, which 
seems like a major barrier to adoption outside of browsers.


Happy to be corrected if there are some wrinkles here, but Hyrum's law 
seems pretty harsh for the existing TLS library APIs.


Best,
Dennis




___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: Trust Expressions Update

[Dennis Jackson]

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?


My concerns are about deploying a mechanism for negotiating which 
certificate the server sends that can scale to the divergent 
requirements of many different parties.


Right now, servers are pretty much forced into choosing between being 
available on the WebPKI or being available on some other PKI. There are 
limited mechanisms which do allow servers to select alternative 
certificates (e.g. based on the client's IP or which interface it is 
accessing in corporate environments), but these mechanisms cannot be 
used at scale without causing massive incidental breakage without some 
signal from the client as to which server certs it trusts.


Trust Expression's 'fixes' that restriction and allows servers to 
participate in multiple PKIs simultaneously. Importantly, Trust Labels 
are not limited to some fixed set like signature_algorithms registered 
with IANA. Trust Expression's design requires that TLS libraries accept 
any trust_label conveyed by the CA via the provisioned certificate chains.


Trust labels are basically opaque user-agent strings which can negotiate 
arbitrary things about the contents of the certificate message in TLS. 
This makes it easy for good actors like Chrome to deploy a new 
experiment or new security policies via a new trust label, but also 
empower actors trying to establish their own PKIs with less noble 
intentions (explained further in [1]).


Does that clarify the technical difference between introducing something 
like Trust Expressions and other more limited negotiation mechanisms?


Best, Dennis

[1] 
https://github.com/dennisjackson/trust-negotiation-comments/blob/main/concerns-and-risks.md#root-programs-and-mass-surveillance
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Dennis Jackson]

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 of pretty much all 
existing library APIs and the library doesn't know what the application 
is going to enforce (or expect) about those certificates. This makes it 
hard (impossible?) for Trust Expressions to accurately convey the 
application's policy or to be used to experiment with the certificate 
format.


Best,
Dennis

On 23/07/2024 09:41, Salz, Rich wrote:


I agree that I didn’t provide a comprehensive answer, only that it was 
possible, perhaps one API at a time.  So maybe that addresses many 
legacy apps.


But you are totally right that the surface area is MUCH bigger than that.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Dennis Jackson]

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 don't 
think we can but definitely appreciate hearing from other implementers.


If the claim is: "This thing has value even if only browsers do it", 
that simplifies the discussion a lot and helps us talk through the 
use-cases.


For example: I want non-browser clients to be able to do fully PQ TLS by 
default. I think that's a reasonable expectation.


If applications have to opt-in to use Trust Expressions through new APIs 
and Trust Expressions is necessary for PQ TLS, I feel we're landing in a 
pretty bad place on the PQ adoption story...


Best,
Dennis

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Discussions on Trust Anchor Negotiation at IETF 120

[Dennis Jackson]

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 critical for making progress. 
It is almost impossible to have sensible conversations about new drafts 
without agreeing on and understanding the problems we want to solve.


The vast majority of folks I've spoken with have said they're interested 
in solving the challenges around deploying fully PQ TLS, but don't feel 
that we are currently close to a shared understanding of those 
challenges or the tradeoffs around the drafts on the table today.


A smaller number of folks are interested in tackling other problems 
around root store management. I fear this aspect of the problem space is 
even less clearly understood and I heard very little agreement on what 
the key challenges are or how they might be addressed.


I hope tomorrow we can focus our discussion on figuring out as a WG the 
problem(s) that we want to tackle and where we differ in our 
understanding of those problems. I am sure that 20 minutes will not be 
enough time to resolve these complex issues, but I hope we can find a 
way to continue the conversation constructively.


Ahead of the meeting tomorrow, I want to highlight some of the questions 
which I think we need to find and agree on answers for:


- What are the problems that we solving?

- Who are we solving these problems for? Browsers or everyone?

- Are we proposing a hard requirement on this negotiation mechanism for 
anyone wanting to do fully PQ TLS?


- Can the proposed mechanism be enabled by default in TLS Libraries 
without requiring application changes?


- Can the proposed mechanism support use in a private PKI? How about in 
a private PKI that runs over the public Internet (in the now-classic 
zero-trust networking model)?


- What is the long-term vision for TLS and the WebPKI? Are we moving 
forward together or fragmenting?


- How do the proposed mechanisms affect TLS Client Hello fingerprinting 
or other tracking vectors?


- How would the proposed system work in practice? What happens when 
actors follow their own interests rather than the requirements of RFCs?


- Are less popular clients incentivized to lie in their Trust 
Expressions about which root stores they have? The history of browser 
HTTP User Agent spoofing [1] highlights how minority clients are forced 
to spoof the signals of other browsers to maximize site compatibility 
(even though it violates protocol requirements).


- How would versioning root programs work in practice when security 
requirements change? If the same root CAs are in version N and version 
N+1 of a root store and version N+1 adopts a stricter security policy - 
can these root CAs still issue certificates for version N?


- What are the consequences of making it easier to establish new root 
programs? For governments that have previously tried to build domestic 
root programs, would solve some of the problems they faced and encourage 
them to try again?


Ultimately, these are two complex drafts which propose substantial 
changes to TLS and the WebPKI. Besides evaluating the technical details 
in the draft themselves, we also have to tackle the nitty gritty 
operational questions about how a new system would work in practice—in 
particular, considering the incentives of the stakeholders to adopt the 
system and or to deliberately deviate from the intended protocol for 
self-benefit.


Finally, in any proposal which alters the power dynamics of a system, 
there will be difficult questions of a political nature, especially when 
the system in question is depended upon by billions of people.


Naturally, good people will often disagree on the nuances of these 
complex topics. However, we owe it to each other to communicate 
constructively, arrive at a shared understanding and find a path 
forwards that as much of the community as possible can support.


Best,

Dennis


[1] https://en.wikipedia.org/wiki/User-Agent_header#User_agent_spoofing


___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Dennis Jackson]

On 24/07/2024 12:59, Tim Hollebeek wrote:


I think this is a good summary.  I want to support this sort of effort, in part 
because it's very similar to some other ideas my boss and I were pushing about 
five years ago.  Something similar to this would solve, but also cause, lots of 
problems.  It's not clear whether the net result is better or worse.

But I find it difficult or impossible to evaluate for exactly the reasons 
Dennis mentions: there's no context explaining how it will be used, or any 
discussion of the impact on the many other things that would need to change for 
this draft to be useful.

We need to have open and honest discussions about how roots and root management 
will work going forward, if we want things to work differently in the future.

-Tim


Thanks Tim and Ilari!

In the meeting on Wednesday, there was only a few minutes for discussion 
at the end of the session.


However, the chairs did propose a vote on 'If we were to adopt T.E. or 
T.A.I, which draft would you prefer?' (to be clear, there was no way for 
participants to indicate 'adopt neither draft'). That vote showed a 
strong preference for the new Trust Anchor Indicators draft over the 
older Trust Expressions draft which really helps narrow the discussion 
going forwards.


Watson proposed an interim which was supported by 10+ people in the 
meeting [1] and I think is a clear signal that folks feel further 
discussion is necessary. If the chairs can facilitate either an interim 
or a dedicated session for this topic at the next IETF meeting, I would 
be very happy to give a presentation to explain the concerns about both 
the risks and the practicality of the proposal. I hope the authors would 
also be willing present their answers to some of the questions below, 
including their vision for delivering (fully) Post-Quantum TLS and their 
proposal's role inwithin that.


I look forward to reading the author's updated draft when they've had a 
chance to integrate the feedback from this meeting and will be happy to 
adjust my own comments once the new draft is ready.


In the meantime, I think the mailing lists (and my keyboard) could 
certainly use the rest.


Safe Travels, Dennis

[1] 
https://drive.google.com/file/d/1lgGb3htLz0cO__tnEJPk_ga5X64RsMB6/view?usp=sharing 



Original: 
https://zulip.ietf.org/#narrow/stream/140-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 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 critical for making progress.
It is almost impossible to have sensible conversations about new drafts
without agreeing on and understanding the problems we want to solve.

The vast majority of folks I've spoken with have said they're interested in
solving the challenges around deploying fully PQ TLS, but don't feel that we
are currently close to a shared understanding of those challenges or the
tradeoffs around the drafts on the table today.

A smaller number of folks are interested in tackling other problems around
root store management. I fear this aspect of the problem space is even less
clearly understood and I heard very little agreement on what the key
challenges are or how they might be addressed.

I hope tomorrow we can focus our discussion on figuring out as a WG the
problem(s) that we want to tackle and where we differ in our understanding
of those problems. I am sure that 20 minutes will not be enough time to
resolve these complex issues, but I hope we can find a way to continue the
conversation constructively.

Ahead of the meeting tomorrow, I want to highlight some of the questions
which I think we need to find and agree on answers for:

- What are the problems that we solving?

- Who are we solving these problems for? Browsers or everyone?

- Are we proposing a hard requirement on this negotiation mechanism for
anyone wanting to do fully PQ TLS?

- Can the proposed mechanism be enabled by default in TLS Libraries without
requiring application changes?

- Can the proposed mechanism support use in a private PKI? How about in a
private PKI that runs over the public Internet (in the now-classic zero-trust
networking model)?

- What is the long-term vision for TLS and the WebPKI? Are we moving
forward together or fragmenting?

- How do the proposed mechanisms affect TLS Client Hello fingerprinting or
other tracking vectors?

- How would the proposed system work in practice? What happens when
actors follow their own interests rather than the requirements of RFCs?

- Are less popular clients incentivized to lie in their Trust Expressions about
wh

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

[Dennis Jackson]

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 Identifiers draft was first published only 4 weeks ago, 
received less than 10 minutes of discussion in the meeting and has a lot 
of unaddressed issues.


We would have had more time to discuss these issues if the author's 
presentation had focused on their new draft, rather than splitting the 
limited time with Trust Expressions, which I think we already knew was 
not going to be a viable option.


Many participants in the meeting expressed a preference for an interim 
so I would be surprised if there was a rough consensus for adoption. 
Especially as the concerns are fundamental to the design rather than 
about issues which could be addressed later.


However, I'm sure the chairs will be gauging the mood based on their own 
conversations with WG participants and deciding accordingly.


PQ TLS on the other hand has a lot of open questions about things like 
different variants of Merkle Tree Certificates that I would love to 
flesh out further.


I completely agree, though I think the first task will be getting a 
shared understanding of the challenges and requirements. I'm excited to 
talk about the different variants of MTC as well.


Best,
Dennis

N.B. I had to retype this message. I"m not sure if the original is going 
to show up on the list or not.



___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Dennis Jackson]

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 Identifiers draft was first published only 4 weeks ago, 
received less than 10 minutes of discussion in the meeting and has a lot 
of unaddressed issues.


I feel that if the authors had chosen to focus their presentation on 
their new draft, rather than splitting their time slot with Trust 
Expressions, there would have been much more time for discussion at the 
end of the meeting.


As I noted, many participants in the meeting expressed a preference for 
an interim so I would be surprised if there was support for adoption. 
Especially as the concerns I want to present are fundamental to the 
design rather than about issues which could be addressed later.


However, I'm sure the chairs will gauge how close we are to a rough 
consensus on adoption based on their own conversations with the other WG 
participants.


PQ TLS on the other hand has a lot of open questions about things like 
different variants of Merkle Tree Certificates that I would love to 
flesh out further. If we want an interim, we should focus on that 
question, and leave trust anchors out of the discussion, in my 
opinion, moving them towards adoption instead of drawing out the 
process even longer.


I agree the scope of PQ TLS is much wider and will also need some 
substantial time to discuss. I think the first job will be figuring out 
problems we're trying to solve and our requirements, but I'm excited to 
talk about the different variants of MTC as well.


Best,
Dennis


___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Dennis Jackson]

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 Identifiers draft was first published only 4 weeks ago, 
received less than 10 minutes of discussion in the meeting and has a lot 
of unaddressed issues.


We would have had more time to discuss these issues if the author's 
presentation had focused on their new draft, rather than splitting the 
limited time with Trust Expressions, which I think we already knew was 
not going to be a viable option.


Many participants in the meeting expressed a preference for an interim 
so I would be surprised if there was a rough consensus for adoption. 
Especially as the concerns are fundamental to the design rather than 
about issues which could be addressed later.


However, I'm sure the chairs will be gauging the mood based on their own 
conversations with WG participants and deciding accordingly.


PQ TLS on the other hand has a lot of open questions about things like 
different variants of Merkle Tree Certificates that I would love to 
flesh out further.


I completely agree, though I think the first task will be getting a 
shared understanding of the challenges and requirements, but I'm excited 
to talk about the different variants of MTC as well.


Best,
Dennis

N.B. I had to re-type this message. I"m not sure if the original is 
going to show up on the list or not.


___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Trust Anchor IDs and PQ

[Dennis Jackson]

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 client can safely
   provide only that TA in the ClientHello while offering a wider set
   of TAs to other servers. This can also be used on the client
   side to measure PQ support on servers.


I haven't seen this come up in discussion before, but I don't think this 
is a meaningful use case.


The type 3 clients don't get any additional security unless they can 
enforce the use of PQ in future connections to that site. Otherwise, an 
attacker can always force this client back to advertising and accepting 
a traditional algorithm. This requires some kind of active signal from 
the server to the client, which the server is going to have to 
consent+commit to anyway, so I don't think trying to mess around with 
the Client Hello to coerce servers can deliver any benefit. Also, I'm 
not sure I can imagine a scenario where there's enough server-side PQ 
support for type 4 clients to exist, but with some servers still 
unwilling to send PQ signatures when offered.


On 03/02/2025 12:57, Bas Westerbaan wrote:

On the negative side, I think it's not clear whether we'll reach 4 
(clients stop advertising traditoinal algs) when the CRQC arrives: 
there could well be sufficiently many servers that don't support PQ EE 
certs yet.


On the positive side, I think we might be able to get more security 
than you suggest before 4.


I agree. I expect this transition will look much like the shift from 
HTTP to HTTPS so it's vital that we have a mechanism where clients and 
servers which have already deployed PQ-support can benefit from it. This 
means providing a way for servers to signal to clients "Please don't 
ever fall back to non-PQ algorithms when connecting to me in the future" 
and having clients store + enforce that signal. Putting this signal in 
DNS isn't acceptable because we want to provide security even when DNS 
is compromised / unauthenticated.


As Bas writes, this signal could be conveyed through a special kind of 
certificate. However, besides the other issues Bas identifies, the 
sketched design would be very hard to deploy because it relies on the 
general body of server operators to take multiple actions: "Remember to 
opt-in to the non-PQ cert package. Remember to opt-out of the non-PQ 
cert package when you deploy PQ support. Remember to monitor CT going 
forward." and it fails if they omit any step. It's reasonable to expect 
security-motivated server operators to go out of their way to do these 
things, but not the general population.


I think HSTS provides the basis for a more effective solution. It needs 
only to be extended with a single additional bit ("Enforce use of PQ 
signatures") and it's already well-understood by website operators. 
Managing the preload list is a bit unpleasant for browsers, but strictly 
speaking the preload list is an optional component of HSTS which is used 
only to protect the very first connection between a client and a site 
(non-preload HSTS protects all subsequent connections) and in any case I 
don't think there's an alternative for first-connection protection.


Best,
Dennis

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption Call for Trust Anchor IDs

[Dennis Jackson]

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 credible proposal for how TN could 
be deployed outside of browsers and major CDNs or how it could bring any 
benefit at all with such a limited scope for deployment. It's not like 
major CDNs struggle to offer certificates suitable for browsers.


Even if the deployability concerns could be solved and so Trust 
Negotiation enabled at scale, then it would cause much more harm than 
good. Managing one certificate chain and CA relationship is already 
painful for many website operators, but TN would compound that pain by 
allowing root programs to diverge and placing the onus on website 
operators to obtain and manage multiple certificate chains to ensure 
compatibility with each root program's clients.


It would also be a major abuse vector for users, who are much more 
likely to suffer than benefit from the resulting fragmentation of the 
WebPKI, as well as being put at risk by use of TN to establish new root 
programs with malicious or negligent stewardship (domestic PKIs, 
enshittification, ossification).


In both cases, the result is a claimed reduction in operational burden 
for root programs and major CDNs (who have the most capacity and 
expertise to handle it) and the very material transfer of risk and 
complexity to users and website operators (who are least well equipped).


As technologists evaluating a proposal that would alter the architecture 
of one of the Internet's most critical ecosystems, we owe users and 
website operators better.


Best,
Dennis

[1] 
https://datatracker.ietf.org/doc/html/draft-jackson-tls-trust-is-nonnegotiable








Below the fold, some comments on the discussion so far:

*On Cross Signing
*

The current solution to trust anchor agility is path building / 
cross-signing. [...] I firmly believe that path building is 
unsalvageable. In addition to the interim discussions, this blog post 
[2] by Ryan Sleevi was very convincing to me. 


I read Ryan's blog post and came to some very different conclusions.

Doing path building 'right' was a problem solved a very long time ago in 
browsers and many other implementations. Implementations that still 
aren't getting it right today simply don't care about the problem enough 
to fix it. If they did care, they would just fix their implementation, 
as indeed OpenSSL had already done 2 years before Ryan's blog post was 
published.


Your argument rests on the idea that someone not doing path building 
correctly today would be willing to do the extra work of implementing 
TAI (including the necessary API changes and DNS integration) and would 
implement it correctly, but would be unwilling to make the smaller and 
simpler changes to fix up their path building implementation. This 
doesn't make much sense.


*On coming PKI transitions
*

My interest is particularly in the WebPKI space, where annual removals 
of web trust bits starting this year will make finding common trust 
amongst clients an exponentially harder problem over time.
Looking at the kind of time its taken to get TLS 1.3, QUIC, ECH and 
other standards into the wider world, I think this perspective is 
extremely optimistic. No matter what, root programs are going to be 
managing the coming root transitions exclusively with cross-signing.


*On dealing with issues post-adoption*

I feel it’s appropriate for the working group to adopt. We can always 
stop before standardizing, or not deploy this stuff, when it becomes 
clear we were wrong.


Once the code has shipped, the genie doesn't go easily back into the 
bottle. There's a right time to address these issues and that's as early 
as possible.


[2] 
https://medium.com/@sleevi_/path-building-vs-path-verifying-the-chain-of-pain-9fbab861d7d6




___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Trust Anchor IDs and PQ

[Dennis Jackson]

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 directions, but this transition to PQ is 
really just a transition to treating TLS with classical crypto as 
equivalent to not using TLS at all. The lessons from the last 10 years 
of HTTPS adoption apply pretty much directly.
PQ HSTS (plus preload)  is interesting and worthwhile for popular 
domains, but it can't carry the weight for the whole Internet, as it 
requires turning off classical crypto after the CRQC arrives. May I 
first challenge you to turn off plain HTTP in Firefox :)?


I don't think we're ever going to be able to turn off plain HTTP or 
classical crypto. We're just going to have scarier and scarier warnings 
according to the frequency with which we expect users to encounter them.


HSTS, or any other transition strategy, is about providing security for 
early adopters by preventing downgrade attacks. Late adopters get nudged 
by bad UX (broken padlocks, interstitials, etc) rather than any 
self-interest in cryptography or actively managing certificates.




___
TLS mailing list --tls@ietf.org
To unsubscribe send an email totls-le...@ietf.org___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: PKI dynamics and trust anchor negotiation

[Dennis Jackson]

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 as the consequences of enabling the deployment of new root 
programs with divergent policies. Unfortunately, fragmentation is often 
an insidious, gradual process that arises from many actors making 
independent decisions that prioritize their own needs, in the absence of 
any ecosystem forces strong enough to bring them together. It doesn't 
have to be a goal that is pursued deliberately, although it can also be 
(e.g. market differentiation or enshittification).


Separately, structural barriers to deployment of a new technology, which 
impact certain constituencies much more than others, are a common cause 
of ecosystem fragmentation. The specific design of TAI has serious 
issues in this regard which are laid out in section 4.6 [2].


The argument that this fragmentation is possible with existing 
mechanisms like certificate_authorities is evaluated at the end of the 
section 3.3 [3]. These extensions do not have any meaningful 
existence in the wild for the purposes of server certificate negotiation 
and it's running code that counts here. Further, for the same reasons 
that the TAI authors identified these extensions as an unsatisfactory 
solution for their needs, it is unsuitable for anyone else trying to 
deploy trust negotiation at scale.


Finally, as is discussed throughout Section 3, I disagree there is any 
security tradeoff at the heart of this issue. We've shipped many many 
improvements over the past 10+ years through the steady ratcheting of 
root program policies. Instead, I believe barriers to further 
improvements are predominantly found server-side, in the level of 
investment that server operators (and to a lesser extent CAs) are 
willing to make in terms of libraries, automation and tooling. Trust 
negotiation does nothing to address these issues, which are largely 
societal rather than technical.


Best,
Dennis

[1] 
https://datatracker.ietf.org/doc/html/draft-jackson-tls-trust-is-nonnegotiable#section-3.3


[2] 
https://datatracker.ietf.org/doc/html/draft-jackson-tls-trust-is-nonnegotiable#section-4.6


[3] 
https://datatracker.ietf.org/doc/html/draft-jackson-tls-trust-is-nonnegotiable#name-alternative-paths-to-abuse


___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Changing WG Mail List Reputation

[Dennis Jackson]

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 objections to solution B are 
painstakingly addressed.


This is slightly adjacent to the point you were making, but I think 
there's an implicit assumption here which is different from 'rough 
consensus' as I understand it. RFC 2418 [1] lays out:



In general, the dominant view of the working group shall prevail.
(However, it must be noted that "dominance" is not to be determined on the 
basis of volume or persistence,
but rather a more general sense of agreement.)
[...]
Note that 51% of the working group does not qualify as "rough consensus" and 
99% is better than rough.


RFC 7282 [2], perhaps more an ideal rather than any actual description 
of IETF practice, explores the last part further in the sections: "One 
hundred people for and five people against might not be rough consensus" 
and "Five people for and one hundred people against might still be rough 
consensus".


I know at least a few implementers that don't engage with the IETF 
because they don't have time for all that.

Coming back to your main point, I agree this is a real problem.

I don't know how it can be effectively addressed for when folks want to 
change the core Internet protocols which are stewarded by the IETF.


However, I think many of the folks who are put off contributing are 
instead trying to bring their new ideas and designs to a wider 
community, rather than tinker with existing systems. The IETF could do a 
much better job of helping them share their work with the community by 
supporting and sign-posting lower process methods for publishing specs 
(e.g. informational) which produce similarly useful outputs (IMO) but 
don't incur the same overhead and drama on the mailing lists.


Best,
Dennis

[1] https://datatracker.ietf.org/doc/rfc2418/

[2] https://datatracker.ietf.org/doc/rfc7282/
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org