Subject: Re: Last Call: <draft-hallambaker-tlsfeature-09.txt> (X.509v3 TLS Feature Extension) to Proposed Standard

From: Stephen Farrell <[email-masked]>
Date: Tue, 07 Apr 2015 14:53:31 +0100

Hiya,

I'm the sponsoring AD for this. I had some non-blocking
comments that I'd like to be considered with other IETF
last call comments.

S.

- I still find the phrase "TLS feature extension" confusing
given section 1.2.

- section 2, 3rd last para: I think this SHOULD NOT is
broken, how (in general) can a CA check/know that it's true
and that it will continue to be true?

- 3.1, para 1 could do with a forward pointer to the
relevant bit of IANA considerations.

- 3.1, 2nd last para, last sentence: I'm not sure I get the
sentence's meaning - it has two MAY statements and a double
negative. I bet a re-phrase (as a positive statement) or
breaking into two boring sentences could be a lot simpler.

- 3.2.2: I wonder if this is really a good idea. (Still)

- 3.2.3: and elsewhere: What exactly does "reject the TLS
configuration" mean? I think you mean the cert and/or
handshake? (And those might differ e.g. with http opp-sec.)
If you need this term, why not define it at the top?

- 3.2.3.1: you could add a reference to RFC7435 at the end
there to justify the MUST NOT.

- 3.3.3: 1st para ends without a "."

- 3.3.3: I think the "treat as bad cert" model is ok, but I
do wonder if that's been fully thought through - would it
maybe be better to treat the bad case as a handshake
failure?

- 5.1: the section title isn't great, maybe "Bad
Certificates" would be better?

- 5.x: I think you could add a risk that we're adding a new
way to brick your site a bit, either via certificate update
or (less likely) s/w update (say if a server deprecates a
feature).

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 7 Apr 2015 14:41:32 +0000

Wording for last paragraph of Section 2, bottom of page 3:
----------------------------------------------------------

    The inclusion of a TLS feature extension advertising the
    status_request feature in the server end entity certificate permits a
    client to fail immediately if the certificate status information is
    not provided by the server.

 Suggestion:  s/server end entity certificate/server end-entity certificate/

Section 2 top of page 4:
------------------------

   Since the TLS feature extension is an option, it is not likely that
   an attacker attempting to obtain a certificate through fraud will
   choose to have a certificate issued with this extension.  Such risks
   are more appropriately addressed by mechanisms such as Certification
   Authority Authorization DNS records RFC 6844 [RFC6844] that are
   designed to prevent or mitigate mis-issue.

I'm profoundly disappointed that the CAB forum seems to have fumbled
CAA support by adopting a weasel-out option:

    https://cabforum.org/2014/10/14/ballot-125-caa-records/

Support for CAA was not made mandatory, and so, for now, CAA is a
failure.  Without CAA (and an agreement between the legitimate CA
and its customer that all certifiates shall signal required OCSP
stapling) the protocol proposed by this draft addresses only key
compromise and not fraudulently obtained certificates (from some
other CA with the fraudster as customer).

Even if CAA records were effective, and the fraudster had to deal
with the subject's preferred CA, what would prevent the issuance
of an "exception" certificate without mandatory OCSP stapling?
Surely an attacked skilled enough in social-engineering to obtain
an unauthorized certificate will be able to persuade the CA that
a new product that must urgently be deployed does not yet support
OCSP stapling,

This is acknowledged in Section 5.1:

   Use of the TLS feature extension to mandate support for a particular
   form of revocation checking is optional.  This control can provide
   protection in the case that a certificate with a TLS feature is
   compromised after issue but not in the case that the attacker obtains
   an unmarked certificate from an issuer through fraud.

   The TLS feature extension is a post-issue security control.  Such
   risks can only be addressed by security controls that take effect
   before issue.

The phrase "Such risks" above is I think not sufficiently strongly
bound to the preceding text to make it clear that it is referring
to the "but not ..." part of the last sentence of the previous
paragraph.

-- 
	Viktor.