Just a quick comment on draft-ietf-tls-keylogfile-00.txt.
It would be better to give a short Applicability Statement in the abstract as
did in Section 1.1:
"This format is intended for use in systems where TLS only protects test data.
While the access that this information provides to TLS connections can be
useful for diagnosing problems while developing systems, this mechanism MUST
NOT be used in a production system."
When I read the abstract, I was thinking: 1) The SSLKEYLOGFILE file should be
strictly protected. Otherwise, the security of TLS will be compromised. 2) Why
is such a file needed?
- Guilin
-----Original Message-----
From: TLS <tls-boun...@ietf.org> On Behalf Of tls-requ...@ietf.org
Sent: Saturday, 24 February 2024 10:41 pm
To: tls@ietf.org
Subject: TLS Digest, Vol 235, Issue 17
Send TLS mailing list submissions to
tls@ietf.org
To subscribe or unsubscribe via the World Wide Web, visit
https://www.ietf.org/mailman/listinfo/tls
or, via email, send a message with subject or body 'help' to
tls-requ...@ietf.org
You can reach the person managing the list at
tls-ow...@ietf.org
When replying, please edit your Subject line so it is more specific than "Re:
Contents of TLS digest..."
Today's Topics:
1. Re: I-D Action: draft-ietf-tls-keylogfile-00.txt (John Mattsson)
2. Re: New Liaison Statement, "Quantum Safe Cryptographic
Protocol Inventory" (John Mattsson)
----------------------------------------------------------------------
Message: 1
Date: Sat, 24 Feb 2024 13:47:21 +0000
From: John Mattsson <john.matts...@ericsson.com>
To: Martin Thomson <m...@lowentropy.net>, "Salz, Rich"
<rsalz=40akamai....@dmarc.ietf.org>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] I-D Action: draft-ietf-tls-keylogfile-00.txt
Message-ID:
<gvxpr07mb9678685468bc43a63ecbfbce89...@gvxpr07mb9678.eurprd07.prod.outlook.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
I just reviwed the whole document and I agree it is ready for WGLC. I just
found very minor things.
I think it would be good to inform the reader that with knowledge of
"_TRAFFIC_SECRET_N", all subsequent application data traffic secret can be
derived without any additional information. Otherwise reader might think they
need to log all the traffic secrets.
I made a PR while revieing. Use as you wish.
https://github.com/tlswg/sslkeylogfile/pull/6
Cheers,
John Preu? Mattsson
From: TLS <tls-boun...@ietf.org> on behalf of Martin Thomson
<m...@lowentropy.net>
Date: Monday, 29 January 2024 at 22:59
To: Salz, Rich <rsalz=40akamai....@dmarc.ietf.org>, tls@ietf.org <tls@ietf.org>
Subject: Re: [TLS] I-D Action: draft-ietf-tls-keylogfile-00.txt On Fri, Jan 26,
2024, at 02:36, Salz, Rich wrote:
>> Internet-Draft draft-ietf-tls-keylogfile-00.txt is now available. It
>> is a work item of the Transport Layer Security (TLS) WG of the IETF.
>
> I assume this just documents the current format and that therefore
> existing implementations (OpenSSL and Wireshark come to mind) just work.
That's exactly right. I'm not looking to add features.
> If that assumption is true, this seems ready for WGLC.
I agree.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://mailarchive.ietf.org/arch/browse/tls/attachments/20240224/3a676593/attachment.htm>
------------------------------
Message: 2
Date: Sat, 24 Feb 2024 14:40:32 +0000
From: John Mattsson <john.matts...@ericsson.com>
To: "ip...@ietf.org" <ip...@ietf.org>, "sp...@ietf.org"
<sp...@ietf.org>, "p...@ietf.org" <p...@ietf.org>, "TLS@ietf.org"
<tls@ietf.org>, IRTF CFRG <c...@irtf.org>
Subject: Re: [TLS] New Liaison Statement, "Quantum Safe Cryptographic
Protocol Inventory"
Message-ID:
<gvxpr07mb9678a769864b5aa50b2f118d89...@gvxpr07mb9678.eurprd07.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
Hi,
Even if JOSE WG is not included in the recipients, I looked at this LS and TR
103 619 that the LS refer to. In addition to the requested information, I think
IETF should send ETSI CYBER comments on TR 103 619 that the LS is based on. My
suggestions:
---------------
IETF kindly suggests that ETSI CYBER makes the following updates/corrections in
the next revision of TR 103 619:
* IETF suggests that ETSI CYBER uses the established term Cryptanalytically
Relevant Quantum Computers (CRQCs). It is important that readers understand
that there is a huge difference between current quantum computers and CRQCs.
* IETF suggests that ETSI CYBER uses another term than ?classical
cryptography?. Quantum-resistant cryptography like ML-KEM and ML-DSA runs on
classical computers and code-based cryptography and hash-based cryptography was
invented in the late 1970s.
* As ETSI CYBER mentions that Quantum Key Distribution is not vulnerable to
attacks from CRQCs, ETSI CYBER should also mention that Quantum Key
Distribution is neither a practical nor a secure solution [1-2].
* IETF advice ETSI CYBER to update and correct the information regarding
symmetric cryptography. The idea that symmetric cryptography will be
practically affected by CRQCs is now seen as a misconception. The ?bits of
security? concept does not work with algorithms that are not parallelizable and
NIST is therefore transitioning to quantum-resistant security levels based on
symmetric algorithms where level 1 is equivalent with AES-128, level 2 is
SHA-256, etc. [3]. UK government assesses that ?symmetric algorithms with at
least 128-bit keys (such as AES) can continue to be used? [4]. While classical
supercomputers might be able to brute force AES-128 around the year 2090 [5-6],
a huge cluster of one billion CRQCs (according to one estimate costing one
billion USD each) would take a million years of uninterrupted calculation to
find a single AES-128 key. Algorithms with quadratic (?2) speedup like Grover?s
algorithm (which is proven to be optimal) will not provide any practical quan
tum advantage for breaking symmetric cryptography and likely not for any other
problems [7-8].
* The name of the X.509 field is ?Subject Public Key Info?, not ?Subject
Key Info?.
[1] ANSSI, BSI, Netherlands NCSA, Swedish NCSA, ?Position Paper on Quantum Key
Distribution?
https://cyber.gouv.fr/actualites/uses-and-limits-quantum-key-distribution
[2] NSA, ?Quantum Key Distribution (QKD) and Quantum Cryptography (QC)?
https://www.nsa.gov/Cybersecurity/Quantum-Key-Distribution-QKD-and-Quantum-Cryptography-QC/
[3] NIST, ?Comments Requested on Three Draft FIPS for Post-Quantum Cryptography?
https://csrc.nist.gov/news/2023/three-draft-fips-for-post-quantum-cryptography
[4] UK NCSC, ?Next steps in preparing for post-quantum cryptography?
https://www.ncsc.gov.uk/whitepaper/next-steps-preparing-for-post-quantum-cryptography
[5] CRYPTEC, ?Cryptographic Technology Evaluation Committee Activity Report?
https://www.cryptrec.go.jp/symposium/2023_cryptrec-eval.pdf
[6] CRYPTEC, ?Japan CRYPTREC Activities on PQC?
https://events.btq.li/Japan_CRYPTREC_Activities_on_PQC_Shiho_Moriai.pdf
[7] Hoefler, H?ner, Troyer, ?Disentangling Hype from Practicality: On
Realistically Achieving Quantum Advantage?
https://cacm.acm.org/magazines/2023/5/272276-disentangling-hype-from-practicality-on-realistically-achieving-quantum-advantage/fulltext
[8] Babbush, McClean, Newman, Gidney, Boixo, Neven, ?Focus beyond Quadratic
Speedups for Error-Corrected Quantum Advantage?
https://arxiv.org/pdf/2011.04149.pdf
---------------
Cheers,
John Preu? Mattsson
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://mailarchive.ietf.org/arch/browse/tls/attachments/20240224/4e271a88/attachment.htm>
------------------------------
Subject: Digest Footer
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
------------------------------
End of TLS Digest, Vol 235, Issue 17
************************************
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
