[TLS]Re: Working Group Last Call for "Hybrid key exchange in TLS 1.3"

[Thom Wiggers]

Hi,

I think this is great and what better time to do this than with the publication 
of FIPS 203 this week.

The one thing that remains is that there are many references to Kyber, e.g. 
commenting on its key sizes fitting in the KeyShareEntry limitations; should 
those be updated to be references to ML-KEM? 

Cheers,

Thom

> Op 12 aug 2024, om 21:50 heeft Deirdre Connolly  
> het volgende geschreven:
> 
> This email starts the working group last call for the Internet-Draft "Hybrid 
> key exchange in TLS 1.3", located here:
> 
> https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/
>  
> The WG last call will end 26th August 2024 @ 2359 UTC.
> 
> Please review the draft and submit issues and pull requests via the GitHub 
> repository that can be found at:
> 
> https://github.com/dstebila/draft-ietf-tls-hybrid-design
>  
> 
> You can also send comments and feedback to tls@ietf.org .
> 
> Cheers and thank you,
> Deirdre
> 
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org

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

[TLS] Bumped AuthKEM draft

[Thom Wiggers]

Hi all,

I have just pushed a minor update to the AuthKEM [1] and AuthKEM-PSK [2] 
drafts. I also have a new “reference” implementation of AuthKEM.

AuthKEM allows authentication via KEM public keys, which in particular might 
save a lot of handshake traffic if you can replace ML-DSA by ML-KEM. This 
approach is particularly interesting if we can mitigate the overhead of the 
other signatures of the handshake using e.g. Merkle Tree Certificates.

The reference implementation lives at [3]. I have only implemented AuthKEM 
server authentication right now; PSK and client auth will follow at some later 
point. The diff with the main branch of Rustls [4] might be particularly 
interesting if you want to see what the impact of an implementation of AuthKEM 
might be. Note that a large part of this diff is just instantiating Rustls' 
pluggable crypto provider API.

The updates to the drafts include some things that I found when implementing 
the specified scheme, and I pinned some code points for experimental use 
(though with a note that these are not stable).

As always, if you have questions or comments, you know where to find us.

Cheers,

Also on behalf of my co-authors,

Thom  

[1]: https://datatracker.ietf.org/doc/draft-celi-wiggers-tls-authkem/ 
[2]: https://datatracker.ietf.org/doc/draft-wiggers-tls-authkem-psk/ 
[3]: https://github.com/kemtls/rustls-authkem/
[4]: https://github.com/rustls/rustls/compare/rustls:793553e...kemtls:a9ca69b ___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Thom Wiggers]

Hi Hannes,

Skimming the document, I had the following questions:

- Can only clients request extended key updates (EKUs)? I think the text does 
not attempt to impose this as a restriction, but all the examples are 
client-initiating.
- If it is limited to client-initiated EKUs, the client shouldn't need to 
indicate it supports this extension? 
- Section 5 specifies that the N-1 keys SHOULD be deleted once computed, but in 
many other sections (e.g. the tail of section 4) keys are specified (MUST) to 
stay around for a bit longer. This seems contradictory, and I think it would be 
less confusing if handling of key material is more explicitly treated in the 
document.

Personally, I’m not super stoked about having extensions that bolt on a new 
state machine, but it seems unavoidable for your problem description (if we’re 
excluding application-layer fixes).

Your "alternative designs considered” section might have been more viable if 
this was built on top of draft-ietf-tls-semistatic-dh or AuthKEM, as we’d have 
long-term static key exchange keys (but it does have other complications, such 
not allowing server-initiated EKUs if there was no client auth). Otherwise I 
think that you’re right to not require servers to store their ephemeral keys 
for the session lifetime if the client sends an extension, while it may never 
even send the EKU request.

Cheers,

Thom


> Op 4 jan 2024, om 12:42 heeft Tschofenig, Hannes 
>  het volgende geschreven:
> 
> 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] What is the TLS WG plan for quantum-resistant algorithms?

[Thom Wiggers]

Hi,

I remembered that this discussion was somewhat summarised in 
https://datatracker.ietf.org/doc/html/draft-ietf-tls-hybrid-design-03#appendix-B,
 which might be helpful.

Cheers,

Thom


> Op 9 nov 2023, om 12:00 heeft Scott Fluhrer (sfluhrer) 
>  het volgende geschreven:
> 
> We had that argument several IETF’s ago (IETF 105?), and the clear consensus 
> of the working group was that explicit named hybrid combinations (e.g. one 
> for ML-KEM-512 + X25519) was the way to go.
>  
> Do we want to reopen that argument?  Now, I was on the other side (and I 
> still think it would be a better engineering decision, given the right 
> negotiation mechanism), but if it delays actual deployment, I would prefer if 
> we didn’t.
>  
> From: TLS  On Behalf Of John Mattsson
> Sent: Thursday, November 9, 2023 3:48 AM
> To: Sophie Schmieg ; tls@ietf.org
> Subject: Re: [TLS] What is the TLS WG plan for quantum-resistant algorithms?
>  
> Hi,
>  
> Everybody seem to agree that hybrids should be specified. Looking in my 
> crystal ball, I predict that registering hybrids as code points will be a big 
> mess with way too many opinions and registrations similar to the TLS 1.2 
> cipher suites. The more I think about it, the more I think TLS 1.3 should 
> standardize a generic solution for combining two or more key shares.
>  
> My understanding of what would be needed:
>  
> - New "split_key_PRF" extension indicating that client supports split-key PRF.
>  
> - When "split_key_PRF" is negotiated the server may chose more than one 
> group/key share.
>  
>   struct {
>   NamedGroup selected_groups<0..2^16-1>;
>   } KeyShareHelloRetryRequest;
>  
>  struct {
>   KeyShareEntry server_shares<0..2^16-1>;
>   } KeyShareServerHello;
>  
> - When "split_key_PRF" is negotiated HKDF-Expand(Secret, HkdfLabel, Length) 
> is replaced by a split-key PRF(Secret1, Secret2, ... , HkdfLabel, Length)
>  
> I think the current structure that the TLS server makes the decisions on 
> “groups” and “key shares” should be kept.
>  
> There was a short discussion earlier on the list
> https://mailarchive.ietf.org/arch/msg/tls/Z-s8A0gZsRudZ9hW4VoCsNI9YUU/
>  
>  
> Sophie Schmieg sschm...@google.com  wrote:
> ”Our stated intention is to move to Kyber once NIST releases the standard”
> “I do not think it makes a lot of sense to have multiple schemes based on 
> structured lattices in TLS, and Kyber is in my opinion the superior 
> algorithm.”
>  
> I agree with that. 
>  
> Cheers,
> John Preuß Mattsson
>  
>  
>  
> From: TLS mailto:tls-boun...@ietf.org>> on behalf of 
> Sophie Schmieg  >
> Date: Thursday, 9 November 2023 at 08:40
> To: tls@ietf.org  mailto:tls@ietf.org>>
> Subject: Re: [TLS] What is the TLS WG plan for quantum-resistant algorithms?
> 
> > > On 8 Nov 2023, at 8:34, Loganaden Velvindron  > > > wrote:
> > > 
> > > I support moving forward with hybrids as a proactively safe deployment
> > > option. I think that supporting
> > > only Kyber for KEX  is not enough. It would make sense to have more 
> > > options.
> > > 
> > > Google uses NTRU HRSS internally:
> > > https://cloud.google.com/blog/products/identity-security/why-google-now-uses-post-quantum-cryptography-for-internal-comms
> > >  
> > > 
> > > 
> > > If Google decides to use this externally, how easy would it be to get
> > > a codepoint for TLS ?
> > As easy as writing it up in a stable document (may or may not be an 
> > Internet-draft) and asking IANA for a code point assignment.
> > 
> > It can be done in days, if needed.
> > 
> >  Yoav
> 
> Just to clarify a few things about our internal usage of NTRU-HRSS: This is 
> for historic reasons.
> 
> Our stated intention is to move to Kyber once NIST releases the standard, see 
> e.g. my talk at PQCrypto [1], where I go into some detail on this topic.
> Long story short, we had to choose a candidate well before even NIST's round 
> 3 announcement, and haven't changed since changing a ciphersuite, while 
> relatively straightforward is not free, so we would like to avoid doing it 
> twice in a year.
> The only security consideration that went into the decision for NTRU was that 
> we wanted to use a structured lattice scheme, with NTRU being chosen for 
> non-security related criteria that have since materially changed.
> I do not think it makes a lot of sense to have multiple schemes based on 
> structured lattices in TLS, and Kyber is in my opinion the superior algorithm.
>  
> [1] https://www.youtube.com/watch?v=8PYYM3G7_GY
> 
> 
> --
> ___
> TLS mailing list
>

Re: [TLS] Updated AuthKEM drafts

[Thom Wiggers]

Hi Ilari,

Op di 7 nov 2023 om 08:34 schreef Ilari Liusvaara :

