From nobody Tue Mar 1 12:37:13 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A3A51B4169 for ; Tue, 1 Mar 2016 12:37:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.096 X-Spam-Level: X-Spam-Status: No, score=-99.096 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_DBL_ABUSE_REDIR=0.001, USER_IN_WHITELIST=-100] autolearn=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 M_4Q3PXmVKPx for ; Tue, 1 Mar 2016 12:37:09 -0800 (PST) Received: from nx-mailgw.apnic.net (nx-mailgw.apnic.net [IPv6:2001:dd8:9:801::25]) (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 D95511B3B0F for ; Tue, 1 Mar 2016 12:37:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=R2D2; h=received:received:content-type:mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer:return-path; bh=JzzcZIFBpi874SLzKMYtWZ0g/Ywy5L4w1OSRjuQQe5c=; b=VtZ14VxNdFctRavRunRhSZadlV3KFW1h8AbjfwNGGRoSbp6bU7D7rsEt+Z4Kv29Z71i5wtxMW5/t8 jnrruTPlpboP4cHK9wu2+GOCmRfoaVn0ROmZEFG3EudMrUjUsoHO9exC0zhcW3xR/DBYYqhGwO2ob9 tsLToWeM5YE71X7U= Received: from iamda3.org.apnic.net (unknown [IPv6:2001:dd8:9:2::101:249]) by nx-mailgw.apnic.net (Halon Mail Gateway) with ESMTPS; Wed, 2 Mar 2016 06:40:27 +1000 (AEST) Received: from dhcp150.potaroo.net (203.119.101.249) by iamda3.org.apnic.net (203.119.111.31) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 2 Mar 2016 06:37:02 +1000 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Geoff Huston In-Reply-To: <56BF78AC.2080803@dcrocker.net> Date: Wed, 2 Mar 2016 07:37:02 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <569FC8C7.40303@gmail.com> <56B3770C.8020505@dcrocker.net> <201602051002.u15A2q0P017177@new.toad.com> <20160213014226.GP19242@mournblade.imrryr.org> <20160213043516.GQ19242@mournblade.imrryr.org> <91AC572E-B942-448F-BB17-BB31C5D13C89@frobbit.se> <56BF78AC.2080803@dcrocker.net> To: X-Mailer: Apple Mail (2.3112) Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Why shut down the DANE group? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 20:37:11 -0000 > On 14 Feb 2016, at 5:40 AM, Dave Crocker wrote: >=20 >=20 > On 2/13/2016 2:42 AM, Patrik F=E4ltstr=F6m wrote: >> On 13 Feb 2016, at 5:35, Viktor Dukhovni wrote: >>=20 >>> Yes, I understand that DNSSEC is at present and may indefinitely = remain too high a bar. >>=20 >> It is too high a bar just because this is repeated over and over = again. Not because it really is. >=20 >=20 > Please explain. The continuing lack of widespread adoption is only = due to what? The fact that people keep saying it's too hard? It would = be easy if only they would realize it? >=20 > When a market is glacially slow to adopt something, it does not help = much to blame the market. >=20 two graphs: http://bit.ly/1QJxNo0 http://bit.ly/1LHZRa3 These two graphs tell me that by the reasoning you are providing about = DNSSEC (=93glacially slow=94 adoption) IPv6 is a complete and total = waste of our collective time. Today we see some 1 in 6 users using DNS resolvers that will perform = DNSSEC validation in signed responses. 1 in 6. Thats some half a billion = users will validate DNSSEC signed responses - AND WILL NOT GO TO A BADLY = SIGNED NAME. By comparison, how=92s V6? 1 in 20 users will use IPv6.=20 I find it impossible to reconcile the mood of doom and depression = surrounding DNSSEC I read from this post and others in a similar vein, = while at the same time observing the sunny, and by this metric = completely insane, optimism of the IPv6 proponents.=20 Sometimes the lies we tell ourselves just get in the way. This is one = such case.=20 regards, Geoff From nobody Tue Mar 1 12:54:39 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC65B1B41A0 for ; Tue, 1 Mar 2016 12:54:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.957 X-Spam-Level: X-Spam-Status: No, score=-1.957 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] 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 FY9g0XRF_3dk for ; Tue, 1 Mar 2016 12:54:37 -0800 (PST) Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26B871B4199 for ; Tue, 1 Mar 2016 12:54:37 -0800 (PST) Received: from [192.168.1.147] (frobbit.cust.teleservice.net [85.30.128.225]) by mail.frobbit.se (Postfix) with ESMTPSA id 93B7F214BE; Tue, 1 Mar 2016 21:54:35 +0100 (CET) From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" To: "Geoff Huston" Date: Tue, 01 Mar 2016 21:54:34 +0100 Message-ID: <0CE3111E-04A2-4764-B499-B1E68934C390@frobbit.se> In-Reply-To: References: <569FC8C7.40303@gmail.com> <56B3770C.8020505@dcrocker.net> <201602051002.u15A2q0P017177@new.toad.com> <20160213014226.GP19242@mournblade.imrryr.org> <20160213043516.GQ19242@mournblade.imrryr.org> <91AC572E-B942-448F-BB17-BB31C5D13C89@frobbit.se> <56BF78AC.2080803@dcrocker.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_AC7410B0-69F1-4FA5-8925-48A7562C060D_="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Mailer: MailMate (1.9.4r5226) Archived-At: Cc: dcrocker@bbiw.net, dane@ietf.org Subject: Re: [dane] Why shut down the DANE group? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 20:54:38 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_AC7410B0-69F1-4FA5-8925-48A7562C060D_= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On 1 Mar 2016, at 21:37, Geoff Huston wrote: > Sometimes the lies we tell ourselves just get in the way. This is one s= uch case. Yup! My view for DNSSEC: Will be deployed in the same speed as new DNS software will include DNSSE= C by default and it will be turned on by default. Further, as the validat= ion is done by the ISP, the end user is not involved. My view for IPv6: Each person/organization that is responsible for IP addressing will compl= etely ignore IPv6 (i.e. have it as priority number 7 in a list where only= the first three can be dealt with) until the day when suddenly there for= that person/organization is zero IPv4 addresses to use. I.e. we have for both IPv6 and DNSSEC passed the point where "normal" adv= ertisements help. Now the best help we get is by just adding time. Sure, we can still inform about both of the above, specifically the 2nd, = but will it help? Patrik --=_MailMate_AC7410B0-69F1-4FA5-8925-48A7562C060D_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlbWAYoACgkQrMabGguI181aPACfVLhlIJxQ9FAYpQRmZIRv39+7 e8IAn0IS6oIqfejURXbUNbfG3Q/Fnh8X =J0r2 -----END PGP SIGNATURE----- --=_MailMate_AC7410B0-69F1-4FA5-8925-48A7562C060D_=-- From nobody Tue Mar 1 13:26:22 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09D011B41A3 for ; Tue, 1 Mar 2016 13:26:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.977 X-Spam-Level: X-Spam-Status: No, score=-0.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] autolearn=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 ksVs1WV7xSj8 for ; Tue, 1 Mar 2016 13:26:19 -0800 (PST) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0985A1B3148 for ; Tue, 1 Mar 2016 13:26:18 -0800 (PST) Received: by mail-yw0-x22a.google.com with SMTP id u200so160579485ywf.0 for ; Tue, 01 Mar 2016 13:26:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aSp2Jfmooa/4iMp1ckKDZRGPNxOmufCA1+9DjVAY0uM=; b=rmcVdXXc99ENx5BcOKb7cctUlAqzKhIikUuBAeNwctpAe5pRF+EjId6sRyTtpx+KNw w8y27dF7XLowWH6e2yW8T6lHjlZF/U+GpdzAAdLD44dk0yr/2N77TsEcP2CuC7xywpKk uFSVR4AX8HbZqzpM/AO+yshZfIEd3sSBEa/CgxYGNqOQaxs4bvd5rkKTt6ZgEYzu56py aeQkFpgbOpYpRP7sCVP5kvh9JTHUmQ8NNn3VzEJOtjfdhe73G1iyms6ZT3yLRKP9Yicb eWBQ85T4TZmfv+t7ECNHoVGQm5GLUBuu5XdyPNtWc6oI5WNbZj/ioB4rpuACVA9Rkkft J8gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aSp2Jfmooa/4iMp1ckKDZRGPNxOmufCA1+9DjVAY0uM=; b=XAul37M7EhFBFP7t1zxbryxa5HqL8FalOs3vJr+RMJN3WftxA/KJEaPfjqZBtPeJoD Zz2WGrFMG70mhq5M9u7tFKCWMLzdWJece1Y0bN2QCxWVaA5hhcZMcqbvSmzEiZNMutul YFAmzCjh1M5tlz8zzMdkvSmhzYTj3C6bZk1FOd0SxFlinVEZZAu6GPCdCd8eK+HmvzPo xxh527haPmxvApiv1utG7oYYZFC1lhU8yRJe1aTX0mpZByMm6a+zgQY2lUKbG3KDdHtV U5f6SezpCJvoOjz1PXqn5rxlYehuOEhhXV7r6rviVhHHCWRg9iu5lgZUuiourHZIhSMg RFKw== X-Gm-Message-State: AD7BkJKY2C3nWuPcPechxYL2H0Z/KlrgbK3ij/QMeAFbW5QIPwMS4YBQFJ7q9jwBVwhPzHhVQI4SWqdechUAZHBE X-Received: by 10.129.107.87 with SMTP id g84mr1913853ywc.105.1456867578255; Tue, 01 Mar 2016 13:26:18 -0800 (PST) MIME-Version: 1.0 References: <569FC8C7.40303@gmail.com> <56B3770C.8020505@dcrocker.net> <201602051002.u15A2q0P017177@new.toad.com> <20160213014226.GP19242@mournblade.imrryr.org> <20160213043516.GQ19242@mournblade.imrryr.org> <91AC572E-B942-448F-BB17-BB31C5D13C89@frobbit.se> <56BF78AC.2080803@dcrocker.net> <0CE3111E-04A2-4764-B499-B1E68934C390@frobbit.se> In-Reply-To: <0CE3111E-04A2-4764-B499-B1E68934C390@frobbit.se> From: Warren Kumari Date: Tue, 01 Mar 2016 21:26:08 +0000 Message-ID: To: =?UTF-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= , Geoff Huston Content-Type: multipart/alternative; boundary=001a11473aac7ccaf4052d036a98 Archived-At: Cc: dcrocker@bbiw.net, dane@ietf.org Subject: Re: [dane] Why shut down the DANE group? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 21:26:21 -0000 --001a11473aac7ccaf4052d036a98 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Mar 1, 2016 at 3:54 PM Patrik F=C3=A4ltstr=C3=B6m = wrote: > On 1 Mar 2016, at 21:37, Geoff Huston wrote: > > > Sometimes the lies we tell ourselves just get in the way. This is one > such case. > > Yup! > > My view for DNSSEC: > > Will be deployed in the same speed as new DNS software will include DNSSE= C > by default and it will be turned on by default. Further, as the validatio= n > is done by the ISP, the end user is not involved. > Yup, but it is critical that we do not screw up the KSK roll -- otherwise the response is likely to disable validation and "once bitten, twice shy" W > > My view for IPv6: > > Each person/organization that is responsible for IP addressing will > completely ignore IPv6 (i.e. have it as priority number 7 in a list where > only the first three can be dealt with) until the day when suddenly there > for that person/organization is zero IPv4 addresses to use. > > > I.e. we have for both IPv6 and DNSSEC passed the point where "normal" > advertisements help. > > Now the best help we get is by just adding time. > > Sure, we can still inform about both of the above, specifically the 2nd, > but will it help? > > Patrik > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > --001a11473aac7ccaf4052d036a98 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue= , Mar 1, 2016 at 3:54 PM Patrik F=C3=A4ltstr=C3=B6m <paf@frobbit.se> wrote:
On 1 Mar 2016, at 21:37, Geoff Huston wrote:

> Sometimes the lies we tell ourselves just get in the way. This is one = such case.

Yup!

My view for DNSSEC:

Will be deployed in the same speed as new DNS software will include DNSSEC = by default and it will be turned on by default. Further, as the validation = is done by the ISP, the end user is not involved.

=
Yup, but it is critical that we do not screw up the KSK roll -- = otherwise the response is likely to disable validation and "once bitte= n, twice shy"

=C2=A0W

My view for IPv6:

Each person/organization that is responsible for IP addressing will complet= ely ignore IPv6 (i.e. have it as priority number 7 in a list where only the= first three can be dealt with) until the day when suddenly there for that = person/organization is zero IPv4 addresses to use.


I.e. we have for both IPv6 and DNSSEC passed the point where "normal&q= uot; advertisements help.

Now the best help we get is by just adding time.

Sure, we can still inform about both of the above, specifically the 2nd, bu= t will it help?

=C2=A0 =C2=A0Patrik
_______________________________________________
dane mailing list
dane@ietf.org
https://www.ietf.org/mailman/listinfo/dane
--001a11473aac7ccaf4052d036a98-- From nobody Tue Mar 1 16:24:48 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAC311B4407 for ; Tue, 1 Mar 2016 16:24:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.963 X-Spam-Level: *** X-Spam-Status: No, score=3.963 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, MANGLED_SPAM=2.3, SPF_PASS=-0.001] autolearn=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 FJxUTOoUVvlZ for ; Tue, 1 Mar 2016 16:24:45 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A32121B4405 for ; Tue, 1 Mar 2016 16:24:44 -0800 (PST) Received: (qmail 30006 invoked from network); 2 Mar 2016 00:24:43 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 2 Mar 2016 00:24:43 -0000 Date: 2 Mar 2016 00:24:21 -0000 Message-ID: <20160302002421.72294.qmail@ary.lan> From: "John Levine" To: dane@ietf.org In-Reply-To: <0CE3111E-04A2-4764-B499-B1E68934C390@frobbit.se> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dane] Why shut down the DANE group? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 00:24:46 -0000 >My view for DNSSEC: > >Will be deployed in the same speed as new DNS software will include DNSSEC by default and it will be turned on by default. >Further, as the validation is done by the ISP, the end user is not involved. I see it as a lot like IPv6 -- the fans claim it's great, just do it, while in the real world the tools are somewhere between half-hearted and unsuable and the benefits vague. As a concrete datapoint, I have about 250 signed zones on my DNS server. Half are usable with a DS record in the parent, all zones that I have registered for myself or as a registrar reseller. I've been able to install the ones I have because Tucows has a proprietary but documented reseller API that lets me do it automatically, not one at a time. I did one elsewhere (sp.am) by hand, just to see if it was possible. The other half are not usable with DNSSEC because there is no way for me to install the DS -- I'm running the DNS for domains other people have registered at other registrars, so those registrars won't talk to me. In theory I could walk my users through their various registrars' DNSSEC hoops; in reality life is too short. You might hope that after more than a decade we'd have gotten around to addressing basic configuration problems, but no. R's, John From nobody Tue Mar 1 21:46:48 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC8881ACD8F for ; Tue, 1 Mar 2016 21:46:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.957 X-Spam-Level: X-Spam-Status: No, score=-1.957 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] 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 o1jGhCnbx6iM for ; Tue, 1 Mar 2016 21:46:45 -0800 (PST) Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 262A01ACD7F for ; Tue, 1 Mar 2016 21:46:45 -0800 (PST) Received: from [192.168.1.147] (frobbit.cust.teleservice.net [85.30.128.225]) by mail.frobbit.se (Postfix) with ESMTPSA id 176901FDB4; Wed, 2 Mar 2016 06:46:42 +0100 (CET) From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" To: "John Levine" Date: Wed, 02 Mar 2016 06:46:38 +0100 Message-ID: <2379614E-6DAC-4687-AFBD-B735642A8DFC@frobbit.se> In-Reply-To: <20160302002421.72294.qmail@ary.lan> References: <20160302002421.72294.qmail@ary.lan> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_6058DA9A-977C-472F-9D0D-C9D87035A9E7_="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Mailer: MailMate (1.9.4r5226) Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Why shut down the DANE group? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 05:46:47 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_6058DA9A-977C-472F-9D0D-C9D87035A9E7_= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On 2 Mar 2016, at 1:24, John Levine wrote: > The other half are not usable with DNSSEC because there is no way for > me to install the DS -- I'm running the DNS for domains other people > have registered at other registrars, so those registrars won't talk to > me. =2E..and the people you talk with have not added you as a tech contact? > In theory I could walk my users through their various registrars' > DNSSEC hoops; in reality life is too short. Of course. But the registrars issue I, speaking as a registrar, will not be sorted o= ut before registries _also_ start to move to a harmonized management of D= NSSEC. Registrars make for example in Sweden about $1/domain name while t= he registry charge $10/domain. paf --=_MailMate_6058DA9A-977C-472F-9D0D-C9D87035A9E7_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlbWfj4ACgkQrMabGguI181SOQCfbsd7777j59cswLW+hSg+5DYU 9FkAn3ibhK5TF7kxz5WHLnB/11yWCsX3 =SgxT -----END PGP SIGNATURE----- --=_MailMate_6058DA9A-977C-472F-9D0D-C9D87035A9E7_=-- From nobody Wed Mar 2 07:20:24 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF9EC1A8872 for ; Wed, 2 Mar 2016 07:20:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.837 X-Spam-Level: X-Spam-Status: No, score=-0.837 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 qCC3Mxn5LOj3 for ; Wed, 2 Mar 2016 07:20:21 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D27701A8895 for ; Wed, 2 Mar 2016 07:20:16 -0800 (PST) Received: (qmail 42786 invoked from network); 2 Mar 2016 15:20:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=a71b.56d704af.k1603; bh=UtJHxSSS6lUUe0gE1ggX4hQ+L6+6qhO8y5eELn0ST5A=; b=Q596PDtJglf1I4i/pnKsLUDGImOrqLYT+0tLj+Xjtu9qvX3//kORVFozafMGg1VxF9E2JkJXdjcXBbZGaSI/0Dp5Ur+X+Z9jdGz6SiDdUNiP9kYnZ7UkdG39f9f3qXsZMccvpbfwqw43aI1SbZj+npLWCXFcrZiAYUUqoUjFKqQQS3uSVji2749Ovs7G2IUk+qQ66G+exrwl7fGfU5lnjkLju7Y574V5lwaXDKqKwMoK1nB7ppN+NZryHFbe9R38 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=a71b.56d704af.k1603; bh=UtJHxSSS6lUUe0gE1ggX4hQ+L6+6qhO8y5eELn0ST5A=; b=BfslnZKwzLYlla3SQ5Q4HJro7rejFCSllZK4gclXEEdtnzABMmPMcHwLXg9k3NTagrda832/tYxPU5jVZKCNtWVDEdwaUBQpfPTTeZLJ3lqrJHRbo2qbihlECBWHjIlINOfsUA5lyR5SudKKt09mmZFfVTt6tgbbtTHvcf4Eaq2apGsHFErhmqQOiIA9mHKEdmTGJIgZ1VSmegY9ZckoOQn3smjVzVqJ1BkodsYh3xQhUEKK86IrSLoSLvR3Ux0N Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 02 Mar 2016 15:20:15 -0000 Date: 2 Mar 2016 10:20:14 -0500 Message-ID: From: "John R Levine" To: "=?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?=" In-Reply-To: <2379614E-6DAC-4687-AFBD-B735642A8DFC@frobbit.se> References: <20160302002421.72294.qmail@ary.lan> <2379614E-6DAC-4687-AFBD-B735642A8DFC@frobbit.se> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Why shut down the DANE group? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 15:20:23 -0000 >> The other half are not usable with DNSSEC because there is no way for >> me to install the DS -- I'm running the DNS for domains other people >> have registered at other registrars, so those registrars won't talk to >> me. > > ...and the people you talk with have not added you as a tech contact? It doesn't matter -- I don't have the password to log into their registrar account. > But the registrars issue I, speaking as a registrar, will not be sorted out before registries _also_ start to move to a harmonized management of DNSSEC. Registrars make for example in Sweden about $1/domain name while the registry charge $10/domain. This isn't just an issue for registrants and registrars; it's a problem wherever the operator of one zone delegates a subzone to someone else with whom they don't have a side channel to exchange the signing key. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Wed Mar 2 07:27:00 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F167E1A8899 for ; Wed, 2 Mar 2016 07:26:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.257 X-Spam-Level: X-Spam-Status: No, score=-1.257 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=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 pyRuert6onQh for ; Wed, 2 Mar 2016 07:26:58 -0800 (PST) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAEB21A8888 for ; Wed, 2 Mar 2016 07:26:57 -0800 (PST) Received: from [172.20.10.3] (2.64.197.139.mobile.tre.se [2.64.197.139]) by mail.frobbit.se (Postfix) with ESMTPSA id 33C6C2000F; Wed, 2 Mar 2016 16:26:55 +0100 (CET) From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" To: "John R Levine" Date: Wed, 02 Mar 2016 16:26:54 +0100 Message-ID: <67FF63CC-FDEE-49A0-BDD0-631EA0C4D1CC@frobbit.se> In-Reply-To: References: <20160302002421.72294.qmail@ary.lan> <2379614E-6DAC-4687-AFBD-B735642A8DFC@frobbit.se> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_1FECE581-3AD3-4879-8485-81767989F8DB_="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Mailer: MailMate (1.9.4r5226) Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Why shut down the DANE group? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 15:26:59 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_1FECE581-3AD3-4879-8485-81767989F8DB_= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On 2 Mar 2016, at 16:20, John R Levine wrote: >>> The other half are not usable with DNSSEC because there is no way for= >>> me to install the DS -- I'm running the DNS for domains other people >>> have registered at other registrars, so those registrars won't talk t= o >>> me. >> >> ...and the people you talk with have not added you as a tech contact? > > It doesn't matter -- I don't have the password to log into their regist= rar account. Ok, my point was that a tech contact should have their own log in. It has= in the Frobbit system ;-) >> But the registrars issue I, speaking as a registrar, will not be sorte= d out before registries _also_ start to move to a harmonized management o= f DNSSEC. Registrars make for example in Sweden about $1/domain name whil= e the registry charge $10/domain. > > This isn't just an issue for registrants and registrars; it's a problem= wherever the operator of one zone delegates a subzone to someone else wi= th whom they don't have a side channel to exchange the signing key. 100% agree. But just to close this, I did not want to restart a discussion between th= e ones that are more optimistic and less optimistic about DNSSEC or IPv6.= I just wanted to say that I personally for DNSSEC think we will not get = forward movement faster than software get the features by default so that= one have to turn off things to not use it. For that to happen, yes, many= many things are still to be resolved. For example side channel for the D= S (which we have a suggestion on how to implement, by publication of the = key material in the zone itself). Glacier speed indeed... paf --=_MailMate_1FECE581-3AD3-4879-8485-81767989F8DB_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlbXBj4ACgkQrMabGguI183JlgCfdVKeCoGPm1a6hCBM1DQuN+YU 218AnA+7MbVvjbKsucZDkrvPyXRjhcoY =XWhc -----END PGP SIGNATURE----- --=_MailMate_1FECE581-3AD3-4879-8485-81767989F8DB_=-- From nobody Wed Mar 2 07:34:58 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4C11A88D4 for ; Wed, 2 Mar 2016 07:34:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.837 X-Spam-Level: X-Spam-Status: No, score=-0.837 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 LMDOT5KjfKQs for ; Wed, 2 Mar 2016 07:34:56 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35E791A88F1 for ; Wed, 2 Mar 2016 07:34:56 -0800 (PST) Received: (qmail 44962 invoked from network); 2 Mar 2016 15:34:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=afa1.56d7081f.k1603; bh=/lJz90y7F9Cb4+dwm6K0lb+BljJM8JS2iZ3rWRwUE2s=; b=il27usUyyZXBp9p10cTLe8hMjyA9QFq46zin8/Dj3JcR+rKhUoCmau425LxtEmIRhOoQpePiZ3ZKXq0u2F/dhXuX+zKmXLMOGHv050t+RbeRwsl92bJPXbOdZArXptaddlS2XqF0yCR7rgRoimdCyhcXEQ84lDQuw8dciUkFHW1azyvxHb1G2zEuV2C9U56reD+M/NlYGC/PvO3lYBibGgK/XBlwLyZTxYENrdzTupskVZTu3UcFRN2rKydPzf5d DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=afa1.56d7081f.k1603; bh=/lJz90y7F9Cb4+dwm6K0lb+BljJM8JS2iZ3rWRwUE2s=; b=N3tNLn095dmENXrMTayURRcgDgBMXmYXAGmSrodf5+jaNEhnNu6dH7zCZ7B4Wm8jPIvM1ejZGlIeFWY1ov8cOZRnpZJ5RXBQWfhrWKKbyuu3iDEMDRxhkQImVM/sZVosHvIpz5u1oFuUxSti4VfDnVyHKA6+QR7dUd2QBWv0k66na0L1FfgjrPIBuAXuLRpzFWKh2W8XE7S7NZS5AhEiM/mpny04PqhlIlZwStTiBbD8+O/NcaYRW0cdFTAPV8Be Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 02 Mar 2016 15:34:55 -0000 Date: 2 Mar 2016 10:34:54 -0500 Message-ID: From: "John R Levine" To: "=?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?=" In-Reply-To: <67FF63CC-FDEE-49A0-BDD0-631EA0C4D1CC@frobbit.se> References: <20160302002421.72294.qmail@ary.lan> <2379614E-6DAC-4687-AFBD-B735642A8DFC@frobbit.se> <67FF63CC-FDEE-49A0-BDD0-631EA0C4D1CC@frobbit.se> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Why shut down the DANE group? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 15:34:57 -0000 >> It doesn't matter -- I don't have the password to log into their registrar account. > Ok, my point was that a tech contact should have their own log in. It has in the Frobbit system ;-) They don't in any of the gTLD registrars I've used. As far as I can tell, the only actual use of the tech contact is so ISC employees can flame you if your DNS records are mildly inconsistent. > I just wanted to say that I personally for DNSSEC think we will > not get forward movement faster than software get the features by > default so that one have to turn off things to not use it. For that to > happen, yes, many many things are still to be resolved. For example side > channel for the DS (which we have a suggestion on how to implement, by > publication of the key material in the zone itself). These issues are certainly soluble, but it's pretty telling that this obvious problem has been been facing us for ten years and we're just getting around to it now. FYI, people at Google have told me that they have no plans to turn on DNSSEC for their zones any time soon because too much stuff breaks. Since it's Google, I expect they have precise but non-public numbers for what too much means. I don't know enough details to guess whether normal upgrade cycles with newer software will fix the breakage. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Sun Mar 6 09:54:00 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82F5E1B2FC0 for ; Sun, 6 Mar 2016 09:53:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.622 X-Spam-Level: X-Spam-Status: No, score=0.622 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 HKnFDNeVm0LE for ; Sun, 6 Mar 2016 09:53:58 -0800 (PST) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 556481B2FBE for ; Sun, 6 Mar 2016 09:53:58 -0800 (PST) Received: by mail-yw0-x234.google.com with SMTP id g3so23677691ywa.3 for ; Sun, 06 Mar 2016 09:53:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=BUpVP4C1zGgxWzdS1OUIvKhxXjody0wrpa4XBs3Pb0I=; b=LxMeZfK3hN0fL2hIhOng9TU3uDtMdeW35f28cRh90TkNTBRYkRUdGhgRkpHvqCpY7s CXUKnXk5YCbfBpyVFRjKFjYspR+72n/VtEDzA+cqmaJoZ2HGCAtaucoDGhOsMkEAZ13G a9KhG8QAj+0wfK21esqtuJQCqIDecMiJUXAAMQK2eKxQ/Xd2x7nD1mYcwFySddtHEUA3 uOC3fOfQPvtYKP3tB8JYe4t8U5qM1ReGo0pWRNSPCbhMnTv3dmFzBCTk+/CTiYaC7ign sM7UJwYRMzSbkkB34cFNdwXc3ctnkEwWQ/MP9QiHYgH6NvcdqtKtu58QYqwE3PjFn+gV shEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=BUpVP4C1zGgxWzdS1OUIvKhxXjody0wrpa4XBs3Pb0I=; b=bqGFxg0OTbjuhJKidJMfBN/8rjZ7HiPLiobW0JnqPVJMiKrpBo3G3A8POm5QgEo+q7 9mzATsYMCZmN6M/ewltfMfiGSh7F1t5rzM8iqi5X73CpbFnqogUOphJoshKpFvNJbKMZ HP9COWAAw04wPWanbbC5s+RklTm22x3QUWpeP6RKTsJzhEPEWoFxbouzvZCkZijw8TnA xDkH8BjyvxOXDpD3fd3MbS6sPwubIYAZdu4XP8Ki/wnuZ78fjOh1pT8XydRMShT9oNZ/ PYWFlvESlmZafE4NNu1ouxlgWzJybXbLrKFhZUUotUCWPAGO3BYMyoJ5RWK9bCQfXDDh 70hw== X-Gm-Message-State: AD7BkJIp02QVQvAJqYp/+a5cYAOouvah7yYUbKjNy1iRJrV2/PzGFOGMgQiq4Ir4fKDLUSFcOEb6Uyv6lz2pN7L3 X-Received: by 10.13.203.193 with SMTP id n184mr10678717ywd.333.1457286837459; Sun, 06 Mar 2016 09:53:57 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Warren Kumari Date: Sun, 06 Mar 2016 17:53:47 +0000 Message-ID: To: "" Content-Type: multipart/alternative; boundary=001a1148285848aa35052d6508a5 Archived-At: Subject: Re: [dane] DANE meeting at IETF95 in BA X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2016 17:53:59 -0000 --001a1148285848aa35052d6508a5 Content-Type: text/plain; charset=UTF-8 So, it seems that the primary authors of many our documents will not be able to make it to Buenos Aires, and, we still have not received any call for agenda items. Unless we hear compelling requests for agenda time soon, we will be cancelling the meeting. W On Mon, Feb 29, 2016 at 12:30 AM Warren Kumari wrote: > A reminder - y'all told us that you want DANE to meet in BA, and that > there is still much work to be done (yay!), but we have not seen any > requests, or recent, promised documents / updates (boo!) > > W > > > On Fri, Feb 12, 2016 at 6:02 PM Warren Kumari wrote: > >> Hi all, >> >> We are glad to see all of the enthusiasm and desire to get more work >> done[0] in response to our "Are we done here?" email. >> >> We've requested a meeting slow in Buenos Aires, and would like to have a >> productive meeting - as always we will be giving meeting time to documents >> which have open issues which are best discussed in person, then to >> documents which have had lots of discussion. Because we are also discussing >> new work we may also give time to new documents / ideas. >> >> So, if you would like some agenda time, please send mail to dane-chairs. >> >> >> Thank you, >> Olafur and Warren >> >> [0]: Huh, almost like we planned that.... ;-P >> > --001a1148285848aa35052d6508a5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
So, it seems that the primary authors of many our document= s will not be able to make it to Buenos Aires, and, we still have not recei= ved any call for agenda items. =C2=A0

