Организация Internet Engineering Task Force (IETF), ответственная за развитие протоколов и архитектуры интернета, создала новые правиладля протокола MLS (Messaging Layer Security). Этот протокол помогает защищать сообщения в интернете. Спецификация RFC 9420 сейчас имеет статус “Предложенного стандарта”. Это означает, что её еще проверяют и могут изменить.
Протокол MLS предназначен для организации сквозного шифрования (End-to-End Encryption, E2EE) в мессенджерах. Предполагается, что внедрение MLS позволит унифицировать механизмы сквозного шифрования сообщений в группах, охватывающих двух и более участников, и упростить внедрение их поддержки в приложения.
О работе по внедрению поддержки MLS в свои продукты объявили компании AWS, Cisco, Cloudflare, Google, Meta, Mozilla, Phoenix R&D и Wire, а также организация Matrix Foundation, развивающая платформу децентрализованных коммуникаций Matrix.
Основной целью создания нового протокола называется унификация средств для сквозного шифрования и внедрение единого стандартизированного и верифицированного протокола вместо отдельных протоколов разных производителей, не совместимых между собой.
MLS позволит использовать готовые реализации протокола, которые можно будет совместно развивать и проверять. Совместимость на уровне приложений будет достигаться на уровне аутентификации, получения ключей и обеспечения конфиденциальности.
MLS разрабатываетсяна C++ ( MLSpp , RingCentral ), Go , TypeScript и Rust ( OpenMLS , Wickr ), причем для его разработки использованы наработки уже существующих протоколов, таких как S/MIME , OpenPGP , Off the Record и Double Ratchet . Поддержка MLS уже реализована на платформах коммуникаций Webex и RingCentral, и ожидается её внедрение в проектах Wickr и Matrix.
Основные задачи протокола включают:
- Конфиденциальность: только члены группы могут читать сообщения;
- Гарантии целостности и аутентификации: каждое сообщение отправляется от проверенного отправителя и не может быть изменено в процессе передачи;
- Аутентификация участников группы: каждый участник может проверить подлинность остальных участников группы;
- Работа в асинхронном режиме: ключи шифрования могут быть предоставлены без необходимости одновременного онлайн-присутствия всех участников;
- Прямая секретность (Forward Secrecy): компрометация одного из участников не позволяет расшифровать ранее отправленные сообщения в группе;
- Защита после компрометации: компрометация одного из участников не позволяет расшифровать будущие сообщения в группе;
- Масштабируемость: потенциальная сублинейная масштабируемость в плане потребления ресурсов в зависимости от размера группы.