6 ms·

I can't say this trend surprises me. Years back I was an IETF meeting when people were already mentioning that the old saying "IP over everything, everything ov

by heipei 8y ago

I can't say this trend surprises me. Years back I was an IETF meeting when people were already mentioning that the old saying "IP over everything, everything over IP" was slowly being phase out for "HTTP over everything, everything over HTTP". The thing to realize here is how much middleboxes sit between a client and a server, boxes which are aware of higher layers than just IP. It's impossible today to deploy an Internet-wide layer-4 protocol other than TCP or UDP, and increasingly it will be harder and harder to deploy a truly universal L7 protocol but HTTP. That's my limited view of this issue, how things like IPv6 might affect it I have no idea.

Immortalin 8y ago
Building a protocol over HTTP has the added benefit of making security easy. HTTP+TLS has a lot more eyeballs than protocols on lower levels. Most protocols on layer 3 and below weren't designed with security as a priority. If you are building a domain specific protocol, it's a lot easier to build on top of one which already has a good security story backed by a triumvirate of internet unicorns, than trying to re-invent the whole public key dance on a homebrewed setup.
- paulddraper 8y ago
  SSL/TLS with other protocols have a lot of usage too. SFTP/FTPS, SSH, SMTPS, etc.
  - BTeam 8y ago
    SSH is a cryptographic network protocol that doesn't use SSL/TLS.
    - paulddraper 8y ago
      My bad. I should have said SSL/TLS/SSH. * SFTP/FTPS (SSH) * SSH (SSH) * SMTPS (SSL, TLS)
      - tzahola 8y ago
        Still wrong. FTPS is vanilla FTP over TLS.
        eganist 8y ago
        > Still wrong You know that thing that gives security practitioners a bad reputation with engineers? You're doing it. As opposed to this, why not something more like "it's not uncommon for these two to be confused, but FTPS is FTP over TLS and isn't interchangeable with SFTP"?
        meeeh 8y ago
        Because it's longer? Pardon my foreign mind, but I do not understand, why you are offended by a simple short and valid statement nor why you are differentiating between "security pratitioners" and "engineers".
  - tzahola 8y ago
    FTPS is FTP over TLS. However SSH and SFTP has nothing to do with TLS.
- tzahola 8y ago
  You only need TLS for that. HTTP adds nothing security-wise.
  - paulddraper 8y ago
    It adds Authorization, WWW-Authenticate, Proxy-Authentication, Proxy-Authenticate, Cache-Control, but those aren't even used that consistently.
- eftychis 8y ago
  As others have commented (adding a couple of notes): HTTP and HTTP/2 use TLS for security which is over TCP (reliable transfer requirement). Nothing more, nothing less. Sure layer 3 and below have different considerations (reliability). Layer 4 (say TCP) covers the end to end security. It would be nice if HTTP/2 added something security wise, as was discussed, but the committee was conservative. Thus I am not sold to this argument. The rich functionality of HTTP and multiplexing of HTTP/2 sound appealing (sections 3.1-3.4), if you are building an API. If not I would not rush to that conclusion. Why would I want to add the necessity for streaming if I am doing a over the network video compression and do not care about reliability or want to skip frames for instance? I guess it is IETFs job to standardize stuff so that is what they do -- for a hammer everything is a nail, right? P.S. I skimmed it, so perhaps it is worth a read, but nothing caught my eye really.
- geocar 8y ago
  > Building a protocol over HTTP has the added benefit of making security easy Not to take away from that, it's also very easy to get wrong as well. - Not doing CA verification check[1] - No alerts/monitoring of new certificates used by the IDP - No verification on certificate-transparency of new certificates used by the IDP - No online CRL checking If you do not do these things, then your application-on-HTTP is insecure. Remember that it's very easy to get a new certificate if you can break IP either by MITMing the server or by BGP takeover of some space near the CA. Both of these things have happened. If there's a way you can detect incorrect implementations, then blacklist them. For example, I use OAuth2 in my own systems, but I require clients retry (by randomly failing during onboarding) and implement fuzzing whereby the client_secret is invalidated if they accept an invalid certificate. [1]: http://web.archive.org/web/20120317165131/http://forum.developers.facebook.net/viewtopic.php?pid=258460 http://web.archive.org/web/20120317165131/http://forum.devel...
- tialaramex 8y ago
  Those eyeballs almost all belong to the Web Browser vendors who are almost exactly a proxy for the Operating System vendors, you mention them as three "unicorns", though it's hard to pick three, I have an easier time saying four, or maybe five. Specifically they are Google's Chrome (Android), Microsoft's IE/Edge (Windows), Apple's Safari (iOS/ macOS) leaving only Mozilla's Firefox (standing in for the Free Unixes). If there's a fifth it's Oracle, as custodians of Java. A tremendous weight ends up resting on the shoulders of these vendors, all of them based on the US West Coast, and it's not as though this a power _seized_ by them, it's more something everybody else shirked.
gsich 8y ago
It is possible. You just don't care about people that have shitty admins. It works for games (mostly UDP) and nobody complains, perhaps because people shouldn't be playing in the office.
bm1362 8y ago
Just curious, what do you think of QUIC? Seems like a layer 4 replacement, right?
- erkl 8y ago
  QUIC operates on top of UDP, which would make it layer 5.
  - paulddraper 8y ago
    QUIC is the transport layer (layer 4). > QUIC is an experimental transport layer network protocol [1] You can run layer 4 on top of layer 4. (Just as you could say, run TCP layer 4 on top of HTTP layer 7.) [1] https://en.wikipedia.org/wiki/QUIC https://en.wikipedia.org/wiki/QUIC
