Hi List,
I currently try to get some clarity about usage of DTLS 1.2.
One topic, which comes across, is the
(TLS) RFC5246 - 7.2.1. Closure Alerts:
> The client and the server must share knowledge that the connection is
ending in order to avoid a truncation attack.
AFAIK, the protection of th
Dear TLS working group,
We wanted to see if there is any further feedback on our draft "Hybrid key
exchange in TLS 1.3"
(https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/) and what steps
are required for it to advance further. We have not received any new feedback
from the workin
I personally do not find the proposed approach appealing (or even useful).
There are three possibilities.
a. Quantum computers capable of breaking crypto (QC) become practical *and*
NIST PQC winner(s) resist both quantum and classic attacks;
b. QC become practical, and NIST PQC candidates fail (
I just took a look. I didn't read the (large) appendices, though I appreciate
that they have value.
The draft is largely in good shape. I have a few minor concerns.
I don't think that you want to reserve the hybrid_private_use(0x2F00..0x2FFF)
range of values. There were specific reasons for
I've updated my version of the draft we discussed a while back. After time to
reflect, I was convinced by feedback from Benjamin Schwartz suggesting that the
more complicated bits of the proposal could be simplifed greatly. So I did
that.
Hopefully this is a little easier to comprehend, imple