Subject: Re: [AVT] Comments on draft-wing-avt-dtls-srtp-key-transport-01

From: "Dan Wing" <[email-masked]>
Date: Mon, 21 Jul 2008 15:57:58 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Eric Rescorla
> Sent: Tuesday, March 11, 2008 7:19 AM
> To: [email-masked]
> Subject: [AVT] Comments on draft-wing-avt-dtls-srtp-key-transport-01
> 
> $Id: draft-wing-avt-dtls-key-transport-01-rev.txt,v 1.1 
> 2008/03/11 13:57:27 ekr Exp $

I recently posted -02 of this draft,
http://tools.ietf.org/html/draft-wing-avt-dtls-srtp-key-transport-02, which
addresses several of Eric's
concerns.  Differences are at:
http://www.tools.ietf.org/rfcdiff?url2=http://tools.ietf.org/id/draft-wing-avt
-dtls-srtp-key-transport-02.txt

> GENERAL COMMENTS
> DTLS-SRTP was explicitly designed for point-to-point sessions in which
> there were two communication parties. This implies that a number of
> RTP settings (e.g., conference bridges/mixers), need to be implemented
> as a number of pairwise DTLS-SRTP connections. Thus, for instance,
> when a single caller on a conference bridge speaks, the bridge needs
> to reencrypt the data for all recipients separately. There has been
> debate about how serious this performance issue is, but people
> certainly have been concerned about it.
> 
> This draft describes a mechanism which allows one side of a DTLS-SRTP
> association to impose a key of its choice on the other side. Thus, for
> instance, the mixer/bridge could give each caller the same receiving
> key (the one that the bridge uses to send/encrypt). Thus, the bridge
> can only perform one encryption instead of one for each recipient.
> This doesn't seem like a crazy idea.
> 
> That said, I have two major concerns about the particular mechanism
> described in this document:
> 
> - It's specified at the DTLS layer but it's only useful for DTLS-SRTP,
>   and doesn't really affect the DTLS part at all. I would prefer to
>   see this either specified as a TLS extension that applies to TLS in
>   all contexts, or to be specified purely as a feature of SRTP
>   (a la EKT, though I'm not claiming it's adequate as-is).

Dtls-srtp-key-transport is specified as an extension to DTLS-SRTP, 
such that it would only be negotiated as part of a 
draft-ietf-avt-dtls-srtp-03.txt handshake.

> - The mechanism described here seems a lot more complicated 
>   (the ability to request keys, convey SSRCs, etc.) than required
>   by the requirements I'm aware of.

The mechanism has been simplified by removal of the YourNewSRTPKey
and DeleteSRTPKey primitives.

> DETAILED COMMENTS
> S 4.1.
>    After successful negotiation of the key_transport 
> extension, the DTLS
>    client and server MAY exchange SRTP packets, encrypted 
> using the KDF
>    described in [I-D.ietf-avt-dtls-srtp].  This is normal and 
> expected,
> 
> I wouldn't write this as "encrypted using the KDF". The keys 
> are generated
> with a KDF, but the packets aren't.

I missed this change in -02; sorry.  It will be picked up in -03.
 
> S 4.2.
> What's the need to request a new key.

It is necessary in the "Point to Multipoint Using Video Switching MCUs" 
scenario, where the speaker is unaware of listeners being 
added/removed by the video switcher.

> I don't understand why the SSRC needs to be communicated, given that
> DTLS-SRTP already describes mechanisms for SSRC->Key Material mapping.

In DTLS-SRTP, there is one SRTP key active at any point in time.  In
DTLS-SRTP-Key-Transport, there are several SRTP keys active at any
point in time:  one SRTP key for each speaker.

> Also, this breaks the general RTP model that implies that new SSRCs
> can be introduced at any time, which (though I'm no RTP expert)
> seems like it's going to be a lot worse in mutiparty cases. 

New SSRCs can be introduced at any time, but we need to know which
(of the several) keys to associate with the incoming packet.  If
there are dozens of speakers, the receipt of a new SRTP packet with
a never-before-seen SSRC will force (a) using SRTP authentication 
and (b) cause the receiver to try all SRTP keys it knows, in order
to discern which SRTP key is suitable.

This seems undesirable to me, but I'm willing to be convinced by
RTP experts that it is desirable.  A brief discussion is in
http://tools.ietf.org/html/draft-wing-avt-dtls-srtp-key-transport-02#section-4
.3.4

> I don't understand wy keys need to be deleted.

This has been removed in -02.

> Under what circumstances would these messages be large enough to
> exceed 512 bytes and thus potentially need fragmentation?

When a listener joins, it can be desirable to immediately send the 
listener with all of the speakers' keys, so that the listener
can authenticate and decrypt an SRTP packet arriving from any
of the speakers.

Also by supporting fragmentation initially, we don't have to
worry about adding it later for small-MTU links or for large
keys in the future.

-d

> -Ekr
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt