From nobody Mon Dec 1 01:30:49 2014 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 AAB621A1AD0 for ; Mon, 1 Dec 2014 01:30:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 0dsD3jOqZTqs for ; Mon, 1 Dec 2014 01:30:46 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 520A91A1AA9 for ; Mon, 1 Dec 2014 01:30:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BC94CBEAF; Mon, 1 Dec 2014 09:30:45 +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 W2npD5OKi7kM; Mon, 1 Dec 2014 09:30:44 +0000 (GMT) Received: from [10.87.48.11] (unknown [86.46.28.169]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B1126BEA1; Mon, 1 Dec 2014 09:30:44 +0000 (GMT) Message-ID: <547C3544.60003@cs.tcd.ie> Date: Mon, 01 Dec 2014 09:30:44 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Peter Saint-Andre - &yet , dane@ietf.org References: <20141201013357.GF285@mournblade.imrryr.org> <547BC8F9.1070605@andyet.net> In-Reply-To: <547BC8F9.1070605@andyet.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/yvW73b7l07BhGUHI_vK_VHUPTco Subject: Re: [dane] WGLC: DANE-SRV 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, 01 Dec 2014 09:30:47 -0000 Hi Peter, On 01/12/14 01:48, Peter Saint-Andre - &yet wrote: > >> A git repo >> with many commits? > > That is not covered by IETF IPR rules. Just to note that some other WGs (e.g. HTTPbis, tls) are successfully using git repos for drafts and issue tracking. That can work and not be a problem with IETF IPR processes, but it does need to be managed and is some new work for the chairs, so it's not quite "free." Cheers, S. From nobody Mon Dec 1 08:20:52 2014 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 10CA01A6F52 for ; Mon, 1 Dec 2014 08:20:43 -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_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 a9PpGEKP3njR for ; Mon, 1 Dec 2014 08:20:40 -0800 (PST) Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com [209.85.213.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3100A1A6F3E for ; Mon, 1 Dec 2014 08:19:53 -0800 (PST) Received: by mail-ig0-f169.google.com with SMTP id hl2so14711575igb.4 for ; Mon, 01 Dec 2014 08:19:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Qhj9F4Pe8zGHHXjJ34GcCbSUrN3B8ujnFRvFb2uwL0g=; b=QhOG4NvGRfRuw5ONUntYmicr5lkXkv8Z8KK4AZm4SoR3PnSoXDPcC4Z+IzNmSN+KaN Vrj5i/HipisSr6jAHDDUDqyR6sdBzGYSITv9gFBsfLAcC8tB6Z+OM/birHtom2vtddZM tZsT1l0jKolTnnPDs9BAOxaeEBcZaHUjOaFORP+MMO+yKK5aSUGX8HWtuZnKBsDcoxqJ AO9s+4NkWL0a8BdNzdWhX8rldIfHGMaTAaft8txmtO3DvqDnDyEFrvqC3jG8jyuAYC5u uVDPI5J6PezAjUZDNe0sIkYfDFaJ/dxBOLd3LjYzjAW4h2jSSFMVr85bSlw37UDwOs2o 8NAg== X-Gm-Message-State: ALoCoQkFiO9HQxcRbbcqrHp8ZkXWCALWVmhQH80XEoC7DHJf1Rv+317LvuXhicn6+iZuGZP4sNU/ X-Received: by 10.50.154.33 with SMTP id vl1mr47244935igb.48.1417450792631; Mon, 01 Dec 2014 08:19:52 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id c62sm9734200ioe.22.2014.12.01.08.19.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Dec 2014 08:19:51 -0800 (PST) Message-ID: <547C9526.8040404@andyet.net> Date: Mon, 01 Dec 2014 09:19:50 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Stephen Farrell , dane@ietf.org References: <20141201013357.GF285@mournblade.imrryr.org> <547BC8F9.1070605@andyet.net> <547C3544.60003@cs.tcd.ie> In-Reply-To: <547C3544.60003@cs.tcd.ie> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/yfN8cgbA1g_7VAY79QWVYohmpN0 Subject: Re: [dane] WGLC: DANE-SRV 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, 01 Dec 2014 16:20:43 -0000 On 12/1/14, 2:30 AM, Stephen Farrell wrote: > > Hi Peter, > > On 01/12/14 01:48, Peter Saint-Andre - &yet wrote: >> >>> A git repo >>> with many commits? >> >> That is not covered by IETF IPR rules. > > Just to note that some other WGs (e.g. HTTPbis, tls) are > successfully using git repos for drafts and issue tracking. > That can work and not be a problem with IETF IPR processes, > but it does need to be managed and is some new work for the > chairs, so it's not quite "free." Well, I'll leave that up to the chairs, then. :-) Peter -- Peter Saint-Andre https://andyet.com/ From nobody Tue Dec 2 09:52:26 2014 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 AC0791A212A for ; Tue, 2 Dec 2014 09:52:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 JA6L4Ddu8oMi for ; Tue, 2 Dec 2014 09:52:11 -0800 (PST) Received: from smtp92.ord1c.emailsrvr.com (smtp92.ord1c.emailsrvr.com [108.166.43.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAD3D1A2130 for ; Tue, 2 Dec 2014 09:52:10 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp4.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 187871800DA for ; Tue, 2 Dec 2014 12:52:10 -0500 (EST) X-Virus-Scanned: OK Received: by smtp4.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 8B7B7180198 for ; Tue, 2 Dec 2014 12:52:09 -0500 (EST) X-Sender-Id: ogud@ogud.com Received: from [10.20.30.43] (pool-74-96-189-180.washdc.fios.verizon.net [74.96.189.180]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.3.2); Tue, 02 Dec 2014 17:52:09 GMT From: Olafur Gudmundsson Content-Type: multipart/alternative; boundary="Apple-Mail=_A0A32FFB-0DE3-4A07-8AE3-B07E4CB8CFB6" Date: Tue, 2 Dec 2014 12:52:08 -0500 References: <0DAFC2A8-A1E2-46F4-BA52-E8261CB09159@ogud.com> To: "" Message-Id: <1B6695EC-E504-4EE9-B737-B3D545FCF387@ogud.com> Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/mE3ns74sz3cW5Q795q5nhZT68UY Subject: [dane] Reminder: WGLC: DANE-SRV & DANE-SMTP 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, 02 Dec 2014 17:52:12 -0000 --Apple-Mail=_A0A32FFB-0DE3-4A07-8AE3-B07E4CB8CFB6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Dear Colleagues=20 please review these documents and let us know if they are ready to = advance or not.=20 thanks Olafur & Warren=20 > Begin forwarded message: >=20 > From: Olafur Gudmundsson > Subject: WGLC: DANE-SRV & DANE-SMTP > Date: November 12, 2014 at 11:09:41 PM EST > To: "" >=20 > Dear wg members >=20 > This email message starts a three week WGLC ending on December 4=92th = at 23:59 UTC.=20 >=20 > http://tools.ietf.org/wg/dane/draft-ietf-dane-srv = > and=20 > https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-13 = >=20 > These two document are specifying related uses of DANE.=20 > Please review the documents carefully, in particular we want to make = sure the documents have no=20 > contradictions.=20 >=20 > We need at least 5 members of the working group to state in public = that they have read the documents and=20 > state what is needed to fixed before the documents are advanced.=20 >=20 > I will act as document shepherd for these two documents.=20 >=20 > Olafur & Warren --Apple-Mail=_A0A32FFB-0DE3-4A07-8AE3-B07E4CB8CFB6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Dear Colleagues 

please review these documents and let us know if = they are ready to advance or not. 
thanks
Olafur = & Warren 

Begin forwarded message:

From: = Olafur Gudmundsson <ogud@ogud.com>
Subject: = WGLC: DANE-SRV = & DANE-SMTP
Date: November 12, 2014 at 11:09:41 PM EST
To: = "<dane@ietf.org>" <dane@ietf.org>

Dear wg members

This = email message starts a three week WGLC ending on December 4=92th at = 23:59 UTC. 

http://tools.ietf.org/wg/dane/draft-ietf-dane-srv
and 
https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-13

These two document are specifying = related uses of DANE. 
Please review the documents = carefully, in particular we want to make sure the documents have = no 
contradictions. 

We need at least 5 members of the working group to state in = public that they have read the documents and 
state = what is needed to fixed before the documents are advanced. 

I will act as document shepherd for these two = documents. 

Olafur & = Warren

= --Apple-Mail=_A0A32FFB-0DE3-4A07-8AE3-B07E4CB8CFB6-- From nobody Tue Dec 2 10:16:44 2014 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 8B7D71A6FC7 for ; Tue, 2 Dec 2014 10:16:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 7JIKIkm8TCK9 for ; Tue, 2 Dec 2014 10:16:41 -0800 (PST) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56EB41A6F2A for ; Tue, 2 Dec 2014 10:15:07 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id n12so9463989wgh.8 for ; Tue, 02 Dec 2014 10:15:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=moQT5p0pHA5kCV7XykUq9EIiT3wqPiFNESu5iLmc8qQ=; b=kb7nEhBEVHVGw9MgftGd5E0WxhQvKGODZNqSKLG7ZzvsX3S9iXwMWdg/8rXyWir+m6 hJHh7Oy3TiR9D9aPA2BXqGHsSftaXo6DM8Anxp5H3+i/cha+zr/k0Xw/q+/QGNiDoj29 7Ht48J8xtA8OSOdGodl/TcAanlaXpTsoLoJGp/Sc1rBTyXmk8aO5gjJ1RYUmPABiXZKR 28oig50rqRAjPeprBAZIKknOFotlP8a/+8QoA9so4/jzRdlxxaRP7m8uL1KzIYkmhXok FCHBy5dEj8AlTFo4cElCgBb5uD8KKa+tbwptgbBt8U9QTmkhFHG8Wo3IKZk/k90GSvZW IxHQ== X-Gm-Message-State: ALoCoQm0KG2oZoBByoPxTX5RZcAYLqx0ANXTJMfuZPTVeOIyt+uXSxbFo9i6yC1FKa/KaGOVP50Z MIME-Version: 1.0 X-Received: by 10.180.86.38 with SMTP id m6mr7168466wiz.65.1417544106079; Tue, 02 Dec 2014 10:15:06 -0800 (PST) Received: by 10.194.64.37 with HTTP; Tue, 2 Dec 2014 10:15:06 -0800 (PST) Date: Tue, 2 Dec 2014 13:15:06 -0500 Message-ID: From: Warren Kumari To: "" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/oy_H3HVOPuNpT_mGnIieiamB7D0 Subject: [dane] Draft Minutes from interim meeting. 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, 02 Dec 2014 18:16:42 -0000 Hi all, DANE just had it's first interim meeting, and we think it went off really well. Thanks to everyone who participated, and to Russ and Doug who "volunteered" to take notes. They are posted here: http://www.ietf.org/proceedings/interim/2014/12/02/dane/minutes/minutes-interim-2014-dane-1 Please send any clarifications / updates within the next 7 days. W -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Tue Dec 2 14:33:26 2014 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 285031A1AF2 for ; Tue, 2 Dec 2014 14:33:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, 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 Tm9-tvB0i5hs for ; Tue, 2 Dec 2014 14:33:24 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0758.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::758]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CF7A1A1ADC for ; Tue, 2 Dec 2014 14:33:24 -0800 (PST) Received: from CY1PR0201MB0826.namprd02.prod.outlook.com (25.160.141.27) by CY1PR0201MB0826.namprd02.prod.outlook.com (25.160.141.27) with Microsoft SMTP Server (TLS) id 15.1.26.15; Tue, 2 Dec 2014 22:33:00 +0000 Received: from CY1PR0201MB0826.namprd02.prod.outlook.com ([25.160.141.27]) by CY1PR0201MB0826.namprd02.prod.outlook.com ([25.160.141.27]) with mapi id 15.01.0026.003; Tue, 2 Dec 2014 22:33:00 +0000 From: "Michael J. Sheldon" To: "dane@ietf.org" Thread-Topic: [dane] WGLC: DANE-SRV (Abstract and introduction feedback) Thread-Index: AQHQDRcir8VKa4YA+Ey10TpiT5Xhfpx84n60 Date: Tue, 2 Dec 2014 22:33:00 +0000 Message-ID: <1417559579751.81339@godaddy.com> References: <20141201013357.GF285@mournblade.imrryr.org> <547BC8F9.1070605@andyet.net>,<20141201033009.GI285@mournblade.imrryr.org> In-Reply-To: <20141201033009.GI285@mournblade.imrryr.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [72.223.77.6] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0201MB0826; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:CY1PR0201MB0826; x-forefront-prvs: 0413C9F1ED x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(24454002)(51704005)(2351001)(107886001)(107046002)(68736005)(120916001)(21056001)(50986999)(54356999)(76176999)(4396001)(99396003)(105586002)(106116001)(40100003)(97736003)(20776003)(2501002)(66066001)(106356001)(64706001)(122556002)(450100001)(36756003)(77156002)(31966008)(62966003)(117636001)(101416001)(46102003)(2656002)(99286002)(87936001)(95666004)(19580395003)(92726001)(92566001)(110136001)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0201MB0826; H:CY1PR0201MB0826.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: godaddy.com Archived-At: http://mailarchive.ietf.org/arch/msg/dane/878HQcodyJrUbV3Huc-ctAAStwc Subject: Re: [dane] WGLC: DANE-SRV (Abstract and introduction feedback) 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, 02 Dec 2014 22:33:26 -0000 >On Sun, Nov 30, 2014 at 06:48:41PM -0700, Peter Saint-Andre - &yet wrote:= =0A= >General comment:=0A= >=0A= > The draft frequently talks about "hostnames", where what is=0A= > really meant is a transport endpoint (port, transport protocol,=0A= > host). With PKIX-EE or DANE-EE certificate usages, TLSA records=0A= > are more precise than the Web PKI and can associate different,=0A= > non-interchangeable key material with distinct services on a=0A= > single host. So in many places I will be suggesting replacing=0A= > statements about "hostnames" with statements about "transport=0A= > endpoints".=0A= =0A= >From a DNS point of view, this may be more confusing. DNS does not distingu= ish between different types of record owners. If you put it in there, it ju= st became a domain name, which most people will refer to as a host name if = it is not at the apex.=0A= =0A= I will agree that from a DANE point of view, it is a transport endpoint. Bu= t from a pure DNS point of view, it is domain/host name, regardless of inte= nt.=0A= =0A= Not saying it's not a good distinction, it is, but I would tread lightly wh= ere you are talking about the actual TLSA record owner name.=0A= =0A= Michael Sheldon=0A= Dev-DNS Services=0A= GoDaddy.com=0A= From nobody Tue Dec 2 21:19:54 2014 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 305AB1A008C for ; Tue, 2 Dec 2014 21:19:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 s0PlqVov0b4Z for ; Tue, 2 Dec 2014 21:19:50 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C6681A008B for ; Tue, 2 Dec 2014 21:19:50 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 56BDE282D5F; Wed, 3 Dec 2014 05:19:49 +0000 (UTC) Date: Wed, 3 Dec 2014 05:19:49 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141203051949.GF285@mournblade.imrryr.org> References: <20141201013357.GF285@mournblade.imrryr.org> <547BC8F9.1070605@andyet.net> <20141201033009.GI285@mournblade.imrryr.org> <1417559579751.81339@godaddy.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1417559579751.81339@godaddy.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/bm9RoYCqfNf5aH69IGAEGdKwXBk Subject: Re: [dane] WGLC: DANE-SRV (Abstract and introduction feedback) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 05:19:52 -0000 On Tue, Dec 02, 2014 at 10:33:00PM +0000, Michael J. Sheldon wrote: > >On Sun, Nov 30, 2014 at 06:48:41PM -0700, Peter Saint-Andre - &yet wrote: > >General comment: > > > > The draft frequently talks about "hostnames", where what is > > really meant is a transport endpoint (port, transport protocol, > > host). With PKIX-EE or DANE-EE certificate usages, TLSA records > > are more precise than the Web PKI and can associate different, > > non-interchangeable key material with distinct services on a > > single host. So in many places I will be suggesting replacing > > statements about "hostnames" with statements about "transport > > endpoints". > > From a DNS point of view, this may be more confusing. DNS does > not distinguish between different types of record owners. If you > put it in there, it just became a domain name, which most people > will refer to as a host name if it is not at the apex. You misunderstood my point. The issue is not about DNS owner names. The issue is that SRV records designate a (port, hostname) pair, not just a hostname, and the input to TLSA lookup is a (port, protocol, hostname) triple not just a hostname. > Not saying it's not a good distinction, it is, but I would tread > lightly where you are talking about the actual TLSA record owner > name. I am not talking about DNS owner names at all. The association in DANE TLSA is between a transport endpoint and its key material. The fact that we construct some DNS name to find this is secondary, (and in fact that owner name is NOT a hostname due to the various underscores, but that's not important). Since SRV also produces lists of transport endpoints, and unlike the Web PKI, the certificates in DANE TLSA can (and often should) be different for different services on the same machine, the discussion is much clearer if we don't gloss over the fact that the TLSA binding is NOT a hostname->key binding. I hope to post further feedback on Thursday evening. It would be useful if possible to get additional initial reaction to the proposed changes in the abstract and introduction. -- Viktor. From nobody Wed Dec 3 00:10:42 2014 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 94AED1A010C for ; Wed, 3 Dec 2014 00:10:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.3 X-Spam-Level: ** X-Spam-Status: No, score=2.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_22=0.6, J_CHICKENPOX_25=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_46=0.6, J_CHICKENPOX_84=0.6] 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 G7xtX9RE_fgg for ; Wed, 3 Dec 2014 00:10:33 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCAAD1A0110 for ; Wed, 3 Dec 2014 00:10:32 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id C7B1F282D5F; Wed, 3 Dec 2014 08:10:31 +0000 (UTC) Date: Wed, 3 Dec 2014 08:10:31 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141203081031.GG285@mournblade.imrryr.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/1MCr-AGK4QaRjBAga6YXtlEBXhY Subject: Re: [dane] SMTP STARTTLS stripping in the wild X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 08:10:34 -0000 [ Resending, as this is not in the list archive, and Google does not seem to find it anywhere. Perhaps this never made it to the list. I am hoping someone from Comcast will read past the TL;DR to the end of the message and deploy real keys for their MX hosts. ] On Thu, Nov 13, 2014 at 02:59:04PM -0500, Paul Wouters wrote: > https://www.eff.org/deeplinks/2014/11/starttls-downgrade-attacks > > "In recent months, researchers have reported ISPs in the US and Thailand > intercepting their customers' data to strip a security flag?called > STARTTLS?from email traffic." > > > Thanks to Viktor, properly configured postfix clients deployed with DANE should > detect this and refuse to send the email unencrypted. Thanks for the nod in my direction. Note however, that we still need a lot more MTAs to adopt DNSSEC and publish TLSA RRs. Please encourage server operators to move forward. However, my curated list stands at 337 domains, with: * 1 with expired RRSIGs * 2 with DS RRs that don't match the zone keyset * 1 with an incorrect TLSA RR post key rotation * 1 with an incorrect TLSA usage (2 instead of 3). [ FWIW, since Nov 13th the working domain count has reached 441. ] In addition I've run into 8 domains with PKIX-EE(1) TLSA RRs which are not "usable" for SMTP. Therefore, I'd like to suggest that while system operators should adopt SMTP with DANE, they should not do so as "fashion statement". Do it right, or don't do it at all. Having a bunch of published broken domains discourages others from deploying and creates headaches for those who've enabled verification. The error rate would have been higher, were it not for some successes in notifying most of the problem domains of their mistakes, with almost all fixing the problem as a result. Once the new testing site is up and running, I'm hoping we can successfully "market" it to would-be SMTP with DANE operators, and avoid most mistakes in the future. The site will support testing of live systems (catch mistakes after the fact) and testing of planned configurations (catch mistakes before they happen). A Cable operator in Germany with ~500K users has enabled DANE. IIRC a Comcast engineer was present at the DANE meeting yesterday. Since the comcast.net zone is signed, I was hoping that a good step in the same direction might have been. _25._tcp.mx1.comcast.net. IN TLSA 3 1 1 3D0CE5F401FE33EFA5ADB136D1E6EDAFBD72DB82FEC50E3CB69CF0943ACBA8D4 _25._tcp.mx2.comcast.net. IN TLSA 3 1 1 3D0CE5F401FE33EFA5ADB136D1E6EDAFBD72DB82FEC50E3CB69CF0943ACBA8D4 Sadly the certificates in question appear to be from a stock keypair: Certificate: Data: Version: 3 (0x2) Serial Number: 2 (0x2) Signature Algorithm: sha1WithRSAEncryption Issuer: C=US, O=Sample, Inc., OU=IT Team, CN=CA Validity Not Before: Nov 18 14:58:26 2010 GMT Not After : Nov 15 14:58:26 2020 GMT Subject: C=US, O=Sample, Inc., OU=IT Team, CN=Server Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (1024 bit) Modulus: ... Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: Sample server certificate, do not use on production systems! ... Likely same key previously noted in: http://markgamache.blogspot.com/2014_01_01_archive.html https://community.virginmedia.com/t5/Email/Sample-server-certificate-do-not-use-on-production-systems/td-p/2142440 So we still have some way to go. -- Viktor. From nobody Wed Dec 3 20:06:29 2014 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 A27261A0025 for ; Wed, 3 Dec 2014 20:01:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.647 X-Spam-Level: X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-2.3] 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 TEHlUY8roMII for ; Wed, 3 Dec 2014 20:00:58 -0800 (PST) Received: from proper.com (Hoffman.Proper.COM [207.182.41.81]) (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 DAE1C1A002F for ; Wed, 3 Dec 2014 20:00:57 -0800 (PST) Received: from [10.20.30.90] (142-254-17-119.dsl.dynamic.fusionbroadband.com [142.254.17.119]) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id sB440trX080100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 3 Dec 2014 21:00:56 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 142-254-17-119.dsl.dynamic.fusionbroadband.com [142.254.17.119] claimed to be [10.20.30.90] Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Paul Hoffman In-Reply-To: Date: Wed, 3 Dec 2014 20:00:55 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6F20D61B-DB10-4ECA-9447-3A8DFD7137DA@vpnc.org> References: <0DAFC2A8-A1E2-46F4-BA52-E8261CB09159@ogud.com> To: "" X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/fUqAdjliHxQVnvaJwoKGRtmUh2o Subject: Re: [dane] WGLC: DANE-SRV & DANE-SMTP 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: Thu, 04 Dec 2014 04:01:01 -0000 I have read these two documents and they seem fine. I'm sure there will = be significant comments in IETF Last Call from folks in Apps Area, both = about the use of SRV and SMTP, and possibly technical changes based on = those, but as a WG product, both of these seem fine. --Paul Hoffman= From nobody Thu Dec 4 08:14:33 2014 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 D952B1AD478 for ; Thu, 4 Dec 2014 08:14:28 -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, 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 Tb7SqEhfrGza for ; Thu, 4 Dec 2014 08:14:26 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0714.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:714]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBB311AD486 for ; Thu, 4 Dec 2014 08:14:25 -0800 (PST) Received: from BY1PR09MB0440.namprd09.prod.outlook.com (25.160.109.22) by BY1PR09MB0549.namprd09.prod.outlook.com (25.160.110.139) with Microsoft SMTP Server (TLS) id 15.1.31.17; Thu, 4 Dec 2014 16:14:03 +0000 Received: from BY1PR09MB0439.namprd09.prod.outlook.com (25.160.109.21) by BY1PR09MB0440.namprd09.prod.outlook.com (25.160.109.22) with Microsoft SMTP Server (TLS) id 15.1.31.17; Thu, 4 Dec 2014 16:14:02 +0000 Received: from BY1PR09MB0439.namprd09.prod.outlook.com ([25.160.109.21]) by BY1PR09MB0439.namprd09.prod.outlook.com ([25.160.109.21]) with mapi id 15.01.0031.000; Thu, 4 Dec 2014 16:14:02 +0000 From: "Rose, Scott" To: dane WG list Thread-Topic: use case for naming convention in the DNS for sign/encrypt functionality Thread-Index: AQHQD91RwJfKriq3gEOhhMn9LNF6xQ== Date: Thu, 4 Dec 2014 16:14:01 +0000 Message-ID: <6A29A54A-14B2-4120-B952-26876E403B08@nist.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [132.163.218.222] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BY1PR09MB0440;UriScan:; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BY1PR09MB0440; x-forefront-prvs: 041517DFAB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(199003)(189002)(31966008)(4396001)(50986999)(33656002)(229853001)(82746002)(66066001)(99396003)(450100001)(110136001)(77156002)(20776003)(36756003)(102836002)(64706001)(62966003)(46102003)(15975445006)(19580395003)(106356001)(105586002)(87936001)(120916001)(19580405001)(83716003)(106116001)(92726001)(2656002)(97736003)(68736005)(99286002)(54356999)(101416001)(92566001)(122556002)(107046002)(21056001)(107886001)(40100003)(86362001)(15202345003)(104396002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR09MB0440; H:BY1PR09MB0439.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <259915FCBCFEC748B7B7D19EBC7DEC77@namprd09.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BY1PR09MB0549; X-OriginatorOrg: nist.gov Archived-At: http://mailarchive.ietf.org/arch/msg/dane/dGynFzi1OpCr6pnKaNfsWvjwNes Subject: [dane] use case for naming convention in the DNS for sign/encrypt functionality 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: Thu, 04 Dec 2014 16:14:29 -0000 >From the interim meeting -=20 Using a naming convention for designating sign/encrypt becomes useful when = CU=3D3 is used. If SMIMEA is going to follow the same interpretation as in= TLSA, then the client may not be doing any other checks or use any other p= arts of the cert such as the keyUsage field. They may not even be present = in the cert - just a bare bones X.509 that may not contain much beyond the = public key. So if an enterprise wants to use certs with CU=3D3 and separat= ion of roles, this functionality becomes useful. A varient of that could be an enterprise using a local trust anchor (CU 2) = for digital signature certs in a wildcard SMIMEA (to cover all domain users= ), and generating encryption certs and using CU=3D3 since clients won't be = able to perform full PKIX validation to the local trust anchor if they don'= t have it stored locally. In a way, the encryption certs could be views as= opportunistic S/MIME. So you have: *._sign._smimecert.example.com IN SMIMEA 2 0 1 and for each user that is allowed to accept encrypted mail: ._encr._smimecert.example.com IN SMIMEA 3 0 0 The draft will have to have some text to specify when a client should not r= ely on the keyUsage field in the cert, and what to do if the field is not p= resent in the cert at all. A lot of this can be done without the naming co= nvention, but it allows more flexibility and allows for easier management f= or some usage scenarios. =20 Scott =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Scott Rose NIST scott.rose@nist.gov +1 301-975-8439 Google Voice: +1 571-249-3671 http://www.dnsops.gov/ https://www.had-pilot.com/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From nobody Thu Dec 4 09:06:45 2014 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 7FE831A024C for ; Thu, 4 Dec 2014 09:06:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.71 X-Spam-Level: X-Spam-Status: No, score=-1.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] 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 htsPShE25USB for ; Thu, 4 Dec 2014 09:06:42 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F3E91AD4CD for ; Thu, 4 Dec 2014 09:06:40 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B2563817C1; Thu, 4 Dec 2014 12:06:38 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1417712798; bh=QDhaH+Ny2iJvkEFVHWyZmHwvWFbCUSGsVmvSQ2NiLY0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=LeyzEY1bzlZHliNQEzfXqvM2+R0B5SAI9rA6TAzrPJCdwnHqDFITi+ZBr/yqobAKl CgJFNaexF+CDnfdc30xQNDRM2jxURcBLoW4P2MXqexsoLBiqKhQIyA+HpLDX2kyHhR lYaIftWLu4casPfuBpZDdpZVn0HNKHCeU7OK2dh8= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id sB4H6cjq030109; Thu, 4 Dec 2014 12:06:38 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Thu, 4 Dec 2014 12:06:37 -0500 (EST) From: =?UTF-8?Q?Paul_Wouters_=F0=9F=94=93?= To: "Rose, Scott" In-Reply-To: <6A29A54A-14B2-4120-B952-26876E403B08@nist.gov> Message-ID: References: <6A29A54A-14B2-4120-B952-26876E403B08@nist.gov> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dane/5qlCqkcfJcjh8IfZ2eccSRfXYu0 Cc: dane WG list Subject: Re: [dane] use case for naming convention in the DNS for sign/encrypt functionality 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: Thu, 04 Dec 2014 17:06:43 -0000 On Thu, 4 Dec 2014, Rose, Scott wrote: > Using a naming convention for designating sign/encrypt becomes useful when CU=3 is used. If SMIMEA is going to follow the same interpretation as in TLSA, then the client may not be doing any other checks or use any other parts of the cert such as the keyUsage field. They may not even be present in the cert - just a bare bones X.509 that may not contain much beyond the public key. So if an enterprise wants to use certs with CU=3 and separation of roles, this functionality becomes useful. But RFC 6698 states: The difference between certificate usage 1 and certificate usage 3 is that certificate usage 1 requires that the certificate pass PKIX validation, but PKIX validation is not tested for certificate usage 3. The Certificate Usage that seems appropriate are the ones specifying it should do "full PKIX validation" (usage 1 or 2, not 3), which would include the EKU's to know whether the certificate is good for signing or encrypting. > A varient of that could be an enterprise using a local trust anchor (CU 2) for digital signature certs in a wildcard SMIMEA (to cover all domain users), and generating encryption certs and using CU=3 since clients won't be able to perform full PKIX validation to the local trust anchor if they don't have it stored locally. In a way, the encryption certs could be views as opportunistic S/MIME. So you have: > > *._sign._smimecert.example.com IN SMIMEA 2 0 1 > > and for each user that is allowed to accept encrypted mail: > ._encr._smimecert.example.com IN SMIMEA 3 0 0 What does an SMIMEA DNS record signify? I thought it meant "you can verify signatures on received email" and "you can send encrypted email using this encryption key". I do not think it can mean "this user is allowed to accept encrypted email". Whether or not to encrypt is a local policy of the sender. If and only if the sender wants to encrypt it, it will look for the appropriate encryption key. I would envision an organisation to either allow individual encryption keys, or a global encryption key. If you use a global encryption key, you might still want to have individual signatures of people within the organisation. So I can see that as a use case. That use case _could_ also be solved by having two keys: ._smimecert.example.com IN SMIMEA 2 0 1 ._smimecert.example.com IN SMIMEA 2 0 1 Where one has the signing EKU set and one has the encryption EKU set. This is much more straight forward and prevents situations where the EKU and the DNS _prefix disagree and eliminates a lot of corner cases. > The draft will have to have some text to specify when a client should not rely on the keyUsage field in the cert It should always rely on it for CU=1 and CU=2. And CU=3 should clearly not be used if there is domain policy covering an individual. >, and what to do if the field is not present in the cert at all. I would say PKIX validation determined an SMIME certificate without signing EKU cannot be used to verify signatures. An SMIME certificate without encryption EKU cannot be be used for sending encrypted email. (and if encryption is mandatory according to local policy, no email should be sent in the clear either) > A lot of this can be done without the naming convention, but it allows more flexibility and allows for easier management for some usage scenarios. In my experience with X.509 and IKE and various EKU's and interop, many vendors come up with many different EKU's related to the policy of authentication and encryption. I'd really prefer not to see a zillion _prefixes and a new RFC whenever a vendor comes up with a new EKU. Paul (and yes, I have had to do interop tests by adding 20 non-RFC EKU's to see if a certain phone vendor would finally use the damn certificate for IKE) From nobody Fri Dec 5 09:34:50 2014 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 CACD31A899C for ; Fri, 5 Dec 2014 07:23:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 qU98rj_beQW8 for ; Fri, 5 Dec 2014 07:23:03 -0800 (PST) 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 0B4281A89A8 for ; Fri, 5 Dec 2014 07:23:03 -0800 (PST) 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.210.2; Fri, 5 Dec 2014 10:22:52 -0500 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.377.0; Fri, 5 Dec 2014 10:23:01 -0500 Received: from 6-140.antd.nist.gov (6-140.antd.nist.gov [129.6.140.6]) by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id sB5FMtdP016562 for ; Fri, 5 Dec 2014 10:22:55 -0500 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Rose, Scott W." In-Reply-To: Date: Fri, 5 Dec 2014 10:22:52 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <6FDA22D1-153B-4926-88D2-3A9F1942A6EF@nist.gov> References: <6A29A54A-14B2-4120-B952-26876E403B08@nist.gov> To: dane WG list X-Mailer: Apple Mail (2.1878.6) X-NIST-MailScanner-Information: Archived-At: http://mailarchive.ietf.org/arch/msg/dane/Qv-21B8fcqQCnRdo8N2ew-iRRc4 X-Mailman-Approved-At: Fri, 05 Dec 2014 09:34:49 -0800 Subject: Re: [dane] use case for naming convention in the DNS for sign/encrypt functionality 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: Fri, 05 Dec 2014 15:23:09 -0000 On Dec 4, 2014, at 12:06 PM, Paul Wouters =F0=9F=94=93 = wrote: > On Thu, 4 Dec 2014, Rose, Scott wrote: >> A varient of that could be an enterprise using a local trust anchor = (CU 2) for digital signature certs in a wildcard SMIMEA (to cover all = domain users), and generating encryption certs and using CU=3D3 since = clients won't be able to perform full PKIX validation to the local trust = anchor if they don't have it stored locally. In a way, the encryption = certs could be views as opportunistic S/MIME. So you have: >>=20 >> *._sign._smimecert.example.com IN SMIMEA 2 0 1 >>=20 >> and for each user that is allowed to accept encrypted mail: >> ._encr._smimecert.example.com IN SMIMEA 3 0 0 >=20 > What does an SMIMEA DNS record signify? >=20 > I thought it meant "you can verify signatures on received email" and > "you can send encrypted email using this encryption key". >=20 > I do not think it can mean "this user is allowed to accept encrypted > email". Whether or not to encrypt is a local policy of the sender. If > and only if the sender wants to encrypt it, it will look for the > appropriate encryption key. >=20 It would be up to the org's policy about who can accept encrypted mail, = and it wouldn't necessarily be signaled by DANE, just if a client = discovers a cert that it can use to send encrypted mail, it could use = it. =20 > I would envision an organisation to either allow individual encryption > keys, or a global encryption key. If you use a global encryption key, > you might still want to have individual signatures of people within > the organisation. So I can see that as a use case. >=20 > That use case _could_ also be solved by having two keys: >=20 > ._smimecert.example.com IN SMIMEA 2 0 1 > ._smimecert.example.com IN SMIMEA 2 0 1 >=20 True, I admit there are several ways to publish the RR's > Where one has the signing EKU set and one has the encryption EKU set. >=20 > This is much more straight forward and prevents situations where the = EKU > and the DNS _prefix disagree and eliminates a lot of corner cases. >=20 >> The draft will have to have some text to specify when a client should = not rely on the keyUsage field in the cert >=20 > It should always rely on it for CU=3D1 and CU=3D2. And CU=3D3 should = clearly > not be used if there is domain policy covering an individual. >=20 I was thinking this too, but it isn't in the explicit in the text right = now. The problem I see is when an org decides to use CU 3 and doesn't = bother to include a keyUsage or EKU. If that isn't the case and can be = prevented with best common practices, then that is ideal. >> , and what to do if the field is not present in the cert at all. >=20 > I would say PKIX validation determined an SMIME certificate without > signing EKU cannot be used to verify signatures. An SMIME certificate > without encryption EKU cannot be be used for sending encrypted email. > (and if encryption is mandatory according to local policy, no email > should be sent in the clear either) >=20 >> A lot of this can be done without the naming convention, but it = allows more flexibility and allows for easier management for some usage = scenarios. >=20 > In my experience with X.509 and IKE and various EKU's and interop, = many > vendors come up with many different EKU's related to the policy of > authentication and encryption. I'd really prefer not to see a zillion > _prefixes and a new RFC whenever a vendor comes up with a new EKU. >=20 I wasn't aware of that - yes that is a problem and a good argument = against having DANE signal/confuse things. =20 Scott > Paul > (and yes, I have had to do interop tests by adding 20 non-RFC EKU's to = see > if a certain phone vendor would finally use the damn certificate for = IKE) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Scott Rose NIST scott.rose@nist.gov +1 301-975-8439 Google Voice: +1 571-249-3671 http://www.dnsops.gov/ https://www.had-pilot.com/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From nobody Fri Dec 5 14:19:06 2014 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 5A89B1A6F7D for ; Fri, 5 Dec 2014 14:19:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.647 X-Spam-Level: X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-2.3] 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 djAjs_zheR71 for ; Fri, 5 Dec 2014 14:19:03 -0800 (PST) Received: from proper.com (Hoffman.Proper.COM [207.182.41.81]) (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 A52AE1A6F68 for ; Fri, 5 Dec 2014 14:19:03 -0800 (PST) Received: from [10.118.130.94] (d1-4-13-143-118-on-nets.com [118.143.13.4] (may be forged)) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id sB5MIxIw080548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Dec 2014 15:19:02 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host d1-4-13-143-118-on-nets.com [118.143.13.4] (may be forged) claimed to be [10.118.130.94] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Paul Hoffman In-Reply-To: <6FDA22D1-153B-4926-88D2-3A9F1942A6EF@nist.gov> Date: Sat, 6 Dec 2014 06:18:58 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <1965262C-5F74-4BAE-A8C9-5C4B5D9463A4@vpnc.org> References: <6A29A54A-14B2-4120-B952-26876E403B08@nist.gov> <6FDA22D1-153B-4926-88D2-3A9F1942A6EF@nist.gov> To: "Rose, Scott W." X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/oLgMcr3Ty-YqzWk9j85T7wyexF8 Cc: dane WG list Subject: Re: [dane] use case for naming convention in the DNS for sign/encrypt functionality 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: Fri, 05 Dec 2014 22:19:05 -0000 On Dec 5, 2014, at 11:22 PM, Rose, Scott W. wrote: >=20 > On Dec 4, 2014, at 12:06 PM, Paul Wouters =F0=9F=94=93 = wrote: >=20 >> On Thu, 4 Dec 2014, Rose, Scott wrote: >>> A varient of that could be an enterprise using a local trust anchor = (CU 2) for digital signature certs in a wildcard SMIMEA (to cover all = domain users), and generating encryption certs and using CU=3D3 since = clients won't be able to perform full PKIX validation to the local trust = anchor if they don't have it stored locally. In a way, the encryption = certs could be views as opportunistic S/MIME. So you have: >>>=20 >>> *._sign._smimecert.example.com IN SMIMEA 2 0 1 >>>=20 >>> and for each user that is allowed to accept encrypted mail: >>> ._encr._smimecert.example.com IN SMIMEA 3 0 0 >>=20 >> What does an SMIMEA DNS record signify? >>=20 >> I thought it meant "you can verify signatures on received email" and >> "you can send encrypted email using this encryption key". >>=20 >> I do not think it can mean "this user is allowed to accept encrypted >> email". Whether or not to encrypt is a local policy of the sender. If >> and only if the sender wants to encrypt it, it will look for the >> appropriate encryption key. >>=20 > It would be up to the org's policy about who can accept encrypted = mail, and it wouldn't necessarily be signaled by DANE, just if a client = discovers a cert that it can use to send encrypted mail, it could use = it. This is a good point, and one that became clearer in the second draft of = draft-osterweil-dane-ent-email-reqs: not all requirements need to be met = by DANE. A separate set of DNS records could be used to say "I don't = care how you got that encryption key for that user: don't send encrypted = to them because they will never get it". >> I would envision an organisation to either allow individual = encryption >> keys, or a global encryption key. If you use a global encryption key, >> you might still want to have individual signatures of people within >> the organisation. So I can see that as a use case. >>=20 >> That use case _could_ also be solved by having two keys: >>=20 >> ._smimecert.example.com IN SMIMEA 2 0 1 >> ._smimecert.example.com IN SMIMEA 2 0 1 >>=20 >=20 > True, I admit there are several ways to publish the RR's This is one of the dangers of giving a use case that includes proposed = on-the-wire solutions. :-) >> Where one has the signing EKU set and one has the encryption EKU set. >>=20 >> This is much more straight forward and prevents situations where the = EKU >> and the DNS _prefix disagree and eliminates a lot of corner cases. >>=20 >>> The draft will have to have some text to specify when a client = should not rely on the keyUsage field in the cert >>=20 >> It should always rely on it for CU=3D1 and CU=3D2. And CU=3D3 should = clearly >> not be used if there is domain policy covering an individual. >>=20 > I was thinking this too, but it isn't in the explicit in the text = right now. The problem I see is when an org decides to use CU 3 and = doesn't bother to include a keyUsage or EKU. If that isn't the case = and can be prevented with best common practices, then that is ideal. This is a topic that came up in the interim meeting that I think is = critical for this WG: are the keyUsage and extendedKeyUsage fields in a = cert received in an SMIMEA response: - always paid attention to - never paid attention to (the key usage will be determined in other = ways) - something squishy in between? This also ties to the question of the interaction of SMIMEA records with = certs received in other ways. If we have rules for keyUsage and = extendedKeyUsage that are *different* based on where you got the cert, = we can be sure that this will be mis-implemented, and possibly for good = policy reasons. >>> , and what to do if the field is not present in the cert at all. >>=20 >> I would say PKIX validation determined an SMIME certificate without >> signing EKU cannot be used to verify signatures. An SMIME certificate >> without encryption EKU cannot be be used for sending encrypted email. >> (and if encryption is mandatory according to local policy, no email >> should be sent in the clear either) >>=20 >>> A lot of this can be done without the naming convention, but it = allows more flexibility and allows for easier management for some usage = scenarios. >>=20 >> In my experience with X.509 and IKE and various EKU's and interop, = many >> vendors come up with many different EKU's related to the policy of >> authentication and encryption. I'd really prefer not to see a zillion >> _prefixes and a new RFC whenever a vendor comes up with a new EKU. >>=20 > I wasn't aware of that - yes that is a problem and a good argument = against having DANE signal/confuse things. =20 Yes, but. Having _prefixes for SMIMEA for SMIME actions (signing and = encrypting) might be useful. We need to make it clearer that SMIMEA is a = way to get a user's S/MIME credentials; an org that wants to distribute = certs for other reasons would need to use a different RRtype. (And this = would help deal with the problem of case sensitivity as well...) --Paul Hoffman= From nobody Fri Dec 5 21:17:02 2014 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 720B91A8AC1 for ; Fri, 5 Dec 2014 21:17:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 mhFR4kGp2NGB for ; Fri, 5 Dec 2014 21:16:59 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38E751A8AC3 for ; Fri, 5 Dec 2014 21:16:58 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id A6247282FBF; Sat, 6 Dec 2014 05:16:57 +0000 (UTC) Date: Sat, 6 Dec 2014 05:16:57 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141206051657.GB285@mournblade.imrryr.org> References: <6A29A54A-14B2-4120-B952-26876E403B08@nist.gov> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/iP1ir2MTlfFAw9HdewyJdQibiq4 Subject: Re: [dane] use case for naming convention in the DNS for sign/encrypt functionality X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Dec 2014 05:17:01 -0000 On Thu, Dec 04, 2014 at 12:06:37PM -0500, Paul Wouters ? wrote: > >Using a naming convention for designating sign/encrypt becomes useful > > when CU=3 is used. If SMIMEA is going to follow the same interpretation > > as in TLSA, then the client may not be doing any other checks or use any > > other parts of the cert such as the keyUsage field. They may not even be > > present in the cert - just a bare bones X.509 that may not contain much > > beyond the public key. So if an enterprise wants to use certs with CU=3 > > and separation of roles, this functionality becomes useful. > > But RFC 6698 states: > > The difference between certificate > usage 1 and certificate usage 3 is that certificate usage 1 > requires that the certificate pass PKIX validation, but PKIX > validation is not tested for certificate usage 3. Though we should keep in mind that the OPS draft updates 6698 to specify that usage 3 ignores expiration and name checks: https://tools.ietf.org/html/draft-ietf-dane-ops-07#section-5.1 but, this says nothing about ignoring keyUsage. Also we've (as the DANE WG) have not yet discussed to what extent the OPS draft updates apply only to DANE TLSA, or to all DANE documents that use compatible RRDATA formats. > The Certificate Usage that seems appropriate are the ones specifying > it should do "full PKIX validation" (usage 1 or 2, not 3), which would > include the EKU's to know whether the certificate is good for signing > or encrypting. I expect DANE-TA(2) to be a fairly popular certificate usage for enterprises that want to publish signature only keys, but per the interim meeting, enterprise certs don't always signal the constraints, so some additional out of band (not in the certificate) signalling may in fact be required. I should also point that when the DANE TLSA RRset for a mailbox publishes only trust anchors (usage 0 or 2), and/or only digests of EE keys, the association is at first blush a signature only association. This is because for first contact, the user's actual public key remains unknown and must be obtained by other means. Only "TLSA [13] ? 0" records provide usable end-entity key material. And perhaps for SMIME even bare keys are not enough, IIRC one may need access to the full recipient certificate to construct an SMIME encrypted message and thus only "TLSA [13] 0 0" are sufficient for (initial encryption). So we potentially have the opportunity to declare that anything other than "1 0 0" or "3 0 0" is a signature-only association, even after the key is obtained out of band. This idea may be a dead-end, but perhaps it is worth mentioning. > > A variant of that could be an enterprise using a local trust anchor (CU > > 2) for digital signature certs in a wildcard SMIMEA (to cover all domain > > users), and generating encryption certs and using CU=3 since clients won't > > be able to perform full PKIX validation to the local trust anchor if they > > don't have it stored locally. Wildcards records are not merged with more specific data published for the specific "owner name" requested in a query. Therefore, one cannot publish a wildcard "CU=2" and also "CU=3" per user, and have the wildcard apply to all the users. In any case the CU=3 comment seems to be a misconception. Just as in TLS the handshake chain needs to include the TA cert with all other intermediates even if the TA is self-signed, similarly with SMIME, the TA will need to be included in the PKCS7 S/MIME message, along any intermediates and the leaf cert. Therefore signed SMIME messages can be verified based on an SMIMEA CU=2 association alone. > > In a way, the encryption certs could be > > viewed as opportunistic S/MIME. So you have: > > > >*._sign._smimecert.example.com IN SMIMEA 2 0 1 > > > >and for each user that is allowed to accept encrypted mail: > >._encr._smimecert.example.com IN SMIMEA 3 0 0 Which would completely hide the wildcard, so that in fact one would need: ._sign._smimecert.example.com SMIMEA 2 0 1 ._encr._smimecert.example.com SMIMEA 3 0 0 which lines up with my observation a paragraph or two back. Only "3 0 0" or "1 0 0" yields usable encryption material, and we could choose to say so. Obviating the need for the "_sign" and "_encr" labels. > >The draft will have to have some text to specify when a client should not rely on the keyUsage field in the cert > > It should always rely on it for CU=1 and CU=2. And CU=3 should clearly > not be used if there is domain policy covering an individual. Perhaps this is too rigid. There are advantages to "3 0 0" associations, and because they fully specify the certificate content, they can signal EKU just like all the other usages can. Though I think that perhaps a good case was made for not expecting EKU to be suitably set in all cases and a likely need for additional signals. -- Viktor. From nobody Sat Dec 6 15:21:01 2014 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 C99C11A1B68 for ; Sat, 6 Dec 2014 15:20:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 qwMRAi4jH5YI for ; Sat, 6 Dec 2014 15:20:57 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ADE31A1B5B for ; Sat, 6 Dec 2014 15:20:56 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id C46CD282BC4; Sat, 6 Dec 2014 23:20:54 +0000 (UTC) Date: Sat, 6 Dec 2014 23:20:54 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141206232054.GI285@mournblade.imrryr.org> References: <20141201013357.GF285@mournblade.imrryr.org> <547BC8F9.1070605@andyet.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <547BC8F9.1070605@andyet.net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/4eWSqxwE1cCeX3CAxflOLqwX3KE Subject: [dane] WGLC: DANE-SRV (Terminology and "SRV Query" feedback) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Dec 2014 23:21:00 -0000 On Sun, Nov 30, 2014 at 06:48:41PM -0700, Peter Saint-Andre - &yet wrote: [ I'm splitting it into a few messages to keep it manageable, and in any case some of my comments are still pencil marks on a print-out, not yet transcribed. ] This message covers sections 2 ("Terminology") and 3.1 ("SRV Query"). General comment (copied verbatim from abstract and introduction feedback): The draft frequently talks about "hostnames", where what is really meant is a transport endpoint (port, transport protocol, host). With PKIX-EE or DANE-EE certificate usages, TLSA records are more precise than the Web PKI and can associate different, non-interchangeable key material with distinct services on a single host. So in many places I will be suggesting replacing statements about "hostnames" with statements about "transport endpoints". 2. Terminology: General comment, this section is a bit too short I think. More terms should perhaps be defined. I will propose a not necessarily comprehensive list. Add a suitable definition of "transport endpoint" (or some other name if the imprecision noted below is objectionable): Transport Endpoint: In this document, a triple which combines * A DNS hostname which abstracts a set of IPv4 and/or IPv6 addresses. * A transport protocol (TCP or UDP) * A port number which specifies a TCP or UDP service deployed at the addresses associated with the hostname. DANE TLSA records associate key material with transport endpoints. Because this definition of a transport endpoint uses a hostname and not a network address, strictly speaking what we have is an indirect reference to a set of related TCP or UDP endpoints. Likely a good idea to paste in some relevant definitions from the SRV RFCs (e.g. "service domain"). Section 3.1 "SRV Query" first paragraph, bottom of page 3/top of page 4 (refine the words "helpful summary"): OLD: When the client makes an SRV query, a successful result will typically be a list of one or more SRV records (or possibly a chain of CNAME / DNAME aliases leading to such a list). Implementers need to be aware that unsuccessful results can occur because of various DNS-related errors; a helpful summary can be found in section 2.1 of . New: When the client makes an SRV query, a successful result will typically be a list of one or more SRV records (or possibly a chain of CNAME / DNAME aliases leading to such a list). Implementers need to be aware that unsuccessful results can occur because of various DNS-related errors; guidance on avoiding downgrade attacks can be found in section 2.1 of . Next paragraph (since the terminology section claims definitions of "secure", ... from 4035, quote from 4035, not 4033). Be more precise about aliases. I think the text about the AD bit is should either be deleted or expanded (a lot), the application may be doing its own validation, and the AD is the irrelevant, or some discussion is needed about when AD-bits might be trustworthy. OLD: For this specification to apply, the entire DNS RRset that is returned MUST be "secure" according to DNSSSEC validation ( section 5). In the case of aliases, the whole chain of CNAME and DNAME RRsets MUST be secure as well. This corresponds to the AD bit being set in the response(s); see section 3.2.3. NEW: For this specification to apply, the entire DNS RRset that is returned MUST be "secure" according to DNSSSEC validation ( section 4.3). In case the answer is obtained via a chain of CNAME and/or DNAME aliases, the whole chain of CNAME and DNAME RRsets MUST also be secure. Next paragraph (number 3 of section 3.1) Again drop AD-bit discussion and improve wording. OLD: If the the entire RRset is "insecure", this protocol has not been correctly deployed. The client SHOULD fall back to its non-DNSSEC, non-DANE behavior (this corresponds to the AD bit being unset). If the entire RRset is "bogus", the client MUST abort the attempt. NEW: If the lookup result is "insecure", this protocol does not apply. The client SHOULD fall back to its non-DNSSEC, non-DANE behavior. If the SRV lookup fails (including the case that the RRset is "bogus"), the client MUST abort its to contact the desired service. Next (number 4 of section 3.1) SRV lookup returns candidate "Transport endpoints", not hostnames, mention requirement for secure CNAME/DNAME indirection once more. OLD: In the successful case, the client now has an authentic list of target server host names with weight and priority values. It performs server ordering and selection using the weight and priority values without regard to the presence or absence of DNSSEC or TLSA records. It also takes note of the DNSSEC validation status of the SRV response for use when checking certificate names (see ). The client can now proceed to making address queries on the target server host names as described in the next section. NEW: When the lookup returns a "secure" RRset, perhaps via a chain of "secure" CNAME/DNAME records, the client now has an authentic list of target transport enpdoints with weight and priority values. It performs server ordering and selection using the weight and priority values without regard to the presence or absence of DNSSEC or TLSA records. It also takes note of the DNSSEC validation status of the SRV response for use when checking certificate names (see ). The client can now proceed to making address queries on the target server host names as described in the next section. -- Viktor. From nobody Mon Dec 8 12:19:04 2014 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 40B391A887C for ; Mon, 8 Dec 2014 12:19:03 -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, SPF_HELO_PASS=-0.001, 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 BDhqnvAnl3is for ; Mon, 8 Dec 2014 12:19:00 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0071.outbound.protection.outlook.com [65.55.169.71]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EF761A888C for ; Mon, 8 Dec 2014 12:18:58 -0800 (PST) Received: from BLUPR06MB243.namprd06.prod.outlook.com (10.242.191.154) by BLUPR06MB242.namprd06.prod.outlook.com (10.242.191.142) with Microsoft SMTP Server (TLS) id 15.1.31.17; Mon, 8 Dec 2014 20:18:54 +0000 Received: from BLUPR06MB243.namprd06.prod.outlook.com ([169.254.7.68]) by BLUPR06MB243.namprd06.prod.outlook.com ([169.254.7.68]) with mapi id 15.01.0026.003; Mon, 8 Dec 2014 20:18:54 +0000 From: Dan York To: Paul Hoffman Thread-Topic: [dane] WGLC: DANE-SRV & DANE-SMTP Thread-Index: AQHP/vetC2cBN15JzUGG0PyM027+/5xxefeAgA1154CAB1qPgA== Date: Mon, 8 Dec 2014 20:18:53 +0000 Message-ID: <2B97DD9A-149D-43CB-9B5B-1860731F767C@isoc.org> References: <0DAFC2A8-A1E2-46F4-BA52-E8261CB09159@ogud.com> <6F20D61B-DB10-4ECA-9447-3A8DFD7137DA@vpnc.org> In-Reply-To: <6F20D61B-DB10-4ECA-9447-3A8DFD7137DA@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2604:6000:9fc0:79:75e8:98cf:f373:661e] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB242; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB242; x-forefront-prvs: 041963B986 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(377454003)(199003)(24454002)(189002)(15975445007)(107046002)(106116001)(19617315012)(99286002)(106356001)(105586002)(97736003)(110136001)(16236675004)(15395725005)(21056001)(36756003)(46102003)(4396001)(68736005)(40100003)(82746002)(122556002)(102836002)(101416001)(19580405001)(19580395003)(33656002)(31966008)(64706001)(99396003)(77156002)(62966003)(20776003)(120916001)(87936001)(54356999)(50986999)(2656002)(76176999)(83716003)(92566001)(86362001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB242; H:BLUPR06MB243.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_2B97DD9A149D43CB9B5B1860731F767Cisocorg_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org Archived-At: http://mailarchive.ietf.org/arch/msg/dane/Wp26ShzTdZItn3WpYSC5_sFQsfI Cc: "" Subject: Re: [dane] WGLC: DANE-SRV & DANE-SMTP 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, 08 Dec 2014 20:19:03 -0000 --_000_2B97DD9A149D43CB9B5B1860731F767Cisocorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Olafur & Warren, I realize that WGLC formally ended on Friday, but I'll note that I have rea= d these two documents and I didn't really much beyond comments that Stephan= e and Viktor have already made. I support the documents moving ahead subjec= t to the comments that have been sent around. In https://tools.ietf.org/html/draft-ietf-dane-srv-08 I have these two com= ments: 1. A nitpick where the abstract says: ---- The DANE specification (RFC 6698) describes how to use TLSA resource records in the DNS to associate a server's host name with its TLS certificate, where the association is secured with DNSSEC. However, application protocols that use SRV records (RFC 2782) to indirectly name the target server host names for a service domain cannot apply the rules from RFC 6698. ---- I think there is a singular/plural mismatch here. I think it should be "to= indirectly name the target server host **name** for a service domain" 2. Where is 'Certificate Usage "DANE-EE"' defined? I see it referenced her= e in section 4.2 but I don't find any reference to "DANE-EE" in RFC 6698 or= find a definition in this document? In https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-13 nothing le= apt out at me in terms of comments, although I will admit I did not read it= as thoroughly as the SRV one. I will note that DANE-EE *is* used and defi= ned here in this document. My 2 cents, Dan -- Dan York Senior Content Strategist, Internet Society york@isoc.org +1-802-735-1624 Jabber: york@jabber.isoc.org Skype: danyork http://twitter.com/danyork http://www.internetsociety.org/deploy360/ On Dec 3, 2014, at 11:00 PM, Paul Hoffman > wrote: I have read these two documents and they seem fine. I'm sure there will be = significant comments in IETF Last Call from folks in Apps Area, both about = the use of SRV and SMTP, and possibly technical changes based on those, but= as a WG product, both of these seem fine. --Paul Hoffman _______________________________________________ dane mailing list dane@ietf.org https://www.ietf.org/mailman/listinfo/dane --_000_2B97DD9A149D43CB9B5B1860731F767Cisocorg_ Content-Type: text/html; charset="us-ascii" Content-ID: <25F8CEB5BD24EA48B93F9138FF338F65@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Olafur & Warren,

