Live data from Hacker News

Internet protocols are changing

blog.apnic.net

101–110 of 138 posts

Re: Internet protocols are changing

#101
post #32

Earlier quoted context omitted.

Authentication mostly. The lack of which is the major reason why the majority of us are still typing passwords into boxes in the browser and send them over the Internet in contradiction to best practices. Doing away with that would potentially solve a lot of problems, like phishing, but also replace cookies. Meaning it would be much harder to track users across the Internet threatening not only the revenue of major p…

There's already a protocol for that[0], just almost nobody's using it. Which is a real shame, because with a cleaner UX and more adoption it could be a serious win. [0] http://webid.info/

Mozilla tried with Persona (née "BrowserID"), which had similar goals. It didn't go anywhere, even with Mozilla's support behind it.

Re: Internet protocols are changing

#102
post #15

Earlier quoted context omitted.

Not sure who "The powers that be" are, but anyone can propose and contribute to IETF standards. They are called "Request for Comment" for a reason.

Almost positively that answer is Google. Notice they are behind multiple of the new protocols here (HTTP/2 and QUIC), and are used as an example how bundling DOH with an existing major player can prevent blocking DNS. Google is effectively the actual determiner of Internet standards. As the article notes, Google implemented QUIC on their servers and their browsers, and therefore, 7% of Internet traffic is already QUI…

I'm very much torn on this phenomenon, and it depends on an org like Google being more or less benevolent when pushing new protocols and tech.

Designing a new protocol to be used at internet scale is really hard. Having the ability to test that on a significant amount of traffic before refining and standardizing is a huge advantage that few groups on the planet are able to make use of. From the IETF's perspective, I would look skeptically upon a new standard that someone dreamed up but had little to no practical real-world data to show how it behaves in practice.

But I also want them to avoid ramming standards down the IETF's throat. If, after due consideration, the IETF says "no" to a new standard, I want Google to stand down and abandon it. If the IETF thinks it's a good idea and is willing to work with Google to iron out issues and standardize in a public manner, then that's the ideal outcome.

Re: Internet protocols are changing

#103
post #36

Earlier quoted context omitted.

SCTP is a superior protocol, but it isn't implemented in many routers or firewalls. As long as Comcast / Verizon routers don't support it, no one will use it. It may be built on top of IP, but TCP / UDP levels are important for NAT and such. Too few people use DMZ and other features of routers / firewalls. Its way easier to just put up with TCP / UDP issues to stay compatible with most home setups.

Which is frankly horrifying considering the reference implementation was released in FreeBSD 7. That really ought to scare people from purchasing any of those routers/firewalls that don’t support it.

It's not a matter of time in the wild, it's a matter of adoption and cost priorities. Until the past several years, most SoHo routers were super constrained wrt CPU, memory, and ROM, so adding support for a new transport layer protocol would involve an unacceptable cost increase in what has rapidly turned into a race-to-the-bottom commodity industry.

So you end up with a chicken-and-egg problem: router manufacturers aren't going to add support for it unless there's sufficient demand, and there can't be sufficient demand because very few people can use and rely on it.

Re: Internet protocols are changing

#104
post #100
post #55

Earlier quoted context omitted.

Can I? On Android, apps now can decide if they want to accept user-installed CAs, or not. So if an app is hostile (say, all the Google apps), then I have no way to intercept their traffic anymore.

You can patch the app using apktool/smali or even use JTM[0], but I prefer just blocking their traffic using iptables. [0] - https://github.com/Fuzion24/JustTrustMe

That also invalidates some SafetyNet verification, unless I abuse the new dex/apk signature verification vulnerability.

Either the user controls the program, or the program controls the user.

Re: Internet protocols are changing

#106
> Finally, we are in the midst of a shift towards more use of encryption on the Internet, first spurred by Edward Snowden’s revelations in 2015.

Personally, I'd say it was first spurred by Firesheep back in 2010, but the idea of encrypting all websites, even content-only websites may have been Snowden related.

Re: Internet protocols are changing

#107
I'm really struck by how hostile to enterprise security these proposals are. Yes, I know that the security folks will adapt (they'll have to), but it still feels like there's a lot of baby+bathwater throwing going on.

DNS over HTTP is a prime example: blocking outbound DNS for all but a few resolvers, and monitoring the hell out of the traffic on those resolvers is a big win for enterprise networks. What the RFC calls hostile "spoofing" of DNS responses enterprise defenders call "sinkholing" of malicious domains. Rather than trying to add a layer of validation to DNS to provide the end user with assurance that the DNS request they got really is the name they asked for (and, in theory, allow the enterprise to add their own key to sign sinkhole answers) instead DOH just throws the whole thing out...basically telling enterprise defenders "fuck your security controls, we hate Comcast too much to allow anyone to rewrite DNS answers."

"Fuck your security controls, we hate Comcast" is, I think, a bad philosophy for internet-wide protocols. (That's basically what the TLS 1.3 argument boils down to also...and that's a shame.)

Re: Internet protocols are changing

#108
post #69
post #67

Earlier quoted context omitted.

You can decide to install the app or not. And you can put your CA into the system CA store if you have root. (You can make an Android image, so technically the requirement is unlocked - unlockable - bootloader.)

Unlocking the bootloader makes the device permanently fail the strictest SafetyNet category. Apps can and will refuse to run in that situation. Modifying /system will make every SafetyNet check fail, as result Netflix, Snapchat, Google Play Movies, and most banking apps will refuse to run. I can decide to install the app or not? How do I go about replacing Google's system apps with my own, without preventing above me…

Then don't buy it. Or support efforts like Librem (and LineageOS and Magisk).

http://www.androidpolice.com/2017/07/16/safetynet-can-detect...

You can walk into your bank and access the services. Or call them. Or use their browser based service, right?

Google and a lot of developers made the choice to restrict user freedom for more security.

I don't agree with it, but it's what it is. A trade off.

Of course, you can sign your own images and put the CA into the recovery DB and relock the bootloader on reasonable devices. ( https://mjg59.dreamwidth.org/31765.html )

Or at least you used to be able to.

Re: Internet protocols are changing

#109
post #95
post #50

Earlier quoted context omitted.

This is an improvement --- it was dumb of SCTP to try to claim a top-level IP protocol for this --- but only marginally, since lots of firewalls won't pass traffic on random UDP ports either.

Why was that dumb of SCTP? What should it have done instead?

Used a UDP port. Making new IP protocols is literally what UDP is for.

Re: Internet protocols are changing

#110
post #97
post #30

Earlier quoted context omitted.

Not the OP, but omitting support for SRV records in HTTP/2 was a terrible missed opportunity, as I’ve written about here before: https://news.ycombinator.com/item?id=8404788 https://news.ycombinator.com/item?id=8550133 I quote myself: “ It really is no surprise that Google is not interested in this, since Google does not suffer from any of those problems which using SRV records for HTTP would solve. It’s only users w…

I would also like to see SRV record support in HTTP/2 but IIRC Mozilla did some telemetry tests and found out that a significant amount of DNS requests for SRV records failed for no reason (or probably for reasons mentioned in this submission). Unfortunately I can't find a source link for that claim right now.

I know of two rather large users of SRV records already: Minecraft servers and (the big one) Microsoft Office 365. I’m less than convinced that resolution of SRV records is that broken.
Post reply on HN