> On Tue, Nov 07, 2023 at 08:00:57AM +0100, Thom Wiggers wrote:
> > Hi Peter,
> >
> > The KEM used for authentication indeed needs to be IND-CCA secure,
> > but so does the KEM for ephemeral key exchange (IND-1CCA, at least).
> > The TLS key schedule should ensure that this all goes correctly, if
> > I recall the discussion on the concatenation of the secrets and
> > is-HKDF-a-dual-PRF discussion.
>
> I thought key exchange only needs absolute minimum to avoid trivial
> breakage (one-wayness)?
>

Surprisingly, it turns out that IND-CPA is not exactly sufficient. The TLS
1.3 proof by Dowling et al. [1] established that you need PRF-ODH for the
ephemeral key exchange. Very similarly, in TLS 1.3 and KEMTLS, in the
indistinguishability experiment we need to be able to answer a single
decapsulation oracle query to properly answer the adversary's queries: this
is due to the fact that the server immediately uses the encapsulated/DH
shared secret to encrypt handshake messages.

Hüguenin-Dumittan and Vaudenay later improved this analysis [2] and showed
that for TLS 1.3, the CDH assumption and some additional construction can
be used to avoid the PRF-ODH assumption.

However, l think this series of papers shows something else: IND-CPA has a
ton of footguns and you're better off just assuming you need IND-CCA
security for all your primitives.


> > But AuthKEM currently tries to build on HPKE, and I think the HPKE
> > draft intends to give IND-CCA security.
>
> >From reading HPKE RFC, it seems weird.
>
> I thought that HPKE intends to guarantee IND-CCA2, however, I can
> not find a requirement for KEM part to be IND-CCA2 secure (all the
> other parts yes). And if the KEM is not IND-CCA2, the whole HPKE
> will not be either.
>
>
We should currently be using full HPKE, we're just wrapping it in some KEM
operations. But this is something I haven't looked at too deeply either.

Cheers,

Thom


[1]: https://eprint.iacr.org/2015/914
[2]: https://eprint.iacr.org/2021/844



>
>
>
>
> -Ilari
>
> ___
> 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] How to issue certs for draft-celi-wiggers-tls-authkem ?

[Thom Wiggers]

Hi Mike,

Yeah, this point is one that I hadn’t thought to bring up in the presentation, 
but that I also think is one of the things that will require pushing from both 
sides; as long as KEMs in certs are a niche use case, then we don’t have a lot 
of motivation to really start having these discussions on the PKI side…

Cheers,

Thom

> Op 6 nov 2023, om 16:17 heeft Mike Ounsworth  het 
> volgende geschreven:
> 
> Hi Thom,
>  
> Your presentation today was good, but I just want to point out an elephant in 
> the room that’s missing from your slides: Public PKI is not currently 
> equipped to issue KEM certificates because every cert enrollment protocol 
> that I can think of uses CSRs at the bottom, and you can’t sign a CSR with a 
> KEM key. Back in 2021 I did some digging into which PKI enrollment protocols 
> have Proof-of-Possession (PoP) mechanisms for encryption keys, which I 
> presented at the Jan 2021 LAMPS Interim – see Slide 27 [1]; missing from that 
> slide is: “ACME: No”. If tls-authkem progresses, then we as a community need 
> to have a whole debate about how much we care about PoP for cert enrollment 
> and whether we’re ok for CAs to accept un-protected CSRs (just nothing in the 
> signature field), or whether we want to go down the rabbit hole of Zero 
> Knowledge Proof based CSR protection such as the one proposed in [2], or 
> re-design cert enrollment protocols to protect KEM CSRs in some other way 
> (like CSRs signed with the ACME account key).
>  
> I am not trying to slow down draft-tls-authkem because it’s good work, but 
> please don’t overlook that WebPKI is not currently equipped to issue KEM 
> certificates and there is a fairly large amount of pre-requisite work that 
> would need to happen before we can deploy tls-authkem at any kind of scale.
>  
> [1]: 
> https://datatracker.ietf.org/doc/slides-interim-2021-lamps-01-sessa-position-presentation-by-mike-ounsworth/
> [2]: https://dl.acm.org/doi/abs/10.1145/3548606.3560560
>  
> ---
> Mike Ounsworth
> Software Security Architect, Entrust
>  
> Any email and files/attachments transmitted with it are intended solely for 
> the use of the individual or entity to whom they are addressed. If this 
> message has been sent to you in error, you must not copy, distribute or 
> disclose of the information it contains. Please notify Entrust immediately 
> and delete the message from your system.

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

Re: [TLS] Updated AuthKEM drafts

[Thom Wiggers]

Hi Peter,

The KEM used for authentication indeed needs to be IND-CCA secure, but so does 
the KEM for ephemeral key exchange (IND-1CCA, at least). The TLS key schedule 
should ensure that this all goes correctly, if I recall the discussion on the 
concatenation of the secrets and is-HKDF-a-dual-PRF discussion.

But AuthKEM currently tries to build on HPKE, and I think the HPKE draft 
intends to give IND-CCA security.

Cheers,

Thom


> Op 6 nov 2023, om 20:51 heeft Peter C  
> het volgende geschreven:
> 
> Sorry, the hybrid TLS draft I referenced should have been 
> draft-tls-westerbaan-xyber768d00.  I do realise they are different drafts 
> with slightly different KEMs, I just can’t copy and paste properly!
>  
> Peter
>  
> From: TLS  On Behalf Of Peter C
> Sent: Monday, November 6, 2023 4:08 PM
> To: tls@ietf.org
> Subject: Re: [TLS] Updated AuthKEM drafts
>  
> Thom,
>  
> If I’m understanding things correctly, the proof of multi-stage security for 
> AuthKEM requires that the KEM used for authentication is IND-CCA2 secure.
>  
> Unfortunately, kem_x25519kyber768 from draft-westerbaan-cfrg-hpke-xyber768d00 
> is not IND-CCA2 secure.  It simply concatenates the shared secrets so is 
> straightforward to distinguish given a decapsulation oracle – modify the 
> first component ciphertext and check whether the second half of the 
> concatenated shared secret stays the same.  It’s possible that the TLS key 
> schedule means it might still be fine to use, maybe – this is the argument in 
> draft-westerbaan-cfrg-hpke-xyber768d00 for the ephemeral KEM – but I don’t 
> think this is covered by the existing KEMTLS security analysis and it’s not 
> clear to me what happens if one of the component algorithms is broken.
>  
> An alternative would be to use a hybrid KEM construction along the lines of 
> draft-ounsworth-cfrg-kem-combiners where you are guaranteed to get IND-CCA2 
> security.  I realise this moves away from directly reusing the ephemeral KEM 
> for authentication, but they have slightly different security requirements 
> and it’s somewhat analogous to using dhkem_x25519_sha256 for authentication 
> instead of x25519 by itself.
>  
> Best,
>  
> Peter
>  
> From: TLS  On Behalf Of Thom Wiggers
> Sent: Friday, August 18, 2023 10:41 AM
> To:  
> Subject: [TLS] Updated AuthKEM drafts
>  
> Hi all,
>  
> I have just updated the AuthKEM draft and published a new one. TL;DR:
>  
> AuthKEM is a proposal that replaces signature-based handshake authentication 
> in TLS by an additional KEM key exchange (putting KEM public keys in endpoint 
> certificates).
>  
> In this update we:
> * Split off the AuthKEM cached/pre-shared KEM public key PSK-style mechanism 
> into a separate draft
> * Added a new section that explains the sizes of different TLS and AuthKEM 
> handshakes
> * Also explain how AuthKEM makes it cheaper to use Falcon for offline 
> signatures
> * Expanded on related work and how this mechanism relates to compression 
> proposals
>  
> In our view, AuthKEM can be especially helpful for embedded and IoT devices, 
> as using KEMs instead of signatures can be much cheaper in terms of 
> bandwidth, computation, and (when mutually authenticating) code size. For 
> example, in [Samandari23], a KEM-authentication approach was investigated for 
> MQTT and resulted in much faster messaging. But also for the WebPKI, AuthKEM 
> can reduce handshake sizes further when combined with e.g. Merkle Tree Certs 
> or Abridged Certificate Compression.
>  
> The KEM-based PSK-style mechanism can in my mind be a robust contribution to 
> the discussion on the update for RFC7924 versus session tickets: storing KEM 
> public keys can be much easier than symmetric session tickets or other 
> symmetric secrets in terms of key management, but also in terms of not having 
> to protect the secrets.
>  
> The source repository for both drafts lives at 
> https://github.com/kemtls/draft-celi-wiggers-tls-authkem. I am already aware 
> that I forgot to update the abstract for authkem-psk, so that is one of the 
> new issues tracked there.
>  
> There are lots of things still open for discussion, and these are marked in 
> the draft. I am also sure the presentation or any details can be much 
> improved, and welcome any and all contributions to either.
>  
> Cheers,
>  
> Also on behalf of my co-authors,
>  
> Thom
> PQShield
>  
> [Samandari23] https://www.mdpi.com/2624-800X/3/3/21/html
> ___
> 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] What is the TLS WG plan for quantum-resistant algorithms?

