Hi,
I submitted a new version of draft-mattsson-tls-psk-ke-dont-dont-dont. psk_ke
is likely the weakest part of TLS 1.3 and German BSI has already made a
deadline for its deprecation. It is long overdue to change the "Recommended"
value for psk_ke to "N".
This is a major update to earlier vers
Hi,
We feel that draft-ietf-lwig-security-protocol-comparison is getting quite
ready now that the included protocols are published or at least stable.
We would love to have more examples of cTLS. Are there any more examples
available? We currently included the example in the draft.
Review by p
Hi John,
just to mention, the CCM8 is also considered to be not recommended in
the future (see
https://mailarchive.ietf.org/arch/msg/core/WnRInwF-j0uZmLggFh37ySljnwE/).
Wouldn't it make more sense to use then CCM
instead (16 bytes tag length)?
I would appreciate, if the comparison DTLS vs. TLS m
Hi John,
I'm not sure, are there any new arguments for this since this discussion
https://mailarchive.ietf.org/arch/msg/tls/WoBwUCqEMcFhvIHN6neo5W4Urg4/
in 2020?
Maybe, if the new arguments are highlighted, the discussion gets this
time shorter.
"Malicious actors can get access to long-term ke
Hi Achim,
Thanks. Good suggestions.
Last time I looked at the process behind the suggested CCM8 deprecation it
seemed like nonsense (using a single-key limits to suggest rekeying which did
not improve security). I have not been following this topic during my parental
leave. I think I need to h
>discussion gets this time shorter.
Let’s hope so. I think quite a lot of things have happened since 2020. BSI
decision that psk_ke can only be used until 2026, as well as a lot more
discussion of exfiltration attacks and zero trust principles. I hope the
working group can have a vote.
>Are the
Thanks Martin,
That seems much better. That is sufficient to me.
John
From: Martin Thomson
Date: Friday, 25 November 2022 at 08:21
To: John Mattsson , Peter Gutmann
, tls@ietf.org
Subject: Re: [TLS] sslkeylogfile
Thanks for the input John,
I agree on both points, the minor one and the substa
>This file doesn't have any extra information than what would be in a
>serialised
>session data used for session resumption. Something plenty of software
>already
>does.
I hope that is TLS 1.2 only. A TLS 1.3 implementation should not save any other
keys than resumption_master_secret or PSKs deri