Unless we hear com= pelling requests for agenda time soon, we will be cancelling the meeting.

W

On Mon, Feb 29, 2016 at 12:30 AM Warren Kumari <warren@kumari.net> wrote:
A reminder - y'all told us that yo= u want DANE to meet in BA, and that there is still much work to be done (ya= y!), but we have not seen any requests, or recent, promised documents / upd= ates (boo!)

W


On Fri, Feb 12, 2016 at 6:02 PM Warren Kumari <warren@kumari.net> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
Hi all,

We are g= lad to see all of the enthusiasm and desire to get more work done[0] in res= ponse to our "Are we done here?" email.

We've requested a meeting slow in Buenos Aires, and would = like to have a productive meeting - as always we will be giving meeting tim= e to documents which have open issues which are best discussed in person, t= hen to documents which have had lots of discussion. Because we are also dis= cussing new work we may also give time to new documents / ideas.

So, if you would like some agenda time, please = send mail to dane-chairs.


<= div style=3D"font-size:13px;line-height:19.5px">Thank you,
Olafur and Warren

[0]: Huh, almost like we planned that.... ;-P
--001a1148285848aa35052d6508a5-- From nobody Sun Mar 6 22:22:15 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E30461A9150 for ; Sun, 6 Mar 2016 22:22:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] 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 KfwOLW6zcXzH for ; Sun, 6 Mar 2016 22:22:12 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 77CF91A914F for ; Sun, 6 Mar 2016 22:22:12 -0800 (PST) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 46A1722E1F3; Mon, 7 Mar 2016 01:22:09 -0500 (EST) To: dane@ietf.org, Warren Kumari From: Sean Leonard Message-ID: <56DD1DB7.7050305@seantek.com> Date: Sun, 6 Mar 2016 22:20:39 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [dane] Request DANE ALPS discussion time at IETF 95 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 06:22:14 -0000 Hello: As the chairs graciously requested and got a meeting slot in Buenos Aires, I would like to request DANE ALPS (Alternative Local-Part Synthesis) discussion time at IETF 95. The Internet-Draft was posted back in October: http://mailarchive.ietf.org/arch/msg/dane/5oV9mDolVS09UoF_ZCQOWAH1f9k https://tools.ietf.org/html/draft-seantek-dane-alps-00 There has been discussion about local-part and e-mail address equivalence issues on other IETF mailing list(s) in the last couple of months. The Mail Gods say that only the receiving MTA gets to determine whether different local-parts are "equal". "Equal" means "deliver to the same mailbox" (a conceptual entity). They are right. The proposed ALPS protocol does not change anything about this. To the extent people perceive otherwise, it needs to be clarified and cleared up. But the issue is an important one for storing names--particularly e-mail address-based names--in DANE, for S/MIME, PGP, and other future protocols. I suppose that the presentation and discussion time should include not only ALPS, but a review of other approaches (see, e.g., John Levine's thread "Encoding local parts in better ways" and associated I-D). It should also review some of the most common local-part equivalence constructs, i.e.: differences solely attributable to case sub-addressing ( + - and = ) return-path randomization etc. UTF-8 (beyond ASCII range) Regards, Sean From nobody Mon Mar 7 04:47:08 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58D6F1B407D for ; Mon, 7 Mar 2016 04:47:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 M51afEqZ_skW for ; Mon, 7 Mar 2016 04:47:06 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6E811B408C for ; Mon, 7 Mar 2016 04:47:04 -0800 (PST) Received: (qmail 74342 invoked from network); 7 Mar 2016 12:46:59 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 7 Mar 2016 12:46:59 -0000 Date: 7 Mar 2016 12:46:37 -0000 Message-ID: <20160307124637.1102.qmail@ary.lan> From: "John Levine" To: dane@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dane] DANE meeting at IETF95 in BA X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 12:47:07 -0000 In article you write: >-=-=-=-=-=- >-=-=-=-=-=- > >So, it seems that the primary authors of many our documents will not be >able to make it to Buenos Aires, and, we still have not received any call >for agenda items. If you meet, I'd like to present draft-bhjl-x509-srv-00 but if you don't meet, that's fine too. R's, John From nobody Mon Mar 7 04:55:25 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 539481B4019 for ; Mon, 7 Mar 2016 04:55:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.862 X-Spam-Level: X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 1iVZQ7UPR234 for ; Mon, 7 Mar 2016 04:55:22 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D31791B4057 for ; Mon, 7 Mar 2016 04:55:17 -0800 (PST) Received: (qmail 75246 invoked from network); 7 Mar 2016 12:55:13 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 7 Mar 2016 12:55:13 -0000 Date: 7 Mar 2016 12:54:50 -0000 Message-ID: <20160307125450.1161.qmail@ary.lan> From: "John Levine" To: dane@ietf.org In-Reply-To: <56DD1DB7.7050305@seantek.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dane] Request DANE ALPS discussion time at IETF 95 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 12:55:23 -0000 In article <56DD1DB7.7050305@seantek.com> you write: >Hello: > >As the chairs graciously requested and got a meeting slot in Buenos >Aires, I would like to request DANE ALPS (Alternative Local-Part >Synthesis) discussion time at IETF 95. This draft belongs in ietf-smtp or maybe appsarea, not DANE. It's an interesting idea, but since it changes the rules about who interprets local-parts, it's an update to RFC 5321. Also, it's an issue that affects people in a lot of places other than DANE. Pkix has been having somewhat similar discussions about the names in X.509 certificates. R's, John From nobody Mon Mar 7 22:17:46 2016 Return-Path: X-Original-To: dane@ietfc.amsl.com Delivered-To: dane@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3E0101CE058 for ; Mon, 7 Mar 2016 22:17:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.41]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XB0g5lB5w9W5 for ; Mon, 7 Mar 2016 22:17:43 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfc.amsl.com (Postfix) with ESMTPS id E770D1CE057 for ; Mon, 7 Mar 2016 22:17:42 -0800 (PST) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 3214722E1F3; Tue, 8 Mar 2016 01:17:36 -0500 (EST) To: John Levine , dane@ietf.org References: <20160307125450.1161.qmail@ary.lan> From: Sean Leonard Message-ID: <56DE6E26.8090101@seantek.com> Date: Mon, 7 Mar 2016 22:16:06 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160307125450.1161.qmail@ary.lan> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [dane] Request DANE ALPS discussion time at IETF 95 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 06:17:44 -0000 On 3/7/2016 4:54 AM, John Levine wrote: > In article <56DD1DB7.7050305@seantek.com> you write: >> Hello: >> >> As the chairs graciously requested and got a meeting slot in Buenos >> Aires, I would like to request DANE ALPS (Alternative Local-Part >> Synthesis) discussion time at IETF 95. > This draft belongs in ietf-smtp or maybe appsarea, not DANE. It's an > interesting idea, but since it changes the rules about who interprets > local-parts, it's an update to RFC 5321. > > Also, it's an issue that affects people in a lot of places other than D= ANE. > Pkix has been having somewhat similar discussions about the names in X.= 509 > certificates. As the document itself states (repeatedly), the DANE ALPS proposal is=20 very specific to DANE. It does not affect how the mail infrastructure=20 interprets local-parts, because to do otherwise would anger the Mail=20 Gods. We are leaving the issue alone. Local-Part is and remains left to=20 the interpretation of the receiving MTA. The point of DANE ALPS is to reduce the burden of maintaining a=20 bajillion variations of records, for operating a DANE/DNSSEC-enabled=20 zone. Consider a case where the owners want *all* messages sent to=20 e-mail addresses in a domain to use the same key. Perhaps that key is a=20 master encryption key for policy reasons, that will be decrypted by some = gateway. Another case is where one user maintains the whole domain:=20 *@ietf.taugh.com e-mail addresses should all be encrypted to the same=20 key and read (ultimately) by the same user, even if the messages get=20 fanned out into different mailboxes on the back end. In such cases, is=20 it desirable for the DANE/DNSSEC-enabled zone to maintain a bajillion=20 different records with the same key info, or just to maintain one=20 record, and have a mechanism to point queries to that specific record?=20 The latter is simply more efficient (and more easily auditable). Now, a possible outcome of the WG presentation/meeting is that the=20 proposal has broader application than just DANE. In that case, expanding = or moving it elsewhere would be fine. But we need to have that discussion= =2E Yes, it came up in PKIX recently...there is a broader question about how = to determine e-mail address equivalence, when the two inputs are not=20 bit-for-bit identical. This is an industry-wide problem. However, the=20 DANE ALPS solution is about alternate queries of the DNS zone between a=20 DNS client and a DNS server, not equivalence. It is specific to the way=20 that DANE operates and is not intended to be a published general=20 statement about how the domain's MTA fans out mail. draft-osterweil-dmarc-dane-names also tries to address the matter using=20 DMARC records. However, it goes a step further by saying=20 "canonicalization policy"--which implies that it is promulgating=20 interpretations of the local-part that might cause a disturbance in the=20 (Mail Gods') Force. See: http://mailarchive.ietf.org/arch/msg/dane/gWhYXtSyNGh2D2uuDp99LWHzBSU That approach should also be covered and discussed. So now we have at least four different approaches: a) do nothing, b)=20 draft-seantek-dane-alps, c) draft-levine-dns-mailbox (a collection of=20 different approaches), d) draft-osterweil-dmarc-dane-names. Obviously=20 the WG is struggling to do something here, hence, discussion. Regards, Sean From nobody Mon Mar 7 22:24:57 2016 Return-Path: X-Original-To: dane@ietfc.amsl.com Delivered-To: dane@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 39A7E1CE080 for ; Mon, 7 Mar 2016 22:24:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.41]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mzv09QaD4bbG for ; Mon, 7 Mar 2016 22:24:55 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfc.amsl.com (Postfix) with ESMTPS id 86C151CE07F for ; Mon, 7 Mar 2016 22:24:55 -0800 (PST) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6433222E253; Tue, 8 Mar 2016 01:24:54 -0500 (EST) To: John Levine , dane@ietf.org References: <20160307124637.1102.qmail@ary.lan> From: Sean Leonard Message-ID: <56DE6FDC.1060001@seantek.com> Date: Mon, 7 Mar 2016 22:23:24 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160307124637.1102.qmail@ary.lan> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dane] DANE meeting at IETF95 in BA X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 06:24:56 -0000 On 3/7/2016 4:46 AM, John Levine wrote: > In article you write: >> -=-=-=-=-=- >> -=-=-=-=-=- >> >> So, it seems that the primary authors of many our documents will not be >> able to make it to Buenos Aires, and, we still have not received any call >> for agenda items. > If you meet, I'd like to present draft-bhjl-x509-srv-00 but if you > don't meet, that's fine too. I do not understand what exactly this draft offers over RFC 4387, which already defines the HTTP certificate service, the URI formats, and the SRV records. I get the vague sense that this draft is an alternative to storing individual certificates in the DNS with DANE as draft-ietf-dane-smime-10 proposes. (See Section 5 of this draft.) That being said, it seems reasonable to present at the DANE meeting, so I support that. Sean From nobody Tue Mar 8 00:32:12 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0B0C12D560 for ; Tue, 8 Mar 2016 00:32:11 -0800 (PST) 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 (1536-bit key) header.d=iecc.com header.b=kLy+XWzS; dkim=pass (1536-bit key) header.d=taugh.com header.b=OIfB+Z0d 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 ooc-GfH3tVZe for ; Tue, 8 Mar 2016 00:32:09 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C898C12D564 for ; Tue, 8 Mar 2016 00:32:08 -0800 (PST) Received: (qmail 53190 invoked from network); 8 Mar 2016 08:32:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=cfc5.56de8e07.k1603; bh=XMqeDDzKk1VBI4QN5JJXlPs4+MPGBkJeQ55W3/qQokI=; b=kLy+XWzSVJjXbKKXrXrV8J/Hexjf62lmIDLX5QBrs2IJlNf+1vNCh7g/zGq48j18jaRazBu5f4uMbetd0b3Zav3ZqFgpPqC5SjfJWkaIibZm6Nc4Pn8eJrGcgpg+wR6g0oy8WyT6jxA/tzwciXUEwdU8U0PK6gv1ypTv9QlH3ew1Ey50x+6Tgu/ZxISytluy5FhYPrBwj8cPdTmCLdf/P6RTC03jndrdLi+/G+yKx80BRMYe9RmHLquLcpGSvPdz DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=cfc5.56de8e07.k1603; bh=XMqeDDzKk1VBI4QN5JJXlPs4+MPGBkJeQ55W3/qQokI=; b=OIfB+Z0dRrYaEUhT1ptINMk51AqptA0sEz5WbKaL60GlT7Xkpy1FgQi3HbsGf35ZQ3f60611F0AdJ0xcdEEJkJzR1Va/wiFw8SjTG8Br4hXwp9KNRmU/0hBEFgErFD/o/PEfj+u70OGVSU5LE8ZapXracGIVkcM6BzCmFe1nzczMXNE4HHwEf7wQFiHAN/vJLEa/xNWRP5HuLq1lrAcAABI/cpcgF5r/ZncAqk0VY7GhShlmEyfdwtACW6FdW8p7 Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 08 Mar 2016 08:32:06 -0000 Date: 8 Mar 2016 09:32:05 +0100 Message-ID: From: "John R Levine" To: "Sean Leonard" In-Reply-To: <56DE6E26.8090101@seantek.com> References: <20160307125450.1161.qmail@ary.lan> <56DE6E26.8090101@seantek.com> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: ietf-smtp@ietf.org, dane@ietf.org Subject: Re: [dane] Request DANE ALPS (another attempt to canonicalize local parts) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 08:32:11 -0000 I think it's fair to say that doing an end run around the "Mail Gods" with yet another attempt to canonicalize local parts will not make them any less annoyed. Hand waving claims that it's doing something else doesn't make it so. I hope it's obvious why one approach to doing it in DANE and a different incompatble approach in PKIX would be a bad idea. R's, John On Mon, 7 Mar 2016, Sean Leonard wrote: > On 3/7/2016 4:54 AM, John Levine wrote: >> In article <56DD1DB7.7050305@seantek.com> you write: >>> Hello: >>> >>> As the chairs graciously requested and got a meeting slot in Buenos >>> Aires, I would like to request DANE ALPS (Alternative Local-Part >>> Synthesis) discussion time at IETF 95. >> This draft belongs in ietf-smtp or maybe appsarea, not DANE. It's an >> interesting idea, but since it changes the rules about who interprets >> local-parts, it's an update to RFC 5321. >> >> Also, it's an issue that affects people in a lot of places other than DANE. >> Pkix has been having somewhat similar discussions about the names in X.509 >> certificates. > > As the document itself states (repeatedly), the DANE ALPS proposal is very > specific to DANE. It does not affect how the mail infrastructure interprets > local-parts, because to do otherwise would anger the Mail Gods. We are > leaving the issue alone. Local-Part is and remains left to the interpretation > of the receiving MTA. > > The point of DANE ALPS is to reduce the burden of maintaining a bajillion > variations of records, for operating a DANE/DNSSEC-enabled zone. Consider a > case where the owners want *all* messages sent to e-mail addresses in a > domain to use the same key. Perhaps that key is a master encryption key for > policy reasons, that will be decrypted by some gateway. Another case is where > one user maintains the whole domain: *@ietf.taugh.com e-mail addresses should > all be encrypted to the same key and read (ultimately) by the same user, even > if the messages get fanned out into different mailboxes on the back end. In > such cases, is it desirable for the DANE/DNSSEC-enabled zone to maintain a > bajillion different records with the same key info, or just to maintain one > record, and have a mechanism to point queries to that specific record? The > latter is simply more efficient (and more easily auditable). > > Now, a possible outcome of the WG presentation/meeting is that the proposal > has broader application than just DANE. In that case, expanding or moving it > elsewhere would be fine. But we need to have that discussion. > > Yes, it came up in PKIX recently...there is a broader question about how to > determine e-mail address equivalence, when the two inputs are not bit-for-bit > identical. This is an industry-wide problem. However, the DANE ALPS solution > is about alternate queries of the DNS zone between a DNS client and a DNS > server, not equivalence. It is specific to the way that DANE operates and is > not intended to be a published general statement about how the domain's MTA > fans out mail. > > draft-osterweil-dmarc-dane-names also tries to address the matter using DMARC > records. However, it goes a step further by saying "canonicalization > policy"--which implies that it is promulgating interpretations of the > local-part that might cause a disturbance in the (Mail Gods') Force. See: > http://mailarchive.ietf.org/arch/msg/dane/gWhYXtSyNGh2D2uuDp99LWHzBSU > > That approach should also be covered and discussed. > > So now we have at least four different approaches: a) do nothing, b) > draft-seantek-dane-alps, c) draft-levine-dns-mailbox (a collection of > different approaches), d) draft-osterweil-dmarc-dane-names. Obviously the WG > is struggling to do something here, hence, discussion. > > Regards, > > Sean > > > Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Tue Mar 8 00:34:11 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6610A12D56A for ; Tue, 8 Mar 2016 00:34:10 -0800 (PST) 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 (1536-bit key) header.d=iecc.com header.b=DfMMysiT; dkim=pass (1536-bit key) header.d=taugh.com header.b=Av/kTfOO 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 KubnGrf-ZY8V for ; Tue, 8 Mar 2016 00:34:09 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1F4E12D55D for ; Tue, 8 Mar 2016 00:34:08 -0800 (PST) Received: (qmail 53503 invoked from network); 8 Mar 2016 08:34:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=d0fe.56de8e7f.k1603; bh=7Z7VNl18UThzyjvycBbKL/ueCke33HE0cu1FRMo7rwc=; b=DfMMysiTY0Etv5tpVQl0VgSv1zuRKx0F/PvT3DsH5OE0kY0XMwzZ/oiiJI76ABwDDOBGLqS7UTfmO3GEZ0Cx+n4TA0BRb4kBcqnfiVDUZfz+3KkgbkVIwG8DkBXZ+mHCQbIbAD5IO3NzsHtqD0W+79jCWNnoGGjfIlhhi4yZFInbaken5SXbUYglTndotoNvQQgjyqAvY0lBPvVvIfrD4wFgjX/cns9R7WjK2OBuJCtGhZbmdziTOYQKzMqC+SFH DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=d0fe.56de8e7f.k1603; bh=7Z7VNl18UThzyjvycBbKL/ueCke33HE0cu1FRMo7rwc=; b=Av/kTfOO4gPug9CedcEghnD5ls5Gt7n5CCEL9l1kSMW+2Ma/M7ymBrX1nmyWHWDsT467O0TzXeWRBDhchxsnKlFQT8/moaU3/AdwXt/r+tR+9dQljqpEIRoMq86Md+J4KNR7LC1qgmOa4oVBBWNFjn2o+VUfUVbqArvp7WL5EGa1a7k2fgVIdNvT2SoHQnukK/68NaZKO6f8hlXNZrqge0IK4vUIDJ3CUwLr5H1CB1s36bKhUl8vcUfbdSzVtIFd Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 08 Mar 2016 08:34:07 -0000 Date: 8 Mar 2016 09:34:08 +0100 Message-ID: From: "John R Levine" To: "Sean Leonard" In-Reply-To: <56DE6FDC.1060001@seantek.com> References: <20160307124637.1102.qmail@ary.lan> <56DE6FDC.1060001@seantek.com> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dane@ietf.org Subject: Re: [dane] DANE meeting at IETF95 in BA X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 08:34:10 -0000 >> If you meet, I'd like to present draft-bhjl-x509-srv-00 but if you >> don't meet, that's fine too. > > I do not understand what exactly this draft offers over RFC 4387, which > already defines the HTTP certificate service, the URI formats, and the SRV > records. I get the vague sense that this draft is an alternative to storing > individual certificates in the DNS with DANE as draft-ietf-dane-smime-10 > proposes. (See Section 5 of this draft.) RFC 4387 is rather vague about how you locate the key server and what URIs you use. This is basically a profile that nails down enough details that clients and servers can interoperate. > That being said, it seems reasonable to present at the DANE meeting, so I > support that. Thanks. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Tue Mar 8 03:30:13 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43C5412D678 for ; Tue, 8 Mar 2016 03:30:10 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 5z5agTKOt6-E for ; Tue, 8 Mar 2016 03:30:08 -0800 (PST) Received: from smtp124.iad3a.emailsrvr.com (smtp124.iad3a.emailsrvr.com [173.203.187.124]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3867112D67A for ; Tue, 8 Mar 2016 03:30:04 -0800 (PST) Received: from smtp8.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp8.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 7A732380296; Tue, 8 Mar 2016 06:30:03 -0500 (EST) Received: from app23.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp8.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 6B0B338017A; Tue, 8 Mar 2016 06:30:02 -0500 (EST) X-Sender-Id: ogud@ogud.com Received: from app23.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.5.4); Tue, 08 Mar 2016 06:30:03 -0500 Received: from ogud.com (localhost [127.0.0.1]) by app23.wa-webapps.iad3a (Postfix) with ESMTP id 8C006A007D; Tue, 8 Mar 2016 06:30:02 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: ogud@ogud.com, from: ogud@ogud.com) with HTTP; Tue, 8 Mar 2016 06:30:02 -0500 (EST) Date: Tue, 8 Mar 2016 06:30:02 -0500 (EST) From: "Olafur Gudmundsson" To: "Sean Leonard" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20160308063002000000_72732" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: <56DD1DB7.7050305@seantek.com> References: <56DD1DB7.7050305@seantek.com> X-Auth-ID: ogud@ogud.com Message-ID: <1457436602.570617043@apps.rackspace.com> X-Mailer: webmail/12.2.3-RC Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Request DANE ALPS discussion time at IETF 95 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 11:30:10 -0000 ------=_20160308063002000000_72732 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0ASean,=0A =0AThank you for your submission of this draft. =0AT= he chairs have reviewed this, and we think it is an interesting contributio= n to the IETF email normalization discussion. =0ABUT while this may help OP= ENPGP and SMIMA limit the "search" for their record lookups, it is not stri= ctly needed. =0AIn your draft there is nothing that is strictly security re= lated, thus it does not fit within our charter, additionally it is outside = the expertise of most of its participants. =0AWe strongly recommend that yo= u take this work to the APPSAREA where there are more of "The Mail Gods" fo= r discussing this issue. =0AWe will not be using this document as justifica= tion to meet. If we *do* meet, and there happens to be free time, we may be= able to give you some time to discuss it, but simply an an "FYI", not some= thing which DANE might adopt / really discuss=0AOlafur & Warren=0A =0AOn Mo= nday, 7 March, 2016 01:20, "Sean Leonard" said:=0A= =0A=0A=0A> Hello:=0A> =0A> As the chairs graciously requested and got a mee= ting slot in Buenos=0A> Aires, I would like to request DANE ALPS (Alternati= ve Local-Part=0A> Synthesis) discussion time at IETF 95.=0A> =0A> The Inter= net-Draft was posted back in October:=0A> http://mailarchive.ietf.org/arch/= msg/dane/5oV9mDolVS09UoF_ZCQOWAH1f9k=0A> =0A> https://tools.ietf.org/html/d= raft-seantek-dane-alps-00=0A> =0A> There has been discussion about local-pa= rt and e-mail address=0A> equivalence issues on other IETF mailing list(s) = in the last couple of=0A> months. The Mail Gods say that only the receiving= MTA gets to determine=0A> whether different local-parts are "equal". "Equa= l" means "deliver to the=0A> same mailbox" (a conceptual entity). They are = right. The proposed ALPS=0A> protocol does not change anything about this. = To the extent people=0A> perceive otherwise, it needs to be clarified and c= leared up.=0A> =0A> But the issue is an important one for storing names--pa= rticularly e-mail=0A> address-based names--in DANE, for S/MIME, PGP, and ot= her future protocols.=0A> =0A> I suppose that the presentation and discussi= on time should include not=0A> only ALPS, but a review of other approaches = (see, e.g., John Levine's=0A> thread "Encoding local parts in better ways" = and associated I-D). It=0A> should also review some of the most common loca= l-part equivalence=0A> constructs, i.e.:=0A> differences solely attributabl= e to case=0A> sub-addressing ( + - and =3D )=0A> return-path randomization = etc.=0A> UTF-8 (beyond ASCII range)=0A> =0A> Regards,=0A> =0A> Sean=0A> =0A= > _______________________________________________=0A> dane mailing list=0A>= dane@ietf.org=0A> https://www.ietf.org/mailman/listinfo/dane=0A> ------=_20160308063002000000_72732 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sean,
=0A
<chair-hat> 
=0AThank = you for your submission of this draft. 
=0A
The chairs have reviewed = this, and we think it is an interesting contribution to the IETF email norm= alization discussion. 
=0A
BUT while this may help OPENPGP and SMIMA = limit the "search" for their record lookups, it is not strictly needed.&nbs= p;
=0A
In your dra= ft there is nothing that is strictly security related, thus it does not fit= within our charter, additionally it is outside the expertise of most of it= s participants. 
=0A
We strongly recommend that you take this work to the APPSAREA where= there are more of "The Mail Gods" for discussing this issue. 
= =0A
We will not be using this document as justification t= o meet. If we *do* meet, and there happens to be free time, we may be able = to give you some time to discuss it, but simply an an "FYI", not something = which DANE might adopt / really discuss
=0A
Olafur & Warren
=0A

 

