Re: dane-openpgp 2nd LC resolution

Stephen Farrell <stephen.farrell@cs.tcd.ie> Tue, 08 March 2016 17:09 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F12E12D8B0 for <ietf@ietfa.amsl.com>; Tue, 8 Mar 2016 09:09:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Level:
X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Q3TUIvsQTe6 for <ietf@ietfa.amsl.com>; Tue, 8 Mar 2016 09:09:10 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0C1112D89F for <ietf@ietf.org>; Tue, 8 Mar 2016 09:08:33 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B15D4BE54 for <ietf@ietf.org>; Tue, 8 Mar 2016 17:08:32 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 67pn06ncto8I for <ietf@ietf.org>; Tue, 8 Mar 2016 17:08:26 +0000 (GMT)
Received: from [10.87.49.100] (unknown [86.46.19.12]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id EE078BE33 for <ietf@ietf.org>; Tue, 8 Mar 2016 17:08:25 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1457456906; bh=obzWpT2sD/za1lySz3EIHJUoBDqTJphHFJh8JNw/x7Q=; h=Subject:To:References:From:Date:In-Reply-To:From; b=YuZhero81xlPrSiipfWDeipe9CbHGkubv66u2Nu9kd/uEB6PPqMUOtlE0eUET3RFx uJAp1IPTkagnN/NB5MpjRsTrV4ZdZMkqkQodal1b1VqSlqhVyhVQ3D2LDho6q79eQ7 /iH9yQbm78X3AolziinUxAVRTsJPHEf2Xd1UMU4c=
Subject: Re: dane-openpgp 2nd LC resolution
To: IETF-Discussion <ietf@ietf.org>
References: <56DC484F.7010607@cs.tcd.ie>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <56DF0709.6060901@cs.tcd.ie>
Date: Tue, 8 Mar 2016 17:08:25 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <56DC484F.7010607@cs.tcd.ie>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000402080809080607090601"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/zp2df3rvJZ3lJsYYawtRuIPyJy4>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
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: Tue, 08 Mar 2016 17:09:23 -0000

Hiya,

On 06/03/16 15:10, Stephen Farrell wrote:
> 
> Hi all,
> 
> The 2nd IETF last call for this started on Feb 8th.
> Thanks again for the lively discussion.
> 
> The tl;dr version is: once a revision addresses the
> substantive issues raised as per below, taking into
> account reactions to this summary, and we have a chance to
> take a quick look at -08 (I'll extend the LC to the date
> of the -08 version plus one week), then if no new
> substantive issues arise, I think we have rough consensus
> to go forward with this experiment (and others to come)
> and let the IESG review the document.

Paul has now posted -08 (diff at [1]) so this mail is
to extend the IETF LC until March 15th.

Thanks,
S.

[1] https://www.ietf.org/rfcdiff?url2=draft-ietf-dane-openpgpkey-08

> 
> Cheers,
> S.
> 
> The substantive issues that arose in the 2nd last call
> were:
> 
> 1. The context of the experiment
> 2. Changes to the trust model
> 3. The local-part (lhs) issue and i18n
> 
> For each, I'll say where I conclude we've ended up and
> recommend what to do for -08.
> 
> 1. The context of the experiment
> --------------------------------
> 
> I think part of the reason this one has been hard has been
> a perception that we're developing the one true way to
> retrieve key retrieval for e2e email security.  The
> resolution here is to include text like that below in all
> similar experiments.
> 
> "This specification is one experiment in improving access
> to public keys for end-to-end email security. There are a
> range of ways in which this can reasonably be done, for
> OpenPGP or S/MIME, for example using the DNS, or SMTP, or
> HTTP.  Proposals for each of these have been made with
> various levels of support in terms of implementation and
> deployment.  For each such experiment, specifications such
> as this will enable experiments to be carried out that may
> succeed or that may uncover technical or other impediments
> to large- or small-scale deployments. The IETF encourages
> those implementing and deploying such experiments to
> publicly document their experiences so that future
> specifications in this space can benefit."
> 
> 2. Changes to trust model
> -------------------------
> 
> John Levine noted a place where -07 seems to be saying a
> bit too much:
> 
> " In sections 1 and 7, it claims that finding a key
> through DNS lookup is not a substitute for web-of-trust
> verification, which is fine.  But section 5.2 says that if
> a domain publishes a key for an address that's
> inconsistent with an existing key, verification of the key
> is "treated as a failure."  It's unclear what the effect
> is supposed to be, but considering the discussion of the
> lost key problem, it appears that the intent is that the
> sender would stop using the old key. "
> 
> I think the text is 5.2 is a little ambiguous so suggest
> the change below, which clarifies that the failure is
> in the confirmation step and that the resulting action
> is dependent on local policy and is not being determined
> by taking part in the experiment.
> 
> OLD:
> 
> Locally stored OpenPGP public keys are not automatically
> refreshed.  If the owner of that key creates a new OpenPGP
> public key, that owner is unable to securely notify all
> users and applications that have its old OpenPGP public
> key.  Applications and users can perform an OPENPGPKEY
> lookup to confirm the locally stored OpenPGP public key is
> still the correct key to use.  If the locally stored
> OpenPGP public key is different from the DNSSEC validated
> OpenPGP public key currently published in DNS, the
> verification MUST be treated as a failure unless the
> locally stored OpenPGP key signed the newly published
> OpenPGP public key found in DNS.  An application that can
> interact with the user MAY ask the user for guidance.  For
> privacy reasons, an application MUST NOT attempt to lookup
> an OpenPGP key from DNSSEC at every use of that key.
> 
> NEW:
> 
> Locally stored OpenPGP public keys are not automatically
> refreshed.  If the owner of that key creates a new OpenPGP
> public key, that owner is unable to securely notify all
> users and applications that have its old OpenPGP public
> key.  Applications and users can perform an OPENPGPKEY
> lookup to confirm the locally stored OpenPGP public key is
> still the correct key to use.  If the locally stored
> OpenPGP public key is different from the DNSSEC validated
> OpenPGP public key currently published in DNS, the
> confirmation MUST be treated as a failure unless the
> locally stored OpenPGP key signed the newly published
> OpenPGP public key found in DNS.  An application that can
> interact with the user MAY ask the user for guidance,
> otherwise the application will have to apply local policy.
> For privacy reasons, an application MUST NOT attempt to
> lookup an OpenPGP key from DNSSEC at every use of that
> key.
> 
> 3. The local-part (lhs) issue and i18n
> ---------------------------------------
> 
> This has always been and will always be an issue for any
> solution in this space. Absent changes to the mail
> architecture, or major changes to email protocols and
> deployment, it will always be an issue. And it's quite
> related to the  "joe+ietf" kind of lhs too, which'd need
> to be considered for a general solution to the problem.  I
> conclude that the right thing here is to do experiments,
> but for those to not try to solve the general issue, and
> instead to define the limits within which the experiment
> is to be done. In this case, I think the only tractable
> thing is stick with the lhs handling in -07, to note that
> implementations are in fact not quite doing that, and to
> point to an existing well-thought out description of some
> some of the issues. To that end I suggest renaming section
> 4 to become "Email address variants and
> internationalisaion considerations." and adding the
> following NEW text to the end of the section:
> 
> "Section 3 above defines how the local-part is used to
> determine the location in which one looks for an
> OPENPGPKEY record. Given the variety of local-parts seen
> in email, designing a good experiment for this is difficult
> as: a) some current implementations are known to lowercase
> at least US-ASCII local-parts, b) we know from (many)
> other situations that any strategy based on guessing and
> making multiple DNS queries is not going to achieve
> consensus for good reasons,  and c) the underlying issues
> are just hard - see Section 10.1 of RFC 6530 for
> discussion of just some of the issues that would need to
> be tackled to fully address this problem.
> 
> However, while this specification is not the place to try
> to address these issues with local-parts, doing so is also
> not required to determine the outcome of this experiment.
> If this experiment succeeds then further work on email
> addresses with non-ASCII local-parts will be needed and
> that would be better based on the findings from this
> experiment, rather than doing nothing or starting this
> experiment based on a speculative approach to what is a
> very complex topic."
> 
> 
> Misc comments
> -------------
> 
> - There were also a bunch of nits noted in [1] that we
> may as well fix in -08.
> 
> [1] https://mailarchive.ietf.org/arch/msg/ietf/7qqmoghCO_BfAt3YdRn81chn5Mc
> 
> 
>