Hi Trevor,
Please see further comments inline.
Thanks,
Yaron
On 07/17/2014 11:02 PM, Trevor Freeman wrote:
Hi Yaron,
Thanks for the response. See inline
-----Original Message-----
From: Uta [mailto:[email protected]] On Behalf Of Yaron Sheffer
Sent: Sunday, July 06, 2014 12:09 PM
To: Trevor Freeman; [email protected]
Subject: Re: [Uta] TLS BCP 01 Draft
Hi Trevor, thanks for your review. Please see my comments in line.
On 06/30/2014 09:11 PM, Trevor Freeman wrote:
General Comments.
There are still no definition on what constitutes best protection
against monitoring i.e. what offers best, adequate or minimal
protection against monitoring. Give one of the goal is to move the
internet to better protect against this kind of activity, we need to
clarify which actions in this draft best enable that goal and not just
providing basic interoperability.
These are lofty goals indeed. But the draft's goal is not to define "best protection against
monitoring", let alone to define 3 levels of such protection. It is simply to remediate issues
with the way TLS is currently deployed. I don't think we "just provide basic
interoperability", I believe we provide strictly better security, within the constraints of
current technology and interoperability.
[TF] The strategy for the ietf's response is to increase the cost of those
activates by making it more expensive to read the traffic. You already hint
that some aspects provide better security that others by the keywords you use
to devein what must, should, may or should not be done.
Sorry, I still do not understand what you would like to see changed in
the draft WRT this comment.
Section 3.4 and 4.1 needs to be consolidated as there is a lot of
overlap between the two sections.
I am not sure about the overlap, and would appreciate specific points.
[TF] Overall I don’t see any logic behind the split between section 3 and 4
which is what I mean by overlap. A lot of what's in section 3 seems pretty
detailed. It's much easier to read if the bottom line of what we need you to do
in in one place.
I agree that Sec. 3.4 suffered some "feature creep" and became too long.
I suppose it could be trimmed down or broken into several subsections.
The logic is that Sec. 3.4 provides reasoning for selecting preferred
cipher suites, leading to a list of recommended cipher suites. Sec. 4.1
builds on this list, and tells the implementer/deployer how to use it.
I think it is good to provide rational behind the recommendations for
various cipher sites, it leaves the reader with some interpretation
between that and the actual cipher suites. It would be better to
actually list the cipher suites in question to remove any scope for
misinterpretation.
The first part of Sec. 3.4 provides more than half a page of rationale for the
cipher suite selection.
Also support for the SNI is missing from the draft. This is a
mandatory for any application interacting with a service.
Quoting my own earlier response to you (my mail of June 21): "I'm all in favor of
using SNI. But as far as the draft goes, I believe this is an operational decision, and
so we should not include such a recommendation."
[TF] The implementers are totality ignorant of the operational choice made by
the server so is in no position to make an informed decision hence the need to
mandate.
OK, I get your point. SNI is important enough to mandate its
implementation. Whether it needs to be used in particular cases, is up
to operations people.
Specific comments.
Section 3.2 still treats SSL 3.0 differently to TLS 1.0. Why is it ok to
fall back to TLS 1.0 but not SSL 3.0 if both offer the same security?
This is a good question. I believe the answer is, because much of the
server population still only supports TLS 1.0, and if we recommend
otherwise, the recommendation will be ignored for (justified)
interoperability reasons. But I may be wrong about the prevalence of
such servers.
[TF] Give the similarity of the security properties of SSL 3.0 and TLS 1.0, I
am still unclear why you consider it is ok to fall back 1.0 and not 3.0. The
only rational I can think of is given the similarities the likelihood of
success with SSL 3.0 if TLS 1.0 fails is pretty small but that seems a weak
case for a prohibition.
See my response in a separate email.
Section 3.4.
bullet 3. Implementations MUST NOT negotiate cipher suites with an
effective key length of less than 112
I can live with this.
bullet 5 Implementations SHOULD prefer cipher suites with greater than
128 bits of effective key length
No, this contradicts our recommendation, and IMO is too strict for the
current state of the industry. In other words, people are perfectly
happy with AES-128 today and it is NOT our goal to push to AES-256.
[TF] This is a less redundant interpretation of how I read this bullet. The read the "if
possible 256" part overriding the "at least 128 bit" part. The base 1.2 rfc already
mandates 128 bit ciphers as a MUST. What are you trying to convey with this bullet?
The current wording is a bit vague: "Implementations SHOULD prefer
cipher suites that use algorithms with at least 128 (and, if possible,
256) bits of security." But I think it makes sense in the context of
leading up to the list of cipher suites.
bullet 6 Given the foregoing considerations, implementation of the
following suites are recommended (in order of preference)
·TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
·TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
·TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
·TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
Rational: In the preceding bullet we give preference to cipher with 256
bit key
Again, we disagree on this point.
Also client MUST send an ec_point_formats extension
As I mentioned earlier, "RFC 4492 specifies the MUST/SHOULD status for
these extensions. I don't think we should be repeating or overriding that."
[TF] I agree that the base RFC should be authoritative however I less convinced
all implementers are totally diligent in recusing though every aspect of every
normative reference and would like to some language on the need to follow rfc
4492 guidance on this extension. Rfc's are complex documents and it is all too
easy to miss something
OK, as Ralph noted, we will include the relevant RFC 4492 extensions in
the next revision.
3.5 public key lengths.
Public key algorithms based on integer factorization or discrete
logarithms MUST use a public key size of at least 2048 bits.
This is currently a SHOULD-level requirement (we use the equivalent term
RECOMMENDED). Given the problems with modular DH in TLS, I'm afraid we
cannot mandate >2048 because of the interoperability issues, and because
some people might value forward secrecy over key length.
[TF] Then we need to differentiate static from ephemeral use cases.
Implementations MUST support end entity public keys in certificates based on
integer factorization or discrete logarithms of at least 2048 bits.
Implementations MUST support ephemeral discrete logarithms public keys of at
least 1024 bits.
I would like to add a rider to do better that 1024 bit but give the inability
of the client to signal what it supports in terms of key sizes, that would be
futile.
I agree we should differentiate between static and ephemeral use cases.
Basically, the section should be broken into "Ephemeral DH" and
"Certificates". We should replace both occurrences of "DH" by "DHE"
(people only care about Ephemeral DH, and our recommended list only
includes DHE and ECDHE cipher suites). And AFAIK, nobody cares about
"certificates based on discrete logarithms" (i.e. DSA certs).
4.1
Clients SHOULD include TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as the
first proposal to any server.
Rational: Section 3.4 bullet 5 says we give preference to ciphers
stronger than 128 bits.
Disagree again.
Clients MUST include the “supported elliptic curve” extension
See above.
[TF] Likewise
Likewise, will be added.
Thanks,
Yaron
Trevor
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
