[Cryptography] IPsec DH parameters, other flaws

[Natanael]

Den ons 18 nov. 2020 01:15jrzx via cryptography <cryptography at metzdowd.com>
skrev:

> > On 11/14/20 1:17 AM, iang wrote:
> >> 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.
>
> On 2020-11-16 18:57, Stephan Neuhaus wrote:
> > [...]> 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.)
>
> Presumably because TCPng would give them an edge.
>
> TCP was designed in more trusting times, when the name system consisted of
> a widely shared hosts file, and everyone trusted everyone.
>
> Over the years people have piled warts on top of TCP and warts on top of
> warts to fix one problem after another, and every fix results in additional
> round trips
>
> Thus "Cloudfare is checking your browser, you will be redirected shortly"
>
> Every additional round trip before a web page comes up results in a
> significant loss of viewers.
>
> TCP is a major problem, which is slowing down the internet. DDOS
> protection and the certificate mess are warts growing on top of warts.
>
> If TCPng fixes those warts, you get more views.
>
> TCPng needs to reply with a proof of work request when a client requests a
> connection, as the second phase of the four phase handshake, where the work
> demanded goes up as the server load increases, thus fixing the horrors of
> DDOS protection.
>
> Key agreement needs to be part of the TCPng handshake, rather than a layer
> on top, to reduce round tripping.
>
> The name system needs to be integrated with the key system, so that you
> get the key when when you get the network address associated with the name,
> and the key/name pairing needs to be blockchain secured, so you don't have
> one thousand certificate authorities each with the authority to mount a man
> in the middle attack.
>

Making the proof of work a required part of the network protocol is likely
to cause trouble for low energy devices.

There's a few options, in particular "Privacy Pass" fits in here (designed
for the same purpose, also supported by Cloudflare). It's basically an
anonymized token by some issuer that will allow you to avoid captchas and
other bot & DDoS protection mechanisms on sites which trust the issuer.

https://blog.cloudflare.com/cloudflare-supports-privacy-pass/amp/

Your client device would first need to get issued a privacy pass ticket
(this is where you may want to integrate proof of work, or solving
captchas, or authenticating by other means to "earn" a ticket). Low energy
devices (like your smartwatch) could have a ticket relayed to it by another
of your devices in case the service it connects to requires proof of work
or similar.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20201118/0b119e25/attachment.htm>