[TLS] (TLS) RFC5246 - 7.2.1. Closure Alerts - Applied to (DTLS) RFC 6347

2021-07-06 Thread Achim Kraus
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

[TLS] Advancing draft-ietf-tls-hybrid-design

2021-07-06 Thread Douglas Stebila
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

Re: [TLS] Advancing draft-ietf-tls-hybrid-design

2021-07-06 Thread Blumenthal, Uri - 0553 - MITLL
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 (

Re: [TLS] Advancing draft-ietf-tls-hybrid-design

2021-07-06 Thread Martin Thomson
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

[TLS] SNIP: simplified negotiation of incompatible protocols

2021-07-06 Thread Martin Thomson
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