4 ms·

How disconcerting. >If this takes off, it would remove one of the last few holdouts of non-HTTP application specific protocols. IRC and FTP come to mind, but

How disconcerting. >If this takes off, it would remove one of the last few holdouts of non-HTTP application specific protocols. IRC and FTP come to mind, but yes. It's as if email's being attacked at all angles, lately. >While using HTTP is not necessarily a bad thing, it's certainly an interesting indication of how application developers prefer convention based protocol definitions (JSON over HTTP) instead of having a strictly defined protocol over a duplex stream (IMAP over TCP). Using HTTP is a bad thing, I think, because it's a complex protocol and it's entirely unnecessary; JSON is a poor, ad-hoc format that isn't optimal for parsing. I don't believe developers ''prefer'' any of this so much as it's being forced on them. You can really only define things rigidly if you want to make much in the way of guarantees. Any system held together by conventions can have those conventions violated and this is a harrowing sign of things to come.

jolmg 7y ago
> IRC and FTP come to mind They're niche now, though. HTTP and email protocols are probably the only open protocols that almost everyone uses. There's ssh, but it's also arguably niche in comparison.
groovybits 7y ago
> IRC and FTP IRC and FTP have widely used secure counterparts. Meanwhile, STARTTLS did not gain the traction that everyone hoped it would. Edit: Additionally, we have secure working replacement protocols for IRC and FTP (such as Matrix and SSH/SCP).
- jolmg 7y ago
  STARTTLS is vulnerable to man-in-the-middle and encryption downgrade attacks. Using a distinct port that only allows these application protocols over SSL/TLS (e.g. SMTPS and IMAPS) is better. It's also widely accepted. I don't think there's many that are still running unencrypted SMTP or IMAP connections.
  - jcranmer 7y ago
    Opportunistic STARTTLS is vulnerable to encryption downgrade attacks. Good email clients don't implement opportunistic STARTTLS, they implement mandatory STARTTLS or TLS, with plaintext being either an option that's heavily discouraged by UX flow, enabled only for tests, or not available at all.
    - jolmg 7y ago
      Sure, but a user has no way of knowing if their mail client does opportunistic STARTTLS or not. It's not something the average user can test, and not something mail clients would typically feel the need to mention. On the other hand, you can tell people that good practice is to use ports 993 for IMAP and 465 for SMTP and they'll be good to go, that using any other ports opens them to potential attack.
satyanash 7y ago
> You can really only define things rigidly if you want to make much in the way of guarantees. Any system held together by conventions can have those conventions violated and this is a harrowing sign of things to come. The problem with this is that most new protocols (or APIs as they're popularly known now) are built by startups aiming for rapid growth. Writing an RFC for the underlying protocol of the newfangled dating app you're building is counterproductive if you don't know the company will exist six months later.
kitsunesoba 7y ago
I’ll take JSON over text any day. Email parsing can break in so many subtle and/or obscure ways that I have trouble putting any confidence in the parsing code I’ve written… it’s quite frustrating, especially since there aren’t well tested mail parsing libraries for every language/platform to fall back on. On the other hand, JSON parsing errors are reasonably bounded and there’s well-tested highly optimized libraries for it for practically every supported platform and language. No it’s not perfect or even well suited for the task, but it’s still an improvement.
- the8472 7y ago
  If it has to be a loose bag of value data format you could at least CBOR instead of JSON.
  - y4mi 7y ago
    >> there’s well-tested highly optimized libraries for it (JSON) for practically every supported platform and language. > If it has to be a loose bag of value data format you could at least CBOR instead of JSON. so you think there are well tested, good performing CBOR parsing libraries in basically all languages?
    - kahlonel 7y ago
      Yes there are: https://cbor.io/impls.html https://cbor.io/impls.html
mey 7y ago
A minimal HTTP 1.1 client is rather straight forward. It's not asynchronous, doesn't use any non-printable characters, not fixed width, US-ASCII, etc. Adding encryption and compression complicates things, but that is true of all protocols.

jolmg 7y ago

> IRC and FTP come to mind They're niche now, though. HTTP and email protocols are probably the only open protocols that almost everyone uses. There's ssh, but it's also arguably niche in comparison.

groovybits 7y ago

> IRC and FTP IRC and FTP have widely used secure counterparts. Meanwhile, STARTTLS did not gain the traction that everyone hoped it would. Edit: Additionally, we have secure working replacement protocols for IRC and FTP (such as Matrix and SSH/SCP).

jolmg 7y ago
STARTTLS is vulnerable to man-in-the-middle and encryption downgrade attacks. Using a distinct port that only allows these application protocols over SSL/TLS (e.g. SMTPS and IMAPS) is better. It's also widely accepted. I don't think there's many that are still running unencrypted SMTP or IMAP connections.
- jcranmer 7y ago
  Opportunistic STARTTLS is vulnerable to encryption downgrade attacks. Good email clients don't implement opportunistic STARTTLS, they implement mandatory STARTTLS or TLS, with plaintext being either an option that's heavily discouraged by UX flow, enabled only for tests, or not available at all.
  - jolmg 7y ago
    Sure, but a user has no way of knowing if their mail client does opportunistic STARTTLS or not. It's not something the average user can test, and not something mail clients would typically feel the need to mention. On the other hand, you can tell people that good practice is to use ports 993 for IMAP and 465 for SMTP and they'll be good to go, that using any other ports opens them to potential attack.

satyanash 7y ago

> You can really only define things rigidly if you want to make much in the way of guarantees. Any system held together by conventions can have those conventions violated and this is a harrowing sign of things to come. The problem with this is that most new protocols (or APIs as they're popularly known now) are built by startups aiming for rapid growth. Writing an RFC for the underlying protocol of the newfangled dating app you're building is counterproductive if you don't know the company will exist six months later.

kitsunesoba 7y ago

I’ll take JSON over text any day. Email parsing can break in so many subtle and/or obscure ways that I have trouble putting any confidence in the parsing code I’ve written… it’s quite frustrating, especially since there aren’t well tested mail parsing libraries for every language/platform to fall back on. On the other hand, JSON parsing errors are reasonably bounded and there’s well-tested highly optimized libraries for it for practically every supported platform and language. No it’s not perfect or even well suited for the task, but it’s still an improvement.

the8472 7y ago
If it has to be a loose bag of value data format you could at least CBOR instead of JSON.
- y4mi 7y ago
  >> there’s well-tested highly optimized libraries for it (JSON) for practically every supported platform and language. > If it has to be a loose bag of value data format you could at least CBOR instead of JSON. so you think there are well tested, good performing CBOR parsing libraries in basically all languages?
  - kahlonel 7y ago
    Yes there are: https://cbor.io/impls.html https://cbor.io/impls.html

mey 7y ago

A minimal HTTP 1.1 client is rather straight forward. It's not asynchronous, doesn't use any non-printable characters, not fixed width, US-ASCII, etc. Adding encryption and compression complicates things, but that is true of all protocols.