Hi Eric, Thanks for your response. Sorry for the delay, I'v been traveling. The responses sound good, I do have a clarification and will respond inline.
On Sat, May 13, 2017 at 2:09 PM, Eric Rescorla <e...@rtfm.com> wrote: > Hi Kathleen, > > Thanks for your review. > > >> 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. > > Yeah, we'll remove this. > > >> 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. > > I agree this should figure more prominently. I'm working on a PR > for this now which addresses at least some of these points, so > I'll hold off on responding to this for now and maybe we can > revisit once that PR has been completed. > Thank you. > >> 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. > > In general, TLS's policy (dating back to TLS 1.0) has been that the > job of TLS is to carry the certificates and other authentication > material but to leave it up to other parts of the system to > interpret them. It's been a long time since that decision was made, > but from my perspective, there are a number of major reasons: > > 1. Most of PKI processing (path construction, etc.) is generic and > not specific to TLS. What is specific to TLS is: > > * How to indicate what your PKI capabilities are > (see, e.g, S 4.2.4 and 4.3.2) > * How to stuff the PKI material into the protocol > (principally S 4.4.2) > * How to determine whether a given certificate is suitable for > use in TLS 4.4.4.2 and 4.3.2.1). > > So we want to outsource the generic PKI part > > > 2. It matches the software architecture that people often use, > which is to have a TLS stack but separate PKI validation. For > instance, Firefox uses NSS for TLS but moz::pkix for > validation. Similarly, Chrome uses BoringSSL for TLS > but the system PKI libraries for validation. > > > In this case, I think that this text was more intended to > say "and go read 5280 to learn how to do this". To that end, > I suggest we say" > > > "In general detailed certificate validation procedures are out of > scope for TLS. [RFC5280] provides general procedures for > certificate validation. This section provides TLS-specific > requirements." > This reads much better, thank you. However, shouldn't it say TLS1.3 since TLS 1.2 referenced RFC3280 and subsequently in RFC7525 includes use of RFC5280 as a best practice. It may be true for TLS 1.0 and 1.1, but it changed for TLS 1.2/ > >> 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? > > I think that these requirements apply equally to TLS 1.3, it's > just that 7525 is older. I think this was poor phrasing on my part for the point. and is hopefully clarified in my response above. RFC7525 came after TLS 1.2 and updated it's guidance recommending 5280. > > >> 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). > > This is part of our generalized attempt to update to point to > the latest RFCs in our references. I'll add something to the > references section. > https://github.com/tlswg/tls13-spec/issues/1015 > > >> 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." > > In general, I think we'd prefer to avoid providing a catalog of > all the ways that things can go wrong, because there are a lot. > The point of the text here is just supposed to be that servers > don't have to fail if they ask for client auth but they are then > sad about what the client provides. That's actually generally kind > of true, but it's more obvious with client auth because in many > cases the server has many ways of authenticating the client and > can fall back if it doesn't like the cert. >From list discussions, the underspecification seems to be causing some interoperability problems. Maybe a response to the list discussion with this point will result in something to improve this section and clarity for developers. I'll look in the next update. Thank you. > > >> 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. > > I agree. I think it would be useful to say something about this. I've > filed https://github.com/tlswg/tls13-spec/issues/1014 to track this. Thank you, this is very helpful. Best regards, Kathleen > > -Ekr > > > On Fri, May 12, 2017 at 7:07 PM, Kathleen Moriarty > <kathleen.moriarty.i...@gmail.com> wrote: >> >> 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 > > -- Best regards, Kathleen _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
