Subject: [Perc] Double questions

From: Eric Rescorla <[email-masked]>
Date: Tue, 21 Mar 2017 15:58:01 -0700

I've been reading Double and wanted to make sure I understand it.
Here's my attempt to summarize, along with some questions.
Corrections/answers would be welcome.

INITIAL ENCRYPTION
- Normal header
- Non-modifiable Extensions
- Modifiable Extensions
- Payload

When you encode a packet, you first encrypt the inner packet consisting
solely of:

- Normal header
- Non-modifiable Extensions
- Payload

[I am ignoring encrypted extensions]

Then if there is 1 or more non-modifiable extensions, you append an
OHB and the modifiable extensions, like so:

- Normal header
- Non-modifiable Extensions
- OHB
- Modifiable Extensions
- Encrypted Payload

And now you encrypt that. As I understand it, the OHB, if present,
must replicate the inner header:

      The OHB MUST replicate the information found in the
      RTP header following the application of the inner cryptographic
      transform.

Does that mean it must be of 3-byte length? If so, why, because the
outer transform shouldn't be changing any of these values. I.e.,
at the point where the packet gets to the media relay, PT and SEQ
should match between the header and OHB.

RELAYING
Now, the media distributor removes the outer transform to recover:

- Normal header
- Non-modifiable Extensions
- OHB
- Modifiable Extensions
- Encrypted Payload

AT this point it can:

1. Change SEQ and/or PT as long as it updates OHB to match.
   But how does it get out of sync?]
2. Do anything it wants to the modifiable extensions, prepending
   an OHB if there was one.

So, now you have:

- Normal header
- Non-modifiable Extensions
- OHB'
- Modifiable Extensions'
- Encrypted Payload

And you encrypt that and send.

DECRYPTION
Finally, upon decryption, you strip the outer transform, and get:

- Normal header
- Non-modifiable Extensions
- OHB'
- Modifiable Extensions'
- Encrypted Payload

You then remove the modifiable extensions, stomp the stuff in the
normal header with the OHB, and then strip the inner transform.

I note that S 5.3. says:

   o  The PT from the outer SRTP packet is used for normal matching to
      SDP and codec selection.

   o  The sequence number from the outer SRTP packet is used for normal
      RTP ordering.

So, does that mean that the original PT/SEQ (as reconstructed from
OHB) are not used for anything other than to make the decryption work?
They're totally discarded?

-Ekr

---

From: Nils Ohlmeier <[email-masked]>
Date: Tue, 21 Mar 2017 16:43:37 -0700

> On Mar 21, 2017, at 15:58, Eric Rescorla <[email-masked]> wrote:
> - Normal header

Yes that is my current reading of the draft that if the originating
client adds the OHB it needs to duplicate PT and SEQ even though
it has obviously not modified these.
I guess the question here is if it is worth to have a shorter OHB
header for the scenarios where PT and SEQ are the same (which could
be used by originating client as well as relays which don't change
any of this)?

> normal header with the OHB, and then strip the inner transform.

To be precise I think you need to take OHB and modifiable extensions out
to make the decryption work. After the decryption you re-insert the
modifiable extensions into the packet, because they might be of interest
for your RTP stack.

> They're totally discarded?

That is my understanding, yes.

  Nils

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 21 Mar 2017 23:57:15 +0000

Ekr,

>They're totally discarded?

Yes, I think you described it all correctly.  The PT and SEQ are 
necessary only because they were originally there when the transmitting 
endpoint performed HBH authenticated encryption.  Thus, we need those 
original values to properly authenticate the packet when decrypting.  No 
other reason for keeping them.

Paul

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 27 Mar 2017 15:09:48 -0500

> On Mar 21, 2017, at 6:43 PM, Nils Ohlmeier <[email-masked]> wrote:
> 

Pretty much .. but they might get used for various stats at e2e level