QUIC is now RFC 9000 • Hacker News Board

Re: QUIC is now RFC 9000

#201

Post by bcoates » Fri, May 28, 2021, 7:37 PM UTC

cbsmith wrote: post #186

bcoates wrote: post #183

Earlier quoted context omitted.

Nah, middleboxes are garbage. The security features they claim to offer are all snakeoil checkbox-ware, businesses and government agencies/state-controlled telcos use them because they have a nominal compliance obligation to do a thing so they buy a middlebox that they can wave their arms at when the auditor/commissar comes around. Generalized "optimizer" middleboxes don't actually work in real world performance test…

I'll give you that a lot of the middlebox problems are because they are garbage, however... Dismissing the security features they are ostensibly delivering snakeoil is more than a bit unfair. There is a legit security context where absolute transparency & auditability is the right design objective, rather than absolute privacy. I'd argue the greatest failing we've seen with the evolution of TLS was the failure to rec…

The reality is that cellular data, satellite data, rogue WiFi, and fixed wireless all exist.

Transparency and Auditability are real, but they absolutely require endpoint security.

If you don't control the endpoint you don't know if it has an LTE chip, and if you do control the endpoint you don't care.

DPI security middleboxes for the enterprise are always and without exception snakeoil and/or checkboxware.

Re: QUIC is now RFC 9000

#202

Post by ninepoints » Fri, May 28, 2021, 7:43 PM UTC

xanathar wrote: post #76

ninepoints wrote: post #69

I wish the QUIC design was datagram-first... so many client/server implementations don't implement the datagram extension properly because it's... well an extension, and for most applications, reliable sequencing should be eschewed in favor of client-side reassembly. IMO QUIC was far too influenced by the legacy of how HTTP works when there was an opportunity to leapfrog a generation of bad decisions.

> so many client/server implementations don't implement the datagram extension properly I'm genuinely interested in what aspects you think are (or were) not implemented properly. I wrote most of the implementation of quiche's datagram extension and, well, if there's something that can be improved, I'm all for it. (aside: I think the standard should've considered an option for datagrams to opt-out of congestion contro…

TBH I haven't looked at the quiche implementation specifically (not being as familiar with rust) so I should check that out.

The main issue I saw with other implementations were mainly of the performance/optimization variety. The "blessed path" were definitely connection streams and I was seeing throughput drops when experimenting with datagrams.

Re: QUIC is now RFC 9000

#203

Post by throw0101a » Fri, May 28, 2021, 8:57 PM UTC

tialaramex wrote: post #196

throwawaaarrgh wrote: post #163

Earlier quoted context omitted.

Ah, the old middleboxes excuse. Changing TCP would break the middleboxes, so instead we'll invent a brand new protocol which is (theoretically) ignored by the middleboxes. The idea being if you slip something in via UDP, nobody will notice, and then you encrypt it so the middleboxes give up on it. This assumes that lack of transparency is the only way forward. I'd argue that IP and TCP ossified not because of transpa…

You're arguing for the "smart network" approach. This approach already failed . Some HN readers might not even have been born when that happened. The dumb network won. Perhaps the smart network can be pulled off successfully, but it won't be by humans, and I don't see anybody else around here trying. The supposed "chilling effects" don't work out in practice. You will sometimes see people saying oh, China blocks TLS…

> The dumb network won.

If the network was actually dumb perhaps we wouldn't have as many issues with routers fiddling with TCP as the GP described.

If was really, really dumb perhaps we could have managed to deploy SCTP and DCCP.

I wonder how much NAT interferes with new protocols, and if 'simple' stateful inspection with IPv6 would (have) made thing easier.

Re: QUIC is now RFC 9000

#204

Post by [deleted] » Fri, May 28, 2021, 9:08 PM UTC

throwawaaarrgh wrote: post #164

jjoonathan wrote: post #152

Earlier quoted context omitted.

All cloud services. Personal computers and devices are not allowed to talk to each other on the internet. They are only allowed to talk to specially designated servers -- specially designated by virtue of having a public IPv4 and open port. Enforcement happens through liability: if you put data in a cloud service and the cloud service gets hacked, it's the cloud service's fault, but if you run a program on an open po…

NAT is literally the only thing stopping every single personal device in the world from being hacked. It may be a kludge, but it's the best kludge in all of technology. And what do you have against QoS? Would it be better if your VoIP calls stuttered every time you loaded a fat web page?

[deleted]

Re: QUIC is now RFC 9000

#205

Post by cbsmith » Fri, May 28, 2021, 9:11 PM UTC

tialaramex wrote: post #199

cbsmith wrote: post #186

Earlier quoted context omitted.

I'll give you that a lot of the middlebox problems are because they are garbage, however... Dismissing the security features they are ostensibly delivering snakeoil is more than a bit unfair. There is a legit security context where absolute transparency & auditability is the right design objective, rather than absolute privacy. I'd argue the greatest failing we've seen with the evolution of TLS was the failure to rec…

