Opened 6 years ago

Closed 5 years ago

#183 closed defect (fixed)

Don't violate the TLS Feature extension definition

Reported by: rlb@… Owned by: draft-ietf-trans-rfc6962-bis@…
Priority: major Milestone: review
Component: rfc6962-bis Version:
Severity: - Keywords:
Cc:

Description

Section 8.2.6 says that a requirement expressed in a TLS Feature extension can
be satisfied "using any of the mechanisms from Section 6". RFC 7633, by
contrast, says that if the ServerHello? MUST contain the requested extension if
the ClientHello? includes it -- and otherwise there is no requirement. So this
is abusing the TLS Feature extension, in that it attaches different semantics to
the same syntax.

Change History (4)

comment:1 Changed 6 years ago by eranm@…

Seems like the simplest solution would be to define a separate X509v3 extension that says "require CT".
That has two benefits:
(1) does not violate RFC7633.
(2) From an implementation perspective, does not require overriding the semantics of the mechanism (i.e. if there's code in the TLS client to advertise every TLS feature extension indicated in the certificate and match it to data returned by the server, we wouldn't need to have hacks in that code).

comment:2 Changed 6 years ago by rob.stradling@…

  • Component changed from client-behavior to to-be-decided

RFC 7633, by contrast, says that if the ServerHello MUST contain the requested extension
if the ClientHello includes it"

The actual quote is...

"If these features are requested by the client in its

ClientHello? message, then the server MUST return a ServerHello?
message that satisfies this request."

I had thought there was room to interpret "satisfies this request" more loosely than "the ServerHello MUST contain the requested extension". Hence the current text in -bis. However, having just reviewed https://tools.ietf.org/html/rfc5246#section-7.4.1.3, it seems that 7633 would need to be changed (i.e., s/server MUST return a ServerHello? message/server MUST perform a TLS handshake/) for my interpretation to become correct.

Seems like the simplest solution would be to define a separate X509v3 extension that says
"require CT"

An even simpler solution would be to completely drop the TLS Feature stuff from 6962-bis.

Perhaps https://tools.ietf.org/html/draft-stark-expect-ct-00 is enough. And, let's face it, 6962-bis isn't going to be widely deployed before October 2017 when Chrome will start requiring CT compliance for all serverAuth certs anyway.

comment:3 Changed 5 years ago by eranm@…

  • Component changed from to-be-decided to rfc6962-bis
  • Milestone set to review

comment:4 Changed 5 years ago by melinda.shore@…

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.