Subject: [pkix] New version of the TLS feature draft

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 3 Sep 2014 16:40:29 -0400

This draft is just a bit of wiring that allows TLS clients to make
intelligent and efficient hardfail decisions when a TLS server
supports OCSP stapling.

OCSP stapling has been supported for some time and when supported by a
server allows a client to obtain OCSP status information direct from
the server rather than going hunting for it from a distribution point.

What makes OCSP stapling rather less useful than it should be is that
a TLS client does not know whether it should expect a TLS token or
not. So the absence of an OCSP token could be because the server does
not support stapling or could be because the CA has revoked the
certificate with extreme prejudice because it is being used to commit
fraud against people visiting the corresponding Web site.

The TLS feature extension allows a certificate to state which TLS
features a server using the cert MUST support. This closes the door on
the downgrade attack.

If the certificate specifies 'server always staples' and the server
does not offer stapling, the client has a very strong signal that
something is wrong and it should either abort the connection
immediately or take some other corrective action.

This version of the document just updates the spec to change the
proposed OID as the one specified previously had been used in an April
Fools RFC and fixes the text accordingly.

A new version of I-D, draft-hallambaker-tlsfeature-05.txt
has been successfully submitted by Phillip Hallam-Baker and posted to the
IETF repository.

Name: draft-hallambaker-tlsfeature
Revision: 05
Title: X.509v3 TLS Feature Extension
Document date: 2014-09-03
Group: Individual Submission
Pages: 8
URL:
http://www.ietf.org/internet-drafts/draft-hallambaker-tlsfeature-05.txt
Status:         https://datatracker.ietf.org/doc/draft-hallambaker-tlsfeature/
Htmlized:       http://tools.ietf.org/html/draft-hallambaker-tlsfeature-05
Diff:           http://www.ietf.org/rfcdiff?url2=draft-hallambaker-tlsfeature-05

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 05 Sep 2014 17:34:43 +0200

> features a server using the cert MUST support. This closes the door on

I don't see how it does close the door. What should the client do if the
server administrator sets up an old version of a valid ocsp staple? This
case is not discussed in the security considerations at all.

regards,
Nikos

---

From: Tom Ritter <[email-masked]>
Date: Sat, 13 Sep 2014 20:20:30 -0500

On 5 September 2014 10:34, Nikos Mavrogiannopoulos <[email-masked]> wrote:
> server administrator sets up an old version of a valid ocsp staple?

Section 3.1.1 specifies "a server MUST return a valid OCSP token".   I
would consider an expired ocsp staple to not actually be valid.  I
would refer to it as expired, with the implication that the signature
is correct, because if it wasn't a person probably would have said
that in addition to describing it as expired.

> This

Because I don't consider an expired staple to be valid, I don't feel
this case is appropriate for Security Considerations.  If for some
reason expired OCSP staples are actually accepted by end entities,
then yea, Security Considerations fits.

Other Comments:

Section 3.2.3, omitting status_request results in a SHOULD reject, and
omitting in general results in a MAY reject.  I agree with the
sentiment: we can't predict if future uses of this would be a MUST or
SHOULD or MAY, but to someone reading the document, it seems
contradictory at first read.  I would suggest that this detail be
included to explain the apparent contradiction.

Section 3.2.2, regarding an Intermediate Cert with the extension.
a) I don't understand "primarily intended for use by parties seeking
to evaluate the performance of certificate issuers".
b) For the status_request extension, I would actually prefer that a
client MUST or SHOULD reject certificates that omit the extension if
signed by a cert that has the extension. I say this because I see a
use case of a CA standing up such an Intermediate, and end entities
purchasing certificates off that Intermediate, and then pinning to
that Intermediate. This is effectively one mechanism of ensuring that
all certificates for a domain contain the extension.  Just like 3.2.3,
this is another example of the specific case seemingly-but-not
contradicting the general case.

Minor Grammar:

Section 2, Paragraph 3, First sentence.  'is' should be 'are', there
should be an 'and', and a period before "These extensions".
Section 2, Paragraph 9: "a client request for the status_request or
status_request_v2 features" - features should be singular

Overall, and I know you went to pains to reduce this, the terminology
is confusing.  I think the definition you set out with extension =
x509 extension and feature = TLS extension works well. But I think it
gets confusing because you also define TLS Feature (capital F) as the
name of the thingie you are writing the draft about.  I'm not saying
it should be called this, but I took the draft and replaced 'TLS
Feature' with 'Required Data'.  This read must nicer, and also exposed
a few places where the terminology/grammar was extra confusing or
inconsistent.

 - Features ::= SEQUENCE OF INTEGER - rather than calling it Features,
perhaps some word that is not used in so many contexts?  Such as
'Requirements', 'RequiredData', 'RequiredExtensions',
'MandatedExtensions', 'MandatedData'...

 - Section 2, Paragraph two: "the TLS Feature is only" - this should
either be 'the TLS Feature extension is only' or if you want to use it
as if it's a proper noun, 'TLS Feature is only'.  I don't think it
should be used as a proper noun, and should be generally referred to
as 'the TLS Feature extension'
 - Section 2, Paragraph three, first sentence: "the only TLS feature
