Hi Paul,
Responding just to the first part of your mail:
The document is not advocating 1024-bit DHE. In Sec. 5.5 it lists it as
the third best option, and explains why some deployers might be forced
to use it even though "1024 bit modular DH parameters are generally
considered insufficient at this time".
Re: the TWIRL correction (http://cs.tau.ac.il/~tromer/twirl/): 11 years
on, I wonder why we still don't have any 1024-bit factorizations, given
that the machine's cost should have gone down to around $100K (applying
Moore's law and vigorous hand-waving).
Yes, we need to correct the bit-length estimate.
Thanks,
Yaron
On 10/26/2014 09:26 PM, Paul Hoffman wrote:
On Oct 24, 2014, at 8:21 AM, Leif Johansson <[email protected]> wrote:
This email starts a 2 week WGLC for draft-ietf-uta-tls-bcp-06. Please
provide your comments no later than Friday the 7th of November.
The following is split into three sections in decreasing order of importance.
--Paul Hoffman
*** Huge security issue ***
5.4:
Rationale: because Diffie-Hellman keys of 1024 bits are estimated to
be roughly equivalent to 80-bit symmetric keys, it is better to use
longer keys for the "DHE" family of cipher suites. Key lengths of at
least 2048 bits are estimated to be roughly equivalent to 112-bit
symmetric keys and might be sufficient for at least the next
10 years. See Section 5.5 for additional information on the use of
modular Diffie-Hellman in TLS.
Earlier, the document points to RFC 3766 (thank you), and that document has
different estimates than what the draft has here. From RFC 3766:
====================
+-------------+-----------+--------------+--------------+
| System | | | |
| requirement | Symmetric | RSA or DH | DSA subgroup |
| for attack | key size | modulus size | size |
| resistance | (bits) | (bits) | (bits) |
| (bits) | | | |
+-------------+-----------+--------------+--------------+
| 70 | 70 | 947 | 129 |
| 80 | 80 | 1228 | 148 |
| 90 | 90 | 1553 | 167 |
| 100 | 100 | 1926 | 186 |
| 150 | 150 | 4575 | 284 |
| 200 | 200 | 8719 | 383 |
| 250 | 250 | 14596 | 482 |
+-------------+-----------+--------------+--------------+
5.1. TWIRL Correction
If the TWIRL machine becomes a reality, and if there are advances in
parallelism for row reduction in factoring, then conservative
estimates would subtract about 11 bits from the system security
column of the table. Thus, in order to get 89 bits of security, one
would need an RSA modulus of about 1900 bits.
====================
That is, with a TWIRL correction, 1024-bit keys yield about 65 bits of
equivalent strength, not the 80 listed in the draft. A 2048-bit key would give
about 92 bits of strength.
Of course, the draft can refer to other documents that have happier estimates
of strength for 1024-bit and 2048-bit keys, but that does not help the intended
audience for this document.
*** Large issues ***
1:
TLS 1.3, when it is standardized and deployed in the field,
should resolve the current vulnerabilities while providing
significantly better functionality. It will very likely obsolete
this document.
This is not correct. TLS 1.3 will only deal with a subset of the issues brought
up in this draft, so it will not obsolete this draft. Further, it would only
make this draft obsolete when it is universally deployed, which won't happen in
our lifetimes. Proposed rewording:
It is expected that the TLS 1.3 specification will resolve many of
the vulnerabilities listed in this document. A system that deploys
TLS 1.3 will have fewer vulnerabilities than TLS 1.2 or below. This
document is likely to be updated after TLS 1.3 gets noticeable
deployment.
2.1:
o Confidentiality: all (payload) communication is encrypted with the
goal that no party should be able to decrypt it except the
intended receiver.
Actually, all of the application-layer communication is encrypted, not just
payloads. Proposed rewording:
o Confidentiality: all application-layer communication is encrypted with
the
goal that no party should be able to decrypt it except the
intended receiver.
2.2:
(indeed, often a server will not know whether a
client might attempt authenticated or unauthenticated TLS)
A server can *never* tell whether a client validated the server's certificate.
Proposed rewording:
(indeed, a server cannot know whether a
client might attempt authenticated or unauthenticated TLS)
4.2:
o In many application protocols, clients can be configured to use
TLS even if the server has not advertised that TLS is mandatory or
even supported (e.g., this is often the case in messaging
protocols such as IMAP and XMPP).
What is "advertised" supposed to mean here? The above is certainly not true for
STARTTLS-style protocols. If this is meant to cover protocols that use URI schemes that might or
might not end is "s", those are not server advertisements. I'm not sure how to reword
this because it is too unclear.
5.5:
Rationale: Elliptic Curve Cryptography is not universally deployed
for several reasons, including its complexity compared to modular
arithmetic and longstanding IPR concerns.
If this document wants to spread the IPR FUD, please at least counter it with:
(These concerns have generally been eliminated with the publication of RFC
6090.)
7.3:
Forward secrecy (also often called Perfect Forward Secrecy or "PFS"
and defined in [RFC4949])
... but then the draft refer to "PFS" instead of "forward secrecy". It would be
better to use the more accurate term.
*** Editorial ***
2: s/WWW/web/
2.1:
o Authentication: an end-point of the TLS communication is
authenticated as the intended entity to communicate with. TLS
enables authentication of one or both end-points in the
communication. Some TLS usage scenarios do not require
authentication. They are not in the scope of this document. We
discuss them under Section 2.2.
The last two sentences change from the positive to the negative in a confusing
way. Maybe move those two sentences to their own unbulleted paragraph.
5.4:
Where a
client certificate is used, a third one is added.
To be clearer, that should be "...a third public key is used".
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
