Subject: RE: [Sip] Review of draft-srivastava-sip-e2e-ciphersuites-00 Issue Header For Request

From: "Samir Srivastava" <[email-masked]>
Date: Thu, 6 Jul 2006 20:06:15 -0500

Hi Eric,

   Thx for the your comments and insights. Pl find my replies below

<< Removed Unrelated stuff>

No, that's not correct either, as I showed in an earlier diagram, of
exactly this case, repeated here.

Alice        Atlanta         Biloxi
-----        -------         ------
AES-SHA      AES-SHA         3DES-SHA
AES-SHA256   AES-SHA256      AES-SHA

In this case, Alice and Atlanta will (most likely) negotiate AES-SHA256.
Atlanta will offer AES-SHA and AES-SHA256. Biloxi will select AES-SHA. 

Now, it's certainly true that if Alice configures her client to be
AES-SHA256 only then she won't be able to get a call through, but that's
a feature because it's a deliberate advertisement that she's unwilling
to do other algorithms. 

1) Here you think, after the upgrade Alice still advertises the older
cipher-suites. Where I think, it will use the latest cipher-suites in
the TLS. And say there are some cipher-suites from the last versions,
and some more from the second last version etc in a header. It can
enumerate any number of cipher-suite with the preference. Any proxy down
the line can use from the preferential order.  In your algorithm, Take
the case of 40 bit cipher-suites being advertised by Alice, and it is
being selected  due to commonality in the hop way ahead of UAC. Though
there is another more secure cipher-suite available and honoured by the
UAC, but that is not carried forward. Let us take the following generic
case

          UAC            P1       P2       P3        P4         UAS
          ----          ----     ----     ----      ----        ----
Ciphers  A,B,C,D,E       B,C     C,D      D,B       B,E         B,E    

   UAC advertises all possible cipher-suites. Here hop P1 to P2 will be
established as C is the common cipher-suite between supported and
offered. Now as the advertised cipher-suites are not carried forward,
Call will fail between Hop P2 and P3, as D is not the cipher-suite used
on the earlier hop and P2 has no knowledge that UAC is willing to honour
D. P2 will reject the call. 

2) You seem to focus on the mandatory cipher-suite being a common
denominator always to setup the call. I found following for Mandatory
cipher-suites 

RFC 2246 in Mandatory Cipher Suite section says 

   "In the absence of an application profile standard specifying
   otherwise, a TLS compliant application MUST implement the cipher
   suite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA. "

RFC 4346 in Mandatory Cipher Suites says 
   "In the absence of an application profile standard specifying
   otherwise, a TLS compliant application MUST implement the cipher
   suite TLS_RSA_WITH_3DES_EDE_CBC_SHA."
 
RFC 3261 mentions that TLS_RSA_WITH_AES_128_CBC_SHA MUST be supported,
but others can be supported too. It asks for supporting 3DES also.
 
Going forward, we might say AES256 MUST be supported, and others can be
too. Your expertise will be helpful for commenting on chances of change
of MUST for SIP. 

Now let us take a generic case with moving mandatories

     UAC      P1         P2           P3          UAS
     ---      --         -----        -----       -----
 ciphers      A1,A2       A1          A1,A2       A1,A2

Assume A1 is older mandatory cipher, and A2 is new mandatory cipher. 

Your scheme doesn't allow the usage of A2 on the further hops (P3-UAS)
down the line, though being supported and acknowdged by UAC, as
somewhere in between older cipher is used. 

Thx
Samir

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip