@djb sure like last round where people copy pasted your template and then later apologized and confirmed they didnβt know what they were talking about and had been mislead by your social media postings to act. *slow clap*
Paul Wouters πͺπΊπ¨π¦
@letoams@defcon.social
Aiven Security Architect
Former two term IETF Security Area Director, IESG
Opensource dev: libreswan, Fedora, etc (see github)
NIST SP800-77 Rev.1 author
RDRonline player
@djb note this exact strategy was attempted by the vendors who didnβt want TLS 1.3 to happen because ephemeral key exchanges were made mandatory in TLS 1.3 ruining their network monitoring capabilities. They sent lots of people to try and block TLS 1.3, but the attempts didnβt work.
The IETF has experience with people sending sockpuppets. It is sad to see you attempt a similar strategy.
@mikalai @djb @pluralistic @eff I am the owner of the crypto / TLS / IPsec security at our company running 200k Linux nodes across the world. Donβt you think those same concerns apply to me ?
@mikalai @pluralistic @eff
I am glad I convinced you that you have a single argument, abd that the other assumptions were just a distraction. Luckily, that argument has been extensively discussed at the list already over the course of two years.
Btw you should asap object to draft-ietf-ipsecme-ikev2-mlkem as it allows peers to decide at runtime whether to use pure mlkem or a hybrid.