<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><font size="+1">coming late to this party... but I'll bet the
permathread will be running for a decade.</font><br>
</p>
<div class="moz-cite-prefix">On 20/07/2020 09:06, Alfie John wrote:<br>
</div>
<blockquote type="cite"
cite="mid:DE531C55-2183-43F3-9190-C25E95E06C1E@alfie.wtf">
<pre class="moz-quote-pre" wrap="">On 19 Jul 2020, at 14:55, Phillip Hallam-Baker <a class="moz-txt-link-rfc2396E" href="mailto:phill@hallambaker.com"><phill@hallambaker.com></a> wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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)</pre>
</blockquote>
<p><br>
</p>
<p>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.<br>
</p>
<p>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.</p>
<p>The who has to be individuals / tight teams.<br>
</p>
<p><br>
</p>
<p>
</p>
<blockquote type="cite"
cite="mid:DE531C55-2183-43F3-9190-C25E95E06C1E@alfie.wtf">
<pre class="moz-quote-pre" wrap=""> - how would you manage the coordination differently (given the current way is prone to sabotage)</pre>
</blockquote>
<p><br>
</p>
<p>Now the how.<br>
</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.<br>
</p>
<p><br>
</p>
<p>iang</p>
<p>ps; See you in another decade.</p>
<br>
</body>
</html>