[secdir] Review of draft-ietf-eppext-tmch-smd-03

Simon Josefsson <simon@josefsson.org> Thu, 03 December 2015 14:59 UTC

Return-Path: <simon@josefsson.org>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E50301A89FF; Thu, 3 Dec 2015 06:59:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.351
X-Spam-Level:
X-Spam-Status: No, score=-0.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, J_CHICKENPOX_35=0.6, J_CHICKENPOX_45=0.6, SPF_PASS=-0.001] autolearn=no
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 UzZt5kGzvhSg; Thu, 3 Dec 2015 06:59:54 -0800 (PST)
Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AB161A8A07; Thu, 3 Dec 2015 06:59:53 -0800 (PST)
Received: from latte.josefsson.org ([155.4.17.2]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id tB3ExhCd008887 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 3 Dec 2015 15:59:44 +0100
X-Hashcash: 1:22:151203:iesg@ietf.org::+X7xjQ3yJwyFfMto:16KX
X-Hashcash: 1:22:151203:secdir@ietf.org::yItOzKGgcz0MllIh:Do6U
X-Hashcash: 1:22:151203:draft-ietf-eppext-tmch-smd.all@tools.ietf.org::pWwscI9K3M3v5L2k:KF0O
From: Simon Josefsson <simon@josefsson.org>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-eppext-tmch-smd.all@tools.ietf.org
OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt
Date: Thu, 03 Dec 2015 15:59:42 +0100
Message-ID: <87twnzy3vl.fsf@latte.josefsson.org>
User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se
X-Virus-Status: Clean
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/vZZHAqjMN-AlaHWJrnxtinEjZMw>
Subject: [secdir] Review of draft-ietf-eppext-tmch-smd-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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: Thu, 03 Dec 2015 14:59:58 -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.

I believe that this document is Not Ready.  The main reason for this is
the editorial concern 1) below.  Due to it I find it difficiult to
complete a proper technical review of the document.  Once 1) is fixed,
I'm happy to take another look and provide final technical feedback.

For easy reference, here is the document that I reviewed:
https://tools.ietf.org/html/draft-ietf-eppext-tmch-smd-03

1) The "Introduction" (section 1) is too thin to give the reader a
useful introduction to the document.  It explains WHAT is described in
the document, but it does not describe for what PURPOSE this is intended
to be used for.  Nor does it give an introduction to the roles of the
various acronyms mentioned, or the terms used.

The document does not explain what a "mark" or a "signed mark" is, which
appears fundamental for understanding any of it.  I can't find anything
in the WG charter that explain what a "mark" or "signed mark" is either.
I also searched through the normative references.

I suggest to add text describing for what purpose this protocol is
intended for, and some context in which it will be useful, and a
reference or definition of the terms used ("mark" and "signed mark").

Further, since section 2 dives directly into XML protocol details, I
believe this document would be greatly improved by having a new section
called "Architecture" that with a few sentences and/or illustration
describe how the solution is actually intended to work and what entities
are involved.  That would be a better place to put some of the security
discussions in (see issue 3 and 6 below).

2) Section 2: Acronyms like XSD should be expanded on first use.

3) Section 2.3: It says that certificates MAY be signed by a CA, but
it does not discuss anything about how a receiver will be able to
trust either the certificate or the CA, nor how the certificate
validation would actually work.  In particular, how would a receiving
entity validate the certificate?  What is the name that the validator
has to look for in the certificate?

4) Section 2.3, re the smd:url, only suggests a HTTP URL.  Wouldn't it
be useful to allow a HTTPS URL to be used?

5) Section 2.1 and 2.3, re mark:voice, mark:fax and smd:voice -- these
descriptions should clarify the format of the phone number.

6) Section 2.3, the algorithm recommendations could probably be
clarified somewhat.  It says:

   SHA256 as suggested by [RFC6194] and RSA-SHA256 SHOULD be used for
   digesting and signing respectively.  The size of the RSA key SHOULD
   be at least 2048 bits.

I don't think the RFC 6194 reference is all that important in this
context.  What matters is the recommendations given.  I suggest:

   The digital signature algorithm used SHOULD be RSA-SHA256 [RFC 4051].
   The size of the RSA key SHOULD be at least 2048 bits.  A valid reason
   for chosing something else would be if RSA-SHA256 would be deemed to
   not provide sufficient security.

7) Regarding section 2.4, I suggest to use RFC 4648 as the reference
for base64.

8) Section 2.5: The example is really long.  Can't you find a shorter
one?  Will people be helped by having this base64 blob in the
document?  Also the section title shouldn't include "Appendix A", this
should be moved to a proper Appendix.

9) Section 3.1 and 3.2: Don't include copyright notice and license,
use the 'BEGIN CODE' and 'END CODE' marker or simply include text
describing that the following is considered code and is available
under the IPR Trust license.

10) The reference for XMLDSIG is the 2008-06-10 version.  Should it
use 1.1 or 2.0 instead?  See http://www.w3.org/TR/xmldsig-core1/ or
http://www.w3.org/TR/xmldsig-core2/

/Simon