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 s
On Thu, Nov 09, 2023 at 08:48:07AM +, John Mattsson wrote:
>
> 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 ci
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
There are several documents in a cluster that define new hybrid
`NamedGroup`s and how those operate / are combined, abstracted away from
the rest of the TLS handshake. Treating hybrid schemes (key establishment,
signatures) as /separate and distinct from their component algorithms/ is a
good idea.
Scott Fluhrer wrote:
>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.
I think it is bit problematic that the discussion was so long ago before any
Sophie Schmieg writes:
> NTRU being chosen for non-security related criteria that have since
> materially changed.
I recommend discussing the patent issues explicitly, including public
analysis of the patent threats. For example, Yunlei Zhao in
https://groups.google.com/a/list.nist.gov/g/pqc-
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 argum
Hey folks,
Following my presentation at the meeting at IETF 118 today (thanks for
taking it easy on me, as this was my first IETF appearance as well as being
my first I-D), I have created another version of my I-D:
https://www.ietf.org/archive/id/draft-hewitt-ietf-qpack-static-table-version-02.ht
I've done a tiny bit of checking on the situation of where we (USG DOD)
have smartcards doing client auth TLS. To my knowledge, most (all?) are
currently TLS 1.2 w/ PKCS1v1.5 certs. So, I would be in favor of this
update (when I wrote RFC9151 I had long discussions about this, because I
was worr
I support moving forward with this document.
On Wed, 25 Oct 2023 at 04:49, Andrei Popov
wrote:
>
> Hi TLS,
>
>
>
> We would like to re-introduce
> https://datatracker.ietf.org/doc/draft-davidben-tls13-pkcs1/
>
> (it’s intended for the TLS WG and the Standards track, despite what the
> document
10 matches
Mail list logo