- heipei 8y ago
  The fact that Google chose to build QUIC on top of UDP rather than on top of IP directly shows that not even Google think it's possible to introduce any new Layer 4 protocol.

by heipei 8y ago

Immortalin 8y ago

Building a protocol over HTTP has the added benefit of making security easy. HTTP+TLS has a lot more eyeballs than protocols on lower levels. Most protocols on layer 3 and below weren't designed with security as a priority. If you are building a domain specific protocol, it's a lot easier to build on top of one which already has a good security story backed by a triumvirate of internet unicorns, than trying to re-invent the whole public key dance on a homebrewed setup.

paulddraper 8y ago
SSL/TLS with other protocols have a lot of usage too. SFTP/FTPS, SSH, SMTPS, etc.
- BTeam 8y ago
  SSH is a cryptographic network protocol that doesn't use SSL/TLS.
  - paulddraper 8y ago
    My bad. I should have said SSL/TLS/SSH. * SFTP/FTPS (SSH) * SSH (SSH) * SMTPS (SSL, TLS)
    - tzahola 8y ago
      Still wrong. FTPS is vanilla FTP over TLS.
      - eganist 8y ago
        > Still wrong You know that thing that gives security practitioners a bad reputation with engineers? You're doing it. As opposed to this, why not something more like "it's not uncommon for these two to be confused, but FTPS is FTP over TLS and isn't interchangeable with SFTP"?
        meeeh 8y ago
        Because it's longer? Pardon my foreign mind, but I do not understand, why you are offended by a simple short and valid statement nor why you are differentiating between "security pratitioners" and "engineers".
- tzahola 8y ago
  FTPS is FTP over TLS. However SSH and SFTP has nothing to do with TLS.
tzahola 8y ago
You only need TLS for that. HTTP adds nothing security-wise.
- paulddraper 8y ago
  It adds Authorization, WWW-Authenticate, Proxy-Authentication, Proxy-Authenticate, Cache-Control, but those aren't even used that consistently.
eftychis 8y ago
As others have commented (adding a couple of notes): HTTP and HTTP/2 use TLS for security which is over TCP (reliable transfer requirement). Nothing more, nothing less. Sure layer 3 and below have different considerations (reliability). Layer 4 (say TCP) covers the end to end security. It would be nice if HTTP/2 added something security wise, as was discussed, but the committee was conservative. Thus I am not sold to this argument. The rich functionality of HTTP and multiplexing of HTTP/2 sound appealing (sections 3.1-3.4), if you are building an API. If not I would not rush to that conclusion. Why would I want to add the necessity for streaming if I am doing a over the network video compression and do not care about reliability or want to skip frames for instance? I guess it is IETFs job to standardize stuff so that is what they do -- for a hammer everything is a nail, right? P.S. I skimmed it, so perhaps it is worth a read, but nothing caught my eye really.
geocar 8y ago
> Building a protocol over HTTP has the added benefit of making security easy Not to take away from that, it's also very easy to get wrong as well. - Not doing CA verification check[1] - No alerts/monitoring of new certificates used by the IDP - No verification on certificate-transparency of new certificates used by the IDP - No online CRL checking If you do not do these things, then your application-on-HTTP is insecure. Remember that it's very easy to get a new certificate if you can break IP either by MITMing the server or by BGP takeover of some space near the CA. Both of these things have happened. If there's a way you can detect incorrect implementations, then blacklist them. For example, I use OAuth2 in my own systems, but I require clients retry (by randomly failing during onboarding) and implement fuzzing whereby the client_secret is invalidated if they accept an invalid certificate. [1]: http://web.archive.org/web/20120317165131/http://forum.developers.facebook.net/viewtopic.php?pid=258460 http://web.archive.org/web/20120317165131/http://forum.devel...
tialaramex 8y ago
Those eyeballs almost all belong to the Web Browser vendors who are almost exactly a proxy for the Operating System vendors, you mention them as three "unicorns", though it's hard to pick three, I have an easier time saying four, or maybe five. Specifically they are Google's Chrome (Android), Microsoft's IE/Edge (Windows), Apple's Safari (iOS/ macOS) leaving only Mozilla's Firefox (standing in for the Free Unixes). If there's a fifth it's Oracle, as custodians of Java. A tremendous weight ends up resting on the shoulders of these vendors, all of them based on the US West Coast, and it's not as though this a power _seized_ by them, it's more something everybody else shirked.

gsich 8y ago

It is possible. You just don't care about people that have shitty admins. It works for games (mostly UDP) and nobody complains, perhaps because people shouldn't be playing in the office.

bm1362 8y ago

Just curious, what do you think of QUIC? Seems like a layer 4 replacement, right?

erkl 8y ago
QUIC operates on top of UDP, which would make it layer 5.
- paulddraper 8y ago
  QUIC is the transport layer (layer 4). > QUIC is an experimental transport layer network protocol [1] You can run layer 4 on top of layer 4. (Just as you could say, run TCP layer 4 on top of HTTP layer 7.) [1] https://en.wikipedia.org/wiki/QUIC https://en.wikipedia.org/wiki/QUIC
heipei 8y ago
The fact that Google chose to build QUIC on top of UDP rather than on top of IP directly shows that not even Google think it's possible to introduce any new Layer 4 protocol.