On Sat, 2009-06-06 at 12:31 +0200, Iñaki Baz Castillo wrote:
> Hi Dale, please don't take me wrong but that sounds too much exotic for me
> and
> I don't expect a SIP device being so clever in the next 25 years XD
I wouldn't be surprised if the peer-to-peer SIP people use such a
scheme. After a
El Viernes, 5 de Junio de 2009, Dale Worley escribió:
> > Anyhow, it seems that before securing the media transmission, it makes
> > sense to also secure the signalling. Since TLS secures the signalling
> > it allows the secure tranmission of master key for SRTP. This is, with
> > TLS you get all t
On Tue, 2009-06-02 at 18:14 +0200, Iñaki Baz Castillo wrote:
> Anyhow, it seems that before securing the media transmission, it makes
> sense to also secure the signalling. Since TLS secures the signalling
> it allows the secure tranmission of master key for SRTP. This is, with
> TLS you get all th
You're right it is inconvenience,
However in e-mail applications for example it is not considered to be
inconvenient,
The public keys can be retrieved and stored in the address book in the
same way as
secure email software does...
Thanks
Vadim
Paul Kyzivat wrote:
> A significant limitation in wh
A significant limitation in what you propose is that it requires Bob to
have a public key that Alice knows. In general we don't find that to be
the case in most telephony applications.
Thanks,
Paul
Vadim Lebedev wrote:
> I see,
> Well this particular attack could be prevented by
I see,
Well this particular attack could be prevented by adding a timestamp +
key validity period into the encrypted material...
This is still much cheaper than using SSL in signalling path.
Actually the current approach (SSL in signalling path and rtp key in
clear in SDP) seems to be weaker i
Man in a middle. Encrypted key can be stored and re-used by man-in-a-
middle to forge future conversations (to garble the stream). Further
enhancing your suggestion will bring us close to SSL/TLS I am afraid.
On Jun 2, 2009, at 8:27 AM, Vadim Lebedev wrote:
> Vadim Lebedev wrote:
>
> Any thoug
2009/6/2 Vadim Lebedev :
> Vadim Lebedev wrote:
>
> Any thoughts on this issue?
> I've just realised that this approach will make lawful interception
> REALLY complicated... Maybe this
> is the reason there is no an RFC covering it? Or am i missing something?
I don't know the RFC 4568, but if you
Vadim Lebedev wrote:
Any thoughts on this issue?
I've just realised that this approach will make lawful interception
REALLY complicated... Maybe this
is the reason there is no an RFC covering it? Or am i missing something?
Thanks
Vadim
> Hello,
>
> I've been reading various RFC describing tran
Hello,
I've been reading various RFC describing tranmission of master key
for SRTP unside SDP's.
They require (like in rfc4568) the INVITE/200/ACK be transmitted using
TLS to avoid key interception.
I wonder why nobody proped following scheme:
Alice generates a mester key, encrypts it wih B
10 matches
Mail list logo
