[secdir] Secdir review of draft-meadors-multiple-attachments-ediint-10

Magnus Nyström <magnusn@gmail.com> Sun, 27 February 2011 03:54 UTC

Return-Path: <magnusn@gmail.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 163E53A69AD; Sat, 26 Feb 2011 19:54:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level:
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5oQge+wS1ns; Sat, 26 Feb 2011 19:54:18 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id C0EA53A69AA; Sat, 26 Feb 2011 19:54:18 -0800 (PST)
Received: by iyj8 with SMTP id 8so2224390iyj.31 for <multiple recipients>; Sat, 26 Feb 2011 19:55:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=iPYRgMBoZfGI8V+2y3FUcJkfCyH1aK3o2rQE4bMu7iI=; b=g6wFPWpPXmXdJhKDwAYiNgYU/ybLR8IlR+rtXxfbWhDU3PpcP4QRs69rtx5EMylmId 6TChsn7L0IEJs4EwoLoaKWCtpWb9Fw15V5yrdASKc/ZW6Pzew19kPj7RApsPpcJyPz1m CfSqAi8/A2jEB87QaK8rRfkeY71nIi63VfRLg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=Z0C79m/VPSjcA5Y1WAuwDz4Apg7hdLYpteJO2Q9X1KBnZvg0sQmBzyXVSDyFJVO6tn pC+E6AzOhwAtiiIzG63PNiS7WNqzlZrsOr4b/EzqgiFbmslQSHXY7j4hVsURlg4Cnef5 lRcn4Ze6Xe7c918iO5oCT0oA64iCrgVSoNq9c=
MIME-Version: 1.0
Received: by 10.231.32.133 with SMTP id c5mr1220771ibd.115.1298778915289; Sat, 26 Feb 2011 19:55:15 -0800 (PST)
Received: by 10.231.31.70 with HTTP; Sat, 26 Feb 2011 19:55:15 -0800 (PST)
Date: Sat, 26 Feb 2011 19:55:15 -0800
Message-ID: <AANLkTikY_fMV-to2oXW6b4pwJZorvag3hHqWzQEBjXx3@mail.gmail.com>
From: =?ISO-8859-1?Q?Magnus_Nystr=F6m?= <magnusn@gmail.com>
To: draft-meadors-multiple-attachments-ediint@tools.ietf.org, secdir@ietf.org, iesg@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: [secdir] Secdir review of draft-meadors-multiple-attachments-ediint-10
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 27 Feb 2011 03:54:20 -0000

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 defines how to carry multiple, related EDI documents in
MIME using the multipart/related content-type and how to calculate
message integrity codes over such related documents.

Section 2.3:

a) Reference to MIC computation in EDIINT compression should be to
Section 4, not Section 2 of RFC 5402.

b)  For clarity, may want to replace the text

  "When a digital signature is applied to the multipart/related
   envelope, the MIC is calculated on the entire multipart/related
   envelope, including the MIME header and all attached documents."

with:

  "When a digital signature is applied to the multipart/related
   envelope, the MIC is calculated on the entire multipart/related
   envelope, including the multipart/related MIME header and all
attached documents."

c) Similarly, (as the sender performs the MIC calculation before
encrypting) I would suggest replacing:

  "For an encrypted but unsigned and uncompressed message, the MIC is
   calculated on the decrypted multipart/related envelope, including
   header and all attached documents."

with:

  "For an encrypted but unsigned and uncompressed message, the MIC is
   calculated on the unencrypted multipart/related envelope, including
   the multipart/related header and all attached documents."

d) I don't understand: "or an unsigned and unencrypted message, the
MIC is calculated over
   the data inside the multipart/related boundaries prior to Content-
   Transfer-Encoding.  However, unsigned and unencrypted messages SHOULD
   not be sent due to lack of security.": Why do the MIC-calculation
on the internal data only? Why not use the same algorithm (i.e.
include the outermost multipart/related MIME header?). Also, should
not canonicalization be carried out in this case?

Section 3:

- May be useful to use micalg SHA-256 (I realize this is an example,
but generally we'd like to move in this direction and so examples
should encourage it)?

Section 4:

- May be worthwhile to reference to S/MIME (RFC 5751) for Security
considerations in general for signed multipart/related messages.

-- Magnus