On Mon, Nov 17, 2014 at 09:12:20PM +0000, Stephen Farrell wrote: > 4.2.1 states that TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 SHOULD > be the first cipher proposed, and servers SHOULD prefer that > cipher whenever is proposed. > > I'd prefer to see the AES_256 version recommended instead, given > that it provides a large margin of cryptographic strength.
The cryptographic margin in AES-128 is I believe quite sufficient for best current practice. The performance benefits can lead to greater adoption. Don't let the perfect be the enemy of the good. > Also in 4.2.1, NIST P-256 (secp256r1) is called out for > interoperability purposes. I get the intent, but I have concerns > given the analysis reported near the bottom of > http://safecurves.cr.yp.to/ for that (and related) curves. > > I would like to see a more complete discussion of ECC curve > selection criteria. Again, best *current* practice. This document can and will be updated in the future. > 4.3: Currently recommends at least 2048 bit DH parameters and > certificates. I'd prefer to see 4096 bit DH parameters and 4096 bit > certificates explicitly recommended. (Rationale: industry > efforts to move to SHA-2 for hashes should be supported by > proportionately strong symmetric and asymmetric key lengths, > as nicey summarized at http://www.keylength.com/en/compare/ ) This would move far outside current practice, and substantially away from interoperable and adequately performant settings. At that strength it makes more sense to simply switch to ECDHE, but we don't have curves we fully trust yet. I think 2048-bit EDH is a good reflection of best *current* practice. > Should there be recommendations around the dhparam generator, too? > E.G., openssl supports 2 and 5 -- which should be used, and why? The generator is irrelevant, all cyclic groups of order (p-1)/2 are isomorphic regardless of choice of generator. And in fact for strong (Sophie Germain) primes, since q=(p-1)/2 is also prime, every g^x with 1 <= x < q is also a generator. To avoid trivial subgroup attacks, we pick a generator that is a square mod p, and therefore generates a subgroup of order q, rather than 2q. So we primes for which 2 or 5 or both are squares. For g = 2: Quadratic reciprocity and ensuring that q is also odd and not trivially divisible by 3, means that p is 7 mod 8 and 2 mod 3, which by CRT makes p = 23 mod 24 (q = 11 mod 12). For g = 5: Quadratic reciprocity and ensuring that q also odd and not divisible by 3 or 5 gives p = 4 mod 5, 3 mod 4 and 2 mod 3, which by CRT gives p = 59 mod 60 (q = 29 mod 30). If you like you can choose p for which both 2 and 5 work, by only looking for p = 119 mod 120 (q = 59 mod 60). We see why g=2 is more popular, more candidate primes means less time searching for suitable primes. However, with "named ff groups" coming soon to a TLS implementation near you, the cost of generating a new group eventually goes away. Ideally, we'll adopt curves nobody distrusts and stop doing DHE around the time that named groups for DHE are finally widely supported. :-) > I'd also suggest that the realities of plans for deprecating > SHA-1 certs in popular browsers means that use of SHA-2 (including > EITHER SHA-256 *OR* SHA-384) is now effectively necessary for > sites that want to have their certs be globally trusted. Thus, > RECOMMENDING use of SHA-256 should be strengthened to MUST USE > and EITHER SHA-256 *OR* SHA-384 should be permitted. Note, there is a big difference between SHA-2 in certificates, and SHA-2 as a PRF in TLS. I've not seen any certs with SHA-384, people seem to be using either 256 or 512. > Other: should there be discussion of certificate chains? Specifically, > some implementations want intermediate certs in order from closest > to the root to furthest from the root, while others reverse that > order. I'd like to see that order normalized. The wire order is specified in the TLS RFCs. Leaf first, then intermediate signer of leaf, ... up to but not necessarily including the root. (The DANE OPS draft explains that for DANE-TA(2) the root is not be optional). -- Viktor. _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
