Исходное сообщение
"TLS 1.3 получил статус предложенного стандарта " Отправлено opennews, 24-Мрт-18 12:59
Комитет IETF (Internet Engineering Task Force), занимающийся развитием протоколов и архитектуры интернета, утвердил (http://www.ietf.org/mail-archive/web/ietf-announce/current/m... финальный вариант спецификации (https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/), определяющей протокол TLS 1.3, в качестве  "Предложенного стандарта" (Proposed Standard). Занимающиеся развитием протокола TLS участники рабочей группы  (Transport Layer Security Working Group) смогли прийти к консенсусу и проголосовали за стандартизацию 28 черновика спецификации (все проголосовали "За",  исключая  Warren Kumari (https://research.google.com/pubs/WarrenKumari.html) из Google, который проголосовал "не возражаю", пояснив (https://www.ietf.org/mail-archive/web/tls/current/msg25562.h... что не является экспертом по обсуждаемому вопросу). Установка защищённых соединений с использованием TLS 1.3 уже поддерживается в Firefox и Chrome, и будет предложена в  ветке OpenSSL 1.1.1. Особенности TLS 1.3: -  Удаление устаревших и ненадёжных криптографических примитивов (MD5, SHA-224) и возможностей (сжатие, повторное согласование, не-AEAD шифры, статический обмен ключами RSA и DH, указание unix-времени в Hello-сообщениях и т.п.); -  Работа только в режиме  совершенной прямой секретности  (PFS, Perfect Forward Secrecy (https://ru.wikipedia.org/wiki/Perfect_forward_secrecy)), при котором компрометация одного из долговременных ключей не позволяет расшифровать ранее перехваченный сеанс. Оставление поддержки только PFS вызвало много споров (https://www.opennet.ru/opennews/art.shtml?num=46902) и стало камнем предкновения в достижении консенсуса, так как ряд производителей указывали на возможное негативное влияние PFS на корпоративные системы, в которых применяется инспектирования проходящего трафика, например, для обеспечения отказоустойчивости; -  Поддержка режима 0-RTT (https://blog.cloudflare.com/introducing-0-rtt/) для устранения задержек при возобновлении ранее установленных HTTPS-соединений. При установке HTTPS-соединения выполняются 4 фазы: запрос DNS, TCP Handshake (1 RTT), TLS Handshake (2 RTT на согласование ключей и параметров шифрованного канала) и отправка запроса HTTP (1 RTT). По сравнению с TLS 1.2 в новом стандарте число RTT для TLS Handshake сокращено с 2 до 1, т.е. для установки и возобновления соединения требуется запрос DNS и 3 цикла обмена данными (RTT) вместо 4.  0-RTT позволяет сохранить ранее согласованные параметры TLS  и снизить до 2 число RTT при  возобновлении ранее установленного соединения; -  Поддержка потокового шифра ChaCha20 (http://cr.yp.to/chacha.html) и алгоритма аутентификации сообщений (MAC) Poly1305 (http://cr.yp.to/mac.html), разработанных Дэниелом Бернштейном (Daniel J. Bernstein (http://cr.yp.to/djb.html)), Таней Ланге (Tanja Lange) и Питером Швабе (Peter Schwabe). ChaCha20 и Poly1305 можно рассматривать, как более быстрые и безопасные аналоги AES-256-CTR и HMAC,  программная реализация которых позволяет добиться фиксированного времени выполнения без задействования специальных аппаратных ускорителей; -  Поддержка защищённых ключей аутентификации Ed25519 (http://ed25519.cr.yp.to/), которые обладают более высоким уровнем безопасности, чем  ECDSA и DSA, и при этом отличаются очень высокой скоростью верификации и создания подписей. Стойкость к взлому для Ed25519 составляет порядка 2^128 (в среднем для атаки на Ed25519 потребуется совершить 2^140 битовых операций), что соответствует стойкости таких алгоритмов, как NIST P-256 и RSA с размером ключа в 375 байт или 128-битному блочному шифру. Ed25519 также не подвержен проблемам с коллизиями в хэшах, не чувствителен к атакам через определение скорости работы кэша (cache-timing attacks (http://cr.yp.to/antiforgery/cachetiming-20050414.pdf)) и атакам по сторонним каналам (side-channel attacks); -  Поддержка  обмена ключами на основе алгоритмов x25519 (https://en.wikipedia.org/wiki/Curve25519) (RFC 7748 (https://tools.ietf.org/html/rfc7748)) и x448 (RFC 8031 (https://tools.ietf.org/html/rfc8031)); -  Поддержка HKDF (https://en.wikipedia.org/wiki/HKDF) (HMAC-based Extract-and-Expand Key Derivation Function). URL: http://www.ietf.org/mail-archive/web/ietf-announce/current/m... Новость: https://www.opennet.ru/opennews/art.shtml?num=48324