For TLS if you build a middlebox which obeys the protocol invariants (e.g. see RFC 8446 section 9.3) then you're golden. This isn't so hard, it's almost embarrassing that anybody needed these writing down, but evidently they did. This is true for QUIC too. Obey the invariants. You don't need to read all these complicated documents, just the invariants. Now of course there are obstacles. First doing this is expensive.…

Yes, yes, you must obey the invariants. The trick is in the consideration of the invariants.

The problem isn't the cost or the "confession", because those are already part of the context. The problem is that in the process it creates new security risks that needn't be there but for the choices made by TLS.

In particular, the lack of separation of concerns between protections from eavesdropping, tampering and forgery proves to be quite problematic for environments where forgery & tampering are a serious concern, but eavesdropping is the nature of the context. It's why you see proposals for ugly hacks of TLS like eTLS; it's doing more harm than good.

Re: QUIC is now RFC 9000

#206

Post by throw0101a » Fri, May 28, 2021, 9:18 PM UTC

throwawaaarrgh wrote: post #197

ikiris wrote: post #166

Earlier quoted context omitted.

No it isn't, that's basic stateful firewalling. NAT in no way provides security. At all.

The fact that a kid with a port scanner can't remotely connect to and exploit your printer is due to NAT not being able to route the traffic, whether you have a stateful firewall or not. The majority of internet-addressable devices in the world do not have firewalls. Hence, NAT keeps most devices safe from drive-by RCE. There are plenty of attacks to get around that, but by default , nothing else protects random devi…

> The majority of internet-addressable devices in the world do not have firewalls. Hence, NAT keeps most devices safe from drive-by RCE.

According to System Preferences, my Mac's firewall is currently turned off. Here are the current non-NATed IPv6 addresses on it:

   $ ifconfig en1 | grep inet6 | grep -v fe80
 inet6 2607:f2c0:93c7:fe00:144f:b9a3:bcd4:ef6 prefixlen 64 autoconf secured 
 inet6 2607:f2c0:93c7:fe00:e04c:f356:f2:b9e2 prefixlen 64 autoconf temporary

You should be able to ping(6). Can you connect to tcp/22? If not, it shows that my router's stateful packet inspection (SPI) works even when NAT isn't present.

* http://www.ipv6scanner.com/cgi-bin/main.py

The results of an nmap of one of those address from the system itself:

    PORT     STATE SERVICE REASON
    22/tcp   open  ssh     syn-ack
    111/tcp  open  rpcbind syn-ack
    1022/tcp open  exp2    syn-ack
    2049/tcp open  nfs     syn-ack

If you have a device doing NAT, then that device is already doing SPI, and so the NAT part is redundant. It is the SPI that gives you the security.

Re: QUIC is now RFC 9000

#207

Post by cbsmith » Fri, May 28, 2021, 9:19 PM UTC

bcoates wrote: post #201

cbsmith wrote: post #186

Earlier quoted context omitted.

I'll give you that a lot of the middlebox problems are because they are garbage, however... Dismissing the security features they are ostensibly delivering snakeoil is more than a bit unfair. There is a legit security context where absolute transparency & auditability is the right design objective, rather than absolute privacy. I'd argue the greatest failing we've seen with the evolution of TLS was the failure to rec…

The reality is that cellular data, satellite data, rogue WiFi, and fixed wireless all exist. Transparency and Auditability are real, but they absolutely require endpoint security. If you don't control the endpoint you don't know if it has an LTE chip, and if you do control the endpoint you don't care. DPI security middleboxes for the enterprise are always and without exception snakeoil and/or checkboxware.

> DPI security middleboxes for the enterprise are always and without exception snakeoil and/or checkboxware.

If you don't care that your broker may be selling you down the river, or whether information is being leaked to an intelligence operative, that's a fair assessment. Unfortunately, much as we might wish otherwise, there can be conflict between privacy solutions and security solutions. The trick is to find a way to service both without compromising either.

Re: QUIC is now RFC 9000

#208

Post by tialaramex » Fri, May 28, 2021, 10:07 PM UTC

cbsmith wrote: post #205

tialaramex wrote: post #199

Earlier quoted context omitted.

For TLS if you build a middlebox which obeys the protocol invariants (e.g. see RFC 8446 section 9.3) then you're golden. This isn't so hard, it's almost embarrassing that anybody needed these writing down, but evidently they did. This is true for QUIC too. Obey the invariants. You don't need to read all these complicated documents, just the invariants. Now of course there are obstacles. First doing this is expensive.…

Yes, yes, you must obey the invariants. The trick is in the consideration of the invariants. The problem isn't the cost or the "confession", because those are already part of the context. The problem is that in the process it creates new security risks that needn't be there but for the choices made by TLS. In particular, the lack of separation of concerns between protections from eavesdropping, tampering and forgery…

