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

[Deirdre Connolly]

> Isn't support for the component mandatory to support the hybrid anyway?

Strictly speaking, not necessarily: I could see support for X-Wing or
another hybrid key agreement as a standalone unit, both from a software
dependency perspective and protocol API perspective. Whether that works in
the long term that also supports the standalone component algorithms,
that's another question

On Wed, Mar 6, 2024, 11:30 PM Orie Steele  wrote:

> Does the argument about hybrid code points first generalize to all PQ Code
> points?
>
> Is it equally true of hybrid signatures?
>
> I don't understand why registering composite components first wouldn't be
> assumed.
>
> Isn't support for the component mandatory to support the hybrid anyway?
>
> Let's assume CRQC drops tomorrow, why did we not register ML-KEM first?
>
> Assume it never drops, you still needed to implement ML-KEM to use the
> hybrid.
>
> If the goal is to prohibit ML-KEM without a traditional component, just
> register it as prohibited.
>
> OS
>
> On Wed, Mar 6, 2024, 10:10 PM Bas Westerbaan  40cloudflare@dmarc.ietf.org> wrote:
>
>> Back to the topic at hand. I think it'd very bad if we'd have a codepoint
>> for pure ML-KEM before we have a codepoint for an ML-KEM hybrid. Process
>> wise, I think that's up to the designated experts of the IANA registry.
>>
>> Best,
>>
>>  Bas
>>
>>
>> On Wed, Mar 6, 2024 at 3:16 AM Deirdre Connolly 
>> wrote:
>>
>>> I have uploaded a preliminary version of ML-KEM for TLS 1.3
>>> 
>>> and have a more fleshed out
>>>  version to
>>> be uploaded when datatracker opens. It is a straightforward new
>>> `NamedGroup` to support key agreement via ML-KEM-768 or ML-KEM-1024, in a
>>> very similar style to -hybrid-design
>>> .
>>>
>>> It will be nice to have pure-PQ options (that are FIPS / CNSA 2.0
>>> compatible) ready to go when users are ready to use them.
>>>
>>> Cheers,
>>> 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
>>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Orie Steele]

Does the argument about hybrid code points first generalize to all PQ Code
points?

Is it equally true of hybrid signatures?

I don't understand why registering composite components first wouldn't be
assumed.

Isn't support for the component mandatory to support the hybrid anyway?

Let's assume CRQC drops tomorrow, why did we not register ML-KEM first?

Assume it never drops, you still needed to implement ML-KEM to use the
hybrid.

If the goal is to prohibit ML-KEM without a traditional component, just
register it as prohibited.

OS

On Wed, Mar 6, 2024, 10:10 PM Bas Westerbaan  wrote:

> Back to the topic at hand. I think it'd very bad if we'd have a codepoint
> for pure ML-KEM before we have a codepoint for an ML-KEM hybrid. Process
> wise, I think that's up to the designated experts of the IANA registry.
>
> Best,
>
>  Bas
>
>
> On Wed, Mar 6, 2024 at 3:16 AM Deirdre Connolly 
> wrote:
>
>> I have uploaded a preliminary version of ML-KEM for TLS 1.3
>> 
>> and have a more fleshed out
>>  version to
>> be uploaded when datatracker opens. It is a straightforward new
>> `NamedGroup` to support key agreement via ML-KEM-768 or ML-KEM-1024, in a
>> very similar style to -hybrid-design
>> .
>>
>> It will be nice to have pure-PQ options (that are FIPS / CNSA 2.0
>> compatible) ready to go when users are ready to use them.
>>
>> Cheers,
>> 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
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Deirdre Connolly]

No objection there 

On Wed, Mar 6, 2024, 11:10 PM Bas Westerbaan  wrote:

> Back to the topic at hand. I think it'd very bad if we'd have a codepoint
> for pure ML-KEM before we have a codepoint for an ML-KEM hybrid. Process
> wise, I think that's up to the designated experts of the IANA registry.
>
> Best,
>
>  Bas
>
>
> On Wed, Mar 6, 2024 at 3:16 AM Deirdre Connolly 
> wrote:
>
>> I have uploaded a preliminary version of ML-KEM for TLS 1.3
>> 
>> and have a more fleshed out
>>  version to
>> be uploaded when datatracker opens. It is a straightforward new
>> `NamedGroup` to support key agreement via ML-KEM-768 or ML-KEM-1024, in a
>> very similar style to -hybrid-design
>> .
>>
>> It will be nice to have pure-PQ options (that are FIPS / CNSA 2.0
>> compatible) ready to go when users are ready to use them.
>>
>> Cheers,
>> 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] ML-KEM key agreement for TLS 1.3

[Bas Westerbaan]

Back to the topic at hand. I think it'd very bad if we'd have a codepoint
for pure ML-KEM before we have a codepoint for an ML-KEM hybrid. Process
wise, I think that's up to the designated experts of the IANA registry.

Best,

 Bas


On Wed, Mar 6, 2024 at 3:16 AM Deirdre Connolly 
wrote:

> I have uploaded a preliminary version of ML-KEM for TLS 1.3
> 
> and have a more fleshed out
>  version to
> be uploaded when datatracker opens. It is a straightforward new
> `NamedGroup` to support key agreement via ML-KEM-768 or ML-KEM-1024, in a
> very similar style to -hybrid-design
> .
>
> It will be nice to have pure-PQ options (that are FIPS / CNSA 2.0
> compatible) ready to go when users are ready to use them.
>
> Cheers,
> 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] ML-KEM key agreement for TLS 1.3

[Bas Westerbaan]

The cost of hybrids is not high, but it's certainly not negligible. I can't
share the exact number of servers we'd be able to cut if we'd go pure PQ,
but with a back of the envelope calculation I think you can convince
yourself that we could've at least hired an engineer instead. We think it's
worth it now, but of course we're not going to keep hybrids around when the
CRQC arrives.

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 <
> durumcrustu...@gmail.com> 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] draft-ietf-tls-cert-abridge Update

[Kampanakis, Panos]

Good point, understood, thanks.

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

I think the former sounds more reasonable. 2 codepoints for (only CA pass 1 
compression) and (Pass1+Pass2) seems to be wasting codepoints.

The problem I am trying to address is cases where 1/ SCTs are not available 
(like Private PKIs), or 2/ the server is lazy and does not want to create that 
dictionary, or 3/ the benefit of Pass 2 is not important enough. I understand 
that you will collect data for 3/ to hopefully prove it, so I will wait for 
those. But I think 1/ and 2/ are still worth addressing.


From: TLS  On Behalf Of Dennis Jackson
Sent: Wednesday, March 6, 2024 7:39 AM
To: tls@ietf.org
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 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
___
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]

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

[Watson Ladd]

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

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

[Rob Sayre]

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.

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

[TLS] Draft on "TLS 1.2 feature freeze"

[Salz, Rich]

The draft, having been adopted, is now part of the TLSWG github repository at 
[1]

Once the posting freeze is over I’ll post a version. The only real change from 
the call-for-adoption one is that it now says
Bluntly, post-quantum cryptography for
TLS 1.2 WILL NOT be supported

I don’t think there’s anything to present at 119, happy to take questions 
should there be any.

[1] https://github.com/tlswg/tls12-frozen
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[D. J. Bernstein]

Andrey Jivsov writes:
> Does this point apply in your opinion to hash-based signatures?

Yes. Here's a comment I made about this topic in CFRG a few weeks ago:
"I've sometimes run into people surprised that I recommend _always_
using hybrids rather than making exceptions for McEliece and SPHINCS+.
This is easy to answer: When a defense is simple and easily affordable,
why make exceptions? Many reviewers aren't familiar with post-quantum
cryptography; why give them excuses to delay deployment? Also, if some
random McEliece implementation has a devastating bug, is blaming the
programmer really the right answer?"

---D. J. Bernstein

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

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

[Deirdre Connolly]

> So I think the question here should be focused on "what level of
confidence would IETF need to specify ML-KEM standalone at Proposed
Standard with Recommended=Y".

