D. J. Bernstein wrote:
>as far as I know there was only one other cryptographer on record
>recommending against using SIKE.
I am on record multiple times recommending against using _any_ non-standard or
paywalled algorithms. That includes Kyber, Dilithium, FrodoKEM, Falcon,
Sphinx+, Classic McEl
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-qu
Hi Bas,
Thanks for adding some structure.
1. Do we want rfc describing the final NIST standards? And for which? I'm
ok with that — in this order of priority: ml-kem, ml-dsa, slh-dsa.
I would definitely want standard track RFCs for ML-KEM and ML-DSA. I think
other standards using TLS (IETF and
A few concerns I have with this extension:
1. Privacy: clients broadcasting intent to identify themselves to anyone who
asks. I know, this is intended for crawler bots, but the TLS stack does not
know whether our caller is a bot, so we will have to implement API support,
which will be used b
Yoav Nir writes:
> To justify a hybrid key exchange you need people who are both worried
> about quantum computers and worried about cryptanalysis or the new
> algorithms, but are willing to bet that those things wonât happen at
> the same time. Or at least, within the time where the generated ke
On Tue, Nov 7, 2023 at 2:09 PM David Benjamin wrote:
> It's a mess. Client certificates are the bane of my existence. :-)
>
It is really confusing, even for someone that knows more than most about
this stuff.
The parts that overlap for me are hardware keys (like a Yubikey or Google
Advanced Pr
I realized I used the word "context" in two different, uh, contexts, so
that was probably very confusing.
What I meant to say is that TLS client certificate decisions need to be
remembered session-wide, for some appropriate notion of session. So
browsing profile or something of that nature. But wi
On Tue, Nov 7, 2023 at 3:43 PM Ilari Liusvaara
wrote:
> On Mon, Oct 23, 2023 at 01:37:55PM -0400, Viktor Dukhovni wrote:
> >
> > - Some Java TLS libraries (used to?) fail the handshake when the
> > client has no configured certs, or the list of issuer CA DN hints
> > does include
Is it sizable? I have talked to enough people who feel the need to say “yes”.
The other thing to consider is the cost. If it is essentially free, I believe
we can make a reasonable case to add it, even if the benefit is only moderate.
If it is costly, then we really need to consider if it is
I wish we didn't need this draft, but I support adoption and can review it.
On Mon, Nov 6, 2023 at 9:25 AM Joseph Salowey wrote:
>
> At the TLS meeting at IETF 118 there was significant support for the draft
> Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3
> (https://datatracker.ietf.org/doc/
For signatures or keys in something like a certificate, I understand how you
would want to have both the PQ and classical keys/sigs in the same structure,
so satisfy those who want the classical algorithm and those who prefer the
post-quantum.
For key exchange? For the most part a negotiation i
Thom and Ilari,
TW> We should currently be using full HPKE, we're just wrapping it in
TW> some KEM operations. But this is something I haven't looked at
TW> too deeply either.
Can I check what you mean here? Are you using the KEM by itself, HPKE with
single-shot secret export, HPKE with singl
On Mon, Oct 23, 2023 at 01:37:55PM -0400, Viktor Dukhovni wrote:
>
> - Some Java TLS libraries (used to?) fail the handshake when the
> client has no configured certs, or the list of issuer CA DN hints
> does include any of its available (typically just zero or one)
> certifi
On Mon, Oct 23, 2023 at 12:26:03PM -0400, David Benjamin wrote:
> > So in my mind this is something that will (almost) never be sent by
> browsers.
>
> What cases would the "(almost)" kick in? This extensions model just doesn't
> match how client certificates work in browsers. I'm not seeing any
>
I support adoption and can review.
Chris P.
On Mon, Nov 6, 2023 at 6:27 PM David Benjamin wrote:
> I support adoption and am willing to contribute text, but this is perhaps
> not surprising. :-)
>
> On Mon, Nov 6, 2023 at 12:25 PM Joseph Salowey wrote:
>
>> At the TLS meeting at IETF 118 there
I also support adoption, and am willing to contribute to text and
implementation efforts.
On Mon, Nov 6, 2023 at 6:50 PM Andrei Popov wrote:
> Likewise, I support adoption, willing to contribute text and
> implementation.
>
> Cheers,
>
> Andrei
>
> --
> *From:* TLS o
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 T
The problem with the argument “X trusts Kyber, so we don’t need hybrid” (where
X can be “NIST” or “the speaker”) is that trust, like beauty, is in the eye of
the beholder. Just because NIST (or any other third party) is comfortable with
just using Kyber (or Dilithium) does not mean that everyon
18 matches
Mail list logo
