[secdir] secdir review of draft-ietf-vcarddav-kind-app-00.txt

Stephen Hanna <shanna@juniper.net> Thu, 20 October 2011 10:04 UTC

Return-Path: <shanna@juniper.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC1E121F8BA6; Thu, 20 Oct 2011 03:04:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.59
X-Spam-Level:
X-Spam-Status: No, score=-105.59 tagged_above=-999 required=5 tests=[AWL=1.009, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6N4cGUxzZ5je; Thu, 20 Oct 2011 03:04:39 -0700 (PDT)
Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id E333F21F8BA4; Thu, 20 Oct 2011 03:04:38 -0700 (PDT)
Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP; Thu, 20 Oct 2011 03:04:39 PDT
Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 20 Oct 2011 03:00:32 -0700
Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Thu, 20 Oct 2011 06:00:31 -0400
From: Stephen Hanna <shanna@juniper.net>
To: "secdir@ietf.org" <secdir@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Date: Thu, 20 Oct 2011 06:00:29 -0400
Thread-Topic: secdir review of draft-ietf-vcarddav-kind-app-00.txt
Thread-Index: AcyPDxkDxYHMlKhpR9u8exbF6CFuFA==
Message-ID: <AC6674AB7BC78549BB231821ABF7A9AEB80EBEAFC1@EMBX01-WF.jnpr.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "draft-ietf-vcarddav-kind-app.all@tools.ietf.org" <draft-ietf-vcarddav-kind-app.all@tools.ietf.org>
Subject: [secdir] secdir review of draft-ietf-vcarddav-kind-app-00.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
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: <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: Thu, 20 Oct 2011 10:04:39 -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 a new value for the vCard kind property:
application. This value is to be used for vCards that represent
software applications.

The Security Considerations section of this document states:

   Use of vCards to represent software applications is not envisioned to
   introduce security considerations beyond those specified for vCards
   in general as described in [VCARD].

However, the Security Considerations section of [VCARD] doesn't
seem adequate to the task. It merely points out that vCards don't
have any security protections and therefore SHOULD be transported
over a secure mechanism such as S/MIME or PGP if security is a
concern. This advice may be adequate if the vCard is only used
to transmit contact information for a person but it's generally
not adequate when the vCard contains information about a software
application. For example, this draft suggests that the KEY property
can be used to convey a public key associated with an application.
What a weak way to convey a public key! Will the recipient be able
to determine whether the key is accurate? How might the key be
revoked if necessary? No provisions are made for this. Other vCard
properties such as URL may cause problems if malicious.

Without proper security protections, the application vCard kind
seems like a great tool for phishing and social engineering.
Attackers can forge an email apparently from a trusted party,
including an application vCard and instructions to click on it
to see something cool. A naive email client may easily decide
that clicking on an application vCard should run the application
referenced in the vCard or visit the URL in the vCard or whatever.

I suggest that the Security Considerations section of the draft
be updated to include specific warnings that the contents of an
application vCard should be considered untrustworthy and dangerous
unless they have been securely delivered from a trustworthy source.
Even then, there's a real possibility that the source may have
been compromised before the vCard was sent. So information
obtained from vCards should not be regarded as ipso facto
trustworthy. Software should not act on information contained
in a vCard unless there's a strong reason to believe it's
accurate. And the KEY property SHOULD NOT be used for an
application. Instead, more robust techniques for managing
software public keys should be used.

Thanks,

Steve