I am not in favor of adoption, but I could be convinced otherwise. Sorry as this may have been discussed in IETF-106, but are we that worried about the CPU cost of ECDSA or EdDSA that we are willing to have the server buffer/slow down client connections, generate the Merkle tree and the batch signature? Do we really pull the private key from a hardware module or remote location with every signature instead of keeping it in volatile memory in our application?
I find it hard to buy the problem statement based on the usecases I know of, and such a draft would require a lot of client upgrades and participation in order to have fruitful results. I am ready to buy the argument, if there is concrete data on actual usecases. Rgs, Panos -----Original Message----- From: TLS <[email protected]> On Behalf Of Sean Turner Sent: Thursday, November 21, 2019 1:57 AM To: TLS List <[email protected]> Subject: [TLS] Adoption call for draft-davidben-tls-batch-signing At IETF 106 there was support for adoption of "Batch Signing for TLS" [0] as a WG item. To confirm this on the list: if you believe that the TLS WG should not adopt this as a WG item, then please let the chairs know by posting a message to the TLS list by 2359 UTC 13 December 2019 (and say why). NOTE: : If the consensus is that this draft should be adopted as a WG item, then this will necessarily result in a WG rechartering discussions. We would have gotten to this rechartering discussion anyway now that DTLS 1.3 is progressing out of the WG. Thanks, Chris, Joe, and Sean [0] https://datatracker.ietf.org/doc/draft-davidben-tls-batch-signing/ _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
