[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: DTLS-SRTP harming GETS [was RE: Additional use cases? (Re: Plan for moving forward)]
At Tue, 12 Jun 2007 18:59:32 -0700,
Lakshminath Dondeti wrote:
> Hmm, interesting choice of words.
> All I was saying was that there is a class of applications that we
> should be able to optimize for. Skipping client authentication during
> secure tunnel establishment and using a legacy method inside the secure
> tunnel is a mode of operation allowed elsewhere in the IETF (e.g., TTLS,
> PEAP, IKEv2-EAP). However, we seem to be not allowing that with
> DTLS-SRTP. We mandate the client to authenticate using self-signed
> certs. There are use cases where that client authentication has a
> purpose. Elsewhere it is wasteful.
I'm not convinced that that's true. Again, the client authentication's
job is to tie the signalling to the media. I haven't yet heard from
you a case where that's clearly not desirable. Even in cases where
you don't care who you are talking to or you have some in-tunnel way
of doing so, you still need to tie it to the signalling, because
you depend on the signalling for things like call transfer.
> Is there "harm" due to that
> additional requirement? I am saying why does one have to fight that
> battle in making a case to other standards organizations in adopting
> IETF protocols. I can think of simple counter arguments: do what is
> necessary and nothing more.
> The only argument against that I see so far is that DTLS-SRTP is the
> chosen protocol and the chosen protocol must not be changed.
Funny, I don't recall anyone making that argument.
I do, however, recall making that argument both earlier on this
thread and at several IETF meetings.