I realize that WGLC formally ended on Friday, but I'll note that I hav= e read these two documents and I didn't really much beyond comments that St= ephane and Viktor have already made. I support the documents moving ahead s= ubject to the comments that have been sent around.

1. A nitpick where the abstract says:
----
   The DANE specification (RFC 6698) describes how to use TL= SA resource
   records in the DNS to associate a server's host name with= its TLS
   certificate, where the association is secured with DNSSEC= .  However,
   application protocols that use SRV records (RFC 2782) to = indirectly
   name the target server host names for a service domain ca= nnot apply
   the rules from RFC 6698. 
----

I think there is a singular/plural mismatch here.  I think it sho= uld be "to indirectly name the target server host **name** for a = service domain"

2. Where is 'Certificate Usage "DANE-EE"' defined?  I s= ee it referenced here in section 4.2 but I don't find any reference to &quo= t;DANE-EE" in RFC 6698 or find a definition in this document?


My 2 cents,
Dan


--
Dan York
Senior Content Strategist, Internet Socie= ty
york@iso= c.org   +1-802-735-1624
Skype: danyork   http://twitter.com/danyork


On Dec 3, 2014, at 11:00 PM, Paul Hoffman <paul.hoffman@vpnc.org>
 wrote:

I have read these two documents and they seem fin= e. I'm sure there will be significant comments in IETF Last Call from folks= in Apps Area, both about the use of SRV and SMTP, and possibly technical c= hanges based on those, but as a WG product, both of these seem fine.