On 'Recommended=Y' I figured it would not be for a while, but it is
available.

>  I don't think there is anywhere near enough confidence in any of the PQ
algorithms to confidently use it standalone,

Crystals-Kyber was introduced in at least 2017, it has gone through many
rounds of analysis, and is now over 7 years old, close to the '10 years' I
often hear quoted as a benchmark for new crypto to marinate I guess. I
understand caution but having the option (not the recommendation) to
support pure-PQ seems reasonable to sort out sooner than later, both to
face the complexity of managing pure traditional, hybrid, and pure PQ
negotiation now, but also to keep the eventual goal of pure PQ clear in
mind, and taken seriously.

On Wed, Mar 6, 2024 at 12:21 PM 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.
>
> I'm open to being persuaded, but at the moment, I don't think there is
> anywhere near enough confidence in any of the PQ algorithms to confidently
> use it standalone, which means we're going to see a lot of hybrid
> deployment sooner rather than later. This also means that we're going to
> have a long tail of clients and servers which only do hybrid and not
> PQ-only, so that complexity is baked in for quite some time to come.
>
>
>> In the more concrete scope, FIPS / CNSA 2.0 compliance guidelines
>> 
>> currently are a big 'maybe' at best for 'hybrid solutions', and the
>> timetables for compliant browsers, servers, and services are to exclusively
>> use FIPS 203 at level V (ML-KEM-1024) by 2033. I figure there will be
>> demand for pure ML-KEM key agreement, not hybrid (with no questions that
>> come along with it of whether it's actually allowed or not).
>>
>
> I'm honestly not moved by this very much. IETF should form its own opinion
> about the security of algorithms, not just take whatever opinions are
> handed down from NIST. If that means that IETF doesn't standardize what
> NIST wants, then NIST is free to register its own codepoints and try to
> persuade implementors to take them.
>
> So I think the question here should be focused on "what level of
> confidence would IETF need to specify ML-KEM standalone at Proposed
> Standard with Recommended=Y".
>
> -Ekr
>
>
>> Relatedly, the currently adopted -hybrid-design
>> 
>> outlines several combinations of ECDH and KEM, and allows computing the
>> ECDH share once and sharing it between an ECDH share and a hybrid ECDH+KEM
>> share, but there is no equivalent for just using a KEM on its own, and
>> computing its shared secret once and advertising it as both standalone and
>> in a hybrid share. So I think defining these standalone ML-KEM
>> `NamedGroup`s also 'draws the rest of the owl' implied by -hybrid-design.
>>
>> On Wed, Mar 6, 2024 at 10:12 AM Eric Rescorla  wrote:
>>
>>> Deirdre, thanks for submitting this. Can you say what the motivation is
>>> for being "fully post-quantum" rather than hybrid?
>>>
>>> Thanks,
>>> -Ekr
>>>
>>>
>>>
>>> On Tue, Mar 5, 2024 at 6:16 PM Deirdre Connolly <
>>> durumcrustu...@gmail.com> wrote:
>>>
 I have uploaded a preliminary version of ML-KEM for TLS 1.3
 
 and have a more fleshed out
  version
 to be uploaded when datatracker opens. It is a straightforward new
 `NamedGroup` to support key agreement via ML-KEM-768 or ML-KEM-1024, in a
 very similar style to -hybrid-design
 .

 It will be nice to have pure-PQ options (that are FIPS / CNSA 2.0
 compatible) ready to go when users are ready to use them.

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

[Eric Rescorla]

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.

I'm open to being persuaded, but at the moment, I don't think there is
anywhere near enough confidence in any of the PQ algorithms to confidently
use it standalone, which means we're going to see a lot of hybrid
deployment sooner rather than later. This also means that we're going to
have a long tail of clients and servers which only do hybrid and not
PQ-only, so that complexity is baked in for quite some time to come.


> In the more concrete scope, FIPS / CNSA 2.0 compliance guidelines
> 
> currently are a big 'maybe' at best for 'hybrid solutions', and the
> timetables for compliant browsers, servers, and services are to exclusively
> use FIPS 203 at level V (ML-KEM-1024) by 2033. I figure there will be
> demand for pure ML-KEM key agreement, not hybrid (with no questions that
> come along with it of whether it's actually allowed or not).
>

I'm honestly not moved by this very much. IETF should form its own opinion
about the security of algorithms, not just take whatever opinions are
handed down from NIST. If that means that IETF doesn't standardize what
NIST wants, then NIST is free to register its own codepoints and try to
persuade implementors to take them.

So I think the question here should be focused on "what level of confidence
would IETF need to specify ML-KEM standalone at Proposed Standard with
Recommended=Y".

-Ekr


> Relatedly, the currently adopted -hybrid-design
> 
> outlines several combinations of ECDH and KEM, and allows computing the
> ECDH share once and sharing it between an ECDH share and a hybrid ECDH+KEM
> share, but there is no equivalent for just using a KEM on its own, and
> computing its shared secret once and advertising it as both standalone and
> in a hybrid share. So I think defining these standalone ML-KEM
> `NamedGroup`s also 'draws the rest of the owl' implied by -hybrid-design.
>
> On Wed, Mar 6, 2024 at 10:12 AM Eric Rescorla  wrote:
>
>> Deirdre, thanks for submitting this. Can you say what the motivation is
>> for being "fully post-quantum" rather than hybrid?
>>
>> Thanks,
>> -Ekr
>>
>>
>>
>> On Tue, Mar 5, 2024 at 6:16 PM Deirdre Connolly 
>> wrote:
>>
>>> I have uploaded a preliminary version of ML-KEM for TLS 1.3
>>> 
>>> and have a more fleshed out
>>>  version to
>>> be uploaded when datatracker opens. It is a straightforward new
>>> `NamedGroup` to support key agreement via ML-KEM-768 or ML-KEM-1024, in a
>>> very similar style to -hybrid-design
>>> .
>>>
>>> It will be nice to have pure-PQ options (that are FIPS / CNSA 2.0
>>> compatible) ready to go when users are ready to use them.
>>>
>>> Cheers,
>>> 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] ML-KEM key agreement for TLS 1.3

[Deirdre Connolly]

My current draft does not include ML-KEM-512, mostly because there seems to
be alignment around ML-KEM-768 being ~equivalent to say X25519 or P-256
ECDH in terms of security level. I'm not married strongly to excluding it
but that was kind of the thinking.

On Wed, Mar 6, 2024 at 11:25 AM John Mattsson 
wrote:

> I think TLS should register all algorithm variants standardized by NIST.
> That means ML-KEM-512, ML-KEM-768, and ML-KEM-1024. And in the future a
> subset of HQC/BIKE/Classic McEliece.
>
> I think the TLS discussions are way too focused on a single ephemeral key
> exchange. A growing use of TLS is for mutually authenticated interfaces.
> When IPsec is used, rekeying is typically done with ephemeral key exchange
> every 1 hour or 100 GB following ANSSI requirements. The telecom industry
> would like to keep that practice when TLS/DTLS/QUIC is used instead. In TLS
> 1.3 that means resumption with psk_dhe_ke. I don’t think you need to use
> the same algorithm in the initial handshake and the resumption. You can
> e.g., use ML-KEM-1024 + x25519 in the initial handshake and then ML-KEM-512
> in resumption. You could also use McEliece initially and then ML-KEM. I
> think you could even use ML-KEM + x25519 in the initial handshake and then
> x25519 during resumption. I think these choices should be left to the
> application.
>
> Cheers,
> John Preuß Mattson
>
> Sent from Outlook for iOS 
> --
> *From:* TLS  on behalf of John Mattsson
> 
> *Sent:* Wednesday, March 6, 2024 4:57:10 PM
> *To:* Deirdre Connolly 
> *Cc:* TLS@ietf.org 
> *Subject:* Re: [TLS] ML-KEM key agreement for TLS 1.3
>
>
> Thanks Deirdre,
>
>
>
> I would like to use hybrid but I strongly believe that registering things
> as standalone NamedGroups and then let TLS negotiate which combinations to
>  use is the right one long-term. This is the approch chosen be IKEv2.
>
>
>
> - As EKR pointed out the word "fully" would need explanation.
>
>
>
> - We align with [hybrid] except that instead of joining ECDH options
>
>   with a KEM, we just have the KEM as a NamedGroup.
>
>
>
>   I don't understand. We align with hybrid by not being hybrid?
>
>
>
> - encapsulated shared secret ciphertext
>
>
>
> Maybe shared secret encapsulated in the ciphertext?
>
>
>
> Cheers,
>
> John
>
>
>
> *From: *TLS  on behalf of Eric Rescorla <
> e...@rtfm.com>
> *Date: *Wednesday, 6 March 2024 at 16:12
> *To: *Deirdre Connolly 
> *Cc: *TLS@ietf.org 
> *Subject: *Re: [TLS] ML-KEM key agreement for TLS 1.3
>
> Deirdre, thanks for submitting this. Can you say what the motivation is
> for being "fully post-quantum" rather than hybrid?
>
>
>
> Thanks,
>
> -Ekr
>
>
>
>
>
>
>
> On Tue, Mar 5, 2024 at 6:16 PM Deirdre Connolly 
> wrote:
>
> I have uploaded a preliminary version of ML-KEM for TLS 1.3
> 
> and have a more fleshed out
> 
>  version
> to be uploaded when datatracker opens. It is a straightforward new
> `NamedGroup` to support key agreement via ML-KEM-768 or ML-KEM-1024, in a
> very similar style to -hybrid-design
> .
>
>
>
> It will be nice to have pure-PQ options (that are FIPS / CNSA 2.0
> compatible) ready to go when users are ready to use them.
>
>
>
> Cheers,
>
> 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] ML-KEM key agreement for TLS 1.3

