Previous Entry Share Next Entry
photo25

Dark Internet Mail Extensions (репост с комментарием)

TLDR: DIME, Dark Internet Mail Extensions - проект от автора Lavabit'a по реформированию емейла в сторону бОльшей безопасности. Страдает скрещиванием ежа с ужом.

Скопирую сюда коммент свой:

Инерция мышления - страшная штука.
Толковых улучшений там два: промежуточные сервера не видят имя получателя, только хост; и выработка ключей энд-юзеров. ВСЁ.
Совместимость с SMTP: с точки зрения оптимиста, это даст optimistic encryption; с точки зрения пессимиста, это даст downgrade-атаки :)
Дикое количество полей заголовков: потому что долбоебы, каждый раз X.509 получается

Я, правда, даже не уверен что надо опираться именно на DNSSEC, просто сейчас ничего лучше нету. Пути апгрейда у них, кстати, не прописаны.
А взлететь оно может именно из-за п.2.

Оригинал взят у slonik_v_domene в DIME вроде как родил полную спеку
https://darkmail.info/downloads/dark-internet-mail-environment-december-2014.pdf

Добрался до спеки. Посмотрел. Забавно то, что авторы не в состоянии выйти за ограничения собственного мирка текстовых протоколов и key=>value полей заголовков.

Это все очень печально. Предлагаемый стандарт откровенно плох. Это не кардинально новое слово в передаче почты, а 100500-е повторение старых идей.

Из очевидных претензий:
1. непонятно, почему протокол текстовый. Почему описание не в виде ASN.1? На дворе 2015 год, какой смысл в текстовых протоколах? Особенно есть учесть что оно всегда должно ходить over SSL.
2. зачем предлагать соместимость с (E)SMTP? Какой в этом глубокий смысл? Что это даст, кроме усложнения парзеров команд?
3. дикое количество полей заголовков. Зачем они в стандарте? Для чего там упоминания о валютах, структуре организации и прочей ненужной ерунде? Чтобы что?
4. Поля в UTF-8 с переводом строк CRLF смотрятся по меньшей мере странно.
5. DMAP - это вообще без комментариев.

В общем, если это начнут использовать, всем станет очень печально.

Мое мнение: протокол должен быть двоичным, с описанием в ASN.1. MIME версии 2.0 должен быть также двоичным, с описанием в ASN.1, с четким указанием размеров part-ов (например, как в BSON, хотя и там много кривизны). Заголовков должен быть минимум; единая кодировка - UTF-8, двоичные данные (аттачменты) передаются как двоичный поток, нигде не должно быть никакого эскейпинга и рекодировки.

Всё не относящееся к передаче именно писем должно быть выкинуто из протокола на мороз. Все даты следует передавать как unix timestamp + localtime чтобы избежать проблем с часовыми поясами и их сменой.

Еще одно обсуждение: https://www.facebook.com/permalink.php?story_fbid=421467708011496&id=100004448105790&pnref=story



This entry was originally posted at http://wizzard.dreamwidth.org/415733.html. It has comment count unavailable comments. Please comment there using OpenID.

  • 1
sab123 January 7th, 2015
Жаждование двоичных протоколов (или как минимум заголовков) показывает отсутствие мозга.

wizzard0 January 7th, 2015
> Жаждование двоичных протоколов (или как минимум заголовков) показывает отсутствие мозга.

С этим можно много спорить. XMPP вот текстовость протокола не спасла никак. А размеры заголовков в современном мире важны.

permea_kra January 7th, 2015
При всем моем, а в ssl и прочих шифропротоколах типично есть сжатие потока, что остроту проблемы избыточности текстового протокола снимает.


wizzard0 January 7th, 2015
Эй-эй. Я про заголовки говорил. SSL хендшейк из-за передачи бандла сертификатов сам по себе весит как пиздец, увы(

permea_kra January 7th, 2015
> SSL хендшейк

Типа, в мейлопротоколе часто случается хендшейк?

wizzard0 January 7th, 2015
Да.

1) Мобильное устройство проверяет почту (не, ну есть всякие IMAP IDLE, но это же пиздец)
2) Демон отправляет нотификацию о каком-то событии на почту

