[ietf-dkim] Is DMARC the right place for SMTP-TLS policy and reporting?

Chris Lamont Mankowski <makerofthings77@gmail.com> Tue, 19 June 2012 11:59 UTC

Return-Path: <ietf-dkim-bounces@mipassoc.org>
X-Original-To: ietfarch-ietf-dkim-archive@ietfa.amsl.com
Delivered-To: ietfarch-ietf-dkim-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55C1A21F85F6 for <ietfarch-ietf-dkim-archive@ietfa.amsl.com>; Tue, 19 Jun 2012 04:59:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.648
X-Spam-Level:
X-Spam-Status: No, score=-5.648 tagged_above=-999 required=5 tests=[AWL=0.950, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 yW8xAXQTxznY for <ietfarch-ietf-dkim-archive@ietfa.amsl.com>; Tue, 19 Jun 2012 04:59:57 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6988721F85F2 for <ietf-dkim-archive@ietf.org>; Tue, 19 Jun 2012 04:59:56 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [127.0.0.1]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q5JBwofp028538; Tue, 19 Jun 2012 04:58:59 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=mipassoc.org; s=k00001; t=1340107146; bh=u3Fos+EUb1p5cXfgGHk2WsPnfg0=; h=MIME-Version:Date: Message-ID:From:To:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Content-Type:Sender; b=QqtadaSr GKB2SOZcdZMvm145pQqeUComAA5nbQLcWyO5S0d44BbeIxNJear8TZixBz1co8QvPNg esFlsNi6nJvw5B8r/2fD8O0wwzaX5XnvhqfXRPq9Y3Xa4Bsv7ucdEiBFGGIg11vk8C3 9D/CrxnvJnXVFUPVMttIWWh1RqpC0=
Received: from mail-ob0-f178.google.com (mail-ob0-f178.google.com [209.85.214.178]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q5JBwjL6028522 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <ietf-dkim@mipassoc.org>; Tue, 19 Jun 2012 04:58:48 -0700
Authentication-Results: sbh17.songbird.com; dkim=pass (2048-bit key) header.i=@gmail.com
Received: by obceq6 with SMTP id eq6so10517157obc.9 for <ietf-dkim@mipassoc.org>; Tue, 19 Jun 2012 04:58:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.114.97 with SMTP id jf1mr19450371obb.59.1340107124870; Tue, 19 Jun 2012 04:58:44 -0700 (PDT)
Received: by 10.76.80.99 with HTTP; Tue, 19 Jun 2012 04:58:44 -0700 (PDT)
Date: Tue, 19 Jun 2012 07:58:44 -0400
Message-ID: <CANMw_CtsiLcJX+JO+zA-MzX9E+JVv1=LCbJdpS+4XqRjpv7pRg@mail.gmail.com>
From: Chris Lamont Mankowski <makerofthings77@gmail.com>
To: ietf-dkim@mipassoc.org
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [127.0.0.1]); Tue, 19 Jun 2012 04:59:06 -0700 (PDT)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Tue, 19 Jun 2012 04:58:49 -0700 (PDT)
Subject: [ietf-dkim] Is DMARC the right place for SMTP-TLS policy and reporting?
X-BeenThere: ietf-dkim@mipassoc.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DKIM Discussion List <ietf-dkim.mipassoc.org>
List-Unsubscribe: <http://mipassoc.org/mailman/listinfo/ietf-dkim>, <mailto:ietf-dkim-request@mipassoc.org?subject=unsubscribe>
List-Archive: <http://mipassoc.org/pipermail/ietf-dkim>
List-Post: <mailto:ietf-dkim@mipassoc.org>
List-Help: <mailto:ietf-dkim-request@mipassoc.org?subject=help>
List-Subscribe: <http://mipassoc.org/mailman/listinfo/ietf-dkim>, <mailto:ietf-dkim-request@mipassoc.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0002059611=="
Sender: ietf-dkim-bounces@mipassoc.org
Errors-To: ietf-dkim-bounces@mipassoc.org

Does it makes sense for the DMARC policy to not only set policy and report
on DKIM and SPF but also how the client authenticates via TLS?

As it stands today, many companies are setting up independent TLS
connections between peers to accommodate the various PII laws that require
encryption of data in transit, and there is no central location to place
policy.

The DKIM RFC describes how some deployments may have a DKIM selector per
user to accommodate traveling laptops (or something to that effect).  If we
were to include TLS certificate information in a policy, that could allow
SPF to be just as portable.    And keeping in the spirit of DMARC, no PKI
is needed if the implementation used certificates in DNS (TLSA)
http://tools.ietf.org/html/draft-ietf-dane-protocol-23

I've seen a few posts that talk about MUAs displaying DMARC-verified
messages with a golden key illustrating it's sent secure.  I understand
that MUAs are out of scope for the DMARC spec, but I want to mention that
feature will be confusing to my end users and customers as it stands today.
 I'm in the financial vertical and work with HIPPA data and other
material relevant to advisory services,benefits, life insurance.  As a
result we are required to encrypt all data in transport.

In fact, I've worked with representatives from DMARC's sponsors (Bank of
America, and Fidelity among others) to set up Enforced TLS between our
companies (NFP).  The reason for this was to increase security in lieu of a
portal-based-encryption such as Voltage or Zixmail.  Many of our end users
and customers noticed how the contents of the message changed and they
aren't requiring a login to a separate website for PII data.  They thought
TLS made the contents insecure in transit, when this isn't the case.

So what are your thoughts?  Should DMARC also incorporate some level of TLS
encryption policy and reporting, especially considering the outcome of the
policy will be reflected in the MUA? Should something else be created such
as DMARC-TLS?

It makes sense to bring this up here and now because the right MTA
developers are addressing message authentication via DNS policy, and TLS is
used for message authentication when the subject name is trusted and
aligned with RFC5322.From.

Thanks for your consideration,

Chris Lamont Mankowski
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html