[Thom Wiggers]

Hi,

> Op 6 nov 2023, om 14:24 heeft Tim Hollebeek 
>  het volgende geschreven:
> 
> I’m fine if the cocktail napkin says “we’ll either do A or B, we’re still 
> figuring that out”.

I’m not sure if we will be able to say this as strictly as “A xor B”, we might 
need to do A and B in different environments. CNSA 2.0’s requirement of level-V 
parameters results in very different behaviour than what we see at NIST level 
I, for example. The platforms on which we deploy things are also subject to 
wildly varying constraints.

Cheers,

Thom 


 
>  
> What I’m trying to avoid is the situation where everyone has a different 
> notional quantum-safe TLS design in their heads, but nobody realizes it 
> because nobody has bothered to try to write down the details, even at a very 
> high level.
>  
> If it changes in the future due to new events or analysis, that’s ok too.
>  
> -Tim
>  
> From: Bas Westerbaan  
> Sent: Monday, November 6, 2023 1:14 PM
> To: Tim Hollebeek 
> Cc: John Mattsson ; TLS@ietf.org
> Subject: Re: [TLS] What is the TLS WG plan for quantum-resistant algorithms?
>  
>  
> (3)-(5) are exactly the hard problems I’ve been thinking a lot about lately.  
> I’d actually be tempted to say that AuthKEM vs signatures is something we 
> should figure out ASAP.  I read AuthKEM again this morning, and it has a lot 
> of attractive features, but I’m not quite sure what the right answer is yet.
>  
> I don't think we can settle the future of PQ authentication in TLS just yet — 
> there are still many unknowns. To name a few:
>  
> 1. What signature schemes are on the horizon? MAYO [1] from the NIST 
> signatures on-ramp would be great, if it doesn't turn out to be broken.
>  
> 2. How will the confidence in existing schemes develop? AuthKEM will look 
> different depending on whether it can use Kyber-512 or Kyber-1024. Also, will 
> it replace Dilithium5 or Dilithium2?
>  
> 3. What other higher level changes is the ecosystem able to adopt? For 
> instance Merkle Tree Certs [2].
>  
> These are all hard questions, and although I do not believe we can answer 
> them now, we should be thinking about them right now. I think we should have 
> different pots on the fire, so to say.
>  
> Best,
>  
>  Bas
>  
> [1] https://pqmayo.org/params-times/
> [2] https://datatracker.ietf.org/doc/draft-davidben-tls-merkle-tree-certs/
>  
> ___
> 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] Updated AuthKEM drafts

[Thom Wiggers]

Hi all,

I have just updated the AuthKEM draft and published a new one. TL;DR:

AuthKEM is a proposal that replaces signature-based handshake
authentication in TLS by an additional KEM key exchange (putting KEM public
keys in endpoint certificates).

In this update we:
* Split off the AuthKEM cached/pre-shared KEM public key PSK-style
mechanism into a separate draft
* Added a new section that explains the sizes of different TLS and AuthKEM
handshakes
* Also explain how AuthKEM makes it cheaper to use Falcon for offline
signatures
* Expanded on related work and how this mechanism relates to compression
proposals

In our view, AuthKEM can be especially helpful for embedded and IoT
devices, as using KEMs instead of signatures can be much cheaper in terms
of bandwidth, computation, and (when mutually authenticating) code size.
For example, in [Samandari23], a KEM-authentication approach was
investigated for MQTT and resulted in much faster messaging. But also for
the WebPKI, AuthKEM can reduce handshake sizes further when combined with
e.g. Merkle Tree Certs or Abridged Certificate Compression.

The KEM-based PSK-style mechanism can in my mind be a robust contribution
to the discussion on the update for RFC7924 versus session tickets: storing
KEM public keys can be much easier than symmetric session tickets or other
symmetric secrets in terms of key management, but also in terms of not
having to protect the secrets.

The source repository for both drafts lives at
https://github.com/kemtls/draft-celi-wiggers-tls-authkem. I am already
aware that I forgot to update the abstract for authkem-psk, so that is one
of the new issues tracked there.

There are lots of things still open for discussion, and these are marked in
the draft. I am also sure the presentation or any details can be much
improved, and welcome any and all contributions to either.

Cheers,

Also on behalf of my co-authors,

Thom
PQShield

[Samandari23] https://www.mdpi.com/2624-800X/3/3/21/html
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Thom Wiggers]

Hi Simon,

Op za 12 aug 2023 om 16:00 schreef Simon Mangel :

> Note: We have already found an adaption for TLS 1.3 in academic work
> [Schwabe2021], where instead of caching the whole chain, each
> certificate is cached separately.
> This however leads to inconsistent signaling, as there is no
> differentiation between a choice of cached certificate chains and
> separately cached certificates of a single chain.
>
> As the author, I want to clarify that the variant that we made was
optimized for least-effort, and you are probably correct in that there are
better ways to do it.

Also, as the author of the AuthKEM proposal, the stored-public-key
mechanism of which also originates in [Schwabe2021], I should obviously
plug that draft here as well :-) (Expect an updated version soon*)*

Cheers,

Thom


[Schwabe2021] More Efficient Post-quantum KEMTLS with Pre-distributed
> Public Keys, https://doi.org/10.1007/978-3-030-88418-5_1
> https://thomwiggers.nl/publication/kemtlspdk/
>
> ___
> 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 draft-jackson-tls-cert-abridge

[Thom Wiggers]

I support adoption

Op di 1 aug 2023 om 21:36 schreef Christopher Wood :

> Hi all,
>
> Based on positive feedback received during IETF 117, this email begins an
> adoption call for "Abridged Compression for WebPKI Certificates"
> (draft-jackson-tls-cert-abridge).
>
> The datatracker page for this document can be found here:
> https://datatracker.ietf.org/doc/draft-jackson-tls-cert-abridge/
>
> And the GitHub repository can be found here:
> https://github.com/dennisjackson/draft-jackson-tls-cert-abridge
>
> Please indicate whether or not your support adoption of this document in
> its current state. Procedure questions raised during the WG meeting last
> week can be ironed out in the event of this item being adopted.
>
> This call for adoption will conclude on August 16.
>
> Thanks,
> Chris, for the chairs
> ___
> 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@ietf117: saag report

[Thom Wiggers]

Hi all,

Op do 27 jul 2023 om 21:31 schreef Sean Turner :

>
> * Update on post-quantum signatures (from NIST): NIST is running another
> round of their competition because there aren't any good, performant and
> small, signature algorithms yet.  Many of the algorithms have already
> fallen. We will see how the process ends.
>

Just to quickly clarify: the update was from Bas Westerbaan and myself on
the new signature schemes that are part of the NIST PQ standardization
effort; it was not a presentation from NIST.

Cheers,

Thom


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

[Thom Wiggers]

Hi Dennis,

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.

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. (You could
even say that we wrap the code points after N years).

Cheers,

Thom

Op vr 7 jul 2023 om 00:18 schreef 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
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] AuthKEM: Splitting the draft and next steps

[Thom Wiggers]

Hi Ilari,

Thanks for your message, I will definitely use this when looking at DTLS.

Op wo 5 jul 2023 om 14:22 schreef Ilari Liusvaara :

> On Wed, Jul 05, 2023 at 09:26:57AM +0200, Thom Wiggers wrote:
> > Hi Ilari,
> >
> > Thanks for pointing this out. I will admit I am pretty unaware of the
> > additional constraints that DTLS has, but I will try to look at this
> issue
> > in more detail. In the meantime, I would also appreciate it if people who
> > are also concerned about AuthKEM+DTLS share their interest and concerns,
> as
> > that will help with their visibility and maybe give me a list of people
> to
> > ask questions to :)
>
> Actually, the changes might not be quite so nasty:
>
> - The DTLS epoch numbering needs to be changed: If AuthKEM is used,
>   then epoch 3 needs to be autheticated_handshake epoch instead of
>   application_0 epoch, which is pushed to epoch 4 and then that pushes
>   other application epoch one number forward.
>
> - Fortunately even if there are 5 active epochs during handshake,
>   the 2 bits in DTLS header are still enough, because one of those is
>   plaintext, and can be recognized from record types used.
>
> - There actually might be chance to make the early auth work. However,
>   there are subtle details:
>
>   * The certificate being a message, it is subject to acknowledgements.
> However, server hello must be logically before it. This is required
> to meet the acknowledgment epoch rule.
>   * The server flight needs to be broken into two just before server
> Finished, first part being unordered with certificate, and second
> being the next flight. This is required to have the certificate
> available for computing finished, and to meet the implicit
> acknowledgment rule.
>

I'm very open to hacks, such as turning it into an ECH-style encrypted
extension. Whatever makes this easier.

I think the main open question, also for regular client-auth
pre-shared-kem-key AuthKEM is how do we treat this message in the
transcript if the server *can't* decrypt this message (and tries to fall
back to e.g. plain AuthKEM or TLS). But this is something that is in the
issue tracker and document already.


