Subject: [Uta] Feedback on draft-ietf-uta-tls-bcp-07 (Forwarding on behalf of Joe. St. Sauver...)

From: Stephen Farrell <[email-masked]>
Date: Mon, 17 Nov 2014 21:12:20 +0000

Hi all,

For some reason Joe's post didn't get to the list so I'm just
forwarding that whilst someone figures out what is/was up. Please
cc' Joe on responses just in case he's not seeing list traffic.

Cheers,
S.

>From [email-masked] Fri Nov 14 13:14:42 2014
Date: Fri, 14 Nov 2014 13:14:42 -0500 (EST)
From: joe <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Feedback on draft-ietf-uta-tls-bcp-07

Hi,

Following discussions with some colleagues, I was encouraged to directly
share feedback on draft-ietf-uta-tls-bcp-07 with UTA. That feedback is
enclosed below for your consideration.

Section 1., top of page 3 in the text version:

   "These are minimum recommendations for the use of TLS in the vast
   majority of implementation and deployment scenarios"

   At least in some parts of the draft, specific recommendations are
   offered, and I am concerned that rather than being read as
   establishing a minimum floor, those recommendations may be taken
   as narrowly defining the ONLY acceptable specification. I'd urge
   that *stronger* options always be explicitly allowed, since different
   users will often have different priorities when it comes to
   cryptographic strength vs. computational loads, etc.

Section 3.1.1

   Totally agree with efforts to get SSLv2 and SSLv3 gone. Would
   like to ALSO see TLS 1.0 and TLS 1.1 treated equally strongly
   (e.g., change the "SHOULD NOT negotiate TLS verison 1.0" and
   change the "MAY negotiate TLS version 1.1" to "MUST NOT")

   If you're NOT doing TLS 1.2, you lose the ability to employ
   AES GCM/AES CCM, you lose HMAC-SHA256/SHA-384 and AEAD,
   and given that TLS 1.1 dates from April 2006 and TLS 1.2 dates
   from August 2008, I think the time has come to pull the plug
   on TLS 1.1. Six years is enough time for TLS 1.2 to gain
   adoption, and if penetration isn't yet where it should be,
   the time has come to push on that a bit.

   I'd also note, as the draft itself comments, "the cipher suites
   recommended by this document (Section 4.2 below) are only
   available in TLS 1.2."

   So, let's not backslide/compromise on TLS 1.1 :-)

3.1.2: Consistent with the preceding comments, I'd like to see
   only Version 1.2 of DTLS listed as acceptable.

3.1.3: If you're only doing TLS 1.2, the fallback scenario is
   inherently dealt with

3.2: I strongly support HSTS. However, I'd encourage you to to
   reference the Proxy User Stories page at
   https://github.com/http2/http2-spec/wiki/Proxy-User-Stories
   outlining some of the issues that can arise in a proxy-incompatible
   Strict TLS environment so that folks can make a fully-informed
   decision.

   Should there be a recommendation around max-age?

   HSTS also relies on the browser maintaining data on what sites are
   using HSTS. Should there be recommendations to browser authors
   around maintaining the integrity of that data? Currently the process
   of overriding HSTS state is trivially accomplished for major browsers
   (see for example
   http://classically.me/blogs/how-clear-hsts-settings-major-browsers)

4.2: This section recommends:

   o  TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
   o  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
   o  TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
   o  TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

   I agree with those recommendations. However, are those cipher suites
   listed in *recommended* order?

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.

   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.

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/ )

   Should there be recommendations around the dhparam generator, too?
   E.G., openssl supports 2 and 5 -- which should be used, and why?

   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.

7. Security considerations section: often this is a proforma section
   included merely to meet RFC formatting requirements, and many
   readers may be in the habit of "tuning out" by the point they
   hit that section. In the case of this draft, however, important
   content is included in section 7. I would urge that it be moved
   up in the document to a more prominent location.

   The approaches for obtaining access to a private key (at the
   bottom of page 14/top of page 15) omit an important process:
   subornation of a system administrators through bribery,
   coercion, etc., or collection of private keys from inadequately
   protected backups.

7.5: Certificate revocation. This section could be succinctly
   summarized as "revocation s*cks." However, revocation is still a
   critically important protection. From a practitioners POV, CRL
   and OCSP are widely supported by CAs and many browsers, and
   should not be summarily given the RFC equivalent of a shrug of
   the shoulders. They aren't perfect, but they do offer some
   ability to communicate revocation status *IF* browsers and other
   clients check them.

   That said...

   More emphasis should be put on the privacy implications of
   relying on OCSP, *AND* use of OCSP should be flagged as a potential
   denial of service attack (a down or unreachable OCSP responder
   from a major CA tends to result in a real "fire drill")

   I would also note that when clients aren't yet connected to the
   Internet (e.g., prior to wireless auth for example), they often
   lack the ability to reach OCSP responders or the ability to
   download CRLs, yet they often need to evaluate the revocation
   status of a certificate they've been presented for use in
   establishing that connection, potentially resulting in a troublesome
   circularity.

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.

No discussion of SPDY. Given that TLS can impose a performance hit,
I think it would be worth at least touching on the impact that SPDY
can have as an offsetting factor.

And as a practical matter, given the technical complexity involved in
configuring systems to meet all the recommendations in the draft,
should there be endorsement of use of automated assessment tools
for the purpose of confirming appropriate system configurations?

Thanks for considering this feedback on a very important draft.

Regards,

Joe

Joe St Sauver, Ph.D. ([email-masked] or [email-masked])
Farsight Security, Inc.
https://www.stsauver.com/joe/

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 18 Nov 2014 20:45:47 +0000

>    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.

>    I would like to see a more complete discussion of ECC curve

Again, best *current* practice.  This document can and will be
updated in the future.

>    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.

>    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. :-)

>    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.

> 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.