[TLS] Re: draft-connolly-tls-mlkem-key-agreement

[Loganaden Velvindron]

On Sat, 14 Dec 2024 at 12:00, Viktor Dukhovni  wrote:
>
> On Fri, Dec 13, 2024 at 08:24:24PM -0800, Joseph Salowey wrote:
>
> > You continue to violate list policy with unprofessional commentary on other
> > participants' motivations and repeatedly raising points that are out of
> > scope.  Please stop this behavior.  This is the last warning before we will
> > take action and temporarily ban you from the list; see BCP 94 [0].
> >
> > [0] https://datatracker.ietf.org/doc/html/rfc3934
>
> I personally find this threat excessive under the circumstances, however
> forceful, or insistent on being heard, Dan may be at times, history has
> shown that he is often enough ultimately proved right, years or decades
> later.  However "inconvenient", IMHO his voice should not be suppressed.
>
> If his strong view is that pure PQ KEMs (probably not just
> ML-KEM/Kyber), are too novel to be responsibly relied on without a
> classical fallback, then he should IMHO able to forcefully make that
> case.
>
I also think that this escalated quickly. I would suggest a peaceful resolution
is found off-list around beer, good food and a nice and quiet beach :-)

Maybe TLS WG needs to do an interim meeting in Mauritius to solve
thorny issues  :-)

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

[TLS] Weekly github digest (TLS Working Group Drafts)

[Repository Activity Summary Bot]

Pull requests
-
* tlswg/sslkeylogfile (+0/-2/💬1)
 1 pull requests received 1 new comments:
 - #17 ECH extensions added to the main SSLKEYLOGFILE spec (1 by yaroslavros)
   https://github.com/tlswg/sslkeylogfile/pull/17 


 2 pull requests merged:
 - ECH extensions added to the main SSLKEYLOGFILE spec
   https://github.com/tlswg/sslkeylogfile/pull/17 
 - Removing KeyUpdate section
   https://github.com/tlswg/sslkeylogfile/pull/18 


* tlswg/tls13-spec (+0/-0/💬1)
 1 pull requests received 1 new comments:
 - #1366 Appendix on RPK misbinding attacks (1 by danwing)
   https://github.com/tlswg/tls13-spec/pull/1366 



Repositories tracked by this digest:
---
* https://github.com/tlswg/certificate-compression
* https://github.com/tlswg/dnssec-chain-extension
* https://github.com/tlswg/draft-deprecate-obsolete-kex
* https://github.com/tlswg/draft-ietf-tls-cert-abridge
* https://github.com/tlswg/draft-ietf-tls-ctls
* https://github.com/tlswg/draft-ietf-tls-ecdhe-psk-aead
* https://github.com/tlswg/draft-ietf-tls-ech-keylogfile
* https://github.com/tlswg/draft-ietf-tls-esni
* https://github.com/tlswg/draft-ietf-tls-external-psk-importer
* https://github.com/tlswg/draft-ietf-tls-grease
* https://github.com/tlswg/draft-ietf-tls-iana-registry-updates
* https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate
* https://github.com/tlswg/draft-ietf-tls-semistatic-dh
* https://github.com/tlswg/draft-ietf-tls-svcb-ech
* https://github.com/tlswg/draft-ietf-tls-ticketrequest
* https://github.com/tlswg/draft-ietf-tls-tls13-vectors
* https://github.com/tlswg/dtls-conn-id
* https://github.com/tlswg/dtls-rrc
* https://github.com/tlswg/dtls13-spec
* https://github.com/tlswg/oldversions-deprecate
* https://github.com/tlswg/rfc4492bis
* https://github.com/tlswg/rfc8447bis
* https://github.com/tlswg/sniencryption
* https://github.com/tlswg/sslkeylogfile
* https://github.com/tlswg/sslv3-diediedie
* https://github.com/tlswg/super-jumbo-record-limit
* https://github.com/tlswg/tls13-spec
* https://github.com/tlswg/tls-exported-authenticator
* https://github.com/tlswg/tls-flags
* https://github.com/tlswg/tls-key-share-prediction
* https://github.com/tlswg/tls-key-update
* https://github.com/tlswg/tls-record-limit
* https://github.com/tlswg/tls-subcerts
* https://github.com/tlswg/tls12-frozen
* https://github.com/tlswg/tls13-pkcs1
* https://github.com/tlswg/tls13-rfc
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: draft-connolly-tls-mlkem-key-agreement

[Blumenthal, Uri - 0553 - MITLL]