[Deirdre Connolly]

>  I don't understand. We align with hybrid by not being hybrid?

Ah sorry, I mean on the design of how the client shares an
ephemeral encapsulation key in their `ClientHello` and how the server
replies with the ciphertext in their `ServerHello`, and generally aligning
in design and encoding with -hybrid-design, I'll clarify.

On Wed, Mar 6, 2024 at 10:57 AM John Mattsson 
wrote:

> Thanks Deirdre,
>
>
>
> I would like to use hybrid but I strongly believe that registering things
> as standalone NamedGroups and then let TLS negotiate which combinations to
>  use is the right one long-term. This is the approch chosen be IKEv2.
>
>
>
> - As EKR pointed out the word "fully" would need explanation.
>
>
>
> - We align with [hybrid] except that instead of joining ECDH options
>
>   with a KEM, we just have the KEM as a NamedGroup.
>
>
>
>   I don't understand. We align with hybrid by not being hybrid?
>
>
>
> - encapsulated shared secret ciphertext
>
>
>
> Maybe shared secret encapsulated in the ciphertext?
>
>
>
> Cheers,
>
> John
>
>
>
> *From: *TLS  on behalf of Eric Rescorla <
> e...@rtfm.com>
> *Date: *Wednesday, 6 March 2024 at 16:12
> *To: *Deirdre Connolly 
> *Cc: *TLS@ietf.org 
> *Subject: *Re: [TLS] ML-KEM key agreement for TLS 1.3
>
> Deirdre, thanks for submitting this. Can you say what the motivation is
> for being "fully post-quantum" rather than hybrid?
>
>
>
> Thanks,
>
> -Ekr
>
>
>
>
>
>
>
> On Tue, Mar 5, 2024 at 6:16 PM Deirdre Connolly 
> wrote:
>
> I have uploaded a preliminary version of ML-KEM for TLS 1.3
> 
> and have a more fleshed out
> 
>  version
> to be uploaded when datatracker opens. It is a straightforward new
> `NamedGroup` to support key agreement via ML-KEM-768 or ML-KEM-1024, in a
> very similar style to -hybrid-design
> .
>
>
>
> It will be nice to have pure-PQ options (that are FIPS / CNSA 2.0
> compatible) ready to go when users are ready to use them.
>
>
>
> Cheers,
>
> 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] ML-KEM key agreement for TLS 1.3

