RE: TLS cipersuites for Rserpool

Ack, that is what I hate about upper level protocols defining lower
level protocol behaviors...

Ok, first by making "the new cypher on the block" the only MUST
implement we get into a situation where AES might become broken, and
therefor we have a problem.

Yes 3des isn't as nice (for many reasons) but I know that I have better
than 90 bits of security with it.  With only 4-5 years of research
agains AES, I am not sure about that (yes I have read B Schneier's work
on cracking AES - don't think it is practical, but I am not enough of a
mathematician to prove it).

Security protocols go out of their way to prove interoperation, IPsec,
TLS, etc. if it turns out that we can not just use these lower layer
protocols intelligently -- why have we bothered to define them

Bill

-----Original Message-----
From: rserpool-admin <at> ietf.org [mailto:rserpool-admin <at> ietf.org] On Behalf
Of Maureen.Stillman <at> nokia.com
Sent: Monday, September 15, 2003 12:41 PM
To: rserpool <at> ietf.org
Subject: [Rserpool] TLS cipersuites for Rserpool

Although we have reached consensus on TLS for securing the Rserpool
infrastructure, we have not discussed TLS cipher suites.  TLS has a very
long and growing list of ciphersuites.  They vary in strength.  Security
experts want strong security.  Application developers worry about
interoperability.  The answer to this is for applications to mandate a
ciphersuite along with one or more shoulds for backward compatibility.

I am including the SIP RFC 3261 security section as an example. In the
SIP specification there is the following text:

The TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6] MUST be supported at
   a minimum by implementers when TLS is used in a SIP application.  For
   purposes of backwards compatibility, proxy servers, redirect servers,
   and registrars SHOULD support TLS_RSA_WITH_3DES_EDE_CBC_SHA.
   Implementers MAY also support any other ciphersuite.

For Rserpool we need to secure the following:

PU <----> ENRP Server
PE <----> ENRP Server
ENRP server <-----> ENRP Server

I recommend Rserpool security text as follows (for ENRP and ASAP
security
sections):

The TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be supported at a
minimum
by implementers of TLS for Rserpool.   For purposes of backwards
compatibility, ENRP SHOULD support TLS_RSA_WITH_3DES_EDE_CBC_SHA.
Implementers MAY also support any other ciphersuite.

I'll get Eric Rescorla's advice about this TLS cipher suite being the
right one to make mandatory to support and also his take on backward
compatibility.  We might not need this in ENRP assuming that everyone
will write new code for Rserpool infrastructure.

Any comments?

-- maureen

_______________________________________________
rserpool mailing list
rserpool <at> ietf.org https://www1.ietf.org/mailman/listinfo/rserpool