Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)
RFC 7457

Note: This ballot was opened for revision 04 and is now closed.

(Stephen Farrell) Yes

Comment (2014-10-13 for -04)
No email
send info
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?

(Barry Leiba) Yes

Comment (2014-10-14 for -04)
No email
send info
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.)

(Kathleen Moriarty) (was Discuss) Yes

Comment (2014-10-23)
No email
send info
Thanks very much for your work on this draft.  I appreciate the additions made from my discuss to cover a couple attack methods.

(Pete Resnick) Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

(Richard Barnes) No Objection

Comment (2014-10-15 for -04)
No email
send info
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.

(Benoît Claise) No Objection

(Adrian Farrel) No Objection

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

Comment (2014-10-16 for -04)
No email
send info
would like to see the term downgrade used in the document where appropiate.

(Martin Stiemerling) No Objection