nponeccop January 7th, 2015
> есть всякие IMAP IDLE

тут надо вспомнить IPSec, который охуенный, с бинарностью,низким оверхедом и мобильностью (даже без учета mobike), но не взлетел.

NAT-T вариант работает по udp и технически реализуем на уровне приложения. Интересно, кто-нибудь пробовал?

wizzard0 January 7th, 2015
IPSec и SCTP не взлетели, потому что worse is better.

А, и я не согласен, что он охуенный. Он сложнее дебажится и сложнее настраивается на роутере за 30 баксов админом за 1 бакс в час, а это приговор.

nponeccop January 7th, 2015
IPSec предназначен для закрытия однотенантной централизованной сети на сетевом уровне. Не взлетел он потому, что это оказалось невостребовано.

Остальное, по большому счёту, попытки натянуть сову на глобус. Все эти tunnel mode, "настройки на роутере". А до роутера как, с голой жопой ходить? Мы же знаем™, что только энд-ту-энд спасёт мир. Все эти поползновения с IKEv2, black hole detection - это же форменное извращение первоначальной идеи, попытка применить его к туннелям.

В IPSec хорошо то, что он по сути connectionless - секьюрити устанавливается и держится "сама" независимо от "соединения". Вот это реально охуенно (в применении к почте - мы же её обсуждаем, верно?) - верхний уровень полностью изолирован от еботни с переподключениями, типичной для TCP with dynamic IP over NAT.

По сути, в спецификациях IPSec уже есть дизайн такого мегаустойчивого к разрывам и смене адресов протокола "закрытия" (обеспечения confidentiality & authenticity). Этот дизайн охуенен.

А для туннелей и тем более защиты уровня приложений айписек неюзабелен, да. Одно то что он сидит в ядре чего стоит. А это раздвоение на IKE-сервер и собственно эндпоинт? Ужас. Всё из-за того что нужно было другое.

permea_kra January 7th, 2015
>1) Мобильное устройство проверяет почту (не, ну есть всякие IMAP IDLE, но это же пиздец)
>2) Демон отправляет нотификацию о каком-то событии на почту

КМК, трафик емейла настолько мал в сравнении со всеми остальными его разновидностями, что бороться за его сокращение с точки зрения загрузки магистралей особого смысла нет. Там же, где реально необходимо экономить на копейках, скорее нужно выбрать другой протокол.

Более того, в силу обязательного шифрования накладные расходы на поддержание текстового протокола тоже не представляются, мнэ, значимыми.


Это не значит, что секьюрный протокол бинарной почты не нужен - нужен, но
1) Ниша у него не в области традиционного емейла, а мгновенный обмен сообщениями поверх тощих каналов (если не мгновенный, то проще периодически посылать пачками, делая накладные расходы на хэндшейки незначимыми)
2) реализовывать его нужно не поверх TLS/SSL, а втыкать свои доморощенные криптосредства (или использовать готовые, но не в виде отдельного слоя-протокола, а внедрять непосредственно в разрабатываемый). Но это, извините, задача совершенно иного уровня сложности и, боюсь, люди её не осилят.

Edited at 2015-01-07 03:28 pm (UTC)

wizzard0 January 7th, 2015
Короче, я понял что у нас разные юзкейсы. В моем мире уже давно 95% емейл-трафика генерируется роботами, время доставки очень важно, а по емейлу его гоняют только от того, что другого общепринятого протокола p2p-нотификаций нету.

Человеческую почту я бы и рад от этого отделить, но ведь не взлетит же.

permea_kra January 7th, 2015
> В моем мире уже давно 95% емейл-трафика генерируется роботами,

Не, ну это само собой, поскольку спама много. Но вот мне как-то неверится, что 95% трафика не предназначены для человека. 95% сообщений - охотно в это поверю, но трафика?

>Короче, я понял что у нас разные юзкейсы.

А что у вас за юзкейз-то?

