[Perc] Double questions

Eric Rescorla <ekr@rtfm.com> Tue, 21 March 2017 22:58 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC9141293FD for <perc@ietfa.amsl.com>; Tue, 21 Mar 2017 15:58:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nsd5wxYXQI4M for <perc@ietfa.amsl.com>; Tue, 21 Mar 2017 15:58:45 -0700 (PDT)
Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54876129404 for <perc@ietf.org>; Tue, 21 Mar 2017 15:58:43 -0700 (PDT)
Received: by mail-yw0-x22e.google.com with SMTP id i203so5135409ywc.3 for <perc@ietf.org>; Tue, 21 Mar 2017 15:58:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=FxwImU+ghi/WekBbaFf+NkGl4p6fT779jnYIFPh98gg=; b=a6/bLuGDqOGHiqeN40PhURt7OGFh8Q/AXWY3L00QIXNSsDeJYIoXruyCCWnpsiHZpJ J46Z0Th4xaov8p9dwN70hLmoiYqebPk71WEH/Bb/VjS1jOsQI2nAsFfP9UFeoS0stnf3 CDoK1Xu502L4+MXGdlYQrj2NaM1NZs7j9e+lVsepZxlt3kXUahFqYdwsSsRnfGw4Jr3p gvBISx63RDn1gLnitkK0cZV30zQ81Fj7Bkv1i0IPZSyRW3P38fDI4hJ7RCY6NMv17ADM fxMQLVz4lmPrzKsWe2MVxd1HhkVPTkIR6fRoELohHKQT5GdH9molvzn8+MH/gQAq8QUT O9lA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=FxwImU+ghi/WekBbaFf+NkGl4p6fT779jnYIFPh98gg=; b=idp5muldBHYtDQPwssLbWG4a9FFkL+eRiZGJ0Ut6q3TcqLpx0XKQIXcS96QcY3HkcX Mbnw/rpMP6wbPcD45fxheo0utfQyr1BJQPpWGle+zTnEoiZq/4sQpFU+Hx3jk7+6aab6 XgWtBudU+Vn3j+grRF2GTOdOzMMGMnl2incTB4UKmiJ4G50KbWRbMFj3bUs+/Ul1XQJi TCsC10JQ+DJbKMaLegxLDcCQ4dlLAF1kOsfnu6MZCeqsdCfoLT/H5bsdOviLi9kVyRwm pIGUR+29PPhPLVQKrRFPCjWlHxhR+xHsnotPFIfNly5DHfVarfCdlc1MoafFx7PiRirz 1Jxg==
X-Gm-Message-State: AFeK/H0/hm2Sqtx8RJgHeCSE6oL8jwdvIIcTEIYZM2KjouaPJdz/jzXI398Pd/5of+kK/QRoBMQh0IUlS8To1w==
X-Received: by 10.37.53.138 with SMTP id c132mr24398986yba.105.1490137122300; Tue, 21 Mar 2017 15:58:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.154.210 with HTTP; Tue, 21 Mar 2017 15:58:01 -0700 (PDT)
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 21 Mar 2017 15:58:01 -0700
Message-ID: <CABcZeBNKZLww=iFutD_EVGzNJo0y6ieSoZ55LjCG4rnnn-bOhw@mail.gmail.com>
To: perc@ietf.org
Content-Type: multipart/alternative; boundary="001a114bbb32d77e47054b4595b6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/perc/rrhAezuD46YvCVj4dCeI0CiWePI>
Subject: [Perc] Double questions
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing <perc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/perc>, <mailto:perc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/perc/>
List-Post: <mailto:perc@ietf.org>
List-Help: <mailto:perc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/perc>, <mailto:perc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Mar 2017 22:58:47 -0000

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