[Deirdre Connolly]

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

In the more concrete scope, FIPS / CNSA 2.0 compliance guidelines

currently are a big 'maybe' at best for 'hybrid solutions', and the
timetables for compliant browsers, servers, and services are to exclusively
use FIPS 203 at level V (ML-KEM-1024) by 2033. I figure there will be
demand for pure ML-KEM key agreement, not hybrid (with no questions that
come along with it of whether it's actually allowed or not).

Relatedly, the currently adopted -hybrid-design

outlines several combinations of ECDH and KEM, and allows computing the
ECDH share once and sharing it between an ECDH share and a hybrid ECDH+KEM
share, but there is no equivalent for just using a KEM on its own, and
computing its shared secret once and advertising it as both standalone and
in a hybrid share. So I think defining these standalone ML-KEM
`NamedGroup`s also 'draws the rest of the owl' implied by -hybrid-design.

On Wed, Mar 6, 2024 at 10:12 AM Eric Rescorla  wrote:

> Deirdre, thanks for submitting this. Can you say what the motivation is
> for being "fully post-quantum" rather than hybrid?
>
> Thanks,
> -Ekr
>
>
>
> On Tue, Mar 5, 2024 at 6:16 PM Deirdre Connolly 
> wrote:
>
>> I have uploaded a preliminary version of ML-KEM for TLS 1.3
>> 
>> and have a more fleshed out
>>  version to
>> be uploaded when datatracker opens. It is a straightforward new
>> `NamedGroup` to support key agreement via ML-KEM-768 or ML-KEM-1024, in a
>> very similar style to -hybrid-design
>> .
>>
>> It will be nice to have pure-PQ options (that are FIPS / CNSA 2.0
>> compatible) ready to go when users are ready to use them.
>>
>> Cheers,
>> 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] ML-KEM key agreement for TLS 1.3

