[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Additional use cases? (Re: Plan for moving forward)
On 6/12/2007 3:54 PM, Eric Rescorla wrote:
At Tue, 12 Jun 2007 15:45:52 -0700,
Lakshminath Dondeti wrote:
Interesting ... I wondered about the reasoning of multiple
serverhellos. Is the argument that multiple clienthellos are alright
since that amounts to lower overhead than multiple serverhellos (if the
expected response is HelloVerifyRequest, then the overhead might be
similar)?
Huh?
Most likely the calling party does DTLS handshakes with every peer who
answers. This is true no matter who is the client or the server.
Good, then there is no issue of overhead in comparing the two approaches.
But that seems to optimize for the forking use case and
ignores other use cases.
It's not an optimization. It's the basic operating mode of DTLS.
Why is the ClientHello going out-of-band a problem?
As I said, there are two problems. The first is that it's not how
DTLS was designed to work so it makes the layering a lot more complicated.
Well, aren't we already modifying the basic operation of TLS anyway to
facilitate the SRTP use case?
In programming terms you need to somehow grab the ClientHello and
shove it into the SIP message. The second problem is that if it's
going in the INVITE (which it must if it's to work with early
media) then there is the possibility of two DTLS instances
with the same ClientHello, which is not something that DTLS
was designed to do, and so would need a new security analysis.
I am not sure I understand the two DTLS instances with the same ClientHello.
As to why to do this: it seems to allow the use case I was talking about
and Dan was making a case for it too earlier today.
I don't really understand what use case you're talking about, but the
situation Dan is talking about can be solved perfectly well with
directional signalling in the SIP and then the entire DTLS handshake
in the media plane.
Ok, perhaps I don't understand this as well, but with directional
signaling in SIP, does the caller have to wait until a response from the
callee comes back in the SIP layer? How is that optimal? What happens
to early media considerations?
If you have some use case you think this doesn't work for, please explain
what that is.
Sigh! Haven't we been talking about it for a long while now? Do I have
to start over?
Lakshminath
-Ekr