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 protected] Fri Nov 14 13:14:42 2014
Date: Fri, 14 Nov 2014 13:14:42 -0500 (EST)
From: joe <[email protected]>
To: [email protected]
Cc: [email protected]
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/
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
