Re: Case distinctions as theoretical exercise
Doug Barton <dougb@dougbarton.us> Mon, 14 March 2016 01:47 UTC
Return-Path: <dougb@dougbarton.us>
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 8517212DA0C for <ietf@ietfa.amsl.com>; Sun, 13 Mar 2016 18:47:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.003
X-Spam-Level:
X-Spam-Status: No, score=-2.003 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, SPF_HELO_PASS=-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=dougbarton.us
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 HJvJLcXePuHn for <ietf@ietfa.amsl.com>; Sun, 13 Mar 2016 18:47:18 -0700 (PDT)
Received: from dougbarton.us (dougbarton.us [208.79.90.218]) (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 CB85812D6D8 for <ietf@ietf.org>; Sun, 13 Mar 2016 18:47:18 -0700 (PDT)
Received: from [IPv6:2001:4830:1a00:8056:e0ab:e13a:62e3:f2b0] (unknown [IPv6:2001:4830:1a00:8056:e0ab:e13a:62e3:f2b0]) by dougbarton.us (Postfix) with ESMTPSA id E64D53A0BD; Mon, 14 Mar 2016 01:47:17 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dkim; t=1457920038; bh=LbiunAW1jMxaSmLsfCUT99j6F2AMsA0Up1LTXHO/AV8=; h=Subject:To:References:Cc:From:Date:In-Reply-To; b=GLR7Ez5BvgNtfHXF7dlV6Z3a+/mI552EPV24/uFPQz1OnNprk45WIvSxEwBbU9Noq 7NvGIY9M0y6NnOfYfYOI5y+l0+tTFA9DRtazehVmBOIo454b3GTagfwSulnnyMF2AW 0g49N4TlcluW7bKsw5NqWfeHLGK/zSjAqo+o3FrE=
Subject: Re: Case distinctions as theoretical exercise
To: John C Klensin <john-ietf@jck.com>, Paul Wouters <paul@nohats.ca>
References: <56DC484F.7010607@cs.tcd.ie> <3470AB158222ED0ECAF2CAEA@JcK-HP8200.jck.com> <56E478F7.5070907@dougbarton.us> <44A260C9DBCF278440C93C0B@JcK-HP5.jck.com>
From: Doug Barton <dougb@dougbarton.us>
Openpgp: id=E3520E149D053533C33A67DB5CC686F11A1ABC84
Message-ID: <56E61823.3070300@dougbarton.us>
Date: Sun, 13 Mar 2016 18:47:15 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <44A260C9DBCF278440C93C0B@JcK-HP5.jck.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/QTsdyimajCHKvhcnk3geOI61EnE>
Cc: ietf@ietf.org
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: Mon, 14 Mar 2016 01:47:20 -0000
Thanks for the response John, more below. On 03/13/2016 08:10 AM, John C Klensin wrote: > Paul, Doug, > > I want to respond to two issues/questions only right now and am > going to do so in two separate messages. Perhaps someone else > will get to the other questions before I do -- I think they have > been answered and explained several times already. This is > therefore message 1 of 2. > > I don't know why we (that "email community") and you (Paul) are > having so much trouble communicating, but Having read a bunch of the DANE archives today it does seem that there is a problem in communication, but honestly it doesn't seem all that one-sided. :) > --On Saturday, March 12, 2016 4:09 PM -0500 Paul Wouters > <paul@nohats.ca> wrote: > >> ... >> However, the email community experts themselves have already >> stated that finding an email server compliant to case 2 is a >> theoretical exercise only. > > I can't speak for others, but I certainly didn't say that. > > The specs (and generally-accepted good practice) recommend using > prohibition, aliasing (of some flavor), or other mechanisms to > avoid making subtle distinctions in addresses that are likely to > be confusing to users and/or to stress expectations about human > memory and precision beyond reasonable limits. I would > certainly recommend that a final delivery system not provide a > mailbox named pauL@example.com to a different recipient than a > mailbox named paul@example.com. I am agnostic about whether > they should be the _same_ mailbox or associated with the same > key: some recipient might plausibly use an obscure form of an > address as a mail classification tool or as part of a very cheap > sender-checking model. Such models, whether done that way or by > subaddresses or the like, are surprisingly effective against > casual bulk attacks even if much less so against focused and > determined ones. I'm perfectly willing to grant that some systems do this. Paul's hashing scheme accounts for this, and CNAMEs can be used to handle any aliases that are desired. Further, I think that many of the critics of the draft are ignoring the fact that in the overwhelming number of cases the sending user is going to have an example of the receiving user's e-mail address, the most likely case being that they are replying to a message they already have in their MUA. Thus it's overwhelmingly likely that the sending user will already have a representation of the receiving user's local part that the receiving user considers to be canonical, and thus is likely to have placed an OPENPGPKEY RR for. > The same thing could be said for other distinctions. For > example, joe.bloggs@example.com is a popular form for a > local-part and has been used on some systems for years. IIR, > there is even a standards-track spec that recommends it. I > would certainly not suggest that a system that uses that form > for local-parts also support separate mailboxes, assigned to > separate recipients, named like "joebloggs@example.com". > Whether is it better to not support the latter at all, to make > it an alias for the joe.bloggs@example.com form, or to > algorithmically remove the special characters(s), possibly also > making joe+bloggs@example.com point to the same mailbox, is a > matter of taste: the specs are (deliberately) mute on the > subject. Agreed, see above. [snip] > Now, having said all of that, I want to note that this has > little or nothing to do with the protocol requirements of > draft-ietf-dane-openpgpkey-08. At least as I read it, that I-D > simply applies a hash function to the mailbox name as given and > does not attempt to find "equivalent" or "canonical" names. > That means that the very worse case is a false negative about > finding a key. You want to experiment with that, fine -- I > won't lose any sleep over it. Good to hear! :) > I do believe that, if that is the > protocol spec, there is a lot of surplus and confusing text in > the I-D that should just come out. FWIW, I agree that the draft in its current state needs some tightening, as it seems to have some leftover tidbits from previous versions. I also think that the approach suggested is wrong, and would like to see a parallel approach codified (which I will comment on further in another message). Doug
- dane-openpgp 2nd LC resolution Stephen Farrell
- Re: dane-openpgp 2nd LC resolution E Taylor
- Re: dane-openpgp 2nd LC resolution Stephen Farrell
- Re: dane-openpgp 2nd LC resolution John C Klensin
- Re: dane-openpgp 2nd LC resolution John C Klensin
- Re: dane-openpgp 2nd LC resolution Doug Barton
- Re: dane-openpgp 2nd LC resolution Paul Wouters
- Treat model (was: Re: dane-openpgp 2nd LC resolut… John C Klensin
- Case distinctions as theoretical exercise (was: R… John C Klensin
- Re: dane-openpgp 2nd LC resolution Viktor Dukhovni
- Re: dane-openpgp 2nd LC resolution John Levine
- Re: dane-openpgp 2nd LC resolution Paul Wouters
- Re: dane-openpgp 2nd LC resolution Paul Wouters
- Re: dane-openpgp 2nd LC resolution Doug Barton
- Re: Case distinctions as theoretical exercise Doug Barton
- Re: Threat model Doug Barton
- Re: dane-openpgp 2nd LC resolution Doug Barton
- Re: Case distinctions as theoretical exercise John C Klensin
- Re: dane-openpgp 2nd LC resolution John R Levine
- Re: dane-openpgp 2nd LC resolution John C Klensin
- Re: dane-openpgp 2nd LC resolution Doug Barton
- Re: dane-openpgp 2nd LC resolution Viktor Dukhovni
- Re: dane-openpgp 2nd LC resolution Paul Wouters
- Re: dane-openpgp 2nd LC resolution Paul Wouters
- Re: dane-openpgp 2nd LC resolution Doug Barton
- Re: dane-openpgp 2nd LC resolution Viktor Dukhovni
- Re: dane-openpgp 2nd LC resolution Mark Andrews
- Re: dane-openpgp 2nd LC resolution Warren Kumari
- Re: Case distinctions as theoretical exercise Phillip Hallam-Baker
- Re: Case distinctions as theoretical exercise John Levine
- Re: Case distinctions as theoretical exercise Phillip Hallam-Baker
- Re: dane-openpgp 2nd LC resolution Stephen Farrell
- Re: dane-openpgp 2nd LC resolution John C Klensin
- Hashing local-parts of addresses (was: dane-openp… ned+ietf