Hello, Thank you all for your work on TLS 1.3. The list has still been active on a few topics, so I want to see how that all settles out in addition to the questions I have on the draft below.
Introduction: 1. Since this is going for IETF last call soon and there has been review of the draft (workshop, but is clearly ongoing from the list discussions), should the first sentence of the Introductions be removed? DISCLAIMER: This is a WIP draft of TLS 1.3 and has not yet seen significant security analysis. 2. Section 4.2.9 - There should be some mention or pointer to the security considerations and recommendations on replay attacks for 0-RTT from this section. I don't see any mention of discouraging 0-RTT from being a default and think that would be good for applications that use TLS expecting replay protection. I know the WG agreed to keeping 0-RTT, but I think it's very important to make the issues clear and not have this come up as a default in any implementation/deployment for unsuspecting users. Part of this will get down to implementation specifics and configuration options, but offering some guidance is important. This document will be read by many, not just developers. Since clients have to initiate 0-RTT, the user has to have some idea that replay attacks are possible and accept that risk. If this were used in web applications, then all servers that don't want to see replay attacks (banking, etc.), would have to have explicitly reject this usage. As such, there needs to be very strong guidance to this point. Would it be that browsers configure this as a default or something users would have to turn on or just leave it as an option (with warnings) for a client to enable? Would servers have clear information in configuration files (or setup) about the implications of this option for those that don't read the RFC and are not aware of this problem? Most of this discussion belongs directly in the security consideration section, but there has to be mention of it with a reference from section 4.2.9. It's not just an API consideration, this is for developers, implementers, and users of the protocol. Many other protocols use TLS beside HTTP and do so with the expectation of replay protection. While Appendix C1 is helpful, I don't think it's enough. It's disappointing to see a protocol with a replay attack written as a prominent feature of TLS 1.3 and little discouragement from use. 3. Section 4.2. "In general, detailed certificate validation procedures are out of scope for TLS (see [RFC5280]). This section provides TLS-specific requirements." I don't see an explanation of why it is out-of-scope. The reference is just to RFC5280, which seems odd. I would expect the reference to be to something that explains why it is out-of-scope. RFC7525 has use of RFC5280 as a best practice for server identity verification and revocation checks for TLS 1.2. Is this just for TLS 1.3? Why? RFC3280 is cited for revocation in the TLS 1.2 RFC. I think a little explanation here would be helpful since this seems to be a departure (or reference to the changes section). If RFC5280 remains out-of-scope, this section should fully describe the certificate validation process for TLS 1.3. I think you need to list out everything that should be checked as opposed to just including one example: "Also, if some aspect of the certificate chain was unacceptable (e.g., it was not signed by a known, trusted CA), the server MAY at its discretion either continue the handshake (considering the client unauthenticated) or abort the handshake." 4. Section 6.2 Error Alerts In addition to sending the error, I don't see any mention of the error being logged on the server side, shouldn't that be specified? Logging errors (at least in debug modes when needed) provides valuable troubleshooting information and many applications don't do an adequate job of logging, so I think it's important to call that out here as a recommendation. -- Best regards, Kathleen _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
