> > 4. I don't actually think there's any protocol engineering required
> > here. The problem of how to arrange for TLS traffic key
> disclosure
> > to third parties without modifying the wire protocol has
> been quite
> > extensively studied and a broad variety of approaches exist,
> > covering a range of levels of active/passiveness, real-timeness,
> > cooperation from the endpoints, etc. Techniques exist which are
> > significantly better than those indicated by Dan. For instance,
> > consider that if you have the TLS server's private key and you're
> > doing RSA, you can do completely passive inspection with no
> > cooperation from either side.
>
> I am aware of that technique; however, for SIP calls with the
> offer in the in the Invite, you could only intercept outgoing
> calls, because incoming calls cause your intercept target to
> be the TLS client. I don't believe that technique is viable
> to meet R24.
>
> > Another example would be [GBGP03].
>
> I was not aware of that technique; thanks for the pointer.
> That technique seems useful.
>
> (Direct link,
> http://crypto.stanford.edu/~pgolle/papers/escrow.pdf)
This is an interesting paper, but doesn't it require also some form of
cooperating client (as required in draft-wing-sipping-srtp-key) as it
would be necessary to exchange at least one of the SSL libs of the
clients?
Ciao
Steffen
>
> > Also, as Jon Peterson observed, the owner of the namespace can
> > always enforce any restrictions that it wants. It's possible that
> > imposes significant performance costs, but it's not clear that
> > that's true in all cases with clever implementation.
> >
> > I don't really have time right now to go into any of this stuff
> > in more detail, but I'd certainly be happy to sit down with
> > anyone who cares in YVR and explain the state of the art.
>
> Thanks for the offer.
>
> > I don't
> > really see that this is really relevant to what happens in this
> > WG, though.
>
> If 3GPP decides to use something other than DTLS-SRTP, we
> will have two standards for SRTP keying -- the IETF standard
> and the non-IETF standard. I do not consider that desirable.
>
> -d
>
>
> > -Ekr
> >
> >
> > [GBGP03] E.-J. Goh, D. Boneh, P. Golle, B. Pinkas",
> > The Design and Implementation of Protocol-Based Hidden
> > Key Recovery", 2003.
>
>
> _______________________________________________
> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use
> [EMAIL PROTECTED] for questions on current sip
> Use [EMAIL PROTECTED] for new developments on the application of sip
>
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
