[TLS] Re: TLS 1.2 hash agility (Mike)

["Mark Tillinghast" <[e-mail]>]

I must admit that I have no clean solution, but to continue to accept as
default that which is demonstrably broken seems a bad idea.
 
A client that supports FORWARD LOOKING SECURITY is a client that
requires requires "better" algorithms than MD5 and SHA-1.

A client that supports FORWARD LOOKING SECURITY MUST abort the session
if it doesn't receive the extension in the ServerHello, or if the list
doesn't contain an acceptable algorithm.

Make FORWARD LOOKING SECURITY optional, but there is at least one
profile in which it is mandatory.

Mark

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: Sunday, September 16, 2007 09:00
To: [e-mail]
Subject: TLS Digest, Vol 38, Issue 11

Send TLS mailing list submissions to
	[e-mail]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www1.ietf.org/mailman/listinfo/tls
or, via email, send a message with subject or body 'help' to
	[e-mail]

You can reach the person managing the list at
	[e-mail]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of TLS digest..."


Today's Topics:

   1. Re:  TLS 1.2 hash agility (Mike)
   2. RE:  Issue 49: Finished.verify length ([e-mail])


----------------------------------------------------------------------

Message: 1
Date: Sat, 15 Sep 2007 11:56:39 -0700
From: Mike <[e-mail]>
Subject: Re: [TLS] TLS 1.2 hash agility
To: [e-mail]
Message-ID: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

I have an idea.  Change the Cert Hash Types extension to the Supported
Signature Algorithms extension, and allow the server to respond with
its supported algorithms (only if the client sends its list, of course).

     struct {
         SignatureAlgorithm supported_algorithms<2..2^16-2>;
     } SupportedSignatureAlgorithms;

If the client doesn't send the extension, the server would assume the
client supports rsa_with_sha1, rsa_with_md5 (?), and dsa_with_sha1
(and the appropriate ecdsa algorithms if an ECDSA cipher suite is
negotiated).  Since the server can't send its list if the client
doesn't, the client must assume that the server only supports the same
list of algorithms.

If the client sends its list, and the server doesn't respond with the
extension, the client must assume that the server only supports the
algorithms mentioned above.  A client that requires better algorithms
than MD5 and SHA-1, can abort the session if it doesn't receive the
extension in the ServerHello, or if the list doesn't contain an
acceptable algorithm.

You can remove the HashType list from the CertificateRequest message
since it is handled by the server's SupportedSignatureAlgorithms
extension.  The client also chooses a certificate signed with a listed
algorithm.

If the Signature becomes (as Pasi suggested):

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

we'd also need to add a null signature algorithm:

     enum {
         null(0),            rsa_with_md5(1),
         rsa_with_sha1(2),   rsa_with_sha256(3),
         rsa_with_sha384(4), rsa_with_sha512(5),
         dsa_with_sha1(6),
         (65535)
     } SignatureAlgorithm;

for use with anonymous exchanges.

Mike



------------------------------

Message: 2
Date: Sun, 16 Sep 2007 11:36:20 +0300
From: <[e-mail]>
Subject: RE: [TLS] Issue 49: Finished.verify length
To: <[e-mail]>
Cc: [e-mail]
Message-ID:
	
<[e-mail]>
Content-Type: text/plain;	charset="us-ascii"

Eric Rescorla wrote:

> OK, I see where you're going with this, but I'm not sure it
> requires us to do anything now. If we're confronted with such a
> cipher suite, we can just have the document Update TLS 1.2, since
> it would only be applicable to that new cipher suite. I don't
> think this needs a version revision.
> 
> Unless you're proposing making this a variable length vector,
> whcih seems like a bad idea, since it should be defined in the
> cipher suite.

Yes, the length should be defined by the cipher suite, but I'd like
to avoid the "Updates: TLS 1.2" part (in general, ciphersuites
shouldn't need that). And we could avoid that by changing the wire 
encoding to a variable-length vector now, i.e. change

   struct {
       opaque verify_data[12];
   } Finished;

to 

   struct {
       opaque verify_data<0..255>;
   } Finished;

(And say that the verify_data length is 12 octets unless explicitly
specified otherwise by the ciphersuite)

Best regards,
Pasi



------------------------------

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


End of TLS Digest, Vol 38, Issue 11
***********************************

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