Subject: [Sip] Review of draft-srivastava-sip-e2e-ciphersuites-00

From: EKR <[email-masked]>
Date: Tue, 04 Jul 2006 08:58:45 -0700

Because TLS is used in SIP in hop-by-hop mode, the cipher suite that
you negotiate with your first hop proxy is no guarantee of what will
be negotiated with future proxies. Consider the classic trapezoid:

        Atlanta ---------------------- Biloxi
         /                                \
        /                                  \
      /	                                    \ 
alice@atlanta                             bob@biloxi

Alice can negotiate AES-256 with Atlanta but then have Atlanta
negotiate RC4-40 with Biloxi. This draft suggests a series of
extensions to SIP to carry the initial client's preferences and that
proxies further down the chain are expected to enforce.

It seems to me that there is a simpler mechanism: any proxy X
can only offer the intersection of the cipher suites that was offered
to it and the ciphersuites that it is willing to support. This has
the result that no downstream proxy can negotiate a cipher suite
that Alice wasn't willing to negotiate with Atlanta. 

There are two obvious disadvantages with respect to the proposed
draft:

1. Alice doesn't get any signal of what was eventually negotiated.
   I would solve this problem by extending Via (I'm actually surprised
   this isn't done). MTAs typically put it in Received lines, FWIW...
2. It's less expressive. In particular, the downstream cipher suites
   always narrow and never grow. So, if there were a third proxy in
   between Atlanta and Biloxi that only spoke DES, then Biloxi and Bob
   would only get DES even if they both spoke AES. Based on my experience
   with what real implementations support and the MUST for AES, I'm not
   much concerned about this. It's generally impossible to pickle
   the full client policy and have it sent to a proxy. It's mostly
   a matter of where you draw the line, and drawing it where the
   protocol already draws it seems natural.

The big advantage of the approach I propose is that it doesn't
require any new mechanisms and can be incrementally deployed in
an interoperable way.

_______________________________________________
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

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 04 Jul 2006 09:21:58 -0700

Oh, one more note. This draft claims:

   An obvious inference of this statement is that SIP allows use of
   different cipher suites at each hop along the path.  At the worst,
   SIP doesn't forbid the use of TLS_NULL_WITH_NULL_NULL ciphersuite for
   the SIPS URI scheme also.

This is explicitly forbidden by TLS.

   TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a
   TLS connection during the first handshake on that channel, but must
   not be negotiated, as it provides no more protection than an
   unsecured connection.

-Ekr

---

From: "Samir Srivastava" <[email-masked]>
Date: Tue, 4 Jul 2006 17:30:50 -0500

Hi Eric,

   Thx for your review and detailed comments. Pl find my replies in line
below.

Thx
Samir

Because TLS is used in SIP in hop-by-hop mode, the cipher suite that you
negotiate with your first hop proxy is no guarantee of what will be
negotiated with future proxies. Consider the classic trapezoid:

Alice can negotiate AES-256 with Atlanta but then have Atlanta negotiate
RC4-40 with Biloxi. This draft suggests a series of extensions to SIP to
carry the initial client's preferences and that proxies further down the
chain are expected to enforce.

It seems to me that there is a simpler mechanism: any proxy X can only
offer the intersection of the cipher suites that was offered to it and
the ciphersuites that it is willing to support. This has the result that
no downstream proxy can negotiate a cipher suite that Alice wasn't
willing to negotiate with Atlanta. 

SS>> Here it is assumed that cipher-suite X which is between
alice@atlanta and Proxy for atlanta is supported between proxies for
biloxi and atlanta. This may not be true. Suppose Proxy for atlanta is
upgraded with the latest TLS version, extension, and cipher suites. But
proxy for biloxi is not upgraded. In this case we cannot make a secure
call. But with the proposal, we can make a call though it will be less
secure. The level of security (qValue) is indicated back in the
response.

SS>> Proposal extends the via to include all TLS security information.
Here we agree.

   would only get DES even if they both spoke AES. Based on my
experience

SS>> Here if proxy for atlanta has good control over it's network, and
it is using less secure cipher-suite (or no-security) in that hop, then
as per your proposal it is going to use same less secure cipher-suite
all along the path even in open internet where it is crossing provider's
boundary, even if edge proxies are supporting the most secure
cipher-suites etc. Here it should be noted that upgrading edge proxies
is easy, as compared to upgrading every UA within provider's domain
with the latest cipher-suite, protocol etc. In your example, If proxies
are crossing the provider's boundaries over the open internet, then I
would like to have AES in that hop. This cannot be done in your
proposal, even if it is supported. 

The big advantage of the approach I propose is that it doesn't require
any new mechanisms and can be incrementally deployed in an interoperable
way.

SS>> My problem is that current mechanism are not future proof. Suppose
down the line current cipher-suites, protocols etc are broken, and we
have new cipher-suites etc . Then we will have different cipher-suites
in the network, we cannot assume that every SIP entity in the network is
upgraded quickly. Proposal caters that with clear indication of
security. 

_______________________________________________
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

---

From: "Samir Srivastava" <[email-masked]>
Date: Tue, 4 Jul 2006 17:35:25 -0500

Hi Eric,

Thx for pointing this out. My mistake. Will be fixed in the next
version.

Thx
Samir 

-----Original Message-----
From: Eric Rescorla [mailto:[email-masked]] 
Sent: Tuesday, July 04, 2006 9:22 AM
To: [email-masked]
Subject: Re: [Sip] Review of draft-srivastava-sip-e2e-ciphersuites-00

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 04 Jul 2006 15:51:35 -0700

"Samir Srivastava" <[email-masked]> writes:
> call.

No, this is incorrect. I didn't say the *selected* cipher suite,
I said the intersection of the offered and acceptable. Consider
the following case for what various agents support:

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. The only way in which the second hop could fail
would be if Atlanta didn't speak AES-SHA, but remember that 
AES-SHA is a MUST implement.

> cipher-suites etc.

I don't see your point here. You seem to be suggesting that we should
deliberately be fostering a mechanism that allows providers to use
weak mechanisms inside their internal networks. That doesn't seem
like a particularly worthy goal, so I don't see why that merits 
the amount of extra protocol complexity you want to introduce.

> Here it should be noted that upgrading edge proxies

It would seem easier to simply relax the narrowing constraint I
indicated in cases where both ends are under the control of
the same operator. This seems a lot simpler than lugging a
bunch of policy information around inside your internal network.

> upgraded quickly. Proposal caters that with clear indication of

Can you name an instance in which this has actually happened?

But suppose it's true? You just relax the constraint that you need to
offer only incoming cipher suites, upgrade your edge proxies,
and the problem goes away. The reason not to do that ordinarily
is that we don't have an unambigous ordering of cipher suite
strengths so we'd like to let the original UA have an opinion
but if you *know* that the UA's offered algorithm is broken,
I think it's safe to override it.

-Ekr

---

From: "Samir Srivastava" <[email-masked]>
Date: Tue, 4 Jul 2006 20:42:57 -0500

Hi Eric,

   Refer the  http://www.cryptosystem.net/aes/ . Some points from there
are quoted below w.r.t algebraic attacks on it...

"Should AES be used ? Most people will answer yes, for now, due to the
lack of a better standard. AES remains still millions of times better
than many snake oil ciphers you can buy here or there. Moreover, even if
AES will be broken in the coming years by a fast algebraic attack, it
will probably still remain more secure than DES, and can still safely be
used for applications that do not require long term security. 

However, though AES seems overdesigned with respect to differential or
linear cryptanalysis, from the point of view of algebraic attacks, it is
an extremely bad cipher. It is rather difficult to imagine a worse
cipher, among ciphers that resist to other known attacks... (worse with
respect to algebraic attacks). Therefore, even if it turns out that the
XSL is NOT faster than the exhaustive search of a 128-bit key, NIST
should sooner or later revoke AES. One should not take chances with
these things. Another open call for a cryptographic standard will
probably be done in the coming years (no need to hurry). "

I am not expert on the algebraic attacks, but I sensed the need for
openess in SIP from this prespective, as breaking of older crypto
algorithm forced to create the new algorithms (AES). IMHO one cannot
deny this trend in future. I will appreciate your views on this.

More replies inline below.

Thx
Samir

> upgraded with the latest TLS version, extension, and cipher suites. 
> But proxy for biloxi is not upgraded. In this case we cannot make a 
> secure call.

No, this is incorrect. I didn't say the *selected* cipher suite, I said
the intersection of the offered and acceptable. Consider the following
case for what various agents support:

Alice        Atlanta         Biloxi
-----        -------         ------
AES-SHA      AES-SHA         3DES-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.
The only way in which the second hop could fail would be if Atlanta
didn't speak AES-SHA, but remember that AES-SHA is a MUST implement.

SS>> Fine. It will work in the current state of affairs. Breaking of
AES-SHA in future, will need another cipher-suite. Then we fix TLS with
that (newer version etc). But SIP doesn't have any knowledge of how much
secure hop it is. 

It is an open issue, how the UAC or proxy preferences of cipher-suites
etc will be overidden. My first goal is to have an agreement on the need
of this in SIP. UAC needs to have the knowledge with what level of
security, it is able to reach UAS. IMHO, Level of Security cannot be
compared with other features of underlying protocols. Without being
having a guranteed level of security, I cannot share senstive info.
There is no such indication in SIP. This level of security can be
upgraded (At UAC and UAS) when SRTP key negotiation etc is done and
media is guranteed to secure also.

SS>> This is being inherited from SIPS. Where it doesn't even have TLS
in the last hop. I don't like  this mechanism, if I am interested in
complete ironclad e2e AES (as per the current state of encryption) . But
closed walled garden supporters like it, and I don't want to start
debate on this.

SS>> Being at UAC, I don't know in advance how I will be able to reach
the UAS. Take the case of retargeting from the another domain's proxy to
the UAC domain proxy. The proposal is cleaner w.r.t. all these aspects. 

SS>> Refer the earlier text in the reply. Ordering of strength of
cipher-suites etc and overriding is not considered currently. If we are
in the agreement that we need a security-level kind of header in SIP,
then we can hash it out.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 04 Jul 2006 20:29:13 -0700

> that (newer version etc). But SIP doesn't have any knowledge of how much

Again, that's not true with the scheme I described. Only 
cipher suites that the first-hop client is willing to negotiate
will be negotiated on any hop. Consider the simple case where
there is currently only one algorithm X. When a new algorithm
Y is introduced (whatever the status of X), if the original
UAC only supports X, then there are two possibilities:

1. Every proxy along the path supports X as well as Y.
2. Some proxy along the path only supports Y.
 
Given the algorithm I described, in case 1 you get X (which by
definition is OK with the UAC). In case 2, the connection fails
somewhere along the line. In neither case can you get a cipher
suite that X does not consider acceptable.

> the UAC domain proxy. The proposal is cleaner w.r.t. all these aspects. 

I don't understand the point you're making here. I'm not talking
about the UAC, but about the various proxies inside a single
trust domain.

> cipher-suites etc and overriding is not considered currently.

I don't understand this point at all. What I'm saying is that
the only reason why you need to consult the UAC's cipher
suite preferences at all is that we don't have a single
agreed upon ordering of algorithm strengths. If we did,
then it would be a simple matter of saying "on outgoing
you can negotiate any algorithm as strong or stronger
as the one on incoming." However, in the case where the
proxy *knows* that the incoming algorithm is broken, then
it's safe to negotiate a stronger algorithm even if the
client did not offer it.

> If we are

I don't agree that we need such a header.

-Ekr

---

From: "Samir Srivastava" <[email-masked]>
Date: Wed, 5 Jul 2006 03:02:51 -0500

> In this case, Alice and Atlanta will (most likely) negotiate
AES-SHA256.
> AES-SHA in future, will need another cipher-suite. Then we fix TLS 
> with that (newer version etc). But SIP doesn't have any knowledge of 
> how much secure hop it is.

Again, that's not true with the scheme I described. Only cipher suites
that the first-hop client is willing to negotiate will be negotiated on
any hop. Consider the simple case where there is currently only one
algorithm X. When a new algorithm Y is introduced (whatever the status
of X), if the original UAC only supports X, then there are two
possibilities:

Given the algorithm I described, in case 1 you get X (which by
definition is OK with the UAC). In case 2, the connection fails
somewhere along the line. In neither case can you get a cipher suite
that X does not consider acceptable.

SS>> Why you want to fail the call setup in 2. In my proposal, When we
have overriding defined, call will be setup, with the clear indication,
that it is less/more secure ( 0 being no secure, 1 being Max i.e. for
Algo Y in this case and their will be some value for X say 0.8 ). Making
more no of retries will not be acceptable by the users and not desired
by the providers. Your proposal will require more no of resubmission of
INVITEs with changing algorithms etc when there are large no of
algorithms.

Moreover, What about the case when UAC and Proxy at the first hop is
upgraded to Y and other hops for particular session are having still X.
In your scheme, secure call setup will fail and more no of retries etc
will be needed. In my proposal, call will be set, with the indication
that it is 
less secure with a single INVITE transaction.

> the UAS. Take the case of retargeting from the another domain's proxy 
> to the UAC domain proxy. The proposal is cleaner w.r.t. all these
aspects.

I don't understand the point you're making here. I'm not talking about
the UAC, but about the various proxies inside a single trust domain.

SS>> My point is, UAC and it's home proxy doesn't know at prior, what
domains it will be visiting. The proxies visted may or may not be in a
single trust domain. When INVITE is issued, they may be in the single
trust domain, and retargeting makes it to go different trust domain.
Retargetor entity (Proxy) needs to know where it is going. The earlier
proxies in path will not have any idea. In the single trust domain, the
original call might be using algorithm X, but going out in a different
domain might need different algorithm Y. There will be cases when X is
more/less stronger than Y.
So again we are back to similar issues of upgrade/downgrade of SIP and
SIPS. My proposal provides clear guideline what proxy should do. Your
proposal will reject the calls based on relative stengths of X and Y and
what UAC has. And require UAC to reInitiate the calls when it is failed.

> offer only incoming cipher suites, upgrade your edge proxies, and the 
> problem goes away. The reason not to do that ordinarily is that we 
> don't have an unambigous ordering of cipher suite strengths so we'd 
> like to let the original UA have an opinion but if you *know* that the

> UA's offered algorithm is broken, I think it's safe to override it.
>

I don't understand this point at all. What I'm saying is that the only
reason why you need to consult the UAC's cipher suite preferences at all
is that we don't have a single agreed upon ordering of algorithm
strengths. If we did, then it would be a simple matter of saying "on
outgoing you can negotiate any algorithm as strong or stronger as the
one on incoming." However, in the case where the proxy *knows* that the
incoming algorithm is broken, then it's safe to negotiate a stronger
algorithm even if the client did not offer it.

SS>> Refer the previous comments. In your proposal calls are failed. And
they need to retried with less security. All together new transactions
etc. are needed. In my proposal call is setup with the available level
of security in the network, if it is acceptable to UAC with a single
INVITE. Then user can accept/reject the calls. In your proposal *more
trust* is given to a single Proxy and UAC doesn't know what is being
done in the path. If a single evil proxy downgrades, it cannot be
indicated back to UAC, as you don't agree on the new header which
carries the information for least strong algorithm being used in path
when RESPONSE is sent back to UAC. My proposal can catch single bad
proxy if it lies. My proposal doesn't cover the case when two adjacent
proxies lie in collaboration. 

SS>> I don't agree with you here. Refer my concerns in above replies.
Let me divide this into two
    1) Header for REQUEST where ciphersuites etc are listed.
    2) Header for RESPONSE where least strong used algorithm in the path