=0A

On Monday, 7 March, 2016 01:20, "Sean Leon= ard" <dev+ietf@seantek.com> said:

=0A
=0A

> Hello:
>
> As the= chairs graciously requested and got a meeting slot in Buenos
> Air= es, I would like to request DANE ALPS (Alternative Local-Part
> Syn= thesis) discussion time at IETF 95.
>
> The Internet-Draft= was posted back in October:
> http://mailarchive.ietf.org/arch/msg= /dane/5oV9mDolVS09UoF_ZCQOWAH1f9k
>
> https://tools.ietf.o= rg/html/draft-seantek-dane-alps-00
>
> There has been disc= ussion about local-part and e-mail address
> equivalence issues on = other IETF mailing list(s) in the last couple of
> months. The Mail= Gods say that only the receiving MTA gets to determine
> whether d= ifferent local-parts are "equal". "Equal" means "deliver to the
> s= ame mailbox" (a conceptual entity). They are right. The proposed ALPS
= > protocol does not change anything about this. To the extent people
> perceive otherwise, it needs to be clarified and cleared up.
&g= t;
> But the issue is an important one for storing names--particul= arly e-mail
> address-based names--in DANE, for S/MIME, PGP, and ot= her future protocols.
>
> I suppose that the presentation = and discussion time should include not
> only ALPS, but a review of= other approaches (see, e.g., John Levine's
> thread "Encoding loca= l parts in better ways" and associated I-D). It
> should also revie= w some of the most common local-part equivalence
> constructs, i.e.= :
> differences solely attributable to case
> sub-addressin= g ( + - and =3D )
> return-path randomization etc.
> UTF-8 = (beyond ASCII range)
>
> Regards,
>
> Sea= n
>
> _______________________________________________
> dane mailing list
> dane@ietf.org
> https://www.ietf.= org/mailman/listinfo/dane
>

