[Cryptography] IPsec DH parameters, other flaws

[Christian Huitema]

On 11/17/2020 4:35 PM, Peter Gutmann wrote:
> Christian Huitema <huitema at huitema.net> writes:
>
>> Consider that despite lots of investment, a quarter of a century after being
>> standardized IPv6 only carries maybe 30 to 50% of the Internet traffic.
>> Wholesale replacement may happen if some radical new technology comes along,
>> maybe quantum networking if it turns out to be practical. But failing that,
>> the best that can happen is a series of small updates.
> In particular, IPv6 solves a very real problem that affects a lot of the
> world, the exhaustion of IPv4 address space (and even then it's usually easier
> to keep kludging around it with NAT than to switch to IPv6).  QUIC just solves
> the problem of efficient content delivery for Google, which no-one but Google
> cares about.

Really? Facebook and Ali-Baba are already sending a bunch of their
traffic over Quic, so it is not just Google. In fact, a sizeable
fraction of the Internet traffic runs over Quic already. Most browsers
already support Quic -- Chromium of course, but also Mozilla and Safari.
There are implemention of Quic on server platforms like Apache, NGinx,
or Litespeed, on VPNs like Akamai, Fastly or Cloudflare, and I am
missing a few. (see:
https://github.com/quicwg/base-drafts/wiki/Implementations).

> If we can't get people to adopt IPv6, why would anyone care about QUIC?  And
> more generally, why would anyone care about any next-big-thing when they've
> already indicated that they prefer to keep extending what's worked in the past
> indefinitely because it's less painful than moving to the next-big-thing?

Quic is really an encrypted transport, solving the vulnerabilities
caused by TCP's clear-text header. Encrypting everything reduces
interference by network based attackers and other middle-boxes, and
allows for much simpler upgrade paths than TCP. Quic is also in many
ways cleaner than TCP, largely because it uses 64 bit packet numbers and
because it cleanly separates packet control from content control. For
example, it is much easier to implement error correction or congestion
control correctly with Quic than with TCP. That does not mean
applications that work well with TCP will rush to migrate to Quic --
that would be silly. But it does make a lot of sense for new
applications. Not to mention that lots of application run on top of HTTP
already, and they easily get QUIC/HTTP3 support.

-- Christian Huitema




>
> Drifting back to security, a lot of the world values stability over the next
> big thing.  I worked on a standard a while back which has a discussion on how
> to keep a system that's been compromised by an attacker running, because the
> only thing worse, far far worse, than having a running system co-managed by an
> attacker is having a non-running system.  So you deal with it by adding
> compensating controls and move on.
>
> Peter.
>