is indicated back 
       to UAC by UAS by inspecting via trails.

    Let me know your opinions for 1 and 2. Then we can focus on the
discussion for that case.

-Ekr

---

From: "Rajnish Jain" <[email-masked]>
Date: Wed, 5 Jul 2006 06:32:17 -0400

> can only offer the intersection of the cipher suites that was 
> offered to it and the ciphersuites that it is willing to 
> support. 

There seems to be a fundamental disconnect in the comment above. The comment
above is basically describing a hop-by-hop mechanism. However, the draft is
fundamentally about solving the e2e problem. The keyword here is e2e. How
will the proxy know that its narrowing down the UAC's preferred ciphersuites
will not be detrimental to the setting up of the call somewhere downstream
in the e2e path? 

> This has the result that no downstream proxy can 
> negotiate a cipher suite that Alice wasn't willing to 
> negotiate with Atlanta. 

But this has also has the undesirable result that no downstream proxy can
negotiate a cipher suite that was agreeable to Alice.

>    this isn't done). MTAs typically put it in Received lines, FWIW...

How will extending 'Via' help Alice, the UAC, learn about the negotiated
ciphersuite? The draft does talk about extending 'Via' but that is to inform
Bob, the UAS. The draft also mentions that the Security-Level header
containing the lowest 'q' value is sent back to Alice. 

