Subject: [TLS] Comments on RFC-4346

From: Jan Nordqvist <[email-masked]>
Date: Tue, 24 Oct 2006 12:43:18 -0700

After implementing a TLS 1.0/1.1 stack according to RFC-4346 and 
RFC-2246 (and other docs) intermixed with debugging sessions, mostly 
with a patched up version of puretls (thanks Eric Rescorla), I thought I 
would share some observations I have made about RFC-4346:

   1. The specification is a bit vague about which exact bytes of the
      SSLv2 Hello are used to calculate the handshake hash. In section
      E.1 of RFC 4346 the client hello is presented as one contiguous
      chunk of bytes with the v2 record protocol header included, but
      doesn't specifically point out that the two first msg_length bytes
      of the record header must be omitted from the hash calculation.
   2. There are few recommendations about what AlertLevel to use for
      each AlertDescription. It appears, as an example, that many
      implementations are using warning as the level for close_notify,
      although the RFC says nothing about what level to actually use.
   3. The definition of the CertificateRequest message specifies
      certificate_types and certificate_authorities as criteria for
      requesting certificates, but there is no mentioning how the two
      sets of values are used to select a certificate, i.e. is a
      certificate qualified if it matches only one of the sets or does
      it have to qualify to both.
   4. The only plausible reason for a server to request any of the
      rsa_fixed_dh or dss_fixed_dh certificate types is obviously after
      a static DH cipher suite has been negotiated and the server is
      "wishful" about getting a DH certificate whose engine parameters
      happens to match the server's certificate engine parameters in
      order to be able to exchange an empty ClientKeyExchange (section
      7.4.7). In any other case, DH certificates should be
      disadvantageous since the key ownership cannot be verified. It
      might be useful if the specification made a note about this fact.
   5. There is no mentioning of the details for how to perform the
      handshake with the TLS_NULL_WITH_NULL_NULL algorithm. Since the
      ClientKeyExchange message is specified as mandatory, one could
      assume that the ClientKeyExchange message would be specified with
      a case for a null algorithm in addition to rsa and diffie_hellman.
      Furthermore, the calculation of the verify_data in the Finished
      message is somewhat dubious since there is no master_secret to
      plug into the PRF, while at the same time the master_secret is
      defined to always be 48 bytes in length (section 8.1)

The TLS_NULL_WITH_NULL_NULL issue may not be overly significant given 
its fairly low security level :). At the same time it is mentioned as a 
defined cipher-suite as part of the TLS 1.1 definition, and it may be 
useful for debugging purposes.
 
Jan Nordqvist
Lucent VitalAAA product group

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: EKR <[email-masked]>
Date: Tue, 24 Oct 2006 13:26:38 -0700

>      although the RFC says nothing about what level to actually use.

Right. However, since fatal makes the session resumption unresumable,
it seems like warning is what you want.

>      it have to qualify to both.

It mist match both.

>      defined to always be 48 bytes in length (section 8.1)

It's forbidden to negotiate this algorithm (see S A.5).

-Ekr

---

From: Martin Rex <[email-masked]>
Date: Tue, 24 Oct 2006 22:42:13 +0200 (MET DST)

>       it have to qualify to both.

A very large installed base of SSLv3/TLSv1.0 seems to entirely ignore
certificate_types for the selection (the vendor forgot to expose
this information at the low level APIs, so the callers above it,
e.g. Web Browser, can not use it for selecting the certificate).

Let's hope that CA's are careful when issuing CA certificates,
and do not use the exact same Subject DName but differing keys
(different in type, size or even just different bits).

-Martin