> Чтобы доставить поинту сообщение(не важно шифрованное или нет), нужно знать его координаты. Либо нужно расширить схему сети и сделать ее обязаловкой, а так же наконец-то начать использовать адреса -- тогда узнать, где поинт не сложно.

В принципе, адреса то у нас есть. Это имя ноды и номер поинта. В качестве примера, если сообщение адресовано <syscall,1> - то это netmail ко мне.

> Либо можно придумать скрытоэху, которая синкается всеми. В ней можно устроить e2e шифрование, например с GPG ключами. На ноде хранить сообщения от туда по-минимуму. Но тут нужно развитие клиентов. Чтобы они генерили ключи. Ключи можно синкать по надам в SKS.

Вот этот вариант по сути и предложил vit, а я думаю в сторону возможности работы без gpg. В приниципе, мы уже повторяемся. Значит, все идеи уже кончились?

> Просто в этом случае, ЛЮБОЙ сможет прочитать эти сообщения. В моей схеме (которая мне тоже до конца не нравится пока) -- только доверенная нода.

Еще бы послушать мнение Андрея.

Peter> поинт -> нода поинта -> целевая нода
Peter> То есть, нет никакой сложной маршрутизации, сообщение от ноды поинта сразу коннектится к целевой ноде и отправляет сообщение на нее. Я считаю это нормальным, так как нода по определению доступна в сети интернет, и нет смысла делать какую то хитрую маршрутизацию

Это противоречит самым основам IDEC (да и ii), а именно:

1. Интернет не должен быть единственным транспортом
2. Никто, абсолютно никто не обязан быть доступным 24/7 (это самое важное правило, на котором построена наша сеть)
3. Один и тот же человек сегодня может подключаться к одной станции, а завтра - к другой

Peter> есть специальная скрытая эха netmail. При ее фетчинге -- клиент получает только те сообщения, которые адресованы именно ему. В качестве адреса -- имя ноды и номер поинта (то, что у нас есть). Авторицация по authstr. Но вот как сообщение доходит до ноды, отдельный разговор. Итак, первый способ.

Peter> 1) Сообщение распостроняется путем фетчинга как и сейчас. При этом, нужно решить 2 проблемы

> a) фетчить netmail могут только те ноды, которым мы доверяем;
> b) сообщение в netmail должны убиваться после доставки;

Мне нравится идея с "убиваться после доставки". Но предлагаю реализовать её немного по-другому.

Опишу целиком.

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

1. Есть публичная эха netmail, которую может фетчить каждый. Все сообщения в netmail зашифрованы.
2. Все ноды открыто забирают друг у друга netmail и смотрят на поле получателя. Если получатель числится на ноде, то сообщение сохраняется там навечно (ну или на очень долгое время вроде 3 месяцев). Иначе (если нода ведёт транзит, т.е. такого поинта на ней нет) - держится около 5-10 дней, на усмотрение сисопа.
3. Шифрование всё end-to-end, сервера в нём не участвуют. Смог расшифровать - сообщение твоё. Не расшифровал - значит не твоё.

Мой вариант уже совместим с любыми текущими реализациями. Просто до этого я не задумывался про то, что они могут быть "сгораемыми".

> Это противоречит самым основам IDEC (да и ii), а именно:

Согласен, этот вариант тоже мне не нравится.

> Мне нравится идея с "убиваться после доставки". Но предлагаю реализовать её немного по-другому.

Твой вариант с шифрованием мне понятен, более того, я сам был ее сторонником. Сейчас мне кажется, это не должно быть частью стандарта (неотъемлемой частью). Может быть, я не прав. Нужно мнение остальных. Кроме того, для кого-то может возникнуть вопрос о прогонки через ноду шифрованного трафика. Если же фича шифрования -- дополнительная. На усмотрение абонентов, то кажется -- так лучше.

Моя идея на фетчинге, если ее упростить/уточнить.

Фетч для абонента (избранные сообщения netmail). Эха доступна для фетчинга по authstr, при этом забираются только те сообщения, которые адресованы этому абоненту.

Фетч для ноды (вся почта netmail). Доверенный фетчинг всей эхи нодой, но степень доверия строится на ЭЦП. На худой конец, тоже по authstr.

