Shepherd writeup
rfc7633-10

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.



Back