Hi Paul, Yaron has already commented on a few points, I'll add some of my own. Please find them inline.
> *** Large issues *** > > 1: > TLS 1.3, when it is standardized and deployed in the field, > should resolve the current vulnerabilities while providing > significantly better functionality. It will very likely obsolete > this document. > This is not correct. TLS 1.3 will only deal with a subset of the issues > brought up in this draft, so it will not obsolete this draft. Further, it > would only make this draft obsolete when it is universally deployed, which > won't happen in our lifetimes. Proposed rewording: > It is expected that the TLS 1.3 specification will resolve many of > the vulnerabilities listed in this document. A system that deploys > TLS 1.3 will have fewer vulnerabilities than TLS 1.2 or below. This > document is likely to be updated after TLS 1.3 gets noticeable > deployment. > > I am not entirely sure what TLS 1.3 will bring or not. I am happy with keeping this much more open-worded. > 2.1: > o Confidentiality: all (payload) communication is encrypted with the > goal that no party should be able to decrypt it except the > intended receiver. > Actually, all of the application-layer communication is encrypted, not > just payloads. Proposed rewording: > o Confidentiality: all application-layer communication is encrypted > with the > goal that no party should be able to decrypt it except the > intended receiver. > > That was indeed meant; your version is better. > 2.2: > (indeed, often a server will not know whether a > client might attempt authenticated or unauthenticated TLS) > A server can *never* tell whether a client validated the server's > certificate. Proposed rewording: > (indeed, a server cannot know whether a > client might attempt authenticated or unauthenticated TLS) > > Yes, and we should use your version. > 4.2: > o In many application protocols, clients can be configured to use > TLS even if the server has not advertised that TLS is mandatory or > even supported (e.g., this is often the case in messaging > protocols such as IMAP and XMPP). > What is "advertised" supposed to mean here? The above is certainly not > true for STARTTLS-style protocols. If this is meant to cover protocols that > use URI schemes that might or might not end is "s", those are not server > advertisements. I'm not sure how to reword this because it is too unclear. > > I am not sure here, either. > 5.5: > Rationale: Elliptic Curve Cryptography is not universally deployed > for several reasons, including its complexity compared to modular > arithmetic and longstanding IPR concerns. > If this document wants to spread the IPR FUD, please at least counter it > with: > (These concerns have generally been eliminated with the publication of > RFC 6090.) > > I think it is safe so say that IPR discussions did have an effect on deployment in the *past*, and that is probably what the document wanted to say (after all, the current deployment is a result of actions that are now in the past). Furthermore, I am not sure how many people know of the good news that IPR is no longer a concern. The thing can be easily reworded by making it "and IPR concerns, which, for the most part, have now been resolved [RFC6090]". Note: IANAL. > 7.3: > Forward secrecy (also often called Perfect Forward Secrecy or "PFS" > and defined in [RFC4949]) > ... but then the draft refer to "PFS" instead of "forward secrecy". It > would be better to use the more accurate term. > > OK. > > *** Editorial *** > > 2: s/WWW/web/ > > Why? Is this an issue of "use only one version"? I find WWW to be the clearer term, actually. > 2.1: > o Authentication: an end-point of the TLS communication is > authenticated as the intended entity to communicate with. TLS > enables authentication of one or both end-points in the > communication. Some TLS usage scenarios do not require > authentication. They are not in the scope of this document. We > discuss them under Section 2.2. > The last two sentences change from the positive to the negative in a > confusing way. Maybe move those two sentences to their own unbulleted > paragraph. > > ACK. This has also been mentioned by Watson (I think). > 5.4: > Where a > client certificate is used, a third one is added. > To be clearer, that should be "...a third public key is used". > > ACK. Thanks for the review! Ralph
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
