Re: Additional use cases? (Re: Plan for moving forward)

[Eric Rescorla <ekr@xxxxxxxxxxxxxxxxxxxx>]

At Tue, 12 Jun 2007 16:06:13 -0700,
Lakshminath Dondeti wrote:
> >> 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?

Not majorly, no. We're certainly not modifying the state machine to
the point where the caller knows which handshake message is being
sent.


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

If you send the ClientHello in the INVITE and there is forking, then
both forks will send you a ServerHello over the media plane. If this
is pre-200, then you need to DTLS negotiate with both of them. But
they (of course) have 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 he wants to be the DTLS client, then at the moment, yes. That's
why it's desirable for him to be the server. If it's really critical
for some reason for the SDP offerer to be the DTLS client, *and*
to have it work before early media, then yes, we would need to have
the answerer send a HelloRequest (this would require a modification
to the DTLS state machine, but it's a trivial one) in order to 
elicit the ClientHello.


> > 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?
 
Well, I for one have never clearly understood what you're trying to achieve.
You'll note that my response was to Dan's comment about tiebreakers.
So, yes, I guess you do have to start over.

-Ekr