IETF Logo Mail Archive

Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt>

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 18 February 2016 03:38 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17F8F1ACD02 for <ietf@ietfa.amsl.com>; Wed, 17 Feb 2016 19:38:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
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 u7YsQ25_uXkO for <ietf@ietfa.amsl.com>; Wed, 17 Feb 2016 19:38:11 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D85E1B29EC for <ietf@ietf.org>; Wed, 17 Feb 2016 19:38:10 -0800 (PST)
Received: from [172.31.24.203] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id E9A01282C3D for <ietf@ietf.org>; Thu, 18 Feb 2016 03:38:09 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
Subject: Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt>
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <alpine.LFD.2.20.1602172221020.27439@bofh.nohats.ca>
Date: Wed, 17 Feb 2016 22:38:08 -0500
Content-Transfer-Encoding: 7bit
Message-Id: <19DDAD6C-B997-48C3-83E5-A61E27D97B6A@dukhovni.org>
References: <20160216224341.4620.qmail@ary.lan> <alpine.LFD.2.20.1602172221020.27439@bofh.nohats.ca>
To: ietf@ietf.org
X-Mailer: Apple Mail (2.3112)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/OBniiQuiLGP4S5-lmNaL6Mqb8w8>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: ietf@ietf.org
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Feb 2016 03:38:13 -0000

> On Feb 17, 2016, at 10:24 PM, Paul Wouters <paul@nohats.ca> wrote:
> 
> So if my ISP is blocking port 25, I am forced to ask my ISP if the
> remote party could accept encrypted email and to which key?

[ That's only if your ISP is your submission server, in which case
they're also likely operating the zone that would public your
public keys, and you're likely vulnerable to a variety of attacks
via that ISP.  Since faking the keys of remote parties is likely
tamper-evident, and such faking can also happen by who-ever is
publishing the zone data on the other end, I think this is a
reasonable architecture, but we digress... ]

The addrquery draft is not under discussion here, so perhaps I
should not even have said that much.  Exploring additional
approaches seems reasonable.

-- 
	Viktor.

v2.23.0 | Report a Bug | By Email