I support rapid adoption, if only based on general principles, as elaborated below.
*** I have not studied the draft in detail, but I think that strongest-link security is important to allow, the sooner the better, for those that can afford it, I think the benefit is worth cost. I think that the how-to of strongest-link is straightforward enough to start working on it, and I trust the draft authors to have done a good job at it. Any subtleties or optimizations of strongest-link crypto can be perfected as they arise. I would also favor using both ECC and PQC, (a) _after_ NIST PQC is done, (b) _before_ a Shor-capable QC arrives. I’m hoping the time of (a) < (b), and therefore hybrid should be ready to roll out. I would also favor adding PQC support to TLS _before_ even NIST PQC is done, then just switching over to NIST choices at the time, even though this seems not to be the interpretation consensus opinion, e.g. CFRG opted to wait for NIST. I agree waiting for NIST is sensible, if one want the best PQC protection, but not to the point of delaying having any PQC protection, see next point. Getting details right is a known difficulty, with mistakes inevitable. Haste makes waste, sure, but delay is deadly, so let’s get to debugging the details right away. Bugs are a nuisance, but better than nothing. I realize that anybody worried about Shor-capable QC, can add a PQC out-of-band to official TLS, but I understand TLS to offer many benefits as security protocol, such that adding in PQC would create synergy (excuse my word choice here). I think “hybrid” is the wrong word. CFRG has adopted another document where “hybrid” means weakest-link. Can we choose clearer words? I like “compound”, but strongest-link, and defense-in-depth are clearer at the price of being longer. (I prefer hybrid to synergy, of course!) General arguments that attackers will find other system weaknesses than directly attacking crypto are valid, but these arguments already rely on good crypto, and are invalid as an excuse to use weaker crypto, to stop improving crypto. Best regards, Dan Brown BlackBerry From: TLS <tls-boun...@ietf.org> On Behalf Of Joseph Salowey Sent: Thursday, February 13, 2020 12:13 PM To: <tls@ietf.org> <tls@ietf.org> Subject: [TLS] Call for Adoption: draft-stebila-tls-hybrid-design The authors of "Hybrid Key Exchange" have asked for adoption of their draft as a WG item. Please state whether you support adoption of this draft as a WG item by posting a message to the TLS list by 2359 UTC 28 February 2020.. Please include any additional information that is helpful in understanding your position. NOTE: If the draft is adopted, the working group has change control over the draft and the timing of its progression. This means the document does not have to be perfect as the working group can and will make changes. Adopting the draft means the working group thinks the topic is a good idea and the draft is a good place to start the work. Thanks, Chris, Joe, and Sean [0] <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dstebila-2Dtls-2Dhybrid-2Ddesign_&d=DwMFaQ&c=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=qkpbVDRj7zlSRVql-UonsW647lYqnsrbXizKI6MgkEw&m=YGrWhrwPJMcluBHfaPE8h_pponmVeM1dfJFrLKO-Y2c&s=QH64ybNj9x2PM84z-J18Fb113WNyH8szhQxy-UzKDZc&e=> https://datatracker.ietf.org/doc/draft-stebila-tls-hybrid-design/ ---------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
