Deprecating Secure Sockets Layer Version 3.0

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

(Ben Campbell) Yes

(Stephen Farrell) Yes

(Brian Haberman) Yes

(Joel Jaeggli) Yes

Barry Leiba Yes

Comment (2015-04-07 for -02)
No email
send info
The abstract says (as it should) that this updates all versions of TLS... yet the metadata only updates 1.2.  For most situations I'd think that appropriate (no need to update the ones that are obsoleted), but in this case the deployment of earlier versions is sufficiently widespread (and, after all, you do have them as normative references) that I think we should add 2246 and 4346 to the "updates" list.  Note, though, that this is not a DISCUSS, so I'll leave it to y'all to decide what's best.

I think prohibiting-rc4 doesn't need to be a normative reference; I'd make it informative.  I think the same is true for RFC 4492.

-- Section 3 --
Pretty short litany, here, really.  I guess it's not the whole megillah.  Jus' sayin'.

(Kathleen Moriarty) Yes

(Martin Stiemerling) Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

Deborah Brungard No Objection

(Spencer Dawkins) No Objection

Comment (2015-04-06 for -02)
No email
send info
Thank you for writing this. Even the transport dorks know it matters. I wish you had used the word "die" in the draft name more than three times, but you're the experts :-)

I'm not parsing this text the way I think you want me to:

   The predecessor of SSLv3, SSL version 2 [RFC6101], is no longer
   considered secure [RFC6176].  SSLv3 now follows.
I'm struggling with "is no longer considered secure" in the present tense, describing an action taken several years ago.

Is the point that negotiating SSLv2 was prohibited in 2011 because SSLv2 was no longer considered secure, and negotiating SSLv3 is now being prohibited in the same way, for the reasons listed in this document?

If so, saying something like that might be clearer ...

(Terry Manderson) No Objection

Alvaro Retana No Objection