Все узлы, которые не обслуживают данного поинта, стирают netmail сообщения спустя n дней.
Узел, обслуживающий поинта -- не стирает. Или стирает после забора поинтом. Короче соответствует твоему 2 пункту.

Что мне не нравится. Не нравится 2 разных типа фетичнга. Клиент (забирает свое). И нода (забирает весь нетмыл).

С шифрованием, конечно, частично все упрощается. Но по моему, все таки, делать его частью стандарта не очень...

Difrex> Но тут нужно развитие клиентов. Чтобы они генерили ключи. Ключи можно синкать по надам в SKS.

Ключи может нагенерировать сисоп и просто выдавать пару поинту вместе с authstr при регистрации.

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

Difrex> На самом деле никому ключ передавать не нужно. Можно воспользоваться тем же pgp.mit.edu. Либо, чтобы сисоп поднял sks и грузить ключик туда. Это не сложно =)

Почесал репу и подумал, что всё-таки это хорошая идея.

> Адреса не уникальны.

В теории, мы можем потребовать уникальности. В любом случае, описанные атаки, не совсем атаки. Так как любая нода может забрать netmail если она доверена.
Доверенность подтверждается ЭЦП. Так что я не понял суть твоего примера до конца. Если я доверяю твоей ноде, и убеждаюсь с помощью ЭЦП в аутентичности твоих запросов, почему бы мне и не слить тебе netmail?

> Нас спасёт только шифрование

Вероятно, так и есть. :( Для меня, это выглядит скорее как отсутствие перспектив на netmail.

> На ноде должен быть доступ ко всем открытым ключам абонентов сети idec.

Хотя это вот, реальное ограничение. Но нода может выдавать по запросу public ключи своих поинтов, что возвращает нас к схеме "шифрования на клиентах". Не знаю, как то не идеально. :)

Peter> В любом случае, описанные атаки, не совсем атаки. Так как любая нода может забрать netmail если она доверена.

Если вдруг нода скомпрометирована, то она может вылавливать нетмейл чужих нод и вывешивать его публично.

Peter> Доверенность подтверждается ЭЦП. Так что я не понял суть твоего примера до конца. Если я доверяю твоей ноде, и убеждаюсь с помощью ЭЦП в аутентичности твоих запросов, почему бы мне и не слить тебе netmail?

Мы совершенно про разные вещи говорим. При схеме

                      abcde
                        |
нода1(from) > нода2 > нода3 > syscall (to)

нода 2 может организовывать атаку MITM, подменяя части сообщений. Например, подменив адрес получателя, она может добиться того, что нода3 отправит сообщение не получателю syscall, а левой ноде abcde. А если она подменит адрес отправителя, то может сама отлавливать чужую почту. Поэтому схемы без шифрования обречены на провал.

Возвращаясь к полю адреса, мы уже высказывали когда-то идею, что в поле адреса можно вписывать открытый ключ или ID этого ключа (неважно, для станции или для самого человека). При этом ЭЦП должна применяться не только для текста сообщения, но и для этого самого поля адреса, чтобы остальные ноды во время синхронизации не смогли подделать "обратный адрес" следования.

И теперь насчёт того, делать шифрование + ЭЦП на ноде или на клиенте.

1. На клиенте
+ не надо доверять сисопам
+ не надо сильно переделывать код станций
+ юзверь может получить свою почту с любой станции, с какой захочет
- надо совершенствовать клиенты
- нужен актуальный keystore для базы данных поинтов

2. На станции
+ не надо переделывать клиенты
+ реализация проще и легковеснее
- юзверь может получить почту только со своей станции
- поинт должен доверять своему "боссу"
- все ноды/юзвери должны знать, на какой станции живёт получатель, чтобы сообщение расшифровалось там, где это надо

Difrex> Мне кажется, что сначала, нужно решить проблему синхронизации поинтов.

Да ни к чему, как по мне.

Difrex> Чтобы доставить поинту сообщение(не важно шифрованное или нет), нужно знать его координаты. Либо нужно расширить схему сети и сделать ее обязаловкой, а так же наконец-то начать использовать адреса -- тогда узнать, где поинт не сложно.

Это было бы актуально при аутбаундах.

Difrex> Либо можно придумать скрытоэху, которая синкается всеми. В ней можно устроить e2e шифрование, например с GPG ключами. На ноде хранить сообщения от туда по-минимуму. Но тут нужно развитие клиентов. Чтобы они генерили ключи. Ключи можно синкать по надам в SKS.

Вот шифрование штука такая. С одной стороны дополнительные зависимости, с другой стороны, сисоп уже не может отвечать за траффик, идущий через его ноду.

Peter> В принципе, адреса то у нас есть. Это имя ноды и номер поинта. В качестве примера, если сообщение адресовано <syscall,1> - то это netmail ко мне.

Адреса не уникальны. Мы можем подключить в сеть ещё хоть 10 узлов под названием syscall и отлавливать твою почту.

Также любые метаданные сообщений можно подменять на пути следования. И отправителя, и получателя, и адреса, и всё остальное. То есть я тупо захожу в админку на станции, ввожу msgid и меняю любые данные в сообщении. Если уложился в 10 минут - атака MITM сработала. Иногда мне приходится очепятки так править, если случайно загнал сообщение, не подумав =)

Нас спасёт только шифрование, потому что именно оно может гарантировать сохранность переписки. И это гораздо надёжнее в плане транспортов, потому что подойдёт под любую схему синхронизации, какую только можно придумать.

> Ключи может нагенерировать сисоп и просто выдавать пару поинту вместе с authstr при регистрации.

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

Ну то есть:
На ноде должен быть доступ ко всем открытым ключам абонентов сети idec.
На ноде должны быть приватные ключи своих поинтов.

В таком случае, внешне, для поинтов вопрос шифрования вообще не стоит. Они могут дополнительно делать что угодно.

Почему то мне такой вариант нравится больше. А вам? :)

Peter> Почему ты думаешь, что уровень доверия к ноде по ЭЦП недостаточная мера?

Ну так ЭЦП ведь действует независимо от шифрования. Так что читать чужие письма всё равно сисопы смогут.
Да и с точки зрения зависимостей один фиг добавлять больше компонентов придётся.

В общем, я пока займу опять выжидательную позицию. Добавлю в клиент поддержку PGP, может быть, сделаю парочку методов для ноды, которые будут фильтровать контент, а там и решим в итоге. На своей собственной станции ты волен добавлять любые фишки, поэтому если "личные сообщения" тебе нужны срочно, то с нами можно особо и не советоваться.

>> Нас спасёт только шифрование
> Вероятно, так и есть. :( Для меня, это выглядит скорее как отсутствие перспектив на netmail.

Вот! Хоть кто-то меня понимает.

AL> Идея личной переписки мёртворождённая. Потому что без шифрования она никому кроме меня не нужна, а с шифрованием мы теряем простоту технологии.

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

Мне личные сообщения нужны скорее в рамках "КЛУБА", есть ли смысл делать их хотя бы в пределах одной ноды? Тогда все упрощается.

Peter>> В принципе, адреса то у нас есть. Это имя ноды и номер поинта. В качестве примера, если сообщение адресовано <syscall,1> - то это netmail ко мне.
vit01> Адреса не уникальны. Мы можем подключить в сеть ещё хоть 10 узлов под названием syscall и отлавливать твою почту.

В сеть то их кто пустит? А я не предлагал разве между узлами обмениваться нетмейлом только по отдельному паролю? Это позволит создать "круг доверия" между узлами и позволит ходить личной переписке между ними без этой уязвимости. Ведь внутри сети у нас не повторяются имена узлов.

vit01> Также любые метаданные сообщений можно подменять на пути следования. И отправителя, и получателя, и адреса, и всё остальное. То есть я тупо захожу в админку на станции, ввожу msgid и меняю любые данные в сообщении. Если уложился в 10 минут - атака MITM сработала. Иногда мне приходится очепятки так править, если случайно загнал сообщение, не подумав =)

Ну и долой такого сисопа при первом палеве из сети. Все так радеют за безопасность, всё время забывая, что это просто шутка. Не бывает информационной безопасности.

vit01> Нас спасёт только шифрование, потому что именно оно может гарантировать сохранность переписки. И это гораздо надёжнее в плане транспортов, потому что подойдёт под любую схему синхронизации, какую только можно придумать.

Тогда я пас.

vit01>> Адреса не уникальны. Мы можем подключить в сеть ещё хоть 10 узлов под названием syscall и отлавливать твою почту.
AL> В сеть то их кто пустит? А я не предлагал разве между узлами обмениваться нетмейлом только по отдельному паролю?