> Of course, even if the theroetical changes are not so nasty, those can
> still play absolute hell with implementations. And there could be some
> other gotcha I have not considered.
>

I will not pretend that this is not a tough change on the practical side,
especially in the PSK-KEM client-authenticated case. But for some use
cases, this may be worth it. If this mode is deemed "too complicated" and
we have no immediate strong proponents, we might postpone solving those
client-auth issues for another time. We have plenty of discussion time
ahead of us to determine that path :)


> And then it occured to me earlier today that web browsers might not like
> the abbreviated AuthKEM very much: They really do not like to use DNS
> for server authentication, instead preferring to use certificates sent
> in-band. Of course, adding certificate message would duplicate the key
> information, which is a footcannon.
>

The keys-in-DNS idea is definitely more of an extension that I do not want
to solve before settling on the main protocol. The main hard problem seems
to be authenticating this key in DNS, and we definitely do not want to push
all certificates there. (ChrisW told me that keys-in-DNS was also briefly
discussed and shot down for semi-static/OPTLS for similar reasons). I am
hoping we might have some synergies with the infra that supports ECH and
perhaps the proposed much-compressed merkle tree certificates though. Any
such deployments, which will need to periodically update the DNS records in
the case of MTCs, might be a bit more advanced but seem by no means
impossible.

Cheers and thanks again,

Thom
PQShield


>
>
>
> -Ilari
>
> ___
> 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] AuthKEM: Splitting the draft and next steps

[Thom Wiggers]

Hi Ilari,

Thanks for pointing this out. I will admit I am pretty unaware of the
additional constraints that DTLS has, but I will try to look at this issue
in more detail. In the meantime, I would also appreciate it if people who
are also concerned about AuthKEM+DTLS share their interest and concerns, as
that will help with their visibility and maybe give me a list of people to
ask questions to :)

You're welcome to contribute or +1 in the mailing list or, if you're
concerned about noise, thumbs-up on this issue
https://github.com/kemtls/draft-celi-wiggers-tls-authkem/issues/23

Cheers,

Thom
PQShield

Op di 4 jul 2023 om 20:27 schreef Ilari Liusvaara :

> On Tue, Jul 04, 2023 at 08:00:00AM +0200, Thom Wiggers wrote:
> >
> > It has been a while since I have had time to work on the IETF draft for
> > AuthKEM (``draft-celi-wiggers-tls-authkem``, aka "KEMTLS"), and some of
> you
> > have previously asked when the draft (which is currently expired) will be
> > updated. In this email, I want to pick up the work again.
> >
> > Specifically, I want to do the following:
> >
> > * Split the proposal in two parts for improved legibility and
> applicability
> > to use cases
> > * Once this is done and in a good shape, move forward towards consensus
> > with the aim of adoption
> >
> > I will now describe the plan in more detail. I am welcoming further
> > suggestions, and would like to hear if these changes make sense and are
> > appreciated. If nothing else, you're welcome to help bikeshed draft
> names.
> > :-)
> >
> > The draft currently describes TLS authentication via KEM ("KEMTLS
> > authentication") and TLS-PSK-style abbreviated handshakes via KEM
> > (KEMTLS-PDK). The TLS authentication and the abbreviated KEM-based
> > PSK-style handshake probably are independently interesting. The two
> > proposals can be split and this would hopefully make evaluating them
> > easier. AuthKEM and "pre-shared KEM" can be independently implemented.
>
> Reading the draft, it occurs to me that adapting it to work on DTLS (or
> unreliable CTLS) might require major and very challenging changes to
> DTLS 1.3. Especially with client authentication.
>
> And 0-RTT client auth probably can not work in DTLS at all, since DTLS
> has no reliability for 0-RTT, unlike other handshake, which is reliable.
>
>
>
>
> -Ilari
>
> ___
> 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] AuthKEM: Splitting the draft and next steps

[Thom Wiggers]

Hi all,

It has been a while since I have had time to work on the IETF draft for
AuthKEM (``draft-celi-wiggers-tls-authkem``, aka "KEMTLS"), and some of you
have previously asked when the draft (which is currently expired) will be
updated. In this email, I want to pick up the work again.

Specifically, I want to do the following:

* Split the proposal in two parts for improved legibility and applicability
to use cases
* Once this is done and in a good shape, move forward towards consensus
with the aim of adoption

I will now describe the plan in more detail. I am welcoming further
suggestions, and would like to hear if these changes make sense and are
appreciated. If nothing else, you're welcome to help bikeshed draft names.
:-)

The draft currently describes TLS authentication via KEM ("KEMTLS
authentication") and TLS-PSK-style abbreviated handshakes via KEM
(KEMTLS-PDK). The TLS authentication and the abbreviated KEM-based
PSK-style handshake probably are independently interesting. The two
proposals can be split and this would hopefully make evaluating them
easier. AuthKEM and "pre-shared KEM" can be independently implemented.

"Plain AuthKEM" is useful for mitigating the cost of post-quantum signature
schemes in "regular" TLS handshakes. Use of plain AuthKEM can be especially
attractive to devices that want to use mutually authenticated TLS, but
would like to re-use the (e.g. protected) implementation of the KEM
algorithm for ephemeral key exchange. Compared to Dilithium2, use of Kyber
also offers significant space savings.

"KEM-PSK" is interesting for embedded or IoT applications that currently
are using symmetric-key PSK with ephemeral key exchange. Using KEM-PSK
avoids symmetric-key key management issues, such as protected storage and
key distribution, while allowing PSK-style abbreviated TLS handshakes.
Meanwhile, no additional code is needed over the ephemeral key exchange
algorithms. (In the future, we could even investigate additional mechanisms
to distribute the server’s public key, such as putting it in HTTPS records
alongside ECH, to allow more clients to use the abbreviated handshake.)

I hope to get these changes done over the coming weeks, but I doubt it'll
be ready for IETF 117. But, as stated above, I do not want to drag this
forward in the unadopted state forever—it's been long enough already. So
once refactoring has happened, discussion has settled and consensus has
been reached, I intend to ask the chairs for a call for adoption.

Cheers, and thanks for your comments,

Also on behalf of my co-authors,

Thom
PQShield

PS: we moved the Git repository to
https://github.com/kemtls/draft-celi-wiggers-tls-authkem
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Pqc] Post-Quantum TLS instantiations and synthetic benchmarks

[Thom Wiggers]

Hi Panos,

You're of course right that the bane of too much javascript probably
affects the median website much more than "a few extra bytes" of key
exchange material. But I do think that measuring time-to-last-byte is also
tricky in other ways, for example, in the question of if/how to consider
server-side processing. Probably, different things are important depending
on the particular application. Probably, we should consider modeling and
measuring both things in future experiments.

As an aside, we also have experimental results (
https://eprint.iacr.org/2023/734) that show that (on Android) applications
sometimes do hundreds of super tiny TLS/HTTP requests, doing full
handshakes each time. Now, of course, those apps probably should all be
using resumption, QUIC, h/2, or h/3 but for whatever reason, they're not
doing that. But at least for those bursty handshakes the time-to-first-byte
of application data is pretty close to time-to-last-byte.

(should this thread on networking/measurement strategies be split off and
moved elsewhere? I guess it is still about post-quantum use in protocols
(PQUIP) in the motivation of the discussion at least...)

Cheers,

Thom

Op di 27 jun 2023 om 22:48 schreef Kampanakis, Panos :

> Imo, we have been measuring handshake time as an indication or
> performance, but time-to-last-byte or time-to-x%-byte should be used
> instead. There is nothing wrong with your study Thom. It is pretty detailed
> and useful. I just think that if these new algos get deployed, we would
> know if their impact would be noticeable by measuring different things that
> what we have been measuring so far. An 150KB (on average) web page over a
> lossy LTE connection will have pretty bad user experience regardless of
> adding 10-15KB of Dilithium certs or 1-2KB of Kyber keys/ciphertexts.
>
>
>
> *From:* Pqc  *On Behalf Of * Thom Wiggers
> *Sent:* Tuesday, June 27, 2023 4:04 PM
> *To:* Bas Westerbaan 
> *Cc:* Martin Thomson ; Sofía Celi ;
> tls@ietf.org; p...@ietf.org
> *Subject:* RE: [EXTERNAL][Pqc] [TLS] Post-Quantum TLS instantiations and
> synthetic benchmarks
>
>
>
> *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 Bas,
>
>
>
> Op di 27 jun 2023 om 14:44 schreef Bas Westerbaan :
>
> Thanks for preparing the excerpt; this will be helpful for many use cases.
> (For the WebPKI, as you already mention, we also need to consider SCTs and
> realistically crappy networks.)
>
>
>
>  "this is LTE in a city", and "this is what a poor-quality rural 3G link
> looks like". But alas, these don't seem to exist either.
>
>
>
> Unfortunately, it will not be as simple as plugging in a single packet
> loss number and then dropping that fraction of packets. Because TCP
> interpets packet loss as congestion, it grinds down to a halt much earlier
> than at a loss of 2%. Instead, lossy links such as WiFi and cellular have
> their own retransmission protocols hidden from TCP.
>
>
>
> Yeah, I'm all too familiar with wireless retransmission (a previous laptop
> had a bad wifi chip that would drop up to 1/3rd of the packets leading to
> massive latency spikes). Still, I hope that someone has a good idea on how
> to best represent these facets of real-world networking in some way that is
> useful for experiments :)
>
>
>
> Cheers,
>
>
>
> Thom
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Pqc] Post-Quantum TLS instantiations and synthetic benchmarks

[Thom Wiggers]

Hi Bas,

Op di 27 jun 2023 om 14:44 schreef Bas Westerbaan :

> Thanks for preparing the excerpt; this will be helpful for many use cases.
> (For the WebPKI, as you already mention, we also need to consider SCTs and
> realistically crappy networks.)
>
>  "this is LTE in a city", and "this is what a poor-quality rural 3G link
>> looks like". But alas, these don't seem to exist either.
>>
>
> Unfortunately, it will not be as simple as plugging in a single packet
> loss number and then dropping that fraction of packets. Because TCP
> interpets packet loss as congestion, it grinds down to a halt much earlier
> than at a loss of 2%. Instead, lossy links such as WiFi and cellular have
> their own retransmission protocols hidden from TCP.
>

Yeah, I'm all too familiar with wireless retransmission (a previous laptop
had a bad wifi chip that would drop up to 1/3rd of the packets leading to
massive latency spikes). Still, I hope that someone has a good idea on how
to best represent these facets of real-world networking in some way that is
useful for experiments :)

Cheers,

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

Re: [TLS] [Pqc] Post-Quantum TLS instantiations and synthetic benchmarks

[Thom Wiggers]

Hi Martin,

Op di 27 jun 2023 om 13:18 schreef Martin Thomson :

> Thanks!  These results are pretty much in line with expectations.
>

Indeed, I don't think there are any results that are surprising when you
know all of the details of the algorithms. But I do hope that this set of
experiments provides a quick point of reference to both those who are
familiar with those details and to those less familiar. :-)

It looks like you don't model packet loss and the effect of that. One
> concern I have is that increases in the number of packets will
> significantly increase exposure to loss. 1-(1-p)^n tends to increase quite
> a bit as n increases.  p of 0.02 is a lot more common than people like to
> think, for which a full 10 packet CWND would need retransmissions almost
> 19% of the time.
>

A long while ago (while writing the original KEMTLS paper) we tried to
model packet loss, but the main problem that we ran into is the fact that
it mainly just seemed to drive up the error bars in the handshakes. We also
had to stop somewhere with the measurements---but I will consider including
2% packet loss in a next benchmark run.[1]


> Also, RSA is probably OK here, even with the wildly asymmetric CPU costs,
> but the size comparisons would look better with P-256.  Your claim that
> KDDD is faster than errr (errr) might not look as favourable for 
> (though the client cost should increase, I'm not sure if  would be
> slower).
>

We again had to stop somewhere, obviously (my PhD thesis has become a *very*
chunky book).

Just for fun: looking at the raw numbers from my laptop, P256 and
Dilithium2 seem close:

openssl speed ecdsap256
  signverifysign/s verify/s
 256 bits ecdsa (nistp256)   0.s   0.0001s  50927.6  16308.6

versus

liboqs speed_sig
 Operation| Iterations | Total time (s) | Time
(us): mean | pop. stdev | CPU cycles: mean  | pop. stdev
 | --:| --:|
---:| --:| -:| --:
Dilithium2   |||
  ||   |
keypair  | 131926 |  3.000 |
   22.740 |  2.257 | 59330 |   5773
sign |  49496 |  3.000 |
   60.612 | 36.122 |158216 |  94312
verify   | 133519 |  3.000 |
   22.469 |  1.411 | 58624 |   3465

As the effect of the additional bandwidth used by KDDD doesn't really kick
in with how the experiments are set up (compared to
https://blog.cloudflare.com/sizing-up-post-quantum-signatures/ which sees a
gradual increase per kilobyte), I think that within the experiment
parameters, our claim seems not too unreasonable still. In a slightly more
real-world setting, ECDSA probably has us beat.

Of course, any computation time that is well under a millisecond is
basically academic (aka negligible) anyway; and this is the case for both
algorithms on my laptop (and the benchmark server) at least.

Cheers,

Thom
PQShield

[1] Off-topic semi-ranty bit: You are completely right that I have no idea
about the prevalence of packet loss. I still think that it is very
unfortunate that there seems to be no "standard" set of parameters for this
style of network benchmarks. I imagine it would be much more helpful to
compare results if people use the same set of experimental parameters, but
this does not seem to be the case unfortunately. I would also have
appreciated a set of "reference" parameters like "this is a data
center-tier connection", "this is a home fibre connection in a western
city", "this is LTE in a city", and "this is what a poor-quality rural 3G
link looks like". But alas, these don't seem to exist either. If someone
does have these numbers, I would very much appreciate it if they maybe put
them up as an RFC in some networking RG somewhere :)

On Tue, Jun 27, 2023, at 17:49, Thom Wiggers wrote:
> > Hi Martin,
> >
> > As Sofía correctly saw, this is just plain TLS with the
> > "straightforward" DH->KEM and Sig->PQ-Sig substitutions.
> >
> > I, of course, do have another 50 pages on how KEMTLS performs and
> > compare it to these results, but I will save those for another day ;-)
> >
> > Cheers,
> >
> > Thom
> > PQShield
> >
> > Op di 27 jun 2023 om 05:19 schreef Sofia Celi :
> >> Hi Martin,
> >>
> >> I’m not the author of the note but, as far as I understand, it is not
> at all about KEMTLS. The experiments use NIST submitted PQC KEM algorithms
> for the key exchange and NIST submitted Sig

Re: [TLS] [Pqc] Post-Quantum TLS instantiations and synthetic benchmarks

[Thom Wiggers]

Hi Martin,

As Sofía correctly saw, this is just plain TLS with the "straightforward"
DH->KEM and Sig->PQ-Sig substitutions.

I, of course, do have another 50 pages on how KEMTLS performs and compare
it to these results, but I will save those for another day ;-)

Cheers,

Thom
PQShield

Op di 27 jun 2023 om 05:19 schreef Sofia Celi :

> Hi Martin,
>
> I’m not the author of the note but, as far as I understand, it is not at
> all about KEMTLS. The experiments use NIST submitted PQC KEM algorithms for
> the key exchange and NIST submitted Signature algorithms for
> authentication. Not sure if I would call this a “simpler integration” (as
> digital signatures are as complex as KEMs) but, as far as I know, that is
> not KEMTLS ;)
>
> Thanks,
>
> Sent from the phone
>
>
> > On 27 Jun 2023, at 00:56, Martin Thomson  wrote:
> >
> > Hi Thom,
> >
> > I infer - though it is not explicit - that this experiment is based on
> the assumption that KEM-TLS is used, rather than a simpler integration.
> Can you comment on what you see as the relative impact of that difference?
> >
> >> On Mon, Jun 26, 2023, at 21:48, Thom Wiggers wrote:
> >> Hi TLS-wg and PQUIP-rg,
> >>
> >> Recently, I have computed the sizes and measured the performance of
> >> post-quantum TLS (both PQ key exchange and post-quantum
> >> authentication). In these experiments, I have examined combinations of
> >> Kyber, Dilithium, Falcon, SPHINCS+-(sf), HQC, and XMSS. The experiments
> >> include measuring their performance over two network settings, one
> >> high-bandwidth, low-latency and one low-bandwidth, high-latency
> >> connection.
> >>
> >> I have examined the instances at NIST PQC security levels I, III and V,
> >> and for both unilaterally authenticated and mutually authenticated TLS.
> >>
> >> The report on these experiments (which is basically an excerpt of my
> >> PhD thesis manuscript) can be found in the attached document. It's a
> >> fairly dense document, so refer to the reading suggestions to easily
> >> find what you are looking for.
> >>
> >> It can be found at
> https://wggrs.nl/post/tls-measurements/handout-tls.pdf.
> >>
> >> I hope this document can be useful to:
> >>
> >> * get a feeling for how we can combine (signature) algorithms to fit
> >> their differing roles in the handshake
> >> * to see how this affects the handshake sizes, and
> >> * have some indication of how the performance of these combinations of
> >> algorithms is in a TLS stack on a network.
> >> * Additionally, I believe my results are useful to compare the cost of
> >> different NIST security levels.
> >>
> >> The experiments do not include SCTs or OSCP staples, but I think that
> >> their effect can mostly be extrapolated from the reported results. Also
> >> note that I am simulating the network environment, so the effect of the
> >> initial congestion window is much less gradual than observed in
> >> practice.
> >>
> >> As I write in the document, I want to examine the NIST on-ramp
> >> candidates' suitability for use in TLS as soon as the list of
> >> algorithms is formally out; for my PhD thesis they unfortunately came
> >> into the picture too late.
> >>
> >> Cheers,
> >>
> >> Thom Wiggers
> >> PQShield
> >>
> >> ___
> >> 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] Post-Quantum TLS instantiations and synthetic benchmarks