wizzard0 January 7th, 2015
Почему "не предназначены для человека"? Вот вы коммент написали, я на него с мобильного ответил. Проверять почту раз в час?

> А что у вас за юзкейз-то?
Эээ, да тот же ЖЖ с комментами возьмем.

permea_kra January 7th, 2015
>Проверять почту раз в час?
Гм. Насколько мне известно, большая часть людей разгребает коммы пару раз в сутки. Поскольку и без того есть чем заняться.

А для ЖЖ, афаик, есть свой велосипед в виде ljtalks.

wizzard0 January 7th, 2015
> большая часть людей разгребает коммы пару раз в сутки. Поскольку и без того есть чем заняться.

Уведомления про то, что сервер упал - тоже?

> А для ЖЖ, афаик, есть свой велосипед в виде ljtalks.
Угу. 100500 этих велосипедов уже. Протокол хочется.
XMPP при этом тоже session-oriented и с шифрованием там всё столь же плохо.

permea_kra January 7th, 2015
>Уведомления про то, что сервер упал - тоже?
Доля таких уведомлений в общем потоке ничтожна.

> Протокол хочется.
Протокола недостаточно, нужна ж еще инфраструктура. А сейчас она есть разве что для СМС,

wizzard0 January 7th, 2015
Протокол даёт почву для открытой инфраструктуры.

СМС инфраструктура из-за закрытости и исторических наслоений стоит уж очень непропорционально дорого, как для своей функциональности...

daedmen January 7th, 2015
У меня например большая часть inbox'а автоматом разгребается, некоторые папки типа комментов в жж действительно пару раз в день потом разгребаю, всякие важные, типа того же нагиуса стараюсь ASAP, ну и оставшееся в inbox'e стараюсь тоже почти ASAP разгрести, так что у всех по разному может быть.

BTW, а чем ljtalks почты удобнее?

nponeccop January 7th, 2015
> большая часть людей разгребает коммы пару раз в сутки

да чего уж там, к боссу с флешкой зайти в соседний подъезд нынче не проблема

wizzard0 January 9th, 2015
Кстати да!

daedmen January 7th, 2015
А какие преимущества у текстовых кроме удобства дебага?

wizzard0 January 7th, 2015
Удобство (=скорость) развития на ранних этапах.

nponeccop January 7th, 2015
Парсинг пишется быстро в начале проекта, и потом о нём забывают, т.к. основные трудозатраты не в нём.
Затраты на парсинг зависят от сложности грамматики, а не от текстовости как таковой. Конкретный синтаксис при разработке протокола должен волновать в последнюю очередь.

На самом деле основное неудобство нетекстовых протоколов - это трудность абстрагирования на ретроградных и низкоуровневых сях.

Но тут надо понимать, что плоские name=value - это очень плохая идея, поскольку грамматика позволяет неконсистентные наборы полей (условно, content-type без mime-version). Если энфорсить инварианты грамматикой, а парсер синтезировать - то получается существенное снижение затрат на application-level валидацию, поскольку большая часть валидации происходит в коде, который пишется в начале проекта и в который потом не заглядывают.


Edited at 2015-01-07 03:11 pm (UTC)

wizzard0 January 7th, 2015
Эй, энфорсить консистентность полей - это означает повышать энтропию передаваемого пакета ("любой бинарный мусор что-нибудь правильное да значит" == энтропия 1.00), задача приятная, как и любая оптимизация, но является AI-complete, т.е. ей не помогут ни синтез, ни ADT, ни даже зависимые типы.

nponeccop January 7th, 2015
Имхо возражения не по существу вопроса. Невозможность точного решения не может быть критерием.

109 January 9th, 2015
а давйте хедэр сделаем джейсоном! :)

кстати, какой формат не позволяет неконсистентные наборы полей [сам по себе, без валидации]? мой ответ: никакой, всегда формат отдельно, валидация отдельно.

nponeccop January 9th, 2015
Да любой компилятор возьмите. Значительная часть валидации делается парсером. Преимущества - валидация грамматикой декларативна.