vit01>> Также любые метаданные сообщений можно подменять на пути следования.
AL> Ну и долой такого сисопа при первом палеве из сети.

Ну, если существует два варианта развития событий: хороший или дурацкий, то ситуация обязательно пойдёт по второму сценарию. Пока нас мало, мы можем не читать чужую почту и жить честно. Как только узлов станет больше, будут и сисопы, которым захочется потешить своё любопытство.

AL> Идея личной переписки мёртворождённая. Потому что без шифрования она никому кроме меня не нужна, а с шифрованием мы теряем простоту технологии.

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

Когда мы пытаемся договориться по поводу чего-то, надо учитывать и плюсы, и минусы. Так что надо приводить примеры и с MITM, потому что кому-то это может не понравиться.

> Ну, если существует два варианта развития событий: хороший или дурацкий, то ситуация обязательно пойдёт по второму сценарию. Пока нас мало, мы можем не читать чужую почту и жить честно. Как только узлов станет больше, будут и сисопы, которым захочется потешить своё любопытство.

Разве это сильно отличается от обычной почты в интернете? Почему ты думаешь, что уровень доверия к ноде по ЭЦП недостаточная мера?

Идея личной переписки мёртворождённая. Потому что без шифрования она никому кроме меня не нужна, а с шифрованием мы теряем простоту технологии.

А ещё я это сообщение набрал одним пальцем =)

Peter> Мне личные сообщения нужны скорее в рамках "КЛУБА", есть ли смысл делать их хотя бы в пределах одной ноды? Тогда все упрощается.

Если нужны, то почему бы не сделать? Главное, чтобы остальной стандарт поддерживался. Причём по большей части достаточно ii-03 =)

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

Но почему-то нет доверия между сисопами. Мы ж кого попало не берём =)

Надо понимать, что вся сеть у нас строится на доверии и так и надо продолжать. Интернет и правительства государств стремятся к разделению людей, а мы же стремимся к обратному. Посмотрите на картинку на http://ii-net.tk/ она передаёт суть idec - сеть людей. Это то немногое, что отличает нас от остального интернета. И важно это не потерять со временем.

Выдохнул.

> Так что читать чужие письма всё равно сисопы смогут.

Те сисопы, кому мы доверим. А если поинт параноит, может и PGP поверх юзать.

> Да и с точки зрения зависимостей один фиг добавлять больше компонентов придётся.

ЭЦП можно и без pcrypto реализовать, прямо на питоне =)

> В общем, я пока займу опять выжидательную позицию.

Если еще идеи возникнут, пиши. У меня пока тоже нет 100% ясности, что делать и делать ли вообще.

Кстати. Можно сделать ЛС и без шифрования и без общей эхи.

Например, методы <POST|GET> /i/username

Т.е поинт отсылает сообщение в свою ноду на поинта с другой ноды.

node1user:$ curl -XPOST /i/node2user -d '{"auth": "authstring"}'

И оно становится доступно для фетча для доверенной ноды. На другой ноде, где юзер хочет почитать почту, делается запрос на получение своей почты. Вторая нода делает запрос на все ей известные ноды, ну и фетчит почту своих поинтов.

Так протокол остается простым и может быть реализован хоть на файлах.

Вот как-то так.

Даже поле Echo можно оставить. Разрешить его быть пустым, например.
Если поле не пустое, то получится, что-то типа канала во всяких irc, только не im :).

Еще можно сразу нескольким юзерам разрешить писать: /x/i/<to_username>/<to_username2>.

Сейчас с утра прочитал свое сообщение -- в общем мне нравится эта идея.

Вынести это все куда-нибудь в расширения, типа, /x/i/<to_username>.
Нода может, как по крону фетчить почту своих поинтов, так и напрямую ходить к соседям при запросе от поинта.

Поинтовое сообщение ничем не отличается по структуре от сообщения в эху.

Годнота же.

Давайте сделаем. =)
Еще у меня возникла мысль, что чтобы не переделывать клиентский софт, можно слать и получать приватные сообщения в обычную эху но такую:

netmail.<authstr> -- по сути это одновременно авторизация и софт не надо менять

>Я примерно это и предлагал, но Виктора смущает MITM, и доступ сисопов доверенных нод к переписке.

