Re: [secdir] Security review of draft-ietf-rtcweb-fec-08 (was Re: Security review of draft-ietf-perc-srtp-ekt-diet-08)

[Hilarie Orman <[e-mail]>]

I think that the purpose of the FEC should be explicit, else the interaction with
encryption will remain a source of confusion forever.

Hilarie  

----- Original Message -----
From: Justin Uberti <[e-mail]>
To: Ben Campbell <[e-mail]>
Cc: Hilarie Orman <[e-mail]>, The IESG <[e-mail]>, [e-mail], draft-ietf-rtcweb-fec all <[e-mail]>
Sent: Fri, 08 Feb 2019 18:20:41 -0700 (MST)
Subject: Re: Security review of draft-ietf-rtcweb-fec-08 (was Re: Security review of draft-ietf-perc-srtp-ekt-diet-08)

On Fri, Feb 1, 2019 at 2:49 PM Ben Campbell <[e-mail]> wrote:

> Hi,
>
> Please note that this review is for draft-ietf-rtcweb-fec-08, not the PERC
> draft referenced in the subject.
>
> Thanks!
>
> Ben.
>
>
> > On Feb 1, 2019, at 1:42 AM, Hilarie Orman <[e-mail]>
> wrote:
> >
> > Security Review of WebRTC Forward Error Correction Requirements
> > draft-ietf-rtcweb-fec-08
> >
> > Do not be alarmed.  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.
> >
> > The document describes the appropriate uses of FEC for web content when
> > using WebRTC.  It also describes how to indicate that FEC is being used.
> >
> > The Security Considerations mention the possibility of additional network
> > congestion when using FEC.  Although this can be a problem, I do not
> think
> > it is a security issue, thus it does not belong in this section.
>

Understood. I think this paragraph could easily be moved to the preceding
section.

> >
> > There is a security-related issue wrt to FEC and encryption.  If the
> > error model is that message blocks may be lost but not altered in
> > transit, then FEC with encryption is fine.  But if FEC is added for
> > the purpose of correcting corrupted bits in a message block, then it
> > is important that FEC is done after encryption.  The draft seems to
> > ignore the issue, and it also seems to recommend a processing scheme
> > that would result in encryption of the FEC data.  If there is a body
> > of practice for other IETF FEC protocols that explains these issues,
> > an explicit reference to it in the Security Considerations would be
> > very helpful.
>
> FEC is added specifically to protect against lost blocks. Any corruption
of the blocks will be detected by the decryption procedure, and such blocks
will be discarded.

There is a reference to RFC 3711, which stipulates the fec-then-encrypt
ordering. RFC 3711 is admittedly terse on this subject, but it is quite
clear about the ordering.