Re: Case distinctions as theoretical exercise
John C Klensin <john-ietf@jck.com> Mon, 14 March 2016 13:47 UTC
Return-Path: <john-ietf@jck.com>
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 C53C312D5A2 for <ietf@ietfa.amsl.com>; Mon, 14 Mar 2016 06:47:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
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 BxS9sh56gjCu for <ietf@ietfa.amsl.com>; Mon, 14 Mar 2016 06:47:23 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E37B412D518 for <ietf@ietf.org>; Mon, 14 Mar 2016 06:47:22 -0700 (PDT)
Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1afSq5-0007y8-C8; Mon, 14 Mar 2016 09:47:17 -0400
Date: Mon, 14 Mar 2016 09:47:12 -0400
From: John C Klensin <john-ietf@jck.com>
To: Doug Barton <dougb@dougbarton.us>, Paul Wouters <paul@nohats.ca>
Subject: Re: Case distinctions as theoretical exercise
Message-ID: <50BC741FF81359B1655E9AD6@JcK-HP8200.jck.com>
In-Reply-To: <56E61823.3070300@dougbarton.us>
References: <56DC484F.7010607@cs.tcd.ie> <3470AB158222ED0ECAF2CAEA@JcK-HP8200.jck.com> <56E478F7.5070907@dougbarton.us> <44A260C9DBCF278440C93C0B@JcK-HP5.jck.com> <56E61823.3070300@dougbarton.us>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/htkoASKDIvCtzbTRKozWFNfb_MY>
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 13:47:25 -0000
--On Sunday, March 13, 2016 18:47 -0700 Doug Barton <dougb@dougbarton.us> wrote: >... > On 03/13/2016 08:10 AM, John C Klensin wrote: >... >> 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. :) I didn't claim that it was. While, IMO, it shouldn't be an excuse for this many communication problems, the two communities rather clearly have different priorities about what is important. Until and unless we can somehow rise about protocol details to engage about those priorities and figure out how to figure out the tradeoffs between them, we aren't going to make much progress. I don't speak for the rest of the "email community" but my highest priority is "don't break things that are implemented, widely deployed, and at least reasonable satisfactory to many millions of users". Some of the arguments for doing what the draft proposes seem to me to be rather close to "encryption whenever possible is so important that, if fewer messages get through or other damage occurs, that is ok". Certainly not all of them, of course. >... > 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. I don't see how the hashing scheme accounts for it without at least some address canonicalization, which the I-D does not specify. > 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. At one level, certainly yes although I'm not sure about "overwhelmingly". FWKW, we have had email systems that, because few people could get the rather complex address formats right, essentially required that one either have a message to reply to or a correct directory entry in order to send a message. It didn't work out well; opinions differ as to how much of the problem was the absence of a working universal email address directory. >... >> 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). Ack. I look forward to that message with the understanding that there are a number of parallel approaches floating around (I don't believe Keith's promised proposal has been posted, btw) and that Stephen's position seems to be that we should just push them all out as experiments. john
- 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