Если зохочется шифрование, то в такой схеме ничего не мешает использовать PGP, либо просто кидая armor сообщение, либо реализовав поддержку в клиенте.

Сейчас, мне кажется, что это не проблема сети совсем. Необязательно же каждую ноду включать в сеть для переписки.

Difrex(mobile)> Кстати. Можно сделать ЛС и без шифрования и без общей эхи.
Difrex(mobile)> Например, методы <POST|GET> /i/username
Difrex(mobile)> Т.е поинт отсылает сообщение в свою ноду на поинта с другой ноды.
Difrex(mobile)> node1user:$ curl -XPOST /i/node2user -d '{"auth": "authstring"}'
Difrex(mobile)> И оно становится доступно для фетча для доверенной ноды. На другой ноде, где юзер хочет почитать почту, делается запрос на получение своей почты. Вторая нода делает запрос на все ей известные ноды, ну и фетчит почту своих поинтов.
Difrex(mobile)> Так протокол остается простым и может быть реализован хоть на файлах.
Difrex(mobile)> Вот как-то так.

Я примерно это и предлагал, но Виктора смущает MITM, и доступ сисопов доверенных нод к переписке.

>Лучше вписать туда что-нить типа net.mail.

Не, фишка в том, что если оставить поле пустым, то будет периписка между двумя пользователями, а если в echo вписать что-то, то туда можно наинвайтить много пользователей и писать на All.

Получится что-то вроде приватной эхи.

Difrex> Нода может, как по крону фетчить почту своих поинтов, так и напрямую ходить к соседям при запросе от поинта.

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

Difrex> Поинтовое сообщение ничем не отличается по структуре от сообщения в эху.

Это сабо самой.

>То есть, доверенные ноды тоже забирают по authstr?
Да.

>Как доверенная нода забирает бандл со всем net.mail?
Примерно так:

for node in neighbords:
  for username in node_users:
    r = requests.get('https://' + node '/x/i/' + username)
    for msg in r.content.split("\n"):
      if msg.split(':')[0] not in point_mails():
        store_to_pointmail(base64.d64decode(msg.split(':')[1]))

Difrex> Даже поле Echo можно оставить. Разрешить его быть пустым, например.

Лучше вписать туда что-нить типа net.mail.

> Difrex> Поинтовое сообщение ничем не отличается по структуре от сообщения в эху.

> Это сабо самой.

То есть, доверенные ноды тоже забирают по authstr? Как доверенная нода забирает бандл со всем net.mail?

>> Лучше вписать туда что-нить типа net.mail.
> Не, фишка в том, что если оставить поле пустым, то будет периписка между двумя пользователями, а если в echo вписать что-то, то туда можно наинвайтить много пользователей и писать на All.
> Получится что-то вроде приватной эхи.

Не понял зачем это может быть нужно. В стандарте чётко прописана структура сообщения и нигде не допускается пустых полей, ЕМНИП. А приватные эхи тем более не нужны. Есть скрытоэхи.

Peter> Еще у меня возникла мысль, что чтобы не переделывать клиентский софт, можно слать и получать приватные сообщения в обычную эху но такую:

Peter> netmail.<authstr> -- по сути это одновременно авторизация и софт не надо менять

Это гениально! =) Отличная идея. Только тут надо помнить, что название эхи - это lowercase, но тут невелика проблема, можно преобразовать.

В схеме Дениса не нравится, что можно фетчить только у соседей и только для своих поинтов, без транзитных пересылок для чужих сообщений. Надо добавить маленький костыль, чтобы иметь возможность обходить это ограничение (например, метка на сообщение, которая будет разрешать трафик через посредников).

Насчёт "эх внутри нетмейла". Идея неплохая, но это можно реализовать проще: через теги, т.е. тем же способом, каким у нас сейчас ставится repto.

>> Difrex> Поинтовое сообщение ничем не отличается по структуре от сообщения в эху.
>> Это сабо самой.
> То есть, доверенные ноды тоже забирают по authstr? Как доверенная нода забирает бандл со всем net.mail?

Идея моя состоит в том, что нода для забора нетмейла использует парольный запрос. То есть доверенная нода регистрируется на ноде-аплинке в роутинге нетмейла (их может быть сколько угодно вплоть до полносвязки) и получает бандл нетмейла по паролю. Так нетмейл не утечёт за пределы доверенной сети.