[Ilari Liusvaara]

On Wed, Mar 06, 2024 at 04:25:16PM +, John Mattsson wrote:
> I think TLS should register all algorithm variants standardized by
> NIST. That means ML-KEM-512, ML-KEM-768, and ML-KEM-1024. And in
> the future a subset of HQC/BIKE/Classic McEliece.

Just as note, supporting Classic McEliece is not possible at all due to
the key size exceeding hard TLS 1.3 limit.

Even FrodoKEM, which seems to be quite widely viewed as "next step up"
from likes of ML-KEM, has painfully large keys. But at least those do
not bust any hard limits.




-Ilari

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

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

[John Mattsson]

I think TLS should register all algorithm variants standardized by NIST. That 
means ML-KEM-512, ML-KEM-768, and ML-KEM-1024. And in the future a subset of 
HQC/BIKE/Classic McEliece.

I think the TLS discussions are way too focused on a single ephemeral key 
exchange. A growing use of TLS is for mutually authenticated interfaces. When 
IPsec is used, rekeying is typically done with ephemeral key exchange every 1 
hour or 100 GB following ANSSI requirements. The telecom industry would like to 
keep that practice when TLS/DTLS/QUIC is used instead. In TLS 1.3 that means 
resumption with psk_dhe_ke. I don’t think you need to use the same algorithm in 
the initial handshake and the resumption. You can e.g., use ML-KEM-1024 + 
x25519 in the initial handshake and then ML-KEM-512 in resumption. You could 
also use McEliece initially and then ML-KEM. I think you could even use ML-KEM 
+ x25519 in the initial handshake and then x25519 during resumption. I think 
these choices should be left to the application.

Cheers,
John Preuß Mattson

Sent from Outlook for iOS

From: TLS  on behalf of John Mattsson 

Sent: Wednesday, March 6, 2024 4:57:10 PM
To: Deirdre Connolly 
Cc: TLS@ietf.org 
Subject: Re: [TLS] ML-KEM key agreement for TLS 1.3


Thanks Deirdre,



I would like to use hybrid but I strongly believe that registering things as 
standalone NamedGroups and then let TLS negotiate which combinations to  use is 
the right one long-term. This is the approch chosen be IKEv2.