Sure, in terms of raw features it looks like being able to uncouple the integrity verification would enable a client to choose to say "You can see what I'm doing, but you can't tamper with it". There are researchers who would like to do that, and last I looked the TLS working group invited them to turn that into an actual draft.

But it's essential in practice to remember that overwhelmingly the environment people are interested in is the Web, and on the Web those aren't actually different things again, in practice.

For example, suppose you're OK with me eavesdropping your Amazon purchases. You're buying a Lego robot for your daughter's birthday, you work for the investment bank, it's nice that we even let you do that from work and clearly we can't just let you do whatever you want with no oversight or you might rob us blind. We have a hypothetical TLS 1.4 which lets you opt in to this eavesdropping but nothing else, and you've done exactly this.

We eavesdrop your purchase, we were prevented from tampering with it. But, this is the Web. The eavesdropped TLS session contains a secret cookie value, which identifies you to Amazon. We can use this to impersonate you and do whatever we want, just as if we were able to tamper with your TLS session. The apparently more limited permissions are a mirage.

Re: QUIC is now RFC 9000

#209

Post by tialaramex » Fri, May 28, 2021, 10:21 PM UTC

KirillPanov wrote: post #185

tialaramex wrote: post #112

Earlier quoted context omitted.

For example, gQUIC has its own custom encryption "QUIC crypto" while as you will see in these RFCs the final IETF QUIC design uses the existing TLS 1.3 (existing now, it didn't exist when Google made gQUIC) for encryption. Or at a philosophical level, gQUIC is an HTTP replacement, it doesn't do anything else except a better HTTP, so it doesn't need to care about any features you might want for, say, SMTP or IMAP or I…

Thanks for the reply! It's coming back now; I definitely remember reading some early drafts and thinking "boy it's sad this is just HTTP 3.0-rc1". I always liked SCTP; I'm glad IETF-QUIC has moved back towards being (sort of) SCTP-over-UDP as well as a better HTTP. On the encryption front I don't remember reading about a non-TLS version (I probably missed it). I'm kinda sad that got dropped. TLS is just crazy complic…

I don't buy the theory that the Web PKI or some equivalent is "unnecessary for non-Web things". If anything I think there have been a few places where there's a nasty security gap because somebody didn't just stuff the Web PKI in there, even though it wasn't necessarily a perfect fit, because what we got instead was nothing ie no security.

An example of that first: Does your phone try to connect to SomeBrand WiFi networks? How does it know if this is a "real" SomeBrand WiFi network? It doesn't. In some scenarios this means you leak valid credentials for the "real" SomeBrand to bad guys. In most cases you at least leak identity information. That's not great news. If the WiFi network was named example.com the WiFi AP could of course present a certificate for example.com, leveraging the Web PKI.

Now, there are people who want to do QUIC without TLS, mostly what they want to do is NOISE. Like this: https://www.cryptologie.net/article/467/quic-noise-nquic/ But again, I think something like SSH is the exception and the Web PKI is more applicable to most uses for QUIC.

Re: QUIC is now RFC 9000

#210

Post by cbsmith » Fri, May 28, 2021, 10:39 PM UTC

tialaramex wrote: post #208

cbsmith wrote: post #205

Earlier quoted context omitted.

Yes, yes, you must obey the invariants. The trick is in the consideration of the invariants. The problem isn't the cost or the "confession", because those are already part of the context. The problem is that in the process it creates new security risks that needn't be there but for the choices made by TLS. In particular, the lack of separation of concerns between protections from eavesdropping, tampering and forgery…

Sure, in terms of raw features it looks like being able to uncouple the integrity verification would enable a client to choose to say "You can see what I'm doing, but you can't tamper with it". There are researchers who would like to do that, and last I looked the TLS working group invited them to turn that into an actual draft. But it's essential in practice to remember that overwhelmingly the environment people are…

> But it's essential in practice to remember that overwhelmingly the environment people are interested in is the Web, and on the Web those aren't actually different things again, in practice.

If the problem is the web, then the problem should be addressed by the web, not TLS.

...and of course, part of the problem is that we've conflated nearly everything to the "web", so thinking that the web is somehow removed from this problem is a mistake.

> We eavesdrop your purchase, we were prevented from tampering with it. But, this is the Web. The eavesdropped TLS session contains a secret cookie value, which identifies you to Amazon. We can use this to impersonate you and do whatever we want, just as if we were able to tamper with your TLS session. The apparently more limited permissions are a mirage.

Yup, that's a legit problem, though I'd argue it actually further reinforces my point. This is a good example of a problem that stems from conflating multiple security concerns, rather than addressing them as separate concerns.

If there's an acknowledgement that your authenticated & tamper proof session is fully exposed to eaves dropping, then you start using the authentication mechanism itself to identify people or you develop an additional identification mechanism that is resilient to replay attacks (both of which are entirely possible) or people just inherently become aware of the reality that buying stuff on Amazon from an eavesdropping environment means that they will be impersonated on Amazon. What you don't do is think a "secret cookie value" is a secret when it so clearly is not.