Subject: [Trans] [trans] #108 (rfc6962-bis): TLS session resumption: Server MUST NOT send SCTs

From: "trans issue tracker" <[email-masked]>
Date: Tue, 22 Sep 2015 09:08:22 -0000

#108: TLS session resumption: Server MUST NOT send SCTs

 This ticket is about how servers behave during TLS session resumption when
 clients send the signed_certificate_timestamp extension in the handshake
 (http://tools.ietf.org/html/rfc6962#section-3.3.1).

 The wording in RFC6962 is slightly ambiguous: It's clear that on session
 resumption clients SHOULD include the extension type but is more lax about
 server response, stating "the server is not expected to process it or
 include the extension in the ServerHello".

 Should this be changed to MUST NOT or SHOULD NOT in -bis ?
 As a reference, RFC6066 uses MUST NOT for the SNI extension (end of
 section 3)

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-trans-
  [email-masked]       |  [email-masked]
     Type:  defect       |     Status:  new
 Priority:  major        |  Milestone:
Component:  rfc6962-bis  |    Version:
 Severity:  -            |   Keywords:
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/108>
trans <http://tools.ietf.org/trans/>

---

From: "trans issue tracker" <[email-masked]>
Date: Tue, 22 Sep 2015 10:23:36 -0000

Comment (by [email-masked]):

 I think changing it to "MUST NOT" makes sense.  IINM, when a session is
 resumed a client typically won't repeat the certificate validation that it
 originally performed (when the session was initially established).  Where
 there is no certificate validation taking place, there is no need for
 SCTs.

 For reference, this is the "MUST NOT for the SNI extension" text you were
 referring to:
   "When resuming a session, the server MUST
    NOT include a server_name extension in the server hello."

 Severity:  -            |  Resolution:
 Keywords:               |

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/108#comment:1>
trans <http://tools.ietf.org/trans/>