Hi Yaron, Thanks for the response. See inline
-----Original Message----- From: Uta [mailto:[email protected]] On Behalf Of Yaron Sheffer Sent: Sunday, July 06, 2014 12:09 PM To: Trevor Freeman; [email protected] Subject: Re: [Uta] TLS BCP 01 Draft Hi Trevor, thanks for your review. Please see my comments in line. On 06/30/2014 09:11 PM, Trevor Freeman wrote: > General Comments. > > There are still no definition on what constitutes best protection > against monitoring i.e. what offers best, adequate or minimal > protection against monitoring. Give one of the goal is to move the > internet to better protect against this kind of activity, we need to > clarify which actions in this draft best enable that goal and not just > providing basic interoperability. These are lofty goals indeed. But the draft's goal is not to define "best protection against monitoring", let alone to define 3 levels of such protection. It is simply to remediate issues with the way TLS is currently deployed. I don't think we "just provide basic interoperability", I believe we provide strictly better security, within the constraints of current technology and interoperability. [TF] The strategy for the ietf's response is to increase the cost of those activates by making it more expensive to read the traffic. You already hint that some aspects provide better security that others by the keywords you use to devein what must, should, may or should not be done. > > Section 3.4 and 4.1 needs to be consolidated as there is a lot of > overlap between the two sections. I am not sure about the overlap, and would appreciate specific points. [TF] Overall I don’t see any logic behind the split between section 3 and 4 which is what I mean by overlap. A lot of what's in section 3 seems pretty detailed. It's much easier to read if the bottom line of what we need you to do in in one place. > > I think it is good to provide rational behind the recommendations for > various cipher sites, it leaves the reader with some interpretation > between that and the actual cipher suites. It would be better to > actually list the cipher suites in question to remove any scope for > misinterpretation. The first part of Sec. 3.4 provides more than half a page of rationale for the cipher suite selection. > > Also support for the SNI is missing from the draft. This is a > mandatory for any application interacting with a service. Quoting my own earlier response to you (my mail of June 21): "I'm all in favor of using SNI. But as far as the draft goes, I believe this is an operational decision, and so we should not include such a recommendation." [TF] The implementers are totality ignorant of the operational choice made by the server so is in no position to make an informed decision hence the need to mandate. > > Specific comments. > > Section 3.2 still treats SSL 3.0 differently to TLS 1.0. Why is it ok to > fall back to TLS 1.0 but not SSL 3.0 if both offer the same security? This is a good question. I believe the answer is, because much of the server population still only supports TLS 1.0, and if we recommend otherwise, the recommendation will be ignored for (justified) interoperability reasons. But I may be wrong about the prevalence of such servers. [TF] Give the similarity of the security properties of SSL 3.0 and TLS 1.0, I am still unclear why you consider it is ok to fall back 1.0 and not 3.0. The only rational I can think of is given the similarities the likelihood of success with SSL 3.0 if TLS 1.0 fails is pretty small but that seems a weak case for a prohibition. > > Section 3.4. > > bullet 3. Implementations MUST NOT negotiate cipher suites with an > effective key length of less than 112 I can live with this. > > bullet 5 Implementations SHOULD prefer cipher suites with greater than > 128 bits of effective key length No, this contradicts our recommendation, and IMO is too strict for the current state of the industry. In other words, people are perfectly happy with AES-128 today and it is NOT our goal to push to AES-256. [TF] This is a less redundant interpretation of how I read this bullet. The read the "if possible 256" part overriding the "at least 128 bit" part. The base 1.2 rfc already mandates 128 bit ciphers as a MUST. What are you trying to convey with this bullet? > > bullet 6 Given the foregoing considerations, implementation of the > following suites are recommended (in order of preference) > > ·TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 > > ·TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 > > ·TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 > > ·TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 > > Rational: In the preceding bullet we give preference to cipher with 256 > bit key Again, we disagree on this point. > > Also client MUST send an ec_point_formats extension As I mentioned earlier, "RFC 4492 specifies the MUST/SHOULD status for these extensions. I don't think we should be repeating or overriding that." [TF] I agree that the base RFC should be authoritative however I less convinced all implementers are totally diligent in recusing though every aspect of every normative reference and would like to some language on the need to follow rfc 4492 guidance on this extension. Rfc's are complex documents and it is all too easy to miss something > > 3.5 public key lengths. > > Public key algorithms based on integer factorization or discrete > logarithms MUST use a public key size of at least 2048 bits. This is currently a SHOULD-level requirement (we use the equivalent term RECOMMENDED). Given the problems with modular DH in TLS, I'm afraid we cannot mandate >2048 because of the interoperability issues, and because some people might value forward secrecy over key length. [TF] Then we need to differentiate static from ephemeral use cases. Implementations MUST support end entity public keys in certificates based on integer factorization or discrete logarithms of at least 2048 bits. Implementations MUST support ephemeral discrete logarithms public keys of at least 1024 bits. I would like to add a rider to do better that 1024 bit but give the inability of the client to signal what it supports in terms of key sizes, that would be futile. > > 4.1 > > Clients SHOULD include TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as the > first proposal to any server. > > Rational: Section 3.4 bullet 5 says we give preference to ciphers > stronger than 128 bits. Disagree again. > > Clients MUST include the “supported elliptic curve” extension See above. [TF] Likewise Thanks, Yaron > > Trevor > > > > _______________________________________________ > Uta mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/uta > _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
