1. Summary
What happens when there’s a downgrade attack on the TLS protocol? The TLS
protocol takes care of it - right? Well TLS does wrt to cipher suites, version
#s, etc., but TLS doesn’t when it comes to ancillary “features” such validating
client credentials through OCSP. To address this shortcoming, the TLS feature
certificate extension is placed into the server certificate to indicate that
clients ought to expect a “feature” be returned to them in the server’s
handshake messages - if absent the connection should be terminated. Currently,
the mechanism is targeted at OCSP responses, but the mechanism is defined
generically to allow for other “features” that are as yet undefined.
Please pay attention to s1, we don’t want ADs to be confused by the fact that
there are both TLS and Certificate extensions. You’ll need to keep s1 in mind
when reading the draft to avoid getting confused.
Also, this draft ought *not* update TLS because not every TLS implementation
need support this extension. As the draft rightly points out, support for this
extension is optional.
Stephen Farrell has kindly offered to AD sponsor this draft.
Sean Turner is the shepherd. Sean’s thought this was a good idea since the
-00. In fact, way back in the day when he was an AD he offered to AD sponsor
the draft.
2. Review and Consensus
This draft is not the result of WG consensus process - it’s AD-sponsored.
If PKIX was still alive and kicking this draft would have been a great fit, but
alas PKIX lives no more. In fact, PKIX was in its death throes when this draft
1st appeared. Luckily, the forward thinking ADs at the time spared the life of
the PKIX mailing list and PHB has dutifully keep those still reading PKIX
apprised of updates based on input he’s received.
PHB also took it upon himself to query the TLS mailing for input (see the
thread in April 2014). Without fail they provided their thoughts.
Note that there was support from multiple sources (this list is not complete -
it’s just to give you a sense that there were folks who were in favor of the
solution proposed by the draft):
[1] http://www.ietf.org/mail-archive/web/pkix/current/msg33039.html
[2] http://www.ietf.org/mail-archive/web/tls/current/msg12334.html
[3] http://www.ietf.org/mail-archive/web/tls/current/msg12300.html
3. Intellectual Property
The shepherd has confirm that the author has stated that their direct, personal
knowledge of any IPR related to this document has already been disclosed, in
conformance with BCPs 78 and 79.
4. Other Points
o IETF LC should probably be forwarded to the TLS, PKIX, and TRANS mailing
lists. That way nobody in the IETF that’s in the PKI space is going to be able
to say they missed the LC.
o DOWNREFs: None.
o IANA Considerations: Section looks good and we get to be the first draft to
get an official assignment out of Russ Housley the designated expert for the
id-pe registry. I believe a request for an OID was made about a year ago, but
Russ was in the process of handing back the OID ARC to IANA. That transition
has completed so there should be no more holdups.
o Random Point: My dog, Lola, likes snow.
o Expert reviews: There’s no ASN.1 in this draft so I don’t there’s any
additional review required. Further, forwarding the IETF LC to the WGs listed
above ought to ensure review from the “PKI” mafia.