Hi! The WG last call for this I-D has ended. There were a couple of point
raised that need to be addressed, but the big issue was to merge this I-D with
draft-ietf-tls-keylogfile. I talked to the authors and they are all okay with
merging the two I-Ds and I talked to the RFC editor and they can
Hi,
I have reviewed the draft. I think it is ready for publication with some minor
changes. See my comments below.
>TLS 1.2 is in widespread use
This will not age well. I suggest removing widespead.
>TLS 1.3 enjoys robust
>security proofs and provides excellent security as-is.
as-is, TLS 1.3 do
Nit: second paragraph of section 3 starts with "While the industry is
waiting for NIST to finish standardization". That's not true anymore.
Otherwise it's good to go.
On Tue, Dec 3, 2024 at 10:28 PM Sean Turner wrote:
> This is the working group last call for TLS 1.2 is in Feature Freeze.
> Ple
>TLS 1.3 enjoys robust
>security proofs and provides excellent security as-is.
as-is, TLS 1.3 does not provide excellent security for long-term connections.
It removes essential features such as asymmetric rekeying and reauthentication.
Would changing it to “provides excellent security for many us
Looks good to me. Consider removing the Acknowledgements section, as it's
not really used.
Chris P.
On Wed, Dec 4, 2024 at 2:48 AM Bas Westerbaan wrote:
> Nit: second paragraph of section 3 starts with "While the industry is
> waiting for NIST to finish standardization". That's not true anymore
That would address your concern.
John
From: Salz, Rich
Date: Wednesday, 4 December 2024 at 15:21
To: John Mattsson , Sean Turner ,
TLS List
Subject: Re: [TLS] Re: Working Group Last Call for TLS 1.2 is in Feature Freeze
>TLS 1.3 enjoys robust
>security proofs and provides excellent security as
Talking about providing "excellent security" also will get out-of-date
and/or subjective once someone decides post-quantum, or any other 1.3-only
improvement, is the bar for "excellent". I would suggest just not having
the draft opine on such things when it doesn't need to.
We could just delete th
Hi David,
I want to support dropping support of plaintext acks in a bis document.
My focus with developing DTLS 1.3 is using DTLS-SRTP with a hybrid key
exchange. We do not have a ressource constrained environment to worry about. So
the initial implementation I do for OpenSSL is seeking to mini
Hi,
I have sympathy for the chairs. I do find this one a little frustrating,
although I agree.
I wrote pretty much the same thing, either directly or by quoting Ekr in a
few messages:
https://mailarchive.ietf.org/arch/msg/tls/_e_osuwApqE3jJcXiAxFMsXWdog/
https://mailarchive.ietf.org/arch/msg/tls
