[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Peter Gutmann]

Yaron Sheffer  writes:

>Specifically, RFC 9325 [1] published a mere two years ago is not even
>referenced in the draft, let alone a comparison made with these deployment
>recommendations that were made by the very same IETF. (Yes you can hear my
>frustration coming through).

In defence of the -LTS draft, RFC 9325 postdates it by six years, so there
wasn't anything to reference at the time.  I'm also not certain how much
overlap there is between the two, for example 9325 contains quite a lot of
stuff (older TLS versions, compression, DTLS, fallback, RC4, NULL cipher
suites, RSA key transport, etc) that has no bearing on what's in -LTS which
means it could cause confusion if someone tries to apply it to things that
mostly don't exist in -LTS.

Having said that, now that my attention has been drawn to it :-), I'd be happy
to include a note along the lines of "further advice on secure use of TLS may
be found in RFC 9325", it would certainly fit in with what -LTS is trying to
achieve.

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

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Peter Gutmann]

David Benjamin  writes:

>Given that the new client_server_hello_hash fully overlaps with the old
>client_random (totally under the client's control) and then the new params
>overlap with the old server_random (totally under the server's control),
>it's... not immediately obvious to me whether this is fine.

If I'm reading your comment correctly then I'm not sure how that could be
exploitable, an attacker only controls one side and even if they didn't, to
move the signature across from LTS -> TLS you'd have to stuff the entire
client and server hello into the client/server_random contained within them in
order to get the same hash value.  Since this is fixed at 32 bytes, or 64 if
you control both client and server, it's not really possible, and going TLS ->
LTS is a complete non-starter.

Peter.

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

[TLS] Re: ML-DSA in TLS

[John Mattsson]

Stephen Farrell wrote: 
>Without going into the details, I'm generally sympathetic to djb's 
>argument here, but also do recognise ekr's "we allow anyone to get 
>a RECOMMENDED=N code point" as valid. 

+1 

In addition to discussing security, it is a fact that many governments requires 
ML-KEM and ML-DSA to be hybritized. Standalone ML-KEM and ML-DSA are simple not 
deployable for any global companies: 

"PQC only in hybrid solutions, i.e. PQC + “Classical”, except for HBS" 
"Post-quantum algorithms must be hybridized with well-known pre-quantum 
algorithms." 
"strongly emphasizes the necessity of hybridation" 
"strongly recommends to use hybrid protocols" 
"If it is not possible to use hash-based signatures, use a hybrid of ML-DSA and 
EC-DSA or legacy RSA" 

For quantum-resistant KEMs I think we need to not only start discussing 
RECOMMENDED=Y but also MTI asap. 

Cheers, 
John 

https://pkic.org/events/2023/pqc-conference-amsterdam-nl/pkic-pqcc_stephan-ehlen_bsi_post-quantum-policy-and-roadmap-of-the-bsi.pdf
 

 

https://pkic.org/events/2023/pqc-conference-amsterdam-nl/pkic-pqcc_jerome-plut_anssi_anssi-plan-for-post-quantum-transition.pdf
 

 

https://cyber.gouv.fr/sites/default/files/document/follow_up_position_paper_on_post_quantum_cryptography.pdf
 

 

https://cyber.gouv.fr/sites/default/files/document/pqc-transition-in-france.pdf 

 

http://kth.diva-portal.org/smash/get/diva2:1902626/FULLTEXT01.pdf 
 


On 2024-11-21, 22:02, "Stephen Farrell"  wrote: 


Hiya, 



Without going into the details, I'm generally sympathetic to djb's 

argument here, but also do recognise ekr's "we allow anyone to get 

a RECOMMENDED=N code point" as valid. 



That said, if the WG adopt *anything* with RECOMMENDED=Y in this 

space (incl. for KEMs) then I think the onus is on the WG to write 

down guidance for the entire space, especially as there will be 

codepoints for non-hybrids. 



In summary: I don't think we should go back to previous policies 

where we'd try prevent registration of non-hybrids, but I do think 

we really need to try reach consensus on guidance text for the whole 

slew of PQ possibilities for TLS. (And IMO that guidance would be 

along the lines of djb's argument.) 



Cheers, 

S. 



PS: It seems pretty ironic to me that ambiguities in NIST and NSA text 

are turning out such a barrier to getting PQ stuff done when at the 

same time they're some of the entities trying to (again IMO) rush a 

pile of things here. (To be clear: for me, everything PQ except hybrid 

KEMs is a thing for which we ought hasten much more slowly.) 








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: ML-DSA in TLS

[Alicja Kario]

On Thursday, 21 November 2024 19:23:12 CET, Tim Hollebeek wrote:
Yes, the thread on this draft got hijacked by a completely 
off-topic discussion about composite and hybrid.
 
To be clear, the draft says absolutely nothing about either of 
those two topics, and to be even more clear, does not at all 
imply in any way that pure ML-DSA is superior or is the only 
option. It just says that if you need ML-DSA for TLS, here’s how 
you do it.
 
People who want to discuss composite / hybrid, which by the way 
I personally am also in favor of and actually prefer for many 
use cases, should move those discussions to threads about the 
appropriate drafts.
 
ML-DSA support for TLS is obvious and straightforward. We 
should explain and standardize the right way to do it, to 
prevent people from inventing a plethora of slightly different, 
non-standard implementations out of necessity because IETF 
failed to publish a straightforward draft in a timely manner.
 
Let’s get back on topic and get this done.


Precisely my point.

I don't want a repeat of the mess that RFC 8734 created.

So, even if I don't think the algorithm is the best choice around,
having the specification go through WG means that it receives more
and better feedback.

From: Scott Fluhrer (sfluhrer)  
Sent: Thursday, November 21, 2024 8:55 AM

To: Andrey Jivsov ; Eric Rescorla 
Cc: tls@ietf.org
Subject: [TLS] Re: ML-DSA in TLS
 
Might I ask what are we arguing about?  Does the TLS working 
group feel the need to prohibit pure ML-DSA as authentication?  
Even though, after Q-day happens (whenever that will be), that 
might be what people want?
 
If you go through the TLS ML-DSA draft, all they do is define 
three code points (for the three ML-DSA parameter sets), that’s 
it.  That sounds like a reasonable addition, even if it were to 
turn out to be useful only in a few networks with private CAs.
 
From: Andrey Jivsov  
Sent: Wednesday, November 20, 2024 3:36 PM

To: Eric Rescorla 
Cc: tls@ietf.org
Subject: [TLS] Re: ML-DSA in TLS
 
Given that the series of Suite B RFCs were Informational, it 
stands to reason that a document of the type that e.g. prohibits 
hybrids because of internal policies of any organization, a 
viewpoint which is not strongly shared by IETF, should not be a 
standards-track document. For what I see, no-hybrids policy 
increases complexity in real-world systems that need to expose a 
hybrid and its components as a separate option, and this is 
especially difficult for systems that must have a single option 
acceptable to everyone.
 
TLS https://datatracker.ietf.org/doc/html/rfc5430

IPSec https://datatracker.ietf.org/doc/html/rfc6380
SMIME https://datatracker.ietf.org/doc/html/rfc6318
OpenPGP: there was pushback on Standards-track, and it only 
could get standards track after we made sure that Brinpool 
curves are supported 
https://www.rfc-editor.org/rfc/rfc6637.html 
 
(The difference in practice may not be significant, but I still 
think that Informational is correct)
 
On Wed, Nov 20, 2024 at 9:22 AM Eric Rescorla  wrote:
 
 
On Wed, Nov 20, 2024 at 6:06 AM D. J. Bernstein  wrote:

https://web.archive.org/web/20240925031754/https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF
includes the following note: "Even though hybrid solutions may be
allowed or required due to protocol standards, product availability, or
interoperability requirements, CNSA 2.0 algorithms will become mandatory
to select at the given date, and selecting CNSA 1.0 algorithms alone
will no longer be approved."

This looks 100% compatible with a TLS WG decision saying "PQ in TLS has
to be hybrid".
 
Without addressing the question of what CNSA 2.0 requires, I don't think

the TLS WG making that decision is really on the table here. As a reminder,
the relevant TLS registry 
(https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8)

operates under an "Expert Review" policy with the standard being quite
low.
  Note:  The role of the designated expert is described in RFC 8447.
  The designated expert [RFC8126] ensures that the specification is
  publicly available.  It is sufficient to have an Internet-Draft
  (that is posted and never published as an RFC) or a document from
  another standards body, industry consortium, university site, etc.
  The expert may provide more in-depth reviews, but their approval
  should not be taken as an endorsement of the supported group.
So, the question isn't so much whether a given algorithm can be used with
TLS but rather (1) whether the WG adopts it (2) whether it's 
standards track,

(3) whether we mark it Recommended and (4) whether it's mandatory to
implement. We certainly could mark ML-KEM Recommended=N (or
even D), but  the policy isn't to forbid code point registration
just because we don't have confidence in the algorithm; I don't 
think we should

change that in this case.
 
-Ekr


--
Regards,
Alicja (nee Hubert) Kario
Principa

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Rob Sayre]

Hi,

It doesn't make sense to me, especially considering the WG has adopted

https://datatracker.ietf.org/doc/draft-ietf-tls-tls12-frozen/

TLS 1.3 is 6+ years old, for those counting.

Ekr wrote:
> There's nothing stopping people deploying this if they want to and in
fact there
> is already a code point assigned. However, the TLS WG should not take up
this work.

That sounds right to me.

thanks,
Rob


On Fri, Nov 22, 2024 at 9:02 AM Andrew Campling
 wrote:

> On Fri, Nov 22, 2024 at 16:46 Watson Ladd  wrote:
>
>
>
> > How on earth would providing another incompatible set of suggestions
> help? No matter what text was in there it would still raise the question of
> what people should be doing.
>
>
>
> Hi Watson
>
> You may of course not believe that this is a problem or that it is not
> something that the working group needs to solve.  I wouldn’t suggest
> starting with “another incompatible set of suggestions” unless you believe
> that the previous efforts were not useful(?).
>
>
>
> If you agree with the previous post from Yaron that there is a problem
> then it seems reasonable to come up with a proposal on how best to address
> the current lack of clarity.  One way to do that is to incorporate updated
> text into the TLS-LTS draft, and any others that touch on TLS 1.2, making
> sure that it communicates clearly to implementers and others the relative
> positions of TLS 1.2, TLS-LTS and TLS 1.3 with reference RFC 9325 and any
> other relevant documents etc.  Using this consistently from now on ought to
> help.
>
>
>
> There are other ways to address this problem if you agree that it needs to
> be addressed.
>
>
>
>
>
> Andrew
>
>
>
>
> ___
> 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: Fwd: New Version Notification for draft-reddy-tls-composite-mldsa-00.txt

[tirumal reddy]

Thank you, Alicja, for the review. I agree with all your comments and have
raised a PR https://github.com/tireddy2/composite-mldsa/pull/1 to address
them.

Cheers,
-Tiru

On Mon, 18 Nov 2024 at 20:44, Alicja Kario  wrote:

> Thanks for the work on this document, it's highly appreciated!
>
> Few comments:
>  - If we allow for pkcs#1v1.5 sig schemes in signatures_algorithms_cert but
>not in signatures_algorithms I think we should, at the very least,
>ask IANA to add a column to the SignatureScheme namespace that
>includes that information
>  - while the descriptive text does say PKCS#1v1.5 schemes shouldn't be in
>signature_algorithms, it doesn't specify peer behaviour if the other
>side of the connection misbehaves ("MAY abort connection with
>illegal_parameter if it's included in Client Hello or Certificate
>Request signature_algorithms extension" and "MUST abort the connection
>with an illegal_parameter alert if it's used in Certificate Verify
>message"?)
>  - while the mapping for Schemes to OIDs in
> draft-ietf-lamps-pq-composite-sigs
>for ECDSA and EdDSA is clear and 1-to-1, that's not the case for RSA.
>The draft-ietf-lamps-pq-composite-sigs specifies RSA with specific key
>sizes, and for example we have both id-HashMLDSA65-RSA3072-PSS-SHA512
>and id-HashMLDSA65-RSA4096-PSS-SHA512... which one should be used with
>mldsa65_rsa_pss_pss_sha384?
>  - same for the hash function, the draft-ietf-lamps-pq-composite-sigs uses
>SHA-512 for the combinations with ML-DSA65, while this draft specifies
>SHA-384... I think they should be aligned and identical: the
>draft-ietf-lamps-pq-composite-sigs schemes should be considered atomic,
>with a key of id-HashMLDSA65-RSA3072-PSS-SHA512 able to perform
> signatures
>only with that scheme, not with arbitrary hash functions...
>
> On Saturday, 16 November 2024 06:57:17 CET, tirumal reddy wrote:
> > Hi all,
> >
> > The updated draft
> > https://datatracker.ietf.org/doc/draft-reddy-tls-composite-mldsa/,
> > incorporates feedback received from the WG. It outlines how
> > ML-DSA in combination with traditional algorithms can be
> > utilized for authentication in TLS 1.3.
> >
> > Further, comments and suggestions are welcome.
> >
> > Best Regards,
> > -Tiru
> >
> > -- Forwarded message -
> > From: 
> > Date: Thu, 14 Nov 2024 at 16:55
> > Subject: New Version Notification for
> draft-reddy-tls-composite-mldsa-00.txt
> > To: Tirumaleswar Reddy.K , John Gray
> > , Scott Fluhrer ,
> > Timothy Hollebeek 
> >
> >
> > A new version of Internet-Draft draft-reddy-tls-composite-mldsa-00.txt
> has
> > been successfully submitted by Tirumaleswar Reddy and posted to the
> > IETF repository.
> >
> > Name: draft-reddy-tls-composite-mldsa
> > Revision: 00
> > Title:Use of Composite ML-DSA in TLS 1.3
> > Date: 2024-11-14
> > Group:Individual Submission
> > Pages:8
> > URL:
> > https://www.ietf.org/archive/id/draft-reddy-tls-composite-mldsa-00.txt
> > Status:
> https://datatracker.ietf.org/doc/draft-reddy-tls-composite-mldsa/
> > HTML:
> >  https://www.ietf.org/archive/id/draft-reddy-tls-composite-mldsa-00.html
> > HTMLized:
> > https://datatracker.ietf.org/doc/html/draft-reddy-tls-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: Adoption call for TLS 1.2 Update for Long-term Support

[Salz, Rich]

If the consensus view of the working group is that the existing communications 
have resulted in mixed messages and some confusion, the adoption of TLS LTS 
could provide a useful vehicle to address that whilst also dealing with the 
various technical points that Peter has already identified in his draft.  By 
expanding the introduction plus sections 3.7  and 4 (or by adding a new 
section), it should be possible to communicate clearly to implementers and 
others the relative positions of TLS 1.2, TLS-LTS and TLS 1.3 with reference 
RFC 9325 and any other relevant documents etc.

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

[TLS] [RFC 7627] PSK vulnerable to MiTM-attacks

[Schlie, Alexander, Dr. (ESEC/3)]

Dear ladies and gentlemen,

the RFC 7627 introduces the "Extended master secret" TLS extension to prevent 
man-in-the-middle attacks.

In section 1 - Introduction - on page three of the RFC, it is stated that 
"other key exchanges, such as [...] Pre-Shared Key (PSK), have also been shown 
to be vulnerable 
[VERIFIED-BINDINGS]".
However, the referenced paper (cf. reference given below) makes no mention of 
pre-shared keys, but rather states that "channel synchronization attacks apply 
also to channel bindings for other key exchanges such as [IKEv2, SRP and 
ECDHE]" 
[VERIFIED-BINDINGS].

I would kindly ask you to clarify how I should interpret the statement in the 
RFC pertaining to the PSK vulnerability?
In other words, is the PSK key exchange vulnerable to MiTM attacks as stated, 
or does the vulnerability arise from a malicious server (MiTM) forcing a client 
not to use a PSK cipher suite, but rather another key exchange such as SRP or 
ECDHE?

I appreciate your support.

Thank you and best regards,
Alexander Schlie


[VERIFIED-BINDINGS]
Bhargavan, K., Delignat-Lavaud, A., and A. Pironti, "Verified Contributive 
Channel Bindings for Compound Authentication", Network and Distributed System 
Security
Symposium (NDSS), 2015.


Dr.-Ing. Alexander Schlie
Car Communication Security (ESEC/3)

Volkswagen Aktiengesellschaft
Brieffach 011/17020
38436 Wolfsburg

www.volkswagenag.de

DE

Volkswagen Aktiengesellschaft
Sitz: Wolfsburg
Registergericht: Amtsgericht Braunschweig
HRB Nr.: 100484
Vorsitzender des Aufsichtsrats: Hans Dieter Pötsch
Vorstand: Oliver Blume (Vorsitzender), Arno Antlitz, Ralf Brandstätter, Gernot 
Döllner, Manfred Döss, Gunnar Kilian, Thomas Schäfer, Thomas Schmall-von 
Westerholt, Hauke Stars
Wichtiger Hinweis: Die vorgenannten Angaben werden jeder E-Mail automatisch 
hinzugefügt und lassen keine Rückschlüsse auf den Rechtscharakter der E-Mail zu.

Informationen zum Umgang mit Ihren personenbezogenen Daten finden Sie unter 
https://www.volkswagen.de/de/mehr/rechtliches/datenschutzerklaerung-allgemeine-kommunikation.html

EN

Volkswagen Aktiengesellschaft
Registered Seat: Wolfsburg I Registration Court: Amtsgericht Braunschweig
Commercial Register No.: 100484
Chairman of the Supervisory Board: Hans Dieter Pötsch
Board of Management: Oliver Blume (Chairman), Arno Antlitz, Ralf Brandstätter, 
Gernot Döllner, Manfred Döss, Gunnar Kilian, Thomas Schäfer, Thomas Schmall-von 
Westerholt, Hauke Stars
Important Notice: The above information is automatically added to this e-mail. 
This addition does not constitute a representation that the content of this 
e-mail is legally relevant and/or is intended to be legally binding upon 
Volkswagen Aktiengesellschaft.

Information about our handling of your personal data can be found here: 
https://www.volkswagen.de/de/mehr/rechtliches/privacy-policy-for-general-communication.html

Weitere Informationen zum Thema E-Mail Signatur bei Volkswagen finden Sie auf 
der Group Wiki Seite des Corporate Design:
https://volkswagen-net.de/wikis/display/CiCdVWgroup/E-Mail+Signatur+bei+Volkswagen



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

[TLS] Re: [EXT] Re: ML-DSA in TLS

[D. J. Bernstein]

Blumenthal, Uri - 0553 - MITLL writes:
> we know enough now about the accepted PQ algorithms to be reasonably
> certain that they won’t be the weakest part.

Reasonably certain meaning, what, 90% certainty? What's the basis for
this claim? And are you saying that a 10% chance of disaster is okay?

> Where do you draw the line?

Simple: require hybrids. Any upgrade from pre-quantum crypto to
post-quantum crypto is obliged to keep the pre-quantum crypto and to
use the post-quantum crypto as an extra layer of defense, rather than
removing the pre-quantum crypto.

This requirement distinguishes "switch from ECC to Dilithium in TLS"
(not allowed) from "switch from ECC to ECC+Dilithium in TLS" (allowed),
for example.

The point is to address the concern that an upgrade to post-quantum
crypto will be to something that's actually breakable. This isn't a
hypothetical concern. On the mathematical side, CECPQ2b was rolled out
with ECC+SIKE, and then the SIKE part was publicly broken; on the
implementation side, PQ software is still in the early days of continual
discovery of exciting new classes of security failures.

Directly addressing this concern reduces security risks and encourages
deployment. That's exactly why we see so much hybrid deployment already.
People understand and appreciate the idea of (1) rolling something out
that _hopefully_ stops quantum attacks while (2) taking reasonable steps
to limit the damage in case #1 goes disastrously wrong.

There are contrary arguments from NSA and GCHQ for using PQ rather than
ECC+PQ. https://blog.cr.yp.to/20240102-hybrid.html quotes and answers
those arguments. For example, the generic argument about ECC+PQ being
"less efficient" than PQ is easily answered by quantification of how the
total ECC+PQ costs are dominated by the PQ communication costs.

If, hypothetically, someone proposes requiring ECC+PQ1+PQ2 rather than
ECC+PQ1, then I'd ask for that proposal to be addressed separately since
analyzing its cost acceptability is much more complicated. See also
https://mailarchive.ietf.org/arch/msg/tls/2bRwN2CUGDwDwwpjHI63uyG09Lk/
regarding the idea of making exceptions to ECC+PQ for some PQ systems.
These variations are distractions from the simple common-sense step of
requiring hybrids.

I've seen various comments that come across as "yes, of course we should
use hybrids, but the U.S. government won't buy hybrids". I'm skeptical
about the accuracy of the won't-buy rumor---NSA's official statements
don't sound like a ban on hybrids---and in any case we shouldn't allow
money to buy approval of something frivolously incurring security risks.

Realistically, what's the problem supposed to be if the TLS WG requires
hybrids? Do we really think the WG is so powerless?

> I recognize (though disagreeing with) the arguments of those who want
> hybrid KEMs. I do not buy the arguments for hybrid signatures at all.

Sorry, can you please say what the relevant difference is supposed to be
between encryption and signatures?

Compared to just PQ, whether for encryption or for signatures, ECC+PQ
reduces the damage caused by PQ breaks. Quantifying costs of ECC vs. PQ
doesn't give the same numbers for encryption as it does for signatures,
but in both cases the total costs of communication and computation for
ECC are much smaller than the costs of PQ communication.

> This boils down to the need to maintain infrastructure, codebase, etc.
> for ECC and PQ,

Pointing to the PQ software is wrong when the comparison is between PQ
and ECC+PQ. The difference is only the ECC software, which is simpler
and vastly more mature than the PQ software.

> plus the possible intricacies of their interactions

The only ECC+PQ failures that matter are the ones so extreme that they
make ECC+PQ _less_ secure than PQ alone would have been.

Sure, this can happen: e.g., a quantum computer comes along and then it
turns out that someone forgot to verify the PQ part of an ECC+PQ
signature. So we build tests for that. The risks here are much more
controlled than the risks of further PQ breaks.

It makes no sense to worry more about failures in the combiner code than
in orders of magnitude more code for the PQ system. Analogous comments
apply to mathematical attacks: sure, combiners have an attack surface,
but the PQ attack surface is much larger.

---D. J. Bernstein

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

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Watson Ladd]

On Fri, Nov 22, 2024 at 6:48 AM Andrew Campling
 wrote:
>
> On 22/11/2024, 13:37, Yaron Sheffer yaronf.i...@gmail.com wrote:
>
> > My point was much broader though: the IETF is sending deployers a bunch
>
> > of mixed messages, and this is on us as a community.
>
> >
>
> > RFC 9325 basically tells them: we prefer that you switch to TLS 1.3, but if
>
> > you absolutely cannot do that, here’s how you can configure the existing
>
> > TLS 1.2 and be secure (as of the time of publication).
>
> >
>
> > TLS-LTS sends a whole different message of course.
>
> >
>
> > And then the working group keeps nibbling at TLS 1.2 with documents like
>
> > draft-ietf-tls-deprecate-obsolete-kex and the earlier “deprecating”
>
> > documents. The KEX document does mention RFC 9325 at one point but
>
> > does not say explicitly which of its requirements are new, making it hard
>
> > for implementers to navigate our recommendations.
>
>
>
>
>
> If the consensus view of the working group is that the existing 
> communications have resulted in mixed messages and some confusion, the 
> adoption of TLS LTS could provide a useful vehicle to address that whilst 
> also dealing with the various technical points that Peter has already 
> identified in his draft.  By expanding the introduction plus sections 3.7  
> and 4 (or by adding a new section), it should be possible to communicate 
> clearly to implementers and others the relative positions of TLS 1.2, TLS-LTS 
> and TLS 1.3 with reference RFC 9325 and any other relevant documents etc.

How on earth would providing another incompatible set of suggestions
help? No matter what text was in there it would still raise the
question of what people should be doing.
>
>
>
> Andrew
>
>
>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org



-- 
Astra mortemque praestare gradatim

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

[TLS] Re: ML-DSA in TLS

[Alicja Kario]

On Thursday, 21 November 2024 22:02:45 CET, Stephen Farrell wrote:

Hiya,

Without going into the details, I'm generally sympathetic to djb's
argument here, but also do recognise ekr's "we allow anyone to get
a RECOMMENDED=N code point" as valid.

That said, if the WG adopt *anything* with RECOMMENDED=Y in this
space (incl. for KEMs) then I think the onus is on the WG to write
down guidance for the entire space, especially as there will be
codepoints for non-hybrids.

In summary: I don't think we should go back to previous policies
where we'd try prevent registration of non-hybrids, but I do think
we really need to try reach consensus on guidance text for the whole
slew of PQ possibilities for TLS. (And IMO that guidance would be
along the lines of djb's argument.)


As somebody wishing promt publication of the "pure ML-DSA in TLS" RFC,
I'm also in favour of the TLS WG publishing a BCP that marks those
codepoints as "MAY" or even "SHOULD NOT", with a detailed information
why depending on pure algorithms, until we know that at least one of them
is thoroughtly broken, may not be a good ieda.


Cheers,
S.

PS: It seems pretty ironic to me that ambiguities in NIST and NSA text
are turning out such a barrier to getting PQ stuff done when at the
same time they're some of the entities trying to (again IMO) rush a
pile of things here. (To be clear: for me, everything PQ except hybrid
KEMs is a thing for which we ought hasten much more slowly.)





--
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 TLS 1.2 Update for Long-term Support

[Yaron Sheffer]

Hi Peter, Just to put matters straight, the predecessor of RFC 9325, RFC 7525, was published in May 2015. But that doesn’t matter a whole lot now. My point was much broader though: the IETF is sending deployers a bunch of mixed messages, and this is on us as a community. RFC 9325 basically tells them: we prefer that you switch to TLS 1.3, but if you absolutely cannot do that, here’s how you can configure the existing TLS 1.2 and be secure (as of the time of publication). TLS-LTS sends a whole different message of course. And then the working group keeps nibbling at TLS 1.2 with documents like draft-ietf-tls-deprecate-obsolete-kex and the earlier “deprecating” documents. The KEX document does mention RFC 9325 at one point but does not say explicitly which of its requirements are new, making it hard for implementers to navigate our recommendations.  Thanks,    Yaron On 22/11/2024, 12:06, "Peter Gutmann"  wrote:Yaron Sheffer  writes: >Specifically, RFC 9325 [1] published a mere two years ago is not even>referenced in the draft, let alone a comparison made with these deployment>recommendations that were made by the very same IETF. (Yes you can hear my>frustration coming through). In defence of the -LTS draft, RFC 9325 postdates it by six years, so therewasn't anything to reference at the time.  I'm also not certain how muchoverlap there is between the two, for example 9325 contains quite a lot ofstuff (older TLS versions, compression, DTLS, fallback, RC4, NULL ciphersuites, RSA key transport, etc) that has no bearing on what's in -LTS whichmeans it could cause confusion if someone tries to apply it to things thatmostly don't exist in -LTS. Having said that, now that my attention has been drawn to it :-), I'd be happyto include a note along the lines of "further advice on secure use of TLS maybe found in RFC 9325", it would certainly fit in with what -LTS is trying toachieve. Peter.___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Andrew Campling]

On Fri, Nov 22, 2024 at 16:46 Watson Ladd 
mailto:watsonbl...@gmail.com>> wrote:



> How on earth would providing another incompatible set of suggestions help? No 
> matter what text was in there it would still raise the question of what 
> people should be doing.



Hi Watson
You may of course not believe that this is a problem or that it is not 
something that the working group needs to solve.  I wouldn’t suggest starting 
with “another incompatible set of suggestions” unless you believe that the 
previous efforts were not useful(?).

If you agree with the previous post from Yaron that there is a problem then it 
seems reasonable to come up with a proposal on how best to address the current 
lack of clarity.  One way to do that is to incorporate updated text into the 
TLS-LTS draft, and any others that touch on TLS 1.2, making sure that it 
communicates clearly to implementers and others the relative positions of TLS 
1.2, TLS-LTS and TLS 1.3 with reference RFC 9325 and any other relevant 
documents etc.  Using this consistently from now on ought to help.



There are other ways to address this problem if you agree that it needs to be 
addressed.





Andrew




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

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Watson Ladd]

On Fri, Nov 22, 2024, 9:01 AM Andrew Campling
 wrote:

> On Fri, Nov 22, 2024 at 16:46 Watson Ladd  wrote:
>
>
>
> > How on earth would providing another incompatible set of suggestions
> help? No matter what text was in there it would still raise the question of
> what people should be doing.
>
>
>
> Hi Watson
>
> You may of course not believe that this is a problem or that it is not
> something that the working group needs to solve.  I wouldn’t suggest
> starting with “another incompatible set of suggestions” unless you believe
> that the previous efforts were not useful(?).
>
>
>
> If you agree with the previous post from Yaron that there is a problem
> then it seems reasonable to come up with a proposal on how best to address
> the current lack of clarity.  One way to do that is to incorporate updated
> text into the TLS-LTS draft, and any others that touch on TLS 1.2, making
> sure that it communicates clearly to implementers and others the relative
> positions of TLS 1.2, TLS-LTS and TLS 1.3 with reference RFC 9325 and any
> other relevant documents etc.  Using this consistently from now on ought to
> help.
>
>
>
> There are other ways to address this problem if you agree that it needs to
> be addressed.
>

That presupposes the matter at hand namely adoption of TLS-LTS and that
it's a good idea.

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

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Andrew Campling]

