Re: [TLS] PR ¤468: Cookie for hrr
On Sun, May 22, 2016 at 10:33:02PM +0300, Ilari Liusvaara wrote: > Here is what I think should match (going through all currently known > values and excetions): > > - Version > - Ciphersuite Protection+PRF, key exchange in allowed values. > - What to do with server_name??? > - Status_request presence (but not contents)??? > - Status_request_v2 presence (but not contents)??? > - Signed_certificate_timestamp presence (but not contents)??? > - ALP can not be negotiated by any means. > - 0-RTT Protection+PRF+ALP can not be negotiated. > > (I think status_request and status_request_v2 should mirror whatever > signed_certificate_timestamp does). Thinking about it some more, including status_request/status_request_v2/ signed_certificate_timestamp is only useful if one wants to tie the ticket lifetime to parent certificate lifetime. Also, list of things saved for 0-RTT-capable context would be useful. I presume: - The context name - The PSK key - The PSK context - Timestamp - Expiry time (not needed for 0-RTT) - On server side: RTT estimate - Allowed key exchanges - Negotiated protection - Negotiated PRF - Negotiated ALP (negotiated via any means, or absence thereof) - (Implementation-defined peer identity, not needed for 0-RTT) - (Implementation-defined self identity, not needed for 0-RTT) - What to do with server_name??? (On server side, one can save the rest encrypted into context name). Also, how is the context in EDI defined? I couldn't find clear answer, and I preseume it is a replay detector for 0-RTT (Client- Random already is a preturbator, and could also be used for replay detection). But such thing could be much shorter than maximum of 255 bytes... -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Document Action: 'Transport Layer Security (TLS) False Start' to Informational RFC (draft-ietf-tls-falsestart-02.txt)
The IESG has approved the following document: - 'Transport Layer Security (TLS) False Start' (draft-ietf-tls-falsestart-02.txt) as Informational RFC This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Stephen Farrell and Kathleen Moriarty. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-falsestart/ 1. Summary "False Startâ was an attempt to reduce the latency impact of HTTPS based on the simple premise that the client send application data earlier in the handshake; to be precise clients send application data before they have received and verified the server's "Finishedâ message. Initial measurements showed a 30% reduction in latency [0] I could paraphrase more of s2, but the authors explained the timing and the implications at the end of s2. Note that this âexperimentâ was supported by Chrome, FF, IE, OpenSSL, NSS, and others. Some additional details: - Chrome 20 disable it except for sites that enabled NPN. - Firefox has (or at some point had) an NPN requirement to enable False Start. - Safari as an additional example without the NPN requirement: http://opensource.apple.com/source/Security/Security-55471/libsecurity_ssl/lib/sslTransport.c - While there were patches to enable False Start with OpenSSL, it's not clear it was ever part of an official release. As far as where you should point your fingers: - Sean Turner is the document shepherd, and; - Stephen Farrell is the responsible Area Director. 2. Review and Consensus There wasnât a whole lot of discussion, primarily because "False Startâ the implementation issues were worked out by the browsers and the WG didnât adopt this draft until long after (Nov-2014). The draft was adopted because it documents existing practices and provides security considerations [0]; the comments in the WG adoption thread were incorporated in the -01 WG version. The WGâs deliberations resulted in a number of changes that more accurately reflect deployments (i.e., dropping server-side False Start) as well as restricting its use to pre-TLS1.3 (see s5.2) and cipher suites (see s5.3). One reviewer wanted all (FF-)DHE cipher suites removed because they believe that the downgrade protections defined in [1] are in adequate. To solve address this issue, the âFalse Startâ draft requires whitelists as well as large groups/curves. [0] https://mailarchive.ietf.org/arch/msg/tls/RLklpxmZ3BQRBIqWgfeUcCLhgx0 [1] https://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/ RFC Editor Note Please change the intended status in the header to "Informational" I don't believe any other text changes are needed. (The IESG and authors figured that informational was better during IESG eval.) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
