Re: [secdir] secdir review of draft-hanes-dispatch-fax-capability-06

David Hanes <> Fri, 11 January 2013 03:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A6D7321F8809; Thu, 10 Jan 2013 19:31:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0Z7P+mHT+C5f; Thu, 10 Jan 2013 19:31:53 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id E350C21F87DC; Thu, 10 Jan 2013 19:31:52 -0800 (PST)
X-TACSUNS: Virus Scanned
Received: from ( []) by (8.13.8+Sun/8.13.8) with ESMTP id r0B3VoMU011273; Thu, 10 Jan 2013 22:31:50 -0500 (EST)
Received: from ( []) by (8.13.8+Sun/8.13.8) with ESMTP id r0B3VnEE013828; Thu, 10 Jan 2013 22:31:49 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset="us-ascii"
From: David Hanes <>
In-Reply-To: <>
Date: Thu, 10 Jan 2013 22:31:49 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Tom Yu <tlyu@MIT.EDU>
X-Mailer: Apple Mail (2.1085)
X-Mailman-Approved-At: Fri, 11 Jan 2013 03:24:12 -0800
Cc:, Kevin Fleming <>, Gonzalo Camarillo <>, Gonzalo Salgueiro <>,,
Subject: Re: [secdir] secdir review of draft-hanes-dispatch-fax-capability-06
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 11 Jan 2013 03:31:54 -0000

Hi Tom,

Sorry for the delayed response but thanks for your review and feedback on the document.  This media feature tag has the effect of explicitly indicating a call *preference* to be fax; but there is no guarantee that it will end up that way (the re-INVITE SIP message later in the call flow is a much more accurate predictor that a call is of type fax).  Your question is reasonable since that simple fact could still seemingly simplify targeted attacks because chances are improved that the resultant call is indeed fax.  The truth is that SIP and SDP have various such media identification features so this is a persistent issue. Secondly, the reason for the umbrella reference to RCFC 3840 is that ANY media feature tag will be an explicitly indication of preference for a particular media type (speech, text, etc.). This draft merely registers a new value in a long list of other media feature tags but doesn't introduce any new Security Considerations that those others wouldn't have to address through the standard recommended privacy mechanisms (e.g., encryption, obfuscation, etc.). 


On Dec 26, 2012, at 11:37 PM, Tom Yu 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 describes a SIP media feature tag for indicating support
> for fax calls.
> The Security Considerations section of this document refers to the
> Security Considerations documented in Section 11.1 of RFC 3840.  This
> seems mostly adequate.  One additional question (which might be
> irrelevant because of my unfamiliarity with SIP) is whether an
> explicit indication of fax content would make it easier for an
> eavesdropper to target fax image data (which might contain sensitive
> information such as credit card numbers).