Opened 15 years ago

Closed 15 years ago

#29 closed clarification (fixed)

Clarify when server certificate is sent

Reported by: pasi.eronen@… Owned by:
Priority: minor Milestone: milestone1
Component: draft-ietf-tls-rfc4346-bis Version: 02
Severity: Keywords:
Cc:

Description

http://www1.ietf.org/mail-archive/web/tls/current/msg01100.html

During the review of TLS 1.x while writing the Internet
Draft describing the proposed TLS_GSS ciphers, Stefan
Santesson noticed the following text from RFC4346 Section
7.4.2:

"7.4.2. Server Certificate

   "When this message will be sent:

      "The server MUST send a certificate whenever the
      agreed-upon key exchange method is not an anonymous
      one.  This message will always immediately follow the
      server hello message."

This text appears in all versions of TLS.  However, RFC2712
states in Section 3:

   "The server's certificate, the client CertificateRequest,
   and the ServerKeyExchange shown in Figure 1 will be
   omitted since authentication and the establishment of a
   master secret will be done using the client's Kerberos
   credentials for the TLS server."

In my opinion, RFC2712's behavior is correct.  The TLS
server must not send a certificate to the client when the
key exchange is being performed in such as manner as not to
rely on the public key pair associated with a certificate.

The text in RFC4346 7.4.2 is correct assuming that
certificate based public key is the only form of server
authentication.  As demonstrated by RFC2712, there are other
methods of performing server authentication that do not
involve certificates.

I propose the following change to TLS 1.2 Section 7.4.2:

  "The server MUST send a certificate whenever the
  agreed-upon key exchange method is not anonymous and does
  not provide an alternative method of server
  authentication.  This message will always immediately
  follow the server hello message."

This text permits the behavior described by RFC2712 and the
forthcoming TLS_GSS Internet Draft.

http://www1.ietf.org/mail-archive/web/tls/current/msg01104.html

It might be better to be more explicit here.  Your proposed
text resolves the conflict, but could be puzzling to
implementors who haven't seen the Kerberos or TLS_GSS
ciphersuite specifications and don't quite know what you're
talking about when you mention alternative methods of server
authentication.  Here is a more elaborate proposal:

     This message is omitted if the agreed-upon key exchange
     method is anonymous or uses an alternative method of
     server authentication.  For all non-anoymous key
     exchange methods specified in this document, the server
     MUST send this message.  For non-anonymous key exchange
     methods specified elsewhere that do not provide an
     alternative method of server authentication, the server
     MUST send this message.  This message will always
     immediately follow the server hello message.

This also would clarify that you can't send a certificate
message in an anonymous handshake, which apparently isn't
strictly forbidden with the current language.  (The
signature part of the ServerKeyExchange is empty, so there's
no point in trying to attach a server certificate to a
handshake that is nominally anonymous.)

http://www1.ietf.org/mail-archive/web/tls/current/msg01103.html

The text is correct if it's interpreted to apply only to the
ciphersuites defined in RFC2246/4346 (all of which are based
on certificates, or are anonymous)... but I do agree that it
would benefit from clarification. But instead of listing the
exceptions when it's not sent, I'd prefer saying when it
*is* sent:

   "The server MUST send a certificate whenever the
   agreed-upon key exchange method uses certificates for
   authentication (this includes all key exchange methods
   defined in this document except DH_anon).  This message
   will always immediately follow the server hello message."

Change History (3)

comment:1 Changed 15 years ago by pasi.eronen@…

http://www1.ietf.org/mail-archive/web/tls/current/msg01106.html

One more revision combining the best of Pasi's and Bodo's text:

     This message is omitted if the agreed-upon key exchange
     method is anonymous or uses server authentication
     method that does not involve certificates.  For all key
     exchange methods specified in this document except for
     DH_anon, the server MUST send this message.  For
     non-anonymous key exchange methods specified elsewhere
     that do not provide an alternative method of server
     authentication, the server MUST send this message.
     This message will always immediately follow the server
     hello message.

http://www1.ietf.org/mail-archive/web/tls/current/msg01107.html

Improving... except I still prefer an ordering where we
first say when the message is sent, and the explain the
exceptions:

   This message MUST be sent if the agreed-upon key exchange
   method involves certificates for server authentication.
   This includes all key exchange methods defined in this
   document except DH_anon. For key exchange methods
   specified elsewhere that are either anonymous or provide
   an alternative method of server authentication, this
   message MUST NOT be sent. This message will always
   immediately follow the server hello message.

http://www1.ietf.org/mail-archive/web/tls/current/msg01108.html

I am happy with this version.

comment:2 Changed 15 years ago by pasi.eronen@…

  • Milestone set to milestone1

comment:3 Changed 15 years ago by ekr@…

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