[Thom Wiggers]

Hi TLS-wg and PQUIP-rg,

Recently, I have computed the sizes and measured the performance of
post-quantum TLS (both PQ key exchange and post-quantum authentication). In
these experiments, I have examined combinations of Kyber, Dilithium,
Falcon, SPHINCS+-(sf), HQC, and XMSS. The experiments include measuring
their performance over two network settings, one high-bandwidth,
low-latency and one low-bandwidth, high-latency connection.

I have examined the instances at NIST PQC security levels I, III and V, and
for both unilaterally authenticated and mutually authenticated TLS.

The report on these experiments (which is basically an excerpt of my PhD
thesis manuscript) can be found in the attached document. It's a fairly
dense document, so refer to the reading suggestions to easily find what you
are looking for.

It can be found at https://wggrs.nl/post/tls-measurements/handout-tls.pdf.

I hope this document can be useful to:

* get a feeling for how we can combine (signature) algorithms to fit their
differing roles in the handshake
* to see how this affects the handshake sizes, and
* have some indication of how the performance of these combinations of
algorithms is in a TLS stack on a network.
* Additionally, I believe my results are useful to compare the cost of
different NIST security levels.

The experiments do not include SCTs or OSCP staples, but I think that their
effect can mostly be extrapolated from the reported results. Also note that
I am simulating the network environment, so the effect of the initial
congestion window is much less gradual than observed in practice.

As I write in the document, I want to examine the NIST on-ramp candidates'
suitability for use in TLS as soon as the list of algorithms is formally
out; for my PhD thesis they unfortunately came into the picture too late.

Cheers,

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

Re: [TLS] CRYSTALS Kyber and TLS

[Thom Wiggers]

Hi,
Op ma 19 jun 2023 om 17:41 schreef Bas Westerbaan :

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

Thanks Bas for the clarification, I was indeed only referring to the
ephemeral key exchange. I will add that sooner rather than later I will be
sending an email to the list suggesting some big editorial changes that
hopefully will make it easier to figure out what exactly AuthKEM has to
offer, and ask for some preliminary support; I also see pushing towards a
call for adoption in the future :)

Cheers,

Thom
PQShield


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

Re: [TLS] CRYSTALS Kyber and TLS

[Thom Wiggers]

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 values selected
> > by the server. (reference: algorithms 8, 9 of the round 3 Kyber
> submission)
>
> My concern is that the security strength cannot depend on the pk, because
> the
> PK is sent in clear over the wire. Thus it cannot contain entropy. Thus,
> entropy only comes from the message m in your listing which is a random
> number
> that is generated by the server. Further, c depends on m and thus does not
> add
> any entropy either.
>
> Ciao
> Stephan
>
>
> ___
> 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] Resurrect AuthKEM?

[Thom Wiggers]

Hi Uri,

I'm afraid that like you I am not going to Yokohama, as I am attending RWC
and HACS in Tokyo that week instead. While the AuthKEM draft has been
sitting idle, I have been very busy, pretty much writing the book on it —
my PhD thesis. I am sitting on a large pile of tables and benchmark results
that show the impact of putting Kyber, Dilithium and Falcon at all NIST
security levels into TLS (and KEMTLS/AuthKEM). Once I manage to get
everything written up and submitted to the reading committee, I will see if
I can extract some numbers for the TLS working group that are hopefully
interesting, also independent of AuthKEM. Hopefully I have time to do so
next month.

Otherwise, I think what I wrote in January [thread] still applies:

> To me, right now, most of the "homework" behind the AuthKEM/KEMTLS
proposal feels pretty "finished"; I'd argue we have some form of running
code (as in the various KEMTLS experimental implementations we did for the
academic work are pretty close to AuthKEM). We also have proofs, both
pen-and-paper and two Tamarin models. If anyone has suggestions for
concrete next steps, perhaps in which AuthKEM solves a problem that they're
seeing, let us know.
>
> But in the end, AuthKEM, as any IETF WG proposal, can't get pushed over
the line by some ivory tower academic like myself --- we will need people
coming out and saying they want to have this.

Your email clearly indicates that you are in favor of AuthKEM. If others
want to voice their support and/or have suggestions for the draft, a plan
of attack, whatever; feel free to also let me know: maybe for IETF 117 can
we dust off the draft, relate it to the NIST selections for signature
schemes, and also see if the idea has support for adoption.

Cheers,

Thom

PS. As mentioned, I will be in Tokyo for RWC and HACS, so I hope to be able
to meet some of the TLS folks face-to-face again there :-)

[thread]:
https://mailarchive.ietf.org/arch/msg/pqc/AsLh6qEtJfn1EE1TTtSEXoZwZAE/

Op di 21 mrt 2023 om 21:55 schreef Blumenthal, Uri - 0553 - MITLL <
u...@ll.mit.edu>:

> Richard, yes, you git it right.
>
>
>
> *From: *Richard Barnes 
> *Date: *Tuesday, March 21, 2023 at 4:32 PM
> *To: *Blumenthal, Uri - 0553 - MITLL 
> *Cc: *tls@ietf.org 
> *Subject: *Re: [TLS] Resurrect AuthKEM?
>
> Hi Uri,
>
>
>
> Just to be clear, the AuthKEM draft you mean is this one?
>
>
>
> https://datatracker.ietf.org/doc/draft-celi-wiggers-tls-authkem/
>
>
>
> Assuming that's the case, in case anyone else is confused (as I was), the
> "AuthKEM" here does not refer to a KEM implementing the AuthEncap/AuthDecap
> interface from RFC 9180.  Instead it refers to the construction in that
> document, which uses a normal KEM.
>
>
>
> --Richard
>
>
>
>
>
> On Tue, Mar 21, 2023 at 2:34 PM Blumenthal, Uri - 0553 - MITLL <
> u...@ll.mit.edu> wrote:
>
> I’m surprised to see that there isn’t much (isn’t any?) discussion of the
> AuthKEM draft.
>
>
>
> It seems pretty obvious that with the advent of PQ algorithms, the sheer
> sizes of signatures and public keys would make {cDm}TLS existing
> authentication and key exchange impractical in bandwidth-constrained
> environments, especially when higher security-level algorithms (like,
> what’s demanded by CNSA-2.0) are required.
>
>
>
> Thus, implicit authentication (think – MQV, Hugo Krawczyk’s HMQV, etc.)
> seems to be a-must for making the PQ impact on bandwidth somewhat
> manageable.
>
>
>
> I would like this WG to resurrect the AuthKEM draft.
>
>
>
> I can’t be in Yokohama, and am not fanatical enough to spend nights on
> XMPP or such. But hopefully, we can discuss AuthKEM approach here on the
> list.
>
>
>
> Thank you!
>
> --
>
> V/R,
>
> Uri Blumenthal  Voice: (781) 981-1638
>
> Secure Resilient Systems and Technologies   Cell:  (339) 223-5363
>
> MIT Lincoln Laboratory
>
> 244 Wood Street, Lexington, MA  02420-9108
>
>
>
> Web: https://www.ll.mit.edu/biographies/uri-blumenthal
>
> Root CA: https://www.ll.mit.edu/llrca2.pem
>
>
>
> *There are two ways to design a system. One is to make it so simple there
> are obviously no deficiencies.*
>
> *The other is to make it so complex there are no obvious deficiencies.*
>
> *
>   
>  -
> C. A. R. Hoare*
>
>
>
> ___
> 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] [Pqc] Did TLS AuthKEM die?

[Thom Wiggers]

Hi all,

I'll first ask the first question, and then try to clarify a few of the
other things raised in this thread.

> Is AuthKEM dead?

I'd say it's hibernating. The draft has indeed expired: there was nothing
significant to add since the last time we edited/updated it. I also
couldn't make it to the last two IETF meetings (and due to conflict with
Real World Crypto, I will most likely not be able to make IETF116 either).
The TLS working group has seemed to want to focus on getting PQ key
exchange out of the door, but if it's ready to continue the discussion on
post-quantum authentication (which should include some other things like
OCSP and CT), I'd be very happy to continue the discussion and work on
AuthKEM.

One change that we'd probably like to make soon is to include Kyber-based
(hybrid / PQ/T) KEMs -- once those KEMs have been hammered out for the
ephemeral key exchange.

I am currently working hard on wrapping up my PhD thesis* (which is largely
on post-quantum TLS and KEMTLS in particular). This is another reason why
the draft has been sitting there for a while. To me, right now, most of the
"homework" behind the AuthKEM/KEMTLS proposal feels pretty "finished"; I'd
argue we have some form of running code (as in the various KEMTLS
experimental implementations we did for the academic work are pretty close
to AuthKEM). We also have proofs, both pen-and-paper and two Tamarin
models. If anyone has suggestions for concrete next steps, perhaps in which
AuthKEM solves a problem that they're seeing, let us know.

