

> cross between history-info and Samir's cipher-suites draft.
> 
> --
> Dean
> 
> 
> 

_______________________________________________
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

; Wed, 01 Nov 2006 16:03:43 -0500
Content-return: allowed
Date: Wed, 01 Nov 2006 21:03:40 +0000
From: "Elwell, John" <[email-masked]>
Subject: RE: [Sip] A sips: trial balloon for you to shoot down
To: Dean Willis <[email-masked]>
Cc: IETF SIP List <[email-masked]>

Dean,

Not quite. See below.

John 

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]] 
> Sent: 01 November 2006 20:32
> To: Elwell, John
> Cc: IETF SIP List
> Subject: Re: [Sip] A sips: trial balloon for you to shoot down
> 
> 
> On Nov 1, 2006, at 2:28 AM, Elwell, John wrote:
> 
> > Dean,
> >
> > I think your proposal is moving in the right direction, but I have  
> > a couple
> > of concerns. See below.
> 
> In summarization, I think your concerns all involve some 
> variation of  
> knowing "what happened downstream". Specifically, you want to know if:
> 
> 1) A sip: URI scheme actually produced a dialog with encryption on  
> all hops. You may want to know more about it than "encryption", for  
> example you may want to know what sort of encryption, or what  
> mechanism was used to authenticate the intermediary or terminus. By  
> knowing you had succeeded in getting a secure channel, you could  
> decide to engage other mechanisms (like key exchange) or activities  
> dependent on that security.
[JRE] If we have a sips scheme that mandates TLS on all hops (whatever TLS
might mean) and fails if it can't achieve it, I think there is an equal
argument for a mechanism that requests TLS on all hops but still succeeds
and tells me if any hop does not meet this requirement. So if we recommend
the sip scheme for achieving best effort, it still doesn't tell me if it
succeeded. Yes, what I want would be a new mechanism, but it would not be
substantially more difficult to define than the SIPS mechanism. I am having
a hard time rationalising why we should specify an all-or-nothing mechanism
(sips) but not a best effort mechanism. In other words I am having a hard
time understanding the use cases for sips. Maybe the lack of plausible use
cases is part of the reason it hasn't been deployed much.

> 
> 2) The security of a sip: or sips: request is degraded (or  
> potentially degraded) by a gateway threshold, beyond which the  
> reporting mechanism has no visibility and which we would generally  
> assume has fully denigrated our cryptographic protections. By 
> knowing  
> the security of sips: is not really end-to-end, you could moderate  
> the invocation of other mechanisms or activities as appropriate for  
> an unsecured channel.
> 
> I think these are great things to know. I think they go 
> substantially  
> beyond anything we can describe as a BCP for using sip: and sips:. I  
> think this requires new mechanism, perhaps something like a mutant  
> cross between history-info and Samir's cipher-suites draft.
> 
> --
> Dean
> 
> 
> 

_______________________________________________
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