D. J. Bernstein wrote:
> More recently, NSA's Dickie George is on video claiming that NSA generated 
> the Dual EC points randomly and that Dual EC is secure.

Do you have a link to the video? Such a comment is surprising as it is a very 
bad PR strategy. “No comment” is a far better strategy. 

This is what I found: https://www.youtube.com/watch?v=qq-LCyRp6bU 
 
IMHO, it’s quite an interesting talk. Dual EC_DRBG is discussed between 
time-marks 30:00 – 34:00. 

The last comment I saw was:

"With hindsight, NSA should have ceased supporting the Dual EC DRBG algorithm 
immediately after security researchers discovered the potential for a trapdoor. 
In truth, I can think of no better way to describe our failure to drop support 
for the Dual EC DRBG algorithm as anything other than regrettable."
https://www.ams.org/journals/notices/201502/rnoti-p165.pdf 
 

I didn’t dive into the EC_DRBG scandal (had more interesting things to deal 
with). But I seem to recall that NIST and ANSI standards allowed verifiable 
random point generation (from the publication you cited), so there was no need 
to use the NSA random points, unless you were building devices for NSA: 
During the development of the ANSI standard based on the NIST publication, 
members of X9F1 (the ANSI-approved working group responsible for cryptographic 
tools) raised concerns about the potential that elliptic curve points used as 
parameters for the Dual EC_DRBG could harbor a trapdoor secret known only to, 
and exploitable only by, the person who generated the points. As a result, the 
X9F1 committee expanded the standard to include verifiable random point 
generation. Since the NSA was using the algorithm at the time and had generated 
elliptic curve points for protecting Department of Defense users, the 
NSA-generated points were included in the standard. In other words, any 
implementation that used the NSA-generated points would be deemed compliant. 
Shortly thereafter, NIST negotiated with ANSI to use the ANSI Random Number 
Generation Standard as the basis for an NIST Random Number Generation Standard. 
ANSI also approved submitting a version of this standard to the ISO. 
I think it is good with increased participation from government agencies in the 
IETF. Suite B, CNSA 1.0, and ZTA are all very good recommendations from NSA, 
significantly surpassing what was typical in deployments at the time they were 
introduced. We would not be prepared for PQC if it was not for the NSA.
https://web.archive.org/web/20150831131731/https://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml
 


Concur 100%. IMHO, CNSA 2.0 is also pretty good – except that I’d rather see a 
DSA with smaller signature and public key sizes (e.g., like HAWK?). Well, maybe 
CNSA 2.x would include that. (And I’m not crazy about LMS/XMSS, but that’s me – 
I hate stateful signatures 😉). 







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: draft-connolly-tls-mlkem-key-agreement

[John Mattsson]

I would also be against a temporarily ban at this point, but hopefully the 
warning will help reduce unprofessional commentary and personal attacks in the 
future. Commentaries on other participants' motivations should not be forbidden 
in general, and I don't think they are according to any IETF policy.

- If someone wants to argue that participants paid by company X are defending 
the use of weak crypto for business reasons just because they have massive 
deployments of that weak cryptography, I think they should be allowed to.

- If someone wants to argue that professor Y is promoting his/hers/their 
algorithm for personal fame, I think they should be allowed to.

- If someone wants to argue that participants paid by SIGINT agency Z are 
intentionally weakening security, I think they should be allowed to.

One of my regrets from the Snowden discussions is not speaking up against the 
demands to remove Kevin Igoe as CFRG chair just because he represented NSA. 
While me and Kevin did not always get along, I did not see him doing anything 
in his role as CFRG chair that motivated the demands to remove him from the 
position. I think we should encourage that participants clearly show who they 
are representing. The idea that people are representing themselves in the IETF 
has nothing to do with reality and would never ever hold in court.

Instead of continuing this thread. Could we please just start adoption calls 
for both draft-connolly-tls-mlkem-key-agreement and 
draft-kwiatkowski-tls-ecdhe-mlkem. I cannot speak for other companies, but for 
Ericsson, migration to PQC is a top priority and we would very much want RFCs 
for quantum-resistant key exchange in TLS 1.3, DTLS 1.3, QUIC, EAP-TLS 1.3, 
DTLS-SRTP, etc. as soon as possible.

Cheers,
John

On 2024-12-14, 08:59, "Viktor Dukhovni"  wrote:
On Fri, Dec 13, 2024 at 08:24:24PM -0800, Joseph Salowey wrote:

> You continue to violate list policy with unprofessional commentary on other
> participants' motivations and repeatedly raising points that are out of
> scope.  Please stop this behavior.  This is the last warning before we will
> take action and temporarily ban you from the list; see BCP 94 [0].
>
> [0] https://datatracker.ietf.org/doc/html/rfc3934

I personally find this threat excessive under the circumstances, however
forceful, or insistent on being heard, Dan may be at times, history has
shown that he is often enough ultimately proved right, years or decades
later.  However "inconvenient", IMHO his voice should not be suppressed.

If his strong view is that pure PQ KEMs (probably not just
ML-KEM/Kyber), are too novel to be responsibly relied on without a
classical fallback, then he should IMHO able to forcefully make that
case.

If there is nevertheless a demonstrable plurality of reputable
cryptographers on record as saying that *pure* PQ KEMs are (despite
initial implementation bugs) strong enough to move towards deployment,
then Dan's view may not prevail, but I do not find his posts to be
beyond the pale.

There were also (with IIRC Dan instrumental in bringing these to light)
some early side-channel issues in AES, that AFAIK still apply to some
reference pure software AES implementations, and when used securely, AES
is hardware assisted, or slower if counter-measures are implemented.

The AES issues were unfortunate, and ideally would have been identified
prior to standardisation, but proved "fixable".  If we're in luck
that'll also be true with Kyber, but arguments for some caution don't
come across as unfounded.

--
Viktor.


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

[TLS] I-D Action: draft-ietf-tls-rfc9147bis-00.txt

[internet-drafts]

Internet-Draft draft-ietf-tls-rfc9147bis-00.txt is now available. It is a work
item of the Transport Layer Security (TLS) WG of the IETF.

   Title:   The Datagram Transport Layer Security (DTLS) Protocol Version 1.3
   Authors: Eric Rescorla
Hannes Tschofenig
Nagendra Modadugu
   Name:draft-ietf-tls-rfc9147bis-00.txt
   Pages:   69
   Dates:   2024-12-14

Abstract:

   This document specifies version 1.3 of the Datagram Transport Layer
   Security (DTLS) protocol.  DTLS 1.3 allows client/server applications
   to communicate over the Internet in a way that is designed to prevent
   eavesdropping, tampering, and message forgery.

   The DTLS 1.3 protocol is based on the Transport Layer Security (TLS)
   1.3 protocol and provides equivalent security guarantees with the
   exception of order protection / non-replayability.  Datagram
   semantics of the underlying transport are preserved by the DTLS
   protocol.

   This document obsoletes RFC 6347.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-rfc9147bis/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-tls-rfc9147bis-00.html

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


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

[TLS] Re: draft-connolly-tls-mlkem-key-agreement

[John Mattsson]

D. J. Bernstein wrote:
> More recently, NSA's Dickie George is on video claiming that NSA generated 
> the Dual EC points randomly and that Dual EC is secure.

Do you have a link to the video? Such a comment is surprising as it is a very 
bad PR strategy. “No comment” is a far better strategy. The last comment I saw 
was:

"With hindsight, NSA should have ceased supporting the Dual EC DRBG algorithm 
immediately after security researchers discovered the potential for a trapdoor. 
In truth, I can think of no better way to describe our failure to drop support 
for the Dual EC DRBG algorithm as anything other than regrettable."
https://www.ams.org/journals/notices/201502/rnoti-p165.pdf

Analysing Dual_EC_DRBG objectively, a backdoor is the only rational requirement 
that could have led to its design. In addation to having a backdoor, it is a 
really bad DRBG being both slow and non-uniform. It is also a fact that 
Dual_EC_DRBG is not secure as the backdoor was backdoored, enabling serious 
attacks by a hostile nation state on US critical infrastructure.
https://web.archive.org/web/20151222092252/https://rpw.sh/blog/2015/12/21/the-backdoored-backdoor/


D. J. Bernstein wrote:
> Yes, NSA has deep cryptographic expertise. This does _not_ mean that we 
> should be trusting NSA's recommendations. An internal NSA history book (which 
> NSA successfully kept secret for many years) shows NSA deciding to manipulate 
> public standards to make sure they were "weak enough" for NSA to break. See 
> https://blog.cr.yp.to/20220805-nsa.html for quotes and further examples.

