[secdir] Secdir review of draft-ietf-appsawg-email-auth-codes

Paul Wouters <paul@nohats.ca> Fri, 01 August 2014 15:28 UTC

Return-Path: <paul@nohats.ca>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 3A8E11B27E0; Fri, 1 Aug 2014 08:28:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id BndyBWsPWB8W; Fri, 1 Aug 2014 08:28:21 -0700 (PDT)
Received: from bofh.nohats.ca (bofh.nohats.ca []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A1BC1B27C3; Fri, 1 Aug 2014 08:28:20 -0700 (PDT)
Received: from bofh.nohats.ca (bofh.nohats.ca []) by bofh.nohats.ca (Postfix) with ESMTP id 6759080048; Fri, 1 Aug 2014 11:28:19 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1406906899; bh=Si5wuKVpAfgaG+j9z7QMexAKp0IcKThdKb4rcYIro+o=; h=Date:From:To:Subject; b=ZN1+2kk8v0FhX+6o1ZPaV/Hnp+G3BQwyiw+yekaGYNFHHCWrjcbNTKyLihFx5eGZg ZYJnZIBYnsU5mWmLdWypNO0I8MWQw7Z0NJn4Lr8qHJter9Hypssj9D4uzP2EWN8BZ9 izF3bQIuySfhBsMKRhPLeQ+7LRNR9xMgT6tNCrGo=
Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s71FSIkm014474; Fri, 1 Aug 2014 11:28:18 -0400
X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs
Date: Fri, 01 Aug 2014 11:28:18 -0400
From: Paul Wouters <paul@nohats.ca>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-appsawg-email-auth-codes.all@tools.ietf.org
Message-ID: <alpine.LFD.2.10.1408011106270.29758@bofh.nohats.ca>
User-Agent: Alpine 2.10 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format="flowed"; charset="US-ASCII"
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/nvRsndAkVI48vmIL1YSlm1WCGD4
Subject: [secdir] Secdir review of draft-ietf-appsawg-email-auth-codes
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: <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: Fri, 01 Aug 2014 15:28:24 -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 proposes to add additional entries to the "SMTP Enhanced
Status Codes Registry", specifically related to DKIM, SPF and Reverse
DNS checks, to assist operators and endusers in determining why their
email message was rejected.

The document looks good and has a proper security consideration section.

I do have one question with respect to the temporary failure codes.

For SPF Failure Codes, a distinction is made between an SPF validation
failure (X.7.22) and an SPF validation error (X.7.23).

A failure is the result of a successful (SPF) check method to mark the
email message as failed. An error means the (SPF) method to check for
failure did not run successfully and it could not determine whether the
message should pass or fail. For example, an error in the (SPF) check
could be due to a temporary DNS problem.

For the DKIM and Reverse DNS, which like SPF depends on a working DNS
resolver for the mail server, there is no such split made. These can
only return failures, not errors in determining success or failure.

If there is value in indicating this distinction for SPF, I would assume
the same distinction would be useful for DKIM and Reverse DNS. If there
are good reasons not to do this, perhaps it would be good to explain
those reasons in the document along with some advise for implementors
on what (existing) extended message code to return in the case of
temporary DNS failures in the DKIM and Reverse DNS case.