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

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

"Rajnish Jain" <[email-masked]> writes:

>> 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. 
>
> 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.

This draft *isn't* end-to-end. End-to-end would be like in RFC 2818
where there's a single TLS channel between UAC and UAS. What this
is is hop-by-hop with policy instructions.

> 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? 

It might be, but a lot of experience with real TLS deployments
and the fact that there is a mandatory-to-implement ciphersuite
suggests that this will not be a problem in practice.

>> 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.

Huh? No, that's incorrect.

>> 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...
>
> 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. 

Yes, you'll need some reverse channel that carries the same data
as the Via.

>> 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. 
>
> 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. 

Yes, that's why I listed it as a disadvantage of the scheme described
in my e-mail message.

-Ekr

_______________________________________________
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: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Wed, 5 Jul 2006 15:27:32 -0400

Eric,

The Record-Route header should contain the path of those proxies that
intend to stay in the signaling path, whereas the Via only provides the
path back for the responses.

Should this make a difference?  Could A to B agree on one suite, while B
to C agree on another, but A to C not have a means for mid-call?  I
think so long as there is one default suite, this would not be a
problem.

There may be some corner cases here where the ciphersuite used on a hop
associated with a node in the path is not the one that will exist
mid-call due to Via/Record-Route differences.

Mike

> -----Original Message-----
> From: Eric Rescorla [mailto:[email-masked]] 
> Sent: Wednesday, July 05, 2006 9:40 AM
> To: Rajnish Jain
> Cc: [email-masked]
> Subject: Re: [Sip] Review of draft-srivastava-sip-e2e-ciphersuites-00
> 
> >> 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.
> >
> > 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.
> 
> This draft *isn't* end-to-end. End-to-end would be like in 
> RFC 2818 where there's a single TLS channel between UAC and 
> UAS. What this is is hop-by-hop with policy instructions.
> 
> > 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?
> 
> It might be, but a lot of experience with real TLS 
> deployments and the fact that there is a 
> mandatory-to-implement ciphersuite suggests that this will 
> not be a problem in practice.
> 
> 
> >> 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.
> 
> > 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.
> 
> Yes, you'll need some reverse channel that carries the same 
> data as the Via.
> 
> Yes, that's why I listed it as a disadvantage of the scheme 
> described in my e-mail message.
> 
> -Ekr
> 
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip