IETF Logo Mail Archive

Re: [dmarc-ietf] Email security beyond DMARC?

Grant Taylor <gtaylor@tnetconsulting.net> Wed, 20 March 2019 14:47 UTC

Return-Path: <gtaylor@tnetconsulting.net>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E14011279A8 for <dmarc@ietfa.amsl.com>; Wed, 20 Mar 2019 07:47:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tnetconsulting.net
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 nrnaVv-yqw8P for <dmarc@ietfa.amsl.com>; Wed, 20 Mar 2019 07:47:27 -0700 (PDT)
Received: from tncsrv06.tnetconsulting.net (tncsrv06.tnetconsulting.net [IPv6:2600:3c00:e000:1e9::8849]) (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 CB6D0127988 for <dmarc@ietf.org>; Wed, 20 Mar 2019 07:47:27 -0700 (PDT)
Received: from Contact-TNet-Consulting-Abuse-for-assistance by tncsrv06.tnetconsulting.net (8.15.2/8.15.2/Debian-3) with ESMTPSA id x2KElP2c019340 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for <dmarc@ietf.org>; Wed, 20 Mar 2019 09:47:27 -0500
ARC-Filter: OpenARC Filter v0.1.0 tncsrv06.tnetconsulting.net x2KElP2c019340
Authentication-Results: tncsrv06.tnetconsulting.net; arc=none header.d=tnetconsulting.net
ARC-Seal: i=1; a=rsa-sha256; d=tnetconsulting.net; s=2015; t=1553093247; cv=none; b=k7yHh6B645sLsaWCZBC3UKyOnIJiFBd71oNwbyd2MjqLj57Y6qxm5IbllEChvtj9Ajw8YRCOZ5efX5pwY4Be7SULYX+LGHQJx3i1yVOxEcpJxLAOc+ARifVA8DmhQikU8zSY/bUqPc7yqBoBq98pIIZcw3cDXWySiopXfgFSo30=
ARC-Message-Signature: i=1; a=rsa-sha256; d=tnetconsulting.net; s=2015; t=1553093247; c=relaxed/simple; bh=0oFxzpw3M18wRCUuG3PlLAaV4e2crjtcpSlAB/i6l34=; h=DKIM-Signature:Subject:To:From:Message-ID:Date:User-Agent: MIME-Version:Content-Type; b=NEjJPArBX75YRA5QiaU7LTkna50WNCXuDrnBiRh0lF3pfP0IL/WUZlsZ8/I4tUWZXd7CJc1fUu3gH2bggBnn82cWL3xNSUUkEp0XvJopEKD2Zb8eyqMzZ4APktTh3WKkXTq1P9A7Ha2CQrmdnCKk418KqSXDh6x59lmBAr866dA=
ARC-Authentication-Results: i=1; tncsrv06.tnetconsulting.net; none
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=tnetconsulting.net; s=2019; t=1553093247; bh=0oFxzpw3M18wRCUuG3PlLAaV4e2crjtcpSlAB/i6l34=; h=Subject:To:References:From:Message-ID:Date:User-Agent: MIME-Version:In-Reply-To:Content-Type:Cc:Content-Disposition: Content-Language:Content-Transfer-Encoding:Content-Type:Date:From: In-Reply-To:Message-ID:MIME-Version:References:Reply-To: Resent-Date:Resent-From:Resent-To:Resent-Cc:Sender:Subject:To: User-Agent; b=KdUj0bshUdDyO9sTGsL7exHTb+QUQWLMy5phSllSZ70uTyAl42CXFsBTp3JDGIsA6 X8IHY09unPQ+dOjSMT3qFFzjlXLiHmAj1GhNounoBgZ6pScf9gICJ8GCZpIZia6wvR PvsDCLeqQ9U0BiZ7JVbpPVc/hI7OFepT4XlQbeuo=
To: dmarc@ietf.org
References: <1dc451a973a8443a87d37b6e5c41fe38@bayviewphysicians.com> <alpine.DEB.2.20.1903181355520.5419@softronics.hoeneisen.ch> <90b936ec488f41108bc4e528eb7933f6@PEXC01.upu.ch> <002a01d4de81$18ac27b0$4a047710$@bayviewphysicians.com> <alpine.DEB.2.20.1903191935400.4731@softronics.hoeneisen.ch> <8e26770d45b14816b3a5b9da33acf83a@PEXC01.upu.ch> <alpine.DEB.2.20.1903201505510.7108@softronics.hoeneisen.ch> <98e1d7e3-625e-ac9c-fd13-f25b5c380e3f@gmail.com>
From: Grant Taylor <gtaylor@tnetconsulting.net>
Organization: TNet Consulting
Message-ID: <227ea49c-c397-be6f-976e-929909d40d78@spamtrap.tnetconsulting.net>
Date: Wed, 20 Mar 2019 08:47:24 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: <98e1d7e3-625e-ac9c-fd13-f25b5c380e3f@gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms090705040002030603070705"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/BTEgeBGwdajRThTYR7H9o43OVLg>
Subject: Re: [dmarc-ietf] Email security beyond DMARC?
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Mar 2019 14:47:30 -0000

On 3/20/19 8:25 AM, Dave Crocker wrote:
> well, mime uses IANA for registering types, and that's certainly a 
> centralized operation...

True.

However there is a distinct difference in a central numbering authority 
verses a central certificate authority.  The former has little impact on 
system security (presuming that everyone agrees / uses the same value 
for things) compared to the latter, which has significant impact on 
security.

We can also operate without said central numbering authority if we all 
agree that specific things are specific values.  We can't (effectively) 
operate without central certificate authorities.  At least not given our 
current operating model at the scale that we operate ate.



-- 
Grant. . . .
unix || die

v2.23.0 | Report a Bug | By Email