Subject: [Perc] I-D Action: draft-ietf-perc-srtp-ekt-diet-09.txt

From: [email-masked]
Date: Wed, 17 Oct 2018 14:34:16 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Privacy Enhanced RTP Conferencing  WG of the IETF.

        Title           : Encrypted Key Transport for DTLS and Secure RTP
        Authors         : Cullen Jennings
                          John Mattsson
                          David A. McGrew
                          Dan Wing
                          Flemming Andreason
	Filename        : draft-ietf-perc-srtp-ekt-diet-09.txt
	Pages           : 24
	Date            : 2018-10-17

Abstract:
   Encrypted Key Transport (EKT) is an extension to DTLS (Datagram
   Transport Layer Security) and Secure Real-time Transport Protocol
   (SRTP) that provides for the secure transport of SRTP master keys,
   rollover counters, and other information within SRTP.  This facility
   enables SRTP for decentralized conferences by distributing a common
   key to all of the conference endpoints.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-perc-srtp-ekt-diet/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-perc-srtp-ekt-diet-09
https://datatracker.ietf.org/doc/html/draft-ietf-perc-srtp-ekt-diet-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-perc-srtp-ekt-diet-09

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Richard Barnes <[email-masked]>
Date: Wed, 17 Oct 2018 17:37:38 -0400

Ben: With this revision, and the one of -double just posted, I think these
two are ready for LC.

On Wed, Oct 17, 2018, 17:34 <[email-masked]> wrote:

> _______________________________________________
> Perc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perc
>

---

From: Ben Campbell <[email-masked]>
Date: Wed, 17 Oct 2018 16:52:05 -0500

Thanks!

I am in the process of reviewing the framework draft. I notice it has some normative language may conflict with this draft concerning rekeying. From our previous discussion:

> 
> - Next Sentence: "Outbound packets SHOULD continue to use the old SRTP Master Key for 250 ms after” Does that imply a normative requirement for recipients to keep old keys around for at least that long? There’s currently an implementation suggestion about that, but it doesn’t use MUST or SHOULD.
> (Editorial: The sentence seems to belong in the “outbound” section, not the “inbound” section.)
> 
> Yeah, moved this to the outbound section.  Added MAY-level inbound considerations to the implementation notes -- either the receiver can accept packet loss or do trial decryption.

If I am reading correctly, the framework (§4.5.2)  says senders MUST delay before sending media with the new key. Is that a conflict? If so, which is correct? Also, the framework does not specify the length of the delay.

Does it make sense for this to be specified in both places?

Ben.

> On Oct 17, 2018, at 4:37 PM, Richard Barnes <[email-masked]> wrote:
> 
> Ben: With this revision, and the one of -double just posted, I think these two are ready for LC.
> 
> On Wed, Oct 17, 2018, 17:34 <[email-masked] <mailto:[email-masked]>> wrote:
> 
> https://datatracker.ietf.org/doc/draft-ietf-perc-srtp-ekt-diet/ <https://datatracker.ietf.org/doc/draft-ietf-perc-srtp-ekt-diet/>
> 
> https://tools.ietf.org/html/draft-ietf-perc-srtp-ekt-diet-09 <https://tools.ietf.org/html/draft-ietf-perc-srtp-ekt-diet-09>
> https://datatracker.ietf.org/doc/html/draft-ietf-perc-srtp-ekt-diet-09 <https://datatracker.ietf.org/doc/html/draft-ietf-perc-srtp-ekt-diet-09>
> 
> https://www.ietf.org/rfcdiff?url2=draft-ietf-perc-srtp-ekt-diet-09 <https://www.ietf.org/rfcdiff?url2=draft-ietf-perc-srtp-ekt-diet-09>
> 
> 
> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
> 
> ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/perc <https://www.ietf.org/mailman/listinfo/perc>

---

From: Ben Campbell <[email-masked]>
Date: Wed, 17 Oct 2018 22:45:53 -0500

I’ve requested IETF LC for both.

Thanks!

Ben.

---

From: Richard Barnes <[email-masked]>
Date: Thu, 18 Oct 2018 14:50:00 -0400

Thanks for requesting LC for double and EKT.

With regard to this issue...

On Wed, Oct 17, 2018 at 5:52 PM Ben Campbell <[email-masked]> wrote:

> Thanks!
>
> I am in the process of reviewing the framework draft. I notice it has some
> normative language may conflict with this draft concerning rekeying. From
> our previous discussion:
>
>
>
>> - Next Sentence: "Outbound packets SHOULD continue to use the old SRTP
>> Master Key for 250 ms after” Does that imply a normative requirement for
>> recipients to keep old keys around for at least that long? There’s
>> currently an implementation suggestion about that, but it doesn’t use MUST
>> or SHOULD.
> Yeah, moved this to the outbound section.  Added MAY-level inbound
> considerations to the implementation notes -- either the receiver can
> accept packet loss or do trial decryption.
>
>
> If I am reading correctly, the framework (§4.5.2)  says senders MUST delay
> before sending media with the new key. Is that a conflict? If so, which is
> correct? Also, the framework does not specify the length of the delay.
>

There's sort of a conflict here.  The crux is here:

"""
   Since it may take some time for all of the
   endpoints in conference to finish re-keying, senders MUST delay a
   short period of time before sending media encrypted with the new
   master key, but it MUST be prepared to make use of the information
   from a new inbound EKT Key immediately.
"""

The first part talks about media keys, which conflicts with EKT; it should
probably be deleted.  The second part is about processing EKT tags, and
should be kept.  So we probably end up with something like the following:

"""
   In order to allow time for all endpoints in the conference to receive
the new keys,
   the sender should follow the recommendations in Section XXX of
[I-D.ietf-perc-srtp-ekt-diet].
   On receiving a new EKT Key, endpoints MUST be prepared to decrypt EKT
tags using the
   new key.  The EKT SPI field can be used to differentiate between tags
encrypted with
   the old and new keys.
"""

Would you mind just including this in your review, to maximize the
probability that Paul catches it?

Thanks,
--Richard

---

From: Ben Campbell <[email-masked]>
Date: Thu, 18 Oct 2018 13:58:41 -0500

> On Oct 18, 2018, at 1:50 PM, Richard Barnes <[email-masked]> wrote:
> 
> Would you mind just including this in your review, to maximize the probability that Paul catches it?
> 

I will do so. I’ve already captured it in my notes, but will adjust based on your comments.

Ben.