--Paul Hoffman
_______________________________________________
dane mailing list
dane@ietf.org
https://www.ietf.org/mailman/listinfo/dane

--_000_2B97DD9A149D43CB9B5B1860731F767Cisocorg_-- From nobody Mon Dec 8 12:34:50 2014 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 378FA1ACE29 for ; Mon, 8 Dec 2014 12:34:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 3PfI3RJ60NxW for ; Mon, 8 Dec 2014 12:34:47 -0800 (PST) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57BF61ACE27 for ; Mon, 8 Dec 2014 12:34:46 -0800 (PST) Received: by mail-ig0-f179.google.com with SMTP id r2so3456846igi.6 for ; Mon, 08 Dec 2014 12:34:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=nIpg7SpMyYMZexVtRhQtXvq3VikUedKumcVzSaws/zc=; b=PJD8ixeNdeDVMYccIv7707Q1pDwULEDtedggLak56LytL8wLxR+CDoozxh2/kS0/yO LhJAFGThO5oA1ELFoDwZCIIPwfJuLYqgzAFAu4IaidXmEOUPR6pVmZnpoLt9mCdfO4GU Y/gVTEZh6hqx7pxuGo9Nqq9h5fTeJicbp1HigLTeg/+BhkHIOCX5urAYxCVxLfC+VP0x NobnEq9AYuCDcVY2JOBB+aYNNtes7fNHXYstaihVAD+GvwNdctXqodDVYsN1uHz/2GT8 Nhy+QpCKarYNwQiVpJI8YLK5yL/L87uHcFH6gURs4EJyWjc5q5NCqGweJPMlFikt0N2A /ghA== MIME-Version: 1.0 X-Received: by 10.50.4.102 with SMTP id j6mr16547984igj.37.1418070885308; Mon, 08 Dec 2014 12:34:45 -0800 (PST) Received: by 10.64.225.196 with HTTP; Mon, 8 Dec 2014 12:34:45 -0800 (PST) In-Reply-To: <2B97DD9A-149D-43CB-9B5B-1860731F767C@isoc.org> References: <0DAFC2A8-A1E2-46F4-BA52-E8261CB09159@ogud.com> <6F20D61B-DB10-4ECA-9447-3A8DFD7137DA@vpnc.org> <2B97DD9A-149D-43CB-9B5B-1860731F767C@isoc.org> Date: Mon, 8 Dec 2014 15:34:45 -0500 Message-ID: From: Shumon Huque To: Dan York Content-Type: multipart/alternative; boundary=001a11c31f6e62a14e0509ba5b2e Archived-At: http://mailarchive.ietf.org/arch/msg/dane/Zw5RzhOUeph2VjANnWC1DZikrfE Cc: Paul Hoffman , "" Subject: Re: [dane] WGLC: DANE-SRV & DANE-SMTP X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: shuque@gmail.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 20:34:49 -0000 --001a11c31f6e62a14e0509ba5b2e Content-Type: text/plain; charset=UTF-8 On Mon, Dec 8, 2014 at 3:18 PM, Dan York wrote: > Olafur & Warren, > > I realize that WGLC formally ended on Friday, but I'll note that I have > read these two documents and I didn't really much beyond comments that > Stephane and Viktor have already made. I support the documents moving ahead > subject to the comments that have been sent around. > > In https://tools.ietf.org/html/draft-ietf-dane-srv-08 I have these two > comments: > > [...] > > 2. Where is 'Certificate Usage "DANE-EE"' defined? I see it referenced > here in section 4.2 but I don't find any reference to "DANE-EE" in RFC 6698 > or find a definition in this document? > DANE parameter abbreviations are defined in RFC 7218. The draft mentions that it references those in Section 2 Terminology. Shumon --001a11c31f6e62a14e0509ba5b2e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Dec 8, 2014 at 3:18 PM, Dan York <york@isoc.org&g= t; wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
Olafur & Warren,

I realize that WGLC formally ended on Friday, but I'll note that I= have read these two documents and I didn't really much beyond comments= that Stephane and Viktor have already made. I support the documents moving= ahead subject to the comments that have been sent around.

In=C2=A0https://tools.ietf.org/html/draft-ietf-dane-srv-08= =C2=A0 I have these two comments:

[...]

2. Where is 'Certificate Usage "DANE-EE"' defined?= =C2=A0 I see it referenced here in section 4.2 but I don't find any ref= erence to "DANE-EE" in RFC 6698 or find a definition in this docu= ment?

DANE parameter abbreviati= ons are defined in RFC 7218. The draft mentions that it references those in= Section 2 Terminology.

Shumon
--001a11c31f6e62a14e0509ba5b2e-- From nobody Mon Dec 8 12:39:56 2014 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 1F78C1A8893 for ; Mon, 8 Dec 2014 12:39:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 cjrZI1gjdIjN for ; Mon, 8 Dec 2014 12:39:53 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 207581ACE44 for ; Mon, 8 Dec 2014 12:39:53 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 34657284B0F; Mon, 8 Dec 2014 20:39:46 +0000 (UTC) Date: Mon, 8 Dec 2014 20:39:46 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141208203945.GK285@mournblade.imrryr.org> References: <0DAFC2A8-A1E2-46F4-BA52-E8261CB09159@ogud.com> <6F20D61B-DB10-4ECA-9447-3A8DFD7137DA@vpnc.org> <2B97DD9A-149D-43CB-9B5B-1860731F767C@isoc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2B97DD9A-149D-43CB-9B5B-1860731F767C@isoc.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/qDrzf6dgE3YObBqQItE601LZkk0 Subject: Re: [dane] WGLC: DANE-SRV & DANE-SMTP X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 20:39:55 -0000 On Mon, Dec 08, 2014 at 08:18:53PM +0000, Dan York wrote: > I realize that WGLC formally ended on Friday, but I'll note that > I have read these two documents and I didn't really much beyond > comments that Stephane and Viktor have already made. I support the > documents moving ahead subject to the comments that have been sent > around. I have not finished posting my -SRV comments yet. Sorry, cycles are a bit scarce, but I'd like a bit more time to post the remainder. -- Viktor. From nobody Mon Dec 8 15:06:42 2014 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 749491A00C5 for ; Mon, 8 Dec 2014 15:06:40 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 aYFNB2hAVQfO for ; Mon, 8 Dec 2014 15:06:39 -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 DFF181A00A2 for ; Mon, 8 Dec 2014 15:06:38 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp8.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 4EC3C380111 for ; Mon, 8 Dec 2014 18:06:37 -0500 (EST) X-Virus-Scanned: OK Received: by smtp8.relay.iad3a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 148C138027F for ; Mon, 8 Dec 2014 18:06:36 -0500 (EST) X-Sender-Id: ogud@ogud.com Received: from [192.168.100.19] ([UNAVAILABLE]. [77.76.110.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.4.2); Mon, 08 Dec 2014 23:06:37 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Olafur Gudmundsson In-Reply-To: <20141208203945.GK285@mournblade.imrryr.org> Date: Mon, 8 Dec 2014 23:06:35 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <48205CBC-7426-4A03-AF33-44EA912142D6@ogud.com> References: <0DAFC2A8-A1E2-46F4-BA52-E8261CB09159@ogud.com> <6F20D61B-DB10-4ECA-9447-3A8DFD7137DA@vpnc.org> <2B97DD9A-149D-43CB-9B5B-1860731F767C@isoc.org> <20141208203945.GK285@mournblade.imrryr.org> To: dane@ietf.org X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/gA6O_yqHXATkZDWEs4Egb_5Npbc Subject: Re: [dane] WGLC: DANE-SRV & DANE-SMTP 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, 08 Dec 2014 23:06:40 -0000 Viktor=20 I=E2=80=99m traveling this week so I may not have much time to exactly = do things but I have long fight on Saturday and was going to use that one to collect all my thoughts on the WGLC and start the OPS = document WG last call then=20 so take your time to rev the next version=20 Olafur (in London)=20 > On Dec 8, 2014, at 8:39 PM, Viktor Dukhovni = wrote: >=20 > On Mon, Dec 08, 2014 at 08:18:53PM +0000, Dan York wrote: >=20 >> I realize that WGLC formally ended on Friday, but I'll note that >> I have read these two documents and I didn't really much beyond >> comments that Stephane and Viktor have already made. I support the >> documents moving ahead subject to the comments that have been sent >> around. >=20 > I have not finished posting my -SRV comments yet. Sorry, cycles > are a bit scarce, but I'd like a bit more time to post the remainder. >=20 > --=20 > Viktor. >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From nobody Mon Dec 8 16:13:00 2014 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 B519F1A02BE for ; Mon, 8 Dec 2014 16:12:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 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, T_RP_MATCHES_RCVD=-0.01] 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 cunuA_6CVZmy for ; Mon, 8 Dec 2014 16:12:57 -0800 (PST) Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) (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 5D9621A0016 for ; Mon, 8 Dec 2014 16:12:57 -0800 (PST) Received: by ore.jhcloos.com (Postfix, from userid 10) id 60E621E108; Tue, 9 Dec 2014 00:12:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1418083976; bh=cMcquP3ktvbL85Gc+UAmVCDp/+Sssd5AzrKt4KaTnAo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=C4nrgQ1SMd+hVL3kb3s2F7mhpQuJZD7dMOBvYUNhuBAJeInbIamctCgh7sEATxtpN NWQ9Ke92QkNNYVjxu/yZLLvoCKR3pztB3x6GKsakE28guos7GMPOz248J+UlKxR55c r/1iRVNYgQIfwnYXojbmxGh5L01tTeXlaPxkxiQg= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 97B9F60023; Tue, 9 Dec 2014 00:11:30 +0000 (UTC) From: James Cloos To: Dan York In-Reply-To: <2B97DD9A-149D-43CB-9B5B-1860731F767C@isoc.org> (Dan York's message of "Mon, 8 Dec 2014 20:18:53 +0000") References: <0DAFC2A8-A1E2-46F4-BA52-E8261CB09159@ogud.com> <6F20D61B-DB10-4ECA-9447-3A8DFD7137DA@vpnc.org> <2B97DD9A-149D-43CB-9B5B-1860731F767C@isoc.org> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Mon, 08 Dec 2014 19:11:30 -0500 Message-ID: Lines: 12 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:28:141209:york@isoc.org::NlfRp80vZ8PgN/wJ:000Au9J2 X-Hashcash: 1:28:141209:paul.hoffman@vpnc.org::LyGMXqK+TduDmEw1:000000000000000000000000000000000000000A6uMO X-Hashcash: 1:28:141209:dane\@ietf.org\::n04mf49FKIGoILY+:03PQ6K X-Hashcash: 1:28:141209:dane@ietf.org::K/+km8ot261SL8Nv:0001qTJK Archived-At: http://mailarchive.ietf.org/arch/msg/dane/dAs8RUxa12YBk8J0hDuU4pFJoKU Cc: Paul Hoffman , "" Subject: Re: [dane] WGLC: DANE-SRV & DANE-SMTP 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, 09 Dec 2014 00:12:58 -0000 >>>>> "DY" == Dan York writes: DY> I think there is a singular/plural mismatch here. I think it should DY> be "to indirectly name the target server host **name** for a service DY> domain" I presume the plural is because a service domain can have several target host names for any given service. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Mon Dec 8 17:24:57 2014 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 013781A0033 for ; Mon, 8 Dec 2014 17:24:54 -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_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 R3RL53lrMUMK for ; Mon, 8 Dec 2014 17:24:52 -0800 (PST) Received: from mail-ig0-f179.google.com (mail-ig0-f179.google.com [209.85.213.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F8111A00FA for ; Mon, 8 Dec 2014 17:24:52 -0800 (PST) Received: by mail-ig0-f179.google.com with SMTP id r2so124582igi.6 for ; Mon, 08 Dec 2014 17:24:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=LuREFbTeYhHOs/rIWK1pD/X17jufaxJQ3o4IMMMe4CY=; b=BIrBJaqOI3aZNSiveoRODTjFxZksuTgbqoV8APKiK+NhlaJiyYDinLddIs6DvnUElc FbZ2qM+yLMM8+qJNaMNmOaVxHMANXMxofZ+Y31Vq5Vv+Ckc7g+dvJ3xZBnVcb+gU1ws8 uWeVJsam3AXCJhH0cM8uzTAOY3K4lTex7bH2GzSvPMvLbcQbmGESTATUNnurj4tkvA5w x97QzvSuQXArq39/Rdw4AtVTqpBeOjIuVqAeMTlz0JGNuwj236e/ecqz4wnJ4dDxVd/V gTQMUzfLBcFZ8WMpFWjbllNt47/21JSVtsCZBdHdaEn7lStCxuiOS7dwApT3xOUP1bhw 7dbg== X-Gm-Message-State: ALoCoQkmJ4qUv+PFQMqJToNnVqgWbwhnGQj/u3eCIdBDELnk3mOM8mU4/MbyYQxfp7G0N32t9tbb X-Received: by 10.43.7.3 with SMTP id om3mr203081icb.97.1418088291784; Mon, 08 Dec 2014 17:24:51 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id ct3sm124096igb.20.2014.12.08.17.24.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 08 Dec 2014 17:24:51 -0800 (PST) Message-ID: <54864F62.9000402@andyet.net> Date: Mon, 08 Dec 2014 18:24:50 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dane@ietf.org References: <0DAFC2A8-A1E2-46F4-BA52-E8261CB09159@ogud.com> <6F20D61B-DB10-4ECA-9447-3A8DFD7137DA@vpnc.org> <2B97DD9A-149D-43CB-9B5B-1860731F767C@isoc.org> <20141208203945.GK285@mournblade.imrryr.org> In-Reply-To: <20141208203945.GK285@mournblade.imrryr.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/94CPa5nEauUL5B1NwD8hM0PXyNY Subject: Re: [dane] WGLC: DANE-SRV & DANE-SMTP 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, 09 Dec 2014 01:24:54 -0000 On 12/8/14, 1:39 PM, Viktor Dukhovni wrote: > On Mon, Dec 08, 2014 at 08:18:53PM +0000, Dan York wrote: > >> I realize that WGLC formally ended on Friday, but I'll note that >> I have read these two documents and I didn't really much beyond >> comments that Stephane and Viktor have already made. I support the >> documents moving ahead subject to the comments that have been sent >> around. > > I have not finished posting my -SRV comments yet. Sorry, cycles > are a bit scarce, but I'd like a bit more time to post the remainder. Personally I am in no great hurry, since I have a bunch of other specs to finish in the UTA, PRECIS, XMPP, URNBIS, and STOX WGs... Peter From nobody Tue Dec 9 01:58:20 2014 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 DC9931A1B6D for ; Tue, 9 Dec 2014 01:58:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 wtVkcQOYHya0 for ; Tue, 9 Dec 2014 01:58:15 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F22B1A1B12 for ; Tue, 9 Dec 2014 01:58:15 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id ECED9282F8B; Tue, 9 Dec 2014 09:58:13 +0000 (UTC) Date: Tue, 9 Dec 2014 09:58:13 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141209095813.GP285@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/RAuSE95NJlhX5sIc1kciq_ZdpZ8 Subject: [dane] Adoption data-point and operational considerations... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 09:58:19 -0000 [ In part WG-related, please see questions at the end... ] Google's email transparency report in includes a last of mail sending and receiving domains that are "large enough" to be included in their stats. https://www.google.com/transparencyreport/saferemail/data/ Out of 17800 domains, 270 had DNSSEC-signed MX records. Of the latter, 162 had one of their best-preference MX host in a DNSSEC domain and were in a position to publish DANE TLSA records. Finally, 10 of those domains actually had TLSA records deployed: unitymedia.de posteo.de bund.de jpberlin.de lrz.de debian.org freebsd.org ietf.org torproject.org listserv.state.pa.us These were already on my curated list, and represent many of its larger domains. That list now has 463 DANE email domains. So clearly at present most of the deployments are small sites that are "more agile" in their willingness to deploy early. If we can clear more deployment roadblocks, I am hoping to see substantially higher numbers by this time next year. One deployment pitfall discovered in recent interoperability tests is that some domains have cleartext-only anti-spam proxies in front of their MTA, with the proxies only allowing connections to the real MTA once the SMTP client passes a grey-listing check (this was observed with "spamd" as the proxy, but any "selective access" to TLS can be similarly problematic). If the receiving domain publishes TLSA records, this creates a catch-22 with DANE-aware client MTAs. The DANE client never begins the first mail transaction, because the proxy does not offer STARTTLS, (the proxy is a receiving system deployed downgrade to cleartext MiTM in front of the real MTA). The short-term solution for such domains is to NOT publish TLSA RRs for port 25. Longer-term the anti-spam proxy should be upgraded to support STARTTLS. For example, the Postfix "postscreen" service, which has functionality similar to "spamd", supports STARTTLS so that grey-listing does not amount to a similar downgrade attack. I'd like to add some language about avoiding this problem in the operational considerations section of the smtp-with-dane draft. Any objections? Additional operational considerations might include not forgetting to update TLSA RRs for *all* the names under which a server might be known when doing key rotation. This is a problem particularly when a single wild-card certificate is deployed on all the MX hosts, and replaced concurrently on them all, creating an immediate outage for any domains that use variant MX host names (for flexibility of later hosting some domains separately). With DANE one should strongly consider per-server certificates to avoid synchronized multi-MTA outages. And lastly, by far the most common problems are with DNSSEC. A mixture of failure to perform timely re-signing and at present lots of domains with nameservers that have non-working Denial of Existence. I don't have a comprehensive list of software that is deficient in this manner, but it seems that some older versions of PowerDNS botch DoE in at least some configurations. Similar issues reportedly with djbdns DNSSEC patches. A few domains have firewalls that block TLSA queries, one blocked these only for IPv4 clients, with IPv6 clients not filtered, that can create difficult to diagnose problems. So I am looking for guidance on how much *current* operational experience to include in the draft that may ultimately become irrelevant as the infrastructure improves, but may be very useful to get us past the initial deployment hurdles. If we don't get early adopters past the initial problems, the long-term obsolescence of the issues might remain forever in the future. The DNSSEC issues often impact domains that don't publish TLSA records, just signing the zone, but operating a nameserver that is not quite up to spec causes the majority of the problems. How should that issue be presented? It applies to folks who are not specifically deploying the protocol. The simplest work-around is often to publish: _25._tcp.. IN TXT "No TLSA RRs here yet" or to publish real TLSA records, since creating either type of record avoids most of the DoE bugs. (I am optimistic that most of the DoE problems will be remediated by this time next year once the .nl registrars update their software, and most PowerDNS users upgrade to a sufficiently recent release). -- Viktor. From nobody Thu Dec 11 02:52:04 2014 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 12EC71A878C for ; Thu, 11 Dec 2014 02:52:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.699 X-Spam-Level: X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 GPkjOKDRKc-r for ; Thu, 11 Dec 2014 02:52:00 -0800 (PST) Received: from sol.sotecware.net (sol.sotecware.net [IPv6:2a01:4f8:d16:1305::2]) by ietfa.amsl.com (Postfix) with ESMTP id 904D31AC425 for ; Thu, 11 Dec 2014 02:52:00 -0800 (PST) Received: from altair.sotecware.net (altair.sotecware.net [217.115.12.84]) by sol.sotecware.net (Postfix) with ESMTPSA id 249771412E2 for ; Thu, 11 Dec 2014 10:51:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wielicki.name; s=k001.sol; t=1418295118; bh=0NjJitSLcz3AJfdiZk/9oDwgi2C+YiOAVyC1GBwQH84=; h=Date:From:To:Subject; b=aBZlmdNUnIR5S1eI9aoNhyAqoECO7GznxkGJEJhVQHa+V8sGtN7a3iRYRfstDFeFZ ChWpPI2uRcSwrrkfSUUlexBkOOLoXVGo8+3eUI9fljDz7gf8Y8crEA8RbH6gdWxnCl /Qxnbp8yAs/o+wbyqlHpZa5G+sEr5oLqvZGx0LgOqsHVrepR/TTGyBxhu5etcyBewF WyDI1MIu9YkOtydeEeVh67fS8eeVZryDP9Gml1yXyGfnzqvKESNlvU5RcK9IKBiLi9 00E9+h5p6p78DsneLz8XOw+nUFixPhS2p78Ag0k1kJ0iT0mmjIo5NJr0/PPMc5w294 acZn2N3y8D6sw== Message-ID: <5489774C.5090600@wielicki.name> Date: Thu, 11 Dec 2014 11:51:56 +0100 From: Jonas Wielicki User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: dane@ietf.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/k1XhPA6PL4Bx8mXUcljoAf3XxWc Subject: [dane] Feedback request: python3-dane (A pure-python DANE library for Python 3) 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: Thu, 11 Dec 2014 10:52:03 -0000 Dear list, I hope this is not too off-topic, but I guess those most well suited for the task can be found at this list. I recently started working on a python3 library[1] to support the implementation of DANE in python3 based applications. I am looking for some support in form of a second or third pair of eyes. As this is a security sensitive topic, I would be glad if someone took the time to look over the approx. 600 lines of python code or the user interface documentation. To make it clear what the scope of the library is: It is not a validating resolver; that is expected to be handled by the application. it is not a TLS stack or bound to a specific TLS stack. It provides parsing and hashing of certificates (via the pyasn1 package), as well as functions to validate a chain of certificates (provided by the application) used for TLS against a TLSA RRset (provided by the application) together with the information whether PKIX validation succeeded (also provided by the application). For PKIX validation, it provides a facility to extract and validate trust anchors from TLSA RRsets. I would like a general review (or any kind of feedback for that matter), but I also have a specific question: I am unsure about the implementation of the "CA constraint" usage. Is it correct to allow a "CA constraint" record to enable the use of an otherwise untrusted (but not invalid, e.g. expired) CA certificate? Please also take a look at the documentation (for your convenience also available online at [2]), as it describes the workflow and interface for developers using the library, which has impact on the achieved security. If anyone wants to review or take a quick look to see whether I’m doing the right thing, I would be happy if any issues or feedback to be reported to me either off-list to this email address, in the github bugtracker, or on-list if that is considered sufficiently on-topic for the list. As the library has been published like just now, I assume that noone has put trust into it yet, so security critical bugs do not need to be handled privately. If you want to do that nevertheless, use the GPG key found in the repository (not attaching as it is quite large). The fingerprint is: Key fingerprint = AA5A 78FF 508D 8CF4 F355 F682 E5ED E5AC 679E 300F thanks for your attention, Jonas Wielicki [1]: https://github.com/horazont/python3-dane/ [2]: https://docs.zombofant.net/python3-dane/devel/ From nobody Thu Dec 11 07:05:45 2014 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 02C341ACF0D for ; Thu, 11 Dec 2014 07:05:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.4 X-Spam-Level: * X-Spam-Status: No, score=1.4 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_44=0.6] 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 XvprZSjEmNFc for ; Thu, 11 Dec 2014 07:05:42 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA8CB1ACF09 for ; Thu, 11 Dec 2014 07:05:41 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 17D78282F8B; Thu, 11 Dec 2014 15:05:40 +0000 (UTC) Date: Thu, 11 Dec 2014 15:05:40 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141211150539.GA25666@mournblade.imrryr.org> References: <5489774C.5090600@wielicki.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5489774C.5090600@wielicki.name> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/4hgTEU6zymT_OFtvPGwdyQrhGB8 Subject: Re: [dane] Feedback request: python3-dane (A pure-python DANE library for Python 3) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 15:05:44 -0000 On Thu, Dec 11, 2014 at 11:51:56AM +0100, Jonas Wielicki wrote: > I recently started working on a python3 library[1] to support the > implementation of DANE in python3 based applications. I am looking for > some support in form of a second or third pair of eyes. As this is a > security sensitive topic, I would be glad if someone took the time to > look over the approx. 600 lines of python code or the user interface > documentation. Here's my advice. I fully encourage you to experiment with this code, as a productive learning exercise. However, please *do not* document this as something other than experimental code that you used to develop your understanding of the various technologies. Unfortunately, in the DANE space, we have too many "toy" libraries that are wrong or incomplete, and too few that are correct and comprehensive, and will be maintained in the long term. My plan is to see DANE support incorporated into the OpenSSL toolkit, at which point Python applications will be able to use Python's OpenSSL support (sufficiently recent, ...) to do DANE validation. A more valuable contribution would be Python code that locates the right validated TLSA records for a host:port combination that deals with CNAME expansion and all the requisite DNS error handling per the OPs draft. For extra points, code that does this indirectly via SRV or MX records, and produces also the correct set of "reference identifiers" that go along with the TLSA records for handling certificate usages 0, 1 and 2. This should also handle conversion of IDNA hostnames to A-label form for DNS lookups and certificate reference identifier construction. Then, users of future robust DANE validation libraries will be able to pass the correct TLSA records and "reference identifiers" (expected DNS subject names) to those libraries. Please continue to grow your skills in this space, but learning and development exercises need to be explicitly labeled as such. Non-expert users have a hard time distinguishing reliable code from experiments, and would benefit from fewer choices of higher quality. As to your questions: * Usages PKIX-TA(0) and PKIX-EE(1) never accept chains that would fail PKIX validation in the absence of DANE (including name checks). These only "constrain" which chains that pass PKIX validation should be accepted. Great care must be exercised here, for example, after PKIX validation succeeds, a naive request to OpenSSL for the peer's chain returns the list of wire certificates, not the validated chain. Additional complications arise due to cross-signing, that make it difficult to validate a PKIX chain constructed in isolation from the DANE records. Such a chain might use a trust-anchor "below" the one that matches the DANE records. * Usage DANE-TA(2) is the most difficult to support, and "toy" implementations neglect to perform chain construction and integrity checks or perform name checks, apply name constraints, depth constraints, handle IDNA conversion of hostnames, ... * Usage DANE-EE(3) is generally straight-forward, you just check that the peer's certificate or public key has the expercted digest. Even here, integration with the TLS library is a good idea, because at some point one might want to negotiate the use of "raw public keys" when the TLSA records for the peer include records of the form "3 1 X", which means that the SSL library needs to be aware of the TLSA records *before* the handshake. -- Viktor. From nobody Thu Dec 11 11:51:41 2014 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 BAE441A8A5E for ; Thu, 11 Dec 2014 11:51:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 nEUcao7o1Dsy for ; Thu, 11 Dec 2014 11:51:39 -0800 (PST) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D23E41A7028 for ; Thu, 11 Dec 2014 11:51:38 -0800 (PST) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.210.2; Thu, 11 Dec 2014 14:51:17 -0500 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.377.0; Thu, 11 Dec 2014 14:51:36 -0500 Received: from 6-140.antd.nist.gov (6-140.antd.nist.gov [129.6.140.6]) by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id sBBJpTld025522 for ; Thu, 11 Dec 2014 14:51:30 -0500 From: "Rose, Scott W." Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <95826148-4F06-4942-87A4-2F6601BA0F90@nist.gov> Date: Thu, 11 Dec 2014 14:51:27 -0500 To: dane WG list MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-NIST-MailScanner-Information: Archived-At: http://mailarchive.ietf.org/arch/msg/dane/Iolwc6x98UAxYHyETLr33f-c4Sc Subject: [dane] email canonicalization for SMIMEA owner names 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: Thu, 11 Dec 2014 19:51:40 -0000 Realized the other action item I was assigned to from the interim = meeting was email canonicalization for SMIMEA. I believe it stems from = Viktor Dukhovni's email to the endymail list: http://www.ietf.org/mail-archive/web/endymail/current/msg00134.html I was wondering if we can borrow a page from RFC 4034 Section 6.2 and = include text in the draft Section 3, item 1 in the numbered list: 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]), is hashed using the SHA2-224 [RFC5754] algorithm (with the hash being represented in its hexadecimal representation, to become the left-most label in the prepared domain name. This does not include the "@" character that separates the left and right sides of the email address. The string that is used for the local part is a Unicode string encoded in UTF-8 **with all upper case letters converted to their corresponding lower case letters where appropriate.** The text between the '**' is new. The goal is to prevent a situation = when the email address is "JRandom@example.com" and the SMIMEA is = created using "jrandom" as the user name. Would this be enough, or are = there scripts where this would result in different or potentially = conflicting owner names? =20 Scott =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Scott Rose NIST scott.rose@nist.gov +1 301-975-8439 Google Voice: +1 571-249-3671 http://www.dnsops.gov/ https://www.had-pilot.com/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From nobody Thu Dec 11 12:50:57 2014 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 CF23C1A016B for ; Thu, 11 Dec 2014 12:50:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] 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 JkUojVyaLhe6 for ; Thu, 11 Dec 2014 12:50:54 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 984331A700F for ; Thu, 11 Dec 2014 12:50:54 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 44B15282F8B; Thu, 11 Dec 2014 20:50:53 +0000 (UTC) Date: Thu, 11 Dec 2014 20:50:53 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141211205053.GN25666@mournblade.imrryr.org> References: <95826148-4F06-4942-87A4-2F6601BA0F90@nist.gov> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <95826148-4F06-4942-87A4-2F6601BA0F90@nist.gov> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/Q-Ho-v4gAauEu_Uxd50B3j8MAnc Subject: Re: [dane] email canonicalization for SMIMEA owner names X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 20:50:57 -0000 On Thu, Dec 11, 2014 at 02:51:27PM -0500, Rose, Scott W. wrote: > Realized the other action item I was assigned to from the interim > meeting was email canonicalization for SMIMEA. I believe it stems > from Viktor Dukhovni's email to the endymail list: > http://www.ietf.org/mail-archive/web/endymail/current/msg00134.html > > I was wondering if we can borrow a page from RFC 4034 Section 6.2 and include text in the draft Section 3, item 1 in the numbered list: > > 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]), is hashed using the SHA2-224 [RFC5754] > algorithm (with the hash being represented in its hexadecimal > representation, to become the left-most label in the prepared > domain name. This does not include the "@" character that > separates the left and right sides of the email address. The > string that is used for the local part is a Unicode string > encoded in UTF-8 **with all upper case letters converted to their > corresponding lower case letters where appropriate.** > > The text between the '**' is new. The goal is to prevent a situation when the email address is "JRandom@example.com" and the SMIMEA is created using "jrandom" as the user name. Would this be enough, or are there scripts where this would result in different or potentially conflicting owner names? This proposal is sadly simply wrong. There is no correct (language-independent) canonicalization of Unicode to lower case. Nor is it appropriate to down-case even ASCII localparts, because these are by definition case-sensitive on the wire, with any case-folding solely at the discretion of the destination system. I have a proposal that solves the ASCII use-case. Sadly, little can be done for non-ASCII Unicode, those names will just have to be used consistently by all parties. For all-ASCII addresses, (ignoring for the moment Turkish case- folding of "I" to a non-ASCII "dotless" "i"), the proposal is as follows: * Clarification: Localparts that are not dot-atoms and require quoting, retain the quotes when hashed, only the @domain part of the address is removed, the rest of the address is retained verbatim. * Domains that publish user SMIMEA records, which intend for for the names to be treated case insensitively, compute two hashes for each name: SHA2-224("Frank.Jr.") -> SHA2-224(@lower:"frank.jr.") -> The DNS records are then: .example.com. IN SMIMEA ... .example.com. IN CNAME * Domains that don't do case-insensitive delivery publish only the as-is form of each address without any "@lower:" prefix. * Clients that encounter an ascii localpart that is not all lower-case try both keys, first the localpart as-is, then case-folded with the "@lower:" prefix. -- Viktor. From nobody Thu Dec 11 14:03:21 2014 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 4DC7E1A0149 for ; Thu, 11 Dec 2014 14:03:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 MAUuh_qkPWid for ; Thu, 11 Dec 2014 14:03:17 -0800 (PST) Received: from homiemail-a28.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 4E0641A1ABE for ; Thu, 11 Dec 2014 14:03:15 -0800 (PST) Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id 5071C1B405F for ; Thu, 11 Dec 2014 14:03:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:references:mime-version:content-type :in-reply-to; s=cryptonector.com; bh=YK/WEKj6f2/fCGZFfrjrCiRYHeg =; b=Zj3G0MsYG2xEjmWqtpgs3JEW6Eqj8Sj21ZYWrHSj9rUKWX2mtX86MorCXZ7 RzBxyXAfAz5ROk9R5GxskerAGT0kOfJH1R/V5Uos23qZzOZUpQDYpBPtqsITtMWs VgvKNrEtxkozTBBx5gnP5R5Yj8ZCifD0gN5ZG01jw0MUOBI0= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPA id 206201B4059 for ; Thu, 11 Dec 2014 14:03:14 -0800 (PST) Date: Thu, 11 Dec 2014 16:03:13 -0600 From: Nico Williams To: dane@ietf.org Message-ID: <20141211220308.GH3448@localhost> References: <95826148-4F06-4942-87A4-2F6601BA0F90@nist.gov> <20141211205053.GN25666@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141211205053.GN25666@mournblade.imrryr.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/3uTsVx1gQ4o5ZBpemEyCLODi7TQ Subject: Re: [dane] email canonicalization for SMIMEA owner names 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: Thu, 11 Dec 2014 22:03:18 -0000 On Thu, Dec 11, 2014 at 08:50:53PM +0000, Viktor Dukhovni wrote: > I have a proposal that solves the ASCII use-case. Sadly, little > can be done for non-ASCII Unicode, those names will just have to > be used consistently by all parties. Well, domains could publish the local-part canonicalization function they use, or, rather, a small index of well-known canonicalization functions. This is just a tweak to your proposal. You propose just two functions: identity and ASCII-tolower, with the client trying all [two] of them. If we add more functions we'll want to know which function the domain uses, so we'll need that one more lookup. We need just a handful of functions that will work for most cases. E.g., gmail treats periods as if they weren't there. That might need to be part of one ore more standard canon function(s). I realize that your proposal is simpler, and we might want to stop there. > For all-ASCII addresses, (ignoring for the moment Turkish case- > folding of "I" to a non-ASCII "dotless" "i"), the proposal is > as follows: What site would want to permit local-part names that are equivalent but for an i/dotless-i? I realize that the situation can have come up, but going forward a site might want to treat them as equivalents, and, really, to implement Unicode case-folding + some standard mappings, as the canonicalization, at least for SMIMEA purposes (the actual e-mail addresses understood by users as canonical might bear a dotless i even if for SMIMEA purposes it becomes a dotted i). > * Clients that encounter an ascii localpart that is not all lower-case > try both keys, first the localpart as-is, then case-folded with > the "@lower:" prefix. Almost there :) Nico -- From nobody Thu Dec 11 14:15:04 2014 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 31B0C1A039C for ; Thu, 11 Dec 2014 14:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 sGf9rviFZZ3K for ; Thu, 11 Dec 2014 14:15:02 -0800 (PST) Received: from homiemail-a66.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id F1E721A01E1 for ; Thu, 11 Dec 2014 14:15:01 -0800 (PST) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id D01BB350072; Thu, 11 Dec 2014 14:15:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=zxc9rNXuoLJJCF EGlDVblnjzHQA=; b=xuRDTlkJraK5fPIYL/RuGsUNRTrITrHTqdVt7M2djGJrI1 g3kxmpRj1Fisw+vvUMtn6UIXirxWO2ANR/wNCFqtb54+c4EsHsDcnjgywb8sSBxC jVIn/kGu8uyO1JWkKXIYEke85w1cyLN/An9wWciiESL+tPA9gAVoh8/apLeXU= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPA id 87C5435005B; Thu, 11 Dec 2014 14:15:01 -0800 (PST) Date: Thu, 11 Dec 2014 16:15:01 -0600 From: Nico Williams To: "Rose, Scott W." Message-ID: <20141211221456.GI3448@localhost> References: <95826148-4F06-4942-87A4-2F6601BA0F90@nist.gov> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <95826148-4F06-4942-87A4-2F6601BA0F90@nist.gov> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/CPAJ2PXFo79yCaUjqmaWebEHRXQ Cc: dane WG list Subject: Re: [dane] email canonicalization for SMIMEA owner names 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: Thu, 11 Dec 2014 22:15:03 -0000 On Thu, Dec 11, 2014 at 02:51:27PM -0500, Rose, Scott W. wrote: > Realized the other action item I was assigned to from the interim meeting was email canonicalization for SMIMEA. I believe it stems from Viktor Dukhovni's email to the endymail list: > http://www.ietf.org/mail-archive/web/endymail/current/msg00134.html Er, the case-(in)sensitivity of DNS seems irrelvant here (re: Viktor's point (e) in that post). After all, we'd be hashing the local-part. All that matters is that senders, resenders, ... preserve the form given them by recipients. So maybe we need no canonicalization step at all. If I say I'm foo@bar.example, and you type Foo@bar.example into your MUA to send me e-mail, you might not reach me. That seems fair. And allows for aliases of any kind. If I want to publish SMIMEA RRs for all possible capitalizations of "foo" @bar.example, well I can, and if I don't want to then I don't have to. Nico -- From nobody Thu Dec 11 14:35:34 2014 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 3D6D81A8AA9 for ; Thu, 11 Dec 2014 14:35:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.351 X-Spam-Level: X-Spam-Status: No, score=-3.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, 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 uSnR_HyDTQhw for ; Thu, 11 Dec 2014 14:35:30 -0800 (PST) Received: from mx.roessner-net.de (mail.roessner-net.de [193.239.107.42]) (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 2C93E1A8A9D for ; Thu, 11 Dec 2014 14:35:30 -0800 (PST) Received: from mail.roessner-net.de (mail.roessner-net.de [193.239.107.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.roessner-net.de", Issuer "Thawte DV SSL CA" (verified OK)) by mx.roessner-net.de (Postfix) with ESMTPS id 3jz91r2z51zGp6N; Thu, 11 Dec 2014 23:35:28 +0100 (CET) Received: from [172.16.2.200] (static-201-106.deltasurf.de [193.239.106.201]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Christian Roessner", Issuer "RootCA (c) 2014" (verified OK)) (Authenticated sender: c@roessner.co) by mail.roessner-net.de (Postfix) with ESMTPSA id 3jz91q6JDPzMlPk; Thu, 11 Dec 2014 23:35:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=roessner-network-solutions.com; s=swioBi3opho; t=1418337328; i=@roessner-network-solutions.com; bh=b0t7FOAkq19vvK7nIJZo7C528/H7Nv9kDLNBFzynOv8=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=l+8UzbwCYC14rhmMedT+UOwqCTKDOakrMQreeb3GCfAwPknspcuYmpsTXonZeZuch Ooulw5QqwLY+OiAzDoynqtwYYevBO5PzRkCbArg803INKj62dcMnCFupgfxhVgodX4 gAEUflOmjkVTkGLoVUEgJxfrjPYQWTrIZz0YyNW0t0jeJkjJWpaFNSUYel45mIRyNB OVm1cEPy4+h976kIR78rrzFuO+JWaNS0tGiRzlq6AR1QXmT0PvHA7Al74MqFW1675F VZ5fZpWKNfYVyC+EO3dZADcWOSqbn37DA+2A6tIT4N9FJQZd6Yzm4i7jKgr4ERefY5 nIUq4tvcBG1ow== Content-Type: multipart/signed; boundary="Apple-Mail=_C1A51581-AAE5-4B4F-9CE6-A440A679007E"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2063\)) From: =?utf-8?Q?Christian_R=C3=B6=C3=9Fner?= In-Reply-To: <95826148-4F06-4942-87A4-2F6601BA0F90@nist.gov> Date: Thu, 11 Dec 2014 23:35:24 +0100 Message-Id: References: <95826148-4F06-4942-87A4-2F6601BA0F90@nist.gov> To: "Rose, Scott W." X-Mailer: Apple Mail (2.2063) X-Outgoing: 0.2.0_alpha1 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/LTY_7vKvvSquc9WMxc-_vbJaT8Y Cc: dane WG list Subject: Re: [dane] email canonicalization for SMIMEA owner names 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: Thu, 11 Dec 2014 22:35:33 -0000 --Apple-Mail=_C1A51581-AAE5-4B4F-9CE6-A440A679007E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, > Am 11.12.2014 um 20:51 schrieb Rose, Scott W. : >=20 > Realized the other action item I was assigned to from the interim = meeting was email canonicalization for SMIMEA. I believe it stems from = Viktor Dukhovni's email to the endymail list: > http://www.ietf.org/mail-archive/web/endymail/current/msg00134.html >=20 > I was wondering if we can borrow a page from RFC 4034 Section 6.2 and = include text in the draft Section 3, item 1 in the numbered list: >=20 > 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]), is hashed using the SHA2-224 [RFC5754] > algorithm (with the hash being represented in its hexadecimal > representation, to become the left-most label in the prepared > domain name. This does not include the "@" character that > separates the left and right sides of the email address. The > string that is used for the local part is a Unicode string > encoded in UTF-8 **with all upper case letters converted to = their > corresponding lower case letters where appropriate.** >=20 >=20 > The text between the '**' is new. The goal is to prevent a situation = when the email address is "JRandom@example.com" and the SMIMEA is = created using "jrandom" as the user name. Would this be enough, or are = there scripts where this would result in different or potentially = conflicting owner names? =20 sorry, if my answer might be a little bit off-topic. When the draft for = SMIMEA was posted the first time, I wrote to someone here on the list = off-list. I asked, why to use SHA2-224 for the local part of an email = address. I thought about useability for many of records in DNS for a = large company. That seeing only hashes and nothing readable would make = it nearly impossible to find a record again manually without technical = help. So I thought about punycode RFC3492. I know the RFC might only be for = domains, but I asked myself, why this would not be applied to a local = part as well. Many countries would benefit from such a representation, because the = have parts of the latin alphabet and therefor just a hand full of = characters would need conversion. I am a layperson, so these are just my ideas and there might exists good = reasons, why this is not applicable. But at least I did not want to miss = the chance to bring up this discussion. And sorry, if this is not 100% answer to this thread. At least it = focuses on parts of the SHA2-224 and I wanted to give an optional view. Kind regards Christian -- Bachelor of Science Informatik Erlenwiese 14, 36304 Alsfeld T: +49 6631 78823400, F: +49 6631 78823409, M: +49 171 9905345 USt-IdNr.: DE225643613, http://www.roessner-network-solutions.com --Apple-Mail=_C1A51581-AAE5-4B4F-9CE6-A440A679007E Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIE8TCCBO0w ggPVoAMCAQICAhAFMA0GCSqGSIb3DQEBCwUAMIHeMQswCQYDVQQGEwJERTESMBAGCgmSJomT8ixk ARkWAmRlMRwwGgYKCZImiZPyLGQBGRYMcm9lc3NuZXItbmV0MQ8wDQYDVQQIDAZIZXNzZW4xEDAO BgNVBAcMB0Fsc2ZlbGQxDzANBgNVBAoMBlIuTi5TLjEeMBwGA1UECwwVQ2VydGlmaWNhdGUgQXV0 aG9yaXR5MRgwFgYDVQQDDA9Sb290Q0EgKGMpIDIwMTQxLzAtBgkqhkiG9w0BCQEWIGNAcm9lc3Nu ZXItbmV0d29yay1zb2x1dGlvbnMuY29tMB4XDTE0MDkwNzE0MDI0NloXDTI0MDkwNDE0MDI0Nlow gdAxCzAJBgNVBAYTAkRFMRIwEAYKCZImiZPyLGQBGRYCZGUxHDAaBgoJkiaJk/IsZAEZFgxyb2Vz c25lci1uZXQxDzANBgNVBAgMBkhlc3NlbjEQMA4GA1UEBwwHQWxzZmVsZDEPMA0GA1UECgwGUi5O LlMuMQ0wCwYDVQQLDARNYWlsMRswGQYDVQQDDBJDaHJpc3RpYW4gUm9lc3NuZXIxLzAtBgkqhkiG 9w0BCQEWIGNAcm9lc3NuZXItbmV0d29yay1zb2x1dGlvbnMuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAvRa6QBgHt56hf1RuKHsNkXPXTFzG0RLualxlyfsJS0nWNWFaBD7ceZ8F WhnP7ypHSyWE4aCy7BYM4n2iVDm9m8bKV5cXuSdLY3kefqSOk9+YvCLu1MqQk70BY7UReS7OUJ1r ml1v09igaYA1+4FT8Um5oXB69BMm/JxFlkJ/TEu7KQzZ++oWavezChU+tc3neP4TJ9B+e4Q3BiTW RPMzmWf1HDR9RfhU4YPT0AQpvMusYUN/QKqKgh7cCCx8fcMO7noZDCNJchKLuil8/jKznJtj8+/B mwbvHJjshv/txNxKr8Id1K7+cQMweMA6uuOiJIt9oOAcPM8UEMzFwrShvwIDAQABo4HAMIG9MAkG A1UdEwQCMAAwLAYJYIZIAYb4QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVkIENlcnRpZmljYXRlMB0G A1UdDgQWBBQkzf3k5Z/BAcTvlAu53yCIqJXMUzAfBgNVHSMEGDAWgBTgcUa1UKCapZJ6/qUWTH2C bOT9nDBCBgNVHR8EOzA5MDegNaAzhjFodHRwOi8vd3d3LnJvZXNzbmVyLW5ldHdvcmstc29sdXRp b25zLmNvbS9jcmwucGVtMA0GCSqGSIb3DQEBCwUAA4IBAQBGVbjnbP3RkXd5BStfKfyGWwNAAzrS dR1fy+tje5Zoq8t9nvxtaNnPCehyztTgUFfNaARFI5yY+z2ZaJ58NnQhSKYuZDkx/mwZkGcVbvp5 r7uDqFo42OfHej6SMIMzwKuXEgF26bKmcm4uZOouw8Ec68raEfnRY22loL8usx2yrH1qURgjSTJP PZ2Rs+2WVTWxylhLADAf7aAXTUPCx4zW6cGPYA2GR8w9ZYk74fIpPus4hs/LbBUVYtOMX6daVwkC 8xmQmcRihGo8wB5N2dH2T0fPV70HSn5GTUQ8O69ObDT8zo33dvg2w4swbWaKdn11Ywhd+HhvM+Ru bOSB+EBuMYIEYjCCBF4CAQEwgeUwgd4xCzAJBgNVBAYTAkRFMRIwEAYKCZImiZPyLGQBGRYCZGUx HDAaBgoJkiaJk/IsZAEZFgxyb2Vzc25lci1uZXQxDzANBgNVBAgMBkhlc3NlbjEQMA4GA1UEBwwH QWxzZmVsZDEPMA0GA1UECgwGUi5OLlMuMR4wHAYDVQQLDBVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkx GDAWBgNVBAMMD1Jvb3RDQSAoYykgMjAxNDEvMC0GCSqGSIb3DQEJARYgY0Byb2Vzc25lci1uZXR3 b3JrLXNvbHV0aW9ucy5jb20CAhAFMAkGBSsOAwIaBQCgggJRMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MTIxMTIyMzUyN1owIwYJKoZIhvcNAQkEMRYEFGwWQTOg 7SSGOXgkRZOKJdQ1BwwYMIH2BgkrBgEEAYI3EAQxgegwgeUwgd4xCzAJBgNVBAYTAkRFMRIwEAYK CZImiZPyLGQBGRYCZGUxHDAaBgoJkiaJk/IsZAEZFgxyb2Vzc25lci1uZXQxDzANBgNVBAgMBkhl c3NlbjEQMA4GA1UEBwwHQWxzZmVsZDEPMA0GA1UECgwGUi5OLlMuMR4wHAYDVQQLDBVDZXJ0aWZp Y2F0ZSBBdXRob3JpdHkxGDAWBgNVBAMMD1Jvb3RDQSAoYykgMjAxNDEvMC0GCSqGSIb3DQEJARYg Y0Byb2Vzc25lci1uZXR3b3JrLXNvbHV0aW9ucy5jb20CAhAFMIH4BgsqhkiG9w0BCRACCzGB6KCB 5TCB3jELMAkGA1UEBhMCREUxEjAQBgoJkiaJk/IsZAEZFgJkZTEcMBoGCgmSJomT8ixkARkWDHJv ZXNzbmVyLW5ldDEPMA0GA1UECAwGSGVzc2VuMRAwDgYDVQQHDAdBbHNmZWxkMQ8wDQYDVQQKDAZS Lk4uUy4xHjAcBgNVBAsMFUNlcnRpZmljYXRlIEF1dGhvcml0eTEYMBYGA1UEAwwPUm9vdENBIChj KSAyMDE0MS8wLQYJKoZIhvcNAQkBFiBjQHJvZXNzbmVyLW5ldHdvcmstc29sdXRpb25zLmNvbQIC EAUwDQYJKoZIhvcNAQEBBQAEggEAXK5lw2PdRzlQ2Pj9M9tERaJuMyaTrju/8zCfXCALjjKUeQhR /vIBx3O5wMwbHy6KL7bKLiJy9zTiZ6UrEMWCuCOBlqwGxlaM5MokLSCW19qj3NqevmpzEV5cRVwN A+Q6htQ8hH6pdUzF7yCB1HffiLk6hrx32s+qMUQPswSQDmEJ3D0Um7UwW2QBA3GEM8S75yCLgqJn McHTlU6HuY13tg7xFchJc7/+6iJ1IytkrtXL9+B25k3Bs3fmQcpCPOYxjop45sLHafbs4HdgL8CY ka1g6C8/nB4n9we7t7nOhFTPJONPfCVntA6obZs+yuWoQU3eQqIMiVGsrd28hRZ8LAAAAAAAAA== --Apple-Mail=_C1A51581-AAE5-4B4F-9CE6-A440A679007E-- From nobody Thu Dec 11 14:40:33 2014 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 6DD461A0389 for ; Thu, 11 Dec 2014 14:40:32 -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 mHo3yBEyrVQO for ; Thu, 11 Dec 2014 14:40:30 -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 3DBE61A1BB1 for ; Thu, 11 Dec 2014 14:40:30 -0800 (PST) Received: (qmail 85850 invoked from network); 11 Dec 2014 22:40:25 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 11 Dec 2014 22:40:25 -0000 Date: 11 Dec 2014 22:40:07 -0000 Message-ID: <20141211224007.10592.qmail@ary.lan> From: "John Levine" To: dane@ietf.org In-Reply-To: <20141211220308.GH3448@localhost> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/zplY4TlC71RevHriDoypHsQdUhk Subject: Re: [dane] email canonicalization for SMIMEA owner names 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: Thu, 11 Dec 2014 22:40:32 -0000 >Well, domains could publish the local-part canonicalization function >they use, or, rather, a small index of well-known canonicalization >functions. Mail systems do fuzzy matching on local parts in an enormous number of ways. But you will find that once you get past "map it all to lower case" the rest of them are all out at the tail of the curve. I don't know anyone other than Gmail that treats dots as noise characters (bobsmith@gmail.com, Bob.Smith@gmail.com, and B.o.B.s.M.i.T.h@gmail.com are all the same mailbox) but since Gmail is such a large player, do they get their own special case? Personally, I think that: a) Viktor's approach is terrible, and 2) it's the best we're going to do so we might as well use it. R's, John From nobody Thu Dec 11 14:51:19 2014 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 2716D1A711A for ; Thu, 11 Dec 2014 14:51:02 -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 aw6DV9rgmizr for ; Thu, 11 Dec 2014 14:51:01 -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 38B821A1AA9 for ; Thu, 11 Dec 2014 14:51:01 -0800 (PST) Received: (qmail 87241 invoked from network); 11 Dec 2014 22:50:56 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 11 Dec 2014 22:50:56 -0000 Date: 11 Dec 2014 22:50:38 -0000 Message-ID: <20141211225038.10634.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: http://mailarchive.ietf.org/arch/msg/dane/Et1HI4_Ja8vsCoESVcbwsa9P4LQ Subject: Re: [dane] email canonicalization for SMIMEA owner names 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: Thu, 11 Dec 2014 22:51:02 -0000 >So I thought about punycode RFC3492. I know the RFC might only be for domains, but I asked >myself, why this would not be applied to a local part as well. Mailboxes can contain characters not valid in punycode. Mailboxes in regular ASCII mail can contain spaces and ASCII graphics. Mailboxes in EAI mail can include arbitrary UTF-8. You could imagine a punycode-like encoding for mailboxes, or perhaps something more like quoted printable, but punycode or A-labels aren't adequate. Also keep in mind that RFC 5321 says that mailbox names are opaque, so any case folding we do is technically wrong. But in practice everyone expects case folded mailboxes to work, so even mail purists are likely to grumble but admit that a hack like Viktor's optional lower case is OK. R's, John From nobody Thu Dec 11 15:12:42 2014 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 A8AF31A8A56 for ; Thu, 11 Dec 2014 15:12:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.088 X-Spam-Level: X-Spam-Status: No, score=-1.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 N9sKnDohHlP9 for ; Thu, 11 Dec 2014 15:12:34 -0800 (PST) Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F97D1A8ACA for ; Thu, 11 Dec 2014 15:12:29 -0800 (PST) Received: by mail-vc0-f176.google.com with SMTP id hq12so2992668vcb.21 for ; Thu, 11 Dec 2014 15:12:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=GVvu86A4yuQnVamGMIk8N6swbjUwXS1xwHiGtwP5Dzk=; b=RUCirg3t9aZeDjY6CAUiHiYhrPykHgFem9nux4dcFHGQZ/CD9AyP/KZgs/uSWpevMJ IaXG4Wi7VA5RZT4iJsQk+8GvYaPb2ARLZVFtuatYtYf+FXh2M/eIlZsJ/VKEwaXw9Zoa nRRa4i64lxfp9foL+oUnVWp5yVOuLZFC2mFlpa3bxgtsE9QKANvJrYq2yq58FaG1O5PA zBhPRHNifTYY6Ye2IeTjgCCSdv8Lc7AH0fI+FKOYG1VgBSEyd5nyT8Ei0uhLlpqyAQJm /1PT+nhM72JOwz/jcGZWfu+bQ+1SDJMcTMQzIywO+0TF9HseZ4xp7RC7w0Vae2hsb02f z1rQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=GVvu86A4yuQnVamGMIk8N6swbjUwXS1xwHiGtwP5Dzk=; b=GTlk2cqi1tqC3ZDddBnoTm8ol6ASPSjM9TNCY0sWZILlQ3O6APe8auWrSVtdpbjSND TPzrBCUEhZv2UAs0hf/bt4yb7Jmzu6P++2sKg8zW86s2LI8sEFDJlL5R48A3eWku+bAR tW2vOS3XLC4lE4x91GRuh117gyGQ7M4rCB7+Ulr34CUrNRIw91XDTGGECw6qrgp+tiqh uuvXZI5DFRethEb9rHPFzSJH1lQBIZn/uzTaVwOyo00P+290GcBEcoHmoOp4vRK2pErc Xe93hEAE7y7gIeasbjQ5npxfQmEbpqMzX6hqf37NhelQH39rPA9fbTbpuUK9RIDIjgsu YrMQ== X-Gm-Message-State: ALoCoQmq/VEqZIbXkCnnte9NZ203b1WhX2csist1HTS6lGLhvI8EZFuUZx0UcTsSr73titobmM51 MIME-Version: 1.0 X-Received: by 10.220.102.20 with SMTP id e20mr9371280vco.12.1418339548547; Thu, 11 Dec 2014 15:12:28 -0800 (PST) Received: by 10.52.13.163 with HTTP; Thu, 11 Dec 2014 15:12:28 -0800 (PST) In-Reply-To: <20141211225038.10634.qmail@ary.lan> References: <20141211225038.10634.qmail@ary.lan> Date: Thu, 11 Dec 2014 15:12:28 -0800 Message-ID: From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= To: John Levine Content-Type: multipart/alternative; boundary=047d7b3a9442f6778f0509f8e8d3 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/0ve6wDZ0yiCOoNSDz8Sn5S6KIKA Cc: dane@ietf.org Subject: Re: [dane] email canonicalization for SMIMEA owner names X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ifette@google.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 23:12:35 -0000 --047d7b3a9442f6778f0509f8e8d3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit I don't know how that's supposed to work with EAI. We are working towards EAI deployment, and while we will probably have to do some normalization (ｲｱﾝﾌｪｯﾃｨ -> イアンフェッティ) I would not make some generic assumption. Until there's more deployment and experience I don't think it's safe to make assumptions there. 2014-12-11 14:50 GMT-08:00 John Levine : > >So I thought about punycode RFC3492. I know the RFC might only be for > domains, but I asked > >myself, why this would not be applied to a local part as well. > > Mailboxes can contain characters not valid in punycode. Mailboxes in > regular ASCII mail can contain spaces and ASCII graphics. Mailboxes > in EAI mail can include arbitrary UTF-8. > > You could imagine a punycode-like encoding for mailboxes, or perhaps > something more like quoted printable, but punycode or A-labels aren't > adequate. > > Also keep in mind that RFC 5321 says that mailbox names are opaque, so > any case folding we do is technically wrong. But in practice everyone > expects case folded mailboxes to work, so even mail purists are likely > to grumble but admit that a hack like Viktor's optional lower case is > OK. > > R's, John > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > --047d7b3a9442f6778f0509f8e8d3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
I don't know how that's supposed to work with EAI. We are working towards EAI deployment, and while we will probably have to do some normalization (ｲｱﾝﾌｪｯﾃｨ -> イアンフェッティ) I would not make some generic assumption. Until there's more deployment and experience I don't think it's safe to make assumptions there.

2014-12-11 14:50 GMT-08:00 John Levine <johnl@taugh.com>:
>So I thought about punycode RFC3492. I know the RFC might only be for domains, but I asked
>myself, why this would not be applied to a local part as well.

Mailboxes can contain characters not valid in punycode.  Mailboxes in
regular ASCII mail can contain spaces and ASCII graphics.  Mailboxes
in EAI mail can include arbitrary UTF-8.

You could imagine a punycode-like encoding for mailboxes, or perhaps
something more like quoted printable, but punycode or A-labels aren't
adequate.

Also keep in mind that RFC 5321 says that mailbox names are opaque, so
any case folding we do is technically wrong.  But in practice everyone
expects case folded mailboxes to work, so even mail purists are likely
to grumble but admit that a hack like Viktor's optional lower case is
OK.

R's, John

_______________________________________________
dane mailing list
dane@ietf.org
https://www.ietf.org/mailman/listinfo/dane

--047d7b3a9442f6778f0509f8e8d3-- From nobody Thu Dec 11 15:55:27 2014 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 B93E21A1A76 for ; Thu, 11 Dec 2014 15:55:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 I8SWTUWgKof8 for ; Thu, 11 Dec 2014 15:55:23 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08DE01A1A23 for ; Thu, 11 Dec 2014 15:55:21 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D2547282F8B; Thu, 11 Dec 2014 23:55:19 +0000 (UTC) Date: Thu, 11 Dec 2014 23:55:19 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141211235519.GO25666@mournblade.imrryr.org> References: <95826148-4F06-4942-87A4-2F6601BA0F90@nist.gov> <20141211221456.GI3448@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141211221456.GI3448@localhost> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/z6XLkL30a3N67dtpenAm9ESL4sE Subject: Re: [dane] email canonicalization for SMIMEA owner names X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 23:55:24 -0000 On Thu, Dec 11, 2014 at 04:15:01PM -0600, Nico Williams wrote: > If I want to > publish SMIMEA RRs for all possible capitalizations of "foo" > @bar.example, well I can, and if I don't want to then I don't have to. The problem is that (without my encoding) a client can't tell whether the "foo@example.com" key it found really is the "FOO@example.com" it wanted to reach, or whether that is some other mailbox. Yes, any mailbox provider that assigned mailboxes that way would be insane, but not "criminally insane"... :-) So my "@local:" prefix avoids collisions if there are in fact sites where mailboxes are case-sensitive. I am pleased with John Levine's characterization of my proposal: * It's terrible. * We may as well use it. Like passwords for authentication (or democracy as a form of governance), it stinks, but the other options stink more. -- Viktor. From nobody Thu Dec 11 16:10:08 2014 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 78BA01A90E0 for ; Thu, 11 Dec 2014 16:10:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 LSbEz3zjc84v for ; Thu, 11 Dec 2014 16:09:59 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88EFC1A90D8 for ; Thu, 11 Dec 2014 16:09:57 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id AB5A83493CE for ; Fri, 12 Dec 2014 00:09:55 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 09A02160067 for ; Fri, 12 Dec 2014 00:14:29 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id D292D16005C for ; Fri, 12 Dec 2014 00:14:28 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id B0FE5254EAE8 for ; Fri, 12 Dec 2014 11:09:53 +1100 (EST) To: dane@ietf.org From: Mark Andrews References: <95826148-4F06-4942-87A4-2F6601BA0F90@nist.gov> <20141211221456.GI3448@localhost> <20141211235519.GO25666@mournblade.imrryr.org> In-reply-to: Your message of "Thu, 11 Dec 2014 23:55:19 -0000." <20141211235519.GO25666@mournblade.imrryr.org> Date: Fri, 12 Dec 2014 11:09:53 +1100 Message-Id: <20141212000953.B0FE5254EAE8@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/dane/6uhMYBs9rPM1H-EXulzKD-HhcCc Subject: Re: [dane] email canonicalization for SMIMEA owner names 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: Fri, 12 Dec 2014 00:10:00 -0000 We could just do this correctly and use SRV records to point to keyserver servers running over TLS. The keyserver can do whatever local canonicalisations that are required. The SMTP server could even be performing this role on a different port. That way you only have to enter the canonicalisation rules once. This also gets rid of the complaints about being able to walk the zone. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Dec 11 16:31:35 2014 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 3E1431A90C5 for ; Thu, 11 Dec 2014 16:31:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 w5KNgW8qwbpu for ; Thu, 11 Dec 2014 16:31:32 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93EB51A90C0 for ; Thu, 11 Dec 2014 16:31:32 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 23782282F8B; Fri, 12 Dec 2014 00:31:31 +0000 (UTC) Date: Fri, 12 Dec 2014 00:31:31 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141212003130.GQ25666@mournblade.imrryr.org> References: <95826148-4F06-4942-87A4-2F6601BA0F90@nist.gov> <20141211221456.GI3448@localhost> <20141211235519.GO25666@mournblade.imrryr.org> <20141212000953.B0FE5254EAE8@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141212000953.B0FE5254EAE8@rock.dv.isc.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/VFy8mG0tmow2OiUFcBRMatnT3G4 Subject: Re: [dane] email canonicalization for SMIMEA owner names X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 00:31:34 -0000 On Fri, Dec 12, 2014 at 11:09:53AM +1100, Mark Andrews wrote: > We could just do this correctly and use SRV records to point to > keyserver servers running over TLS. The keyserver can do whatever > local canonicalisations that are required. The SMTP server could > even be performing this role on a different port. That way you > only have to enter the canonicalisation rules once. > > This also gets rid of the complaints about being able to walk the > zone. Since this is the DANE working group, those would be DANE TLSA authenticated servers, designated via a suitable SRV record. The presence of the SRV record itself would signal adoption of the protocol by the domain. However, this makes the protocol much more complex. Mail clients that just do local submission and did not need a TLS stack, would now need to implement HTTPS, and we'd end-up defining a rather complex protocol layered over that. DNS does scale better. If we're really going to do this as a direct query to the remote domain (and not a DNSSEC lookup), perhaps the right application protocol is some sort of minimal SMTP over SSL on a port indicated by the SRV record: C/S: C: SMIMEA "Frank.Jr."@example.com S: 250-3 1 1 S: 250 3 1 2 HTTP seems like much too much baggage, and the above could actually be an additional service operated as part of the MTA, (the email administrator would not need to be either a DNS administrator or a webmaster). The SMTP server would know how/whether to case-fold the address. -- Viktor. From nobody Thu Dec 11 16:41:39 2014 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 C7D7F1A90C8 for ; Thu, 11 Dec 2014 16:41:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 ImpPMFY2PlkF for ; Thu, 11 Dec 2014 16:41:36 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1894F1A8893 for ; Thu, 11 Dec 2014 16:41:36 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id C45A83493CE for ; Fri, 12 Dec 2014 00:41:33 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 0669E16006A for ; Fri, 12 Dec 2014 00:46:07 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id AC92B160069 for ; Fri, 12 Dec 2014 00:46:06 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 09FDB254F4F4 for ; Fri, 12 Dec 2014 11:41:31 +1100 (EST) To: dane@ietf.org From: Mark Andrews References: <95826148-4F06-4942-87A4-2F6601BA0F90@nist.gov> <20141211221456.GI3448@localhost> <20141211235519.GO25666@mournblade.imrryr.org> <20141212000953.B0FE5254EAE8@rock.dv.isc.org> <20141212003130.GQ25666@mournblade.imrryr.org> In-reply-to: Your message of "Fri, 12 Dec 2014 00:31:31 -0000." <20141212003130.GQ25666@mournblade.imrryr.org> Date: Fri, 12 Dec 2014 11:41:30 +1100 Message-Id: <20141212004131.09FDB254F4F4@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/dane/48psQjv4kwGfOD01yizV6gGCouw Subject: Re: [dane] email canonicalization for SMIMEA owner names 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: Fri, 12 Dec 2014 00:41:37 -0000 In message <20141212003130.GQ25666@mournblade.imrryr.org>, Viktor Dukhovni writes: > On Fri, Dec 12, 2014 at 11:09:53AM +1100, Mark Andrews wrote: > > > We could just do this correctly and use SRV records to point to > > keyserver servers running over TLS. The keyserver can do whatever > > local canonicalisations that are required. The SMTP server could > > even be performing this role on a different port. That way you > > only have to enter the canonicalisation rules once. > > > > This also gets rid of the complaints about being able to walk the > > zone. > > Since this is the DANE working group, those would be DANE TLSA > authenticated servers, designated via a suitable SRV record. > > The presence of the SRV record itself would signal adoption of the > protocol by the domain. > > However, this makes the protocol much more complex. Mail clients > that just do local submission and did not need a TLS stack, would > now need to implement HTTPS, and we'd end-up defining a rather > complex protocol layered over that. If mail clients are doing SMIME the addition complexity of HTTPS or TLS is not much. > DNS does scale better. No, it doesn't. DNS scales equally well. > If we're really going to do this as a direct query to the remote > domain (and not a DNSSEC lookup), perhaps the right application > protocol is some sort of minimal SMTP over SSL on a port indicated > by the SRV record: > > > C/S: > C: SMIMEA "Frank.Jr."@example.com > S: 250-3 1 1 > S: 250 3 1 2 > But not port 25. That is blocked too often. > HTTP seems like much too much baggage, and the above could actually > be an additional service operated as part of the MTA, (the email > administrator would not need to be either a DNS administrator or > a webmaster). The SMTP server would know how/whether to case-fold > the address. > > -- > Viktor. > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Dec 11 16:55:54 2014 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 4BFC81A90DB for ; Thu, 11 Dec 2014 16:55:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 c8s3U4rS5nr0 for ; Thu, 11 Dec 2014 16:55:51 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6898C1A90C9 for ; Thu, 11 Dec 2014 16:55:51 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 92980282F8B; Fri, 12 Dec 2014 00:55:50 +0000 (UTC) Date: Fri, 12 Dec 2014 00:55:50 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141212005550.GR25666@mournblade.imrryr.org> References: <95826148-4F06-4942-87A4-2F6601BA0F90@nist.gov> <20141211221456.GI3448@localhost> <20141211235519.GO25666@mournblade.imrryr.org> <20141212000953.B0FE5254EAE8@rock.dv.isc.org> <20141212003130.GQ25666@mournblade.imrryr.org> <20141212004131.09FDB254F4F4@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141212004131.09FDB254F4F4@rock.dv.isc.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/Kt-X5gsR1QDu6XXKter9nj6pYSM Subject: Re: [dane] email canonicalization for SMIMEA owner names X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 00:55:53 -0000 On Fri, Dec 12, 2014 at 11:41:30AM +1100, Mark Andrews wrote: > > If we're really going to do this as a direct query to the remote > > domain (and not a DNSSEC lookup), perhaps the right application > > protocol is some sort of minimal SMTP over SSL on a port indicated > > by the SRV record: > > > > > > C/S: > > C: SMIMEA "Frank.Jr."@example.com > > S: 250-3 1 1 > > S: 250 3 1 2 > > > > But not port 25. That is blocked too often. Absolutely, this would be an additional service on some other port, indicated via SRV records, and authenticated via DANE TLSA records. The downside of something other than HTTPS or DNS, is that while less likely to be blocked for anti-spam reasons, this is likely to be inaccessible to MUAs inside various firewalled environments. Perhaps a sufficiently light-weight http encapsulation is right after all, and MTA authors might be able to implement just enough HTTPS to still support this as an MTA feature. In Postfix this would be a separate program that runs out of "master.cf", but uses the Postfix table facilities to get the data out of any supported datastore (including LDAP!). This however takes far away from any similarity to the SMIMEA draft as it is today. Is it really time to throw it all away and start again? -- Viktor. From nobody Thu Dec 11 17:00:18 2014 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 2BFEE1A90E6 for ; Thu, 11 Dec 2014 17:00:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 cCn6YYB7TWWF for ; Thu, 11 Dec 2014 17:00:13 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BF281A90C8 for ; Thu, 11 Dec 2014 17:00:13 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id F34591FCD01 for ; Fri, 12 Dec 2014 01:00:09 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id C3EA8160068 for ; Fri, 12 Dec 2014 01:04:42 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 8CE1716005C for ; Fri, 12 Dec 2014 01:04:42 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 2F78C254FBF3 for ; Fri, 12 Dec 2014 12:00:07 +1100 (EST) To: dane@ietf.org From: Mark Andrews References: <95826148-4F06-4942-87A4-2F6601BA0F90@nist.gov> <20141211221456.GI3448@localhost> <20141211235519.GO25666@mournblade.imrryr.org> <20141212000953.B0FE5254EAE8@rock.dv.isc.org> <20141212003130.GQ25666@mournblade.imrryr.org> <20141212004131.09FDB254F4F4@rock.dv.isc.org> <20141212005550.GR25666@mournblade.imrryr.org> In-reply-to: Your message of "Fri, 12 Dec 2014 00:55:50 -0000." <20141212005550.GR25666@mournblade.imrryr.org> Date: Fri, 12 Dec 2014 12:00:07 +1100 Message-Id: <20141212010007.2F78C254FBF3@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/dane/c1CFHBWAkkAADn_1THV20d9e2aI Subject: Re: [dane] email canonicalization for SMIMEA owner names 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: Fri, 12 Dec 2014 01:00:17 -0000 In message <20141212005550.GR25666@mournblade.imrryr.org>, Viktor Dukhovni writ es: > On Fri, Dec 12, 2014 at 11:41:30AM +1100, Mark Andrews wrote: > > > > If we're really going to do this as a direct query to the remote > > > domain (and not a DNSSEC lookup), perhaps the right application > > > protocol is some sort of minimal SMTP over SSL on a port indicated > > > by the SRV record: > > > > > > > > > C/S: > > > C: SMIMEA "Frank.Jr."@example.com > > > S: 250-3 1 1 > > > S: 250 3 1 2 > > > > > > > But not port 25. That is blocked too often. > > Absolutely, this would be an additional service on some other port, > indicated via SRV records, and authenticated via DANE TLSA records. > > The downside of something other than HTTPS or DNS, is that while > less likely to be blocked for anti-spam reasons, this is likely to > be inaccessible to MUAs inside various firewalled environments. > > Perhaps a sufficiently light-weight http encapsulation is right > after all, and MTA authors might be able to implement just enough > HTTPS to still support this as an MTA feature. > > In Postfix this would be a separate program that runs out of > "master.cf", but uses the Postfix table facilities to get the data > out of any supported datastore (including LDAP!). > > This however takes far away from any similarity to the SMIMEA draft > as it is today. Is it really time to throw it all away and start > again? Yes. It's just a pity it has taken so long for other to realise this. > -- > Viktor. > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Dec 11 17:22:31 2014 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 D92381A90EB for ; Thu, 11 Dec 2014 17:22:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.088 X-Spam-Level: X-Spam-Status: No, score=-1.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 9I0_tQ2oS_2F for ; Thu, 11 Dec 2014 17:22:28 -0800 (PST) Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E2001A90E0 for ; Thu, 11 Dec 2014 17:22:04 -0800 (PST) Received: by mail-vc0-f173.google.com with SMTP id kv19so1397188vcb.4 for ; Thu, 11 Dec 2014 17:22:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=O83CSevLqeAkcai2PPdrEmth74RHotfVG72Tg8N8+W0=; b=jW0It/UZuJA5cZMvQzpXwuSo8Bvt+nAw4SsdbQy09VeCiDDRSlIyToBeIQu0Rfup8k NBE4UDW9AcyYf5N+BsEv8rwCoP7gPTF9qXxj+UGtDrvlBTzy1GJZ/6Xts2U/sD/Jzb2v aG9CjMhCFPEZSzd+rf1Fs+TsOAseMtznjPYtvIaL6NFEUxUK5gFTvS/TVXkqeHiCK3sL 1PjamzjtyIdzlF4v1u6q1mU7gGKZ/eF95ysLmsGJ1KhFpbKS1yz2Z11B+Y8XTY85FUgJ nv0qsRf7JXgVRmTjSrflRk+0OyuiS3zqcmFWgAXS/Pmd3Y2ze++5wE+uLzUwKqFar6xZ lDog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=O83CSevLqeAkcai2PPdrEmth74RHotfVG72Tg8N8+W0=; b=lIkGCgm3KQHFVrhrPjHO/O678lpBc2e6E1/jtHtpJKIUOBEKkGvOY0zIlFfQ0/YOfR 96XO8bu7oyo2zE9W7GbJ9CbqU1hgEQmyQ6Cffbv9fau2hRVA7NuZ6YK6RmJMygLF1ttR b2+ChcBObEcyoe92zVPuZVBmq9lwhUg7atpdLAxRrdPB4OeF4dvymMhsyNfVOT+dB0uy Q7ssL2enATZSUHo1X0sptjc0X1yDL7T/FjRV3h4livFrXKtYlbLUxnyJ8KH+oU+n65XQ 5VgqvGPzu2RiD5SnNTfh0Mc9JTJ0oBiXOFUkos6VXDxuPYXTXYbNAsNYSeKT1ZgosZsG P+mw== X-Gm-Message-State: ALoCoQnsAwd4DmfyM/VGvZR5NQ51hQN5E5AiVUsijN1UbWT91mdSxHxCRJBiIGRWC47zpGzZ/U8d MIME-Version: 1.0 X-Received: by 10.52.29.84 with SMTP id i20mr8033314vdh.1.1418347323259; Thu, 11 Dec 2014 17:22:03 -0800 (PST) Received: by 10.52.13.163 with HTTP; Thu, 11 Dec 2014 17:22:03 -0800 (PST) In-Reply-To: <20141212010007.2F78C254FBF3@rock.dv.isc.org> References: <95826148-4F06-4942-87A4-2F6601BA0F90@nist.gov> <20141211221456.GI3448@localhost> <20141211235519.GO25666@mournblade.imrryr.org> <20141212000953.B0FE5254EAE8@rock.dv.isc.org> <20141212003130.GQ25666@mournblade.imrryr.org> <20141212004131.09FDB254F4F4@rock.dv.isc.org> <20141212005550.GR25666@mournblade.imrryr.org> <20141212010007.2F78C254FBF3@rock.dv.isc.org> Date: Thu, 11 Dec 2014 17:22:03 -0800 Message-ID: From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= To: Mark Andrews Content-Type: multipart/alternative; boundary=20cf307cff105f29c10509fab8f5 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/0YRvyFvLBLMqiQXnYexrZOMBPI0 Cc: dane@ietf.org Subject: Re: [dane] email canonicalization for SMIMEA owner names X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ifette@google.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 01:22:30 -0000 --20cf307cff105f29c10509fab8f5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sorry, just reading the SMIMEA stuff for the first time, so apologies for the basic question, but do I really have to publish a record for each address? How would I say "this is a trusted intermediate CA for *@gmail.com "? 2014-12-11 17:00 GMT-08:00 Mark Andrews : > > > In message <20141212005550.GR25666@mournblade.imrryr.org>, Viktor > Dukhovni writ > es: > > On Fri, Dec 12, 2014 at 11:41:30AM +1100, Mark Andrews wrote: > > > > > > If we're really going to do this as a direct query to the remote > > > > domain (and not a DNSSEC lookup), perhaps the right application > > > > protocol is some sort of minimal SMTP over SSL on a port indicated > > > > by the SRV record: > > > > > > > > > > > > C/S: > > > > C: SMIMEA "Frank.Jr."@example.com > > > > S: 250-3 1 1 > > > > S: 250 3 1 2 > > > > > > > > > > But not port 25. That is blocked too often. > > > > Absolutely, this would be an additional service on some other port, > > indicated via SRV records, and authenticated via DANE TLSA records. > > > > The downside of something other than HTTPS or DNS, is that while > > less likely to be blocked for anti-spam reasons, this is likely to > > be inaccessible to MUAs inside various firewalled environments. > > > > Perhaps a sufficiently light-weight http encapsulation is right > > after all, and MTA authors might be able to implement just enough > > HTTPS to still support this as an MTA feature. > > > > In Postfix this would be a separate program that runs out of > > "master.cf", but uses the Postfix table facilities to get the data > > out of any supported datastore (including LDAP!). > > > > This however takes far away from any similarity to the SMIMEA draft > > as it is today. Is it really time to throw it all away and start > > again? > > Yes. It's just a pity it has taken so long for other to realise this. > > > -- > > Viktor. > > > > _______________________________________________ > > dane mailing list > > dane@ietf.org > > https://www.ietf.org/mailman/listinfo/dane > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > --20cf307cff105f29c10509fab8f5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Sorry, just reading the SMIMEA stuff for the first time, so apologies for the basic question, but do I really have to publish a record for each address? How would I say "this is a trusted intermediate CA for *@gmail.com"?

2014-12-11 17:00 GMT-08:00 Mark Andrews <marka@isc.org>:

In message <20141212005550.GR25666@mournblade.imrryr.org>, Viktor Dukhovni writ
es:
> On Fri, Dec 12, 2014 at 11:41:30AM +1100, Mark Andrews wrote:
>
> > > If we're really going to do this as a direct query to the remote
> > > domain (and not a DNSSEC lookup), perhaps the right application
> > > protocol is some sort of minimal SMTP over SSL on a port indicated
> > > by the SRV record:
> > >
> > >     <tcp connect>
> > >     C/S: <TLS handshake>
> > >     C: SMIMEA "Frank.Jr."@example.com
> > >     S: 250-3 1 1 <blob1>
> > >     S: 250 3 1 2 <blob2>
> > >     <TCP disconnect>
> >
> > But not port 25.  That is blocked too often.
>
> Absolutely, this would be an additional service on some other port,
> indicated via SRV records, and authenticated via DANE TLSA records.
>
> The downside of something other than HTTPS or DNS, is that while
> less likely to be blocked for anti-spam reasons, this is likely to
> be inaccessible to MUAs inside various firewalled environments.
>
> Perhaps a sufficiently light-weight http encapsulation is right
> after all, and MTA authors might be able to implement just enough
> HTTPS to still support this as an MTA feature.
>
> In Postfix this would be a separate program that runs out of
> "master.cf", but uses the Postfix table facilities to get the data
> out of any supported datastore (including LDAP!).
>
> This however takes far away from any similarity to the SMIMEA draft
> as it is today.  Is it really time to throw it all away and start
> again?

Yes.  It's just a pity it has taken so long for other to realise this.

> --
>       Viktor.
>
> _______________________________________________
> dane mailing list
> dane@ietf.org
> https://www.ietf.org/mailman/listinfo/dane
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

_______________________________________________
dane mailing list
dane@ietf.org
https://www.ietf.org/mailman/listinfo/dane
--20cf307cff105f29c10509fab8f5-- From nobody Thu Dec 11 17:37:15 2014 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 185CB1A1A2D for ; Thu, 11 Dec 2014 17:37:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 72RFnUuJ6bP3 for ; Thu, 11 Dec 2014 17:37:11 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1BDD1A9136 for ; Thu, 11 Dec 2014 17:36:57 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 64E69282F8B; Fri, 12 Dec 2014 01:36:56 +0000 (UTC) Date: Fri, 12 Dec 2014 01:36:56 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141212013656.GT25666@mournblade.imrryr.org> References: <95826148-4F06-4942-87A4-2F6601BA0F90@nist.gov> <20141211221456.GI3448@localhost> <20141211235519.GO25666@mournblade.imrryr.org> <20141212000953.B0FE5254EAE8@rock.dv.isc.org> <20141212003130.GQ25666@mournblade.imrryr.org> <20141212004131.09FDB254F4F4@rock.dv.isc.org> <20141212005550.GR25666@mournblade.imrryr.org> <20141212010007.2F78C254FBF3@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/UCt_GYDW33aqTe25v6B7EI7pFNk Subject: Re: [dane] email canonicalization for SMIMEA owner names X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 01:37:13 -0000 On Thu, Dec 11, 2014 at 05:22:03PM -0800, Ian Fette (????????) wrote: > Sorry, just reading the SMIMEA stuff for the first time, so apologies for > the basic question, but do I really have to publish a record for each > address? How would I say "this is a trusted intermediate CA for *@gmail.com > "? That would look like so: ;; insert CNAMEs for any desired indirection when ;; the same set of SMIMEA RRs handles multiple domains ;; *._smimecert.gmail.com IN SMIMEA 2 0 1 Keep in mind that this only supports signature verification, not encryption, one can't encrypt to an intermediate CA, one needs the leaf public key for that. So enabling encryption on first contact requires publishing per-user keys by some means. Otherwise all one gets is authenticated key exchange, possibly followed later by encryption once leaf keys have been exchanged in both directions. -- Viktor. From nobody Thu Dec 11 18:11:48 2014 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 535611A914D for ; Thu, 11 Dec 2014 18:11:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 wErWpGUHswnF for ; Thu, 11 Dec 2014 18:11:44 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BA8D1A9106 for ; Thu, 11 Dec 2014 18:11:44 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 6FA0F80046; Thu, 11 Dec 2014 21:11:43 -0500 (EST) Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id sBC2BgKF023620; Thu, 11 Dec 2014 21:11:42 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Thu, 11 Dec 2014 21:11:42 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Nico Williams In-Reply-To: <20141211221456.GI3448@localhost> Message-ID: References: <95826148-4F06-4942-87A4-2F6601BA0F90@nist.gov> <20141211221456.GI3448@localhost> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/dane/sAuS_Vgwegh_3cU1fhjTRCl-tGg Cc: dane WG list Subject: Re: [dane] email canonicalization for SMIMEA owner names 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: Fri, 12 Dec 2014 02:11:46 -0000 On Thu, 11 Dec 2014, Nico Williams wrote: > So maybe we need no canonicalization step at all. > > If I say I'm foo@bar.example, and you type Foo@bar.example into your > MUA to send me e-mail, you might not reach me. > > That seems fair. Actually, that is really stupid, seeing that many mobile phones, which are hard to type on to begin with, auto-capitalize for many reasons. My phone regularly corrects emails I forward to myself to Paul@nohats.ca. No currently maintained implementation of email should support that these two might be different local users. > And allows for aliases of any kind. If I want to > publish SMIMEA RRs for all possible capitalizations of "foo" > @bar.example, well I can, and if I don't want to then I don't have to. A client can lookup the given name, if NXDOMAIN and not all lowercase, lowercase it and try again. And someone should write an RFC updating SMTP to not allow case-sensitivity for different mailboxes so we can stop coming back to this whenever anyone wants to do anything with email addresses. Paul From nobody Thu Dec 11 18:14:11 2014 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 CF7391A914D for ; Thu, 11 Dec 2014 18:14:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 zuuMJIWbyDsU for ; Thu, 11 Dec 2014 18:14:09 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D2681A9143 for ; Thu, 11 Dec 2014 18:14:09 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 8C56A80046 for ; Thu, 11 Dec 2014 21:14:08 -0500 (EST) Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id sBC2E8Yh023790 for ; Thu, 11 Dec 2014 21:14:08 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Thu, 11 Dec 2014 21:14:08 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: dane WG list In-Reply-To: <20141211205053.GN25666@mournblade.imrryr.org> Message-ID: References: <95826148-4F06-4942-87A4-2F6601BA0F90@nist.gov> <20141211205053.GN25666@mournblade.imrryr.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dane/Y3o64OVx_newlcL6loBPu6M7bmE Subject: Re: [dane] email canonicalization for SMIMEA owner names 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: Fri, 12 Dec 2014 02:14:11 -0000 On Thu, 11 Dec 2014, Viktor Dukhovni wrote: > * Domains that publish user SMIMEA records, which intend for > for the names to be treated case insensitively, compute two > hashes for each name: > > SHA2-224("Frank.Jr.") -> > SHA2-224(@lower:"frank.jr.") -> > > The DNS records are then: > > .example.com. IN SMIMEA ... > .example.com. IN CNAME Are you confusing wire format with presentation format? Why the extra base32 ? Paul From nobody Thu Dec 11 19:43:31 2014 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 74DB31A1B4B for ; Thu, 11 Dec 2014 19:43:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 49BgllMJ8C99 for ; Thu, 11 Dec 2014 19:43:29 -0800 (PST) Received: from homiemail-a27.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 7D4981A1B3E for ; Thu, 11 Dec 2014 19:43:29 -0800 (PST) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id 3FDC859805F; Thu, 11 Dec 2014 19:43:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=W6OJ8M0f8bSv4i tDUSpU7fmBPTY=; b=ktOit5AFyWkAinafdN7XfOwYvLB4FK54C3JrHc4k4VyMM4 SaYwgNbDgQcgVfVNV+O03hfL/XZoCFkGFhnA9QFBA6zJydiB0VGlQVQ1wI/Zk0nO XNVRi5TeVa0aCWoh0TWDrDyCbCy6Hp9HuiBWumackZ1GNr4H69V7l5gqhe3bY= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPA id D4677598057; Thu, 11 Dec 2014 19:43:27 -0800 (PST) Date: Thu, 11 Dec 2014 21:43:27 -0600 From: Nico Williams To: Paul Wouters Message-ID: <20141212034323.GO3448@localhost> References: <95826148-4F06-4942-87A4-2F6601BA0F90@nist.gov> <20141211221456.GI3448@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/mqSfLHnxrfEtWctxSuhq62A0xHA Cc: dane WG list Subject: Re: [dane] email canonicalization for SMIMEA owner names 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: Fri, 12 Dec 2014 03:43:30 -0000 On Thu, Dec 11, 2014 at 09:11:42PM -0500, Paul Wouters wrote: > On Thu, 11 Dec 2014, Nico Williams wrote: > >So maybe we need no canonicalization step at all. > > > >If I say I'm foo@bar.example, and you type Foo@bar.example into your > >MUA to send me e-mail, you might not reach me. > > > >That seems fair. > > Actually, that is really stupid, seeing that many mobile phones, which > are hard to type on to begin with, auto-capitalize for many reasons. My > phone regularly corrects emails I forward to myself to Paul@nohats.ca. That's dumb of the MUA. Local-parts are case-sensitive as far as the standard goes, but MTAs can make them case-insensitive. (The same is true for all sorts of things. Filesystems, HTTP URIs, ...) If you have such a dumb MUA you would still be able to send e-mail if you got the address wrong and got an alias instead, you just wouldn't get SMIMEA. On mobiles it's all about how the app configures the keyboard context. Some apps match what you type against addresses of peers you've corresponded with before, and that's extremely useful, while plain old auto-correct for e-mail addresses is about the most obnoxious thing an MUA can do to its user. > No currently maintained implementation of email should support that these > two might be different local users. I can't decode this. The problem is that now we want the client to be able to find a public key for the recipient and encrypt to it, yes? But we also want to avoid making it trivial to find addresses to spam, no? Well, these two requirements conflict. Any solution that addresses them both is going to have the suckage you mention above. > >And allows for aliases of any kind. If I want to > >publish SMIMEA RRs for all possible capitalizations of "foo" > >@bar.example, well I can, and if I don't want to then I don't have to. > > A client can lookup the given name, if NXDOMAIN and not all lowercase, > lowercase it and try again. Yes, for ASCII that works. For Unicode it requires accepting more aliasing that one might want. I might not be opposed (I haven't decided), but the problem is that either way you're getting aliasing that the target domain may not want, but with Unicode there are tricky political problems ("why can't I have a dotless i in my address?" "well, you can" "but I keep seeing e-mail sent to my address with a dotted i, and that's wrong!" "well, uh..."). > And someone should write an RFC updating SMTP to not allow > case-sensitivity for different mailboxes so we can stop coming back to > this whenever anyone wants to do anything with email addresses. How would you know whether a target domain's local-parts are case sensitive or not? They aren't now. Nico -- From nobody Thu Dec 11 20:14:27 2014 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 6E83B1A1BA3 for ; Thu, 11 Dec 2014 20:14:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.066 X-Spam-Level: X-Spam-Status: No, score=-1.066 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_NONE=-0.0001] 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 22fRRjyNJmQm for ; Thu, 11 Dec 2014 20:14:24 -0800 (PST) Received: from homiemail-a103.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 90CB11A6F9A for ; Thu, 11 Dec 2014 20:14:24 -0800 (PST) Received: from homiemail-a103.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTP id 3D48C20047B83 for ; Thu, 11 Dec 2014 20:14:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:references:mime-version:content-type :in-reply-to; s=cryptonector.com; bh=Dy1CZoZkhLoWXb1ZR8ewiEbXP5Q =; b=kqFtT2Nj8aLyjcoq0L3/eN5A2Ts4ASfnotWNkEC/QjENUGFNHXpzmJ9XswM 8V15Wh+U1jMISaCq7bbR/COYI4LJpzW0fXhRolehq1Iv/r7Ta8CM9bsDBoB0MElj O5JtvuzIb/O9VSXZ6ruousMqgYKvqcvvY3rCgNWKK3+j73Os= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTPA id 0B4EB20047B80 for ; Thu, 11 Dec 2014 20:14:23 -0800 (PST) Date: Thu, 11 Dec 2014 22:14:23 -0600 From: Nico Williams To: dane@ietf.org Message-ID: <20141212041419.GP3448@localhost> References: <95826148-4F06-4942-87A4-2F6601BA0F90@nist.gov> <20141211221456.GI3448@localhost> <20141211235519.GO25666@mournblade.imrryr.org> <20141212000953.B0FE5254EAE8@rock.dv.isc.org> <20141212003130.GQ25666@mournblade.imrryr.org> <20141212004131.09FDB254F4F4@rock.dv.isc.org> <20141212005550.GR25666@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141212005550.GR25666@mournblade.imrryr.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/vuhkYGwuSRibhoSyh_RTyM2HZt4 Subject: Re: [dane] email canonicalization for SMIMEA owner names 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: Fri, 12 Dec 2014 04:14:25 -0000 On Fri, Dec 12, 2014 at 12:55:50AM +0000, Viktor Dukhovni wrote: > On Fri, Dec 12, 2014 at 11:41:30AM +1100, Mark Andrews wrote: > > [stuff about indirecting via a keyserver elided] SUBMIT/SMTP itself could act as the keyserver. There are two use cases: validate a sender's signing certificate, and get a recipient's encryption certificate. Both mean contacting the peer's domain's keyserver, but we could indirect through any SUBMIT server that the MUA can talk to, and we can authenticate any replies via DNSSEC in a way that does not permit walking the zone. I.e., Client: connect to C's MSA Client: VRFY_SENDER_CERT sender-local-part@sender.domain cert-hash MSA: connect to sender.domain's MTA MSA: VRFY_SENDER_CERT sender-local-part@sender.domain cert-hash The MTA responds, the MSA forwards the response. The client also does a DNS lookup for base32(H(sender certificate || sender address))._smimesendercert.sender.domain. and [hopefully] finds base32(H(sender address)). No need for the client to talk to sender.domain's MTA directly, so no concerns about port 25 blocking. And if the MSA lies, the client will find out. The client has to speak SUBMIT/SMTP anyways, and it has to support doing so with TLS (which the client's MSA surely will speak, and the network damned well ought to permit). > The downside of something other than HTTPS or DNS, is that while > less likely to be blocked for anti-spam reasons, this is likely to > be inaccessible to MUAs inside various firewalled environments. See above as to firewalls. But it's true that a pure DNSSEC scheme means that the client can encrypt e-mail to / validate e-mail signatures without having to worry about downgrade attacks on SMTP. We'd still want the client to use TLS for SUBMIT/SMTP though. A middle of the road might be that domains could publish RRSets for local-parts they don't mind people being able to walk, but not for those they do, with the trade-off being that the latter lose security (or access) when networks attempt MITM downgrade attacks on StartTLS. > Perhaps a sufficiently light-weight http encapsulation is right > after all, and MTA authors might be able to implement just enough > HTTPS to still support this as an MTA feature. Why HTTP? > [...] > This however takes far away from any similarity to the SMIMEA draft > as it is today. Is it really time to throw it all away and start > again? Maybe so. Nico -- From nobody Thu Dec 11 20:16:51 2014 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 0592A1A7017 for ; Thu, 11 Dec 2014 20:16:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 kr4IDZUgpSFU for ; Thu, 11 Dec 2014 20:16:47 -0800 (PST) Received: from homiemail-a26.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 51C291A6F9A for ; Thu, 11 Dec 2014 20:16:47 -0800 (PST) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id 1730FB805C for ; Thu, 11 Dec 2014 20:16:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:references:mime-version:content-type :in-reply-to; s=cryptonector.com; bh=5rVbtA751ZtQ6w8IfeIGwxH1/Ho =; b=GKrLUpnvvCisrdqW43z6t6GctTT3KVImnoxTNC9AIMDJiEGfXlmMruCzuMw jmJ9LqEtgF7Ps5s8e8ZTK3oAdIesU97QH/IHq/X8DP7fuDd5DtdASYAF8ZFFsq8K ZwEbz3pYUb0LP0bKmaJCvMgoDPQpExqV/EwoK47wO277qGs4= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPA id D8194B8057 for ; Thu, 11 Dec 2014 20:16:46 -0800 (PST) Date: Thu, 11 Dec 2014 22:16:46 -0600 From: Nico Williams To: dane@ietf.org Message-ID: <20141212041641.GQ3448@localhost> References: <95826148-4F06-4942-87A4-2F6601BA0F90@nist.gov> <20141211221456.GI3448@localhost> <20141211235519.GO25666@mournblade.imrryr.org> <20141212000953.B0FE5254EAE8@rock.dv.isc.org> <20141212003130.GQ25666@mournblade.imrryr.org> <20141212004131.09FDB254F4F4@rock.dv.isc.org> <20141212005550.GR25666@mournblade.imrryr.org> <20141212010007.2F78C254FBF3@rock.dv.isc.org> <20141212013656.GT25666@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141212013656.GT25666@mournblade.imrryr.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/aCwR6pHoznvpD6xj7bPXR8muZNE Subject: Re: [dane] email canonicalization for SMIMEA owner names 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: Fri, 12 Dec 2014 04:16:48 -0000 On Fri, Dec 12, 2014 at 01:36:56AM +0000, Viktor Dukhovni wrote: > On Thu, Dec 11, 2014 at 05:22:03PM -0800, Ian Fette (????????) wrote: > > Sorry, just reading the SMIMEA stuff for the first time, so apologies for > > the basic question, but do I really have to publish a record for each > > address? How would I say "this is a trusted intermediate CA for *@gmail.com > > "? > > That would look like so: > > ;; insert CNAMEs for any desired indirection when > ;; the same set of SMIMEA RRs handles multiple domains > ;; > *._smimecert.gmail.com IN SMIMEA 2 0 1 > > Keep in mind that this only supports signature verification, not > encryption, one can't encrypt to an intermediate CA, one needs the > leaf public key for that. So enabling encryption on first contact > requires publishing per-user keys by some means. There's always IBE, or just plain encrypting to the MTA's encryption cert and then let it decrypt and re-encrypt to the local-part's encryption key. > Otherwise all one gets is authenticated key exchange, possibly > followed later by encryption once leaf keys have been exchanged in > both directions. That's not so bad. It's interactive, but so what. Nico -- From nobody Thu Dec 11 20:32:34 2014 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 CA7891A6F9A for ; Thu, 11 Dec 2014 20:32:32 -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_20=-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 SKD44WAr0YlY for ; Thu, 11 Dec 2014 20:32:32 -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 E41451A1A91 for ; Thu, 11 Dec 2014 20:32:31 -0800 (PST) Received: (qmail 25663 invoked from network); 12 Dec 2014 04:32:27 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 12 Dec 2014 04:32:27 -0000 Date: 12 Dec 2014 04:32:08 -0000 Message-ID: <20141212043208.11432.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: http://mailarchive.ietf.org/arch/msg/dane/rk8xraDpKhMKQDYJ3SfvlkAVk38 Subject: Re: [dane] email canonicalization for SMIMEA owner names 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: Fri, 12 Dec 2014 04:32:33 -0000 >> If I say I'm foo@bar.example, and you type Foo@bar.example into your >> MUA to send me e-mail, you might not reach me. >> >> That seems fair. > >Actually, that is really stupid, ... This time I completely agree with Paul. >And someone should write an RFC updating SMTP to not allow >case-sensitivity for different mailboxes so we can stop coming back to >this whenever anyone wants to do anything with email addresses. It's 30 years too late for that. The situation we're in here is fairly peculiar, in that clients other than the recipient MTA are trying to interpret the mailbox name. Previous mail protocol hacks have carefully avoided that. R's, John From nobody Thu Dec 11 20:42:27 2014 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 67E031A7017 for ; Thu, 11 Dec 2014 20:42:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.89 X-Spam-Level: X-Spam-Status: No, score=-0.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 EKWbD-pOZfPI for ; Thu, 11 Dec 2014 20:42:21 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FAF71A1AFB for ; Thu, 11 Dec 2014 20:42:21 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 6E8A51FCAB2 for ; Fri, 12 Dec 2014 04:42:18 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id E2A3416005C for ; Fri, 12 Dec 2014 04:46:51 +0000 (UTC) Received: from rock.dv.isc.org (unknown [149.20.66.86]) by zmx1.isc.org (Postfix) with ESMTPSA id 1751816004E for ; Fri, 12 Dec 2014 04:46:51 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 318552553F6A for ; Fri, 12 Dec 2014 15:42:12 +1100 (EST) Cc: dane@ietf.org From: Mark Andrews References: <20141212043208.11432.qmail@ary.lan> In-reply-to: Your message of "12 Dec 2014 04:32:08 -0000." <20141212043208.11432.qmail@ary.lan> Date: Fri, 12 Dec 2014 15:42:11 +1100 Message-Id: <20141212044212.318552553F6A@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/dane/AtDRLi_q3oBu9wRaRROrDBs88bE Subject: Re: [dane] email canonicalization for SMIMEA owner names 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: Fri, 12 Dec 2014 04:42:24 -0000 The other thing we have to do is to arrange for the CERT to get from the MUA to the keyserver. Extending submission to handle that is a sensible. That way the user can generate their own CERT. They can then submit it to the keyserver using submission/smtp after authenticating themselves. This last step is critical. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Dec 11 21:08:38 2014 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 695911A87EE for ; Thu, 11 Dec 2014 21:08:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 CugRkZNQtlMd for ; Thu, 11 Dec 2014 21:08:33 -0800 (PST) Received: from homiemail-a36.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id C39461A1B42 for ; Thu, 11 Dec 2014 21:08:32 -0800 (PST) Received: from homiemail-a36.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTP id 51E0477805B; Thu, 11 Dec 2014 21:08:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=a696N9rBM/Rn7X 38TV3cxjNec5A=; b=MwCHTrOKf/54qEORMZj1YBLl4WKRv9WfhN3L1TyFwvM2EL dD88eCWKmpRyJidK8O5jTuMQ68f/Cl62caln7Muyqg0laZ8Ur4uQ17Lkgp+ZvMUr KlXp8OqTP01Wh/22yfikgQlrVtuxcjxCgpH9czrl3Mpi+eTeEjee9Nzq9QciQ= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTPA id 04825778056; Thu, 11 Dec 2014 21:08:31 -0800 (PST) Date: Thu, 11 Dec 2014 23:08:31 -0600 From: Nico Williams To: Mark Andrews Message-ID: <20141212050826.GT3448@localhost> References: <20141212043208.11432.qmail@ary.lan> <20141212044212.318552553F6A@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141212044212.318552553F6A@rock.dv.isc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/RRC8PTmndmVzdnEDa9oYk8ka08U Cc: dane@ietf.org Subject: Re: [dane] email canonicalization for SMIMEA owner names 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: Fri, 12 Dec 2014 05:08:34 -0000 On Fri, Dec 12, 2014 at 03:42:11PM +1100, Mark Andrews wrote: > The other thing we have to do is to arrange for the CERT to get > from the MUA to the keyserver. Extending submission to handle that > is a sensible. That way the user can generate their own CERT. They > can then submit it to the keyserver using submission/smtp after > authenticating themselves. This last step is critical. Yes: use MSA/MTA as the keyserver, both for lookup and registration. For verification/key lookup results can be attested to via DNSSEC. A client's MSA could check the peer's MTA on behalf of the MUA. I think this solves all problems, including aliasing, except in the case where the sender doesn't trust its own MSA as to the local-parts of peers. Nico -- From nobody Fri Dec 12 02:24:14 2014 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 AFC581ACC88 for ; Fri, 12 Dec 2014 02:24:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_44=0.6, 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 XmcbwiC7hg3l for ; Fri, 12 Dec 2014 02:24:10 -0800 (PST) Received: from sol.sotecware.net (sol.sotecware.net [IPv6:2a01:4f8:d16:1305::2]) by ietfa.amsl.com (Postfix) with ESMTP id 850C51ACC7F for ; Fri, 12 Dec 2014 02:24:09 -0800 (PST) Received: from [IPv6:2a00:1328:e101:b04::1] (whiterabbit.sotecware.net [IPv6:2a00:1328:e101:b04::1]) by sol.sotecware.net (Postfix) with ESMTPSA id 455481412E2 for ; Fri, 12 Dec 2014 10:24:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wielicki.name; s=k001.sol; t=1418379847; bh=H4OzgQv1+KY0i2w2ZUHdNDPuydG/x1b9yDCJDSjgbms=; h=Date:From:To:Subject:References:In-Reply-To; b=qAtOSaTTIoTuU4ZqqFWPEDyg9X3lrm52/xhKw8uYjtb6Qbyk5Z++4iW+6TFh2QNSX 1tlqR8GpFRn5MH69WOs7Nb0MhjPQMT0cgeuz9CMhmi3iOYuVUbIfQeXKn+clc32IQg wBRcAQ/0ntYFt+lAYL7dwBKfMVJniQ03o6Zzk31VmibUJ3e+y5pKR+oFxuJqkqo62N 3qY0l0vGiM+ualXn6iXCs2L95WuylZK7/uHJuXgzHpYHezG7ihCB+3MdjxE26res+u 2Z1cFppIIlT84PthKvrru6/NQ05rhv2DNyYVNL+5P6XAlVzKLc5eHG9D1+i43p/xwP cDUKH3dP68EEw== Message-ID: <548AC246.8090004@wielicki.name> Date: Fri, 12 Dec 2014 11:24:06 +0100 From: Jonas Wielicki User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: dane@ietf.org References: <5489774C.5090600@wielicki.name> <20141211150539.GA25666@mournblade.imrryr.org> In-Reply-To: <20141211150539.GA25666@mournblade.imrryr.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/aYsflN4MGRfYPnSpggD9AEDR8wY Subject: Re: [dane] Feedback request: python3-dane (A pure-python DANE library for Python 3) 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: Fri, 12 Dec 2014 10:24:12 -0000 Dear Viktor, On 11.12.2014 16:05, Viktor Dukhovni wrote: > On Thu, Dec 11, 2014 at 11:51:56AM +0100, Jonas Wielicki wrote: > >> I recently started working on a python3 library[1] to support >> the implementation of DANE in python3 based applications. I am >> looking for some support in form of a second or third pair of >> eyes. As this is a security sensitive topic, I would be glad if >> someone took the time to look over the approx. 600 lines of >> python code or the user interface documentation. > > Here's my advice. I fully encourage you to experiment with this > code, as a productive learning exercise. However, please *do not* > document this as something other than experimental code that you > used to develop your understanding of the various technologies. > > Unfortunately, in the DANE space, we have too many "toy" libraries > that are wrong or incomplete, and too few that are correct and > comprehensive, and will be maintained in the long term. I understand your concerns and I have added a note to the README and a huge red warning to the autogenerated docs. > A more valuable contribution would be Python code that locates the > right validated TLSA records for a host:port combination that > deals with CNAME expansion and all the requisite DNS error handling > per the OPs draft. For extra points, code that does this > indirectly via SRV or MX records, and produces also the correct set > of "reference identifiers" that go along with the TLSA records for > handling certificate usages 0, 1 and 2. This should also handle > conversion of IDNA hostnames to A-label form for DNS lookups and > certificate reference identifier construction. I agree that this indeed is also a field of problem. However, I currently don’t dare to implement a DNSSEC validating resolver, which would be required for this task (or, again, offload the burden of ensuring such a resolver is present to the user, which is generally error-prone). There is DNSPython, which has some DNSSEC utilities, but as far as I know does not provide validation support. Thank you for giving me the hint to the draft though. I did not know that it existed and it provides valuable insights on the workings of DANE. > * Usages PKIX-TA(0) and PKIX-EE(1) never accept chains that would > fail PKIX validation in the absence of DANE (including name > checks). These only "constrain" which chains that pass PKIX > validation should be accepted. Thank you, that answers my question. > Great care must be exercised here, for example, after PKIX > validation succeeds, a naive request to OpenSSL for the peer's > chain returns the list of wire certificates, not the validated > chain. But I assume that one can obtain the actually validated chain using the verify_callback mechanism provided by OpenSSL? > Additional complications arise due to cross-signing, that make it > difficult to validate a PKIX chain constructed in isolation from > the DANE records. Such a chain might use a trust-anchor "below" > the one that matches the DANE records. I read about that in the draft. I think this is unfortunate, as it really requires to meld the support into the PKIX validating library, something I hoped could be avoided (or, alternatively, validate yourself, as you appearantly did in the postfix DANE code). > * Usage DANE-TA(2) is the most difficult to support, and "toy" > implementations neglect to perform chain construction and integrity > checks or perform name checks, apply name constraints, depth > constraints, handle IDNA conversion of hostnames, ... I wonder whether adding certificates provided by DANE-TA records (assuming we have a Cert+Full record) to the trusted store of the SSL implementation (only for that particular connection) and check whether these have been used after the fact would be sufficient?. thank you for your input, Jonas Wielicki From nobody Fri Dec 12 03:37:19 2014 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 A0DA21ACD08 for ; Fri, 12 Dec 2014 03:37:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.389 X-Spam-Level: X-Spam-Status: No, score=-3.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 jr6d_Zrw_n_2 for ; Fri, 12 Dec 2014 03:37:15 -0800 (PST) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C5D51ACD01 for ; Fri, 12 Dec 2014 03:37:15 -0800 (PST) Received: by mail-qa0-f45.google.com with SMTP id x12so4951487qac.32 for ; Fri, 12 Dec 2014 03:37:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=2n59SeIee0AvnbxrwRpyrD+6XJEQp076r1qoYX+8jPs=; b=oVWfOvWOd11KGNzSLxysohqUwMOOLGnyD9sk2h2ozHh7DnZVpTPc0JncV6mZ83ou8c tsAT05XuGjoxHUgoeC2KhpVXR+dLesuGQHO5vWRQ7tk2C/wq58EmXOaXcgtvdweC9A94 iB5ezFDNxQ6LAIgbd7xYb1lA9zSGcDuwS6kl4Z0PfW+jAE7hDlITkEfhKPptabSe7peR ipf5T8XEaVgClubWN/trfU+madKdyj0zFzrSjYwyj4jSabxzNTVe2QHFVKeLO+28Kz8F 350QG1jc89jStgMk4Os6EQNcWcjVb/VipEzv9/et/pkUcia1vVqQXT1frWh04oOdQ8gZ VGEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=2n59SeIee0AvnbxrwRpyrD+6XJEQp076r1qoYX+8jPs=; b=EaP8ntwNGAXOAfzXXZ5neuq40Gfx1ciuijOvMbzIGtfMQ9Yarhb7qPE/Vwz+C2p36c HxJZ/42NMdForrZMJdLBUYewbTBIOjYi2U0jFU3XjoQteqEhpOftp111/+iyxnPjtXuu QnARJRSG3TMBPA8SvFlxJkOZNCnwHyBdstsp9iDA0WGQMfO2avWeoOayfB5EFcU+Aoma vY0lCb8WZNajLc/VlngGLV2DMiL8Bj/RZ0jrilxOZTz7DL1OXX77cVyAxeBRctqa2o2N Mdxnj3vOtIUj3sEiKkA2+ewmaKtOIimGAnO9LPOrxOkXuuWS9G0eUafRu9aHGbJaqH46 gd6Q== X-Gm-Message-State: ALoCoQmDEkdeVfycubXMyEV7G+DZjeOVpNZ61u7w6qhbao8y89s77mG9SypLa1Aei9yUwaKJDDAy MIME-Version: 1.0 X-Received: by 10.140.105.7 with SMTP id b7mr16495711qgf.8.1418384234478; Fri, 12 Dec 2014 03:37:14 -0800 (PST) Received: by 10.229.183.201 with HTTP; Fri, 12 Dec 2014 03:37:14 -0800 (PST) In-Reply-To: <95826148-4F06-4942-87A4-2F6601BA0F90@nist.gov> References: <95826148-4F06-4942-87A4-2F6601BA0F90@nist.gov> Date: Fri, 12 Dec 2014 11:37:14 +0000 Message-ID: From: Ben Laurie To: "Rose, Scott W." Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dane/YbsgBa7_STHUqM3i0Sn16QXctx0 Cc: dane WG list Subject: Re: [dane] email canonicalization for SMIMEA owner names 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: Fri, 12 Dec 2014 11:37:18 -0000 On 11 December 2014 at 19:51, Rose, Scott W. wrote: > Realized the other action item I was assigned to from the interim meeting= was email canonicalization for SMIMEA. I believe it stems from Viktor Duk= hovni's email to the endymail list: > http://www.ietf.org/mail-archive/web/endymail/current/msg00134.html > > I was wondering if we can borrow a page from RFC 4034 Section 6.2 and inc= lude text in the draft Section 3, item 1 in the numbered list: > > 1. The user name (the "left-hand side" of the email address, calle= d > the "local-part" in the mail message format definition [RFC2822] > and the "local part" in the specification for internationalized > email [RFC6530]), is hashed using the SHA2-224 [RFC5754] > algorithm (with the hash being represented in its hexadecimal > representation, to become the left-most label in the prepared > domain name. This does not include the "@" character that > separates the left and right sides of the email address. The > string that is used for the local part is a Unicode string > encoded in UTF-8 **with all upper case letters converted to their > corresponding lower case letters where appropriate.** > > > The text between the '**' is new. The goal is to prevent a situation whe= n the email address is "JRandom@example.com" and the SMIMEA is created usin= g "jrandom" as the user name. Would this be enough, or are there scripts = where this would result in different or potentially conflicting owner names= ? Speaking of canonicalisation: 1. What about X+Y@Z - for almost all MTAs, this is the same as X@Z. 2. What about GMail's a.b.c@gmail.com =3D=3D abc@gmail.com =3D=3D ab.c@gmail.com =3D=3D a.bc@gmail.com? From nobody Fri Dec 12 07:33:59 2014 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 0128B1A902F for ; Fri, 12 Dec 2014 07:33:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 nQ9detF7jCUX for ; Fri, 12 Dec 2014 07:33:56 -0800 (PST) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) (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 C3A921A9031 for ; Fri, 12 Dec 2014 07:33:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:content-type:mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=Lkt0L9utkPxf/MNIaV/aeS7mPbThttASimYpLrQiVW4=; b=PqvOnhnCQN0ES6KRM27tSE/hRXyeG7DQfVeJEQMMuut12BfO7DhXO85p+bTZWmZ7aHVbfTffl67gm OyATLFFZnnplY1XwhjU6KbJvfhoU0I+q6/lxG6JyAKHF+k3lCBs3qIyY7lEjzLDx9SEEw7r3G1sTX2 YBW4rtDRaHqX0fvQ= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Fri, 12 Dec 2014 16:33:35 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Jakob Schlyter In-Reply-To: Date: Fri, 12 Dec 2014 16:33:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <95826148-4F06-4942-87A4-2F6601BA0F90@nist.gov> <20141211221456.GI3448@localhost> To: Paul Wouters X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/jZ9Msx2JmznDY2uqz2NFt4jZLg8 Cc: dane WG list Subject: Re: [dane] email canonicalization for SMIMEA owner names 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: Fri, 12 Dec 2014 15:33:58 -0000 On 12 dec 2014, at 03:11, Paul Wouters wrote: > A client can lookup the given name, if NXDOMAIN and not all lowercase, > lowercase it and try again. IMHO, this is a very reasonable approach that does not require any = magic. It is also the reasonable thing to do for a client that actually = want to find something. jakob From nobody Fri Dec 12 07:38:26 2014 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 56D281ACE07 for ; Fri, 12 Dec 2014 07:38:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.01 X-Spam-Level: X-Spam-Status: No, score=-4.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, T_RP_MATCHES_RCVD=-0.01] 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 ogHIOrjvOSYY for ; Fri, 12 Dec 2014 07:38:14 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF6771A6FF3 for ; Fri, 12 Dec 2014 07:38:14 -0800 (PST) Received: from [193.110.157.237] (unknown [76.10.157.65]) by bofh.nohats.ca (Postfix) with ESMTPSA id B3F4380046; Fri, 12 Dec 2014 10:38:12 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1418398693; bh=kaToMnawTjhfOtbibYlHaPp/U7U+bwAFutdpAsKOZ0k=; h=References:In-Reply-To:Cc:From:Subject:Date:To; b=A+GvDJF1mVMZoZiIdyRdQuFRV1wXUjalNrqKm2mi5ZblpuQRecjqkZlou0gW6bXxY 40BlcXjAU19MT0XY6Cqfp/6lrLEZXTsHitXcJqhQEaajUJ1/2mr/JAsMtJCthXDPjM SREs4XZBw/afqVyT83y4GLC55M6hXD7VmKj/KZgM= References: <95826148-4F06-4942-87A4-2F6601BA0F90@nist.gov> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (12B411) From: Paul Wouters Date: Fri, 12 Dec 2014 10:38:13 -0500 To: Ben Laurie Archived-At: http://mailarchive.ietf.org/arch/msg/dane/9xTBCEruFfJwZpFOvbhuhHBOpNE Cc: dane WG list Subject: Re: [dane] email canonicalization for SMIMEA owner names 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: Fri, 12 Dec 2014 15:38:23 -0000 Whoever starts using variant email addresses should publish records for it? A= s John said, clients shouldn't start guessing addressing schemes used by oth= ers Sent from my iPhone > On Dec 12, 2014, at 06:37, Ben Laurie wrote: >=20 >> On 11 December 2014 at 19:51, Rose, Scott W. wrote:= >> Realized the other action item I was assigned to from the interim meeting= was email canonicalization for SMIMEA. I believe it stems from Viktor Dukh= ovni's email to the endymail list: >> http://www.ietf.org/mail-archive/web/endymail/current/msg00134.html >>=20 >> I was wondering if we can borrow a page from RFC 4034 Section 6.2 and inc= lude text in the draft Section 3, item 1 in the numbered list: >>=20 >> 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]), is hashed using the SHA2-224 [RFC5754] >> algorithm (with the hash being represented in its hexadecimal >> representation, to become the left-most label in the prepared >> domain name. This does not include the "@" character that >> separates the left and right sides of the email address. The >> string that is used for the local part is a Unicode string >> encoded in UTF-8 **with all upper case letters converted to their >> corresponding lower case letters where appropriate.** >>=20 >>=20 >> The text between the '**' is new. The goal is to prevent a situation whe= n the email address is "JRandom@example.com" and the SMIMEA is created using= "jrandom" as the user name. Would this be enough, or are there scripts wh= ere this would result in different or potentially conflicting owner names? >=20 > Speaking of canonicalisation: >=20 > 1. What about X+Y@Z - for almost all MTAs, this is the same as X@Z. >=20 > 2. What about GMail's a.b.c@gmail.com =3D=3D abc@gmail.com =3D=3D > ab.c@gmail.com =3D=3D a.bc@gmail.com? >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From nobody Fri Dec 12 07:56:57 2014 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 6BFC51ACCED for ; Fri, 12 Dec 2014 07:56:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.01 X-Spam-Level: X-Spam-Status: No, score=-4.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, T_RP_MATCHES_RCVD=-0.01] 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 69SR656Yq70e for ; Fri, 12 Dec 2014 07:56:37 -0800 (PST) Received: from statler.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6731ACE7B for ; Fri, 12 Dec 2014 07:56:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1418399781; d=isode.com; s=selector; i=@isode.com; bh=kw7JW/JM0A9RrNVKiAjiE99LDp8pL5Q2oS6j4dOvSVk=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=J2QkaJrJwJvLUudsEdEVr7HKzNBAyNzmqrDZ/Vg/NpEvHod9JqcxbHIpEUQku9FZtDml3r 856mvkyfok9clqYkdvRcAFkVVF8qSxLUyjDPHd8jRV/OTyrox6PRdAeA2cVqIII57gZyWL lVG6SevRBuKFZdvs/utoyBc2PzYMufg=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 12 Dec 2014 15:56:21 +0000 Message-ID: <548B1013.4090000@isode.com> Date: Fri, 12 Dec 2014 15:56:03 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 To: Paul Wouters , Ben Laurie References: <95826148-4F06-4942-87A4-2F6601BA0F90@nist.gov> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/V5JAdBuckPXHFgB0vo2eRdtQ_kY Cc: dane WG list Subject: Re: [dane] email canonicalization for SMIMEA owner names 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: Fri, 12 Dec 2014 15:56:40 -0000 On 12/12/2014 15:38, Paul Wouters wrote: > Whoever starts using variant email addresses should publish records for it? As John said, clients shouldn't start guessing addressing schemes used by others +1. Nobody other than the final MTA/MDA knows that certain forms are equivalent. > Sent from my iPhone > >> On Dec 12, 2014, at 06:37, Ben Laurie wrote: >> >>> On 11 December 2014 at 19:51, Rose, Scott W. wrote: >>> Realized the other action item I was assigned to from the interim meeting was email canonicalization for SMIMEA. I believe it stems from Viktor Dukhovni's email to the endymail list: >>> http://www.ietf.org/mail-archive/web/endymail/current/msg00134.html >>> >>> I was wondering if we can borrow a page from RFC 4034 Section 6.2 and include text in the draft Section 3, item 1 in the numbered list: >>> >>> 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]), is hashed using the SHA2-224 [RFC5754] >>> algorithm (with the hash being represented in its hexadecimal >>> representation, to become the left-most label in the prepared >>> domain name. This does not include the "@" character that >>> separates the left and right sides of the email address. The >>> string that is used for the local part is a Unicode string >>> encoded in UTF-8 **with all upper case letters converted to their >>> corresponding lower case letters where appropriate.** >>> >>> >>> The text between the '**' is new. The goal is to prevent a situation when the email address is "JRandom@example.com" and the SMIMEA is created using "jrandom" as the user name. Would this be enough, or are there scripts where this would result in different or potentially conflicting owner names? >> Speaking of canonicalisation: >> >> 1. What about X+Y@Z - for almost all MTAs, this is the same as X@Z. >> >> 2. What about GMail's a.b.c@gmail.com == abc@gmail.com == >> ab.c@gmail.com == a.bc@gmail.com? From nobody Fri Dec 12 07:58:16 2014 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 43BA41ACE5C for ; Fri, 12 Dec 2014 07:58:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.01 X-Spam-Level: X-Spam-Status: No, score=-4.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, T_RP_MATCHES_RCVD=-0.01] 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 cviCxfpoidnI for ; Fri, 12 Dec 2014 07:58:12 -0800 (PST) Received: from statler.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE7A1ACE54 for ; Fri, 12 Dec 2014 07:58:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1418399876; d=isode.com; s=selector; i=@isode.com; bh=C0rVuX+ZRLrE6leQMGrYOoZupzNOy1ZENtq2Zc/El18=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=n/9LyMC3ODnBJSGFroazmTCiJFbOXDpeFqPrmL4tiFYfc2Nwe9g4SGzBu6kXl4pwSDD3MC A01ae2TaOBA74G/aasLZy3mc1cza+v3FcXqyWQrNO0Lzx19xLe2fRxHcX0jvvBsCeBbvG8 vHMbOAGhrcld1yOF0r5OLpN4n8SQB88=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 12 Dec 2014 15:57:56 +0000 Message-ID: <548B1072.1090206@isode.com> Date: Fri, 12 Dec 2014 15:57:38 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 To: Ben Laurie , "Rose, Scott W." References: <95826148-4F06-4942-87A4-2F6601BA0F90@nist.gov> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/AUR2qXHVfUoJt0ARqNYp-YFmmWY Cc: dane WG list Subject: Re: [dane] email canonicalization for SMIMEA owner names 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: Fri, 12 Dec 2014 15:58:15 -0000 On 12/12/2014 11:37, Ben Laurie wrote: > On 11 December 2014 at 19:51, Rose, Scott W. wrote: >> Realized the other action item I was assigned to from the interim meeting was email canonicalization for SMIMEA. I believe it stems from Viktor Dukhovni's email to the endymail list: >> http://www.ietf.org/mail-archive/web/endymail/current/msg00134.html >> >> I was wondering if we can borrow a page from RFC 4034 Section 6.2 and include text in the draft Section 3, item 1 in the numbered list: >> >> 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]), is hashed using the SHA2-224 [RFC5754] >> algorithm (with the hash being represented in its hexadecimal >> representation, to become the left-most label in the prepared >> domain name. This does not include the "@" character that >> separates the left and right sides of the email address. The >> string that is used for the local part is a Unicode string >> encoded in UTF-8 **with all upper case letters converted to their >> corresponding lower case letters where appropriate.** >> >> >> The text between the '**' is new. The goal is to prevent a situation when the email address is "JRandom@example.com" and the SMIMEA is created using "jrandom" as the user name. Would this be enough, or are there scripts where this would result in different or potentially conflicting owner names? > Speaking of canonicalisation: > > 1. What about X+Y@Z - for almost all MTAs, this is the same as X@Z. This is a bit misleading: MSA or intermediate MTAs can't know that these are the same (unless MSA is also the final MTA). > 2. What about GMail's a.b.c@gmail.com == abc@gmail.com == > ab.c@gmail.com == a.bc@gmail.com? As above. From nobody Fri Dec 12 08:13:25 2014 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 1FEB21ACE7D for ; Fri, 12 Dec 2014 08:13:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] 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 wJIueQ_PvFj9 for ; Fri, 12 Dec 2014 08:13:14 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 478431ACE77 for ; Fri, 12 Dec 2014 08:13:14 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 78CBA80046; Fri, 12 Dec 2014 11:13:13 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1418400793; bh=8iPAHduCEkxCe72nY3zFxcjgU5B5k0GZGzPSS7UveKM=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=FivDs/+Q+RB8TwIfRBpSYkyh9kt7bZ1qQnGpSfi7NaSzuw0Hkbauz0FOab6rWJ5XL e+0pVRVcNpfBh7WnP+gV1ikfjCR/1OJVXNalbFqBbZOaJLiHUZZvjzTivc8/AYUyaJ NKUP2nESnII+cd+oORNmuHglmQ5VnSg8hVMBLP8w= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id sBCGDCM6003931; Fri, 12 Dec 2014 11:13:13 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Fri, 12 Dec 2014 11:12:56 -0500 (EST) From: Paul Wouters To: Nico Williams In-Reply-To: <20141212050826.GT3448@localhost> Message-ID: References: <20141212043208.11432.qmail@ary.lan> <20141212044212.318552553F6A@rock.dv.isc.org> <20141212050826.GT3448@localhost> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dane/svhDkGpbdMmJ8SPui5bVOLzNcMs Cc: dane WG list Subject: Re: [dane] email canonicalization for SMIMEA owner names 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: Fri, 12 Dec 2014 16:13:20 -0000 On Thu, 11 Dec 2014, Nico Williams wrote: > Yes: use MSA/MTA as the keyserver, both for lookup and registration. Why add another service, another dependancy and another choke point and another trans protocol for auditing that the world sees the same view? That can all be done with DNS. Adding another service just adds more problems. Paul From nobody Fri Dec 12 08:21:13 2014 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 D6D821A1B56 for ; Fri, 12 Dec 2014 08:21:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 fNMrreG0aOKq for ; Fri, 12 Dec 2014 08:21:11 -0800 (PST) Received: from homiemail-a63.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC061A1AF4 for ; Fri, 12 Dec 2014 08:21:11 -0800 (PST) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id E2AEA2F406A; Fri, 12 Dec 2014 08:21:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=XvkRsubvPorV4A Re3Qm9UdvEXmQ=; b=s8OsgnkHYzmHUUmDrCpmVwjVecs4XySweltCM6mxQiS7dI /L/ZL1YVwwcQm+8JS0XDkJQ0TdPDVI7sOqJFADXCsxPmcvSX7MJYZBanpGy19Xk5 PiorIu7qs2kMKwC1KNuJV//SZWLFNKtOlzWNBPOVGn/ib8mNrKyG/R6LGSjao= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPA id 8CBE72F4057; Fri, 12 Dec 2014 08:21:10 -0800 (PST) Date: Fri, 12 Dec 2014 10:21:09 -0600 From: Nico Williams To: Paul Wouters Message-ID: <20141212162104.GU3448@localhost> References: <20141212043208.11432.qmail@ary.lan> <20141212044212.318552553F6A@rock.dv.isc.org> <20141212050826.GT3448@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/TN7Cn4_gAb7Xw5SsQbwSt12bbPg Cc: dane WG list Subject: Re: [dane] email canonicalization for SMIMEA owner names 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: Fri, 12 Dec 2014 16:21:12 -0000 On Fri, Dec 12, 2014 at 11:12:56AM -0500, Paul Wouters wrote: > On Thu, 11 Dec 2014, Nico Williams wrote: > >Yes: use MSA/MTA as the keyserver, both for lookup and registration. > > Why add another service, another dependancy and another choke point and > another trans protocol for auditing that the world sees the same view? Well, it's another service on a protocol that already exists, that the MUA must speak, and has similar functionality (VRFY) anyways. > That can all be done with DNS. If done *only* with DNS then we get into the canonicalization/zone walking (spam) trap and we then have to do something that sucks. > Adding another service just adds more problems. So does not adding it. It's a case of pick your poison. I can't say I like one poison better than the other yet... BTW, for the DNS-only scheme, there's no need for local-part canon when verifying sender certs: because hopefully! the sender's MUA will use a canonical sender local-part. As for looking up a recipient's encryption cert... well, if the MUA gets the wrong recipient local-part form as a result of applying an incorrect canonicalization, then it could get the wrong recipient -- a relatively minor problem, but one worth noting. The SMIMEA I-D does need to describe the motions that the MUA goes through to do the two different tasks: verifying sender signature certs, and finding recipient encryption certs. Nico -- From nobody Fri Dec 12 08:28:41 2014 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 554F91A6F38 for ; Fri, 12 Dec 2014 08:28:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.389 X-Spam-Level: X-Spam-Status: No, score=-3.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 RDG-QBCpH9rW for ; Fri, 12 Dec 2014 08:28:35 -0800 (PST) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7530E1A1BD6 for ; Fri, 12 Dec 2014 08:28:35 -0800 (PST) Received: by mail-qc0-f181.google.com with SMTP id m20so5717786qcx.40 for ; Fri, 12 Dec 2014 08:28:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2IVh3YnQiDz+1FW9o1IiDxZHb0lzHHB+N+EOxbsLRVA=; b=P5cqtDsQKkE6O1VycQhgzYrdzKg/QGurUYEcfObhzF2cMj3fa7o0nNebWQkulMw3R6 w+S0QM0wtu98T3dfEtFT6Lb9mkGmwDwiUBRN+SssUn7IEQLQ4uARmWnyRu8g8pEqI0BB cdkJlncsCltjduDYIKWy9DYuHXoBk1wWoZpkf0kRKCsIhUVO4DeIMnfbESaZ6HWUda/L v4bVnYuT5IdDrnCEeZlGWGAIpqQ/6UNthX4s6/L6CfYVWGBSELOpbh+rJ2jXTV9Rf24L eBHo2O0h1JUKttuPE5+89kl+96egqtz7pli2I0QW/xWBtxvvWhRD9SBwZ4Z95wZU4xAK 7Vyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=2IVh3YnQiDz+1FW9o1IiDxZHb0lzHHB+N+EOxbsLRVA=; b=cq60yZ3icKpkxpSKmyGRp/4dM8IdnqAFoyj+mDP0cSsc9GbGpdK02V1A/86j1C6hbt RunXc8nhdKdKvFK3POKmZzNTdoVyNow6uuk3OAllOFcPhNMf4Xbw+NOHhi1EoE8tOrbo oGs13GV8GgG/5xP+GREFIuhRCW+s6un5G3FGAqIiq7lxkCSxJ0NY22jhuxHWzbav2Ol8 FYVJN/fqQBNiKDIlIDpN4ZNmHcmyipL3ZoGAC4U9iuyYYwLG3llIFaJa4icEwG1KaQFm xjRjOZhWZNuLr7n7AwQLY34fKJVNKHTn4vkzlsNy4OhRRPjMKFtHWcQcxiD48Xru8b8x OhIQ== X-Gm-Message-State: ALoCoQl5705VverZ2zJhRTtQhCLjNEPK8xPH41kIzCJ7Qug+btnrNtIMgPjfv5X0g1bLYdtsr1mT MIME-Version: 1.0 X-Received: by 10.224.136.194 with SMTP id s2mr32838489qat.82.1418401714528; Fri, 12 Dec 2014 08:28:34 -0800 (PST) Received: by 10.229.183.201 with HTTP; Fri, 12 Dec 2014 08:28:34 -0800 (PST) In-Reply-To: <548B1013.4090000@isode.com> References: <95826148-4F06-4942-87A4-2F6601BA0F90@nist.gov> <548B1013.4090000@isode.com> Date: Fri, 12 Dec 2014 16:28:34 +0000 Message-ID: From: Ben Laurie To: Alexey Melnikov Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/zG-6D_Ak9EDD0kP3JSQpwbaMbEA Cc: Paul Wouters , dane WG list Subject: Re: [dane] email canonicalization for SMIMEA owner names 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: Fri, 12 Dec 2014 16:28:37 -0000 On 12 December 2014 at 15:56, Alexey Melnikov wrote: > On 12/12/2014 15:38, Paul Wouters wrote: >> >> Whoever starts using variant email addresses should publish records for >> it? As John said, clients shouldn't start guessing addressing schemes used >> by others > > +1. Nobody other than the final MTA/MDA knows that certain forms are > equivalent. True, but does not make your scheme workable. > >> Sent from my iPhone >> >>> On Dec 12, 2014, at 06:37, Ben Laurie wrote: >>> >>>> On 11 December 2014 at 19:51, Rose, Scott W. >>>> wrote: >>>> Realized the other action item I was assigned to from the interim >>>> meeting was email canonicalization for SMIMEA. I believe it stems from >>>> Viktor Dukhovni's email to the endymail list: >>>> http://www.ietf.org/mail-archive/web/endymail/current/msg00134.html >>>> >>>> I was wondering if we can borrow a page from RFC 4034 Section 6.2 and >>>> include text in the draft Section 3, item 1 in the numbered list: >>>> >>>> 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]), is hashed using the SHA2-224 [RFC5754] >>>> algorithm (with the hash being represented in its hexadecimal >>>> representation, to become the left-most label in the prepared >>>> domain name. This does not include the "@" character that >>>> separates the left and right sides of the email address. The >>>> string that is used for the local part is a Unicode string >>>> encoded in UTF-8 **with all upper case letters converted to their >>>> corresponding lower case letters where appropriate.** >>>> >>>> >>>> The text between the '**' is new. The goal is to prevent a situation >>>> when the email address is "JRandom@example.com" and the SMIMEA is created >>>> using "jrandom" as the user name. Would this be enough, or are there >>>> scripts where this would result in different or potentially conflicting >>>> owner names? >>> >>> Speaking of canonicalisation: >>> >>> 1. What about X+Y@Z - for almost all MTAs, this is the same as X@Z. >>> >>> 2. What about GMail's a.b.c@gmail.com == abc@gmail.com == >>> ab.c@gmail.com == a.bc@gmail.com? > > From nobody Fri Dec 12 09:01:44 2014 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 63C4D1A6FB8 for ; Fri, 12 Dec 2014 09:01:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.01 X-Spam-Level: X-Spam-Status: No, score=-4.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, T_RP_MATCHES_RCVD=-0.01] 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 CNCHyFR3aeHB for ; Fri, 12 Dec 2014 09:01:40 -0800 (PST) Received: from waldorf.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id B9B271A6F96 for ; Fri, 12 Dec 2014 09:01:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1418403699; d=isode.com; s=selector; i=@isode.com; bh=4NQY7Xwu2WXaCr4XQntqDQnHZd8pmOzLuDbVl26oxHY=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=SbvLOcapLpGHaUJ4Qpu8f2JrLbmR0On4BrPx+6oFgEjhb6UImQ5KYORux0rJOrBVJg1NSm Aw+BqijbOAO5s5LJojvby2jZwYu2iMwDKxwc8GzAJw/DYjikJ8FIe+G8jg+hSmnWkKhRK2 ywcqslGhh2ryN1ADeZsQ7hn4iGNJei0=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 12 Dec 2014 17:01:39 +0000 Message-ID: <548B1F62.5090002@isode.com> Date: Fri, 12 Dec 2014 17:01:22 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 To: Ben Laurie References: <95826148-4F06-4942-87A4-2F6601BA0F90@nist.gov> <548B1013.4090000@isode.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/ZNyp0_U6gfImLHAWFIoUV6pQrro Cc: Paul Wouters , dane WG list Subject: Re: [dane] email canonicalization for SMIMEA owner names 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: Fri, 12 Dec 2014 17:01:42 -0000 On 12/12/2014 16:28, Ben Laurie wrote: > On 12 December 2014 at 15:56, Alexey Melnikov wrote: >> On 12/12/2014 15:38, Paul Wouters wrote: >>> Whoever starts using variant email addresses should publish records for >>> it? As John said, clients shouldn't start guessing addressing schemes used >>> by others >> +1. Nobody other than the final MTA/MDA knows that certain forms are >> equivalent. > True, but does not make your scheme workable. Only publish canonical form or variants that were used for sending emails out? >>> Sent from my iPhone >>> >>>> On Dec 12, 2014, at 06:37, Ben Laurie wrote: >>>> >>>>> On 11 December 2014 at 19:51, Rose, Scott W. >>>>> wrote: >>>>> Realized the other action item I was assigned to from the interim >>>>> meeting was email canonicalization for SMIMEA. I believe it stems from >>>>> Viktor Dukhovni's email to the endymail list: >>>>> http://www.ietf.org/mail-archive/web/endymail/current/msg00134.html >>>>> >>>>> I was wondering if we can borrow a page from RFC 4034 Section 6.2 and >>>>> include text in the draft Section 3, item 1 in the numbered list: >>>>> >>>>> 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]), is hashed using the SHA2-224 [RFC5754] >>>>> algorithm (with the hash being represented in its hexadecimal >>>>> representation, to become the left-most label in the prepared >>>>> domain name. This does not include the "@" character that >>>>> separates the left and right sides of the email address. The >>>>> string that is used for the local part is a Unicode string >>>>> encoded in UTF-8 **with all upper case letters converted to their >>>>> corresponding lower case letters where appropriate.** >>>>> >>>>> >>>>> The text between the '**' is new. The goal is to prevent a situation >>>>> when the email address is "JRandom@example.com" and the SMIMEA is created >>>>> using "jrandom" as the user name. Would this be enough, or are there >>>>> scripts where this would result in different or potentially conflicting >>>>> owner names? >>>> Speaking of canonicalisation: >>>> >>>> 1. What about X+Y@Z - for almost all MTAs, this is the same as X@Z. >>>> >>>> 2. What about GMail's a.b.c@gmail.com == abc@gmail.com == >>>> ab.c@gmail.com == a.bc@gmail.com? >> From nobody Fri Dec 12 09:53:15 2014 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 674571ACE61 for ; Fri, 12 Dec 2014 09:53:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 SDuael3ekxO3 for ; Fri, 12 Dec 2014 09:53:11 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AD3B1ACEAB for ; Fri, 12 Dec 2014 09:52:43 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 7C2BC282FBF; Fri, 12 Dec 2014 17:52:42 +0000 (UTC) Date: Fri, 12 Dec 2014 17:52:42 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141212175242.GB25666@mournblade.imrryr.org> References: <95826148-4F06-4942-87A4-2F6601BA0F90@nist.gov> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/CTe3t3AWPMEmkdDsI8q-oXdLir4 Subject: Re: [dane] email canonicalization for SMIMEA owner names X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 17:53:13 -0000 On Fri, Dec 12, 2014 at 10:38:13AM -0500, Paul Wouters wrote: [ NOTE: I am not advocating abandoning SMIMEA, just thinking out loud about what an alternative might look like, since some folks seem to want to discuss alternatives. ] > Whoever starts using variant email addresses should publish > records for it? As John said, clients shouldn't start guessing > addressing schemes used by others With address extensions, There may not be such a list to publish, all extensions are valid. In @example.com The part is any string that is not too long to fit into SMTP commands and email headers. If queries are sent to an HTTPS service that is deployed with the (ultimate) inbound MTA for "example.com", then X.509 key lookup is rather similar to what the MTA already does to validate the inbound recipient so as not to be a backscatter source. The HTTPS service would be operated as part of the organization's boundary MTA (thus with MessageLabs, Postini, ... in proxy rather than hosting mode, not as part of those services, but as part of the real border system accepting mail from those). The presence of the associated SRV records would signal adoption of the protocol. Domains that employ filtering services such as MessageLabs, Postini, ... might publish only signing keys if they wish for all email to be scanned and don't want end-to-end encryption, or might allow end-to-end encryption via user to user requests (you can only get my encryption key if I reply, the protocol only yields signature verification data). The main thing this would have to recommend itself is there is no encoding of the localpart into DNS labels, the HTTPS service can support queries with the full EAI address as-is, and can easily grok the address extensions, etc., because the MTA already knows how to do that. DANE would be used to authenticate that service, and the data coming back from the service would still be RFC 6698 style (usage,selector,mtype,data) associations. This would just be a variant oracle that avoids encoding email addresses in DNS. The oracle can query LDAP, ... can make up fake replies for non-existent addresses to thwart directory harvesting attacks if desired, ... HTTPS, allows the service to be reached from inside corporate environments that block most other outbound services (possibly including external DNS). In some environments even HTTPS is subject to corporate MiTM (that the users are aware of with the HTTP proxy signing certs trusted by browsers, ...). In such environments users don't get end-to-end email encryption, just like they don't get end-to-end HTTPS. Their border email gateway might be able to play gateway-to-gateway SMIME with the destination. -- Viktor. From nobody Fri Dec 12 10:06:29 2014 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 CA62E1A1B96 for ; Fri, 12 Dec 2014 10:06:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.037 X-Spam-Level: X-Spam-Status: No, score=-1.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 biJOUNRXbjcl for ; Fri, 12 Dec 2014 10:06:24 -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 DBE831A6FCD for ; Fri, 12 Dec 2014 10:06:14 -0800 (PST) Received: (qmail 25797 invoked from network); 12 Dec 2014 18:06:09 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 12 Dec 2014 18:06:09 -0000 Date: 12 Dec 2014 18:05:51 -0000 Message-ID: <20141212180551.13185.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: http://mailarchive.ietf.org/arch/msg/dane/F4Y5VaIjS1Ih-ayn_0HHsVhr5hs Subject: Re: [dane] email canonicalization for SMIMEA owner names 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: Fri, 12 Dec 2014 18:06:26 -0000 >Speaking of canonicalisation: > >1. What about X+Y@Z - for almost all MTAs, this is the same as X@Z. Only if by almost all you mean sendmail and postfix. Subaddresses are popular here in nerd land but they're almost unknown elsewhere. Yahoo has an obscure subaddress feature which nobody uses. >2. What about GMail's a.b.c@gmail.com == abc@gmail.com == >ab.c@gmail.com == a.bc@gmail.com? That's a better question. Having written a few books aimed at non-technical users and gotten a certain number of comments, it's clear that everyone expects upper and lower mailbox names to be equivalent, but have no general expectations about dots, + - and the like. The point about UTF-8 characters is a good one, but until there's a lot more experience with EAI, I don't see how we can say anything about a similar canonicalization. R's, John From nobody Fri Dec 12 10:14:16 2014 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 1D2791A873A for ; Fri, 12 Dec 2014 10:14:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_44=0.6] 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 ddpx7yYzymLB for ; Fri, 12 Dec 2014 10:14:13 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E11471A7113 for ; Fri, 12 Dec 2014 10:14:12 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 1F4B8282FBF; Fri, 12 Dec 2014 18:14:12 +0000 (UTC) Date: Fri, 12 Dec 2014 18:14:12 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141212181411.GE25666@mournblade.imrryr.org> References: <5489774C.5090600@wielicki.name> <20141211150539.GA25666@mournblade.imrryr.org> <548AC246.8090004@wielicki.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <548AC246.8090004@wielicki.name> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/vymsiBdK97ki5gELP__5s3XWZqI Subject: Re: [dane] Feedback request: python3-dane (A pure-python DANE library for Python 3) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 18:14:14 -0000 On Fri, Dec 12, 2014 at 11:24:06AM +0100, Jonas Wielicki wrote: > > Great care must be exercised here, for example, after PKIX > > validation succeeds, a naive request to OpenSSL for the peer's > > chain returns the list of wire certificates, not the validated > > chain. > > But I assume that one can obtain the actually validated chain using > the verify_callback mechanism provided by OpenSSL? Yes with usage 0/1, with usage 2 the traditional chain building code cannot be used as-is. > > * Usage DANE-TA(2) is the most difficult to support, and "toy" > > implementations neglect to perform chain construction and integrity > > checks or perform name checks, apply name constraints, depth > > constraints, handle IDNA conversion of hostnames, ... > > I wonder whether adding certificates provided by DANE-TA records > (assuming we have a Cert+Full record) to the trusted store of the SSL > implementation (only for that particular connection) and check whether > these have been used after the fact would be sufficient?. It is not "sufficient", as these are not necessarily self-signed, and OpenSSL (before 1.0.2) does not have a way to validate chains that start with trust-anchor that is not self-signed. Postfix can also verify chains via a "2 1 0 " TLSA record, even when the chain does not include the associated certificate! -- Viktor. From nobody Fri Dec 12 10:39:00 2014 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 EABF81A1B9B for ; Fri, 12 Dec 2014 10:38:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 YLT319mPIur4 for ; Fri, 12 Dec 2014 10:38:55 -0800 (PST) Received: from homiemail-a86.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 85E071A1EFC for ; Fri, 12 Dec 2014 10:38:44 -0800 (PST) Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id 401EA360072 for ; Fri, 12 Dec 2014 10:38:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:references:mime-version:content-type :in-reply-to; s=cryptonector.com; bh=mBwt8E8p51z3j6hJSHIHro+2J+I =; b=IaPfXIHYim4kW/5x5YaBhYyRA3LohYXkpjbDje8whOVjWugEKs3BlqVMuak 3B8LQYiK1VTzvZ+SnyKKvtpzjIeSQYj3Q+2ZYgE+9eNhikIhxjAfxGHoEiY68Jy8 CHaN9KTveuS4QIjnBhJNfJ4ZuOHdPFg9SAukqk14sGnJNVjw= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTPA id F306936006D for ; Fri, 12 Dec 2014 10:38:43 -0800 (PST) Date: Fri, 12 Dec 2014 12:38:28 -0600 From: Nico Williams To: dane@ietf.org Message-ID: <20141212183823.GV3448@localhost> References: <95826148-4F06-4942-87A4-2F6601BA0F90@nist.gov> <20141212175242.GB25666@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141212175242.GB25666@mournblade.imrryr.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/pwudTfefaG7-fFYgV6OINddvMPs Subject: Re: [dane] email canonicalization for SMIMEA owner names 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: Fri, 12 Dec 2014 18:38:56 -0000 On Fri, Dec 12, 2014 at 05:52:42PM +0000, Viktor Dukhovni wrote: > If queries are sent to an HTTPS service that is deployed with the > (ultimate) inbound MTA for "example.com", then X.509 key lookup is > rather similar to what the MTA already does to validate the inbound > recipient so as not to be a backscatter source. Yes. It has to be HTTPS because that will go through firewalls. Whereas my chaining through MSAs/MTAs idea is too burdensome on the MSAs/MTAs. For verification of sender signing certs this need not reveal anything about valid local-parts. For recipient encryption cert lookups... avoiding an oracle for local-part validity is harder because the service would have to serve a valid encryption cert (SMIMEA RRs, really) for every query. For PK algorithms where it's cheap to fake random public keys this is not a problem at all. > The main thing this would have to recommend itself is there is no > encoding of the localpart into DNS labels, [...] And thus no canonicalization concerns. > The oracle can query LDAP, ... can make up fake replies for > non-existent addresses to thwart directory harvesting attacks > if desired, ... > > HTTPS, allows the service to be reached from inside corporate > environments that block most other outbound services (possibly > including external DNS). In some environments even HTTPS is subject > to corporate MiTM (that the users are aware of with the HTTP proxy > signing certs trusted by browsers, ...). In such environments > users don't get end-to-end email encryption, just like they don't > get end-to-end HTTPS. Their border email gateway might be able to > play gateway-to-gateway SMIME with the destination. Yeah, and then either the client gives up (hey, if it's in a corporate network that seems fair) or we do the chaining-with-DNSSEC-proof thing I proposed earlier. Nico -- From nobody Fri Dec 12 14:50:56 2014 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 8D41C1A0065 for ; Fri, 12 Dec 2014 14:50:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 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, T_RP_MATCHES_RCVD=-0.01] 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 JlhAHzpsDbEo for ; Fri, 12 Dec 2014 14:50:53 -0800 (PST) Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) (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 64E4B1A00A7 for ; Fri, 12 Dec 2014 14:50:53 -0800 (PST) Received: by ore.jhcloos.com (Postfix, from userid 10) id CBF4C1E240; Fri, 12 Dec 2014 22:50:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1418424651; bh=K5bPaE1kXE6eTAEudeK1p+rABfWyI45Sm+5o5haBFP0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=F7nfas03cF/8Reznhq2cllxFdThaqNDsT7pbHsqiPW7ASVxvWmZbzWUZuNS7HA+pA 2VKBn6dJbWO2DgvzQpNQT50V6nspwDYKm03pj8/jPchEKldUxtrrCOCYkNf1B5By/6 v/tkTYTBaA3blaCTdoA8cvVj/kfVkgMMKaUvULXg= Received: by carbon.jhcloos.org (Postfix, from userid 500) id B08F160023; Fri, 12 Dec 2014 22:50:10 +0000 (UTC) From: James Cloos To: dane@ietf.org In-Reply-To: <20141212175242.GB25666@mournblade.imrryr.org> (Viktor Dukhovni's message of "Fri, 12 Dec 2014 17:52:42 +0000") References: <95826148-4F06-4942-87A4-2F6601BA0F90@nist.gov> <20141212175242.GB25666@mournblade.imrryr.org> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Fri, 12 Dec 2014 17:50:10 -0500 Message-ID: Lines: 14 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:28:141212:dane@ietf.org::ipuDHkJPPhaec6WL:0004GWKh X-Hashcash: 1:28:141212:ietf-dane@dukhovni.org::FE38NmRnY3RxUJ1u:000000000000000000000000000000000000009m/up Archived-At: http://mailarchive.ietf.org/arch/msg/dane/ZMy5ICPBd9ZK-VjxbWnzQ_vsOkw Subject: Re: [dane] email canonicalization for SMIMEA owner names 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: Fri, 12 Dec 2014 22:50:54 -0000 >>>>> "VD" == Viktor Dukhovni writes: VD> The presence of the associated SRV records would signal adoption VD> of the protocol. The only issue with using SRV is that the http GET path would have to be standardized, which could be an pain if the advertized MXs already serve https for something else. An NAPTR RR, OTOH, can specify an arbitrary URL. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Fri Dec 12 15:16:37 2014 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 AEECC1A00CD for ; Fri, 12 Dec 2014 15:16:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 qS47W6PbB531 for ; Fri, 12 Dec 2014 15:16:30 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F8811A0025 for ; Fri, 12 Dec 2014 15:16:30 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 8294E282FBF; Fri, 12 Dec 2014 23:16:28 +0000 (UTC) Date: Fri, 12 Dec 2014 23:16:28 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141212231628.GM25666@mournblade.imrryr.org> References: <95826148-4F06-4942-87A4-2F6601BA0F90@nist.gov> <20141212175242.GB25666@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/y3OG4sX6KHfgostxM2PE8SAV3m0 Subject: Re: [dane] email canonicalization for SMIMEA owner names X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 23:16:34 -0000 On Fri, Dec 12, 2014 at 05:50:10PM -0500, James Cloos wrote: > VD> of the protocol. > > The only issue with using SRV is that the http GET path would have to be > standardized, which could be an pain if the advertized MXs already serve > https for something else. I was thinking of multiplexing by port, rather than URI. So that the service in question really could be a light-weight HTTPS server add-on to an MTA, rather than an HTTP application in a general purpose HTTPS server. The key advantage is that MTAs already have code for email address parsing, table lookups, LDAP, ... and so operating a listener on some custom port (from an SRV record) might not be a major burden. The URI would then be "/". The protocol would be some elaboration of: Client: GET /?email= HTTP/1.1 Host: Content-Length: 0 Server: 200 OK Content-Type: text/plain; charset=us-ascii Connection: close 2 0 1 3 0 0 This avoids encoding issues, UDP payload limits, and allows MTAs to perform the necessary canonicalization to find the keys of variant address forms. The disadvantage of a service that's operated as part of the MTA, is that people would have to deploy updated MTAs to support this. It does however seem that this may be easier and more flexible than populating per-user data into the DNS. -- Viktor. From nobody Fri Dec 12 20:48:04 2014 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 529001A87C1 for ; Fri, 12 Dec 2014 20:48:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.037 X-Spam-Level: X-Spam-Status: No, score=-1.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 qABEPBroFpCH for ; Fri, 12 Dec 2014 20:48:01 -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 EE7411A802C for ; Fri, 12 Dec 2014 20:48:00 -0800 (PST) Received: (qmail 5089 invoked from network); 13 Dec 2014 04:47:55 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 13 Dec 2014 04:47:55 -0000 Date: 13 Dec 2014 04:47:37 -0000 Message-ID: <20141213044737.14765.qmail@ary.lan> From: "John Levine" To: dane@ietf.org Cc: dane@ietf.org In-Reply-To: <20141212231628.GM25666@mournblade.imrryr.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/5rigNW0ZTKiRo2wooKXC6cFbxH4 Subject: Re: [dane] email canonicalization for SMIMEA owner names 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: Sat, 13 Dec 2014 04:48:02 -0000 In article <20141212231628.GM25666@mournblade.imrryr.org> you write: >On Fri, Dec 12, 2014 at 05:50:10PM -0500, James Cloos wrote: > >> VD> of the protocol. >> >> The only issue with using SRV is that the http GET path would have to be >> standardized, which could be an pain if the advertized MXs already serve >> https for something else. > >I was thinking of multiplexing by port, rather than URI. So that >the service in question really could be a light-weight HTTPS server >add-on to an MTA, rather than an HTTP application in a general >purpose HTTPS server. Before we go too far down this road, we might check with some people who run large mail systems and ask how likely they are to spin up an all new address verification server. It doesn't seem very likely to me. The DNS has its faults, but it has the great advantage of already existing. R's, John From nobody Fri Dec 12 20:48:08 2014 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 421361A1C05 for ; Fri, 12 Dec 2014 20:48:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.037 X-Spam-Level: X-Spam-Status: No, score=-1.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 3NajQb8Anf5k for ; Fri, 12 Dec 2014 20:48:02 -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 EE69E1A6F03 for ; Fri, 12 Dec 2014 20:48:00 -0800 (PST) Received: (qmail 5089 invoked from network); 13 Dec 2014 04:47:55 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 13 Dec 2014 04:47:55 -0000 Date: 13 Dec 2014 04:47:37 -0000 Message-ID: <20141213044737.14765.qmail@ary.lan> From: "John Levine" To: dane@ietf.org Cc: dane@ietf.org In-Reply-To: <20141212231628.GM25666@mournblade.imrryr.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/5rigNW0ZTKiRo2wooKXC6cFbxH4 Subject: Re: [dane] email canonicalization for SMIMEA owner names 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: Sat, 13 Dec 2014 04:48:03 -0000 In article <20141212231628.GM25666@mournblade.imrryr.org> you write: >On Fri, Dec 12, 2014 at 05:50:10PM -0500, James Cloos wrote: > >> VD> of the protocol. >> >> The only issue with using SRV is that the http GET path would have to be >> standardized, which could be an pain if the advertized MXs already serve >> https for something else. > >I was thinking of multiplexing by port, rather than URI. So that >the service in question really could be a light-weight HTTPS server >add-on to an MTA, rather than an HTTP application in a general >purpose HTTPS server. Before we go too far down this road, we might check with some people who run large mail systems and ask how likely they are to spin up an all new address verification server. It doesn't seem very likely to me. The DNS has its faults, but it has the great advantage of already existing. R's, John From nobody Fri Dec 12 20:59:12 2014 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 B1CD31A88AE for ; Fri, 12 Dec 2014 20:59:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 K5cgHelPN4IS for ; Fri, 12 Dec 2014 20:59:10 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 510921A0385 for ; Fri, 12 Dec 2014 20:59:10 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3E4E9282F8B; Sat, 13 Dec 2014 04:59:09 +0000 (UTC) Date: Sat, 13 Dec 2014 04:59:09 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141213045908.GT25666@mournblade.imrryr.org> References: <20141212231628.GM25666@mournblade.imrryr.org> <20141213044737.14765.qmail@ary.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141213044737.14765.qmail@ary.lan> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/QFhuOfGr5RgOg_8QSfTglR5i1Rc Subject: Re: [dane] email canonicalization for SMIMEA owner names X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Dec 2014 04:59:12 -0000 On Sat, Dec 13, 2014 at 04:47:37AM -0000, John Levine wrote: > >I was thinking of multiplexing by port, rather than URI. So that > >the service in question really could be a light-weight HTTPS server > >add-on to an MTA, rather than an HTTP application in a general > >purpose HTTPS server. > > Before we go too far down this road, we might check with some people > who run large mail systems and ask how likely they are to spin up an > all new address verification server. It doesn't seem very likely to > me. > > The DNS has its faults, but it has the great advantage of already existing. And of course ask them also how likely they are to publish per-user keys in DNS, other than perhaps a wildcard trust-anchor. In other words, were they to provide access to a key lookup service, what are the relevant design constraints. Perhaps Ian Fette can comment from a Gmail perspective. Also do they see key lookup for encryption on first contact as a requirement? Or is signature-only first contact with encryption keys provided optionally on reply, their preferred model for encryption key distribution. -- Viktor. From nobody Sat Dec 13 08:02:32 2014 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 287331A01F4 for ; Sat, 13 Dec 2014 08:02:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 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, T_RP_MATCHES_RCVD=-0.01] 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 ovdV85bjlc5h for ; Sat, 13 Dec 2014 08:02:28 -0800 (PST) Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.23.85]) (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 2D4801A01D6 for ; Sat, 13 Dec 2014 08:02:28 -0800 (PST) Received: by ore.jhcloos.com (Postfix, from userid 10) id 8295D1E7C7; Sat, 13 Dec 2014 16:02:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1418486547; bh=8I/1niQ9ChKQMhJoyYadeiVdSPday92/7nqEBc+ySSk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Xur9hkgTcJDkr4LzvCLlGLTVVNXdawcKwT/Ryyh+h9OA3oR2GfZXayajd4n3lONI6 dgOH2lo4Gbw1izEFQSECgBpTnWNv2AWWE7n6Oa0iu0/IBc3xMlrbezIqGeMFomcDFg UFjqXrTjhqAffdCAemXECTzQGQWFRDhtTEUcgv90= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 5473860027; Sat, 13 Dec 2014 16:02:12 +0000 (UTC) From: James Cloos To: Viktor Dukhovni In-Reply-To: <20141212231628.GM25666@mournblade.imrryr.org> (Viktor Dukhovni's message of "Fri, 12 Dec 2014 23:16:28 +0000") References: <95826148-4F06-4942-87A4-2F6601BA0F90@nist.gov> <20141212175242.GB25666@mournblade.imrryr.org> <20141212231628.GM25666@mournblade.imrryr.org> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Sat, 13 Dec 2014 11:02:12 -0500 Message-ID: Lines: 29 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:28:141213:ietf-dane@dukhovni.org::aJJ25I3ymRuuGGjh:000000000000000000000000000000000000000G50w X-Hashcash: 1:28:141213:dane@ietf.org::mNhMrzZl67QUWH4s:0003oj7l Archived-At: http://mailarchive.ietf.org/arch/msg/dane/5FY09kHV3gRaugcZjq80J9aEO8Q Cc: dane@ietf.org Subject: Re: [dane] email canonicalization for SMIMEA owner names 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: Sat, 13 Dec 2014 16:02:30 -0000 >>>>> "VD" == Viktor Dukhovni writes: VD> I was thinking of multiplexing by port, rather than URI. I got that. But what if the MXs already run something on port 443? If the GET/POST path can be specified, the existing web server can proxy to the MTA's port. Otherwise the MTA would have to proxy anything which it doesn't handle. Of course, with ipv6 there are always enough addresses to put the other 443 service(s) on their own ip. So it is a short-term issue. And it may take longer for something like this widely to deploy than it will for v6 to displace v4 w/in the subset of sites which would use it. So it may not be worth worry. Otherwise, I like the idea. Either way, it would be cool for such a service to provide gpg keyids, too. So the reply should include for each line a token specifying which kind of key (smime, gpg, future) that line matches. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Sat Dec 13 10:17:51 2014 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 170801A1A98 for ; Sat, 13 Dec 2014 10:17:49 -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 nDD6O7ddAXIH for ; Sat, 13 Dec 2014 10:17:48 -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 DB6391A1A78 for ; Sat, 13 Dec 2014 10:17:47 -0800 (PST) Received: (qmail 87769 invoked from network); 13 Dec 2014 18:17:43 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 13 Dec 2014 18:17:43 -0000 Date: 13 Dec 2014 18:17:24 -0000 Message-ID: <20141213181724.16565.qmail@ary.lan> From: "John Levine" To: dane@ietf.org In-Reply-To: <20141213045908.GT25666@mournblade.imrryr.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/PQYU2U0AzhXoLMez3wLJcj-huMc Subject: Re: [dane] email canonicalization for SMIMEA owner names 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: Sat, 13 Dec 2014 18:17:49 -0000 >Also do they see key lookup for encryption on first contact as a >requirement? Or is signature-only first contact with encryption >keys provided optionally on reply, their preferred model for >encryption key distribution. How does that differ from what S/MIME does now, give or take the warts of which CAs you trust? It seems to me that SMIMEA offers two things: * verify an incoming signature without reference to a CA * encrypt mail to people who haven't already sent you a key Of the two, the second seems much more important. If it's only the first, I don't think it's worth the effort. R's, John From nobody Sat Dec 13 10:33:42 2014 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 245301A1A78 for ; Sat, 13 Dec 2014 10:33:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-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 lMpO0tvliAV3 for ; Sat, 13 Dec 2014 10:33:38 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A67841A0103 for ; Sat, 13 Dec 2014 10:33:38 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 83355284AF9; Sat, 13 Dec 2014 18:33:37 +0000 (UTC) Date: Sat, 13 Dec 2014 18:33:37 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141213183337.GW25666@mournblade.imrryr.org> References: <20141213045908.GT25666@mournblade.imrryr.org> <20141213181724.16565.qmail@ary.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141213181724.16565.qmail@ary.lan> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/uV-9oYjaN9TSBVgqktUJi_tmXfw Subject: Re: [dane] email canonicalization for SMIMEA owner names X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Dec 2014 18:33:40 -0000 On Sat, Dec 13, 2014 at 06:17:24PM -0000, John Levine wrote: > * verify an incoming signature without reference to a CA > * encrypt mail to people who haven't already sent you a key > > Of the two, the second seems much more important. If it's only the > first, I don't think it's worth the effort. [ I understand and in part agree with your point, but I think even the first alone is not as vacuous as it might seem. ] Well I don't see to many organizations outsourcing user enrollment to a CA, or wanting to operate an RA, so the CA-trust thing is not so much the issue as the problem of getting CA signatures for the user certificates, having to handle revocation via a CA, ... What DANE can do is make it possible to just use your enterprise CA. For example, the Microsoft CA is very difficult to use for a Windows shop, with DANE this can be extend to issuing certificates that others can validate. And I am not sure that first contact end-to-end encryption in which only the final recipient gets to read the mail will be terribly popular in a world of spam and email malware. In many ways, signature-only with key exchange on reply has security advantages that may make it a popular mode of deployment. -- Viktor. From nobody Sun Dec 14 14:45:06 2014 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 11CFC1A0250 for ; Sun, 14 Dec 2014 14:45:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-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 9LFCQHIl3Zvc for ; Sun, 14 Dec 2014 14:45:03 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62AF31A01F6 for ; Sun, 14 Dec 2014 14:45:03 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id B4C21284AD5; Sun, 14 Dec 2014 22:45:01 +0000 (UTC) Date: Sun, 14 Dec 2014 22:45:01 +0000 From: Viktor Dukhovni Sender: dane To: dane@ietf.org Message-ID: <20141214224501.GI25666@mournblade.imrryr.org> References: <20141201013357.GF285@mournblade.imrryr.org> <547BC8F9.1070605@andyet.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <547BC8F9.1070605@andyet.net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/ClxfuXaC4CRie79plUXKttywqG0 Subject: [dane] WGLC: DANE-SRV ("Address Queries" and "TLSA queries" feedback) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Dec 2014 22:45:05 -0000 On Sun, Nov 30, 2014 at 06:48:41PM -0700, Peter Saint-Andre - &yet wrote: [ I'm splitting it into a few messages to keep it manageable, and in any case some of my comments are still pencil marks on a print-out, not yet transcribed. ] This message covers sections 3.2 ("Address Queries") and 3.3 ("TLSA Queries"). General comment (copied verbatim from abstract and introduction feedback): The draft frequently talks about "hostnames", where what is really meant is a transport endpoint (port, transport protocol, host). With PKIX-EE or DANE-EE certificate usages, TLSA records are more precise than the Web PKI and can associate different, non-interchangeable key material with distinct services on a single host. So in many places I will be suggesting replacing statements about "hostnames" with statements about "transport endpoints". 3.2. Address Queries Clients that support only v4 or only v6 need not make queries for an address type they can't use. OLD: For each SRV target server host name, the client makes A and AAAA queries, performs DNSSEC validation on the address (A or AAAA) response, and continues as follows based on the results: NEW: For each SRV target server host name, the client makes A and/or AAAA queries, performs DNSSEC validation on the address (A or AAAA) response, and continues as follows based on the results: The term "usable" is not applicable in the context of address queries. TLSA queries should be made if either the A or AAAA response is secure (e.g., sometimes the absence of "AAAA" is "insecure" due to opt-out, while the "A" records are "secure"). When the zone containing the host's A/AAAA records is unsigned, queries for TLSA are more likely to fail than to unexpectedly produce "secure" results. This is not to say that they are in fact likely to "fail". OLD: If the response is "secure" and usable, the client MUST perform a TLSA query for that target server host name as described in the next section. If the response is "insecure", the client MUST NOT perform a TLSA query for that target server host name; the TLSA query will most likely fail. If the response is "bogus" or "indeterminate", the client MUST NOT connect to this target server; instead it uses the next most appropriate SRV target. NEW: If either of the A or AAAA RRsets is "secure", the client MUST perform a TLSA query for that target service endpoint as described in the next section. If both RRsets are "insecure", the client MUST NOT perform a TLSA query for that target; such TLSA queries are very unlikely to produce "secure" results and have been observed to spuriously fail even though no TLSA records are present. To defend against downgrade attacks, if address record lookup fails (this includes both the "bogus" and RFC 4035 "indeterminate" validation status) the client MUST NOT connect to this target service endpoint; instead it uses the next most appropriate SRV target. 3.3. TLSA Queries Perhaps a better split: OLD: For example, the following SRV record for IMAP (see ) leads to the TLSA query shown below:
NEW: For example, the following SRV record for IMAP (see )
leads to the TLSA query shown below:
-- Viktor. From nobody Sun Dec 14 15:44:53 2014 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 B9D581A0161 for ; Sun, 14 Dec 2014 15:44:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 qgxq4mehom1s for ; Sun, 14 Dec 2014 15:44:50 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 149971A0217 for ; Sun, 14 Dec 2014 15:44:49 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 72C7B284AD5; Sun, 14 Dec 2014 23:44:48 +0000 (UTC) Date: Sun, 14 Dec 2014 23:44:48 +0000 From: Viktor Dukhovni Sender: dane To: dane@ietf.org Message-ID: <20141214234448.GK25666@mournblade.imrryr.org> References: <20141201013357.GF285@mournblade.imrryr.org> <547BC8F9.1070605@andyet.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <547BC8F9.1070605@andyet.net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/JBU3l9-pBLSQ-VCPvrmK9ALI2eI Subject: [dane] WGLC: DANE-SRV feedback on 3.4 through rest of document. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Dec 2014 23:44:51 -0000 [ I'm splitting it into a few messages to keep it manageable, and in any case some of my comments are still pencil marks on a print-out, not yet transcribed. ] This message covers 3.4 through the end of the document. General comment (copied verbatim from abstract and introduction feedback): The draft frequently talks about "hostnames", where what is really meant is a transport endpoint (port, transport protocol, host). With PKIX-EE or DANE-EE certificate usages, TLSA records are more precise than the Web PKI and can associate different, non-interchangeable key material with distinct services on a single host. So in many places I will be suggesting replacing statements about "hostnames" with statements about "transport endpoints". 3.4. Impact on TLS Usage First bullet: s/under 4/in 4/ Third bullet: s/If the TLSA response is "bogus" or "indeterminate"/If the TLSA lookup fails/ perhaps noting that a "secure" or "insecure" NXDOMAIN is not a failure (as in DNS error section of SMTP draft). 4.1. SRV records only Second paragraph: Also mention here that 6125 and reference identifiers don't apply with DANE-EE(3) (some folks may not read as far as 4.2) 4.2 TLSA Records: The SMTP and OPS drafts have "toned down" the degree to which the content of DANE-EE(3) certs is ignored, specifically only the hostname and expiration are superseded by DNSSEC. Other features of the certificate (key usage, ...) may still be taken into account. Material after section 4 is largely fine. * Please update smtp-with-dane reference from -05 to -13. * Should he XMPP example SRV record really be "_xmpp-client", or instead "_xmpp-server"? Not familiar with XMPP, so please pardon my confusion if that's what it is. -- Viktor. From nobody Sun Dec 21 14:55:56 2014 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 355031A89B5 for ; Sun, 21 Dec 2014 14:55:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.078 X-Spam-Level: X-Spam-Status: No, score=0.078 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] 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 aWWWlY8XnJei for ; Sun, 21 Dec 2014 14:55:51 -0800 (PST) Received: from gw02.mail.saunalahti.fi (gw02.mail.saunalahti.fi [195.197.172.116]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23D081A702F for ; Sun, 21 Dec 2014 14:55:50 -0800 (PST) Received: from woodstock.owlhill.net (a88-113-163-188.elisa-laajakaista.fi [88.113.163.188]) by gw02.mail.saunalahti.fi (Postfix) with ESMTP id 6A1A540017 for ; Mon, 22 Dec 2014 00:55:46 +0200 (EET) Received: from [IPv6:2001:14b8:14e:1:a05a:f9b3:645:fc7b] (unknown [IPv6:2001:14b8:14e:1:a05a:f9b3:645:fc7b]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by woodstock.owlhill.net (Postfix) with ESMTP id C17DF734B261 for ; Mon, 22 Dec 2014 00:55:46 +0200 (EET) Message-ID: <54974FEA.4070401@iki.fi> Date: Mon, 22 Dec 2014 00:55:38 +0200 From: Tapio Sokura User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: dane@ietf.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/JQsXCRNLDewRYeLXMFkpDGxSxDw Subject: [dane] Extracting SPKI from a certificate/key 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, 21 Dec 2014 22:55:55 -0000 Hello, I had some trouble finding out how to extract the SPKI from an x.509 certificate to use in TLSA records. I stumbled upon https://www.huque.com/bin/gen_tlsa and based on matching the output, I came up with the openssl/sha256sum command lines listed below. The first one is based on the private key file and the second on an x.509 certificate that contains the same public key. Can someone verify these produce the correct results for use with tlsa dane-ee spki sha-256 records? Naturally these exact syntaxes only work for RSA keys. from private key: openssl rsa -in private.key -outform der -pubout |sha256sum from x509 certificate: openssl x509 -in x509.crt -pubkey -noout|openssl rsa -pubin -outform der|sha256sum Tapio From nobody Sun Dec 21 15:07:52 2014 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 5FB761A6F2C for ; Sun, 21 Dec 2014 15:07:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 cpX0QWbS5Bnz for ; Sun, 21 Dec 2014 15:07:47 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 113CC1A702F for ; Sun, 21 Dec 2014 15:07:47 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D0809284ADB; Sun, 21 Dec 2014 23:07:45 +0000 (UTC) Date: Sun, 21 Dec 2014 23:07:45 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141221230745.GY24649@mournblade.imrryr.org> References: <54974FEA.4070401@iki.fi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="48TaNjbzBVislYPb" Content-Disposition: inline In-Reply-To: <54974FEA.4070401@iki.fi> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/3AWi6BTeoohnzkdH3xAGKv3sN_Q Subject: Re: [dane] Extracting SPKI from a certificate/key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Dec 2014 23:07:49 -0000 --48TaNjbzBVislYPb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Dec 22, 2014 at 12:55:38AM +0200, Tapio Sokura wrote: > Can someone verify these > produce the correct results for use with tlsa dane-ee spki sha-256 > records? Naturally these exact syntaxes only work for RSA keys. > > from private key: > > openssl rsa -in private.key -outform der -pubout | > sha256sum > > from x509 certificate: > > openssl x509 -in x509.crt -pubkey -noout | > openssl rsa -pubin -outform der | > sha256sum Basically correct. In notices I send to sites whose TLSA records are not right, I include the text below: ----- Snip ----- To generate a TLSA "3 1 1" record from a certificate file in PEM format (using OpenSSL 1.0.0 or later): printf '_25._tcp.%s. IN TLSA 3 1 1 %s\n' \ $(uname -n) \ $(openssl x509 -in cert.pem -noout -pubkey | openssl pkey -pubin -outform DER | openssl dgst -sha256 -binary | hexdump -ve '/1 "%02x"') you can use the attached tlsagen script if you prefer, $ ./tlsagen cert.pem $(uname -n) 3 1 1 or use the website: https://www.huque.com/bin/gen_tlsa ----- Snip ----- The above is not RSA-specific and works equally well for ECDSA keys. However, it requires OpenSSL 1.0.0 or later. One really should not be using OpenSSL 0.9.8 or earlier at this point, and even 1.0.0 is reaching end-of-life. -- Viktor. --48TaNjbzBVislYPb Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=tlsagen #! /usr/bin/env bash # Bash needed for PIPESTATUS array extract() { case "$4" in 0) openssl x509 -in "$1" -outform DER;; 1) openssl x509 -in "$1" -noout -pubkey | openssl pkey -pubin -outform DER;; esac } digest() { case "$5" in 0) cat;; 1) openssl dgst -sha256 -binary;; 2) openssl dgst -sha512 -binary;; esac } encode() { local cert=$1; shift local hostport=$1; shift local u=$1; shift local s=$1; shift local m=$1; shift local host=$hostport local port=25 OIFS="$IFS"; IFS=":"; set -- $hostport; IFS="$OIFS" if [ $# -eq 2 ]; then host=$1; port=$2; fi printf "_%d._tcp.%s. IN TLSA %d %d %d %s\n" \ "$port" "$host" "$u" "$s" "$m" \ "$(hexdump -ve '/1 "%02X"')" } error() { echo "$1" 1>&2; exit 1; } usage() { error "Usage: $0 cert.pem host[:port] usage selector mtype"; } if [ $# -ne 5 ]; then usage; fi case "$(echo $3 | tr '[A-Z]' '[a-z]')" in 0|pkix-[ct]a) usage=0;; 1|pkix-ee) usage=1;; 2|dane-[ct]a) usage=2;; 3|dane-ee) usage=3;; *) error "Invalid certificate usage: $3";; esac case "$(echo $4 | tr '[A-Z]' '[a-z]')" in 0|cert) selector=0;; 1|spki|pkey) selector=1;; *) error "Invalid selector: $4";; esac case "$(echo $5 | tr '[A-Z]' '[a-z]')" in 0|full) mtype=0;; 1|sha2-256|sha256|sha-256) mtype=1;; 2|sha2-512|sha512|sha-512) mtype=2;; *) error "Invalid matching type: $5";; esac set -- "$1" "$2" "$usage" "$selector" "$mtype" rr=$( extract "$@" | digest "$@" | encode "$@" exit $(( ${PIPESTATUS[0]} | ${PIPESTATUS[1]} | ${PIPESTATUS[2]} )) ) status=$? if [ $status -ne 0 ]; then exit $status fi echo "$rr" --48TaNjbzBVislYPb--