[TLS] Re: Changing WG Mail List Reputation
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 process-gating question in the past. Recognizing that not everything the > WG will do is useful or applicable to all participants is, I think, a > useful reminder for, well, all participants. > > Yes. I think we can do that as a separate reminder ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Changing WG Mail List Reputation
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 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 not everything > the WG will do is useful or applicable to all participants is, I think, a > useful reminder for, well, all participants. > > Not faulty, I definitely asked this at the end of the TLS 1.3 development, > because we really wanted to make sure we got buy in. It may have happened > other times too, but I don’t remember it happening recently. We should be > saying "who will implement." > > > Yes. I think we can do that as a separate reminder > > I tend to agree and I would like to propose that we update the FAQ and > then send a separate reminder to list about the FAQ. More reminders, I > think, can’t hurt. > Well, everyone kind of has to agree on scope during chartering and rechartering, right? I will write an exaggeration here, just to show there must be limits: "My implementation is a Nintendo 64 that controls a nuclear power plant, and I must have visibility into the SNI, so ECH is unacceptable. PQ proposals are too expensive for my hardware, which I can only update every 25 years." When the WG takes on new work, we must have consensus that it's worth doing. In particular, the WG is not required to accomodate our Nintendo 64 enthusiast here while doing new work (that person can use the old stuff...), even though the use case might be a real thing. Looking at it that way, it's clear that there will always be people upset that their use case is ignored if the WG is being managed well. thanks, Rob ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: New Version Notification for draft-tls-reddy-slhdsa-00.txt
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 cases, can take on the order of > seconds. For, e.g., sphincsf128shake256simple, a quad-core 3GHz Intel Skylake from 2015 handles 85 signatures per second and 1300 verifications per second. (Source: dividing 12 billion cycles/second by the cycle counts given in https://bench.cr.yp.to/results-sign/amd64-samba.html.) Sure, one can come up with scenarios where this isn't fast enough or where 17KB for a signature is a problem. But there are also environments where these costs are negligible compared to the transmission and processing of user data. > 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 recommend? If the answer is that all decisions will be made by the scenarios most sensitive to speed, so being less affordable than Dilithium (ML-DSA) is fatal, then shouldn't Dilithium be analogously excluded, given that Dilithium is less affordable than KEMs for typical authentication tasks? The point here isn't just that Dilithium is outperformed by Kyber; consider the fact that a few hundred Dilithium signatures plus a public key cost more than a few hundred McEliece ciphertexts plus a public key. Conversely, if the answer is that we should skip all of these signature systems for TLS server keys and consider them only for CA keys, then shouldn't claims about signature affordability start with data regarding how many signatures CAs are doing? ---D. J. Bernstein ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: New Version Notification for draft-tls-reddy-slhdsa-00.txt
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 times slower than traditional > > certificate chains and, in some cases, can take on the order of > > seconds. > > For, e.g., sphincsf128shake256simple, a quad-core 3GHz Intel Skylake > from 2015 handles 85 signatures per second and 1300 verifications per > second. (Source: dividing 12 billion cycles/second by the cycle counts > given in https://bench.cr.yp.to/results-sign/amd64-samba.html.) > > Sure, one can come up with scenarios where this isn't fast enough or > where 17KB for a signature is a problem. But there are also environments > where these costs are negligible compared to the transmission and > processing of user data. > Agreed. That SLH-DSA is clearly not suited for all use cases for TLS, doesn't mean we should withhold it for those where it's acceptable. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: [EXT] Re: New Version Notification for draft-tls-reddy-slhdsa-00.txt
>> 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 recommend? The problem is interoperability , or induced lack thereof. So, depending on the intended server “visibility” and the expected range of clients, a server can require McEliece for KEX and SLH-DSA for cert signing. But that’s not likely to be useful in the “wide Internet”. “Not recommended” does not mean “prohibited”: for the larger part of the Internet users those “not recommended” algorithms won’t make sense, while those who need/want them – can still use them. smime.p7s Description: S/MIME cryptographic signature ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Changing WG Mail List Reputation
> 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 not everything the WG will do is useful or applicable to all participants is, I think, a useful reminder for, well, all participants. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Fwd: New Version Notification for draft-tls-reddy-composite-mldsa-00.txt
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 be rather hard on the cryptographic backends... So I'd rather not have them. On Sunday, 3 November 2024 01:07:34 CET, tirumal reddy wrote: Hi all, The draft https://datatracker.ietf.org/doc/draft-tls-reddy-composite-mldsa/ specifies how ML-DSA in combination with traditional algorithms can be used for authentication in TLS 1.3. Comments and suggestions are welcome. Regards, - Tiru -- Forwarded message - From: Date: Sun, 3 Nov 2024 at 05:33 Subject: New Version Notification for draft-tls-reddy-composite-mldsa-00.txt To: Tirumaleswar Reddy.K , John Gray , Scott Fluhrer , Timothy Hollebeek A new version of Internet-Draft draft-tls-reddy-composite-mldsa-00.txt has been successfully submitted by Tirumaleswar Reddy and posted to the IETF repository. Name: draft-tls-reddy-composite-mldsa Revision: 00 Title:Use of Composite ML-DSA in TLS 1.3 Date: 2024-11-02 Group:Individual Submission Pages:8 URL: https://www.ietf.org/archive/id/draft-tls-reddy-composite-mldsa-00.txt Status: https://datatracker.ietf.org/doc/draft-tls-reddy-composite-mldsa/ HTML: https://www.ietf.org/archive/id/draft-tls-reddy-composite-mldsa-00.html HTMLized: https://datatracker.ietf.org/doc/html/draft-tls-reddy-composite-mldsa Abstract: This document specifies how the post-quantum signature scheme ML-DSA [FIPS204], in combination with traditional algorithms RSA- PKCS#1v1.5,RSA-PSS, ECDSA, Ed25519, and Ed448 can be used for authentication in TLS 1.3. The composite ML-DSA approach is beneficial in deployments where operators seek additional protection against potential breaks or catastrophic bugs in ML-DSA. The IETF Secretariat -- Regards, Alicja (nee Hubert) Kario Principal Quality Engineer, RHEL Crypto team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: DTLS 1.3 ACK sorting, and when to clear the ACK buffer
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 reordering. That can also cause you to see the older epoch > even after the handshake has progressed past it. I'm not sure if there's > any benefit to doing this specifically during the handshake, although it > might let you see an older ACK. Seeing that older ACK may be unnecessary if > you do the epoch-aware implicit ACK you describe, but neither that nor > epoch management in general is described in the document. (I think the > very, very badly needed rfc9147bis should fix the latter at least. Adding > your extra implicit ACK case seems reasonable too.) Yes, it is reasonable to keep older epochs for a bit for possible reordered application data. But since this is merely SHOULD, things should still work even if all handshake records from older epoch are ignored. There might be an edge case where if client ignores all handshake records from older epoch, the server has to do epoch 0 implcit ACK in order to avoid a deadlock. > > There is subtle edge case where this can cause outright failures: > > > > - Sender that implements only linear tracking. > > - Very large flight that gets split into lots of records. > > - Some of those records get evicted from ACK buffer before being ACKed. > > - Flight has no response, or response is blocked. > > > > In this scenario, no data will get through, and the sender will just > > re-transmit the flight forever. > > > > To counter this, if ACK buffer fills with unacknowledged records, one > > should immediately send ACK. If the first record in transmission was > > received and that ACK makes it through, it will cause forward progress. > > > > I'm not sure that will actually prevent forward progress, though I may be > misunderstanding your example. In the worst case, you will manage to ACK, > say, the last 32K of that flight. The peer will then retransmit all but the > last 32K, you'll ACK the last 32K of that, and so on until the whole flight > gets ACKed. This is not amazing, but it's still forward progress. And given > each record number covers about an MTU's worth of handshake data, you don't > need much ACK buffer to avoid this or make its effects minimal. Though I > agree flushing the ACK buffer when full is a sensible implementation > strategy (though also not mentioned by the specification). Maybe such sender would be too simplistic, and all senders should implement full tracking. But with such simplistic sender, that case would not make forward progress and would livelock. However, when sending, one should be mindful of implementations with limited tracking (on receive side): - Do not have fragment sequence jump back. - Do not have multi-message records unless all but the last are guaranteed to be complete. What is the current maximum for number of messages in one flight? 6 (ServerHello, EncryptedExtensions, CertificateRequest, Certificate, CertificateVerify, Finished)? > > Above is one case where one wants last records sent (highest RSN), not > > last records received. > > > > I'm not sure I follow. In that example, there are more unACKed records than > fit in the buffer at all, so neither eviction algorithm will ACK > everything. I'm not seeing how prioritizing the highest RSN improves > things. More generally, the last records received are the one that you > haven't ACKed yet, so when there aren't eviction problems, those are the > ones to prioritize. Yeah, it is probably too marginal to be worthwhile. > > There is in fact another subtle edge case which requires ACKing stuff > > from previous flight: > > > > - Sender sends flight that has no response or response is blocked. > > - The complete flight comes through, but the last ACK is lost. > > - Sender re-transmits the (possibly partial) flight. > > > > The receiver considers flight complete, but sender does not. Getting > > things unstuck requires ACKing stuff from previous flight. > > > > However, this does not require keeping the records from previous flight > > in the list. > > > > Well, there's two ways to get it unstuck. You could either explicitly ACK > the previous flight, or just start sending your reply, which implicitly > ACKs that flight. If the blocking flight has response, then explicit ACK is required to avoid deadlock (to get out of state where both sides have flight in progress). But this can only happen post-handshake. > > When the old fragment is in the *current* flight, the > > peer may have lost an earlier ACK and not realize they can stop > > retransmitting. It's only old fragments in *previous* flights that are > > unnecessary to ACK, but the specification does not suggest to distinguish > > them. (Distinguishing them would require extra state in the record layer > to > > store
[TLS] Re: New Version Notification for draft-tls-reddy-slhdsa-00.txt
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 be made for Root Certs in TLS (I am not convinced), then I suggest it to be with just the slimmer parameters for 2^10 sigs in https://eprint.iacr.org/2024/018.pdf . Note that NIST has committed to standardizing slimmer SLH-DSA params sometime in the future. From: tirumal reddy Sent: Monday, November 4, 2024 2:16 AM To: Peter C Cc: IETF TLS Subject: [EXTERNAL] [TLS] Re: New Version Notification for draft-tls-reddy-slhdsa-00.txt 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 Peter, Please see inline On Sun, 3 Nov 2024 at 22:17, Peter C mailto:pete...@ncsc.gov.uk>> wrote: Tiru, Is SLH-DSA considered a practical option for TLS end-entity certificates? 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 cases, can take on the order of seconds. See, for example, the results in https://eprint.iacr.org/2020/071, https://eprint.iacr.org/2021/1447, https://mediatum.ub.tum.de/1728103 and https://thomwiggers.nl/post/tls-measurements/. 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. 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) -Tiru Peter From: Russ Housley mailto:hous...@vigilsec.com>> Sent: 03 November 2024 11:13 To: tirumal reddy mailto:kond...@gmail.com>> Cc: IETF TLS mailto:tls@ietf.org>> Subject: [TLS] Re: New Version Notification for draft-tls-reddy-slhdsa-00.txt Thanks for doing this work. I hope the TLS WG will promptly adopt it. Russ On Nov 2, 2024, at 8:15 PM, tirumal reddy mailto:kond...@gmail.com>> wrote: Hi all, 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. Comments and suggestions are welcome. Regards, -Tiru -- Forwarded message - From: mailto:internet-dra...@ietf.org>> Date: Sun, 3 Nov 2024 at 05:39 Subject: New Version Notification for draft-tls-reddy-slhdsa-00.txt To: Tirumaleswar Reddy.K mailto:kond...@gmail.com>>, John Gray mailto:john.g...@entrust.com>>, Scott Fluhrer mailto:sfluh...@cisco.com>>, Timothy Hollebeek mailto:tim.holleb...@digicert.com>> A new version of Internet-Draft draft-tls-reddy-slhdsa-00.txt has been successfully submitted by Tirumaleswar Reddy and posted to the IETF repository. Name: draft-tls-reddy-slhdsa Revision: 00 Title:Use of SLH-DSA in TLS 1.3 Date: 2024-11-02 Group:Individual Submission Pages:8 URL: https://www.ietf.org/archive/id/draft-tls-reddy-slhdsa-00.txt Status: https://datatracker.ietf.org/doc/draft-tls-reddy-slhdsa/ HTML: https://www.ietf.org/archive/id/draft-tls-reddy-slhdsa-00.html HTMLized: https://datatracker.ietf.org/doc/html/draft-tls-reddy-slhdsa Abstract: This memo specifies how the post-quantum signature scheme SLH-DSA [FIPS205] is used for authentication in TLS 1.3. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: New Version Notification for draft-tls-reddy-slhdsa-00.txt
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
>
> > generation and signing. They have *slower* verification.
>
>
>
> Also:
>
>
>
> “This document specifies the use of the SLH-DSA algorithm in
>
>TLS at three security levels. It includes the small (S) or
>
>fast (F) versions of the algorithm and allows for the use of
>
>either SHA-256 [FIPS180] or SHAKE256 [FIPS202] as the hash
>
>function.”
>
>
>
> The SHA2 parameter sets for security categories 3 and 5 use a
>
> mixture of SHA-256 and SHA-512. This means that you probably
>
> want to rename the SignatureScheme entries to
>
Agreed and we will address this in the next revision.
-Tiru
>
>
>enum {
>
> slhdsa128s_sha2 (0x0911),
>
> slhdsa128f_sha2 (0x0912),
>
> slhdsa192s_sha2 (0x0913),
>
> slhdsa192f_sha2 (0x0914),
>
> slhdsa256s_sha2 (0x0915),
>
> slhdsa256f_sha2 (0x0916),
>
> ...
>
>} SignatureScheme;
>
>
>
> Peter
>
>
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: New Version Notification for draft-tls-reddy-slhdsa-00.txt
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, >> it is preferred for CA certificates (please see the 3rd >> paragraph in [draft-section 2]). Me: > if you are not proposing SLH-DSA end-entity certificates > then you need to be more explicit that it is not recommended > for use in signature_algorithms. Yes, I’m surprised but at no point am I suggesting that SLH-DSA should be withheld, just that the draft should be explicit about what is or is not being proposed. The conditional in the final quote is fairly important. Thanks, Peter From: Bas Westerbaan Sent: 04 November 2024 17:37 To: tls@ietf.org Subject: [TLS] Re: New Version Notification for draft-tls-reddy-slhdsa-00.txt On Mon, Nov 4, 2024 at 6:31 PM D. J. Bernstein mailto:d...@cr.yp.to>> 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 times slower than traditional > certificate chains and, in some cases, can take on the order of > seconds. For, e.g., sphincsf128shake256simple, a quad-core 3GHz Intel Skylake from 2015 handles 85 signatures per second and 1300 verifications per second. (Source: dividing 12 billion cycles/second by the cycle counts given in https://bench.cr.yp.to/results-sign/amd64-samba.html.) Sure, one can come up with scenarios where this isn't fast enough or where 17KB for a signature is a problem. But there are also environments where these costs are negligible compared to the transmission and processing of user data. Agreed. That SLH-DSA is clearly not suited for all use cases for TLS, doesn't mean we should withhold it for those where it's acceptable. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Fwd: New Version Notification for draft-tls-reddy-slhdsa-00.txt
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 think the context to use should be taken as open question and > resolved together with ML-DSA. > Providing guidance on the use of context would be helpful for all protocols that utilize PQC signatures. I don't see any of the protocols using SLH-DSA/ML-DSA leverage the context—for instance, it is set to an empty string in draft-ietf-lamps-cms-sphincs-plus, draft-ietf-lamps-x509-slhdsa, and draft-ietf-cose-sphincs-plus (where use of context is not specified). -Tiru > After all, ML-DSA and SLH-DSA share the interface design, which is > beyond the capabilities of Ed25519ctx and Ed448, let alone Ed25519. > > And with regards to precedent, Ed25519 does not support contexts. > Ed25519ctx is the version where I hacked in context support, but > very few things support that. Ed448 does have native context > support, but much of code treats it just as larger Ed25519. > > > > -Ilari > > ___ > 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] Re: New Version Notification for draft-tls-reddy-slhdsa-00.txt
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. They have slower verification.
Also:
“This document specifies the use of the SLH-DSA algorithm in
TLS at three security levels. It includes the small (S) or
fast (F) versions of the algorithm and allows for the use of
either SHA-256 [FIPS180] or SHAKE256 [FIPS202] as the hash
function.”
The SHA2 parameter sets for security categories 3 and 5 use a
mixture of SHA-256 and SHA-512. This means that you probably
want to rename the SignatureScheme entries to
enum {
slhdsa128s_sha2 (0x0911),
slhdsa128f_sha2 (0x0912),
slhdsa192s_sha2 (0x0913),
slhdsa192f_sha2 (0x0914),
slhdsa256s_sha2 (0x0915),
slhdsa256f_sha2 (0x0916),
...
} SignatureScheme;
I think I'd go as far as make them follow the OID naming:
* slhdsa_sha2_128s
* slhdsa_sha2_128f
* ...
* slhdsa_shake_128s
* ...
as placing the hash at the end can be confusing, and indicate that's what
is used to hash the signed message in TLS, which is not the case; the
whole name specifies the public algorithm type, just like with Ed25519
--
Regards,
Alicja (nee Hubert) Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: New Version Notification for draft-tls-reddy-slhdsa-00.txt
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 introduction says: “This memo specifies how SLH-DSA can be negotiated for authentication in TLS 1.3 via the ‘signature_algorithms’ and ‘signature_algorithms_cert’ extensions.” which certainly implies end-entity certificates with SLH-DSA public keys. I realise that a single SignatureScheme registry is used for both extensions, so if you are not proposing SLH-DSA end-entity certificates then you need to be more explicit that it is not recommended for use in signature_algorithms. I think that's more of an argument for marking it as "Recommended = N" in the registry than outright forbidding it in CertificateVerify. Yes, it's totally overkill for signing TLS messages, and normal Internet clients and servers should not use it, but I think forbidding it for signature_algorithms and not signature_algorithms_cert will just complicate implementations unnecessairly. Peter From: tirumal reddy Sent: 04 November 2024 07:16 To: Peter C Cc: IETF TLS Subject: Re: [TLS] Re: New Version Notification for draft-tls-reddy-slhdsa-00.txt Hi Peter, Please see inline On Sun, 3 Nov 2024 at 22:17, Peter C wrote: Tiru, Is SLH-DSA considered a practical option for TLS end-entity certificates? 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 cases, can take on the order of seconds. See, for example, the results in https://eprint.iacr.org/2020/071, https://eprint.iacr.org/2021/1447, https://mediatum.ub.tum.de/1728103 and https://thomwiggers.nl/post/tls-measurements/. 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. 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) -Tiru Peter From: Russ Housley Sent: 03 November 2024 11:13 To: tirumal reddy Cc: IETF TLS Subject: [TLS] Re: New Version Notification for draft-tls-reddy-slhdsa-00.txt Thanks for doing this work. I hope the TLS WG will promptly adopt it. Russ On Nov 2, 2024, at 8:15 PM, tirumal reddy wrote: Hi all, 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. Comments and suggestions are welcome. Regards, -Tiru -- Forwarded message - From: Date: Sun, 3 Nov 2024 at 05:39 Subject: New Version Notification for draft-tls-reddy-slhdsa-00.txt To: Tirumaleswar Reddy.K , John Gray , Scott Fluhrer , Timothy Hollebeek A new version of Internet-Draft draft-tls-reddy-slhdsa-00.txt has been successfully submitted by Tirumaleswar Reddy and posted to the IETF repository. Name: draft-tls-reddy-slhdsa Revision: 00 Title:Use of SLH-DSA in TLS 1.3 Date: 2024-11-02 Group:Individual Submission Pages:8 URL: https://www.ietf.org/archive/id/draft-tls-reddy-slhdsa-00.txt Status: https://datatracker.ietf.org/doc/draft-tls-reddy-slhdsa/ HTML: https://www.ietf.org/archive/id/draft-tls-reddy-slhdsa-00.html HTMLized: https://datatracker.ietf.org/doc/html/draft-tls-reddy-slhdsa Abstract: This memo specifies how the post-quantum signature scheme SLH-DSA [FIPS205] is used for authentication in TLS 1.3. -- Regards, Alicja (nee Hubert) Kario Principal Quality Engineer, RHEL Crypto team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Adoption call for Large Record Sizes for TLS and DTLS
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 [3]. The I-D has been revised a few times since IETF 119 to incorporate > list feedback. This message is to judge consensus on whether there is support > to adopt this I-D. If you support adoption and are willing to review and > contribute text, please send a message to the list. If you do not support > adoption of this draft, please send a message to the list and indicate why. > This call will close on November 7, 2024. > > Thanks, > Deirdre, Joe, and Sean > > [0] > https://datatracker.ietf.org/doc/draft-mattsson-tls-super-jumbo-record-limit/ > [1] > https://datatracker.ietf.org/meeting/119/materials/slides-119-tls-large-record-sizes-for-tls-and-dtls-00 > > [2] https://mailarchive.ietf.org/arch/msg/tls/ZnGzqIWOkpm_F6zaqAxxtReHpVg/ > [3] https://mailarchive.ietf.org/arch/msg/tls/cRH9x6nbLeAnkG-fhOS3ASDA3oU/ ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: New Version Notification for draft-tls-reddy-slhdsa-00.txt
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 can be negotiated for authentication in TLS 1.3 via the 'signature_algorithms' and 'signature_algorithms_cert' extensions." which certainly implies end-entity certificates with SLH-DSA public keys. I realise that a single SignatureScheme registry is used for both extensions, so if you are not proposing SLH-DSA end-entity certificates then you need to be more explicit that it is not recommended for use in signature_algorithms. Peter From: tirumal reddy Sent: 04 November 2024 07:16 To: Peter C Cc: IETF TLS Subject: Re: [TLS] Re: New Version Notification for draft-tls-reddy-slhdsa-00.txt Hi Peter, Please see inline On Sun, 3 Nov 2024 at 22:17, Peter C mailto:pete...@ncsc.gov.uk>> wrote: Tiru, Is SLH-DSA considered a practical option for TLS end-entity certificates? 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 cases, can take on the order of seconds. See, for example, the results in https://eprint.iacr.org/2020/071, https://eprint.iacr.org/2021/1447, https://mediatum.ub.tum.de/1728103 and https://thomwiggers.nl/post/tls-measurements/. 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. 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) -Tiru Peter From: Russ Housley mailto:hous...@vigilsec.com>> Sent: 03 November 2024 11:13 To: tirumal reddy mailto:kond...@gmail.com>> Cc: IETF TLS mailto:tls@ietf.org>> Subject: [TLS] Re: New Version Notification for draft-tls-reddy-slhdsa-00.txt Thanks for doing this work. I hope the TLS WG will promptly adopt it. Russ On Nov 2, 2024, at 8:15 PM, tirumal reddy mailto:kond...@gmail.com>> wrote: Hi all, 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. Comments and suggestions are welcome. Regards, -Tiru -- Forwarded message - From: mailto:internet-dra...@ietf.org>> Date: Sun, 3 Nov 2024 at 05:39 Subject: New Version Notification for draft-tls-reddy-slhdsa-00.txt To: Tirumaleswar Reddy.K mailto:kond...@gmail.com>>, John Gray mailto:john.g...@entrust.com>>, Scott Fluhrer mailto:sfluh...@cisco.com>>, Timothy Hollebeek mailto:tim.holleb...@digicert.com>> A new version of Internet-Draft draft-tls-reddy-slhdsa-00.txt has been successfully submitted by Tirumaleswar Reddy and posted to the IETF repository. Name: draft-tls-reddy-slhdsa Revision: 00 Title:Use of SLH-DSA in TLS 1.3 Date: 2024-11-02 Group:Individual Submission Pages:8 URL: https://www.ietf.org/archive/id/draft-tls-reddy-slhdsa-00.txt Status: https://datatracker.ietf.org/doc/draft-tls-reddy-slhdsa/ HTML: https://www.ietf.org/archive/id/draft-tls-reddy-slhdsa-00.html HTMLized: https://datatracker.ietf.org/doc/html/draft-tls-reddy-slhdsa Abstract: This memo specifies how the post-quantum signature scheme SLH-DSA [FIPS205] is used for authentication in TLS 1.3. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: DTLS 1.3 ACK sorting, and when to clear the ACK buffer
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 and either processed or buffered, in > > numerically increasing order. > > https://www.rfc-editor.org/rfc/rfc9147.html#name-ack-message > > > > First, it is ambiguous what "numerically increasing order" means when > there > > are two integers in a packet number, not one. > > I would interpret "numerically increasing order" to mean primarily > sorted by epoch, secondarily by record sequence number. > > However, I do not think there are any other flights that should span > epochs besides the ServerHello-ServerFinished one. But I think this is > one of those reasonable-but-not-required-by-spec things. > > And that flight seems pretty special in terms of ACKing. For example, > any epoch 2+ ACK implicitly ACKs complete ServerHello message (it is > impossible to enter epoch 2+ without it). And one should be very > careful about epoch 0 (unencrypted) ACKs. > > (The DTLS 1.3 spec allows all sorts of stuff that seems pretty > unreasonable, like fragment sequence in a record jumping backwards.) > The spec also recommends you keep your older epochs around for a spell in case of packet reordering. That can also cause you to see the older epoch even after the handshake has progressed past it. I'm not sure if there's any benefit to doing this specifically during the handshake, although it might let you see an older ACK. Seeing that older ACK may be unnecessary if you do the epoch-aware implicit ACK you describe, but neither that nor epoch management in general is described in the document. (I think the very, very badly needed rfc9147bis should fix the latter at least. Adding your extra implicit ACK case seems reasonable too.) > > In particular, it seems a natural implementation will result in receive > > order, not numerical order. Implementations should bound their ACK > buffers > > to avoid DoS, and are expected to preferentially ACK more recent records: > > > > > Implementations MAY acknowledge the records corresponding to each > > transmission of each flight or simply acknowledge the most recent one. In > > general, implementations SHOULD ACK as many received packets as can fit > > into the ACK record, as this provides the most complete information and > > thus reduces the chance of spurious retransmission; if space is limited, > > implementations SHOULD favor including records which have not yet been > > acknowledged. > > I think it is important to priorize acking highest record numbers, > because senders should bound outstanding record buffers to avoid DoS, > those entries are required to handle ACK, and there is no backup whole- > message ack (with exception of ServerHello). > > There is subtle edge case where this can cause outright failures: > > - Sender that implements only linear tracking. > - Very large flight that gets split into lots of records. > - Some of those records get evicted from ACK buffer before being ACKed. > - Flight has no response, or response is blocked. > > In this scenario, no data will get through, and the sender will just > re-transmit the flight forever. > > To counter this, if ACK buffer fills with unacknowledged records, one > should immediately send ACK. If the first record in transmission was > received and that ACK makes it through, it will cause forward progress. > I'm not sure that will actually prevent forward progress, though I may be misunderstanding your example. In the worst case, you will manage to ACK, say, the last 32K of that flight. The peer will then retransmit all but the last 32K, you'll ACK the last 32K of that, and so on until the whole flight gets ACKed. This is not amazing, but it's still forward progress. And given each record number covers about an MTU's worth of handshake data, you don't need much ACK buffer to avoid this or make its effects minimal. Though I agree flushing the ACK buffer when full is a sensible implementation strategy (though also not mentioned by the specification). And when the response is merely blocked, at some point one hopes you will manage to generate that response, otherwise forward progress was impossible anyway for other reasons! :-) > > Given that, the natural implementation is some kind of bounded MRU queue > of > > records, where old ones fall off the end. (I'm planning to use a ring > > buffer for our implementation.) To get numerical order, you'd need to > > re-sort when sending an ACK. That is not hard, but it's unclear to me > > what's the point. > > Above is one case where one wants last records sent (highest RSN), not > last records received. > I'm not sure I follow. In that example, there are more unACKed records than fit in the buffer at all, so neither eviction algorithm will ACK everything. I'm not seeing how prioritizin
[TLS] Re: Changing WG Mail List Reputation
> 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, perhaps faulty, is that "will browsers implement this" has been a > process-gating question in the past. Recognizing that not everything the WG > will do is useful or applicable to all participants is, I think, a useful > reminder for, well, all participants. Not faulty, I definitely asked this at the end of the TLS 1.3 development, because we really wanted to make sure we got buy in. It may have happened other times too, but I don’t remember it happening recently. We should be saying "who will implement." > Yes. I think we can do that as a separate reminder I tend to agree and I would like to propose that we update the FAQ and then send a separate reminder to list about the FAQ. More reminders, I think, can’t hurt. spt ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
