Subject: RE: [Sip] closure on display-names & sip-identity

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 26 Apr 2005 13:08:52 -0400

> I disagree: it says at the very least that that display name is the one
> that the signer saw as it passed by its stamper. If it is not added to
> the hash, then you'll never know.

If man-in-the-middle attacks were the concern of the draft, I would agree with you - but they are not. This draft sets out to beat trivial >From header forgery, not attackers with the capability to capture and modify signaling in passing. There are other SIP mechanisms that address those sorts of attacks.

> As I've said repeatedly: people are whistling in the dark if they think
> that some sort of proscription in this draft, or withholding of signed
> bits, or whatever else is going to stop UA's from displaying the display
> name if it's there. They will, and you can count on that. In the end,
> not signing the display name so that you could conceivably disavow 
> that name later because you aren't able completely guarantee its
> veracity is so many angels on a pinhead: it makes no operational
> difference. We should err on the side of forensics here, not finger
> wagging at developers or careful parsing of what the meaning of
> "is" is.

I don't think anyone believes bits are going to "stop" UAs from displaying the display-name. I think there has been some reasoned argument from a number of parties that UAs might not use the display-name anyway under various circumstances. The important deciding points about all of this are how useful a display-name is to a verifier in actually defeating impersonation. I have not seen much by way of argument as to why signatures over display-names are actually important to verifiers. 

> So, I disagree with this, and the general philosophy that picks
> winners and loser for the hash input. The more the merrier. 

Regardless of whether the draft picks winners and losers, discussion of the security effects of signing one thing or another is warranted and in my opinion necessary. If you leave it completely to application developers or deployers/users of the technology to decide what should and shouldn't be signed, I think it is likely that people will come to different opinions, and that the mechanism will therefore be used in ways that have different strength, which are in turn potentially unacceptable to some recipients, and so on. If we don't at least do the analysis now, they will have to do it later, and some of them might not be in a position to do it adequately. I don't think this is a feature.

Jon Peterson
NeuStar, Inc.

> 		Mike

_______________________________________________
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