> > This (a) destroys end-to-end identity
>> (which is the subject of this thread) *and* (b) allows
>> intermediaries to perform the very downgrade attack you
>> cited ([WBC+08]).
>>
>> This is why I want to improve upon 4474.
>
>I don't agree with this analysis.
>
>Let's say that [EMAIL PROTECTED] sends [EMAIL PROTECTED] an INVITE.
>It's 4474 signed by atlanta.com. Now, some SBC in the middle
>edits the SDP. This breaks the signature.
>
>At this point, when Bob gets the message, he knows:
>
>(1) This message claims to be from Alice.
>(2) The signature was broken.
>
>He therefore has no knowledge of what happen. He can choose to
>accept or reject the call, but can't reasonably infer that
>the call came from Alice or anything else about Alice's
>intentions.
>
>
>Now, if the SBC resigns, then Bob gets a valid message
>from somebody else other than Alice. Effectively, the
>SBC. Now, the SBC claims that it is connecting Bob to
>Alice, but it could be lying. If Bob trusts the SBC,
>he can accept the call, but he's trusting the SBC.
This is a far more cogent description of what I suggested
at the mic as "you broke it, you bought it". It retains
the property that 4474 is meant to provide (it shows
when an SDP was changed), but it provides a mechanism
to allow the SDP to continue to progress with an indication
of who caused the previous signature to break.
The obvious questions that arise ( "Why should I trust
mumblefratz.net's signature over sdp from '[EMAIL PROTECTED]',
when my provider is rassemfratchit.com"?) are ones we've
seen before in other contexts. They may seem intractable,
but the blunt truth is that the cryptographic trust issue here
reflects the user trust issues.
My two cents,
Ted
_______________________________________________
Sip mailing list https://www.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
