Hi Sean,
Thanks for the detailed review. This'll all go into the next revision of
the draft.
Best,
Yaron
On 10/03/2014 12:20 AM, Sean Turner wrote:
Is this what you were looking for:
Hi authors,
I’ve recently read the -04 version of the draft and have a couple of couple and
some
questions comments. I guess I’d categorize the comments as editorial but this
draft is
about explaining things to non-sec folks I hope you’ll entertain them:
0) s1, para1:
- If I weren’t a security guy I might ask what on earth are AES-CBC and RC4
(beyond
some well-intentioned IESGer asking you to expand the acronyms).
- The 2nd sentence talks about its most common suites/modes and then it’s
repeated
in the 3rd sentence - there’s probably no need to repeat in the context of TLS.
- "which together comprise most current usage” I think is saying are widely
deployed.
- I’d also just use see [] instead of the extra sentence.
- Maybe just put the bridge between the 1st paragraph and the rest of the intro
in
para 1.
how about:
Transport Layer Security (TLS) and Datagram Transport Security Layer
(DTLS) are widely used to protect data exchanged over application
protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the
last few years, several serious attacks on TLS have emerged,
including attacks on its most commonly used cipher suites and modes
of operation, e.g., AES-CBC and RC4 have been attacked (see
[I-D.ietf-uta-tls-attacks]). To address these attacks, this document
provides
guidance to those who implement and deploy TLS and DTLS.
1) s1, para 2-4 and s2:
Actually now that I read farther, it seems like this draft ought to tell you
who it’s for,
what it’s for, and how it’s going to do it. It also seems like the intro and
audience
section ought to be combined to cut down on some of the duplication. Might I
suggest:
adding the following the end of the 1st para:
Unless otherwise noted, these recommendations apply to both TLS and DTLS
implementations prior to version 1.3; TLS 1.3, when standardized and deployed
in the field, should resolve the current vulnerabilities while providing
significantly better functionality.
and then follow on with:
The deployment recommendations address the operators of application
layer services that are most commonly used on the Internet, including
but not limited to:
o Operators of WWW servers that wish to protect HTTP with TLS.
[spt: The bullets ought to be parallel.]
o Operators of email servers who wish to protect the application-
layer protocols with TLS (e.g., IMAP, POP3, or SMTP between client
and server).
o Operators of instant-messaging services who wish to protect their
application-layer protocols with TLS (e.g. XMPP or IRC between
client and server).
[spt: IRCS is listed here and SIP is listed in para1 - intentional?]
Stricter recommendations can be specified by individual protocols and
when specified deployers adhere to them.
[spt: I don’t think you need the MUST here. Deployers will just do implement
the stricter recommendations.]
The implementation recommendations address the options that TLS and
DTLS implementations make or not make available to deployers.
The recommendations address the utilization of all of the security services
provided by TLS, which include the following three services:
o Confidentiality: all (payload) communication is encrypted with the
goal that no party be able to decrypt it except the
intended peer.
o Data integrity: any changes made to the communication are
detectable by the peer.
o (optionally) Authentication: the peer is the intended entity to which
communication is desired. TLS support authentication of one or
both peers (i.e., server authentication or server and client
authentication).
This document does not address the rare deployment scenarios where
one of these three properties is not desired. In fact, it is so rare that
deployers
need to verify carefully consider why they need to deviate from the
recommendations provided in this document. An example of an audience
not needing confidentiality is the following: a monitored network where the
authorities in charge of that traffic domain require full access to
unencrypted
(plaintext) traffic, and where users collaborate and send their traffic in
the
clear.
The recommendations herein take into consideration the security of
various mechanisms, their technical maturity and interoperability,
and their prevalence in implementations at the time of writing.
For example, this document calls for the deployment of algorithms
that are widely implemented but not yet widely deployed.
Community knowledge about the strength of various algorithms and
feasible attacks can change quickly, and experience shows that a
security BCP is a point-in-time statement. Readers are advised to
seek out any errata or updates that apply to this document.
and then just renumber the remaining sections.
2) s4.*: seems like we should be consistent about the use of requirement
followed by rationale. Not all of the sections follow the same script.
3) s4.1:
a) It seems like the base rationale is support AEAD algorithms so that leads us
to TLS 1.2. It seems like we ought to just say that as opposed to leaving it to
a later section.
b) r/SSLv2 is considered today as insecure [RFC6176].
/Today, SSLv2 is considered insecure [RFC6176].
c) ssl3: The rationale for SSLv3 not supporting some extensions begs the
question - which ones.
d) You could also tweak the intro a little:
It is important both to stop using old, less secure versions of SSL/
TLS and to start using modern, more secure versions; therefore, the following
are the recommendations concerning TLS/SSL protocol versions:
4) s4.2: This section kind of comes out of nowhere. Maybe make 4.1 4.1.1. for
SSL/TLS Protocol Versions and then make s4.1.2. DTLS Protocol Versions and then
you can use the same layout:
The following are the recommendations with respect to DTLS:
o Implementations MAY negotiate DTLS version 1.1 [RFC4347].
o Implementations MUST negotiate DTLS version 1.1 [RFC6347].
Rationale: DTLS is an adaptation of TLS for UDP datagrams that was
introduced when TLS 1.1 was published. Version 1.0 correlates to TLS 1.1
and Version 1.2 correlates to TLS 1.2. There is no DTLS 1.1 or “DSSL"
equivalent.
NOTE: DTLS and TLS are nearly identical. The most notable exception is that
RC4, which is a steam-based bulk encryption algorithm, cannot be supported by
DTLS.
5) s4.3: Two things:
a) Is the section title right - if it’s SSL or TLS fallback maybe we can just
call it “Fallback”.
b) I think we should stick to the requirement followed by rationale where we
can:
Clients that “fallback" to lower versions of the protocol after the server
rejects higher versions of the protocol to MUST NOT fall back to SSLv3.
Rationale: Some client implementations revert to lower versions of TLS or
even
to SSLv3 if the server rejected higher versions of the protocol.
This fall back can be forced by a man in the middle (MITM) attacker.
TLS 1.0 and SSLv3 are significantly less secure than TLS
1.2, the version recommended by this document. While TLS 1.0-only
servers are still quite common, IP scans show that SSLv3-only servers
amount to only about 3% of the current Web server population.
6) s4.4: I read the attack in uta-attacks draft and it’s a little more
complicated than expressed in the 1st sentence. I would do the following:
To prevent SSL stripping:
and have the bullets
follow that with the Rationale: paragraph. It never really explains how it
protects - i.e., everything is integrity protected so you’d notice if something
changed.
7) s4.5: Again requirement followed by rationale:
Implementations and deployments SHOULD disable TLS-level compression
([RFC5246], Sec. 6.2.2).
Recommendation: TLS-level compression has been subject to security attacks …
8) s4.6-8: probably sounding like a broken record: requirement followed by
rationale.
9) s5: I think some of the intro para is a bit strong. Some suites are weak,
some are just fine they just don’t give you all the services we’re targeting:
TLS and its implementations provide considerable flexibility in the
selection of cipher suites. Unfortunately, some available cipher
suites are insecure, some do not provide the targeted security
services, and some no longer provide enough security. Incorrectly
configuring a server leads to no or reduced security. This section
includes recommendations on the selection and negotiation of
cipher suites.
10) s5.1: I think we really ought to drive it home that stuff needs to be
updated, so how about we add a bit more to the intro:
Cryptographic algorithms weaken overtime as cryptanalysis improves. In other
words, as time progresses, algorithms that were once considered strong but
are
now weak need to be phased out over time and replaced with more secure
cipher suites to ensure the . SSL/TLS has been in existence for almost 20
years
at this point and this section provides some much needed recommendations
concerning cipher suite section:
11) s5.1 null cipher suites: I assume you’re referring to the NULL encryption
cipher suites and not the TLS_NULL_WITH_NULL_NULL. It’s probably more precise
to say:
Implementations MUST NOT negotiate the cipher suites with NULL encryption.
and maybe we could make the rationale slight more scary:
Rationale: The NULL cipher suites does not encrypt traffic. It provides
no confidentiality services. Any entity in the network with access to the
connection can view the contents being exchanged by the client and
server unaided.
12) s5.1 RC4 might be worth noting RC4 isn’t available to DTLS - maybe not not
sure.
13) s5.1 40-bit and 112 bits: I think you can lump these two together and
provide one rationale based on RFC 3766, which provides a rule of thumb for
bits of security:
Implementations MUST NOT negotiate cipher suites
offering less than 112 bits of security including the so-called
"export-level” encryption that provide 40 or 56 bits of security.
[spt: I let you fill in the # below.]
Rationale: Based on [RFC3766], X bits of security is needed. 40-bit
and 56-bit security are considered insecure today. TLS 1.1/2 never
negotiate 40-bit or 56-bit export ciphers.
14) s5.1 128-bit recommendation: I’d move the 2nd and 3rd sentence to the
rationale.
15) s5.1 128-bit rationale: I have to admit I’m a little confused by the first
sentence in the rationale. Which cipher suites the ones between 112-128 or
128? How about:
Rationale: Cipher suites that offer between 112-bits and 128-bits of security
are not considered weak at this time, it is expected that their useful
lifespan
is short enough to justify supporting stronger cipher suites at this time.
128-bit ciphers are expected to remain secure for at least several years,
and 256-bit ciphers "until the next fundamental technology breakthrough".
Note that
some legacy cipher suites (e.g. 168-bit 3DES) have an effective
key length which is smaller than their nominal key length (112
bits in the case of 3DES). Such cipher suites should be evaluated
according to their effective key length.
16) s5.2: I’d delete the paragraph after the bullets - it’s about negotiation
and it’s repeated in s5.3.
17) s5.2: Is it worth noting somewhere in s5.2 that this is only really going
to work if the deployer configures their client/server to order these suites
somehow?
18) s5.3: If this section is targeted just at stack implementers maybe it
should say so.
19) s5.4: There should be an introductory paragraph to note that there are two
kinds of public keys used: one for key agreement and one for authentication.
With the definition of bare keys should the authentication requirement be
generalized to include 2048-bit keys?
20) s5.5: It’s unclear to me what “the same cipher suite” is in bullet 3. It
would be clearer to just repeat it.
21) s5.6: Start with the recommendation end with the Rationale:.
22) s7.2: r/Sec. Section 5.2/Section 5.2
spt
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