=0A
 ------=_20160308063002000000_72732-- From nobody Tue Mar 8 08:14:21 2016 Return-Path: X-Original-To: dane@ietf.org Delivered-To: dane@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1491D12D7DD; Tue, 8 Mar 2016 08:14:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.15.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160308161417.10391.2011.idtracker@ietfa.amsl.com> Date: Tue, 08 Mar 2016 08:14:17 -0800 Archived-At: Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-openpgpkey-08.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 16:14:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS-based Authentication of Named Entities of the IETF. Title : Using DANE to Associate OpenPGP public keys with email addresses Author : Paul Wouters Filename : draft-ietf-dane-openpgpkey-08.txt Pages : 19 Date : 2016-03-08 Abstract: OpenPGP is a message format for email (and file) encryption that lacks a standardized lookup mechanism to securely obtain OpenPGP public keys. DNS-Based Authentication of Named Entities ("DANE") is a method for publishing public keys in DNS. This document specifies a DANE method for publishing and locating OpenPGP public keys in DNS for a specific email address using a new OPENPGPKEY DNS Resource Record. Security is provided via Secure DNS, however the OPENPGPKEY record is not a replacement for verification of authenticity via the "Web Of Trust" or manual verification. The OPENPGPKEY record can be used to encrypt an email that would otherwise have to be sent unencrypted. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dane-openpgpkey-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dane-openpgpkey-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Mar 8 08:32:09 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A10012D804; Tue, 8 Mar 2016 08:32:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.001] autolearn=no autolearn_force=no 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 s-01DC6a_HHY; Tue, 8 Mar 2016 08:32:00 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 8C22F12D7F2; Tue, 8 Mar 2016 08:31:52 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3qKMW94Wlzz3PT; Tue, 8 Mar 2016 17:31:49 +0100 (CET) X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id ewaMkOFH70UY; Tue, 8 Mar 2016 17:31:47 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 8 Mar 2016 17:31:47 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 9CA23603BAAB; Tue, 8 Mar 2016 11:31:46 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 9CA23603BAAB Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 98EF4A3C7; Tue, 8 Mar 2016 11:31:46 -0500 (EST) Date: Tue, 8 Mar 2016 11:31:46 -0500 (EST) From: Paul Wouters To: ietf@ietf.org In-Reply-To: <20160308161417.10391.2011.idtracker@ietfa.amsl.com> Message-ID: References: <20160308161417.10391.2011.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: dane WG list Subject: [dane] FWD: I-D Action: draft-ietf-dane-openpgpkey-08.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 16:32:02 -0000 On Tue, 8 Mar 2016, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the DNS-based Authentication of Named Entities of the IETF. > > Title : Using DANE to Associate OpenPGP public keys with email addresses > Author : Paul Wouters > Filename : draft-ietf-dane-openpgpkey-08.txt > Pages : 19 > Date : 2016-03-08 > https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-dane-openpgpkey-08 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dane-openpgpkey-08 This version includes the changes suggested by Stephen's summary of the IETF LC, Paul From nobody Tue Mar 8 09:05:54 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85BDE12D878; Tue, 8 Mar 2016 09:05:52 -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 aWfGrzKqE3Mp; Tue, 8 Mar 2016 09:05:50 -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 BC83D12D866; Tue, 8 Mar 2016 09:05:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id F0912BE35; Tue, 8 Mar 2016 17:04:58 +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 oyH7X-lzOzIS; Tue, 8 Mar 2016 17:04:57 +0000 (GMT) Received: from [10.87.49.100] (unknown [86.46.19.12]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DF86EBE33; Tue, 8 Mar 2016 17:04:56 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1457456697; bh=iRR0mTxYRzDY77Z+oqvL76xorbWxtuIPBjuxzqH3JeY=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=MRldRnOuSHbYLZvtmL+gltLd0Y5zhNoq//iz6Nz6BxAdMoopPl57VQcUSAIrbvoUH g2Vmtu9qQbcOXH+05S7cp839BFhyMW4+M2lHYzpDDAsDFGSEPfeICYcQJiTeTXSMUH fmrAS88u8xgQg/cLzdfbAMe6DQrV9vw2x59cw/Pw= To: Paul Wouters , ietf@ietf.org References: <20160308161417.10391.2011.idtracker@ietfa.amsl.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56DF0638.9010208@cs.tcd.ie> Date: Tue, 8 Mar 2016 17:04:56 +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: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080909060203060303030109" Archived-At: Cc: dane WG list Subject: Re: [dane] FWD: I-D Action: draft-ietf-dane-openpgpkey-08.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 17:05:52 -0000 This is a cryptographically signed message in MIME format. --------------ms080909060203060303030109 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 08/03/16 16:31, Paul Wouters wrote: > On Tue, 8 Mar 2016, internet-drafts@ietf.org wrote: >=20 >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the DNS-based Authentication of Named >> Entities of the IETF. >> >> Title : Using DANE to Associate OpenPGP public keys >> with email addresses >> Author : Paul Wouters >> Filename : draft-ietf-dane-openpgpkey-08.txt >> Pages : 19 >> Date : 2016-03-08 >=20 >> https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-dane-openpgpkey-08 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dane-openpgpkey-08 >=20 > This version includes the changes suggested by Stephen's summary of the= > IETF LC, Thanks Paul, as stated previously I'll extend the IETF LC for a week and hopefully then we'll be done with this part of the process. Cheers, S. >=20 > Paul >=20 >=20 --------------ms080909060203060303030109 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAzMDgx NzA0NTZaMC8GCSqGSIb3DQEJBDEiBCCt5EEJjHfMwADIObDzch2t6k6Ao6cTwWz63Ih51I3E pjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBUmFEmFgc36GPF9g8VSHG0yUcmS7CHOuUgNZeq4OmgiN6j1bDtNLoK yiAqyP+4vjBvw9SoOOg+9P4NB7fVnnvMXkh7raiDYsWGtUUExOp/MlCu7k6VNotA2v+pY1kq Sl+8fsl/ii2ZI61bonOQ5Wp/ryLju5ocBDcxXloy86ufgpFguN15K43zEeSLQgDRi4Qj1fqs KLz8iV9fGdXIt+kDTox2rM9/R8xHIBWFZQvBJcyab8Vfe+b427jBr3tq+goOmGcgyQqkCaox Rtzjt3IEXRUe81YDOHvXU0vfLanIK0QPDH905xGCr7WM/1W8ddg58O2lIl+Z9bLY/vKlze6B AAAAAAAA --------------ms080909060203060303030109-- From nobody Tue Mar 8 20:30:14 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4410112DE87 for ; Tue, 8 Mar 2016 20:30:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no 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 drFBNQF-8-EB for ; Tue, 8 Mar 2016 20:30:10 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 6A8C612DE82 for ; Tue, 8 Mar 2016 20:30:10 -0800 (PST) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5FDF1509B5; Tue, 8 Mar 2016 23:30:08 -0500 (EST) To: Olafur Gudmundsson References: <56DD1DB7.7050305@seantek.com> <1457436602.570617043@apps.rackspace.com> From: Sean Leonard Message-ID: <56DFA676.80501@seantek.com> Date: Tue, 8 Mar 2016 20:28:38 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <1457436602.570617043@apps.rackspace.com> Content-Type: multipart/alternative; boundary="------------080007060206070004050405" Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Request DANE ALPS discussion time at IETF 95 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 04:30:12 -0000 This is a multi-part message in MIME format. --------------080007060206070004050405 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Okay. Thanks and I respect the decision of the chairs. (Actually it doesn't actually "limit" the search...it's more like it casts a broader net. But anyway.) Since we are moving on and such, there is one issue about the local-part that affects draft-ietf-dane-openpgpkey and draft-ietf-dane-smime, related to proper (un)escaping, which I will comment on in a separate thread. Sean On 3/8/2016 3:30 AM, Olafur Gudmundsson wrote: > Sean, > > Thank you for your submission of this draft. > The chairs have reviewed this, and we think it is an interesting > contribution to the IETF email normalization discussion. > BUT while this may help OPENPGP and SMIMA limit the "search" for their > record lookups, it is not strictly needed. > In your draft there is nothing that is strictly security related, thus > it does not fit within our charter, additionally it is outside the > expertise of most of its participants. > We strongly recommend that you take this work to the APPSAREA where > there are more of "The Mail Gods" for discussing this issue. > We will not be using this document as justification to meet. If we > *do* meet, and there happens to be free time, we may be able to give > you some time to discuss it, but simply an an "FYI", not something > which DANE might adopt / really discuss > Olafur & Warren > > On Monday, 7 March, 2016 01:20, "Sean Leonard" > said: > > > Hello: > > > > As the chairs graciously requested and got a meeting slot in Buenos > > Aires, I would like to request DANE ALPS (Alternative Local-Part > > Synthesis) discussion time at IETF 95. > > > > The Internet-Draft was posted back in October: > > http://mailarchive.ietf.org/arch/msg/dane/5oV9mDolVS09UoF_ZCQOWAH1f9k > > > > https://tools.ietf.org/html/draft-seantek-dane-alps-00 > > > > There has been discussion about local-part and e-mail address > > equivalence issues on other IETF mailing list(s) in the last couple of > > months. The Mail Gods say that only the receiving MTA gets to determine > > whether different local-parts are "equal". "Equal" means "deliver to the > > same mailbox" (a conceptual entity). They are right. The proposed ALPS > > protocol does not change anything about this. To the extent people > > perceive otherwise, it needs to be clarified and cleared up. > > > > But the issue is an important one for storing names--particularly e-mail > > address-based names--in DANE, for S/MIME, PGP, and other future > protocols. > > > > I suppose that the presentation and discussion time should include not > > only ALPS, but a review of other approaches (see, e.g., John Levine's > > thread "Encoding local parts in better ways" and associated I-D). It > > should also review some of the most common local-part equivalence > > constructs, i.e.: > > differences solely attributable to case > > sub-addressing ( + - and = ) > > return-path randomization etc. > > UTF-8 (beyond ASCII range) > > > > Regards, > > > > Sean > > > > _______________________________________________ > > dane mailing list > > dane@ietf.org > > https://www.ietf.org/mailman/listinfo/dane > > > --------------080007060206070004050405 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Okay. Thanks and I respect the decision of the chairs.

