On Mon, Nov 4, 2024 at 10:48 AM Salz, Rich wrote:
> > While there is overlap between professional behavior and the perceived
> focus on browser specific use cases; I think we should try to separate out
> the topic.
>
> My memory, perhaps faulty, is that "will browsers implement this" has been
> a
On Mon, Nov 4, 2024 at 8:25 AM Sean Turner wrote:
>
> > On Nov 4, 2024, at 15:35, Joseph Salowey wrote:
> >
> > On Mon, Nov 4, 2024 at 10:48 AM Salz, Rich wrote:
> > > While there is overlap between professional behavior and the perceived
> focus on browser specific use cases; I think we should
Speaking for myself, not on behalf of the SPHINCS+ team (or other teams
potentially relevant here).
Peter C writes:
> Under realistic network conditions, TLS handshakes with full SLH-DSA
> certificate chains seem to be about 5-10 times slower than traditional
> certificate chains and, in some case
On Mon, Nov 4, 2024 at 6:31 PM D. J. Bernstein wrote:
> Speaking for myself, not on behalf of the SPHINCS+ team (or other teams
> potentially relevant here).
>
> Peter C writes:
> > Under realistic network conditions, TLS handshakes with full SLH-DSA
> > certificate chains seem to be about 5-10 t
>> not recommended for use in signature_algorithms
>
> People deploying TLS can do the performance measurements for themselves
> and decide whether high confidence in security is affordable for their
> applications. Shouldn't speed be given lower weight than security in
> decisions of what to rec
> While there is overlap between professional behavior and the perceived focus
> on browser specific use cases; I think we should try to separate out the
> topic.
My memory, perhaps faulty, is that "will browsers implement this" has been a
process-gating question in the past. Recognizing that
Hello,
I don't think we should go back to signing with PKCS#1 v1.5 in TLSv1.3.
I'm opposed to including those two IDs:
mldsa44_rsa_pkcs1_sha256 (0x090C),
mldsa65_rsa_pkcs1_sha384 (0x090D),
Theoretically we could require the RSA part to still make PSS signatures
but I think that would b
On Mon, Nov 04, 2024 at 01:52:06PM +, David Benjamin wrote:
> On Sun, Nov 3, 2024 at 3:50 PM Ilari Liusvaara
> wrote:
>
> > On Sun, Nov 03, 2024 at 12:49:59PM +, David Benjamin wrote:
> >
>
> The spec also recommends you keep your older epochs around for a spell in
> case of packet reord
From draft-tls-reddy-slhdsa-00
> SLH-DSA can be preferred for CA certificates, making it ideal for long-term
> security as a trust anchor.
I think the standardized SLH-DSA parameters (designed for 2^64 signatures)
still make the ICA cert unnecessarily large.
If there is an SLH-DSA argument to
On Mon, 4 Nov 2024 at 02:52, Peter C wrote:
> John Mattsson wrote:
>
> > ”Conversely, the fast version prioritizes speed over
>
> > signature size, minimizing the time required to generate
>
> > and verify signatures.”
>
> >
>
> > This is incorrect. The “f” versions only have faster key
>
> > gen
Before this goes any further, perhaps I should clarify the
context of my comment.
Me:
>>> I agree that there’s an argument for using SLH-DSA
>>> in root certificates, but I’m surprised it’s being
>>> proposed for the full chain.
Tiru:
>> SLH-DSA is not proposed for the end-entity certificates,
>>
On Sun, 3 Nov 2024 at 14:34, Ilari Liusvaara
wrote:
> On Sun, Nov 03, 2024 at 05:45:13AM +0530, tirumal reddy wrote:
> >
> > This draft https://datatracker.ietf.org/doc/draft-tls-reddy-slhdsa/
> > specifies how the PQC signature scheme SLH-DSA can be used for
> > authentication in TLS 1.3.
>
> I
On Sunday, 3 November 2024 22:22:52 CET, Peter C wrote:
John Mattsson wrote:
”Conversely, the fast version prioritizes speed over
signature size, minimizing the time required to generate
and verify signatures.”
This is incorrect. The “f” versions only have faster key
generation and signing. The
On Monday, 4 November 2024 14:39:12 CET, Peter C wrote:
Tirumal Reddy wrote:
SLH-DSA is not proposed for the end-entity certificates, it is preferred
for CA certificates (please see the 3rd paragraph in
https://www.ietf.org/archive/id/draft-tls-reddy-slhdsa-00.html#section-2)
Yes, except the
Hi! This is just another reminder that this WG adoption call is still ongoing.
spt
> On Oct 25, 2024, at 03:46, Sean Turner wrote:
>
> At the TLS meeting at IETF 119 we discussed the Large Record Sizes for TLS
> and DTLS I-D; see [0] and [1]. There has been some list discussion; see [2]
> and
Tirumal Reddy wrote:
> SLH-DSA is not proposed for the end-entity certificates, it is preferred
> for CA certificates (please see the 3rd paragraph in
> https://www.ietf.org/archive/id/draft-tls-reddy-slhdsa-00.html#section-2)
Yes, except the introduction says:
"This memo specifies how SLH-DSA
On Sun, Nov 3, 2024 at 3:50 PM Ilari Liusvaara
wrote:
> On Sun, Nov 03, 2024 at 12:49:59PM +, David Benjamin wrote:
> > Hi all,
> >
> > So, Section 7 says the ACK contains:
> > > A list of the records containing handshake messages in the current
> flight
> > which the endpoint has received an
> On Nov 4, 2024, at 15:35, Joseph Salowey wrote:
>
> On Mon, Nov 4, 2024 at 10:48 AM Salz, Rich wrote:
> > While there is overlap between professional behavior and the perceived
> > focus on browser specific use cases; I think we should try to separate out
> > the topic.
>
> My memory, per
18 matches
Mail list logo