- As EKR pointed out the word "fully" would need explanation.



- We align with [hybrid] except that instead of joining ECDH options

  with a KEM, we just have the KEM as a NamedGroup.



  I don't understand. We align with hybrid by not being hybrid?



- encapsulated shared secret ciphertext



Maybe shared secret encapsulated in the ciphertext?



Cheers,

John



From: TLS  on behalf of Eric Rescorla 
Date: Wednesday, 6 March 2024 at 16:12
To: Deirdre Connolly 
Cc: TLS@ietf.org 
Subject: Re: [TLS] ML-KEM key agreement for TLS 1.3

Deirdre, thanks for submitting this. Can you say what the motivation is for 
being "fully post-quantum" rather than hybrid?



Thanks,

-Ekr







On Tue, Mar 5, 2024 at 6:16 PM Deirdre Connolly 
mailto:durumcrustu...@gmail.com>> wrote:

I have uploaded a preliminary version of ML-KEM for TLS 
1.3  
and have a more fleshed 
out
 version to be uploaded when datatracker opens. It is a straightforward new 
`NamedGroup` to support key agreement via ML-KEM-768 or ML-KEM-1024, in a very 
similar style to 
-hybrid-design.



It will be nice to have pure-PQ options (that are FIPS / CNSA 2.0 compatible) 
ready to go when users are ready to use them.



Cheers,

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

[John Mattsson]

Thanks Deirdre,

I would like to use hybrid but I strongly believe that registering things as 
standalone NamedGroups and then let TLS negotiate which combinations to  use is 
the right one long-term. This is the approch chosen be IKEv2.

- As EKR pointed out the word "fully" would need explanation.

- We align with [hybrid] except that instead of joining ECDH options
  with a KEM, we just have the KEM as a NamedGroup.

  I don't understand. We align with hybrid by not being hybrid?

- encapsulated shared secret ciphertext

Maybe shared secret encapsulated in the ciphertext?

Cheers,
John

From: TLS  on behalf of Eric Rescorla 
Date: Wednesday, 6 March 2024 at 16:12
To: Deirdre Connolly 
Cc: TLS@ietf.org 
Subject: Re: [TLS] ML-KEM key agreement for TLS 1.3
Deirdre, thanks for submitting this. Can you say what the motivation is for 
being "fully post-quantum" rather than hybrid?

Thanks,
-Ekr



On Tue, Mar 5, 2024 at 6:16 PM Deirdre Connolly 
mailto:durumcrustu...@gmail.com>> wrote:
I have uploaded a preliminary version of ML-KEM for TLS 
1.3  
and have a more fleshed 
out
 version to be uploaded when datatracker opens. It is a straightforward new 
`NamedGroup` to support key agreement via ML-KEM-768 or ML-KEM-1024, in a very 
similar style to 
-hybrid-design.

It will be nice to have pure-PQ options (that are FIPS / CNSA 2.0 compatible) 
ready to go when users are ready to use them.

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

[Eric Rescorla]

Deirdre, thanks for submitting this. Can you say what the motivation is for
being "fully post-quantum" rather than hybrid?

Thanks,
-Ekr



On Tue, Mar 5, 2024 at 6:16 PM Deirdre Connolly 
wrote:

> I have uploaded a preliminary version of ML-KEM for TLS 1.3
> 
> and have a more fleshed out
>  version to
> be uploaded when datatracker opens. It is a straightforward new
> `NamedGroup` to support key agreement via ML-KEM-768 or ML-KEM-1024, in a
> very similar style to -hybrid-design
> .
>
> It will be nice to have pure-PQ options (that are FIPS / CNSA 2.0
> compatible) ready to go when users are ready to use them.
>
> Cheers,
> 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] draft-ietf-tls-cert-abridge Update

[Ackermann, Michael]

But I thought retired people were supposed to sleep in?

From: TLS  On Behalf Of Dennis Jackson
Sent: Wednesday, March 6, 2024 7:39 AM
To: tls@ietf.org
Subject: Re: [TLS] draft-ietf-tls-cert-abridge Update

[External email]

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

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