Encrypted Key Transport for DTLS and Secure RTP
draft-ietf-perc-srtp-ekt-diet-13
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2021-01-14 |
13 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2020-09-08 |
13 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2020-07-20 |
13 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2020-07-20 |
13 | (System) | RFC Editor state changed to RFC-EDITOR from IANA |
2020-07-20 |
13 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2020-07-20 |
13 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2020-07-15 |
13 | (System) | RFC Editor state changed to IANA from EDIT |
2020-06-26 |
13 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2020-06-26 |
13 | (System) | IANA Action state changed to In Progress from On Hold |
2020-06-26 |
13 | (System) | IANA Action state changed to On Hold from In Progress |
2020-06-24 |
13 | (System) | RFC Editor state changed to EDIT |
2020-06-24 |
13 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2020-06-24 |
13 | (System) | Announcement was received by RFC Editor |
2020-06-23 |
13 | (System) | IANA Action state changed to In Progress |
2020-06-23 |
13 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2020-06-23 |
13 | Amy Vezza | IESG has approved the document |
2020-06-23 |
13 | Amy Vezza | Closed "Approve" ballot |
2020-06-23 |
13 | Amy Vezza | Ballot approval text was generated |
2020-06-23 |
13 | Amy Vezza | Ballot writeup was changed |
2020-06-23 |
13 | Murray Kucherawy | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2020-06-23 |
13 | Murray Kucherawy | [Ballot comment] Adam Roach's comments were addressed in: https://github.com/ietf/perc-wg/pull/180 |
2020-06-23 |
13 | Murray Kucherawy | [Ballot Position Update] Position for Murray Kucherawy has been changed to Yes from No Record |
2020-06-23 |
13 | Cullen Jennings | New version available: draft-ietf-perc-srtp-ekt-diet-13.txt |
2020-06-23 |
13 | (System) | New version approved |
2020-06-23 |
13 | (System) | Request for posting confirmation emailed to previous authors: Dan Wing <dwing-ietf@fuggles.com>, David McGrew <mcgrew@cisco.com>, Flemming Andreasen <fandreas@cisco.com>, John Mattsson <john.mattsson@ericsson.com>, Cullen Jennings <fluffy@iii.ca> |
2020-06-23 |
13 | Cullen Jennings | Uploaded new revision |
2020-06-22 |
12 | Murray Kucherawy | Requested one more round over Adam's non-editorial comments. |
2020-06-22 |
12 | Murray Kucherawy | IESG state changed to IESG Evaluation::AD Followup from Approved-announcement to be sent |
2020-06-22 |
12 | Murray Kucherawy | [Ballot Position Update] Position for Murray Kucherawy has been changed to No Record from Yes |
2020-06-22 |
12 | Murray Kucherawy | [Ballot Position Update] New position, Yes, has been recorded for Murray Kucherawy |
2020-06-22 |
12 | Murray Kucherawy | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2020-06-22 |
12 | Magnus Westerlund | [Ballot comment] Thanks for addressing the issue. |
2020-06-22 |
12 | Magnus Westerlund | [Ballot Position Update] Position for Magnus Westerlund has been changed to No Objection from Discuss |
2020-06-18 |
12 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2020-06-18 |
12 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2020-06-18 |
12 | Cullen Jennings | New version available: draft-ietf-perc-srtp-ekt-diet-12.txt |
2020-06-18 |
12 | (System) | New version approved |
2020-06-18 |
12 | (System) | Request for posting confirmation emailed to previous authors: David McGrew <mcgrew@cisco.com>, Cullen Jennings <fluffy@iii.ca>, John Mattsson <john.mattsson@ericsson.com>, Dan Wing <dwing-ietf@fuggles.com>, Flemming Andreasen <fandreas@cisco.com> |
2020-06-18 |
12 | Cullen Jennings | Uploaded new revision |
2020-03-25 |
11 | Amy Vezza | Shepherding AD changed to Murray Kucherawy |
2020-02-07 |
11 | Alexey Melnikov | Ballot writeup was changed |
2020-02-06 |
11 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2020-02-06 |
11 | Éric Vyncke | [Ballot comment] Thank you for the work put into this document. Please find below two non-blocking questions. NB: the document shepherd write-up should be updated … [Ballot comment] Thank you for the work put into this document. Please find below two non-blocking questions. NB: the document shepherd write-up should be updated with the responsible AD ;-) Regards, -éric About section 4.3.1 What is a "packet" in the context of "appended to the packet"? Is it the UDP payload ? Should the UDP length be increased? is it the layer-2 frame ? I also wonder whether 250 msec is enough in all case... Unsure whether SRTP is only used in real-time communication (for info, just reviewed 2 I-D from Delay Tolerant Network... so I may be biased) |
2020-02-06 |
11 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2020-02-06 |
11 | Alexey Melnikov | [Ballot comment] Note to self: make sure editors look/respond to Adam’s and Ben’s comments. Old comments preserved for posterity. I didn't check if they still … [Ballot comment] Note to self: make sure editors look/respond to Adam’s and Ben’s comments. Old comments preserved for posterity. I didn't check if they still apply: I share Benjamin's concern about extensibility. In 4.4.1: The default EKT Cipher is the Advanced Encryption Standard (AES) Key Wrap with Padding [RFC5649] algorithm. It requires a plaintext length M that is at least one octet, and it returns a ciphertext with a length of N = M + (M mod 8) + 8 octets. I started looking at RFC 5649. Maybe I was tired and my math was wrong, but I couldn't figure out how you came up with the N value above. In particular, where is the "+ 8" coming from? In 6: An attacker who tampers with the bits in FullEKTField can prevent the intended receiver of that packet from being able to decrypt it. This is a minor denial of service vulnerability. Similarly the attacker could take an old FullEKTField from the same session and attach it to the packet. The FullEKTField would correctly decode and pass integrity checks. However, the key extracted from the FullEKTField , when used to decrypt the SRTP payload, would be wrong and the SRTP integrity check would fail. Note that the FullEKTField only changes the decryption key and does not change the encryption key. None of these are considered significant attacks as any attacker that can modify the packets in transit and cause the integrity check to fail. The last sentence seems to be incomplete. Did you mean "can" instead of the last "and"? |
2020-02-06 |
11 | Alexey Melnikov | Ballot comment text updated for Alexey Melnikov |
2020-02-05 |
11 | Benjamin Kaduk | [Ballot comment] We say that EKT can work well in scenarios such as the PERC private media framework, and in the security considerations we give … [Ballot comment] We say that EKT can work well in scenarios such as the PERC private media framework, and in the security considerations we give some information about concerns/caveats with respect to EKT usage in terms of the low-level cryptographic properties. Do we want to give some high-level advice about deployment scenarios in which EKT does not make sense? I also wonder if the "ekt" name is a little generic for the TLS codepoints being requested, as opposed to something involving "srtp_ekt", but that's basically cosmetic. Updating to include my previous comments, since (as for Adam) they largely seem to have not been acted upon: This document is written under the assumption that the EKT content will be the only content after the encrypted SRTP payload (and authentication tag, if present). That's true at present, of course, but I would still like to see a little discussion of how it might coexist with other SRTP extensions that place content as a trailer (both would need to be parseable from the tail of the content and have a length field; and they woule either need to share a message-type namespace or have a profile specification to indicate what order they appear in), though the discussion that already occurred suffices to make this not a Discuss-level point. Section 5 has: the DTLS-SRTP peer in the server role to the client. This allows those peers to process EKT keying material in SRTP (or SRTCP) and retrieve the embedded SRTP keying material. This combination of but in Section 4 we say that "use with SRTCP would be similar, but is reserved for a future specification". (There may be one or two other places that have text placing SRTCP on the same footing as SRTP even though they are not, at present.) Also section 5 In cases where the DTLS termination point is more trusted than the media relay, the protection that DTLS affords to EKT key material can allow EKT keys to be tunneled through an untrusted relay such as a centralized conference bridge. For more details, see [I-D.ietf-perc-private-media-framework]. I did not chase the reference, but it seems like this sentence might apply equally for "EKT keys to be tunneled" and "SRTP master keys to be tunneled". I trust the authors to say what they mean :) Section 5.2.2 What do I do when I receive an EKTKey containing an ekt_spi value for which I already have stored parameters? When an EKTKey is received and processed successfully, the recipient MUST respond with an Ack handshake message as described in Section 7 of [I-D.ietf-tls-dtls13]. The EKTKey message and Ack MUST be Ack is a content type, not a handshake type. (Per DISCUSS point) When an EKTKey is received and processed successfully, the recipient MUST respond with an Ack handshake message as described in Section 7 of [I-D.ietf-tls-dtls13]. The EKTKey message and Ack MUST be retransmitted following the rules in Section 4.2.4 of [RFC6347]. It's a little weird to cite DTLS 1.3 for the Ack message but then revert to DTLS 1.2 for the retransmission schedule... EKT MAY be used with versions of DTLS prior to 1.3. In such cases, the Ack message is still used to provide reliability. Thus, DTLS implementations supporting EKT with DTLS pre-1.3 will need to have explicit affordances for sending the Ack message in response to an EKTKey message, and for verifying that an Ack message was received. The retransmission rules for both sides are the same as in DTLS 1.3. ...but here we say that the DTLS 1.3 retransmission rules are authoritative. (per DISCUSS) Section 6 With EKT, each SRTP sender and receiver MUST generate distinct SRTP master keys. This property avoids any security concern over the re- Er, does an SRTP receiver have a master key ("what does it encrypt if it's not sending anything")? In some systems, when a member of a conference leaves the conferences, the conferences is rekeyed so that member no longer has the key. When changing to a new EKTKey, it is possible that the attacker could block the EKTKey message getting to a particular endpoint and that endpoint would keep sending media encrypted using the old key. To mitigate that risk, the lifetime of the EKTKey MUST be limited using the ekt_ttl. Do we want to give any concrete guidance about ekt_ttl values? |
2020-02-05 |
11 | Benjamin Kaduk | Ballot comment text updated for Benjamin Kaduk |
2020-02-05 |
11 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2020-02-05 |
11 | Magnus Westerlund | [Ballot discuss] I think there are an important discrpency between the figure and the ABNF for the full EKT message in section 4.1: Figure 1: … [Ballot discuss] I think there are an important discrpency between the figure and the ABNF for the full EKT message in section 4.1: Figure 1: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : EKT Ciphertext : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameter Index | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 1 0| +-+-+-+-+-+-+-+-+ The ABNF parts that appears relevant: EKTCiphertext = 1*256BYTE ; EKTEncrypt(EKTKey, EKTPlaintext) Epoch = 2BYTE SPI = 2BYTE FullEKTField = EKTCiphertext SPI Epoch EKTMsgLength EKTMsgTypeFull Note that the above ABNF states that the SPI is followed by a 16-bit Epoch field prior to the length field. Can you please ensure that this discrepancy is clarified. |
2020-02-05 |
11 | Magnus Westerlund | [Ballot Position Update] New position, Discuss, has been recorded for Magnus Westerlund |
2020-02-04 |
11 | Barry Leiba | [Ballot comment] I agree that Adam’s comments need to be addressed. |
2020-02-04 |
11 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2020-02-04 |
11 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2020-02-04 |
11 | Roman Danyliw | [Ballot comment] The document appears to have already gotten significant review with iterative updates. Section 5.2. If an EKTKey message is received that cannot … [Ballot comment] The document appears to have already gotten significant review with iterative updates. Section 5.2. If an EKTKey message is received that cannot be processed, then the recipient MUST respond with an appropriate DTLS alert. Is there any more specificity that can be provided on which DTLS alert might be appropriate? |
2020-02-04 |
11 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2020-02-03 |
11 | Adam Roach | [Ballot comment] Re-sending my initial comments, as only one of the 17 were addressed in subsequent revisions. While no single comment rises to the level … [Ballot comment] Re-sending my initial comments, as only one of the 17 were addressed in subsequent revisions. While no single comment rises to the level of a DISCUSS-worthy issue, several of these are moderately severe. I would appreciate either a response to each comment, or a corresponding change in the document. --------------------------------------------------------------------------- Thanks to the work that everyone has put in on getting an EKT mechanism specified and finalized. I have a handful of comments that I would like to see considered prior to publication of the document. --------------------------------------------------------------------------- §1: > EKT provides a way for an SRTP session participant, to securely > transport its SRTP master key and current SRTP rollover counter to > the other participants in the session. Nit: "...participant to securely..." --------------------------------------------------------------------------- §4.1: > EKTMsgTypeExtension = %x03-FF Shouldn't this be "%x01 / %x03-ff" ? > SRTPMasterKeyLength = BYTE > SRTPMasterKey = 1*256BYTE I think this either needs to be "1*255BYTE", or we need text that explicitly indicates that an SRTPMasterKeyLength value of 0x00 means "256 bytes." Probably the former. I think this is even further constrained by the fact that EKTCiphertext is limited to 256 bytes, and contains the SRTPMasterKeyLength, SRTPMasterKey, SSRC, and ROC (and is not compressed) -- which means the SRTPMasterKeyLength can't be more than (256 - 1 - 4 - 4 =) 247 bytes. So perhaps "1*247BYTE" is more appropriate? --------------------------------------------------------------------------- §4.2.1: > The creation of the EKTField MUST precede the normal SRTP > packet processing. Why? This seems unnecessary and unnecessarily complicated. If the order of operations has an impact on the bits on the wire (I don't see how it does?), then please include some explanatory text here that clarifies the reason for this constraint. --------------------------------------------------------------------------- §4.2.1: > When a packet is sent with the ShortEKTField, the ShortEKFField is > simply appended to the packet. Nit: s/ShortEKFField/ShortEKTField/ --------------------------------------------------------------------------- §4.2.1: > 5. If the SSRC in the EKTPlaintext does not match the SSRC of the > SRTP packet received, then all the information from this > EKTPlaintext MUST be discarded and the following steps in this > list are skipped. I can see implementors easily interpreting this as requiring them to discard the RTP payload as well. If that's not the intention (I don't think it is), consider adding text like "The FullEKTField is removed from the packet then normal SRTP or SRTCP processing occurs." --------------------------------------------------------------------------- §4.3: > Section 4.2.1 recommends that SRTP senders continue using an old key > for some time after sending a new key in an EKT tag. This is the first appearance of the phrase "EKT tag," which never seems to be properly defined. I presume this is meant to be the combination of the EKT Ciphertext and the SPI? In any case, please clearly define this term somewhere, preferably before using it the first time. --------------------------------------------------------------------------- §4.3: > cannot be used and they also need to create a counter that keeps > track of how many times the key has been used to encrypt data to > ensure it does not exceed the T value for that cipher (see ). The parenthetical phrase appears to be missing something here. > If > either of these limits are exceeded, the key can no longer be used Nit: "...either... is exceeded..." > for encryption. At this point implementation need to either use the Nit: "...implementations need..." --------------------------------------------------------------------------- §4.5: > If a source has its EKTKey changed by the key management, it MUST > also change its SRTP master key I suppose it's not terribly important for interop, but the implication that this change takes place immediately seems to contradict the 250 ms period specified in §4.2.1. Perhaps a few words here about how these two normative statements are intended to interact would save implementors a bit of grief. --------------------------------------------------------------------------- §4.6: > This document defines the use of EKT with SRTP. Its use with SRTCP > would be similar, but is reserved for a future specification. After reading this far, I was quite surprised to find this qualification. If this is the intention for this document, please adjust the rest of the text to match. Some examples follow. > The following shows the syntax of the EKTField expressed in ABNF > [RFC5234]. The EKTField is added to the end of an SRTP or SRTCP > packet. ----- > Rollover Counter (ROC): On the sender side, this is set to the > current value of the SRTP rollover counter in the SRTP/SRTCP context > associated with the SSRC in the SRTP or SRTCP packet. ----- > 1. The final byte is checked to determine which EKT format is in > use. When an SRTP or SRTCP packet contains a ShortEKTField, the > ShortEKTField is removed from the packet then normal SRTP or > SRTCP processing occurs. ----- > The reason for > using the last byte of the packet to indicate the type is that > the length of the SRTP or SRTCP part is not known until the > decryption has occurred. ----- > 7. At this point, EKT processing has successfully completed, and the > normal SRTP or SRTCP processing takes place. ----- > This allows > those peers to process EKT keying material in SRTP (or SRTCP) and > retrieve the embedded SRTP keying material. --------------------------------------------------------------------------- §4.7: > To accommodate packet loss, it is > RECOMMENDED that three consecutive packets contain the > FullEKTField be transmitted. Nit: "...containing..." (alternately, remove "be transmitted" -- both make a grammatically correct sentance) More substantially -- under "New sender:", I'm a little surprised that there isn't any mention of other senders re-keying in response to a new sender joining. In the vast majority of conferences, when a sender joins, that same entity generally will also be a receiver. It seems this should trigger other senders to include the key in their next packet. --------------------------------------------------------------------------- §4.7: > Rekey: > By sending EKT tag over SRTP, the rekeying event shares fate with > the SRTP packets protected with that new SRTP master key. Is this actually true? Going back to the 250 ms period specified in §4.2.1, it seems that the master key is sent out in packets pretty far removed from those it actually protects. Between this and the inconsistency I mention in §4.5 above, this increasingly feels like maybe there were two different ways of reasoning about the timing of sending a master key versus the timing of actually using it. Does the text in §4.2.1 perhaps represent an outdated notion of how this is intended to work? --------------------------------------------------------------------------- §4.7: > If sending audio and video, the RECOMMENDED > frequency is the same as the rate of intra coded video frames. If > only sending audio, the RECOMMENDED frequency is every 100ms. Is this "100ms" correct? Assuming, say, the use of Opus at voice quality with 20 ms packets, this is taking packets on the order of 40 bytes in length and tacking on something like 20 to 30 bytes to every fifth packet. That's an increase in overall stream size on the order of roughly 15% to 20%. At the same time, when using real-time video, intra frames are going to happen roughly every 500 ms to 1500 ms. If a cadence on that order is okay for audiovisual streams, I have to imagine it's okay for audio streams. So, to clarify: is this "100ms" a typo for "1000 ms"? --------------------------------------------------------------------------- §7.2: > +----------+-------+---------------+ > | Name | Value | Specification | > +----------+-------+---------------+ > | AESKW128 | 1 | RFCAAAA | > | AESKW256 | 2 | RFCAAAA | > | Reserved | 255 | RFCAAAA | > +----------+-------+---------------+ > > Table 3: EKT Cipher Types Section 5.2.1 reserves "0" as well. I suspect we want to replicate that reservation in this table. |
2020-02-03 |
11 | Adam Roach | Ballot comment text updated for Adam Roach |
2020-02-03 |
11 | Benjamin Kaduk | [Ballot comment] We say that EKT can work well in scenarios such as the PERC private media framework, and in the security considerations we give … [Ballot comment] We say that EKT can work well in scenarios such as the PERC private media framework, and in the security considerations we give some information about concerns/caveats with respect to EKT usage in terms of the low-level cryptographic properties. Do we want to give some high-level advice about deployment scenarios in which EKT does not make sense? I also wonder if the "ekt" name is a little generic for the TLS codepoints being requested, as opposed to something involving "srtp_ekt", but that's basically cosmetic. |
2020-02-03 |
11 | Benjamin Kaduk | Ballot comment text updated for Benjamin Kaduk |
2020-01-31 |
11 | Christer Holmberg | Request for Telechat review by GENART Completed: Ready with Issues. Reviewer: Christer Holmberg. Sent review to list. |
2020-01-30 |
11 | Jean Mahoney | Request for Telechat review by GENART is assigned to Christer Holmberg |
2020-01-30 |
11 | Jean Mahoney | Request for Telechat review by GENART is assigned to Christer Holmberg |
2020-01-30 |
11 | Alexey Melnikov | Telechat date has been changed to 2020-02-06 from 2019-02-21 |
2020-01-30 |
11 | Alexey Melnikov | [Ballot comment] I need one more review from IESG of this document. Old comments preserved for posterity. I didn't check if they still apply: I … [Ballot comment] I need one more review from IESG of this document. Old comments preserved for posterity. I didn't check if they still apply: I share Benjamin's concern about extensibility. In 4.4.1: The default EKT Cipher is the Advanced Encryption Standard (AES) Key Wrap with Padding [RFC5649] algorithm. It requires a plaintext length M that is at least one octet, and it returns a ciphertext with a length of N = M + (M mod 8) + 8 octets. I started looking at RFC 5649. Maybe I was tired and my math was wrong, but I couldn't figure out how you came up with the N value above. In particular, where is the "+ 8" coming from? In 6: An attacker who tampers with the bits in FullEKTField can prevent the intended receiver of that packet from being able to decrypt it. This is a minor denial of service vulnerability. Similarly the attacker could take an old FullEKTField from the same session and attach it to the packet. The FullEKTField would correctly decode and pass integrity checks. However, the key extracted from the FullEKTField , when used to decrypt the SRTP payload, would be wrong and the SRTP integrity check would fail. Note that the FullEKTField only changes the decryption key and does not change the encryption key. None of these are considered significant attacks as any attacker that can modify the packets in transit and cause the integrity check to fail. The last sentence seems to be incomplete. Did you mean "can" instead of the last "and"? |
2020-01-30 |
11 | Alexey Melnikov | Ballot comment text updated for Alexey Melnikov |
2020-01-30 |
11 | Alexey Melnikov | Set telechat returning item indication |
2020-01-30 |
11 | Alexey Melnikov | IESG state changed to IESG Evaluation from Approved-announcement to be sent |
2020-01-16 |
11 | Alexey Melnikov | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2020-01-16 |
11 | Alexey Melnikov | [Ballot comment] Old comments preserved for posterity. I didn't check if they still apply: I share Benjamin's concern about extensibility. In 4.4.1: The default … [Ballot comment] Old comments preserved for posterity. I didn't check if they still apply: I share Benjamin's concern about extensibility. In 4.4.1: The default EKT Cipher is the Advanced Encryption Standard (AES) Key Wrap with Padding [RFC5649] algorithm. It requires a plaintext length M that is at least one octet, and it returns a ciphertext with a length of N = M + (M mod 8) + 8 octets. I started looking at RFC 5649. Maybe I was tired and my math was wrong, but I couldn't figure out how you came up with the N value above. In particular, where is the "+ 8" coming from? In 6: An attacker who tampers with the bits in FullEKTField can prevent the intended receiver of that packet from being able to decrypt it. This is a minor denial of service vulnerability. Similarly the attacker could take an old FullEKTField from the same session and attach it to the packet. The FullEKTField would correctly decode and pass integrity checks. However, the key extracted from the FullEKTField , when used to decrypt the SRTP payload, would be wrong and the SRTP integrity check would fail. Note that the FullEKTField only changes the decryption key and does not change the encryption key. None of these are considered significant attacks as any attacker that can modify the packets in transit and cause the integrity check to fail. The last sentence seems to be incomplete. Did you mean "can" instead of the last "and"? |
2020-01-16 |
11 | Alexey Melnikov | [Ballot Position Update] Position for Alexey Melnikov has been changed to Yes from Discuss |
2020-01-15 |
11 | Benjamin Kaduk | [Ballot comment] Thank you for addressing my Discuss points! Original COMMENT preserved below for posterity. This document is written under the assumption that the EKT … [Ballot comment] Thank you for addressing my Discuss points! Original COMMENT preserved below for posterity. This document is written under the assumption that the EKT content will be the only content after the encrypted SRTP payload (and authentication tag, if present). That's true at present, of course, but I would still like to see a little discussion of how it might coexist with other SRTP extensions that place content as a trailer (both would need to be parseable from the tail of the content and have a length field; and they woule either need to share a message-type namespace or have a profile specification to indicate what order they appear in), though the discussion that already occurred suffices to make this not a Discuss-level point. Section 5 has: the DTLS-SRTP peer in the server role to the client. This allows those peers to process EKT keying material in SRTP (or SRTCP) and retrieve the embedded SRTP keying material. This combination of but in Section 4 we say that "use with SRTCP would be similar, but is reserved for a future specification". (There may be one or two other places that have text placing SRTCP on the same footing as SRTP even though they are not, at present.) Also section 5 In cases where the DTLS termination point is more trusted than the media relay, the protection that DTLS affords to EKT key material can allow EKT keys to be tunneled through an untrusted relay such as a centralized conference bridge. For more details, see [I-D.ietf-perc-private-media-framework]. I did not chase the reference, but it seems like this sentence might apply equally for "EKT keys to be tunneled" and "SRTP master keys to be tunneled". I trust the authors to say what they mean :) Section 5.2.2 What do I do when I receive an EKTKey containing an ekt_spi value for which I already have stored parameters? When an EKTKey is received and processed successfully, the recipient MUST respond with an Ack handshake message as described in Section 7 of [I-D.ietf-tls-dtls13]. The EKTKey message and Ack MUST be Ack is a content type, not a handshake type. (Per DISCUSS point) When an EKTKey is received and processed successfully, the recipient MUST respond with an Ack handshake message as described in Section 7 of [I-D.ietf-tls-dtls13]. The EKTKey message and Ack MUST be retransmitted following the rules in Section 4.2.4 of [RFC6347]. It's a little weird to cite DTLS 1.3 for the Ack message but then revert to DTLS 1.2 for the retransmission schedule... EKT MAY be used with versions of DTLS prior to 1.3. In such cases, the Ack message is still used to provide reliability. Thus, DTLS implementations supporting EKT with DTLS pre-1.3 will need to have explicit affordances for sending the Ack message in response to an EKTKey message, and for verifying that an Ack message was received. The retransmission rules for both sides are the same as in DTLS 1.3. ...but here we say that the DTLS 1.3 retransmission rules are authoritative. (per DISCUSS) Section 6 With EKT, each SRTP sender and receiver MUST generate distinct SRTP master keys. This property avoids any security concern over the re- Er, does an SRTP receiver have a master key ("what does it encrypt if it's not sending anything")? In some systems, when a member of a conference leaves the conferences, the conferences is rekeyed so that member no longer has the key. When changing to a new EKTKey, it is possible that the attacker could block the EKTKey message getting to a particular endpoint and that endpoint would keep sending media encrypted using the old key. To mitigate that risk, the lifetime of the EKTKey MUST be limited using the ekt_ttl. Do we want to give any concrete guidance about ekt_ttl values? |
2020-01-15 |
11 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss |
2020-01-15 |
11 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2020-01-15 |
11 | Cullen Jennings | New version available: draft-ietf-perc-srtp-ekt-diet-11.txt |
2020-01-15 |
11 | (System) | New version approved |
2020-01-15 |
11 | (System) | Request for posting confirmation emailed to previous authors: Flemming Andreasen <fandreas@cisco.com>, Cullen Jennings <fluffy@iii.ca>, David McGrew <mcgrew@cisco.com>, John Mattsson <john.mattsson@ericsson.com>, Dan Wing <dwing-ietf@fuggles.com> |
2020-01-15 |
11 | Cullen Jennings | Uploaded new revision |
2019-11-19 |
10 | Benjamin Kaduk | [Ballot discuss] The -10 introduced text implying that the DTLS 1.3 retransmission rules are normative, that is in conflict with the existing text indicating that … [Ballot discuss] The -10 introduced text implying that the DTLS 1.3 retransmission rules are normative, that is in conflict with the existing text indicating that DTLS 1.2 retransmission rules are normative (see COMMENT). The DTLS 1.3 Ack message is a dedicated content-type, not a handshake-type. I support Alexey's Discuss about the ABNF breakage. Note that there is a similar issue in the names of the TLS extensions in the IANA considerations -- the names now include "\_" instead of just "_". |
2019-11-19 |
10 | Benjamin Kaduk | [Ballot comment] This document is written under the assumption that the EKT content will be the only content after the encrypted SRTP payload (and authentication … [Ballot comment] This document is written under the assumption that the EKT content will be the only content after the encrypted SRTP payload (and authentication tag, if present). That's true at present, of course, but I would still like to see a little discussion of how it might coexist with other SRTP extensions that place content as a trailer (both would need to be parseable from the tail of the content and have a length field; and they woule either need to share a message-type namespace or have a profile specification to indicate what order they appear in), though the discussion that already occurred suffices to make this not a Discuss-level point. Section 5 has: the DTLS-SRTP peer in the server role to the client. This allows those peers to process EKT keying material in SRTP (or SRTCP) and retrieve the embedded SRTP keying material. This combination of but in Section 4 we say that "use with SRTCP would be similar, but is reserved for a future specification". (There may be one or two other places that have text placing SRTCP on the same footing as SRTP even though they are not, at present.) Also section 5 In cases where the DTLS termination point is more trusted than the media relay, the protection that DTLS affords to EKT key material can allow EKT keys to be tunneled through an untrusted relay such as a centralized conference bridge. For more details, see [I-D.ietf-perc-private-media-framework]. I did not chase the reference, but it seems like this sentence might apply equally for "EKT keys to be tunneled" and "SRTP master keys to be tunneled". I trust the authors to say what they mean :) Section 5.2.2 What do I do when I receive an EKTKey containing an ekt_spi value for which I already have stored parameters? When an EKTKey is received and processed successfully, the recipient MUST respond with an Ack handshake message as described in Section 7 of [I-D.ietf-tls-dtls13]. The EKTKey message and Ack MUST be Ack is a content type, not a handshake type. (Per DISCUSS point) When an EKTKey is received and processed successfully, the recipient MUST respond with an Ack handshake message as described in Section 7 of [I-D.ietf-tls-dtls13]. The EKTKey message and Ack MUST be retransmitted following the rules in Section 4.2.4 of [RFC6347]. It's a little weird to cite DTLS 1.3 for the Ack message but then revert to DTLS 1.2 for the retransmission schedule... EKT MAY be used with versions of DTLS prior to 1.3. In such cases, the Ack message is still used to provide reliability. Thus, DTLS implementations supporting EKT with DTLS pre-1.3 will need to have explicit affordances for sending the Ack message in response to an EKTKey message, and for verifying that an Ack message was received. The retransmission rules for both sides are the same as in DTLS 1.3. ...but here we say that the DTLS 1.3 retransmission rules are authoritative. (per DISCUSS) Section 6 With EKT, each SRTP sender and receiver MUST generate distinct SRTP master keys. This property avoids any security concern over the re- Er, does an SRTP receiver have a master key ("what does it encrypt if it's not sending anything")? In some systems, when a member of a conference leaves the conferences, the conferences is rekeyed so that member no longer has the key. When changing to a new EKTKey, it is possible that the attacker could block the EKTKey message getting to a particular endpoint and that endpoint would keep sending media encrypted using the old key. To mitigate that risk, the lifetime of the EKTKey MUST be limited using the ekt_ttl. Do we want to give any concrete guidance about ekt_ttl values? |
2019-11-19 |
10 | Benjamin Kaduk | Ballot comment and discuss text updated for Benjamin Kaduk |
2019-09-05 |
10 | Benjamin Kaduk | [Ballot discuss] Thanks for the updates in the -10; we're making progress. I think there are still some issues left to resolve, though. My previous … [Ballot discuss] Thanks for the updates in the -10; we're making progress. I think there are still some issues left to resolve, though. My previous position had: """I think we need to discuss whether the mechanism described in Section 4.1 contains an EKT-specific extension mechanism or is in fact a more general mechanism for including extensions in SRTP packets outside the SRTP cryptographic protection. (If so, we would probably need to Update 3711 to indicate as much, and perhaps allow for multiple extension types to be present adjacently.) In particular, how would this EKT extension interact with any other future mechanism that needs to add data to SRTP packets outside the SRTP cryptographic wrapper?""" I think I remember having such a discussion, but cannot find any record of it. Does anyone have a pointer handy (or a corrective to my memory)? Similarly, I don't remember any discussion on: """I also think we need to discuss whether it is appropriate to set a precedent that any standards-track protocol can get a dedicated TLS HandshakeType (noting that this is a potentially scarce one-octet field. Would it be more appropriate to define a generic "key transport" container that can be generally applicable to many protocols, and have an internal extension point that allows for an SRTP+EKT-specific usage within the TLS HandshakeType?""" [IANA says they're okay now] |
2019-09-05 |
10 | Benjamin Kaduk | Ballot discuss text updated for Benjamin Kaduk |
2019-09-02 |
10 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2019-08-26 |
10 | Gunter Van de Velde | Assignment of request for Last Call review by OPSDIR to Carlos Martínez was marked no-response |
2019-07-17 |
10 | Benjamin Kaduk | [Ballot discuss] Thanks for the updates in the -10; we're making progress. I think there are still some issues left to resolve, though. My previous … [Ballot discuss] Thanks for the updates in the -10; we're making progress. I think there are still some issues left to resolve, though. My previous position had: """I think we need to discuss whether the mechanism described in Section 4.1 contains an EKT-specific extension mechanism or is in fact a more general mechanism for including extensions in SRTP packets outside the SRTP cryptographic protection. (If so, we would probably need to Update 3711 to indicate as much, and perhaps allow for multiple extension types to be present adjacently.) In particular, how would this EKT extension interact with any other future mechanism that needs to add data to SRTP packets outside the SRTP cryptographic wrapper?""" I think I remember having such a discussion, but cannot find any record of it. Does anyone have a pointer handy (or a corrective to my memory)? Similarly, I don't remember any discussion on: """I also think we need to discuss whether it is appropriate to set a precedent that any standards-track protocol can get a dedicated TLS HandshakeType (noting that this is a potentially scarce one-octet field. Would it be more appropriate to define a generic "key transport" container that can be generally applicable to many protocols, and have an internal extension point that allows for an SRTP+EKT-specific usage within the TLS HandshakeType?""" We are also still waiting on IANA, if I understand correctly. I do not see any indication that the needed expert review for TLS ExtensionType allocation has been requested (the authors should initiate this, per RFC 8447), and there may have been other matters that needed clarification. |
2019-07-17 |
10 | Benjamin Kaduk | [Ballot comment] [original comment section unchanged; contents likely stale] There is no cryptographic binding between the EKTCiphertext and the main SRTP packet, nor is there … [Ballot comment] [original comment section unchanged; contents likely stale] There is no cryptographic binding between the EKTCiphertext and the main SRTP packet, nor is there an authentication tag on the EKTCiphertext that protects the SPI or length fields (or, for that matter, the message type). The consequences of this are probably minor, given that an attacker who can tamper with them could also tamper with the main plaintext, but there is perhaps potential for causing trouble later in the pipeline, especially since (as this document admits) there is the possibility of SRTP transforms that do not provide integrity protection. The EKT is a group shared symmetric key, with all the usual caveats that any group member can spoof a message "from" any other group member. (Reading the group's messages is of course a necessary feature.) The EKT is furthermore possessed by the central broker in the portrayed deployment scenario, allowing the broker access to the plaintext of media if it did not already have such access. It's probably worth mentioning somewhere what the master salt is used for so the reader not familiar with the details of RFC 3711 is not left wondering why we are conveying it. Section 1 This document defines Encrypted Key Transport (EKT) for SRTP and reduces the amount of external signaling control that is needed in a SRTP session with multiple receivers. EKT securely distributes the SRTP master key and other information for each SRTP source. With this method, SRTP entities are free to choose SSRC values as they see fit, and to start up new SRTP sources with new SRTP master keys within a session without coordinating with other entities via external signaling or other external means. I think you need an explanation and/or reference for previous systems that required central SSRC allocation (or otherwise why the "free to choose" is noteworthy here). EKT provides a way for an SRTP session participant, to securely transport its SRTP master key and current SRTP rollover counter to the other participants in the session. [...] nit: spurious comma. This reduces the amount of CPU time needed for encryption and can be used for some optimization to media sending that use source specific multicast. nit: I think there's a singular/plural mismatch here. Section 4 EKT MUST NOT be used in conjunction with SRTP's MKI (Master Key Identifier) or with SRTP's <From, To> [RFC3711], as those SRTP features duplicate some of the functions of EKT. Senders MUST NOT include MKI when using EKT. Receivers SHOULD simply ignore any MKI field received if EKT is in use. It feels like we're specifically emphasizing the prohibition on EKT with MKI, and only saying once that EKT with <From, To> is prohibited. Is there a reason to have a stronger prohibition of the one than the other? Section 4.1 The EKTField uses the format defined in Figure 1 for the FullEKTField and ShortEKTField. nit: the ShortEKTField is in Figure 2. SRTPMasterKeyLength = BYTE SRTPMasterKey = 1*256BYTE SSRC = 4BYTE; SSRC from RTP ROC = 4BYTE ; ROC from SRTP FOR THE GIVEN SSRC nit: is it conventional to all-caps "FOR THE GIVEN"? EKTCiphertext: The data that is output from the EKT encryption operation, described in Section 4.4. This field is included in SRTP packets when EKT is in use. The length of EKTCiphertext can be larger than the length of the EKTPlaintext that was encrypted. Doesn't it *need* to be larger in order to provide the stated properties? (I.e., it "will be larger".) SRTPMasterKeyLength: The length of the SRTPMasterKey in bytes. This depends on the cipher suite negotiated for SRTP using SDP Offer/ Answer [RFC3264] for the SRTP. This text would seem to forbid using EKT with any mechanism other than SDP Offer/Answer for central control. Do we want to say why a Message Type of 1 is not usable? Section 4.2.2 [Isn't there a step 0 to figure out whether any EKT/extensions are in use?] 5. If the SSRC in the EKTPlaintext does not match the SSRC of the SRTP packet received, then all the information from this EKTPlaintext MUST be discarded and the following steps in this list are skipped. Does this mean I just ignore EKT and attempt to process the SRTP packet with whatever non-EKT material I have on hand? * Unless the transform specifies other acceptable key lengths, the length of the SRTP Master Key MUST be the same as the This is the first usage of "transform" in this document; perhaps a reminder to the reader that this is a stock SRTP concept is in order. master key length for the SRTP transform in use. If this is not the case, then the receiver MUST abort EKT processing and SHOULD discared the whole UDP packet. nit: The "this" in "if this is not the case" should probably be spelled out more clearly, as it seems to require both that the master key length is different from the master key length for the SRTP transform in use and that the transform specifies other acceptable key lengths. (Presumably the master key still needs to match one of those other acceptable key lengths, though?) * If the length of the SRTP Master Key is less than the master key length for the SRTP transform in use, and the transform specifies that this length is acceptable, then the SRTP Master Key value is used to replace the first bytes in the existing master key. [...] Do we need to be more clear about what the "existing master key" is? (Are there reordering issues where we could operate on a different key than intended?) Also, what do I do if the length of the SRTP master key is larger than the master key length for the transform in use? Section 4.3 Section 4.2.1 recommends that SRTP senders continue using an old key for some time after sending a new key in an EKT tag. Receivers that wish to avoid packet loss due to decryption failures MAY perform trial decryption with both the old key and the new key, keeping the result of whichever decryption succeeds. Note that this approach is We have multiple types of key floating around; please be clear about which ones are which. only compatible with SRTP transforms that include integrity protection. What's the guidance for when that's not the case? When receiving a new EKTKey, implementations need to use the ekt_ttl field (see Section 5.2.2) to create a time after which this key cannot be used and they also need to create a counter that keeps track of how many times the key has been used to encrypt data to ensure it does not exceed the T value for that cipher (see ). If Since we knowingly create EKTCiphertexts that are identical, do we count those as a single encryption or do we count each time we send them? (I guess Section 4.4 mostly answers this by way of example but a non-example statement is probably in order.) At this point implementation need to either use the call signaling to renegotiate a new session or need to terminate the nit: "call signaling" seems more SIP-specific than necessary. The encryption function returns a ciphertext value C whose length is N bytes, where N may be larger than M. [...] (same comment about "may be larger" as above) Section 4.4.2 An EKTCipher determines how the EKTCiphertext field is written, and how it is processed when it is read. This field is opaque to the other aspects of EKT processing. EKT ciphers are free to use this field in any way, but they SHOULD NOT use other EKT or SRTP fields as an input. [...] Why is this SHOULD NOT instead of MUST NOT? Section 4.5 Is it worth mentioning (or internally referencing) the 250ms delay before using the new key? Section 5.2.1 Given that you're using the DTLS 1.3 handshake structure, why is RFC 5246 the syntax reference? Section 5.2.2 If the server did not provide a supported_ekt_ciphers extension in its ServerHello, then EKTKey messages MUST NOT be sent by the client or the server. The general text and Figure 4 only show EKTKey being sent by the server. Is it ever allowed to be sent by the client? When an EKTKey is received and processed successfully, the recipient MUST respond with an Ack handshake message as described in Section 7 of [I-D.ietf-tls-dtls13]. The EKTKey message and Ack MUST be retransmitted following the rules in Section 4.2.4 of [RFC6347]. It is super-weird to cite draft-ietf-tls-dtls13 and RFC 6347 in adjacent sentences. Section 6 With EKT, each SRTP sender and receiver MUST generate distinct SRTP master keys. [...] Er, isn't this just senders? Note that the inputs of EKT are the same as for SRTP with key- "inputs" in terms of shared cryptographic material that is fed into the SRTP (plus EKT) protocol collection? sharing: a single key is provided to protect an entire SRTP session. However, EKT remains secure even when SSRC values collide. I think you need to say more about what "secure" is supposed to mean, here. The presence of the SSRC in the EKTPlaintext ensures that an attacker cannot substitute an EKTCiphertext from one SRTP stream into another SRTP stream. Depends on the attacker; if one of the call participants has the network positioning to do so, their knowledge of the EKT allows for generating an EKTCiphertext that matches the SSRC of an arbitrary message. (I guess technically that involves modifying and not straight substitution of the EKTCiphertext.) An attacker who tampers with the bits in FullEKTField can prevent the intended receiver of that packet from being able to decrypt it. This is a minor denial of service vulnerability. Similarly the attacker could take an old FullEKTField from the same session and attach it to the packet. The FullEKTField would correctly decode and pass integrity checks. However, the key extracted from the FullEKTField , when used to decrypt the SRTP payload, would be wrong and the SRTP integrity check would fail. Note that the FullEKTField only changes the decryption key and does not change the encryption key. None of these are considered significant attacks as any attacker that can modify the packets in transit and cause the integrity check to fail. I think this last sentence went a bit funky; presumably it's "any attacker that can modify the packets in transit can already cause the SRTP integrity check to fail even in the absence of EKT". An attacker could send packets containing a FullEKTField, in an attempt to consume additional CPU resources of the receiving system by causing the receiving system to decrypt the EKT ciphertext and detect an authentication failure. In some cases, caching the previous values of the Ciphertext as described in Section 4.3 helps mitigate this issue. I'm not really sure what cases those are supposed to be, since an attacker can send arbitrary junk and tweak it by a bit each time, and the recipient has to do the full decryption to validate the integrity IV. In a similar vein, EKT has no replay protection, so an attacker could implant improper keys in receivers by capturing EKTCiphertext values encrypted with a given EKTKey and replaying them in a different context, e.g., from a different sender. When the underlying SRTP Wouldn't the SSRC check block this particular replay? transform provides integrity protection, this attack will just result in packet loss. If it does not, then it will result in random data being fed to RTP payload processing. An attacker that is in a position to mount these attacks, however, could achieve the same effects more easily without attacking EKT. maybe add "by directly modifying the SRTP packet contents"? The confidentiality, integrity, and authentication of the EKT cipher MUST be at least as strong as the SRTP cipher and at least as strong as the DTLS-SRTP ciphers. EKT doesn't carry anything that's an input to DTLS, so shouldn't this restriction be that the DTLS cipher must be as stront as the EKT one? Section 7.1 All new EKT messages MUST be defined to have a length as second from the last element. "16-bit", right? section 7.4 IANA is requested to add ekt_key as a new entry in the "TLS HandshakeType Registry" table of the "Transport Layer Security (TLS) Parameters" registry with a reference to this specification, a DTLS- OK value of "Y", and allocate a value of TBD to for this content type. HandshakeType != content type |
2019-07-17 |
10 | Benjamin Kaduk | Ballot comment and discuss text updated for Benjamin Kaduk |
2019-07-15 |
10 | Alexey Melnikov | [Ballot discuss] Recent ABNF changes (from "*" to "\*") made the ABNF invalid. |
2019-07-15 |
10 | Alexey Melnikov | [Ballot Position Update] Position for Alexey Melnikov has been changed to Discuss from Yes |
2019-07-15 |
10 | Alexey Melnikov | [Ballot comment] I share Benjamin's concern about extensibility. In 4.4.1: The default EKT Cipher is the Advanced Encryption Standard (AES) Key Wrap with … [Ballot comment] I share Benjamin's concern about extensibility. In 4.4.1: The default EKT Cipher is the Advanced Encryption Standard (AES) Key Wrap with Padding [RFC5649] algorithm. It requires a plaintext length M that is at least one octet, and it returns a ciphertext with a length of N = M + (M mod 8) + 8 octets. I started looking at RFC 5649. Maybe I was tired and my math was wrong, but I couldn't figure out how you came up with the N value above. In particular, where is the "+ 8" coming from? In 6: An attacker who tampers with the bits in FullEKTField can prevent the intended receiver of that packet from being able to decrypt it. This is a minor denial of service vulnerability. Similarly the attacker could take an old FullEKTField from the same session and attach it to the packet. The FullEKTField would correctly decode and pass integrity checks. However, the key extracted from the FullEKTField , when used to decrypt the SRTP payload, would be wrong and the SRTP integrity check would fail. Note that the FullEKTField only changes the decryption key and does not change the encryption key. None of these are considered significant attacks as any attacker that can modify the packets in transit and cause the integrity check to fail. The last sentence seems to be incomplete. Did you mean "can" instead of the last "and"? |
2019-07-15 |
10 | Alexey Melnikov | [Ballot Position Update] Position for Alexey Melnikov has been changed to Yes from Discuss |
2019-07-08 |
10 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-07-08 |
10 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2019-07-08 |
10 | Cullen Jennings | New version available: draft-ietf-perc-srtp-ekt-diet-10.txt |
2019-07-08 |
10 | (System) | New version approved |
2019-07-08 |
10 | (System) | Request for posting confirmation emailed to previous authors: Flemming Andreasen <fandreas@cisco.com>, Cullen Jennings <fluffy@iii.ca>, David McGrew <mcgrew@cisco.com>, John Mattsson <john.mattsson@ericsson.com>, Dan Wing <dwing-ietf@fuggles.com> |
2019-07-08 |
10 | Cullen Jennings | Uploaded new revision |
2019-07-08 |
10 | (System) | Request for posting confirmation emailed to previous authors: Flemming Andreasen <fandreas@cisco.com>, Cullen Jennings <fluffy@iii.ca>, David McGrew <mcgrew@cisco.com>, John Mattsson <john.mattsson@ericsson.com>, Dan Wing <dwing-ietf@fuggles.com> |
2019-07-08 |
10 | Cullen Jennings | Uploaded new revision |
2019-03-27 |
09 | Cindy Morgan | Shepherding AD changed to Alexey Melnikov |
2019-02-21 |
09 | Ben Campbell | [Ballot discuss] I'm adding a process discuss to hold things until we get clarity around the IANA expert reviews. I know Benjamin mentioned this in … [Ballot discuss] I'm adding a process discuss to hold things until we get clarity around the IANA expert reviews. I know Benjamin mentioned this in his DISCUSS; I am duplicating it here in case we clear up the rest of Benjamin's discuss points prior to the IANA questions. |
2019-02-21 |
09 | Ben Campbell | [Ballot Position Update] Position for Ben Campbell has been changed to Discuss from Yes |
2019-02-21 |
09 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2019-02-20 |
09 | Alissa Cooper | [Ballot comment] I think I-D.ietf-tls-dtls13 needs to be a normative reference. |
2019-02-20 |
09 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2019-02-20 |
09 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2019-02-20 |
09 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2019-02-20 |
09 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2019-02-20 |
09 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2019-02-20 |
09 | Benjamin Kaduk | [Ballot discuss] I think we need to discuss whether the mechanism described in Section 4.1 contains an EKT-specific extension mechanism or is in fact a … [Ballot discuss] I think we need to discuss whether the mechanism described in Section 4.1 contains an EKT-specific extension mechanism or is in fact a more general mechanism for including extensions in SRTP packets outside the SRTP cryptographic protection. (If so, we would probably need to Update 3711 to indicate as much, and perhaps allow for multiple extension types to be present adjacently.) In particular, how would this EKT extension interact with any other future mechanism that needs to add data to SRTP packets outside the SRTP cryptographic wrapper? I also think we need to discuss whether it is appropriate to set a precedent that any standards-track protocol can get a dedicated TLS HandshakeType (noting that this is a potentially scarce one-octet field. Would it be more appropriate to define a generic "key transport" container that can be generally applicable to many protocols, and have an internal extension point that allows for an SRTP+EKT-specific usage within the TLS HandshakeType? I'll also hold a discuss for the IANA NOT OK (I noticed the need for more columns for TLS extension type, at least, and there seems to be more in their review). Please state clearly what the scope of an SPI value (and its binding to EKTKey and other parameters) is; e.g., that it is only defined within a given communications session. Section 4.2.1 Outbound packets SHOULD continue to use the old SRTP Master Key for 250 ms after sending any new key. This gives all the receivers in the system time to get the new key before they start receiving media encrypted with the new key. What channel is the "sending any new key" to occur on? The most straightforward reading would be in the FullEKTField, but that does not seem to make much sense. (Also, is the "any new key" an SRTP master key or an EKTKey?) Section 5's one-paragraph intro doesn't really paint a clear picture for me of why/which DTLS connections are "secure" in a way that the central media distribution is not. From reading the whole doc, my perception is that basically this scheme is useful in cases when you have a central hub for DTLS negotiation that's trusted to have access to media plaintext, plus a mesh of SRTP streams (whether centrally mediated or directly connected), and that it's not appropriate when the central hub is not trusted with media access or when there is not a single DTLS party that can distribute the EKT to all (other) participants). Could we get some clear explanation of where this technique is and is not expected to be utilized? Section 5.5.2 has: Note: To be clear, EKT can be used with versions of DTLS prior to 1.3. The only difference is that in a pre-1.3 TLS stacks will not have built-in support for generating and processing Ack messages. You need to be more clear about the Ack being needed even when pre-1.3 is in use (which would seem to make DLTS 1.3 a normative reference). (See also the COMMENT about citing both DTLS 1.2 and 1.3.) |
2019-02-20 |
09 | Benjamin Kaduk | [Ballot comment] There is no cryptographic binding between the EKTCiphertext and the main SRTP packet, nor is there an authentication tag on the EKTCiphertext that … [Ballot comment] There is no cryptographic binding between the EKTCiphertext and the main SRTP packet, nor is there an authentication tag on the EKTCiphertext that protects the SPI or length fields (or, for that matter, the message type). The consequences of this are probably minor, given that an attacker who can tamper with them could also tamper with the main plaintext, but there is perhaps potential for causing trouble later in the pipeline, especially since (as this document admits) there is the possibility of SRTP transforms that do not provide integrity protection. The EKT is a group shared symmetric key, with all the usual caveats that any group member can spoof a message "from" any other group member. (Reading the group's messages is of course a necessary feature.) The EKT is furthermore possessed by the central broker in the portrayed deployment scenario, allowing the broker access to the plaintext of media if it did not already have such access. It's probably worth mentioning somewhere what the master salt is used for so the reader not familiar with the details of RFC 3711 is not left wondering why we are conveying it. Section 1 This document defines Encrypted Key Transport (EKT) for SRTP and reduces the amount of external signaling control that is needed in a SRTP session with multiple receivers. EKT securely distributes the SRTP master key and other information for each SRTP source. With this method, SRTP entities are free to choose SSRC values as they see fit, and to start up new SRTP sources with new SRTP master keys within a session without coordinating with other entities via external signaling or other external means. I think you need an explanation and/or reference for previous systems that required central SSRC allocation (or otherwise why the "free to choose" is noteworthy here). EKT provides a way for an SRTP session participant, to securely transport its SRTP master key and current SRTP rollover counter to the other participants in the session. [...] nit: spurious comma. This reduces the amount of CPU time needed for encryption and can be used for some optimization to media sending that use source specific multicast. nit: I think there's a singular/plural mismatch here. Section 4 EKT MUST NOT be used in conjunction with SRTP's MKI (Master Key Identifier) or with SRTP's <From, To> [RFC3711], as those SRTP features duplicate some of the functions of EKT. Senders MUST NOT include MKI when using EKT. Receivers SHOULD simply ignore any MKI field received if EKT is in use. It feels like we're specifically emphasizing the prohibition on EKT with MKI, and only saying once that EKT with <From, To> is prohibited. Is there a reason to have a stronger prohibition of the one than the other? Section 4.1 The EKTField uses the format defined in Figure 1 for the FullEKTField and ShortEKTField. nit: the ShortEKTField is in Figure 2. SRTPMasterKeyLength = BYTE SRTPMasterKey = 1*256BYTE SSRC = 4BYTE; SSRC from RTP ROC = 4BYTE ; ROC from SRTP FOR THE GIVEN SSRC nit: is it conventional to all-caps "FOR THE GIVEN"? EKTCiphertext: The data that is output from the EKT encryption operation, described in Section 4.4. This field is included in SRTP packets when EKT is in use. The length of EKTCiphertext can be larger than the length of the EKTPlaintext that was encrypted. Doesn't it *need* to be larger in order to provide the stated properties? (I.e., it "will be larger".) SRTPMasterKeyLength: The length of the SRTPMasterKey in bytes. This depends on the cipher suite negotiated for SRTP using SDP Offer/ Answer [RFC3264] for the SRTP. This text would seem to forbid using EKT with any mechanism other than SDP Offer/Answer for central control. Do we want to say why a Message Type of 1 is not usable? Section 4.2.2 [Isn't there a step 0 to figure out whether any EKT/extensions are in use?] 5. If the SSRC in the EKTPlaintext does not match the SSRC of the SRTP packet received, then all the information from this EKTPlaintext MUST be discarded and the following steps in this list are skipped. Does this mean I just ignore EKT and attempt to process the SRTP packet with whatever non-EKT material I have on hand? * Unless the transform specifies other acceptable key lengths, the length of the SRTP Master Key MUST be the same as the This is the first usage of "transform" in this document; perhaps a reminder to the reader that this is a stock SRTP concept is in order. master key length for the SRTP transform in use. If this is not the case, then the receiver MUST abort EKT processing and SHOULD discared the whole UDP packet. nit: The "this" in "if this is not the case" should probably be spelled out more clearly, as it seems to require both that the master key length is different from the master key length for the SRTP transform in use and that the transform specifies other acceptable key lengths. (Presumably the master key still needs to match one of those other acceptable key lengths, though?) * If the length of the SRTP Master Key is less than the master key length for the SRTP transform in use, and the transform specifies that this length is acceptable, then the SRTP Master Key value is used to replace the first bytes in the existing master key. [...] Do we need to be more clear about what the "existing master key" is? (Are there reordering issues where we could operate on a different key than intended?) Also, what do I do if the length of the SRTP master key is larger than the master key length for the transform in use? Section 4.3 Section 4.2.1 recommends that SRTP senders continue using an old key for some time after sending a new key in an EKT tag. Receivers that wish to avoid packet loss due to decryption failures MAY perform trial decryption with both the old key and the new key, keeping the result of whichever decryption succeeds. Note that this approach is We have multiple types of key floating around; please be clear about which ones are which. only compatible with SRTP transforms that include integrity protection. What's the guidance for when that's not the case? When receiving a new EKTKey, implementations need to use the ekt_ttl field (see Section 5.2.2) to create a time after which this key cannot be used and they also need to create a counter that keeps track of how many times the key has been used to encrypt data to ensure it does not exceed the T value for that cipher (see ). If Since we knowingly create EKTCiphertexts that are identical, do we count those as a single encryption or do we count each time we send them? (I guess Section 4.4 mostly answers this by way of example but a non-example statement is probably in order.) At this point implementation need to either use the call signaling to renegotiate a new session or need to terminate the nit: "call signaling" seems more SIP-specific than necessary. The encryption function returns a ciphertext value C whose length is N bytes, where N may be larger than M. [...] (same comment about "may be larger" as above) Section 4.4.2 An EKTCipher determines how the EKTCiphertext field is written, and how it is processed when it is read. This field is opaque to the other aspects of EKT processing. EKT ciphers are free to use this field in any way, but they SHOULD NOT use other EKT or SRTP fields as an input. [...] Why is this SHOULD NOT instead of MUST NOT? Section 4.5 Is it worth mentioning (or internally referencing) the 250ms delay before using the new key? Section 5.2.1 Given that you're using the DTLS 1.3 handshake structure, why is RFC 5246 the syntax reference? Section 5.2.2 If the server did not provide a supported_ekt_ciphers extension in its ServerHello, then EKTKey messages MUST NOT be sent by the client or the server. The general text and Figure 4 only show EKTKey being sent by the server. Is it ever allowed to be sent by the client? When an EKTKey is received and processed successfully, the recipient MUST respond with an Ack handshake message as described in Section 7 of [I-D.ietf-tls-dtls13]. The EKTKey message and Ack MUST be retransmitted following the rules in Section 4.2.4 of [RFC6347]. It is super-weird to cite draft-ietf-tls-dtls13 and RFC 6347 in adjacent sentences. Section 6 With EKT, each SRTP sender and receiver MUST generate distinct SRTP master keys. [...] Er, isn't this just senders? Note that the inputs of EKT are the same as for SRTP with key- "inputs" in terms of shared cryptographic material that is fed into the SRTP (plus EKT) protocol collection? sharing: a single key is provided to protect an entire SRTP session. However, EKT remains secure even when SSRC values collide. I think you need to say more about what "secure" is supposed to mean, here. The presence of the SSRC in the EKTPlaintext ensures that an attacker cannot substitute an EKTCiphertext from one SRTP stream into another SRTP stream. Depends on the attacker; if one of the call participants has the network positioning to do so, their knowledge of the EKT allows for generating an EKTCiphertext that matches the SSRC of an arbitrary message. (I guess technically that involves modifying and not straight substitution of the EKTCiphertext.) An attacker who tampers with the bits in FullEKTField can prevent the intended receiver of that packet from being able to decrypt it. This is a minor denial of service vulnerability. Similarly the attacker could take an old FullEKTField from the same session and attach it to the packet. The FullEKTField would correctly decode and pass integrity checks. However, the key extracted from the FullEKTField , when used to decrypt the SRTP payload, would be wrong and the SRTP integrity check would fail. Note that the FullEKTField only changes the decryption key and does not change the encryption key. None of these are considered significant attacks as any attacker that can modify the packets in transit and cause the integrity check to fail. I think this last sentence went a bit funky; presumably it's "any attacker that can modify the packets in transit can already cause the SRTP integrity check to fail even in the absence of EKT". An attacker could send packets containing a FullEKTField, in an attempt to consume additional CPU resources of the receiving system by causing the receiving system to decrypt the EKT ciphertext and detect an authentication failure. In some cases, caching the previous values of the Ciphertext as described in Section 4.3 helps mitigate this issue. I'm not really sure what cases those are supposed to be, since an attacker can send arbitrary junk and tweak it by a bit each time, and the recipient has to do the full decryption to validate the integrity IV. In a similar vein, EKT has no replay protection, so an attacker could implant improper keys in receivers by capturing EKTCiphertext values encrypted with a given EKTKey and replaying them in a different context, e.g., from a different sender. When the underlying SRTP Wouldn't the SSRC check block this particular replay? transform provides integrity protection, this attack will just result in packet loss. If it does not, then it will result in random data being fed to RTP payload processing. An attacker that is in a position to mount these attacks, however, could achieve the same effects more easily without attacking EKT. maybe add "by directly modifying the SRTP packet contents"? The confidentiality, integrity, and authentication of the EKT cipher MUST be at least as strong as the SRTP cipher and at least as strong as the DTLS-SRTP ciphers. EKT doesn't carry anything that's an input to DTLS, so shouldn't this restriction be that the DTLS cipher must be as stront as the EKT one? Section 7.1 All new EKT messages MUST be defined to have a length as second from the last element. "16-bit", right? section 7.4 IANA is requested to add ekt_key as a new entry in the "TLS HandshakeType Registry" table of the "Transport Layer Security (TLS) Parameters" registry with a reference to this specification, a DTLS- OK value of "Y", and allocate a value of TBD to for this content type. HandshakeType != content type |
2019-02-20 |
09 | Benjamin Kaduk | Ballot comment and discuss text updated for Benjamin Kaduk |
2019-02-20 |
09 | Alexey Melnikov | [Ballot discuss] The document is generally quite readable, which is great. But I have a few small issues I would like to get clarification on … [Ballot discuss] The document is generally quite readable, which is great. But I have a few small issues I would like to get clarification on before recommending approval of this document: In 4.1: Message Type: The last byte is used to indicate the type of the EKTField. This MUST be 2 for the FullEKTField format and 0 in ShortEKTField format. Values less than 64 are mandatory to understand while other values are optional to understand. I thought I knew what this meant when I read it, and then I saw this: A receiver SHOULD discard the whole EKTField if it contains any message type value that is less than 64 and that is not understood. "SHOULD discard ... EKTField" makes this field NOT mandatory. (If you said "SHOULD discard the whole packet", that would have been different.) Also, how "discard" different from the following sentence suggesting "ignore"? I think you have some inconsistencies/terminology problem here! Message type values that are 64 or greater but not implemented or understood can simply be ignored. |
2019-02-20 |
09 | Alexey Melnikov | [Ballot comment] I share Benjamin's concern about extensibility. General: Mixture of normative TLS 1.2 and TLS 1.3 references is confusing in the document. There is … [Ballot comment] I share Benjamin's concern about extensibility. General: Mixture of normative TLS 1.2 and TLS 1.3 references is confusing in the document. There is a note later on explaining that either can be used, but it would be better for readers to see this note earlier in the document. In 4.1: EKTMsgLength = 2BYTE; and similarly: SPI = 2BYTE The document doesn't seem to say whether or not this is in network byte order. In 4.2.1: 2. The EKTPlaintext field is computed from the SRTP Master Key, SSRC, and ROC fields, as shown in Section 4.1. The ROC, SRTP Master Key, and SSRC used in EKT processing SHOULD be the same as the one used in the SRTP processing. When can they be different? I.e. why is this not a MUST? The computed value of the FullEKTField is written into the SRTP packet. I think this might be misleading. Do you just mean appended to the end of the SRTP packet after encrypted data? If yes, please say so to avoid confusion with writing it into encrypted data before encryption. In 4.3: When receiving a new EKTKey, implementations need to use the ekt_ttl field (see Section 5.2.2) to create a time after which this key cannot be used and they also need to create a counter that keeps track of how many times the key has been used to encrypt data to ensure it does not exceed the T value for that cipher (see ). Missing reference after "see" here. In 4.4.1: The default EKT Cipher is the Advanced Encryption Standard (AES) Key Wrap with Padding [RFC5649] algorithm. It requires a plaintext length M that is at least one octet, and it returns a ciphertext with a length of N = M + (M mod 8) + 8 octets. I started looking at RFC 5649. Maybe I was tired and my math was wrong, but I couldn't figure out how you came up with the N value above. In particular, where is the "+ 8" coming from? In 4.7: New sender: A new sender SHOULD send a packet containing the FullEKTField as soon as possible, always before or coincident with sending its initial SRTP packet. To accommodate packet loss, it is RECOMMENDED that three consecutive packets contain the FullEKTField be transmitted. If the sender does not send a FullEKTField in its initial packets and receivers have not otherwise been provisioned with a decryption key, then decryption will fail and SRTP packets will be dropped until the the receives Nit: duplicated "the". a FullEKTField from the sender. In 6: An attacker who tampers with the bits in FullEKTField can prevent the intended receiver of that packet from being able to decrypt it. This is a minor denial of service vulnerability. Similarly the attacker could take an old FullEKTField from the same session and attach it to the packet. The FullEKTField would correctly decode and pass integrity checks. However, the key extracted from the FullEKTField , when used to decrypt the SRTP payload, would be wrong and the SRTP integrity check would fail. Note that the FullEKTField only changes the decryption key and does not change the encryption key. None of these are considered significant attacks as any attacker that can modify the packets in transit and cause the integrity check to fail. The last sentence seems to be incomplete. Did you mean "can" instead of the last "end"? |
2019-02-20 |
09 | Alexey Melnikov | [Ballot Position Update] New position, Discuss, has been recorded for Alexey Melnikov |
2019-02-19 |
09 | Adam Roach | [Ballot comment] Thanks to the work that everyone has put in on getting an EKT mechanism specified and finalized. I have a handful of comments … [Ballot comment] Thanks to the work that everyone has put in on getting an EKT mechanism specified and finalized. I have a handful of comments that I would like to see considered prior to publication of the document. --------------------------------------------------------------------------- §1: > EKT provides a way for an SRTP session participant, to securely > transport its SRTP master key and current SRTP rollover counter to > the other participants in the session. Nit: "...participant to securely..." --------------------------------------------------------------------------- §4.1: > EKTMsgTypeExtension = %x03-FF Shouldn't this be "%x01 / %x03-ff" ? > SRTPMasterKeyLength = BYTE > SRTPMasterKey = 1*256BYTE I think this either needs to be "1*255BYTE", or we need text that explicitly indicates that an SRTPMasterKeyLength value of 0x00 means "256 bytes." Probably the former. I think this is even further constrained by the fact that EKTCiphertext is limited to 256 bytes, and contains the SRTPMasterKeyLength, SRTPMasterKey, SSRC, and ROC (and is not compressed) -- which means the SRTPMasterKeyLength can't be more than (256 - 1 - 4 - 4 =) 247 bytes. So perhaps "1*247BYTE" is more appropriate? --------------------------------------------------------------------------- §4.2.1: > The creation of the EKTField MUST precede the normal SRTP > packet processing. Why? This seems unnecessary and unnecessarily complicated. If the order of operations has an impact on the bits on the wire (I don't see how it does?), then please include some explanatory text here that clarifies the reason for this constraint. --------------------------------------------------------------------------- §4.2.1: > When a packet is sent with the ShortEKTField, the ShortEKFField is > simply appended to the packet. Nit: s/ShortEKFField/ShortEKTField/ --------------------------------------------------------------------------- §4.2.1: > 5. If the SSRC in the EKTPlaintext does not match the SSRC of the > SRTP packet received, then all the information from this > EKTPlaintext MUST be discarded and the following steps in this > list are skipped. I can see implementors easily interpreting this as requiring them to discard the RTP payload as well. If that's not the intention (I don't think it is), consider adding text like "The FullEKTField is removed from the packet then normal SRTP or SRTCP processing occurs." --------------------------------------------------------------------------- §4.3: > Section 4.2.1 recommends that SRTP senders continue using an old key > for some time after sending a new key in an EKT tag. This is the first appearance of the phrase "EKT tag," which never seems to be properly defined. I presume this is meant to be the combination of the EKT Ciphertext and the SPI? In any case, please clearly define this term somewhere, preferably before using it the first time. --------------------------------------------------------------------------- §4.3: > cannot be used and they also need to create a counter that keeps > track of how many times the key has been used to encrypt data to > ensure it does not exceed the T value for that cipher (see ). The parenthetical phrase appears to be missing something here. > If > either of these limits are exceeded, the key can no longer be used Nit: "...either... is exceeded..." > for encryption. At this point implementation need to either use the Nit: "...implementations need..." --------------------------------------------------------------------------- §4.5: > If a source has its EKTKey changed by the key management, it MUST > also change its SRTP master key I suppose it's not terribly important for interop, but the implication that this change takes place immediately seems to contradict the 250 ms period specified in §4.2.1. Perhaps a few words here about how these two normative statements are intended to interact would save implementors a bit of grief. --------------------------------------------------------------------------- §4.6: > This document defines the use of EKT with SRTP. Its use with SRTCP > would be similar, but is reserved for a future specification. After reading this far, I was quite surprised to find this qualification. If this is the intention for this document, please adjust the rest of the text to match. Some examples follow. > The following shows the syntax of the EKTField expressed in ABNF > [RFC5234]. The EKTField is added to the end of an SRTP or SRTCP > packet. ----- > Rollover Counter (ROC): On the sender side, this is set to the > current value of the SRTP rollover counter in the SRTP/SRTCP context > associated with the SSRC in the SRTP or SRTCP packet. ----- > 1. The final byte is checked to determine which EKT format is in > use. When an SRTP or SRTCP packet contains a ShortEKTField, the > ShortEKTField is removed from the packet then normal SRTP or > SRTCP processing occurs. ----- > The reason for > using the last byte of the packet to indicate the type is that > the length of the SRTP or SRTCP part is not known until the > decryption has occurred. ----- > 7. At this point, EKT processing has successfully completed, and the > normal SRTP or SRTCP processing takes place. ----- > This allows > those peers to process EKT keying material in SRTP (or SRTCP) and > retrieve the embedded SRTP keying material. --------------------------------------------------------------------------- §4.7: > To accommodate packet loss, it is > RECOMMENDED that three consecutive packets contain the > FullEKTField be transmitted. Nit: "...containing..." (alternately, remove "be transmitted" -- both make a grammatically correct sentance) More substantially -- under "New sender:", I'm a little surprised that there isn't any mention of other senders re-keying in response to a new sender joining. In the vast majority of conferences, when a sender joins, that same entity generally will also be a receiver. It seems this should trigger other senders to include the key in their next packet. --------------------------------------------------------------------------- §4.7: > Rekey: > By sending EKT tag over SRTP, the rekeying event shares fate with > the SRTP packets protected with that new SRTP master key. Is this actually true? Going back to the 250 ms period specified in §4.2.1, it seems that the master key is sent out in packets pretty far removed from those it actually protects. Between this and the inconsistency I mention in §4.5 above, this increasingly feels like maybe there were two different ways of reasoning about the timing of sending a master key versus the timing of actually using it. Does the text in §4.2.1 perhaps represent an outdated notion of how this is intended to work? --------------------------------------------------------------------------- §4.7: > If sending audio and video, the RECOMMENDED > frequency is the same as the rate of intra coded video frames. If > only sending audio, the RECOMMENDED frequency is every 100ms. Is this "100ms" correct? Assuming, say, the use of Opus at voice quality with 20 ms packets, this is taking packets on the order of 40 bytes in length and tacking on something like 20 to 30 bytes to every fifth packet. That's an increase in overall stream size on the order of roughly 15% to 20%. At the same time, when using real-time video, intra frames are going to happen roughly every 500 ms to 1500 ms. If a cadence on that order is okay for audiovisual streams, I have to imagine it's okay for audio streams. So, to clarify: is this "100ms" a typo for "1000 ms"? --------------------------------------------------------------------------- §7.2: > +----------+-------+---------------+ > | Name | Value | Specification | > +----------+-------+---------------+ > | AESKW128 | 1 | RFCAAAA | > | AESKW256 | 2 | RFCAAAA | > | Reserved | 255 | RFCAAAA | > +----------+-------+---------------+ > > Table 3: EKT Cipher Types Section 5.2.1 reserves "0" as well. I suspect we want to replicate that reservation in this table. |
2019-02-19 |
09 | Adam Roach | [Ballot Position Update] New position, Yes, has been recorded for Adam Roach |
2019-02-19 |
09 | Benjamin Kaduk | [Ballot discuss] [this is a placeholder Discuss to indicate a couple of broad issues early; a full review and ballot position is forthcoming] I think … [Ballot discuss] [this is a placeholder Discuss to indicate a couple of broad issues early; a full review and ballot position is forthcoming] I think we need to discuss whether the mechanism described in Section 4.1 contains an EKT-specific extension mechanism or is in fact a more general mechanism for including extensions in SRTP packets outside the SRTP cryptographic protection. (If so, we would probably need to Update 3711 to indicate as much, and perhaps allow for multiple extension types to be present adjacently.) In particular, how would this EKT extension interact with any other future mechanism that needs to add data to SRTP packets outside the SRTP cryptographic wrapper? I also think we need to discuss whether it is appropriate to set a precedent that any standards-track protocol can get a dedicated TLS HandshakeType (noting that this is a potentially scarce one-octet field. Would it be more appropriate to define a generic "key transport" container that can be generally applicable to many protocols, and have an internal extension point that allows for an SRTP+EKT-specific usage within the TLS HandshakeType? |
2019-02-19 |
09 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2019-02-19 |
09 | Mirja Kühlewind | [Ballot comment] Just a quick clarification question: Sec 4.2.1: " Outbound packets SHOULD continue to use the old SRTP Master Key for 250 ms … [Ballot comment] Just a quick clarification question: Sec 4.2.1: " Outbound packets SHOULD continue to use the old SRTP Master Key for 250 ms after sending any new key. This gives all the receivers in the system time to get the new key before they start receiving media encrypted with the new key." I assume that 250ms is selected under the assumption that longer RTTs are a problem for interactive communication anyway? Or where does this value come from? |
2019-02-19 |
09 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2019-02-18 |
09 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2019-02-16 |
09 | Eric Rescorla | [Ballot comment] Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D3741 IMPORTANT S 4.4.1. > FullEKTField is retransmitted 3 times, that only counts as 1 … [Ballot comment] Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D3741 IMPORTANT S 4.4.1. > FullEKTField is retransmitted 3 times, that only counts as 1 > encryption. > > Security requirements for EKT ciphers are discussed in Section 6. > > 4.4.1. Ciphers How do I know which cipher is in use? Is it attached to EKTKey? S 5.2.2. > Note: To be clear, EKT can be used with versions of DTLS prior to > 1.3. The only difference is that in a pre-1.3 TLS stacks will not > have built-in support for generating and processing Ack messages. > > If an EKTKey message is received that cannot be processed, then the > recipient MUST respond with an appropriate DTLS alert. How important is it that you (a) be able to change EKTKeys and (b) be able to work with DTLS < 1.3? Because if the answer to these is "no", then you can just send EKTKeys in EncryptedExtensions. S 6. > With EKT, each SRTP sender and receiver MUST generate distinct SRTP > master keys. This property avoids any security concern over the re- > use of keys, by empowering the SRTP layer to create keys on demand. > Note that the inputs of EKT are the same as for SRTP with key- > sharing: a single key is provided to protect an entire SRTP session. > However, EKT remains secure even when SSRC values collide. How am I supposed to decrypt in case I don't have a FullEKTField? Am I supposed to use the IP address. S 6. > context, e.g., from a different sender. When the underlying SRTP > transform provides integrity protection, this attack will just result > in packet loss. If it does not, then it will result in random data > being fed to RTP payload processing. An attacker that is in a > position to mount these attacks, however, could achieve the same > effects more easily without attacking EKT. Why don't you add an epoch so that you can't roll back? COMMENTS S 4.1. > : : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Security Parameter Index | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0 0 0 0 0 0 1 0| > +-+-+-+-+-+-+-+-+ This encoding seems suboptimal, in that you burn an extra byte for every FullEKTField. Given that: 1. You are only defining two types 2. It seems unlikely that there will ever be an EKTCiphertext longer than 128 bits. I would suggest the following encoding: - The first bit of the last byte indicates whether this is FullEKTField or <Something else.>. If it's FullEKTField, the rest is used for length. Otherwise, the rest is used for type. |
2019-02-16 |
09 | Eric Rescorla | [Ballot Position Update] New position, No Objection, has been recorded for Eric Rescorla |
2019-02-07 |
09 | Amy Vezza | Placed on agenda for telechat - 2019-02-21 |
2019-02-07 |
09 | Ben Campbell | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2019-02-07 |
09 | Ben Campbell | Ballot has been issued |
2019-02-07 |
09 | Ben Campbell | [Ballot Position Update] New position, Yes, has been recorded for Ben Campbell |
2019-02-07 |
09 | Ben Campbell | Created "Approve" ballot |
2018-11-01 |
09 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2018-10-31 |
09 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Hilarie Orman. |
2018-10-30 |
09 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2018-10-30 |
09 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-perc-srtp-ekt-diet-09. If any part of this review is inaccurate, please let us … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-perc-srtp-ekt-diet-09. If any part of this review is inaccurate, please let us know. The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document. The IANA Functions Operator understands that, upon approval of this document, there are four actions which we must complete. First, a new registry is to be created called the EKT Messages Types registry. The new registry will be located on the Real-Time Transport Protocol (RTP) Parameters registry page located at: https://www.iana.org/assignments/rtp-parameters/ The new registry will be maintained via Specification Required as defined in RFC 8126. There are initial registrations in the new registry as follows: +--------------+-------+---------------+ | Message Type | Value | Reference | +--------------+-------+---------------+ | Short | 0 | [ RFC-to-be ] | | Full | 2 | [ RFC-to-be ] | | Reserved | 63 | [ RFC-to-be ] | | Reserved | 255 | [ RFC-to-be ] | +--------------+-------+---------------+ IANA Question --> Are the values 1, 3-62, and 64-254 unassigned and available for future assignment? Is 255 the maximal value in the registry? Second, a new registry is to be created called the EKT Ciphers registry. The new registry will be located on the Real-Time Transport Protocol (RTP) Parameters registry page located at: https://www.iana.org/assignments/rtp-parameters/ The new registry will be maintained via Specification Required as defined in RFC 8126. There are initial registrations in the new registry as follows: +----------+-------+---------------+ | Name | Value | Specification | +----------+-------+---------------+ | AESKW128 | 1 | [ RFC-to-be ] | | AESKW256 | 2 | [ RFC-to-be ] | | Reserved | 255 | [ RFC-to-be ] | +----------+-------+---------------+ IANA Question --> Are the values 0, and 3-254 unassigned and available for future assignment? Is 255 the maximal value in the registry? Third, in the TLS ExtensionType Values registry on the Transport Layer Security (TLS) Extensions registr4y page located at: https://www.iana.org/assignments/tls-extensiontype-values/ a single, new registration is to be made as follows: Value: [ TBD-at-Registration ] Extension Name: supported_ekt_ciphers TLS 1.3: Recommended: Reference: [ RFC-to-be ] IANA Question --> What should the values be for the entries "TLS 1.3" and "Recommended" for this new registration? Because this registry requires Expert Review [RFC 8126] for registration, the IESG-designated experts for the TLS ExtensionType Values registry have asked that you send a review request to the mailing list. Expert review should be completed before your document can be approved for publication as an RFC. Fourth, in the TLS HandshakeType registry on the Transport Layer Security (TLS) Parameters registry page located at: https://www.iana.org/assignments/tls-parameters/ a single, new registration is to be made as follows: Value: [ TBD-at-Registration ] Description: ekt_key DTLS-OK: Reference: [ RFC-to-be ] IANA Question --> What should the value be for the entry "DTLS-OK" for this new registration? The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2018-10-26 |
09 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Carlos Martínez |
2018-10-26 |
09 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Carlos Martínez |
2018-10-20 |
09 | Christer Holmberg | Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Christer Holmberg. Sent review to list. |
2018-10-18 |
09 | Jean Mahoney | Request for Last Call review by GENART is assigned to Christer Holmberg |
2018-10-18 |
09 | Jean Mahoney | Request for Last Call review by GENART is assigned to Christer Holmberg |
2018-10-18 |
09 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Hilarie Orman |
2018-10-18 |
09 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Hilarie Orman |
2018-10-18 |
09 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2018-10-18 |
09 | Amy Vezza | The following Last Call announcement was sent out (ends 2018-11-01): From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: ben@nostrum.com, suhasietf@gmail.com, perc@ietf.org, draft-ietf-perc-srtp-ekt-diet@ietf.org, Suhas Nandakumar <suhasietf@gmail.com>, … The following Last Call announcement was sent out (ends 2018-11-01): From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: ben@nostrum.com, suhasietf@gmail.com, perc@ietf.org, draft-ietf-perc-srtp-ekt-diet@ietf.org, Suhas Nandakumar <suhasietf@gmail.com>, perc-chairs@ietf.org Reply-To: ietf@ietf.org Sender: <iesg-secretary@ietf.org> Subject: Last Call: <draft-ietf-perc-srtp-ekt-diet-09.txt> (Encrypted Key Transport for DTLS and Secure RTP) to Proposed Standard The IESG has received a request from the Privacy Enhanced RTP Conferencing WG (perc) to consider the following document: - 'Encrypted Key Transport for DTLS and Secure RTP' <draft-ietf-perc-srtp-ekt-diet-09.txt> as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-11-01. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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 file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-perc-srtp-ekt-diet/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-perc-srtp-ekt-diet/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/3231/ |
2018-10-18 |
09 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2018-10-18 |
09 | Amy Vezza | Last call announcement was changed |
2018-10-17 |
09 | Ben Campbell | Last call was requested |
2018-10-17 |
09 | Ben Campbell | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2018-10-17 |
09 | Ben Campbell | Last call announcement was generated |
2018-10-17 |
09 | Ben Campbell | Ballot writeup was changed |
2018-10-17 |
09 | Ben Campbell | Ballot approval text was generated |
2018-10-17 |
09 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2018-10-17 |
09 | Cullen Jennings | New version available: draft-ietf-perc-srtp-ekt-diet-09.txt |
2018-10-17 |
09 | (System) | New version approved |
2018-10-17 |
09 | (System) | Request for posting confirmation emailed to previous authors: Flemming Andreasen <fandreas@cisco.com>, David McGrew <mcgrew@cisco.com>, Cullen Jennings <fluffy@iii.ca>, John Mattsson <john.mattsson@ericsson.com>, perc-chairs@ietf.org, Dan Wing <dwing@cisco.com> |
2018-10-17 |
09 | Cullen Jennings | Uploaded new revision |
2018-08-09 |
08 | Ben Campbell | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2018-08-09 |
08 | Ben Campbell | This is my AD Evaluation of draft-ietf-perc-srtp-ekt-diet-08. The document is mostly in good shape. It’s easy to read and understand. However, I have a few … This is my AD Evaluation of draft-ietf-perc-srtp-ekt-diet-08. The document is mostly in good shape. It’s easy to read and understand. However, I have a few substantive comments/questions and some editorial comments. I would like to at least discuss the substantive comments before going to IETF LC. *** Substantive Comments: *** §3: Is there a reason not to use the RFC 8174 boilerplate? There are at least a few instances of lowercase keywords in places that don’t seem intended as normative. §4.2.1, first paragraph: Is there never a situation where you send neither version? Also, did I miss a description of the purpose and semantics for ShortEKTField, other than “send it when you don’t send the full version”? §4.2.2, step 3: "If the EKT decryption operation returns an authentication failure, then the packet processing stops.” ... and then what? - Step 6: "This applies in transforms such as [ I-D.ietf-perc-double] for replacing just half the key, but SHOULD return a processing error otherwise.” I don’t understand that sentence. Is the point to say that using a “too short” key to replace part of the old key is only valid for perc-double or similar transforms, and receiving one in other contexts is an error? - 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.) §4.3: - “ This ciphertext value MAY be cached by an SRTP receiver to minimize computational effort by noting when the SRTP master key is unchanged and avoiding repeating the steps defined in .” Are we really talking about the recipient? How would the recipient know that the key has not changed without processing the ciphertext value? (Also, the sentence is unfinished--maybe the answer would be clear if the rest of the sentence came out of hiding :-) ) - “ The receiver may want to have a sliding window to retain old SRTP Master Keys (and related context) for some brief period of time, so that out of order packets can be processed as well as packets sent during the time keys are changing.” See comment to §4.2.2, step 6. “may want” seems weak given that the sender SHOULD keep using the old key for a period of time. §4.7: “A new sender SHOULD send a packet containing the FullEKTField as soon as possible...” Why not MUST? Would it ever make sense not to do this? It seems like the mechanism doesn’t work very well otherwise. §6, first paragraph: “or other” - what other? - paragraph 8: “ An endpoint MUST NOT encrypt more than T different FullEKTField values using the same EKTKey.” Is there a reciprocal requirement for decryption? - last paragraph: “...SHOULD be limited using the ekt_ttl” Why not MUST? §7.3: Should this cite RFC 5246 instead of RFC 4366? *** Editorial Comments: *** §2: “...each endpoint picks there own SRTP master key...: s/their/its §4.1, first paragraph: Please reference figures by number. I can imagine some future RFC rendering failing to maintain the relative positions. (This occurs a few times throughout the document.) §4.2.2, step 3: Should "The EKTCiphertext authentication is checked and is decrypted” be something like “ The EKTCiphertext field authentication is checked and its contents decrypted” I assume you don’t mean to say its authentication is decrypted. Also, there’s a number of occurrences of “The [fieldname]...” that should probably say “The [fieldname] field...” - Step 6: s/crypto/cryptographic - Step 7: is the replay protection part relevant to the step? §4.3, third paragraph: This is the first mention of ekt_ttl. It would help to have a brief explanation or at least a forward reference. §4.6: s/ “other specification” / “another specification” ; or “other specifications” §4.7, third paragraph: Both occurrences of “which” need preceding commas. §5.2, paragraph after figure 4: “ ... the extensions defined in this session allows the DTLS server...” Defined in this “session” or this “section”? §, paragraph 7: “... causing the receiving system will decrypt...” s/will/to |
2018-08-09 |
08 | Ben Campbell | IESG state changed to AD Evaluation from Publication Requested |
2018-07-15 |
08 | Suhas Nandakumar | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? draft-ietf-perc-srtp-ekt-diet is targeted at the Standards track, and this writeup is for Proposed Standard. This is reflected on the title page and in the data tracker. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document defines extensions to DTLS-SRTP and SRTP for securely Transmitting SRTP master keys and related information in the Media path for decentralized multimedia conferences Working Group Summary The current version of the specification is a streamlined version of draft-ietf-avtcore-srtp-ekt to cater to PERC WG use cases. The AVTCore version of the this draft was extensively reviewed prior to producing this version of the draft in PERC WG. The version adopted by the PERC WG has been discussed several times and reviewed both internally and by security area personnel (Russ Housley, Sean Turner) This document in general has gotten strong support from the working group as the work that needs to be done. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? An early draft of EKT was implemented in many of Cisco telepresence products and has been widely shipped and used. libsrtp, a widely used SRTP library in commercial and open source SIP and Webrtc products, has a branch with the implementation for EKT. A branch of Firefox has the relevant integration for performing DTLS-SRTP and EKTKey setup procedures as part of NSS library. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? The document shepherd is Suhas Nandakumar; the responsible Area Director is Ben Campbell. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. This document has been reviewed and discussed several times with in the WG. It has been reviewed by personnel from Security Area. Special thanks to Russ Housley and Sean Turner for their detailed reviews.) (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? I do not have any concerns about the working group reviews to date. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. Another round of Security review and TLS WG personnel is welcomed. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No concerns that I am aware of. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Yes (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There was an IPR filed for the original author version of this draft back in 2006 https://datatracker.ietf.org/ipr/707/. Cisco has filed the same IPR on the current version here: https://datatracker.ietf.org/ipr/3231/ (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? It's solid (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No threats of appeal or otherwise. (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. There were couple of warnings in the draft-ietf-perc-srtp-ekt-diet-08.txt and authors have been notified of the same (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. This document does not present the need for these reviews. (13) Have all references within this document been identified as either normative or informative? Yes (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? Not applicable. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. There are no requests for downward references. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. This document does not change the status of any existing RFC. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). This document requests an update couple of existing registries. - RTP parameters registry needs to be updated to include new tables for "EKT Message Types" and "EKT Ciphers" - Transport Layer Security (TLS) Extensions registry needs to be updated to defined "supported_ekt_ciphers" as new extension - TLS HandshakeType Registry needs to be updated to add "ekt_key" as a new handshake type. The IANA requests is appropriately defined in the document. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. This document does not request new registries. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. ABNF content in the document was validated with https://tools.ietf.org/tools/bap/abnf.cgi |
2018-07-15 |
08 | Suhas Nandakumar | Responsible AD changed to Ben Campbell |
2018-07-15 |
08 | Suhas Nandakumar | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2018-07-15 |
08 | Suhas Nandakumar | IESG state changed to Publication Requested |
2018-07-15 |
08 | Suhas Nandakumar | IESG process started in state Publication Requested |
2018-07-15 |
08 | Suhas Nandakumar | Changed consensus to Yes from Unknown |
2018-07-15 |
08 | Suhas Nandakumar | Intended Status changed to Proposed Standard from None |
2018-07-15 |
08 | Suhas Nandakumar | Changed document writeup |
2018-07-15 |
08 | Cullen Jennings | New version available: draft-ietf-perc-srtp-ekt-diet-08.txt |
2018-07-15 |
08 | (System) | New version approved |
2018-07-15 |
08 | (System) | Request for posting confirmation emailed to previous authors: Flemming Andreasen <fandreas@cisco.com>, David McGrew <mcgrew@cisco.com>, John Mattsson <john.mattsson@ericsson.com>, Dan Wing <dwing@cisco.com>, Cullen Jennings <fluffy@iii.ca> |
2018-07-15 |
08 | Cullen Jennings | Uploaded new revision |
2018-07-14 |
Jenny Bui | Posted related IPR disclosure: Cisco's Statement about IPR related to draft-ietf-perc-srtp-ekt-diet | |
2018-03-18 |
07 | Suhas Nandakumar | Notification list changed to Suhas Nandakumar <suhasietf@gmail.com> |
2018-03-18 |
07 | Suhas Nandakumar | Document shepherd changed to Suhas Nandakumar |
2018-03-18 |
07 | Suhas Nandakumar | IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document |
2018-03-05 |
07 | Cullen Jennings | New version available: draft-ietf-perc-srtp-ekt-diet-07.txt |
2018-03-05 |
07 | (System) | New version approved |
2018-03-05 |
07 | (System) | Request for posting confirmation emailed to previous authors: Flemming Andreasen <fandreas@cisco.com>, David McGrew <mcgrew@cisco.com>, John Mattsson <john.mattsson@ericsson.com>, Dan Wing <dwing@cisco.com>, Cullen Jennings <fluffy@iii.ca> |
2018-03-05 |
07 | Cullen Jennings | Uploaded new revision |
2017-10-30 |
06 | Cullen Jennings | New version available: draft-ietf-perc-srtp-ekt-diet-06.txt |
2017-10-30 |
06 | (System) | New version approved |
2017-10-30 |
06 | (System) | Request for posting confirmation emailed to previous authors: perc-chairs@ietf.org, David McGrew <mcgrew@cisco.com>, John Mattsson <john.mattsson@ericsson.com>, Dan Wing <dwing@cisco.com>, Cullen Jennings <fluffy@iii.ca> |
2017-10-30 |
06 | Cullen Jennings | Uploaded new revision |
2017-06-29 |
05 | Cullen Jennings | New version available: draft-ietf-perc-srtp-ekt-diet-05.txt |
2017-06-29 |
05 | (System) | New version approved |
2017-06-29 |
05 | (System) | Request for posting confirmation emailed to previous authors: John Mattsson <john.mattsson@ericsson.com>, David McGrew <mcgrew@cisco.com>, Dan Wing <dwing@cisco.com>, Cullen Jennings <fluffy@iii.ca> |
2017-06-29 |
05 | Cullen Jennings | Uploaded new revision |
2017-04-28 |
04 | Cullen Jennings | New version available: draft-ietf-perc-srtp-ekt-diet-04.txt |
2017-04-28 |
04 | (System) | New version approved |
2017-04-28 |
04 | (System) | Request for posting confirmation emailed to previous authors: John Mattsson <john.mattsson@ericsson.com>, Cullen Jennings <fluffy@iii.ca>, David McGrew <mcgrew@cisco.com>, Dan Wing <dwing@cisco.com>, perc-chairs@ietf.org |
2017-04-28 |
04 | Cullen Jennings | Uploaded new revision |
2017-03-13 |
03 | Cullen Jennings | New version available: draft-ietf-perc-srtp-ekt-diet-03.txt |
2017-03-13 |
03 | (System) | New version approved |
2017-03-13 |
03 | (System) | Request for posting confirmation emailed to previous authors: John Mattsson <john.mattsson@ericsson.com>, Cullen Jennings <fluffy@iii.ca>, David McGrew <mcgrew@cisco.com>, Dan Wing <dwing@cisco.com>, perc-chairs@ietf.org |
2017-03-13 |
03 | Cullen Jennings | Uploaded new revision |
2016-10-31 |
02 | Cullen Jennings | New version available: draft-ietf-perc-srtp-ekt-diet-02.txt |
2016-10-31 |
02 | (System) | New version approved |
2016-10-31 |
01 | (System) | Request for posting confirmation emailed to previous authors: perc-chairs@ietf.org, "David McGrew" <mcgrew@cisco.com>, "Cullen Jennings" <fluffy@iii.ca>, "John Mattsson" <john.mattsson@ericsson.com>, "Dan Wing" <dwing@cisco.com> |
2016-10-31 |
01 | Cullen Jennings | Uploaded new revision |
2016-07-08 |
01 | Cullen Jennings | New version available: draft-ietf-perc-srtp-ekt-diet-01.txt |
2016-05-09 |
00 | Suhas Nandakumar | This document now replaces draft-jennings-perc-srtp-ekt-diet instead of None |
2016-05-09 |
00 | Cullen Jennings | New version available: draft-ietf-perc-srtp-ekt-diet-00.txt |