(Actually it doesn't actually "limit" the search...it's more like it casts a broader net. But anyway.) Since we are moving on and such, there is one issue about the local-part that affects draft-ietf-dane-openpgpkey and draft-ietf-dane-smime, related to proper (un)escaping, which I will comment on in a separate thread.

Sean

On 3/8/2016 3:30 AM, Olafur Gudmundsson wrote:
Sean,
<chair-hat> 
Thank you for your submission of this draft. 
The chairs have reviewed this, and we think it is an interesting contribution to the IETF email normalization discussion. 
BUT while this may help OPENPGP and SMIMA limit the "search" for their record lookups, it is not strictly needed. 
In your draft there is nothing that is strictly security related, thus it does not fit within our charter, additionally it is outside the expertise of most of its participants. 
We strongly recommend that you take this work to the APPSAREA where there are more of "The Mail Gods" for discussing this issue. 
We will not be using this document as justification to meet. If we *do* meet, and there happens to be free time, we may be able to give you some time to discuss it, but simply an an "FYI", not something which DANE might adopt / really discuss
Olafur & Warren

 

On Monday, 7 March, 2016 01:20, "Sean Leonard" <dev+ietf@seantek.com> said:

> Hello:
>
> As the chairs graciously requested and got a meeting slot in Buenos
> Aires, I would like to request DANE ALPS (Alternative Local-Part
> Synthesis) discussion time at IETF 95.
>
> The Internet-Draft was posted back in October:
> http://mailarchive.ietf.org/arch/msg/dane/5oV9mDolVS09UoF_ZCQOWAH1f9k
>
> https://tools.ietf.org/html/draft-seantek-dane-alps-00
>
> There has been discussion about local-part and e-mail address
> equivalence issues on other IETF mailing list(s) in the last couple of
> months. The Mail Gods say that only the receiving MTA gets to determine
> whether different local-parts are "equal". "Equal" means "deliver to the
> same mailbox" (a conceptual entity). They are right. The proposed ALPS
> protocol does not change anything about this. To the extent people
> perceive otherwise, it needs to be clarified and cleared up.
>
> But the issue is an important one for storing names--particularly e-mail
> address-based names--in DANE, for S/MIME, PGP, and other future protocols.
>
> I suppose that the presentation and discussion time should include not
> only ALPS, but a review of other approaches (see, e.g., John Levine's
> thread "Encoding local parts in better ways" and associated I-D). It
> should also review some of the most common local-part equivalence
> constructs, i.e.:
> differences solely attributable to case
> sub-addressing ( + - and = )
> return-path randomization etc.
> UTF-8 (beyond ASCII range)
>
> Regards,
>
> Sean
>
> _______________________________________________
> dane mailing list
> dane@ietf.org
> https://www.ietf.org/mailman/listinfo/dane
>


--------------080007060206070004050405-- From nobody Wed Mar 9 15:53:18 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77FF012DBB4; Wed, 9 Mar 2016 15:53:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-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 37_pvIY-zTMH; Wed, 9 Mar 2016 15:53:14 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 B5DFF12DBB3; Wed, 9 Mar 2016 15:53:14 -0800 (PST) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 935BB509B6; Wed, 9 Mar 2016 18:53:13 -0500 (EST) From: Sean Leonard To: dane@ietf.org Message-ID: <56E0B710.10402@seantek.com> Date: Wed, 9 Mar 2016 15:51:44 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: ietf-smtp@ietf.org Subject: [dane] "decoded local-part" for dane-smime and dane-openpgp X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 23:53:16 -0000 Currently, dane-smime says: Section 3: 1. The user name (the "left-hand side" of the email address, called the "local-part" in the mail message format definition [RFC2822 ] and the "local part" in the specification for internationalized email [RFC6530 ]) should already be encoded in UTF-8 (or its subset ASCII). If it is written in another encoding it should be converted to UTF-8. Next, it is hashed using the SHA2-256 [RFC5754 ] algorithm, with the hash truncated to 28 octets and represented in its hexadecimal representation, to become the left-most label in the prepared domain name. Truncation comes from the right-most octets. This does not include the at symbol ("@") that separates the left and right sides of the email address. The problem is that this text does not distinguish between the local-part production, and the decoded (unescaped) local-part characters. As I am discussing in another Internet-Draft elsewhere (in progress, not necessary to cover right now here), the local-part has evolved basically to be a string of Unicode scalar values, which may or may not be escaped or quoted. Specifically: johnny.apple@example.com "johnny\.apple"@example.com "johnny.ap\ple"@example.com all have the same local-part characters: johnny.apple It is therefore appropriate that the local-part be isolated from the entire e-mail address production, and unescaped/unquoted (i.e., decoded). All three of the above examples should result in the same SHA-2-256 value, namely A3E3740AD57C3A2D1927DFED24B719FA8C4BBC006E1D0DE30670974B257D4FDD. Note that this issue has nothing to do with case. While we are at it, RFC 5322 (Internet Message Format) still permits CFWS (but not RFC 5321 (SMTP)). Therefore, these also have equivalent local-parts: johnny.apple (seed!) @ example.com (could be a song) (mis(ter)) "j\oh\nny.apple"@example.com Note that the term "user name" is not really ideal or correct in draft-ietf-dane-smime-10. Details were already hashed out a long time ago and are discussed in RFC 5322 sec. 3.4.1 and RFC 5321 sec. 2.3.11. I therefore propose the following text: Section 3: 1. a. The local part of the address ("local-part" [RFC5321] [RFC5322] [RFC6530]) is isolated and decoded, i.e., de-commented, whitespace-folded, unquoted, and unescaped, as appropriate. The resulting UTF-8 string is the "decoded local part". Note that the at symbol ("@") that separates the left and right sides of the email address is not part of the local part. b. The decoded local part is hashed using the SHA2-256 [RFC5754 ] algorithm, with the hash truncated to 28 octets and represented in its hexadecimal representation, to become the left-most label in the prepared domain name. Truncation comes from the right-most octets. I propose similar text for draft-ietf-dane-openpgpkey. Assuming we have agreement, I can tackle that draft accordingly. Sean From nobody Fri Mar 11 04:51:47 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CBF412D6DA; Fri, 11 Mar 2016 04:51:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.001] autolearn=no 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 yaovm1P1s3m3; Fri, 11 Mar 2016 04:51:44 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 8FAFE12D6E0; Fri, 11 Mar 2016 04:51:41 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3qM6Tl66FWz23X; Fri, 11 Mar 2016 13:51:39 +0100 (CET) X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id NFcYH1Qd2BZ2; Fri, 11 Mar 2016 13:51:39 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 11 Mar 2016 13:51:39 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 33E006000315; Fri, 11 Mar 2016 07:51:38 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 33E006000315 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 2FA10A3C7; Fri, 11 Mar 2016 07:51:38 -0500 (EST) Date: Fri, 11 Mar 2016 07:51:38 -0500 (EST) From: Paul Wouters To: Sean Leonard In-Reply-To: <56E0B710.10402@seantek.com> Message-ID: References: <56E0B710.10402@seantek.com> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: ietf-smtp@ietf.org, dane@ietf.org Subject: Re: [dane] "decoded local-part" for dane-smime and dane-openpgp X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 12:51:46 -0000 On Wed, 9 Mar 2016, Sean Leonard wrote: > Subject: [dane] "decoded local-part" for dane-smime and dane-openpgp > The problem is that this text does not distinguish between the local-part > production, and the decoded (unescaped) local-part characters. > > As I am discussing in another Internet-Draft elsewhere (in progress, not > necessary to cover right now here), the local-part has evolved basically to > be a string of Unicode scalar values, which may or may not be escaped or > quoted. Specifically: > It is therefore appropriate that the local-part be isolated from the entire > e-mail address production, and unescaped/unquoted (i.e., decoded). All three > I propose similar text for draft-ietf-dane-openpgpkey. Assuming we have > agreement, I can tackle that draft accordingly. I believe the chairs stated that the experiments of dane for openpgpkey and smime can continue without tackling every corner case of local-parts. Fixing the local-parts is up to th email community, not the dane community. So while I encourage your comments and drafts, I don't believe at this point any changes should be made to either dane document. Paul From nobody Fri Mar 11 05:02:27 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADFD012D6E1; Fri, 11 Mar 2016 05:02:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-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 DCTW5c-pOYXi; Fri, 11 Mar 2016 05:02:18 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 C9F7212D6D4; Fri, 11 Mar 2016 05:01:57 -0800 (PST) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 76A0F509B5; Fri, 11 Mar 2016 08:01:54 -0500 (EST) To: Paul Wouters References: <56E0B710.10402@seantek.com> From: Sean Leonard Message-ID: <56E2C137.2050304@seantek.com> Date: Fri, 11 Mar 2016 04:59:35 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: ietf-smtp@ietf.org, dane@ietf.org Subject: Re: [dane] "decoded local-part" for dane-smime and dane-openpgp X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 13:02:20 -0000 On 3/11/2016 4:51 AM, Paul Wouters wrote: > On Wed, 9 Mar 2016, Sean Leonard wrote: > >> Subject: [dane] "decoded local-part" for dane-smime and dane-openpgp > >> The problem is that this text does not distinguish between the >> local-part production, and the decoded (unescaped) local-part >> characters. >> >> As I am discussing in another Internet-Draft elsewhere (in progress, >> not necessary to cover right now here), the local-part has evolved >> basically to be a string of Unicode scalar values, which may or may >> not be escaped or quoted. Specifically: > >> It is therefore appropriate that the local-part be isolated from the >> entire e-mail address production, and unescaped/unquoted (i.e., >> decoded). All three > >> I propose similar text for draft-ietf-dane-openpgpkey. Assuming we >> have agreement, I can tackle that draft accordingly. > > I believe the chairs stated that the experiments of dane for > openpgpkey and smime can continue without tackling every corner case > of local-parts. Fixing the local-parts is up to th email community, > not the dane community. There is nothing to "fix" in this comment. "paul"@nohats.ca "p\a\u\l"@nohats.ca paul@nohats.ca are all distinct e-mail address strings, that represent the local part: paul This is hardly a corner case; it's just the way that e-mail addresses work. Are you saying that you believe that those three variations should result in three different SHA-256 hashes? Sean From nobody Fri Mar 11 15:06:37 2016 Return-Path: X-Original-To: dane@ietf.org Delivered-To: dane@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA8A12DDE0; Fri, 11 Mar 2016 15:05:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160311230530.15028.14792.idtracker@ietfa.amsl.com> Date: Fri, 11 Mar 2016 15:05:30 -0800 Archived-At: Cc: dane@ietf.org Subject: [dane] dane - Requested session has been scheduled for IETF 95 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 23:05:30 -0000 Dear Warren Kumari, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. dane Session 1 (1:00:00) Wednesday, Afternoon Session II 1620-1720 Room Name: Atlantico B size: 125 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: DNS-based Authentication of Named Entities Area Name: Security Area Session Requester: Warren Kumari Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 80 Conflicts to Avoid: First Priority: curdle dprive capport dots opsawg Second Priority: dnsop dbound saag dnssd Special Requests: --------------------------------------------------------- From nobody Sun Mar 20 13:54:03 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C928912D564 for ; Sun, 20 Mar 2016 13:54:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 gXBQOaQNNGES for ; Sun, 20 Mar 2016 13:54:00 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACB7412D52E for ; Sun, 20 Mar 2016 13:54:00 -0700 (PDT) Received: (qmail 89746 invoked from network); 20 Mar 2016 20:53:59 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 20 Mar 2016 20:53:59 -0000 Date: 20 Mar 2016 20:53:37 -0000 Message-ID: <20160320205337.43473.qmail@ary.lan> From: "John Levine" To: dane@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dane] DANE meeting at IETF95 in BA X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2016 20:54:02 -0000 >Unless we hear compelling requests for agenda time soon, we will be >cancelling the meeting. So, uh, is there a meeting? I see there's a slot assigned, but I don't see an agenda. It's at the same time as ianaplan, so some of us would not be heartbroken to have one less conflict. R's, John From nobody Sun Mar 20 13:57:47 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ECA612D784 for ; Sun, 20 Mar 2016 13:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-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 UUDfvcozaCJy for ; Sun, 20 Mar 2016 13:57:44 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 603A812D515 for ; Sun, 20 Mar 2016 13:57:44 -0700 (PDT) Received: from [192.168.122.101] (unknown [98.176.33.211]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 2C07F509B6; Sun, 20 Mar 2016 16:57:42 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Sean Leonard In-Reply-To: <20160320205337.43473.qmail@ary.lan> Date: Sun, 20 Mar 2016 13:57:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3DAF1258-8C32-4097-85F8-0AED18616EAB@seantek.com> References: <20160320205337.43473.qmail@ary.lan> To: John Levine X-Mailer: Apple Mail (2.3112) Archived-At: Cc: dane@ietf.org Subject: Re: [dane] DANE meeting at IETF95 in BA X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2016 20:57:46 -0000 > On Mar 20, 2016, at 1:53 PM, John Levine wrote: >=20 >> Unless we hear compelling requests for agenda time soon, we will be >> cancelling the meeting. >=20 > So, uh, is there a meeting? =20 >=20 > I see there's a slot assigned, but I don't see an agenda. It's at the > same time as ianaplan, so some of us would not be heartbroken to have > one less conflict. For my part, I would like a meeting to happen... But given the paucity of agenda items, I think a half-meeting would be = okay... Sean From nobody Sun Mar 20 16:54:52 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8471C12D555 for ; Sun, 20 Mar 2016 16:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com 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 hDrUJfXoD4li for ; Sun, 20 Mar 2016 16:54:50 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36E3F12D51A for ; Sun, 20 Mar 2016 16:54:50 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id h65so55759627ywe.0 for ; Sun, 20 Mar 2016 16:54:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=DMy/mrW1fxRsbltAS19YDQreI/n3YSbAog9GqfNVxvU=; b=cOPYtBdGN4JpEtzlNdQh+u6XmzIqJ9XlvGBgiohwvYriuVBuAckPWHkJrKCxItB1u2 GgRE0qZjycMa7Q7cc1vJUYO5EOhVJ140itv8XW8qw/Z9GnZKvn3HrlcOVKmiNkV2r/QX sowjxcZXj8AjESZCgF8vPGJk4zofGwQVhOwrsjiR2Q9AylMyjHrPJ3gUS+413qikV//A 17mCljYRMsnRmz5N5vwQrwdsP9hRASrJwILyZdwT3K70FJVBFT4de3rPb598hKnArB14 /3uAorTBYDkNfpygfnV18QJDJJaG60cchWKkC9oD0zl3v09Ht2h3eueO1YoDFZPD1RhY oPzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=DMy/mrW1fxRsbltAS19YDQreI/n3YSbAog9GqfNVxvU=; b=Ceoot9ss0S6CVN6rl5LK5aXdNfK3xyy48fJ5j5DQubwni5gFEplITvag061DdC9z2P IthLhn9OTbq13blhzM5zCOtWcH48nwoZA5v1ijSt/umL0kAduinIT4Hfmy5XYSVEO+KJ fOKQzw5v4IeaxCHMzW1mVTrwr98FlX/IT1s54lB4gY/zmK/+DfsDhUhdIXda9usv3Fa1 3Os/eIIXMkPgaQRrSloYy2Cylf4UpgUIFAKBbFnlX+HVhnrxD8u1M8+wJ0sXrt7kkrHL lQpxqsP7/O8FtDGpxZFMNSgpJivkhkQCksjpN1oS1pfqLh0jUaeD26/BpGYvB4t4KQBV EWRQ== X-Gm-Message-State: AD7BkJJXwZgJAAeVeQxRac308cEmhsD09N7m/GB8K8DEGNo5+08FoNrlVz78B5rO6PcxNlGZxnmwL6f5i3KNH0sa X-Received: by 10.129.124.70 with SMTP id x67mr6408131ywc.333.1458518089360; Sun, 20 Mar 2016 16:54:49 -0700 (PDT) MIME-Version: 1.0 References: <20160320205337.43473.qmail@ary.lan> In-Reply-To: <20160320205337.43473.qmail@ary.lan> From: Warren Kumari Date: Sun, 20 Mar 2016 23:54:39 +0000 Message-ID: To: John Levine , dane@ietf.org Content-Type: multipart/alternative; boundary=001a11494ad49d9a99052e83b4b4 Archived-At: Subject: Re: [dane] DANE meeting at IETF95 in BA X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2016 23:54:51 -0000 --001a11494ad49d9a99052e83b4b4 Content-Type: text/plain; charset=UTF-8 On Sun, Mar 20, 2016 at 3:54 PM John Levine wrote: > >Unless we hear compelling requests for agenda time soon, we will be > >cancelling the meeting. > > So, uh, is there a meeting? > > I see there's a slot assigned, but I don't see an agenda. It's at the > same time as ianaplan, so some of us would not be heartbroken to have > one less conflict. > Apologies for the delay, and keeping everyone hanging. I'm home for a few days ("I just flew back from Macau, and boy, are my arms tired") and Olafur and I should be able to discuss and make a final decision tomorrow. At the moment I'm leaning towards not meeting, but to be brutally honest, I'm behind on emails and so want to confirm with Olafur. W > > R's, > John > --001a11494ad49d9a99052e83b4b4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun= , Mar 20, 2016 at 3:54 PM John Levine <johnl@taugh.com> wrote:
&g= t;Unless we hear compelling requests for agenda time soon, we will be
>cancelling the meeting.

So, uh, is there a meeting?

I see there's a slot assigned, but I don't see an agenda.=C2=A0 It&= #39;s at the
same time as ianaplan, so some of us would not be heartbroken to have
one less conflict.

Apologies for the de= lay, and keeping everyone hanging. I'm home for a few days ("I jus= t flew back from Macau, and boy, are my arms tired") and Olafur and I = should be able to discuss and make a final decision tomorrow.=C2=A0

At the moment I'm leaning towards not meeting, but to= be brutally honest, I'm behind on emails and so want to confirm with O= lafur.

W
=C2=A0

R's,
John
--001a11494ad49d9a99052e83b4b4-- From nobody Mon Mar 21 06:58:08 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 567BD12D5E0 for ; Mon, 21 Mar 2016 06:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 05ka1dpEbmjG for ; Mon, 21 Mar 2016 06:58:05 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEA9C12D85B for ; Mon, 21 Mar 2016 06:58:04 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 21 Mar 2016 09:59:41 -0400 Received: from postmark.nist.gov (129.6.16.94) by WSXGHUB1.xchange.nist.gov (129.6.18.96) with Microsoft SMTP Server (TLS) id 8.3.444.0; Mon, 21 Mar 2016 09:58:03 -0400 Received: from [129.6.140.7] (7-140.antd.nist.gov [129.6.140.7]) by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id u2LDvmqU012391 for ; Mon, 21 Mar 2016 09:57:48 -0400 From: "Rose, Scott" To: Date: Mon, 21 Mar 2016 09:57:56 -0400 Message-ID: <9750158A-972D-4A94-A4A2-61A36E31675F@nist.gov> In-Reply-To: <3DAF1258-8C32-4097-85F8-0AED18616EAB@seantek.com> References: <20160320205337.43473.qmail@ary.lan> <3DAF1258-8C32-4097-85F8-0AED18616EAB@seantek.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.4r5234) X-NIST-MailScanner-Information: Archived-At: Subject: Re: [dane] DANE meeting at IETF95 in BA X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 13:58:08 -0000 On 20 Mar 2016, at 16:57, Sean Leonard wrote: >> On Mar 20, 2016, at 1:53 PM, John Levine wrote: >> >>> Unless we hear compelling requests for agenda time soon, we will be >>> cancelling the meeting. >> >> So, uh, is there a meeting? >> >> I see there's a slot assigned, but I don't see an agenda. It's at >> the >> same time as ianaplan, so some of us would not be heartbroken to have >> one less conflict. > > For my part, I would like a meeting to happen... > > But given the paucity of agenda items, I think a half-meeting would be > okay... > I don’t think we need to rehash the LHS issue again, but there are still two WG drafts, and there was talk of possible next steps. Is that still planned? Scott === Scott Rose, NIST scottr@nist.gov ph: +1-301-975-8439 Google Voice: +1-571-249-3671 From nobody Mon Mar 21 12:20:34 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECFAA12DA59 for ; Mon, 21 Mar 2016 12:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com 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 rU7ziEv7xQC9 for ; Mon, 21 Mar 2016 12:20:25 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 497B512D9F0 for ; Mon, 21 Mar 2016 12:20:25 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id h65so84247646ywe.0 for ; Mon, 21 Mar 2016 12:20:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=y+zcYRF6XseXT+JONpm1XCKL7zeNvTqGVfHpeAm15Tw=; b=BJsmwCmnk4pBsJjaVWBrARBvKzm4DIMRJLB8zlWdnKnzyBjS7bL0V/wD7+TwXtvaHR q1kbycvMdt+1HmRvi/yGhcLjtoMXQUPI4HVf219dZ2/mH345ZraQhAY81D3N5mQqKGXv kCtsvGiJ0hr95otPvdL0huVDU3mlt3xEMgPh2fPSc4v+bu2xQrpPRom65ZfFTENt7KlY G+p4QGDehinoEQTyxB8vgVtxBxJ8jJRehd8lbFW+/m65RSpFcExlHD7fk+qzO/z60iP1 2XbhQchSK3KJ9K/a8gHujTXGsvGqWZZkc9bCNfCzgLF1/XGS8p+sigeKhLQmTa3aQFhd oCmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=y+zcYRF6XseXT+JONpm1XCKL7zeNvTqGVfHpeAm15Tw=; b=kHRmbFfyUU9HEkU1ioRsKxDC9KZ/8JEi+iqovofSvB4PQiu7xf2LRJrj0p0FdKoUrM /rV14ywSkK7W92QfxCXIbOf1SO0DcATwFywe6/wu0wS4Qk91P9QmNMNOY3dtdsjtoFqa tYm/d7QLrvBbV6TSrISH4p9Jso7guVZnp6GrWCc45cQF3ySniKV0YikkdixvTS8SR8Ml nvP/Y+6jjgZ02aKfooNNO7qZ6EtI6VHGdo9lvlWEOULIGbT1j8Hdr3l+p6Va2TzsH+/2 /7TvTj1K1J3ga09tN2VI9YEWlkbyvFgsPoUmd3jrvQ8JT47wtvSwduS72Kz8Z+HJw4Ao PI7g== X-Gm-Message-State: AD7BkJLkHWjtnpGOw2Y4f5BVBOBKGpnIK8ojjhg7Ibp3B2zrjzu9irY1lj4e6e8LXJQfIxnMchzdejOQFidvZneG X-Received: by 10.129.124.70 with SMTP id x67mr8786304ywc.333.1458588024445; Mon, 21 Mar 2016 12:20:24 -0700 (PDT) MIME-Version: 1.0 From: Warren Kumari Date: Mon, 21 Mar 2016 19:20:15 +0000 Message-ID: To: "" Content-Type: multipart/alternative; boundary=001a11494ad4126970052e93fd94 Archived-At: Subject: [dane] Cancelled: DANE meeting at IETF95. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 19:20:29 -0000 --001a11494ad4126970052e93fd94 Content-Type: text/plain; charset=UTF-8 Dear Colleagues The chairs scheduled a meeting and asked for agenda items. At this point there is insufficient material for us to justify meeting in person thus we are canceling the meeting. We hope that DNSOP may be able to take our slot (DNS-OARC meets just before the IETF meeting, and having a DNSOP slot earlier in the week may allow more overlap). There is interesting discussion going on the IETF mailing list about OpenPGP draft and the interaction with mail; it may make sense to have a small side gathering to hash out these thoughts / discuss forming a working group to work on this larger issue. If you are interested in being involved drop Olafur a line Olafur & Warren --001a11494ad4126970052e93fd94 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Colleagues

The chairs s= cheduled a meeting and asked for agenda items.
At this point ther= e is insufficient material for us to justify meeting in person thus we are = canceling the meeting. We hope that
DNSOP may be able to take our= slot (DNS-OARC meets just before the IETF meeting, and having a DNSOP slot= earlier in the week may allow more overlap).

Ther= e is interesting discussion going on the IETF mailing list about OpenPGP dr= aft and the interaction with mail; it may make sense to
have a sm= all side gathering to hash out these thoughts / discuss forming a working g= roup to work on this larger issue.
If you are interested in being= involved drop Olafur a line

Olafur & Warren
--001a11494ad4126970052e93fd94-- From nobody Tue Mar 22 15:57:46 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED26D12D1B3; Tue, 22 Mar 2016 15:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-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 a6SKXzfSKrjU; Tue, 22 Mar 2016 15:57:41 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 21FDE12D1A1; Tue, 22 Mar 2016 15:57:41 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id F31C8509B5; Tue, 22 Mar 2016 18:57:39 -0400 (EDT) References: <56F1CD23.2040002@seantek.com> To: "pkix@ietf.org" , dane@ietf.org From: Sean Leonard X-Forwarded-Message-Id: <56F1CD23.2040002@seantek.com> Message-ID: <56F1CE3D.6010609@seantek.com> Date: Tue, 22 Mar 2016 15:59:09 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56F1CD23.2040002@seantek.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [dane] [fyi] BCP proposal: regular expressions for Internet Mail identifiers X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 22:57:43 -0000 [+PKIX and DANE] To those not on the lists below, this is an FYI about a new work proposal for regular expressions for email address and Message-ID identifiers. The original thread is just on ietf-smtp and dispatch, to avoid excessive cross-posting. The draft is draft-seantek-mail-regexen-00. Thank you. -------- Forwarded Message -------- Subject: [dispatch] BCP proposal: regular expressions for Internet Mail identifiers Date: Tue, 22 Mar 2016 15:54:27 -0700 To: ietf-smtp@ietf.org, dispatch@ietf.org Greetings IETF-SMTP Gods and Denizens (and dispatch): Over the winter I worked on a new Internet-Draft that I would like to propose the IETF adopts: Regular Expressions for Internet Mail. The draft focuses on two identifiers: email addresses and Message-IDs. The purpose of this standard (proposed as a Best Current Practice) is to have *IETF-vetted* expressions that implementers and non-mail standards authors can plug-and-chug without futzing with trying to interpret 40 years of (occasionally conflicting and arcane) RFCs and implementation lore. There are many non-mail systems out there (read: nearly every web app, reservation system, customer database, etc. on Earth) that use or consume email addresses as identifiers, and their inability to accept the most obvious valid characters (like "+" or even "-"; I have used apps that do not even accept "-") is a great source of interoperability problems. (This document is also relevant to some other threads about the nature of email address identifiers in security artifacts such as certificates, PGP keys, and DNS records: anyone who is vouching for an email address ought to be sure that they are recording something that actually is a valid email address in the first place.) We should get this right now, before Unicode/EAI makes interoperability issues 50000x more expensive to correct. The document is not meant to modify the mail standards, but merely to reflect and track them as they are updated over time. As a first draft, the document is in rough shape and has extensive notes about issues that came up during R&D but have yet to be addressed. Significant areas that need adequate treatment include: 1. the impact of Unicode (EAI) on identifiers. 2. handling domain names, which comprise 50% of an email address, but perhaps 85% of the complexity when Unicode gets involved. 2. "deliverable email address" (complying with the modern SMTP infrastructure) vs. other kinds of email addresses (Internet Message Format, historic forms). 3. regular expression engines and grammars (i.e., which grammars to use, which are widely used and produce uniform results). 4. efficiency of the regular expressions. 5. different expressions for validation (testing), part extraction (capturing groups), decoding, encoding, and searching through text. 6. test vectors. Hopefully the adoption of this work as an IETF item, coupled with input from those with extensive experience (Thanks to John Levine, Pete Resnick, and others for taking initial questions and discussion on the topic.) Discussion welcome. Thanks. Sean -------- Forwarded Message -------- Subject: New Version Notification for draft-seantek-mail-regexen-00.txt Date: Mon, 21 Mar 2016 16:55:53 -0700 From: internet-drafts@ietf.org A new version of I-D, draft-seantek-mail-regexen-00.txt has been successfully submitted by Sean Leonard and posted to the IETF repository. Name: draft-seantek-mail-regexen Revision: 00 Title: Regular Expressions for Internet Mail Document date: 2016-03-21 Group: Individual Submission Pages: 24 URL: https://www.ietf.org/internet-drafts/draft-seantek-mail-regexen-00.txt Status: https://datatracker.ietf.org/doc/draft-seantek-mail-regexen/ Htmlized: https://tools.ietf.org/html/draft-seantek-mail-regexen-00 Abstract: Internet Mail identifiers are used ubiquitously throughout computing systems as building blocks of online identity. Unfortunately, incomplete understandings of the syntaxes of these identifiers has led to interoperability problems and poor user experiences. Many users use specific characters in their addresses that are not properly accepted on various systems. This document prescribes normative regular expression (regex) patterns for all Internet- connected systems to use when validating or parsing Internet Mail identifiers, with special attention to regular expressions that work with popular languages and platforms. _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch