On 2014-07-06 21:09, Yaron Sheffer wrote: > 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. >
Adding my voice here as chair. Even though the WG haven't really talked about the type of RFC to publish, the term 'BCP' should still guide our efforts. This means that the draft should focus on best _current_ (my emphasis) practice which means neither good, worst, bad or good-enough and also neither future or historic practice. We need to strike a careful balance between what we want and what we can have given current deployment status. This also means that a BCP-like document is not an appropriate forum for pushing too much against the inside of the envelope - in fact it should nestle right up to the inside edge of the envelope. If we want to write a document describing what we'd _wish_ implementers and deployers would do, we can do that too. >> >> 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. > Speaking as chair: Trevor, please suggest changes so the WG has something more tangible to work with. >> >> 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." > Speaking as an individual, I'd say that SNI should (in this day and age) be considered mandatory to implement if not mandatory to deploy. I suspect Trevor is pushing on the first issue while you are pushing back on the second. >> >> 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. > >> >> 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. > >> >> 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. > Speaking as chair I need others to chime in here. The WG needs to come to consensus (even if it is rough) and right now me and Orit don't have enough data. >> >> 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." >> >> 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. > >> >> 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. cf above > >> >> Clients MUST include the “supported elliptic curve” extension > > See above. > cf above > 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
