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

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 01 Dec 2014 20:21:01 -0700

On 11/17/14, 2:12 PM, Stephen Farrell wrote:
>
>
> 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.

Thanks for the forward, and my apologies for the slow reply. My 
attention is in round-robin mode among a dozen active I-Ds. :-)

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

Although I think the current document is clear enough here, it also 
can't hurt to reinforce the point.

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

I'd be fine with SHOULD NOT for TLS 1.1 (instead of the MAY in the 
document right now). I'm not sure what my co-authors think, or working 
group participants more broadly.

As always with documents like this (e.g., RFC 6125), we're walking a 
fine line between best practice and current practice. Right now, saying 
MUST NOT for SSLv2 and SSLv3 is clear, but it's less clear to me that we 
have that consensus for TLS 1.0 and TLS 1.1. Might we have that 
consensus a year or two from now? Maybe, in which case someone can 
publish a document that obsoletes this one.

In any case, I'd want to see some support from other folks here before 
changing TLS 1.0 and TLS 1.1 to MUST NOT. (Perhaps the chairs could 
issue a consensus call on the topic.)

> 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

True, and that has its appeal.

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

My feeling is that those matters are HSTS implementation details and 
ought to be covered in an HSTS-specific document.

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

I don't think so, but Yaron and Ralph might have had something else in mind.

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

We had a separate discussion about this and I for one didn't see 
agreement there that AES_256 was recommended.

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

Yes, that is concerning.

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

Ideally, that would be nice. Finding the time to write it is another 
question.

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

Again I think that might be something for a future BCP, not this one.

(IMHO this document is already a year late.)

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

I don't particularly see a reason to route around lazy readers. :-)

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

Sadly, yes.

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

I think that text along the lines of what Massamiliano Para proposed 
will improve this section.

>     That said...
>
>     More emphasis should be put on the privacy implications of
>     relying on OCSP,

See also the foregoing text proposed by Massamiliano Para.

> *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")

Indeed.

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

Good point.

We'll add some text on both of those points.

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

I don't think that's within the scope of this document.

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

IMHO this document ought to be as application-neutral as possible, so 
I'd prefer to avoid talking about HTTP/2 details.

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

I'm not sure if that level of operational advice really belongs here.

> Thanks for considering this feedback on a very important draft.

Thanks for your feedback!

Peter

-- 
Peter Saint-Andre
https://andyet.com/