Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)
draft-ietf-uta-tls-attacks-05
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2015-02-04
|
05 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2015-02-03
|
05 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2015-01-23
|
05 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2015-01-04
|
05 | (System) | IANA Action state changed to No IC |
2015-01-02
|
05 | Cindy Morgan | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2015-01-02
|
05 | (System) | RFC Editor state changed to EDIT |
2015-01-02
|
05 | (System) | Announcement was received by RFC Editor |
2015-01-01
|
05 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2015-01-01
|
05 | Cindy Morgan | IESG has approved the document |
2015-01-01
|
05 | Cindy Morgan | Closed "Approve" ballot |
2015-01-01
|
05 | Cindy Morgan | Ballot approval text was generated |
2014-12-29
|
05 | Pete Resnick | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed |
2014-10-30
|
05 | Tero Kivinen | Request for Telechat review by SECDIR Completed: Has Nits. Reviewer: David Harrington. |
2014-10-30
|
05 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to David Harrington |
2014-10-30
|
05 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to David Harrington |
2014-10-30
|
05 | Gunter Van de Velde | Request for Last Call review by OPSDIR Completed: Ready. Reviewer: David Harrington. |
2014-10-27
|
05 | Pete Resnick | Need to review before final approval |
2014-10-27
|
05 | Pete Resnick | IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation::AD Followup |
2014-10-23
|
05 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'No Response' |
2014-10-23
|
05 | Kathleen Moriarty | [Ballot comment] Thanks very much for your work on this draft. I appreciate the additions made from my discuss to cover a couple attack methods. |
2014-10-23
|
05 | Kathleen Moriarty | [Ballot Position Update] Position for Kathleen Moriarty has been changed to Yes from Discuss |
2014-10-22
|
05 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2014-10-22
|
05 | Yaron Sheffer | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2014-10-22
|
05 | Yaron Sheffer | New version available: draft-ietf-uta-tls-attacks-05.txt |
2014-10-16
|
04 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2014-10-16
|
04 | Cindy Morgan | Changed consensus to Yes from Unknown |
2014-10-16
|
04 | Pete Resnick | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2014-10-16
|
04 | Joel Jaeggli | [Ballot comment] would like to see the term downgrade used in the document where appropiate. |
2014-10-16
|
04 | Joel Jaeggli | Ballot comment text updated for Joel Jaeggli |
2014-10-16
|
04 | Joel Jaeggli | [Ballot comment] would like to see the termdowngrade used in the document where appropiate. |
2014-10-16
|
04 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2014-10-15
|
04 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2014-10-15
|
04 | Richard Barnes | [Ballot comment] It might be useful to note that SSL stripping is a flavor of downgrade attack. Likewise, it could be worth noting in this … [Ballot comment] It might be useful to note that SSL stripping is a flavor of downgrade attack. Likewise, it could be worth noting in this section or Section 2.2 that STARTTLS is very vulnerable to downgrade without some sort of HSTS-like mechanism. For example, there's some recent evidence of downgrade attacks on mail protocols. Downgrade in general could use more attention. The IETF can fix things in newer versions of the protocol, but if the client and server can't negotiate that version, it's all for naught. https://www.techdirt.com/blog/netneutrality/articles/20141012/06344928801/revealed-isps-already-violating-net-neutrality-to-block-encryption-make-everyone-less-safe-online.shtml Given the news about POODLE this week, I would suggest changing Section 2.4 to be "Padding Oracle Attacks", and adding POODLE there. I'm surprised not to see some mention of Heartbleed in Section 2.13. |
2014-10-15
|
04 | Richard Barnes | [Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes |
2014-10-15
|
04 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
2014-10-15
|
04 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2014-10-14
|
04 | Barry Leiba | [Ballot comment] A tiny thing in the Introduction: "suffice it to say" may sound cute, but if it were really sufficient, the document could stop … [Ballot comment] A tiny thing in the Introduction: "suffice it to say" may sound cute, but if it were really sufficient, the document could stop there. I suggest replacing "suffice it to say" with "a quick summary is". But take this or leave it as you please. My other comment is more significant: -- Section 2.13 -- o Implementations may not validate the server identity. This validation typically amounts to matching the protocol-level server name with the certificate's Subject Alternative Name field. Note: historically, although incorrect, this information is also often found in the Common Name part of the Distinguished Name instead. I had to read the "note" a few times before I followed it. It's not the information that's incorrect, and the "also ... instead" bit is confusing. But the biggest problem is that it's unclear what the incorrect thing IS: is it that the information is put in the CN and shouldn't be? Or is it that validators retrieve it from there instead of from the SAN? Maybe this (correct it as necessary)?: NEW o Implementations might not validate the server identity. This validation typically amounts to matching the protocol-level server name with the certificate's Subject Alternative Name field. Note: this same information is often in the Common Name part of the Distinguished Name also, and some validators incorrectly retrieve it from there instead of from the Subject Alternative Name. (That also changes the "may" to "might", to avoid accidentally conveying a sense of permission.) |
2014-10-14
|
04 | Barry Leiba | [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba |
2014-10-14
|
04 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2014-10-13
|
04 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2014-10-13
|
04 | Kathleen Moriarty | [Ballot discuss] Thank you for your work on this draft! It looks great, but I do have two items I'd like to discuss and see … [Ballot discuss] Thank you for your work on this draft! It looks great, but I do have two items I'd like to discuss and see if we can add text to address these concerns/attacks before switching to a yes. 1. I think it would be very helpful to include what techniques are used by forensic tools that enable access to decrypt TLS sessions and how to respond/prevent that access. I see you have certificate attacks listed in 2.7, which is what the common forensic tools leverage. However, these tools also require access to the private key, and it would be helpful to mention the importance of protecting the private key, preventing exportability, etc.. In 2.7 I thin it would be helpful to explicitly state that commonly used forensic tools such as wireshark require access to the private key as well as use of RSA. Another option might be to add the recommendation to protect the private key in 2.13. If you can't export the key (from an implementation perspective), that could go a long way to helping to reduce this method of exposure. I've included a few links for additional information on the list of tools and explicit details of the attack used in case this is helpful. Forensic tools that rely on a MiTM attack to decrypt TLS and DTLS session: http://forensicswiki.org/wiki/SSL_forensics Wireshark requires you have the key: http://support.citrix.com/article/CTX116557 Mitigations are to protect the private key and to not use RSA: http://wirewatcher.wordpress.com/2010/07/20/decrypting-ssl-traffic-with-wireshark-and-ways-to-prevent-it/ http://wiki.wireshark.org/DTLS?highlight=%28tls%29 If you would like text suggestions, let me know and I'll help. 2. I realize this draft covers explicit attacks against TLS, however since pervasive monitoring is considered an attack, it could be helpful for this draft also cover techniques used by middle boxes to intercept TLS streams (proxy firewalls, load balancers, etc.). Although these are more of 'attacks' on the user, than of TLS, it could be a short addition to have this documented. The TLS session is intercepted, or in the case of a load balancer it might be terminated, with a second TLS session initiated to the destination allowing traffic to pass in the clear on the middlebox. The user is alerted and warned to accept an untrusted certificate in this process, and many do as a result of corporate restrictions (they have no choice if they want to go to that site). Perhaps implementation recommendations could assist here to improve the warnings to the user, letting them know their traffic may be passing in the clear and they may not want to continue with their session. Some may chose to avoid certain transactions from the work place as a result. If you have already discussed these items and decided they were out of scope, please let me know. I support this work and just wanted to make sure we covered all bases or put some out of scope. Thank you. |
2014-10-13
|
04 | Kathleen Moriarty | [Ballot Position Update] New position, Discuss, has been recorded for Kathleen Moriarty |
2014-10-13
|
04 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2014-10-13
|
04 | Stephen Farrell | [Ballot comment] I have a number of nits. Please treat them as such. - Is "current" correct in the name for an RFC? Perhaps "known" … [Ballot comment] I have a number of nits. Please treat them as such. - Is "current" correct in the name for an RFC? Perhaps "known" is better. - intro, para 2: s/is tasked/was tasked/ - s2, 2nd para: "a more systemic solution" is left hanging - do you mean TLS1.3? If so, maybe say so? - 2.5, 2nd para: draft-ietf-tls-prohibiting-rc4 does not itself provide those details, maybe say "see the references in" that draft? - 2.6: should the RFC editor wait on the official allocation of the BEAST CVE number? I don't think that's happened already has it? - 2.7, is Bleichenbacher really a certificate attack? I think its not, but is a pkcs#1 encryption attack. (It would apply just as well to OOB keys in TLS.) I'm not sure if Klima is or is not the same in that respect. Also the timing attacks in the 2nd para, don't seem to be certificate related are they? So perhaps only the last para is really certificate related? - 2.8: I forget if this has been discussed - should three be a reference to draft-ietf-tls-negotiated-ff-dhe - 2.10: isn't TRIPLE-HS published yet? - 2.12: A reference would be good here if we have one, esp. for the "It is known" point. - 2.13, para1: "fully specified" isn't really correct there, I think you mean 'properly specified, so that implementations should be "secure"' but maybe some other wording would be better. - 2.13: Doesn't that paper also blame hard-to-use APIs as well as the IETF protocols and their complexity? Worth a mention? |
2014-10-13
|
04 | Stephen Farrell | [Ballot Position Update] New position, Yes, has been recorded for Stephen Farrell |
2014-10-13
|
04 | Pete Resnick | Ballot has been issued |
2014-10-13
|
04 | Pete Resnick | [Ballot Position Update] New position, Yes, has been recorded for Pete Resnick |
2014-10-13
|
04 | Pete Resnick | Created "Approve" ballot |
2014-10-13
|
04 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2014-10-10
|
04 | Meral Shirazipour | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Meral Shirazipour. |
2014-10-10
|
04 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2014-10-10
|
04 | Amanda Baber | IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-uta-tls-attacks-04, which is currently in Last Call, and has the following comments: We understand that this document doesn't require … IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-uta-tls-attacks-04, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any IANA actions. While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object. If this assessment is not accurate, please respond as soon as possible. |
2014-10-08
|
04 | Jean Mahoney | Request for Last Call review by GENART is assigned to Meral Shirazipour |
2014-10-08
|
04 | Jean Mahoney | Request for Last Call review by GENART is assigned to Meral Shirazipour |
2014-10-02
|
04 | Jean Mahoney | Request for Last Call review by GENART is assigned to Meral Shirazipour |
2014-10-02
|
04 | Jean Mahoney | Request for Last Call review by GENART is assigned to Meral Shirazipour |
2014-10-02
|
04 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to David Harrington |
2014-10-02
|
04 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to David Harrington |
2014-10-02
|
04 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Dacheng Zhang |
2014-10-02
|
04 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Dacheng Zhang |
2014-09-29
|
04 | Pete Resnick | Placed on agenda for telechat - 2014-10-16 |
2014-09-29
|
04 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2014-09-29
|
04 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Summarizing Current Attacks on TLS … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Summarizing Current Attacks on TLS and DTLS) to Informational RFC The IESG has received a request from the Using TLS in Applications WG (uta) to consider the following document: - 'Summarizing Current Attacks on TLS and DTLS' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-10-13. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Over the last few years there have been several serious attacks on TLS, including attacks on its most commonly used ciphers and modes of operation. This document summarizes these attacks, with the goal of motivating generic and protocol-specific recommendations on the usage of TLS and DTLS. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-uta-tls-attacks/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-uta-tls-attacks/ballot/ No IPR declarations have been submitted directly on this I-D. |
2014-09-29
|
04 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2014-09-29
|
04 | Pete Resnick | Last call was requested |
2014-09-29
|
04 | Pete Resnick | Ballot approval text was generated |
2014-09-29
|
04 | Pete Resnick | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2014-09-29
|
04 | Pete Resnick | Last call announcement was generated |
2014-09-29
|
04 | Pete Resnick | Last call announcement was generated |
2014-09-29
|
04 | Pete Resnick | Ballot writeup was changed |
2014-09-29
|
04 | Pete Resnick | Ballot writeup was generated |
2014-09-29
|
04 | Pete Resnick | Notification list changed to : uta-chairs@tools.ietf.org, draft-ietf-uta-tls-attacks@tools.ietf.org, uta@ietf.org |
2014-09-28
|
04 | Yaron Sheffer | New version available: draft-ietf-uta-tls-attacks-04.txt |
2014-09-28
|
03 | Pete Resnick | AD Eval complete. Waiting on WG to decide if we should hold off on Last Call until BCP is also ready. |
2014-09-28
|
03 | Pete Resnick | IESG state changed to AD Evaluation::AD Followup from AD Evaluation |
2014-09-18
|
03 | Pete Resnick | IESG state changed to AD Evaluation from Publication Requested |
2014-09-09
|
03 | Leif Johansson | 1. Summary Leif Johansson is the shepherd. Pete Resnick is the responsible AD The shepeard believs the document is ready to go. Abstract ----------- Over … 1. Summary Leif Johansson is the shepherd. Pete Resnick is the responsible AD The shepeard believs the document is ready to go. Abstract ----------- Over the last few years there have been several serious attacks on TLS, including attacks on its most commonly used ciphers and modes of operation. This document summarizes these attacks, with the goal of motivating generic and protocol-specific recommendations on the usage of TLS and DTLS. ----------- The document is intended for publication as an Informational RFC 2. Review and Consensus The document has received extensive review on the uta list by several reviewers (not just the usual suspects). There have been a few near-miss consensus, but they were all resolved to the satisfaction of all involved. Most of the reviewers / active participants have ties to information security or TLS specifically. Additional review in the secdir group should probably try to find a person with another perspective. 3. Intellectual Property No issues 4. Other points The ID nits page lists an obsoleted reference RFC 4347 (Obsoleted by RFC 6347) but that can probably be delt with as an RFC editors note. There are no IANA considerations. |
2014-09-09
|
03 | Leif Johansson | State Change Notice email list changed to uta-chairs@tools.ietf.org, draft-ietf-uta-tls-attacks@tools.ietf.org |
2014-09-09
|
03 | Leif Johansson | Responsible AD changed to Pete Resnick |
2014-09-09
|
03 | Leif Johansson | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2014-09-09
|
03 | Leif Johansson | IESG state changed to Publication Requested |
2014-09-09
|
03 | Leif Johansson | IESG process started in state Publication Requested |
2014-09-09
|
03 | Leif Johansson | Changed document writeup |
2014-09-09
|
03 | Leif Johansson | Tag Revised I-D Needed - Issue raised by WG cleared. |
2014-09-09
|
03 | Leif Johansson | IETF WG state changed to WG Consensus: Waiting for Write-Up from Waiting for WG Chair Go-Ahead |
2014-09-09
|
03 | Leif Johansson | Document shepherd changed to Leif Johansson |
2014-09-09
|
03 | Leif Johansson | Intended Status changed to Informational from None |
2014-09-09
|
03 | Yaron Sheffer | New version available: draft-ietf-uta-tls-attacks-03.txt |
2014-09-03
|
02 | Leif Johansson | Waiting for another revision including WGLC comments. |
2014-09-03
|
02 | Leif Johansson | Tag Revised I-D Needed - Issue raised by WG set. |
2014-09-03
|
02 | Leif Johansson | IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call |
2014-08-18
|
02 | Leif Johansson | IETF WG state changed to In WG Last Call from WG Document |
2014-08-12
|
02 | Yaron Sheffer | New version available: draft-ietf-uta-tls-attacks-02.txt |
2014-06-23
|
01 | Yaron Sheffer | New version available: draft-ietf-uta-tls-attacks-01.txt |
2014-03-27
|
00 | Peter Saint-Andre | New version available: draft-ietf-uta-tls-attacks-00.txt |