Thank you for the work on this document, well written and easy to read. I don't have major comments. I have some minor comments, and a couple of nits or request for clarifications, which you can address together with any other Last Call comments.
Many thanks to Paul Wouters who has provided an early SEC AD review - I think his mail might have been blocked in moderation queue because I can't find it in the mailarchive, so I will copy it at the end of my mail here. Authors: as I don’t see major blocking comments from Paul, I will not delay Last Call, but will look forward to your answers to Paul’s very valid comments as well. Francesca 1. ----- FP: DTLS 1.3 has been published, please update the reference to RFC9147 2. ----- This document attempts to minimize new guidance to TLS 1.2 implementations, and the overall approach is to encourage systems to move to TLS 1.3. However this is not always practical. Newly FP: I believe this is the first time TLS 1.3 appear (excluding the abstract) so it would be good to add a reference to RFC 8446 here. On the same note, there are a number of protocols named as examples, but with no references, it would be good to add some informative references for these (SMTP, IMAP, POP3, SIP, XMPP, IRC, SRTP) 3. ----- FP: Has the working group had a discussion about the "Updates" header tag for this document? The two existing ones are quite straightforward, but I wondered if it would make sense to add the TLS and DTLS docs there as well, to provide an easy link for implementers to more easily find this BCP. 4. ----- more secure PSK-based mechanism is described in Section 4.6.1 of [RFC8446]. See this post (https://blog.filippo.io/we-need-to-talk- about-session-tickets/) by Filippo Valsorda for a comparison of TLS 1.2 and 1.3 session resumption, and [Springall16] for a quantitative study of TLS cryptographic "shortcuts", including session resumption. FP: Can we add the blog post as reference, and take a stable screenshot of it to include as reference in this document? 5. ----- * For similar reasons, session ticket validity SHOULD be limited to a reasonable duration (e.g., half as long as ticket key validity). FP: It would be good to expand on why this is not a MUST, i.e. what is the expected exception case. Also I appreciate the example, but it is hard to define what a "reasonable duration" is, maybe something more can be added here? 6. ----- of protocols that multiplex requests over a single connection (such as HTTP/2), post-handshake authentication has the same problems as FP: Please add a reference to HTTP/2 (draft-ietf-httpbis-http2bis-07). 7. ----- mistaken for a message for use in another protocol, servers should strictly enforce the behavior prescribed in Section 3.2 of [RFC7301]: FP: I am wondering why this "should" and not "need to" or "ought to", or even MUST. 8. ----- FP: Running the ID Nits I also get the following warning: (Using the creation date from RFC5288, updated by this document, for RFC5378 checks: 2007-06-19) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) Were the original authors of RFC 5288 involved? ===================== From: Paul Wouters Date: Monday, 16 May 2022 at 04:03 To: uta@ietf.org Cc: Francesca Palombini Subject: Review of draft-ietf-uta-rfc7525bis-06 This is a good document. I do have a view specific comments. One larger overview question I have is if the authors have thought about using tables to summarize changes, instead of the Appendix A style write up of changes? Specific comments and nits follow below, Paul - We note that as long as TLS 1.2 is still allowed by a particular implementation, even if it defaults to TLS 1.3, implementers MUST still follow all the recommendations in this document. What is this really trying to say? "MUST is a MUST" is not something we need to clarify - Similarly, we RECOMMEND that new protocol designs that embed the TLS mechanisms (such as QUIC has done [RFC9001]) include TLS 1.3 I would not say "include" but really say "be based on" as no one new should make something based on TLS 1.2. - In cases where an application protocol allows implementations or deployments a choice between strict TLS configuration and dynamic upgrade from unencrypted to TLS-protected traffic (such as STARTTLS), clients and servers SHOULD prefer strict TLS configuration. First of all, why is this a SHOULD and not a MUST? Especially since "prefer" seems to also weaken this already. And second, does prefer mean a fallback to dynamic upgrade is allowed if a strict configuration fails? If so, does that apply to all kind of failures? Is this not introducing a downgrade attack? - A client SHOULD attempt to negotiate TLS even if these indications are not communicated by the server. Again, why a SHOULD and not a MUST ? I guess this is why the above uses "prefer" or else there would be a contradiction. - [compression] unless the application protocol in question has been shown not to be open to such attacks. Can something perhaps be said about the standard HTTPS "application" ? eg browsers ? Is it safe or not to support there? - In order to gain forward secrecy, this document recommends that server implementations SHOULD respond with a "key_share", to complete an ECDHE exchange on each session resumption. Doesn't this mostly negate the "essential performance feature" of TLS session resumption? Protocol developers are strongly encouraged to register an ALPN identifier for their protocols. This applies to new protocols, as well as well-established protocols such as SMTP. This seems like a directive in an RFC to the IETF - get an ALPN for SMTP. We should just start that process instead of passive aggressively writing that in an RFC :) When using ECDSA signatures for authentication of TLS peers, it is RECOMMENDED that implementations use the NIST curve P-256. Why only P-256? Why not P-384 or P-521 ? The Logjam attack [Logjam] further demonstrates that 1024-bit Diffie Hellman parameters should be avoided. Why is this should a lowercase? Also why not simply a "MUST NOT use" ? Comments: - The abstract is copied from its 7 years old predecessor, which feels a little dated when it again claims "Over the years [...]. Perhaps a better way is a more generic txt. For example see RFC 8247. - "This document provides recommendations for improving the security of deployed services that use TLS and DTLS." That sounds a bit arrogant. Good deployments might have nothing to improve. Just state this document provides the latest recommendations. - "This document is being republished" This feels odd, the IETF does not "republish". Perhaps "This document has been updated with this in mind" - In fact, the cipher suites recommended by this document for TLS 1.2 (Section 4.2 below) are only available in this version. Why are they not in TLS 1.3 ? :P Or are they? - Implementations of "greenfield" protocols or deployments, where there is no need to support legacy endpoints I don't think "protocols" applies here. It really just says "if you are a greenfield deployment (you manage all the nodes communicatiing), you could insist on TLS 1.3 only. - See this post (https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-f50c199c2e19ebfa&q=1&e=a0863fc0-c9b6-43b3-b9a6-18db1298e613&u=https%3A%2F%2Fblog.filippo.io%2Fwe-need-to-talk- about-session-tickets/) Turn into a proper informative reference ? Also, it is a weak link and likely to break over the next few years. - Section 3.5 seems to miss an introduction line of what renegotiation is, similar to how 3.4 states what session resumption is (sort of) - (formerly called Encrypted SNI) I think this reference can be removed, it was really only a draft name and not something with actual deployment that people "know". Also "formerly called" is misleading, it was something completely different that had the same goal as ECH. TLS and its implementations provide considerable flexibility in the selection of cipher suites. I wouldn't say that for TLS 1.3 ? It does still apply to TLS 1.2. algorithms that were once considered strong become weak. Such algorithms need to be phased out over time I think "such" here is misleading. It feels like referencing "weak algorithms" yet we are talking about replacing algorithms before these become week. I would simply remove the word "Such". TLS 1.1 and 1.2 never negotiate 40-bit or 56-bit export ciphers. This (misleadingly) suggests TLS 1.3 might however do this? Implementations SHOULD NOT negotiate cipher suites that use algorithms offering less than 128 bits of security. Rationale: Cipher suites that offer between 112-bits and 128-bits of security are not considered weak at this time These sentences together lead to a weird case for 128. Even though it looks a little weird, I would say either "between 112-bits and 127-bits" or "more than 112-bits but less than 128-bits". Also, how long have we had 128 bit ciphers? Can we really not say MUST NOT instead of SHOULD NOT for the 112-127 range? Also in light of Grover's algorithm that brings 256 back to effectively 128? Rationale: Forward secrecy (sometimes called "perfect forward secrecy") prevents the recovery of information that was encrypted with older session keys, thus limiting the amount of time during which attacks can be successful. See Section 7.3 for a detailed discussion. I think this should be rewritten a little? It's not that attack time is limited, but really the exposure after a successful attack. Eg if the vulnerability is not fixed, PFS won't help you as for each session the attacker is either still there or regains access using the same vulnerability. I would more clearly say "limits how far back in time data can be decrypted when an attack is successfull". Nits: "An earlier version of this document was published as RFC 7525" more common is to write: "This document obsoletes RFC 7525" Version 1.3 of TLS [RFC8446] was released and version 1.3 of DTLS was finalized [I-D.ietf-tls-dtls13] This reference can be updated now but requires textual change ("finalized" no longer needed) "leak will be plugged by use of" -> leak is closed by using "It is also RECOMMENDED that clients abort" -> Clients SHOULD abort SEction 3.7, 3.8 I would also add the acronym in the section title. "It is also RECOMMENDED that clients" -> Clients SHOULD improved latency -> reduced latency because they are -> because these are but they are out of scope -> but these are out of scope "[RFC8422]" appears without proper linking in 4.2.1 [I-D.ietf-tls-dtls13] can be updated to [RFC9147] Clients MUST indicate to servers that they request SHA-256, by using the "Signature Algorithms" extension defined in TLS 1.2. Maybe start with: "TLS 1.2 client MUST ....." current state of the art -> best current practises ?
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