extensions that are relevant" - should be "the only features" or
expand the definition this once and say "the only TLS extensions"
 - Section 2, Paragraph three, second sentence: In this sentence
'extension' refers to the TLS extensions.
 - Section 2, Paragraph five: "The inclusion of a TLS feature
extension" - feature should be capitalised as it refers to the thingie
defined in the draft.

 - Section 2, Paragraph six:  "Nevertheless a Certification Authority
MAY consider the presence or absence of a required TLS feature as one
factor" - a) I think you should remove 'required' as it gets confusing
as who is requiring what. Whether the client requires Comodo to
include the x509 extension or requests it to be included is not
relevant. It's also not necessary accurate.  Is the presence of a x509
extension in a CSR a requirement?  Nay, as I include BasicConstraints
ca:True and don't get what I require ;)   b) feature should again by
capitalized, as you're referring to the thingie defined in the draft.
I would suggest saying "absence of the TLS Feature extension in the
certificate signing transaction as one factor".  I said 'transaction'
vs 'request' to encompass both a CSR and a (e.g.) phone call.

 - Section 2, Paragraph seven: "A server offering an end entity
certificate with a TLS feature extension MUST" - again, feature should
be capitalized to refer to the thingie being defined
 - Section 2, Paragraph seven: "that the server is capable of
verifying that its configuration is compatible with the feature
declaration of the certificates it offers" - strongly suggest this be
re-worded to 'with the TLS Feature declaration it offers'.
Technically feature could be correct, if it was interpreted not as a
defined term but as the colloquial word - but lets try to avoid that.
 - Section 2, Paragraph seven: "Ideally, the TLS feature declaration"
- again, feature should be capitalised to refer to the thingie being
defined
 - Section 2, Paragraph ten: "This document describes the use of the
TLS feature in PKIX end entity" - feature should be capitalised, and I
would suggest adding 'extension' after it.
 - Section 3.1 Paragraph one: "server compliant with the feature
declaration" - I think omitting 'feature' is actually more
descriptive.  Otherwise, perhaps 'the object member declaration'?
 - Section 3.1 Paragraph three: "offering the certificate MUST support
the extension specified" - extension refers to TLS extension, and so
should be 'feature'
 - Section 3.1 Paragraph three: "specified for that feature in this
document or in the document that specifies the TLS feature" - suggest
maintaining consistency and saying 'that TLS feature' in both of these
two instances
 - Section 3.2.3 "a server MUST meet to be compliant with the feature
declaration" (and the other two instances of 'feature declaration' in
this section) - perhaps replace feature declaration with 'the TLS
Feature extension'?
 - Section 3.3.1 "For example the use of a Feature extension in the
CSR" - should be full name, "TLS Feature"
 - Section 3.3.2 "A server SHOULD support generation of the Feature
extension in CSRs if key generation is supported." - same

I realize this is an intense number of minor suggestions with
tough-to-follow context.  If you send the .xml or post it on Github,
I'd be happy to make these suggestions in the form of text changes. (I
particularly like drafts on Github, as I can logically separate
different changes into different commits and you can review them as
such.)

-tom

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 18 Sep 2014 07:57:39 -0400

On Thu, Sep 18, 2014 at 5:25 AM, Nikos Mavrogiannopoulos
<[email-masked]> wrote:
> On Sat, 2014-09-13 at 20:20 -0500, Tom Ritter wrote:
> That's pretty sketchy. OCSP responses have a recommended validity
> interval, this is not the same as X.509 certificate expiration. I'm not
> sure what popular browsers do with responses received by the server that
> are outside the validity period, but I would be very surprised if they
> dropped the connection. If in this document it is assumed that responses
> not within the recommended interval should cause a TLS connection
> failure, it should be explicit.

Given that we currently have a situation where the vast majority of
Web browsers are not PKIX compliant and ignore revocation information
completely and Web browsers are only one PKIX application, I don't
think it is appropriate to use a MUST here to direct how invalid
status is handled.

Dropping the connection is only one response that might be appropriate.

For example, if a certificate is presented during an SMPT STARTTLS
upgrade. Do we want to abort the connection if the certificate is
expired or revoked? Well maybe we do but what if we would have
delivered the message without TLS at all.

In the Web browser case we might also be in an opportunistic
encryption situation. We might drop out the security indicator for a
revoked cert in that case.

We can certainly tell the server that if the feature extension is
present the server MUST be in compliance. Because failure to comply is
almost certain to result in a compatibility issue. That compatibility
issue may be less than rejection of the connection but client is in
its rights to do that.

I don't think we can specify compliance requirements on the client. We
can provide the client with information and tell the client how to
interpret is but we can't mandate anything more.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 18 Sep 2014 11:25:33 +0200

regards,
Nikos

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 18 Sep 2014 16:38:58 +0200

> think it is appropriate to use a MUST here to direct how invalid

Maybe not, but it makes sense to define what is valid and invalid.
The problem statement of this draft as you set it is to close a door on
a "downgrade" attack where no OCSP response is sent. However, if you
don't define what is a secure connection to a server that supports OCSP
status request, how can you claim to fix an attack?

regards,
Nikos

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 22 Sep 2014 15:10:53 -0400

> status request, how can you claim to fix an attack?

The draft is designed to allow the client to close the door on the
downgrade attack. That meets the problem statement, I think.