But in the end, AuthKEM, as any IETF WG proposal, can't get pushed over the
line by some ivory tower academic like myself --- we will need people
coming out and saying they want to have this.

By the way, if anyone wants to discuss KEM-based authentication for other
protocol(s) by the way, I am always happy to talk, for example in the new
PQUIP wg that's also addressed :-)

Next, replying to John's comments:

Op di 24 jan. 2023 om 19:32 schreef John Mattsson :

> Using ephemeral-static ECDH for implit authentication as in the Noise
> protocol has several benefits. The benefits of using KEMs instead of
> signatures seem more limited. The current proposal requires 3 full
> round-trips instead of 1.5 round-trips for mutual authentication. If I
> understand correctly, the messages sizes are smaller than Kyber+Dilithium
> but similar to Kyber+Falcon (probably a bit larger in total).
>

Indeed, our mutual authentication story with plain AuthKEM is pretty weak;
but to be fair, it appears mutual authentication is extremely rarely used
in web browsing [0]. Naturally, that doesn't say anything about mTLS
deployments in e.g. service-to-service or IoT contexts. The
'pre-distributed key' version of AuthKEM (which relies on much-easier to
manage public keys) may be a remedy in some of those deployments, or be
used with caching, to at least avoid the full handshake penalty most of the
time.



> If continued, I think Kyber KEMs makes a lot more sense than ECDH KEM.
> For ECDH KEM you can do something much more efficient.
>

Naturally, OPTLS/draft-semistatic are indeed more elegant given DH/NIKE.
I'd argue that we're looking at a KEM-based future, though: AFAIK we
currently still don't have any satisfactory answers to the PQ NIKE
question: CSIDH's security is still a big, on-going discussion, CSIDH is
also awfully slow, and SIDH-based solutions (not to be confused with CSIDH)
seem dead in the water. If any new proposals pop up, they will probably not
have seen much cryptanalysis yet.

- “these proposals require a non-interactive key exchange”
>
> My understandaing of NIKE is that the parties do not have any interaction.
> One example of NIKE is static-static DH. OPTLS uses ephemeral-static DH.
> I don't think it is correct to describe that as NIKE.
>
> https://eprint.iacr.org/2012/732.pdf
>

Ephemeral-static DH key exchange is also exactly what I would describe as
NIKE: you just get a unilaterally authenticated secret instead of a
mutually authenticated secret. Following the terminology in the linked
paper (slightly simplified), you need exactly the SharedSecret operation:

server_authenticated_ss = SharedKey(servers_sk_static,
client_pk_ephemeral).

The "lack of interaction" lies in the fact that the computation of the
shared secret has only this single operation and that it requires no more
communication than the exchange of public keys, unlike KEMs which have
Encaps and Decaps and require the exchange of a ciphertext: indeed, there
is no way of doing static-ephemeral with a KEM-style API.

 - The document could mentioned that to derive the
> application_traffic_secret, an attacker needs more than a single private
> key. Having a single ephemeral private key is no longer enough as it is
> the case in ordinary certificate based TLS 1.3.
>

Thanks! We must have missed pointing that out. I put it on the list for a
next revision:
https://github.com/claucece/draft-celi-wiggers-tls-authkem/issues/22

Cheers,

Thom

Re: [TLS] [lamps] Q: Creating CSR for encryption-only cert?

[Thom Wiggers]

Hi Tomas, all,

Good discussion today, I'm learning some new things :D

Op do 6 okt. 2022 om 13:37 schreef Tomas Gustavsson <
tomas.gustavs...@keyfactor.com>:

> For CT logs as in 'CT used for public web sites' there is no possibility
> to delay submitting.
>

Ah, of course it does. I must've been low on coffee when I forgot that the
SCT is obviously computed through submission to a log, rather than over a
promise to submit.

I suppose that pretty much rules out the "implicit"
challenge-is-encrypted-cert method described in CMRF/CMP for web
certificates then. Otherwise one might spam CT logs?

Cheers and thanks,

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

Re: [TLS] [lamps] Q: Creating CSR for encryption-only cert?

[Thom Wiggers]

Hi David,

Thanks for your email; you sent it right on time as I'd just started
composing a similar email based on my reading of section 4.2 of RFC4211.

Op do 6 okt. 2022 om 09:58 schreef Thom Wiggers :

>
> We weren't aware of CRMF, so it seems I've got some reading to do as I
> write some paragraphs on KEM certificates in my PhD thesis :)
>
>
Digging into RFC4211 and as David just wrote, my interpretation of the
"indirect method" specified there mostly lines up with the "encrypt
certificate" approach I described in my previous email. CRMF, as an
interactive protocol, does require that you prove to the issuer that you
decrypted correctly, as David wrote, so I suppose that this makes it
important that the protocol that implements CRMF delays submitting to the
CT logs until after they've received confirmation, to avoid the "attack"
that I described.

Of course, that still means that the "encrypt certificate" message does not
work for the kinds of "non-interactive" issuance that CSRs allow.

I'll continue my reading with your pointers, thanks :)

Cheers,

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

Re: [TLS] Q: Creating CSR for encryption-only cert?

[Thom Wiggers]

Hi Uri, all,

Op di 4 okt. 2022 om 17:07 schreef Blumenthal, Uri - 0553 - MITLL <
u...@ll.mit.edu>:

> CSR is supposed to be signed by the corresponding private key to prove
> possession. Obviously, it cannot be done with a key such as described
> above. How is this problem addressed in the real world?  With AuthKEM and
> KEMTLS, how would these protocols get their certificates?
>

Yeah, that's something that came up a few times while we were working on
KEMTLS (and it eventually resulted in this paper by Güneysu, Hodges, Land,
Ounsworth, Stebila, and Zaverucha [1]). They also have some nice references
for the kinds of attacks that "sloppy" issuance could lead to in Appendix
A. I've not tried to work out if they apply to TLS/KEMTLS/AuthKEM, but
ruling them out anyway because of the many applications of certificates
seems worth it.

A different naive approach for issuance (that I have done zero security
analysis on) could be simply creating the cert for key PK and encrypting it
to a key encapsulated to PK. Then the owner of PK would need to decrypt the
certificate; using it the first time immediately proves possession. Of
course, in the real-world we also have things like CT logs and such; and it
would be terribly annoying if I could spam you with CT log alerts for
yourwebsite dot com. So this approach doesn't seem very favorable over a
"fancy" ZKP or interactive approach.

We weren't aware of CRMF, so it seems I've got some reading to do as I
write some paragraphs on KEM certificates in my PhD thesis :)

Cheers,

Thom


[1]: https://www.douglas.stebila.ca/research/papers/CCS-GHLOSZ22/
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Before we PQC... Re: PQC key exchange sizes

[Thom Wiggers]

Hi,

Op di 9 aug. 2022 om 22:58 schreef Robert Relyea :

> Multivarient equations sounded good at the beginning, but all forms and
> uses of multivarient have been broken.
>

Unbalanced Oil-and-Vinegar (UOV) is still standing and has been for a very
long time; and it will be submitted to NIST's 4th round on-ramp for
signatures. It's been around for a decent amount of time; the problem is
that it's quite chunky (e.g. 400kb public keys without expensive
compression). That's why all of these variants, like Rainbow, existed.

Cheers,

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

[TLS] PQC key exchange sizes

[Thom Wiggers]

Hi all,

In yesterday’s working group meeting we had a bit of a discussion of the
impact of the sizes of post-quantum key exchange on TLS and related
protocols like QUIC. As we neglected to put Kyber’s key sizes in our slide
deck (unlike the signature schemes), I thought it would be a good idea to
get the actual numbers of Kyber onto the mailing list.

Note that in the context of TLS’s key exchange, the public key would be
what goes into the ClientHello key_shares extension, and the ciphertext
would go into the Server’s ServerHello key_shares extension.

Kyber512: NIST level I, "strength ~AES128"
  public key: 800 bytes
  ciphertext: 768 bytes
  secret key: 1632 bytes
Kyber768: NIST level III, "~AES192"
  public key: 1184
  ciphertext: 1088
  secret key: 2400 bytes
Kyber1024: NIST level V, "~AES256"
  public key: 1568
  ciphertext: 1568
  secret key: 3168

So for the key exchange at least, it seems to me Kyber512 should work for
TLS and QUIC just fine; Kyber768 might be a bit of a squeeze if you want to
stay in QUIC’s default 1300 byte initial packet? Also, I don't really know
how the D of DTLS might change the story.

All the numbers we reported are as of the latest version of the individual
submissions (except as discussed below). The standards that NIST eventually
names FIPS-xyz might have (mildly) different sizes. NIST has said that
they’re always happy to receive feedback and information about use cases
and constraints.