dmytrish January 7th, 2015
Они намного более самодокументированы. Если протокол простой и распространенный, то и бинарный сойдет, но если это что-то обширное и специфическое, лучше что-то, что можно хоть немного понять интуитивно.

wizzard0 January 7th, 2015
> самодокументированы
увидел что-то, написал недореализацию, потом она пошла в массы "эта либа меньше весит! она круче!!111", а потом все мучаются. спасибо.

dmytrish January 7th, 2015
Ну, я в протоколах вообще не гуру, просто для текстовых уже и так готова огромная куча юниксового инструментария, а для бинарных вечно какие-то велосипеды и кардинально новые™ решения.

Хотя я был бы не против ASN.1 как универсального бинарного протокола с универсальными удобными инструментами.

Касательно стандартов и недореализаций согласен, это зло, но я не вижу, чем бинарные протоколы лучше. Написать кривую и неполную реализацию можно и там, и там (сам когда-то в детстве немного реверсил формат 3ds, ужас еще тот).

wizzard0 January 7th, 2015
Для asn.1 инструменты весьма крутые есть. Только за них много денег обычно хотят. В опенсорсе есть хорошие компиляторы и пару простеньких визуализаторов, но не более того.

А так-то есть и IDE, и симуляторы, и всё такое. Но из расчета "бюджет внедрения 5М баксов, лишнюю десятку за тулзу отвалить не проблема"

nponeccop January 7th, 2015
ASN толстый очень. Ввиду отсутствия каких-либо стандартных альтернатив, можно грубо специфицировать бинарный протокол в EBNF

sporaw January 7th, 2015
php-исты смогут подтянуться ;)

daedmen January 7th, 2015
Га php и с бинарными протоколами проблем 0, для того же thrift отлично генерится из машиночитабельного формата вся обвязка кода, не руками же программировать.

sab123 January 7th, 2015
Это удобство проявляется постоянно. В первую очередь, для админов.

daedmen January 7th, 2015
Ну хз, каждый раз когда мне надо например TCP трафик посмотреть, его отлично wireshark показывает в хорошо читабельной форме, всё очень удобно - рекомендую.

nponeccop January 7th, 2015
Имхо надо догфудиться и действовать от референс-реализации (а лучше от трёх - на крестах, скалке и рубях), и выкидывать из стандарта всё, что приводит к неоправданному раздуванию или усложнению реализаций. Библиотеки не считать.

Вообще конечно ситуация с протоколами напоминает ситуацию с парсингом до изобретения BNF - каждый раз приходится лепить адхок вместо декларативного синтеза.

Даёшь протокольный yacc!

beldmit January 7th, 2015
Шетухин, конечно, крут, и особенно в части почты. Но security guys как минимум в двух рассылках, которые я читаю и где эта тема поднималась от ASN1 открещиваются со страшной силой.

wizzard0 January 7th, 2015
Ну, не asn1 единым. Есть же куча всяких бинарных JSON'ов, торрентовский bencode и т.д.

beldmit January 7th, 2015
Да. Но Шетухин почему-то требует ASN1. Наверное, чтобы парсер проще был.

nponeccop January 7th, 2015
Ну, всякие бинарные жсоны нестандартизированы. Из стандартного - только варианты BNF да ASN.1

ASN.1 говно и не нужен, но хипстерских аналогов у него (пока) нет. Разве что протобуферы какие-нибудь.

wizzard0 January 7th, 2015
Я пробовал использовать протобуфы, в итоге мне сильно не понравилось. В том числе то, как там "насильно" сделано версионирование.

nponeccop January 8th, 2015
Ну этим и отличаются стандартные вещи от нестандартных. У протобуфов даже база инсталляций за пределами гугла не такая большая. Интересно с thrift сравнить.

Вообще конечно идеальный вариант -- это умный benevolent dictator, но где таких взять

Комитеты тоже бывает такого надизайнят, хоть плачь

beldmit January 7th, 2015
Ну, там, где он и так есть, нехай будет. Но новые вещи на нём строить стрёмно.

  • 1
?

Log in

No account? Create an account