[Cryptography] IPsec DH parameters, other flaws

[iang]

coming late to this party... but I'll bet the permathread will be 
running for a decade.

On 20/07/2020 09:06, Alfie John wrote:
> On 19 Jul 2020, at 14:55, Phillip Hallam-Baker <phill at hallambaker.com> wrote:
>> There are a few individuals who seemed to be always there to pour poison in people's ears and to encourage them to 'stand their ground' when insisting on some asinine security requirement that makes the whole thing undeployable.
> All these war stories are great to finally be open and to a larger audience. Thanks everyone for adding their nuggets!
>
> So it's 2020 and we now know that there's a concerted effort to actively sabotage standards and implementations by many actors (including large budgets to sway people at all levels). Considering a clean slate for the whole stack - from TCP, IP, BGP, DNS, HTTP, etc and all the way to certificate infrastructure, application layer authentication, key management etc:
>
>    - how would you design the state of the art with security as one of its primary goals (i.e features and anti-features)


The key is to start asking who, not how. It's clear that the IETF/etc 
was setup to allow vendors to duke it out. Which opened the way for NSA 
& friends to futz up the security groups with targetted interventions. 
In short to bring the process to a standstill where their security was 
involved.

So the answer is to not do that - not do committees, working groups, and 
not rely on the good faith of participants. When there is an attacker 
who is prepared to outspend you and out-faith you, you have to change 
the process. In this context, the who cannot be a committee.

The who has to be individuals / tight teams.


>    - how would you manage the coordination differently (given the current way is prone to sabotage)


Now the how.

The NIST AES process showed one way: a knock down competition. Set the 
requirements, invite open submissions. Only one proposal wins. Set a 
schedule. Stick to it. Thunderdome. 30 proposals enter, 1 leaves.

Another way (also shown by NIST) is to contract someone credible to do 
the job. This was done with SHA2. To date, criticisms have been 
glancing, including as proven with SHA3 competition.

Ofc, one could criticise and say this can only be done with very simple 
designs that have nothing to do with hiding information. But actually, 
there are many people & teams who we could probably widespread trust to 
do a good job, given strong requirements.

The problem here might be how to stop nefarious agencies (NSA) from 
spiking the project while in gestation. Here, strong requirements, 
transparent schedule and many well known observers can help.


iang

ps; See you in another decade.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20201114/196da427/attachment.htm>