I don’t know why you (and the IETF) are so obsessed with NSA, there are very 
good reasons to take recommendations from SIGINT with a grain of salt and force 
them to provide thorough motivation, but there are _many_ SIGINT agencies 
globally. Snowden publicly said that GCHQ is “worse” than NSA, and I have heard 
a person with a background in SIGINT stating that French SIGINT is the “worst”. 
Then we have very active SIGINT from a lot of other countries such as China, 
Russia, Iran, and North Korea, etc. According to Research Nester and Mordor 
Intelligence, North America only has 32% of the global SIGINT market share and 
Asia Pacific is the fastest growing market.
https://www.researchnester.com/reports/signals-intelligence-market/5134/market-share
https://www.mordorintelligence.com/industry-reports/signals-intelligence-sigint-market

I think it is good with increased participation from government agencies in the 
IETF. Suite B, CNSA 1.0, and ZTA are all very good recommendations from NSA, 
significantly surpassing what was typical in deployments at the time they were 
introduced. We would not be prepared for PQC if it was not for the NSA.
https://web.archive.org/web/20150831131731/https://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: [EXT] Re: draft-connolly-tls-mlkem-key-agreement

[Stephen Farrell]

Hiya,

On 15/12/2024 00:07, Blumenthal, Uri - 0553 - MITLL wrote:

Those who agree with BSI – let them use Hybrid KEM, as they have their reasons.
Those who agree with NSA – let them use pure ML-KEM, as they have their reasons 


FWIW, my opinion is that the IETF and the TLS WG ought (try) develop our
own consensus position on this and related topics.

Cheers,
S.







OpenPGP_signature.asc
Description: OpenPGP digital signature
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: [EXT] Re: draft-connolly-tls-mlkem-key-agreement

[Blumenthal, Uri - 0553 - MITLL]

. . . however forceful, or insistent on being heard, Dan may be at times, 
history has
shown that he is often enough ultimately proved right, years or decades
later. 

An arguable point. 

However "inconvenient", IMHO his voice should not be suppressed. 

Of course. 
However, there must be a limit, n’est c’est pas? 

If his strong view is that pure PQ KEMs (probably not just
ML-KEM/Kyber), are too novel to be responsibly relied on without a
classical fallback, then he should IMHO able to forcefully make that
case. 

And didn’t he “forcefully made that case” plenty of times already? 
How many times is it OK to “forcefully make that case”, until the person is 
told “we understand what you’re saying, please stop repeating yourself”? 
Shouldn’t once be enough – especially if the “case” is as “verbosely-presented” 
as this? 

By now I think everybody on this list, and plenty of folks outside, know that 
Dan is strongly against allowing pure ML-KEM “without a classical fallback”. 
Some cryptographers (including BSI and a few other European government 
agencies) agree with him, other cryptographers (including NSA, GCHQ, etc.) 
disagree. 

Those who agree with BSI – let them use Hybrid KEM, as they have their reasons. 
Those who agree with NSA – let them use pure ML-KEM, as they have their reasons 
(shockingly, disagreeing with Dan and a few other members here). 

I for one am strongly against reiterating the above ad nauseum. 







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: [EXT] Re: draft-connolly-tls-mlkem-key-agreement

[Blumenthal, Uri - 0553 - MITLL]

Stephen, I don’t think attempting to develop consensus in this case would be 
either useful or productive. 

It is obvious that pure PQ KEMs are the future, when CRQC becomes “more” real. 
Some respected cryptographers are convinced that it is the optimal solution for 
now as well. 
Some other respected cryptographers insist on combining PQ KEM with a classic 
one, at least until .

Both camps based their conclusions on solid reasoning (some of which I disagree 
with, but all of which I respect), and are well-aware of the arguments of the 
opposing group. Their positions are not of ignorance, and are extremely 
unlikely to change. 

Thus, I don’t think there’s a way to bring these two camps together, nor do I 
see a need for that. Let TLS offer both hybrid and pure KEMs. And be done with 
it. 
—
Regards,
Uri

Secure Resilient Systems and Technologies
MIT Lincoln Laboratory

> On Dec 14, 2024, at 19:29, Stephen Farrell  wrote:
> 
> Hiya,
> 
> On 15/12/2024 00:07, Blumenthal, Uri - 0553 - MITLL wrote:
>> Those who agree with BSI – let them use Hybrid KEM, as they have their 
>> reasons.
>> Those who agree with NSA – let them use pure ML-KEM, as they have their 
>> reasons
> 
> FWIW, my opinion is that the IETF and the TLS WG ought (try) develop our
> own consensus position on this and related topics.
> 
> Cheers,
> S.
> 
> 
> 
> 
> 
> 


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org