[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Cryptography] IPsec DH parameters, other flaws

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.


ps; See you in another decade.

The cryptography mailing list
cryptography AT metzdowd.com