On Tue, Dec 07, 2021 at 03:59:50PM +0300, Valery Smyslov wrote: > Hi, > > this message starts a Working Group Last Call for > draft-ietf-uta-rfc7525bis-04: > https://datatracker.ietf.org/doc/draft-ietf-uta-rfc7525bis/ > > The WGLC will last for two weeks and will end on December the 21st. > Please send your comments to the list before this date.
- Section 3.1.1: Obsolete NOTE should be removed. - Section 3.4: The recommendations given are not sufficient for security. To actually give any forward security, with any timeframe, an server implementation supporting TLS 1.2 session tickets MUST: 1) Rotate ticket keys periodically, AND 2) Securely destroy the old ticket keys, AND 3) Refuse to resume too old sessions. Failure to do so does not just expose resumed connections to compromise, it exposes all connections where client sent the session ticket extension to compromise, regardless of if the sessions were ever resumed or not. The last one is about age of session, not age of ticket. Session can be older than the ticket. These requirements follow from rather nasty interaction of the following properties of TLS 1.2 session tickets: 1) Client can initiate handshake without proof-of-possession of the session ticket key. 2) The ticket is returned unencrypted. 3) The server can update the ticket. 4) There is no ratcheting of keys. TLS 1.3 session tickets do not have three of these properties. As consequence, e.g.: 1) Sending session ticket never compromises the connection. 2) Even without DH, only connections using ticket with compromised session ticket encryption key are compromised. - Section 3.5: This needs to be strengthened to that all TLS 1.2 implementations MUST implement renegotiation_info, regardless of if renegotiation is implemented or not. It is not safe for client to connect to TLS 1.2 server that does not support renegotiation_info, regardless of if either endpoint actually implements renegotiation. - Section 3.7: It is not possible for server to acknowledge different SNI hostname. The server version of server_name extension always has an empty payload. - Section 3.9: I do not think the recommendation is in agreement with TLS 1.3. TLS absolutely requires application profile for 0-RTT (section E.5). - Section 4: What is "targeted security services" in context of cipher suites? Maybe "targeted security level"? - Section 6.4: Reusing ECDH exponents is insecure unless one either: 1) Checks for point validity, or 2) Uses montgomery ladder with twist-secure curve. Currently the only curves in TLS satsifying 2) are x25519 and x448. For any other elliptic curve, reusing exponents without validating points is insecure. Few thoursand connection attempts at most is sufficient for recovering the ECDH private key, which compromises any connection that used it. - Section 6.5: It seems that status_request_v2 is rather poorly supported. Furthermore in context of WebPKI, the support for CA OCSP is really poor. Major intermediates lack OCSP entierely, or the responses have really long lifetimes (up to the 1 year maximum). Effective revocation of WebPKI CAs basically requires propiteriary mechanisms. -Ilari _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
