<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>On 11/16/2020 12:57 AM, Stephan Neuhaus wrote:<br>
</p>
<blockquote type="cite"
cite="mid:38ab060d-2ce8-bba7-d10f-d65c3ccd577c@zhaw.ch"><br>
<br>
On 11/14/20 1:17 AM, iang wrote:
<br>
<blockquote type="cite" style="color: #000000;">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.
<br>
</blockquote>
<br>
The killer to this approach will be, I suggest, interoperability.
<br>
<br>
The nice thing about symmetric crypto is that everyone agrees that
there is just one basic building block, the block cipher[1], that
from an interop perspective only has two design parameters: block
size and key size. Compare that with, say, a protocol that does
all the things that TCP does (which was one thing the OP wanted to
replace). There are dozens of design parameters, and there will
even be dozens of mutually incompatible <b class="moz-txt-star"><span
class="moz-txt-tag">*</span>sets<span class="moz-txt-tag">*</span></b>
of design parameters, depending on your architecture.
<br>
<br>
Also, if you want interoperability, you have to get the vendors on
board. With block ciphers, we know that you can't really roll your
own. With network protocols, there are many different, viable
designs that are not interoperable. Vendors can, and, before the
Internet took over, did, roll their own network protocols.
<br>
<br>
So let's say that NIST organises a competition and "TCPng" wins.
So what? Why on Earth should anyone implement that thing when it
cannot give them an edge? (I realise that this is an argument from
incredulity, so I'd be happy to hear counterarguments.)
</blockquote>
<p><br>
</p>
<p>Do you mean something like QUIC, which does all of TCP and embeds
TLS, plus HTTP3, which subsumes HTTP2?</p>
<p>-- Christian Huitema<br>
</p>
</body>
</html>