On 22/11/2024, 13:37, Yaron Sheffer 
yaronf.i...@gmail.com wrote:
> My point was much broader though: the IETF is sending deployers a bunch
> of mixed messages, and this is on us as a community.
>
> RFC 9325 basically tells them: we prefer that you switch to TLS 1.3, but if
> you absolutely cannot do that, here’s how you can configure the existing
> TLS 1.2 and be secure (as of the time of publication).
>
> TLS-LTS sends a whole different message of course.
>
> And then the working group keeps nibbling at TLS 1.2 with documents like
> draft-ietf-tls-deprecate-obsolete-kex and the earlier “deprecating”
> documents. The KEX document does mention RFC 9325 at one point but
> does not say explicitly which of its requirements are new, making it hard
> for implementers to navigate our recommendations.


If the consensus view of the working group is that the existing communications 
have resulted in mixed messages and some confusion, the adoption of TLS LTS 
could provide a useful vehicle to address that whilst also dealing with the 
various technical points that Peter has already identified in his draft.  By 
expanding the introduction plus sections 3.7  and 4 (or by adding a new 
section), it should be possible to communicate clearly to implementers and 
others the relative positions of TLS 1.2, TLS-LTS and TLS 1.3 with reference 
RFC 9325 and any other relevant documents etc.

Andrew

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

[TLS] Re: Fwd: New Version Notification for draft-reddy-tls-composite-mldsa-00.txt

[Ilari Liusvaara]

On Fri, Nov 22, 2024 at 07:34:18PM +0530, tirumal reddy wrote:
> Thank you, Alicja, for the review. I agree with all your comments and have
> raised a PR https://github.com/tireddy2/composite-mldsa/pull/1 to address
> them.

I think it would be better to have a footnote for the two
SignatureScheme values that are not allowed in signature_algorithms than
adding a whole new column. The TLS ExtensionType Values already has such
footnote for non-standard behavior in where the ech_outer_extensions
extension can appear.

However, I do not think it is clear if clent is allowed to send the
values in signature_algorithms or not. And if not, how is the server to
handle the values appearing anyway? And the values are definitely not
allowed to appear in CertificateVerify, but this is not stated.

As reference, TLS 1.3 does allow PKCS#1 v1.5 signatures in
signature_algorithms, but not in CertificateVerify. And there are no
notes in the registry about that.




-Ilari

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