Subject: [AVTCORE] comments on draft-ietf-avtcore-srtp-encrypted-header-ext-00.txt

From: Roni Even <[email-masked]>
Date: Tue, 12 Jul 2011 11:27:49 +0300

Hi,
I read the draft, some comments:

1. I think it needs an offer answer section. We need to specify the behavior
when an offer to encrypt the header is sent and the answerer do not support
the encryption header extension. Can alternatives, one with encryption and
one without be offered. 

2. Extmap can be a session level attribute. What about encryption, is it
only a media level.

In general are the offer answer rules from RFC 5285 applicable here and how.

Regards
Roni Even

---

From: Jonathan Lennox <[email-masked]>
Date: Tue, 12 Jul 2011 14:37:46 -0400

The intention is that from the point of view of an answerer that doesn't understand this spec, urn:ietf:params:rtp-hdrext:encrypt is just another unknown header extension element URI, so it will negotiate not to use it using the standard RFC 5285 mechanisms.

It's thus also possible to offer encrypted and non-encrypted versions of the same header extension element, if that's acceptable for security reasons.

I can add some explicit text explaining this in the next revision of the draft.

--
Jonathan Lennox
[email-masked]

---

From: Roni Even <[email-masked]>
Date: Tue, 12 Jul 2011 22:07:44 +0300

Hi Jonathan,
I think it will be good to have some such text.
What about the question about using it at the session level?

Thanks
Roni

> -----Original Message-----
> From: Jonathan Lennox [mailto:[email-masked]]
> Sent: Tuesday, July 12, 2011 9:38 PM
> To: Roni Even
> Cc: [email-masked]
> Subject: Re: comments on draft-ietf-avtcore-srtp-encrypted-header-ext-
> 00.txt
> 
> The intention is that from the point of view of an answerer that
> doesn't understand this spec, urn:ietf:params:rtp-hdrext:encrypt is
> just another unknown header extension element URI, so it will negotiate
> not to use it using the standard RFC 5285 mechanisms.
> 
> It's thus also possible to offer encrypted and non-encrypted versions
> of the same header extension element, if that's acceptable for security
> reasons.
>

---

From: Jonathan Lennox <[email-masked]>
Date: Tue, 12 Jul 2011 15:45:48 -0400

Hi, Roni --

If extensions are specified at the session level, it's straightforward if all the media streams are using SRTP -- the standard RFC 5285 rules apply.

If there's a mix of SRTP and non-SRTP media streams, either we can say that encrypted extension headers MUST be ignored for non-SRTP streams, or we can forbid specifying encrypted extension headers at the session level in this case.  I'm inclined towards the former, but would be fine with either option.

--
Jonathan Lennox
[email-masked]

---

From: Roni Even <[email-masked]>
Date: Wed, 13 Jul 2011 00:10:51 +0300

Jonathan,
I am OK with the first option.
Roni

> Sent: Tuesday, July 12, 2011 10:46 PM
> To: Roni Even
> Cc: [email-masked]
> If extensions are specified at the session level, it's straightforward
> if all the media streams are using SRTP -- the standard RFC 5285 rules
> apply.
> 
> If there's a mix of SRTP and non-SRTP media streams, either we can say
> that encrypted extension headers MUST be ignored for non-SRTP streams,
> or we can forbid specifying encrypted extension headers at the session
> level in this case.  I'm inclined towards the former, but would be fine
> with either option.
> 
> >>> 2. Extmap can be a session level attribute. What about encryption,
> is
> >> it
> >>> only a media level.
> >>>

---

From: Qin Wu <[email-masked]>
Date: Thu, 14 Jul 2011 16:15:50 +0800

One more comment to draft-ietf-avtcore-srtp-encrypted-header-ext:
This draft allocates two new lable value from 0x06 to 0x07 for k_he and k_hs, I am wondering
Is there a need in the IANA section to regiserter these values and if yes, who are responsible for regisering
 thes new values? Does it rely on key management protocol or SRTP protcol or this draft?

Regards!
-Qin
----- Original Message ----- 
From: "Roni Even" <[email-masked]>
To: <[email-masked]>
Cc: "'Jonathan Lennox'" <[email-masked]>
Sent: Tuesday, July 12, 2011 4:27 PM
Subject: [AVTCORE] comments ondraft-ietf-avtcore-srtp-encrypted-header-ext-00.txt

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

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 14 Jul 2011 11:15:22 -0400

Hi, Qin --

My inclination would be that label values are used rarely enough that there doesn't need to be an IANA registry for them -- they should only be allocated by standards action, and coordination is done by the usual working group consensus processes.

Is there some use case where these values would need to be allocated for non-standards-track purposes, or by working groups other than AVTCore?

--
Jonathan Lennox
[email-masked]

---

From: Qin Wu <[email-masked]>
Date: Fri, 15 Jul 2011 10:20:30 +0800

Hi,:
The old or new label value is used to calculate the encryption and salting keys that encrypt the either header or payload. 
It seems they should be registered somewhere. However I am not aware of any other SDO or organization use these values.
Anyway, I am okay with your clarification.

Regards!
-Qin