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 хендшейк из-за передачи бандла сертификатов сам по себе весит как пиздец, увы(

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)

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

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

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

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. Наверное, чтобы парсер проще был.

  • 1
?

Log in

No account? Create an account