>    would only get DES even if they both spoke AES. 

This comment doesn't seem to reflect the scheme described in the draft.
Instead, this seems like a comment reflecting the hop-by-hop mechanism
suggested in your own email. 

Rajnish

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 05 Jul 2006 06:37:00 -0700

Editorial note:

Samir, can I ask you to use standard ">" quoting markers?
I'm finding this exchange very hard to read with the quote
markers you'r;e using.
 
"Samir Srivastava" <[email-masked]> writes:

> SS>> Why you want to fail the call setup in 2.

I don't want it to, particularly. But I'm pointing out the scheme I
described fails safe. You may not have "any knowledge of how secure
it is" but you never end up sending data over a channel you
wouldn't be willing to.

> In my proposal, When we

No, I don't believe it will. Please show the flow diagrams that
you think demonstrate this.

> less secure with a single INVITE transaction.

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

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. 

> what UAC has. And require UAC to reInitiate the calls when it is failed.

Let's put this issue aside until we're clear on how the system I
described works in the simple case above.

>     1) Header for REQUEST where ciphersuites etc are listed.

This is totally unnecessary.

>        to UAC by UAS by inspecting via trails.

The whole concept of "least strong" is a mistake. What should be
reported back is the entire list of proxies the message went
through and the relevant crypto algorithms.