Lastly, Bas Westerbaan has talked about a Kyber draft in yesterday’s CFRG
meeting. I believe a stated goal is to use that for coordinating any
experiments before the NIST standard is out. So keep an eye out if that
interests you.

Cheers,

Thom

PS: Let me also correct the mistake I had introduced in the SPHINCS+
numbers in the TLS talk: SPHINCS+ has indeed gotten slightly smaller than
the numbers I reported. The smallest SPHINCS+ variant (sphincs+-128s) has a
signature size of 7,856 bytes. There’s a nice table with the different
parameter sets of SPHINCS+ on their Github repository
https://github.com/sphincs/sphincsplus#parameters. I’m glad that people
were paying attention, apparently more than I was :-)

I will also clarify that when we mentioned that Falcon needs very careful
attention when implementing, this concerns Falcon's signing routines. These
require constant-time double-width floating point maths; on many CPUs this
will need to be emulated in software. Verification, on the other hand, is a
lot less sensitive.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Revised hybrid key exchange draft

[Thom Wiggers]

Hi all,

I think this work is an interesting examination of the assumptions, and as
a new key schedule it might be worth considering for future version numbers
of TLS and other protocols that rely on dual-PRF. Computationally, a few
extra hashes won't hurt anyone.

However, I don't agree with the suggestion that this would be something
that would be easy to "just do" when negotiating Hybrid KEMs. As I
understand the proposal, it is a complete redesign of the key schedule,
which has significant pains when implementing this. The "beauty" of the
draft-Stebila proposal is the fact that all its complexity is hidden behind
the API of the key exchange algorithm. From the point of view of the TLS
state machine, it's just another code point, and nothing needs to be
changed if you just have "keygen", "generate hello keyshare" (aka encaps)
and "derive shared secret" (aka decapsulate) operations in your ClientHello
and ServerHello messages. To use the KeyCombine() function in hybrid-KEX
TLS 1.3 handshakes and "old-fashioned" HKDF.Extract in ECDH-KEX TLS 1.3
handshakes means having to keep track of which type of key derivation is
being used throughout the handshake state machine, which is a significant
deviation from the current "just input the secret and advance the ratchet"
construction. This is especially true for more highly "integrated"
implementations (ie. the code mixes the protocol message handling and key
derivation steps [1]).

Cheers,

Thom

[1]: It's not necessarily the "usual suspects" that do this: see for
example the (imo) high-quality Go TLS implementation:
https://github.com/golang/go/blob/master/src/crypto/tls/handshake_server_tls13.go#L657-L658


Op zo 23 jan. 2022 om 18:21 schreef Russ Housley :

> I think that Martin is asking what properties this provides that justify
> the additional complexity.  I'm sure that a few test vectors are sufficient
> to get interoperability, but what properties of the construction justify
> the effort to do something different?
>
> Russ
>
>
> On Jan 22, 2022, at 6:35 AM, Nimrod Aviram 
> wrote:
>
> > I might have preferred a more efficient option though.
> By efficient, are you referring to the computation cost, or the
> implementation complexity?
> As to the former, the new construction requires ~7 microseconds, whereas
> HKDF.extract requires ~1.
> As to the implementation complexity, if that's your main concern, could
> you please elaborate about your concern?
> FWIW, our Python reference implementation
> 
> is quite short. We also provide a C implementation that wasn't hard to
> write (for me). And I can't imagine this causing interop problems.
>
> > The nice thing about the hybrid draft is that it isn't a firm commitment
> to any particular combination method.
> > It only suggests a method.
> That's not my understanding. My reading is that the draft prescribes a
> combination method, and if adopted and standardized, it would be
> concatenation, for all group combinations.
> Do you envision a scenario where a different combination method is
> standardized? If so, could you please elaborate how this would come to pass
> - perhaps as a revision of the eventual hybrid standard?
> Douglas, could you please chime in regarding this issue? If standardized,
> do you envision changing/adding combination methods?
>
> thanks,
> Nimrod
>
>
>
> On Fri, 21 Jan 2022 at 02:03, Martin Thomson  wrote:
>
>> I am not convinced that the extra effort is justified.
>>
>> However, I am convinced that the proposed construction is complex.
>>
>> combined_key = H(HMAC(key=H1(k1), data=2||F(k2)) xor HMAC(key=H2(k2),
>> data=1||F(k1)))
>> H1(k) = H('derive1' || k)
>> H2(k) = H('derive2' || k)
>> F(m) =
>> H(0||m1)||H(1||m1)||...||H(j-1||m1)||H(0||m2)||H(1||m2)||...||H(j-1||m2)||H(0||mn)||H(1||mn)||...||H(j-1||mn)
>> for m = m1||m2||...||mn and j =~ 3
>>
>> It's nice that this is a dual PRF; that's something I think we've wanted
>> for a number of other reasons in TLS.  I might have preferred a more
>> efficient option though.
>>
>> Comparing that to k1 || k2 means - for me - this needs much stronger
>> justification.
>>
>> Perhaps if the CFRG were to standardize a dual (or multi) PRF that were
>> more efficient I would be more favourably inclined toward its inclusion -
>> in a revision of the core specification.
>>
>> The nice thing about the hybrid draft is that it isn't a firm commitment
>> to any particular combination method.  Each new key exchange "group" can
>> define its own combination method.  It only suggests a method.  So I don't
>> agree that "[m]issing this opportunity would effectively further embed the
>> problem" (or maybe "effectively" is doing a little too much work there).
>>
>> On Wed, Jan 19, 2022, at 22:21, Nimrod Aviram wrote:
>> > Hi Everyone,
>> >
>> >
>> > As Douglas wrote, we have discussed the issues together at length, and
>> > we thank him for the productive (and 

Re: [TLS] Comments on draft-celi-wiggers-tls-authkem-00.txt

[Thom Wiggers]

Dear list,

This email is in regards to draft-celi-wiggers-tls-authkem.

We’ve only made some minor fixes to the authentication-via-KEM proposal
that we submitted and presented at the last IETF meeting (IETF111) at the
working group. We did receive a few questions and comments on the draft
during that presentation and prior to it that we would like to address. We
had the impression that those questions were mainly focused on the
motivation: the reason for the draft's existence.

Because we found there is not really a lot of space for the motivation of
certain choices in the text of the draft itself, we instead wrote a
document that we call “AuthKEM abridged”. In it, we try to clearly point
out our motivations, design choices and provide an intuition of the
security model. You can find it at
https://claucece.github.io/draft-celi-wiggers-tls-authkem/docs/authkem-abridged.html.
We hope that you will find it useful and if there is anything we should add
or explain better, please let us know. We touch over questions such as:


   -

   Why consider KEMs for authentication?
   -

   Why now if post-quantum KEMs or post-quantum signatures aren’t
   standardized yet?
   -

   Discussion about the extra half-round trip that is added


Meanwhile, we’ve been putting some cycles towards the formal analysis of
the KEMTLS protocol (which should extend to the AuthKEM one) in Tamarin,
building on the existing TLS 1.3 model. There’s still a lot to be done, but
we hope to be able to back this draft proposal with some machine-checked
analysis in the future.

Noting here as there seemed to be some confusion around it: KEMs are not
compatible with non-interactive key exchange schemes such as
draft-ietf-tls-semistatic-dh. At the moment, CSIDH is the only post-quantum
scheme compatible with semistatic-DH-like protocols. CSIDH is probably not
practical for use in TLS due to it being very slow, and its security level
is still the subject of intense debate.

Cheers and have a nice IETF 112,

Thom Wiggers and Sofía Celi
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Drafts for batch signing and PKCS#1 v1.5

[Thom Wiggers]

Hi David,

I've found some small textual issues (I'm looking at the PDF version):

In section 3.1 in step 1 (on PDF page 4):

"element 2*i+1 to a random byte of string of Hash.length bytes."

This sentence is slightly puzzling. A random bytestring?

Section 4.2, first paragraph, last sentence:

"so batch signing inherits preserves separation"

This sentence contains two verbs.

It looks like an interesting proposition, which could also be interesting
in the context of some of the post-quantum signing algorithms.

Cheers,

Thom

Op di 30 jul. 2019 om 02:16 schreef David Benjamin :

> Hi all,
>
> I’ve just uploaded a pair of drafts relating to signatures in TLS 1.3.
> https://tools.ietf.org/html/draft-davidben-tls13-pkcs1-00
> https://tools.ietf.org/html/draft-davidben-tls-batch-signing-00
>
> The first introduces optional legacy codepoints for PKCS#1 v1.5 signatures
> with client certificates. This is unfortunate, but I think we should do it.
> On the Chrome side, we’ve encountered some headaches with the TLS 1.3 PSS
> requirement which are unique to client certificates. The document describes
> the motivations in detail.
>
> The second describes a batch signing mechanism for TLS using Merkle trees..
> It allows TLS clients and servers to better handle signing load. I think it
> could be beneficial for a number of DoS and remote key scenarios.
>
> Thoughts?
>
> David
> ___
> 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