Subject: Re: [Perc] Benjamin Kaduk's Discuss on draft-ietf-perc-srtp-ekt-diet-10: (with DISCUSS and COMMENT)

From: Richard Barnes <[email-masked]>
Date: Fri, 2 Aug 2019 13:48:11 -0500

On Wed, Jul 17, 2019 at 3:12 PM Benjamin Kaduk via Datatracker <
[email-masked]> wrote:

> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-perc-srtp-ekt-diet-10: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-perc-srtp-ekt-diet/
>
>
>
> ----------------------------------------------------------------------
> 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)?
>

We may have had one in person, but I'm not seeing one in my email history
either.  The short answer is that I don't think any generalization is
needed.

The longer version is: RTP and SRTP packet formats are not intended to
self-describing.  Instead, they rely heavily on external negotiation to
tell the endpoint how to parse the packet.  For example, there is no
standard format for the RTP extension field; the format of the field (and
even the identifiers for individual extensions used therein) are negotiated
in SDP.

In this context, that means that it's up to the application to make good
decisions about which extensions apply.  Note that EKT is already
incompatible with the SRTP MKI mechanism (as noted in the document), as an
example of the types of incompatibilities that application need to navigate.

> 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.
>

On the HandshakeType: The authors had a fairly extensive (but unfortunately
off-list) discussion with EKR about how to transmit the EKT key.  After
evaluating the full range of options -- from EncryptedExtensions all the
way to the application layer -- the conclusion of that discussion was that
a HandshakeType fit best with the requirements here.  I'm not sure I
understand your worry about the scarcity of HandshakeType values. "Any
standards-track protocol" is basically the highest bar we have; what more
would you ask?  Practically speaking, we are defining new HandshakeType
values at a high enough rate that we seem likely to exhaust the pool.

On the ExtensionType: Thanks for calling that out; I have sent a request to
the mailing list.  Is there a reason that IANA doesn't send those emails,
like they do with other approvals from designated experts?

--Richard

>
>
> ----------------------------------------------------------------------
> 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
>
>
> _______________________________________________
> Perc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perc
>

---

From: Suhas Nandakumar <[email-masked]>
Date: Fri, 16 Aug 2019 07:44:42 -0700

Hi Benjamin

  Curious to see if Richard's responses addresses your feedback.

Thanks
Suhas

On Fri, Aug 2, 2019 at 11:48 AM Richard Barnes <[email-masked]> wrote:

> On the HandshakeType: The authors had a fairly extensive (but
> unfortunately off-list) discussion with EKR about how to transmit the EKT
> key.  After evaluating the full range of options -- from
> EncryptedExtensions all the way to the application layer -- the conclusion
> of that discussion was that a HandshakeType fit best with the requirements
> here.  I'm not sure I understand your worry about the scarcity of
> HandshakeType values. "Any standards-track protocol" is basically the
> highest bar we have; what more would you ask?  Practically speaking, we are
> defining new HandshakeType values at a high enough rate that we seem likely
> to exhaust the pool.
>
> On the ExtensionType: Thanks for calling that out; I have sent a request
> to the mailing list.  Is there a reason that IANA doesn't send those
> emails, like they do with other approvals from designated experts?
>
> --Richard
>
>
>
>>
>>

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 30 Aug 2019 17:07:27 -0500

Hi Richard,

Sorry I effectively missed this when it came in, and needed reminding.

> example of the types of incompatibilities that application need to navigate.

I can accept that it's up to the application to make good decisions, but I
think we can try to help the application make informed decisions.  Based
just on what's in the document right now, I can't really decide whether EKT
needs all of the stuff between the end of SRTP and the end of UDP, or just
needs to be at the absolute end, or needs to be identifiable based on
cleartext framing [starting from the end], or something else.  We note that
EKT is incompatible with MKI because they offer largely the same
functionality, not because their wire encodings are incompatible; I'd like
to see some text that gives more explicit treatment of the ways in which
this extension behaves that are at risk of being incompatible with other
common extension patterns.  (I'm not quite sure yet whether I'd insist on
such text in the document, though, and am open to further discussion.)

> values at a high enough rate that we seem likely to exhaust the pool.

My comment about "any standards-track protocol" was trying to indicate that
there's not a strict hierarchy of what bar we apply to registrations --
effectively, the IETF-wide review that we want for standards-track
documents does not encompass everyone at the IETF for all documents, and
there may be case where some reviews (e.g., those of the registry's DEs)
may be particularly important to solicit.
That said, we've definitely had some high-powered TLS Experts thinking hard
about this issue, so it's not clear how much real benefit there'd be to
adding delay to do a formal call for review on the TLS WG.  (Though it
would have been nice if we could have done that in parallel at an earlier
stage of the document's lifecycle.)

I did get a chance to think harder about the range of options, and don't
have a fundamental objection to using a TLS handshake type to carry
EKTKeys, since in the RFC 5764/7983 world we're in some sense treating DTLS
and SRTP as a single combined protocol, with DTLS providing key material
for the SRTP "application data" (among other things) -- in that mindset we
are naturally using a DTLS handshake message to provide cryptographic input
to the other protocol layer, which is exactly what the handshake protocol
is for!

That said, I do have a new(?) concern about this document, since it
refers to the "Ack handshake message as described in Section 7 of
[I-D.ietf-tls-dtls13]"; chasing the reference, we find that Ack is a new
content-type, not a handshake type, to avoid having to include them in the
transcript.  There is not a fundamental reason why the Ack being a
dedicated content-type means that the EKTkey being ack'd should be a
dedicated content-type, too, though -- after all, the original purpose of
the ack is to acknowledge ... handshake records.

> like they do with other approvals from designated experts?

And it only got one expert to reply; I guess I should try to ping that
thread.

I think we are still figuring out what the best workflow for this sort of
thing is, and were definitely lacking on specific guidance/procedures in
the document that established the registry/list.  But, I believe the intent
for doing it this way is that the requestor can engage directly with the
experts, and the requestor is presumed to have a better understanding of
what exactly they need than the fine folks at IANA do.  That is, this way
IANA doesn't have to keep relaying messages back and forth, if there is any
clarification needed.

Thanks,

Ben