Subject: Re: [TLS] TLS 1.2

From: Mike <[email-masked]>
Date: Wed, 01 Aug 2007 12:02:13 -0700

To the person trying to interoperate with my server:

You uncovered a bug in my server that was looking for
a HashType in the CertificateVerify message regardless
of the key type.  I fixed it so now it only looks for
that if it's an RSA client certificate.

Also, your client gets as far as establishing the
master secret, but when an encrypted packet arrives,
either the MAC or padding is invalid.  I will look
over my code to see if it's my fault.

Mike

Mike wrote:
> I realize it's still a moving target, but I updated
> my test server to implement TLS 1.2 as of the latest
> draft (-04).  You can test against it at
> 
>       https://www.mikestoolbox.net
> 
> Mike

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

---

From: Mike <[email-masked]>
Date: Thu, 02 Aug 2007 09:57:05 -0700

I just want to make sure I'm reading the spec
correctly.  Is SHA-256 used only for the PRF
calculation and the MAC algorithm is still
whatever the cipher suite says?  Or is SHA-
256 also used for MAC calculations?  I believe
the former, so MD5 could even still be used
with RC4 -- is this correct?

Thanks,

Mike

---

From: [email-masked]
Date: Fri, 3 Aug 2007 12:25:03 +0200

Mike, 

> with RC4 -- is this correct?

My opinion is, that for compatibility reasons, 
all defined cipher suits sould work as before. 
The SHA-256 versions of any cipher suits should 
get a new id. This would also make the 
implementation easier if all SSL/TLS versions 
are supported.

Axel

---

From: Bodo Moeller <[email-masked]>
Date: Fri, 3 Aug 2007 12:47:02 +0200

> implementation easier if all SSL/TLS versions 

Compatibility isn't really an important issue here (we have explicit
version negotiation).  Ease of implementation is.  Luckily, appendices
B and C make it quite clear that SHA still means SHA-1, and that MD5
still means MD5.  There's really nothing wrong with this: This use of
HMAC is for ephemeral authentication only, so there's no reason to
force everyone to live with the overhead of SHA-256 or something.

The situation is quite different for hashes in the PRF.  The PRF is
essential for the long-term security of encryption, and the old PRF is
somewhat weird; replacing it makes a lot of sense.

Bodo

---

From: Mike <[email-masked]>
Date: Fri, 03 Aug 2007 12:43:31 -0700

Today someone has successfully connected
to my server using TLS 1.2 (-04 draft).

An added benefit is that TLS 1.2 is about
3-4% faster than TLS 1.1 in establishing a
connection (RSA_WITH_RC4_128_MD5 1024 bit
was used to test).

Mike

---

From: <[email-masked]>
Date: Thu, 9 Aug 2007 12:34:07 +0300

Mike ([email-masked]) wrote:

> I think the solution we need is to specifically list each supported
> signature algorithm, e.g.
> 
>      enum {
>        rsa_with_md5(0),    rsa_with_sha1(1),
>        rsa_with_sha256(2), rsa_with_sha384(3),
>        rsa_with_sha512(4), dsa_with_sha1(5),
>        (65535)
>      };
> 
> These may not be specific enough, as I've seen suggestions for,
> e.g. rsa_pkcs1v1_5_with_sha1, and I've heard that some algorithms
> need parameters, but I think I've made my point.

I think your suggestion looks good; it seems to handle the DSA and
ECDSA cases better than just a list of hashes, and it's more
in TLS style than sending DER-encoded AlgorithmIdentifiers. 
And then we could change Signature structure to

   struct {
      SignatureAlgorithm signature_algorithm;
      opaque signature_value<0..2^16-1>;
   } Signature;  

Eric, what's your opinion?

Best regards,
Pasi