-Ekr

---

From: "Matthew Gardiner" <[email-masked]>
Date: Wed, 5 Jul 2006 16:22:43 +0100

Hi Eric,

>In particular, the downstream cipher suites always narrow and never grow.

I don't see that this is the case with Samir's scheme. Consider the case below where A wants to talk to D, via B and C:

          B ---------------------- C
         /                          \
        /                            \
       /	                          \ 
      A                                D

A, C and D all support cipher suites x,y and z. B only supports x. Just because the hops AB and BC must negotiate cipher suite x, it does not prevent hop CD negotiating anything from the range x,y,z.

That was my (brief) understanding of Samir's proposal. I can't see where the narrowing occurs, though obviously the range of suites will not grow.

Matthew Gardiner
Software Enginneer
Aculab

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 05 Jul 2006 08:32:55 -0700

> That was my (brief) understanding of Samir's proposal. I can't see where the narrowing occurs, though obviously the range of suites will not grow.

No, that's a disadvantage of the scheme I proposed.

-Ekr

---

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

Hi Eric,

   This is another thread, to discuss content in the response.

<<Removed Unrelated stuff>>

The whole concept of "least strong" is a mistake. What should be
reported back is the entire list of proxies the message went through and
the relevant crypto algorithms.

1. From the another threads, it looks that you are in agreement for a
reverse channel for indicating back the cipher etc used at each hop.

2. I am okay with sending the complete via trails with ciphers etc used,
and let UAC decide how it wants to interpret it. It will be having more
number of bytes. If they are in the same packet, it doesn't cost much. 

Thx
Samir