Re: [secdir] Secdir review of draft-ietf-perc-double-10

[Radia Perlman <[e-mail]>]

On Wed, Oct 31, 2018 at 12:30 PM Richard Barnes <[e-mail]> wrote:

> Hi Radia,
>
> Thanks for the review.  Responses to the substantive comments inline.
> Will take a look at the editorial ones in a bit.
>
>
> On Wed, Oct 31, 2018 at 2:25 PM Radia Perlman <[e-mail]>
> wrote:
>
>>
>> I have reviewed this document as part of the security directorate's
>> ongoing effort to review all IETF documents being processed by the IESG.
>> These comments were written primarily for the benefit of the security area
>> directors.  Document editors and WG chairs should treat these comments just
>> like any other last call comments.
>>
>> This document specifies a syntax for doubly encrypting Secure Real Time
>> Protocol (SRTP) packets so that the inner (media) content is encrypted with
>> a key known only to the endpoints while some header content is encrypted
>> with a separate key known by both the endpoints and network relay points
>> called Media Distributors (with the outer encryption key (usually) changing
>> on each hop).
>>
>> Below are details for consideration by the authors and other potential
>> security reviewers.
>>
>> Substantive comments:
>>
>> Page 2 First paragraph:
>> AES-GCM is the only specified cryptographic mode, but may not be the
>> appropriate mode to use in distributing this content because there may be
>> cases where we want to guarantee the integrity of the data end-to-end while
>> allowing intermediaries to see the content. To support this case, it might
>> make sense to allow the encryption and integrity protection keys to be
>> separate so that an intermediary might be given the encryption key but not
>> the integrity protection key.
>>
>
> I think you mean we would give the intermediary the integrity key, not the
> encryption key :)  Since we want to enable the intermediary to modify
> things, but not read the content.
>


No, I really mean an intermediary might need the encryption key, so it can
read the contents, but not the integrity key, because it shouldn't modify
the contents.  An example is an intermediary scanning for viruses.  It
needs to see the contents, but is not going to modify the contents. That
way the integrity check really means that the source is vouching for the
authenticity of the content ("end-to-end integrity")

I can't think of any cases of an intermediary needing to modify encrypted
contents, and therefore needing the integrity key but not the encryption
key.

I'll look at the rest of the comments later..

Radia