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

Re: [Cryptography] IPsec DH parameters, other flaws





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. 
_______________________________________________
The cryptography mailing list
cryptography AT metzdowd.com
https://www.metzdowd.com/mailman/listinfo/cryptography