Samir Srivastava wrote:
My very simple requirement, which I posted recently to the Dean's
question on the what callee wants. And a lot of this, I explained
earlier.
1) If I am DOD, I want AES 256. As it is considered TOP SECRET by them.
If you are the DOD, then you will control the whole network and insist
that it use AES 256 uniformly, regardless of what is signaled.
If I am talking to bank then I want AES 256 (using KPML etc as it has
lot of valuable information).
*You* may know you are talking to a bank. But how does your UAC know
that? Do you expect to have an "AES 256" button on the phone to signal this?
Its also possible that you didn't know when you made the call that it
was to a bank. (It might just be a number on your missed-calls list.)
Its quite possible that it is the *bank*, not you, that wants to ensure
that the call is secure, because it has legal liability if it doesn't. I
don't see how you intend to deal with that.
If a CEO of company A is in talks with CEO
of another company B, he will need AES 256 for all along. As the call
pattern tracking itself is more sensitive. As if Competetior of Company
of A knows that A and B are in talks, he can also come into the picture.
The damage varies on the size, content of talk (consider Page mode IM
too).
In general it becomes quite messy if you insist that the security policy
to use for the call be specified by the caller and yet be dependent on
the nature of both the caller and callee.
Paul
2) If I am making 911 call, I need my call to be setup even with the
plain text.
3) If I am small office owner in the downtown, then I might be okay even
with 3DES or 40 bit ciphers etc..
4) If I am a normal user, then I will need AES128 all along.
5) There are geographic regions, where ciphersuites just provide the
integrity and no confidentiality. If my UA moves to those regions, then
atleast the proxy sitting at the boundary should inform the request
needing back AES256, that it cannot be served.
I have given a lot of other reasons earlier. Like Cheater Proxy, the N+1
Cycle for new cipher-suite development etc..
My only request to the group is, please postpone the decision of SIPS
with patches as STANDARD track document, till I publish my next version
of the cipher-suite draft.
Thx
Samir
There are two features being discussed here:
1. An indicator of which cipher suite was negotiated.
2. A signal that you want the next hop to negotiate a specific
set of cipher suites.
I have no problem with the first feature, though I'm not sure
it's incredibly useful. I don't agree that the second feature
is particularly useful. The cases where it's relevant strike
me as fairly esoteric and unlikely.
-Ekr
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
