[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-tls
Subject:    [TLS] TLS Security Policy Draft Update
From:       Phillip Hallam-Baker <hallam () gmail ! com>
Date:       2012-10-20 1:08:28
Message-ID: CAMm+LwhzE02by-HqtDo5VPBeA9eMgrZiCwn_0vLcSqar=+bGdQ () mail ! gmail ! com
[Download RAW message or body]

http://www.ietf.org/id/draft-hallambaker-tlssecuritypolicy-02.txt

I am not proposing this as a PKIX WG item as the plan is to close the
group. It may be of interest to PKIX and TLS members however.

This is a slight generalization of the 'MUST STAPLE' certificate and CSR
extension. Specifically the specification permits two types of security
policy to be specified in an X.509v3 cert.

* Minimum TLS Version
* 'Must Staple OCSP token'

The design is slightly more general so that it can co-exist with TLS
extensions that are similar to OCSP token stapling. For example Certificate
Transparency info.


The big advantage to using this is that it allows a client to check
revocation status and to immediately fail if the OCSP token is not provided
as it should be. At present most clients will only fail if they see an
invalid OCSP token, if the token is not returned, they consider it valid.
To do otherwise opens the client to a DoS attack bu DDoS-ing the OCSP
servers.

Note that the TLS protocol handshake provides protection against most forms
of downgrade attack and most importantly cipher suite downgrade (for later
versions at least). So it is not necessary to wire them into the cert. In
fact the only statements that should be wired into the cert are statements
that the server knows that it can ensure compliance with.


-- 
Website: http://hallambaker.com/

[Attachment #3 (text/html)]

<div><a href="http://www.ietf.org/id/draft-hallambaker-tlssecuritypolicy-02.txt">http: \
//www.ietf.org/id/draft-hallambaker-tlssecuritypolicy-02.txt</a></div><div><br></div>I \
am not proposing this as a PKIX WG item as the plan is to close the group. It may be \
of interest to PKIX and TLS members however.<div> <br></div><div>This is a slight \
generalization of the &#39;MUST STAPLE&#39; certificate and CSR extension. \
Specifically the specification permits two types of security policy to be specified \
in an X.509v3 cert.</div><div> <br></div><div>* Minimum TLS Version</div><div>* \
&#39;Must Staple OCSP token&#39;</div><div><br></div><div>The design is slightly more \
general so that it can co-exist with TLS extensions that are similar to OCSP token \
stapling. For example Certificate Transparency info.</div> \
<div><br></div><div><br></div><div>The big advantage to using this is that it allows \
a client to check revocation status and to immediately fail if the OCSP token is not \
provided as it should be. At present most clients will only fail if they see an \
invalid OCSP token, if the token is not returned, they consider it valid. To do \
otherwise opens the client to a DoS attack bu DDoS-ing the OCSP servers.</div> \
<div><br></div><div>Note that the TLS protocol handshake provides protection against \
most forms of downgrade attack and most importantly cipher suite downgrade (for later \
versions at least). So it is not necessary to wire them into the cert. In fact the \
only statements that should be wired into the cert are statements that the server \
knows that it can ensure compliance with. </div> \
<div><br></div><div><div><br></div>-- <br>Website: <a \
href="http://hallambaker.com/">http://hallambaker.com/</a><br><br> </div>



[prev in list] [next in list] [prev in thread] [next in thread]