Hi Richard, thanks for the thoughtful review. Comments inline.
On 2/18/15 8:34 PM, Richard Barnes wrote:
Richard Barnes has entered the following ballot position for
draft-ietf-uta-tls-bcp-09: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-uta-tls-bcp/
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
I really can't abide by the abdication in Section 5.2.
Abdication is an awfully strong word.
Getting a cert is
hard. Running reasonably recent software and configuring it properly is
not. The possibility that a connection will not be authenticated is no
excuse for using bad versions of TLS or using insecure ciphersuites.
I appreciate that normally deference to WG consensus is appropriate, but
this is a recommendation that could be actively harmful to the Internet
by encouraging the continued use of broken code.
I think the document, then, does not provide clear enough text.
I do not think we intended to actively recommend that anyone run broken
code, use outdated versions of TLS, use insecure ciphersuites, etc.
However, we are saying that this document was not written specifically
to cover unauthenticated TLS usages because that was a point of strong
contention in the WG and we were not able to reach consensus. The thread
beginning here is illustrative:
http://www.ietf.org/mail-archive/web/uta/current/msg00625.html
If you are insisting that this document be remanded to the WG with
instructions that it reach consensus one way or the other, then please
let us know.
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
These COMMENTs are right on the edge of being DISCUSS points, because I
think there are some pretty critical references missing. Please consider
this a COMMENT of Unusual Strength.
Section 1. "which together are the most widely deployed ciphers"
Actually, at least in the web context, this isn't totally true.
According to Firefox telemetry, AES-GCM has been the most widely deployed
cipher since at least 3Q14, and is currently used in the majority of TLS
handshakes that Firefox does (52%) [1].
As a result of addressing a comment from another IESG member, we will be
changing "are" to "have been" in the quoted text.
Section 3.1.1. Implementations MUST NOT negotiate SSL version 3
A reference to draft-ietf-tls-sslv3-diediedie seems in order here.
Are you thinking that would be a normative reference or an informative
reference?
Section 3.1.
It would be good for this section to mention that servers MUST implement
TLS version negotiation. That is, they MUST NOT abort the handshake if
the version offered by the client is higher than the version the server
supports. This is, after all, the root cause of fallback.
Good point.
Section 3.1.3.
I'm surprised that there's not even a SHOULD CONSIDER [RFC6919] for SCSV
here. Did the WG discuss having any requirement for SCSV?
As I recall, the (brief) discussion concluded that a normative
dependency on draft-ietf-tls-downgrade-scsv was not yet appropriate
because it is too new to yet be a best *current* practice.
On a more general note, the WG considered a number of recent proposals
for TLS hardening, but concluded as well that they were too new to
recommend quite yet. There is breaking news (pun intended) every week
about TLS and there's no way that a document like this can reflect the
very latest ideas and suggestions - we tried to balance practices that
are (or might be considered) "best" against practices that are
implemented and can be deployed today. IMHO the most we can do is get
this BCP published and, as needed, update or replace it with improved
recommendations on a regular basis (say, every year or two). This
document was supposed to be published quickly after IETF 88 and is
already late.
Also, if you want a cite for the 3% number, it's in the proceedings of
IETF 91 [2].
Thanks.
Section 3.3.
You might point out HPACK [3] as an example of compression that is
sensitive to things like CRIME.
I see no harm in an informative reference.
Section 3.5.
Shouldn't this refer more specifically to draft-ietf-tls-session-hash
[4]? As it is, the recommendations in this section are kind of vacuous;
e.g., TLS without session-hash provides no way to "bind the master secret
to the full handshake".
Yes, that's what [triple-handshake] cites as well, and I agree that a
pointer to it would be helpful.
Section 4.4. "Modular vs. Elliptic Curve"
I think that "finite field" or "modp" are more common than "modular".
I have been told that elliptic curves are also finite fields, but I am
not a cryptographer.
Peter
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
