From nobody Tue Sep 1 11:44:46 2015 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 DA53F1AC39D for ; Tue, 1 Sep 2015 11:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-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 HLwew40Wizey for ; Tue, 1 Sep 2015 11:44:43 -0700 (PDT) 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 B6C531ABD3D for ; Tue, 1 Sep 2015 11:44:43 -0700 (PDT) Received: from smtp32.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp32.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id D1FCE380389 for ; Tue, 1 Sep 2015 14:44:42 -0400 (EDT) Received: by smtp32.relay.iad3a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id B52D73802F3 for ; Tue, 1 Sep 2015 14:44:41 -0400 (EDT) X-Sender-Id: ogud@ogud.com Received: from [10.20.30.43] (pool-173-66-187-177.washdc.fios.verizon.net [173.66.187.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.4.2); Tue, 01 Sep 2015 18:44:42 GMT From: Olafur Gudmundsson Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <8E7802A2-A9DC-464A-A427-DEA2C0EA5E65@ogud.com> Date: Tue, 1 Sep 2015 14:44:37 -0400 To: dane WG list Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [dane] E-mail Cert left hand side -- what the chairs think the consensus is X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 18:44:45 -0000 Dear Colleagues=20 We received some questions about the selection.=20 In the discussions on the different ways to represent the left hand = sides as DNS names there are number of ways the three ways we have been = discussing are: a) HEX( SHA256( LHS) [:28])) i.e. 28 left most bytes of SHA256 hash = hexified=20 b) HEX( SHA256( str2lower(LHS))[:28]) i.e. the same as before but the = email name is lower cased before digesting, this will help mainly email = addresses written in Latin-1=20 c) split_lables(HEX(LHS), 60)) i.e. encode the email as a HEX, there = are two drawbacks and one advantage see below=20 a) and b) both are fixed length and fit in one label, c) on the other = hand may require multiple labels=20 c) in theory allows server that sees query may apply rules that allow it = to give out better answers=20 c) on the other hand also has privacy issues against a passive = =E2=80=9Cattacker=E2=80=9D i.e. one that only listens to traffic, it can = w/o any work discover email addresses, a) and b) require work by = attacker to discover the email address (reverse/guess the HASH()) . = There was pushback due to the privacy issue.=20 The difference between a) and b) is the lower casing. While this may be = a win in some cases that is unproven, as we do not know if more people = will know or guess the LHS they want to send to.=20 In addition the DNS contains a simple facility to equate names i.e. = CNAME. Olafur & Warren=20 From nobody Tue Sep 1 12:00:38 2015 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 DA4B11B2E78 for ; Tue, 1 Sep 2015 12:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.961 X-Spam-Level: X-Spam-Status: No, score=-1.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, 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 oL-oSsg7K-qd for ; Tue, 1 Sep 2015 12:00:31 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AF461B2DA7 for ; Tue, 1 Sep 2015 12:00:25 -0700 (PDT) Received: from [192.168.50.163] (scandic804.host.songnetworks.se [212.214.188.34]) by mail.frobbit.se (Postfix) with ESMTPSA id 99DD723C0A; Tue, 1 Sep 2015 21:00:22 +0200 (CEST) From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" To: "Olafur Gudmundsson" Date: Tue, 01 Sep 2015 21:00:22 +0200 Message-ID: <80A58E34-A4E8-4F05-9809-EDA6E4887B93@frobbit.se> In-Reply-To: <8E7802A2-A9DC-464A-A427-DEA2C0EA5E65@ogud.com> References: <8E7802A2-A9DC-464A-A427-DEA2C0EA5E65@ogud.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_74BDF303-B560-4478-8353-7D47591CC1EF_="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Mailer: MailMate (1.9.2r5107) Archived-At: Cc: dane WG list Subject: Re: [dane] E-mail Cert left hand side -- what the chairs think the consensus is X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 19:00:33 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_74BDF303-B560-4478-8353-7D47591CC1EF_= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I think one should combine: 1. Whatever the left hand side is in the traditional RFC822 envelope addr= ess 2. Case folding, so that it is surviving whatever basic matching in email= clients/services 3. Hash, if nothing else for privacy reasons So, I guess (b) is the closest, but I want to be more specific it is "the= ascii/fallback" version of the local part and not (for example) the inte= rnationalized version -- while supporting potential future UTF-8 encoded = raw addresses. I.e. use whatever localpart is used in the SMTP protocol. = But I guess that is what you mean with LHS? Patrik On 1 Sep 2015, at 20:44, Olafur Gudmundsson wrote: > Dear Colleagues > > We received some questions about the selection. > In the discussions on the different ways to represent the left hand sid= es as DNS names there are number of ways the three ways we have been disc= ussing are: > a) HEX( SHA256( LHS) [:28])) i.e. 28 left most bytes of SHA256 hash he= xified b) HEX( SHA256( str2lower(LHS))[:28]) i.e. the same as before but = the email name is lower cased before digesting, this will help mainly ema= il addresses written in Latin-1 c) split_lables(HEX(LHS), 60)) i.e. e= ncode the email as a HEX, there are two drawbacks and one advantage see b= elow > > a) and b) both are fixed length and fit in one label, c) on the other h= and may require multiple labels c) in theory allows server that sees quer= y may apply rules that allow it to give out better answers c) on the othe= r hand also has privacy issues against a passive =E2=80=9Cattacker=E2=80=9D= i.e. one that only listens to traffic, it can w/o any work discover emai= l addresses, a) and b) require work by attacker to discover the email add= ress (reverse/guess the HASH()) . There was pushback due to the privacy i= ssue. > > The difference between a) and b) is the lower casing. While this may be= a win in some cases that is unproven, as we do not know if more people w= ill know or guess the LHS they want to send to. > In addition the DNS contains a simple facility to equate names i.e. CNA= ME. > > Olafur & Warren > > > > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane --=_MailMate_74BDF303-B560-4478-8353-7D47591CC1EF_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlXl9cYACgkQrMabGguI183pjwCfR9RS/JoMpN0Ws3hvVRc5UWMx W2QAnAs8O/bWnSZYRR0iayhvPiD3vmVm =ERpP -----END PGP SIGNATURE----- --=_MailMate_74BDF303-B560-4478-8353-7D47591CC1EF_=-- From nobody Tue Sep 1 17:14:45 2015 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 5DF581A8889 for ; Tue, 1 Sep 2015 17:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 YckgHIle19Q5 for ; Tue, 1 Sep 2015 17:14:42 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 427BB1A8892 for ; Tue, 1 Sep 2015 17:14:42 -0700 (PDT) Received: by iofb144 with SMTP id b144so2458518iof.1 for ; Tue, 01 Sep 2015 17:14:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=nSi3MRfWSVhmJjpD++mHmnqyGU50jldxU9i06SeVoQM=; b=aTKzER+KA43UAqJHjZ10dhZGfHVvOQ9RkT7L/anwSml5ccc/pvSwpmW7GCWoehVZLN aBwZDgj2pt0TU21UZhthZNg5hOEUW4N7kFYowND5I+sZqJEomF6mXuS+DuNBbnk8kwYm m39uwgKOg04sbRW+iXksA/MPFegkmD1GEO5z1ScfiH66Uv7H2M7F4KaLFc+aAZDRtMTg zCgQFhSSuvLq8K2WEgyOnpy/qvNRCGXToUt1M+Ynos2jGk2pe+sXWnSI8UjX8LsMHpRx RWelgLOdNUJlNeIjGaS1i0LgihYIsY7M1a+V0/mv3mY6/CI+7eGramayL72v59cGKL4d BM7g== MIME-Version: 1.0 X-Received: by 10.107.153.74 with SMTP id b71mr15452041ioe.23.1441152881505; Tue, 01 Sep 2015 17:14:41 -0700 (PDT) Received: by 10.64.76.45 with HTTP; Tue, 1 Sep 2015 17:14:41 -0700 (PDT) In-Reply-To: <8E7802A2-A9DC-464A-A427-DEA2C0EA5E65@ogud.com> References: <8E7802A2-A9DC-464A-A427-DEA2C0EA5E65@ogud.com> Date: Tue, 1 Sep 2015 20:14:41 -0400 Message-ID: From: Brian Dickson To: Olafur Gudmundsson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: dane WG list Subject: Re: [dane] E-mail Cert left hand side -- what the chairs think the consensus is X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 00:14:44 -0000 I think the safest choice is a). Here's the logic that applies to a) vs b), which I think leads to choice a) being preferred. Suppose there is a domain where email addresses are case-sensitive. (RFC822 et al permit this.) Suppose there is a case-folded collision (two LHS addresses differ only by case). What happens if you want to encrypt ONLY to the correct recipient? You need some way to identify the correct public key from among the two (or more!) colliding LHS values, or you are forced to encrypt with all the keys found. This is an undesirable security and/or privacy risk introduced by the use of str2lower. Or, alternatively, how do you associate the correct key with the correct recipient, in a way that does not also leak the non-SHA256'd address to a passive observer? I don't think you can. These questions are mooted in choice a), since there is no case folding and thus no collision. So, I think the choice between a) and b) is a no-brainer: a). Brian On Tue, Sep 1, 2015 at 2:44 PM, Olafur Gudmundsson wrote: > > Dear Colleagues > > We received some questions about the selection. > In the discussions on the different ways to represent the left hand sides= as DNS names there are number of ways the three ways we have been discussi= ng are: > a) HEX( SHA256( LHS) [:28])) i.e. 28 left most bytes of SHA256 hash hexi= fied > b) HEX( SHA256( str2lower(LHS))[:28]) i.e. the same as before but the ema= il name is lower cased before digesting, this will help mainly email addres= ses written in Latin-1 > c) split_lables(HEX(LHS), 60)) i.e. encode the email as a HEX, there = are two drawbacks and one advantage see below > > a) and b) both are fixed length and fit in one label, c) on the other han= d may require multiple labels > c) in theory allows server that sees query may apply rules that allow it = to give out better answers > c) on the other hand also has privacy issues against a passive =E2=80=9Ca= ttacker=E2=80=9D i.e. one that only listens to traffic, it can w/o any work= discover email addresses, a) and b) require work by attacker to discover t= he email address (reverse/guess the HASH()) . There was pushback due to the= privacy issue. > > The difference between a) and b) is the lower casing. While this may be a= win in some cases that is unproven, as we do not know if more people will = know or guess the LHS they want to send to. > In addition the DNS contains a simple facility to equate names i.e. CNAME= . > > Olafur & Warren > > > > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From nobody Tue Sep 1 20:10:14 2015 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 119651B424A for ; Tue, 1 Sep 2015 20:10:13 -0700 (PDT) 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 qLBrKyBqnwy5 for ; Tue, 1 Sep 2015 20:10:10 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5063A1B4245 for ; Tue, 1 Sep 2015 20:10:10 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3n5Vcv6ZYTz3FT; Wed, 2 Sep 2015 05:10:07 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=sFrJbqeJ X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id cTNO231W5tD5; Wed, 2 Sep 2015 05:10:04 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 2 Sep 2015 05:10:04 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id C6D5C80030; Tue, 1 Sep 2015 23:10:02 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1441163402; bh=RKT3xVzSYRhT64u9KktDcZi5S8L/w2kgMCdbDAYxfK0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=sFrJbqeJksjd56tOOZtYFcSk2S+YPeD2WS/QfwtuJ4pr4yWInmsShnZT1R6ZInkG9 cg5fsUWEIKDFBngUayRZ1H6w8Y7Z2OUGsg2imZfmllADSUTx2g+DQuWbO7SB5bzmQH 7gm1VYXs58K7WP4WGPccC5GW1wJ+cqNXziYG8itg= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.2/8.15.2/Submit) with ESMTP id t823A2QC024439; Tue, 1 Sep 2015 23:10:02 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 1 Sep 2015 23:10:02 -0400 (EDT) From: Paul Wouters To: Brian Dickson In-Reply-To: Message-ID: References: <8E7802A2-A9DC-464A-A427-DEA2C0EA5E65@ogud.com> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=UTF-8 Content-Transfer-Encoding: 8BIT Archived-At: Cc: dane WG list Subject: Re: [dane] E-mail Cert left hand side -- what the chairs think the consensus is X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 03:10:13 -0000 On Tue, 1 Sep 2015, Brian Dickson wrote: > Suppose there is a domain where email addresses are case-sensitive. > (RFC822 et al permit this.) > Suppose there is a case-folded collision (two LHS addresses differ > only by case). > > What happens if you want to encrypt ONLY to the correct recipient? What is "the correct recipient" in that case? Your supposed use case would consist of say Paul@nohats.ca and paul@nohats.ca being different people. These two people would already regularly receive each other's email. When you tell someone your email over the phone, do you say "brian dot peter dot dickson at gmail dot com" or do you say "lowercase brian dot lowercase peter dot lowercase dickson at gmail dot com"? This simply does not happen in the real world. > So, I think the choice between a) and b) is a no-brainer: a). I disagree. You are solving a non-existent case at the experience of a real life case of auto-capitalization. For example, today I logged in on "bluejeans.com" using their ios app, and their app changed my username input of "pwouters@redhat.com" to "Pwouters@redhat.com". It wasn't even a dictionary word/name and it got capitalized. In the real world therefor, option a) is the worst choice. Paul > Brian > > On Tue, Sep 1, 2015 at 2:44 PM, Olafur Gudmundsson wrote: >> >> Dear Colleagues >> >> We received some questions about the selection. >> In the discussions on the different ways to represent the left hand sides as DNS names there are number of ways the three ways we have been discussing are: >> a) HEX( SHA256( LHS) [:28])) i.e. 28 left most bytes of SHA256 hash hexified >> b) HEX( SHA256( str2lower(LHS))[:28]) i.e. the same as before but the email name is lower cased before digesting, this will help mainly email addresses written in Latin-1 >> c) split_lables(HEX(LHS), 60)) i.e. encode the email as a HEX, there are two drawbacks and one advantage see below >> >> a) and b) both are fixed length and fit in one label, c) on the other hand may require multiple labels >> c) in theory allows server that sees query may apply rules that allow it to give out better answers >> c) on the other hand also has privacy issues against a passive “attacker” i.e. one that only listens to traffic, it can w/o any work discover email addresses, a) and b) require work by attacker to discover the email address (reverse/guess the HASH()) . There was pushback due to the privacy issue. >> >> The difference between a) and b) is the lower casing. While this may be a win in some cases that is unproven, as we do not know if more people will know or guess the LHS they want to send to. >> In addition the DNS contains a simple facility to equate names i.e. CNAME. >> >> Olafur & Warren >> >> >> >> >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > From nobody Wed Sep 2 02:59:49 2015 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 D59D91B515A for ; Wed, 2 Sep 2015 02:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.66 X-Spam-Level: X-Spam-Status: No, score=-1.66 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_DE=0.35, HTML_MESSAGE=0.001, 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 N9MQKaVJh3Kv for ; Wed, 2 Sep 2015 02:59:45 -0700 (PDT) Received: from michael01.phpgangsta.de (phpgangsta.de [84.200.8.31]) (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 19E1B1B52AF for ; Wed, 2 Sep 2015 02:59:44 -0700 (PDT) Received: from [10.0.118.101] (ip-88-153-154-113.hsi04.unitymediagroup.de [88.153.154.113]) by michael01.phpgangsta.de (Postfix) with ESMTPSA id 92D0B48C68A for ; Wed, 2 Sep 2015 11:59:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=phpgangsta.de; s=mail201210; t=1441187949; bh=sLdYQ2/AfnDQ7GtR+5/7GvTfNGN4oHkCN5ycZ3We1v8=; h=Subject:To:References:From:Date:In-Reply-To; b=RoP7prAaLhjfFMy6JDe7ayBgh3bAlKMIZY+aoENtj63fX7cBJig/h5KPbCkpBXRNG KvqNpdMQ3Z6aFpKtci03rUuL4AiCXcTkcK24DHpLjNRaelPIA1iYTCR6vm/7iDQDjM EEAWYAUlLHBuA4AusASk4lww69FsUn9q59fLUn/8= To: dane@ietf.org References: <8E7802A2-A9DC-464A-A427-DEA2C0EA5E65@ogud.com> From: Michael Kliewe X-Enigmail-Draft-Status: N1110 Message-ID: <55E6C885.2080102@phpgangsta.de> Date: Wed, 2 Sep 2015 11:59:33 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------050504060608020509040309" Archived-At: Subject: Re: [dane] E-mail Cert left hand side -- what the chairs think the consensus is X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 09:59:48 -0000 This is a multi-part message in MIME format. --------------050504060608020509040309 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit b) is the most practical solution, I don't know ANY mail provider or private mailserver that handles local parts case-sensitive... a) would be more correct. And I would suggest an additional DNS record for "rules", like TXT="nodots,lower,subaddressing:+" for Gmail (I hope it's correct) and maybe just "lower" for most others. The mail provider can publish this rule, and clients that want to help the enduser can apply it to the local part before querying for the OPENPGPKEY/SMIME record... The only drawback is that you need 2 DNS queries, but does anybody notice these additional 50ms? And the most used "rules" can be cached or hardcoded into the client. With this you are most flexible, you don't have unwanted collisions, and it's a solution that can be fully automated and secure for encryption gateways. You even could think about a "domain-salt" that could be added to the "rules" TXT record, so that "info" in domain.com is not the same as "info" in domain.org... Then an attacker needs a rainbow table per domain, and not one global rainbow table... c) is no option (privacy) Michael On 02.09.2015 02:14, Brian Dickson wrote: > I think the safest choice is a). > > Here's the logic that applies to a) vs b), which I think leads to > choice a) being preferred. > Suppose there is a domain where email addresses are case-sensitive. > (RFC822 et al permit this.) > Suppose there is a case-folded collision (two LHS addresses differ > only by case). > > What happens if you want to encrypt ONLY to the correct recipient? You > need some way to identify the correct public key from among the two > (or more!) colliding LHS values, or you are forced to encrypt with all > the keys found. This is an undesirable security and/or privacy risk > introduced by the use of str2lower. > > Or, alternatively, how do you associate the correct key with the > correct recipient, in a way that does not also leak the non-SHA256'd > address to a passive observer? I don't think you can. > > These questions are mooted in choice a), since there is no case > folding and thus no collision. > > So, I think the choice between a) and b) is a no-brainer: a). > > Brian > > On Tue, Sep 1, 2015 at 2:44 PM, Olafur Gudmundsson wrote: >> Dear Colleagues >> >> We received some questions about the selection. >> In the discussions on the different ways to represent the left hand sides as DNS names there are number of ways the three ways we have been discussing are: >> a) HEX( SHA256( LHS) [:28])) i.e. 28 left most bytes of SHA256 hash hexified >> b) HEX( SHA256( str2lower(LHS))[:28]) i.e. the same as before but the email name is lower cased before digesting, this will help mainly email addresses written in Latin-1 >> c) split_lables(HEX(LHS), 60)) i.e. encode the email as a HEX, there are two drawbacks and one advantage see below >> >> a) and b) both are fixed length and fit in one label, c) on the other hand may require multiple labels >> c) in theory allows server that sees query may apply rules that allow it to give out better answers >> c) on the other hand also has privacy issues against a passive “attacker” i.e. one that only listens to traffic, it can w/o any work discover email addresses, a) and b) require work by attacker to discover the email address (reverse/guess the HASH()) . There was pushback due to the privacy issue. >> >> The difference between a) and b) is the lower casing. While this may be a win in some cases that is unproven, as we do not know if more people will know or guess the LHS they want to send to. >> In addition the DNS contains a simple facility to equate names i.e. CNAME. >> >> Olafur & Warren >> >> >> >> >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane --------------050504060608020509040309 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit b) is the most practical solution, I don't know ANY mail provider or private mailserver that handles local parts case-sensitive...

a) would be more correct. And I would suggest an additional DNS record for "rules", like TXT="nodots,lower,subaddressing:+" for Gmail (I hope it's correct) and maybe just "lower" for most others. The mail provider can publish this rule, and clients that want to help the enduser can apply it to the local part before querying for the OPENPGPKEY/SMIME record... The only drawback is that you need 2 DNS queries, but does anybody notice these additional 50ms? And the most used "rules" can be cached or hardcoded into the client.
With this you are most flexible, you don't have unwanted collisions, and it's a solution that can be fully automated and secure for encryption gateways.
You even could think about a "domain-salt" that could be added to the "rules" TXT record, so that "info" in domain.com is not the same as "info" in domain.org... Then an attacker needs a rainbow table per domain, and not one global rainbow table...

c) is no option (privacy)

Michael

On 02.09.2015 02:14, Brian Dickson wrote:
I think the safest choice is a).

Here's the logic that applies to a) vs b), which I think leads to
choice a) being preferred.
Suppose there is a domain where email addresses are case-sensitive.
(RFC822 et al permit this.)
Suppose there is a case-folded collision (two LHS addresses differ
only by case).

What happens if you want to encrypt ONLY to the correct recipient? You
need some way to identify the correct public key from among the two
(or more!) colliding LHS values, or you are forced to encrypt with all
the keys found. This is an undesirable security and/or privacy risk
introduced by the use of str2lower.

Or, alternatively, how do you associate the correct key with the
correct recipient, in a way that does not also leak the non-SHA256'd
address to a passive observer? I don't think you can.

These questions are mooted in choice a), since there is no case
folding and thus no collision.

So, I think the choice between a) and b) is a no-brainer: a).

Brian

On Tue, Sep 1, 2015 at 2:44 PM, Olafur Gudmundsson <ogud@ogud.com> wrote:

Dear Colleagues

We received some questions about the selection.
In the discussions on the different ways to represent the left hand sides as DNS names there are number of ways the three ways we have been discussing are:
a) HEX( SHA256( LHS) [:28]))  i.e. 28 left most bytes of SHA256 hash hexified
b) HEX( SHA256( str2lower(LHS))[:28]) i.e. the same as before but the email name is lower cased before digesting, this will help mainly email addresses written in Latin-1
c)  split_lables(HEX(LHS), 60))    i.e. encode the email as a HEX, there are two drawbacks and one advantage see below

a) and b) both are fixed length and fit in one label, c) on the other hand may require multiple labels
c) in theory allows server that sees query may apply rules that allow it to give out better answers
c) on the other hand also has privacy issues against a passive “attacker” i.e. one that only listens to traffic, it can w/o any work discover email addresses, a) and b) require work by attacker to discover the email address (reverse/guess the HASH()) . There was pushback due to the privacy issue.

The difference between a) and b) is the lower casing. While this may be a win in some cases that is unproven, as we do not know if more people will know or guess the LHS they want to send to.
In addition the DNS contains a simple facility to equate names i.e. CNAME.

Olafur & Warren




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

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

--------------050504060608020509040309-- From nobody Wed Sep 2 07:30:21 2015 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 EB5E31AD079 for ; Wed, 2 Sep 2015 07:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] 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 ZcCccLbon7Y1 for ; Wed, 2 Sep 2015 07:30:14 -0700 (PDT) Received: from hoffman.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 7C0E71ACE2E for ; Wed, 2 Sep 2015 07:30:14 -0700 (PDT) Received: from [10.32.60.131] (142-254-17-100.dsl.dynamic.fusionbroadband.com [142.254.17.100]) (authenticated bits=0) by hoffman.proper.com (8.15.1/8.14.9) with ESMTPSA id t82EUBnA018627 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Sep 2015 07:30:13 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 142-254-17-100.dsl.dynamic.fusionbroadband.com [142.254.17.100] claimed to be [10.32.60.131] From: "Paul Hoffman" To: "Olafur Gudmundsson" Date: Wed, 02 Sep 2015 07:30:11 -0700 Message-ID: In-Reply-To: <8E7802A2-A9DC-464A-A427-DEA2C0EA5E65@ogud.com> References: <8E7802A2-A9DC-464A-A427-DEA2C0EA5E65@ogud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: dane WG list Subject: Re: [dane] E-mail Cert left hand side -- what the chairs think the consensus is X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 14:30:16 -0000 On 1 Sep 2015, at 11:44, Olafur Gudmundsson wrote: > Dear Colleagues > > We received some questions about the selection. > In the discussions on the different ways to represent the left hand > sides as DNS names there are number of ways the three ways we have > been discussing are: > a) HEX( SHA256( LHS) [:28])) i.e. 28 left most bytes of SHA256 hash > hexified > b) HEX( SHA256( str2lower(LHS))[:28]) i.e. the same as before but the > email name is lower cased before digesting, this will help mainly > email addresses written in Latin-1 > c) split_lables(HEX(LHS), 60)) i.e. encode the email as a HEX, > there are two drawbacks and one advantage see below > > a) and b) both are fixed length and fit in one label, c) on the other > hand may require multiple labels > c) in theory allows server that sees query may apply rules that allow > it to give out better answers > c) on the other hand also has privacy issues against a passive > “attacker” i.e. one that only listens to traffic, it can w/o any > work discover email addresses, a) and b) require work by attacker to > discover the email address (reverse/guess the HASH()) . There was > pushback due to the privacy issue. > > The difference between a) and b) is the lower casing. While this may > be a win in some cases that is unproven, as we do not know if more > people will know or guess the LHS they want to send to. > In addition the DNS contains a simple facility to equate names i.e. > CNAME. > > Olafur & Warren All of the options have operational plusses and minuses that we can't actually measure until after we deploy. (a) seems most in line with the mail standards we are using. That is a strong argument for (a). --Paul Hoffman From nobody Wed Sep 2 07:36:29 2015 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 A459F1B3AD5 for ; Wed, 2 Sep 2015 07:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 3TJWvLzjd4Kp for ; Wed, 2 Sep 2015 07:36:27 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DAF81B3AB7 for ; Wed, 2 Sep 2015 07:36:26 -0700 (PDT) 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.248.2; Wed, 2 Sep 2015 10:36:18 -0400 Received: from postmark.nist.gov (129.6.16.94) by WSXGHUB1.xchange.nist.gov (129.6.18.96) with Microsoft SMTP Server (TLS) id 8.3.406.0; Wed, 2 Sep 2015 10:36:23 -0400 Received: from [129.6.219.48] ([129.6.219.48]) by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id t82EaDmZ010042 for ; Wed, 2 Sep 2015 10:36:13 -0400 From: "Rose, Scott" To: dane WG list Date: Wed, 2 Sep 2015 10:36:13 -0400 Message-ID: <84D5D276-F699-4CDA-81D2-EA743E948406@nist.gov> In-Reply-To: References: <8E7802A2-A9DC-464A-A427-DEA2C0EA5E65@ogud.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.1r5084) X-NIST-MailScanner-Information: Archived-At: Subject: Re: [dane] E-mail Cert left hand side -- what the chairs think the consensus is X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 14:36:28 -0000 On 2 Sep 2015, at 10:30, Paul Hoffman wrote: > On 1 Sep 2015, at 11:44, Olafur Gudmundsson wrote: > >> Dear Colleagues >> >> We received some questions about the selection. >> In the discussions on the different ways to represent the left hand >> sides as DNS names there are number of ways the three ways we have >> been discussing are: >> a) HEX( SHA256( LHS) [:28])) i.e. 28 left most bytes of SHA256 hash >> hexified >> b) HEX( SHA256( str2lower(LHS))[:28]) i.e. the same as before but the >> email name is lower cased before digesting, this will help mainly >> email addresses written in Latin-1 >> >> >> The difference between a) and b) is the lower casing. While this may >> be a win in some cases that is unproven, as we do not know if more >> people will know or guess the LHS they want to send to. >> In addition the DNS contains a simple facility to equate names i.e. >> CNAME. >> >> Olafur & Warren > > All of the options have operational plusses and minuses that we can't > actually measure until after we deploy. (a) seems most in line with > the mail standards we are using. That is a strong argument for (a). > > --Paul Hoffman > Another ‘+1’ for (a). I kind of feel (b), may make discovery easier, but not sure and we will never know unless we deploy. (a) is simpler and after some deployment we may find out that cert discovery is not that difficult, not desired, or easily done another way. Scott > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane ================================== Scott Rose, NIST scottr@nist.gov ph: +1-301-975-8439 Google Voice: +1-571-249-3671 From nobody Wed Sep 2 07:42:00 2015 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 713EE1AC3C7 for ; Wed, 2 Sep 2015 07:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 8ShQlXUlG4cf for ; Wed, 2 Sep 2015 07:41:58 -0700 (PDT) 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 B375B1A8748 for ; Wed, 2 Sep 2015 07:41:57 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 9533B284D23; Wed, 2 Sep 2015 14:41:56 +0000 (UTC) Date: Wed, 2 Sep 2015 14:41:56 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150902144156.GH9021@mournblade.imrryr.org> References: <8E7802A2-A9DC-464A-A427-DEA2C0EA5E65@ogud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8E7802A2-A9DC-464A-A427-DEA2C0EA5E65@ogud.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] E-mail Cert left hand side -- what the chairs think the consensus is 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, 02 Sep 2015 14:41:59 -0000 On Tue, Sep 01, 2015 at 02:44:37PM -0400, Olafur Gudmundsson wrote: > We received some questions about the selection. > In the discussions on the different ways to represent the left hand sides as DNS names there are number of ways the three ways we have been discussing are: > a) HEX( SHA256( LHS) [:28])) i.e. 28 left most bytes of SHA256 hash hexified Once we're hashing, there's no point in making the hashes needlessly long, so if we're hashing "a" of course. > b) HEX( SHA256( str2lower(LHS))[:28]) i.e. the same as before but the > email name is lower cased before digesting, this will help mainly email > addresses written in Latin-1 No, this would be a second lookup, if the original input in "a" is not lower-case, and if MUAs choose to do that. > c) split_lables(HEX(LHS), 60)) i.e. encode the email as a HEX, there are two drawbacks and one advantage see below This is the "low-privacy" unhashed option, which supports hypothetical nameservers that can canonicalize the address and perform on-the-fly signing. If such servers are unlikely to materialize, then "a" is better. If, on the contrary, large providers are likely to implement such nameservers, then "c" is better. I thought that there was a recent rough consensus to hash, but if there's not, it is not clear that we have enought information to choose between "a" and "c". I'll be at M3AAWG35 in Atlanta in late October, and will be askin the large providers what they think about all this, and also Keith Moore's "addrquery" draft by comparison. Of course that's still 7 weeks away, and I may not get any feedback to report... -- Viktor. From nobody Wed Sep 2 12:18:20 2015 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 4A39E1B29FB for ; Wed, 2 Sep 2015 12:18:18 -0700 (PDT) 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 kxOL49ejR9A4 for ; Wed, 2 Sep 2015 12:18:16 -0700 (PDT) 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 341CD1B3EEC for ; Wed, 2 Sep 2015 12:18:15 -0700 (PDT) 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: content-transfer-encoding:message-id:references:to:x-mailer; bh=qbLolUTdSB4RoeP79DnJ8RDeudKNrf8NubpGhRCOq0A=; b=NonjeedLuZMvwIJNh57zzdWoYCkKFwOkZ/JRNClCJBvGtaHbfGSsvlyUnVmGDpCljAkUXAYTL3pRu n5SFyctkcv6FXUDqiQrUQEmhEeWZkZlTks2kyGEEkdeYGDgvtIqThUZNQYGfRPWoQ1Ud+O0IV+NoYI McLgyS6p20BFeVEs= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS for ; Wed, 2 Sep 2015 21:18:13 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Jakob Schlyter In-Reply-To: <20150902144156.GH9021@mournblade.imrryr.org> Date: Wed, 2 Sep 2015 21:18:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8E7802A2-A9DC-464A-A427-DEA2C0EA5E65@ogud.com> <20150902144156.GH9021@mournblade.imrryr.org> To: dane@ietf.org X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [dane] E-mail Cert left hand side -- what the chairs think the consensus is X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 19:18:18 -0000 > On 2 sep 2015, at 16:41, Viktor Dukhovni = wrote: >=20 > I thought that there was a recent rough consensus to hash, but if > there's not, it is not clear that we have enought information to > choose between "a" and "c". Consensus was declared by the chairs August 6th 2015 in [1] and both the = OpenPGP and S/MIME drafts has been updated since. I believe/hope = Olafur's revisit in this thread sought to clarify the pre-consensus = options, not to stir things up again. jakob [1] Message-ID: = From nobody Wed Sep 2 12:33:22 2015 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 129CE1B34A0 for ; Wed, 2 Sep 2015 12:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 x1ZrcQyces2b for ; Wed, 2 Sep 2015 12:33:18 -0700 (PDT) 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 CCE381B3389 for ; Wed, 2 Sep 2015 12:33:18 -0700 (PDT) Received: from smtp8.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp8.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 03736380360; Wed, 2 Sep 2015 15:33:17 -0400 (EDT) Received: by smtp8.relay.iad3a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id C9F273802B7; Wed, 2 Sep 2015 15:33:16 -0400 (EDT) X-Sender-Id: ogud@ogud.com Received: from [10.20.30.43] (pool-173-66-187-177.washdc.fios.verizon.net [173.66.187.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.4.2); Wed, 02 Sep 2015 19:33:17 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Olafur Gudmundsson In-Reply-To: Date: Wed, 2 Sep 2015 15:33:16 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8E7802A2-A9DC-464A-A427-DEA2C0EA5E65@ogud.com> <20150902144156.GH9021@mournblade.imrryr.org> To: Jakob Schlyter X-Mailer: Apple Mail (2.2104) Archived-At: Cc: dane@ietf.org Subject: Re: [dane] E-mail Cert left hand side -- what the chairs think the consensus is X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 19:33:21 -0000 > On Sep 2, 2015, at 3:18 PM, Jakob Schlyter wrote: >=20 >=20 >> On 2 sep 2015, at 16:41, Viktor Dukhovni = wrote: >>=20 >> I thought that there was a recent rough consensus to hash, but if >> there's not, it is not clear that we have enought information to >> choose between "a" and "c". >=20 > Consensus was declared by the chairs August 6th 2015 in [1] and both = the OpenPGP and S/MIME drafts has been updated since. I believe/hope = Olafur's revisit in this thread sought to clarify the pre-consensus = options, not to stir things up again. >=20 > jakob >=20 >=20 > [1] Message-ID: = To clarify=20 The chairs were trying to clarify the background of their consensus = call.=20 We are not trying to change consensus at this point in the working = group.=20 The OPENPGP document is in IETF last call, if the chairs made the wrong = call please put that comment to the IETF last call=20 thread.=20 Olafur From nobody Thu Sep 3 03:47:01 2015 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 3F5F91A8930 for ; Thu, 3 Sep 2015 03:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.261 X-Spam-Level: X-Spam-Status: No, score=-1.261 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, 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 Y6v3tyhmVkRk for ; Thu, 3 Sep 2015 03:46:57 -0700 (PDT) Received: from mout01.posteo.de (mout01.posteo.de [185.67.36.65]) (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 CA5981A1B71 for ; Thu, 3 Sep 2015 03:46:56 -0700 (PDT) Received: from dovecot03.posteo.de (dovecot03.posteo.de [172.16.0.13]) by mout01.posteo.de (Postfix) with ESMTPS id 6A1D920929 for ; Thu, 3 Sep 2015 12:46:53 +0200 (CEST) Received: from mail.posteo.de (localhost [127.0.0.1]) by dovecot03.posteo.de (Postfix) with ESMTPSA id 3n6JjS6s5Qz5vN7 for ; Thu, 3 Sep 2015 12:46:52 +0200 (CEST) Message-ID: <55E82512.2080507@posteo.de> Date: Thu, 03 Sep 2015 12:46:42 +0200 From: =?UTF-8?B?UGF0cmlrIEzDtmhy?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "" References: <55D857EA.80107@strotmann.de> <8321AB9D-ADCD-44BD-8A0F-1D6B5CF1971C@ogud.com> <55DC74A3.6060206@posteo.de> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040603050107000603070800" Archived-At: Subject: Re: [dane] DNS-Record type for SMIMEA 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, 03 Sep 2015 10:47:00 -0000 This is a cryptographically signed message in MIME format. --------------ms040603050107000603070800 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Warren, It would be great if you could do that, thanks Best regards Patrik Am 25.08.2015 um 23:40 schrieb Warren Kumari: >=20 >=20 > On Tuesday, August 25, 2015, Warren Kumari > wrote: >=20 > On Tue, Aug 25, 2015 at 1:31 PM, Olafur Gudmundsson > wrote: > > Nobody has submitted the request form. >=20 > ... also known as: If someone would like a DNS RR for SMIMEA, pleas= e > write up a short draft and we can consider it... >=20 >=20 >=20 > Doh, Jim just reminded me (offlist) that we don't even need a draft, > just fill in the template and mail it off. >=20 > Does anyone want to do that, or shall I? >=20 > W > =20 > Gorilla typing on a phone. >=20 >=20 > W >=20 >=20 > > > > Olafur > > > >> On Aug 25, 2015, at 9:58 AM, Patrik L=C3=B6hr > wrote: > >> > >> Hi Olafur and Carsten, > >> > >> it would be very useful for the tests to have the DNS record typ= e > >> number. Just for clarification: Did anyone request it? > >> > >> Thanks and best regards > >> Patrik > >> > >> Am 22.08.2015 um 15:47 schrieb Olafur Gudmundsson: > >>> Such a request has not been submitted, but it is good idea to > do it. > >>> Olafur (as chair) > >>> > >>> > >>>> On Aug 22, 2015, at 7:07 AM, Carsten Strotmann > > wrote: > >>>> > >>>> Hi, > >>>> > >>>> I remember there was a brief discussion during the DANE WG > session @ > >>>> IETF 93 about requesting a DNS record type number for SMIMEA > from IANA, > >>>> but I don't remember if there was a conclusion or an action > decided. I > >>>> cannot find it mentioned in the minutes. > >>>> > >>>> Does anyone know the status of this? > >>>> > >>>> Testing of SMIMEA will be be done with "normal but security > >>>> enthusiastic" users, it would be good to have a "well known" > DNS record > >>>> type number for SMIMEA instead of a private type number for > these tests. > >>>> > >>>> Best regards > >>>> > >>>> Carsten > >>>> > >>>> _______________________________________________ > >>>> dane mailing list > >>>> dane@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/dane > >>> > >>> _______________________________________________ > >>> dane mailing list > >>> dane@ietf.org > >>> https://www.ietf.org/mailman/listinfo/dane > >>> > >> > >> -- > >> Patrik L=C3=B6hr > >> > >> Posteo e.K. > >> Methfesselstr. 38 > >> 10965 Berlin > >> > >> tel. +49 30 85074618 > >> mail > > >> web > >> > >> USt-IdNr.: DE186713958 > >> Handelsregister: Berlin-Charlottenburg =C2=B7 HRA 47592 B > >> > >> _______________________________________________ > >> dane mailing list > >> dane@ietf.org > >> https://www.ietf.org/mailman/listinfo/dane > > > > _______________________________________________ > > dane mailing list > > dane@ietf.org > > https://www.ietf.org/mailman/listinfo/dane >=20 >=20 >=20 > -- > 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 express= ing > regret at having chosen those particular rabid weasels and that pai= r > of pants. > ---maf >=20 >=20 >=20 > --=20 > I don't think the execution is relevant when it was obviously a bad ide= a > 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 --=20 Patrik L=C3=B6hr Posteo e.K. Methfesselstr. 38 10965 Berlin tel. +49 30 85074618 mail web USt-IdNr.: DE186713958 Handelsregister: Berlin-Charlottenburg =C2=B7 HRA 47592 B --------------ms040603050107000603070800 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMbDCC BjAwggUYoAMCAQICAw2zGTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBMB4XDTE1MDQxNDEzNDUzNFoXDTE2MDQxNDEzMjcwNVowSDEfMB0GA1UE AwwWcGF0cmlrLmxvZWhyQHBvc3Rlby5kZTElMCMGCSqGSIb3DQEJARYWcGF0cmlrLmxvZWhy QHBvc3Rlby5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL4AsH4F/E5sb3xc 7+8rPfCcBHjuZk5LHc3JBJ48t2wgdIRliSkiK1VtIp5SHTMDBGKy7O6z1JQiB9mmJkQ2F6/T 62SsisSHctrCybHSufP8c4Vlr2vJScJIqzLVdg/WHo+UosmCwaZ8XCeLFr8g/lhNlZ5BKcb+ OUFYSeEfcb0AZc/gIhrQ6nnDARQVWpj3S2SXeGutkrrifjU1niqViMUxbE8TNitg2R3XoFJc a4e8rLACP0m6UoJ1JelHiaKdCYOCk+w8GGRrDTXecF1RzCU/9CIvdMzpurxSN6zfSvUg58dE xGv+4hFxydbR0+GN8+KWshFFumTa0xCIVfYzKskCAwEAAaOCAtwwggLYMAkGA1UdEwQCMAAw CwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU TvYppnwFOAQKigRZCBsApLfBzTAwHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw IQYDVR0RBBowGIEWcGF0cmlrLmxvZWhyQHBvc3Rlby5kZTCCAUwGA1UdIASCAUMwggE/MIIB OwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNv bS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9u IEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGlu ZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRD b20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBp biBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggr BgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3Vi L2NsYXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29t L2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAJnKy35YtxD0cETG0zygXYrCFQTX zjOgEPPunCIJw9O3BAgYS4z7NGdpJv2U1hru38QTdV8gtTv/BVwkyfnWQbCgopkVYvQ4hE94 3G9QIDtEffB9FhXj93BECa7Avqz+jvt1BAHG4IobsBfpJyOKtLFFQfJx7zM5QRWxnudIZVbj mKGlB6UfOOcglcfQyF28/JI4SY8qafWVxqGoL17rzuoqWq89dxWxljaCeUpLL9jp7txUMyJ1 9f8LTU+N27vAw1DShxljz4pIiH9wKzAEisZcFA5ocWvZVXxCKTKXAu7Vgyv07OtcUrhJaAmn 0feBFoyoDofwq7JKx2XDCkgjEPEwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQsw CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQ cmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6E RKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9 f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89l GxahNvuryGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZn a//jdiSyrrSMTGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGj ggGtMIIBqTAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Lt kpzg2ssBXHx+ljVO8tS4UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYI KwYBBQUHAQEEWjBYMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2Ew LQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8E VDBSMCegJaAjhiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0 dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1 NwECATBmMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRm MDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRm MA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkF gdtY1o95CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA 5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4q SfQoCRcLN5A0t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y 0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3 OHQgWI270g+5MYA8GfgI/EPT5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0Lw Zrp8MQ+Z77U1uL7TelWO5lApsbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0q ZW2Niy/QvVNKbb43A43ny076khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6Tcv GbjxkJh8BYtv9ePsXklAxtm8J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZj oEhdGwXV27ioRKbj/cIq7JRXun0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jGCA90wggPZ AgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAw2zGTAJBgUrDgMC GgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTA5 MDMxMDQ2NDJaMCMGCSqGSIb3DQEJBDEWBBRY4BUP9OBJUQy1DPOmB9M5oe4aPjBsBgkqhkiG 9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkr BgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQD Ey9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDDbMZ MIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgMNsxkwDQYJKoZIhvcNAQEBBQAEggEANLu3DmU5m9WZEQ5Y386UtkP6CvnlflqEX9LD 2PfqFxFsrqE90IJbPA49F/u8uPaIMBauf7CKirZCKVoJOEXfg3aCarAvgccmJaho21AKjdwF xZ1UN5Ez1yJDt1wWxXTmrIojl/wHORcJW+KkzVZ8rBIuTcqauHGq1gXBsMAopitOh0I1KELR QkOOOwKFGAQuIIo8IMe0TUklEzLOTT2OsOVooZbursP1kYIdu3TFWAzteXoKcbkUdfzSTLFW 1qZ4j0ghQ/sBe3BbWSLkl6U1oQX+JGxkCh0uW65BxfWGKdDMoScDAkVxwI49H9QcvPw54A0h 59Fhc2d7UqeNOYGAKAAAAAAAAA== --------------ms040603050107000603070800-- From nobody Thu Sep 3 06:25:59 2015 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 58EF41B2DAD for ; Thu, 3 Sep 2015 06:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 Oy3txGxHE4ub for ; Thu, 3 Sep 2015 06:25:55 -0700 (PDT) Received: from mail-oi0-f51.google.com (mail-oi0-f51.google.com [209.85.218.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9B5F1B2AAB for ; Thu, 3 Sep 2015 06:25:55 -0700 (PDT) Received: by oiww128 with SMTP id w128so27268332oiw.2 for ; Thu, 03 Sep 2015 06:25:55 -0700 (PDT) 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=5R0UXcd4HnYnbKOY8/1YjLFM/jDRFhQuHsDLYWI49tE=; b=Q9iQ4mcwxJhfVbciJVt9raSFJOLtw7tjBdSlpOII/ncsMgZpFLkbSQ21V58ljls/ny sL+I3z0GqoLlrrbveghy06cj1AwnPvbbXJsOJpZ4tlliQ2y1vioSrsjH9MQJKR/KtEQO uCzsmHQ2c7Cu+0RNZM58JCFxGXw4n5yJoaYZzquB36y/cho+NpEGeS85uiRMmT7D50A/ puai2PBWVEGll7dpW9guRGW4mp/M2/vEIoNZAUKVqB4mLtMKuxiW+emmjPqNV1FADWXY 7A13VkfnZ9H9NCqheOyijnkaL2474CjBpE6Mq9Ng4sLnvsXEl5gFH9ZTMHd5a6tEZxpK Ce2g== X-Gm-Message-State: ALoCoQkpHVZJEtPN+euqRghkoqhO8lHZO9MJ5czoOvQFUq9d3KDcyxcXMzsxJVpns7541l6Tm+kc MIME-Version: 1.0 X-Received: by 10.202.108.147 with SMTP id h141mr24837749oic.86.1441286754926; Thu, 03 Sep 2015 06:25:54 -0700 (PDT) Received: by 10.202.202.19 with HTTP; Thu, 3 Sep 2015 06:25:54 -0700 (PDT) In-Reply-To: <55E82512.2080507@posteo.de> References: <55D857EA.80107@strotmann.de> <8321AB9D-ADCD-44BD-8A0F-1D6B5CF1971C@ogud.com> <55DC74A3.6060206@posteo.de> <55E82512.2080507@posteo.de> Date: Thu, 3 Sep 2015 09:25:54 -0400 Message-ID: From: Warren Kumari To: =?UTF-8?B?UGF0cmlrIEzDtmhy?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "" Subject: Re: [dane] DNS-Record type for SMIMEA 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, 03 Sep 2015 13:25:57 -0000 I'd like to draw people's attention to draft-ietf-dane-smime , Section 5.1 ( http://tools.ietf.org/html/draft-ietf-dane-smime-09 - August 27 ) which contains a (completed) DNS RR template. Thanks to our authors, who don't suck... W On Thu, Sep 3, 2015 at 6:46 AM, Patrik L=C3=B6hr w= rote: > Hi Warren, > > It would be great if you could do that, thanks > > Best regards > Patrik > > Am 25.08.2015 um 23:40 schrieb Warren Kumari: >> >> >> On Tuesday, August 25, 2015, Warren Kumari > > wrote: >> >> On Tue, Aug 25, 2015 at 1:31 PM, Olafur Gudmundsson > > wrote: >> > Nobody has submitted the request form. >> >> ... also known as: If someone would like a DNS RR for SMIMEA, please >> write up a short draft and we can consider it... >> >> >> >> Doh, Jim just reminded me (offlist) that we don't even need a draft, >> just fill in the template and mail it off. >> >> Does anyone want to do that, or shall I? >> >> W >> >> Gorilla typing on a phone. >> >> >> W >> >> >> > >> > Olafur >> > >> >> On Aug 25, 2015, at 9:58 AM, Patrik L=C3=B6hr > > wrote: >> >> >> >> Hi Olafur and Carsten, >> >> >> >> it would be very useful for the tests to have the DNS record type >> >> number. Just for clarification: Did anyone request it? >> >> >> >> Thanks and best regards >> >> Patrik >> >> >> >> Am 22.08.2015 um 15:47 schrieb Olafur Gudmundsson: >> >>> Such a request has not been submitted, but it is good idea to >> do it. >> >>> Olafur (as chair) >> >>> >> >>> >> >>>> On Aug 22, 2015, at 7:07 AM, Carsten Strotmann >> > wrote: >> >>>> >> >>>> Hi, >> >>>> >> >>>> I remember there was a brief discussion during the DANE WG >> session @ >> >>>> IETF 93 about requesting a DNS record type number for SMIMEA >> from IANA, >> >>>> but I don't remember if there was a conclusion or an action >> decided. I >> >>>> cannot find it mentioned in the minutes. >> >>>> >> >>>> Does anyone know the status of this? >> >>>> >> >>>> Testing of SMIMEA will be be done with "normal but security >> >>>> enthusiastic" users, it would be good to have a "well known" >> DNS record >> >>>> type number for SMIMEA instead of a private type number for >> these tests. >> >>>> >> >>>> Best regards >> >>>> >> >>>> Carsten >> >>>> >> >>>> _______________________________________________ >> >>>> dane mailing list >> >>>> dane@ietf.org >> >>>> https://www.ietf.org/mailman/listinfo/dane >> >>> >> >>> _______________________________________________ >> >>> dane mailing list >> >>> dane@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/dane >> >>> >> >> >> >> -- >> >> Patrik L=C3=B6hr >> >> >> >> Posteo e.K. >> >> Methfesselstr. 38 >> >> 10965 Berlin >> >> >> >> tel. +49 30 85074618 >> >> mail > >> >> web >> >> >> >> USt-IdNr.: DE186713958 >> >> Handelsregister: Berlin-Charlottenburg =C2=B7 HRA 47592 B >> >> >> >> _______________________________________________ >> >> dane mailing list >> >> dane@ietf.org >> >> https://www.ietf.org/mailman/listinfo/dane >> > >> > _______________________________________________ >> > dane mailing list >> > dane@ietf.org >> > https://www.ietf.org/mailman/listinfo/dane >> >> >> >> -- >> 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 expressi= ng >> regret at having chosen those particular rabid weasels and that pair >> of pants. >> ---maf >> >> >> >> -- >> 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 > > -- > Patrik L=C3=B6hr > > Posteo e.K. > Methfesselstr. 38 > 10965 Berlin > > tel. +49 30 85074618 > mail > web > > USt-IdNr.: DE186713958 > Handelsregister: Berlin-Charlottenburg =C2=B7 HRA 47592 B > > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > --=20 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 Thu Sep 3 06:52:22 2015 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 8C97B1B3306 for ; Thu, 3 Sep 2015 06:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.261 X-Spam-Level: X-Spam-Status: No, score=-1.261 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, 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 xsD5Bfx4gvYb for ; Thu, 3 Sep 2015 06:52:18 -0700 (PDT) Received: from mout01.posteo.de (mout01.posteo.de [185.67.36.65]) (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 07EF21B3410 for ; Thu, 3 Sep 2015 06:52:17 -0700 (PDT) Received: from dovecot03.posteo.de (dovecot03.posteo.de [172.16.0.13]) by mout01.posteo.de (Postfix) with ESMTPS id 151C020897 for ; Thu, 3 Sep 2015 15:52:14 +0200 (CEST) Received: from mail.posteo.de (localhost [127.0.0.1]) by dovecot03.posteo.de (Postfix) with ESMTPSA id 3n6NqK6smSz5vN5; Thu, 3 Sep 2015 15:52:13 +0200 (CEST) Message-ID: <55E85082.1050008@posteo.de> Date: Thu, 03 Sep 2015 15:52:02 +0200 From: =?UTF-8?B?UGF0cmlrIEzDtmhy?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Warren Kumari References: <55D857EA.80107@strotmann.de> <8321AB9D-ADCD-44BD-8A0F-1D6B5CF1971C@ogud.com> <55DC74A3.6060206@posteo.de> <55E82512.2080507@posteo.de> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000603050603040901040901" Archived-At: Cc: "" Subject: Re: [dane] DNS-Record type for SMIMEA 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, 03 Sep 2015 13:52:21 -0000 This is a cryptographically signed message in MIME format. --------------ms000603050603040901040901 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Warren, great - didn't see this... Thanks, Patrik Am 03.09.2015 um 15:25 schrieb Warren Kumari: > I'd like to draw people's attention to draft-ietf-dane-smime , Section > 5.1 ( http://tools.ietf.org/html/draft-ietf-dane-smime-09 - August 27 > ) which contains a (completed) DNS RR template. >=20 > Thanks to our authors, who don't suck... >=20 > W >=20 > On Thu, Sep 3, 2015 at 6:46 AM, Patrik L=C3=B6hr wrote: >> Hi Warren, >> >> It would be great if you could do that, thanks >> >> Best regards >> Patrik >> >> Am 25.08.2015 um 23:40 schrieb Warren Kumari: >>> >>> >>> On Tuesday, August 25, 2015, Warren Kumari >> > wrote: >>> >>> On Tue, Aug 25, 2015 at 1:31 PM, Olafur Gudmundsson >> > wrote: >>> > Nobody has submitted the request form. >>> >>> ... also known as: If someone would like a DNS RR for SMIMEA, ple= ase >>> write up a short draft and we can consider it... >>> >>> >>> >>> Doh, Jim just reminded me (offlist) that we don't even need a draft, >>> just fill in the template and mail it off. >>> >>> Does anyone want to do that, or shall I? >>> >>> W >>> >>> Gorilla typing on a phone. >>> >>> >>> W >>> >>> >>> > >>> > Olafur >>> > >>> >> On Aug 25, 2015, at 9:58 AM, Patrik L=C3=B6hr >> > wrote: >>> >> >>> >> Hi Olafur and Carsten, >>> >> >>> >> it would be very useful for the tests to have the DNS record t= ype >>> >> number. Just for clarification: Did anyone request it? >>> >> >>> >> Thanks and best regards >>> >> Patrik >>> >> >>> >> Am 22.08.2015 um 15:47 schrieb Olafur Gudmundsson: >>> >>> Such a request has not been submitted, but it is good idea t= o >>> do it. >>> >>> Olafur (as chair) >>> >>> >>> >>> >>> >>>> On Aug 22, 2015, at 7:07 AM, Carsten Strotmann >>> > wrote: >>> >>>> >>> >>>> Hi, >>> >>>> >>> >>>> I remember there was a brief discussion during the DANE WG >>> session @ >>> >>>> IETF 93 about requesting a DNS record type number for SMIMEA= >>> from IANA, >>> >>>> but I don't remember if there was a conclusion or an action >>> decided. I >>> >>>> cannot find it mentioned in the minutes. >>> >>>> >>> >>>> Does anyone know the status of this? >>> >>>> >>> >>>> Testing of SMIMEA will be be done with "normal but security >>> >>>> enthusiastic" users, it would be good to have a "well known"= >>> DNS record >>> >>>> type number for SMIMEA instead of a private type number for >>> these tests. >>> >>>> >>> >>>> Best regards >>> >>>> >>> >>>> Carsten >>> >>>> >>> >>>> _______________________________________________ >>> >>>> dane mailing list >>> >>>> dane@ietf.org >>> >>>> https://www.ietf.org/mailman/listinfo/dane >>> >>> >>> >>> _______________________________________________ >>> >>> dane mailing list >>> >>> dane@ietf.org >>> >>> https://www.ietf.org/mailman/listinfo/dane >>> >>> >>> >> >>> >> -- >>> >> Patrik L=C3=B6hr >>> >> >>> >> Posteo e.K. >>> >> Methfesselstr. 38 >>> >> 10965 Berlin >>> >> >>> >> tel. +49 30 85074618 >>> >> mail > >>> >> web >>> >> >>> >> USt-IdNr.: DE186713958 >>> >> Handelsregister: Berlin-Charlottenburg =C2=B7 HRA 47592 B >>> >> >>> >> _______________________________________________ >>> >> dane mailing list >>> >> dane@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/dane >>> > >>> > _______________________________________________ >>> > dane mailing list >>> > dane@ietf.org >>> > https://www.ietf.org/mailman/listinfo/dane >>> >>> >>> >>> -- >>> I don't think the execution is relevant when it was obviously a b= ad >>> idea in the first place. >>> This is like putting rabid weasels in your pants, and later expre= ssing >>> regret at having chosen those particular rabid weasels and that p= air >>> of pants. >>> ---maf >>> >>> >>> >>> -- >>> I don't think the execution is relevant when it was obviously a bad i= dea >>> in the first place. >>> This is like putting rabid weasels in your pants, and later expressin= g >>> regret at having chosen those particular rabid weasels and that pair = of >>> pants. >>> ---maf >> >> -- >> Patrik L=C3=B6hr >> >> Posteo e.K. >> Methfesselstr. 38 >> 10965 Berlin >> >> tel. +49 30 85074618 >> mail >> web >> >> USt-IdNr.: DE186713958 >> Handelsregister: Berlin-Charlottenburg =C2=B7 HRA 47592 B >> >> >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >> >=20 >=20 >=20 --=20 Patrik L=C3=B6hr Posteo e.K. Methfesselstr. 38 10965 Berlin tel. +49 30 85074618 mail web USt-IdNr.: DE186713958 Handelsregister: Berlin-Charlottenburg =C2=B7 HRA 47592 B --------------ms000603050603040901040901 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMbDCC BjAwggUYoAMCAQICAw2zGTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBMB4XDTE1MDQxNDEzNDUzNFoXDTE2MDQxNDEzMjcwNVowSDEfMB0GA1UE AwwWcGF0cmlrLmxvZWhyQHBvc3Rlby5kZTElMCMGCSqGSIb3DQEJARYWcGF0cmlrLmxvZWhy QHBvc3Rlby5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL4AsH4F/E5sb3xc 7+8rPfCcBHjuZk5LHc3JBJ48t2wgdIRliSkiK1VtIp5SHTMDBGKy7O6z1JQiB9mmJkQ2F6/T 62SsisSHctrCybHSufP8c4Vlr2vJScJIqzLVdg/WHo+UosmCwaZ8XCeLFr8g/lhNlZ5BKcb+ OUFYSeEfcb0AZc/gIhrQ6nnDARQVWpj3S2SXeGutkrrifjU1niqViMUxbE8TNitg2R3XoFJc a4e8rLACP0m6UoJ1JelHiaKdCYOCk+w8GGRrDTXecF1RzCU/9CIvdMzpurxSN6zfSvUg58dE xGv+4hFxydbR0+GN8+KWshFFumTa0xCIVfYzKskCAwEAAaOCAtwwggLYMAkGA1UdEwQCMAAw CwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU TvYppnwFOAQKigRZCBsApLfBzTAwHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw IQYDVR0RBBowGIEWcGF0cmlrLmxvZWhyQHBvc3Rlby5kZTCCAUwGA1UdIASCAUMwggE/MIIB OwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNv bS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9u IEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGlu ZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRD b20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBp biBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggr BgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3Vi L2NsYXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29t L2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAJnKy35YtxD0cETG0zygXYrCFQTX zjOgEPPunCIJw9O3BAgYS4z7NGdpJv2U1hru38QTdV8gtTv/BVwkyfnWQbCgopkVYvQ4hE94 3G9QIDtEffB9FhXj93BECa7Avqz+jvt1BAHG4IobsBfpJyOKtLFFQfJx7zM5QRWxnudIZVbj mKGlB6UfOOcglcfQyF28/JI4SY8qafWVxqGoL17rzuoqWq89dxWxljaCeUpLL9jp7txUMyJ1 9f8LTU+N27vAw1DShxljz4pIiH9wKzAEisZcFA5ocWvZVXxCKTKXAu7Vgyv07OtcUrhJaAmn 0feBFoyoDofwq7JKx2XDCkgjEPEwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQsw CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQ cmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6E RKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9 f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89l GxahNvuryGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZn a//jdiSyrrSMTGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGj ggGtMIIBqTAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Lt kpzg2ssBXHx+ljVO8tS4UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYI KwYBBQUHAQEEWjBYMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2Ew LQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8E VDBSMCegJaAjhiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0 dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1 NwECATBmMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRm MDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRm MA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkF gdtY1o95CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA 5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4q SfQoCRcLN5A0t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y 0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3 OHQgWI270g+5MYA8GfgI/EPT5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0Lw Zrp8MQ+Z77U1uL7TelWO5lApsbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0q ZW2Niy/QvVNKbb43A43ny076khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6Tcv GbjxkJh8BYtv9ePsXklAxtm8J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZj oEhdGwXV27ioRKbj/cIq7JRXun0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jGCA90wggPZ AgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAw2zGTAJBgUrDgMC GgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTA5 MDMxMzUyMDJaMCMGCSqGSIb3DQEJBDEWBBSSrprPJoSPO3V1DoYhqQFdp1WBCjBsBgkqhkiG 9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkr BgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQD Ey9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDDbMZ MIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgMNsxkwDQYJKoZIhvcNAQEBBQAEggEAIRzV0YOETktxNAnw47dDcHSV+FwHPS3lb4Gy /Q2k5/qOaLrGjCDB4MBK6GP9+NXnaECGQHsCLgQYNZGW4pzoeRIYWfu2tkXsZ/gqsrhCumNh 6fQKiVcJYycC8coDzHH5csLe8ckLeu1BhJNhPT6IamEidoRqyQM0PTwJ2sgZkasK40k73UBR lJdoKPnxb4CK6cWx+c7q1/WeD8UZmY/8DGlsL0fYbJdxhl4hpLmwfAqDBnQ+RtVgxeAbPMCh wNwcPolMrRinGuy17m8dJK8NJ3svXeE2WkEngscMsl5v9HIZaRt5DcDpfc8LMbSXkyQy2FyG RvVFd7l9DbF2UqeU5AAAAAAAAA== --------------ms000603050603040901040901-- From nobody Thu Sep 3 09:21:49 2015 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 035821B3140 for ; Thu, 3 Sep 2015 09:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.047 X-Spam-Level: X-Spam-Status: No, score=-1.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3B3PxCqHfBBt for ; Thu, 3 Sep 2015 09:21:44 -0700 (PDT) Received: from hoffman.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 6F1671AC3EF for ; Thu, 3 Sep 2015 09:21:44 -0700 (PDT) Received: from [10.32.60.122] ([216.9.110.4]) (authenticated bits=0) by hoffman.proper.com (8.15.1/8.14.9) with ESMTPSA id t83GLgEI026892 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Sep 2015 09:21:43 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host [216.9.110.4] claimed to be [10.32.60.122] From: "Paul Hoffman" To: "Patrik =?utf-8?q?L=C3=B6hr?=" Date: Thu, 03 Sep 2015 09:21:42 -0700 Message-ID: <22DCFC67-C65D-45E1-A5EB-EC8BD4F887B9@vpnc.org> In-Reply-To: <55E85082.1050008@posteo.de> References: <55D857EA.80107@strotmann.de> <8321AB9D-ADCD-44BD-8A0F-1D6B5CF1971C@ogud.com> <55DC74A3.6060206@posteo.de> <55E82512.2080507@posteo.de> <55E85082.1050008@posteo.de> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: "" Subject: Re: [dane] DNS-Record type for SMIMEA 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, 03 Sep 2015 16:21:45 -0000 Also, we (belatedly) turned in the application to the Right Place this morning. Sorry about the the delay... --Paul Hoffman From nobody Thu Sep 3 12:50:05 2015 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 08D571B3C57 for ; Thu, 3 Sep 2015 12:50:04 -0700 (PDT) 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_HELO_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 YvKwM8xqwm7O for ; Thu, 3 Sep 2015 12:50:02 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D51FB1B3CA1 for ; Thu, 3 Sep 2015 12:50:01 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 510ECC0B2B59 for ; Thu, 3 Sep 2015 19:50:01 +0000 (UTC) Received: from pspacek.brq.redhat.com (ovpn-204-26.brq.redhat.com [10.40.204.26]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t83JnxQ6028505 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 3 Sep 2015 15:50:00 -0400 To: dane@ietf.org References: <20150828151107.2592.98917.idtracker@ietfa.amsl.com> From: Petr Spacek X-Enigmail-Draft-Status: N1110 Organization: Red Hat Message-ID: <55E8A468.40006@redhat.com> Date: Thu, 3 Sep 2015 21:50:00 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150828151107.2592.98917.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: Subject: Re: [dane] Last Call: (Using DANE to Associate OpenPGP public keys with email addresses) to Proposed Standard 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, 03 Sep 2015 19:50:04 -0000 Hello, as far as I can tell people favor various LHS-hashing variants for privacy reasons. Assuming that this observation is correct, I consider current hashing scheme totally insufficient - it does not protect anyone's privacy against even against moderately-funded attackers. We should do better (not only to please Snowden :-) I very much like the generic idea of salting described in variant a) here: https://mailarchive.ietf.org/arch/msg/dane/LuC7BYtd6zVEWJF0s4cnmBLL1rU (I'm not so certain about "rulez", but that is a separate discussion. Do not conflate these two discussions.) Personally I would store salt+iteration parameters in "_openpgpkey." so the whole tree can be shared/DNAMEd at will. Yes, this requires additional lookup. Still, I can see important benefits which in my eyes outweigh the disadvantage: - The additional "salt" lookup works as privacy guard for domains which did not deploy _openpgpkey at all. If the client does not find "salt" record then no lookups for names derived from LHS should be made. This effectively prevents leaks for domains which did not deploy _openpgpkey. (Domain name leaks anyway because of MX lookups.) - The "salt" record for big mail providers will be often in a nearby cache so the additional time-overhead for big mail providers will be negligible. And of course, TTL for this kind of record can be pretty long. - Salt/iteration count can be increased over time so we can keep raising the bar to make it costly to revert the hashing as computing power gets cheaper. Really, I think that we should rethink the hashing if we are serious about privacy. Petr Spacek On 28.8.2015 17:11, The IESG wrote: > The IESG has received a request from the DNS-based Authentication of > Named Entities WG (dane) to consider the following document: > - 'Using DANE to Associate OpenPGP public keys with email addresses' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2015-09-11. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. From nobody Thu Sep 3 13:26:47 2015 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 0496E1B305B for ; Thu, 3 Sep 2015 13:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.61 X-Spam-Level: X-Spam-Status: No, score=-0.61 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 Oep34QnBhNnE for ; Thu, 3 Sep 2015 13:26:43 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B69361A039F for ; Thu, 3 Sep 2015 13:26:42 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3n6YZT0LrCz3Ht; Thu, 3 Sep 2015 22:26:41 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=O389aT/a X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 42n6tcyYyMi2; Thu, 3 Sep 2015 22:26:39 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 3 Sep 2015 22:26:39 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B4F0B80030; Thu, 3 Sep 2015 16:26:38 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1441311998; bh=U0PD5NIzcoPH/yghpZdcWh+OXzhPf55H9U5VjCtZpWo=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=O389aT/a8arBA6u/NV1lbuEGSRXitYuDuSHmq7CmsJ1h9j6N46Hw1hJzhZni3Uc1e ipqRWgb14F7rmyCDLgGhXw6VsMvaykrBpH4vUTG+xUtmJWIt1xEeL1Q3SSG8p8bDIr FQkrrMD1J4qL5cYxP+tgX0He+v2Z+H6PNc1++gdE= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.2/8.15.2/Submit) with ESMTP id t83KQcMB002123; Thu, 3 Sep 2015 16:26:38 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Thu, 3 Sep 2015 16:26:38 -0400 (EDT) From: Paul Wouters To: Petr Spacek In-Reply-To: <55E8A468.40006@redhat.com> Message-ID: References: <20150828151107.2592.98917.idtracker@ietfa.amsl.com> <55E8A468.40006@redhat.com> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Last Call: (Using DANE to Associate OpenPGP public keys with email addresses) to Proposed Standard 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, 03 Sep 2015 20:26:45 -0000 On Thu, 3 Sep 2015, Petr Spacek wrote: note if you meant this as a comment for the IETF LC, you should use that threat over at ietf@ietf.org and not this one..... > as far as I can tell people favor various LHS-hashing variants for privacy > reasons. Assuming that this observation is correct, I consider current hashing > scheme totally insufficient - it does not protect anyone's privacy against > even against moderately-funded attackers. We should do better (not only to > please Snowden :-) I don't think anything helps against moderately-funded attackers. How long does it take to build a dictionary of common email names/varients ? As the nsec3 cracker shows, it's going to be a simple offline attack to generate the qname's, then you go online to fire them off. > Personally I would store salt+iteration parameters in "_openpgpkey." > so the whole tree can be shared/DNAMEd at will. That would cause an additional administrative burden though. Now one cannot just "add OPENPGPKEY" record to the zone. Now you have to query for the salt before you can generate and then add the OPENPGPKEY record to the zone. And whoever updates the salt record now needs to ensure to update all existing OPENPGPKEY records. so in theory you would have to: 1) query the salt 2) generate the openpgpkey record 3) give it to whatever human/webui adds it to the zone 4) requery the salt to ensure it hadn't changed 5) keep querying the salt to see if you need to submit an updated record That's a lot of overkill and someone (google) can still simply lookup the salt and run it over strings like "paul" and compare it with the DNS query log. > Yes, this requires additional lookup. Still, I can see important benefits > which in my eyes outweigh the disadvantage: > > - The additional "salt" lookup works as privacy guard for domains which did > not deploy _openpgpkey at all. If the client does not find "salt" record then > no lookups for names derived from LHS should be made. This effectively > prevents leaks for domains which did not deploy _openpgpkey. (Domain name > leaks anyway because of MX lookups.) That's even more state. And you still have the case where the salt record is there but no OPENPGPKEY record for paul is there, and you end up possibly requerying for paul many times anyway. That is, it does not really solve the problem. Only a small part of it. > - Salt/iteration count can be increased over time so we can keep raising the > bar to make it costly to revert the hashing as computing power gets cheaper. when does "raising the bar" become "denial of service"? Especially when the nation states have more CPU power than we do :P > Really, I think that we should rethink the hashing if we are serious about > privacy. The real answer here is DPRIVE plus using a trusted DNS resolver. Which solves query privacy in general and is not specific to one record type. Paul From nobody Thu Sep 10 09:31:59 2015 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 2801E1B3D29 for ; Thu, 10 Sep 2015 09:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.187 X-Spam-Level: X-Spam-Status: No, score=0.187 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, 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 kozDQsXH-SbU for ; Thu, 10 Sep 2015 09:31:55 -0700 (PDT) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC4FA1B3CD3 for ; Thu, 10 Sep 2015 09:31:54 -0700 (PDT) Received: from srv4.stroeder.local (unknown [10.1.1.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.stroeder.local", Issuer "stroeder.com Server CA no. 2009-07" (verified OK)) by srv1.stroeder.com (Postfix) with ESMTPS id E904D1CF28 for ; Thu, 10 Sep 2015 16:31:51 +0000 (UTC) Received: from nb2.stroeder.local (nb2.stroeder.local [10.1.1.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by srv4.stroeder.local (Postfix) with ESMTPS id 875BB1CE87 for ; Thu, 10 Sep 2015 16:31:50 +0000 (UTC) To: dane@ietf.org References: <20150824031926.GF9021@mournblade.imrryr.org> From: =?UTF-8?Q?Michael_Str=c3=b6der?= X-Enigmail-Draft-Status: N1110 Message-ID: <55F1B075.5060809@stroeder.com> Date: Thu, 10 Sep 2015 18:31:49 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 SeaMonkey/2.35 MIME-Version: 1.0 In-Reply-To: <20150824031926.GF9021@mournblade.imrryr.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040304020509050601050904" Archived-At: Subject: Re: [dane] DANE for MX host via insecure MX RR? 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, 10 Sep 2015 16:31:57 -0000 This is a cryptographically signed message in MIME format. --------------ms040304020509050601050904 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Viktor Dukhovni wrote: > On Sun, Aug 23, 2015 at 07:29:50PM +0200, Patrik F?ltstr?m wrote: >=20 >> If not, we will get absolutely zero deployment of DANE with SMTP as we= >> will never get 100% DNSSEC deployment. >=20 > We already have non-zero deployment, in fact ~2000 domains now, and > soon gmx.de and web.de as announced last week. >=20 > I think this thread needs to end, or else needs a more relevant > (to this WG) reboot. >=20 > If you want to propose an update that requires SMTP clients to > employ DANE TLSA verification of MX hosts in signed zones even when > the MX RRset was not "secure", read the previous discussion of this > question in the list archives (yes, it has come up before) and make > a clear-cut proposal with as solid a rationale as you can. =20 >=20 > I am not sure this can get enough support to reach "rough consensus", > but I'm open to the possibility. Without a signed MX there's no cryptographically secured binding between = the recipient domain (right address part) and the public key used for TLS aut= hc. So I'm strictly against this possibility and the developers of a MTA I sp= oke with today are also strongly against this. @Patrik: Deploying DNSSEC/DANE at large scale is not an easy job. If you = drop the requirement for signed MX RRs DANE would not be worth the effort to b= e implemented. Ciao, Michael. --------------ms040304020509050601050904 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DIEwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBkUwggUtoAMCAQICAwtNUDANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTE0MDkyMzIw NDc1NVoXDTE1MDkyNDIyMDUxOFowXzEZMBcGA1UEDRMQNk0yWTdpOXpEdGU2alV3MDEdMBsG A1UEAwwUbWljaGFlbEBzdHJvZWRlci5jb20xIzAhBgkqhkiG9w0BCQEWFG1pY2hhZWxAc3Ry b2VkZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAynIH09fU597v4fg4 uwqFJDPUxQHV9qxrfM/c3veStPyYl0JorqKHrD+hfCNZ+Toy65NN9f9vO26WnnLoDF+FE2Dk Qi61iTgK5jZTr5dJG1WQkk698UNWO87lUWBRYYiUM7wC3ek2E0rzR99qIxE4dG9wws19F3KK JvNN8tMTyoPw5Vkw4qx2SW54WEBMx7oCXBIZPPDD8ovled6vDVweVSaYXFUbkxbKJR87Msih 34Ba+cM5SAHQNQ11jaSJjFeqbQnXjf0nESnvo0XIckc9w240w3jcgu6b5SIQBI2vv5TaIv7v KqNk0o+cGc9NnCw5/xD/OAB9Aj/qDca6NheHCQIDAQABo4IC2jCCAtYwCQYDVR0TBAIwADAL BgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTj z1BhELZO3zEJfmZQ4I+c6NCXIjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAf BgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYL KwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9w b2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0 byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20g Q0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAt MCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEF BQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2Ns YXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2Nl cnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAAfByd9CEZ5pYuRa3XuE5xeJoIpDol22 A1mIGuRqxaBFIummmDoYr/tVgFod/3evQJO+ad8T5wpooY422HkHN4a1UI7ujCKcU/PrQSxm v28AAsl4Fo/InY1nSFjMy8Ywj3EG+Edj1ZpCkzTRNGZjBa6Uj7UY7UW71kYcSdCBe8vc9Zi3 6OnHGkXROWIii3wBKLDEZqxknw0Cj9TTy5lyllYzyHku4aXLDPhiYrTzhWiwgYmweaLvW/yq YVsHRpW8udzqOr6xvUVcuRmfMTENM7RSlRZVw2+5+I+zn7jqOrrULO1FP7Lo5cPilsMpSMOw oJnPLQgNZvXOPFO6VaDCOboxggPtMIID6QIBATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBAgMLTVAwDQYJYIZIAWUDBAIBBQCgggIpMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDkxMDE2MzE0OVowLwYJKoZIhvcNAQkEMSIE INo6JVc+zRit6CH4Thnv5KDV9hFiGiXbYGX4ZOil3o9AMGwGCSqGSIb3DQEJDzFfMF0wCwYJ YIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaUGCSsGAQQBgjcQBDGBlzCB lDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNl Y3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMLTVAwgacGCyqGSIb3DQEJ EAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3Rh cnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwtNUDANBgkq hkiG9w0BAQEFAASCAQBiPnEffOUWa1+iQhiI26dNeJLQFkt/9Y9CLn2tdUgZ4rHK8NH76/lY AcxDzHig04RtsGaJ0+UYMmFC+dM3twA7KunVezN++K7FltNTpwXF+rHCQMMgOVS/Gku2Gv8I K2pq5ZPIIAEPI46m/fi1vOyoucCd3vUwFCA/bcmSMoMYXUnE/ERAA2bkC+m1UuFLqvV8uIaI 9W77jLT/xO6FpPVWDL86w+UIAvjKMjttc3B+Wz5d/UeEnGVhakoRd2OKIR9Td/qLm/12OLqh wyvMqDbdVsBGyKLukk2MSN4aaG0oVXyyXjyu8fAu9AZijWw19mq7VXQY9o42+KMVZmBF3q4E AAAAAAAA --------------ms040304020509050601050904-- From nobody Thu Sep 10 09:53:41 2015 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 83F821A0383 for ; Thu, 10 Sep 2015 09:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 AF0toLHBhVzU for ; Thu, 10 Sep 2015 09:53:38 -0700 (PDT) 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 436A11B37A9 for ; Thu, 10 Sep 2015 09:53:38 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 97FC9284B70; Thu, 10 Sep 2015 16:53:37 +0000 (UTC) Date: Thu, 10 Sep 2015 16:53:37 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150910165337.GZ21942@mournblade.imrryr.org> References: <20150824031926.GF9021@mournblade.imrryr.org> <55F1B075.5060809@stroeder.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <55F1B075.5060809@stroeder.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [dane] DANE for MX host via insecure MX RR? 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, 10 Sep 2015 16:53:40 -0000 On Thu, Sep 10, 2015 at 06:31:49PM +0200, Michael Strder wrote: > > If you want to propose an update that requires SMTP clients to > > employ DANE TLSA verification of MX hosts in signed zones even when > > the MX RRset was not "secure", read the previous discussion of this > > question in the list archives (yes, it has come up before) and make > > a clear-cut proposal with as solid a rationale as you can. > > > > I am not sure this can get enough support to reach "rough consensus", > > but I'm open to the possibility. > > Without a signed MX there's no cryptographically secured binding between the > recipient domain (right address part) and the public key used for TLS authc. > > So I'm strictly against this possibility and the developers of a MTA I spoke > with today are also strongly against this. > > @Patrik: Deploying DNSSEC/DANE at large scale is not an easy job. If you drop > the requirement for signed MX RRs DANE would not be worth the effort to be > implemented. Note, the hypothetical proposal would not weaken DANE in any way, nor would it "drop" the requirement to pay attention to the security status of the MX RRset, in particular "bogus" replies or other DNS errors in MX resolution would still result in deferral of mail. All that would hypothetically happen, is that even when the MX RRset is "insecure" (verifiably from an unsigned zone) but the target MX host is in a signed zone and has "secure" TLSA records, DANE authentication might be "SHOULD" or "MUST", rather than the current "MAY". https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-19#section-2.2.1 Since the protocol in this memo is an "opportunistic security" protocol ([RFC7435]) the SMTP client MAY elect to use DANE TLS (as described in Section 2.2.2 below) even with MX hosts obtained via an "insecure" MX RRSet. For example, when a hosting provider has a signed DNS zone and publishes TLSA records for its SMTP servers, hosted domains that are not signed may still benefit from the provider's TLSA records. Deliveries via the provider's SMTP servers will not be subject to active attacks when sending SMTP clients elect to make use of the provider's TLSA records (active attacks that tamper with the "insecure" MX RRSet are of course still possible in this case). I think the current "MAY" is sufficient for now, but if that proves to be a valuable feature of the protocol, an a short update BCP RFC upgrading the "MAY" to a "SHOULD" or "MUST" might be possible in the future. So long as such sessions are not reported as secure, and are not accepted when DANE authentication is mandatory (e.g. Postfix "dane-only" TLS security level), the proposal does not in any way reduce the security of DANE as specified. The main risk is with reliability. Perhaps only those customers of a service provider that operate DNSSEC signed domains are willing to accept service availability risk in case of DANE authentication failure, and the customers with unsigned zones want service availability above all else. If the proposal is formalized, then all customer domains suffer if the TLSA records are ever wrong, even those whose domains are unsigned. Of course service outages happen for operational reasons beyond incorrect TLSA record updates (or failure to update). And the sending domains that elect the "MAY" policy will defer email even for the unsigned domains. So the proposal is not obviously damaging, just possibly premature. We'll know more once there is more deployment and people either learn (or don't learn) to operate their TLSA records correctly. -- Viktor. From nobody Thu Sep 10 10:35:33 2015 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 C12C71B31C7; Thu, 10 Sep 2015 10:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 7-cEtFmyH9aJ; Thu, 10 Sep 2015 10:35:29 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 371201A8868; Thu, 10 Sep 2015 10:35:28 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t8AHZKk5021813 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 10 Sep 2015 19:35:21 +0200 From: Simon Josefsson To: ietf@ietf.org, dane@ietf.org References: <20150828151107.2592.98917.idtracker@ietfa.amsl.com> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:150910:dane@ietf.org::n2ueiiX3YsDALlSG:0rNm X-Hashcash: 1:22:150910:iesg-secretary@ietf.org::26tGmNfXoVS/gJNN:1Yf4 X-Hashcash: 1:22:150910:ietf@ietf.org::2xrpAFq3/88jA+DN:LMED X-Hashcash: 1:22:150910:ietf-announce@ietf.org::/CtOMBFltdc2YtH1:fK5h Date: Thu, 10 Sep 2015 19:35:19 +0200 In-Reply-To: <20150828151107.2592.98917.idtracker@ietfa.amsl.com> (The IESG's message of "Fri, 28 Aug 2015 08:11:07 -0700") Message-ID: <87613iyy7c.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Subject: Re: [dane] Last Call: (Using DANE to Associate OpenPGP public keys with email addresses) to Proposed Standard 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, 10 Sep 2015 17:35:31 -0000 --=-=-= Content-Type: text/plain I believe it would be a mistake to publish this document without having it include a discussion of its relationship to RFC 4648. As far as I can tell, the CERT record defined in RFC 4648 solves roughly the same problem as OPENPGPKEY and CERT is already deployed with support in (for example) GnuPG. I believe the community would benefit from sorting out the relationship before publication, not after, when we would have two RFCs describing solutions for what appears to be the same problem. /Simon The IESG writes: > The IESG has received a request from the DNS-based Authentication of > Named Entities WG (dane) to consider the following document: > - 'Using DANE to Associate OpenPGP public keys with email addresses' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2015-09-11. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > OpenPGP is a message format for email (and file) encryption that > lacks a standardized lookup mechanism to securely obtain OpenPGP > public keys. This document specifies a method for publishing and > locating OpenPGP public keys in DNS for a specific email address > using a new OPENPGPKEY DNS Resource Record. Security is provided via > DNSSEC. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/ > > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJV8b9XAAoJEIYLf7sy+BGdFooIAKJUI0UnmpOc20kood/6zLdp pJUd7z5bmSunPo0YoU73u8AETVxcqtYLi7LZkALUnOEB/ssQ3+xb8lWO9adA6+Y0 lcC0HdCwguXykAGTtgyUAsL8h7CwexxPvPXl2CBY/9wlquyBTEeBlLgJxbitcvir F6Y5fLo338T41W1Ib6iWgqu8wv3g6fkctCQD28TgtcWlkK8Xgno2hbmfYc5d39z+ n5yt887zeJL7DN2YxraZfinXbngt/5hAaAYd2Qzlhgm6A56iATFupNcfM09jJN6j jRi3HRzqkBcjKziLL3k7n3GexOR9Ow8TizVJSizp/DsfMh5E6GokMWnGmMvft1I= =6yYW -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Sep 10 10:40:40 2015 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 749881B3431; Thu, 10 Sep 2015 10:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 4PbVJ98S4X0A; Thu, 10 Sep 2015 10:40:37 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 16A5D1B33B0; Thu, 10 Sep 2015 10:40:36 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t8AHeMl2022314 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 10 Sep 2015 19:40:23 +0200 X-Hashcash: 1:22:150910:ietf@ietf.org::0Z/Kg4cictr7yMho:3shd X-Hashcash: 1:22:150910:dane@ietf.org::BjUhACxT8yI3BOR+:8CoK From: Simon Josefsson To: ietf@ietf.org, dane@ietf.org References: <20150828151107.2592.98917.idtracker@ietfa.amsl.com> <87613iyy7c.fsf@latte.josefsson.org> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:150910:ietf-egrivxuawey@public.gmane.org::7hJdJn/Id3rHhZgA:CSrl X-Hashcash: 1:22:150910:simon-rtwakxxyig6ei8dpzvb4nw@public.gmane.org::c/d1AEALX1Od3HDW:O+Vs X-Hashcash: 1:22:150910:dane-egrivxuawey@public.gmane.org::aOpeHKpnmDsZH0Hz:R4Ue Date: Thu, 10 Sep 2015 19:40:21 +0200 In-Reply-To: <87613iyy7c.fsf@latte.josefsson.org> (Simon Josefsson's message of "Thu, 10 Sep 2015 19:35:19 +0200") Message-ID: <87r3m6xjei.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Subject: Re: [dane] Last Call: (Using DANE to Associate OpenPGP public keys with email addresses) to Proposed Standard 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, 10 Sep 2015 17:40:38 -0000 --=-=-= Content-Type: text/plain Sorry -- I meant RFC 4398 and not RFC 4648! /Simon Simon Josefsson writes: > I believe it would be a mistake to publish this document without having > it include a discussion of its relationship to RFC 4648. As far as I > can tell, the CERT record defined in RFC 4648 solves roughly the same > problem as OPENPGPKEY and CERT is already deployed with support in (for > example) GnuPG. I believe the community would benefit from sorting out > the relationship before publication, not after, when we would have two > RFCs describing solutions for what appears to be the same problem. > > /Simon > > The IESG writes: > >> The IESG has received a request from the DNS-based Authentication of >> Named Entities WG (dane) to consider the following document: >> - 'Using DANE to Associate OpenPGP public keys with email addresses' >> as Proposed Standard >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to the >> ietf-EgrivxUAwEY@public.gmane.org mailing lists by 2015-09-11. Exceptionally, comments may be >> sent to iesg-EgrivxUAwEY@public.gmane.org instead. In either case, please retain the >> beginning of the Subject line to allow automated sorting. >> >> Abstract >> >> >> OpenPGP is a message format for email (and file) encryption that >> lacks a standardized lookup mechanism to securely obtain OpenPGP >> public keys. This document specifies a method for publishing and >> locating OpenPGP public keys in DNS for a specific email address >> using a new OPENPGPKEY DNS Resource Record. Security is provided via >> DNSSEC. >> >> >> >> >> The file can be obtained via >> https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/ >> >> IESG discussion can be tracked via >> https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/ballot/ >> >> >> No IPR declarations have been submitted directly on this I-D. >> >> >> > > _______________________________________________ > dane mailing list > dane-EgrivxUAwEY@public.gmane.org > https://www.ietf.org/mailman/listinfo/dane > --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJV8cCFAAoJEIYLf7sy+BGdd0AH/0/HqPDNRKiODdqQEmW1wa6u n8ideWaSbBjXycEI/Bakvq7Wu2oFz/+q2aa3WkQBZCvHE3jDnB85bRrJEsPbptJZ vJVyksBxHujSuOZI1Wz8BN4/iuUnVryw+8ZL6WTal1UH2E8xJ9nnzYpQbqkbu+PX OE3U/8RfTU9zfX2fpqlnQTFYjTsrBO3jNIZVo/L+BDGfx9XJxDsaxFl3YXIm90eH 1r4dEWpTFQ3bb3Nzz3XGhO6TEYNZmDcsFqWBsl+mMNkZH6q1rtm20iODIRlzW2aU ODvrBDG3ThVlWAGNzdeTwdqCsrYuuvOu52zHi93mIicM/Pex6FxF4gAqcWzxTcA= =H2IK -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Sep 10 10:41:04 2015 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 AF8961B377E; Thu, 10 Sep 2015 10:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NO_DNS_FOR_FROM=0.001, 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 Do2fgywtd48s; Thu, 10 Sep 2015 10:40:26 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE921A1AB5; Thu, 10 Sep 2015 10:39:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by vacation.karoshi.com (Postfix) with ESMTP id 48577BC168D; Thu, 10 Sep 2015 10:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at karoshi.com Received: from vacation.karoshi.com ([127.0.0.1]) by localhost (vacation.karoshi.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yq9ZYusAg8Ci; Thu, 10 Sep 2015 10:39:42 -0700 (PDT) Received: from [198.32.4.206] (unknown [198.32.4.206]) by vacation.karoshi.com (Postfix) with ESMTPSA id F2C2FBC1683; Thu, 10 Sep 2015 10:39:41 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=windows-1252 From: manning In-Reply-To: <87613iyy7c.fsf@latte.josefsson.org> Date: Thu, 10 Sep 2015 10:39:40 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <84E13393-79F4-4930-A418-263F1002E56B@karoshi.com> References: <20150828151107.2592.98917.idtracker@ietfa.amsl.com> <87613iyy7c.fsf@latte.josefsson.org> To: dane@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: IETF discussion list Subject: Re: [dane] Last Call: (Using DANE to Associate OpenPGP public keys with email addresses) to Proposed Standard 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, 10 Sep 2015 17:41:01 -0000 I=92d have to agree with Simon here. =20 manning bmanning@karoshi.com PO Box 6151 Playa del Rey, CA 90296 310.322.8102 On 10September2015Thursday, at 10:35, Simon Josefsson = wrote: > I believe it would be a mistake to publish this document without = having > it include a discussion of its relationship to RFC 4648. As far as I > can tell, the CERT record defined in RFC 4648 solves roughly the same > problem as OPENPGPKEY and CERT is already deployed with support in = (for > example) GnuPG. I believe the community would benefit from sorting = out > the relationship before publication, not after, when we would have two > RFCs describing solutions for what appears to be the same problem. >=20 > /Simon >=20 > The IESG writes: >=20 >> The IESG has received a request from the DNS-based Authentication of >> Named Entities WG (dane) to consider the following document: >> - 'Using DANE to Associate OpenPGP public keys with email addresses' >> as Proposed Standard >>=20 >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to = the >> ietf@ietf.org mailing lists by 2015-09-11. Exceptionally, comments = may be >> sent to iesg@ietf.org instead. In either case, please retain the >> beginning of the Subject line to allow automated sorting. >>=20 >> Abstract >>=20 >>=20 >> OpenPGP is a message format for email (and file) encryption that >> lacks a standardized lookup mechanism to securely obtain OpenPGP >> public keys. This document specifies a method for publishing and >> locating OpenPGP public keys in DNS for a specific email address >> using a new OPENPGPKEY DNS Resource Record. Security is provided = via >> DNSSEC. >>=20 >>=20 >>=20 >>=20 >> The file can be obtained via >> https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/ >>=20 >> IESG discussion can be tracked via >> https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/ballot/ >>=20 >>=20 >> No IPR declarations have been submitted directly on this I-D. >>=20 >>=20 >>=20 From nobody Thu Sep 10 10:52:42 2015 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 0C1FA1B402B for ; Thu, 10 Sep 2015 10:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, 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 yLWIsap1QXYb for ; Thu, 10 Sep 2015 10:52:38 -0700 (PDT) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D30701B3FDF for ; Thu, 10 Sep 2015 10:52:37 -0700 (PDT) Received: from srv4.stroeder.local (unknown [10.1.1.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.stroeder.local", Issuer "stroeder.com Server CA no. 2009-07" (verified OK)) by srv1.stroeder.com (Postfix) with ESMTPS id 97F771CF28 for ; Thu, 10 Sep 2015 17:52:35 +0000 (UTC) Received: from nb2.stroeder.local (nb2.stroeder.local [10.1.1.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by srv4.stroeder.local (Postfix) with ESMTPS id 8DB3B1CE87 for ; Thu, 10 Sep 2015 17:52:34 +0000 (UTC) To: dane@ietf.org References: <20150824031926.GF9021@mournblade.imrryr.org> <55F1B075.5060809@stroeder.com> <20150910165337.GZ21942@mournblade.imrryr.org> From: =?UTF-8?Q?Michael_Str=c3=b6der?= X-Enigmail-Draft-Status: N1110 Message-ID: <55F1C362.4000607@stroeder.com> Date: Thu, 10 Sep 2015 19:52:34 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 SeaMonkey/2.35 MIME-Version: 1.0 In-Reply-To: <20150910165337.GZ21942@mournblade.imrryr.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040909050609040407040403" Archived-At: Subject: Re: [dane] DANE for MX host via insecure MX RR? 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, 10 Sep 2015 17:52:41 -0000 This is a cryptographically signed message in MIME format. --------------ms040909050609040407040403 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Viktor Dukhovni wrote: > On Thu, Sep 10, 2015 at 06:31:49PM +0200, Michael Str=F6der wrote: >>> If you want to propose an update that requires SMTP clients to >>> employ DANE TLSA verification of MX hosts in signed zones even when >>> the MX RRset was not "secure", read the previous discussion of this >>> question in the list archives (yes, it has come up before) and make >>> a clear-cut proposal with as solid a rationale as you can. =20 >>> >>> I am not sure this can get enough support to reach "rough consensus",= >>> but I'm open to the possibility. >> >> Without a signed MX there's no cryptographically secured binding betwe= en the >> recipient domain (right address part) and the public key used for TLS = authc. >> >> So I'm strictly against this possibility and the developers of a MTA I= spoke >> with today are also strongly against this. >> >> @Patrik: Deploying DNSSEC/DANE at large scale is not an easy job. If y= ou drop >> the requirement for signed MX RRs DANE would not be worth the effort t= o be >> implemented. >=20 > Note, the hypothetical proposal would not weaken DANE in any way, > nor would it "drop" the requirement to pay attention to the security > status of the MX RRset, in particular "bogus" replies or other DNS > errors in MX resolution would still result in deferral of mail. >=20 > All that would hypothetically happen, is that even when the MX > RRset is "insecure" (verifiably from an unsigned zone) but the > target MX host is in a signed zone and has "secure" TLSA records, > DANE authentication might be "SHOULD" or "MUST", rather than the > current "MAY". >=20 > https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-19#secti= on-2.2.1 >=20 > Since the protocol in this memo is an "opportunistic security" > protocol ([RFC7435]) the SMTP client MAY elect to use DANE TLS (= as > described in Section 2.2.2 below) even with MX hosts obtained vi= a an > "insecure" MX RRSet. For example, when a hosting provider has a= > signed DNS zone and publishes TLSA records for its SMTP servers,= > hosted domains that are not signed may still benefit from the > provider's TLSA records. Deliveries via the provider's SMTP ser= vers > will not be subject to active attacks when sending SMTP clients = elect > to make use of the provider's TLSA records (active attacks that > tamper with the "insecure" MX RRSet are of course still possible= in > this case). >=20 > I think the current "MAY" is sufficient for now, but if that proves > to be a valuable feature of the protocol, an a short update BCP > RFC upgrading the "MAY" to a "SHOULD" or "MUST" might be possible > in the future. Hmm...I can understand why you wrote it like this. But some people are mo= re eager and want to push things into mandatory way. I wished DANE starts wi= th "MUST" from the very beginning. It's a new standard and a big invest anyw= ay. > So long as such sessions are not reported as secure, and are not > accepted when DANE authentication is mandatory (e.g. Postfix > "dane-only" TLS security level), the proposal does not in any > way reduce the security of DANE as specified. Postfix's "dane-only" requires successfully validated signed MX RRs? > The main risk is with reliability. Perhaps only those customers > of a service provider that operate DNSSEC signed domains are willing > to accept service availability risk in case of DANE authentication > failure, and the customers with unsigned zones want service > availability above all else. If the proposal is formalized, then > all customer domains suffer if the TLSA records are ever wrong, > even those whose domains are unsigned. Yes, service providers have opt-in mechs for such a distinction. And of c= ourse they must have *different* right-hand parts in their MX RRs for both case= s. > So the proposal is not obviously damaging, just possibly premature. > We'll know more once there is more deployment and people either > learn (or don't learn) to operate their TLSA records correctly. People should be prepared that some MTAs will require signed MX RRs. Ciao, Michael. --------------ms040909050609040407040403 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DIEwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBkUwggUtoAMCAQICAwtNUDANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTE0MDkyMzIw NDc1NVoXDTE1MDkyNDIyMDUxOFowXzEZMBcGA1UEDRMQNk0yWTdpOXpEdGU2alV3MDEdMBsG A1UEAwwUbWljaGFlbEBzdHJvZWRlci5jb20xIzAhBgkqhkiG9w0BCQEWFG1pY2hhZWxAc3Ry b2VkZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAynIH09fU597v4fg4 uwqFJDPUxQHV9qxrfM/c3veStPyYl0JorqKHrD+hfCNZ+Toy65NN9f9vO26WnnLoDF+FE2Dk Qi61iTgK5jZTr5dJG1WQkk698UNWO87lUWBRYYiUM7wC3ek2E0rzR99qIxE4dG9wws19F3KK JvNN8tMTyoPw5Vkw4qx2SW54WEBMx7oCXBIZPPDD8ovled6vDVweVSaYXFUbkxbKJR87Msih 34Ba+cM5SAHQNQ11jaSJjFeqbQnXjf0nESnvo0XIckc9w240w3jcgu6b5SIQBI2vv5TaIv7v KqNk0o+cGc9NnCw5/xD/OAB9Aj/qDca6NheHCQIDAQABo4IC2jCCAtYwCQYDVR0TBAIwADAL BgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTj z1BhELZO3zEJfmZQ4I+c6NCXIjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAf BgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYL KwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9w b2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0 byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20g Q0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAt MCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEF BQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2Ns YXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2Nl cnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAAfByd9CEZ5pYuRa3XuE5xeJoIpDol22 A1mIGuRqxaBFIummmDoYr/tVgFod/3evQJO+ad8T5wpooY422HkHN4a1UI7ujCKcU/PrQSxm v28AAsl4Fo/InY1nSFjMy8Ywj3EG+Edj1ZpCkzTRNGZjBa6Uj7UY7UW71kYcSdCBe8vc9Zi3 6OnHGkXROWIii3wBKLDEZqxknw0Cj9TTy5lyllYzyHku4aXLDPhiYrTzhWiwgYmweaLvW/yq YVsHRpW8udzqOr6xvUVcuRmfMTENM7RSlRZVw2+5+I+zn7jqOrrULO1FP7Lo5cPilsMpSMOw oJnPLQgNZvXOPFO6VaDCOboxggPtMIID6QIBATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBAgMLTVAwDQYJYIZIAWUDBAIBBQCgggIpMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDkxMDE3NTIzNFowLwYJKoZIhvcNAQkEMSIE IEtWGeM2T+OvzeCNp7amkwTHrgOdm1Nmuekh3tPWawc4MGwGCSqGSIb3DQEJDzFfMF0wCwYJ YIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaUGCSsGAQQBgjcQBDGBlzCB lDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNl Y3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMLTVAwgacGCyqGSIb3DQEJ EAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3Rh cnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwtNUDANBgkq hkiG9w0BAQEFAASCAQBIpa2rQN7MRmc7L9scJOBZURm9rZCI54+5DHfXOIwxFk3icMXdUu+P NY4OTru+OFs4nRQyP9+L3Du5uMTIyz6wen5NXJX4fgJ2fTxRYeIXWWCxhXAg+hXl1754GttH sN6qQ8bK7EXBiIy03FPnj+sp8hs8TMjtYX7655x61JiGnAzn/XVposAl2u9FeAjHYX/3BSPA 2F7RyruFqVL3sLERwbfmyVXDVA3dgnr9ZJbUP2r7fEp+/iKA6hjyMSiSrcr24h40/uPYSOFG KvVyzLatms3TgRNs+PecS7r0jwp7tTb/3mrtDcTayhBfJdOM+JzaHW69o6Nd1XPQhHJCcdyX AAAAAAAA --------------ms040909050609040407040403-- From nobody Thu Sep 10 11:18:28 2015 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 7B4881B3F49 for ; Thu, 10 Sep 2015 11:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 z6_FWuB_okvQ for ; Thu, 10 Sep 2015 11:18:25 -0700 (PDT) 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 7C5E11B30DA for ; Thu, 10 Sep 2015 11:18:25 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D37DB284B70; Thu, 10 Sep 2015 18:18:22 +0000 (UTC) Date: Thu, 10 Sep 2015 18:18:22 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150910181822.GF21942@mournblade.imrryr.org> References: <20150824031926.GF9021@mournblade.imrryr.org> <55F1B075.5060809@stroeder.com> <20150910165337.GZ21942@mournblade.imrryr.org> <55F1C362.4000607@stroeder.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <55F1C362.4000607@stroeder.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [dane] DANE for MX host via insecure MX RR? 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, 10 Sep 2015 18:18:27 -0000 On Thu, Sep 10, 2015 at 07:52:34PM +0200, Michael Strder wrote: > > https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-19#section-2.2.1 > > > > Since the protocol in this memo is an "opportunistic security" > > protocol ([RFC7435]) the SMTP client MAY elect to use DANE TLS (as > > described in Section 2.2.2 below) even with MX hosts obtained via an > > "insecure" MX RRSet. For example, when a hosting provider has a > > signed DNS zone and publishes TLSA records for its SMTP servers, > > hosted domains that are not signed may still benefit from the > > provider's TLSA records. Deliveries via the provider's SMTP servers > > will not be subject to active attacks when sending SMTP clients elect > > to make use of the provider's TLSA records (active attacks that > > tamper with the "insecure" MX RRSet are of course still possible in > > this case). > > > > I think the current "MAY" is sufficient for now, but if that proves > > to be a valuable feature of the protocol, an a short update BCP > > RFC upgrading the "MAY" to a "SHOULD" or "MUST" might be possible > > in the future. > > Hmm...I can understand why you wrote it like this. But some people are more > eager and want to push things into mandatory way. I wished DANE starts with > "MUST" from the very beginning. It's a new standard and a big invest anyway. It does start with MUST, when the MX RRset is "secure" *and* the MX host address records are "secure" *and* "secure" TLSA records are published. When the first condition is false, and you don't actually get MiTM protection, there's a MAY. The MAY allows one to get a secure-channel to possibly the wrong host (this is at least tamper-evident if logs are read). > > So long as such sessions are not reported as secure, and are not > > accepted when DANE authentication is mandatory (e.g. Postfix > > "dane-only" TLS security level), the proposal does not in any > > way reduce the security of DANE as specified. > > Postfix's "dane-only" requires successfully validated signed MX RRs? Requires all three conditions, and matching TLSA records for the peer domain. If you know a domain has committed to implement DANE and keep it that way, you can set the policy for that domain to "dane-only". > > So the proposal is not obviously damaging, just possibly premature. > > We'll know more once there is more deployment and people either > > learn (or don't learn) to operate their TLSA records correctly. > > People should be prepared that some MTAs will require signed MX RRs. Not in the forseeable future. Without signed MX RRs, many sites will not take advantage of DANE TLSA RRs for the corresponding MX hosts even if present. That's different from requiring the MX RRset to be signed in the first place. -- Viktor. From nobody Thu Sep 10 11:28:24 2015 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 856E01A1BDE for ; Thu, 10 Sep 2015 11:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, 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 sMF53gjwAkB3 for ; Thu, 10 Sep 2015 11:28:22 -0700 (PDT) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D35751B3E18 for ; Thu, 10 Sep 2015 11:28:21 -0700 (PDT) Received: from srv4.stroeder.local (unknown [10.1.1.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.stroeder.local", Issuer "stroeder.com Server CA no. 2009-07" (verified OK)) by srv1.stroeder.com (Postfix) with ESMTPS id DE75A1CF28 for ; Thu, 10 Sep 2015 18:28:19 +0000 (UTC) Received: from nb2.stroeder.local (nb2.stroeder.local [10.1.1.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by srv4.stroeder.local (Postfix) with ESMTPS id 50E2A1CF12 for ; Thu, 10 Sep 2015 18:28:19 +0000 (UTC) To: dane@ietf.org References: <20150824031926.GF9021@mournblade.imrryr.org> <55F1B075.5060809@stroeder.com> <20150910165337.GZ21942@mournblade.imrryr.org> <55F1C362.4000607@stroeder.com> <20150910181822.GF21942@mournblade.imrryr.org> From: =?UTF-8?Q?Michael_Str=c3=b6der?= Message-ID: <55F1CBC3.20406@stroeder.com> Date: Thu, 10 Sep 2015 20:28:19 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 SeaMonkey/2.35 MIME-Version: 1.0 In-Reply-To: <20150910181822.GF21942@mournblade.imrryr.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010704090503070100010406" Archived-At: Subject: Re: [dane] DANE for MX host via insecure MX RR? 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, 10 Sep 2015 18:28:23 -0000 This is a cryptographically signed message in MIME format. --------------ms010704090503070100010406 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Viktor Dukhovni wrote: > On Thu, Sep 10, 2015 at 07:52:34PM +0200, Michael Str=F6der wrote: >> People should be prepared that some MTAs will require signed MX RRs. >=20 > [..] Without signed MX RRs, many sites will not take advantage of DANE= > TLSA RRs for the corresponding MX hosts even if present. That's what I meant. > That's different from requiring the MX > RRset to be signed in the first place. Yes. Ciao, Michael. --------------ms010704090503070100010406 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DIEwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBkUwggUtoAMCAQICAwtNUDANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTE0MDkyMzIw NDc1NVoXDTE1MDkyNDIyMDUxOFowXzEZMBcGA1UEDRMQNk0yWTdpOXpEdGU2alV3MDEdMBsG A1UEAwwUbWljaGFlbEBzdHJvZWRlci5jb20xIzAhBgkqhkiG9w0BCQEWFG1pY2hhZWxAc3Ry b2VkZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAynIH09fU597v4fg4 uwqFJDPUxQHV9qxrfM/c3veStPyYl0JorqKHrD+hfCNZ+Toy65NN9f9vO26WnnLoDF+FE2Dk Qi61iTgK5jZTr5dJG1WQkk698UNWO87lUWBRYYiUM7wC3ek2E0rzR99qIxE4dG9wws19F3KK JvNN8tMTyoPw5Vkw4qx2SW54WEBMx7oCXBIZPPDD8ovled6vDVweVSaYXFUbkxbKJR87Msih 34Ba+cM5SAHQNQ11jaSJjFeqbQnXjf0nESnvo0XIckc9w240w3jcgu6b5SIQBI2vv5TaIv7v KqNk0o+cGc9NnCw5/xD/OAB9Aj/qDca6NheHCQIDAQABo4IC2jCCAtYwCQYDVR0TBAIwADAL BgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTj z1BhELZO3zEJfmZQ4I+c6NCXIjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAf BgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYL KwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9w b2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0 byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20g Q0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAt MCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEF BQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2Ns YXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2Nl cnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAAfByd9CEZ5pYuRa3XuE5xeJoIpDol22 A1mIGuRqxaBFIummmDoYr/tVgFod/3evQJO+ad8T5wpooY422HkHN4a1UI7ujCKcU/PrQSxm v28AAsl4Fo/InY1nSFjMy8Ywj3EG+Edj1ZpCkzTRNGZjBa6Uj7UY7UW71kYcSdCBe8vc9Zi3 6OnHGkXROWIii3wBKLDEZqxknw0Cj9TTy5lyllYzyHku4aXLDPhiYrTzhWiwgYmweaLvW/yq YVsHRpW8udzqOr6xvUVcuRmfMTENM7RSlRZVw2+5+I+zn7jqOrrULO1FP7Lo5cPilsMpSMOw oJnPLQgNZvXOPFO6VaDCOboxggPtMIID6QIBATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBAgMLTVAwDQYJYIZIAWUDBAIBBQCgggIpMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDkxMDE4MjgxOVowLwYJKoZIhvcNAQkEMSIE IFQw+BEaiVpgJWAG4/aQO6zc3RVCEXi2yBRZbZaBOaDoMGwGCSqGSIb3DQEJDzFfMF0wCwYJ YIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaUGCSsGAQQBgjcQBDGBlzCB lDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNl Y3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMLTVAwgacGCyqGSIb3DQEJ EAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3Rh cnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwtNUDANBgkq hkiG9w0BAQEFAASCAQAGImFCchD4BqwyD0mIphXxFNrc6lqUudbbLb68uVIIQd1juru/zLuV 68aIgbafSyvMTgf1i0SCyFUdmC5e6+K+HDcr7nebU6RQFEmy4lRSn9tRZh46uEurWpog1pZB xeS29gYEDVBHvXAyasNmvVCjYobhC0AR1zMbynl6gfYJZ0SwZXZbDZWfqWLxDOZf2P1dZA3I +oCEnQZ78XZqOy1uDOn9EeyvN9eKDQcs87r+ZbZKBoeDkEQqif0XzZ9PtDg1xe92F7L9hAX1 NBYNwaYa4HAjOA0c8niN5kqRkTB82x84WaDX4v1Wiqd6NiBOkJyBJZyMN7Pmuzc6zRgGo27T AAAAAAAA --------------ms010704090503070100010406-- From nobody Thu Sep 10 16:38:57 2015 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 9C5C81B3190; Thu, 10 Sep 2015 16:38:56 -0700 (PDT) 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 s6mTd7dpqOxg; Thu, 10 Sep 2015 16:38:55 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A8911B2F7F; Thu, 10 Sep 2015 16:38:55 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3nBxW027xPz3P3; Fri, 11 Sep 2015 01:38:52 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=QgY4tzaD X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id srvmPBRgohST; Fri, 11 Sep 2015 01:38:50 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 11 Sep 2015 01:38:50 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 754618009F; Thu, 10 Sep 2015 19:38:49 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1441928329; bh=6xOM6ucx/mFtBUYcJmiLGyyHsHz+6ar1Y+RRUdiOIn8=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=QgY4tzaDck0IZb7NfiDsuQj3t/loTorXsfI/DeUGqtGCbvvcKV+sKufaA5+8qVoT9 uxT7KkPiMzQmzNAlnpQ+3/YC2IEIvaxL0uycIioVTsyFYvvgn2Q2q9a5BuO4fGa5iU qGPrpaM7oHkq4+JbW39b/haRI8osJWxHY1Ozjy24= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.2/8.15.2/Submit) with ESMTP id t8ANcnDw024375; Thu, 10 Sep 2015 19:38:49 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Thu, 10 Sep 2015 19:38:49 -0400 (EDT) From: Paul Wouters To: Simon Josefsson In-Reply-To: <87613iyy7c.fsf@latte.josefsson.org> Message-ID: References: <20150828151107.2592.98917.idtracker@ietfa.amsl.com> <87613iyy7c.fsf@latte.josefsson.org> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: ietf@ietf.org, dane@ietf.org Subject: Re: [dane] Last Call: (Using DANE to Associate OpenPGP public keys with email addresses) to Proposed Standard 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, 10 Sep 2015 23:38:56 -0000 On Thu, 10 Sep 2015, Simon Josefsson wrote: > I believe it would be a mistake to publish this document without having > it include a discussion of its relationship to RFC 4648. As far as I > can tell, the CERT record defined in RFC 4648 solves roughly the same > problem as OPENPGPKEY and CERT is already deployed with support in (for > example) GnuPG. I believe the community would benefit from sorting out > the relationship before publication, not after, when we would have two > RFCs describing solutions for what appears to be the same problem. This issue has also come up several times in the working group discussion. While a paragraph could surely be added to the document, I don't see much value in such historic inclusion to implementors. The CERT record uses sub typing which is (now) considered to be bad in DNS, including by at least one of the authors of the original CERT record RFC-2538. It includes dependancies on other security modules besides DNSSEC (PKIX, CA's, generic URI's dealing with TLS security, etc.) which makes it hard on implementors that only want to implement certain security schemes (eg just OpenPGP and not PKIX, SPKI, X.509 blobs, etc). So that leaves only the PGP and iPGP sub types of the CERT. That also means the DNSKEY algorthm number of the CERT RDATA is always 0 (and really not needed) Indirect URI schemes of CERT can also be used to trick MUA's or MTA's into connecting to random rogue servers, which is both a security and a privacy problem. This makes the CERT sub-type IPGP undesirable. The OPENPGPKEY record uses no sub types, involves no other PKIs, and supports one clear RDATA format to implement. Depending on only DNS(SEC) means that openpgp key data can be distributed easilly and widely, without creating single point of failures or easilly blocked HTTP requests that are indistinguisable from outages. With DNSSEC, tampering is visible because there will be a BOGUS DNS answer when the data is filtered or the data is obtained. Whereas with indirect methods there can be "unknown errors" in reaching the indirectly pointed by resource. The CERT record did not address the local-part lookup problem. So regardless, a new RFC would be needed to specify the local-part lookup. That RFC would than basically have to say "Only use IANA certificate type is 3 (PGP) and algorithm type 0 (not a DNSKEY algorithm). It seems much cleaner to limit the RDATA section to just the OpenPGP key material without unused sub-typing and zero'd algorithm identifiers. The OPENPGPKEY record early code point has already seen more deployment than the CERT record. The SMIME record draft also does not plan on using the CERT record. Paul From nobody Mon Sep 14 00:15:24 2015 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 728101B49D3 for ; Mon, 14 Sep 2015 00:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4Pjp9gnL85F for ; Mon, 14 Sep 2015 00:15:21 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD3ED1B2C0B for ; Mon, 14 Sep 2015 00:15:20 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 76034509BD for ; Mon, 14 Sep 2015 03:15:19 -0400 (EDT) From: Sean Leonard To: dane@ietf.org Message-ID: <55F6742A.4030806@seantek.com> Date: Mon, 14 Sep 2015 00:15:54 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000606040603020106060701" Archived-At: Subject: [dane] Published Rules for equivalent local-parts 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, 14 Sep 2015 07:15:23 -0000 This is a cryptographically signed message in MIME format. --------------ms000606040603020106060701 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Colleagues: I have mostly stayed out of DANE postings as I have been waiting for the = smoke to clear. However there is one point where I feel the need to put=20 a thumb on the scale: proper querying of the mailbox local-part. After reading the last 12 months of postings/proceedings, I am convinced = that e-mail address local-part canonicalization is an important topic,=20 and that this WG should not punt on it. The ultimate (and only) arbiter=20 of what constitutes a "correct" e-mail address (local-part) is the=20 receiving SMTP server (MTA). This is just like the post office in real=20 life: the sender can put whatever casing or abbreviations he or she=20 wants on an envelope; all that matters is that the postal service gets=20 the mailpiece into the same mailbox. For the most part I concur with=20 John Levine's remarks on the subject all the way down. People want to provide SMIMEA/OPENPGPKEY keys passively, i.e., by=20 loading up the DNS server with entries, rather than actively, i.e., by=20 passing the DNS query to a backend process that dynamically generates=20 the records. John says this is straightforward ; detractors cite coordination=20 difficulties with the mail server and risks of keeping the signing key=20 online. We have to acknowledge that RFC 5321/5322 say local-part is=20 case-sensitive, and also that many (most) receiving MTAs operate as=20 case-preserving but case-insensitive. Therefore, I propose the development of a new DNS RR Type, that conveys=20 mailbox equivalences for a domain. It could be placed at the=20 domain-level, right alongside the MX records. A DANE OPENPGPKEY or=20 SMIMEA client SHALL take the information from this RR and apply it to=20 the local-part before any other transformations mandated by the specs. *** DNS RR type: MBLPEQV ("Mailbox local-part Equivalence Rules") case-fold to lowercase (US-ASCII) (boolean) sub-address characters (UTF-8) (array of characters) remove characters (UTF-8) (array of characters) (extensions for future rules) *** Definitions: case-fold to lowercase (US-ASCII): if true and if capital letters are=20 present, construct TWO queries: a typical query, and a query with A-Z=20 (0x41 - 0x5A) converted to a-z (0x61 - 0x7A). sub-address characters (UTF-8): at the first instance of any of the=20 characters, construct TWO queries: a query with the complete local-part=20 and a query with the characters prior to the first sub-address character.= (NB: qmail supports both + and - sub-addressing at the same time.=20 Yahoo! Mail Plus supports - sub-addressing. I would call these=20 "significant deployments".) (SAD: A spammer could use this published rule to defeat some of the=20 esrtwhile advantages of sub-addressing, as de-subbing an address now=20 becomes a deterministic exercise.) remove characters (UTF-8): if any of the characters are present in the=20 local-part, construct TWO queries: a query with all characters, and a=20 query where the characters are deleted from the query. Meant to support=20 Gmail dots, among others. (extensions for future rules): The RR should be extensible to define future rules, but don't go overboar= d. Exemplary future rules including case folding and canonicalization=20 issues with extended UTF-8 characters. For example: "Normalization Form=20 C", "Lowercase Swedish/Latin Characters", etc. These should be developed = only after sufficient experience with EAI deployments, and with I18N +=20 security experts. Nomenclature: RFC 5322/RFC 5321 don't bless any particular casing or=20 whatever as "canonical", so the concept of a "canonical local-part" does = not exist from the standpoint of the mail infrastructure. That is why I=20 named the RR type "Equivalence Rules" because they are equivalent rather = than one being more correct than another. The concept of=20 "canonicalization" only exists for DNS/DANE purposes, and it's for the=20 convenience of the DNS operator. Kind regards, Sean Acknowledgements: This proposal was conceived independently by me, but=20 others have proposed it or variations of it over the last several=20 months. It didn't get nearly as much discussion as deserved. Refs below. mid:20141211224007.10592.qmail@ary.lan mid:20141211205053.GN25666@mournblade.imrryr.org mid:20141211220308.GH3448@localhost mid:55E6C885.2080102@phpgangsta.de See also: Publishing mailbox (or, rather, mail *service*) information in the DNS=20 is not without precedent. See the RR types MD, MF, MB, MINFO, MAILB,=20 MAILA from [RFC1035], for example. --------------ms000606040603020106060701 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfYwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggU/MIIEJ6ADAgECAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwMjAyMDAwMDAwWhcNMTYwMjAyMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkB FhRkZXYraWV0ZkBzZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AM+J9tKgDs1LQtaDc+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgiv boRKoo2guKi2R5xrf/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftv TEun2mOrnJ3G53zvawQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecN VbfusUU1wZOlfdy8lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd 7oCj5MRKOg2ZLia33JN+oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAfIwggHu MB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQaZuXe8vDwU+ja pyFW3zSvIW6TxjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQv Q1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NI QTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUF BwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHwYDVR0RBBgwFoEUZGV2K2lldGZAc2Vh bnRlay5jb20wDQYJKoZIhvcNAQELBQADggEBAHiH/zXr779dLLJNLp6yW/RQvJSYuNbEqauQ BWLZgvCF8FJjcS+y+bhN7RpTSVaEymbxnpJWFg0Qs6us6rXtttU6MF2JhTuxtu6yWW0EYy80 KGOt6zJRTxa46kAhAOqw4KPQ5RTvf/NT+2Qu8b2edlh+3t6f8iTQOAL/BNHnmr4QvpfnMLa8 NMAqd4FLOcSU9JKBlb5YtsEdfM3nBt4m95pfhpww79gB+zoXMoVaI+lfQHhkGth6mlaTkFUV DT2pqq98XgESpObFEngb8ZRftBVoZfgJ4ajXcZnhKaqYEr23EtY207KgKb4LAXA84wtPcFfJ rQaDArapR7xd2GNs+eYxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCWCGSAFlAwQC AQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTA5 MTQwNzE1NTRaMC8GCSqGSIb3DQEJBDEiBCA6GdNAEQAonCCo89T1kpavcFRjEbrrWwngsdE6 xjJjLDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQGkJKzyf5xBtzPJYq257J5zCBwwYLKoZIhvcNAQkQ AgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQD EzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFp bCBDQQIQGkJKzyf5xBtzPJYq257J5zANBgkqhkiG9w0BAQEFAASCAQCMNJh4cb6RA+GnkxNa GRdzb0cS64M02C/GlUbZUODpbweYDnH8/QMPE+ozsogAmtg1kZnb2rzLenCzcSOaUtaEgnrg PmkWpIXOveV1lSCZ2pxeEAgEYXqGD13D7YrNndtGPGXisd3h7E0J+PUJ5+LxfVwUfVn/RRDA er1cBc2fFioG1eXiPbnmPJ9aFG1s8uZAEhe77XiQpwtWLTMDe4NeH/6D09k9CLRV40y7Ph5V VkCbE3KHqwwNU0NaDj5B31ORS35x4OwBBavSrG3W8QXNyy/4KPel4G8T4EVHkLSDz6SaSU0x ouQsFOzp14oGtm+QSw2Uo9THu1GnLAveunIZAAAAAAAA --------------ms000606040603020106060701-- From nobody Mon Sep 14 04:16:39 2015 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 2474F1B3931 for ; Mon, 14 Sep 2015 04:16:38 -0700 (PDT) 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_HELO_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 h8EiwY6ETRAC for ; Mon, 14 Sep 2015 04:16:36 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72EBA1B35A9 for ; Mon, 14 Sep 2015 04:16:36 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id C388691C02 for ; Mon, 14 Sep 2015 11:16:35 +0000 (UTC) Received: from pspacek.brq.redhat.com (ovpn-204-56.brq.redhat.com [10.40.204.56]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8EBGX2F013897 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Mon, 14 Sep 2015 07:16:35 -0400 To: dane@ietf.org References: <20150828151107.2592.98917.idtracker@ietfa.amsl.com> <87613iyy7c.fsf@latte.josefsson.org> From: Petr Spacek Organization: Red Hat Message-ID: <55F6AC91.6060501@redhat.com> Date: Mon, 14 Sep 2015 13:16:33 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: Subject: Re: [dane] Last Call: (Using DANE to Associate OpenPGP public keys with email addresses) to Proposed Standard 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, 14 Sep 2015 11:16:38 -0000 On 11.9.2015 01:38, Paul Wouters wrote: > On Thu, 10 Sep 2015, Simon Josefsson wrote: > >> I believe it would be a mistake to publish this document without having >> it include a discussion of its relationship to RFC 4648. As far as I >> can tell, the CERT record defined in RFC 4648 solves roughly the same >> problem as OPENPGPKEY and CERT is already deployed with support in (for >> example) GnuPG. I believe the community would benefit from sorting out >> the relationship before publication, not after, when we would have two >> RFCs describing solutions for what appears to be the same problem. > > This issue has also come up several times in the working group > discussion. While a paragraph could surely be added to the document, I > don't see much value in such historic inclusion to implementors. > > The CERT record uses sub typing which is (now) considered to be bad > in DNS, including by at least one of the authors of the original CERT > record RFC-2538. > > It includes dependancies on other security modules besides DNSSEC (PKIX, > CA's, generic URI's dealing with TLS security, etc.) which makes it hard > on implementors that only want to implement certain security schemes > (eg just OpenPGP and not PKIX, SPKI, X.509 blobs, etc). So that leaves > only the PGP and iPGP sub types of the CERT. That also means the DNSKEY > algorthm number of the CERT RDATA is always 0 (and really not needed) > > Indirect URI schemes of CERT can also be used to trick MUA's or MTA's > into connecting to random rogue servers, which is both a security and > a privacy problem. This makes the CERT sub-type IPGP undesirable. > > The OPENPGPKEY record uses no sub types, involves no other PKIs, and > supports one clear RDATA format to implement. Depending on only DNS(SEC) > means that openpgp key data can be distributed easilly and widely, > without creating single point of failures or easilly blocked HTTP > requests that are indistinguisable from outages. > > With DNSSEC, tampering is visible because there will be a BOGUS DNS answer > when the data is filtered or the data is obtained. Whereas with indirect > methods there can be "unknown errors" in reaching the indirectly pointed > by resource. > > The CERT record did not address the local-part lookup problem. > So regardless, a new RFC would be needed to specify the local-part > lookup. That RFC would than basically have to say "Only use IANA > certificate type is 3 (PGP) and algorithm type 0 (not a DNSKEY algorithm). > > It seems much cleaner to limit the RDATA section to just the OpenPGP key > material without unused sub-typing and zero'd algorithm identifiers. > > The OPENPGPKEY record early code point has already seen more deployment > than the CERT record. I agree with your reasoning, Paul. On the other hand, it makes sense to write one paragraph about it to the draft so we do not need to explain and again and again, especially to future generations. -- Petr Spacek @ Red Hat From nobody Wed Sep 16 09:21:38 2015 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 85DC91A038F for ; Wed, 16 Sep 2015 09:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, GB_I_LETTER=-2, 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 KygxnVNec6gG for ; Wed, 16 Sep 2015 09:21:34 -0700 (PDT) Received: from smtp116.iad3a.emailsrvr.com (smtp116.iad3a.emailsrvr.com [173.203.187.116]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D8B11A1A19 for ; Wed, 16 Sep 2015 09:21:34 -0700 (PDT) Received: from smtp15.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp15.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id F13C8380352; Wed, 16 Sep 2015 12:21:32 -0400 (EDT) Received: by smtp15.relay.iad3a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id BAA223802F4; Wed, 16 Sep 2015 12:21:32 -0400 (EDT) X-Sender-Id: ogud@ogud.com Received: from [10.20.30.43] (pool-173-66-187-177.washdc.fios.verizon.net [173.66.187.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.4.2); Wed, 16 Sep 2015 16:21:32 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Olafur Gudmundsson In-Reply-To: <55F6742A.4030806@seantek.com> Date: Wed, 16 Sep 2015 12:21:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55F6742A.4030806@seantek.com> To: Sean Leonard X-Mailer: Apple Mail (2.2104) Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Published Rules for equivalent local-parts X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 16:21:36 -0000 Sean,=20 =20 =20 I think this at worth while idea and you should write it up as ID.=20 The right place to publish this rule record is next to the MX records = and/or at the top of the key store, but based on experience I would = limit the=20 expansion to new rules, thus try to capture as many rules as possible in = the document before publication.=20 =20 not sure if DANE is the right working group for this.=20 but for now the discussion can take place in here, as if this is = helpful.=20 I see no reason to hold up the publication of OPENPGP/SMIMEA documents = as this is an add-on to the =E2=80=9Cexperiment=E2=80=9D=20 Olafur > On Sep 14, 2015, at 3:15 AM, Sean Leonard = wrote: >=20 > Colleagues: >=20 > I have mostly stayed out of DANE postings as I have been waiting for = the smoke to clear. However there is one point where I feel the need to = put a thumb on the scale: proper querying of the mailbox local-part. >=20 > After reading the last 12 months of postings/proceedings, I am = convinced that e-mail address local-part canonicalization is an = important topic, and that this WG should not punt on it. The ultimate = (and only) arbiter of what constitutes a "correct" e-mail address = (local-part) is the receiving SMTP server (MTA). This is just like the = post office in real life: the sender can put whatever casing or = abbreviations he or she wants on an envelope; all that matters is that = the postal service gets the mailpiece into the same mailbox. For the = most part I concur with John Levine's remarks on the subject all the way = down. >=20 > People want to provide SMIMEA/OPENPGPKEY keys passively, i.e., by = loading up the DNS server with entries, rather than actively, i.e., by = passing the DNS query to a backend process that dynamically generates = the records. John says this is straightforward ; detractors cite coordination = difficulties with the mail server and risks of keeping the signing key = online. We have to acknowledge that RFC 5321/5322 say local-part is = case-sensitive, and also that many (most) receiving MTAs operate as = case-preserving but case-insensitive. >=20 > Therefore, I propose the development of a new DNS RR Type, that = conveys mailbox equivalences for a domain. It could be placed at the = domain-level, right alongside the MX records. A DANE OPENPGPKEY or = SMIMEA client SHALL take the information from this RR and apply it to = the local-part before any other transformations mandated by the specs. >=20 > *** > DNS RR type: MBLPEQV ("Mailbox local-part Equivalence Rules") > case-fold to lowercase (US-ASCII) (boolean) > sub-address characters (UTF-8) (array of characters) > remove characters (UTF-8) (array of characters) > (extensions for future rules) > *** >=20 > Definitions: > case-fold to lowercase (US-ASCII): if true and if capital letters are = present, construct TWO queries: a typical query, and a query with A-Z = (0x41 - 0x5A) converted to a-z (0x61 - 0x7A). >=20 > sub-address characters (UTF-8): at the first instance of any of the = characters, construct TWO queries: a query with the complete local-part = and a query with the characters prior to the first sub-address = character. > (NB: qmail supports both + and - sub-addressing at the same time. = Yahoo! Mail Plus supports - sub-addressing. I would call these = "significant deployments".) > (SAD: A spammer could use this published rule to defeat some of the = esrtwhile advantages of sub-addressing, as de-subbing an address now = becomes a deterministic exercise.) >=20 > remove characters (UTF-8): if any of the characters are present in the = local-part, construct TWO queries: a query with all characters, and a = query where the characters are deleted from the query. Meant to support = Gmail dots, among others. >=20 > (extensions for future rules): > The RR should be extensible to define future rules, but don't go = overboard. >=20 > Exemplary future rules including case folding and canonicalization = issues with extended UTF-8 characters. For example: "Normalization Form = C", "Lowercase Swedish/Latin Characters", etc. These should be developed = only after sufficient experience with EAI deployments, and with I18N + = security experts. >=20 >=20 > Nomenclature: RFC 5322/RFC 5321 don't bless any particular casing or = whatever as "canonical", so the concept of a "canonical local-part" does = not exist from the standpoint of the mail infrastructure. That is why I = named the RR type "Equivalence Rules" because they are equivalent rather = than one being more correct than another. The concept of = "canonicalization" only exists for DNS/DANE purposes, and it's for the = convenience of the DNS operator. >=20 > Kind regards, >=20 > Sean >=20 > Acknowledgements: This proposal was conceived independently by me, but = others have proposed it or variations of it over the last several = months. It didn't get nearly as much discussion as deserved. Refs below. > mid:20141211224007.10592.qmail@ary.lan > mid:20141211205053.GN25666@mournblade.imrryr.org > mid:20141211220308.GH3448@localhost > mid:55E6C885.2080102@phpgangsta.de >=20 > See also: > Publishing mailbox (or, rather, mail *service*) information in the DNS = is not without precedent. See the RR types MD, MF, MB, MINFO, MAILB, = MAILA from [RFC1035], for example. >=20 >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From nobody Thu Sep 17 20:23:24 2015 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 0A5011A1AA3; Thu, 17 Sep 2015 20:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.057 X-Spam-Level: X-Spam-Status: No, score=-1.057 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, RCVD_IN_DNSWL_LOW=-0.7] 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 0F3Ng9crwC8A; Thu, 17 Sep 2015 20:23:21 -0700 (PDT) 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 F3AA71A1A68; Thu, 17 Sep 2015 20:23:20 -0700 (PDT) Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id E7C58282F4C; Fri, 18 Sep 2015 03:23:19 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: text/plain; charset=us-ascii From: Viktor Dukhovni In-Reply-To: Date: Thu, 17 Sep 2015 14:09:11 -0400 Content-Transfer-Encoding: 7bit Message-Id: <931830E6-6B8C-410E-9B57-F3E5CB5AE5B8@dukhovni.org> References: <20150917055456.1162.qmail@ary.lan> To: ietf@ietf.org X-Mailer: Apple Mail (2.2104) Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Summary of IETF LC for draft-ietf-dane-openpgpkey X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ietf@ietf.org, 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, 18 Sep 2015 03:23:22 -0000 > On Sep 17, 2015, at 5:26 AM, John C Klensin wrote: > > The document seems to say that I should not trust a key found by > this method just because of where I find it. That is entirely > consistent with other PGP documents and existing keyservers. I > should, instead, rely on web of trust relationships, e.g., > signatures on the particular key. OPENPGP is a data format, WoT is one way to employ that format to exchange messages. It is not a *required* way to use OPENPGP. In particular, if a user elects to configure an MUA to use DNSSEC as a trusted introducer, so as to be able to increase privacy of messaging beyond his immediate social circle, that's a fine choice. Think of it as "opportunistic PGP". It's what you do when you'd have otherwise sent the email in the clear anyway. -- Viktor. From nobody Fri Sep 18 04:39:06 2015 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 C62CA1B2B16 for ; Fri, 18 Sep 2015 04:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.601 X-Spam-Level: X-Spam-Status: No, score=-4.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IbBy1dGGxpCz for ; Fri, 18 Sep 2015 04:38:57 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D18DE1B2B29 for ; Fri, 18 Sep 2015 04:38:56 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 58BA5509BE; Fri, 18 Sep 2015 07:38:53 -0400 (EDT) To: Olafur Gudmundsson References: <55F6742A.4030806@seantek.com> From: Sean Leonard Message-ID: <55FBF7F1.3040207@seantek.com> Date: Fri, 18 Sep 2015 04:39:29 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090402040304080809090409" Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Published Rules for equivalent local-parts 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, 18 Sep 2015 11:39:04 -0000 This is a cryptographically signed message in MIME format. --------------ms090402040304080809090409 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Olafur, Thank you. I will try to write something up in the next 2-3 weeks or so. Sean On 9/16/2015 9:21 AM, Olafur Gudmundsson wrote: > Sean, > > > > I think this at worth while idea and you should write it up as ID. > The right place to publish this rule record is next to the MX records a= nd/or at the top of the key store, but based on experience I would limit = the > expansion to new rules, thus try to capture as many rules as possible i= n the document before publication. > > > not sure if DANE is the right working group for this. > but for now the discussion can take place in here, as if this is helpfu= l. > > I see no reason to hold up the publication of OPENPGP/SMIMEA documents = as this is an add-on to the =E2=80=9Cexperiment=E2=80=9D > > Olafur > > >> On Sep 14, 2015, at 3:15 AM, Sean Leonard wrote= : >> >> Colleagues: >> >> I have mostly stayed out of DANE postings as I have been waiting for t= he smoke to clear. However there is one point where I feel the need to pu= t a thumb on the scale: proper querying of the mailbox local-part. >> >> After reading the last 12 months of postings/proceedings, I am convinc= ed that e-mail address local-part canonicalization is an important topic,= and that this WG should not punt on it. The ultimate (and only) arbiter = of what constitutes a "correct" e-mail address (local-part) is the receiv= ing SMTP server (MTA). This is just like the post office in real life: th= e sender can put whatever casing or abbreviations he or she wants on an e= nvelope; all that matters is that the postal service gets the mailpiece i= nto the same mailbox. For the most part I concur with John Levine's remar= ks on the subject all the way down. >> >> People want to provide SMIMEA/OPENPGPKEY keys passively, i.e., by load= ing up the DNS server with entries, rather than actively, i.e., by passin= g the DNS query to a backend process that dynamically generates the recor= ds. John says this is straightforward ; detractors cite coordination difficulties with the mail= server and risks of keeping the signing key online. We have to acknowled= ge that RFC 5321/5322 say local-part is case-sensitive, and also that man= y (most) receiving MTAs operate as case-preserving but case-insensitive. >> >> Therefore, I propose the development of a new DNS RR Type, that convey= s mailbox equivalences for a domain. It could be placed at the domain-lev= el, right alongside the MX records. A DANE OPENPGPKEY or SMIMEA client SH= ALL take the information from this RR and apply it to the local-part befo= re any other transformations mandated by the specs. >> >> *** >> DNS RR type: MBLPEQV ("Mailbox local-part Equivalence Rules") >> case-fold to lowercase (US-ASCII) (boolean) >> sub-address characters (UTF-8) (array of characters) >> remove characters (UTF-8) (array of characters) >> (extensions for future rules) >> *** >> >> Definitions: >> case-fold to lowercase (US-ASCII): if true and if capital letters are = present, construct TWO queries: a typical query, and a query with A-Z (0x= 41 - 0x5A) converted to a-z (0x61 - 0x7A). >> >> sub-address characters (UTF-8): at the first instance of any of the ch= aracters, construct TWO queries: a query with the complete local-part and= a query with the characters prior to the first sub-address character. >> (NB: qmail supports both + and - sub-addressing at the same time. Yaho= o! Mail Plus supports - sub-addressing. I would call these "significant d= eployments".) >> (SAD: A spammer could use this published rule to defeat some of the es= rtwhile advantages of sub-addressing, as de-subbing an address now become= s a deterministic exercise.) >> >> remove characters (UTF-8): if any of the characters are present in the= local-part, construct TWO queries: a query with all characters, and a qu= ery where the characters are deleted from the query. Meant to support Gma= il dots, among others. >> >> (extensions for future rules): >> The RR should be extensible to define future rules, but don't go overb= oard. >> >> Exemplary future rules including case folding and canonicalization iss= ues with extended UTF-8 characters. For example: "Normalization Form C", = "Lowercase Swedish/Latin Characters", etc. These should be developed only= after sufficient experience with EAI deployments, and with I18N + securi= ty experts. >> >> >> Nomenclature: RFC 5322/RFC 5321 don't bless any particular casing or w= hatever as "canonical", so the concept of a "canonical local-part" does n= ot exist from the standpoint of the mail infrastructure. That is why I na= med the RR type "Equivalence Rules" because they are equivalent rather th= an one being more correct than another. The concept of "canonicalization"= only exists for DNS/DANE purposes, and it's for the convenience of the D= NS operator. >> >> Kind regards, >> >> Sean >> >> Acknowledgements: This proposal was conceived independently by me, but= others have proposed it or variations of it over the last several months= =2E It didn't get nearly as much discussion as deserved. Refs below. >> mid:20141211224007.10592.qmail@ary.lan >> mid:20141211205053.GN25666@mournblade.imrryr.org >> mid:20141211220308.GH3448@localhost >> mid:55E6C885.2080102@phpgangsta.de >> >> See also: >> Publishing mailbox (or, rather, mail *service*) information in the DNS= is not without precedent. See the RR types MD, MF, MB, MINFO, MAILB, MAI= LA from [RFC1035], for example. >> >> >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane --------------ms090402040304080809090409 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfYwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggU/MIIEJ6ADAgECAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwMjAyMDAwMDAwWhcNMTYwMjAyMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkB FhRkZXYraWV0ZkBzZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AM+J9tKgDs1LQtaDc+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgiv boRKoo2guKi2R5xrf/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftv TEun2mOrnJ3G53zvawQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecN VbfusUU1wZOlfdy8lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd 7oCj5MRKOg2ZLia33JN+oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAfIwggHu MB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQaZuXe8vDwU+ja pyFW3zSvIW6TxjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQv Q1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NI QTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUF BwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHwYDVR0RBBgwFoEUZGV2K2lldGZAc2Vh bnRlay5jb20wDQYJKoZIhvcNAQELBQADggEBAHiH/zXr779dLLJNLp6yW/RQvJSYuNbEqauQ BWLZgvCF8FJjcS+y+bhN7RpTSVaEymbxnpJWFg0Qs6us6rXtttU6MF2JhTuxtu6yWW0EYy80 KGOt6zJRTxa46kAhAOqw4KPQ5RTvf/NT+2Qu8b2edlh+3t6f8iTQOAL/BNHnmr4QvpfnMLa8 NMAqd4FLOcSU9JKBlb5YtsEdfM3nBt4m95pfhpww79gB+zoXMoVaI+lfQHhkGth6mlaTkFUV DT2pqq98XgESpObFEngb8ZRftBVoZfgJ4ajXcZnhKaqYEr23EtY207KgKb4LAXA84wtPcFfJ rQaDArapR7xd2GNs+eYxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCWCGSAFlAwQC AQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTA5 MTgxMTM5MjlaMC8GCSqGSIb3DQEJBDEiBCDr7go/ec66dBmZhu321pMFJKHp7/fZVxA2CE0O CQ7M3DBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQGkJKzyf5xBtzPJYq257J5zCBwwYLKoZIhvcNAQkQ AgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQD EzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFp bCBDQQIQGkJKzyf5xBtzPJYq257J5zANBgkqhkiG9w0BAQEFAASCAQBNzY1Ij7FhsALPZZlP cZG7sZNF22cTEIzRE3hF5SuM6Mva6eI4f1cOEf/xkV4X2fr7XCnsa7dK+FLi8nIDMcl6D6JD FsBRLMpT13UuYwGsjjgPSRt75FgToAIAZeyddkUkOIvC+i2tcMFk/YF4rPq8i1dBE9fFst0G BFIHUj5yh2eYPpNq6Az/pfbjIdjjW+bDM0jEXvB81Xa6vTfx9epDNz9mpBThx9JQLb1v7Sc2 T2x15o7jWvTCgl0Q3Z5PnL5tKGjAkcYzqD407Ltt8QJ3zWsvifknI7PpCJExiUQDsGE+NAm1 QWOGm0IWtNm5qk/cgC1Wjbx+se3JcsdYAYqEAAAAAAAA --------------ms090402040304080809090409-- From nobody Sun Sep 20 12:06:29 2015 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 EC6A41A6FC8 for ; Sun, 20 Sep 2015 12:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.563 X-Spam-Level: * X-Spam-Status: No, score=1.563 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 nysNHAvjWsNT for ; Sun, 20 Sep 2015 12:06:26 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D589D1A6F92 for ; Sun, 20 Sep 2015 12:06:25 -0700 (PDT) Received: (qmail 37535 invoked from network); 20 Sep 2015 19:06:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=929e.55ff03b0.k1509; bh=siW8GZq+iyktFDRem0Jy0km1cPK0lG4mzjHpVaCscho=; b=GH12UTeYvxDrsbTWKKgL7IO7DVvgySRCWx8nz6hVP/l9Elrv9PvZDw9Ihu1tWJuBFbewRfOC4M3WvWp4MIuAl3RPD+dgGjdkSgQcmjaLpo6P1h33Ncm/yV5NDnNFyBhxL41wSMoMhMmv3JKvLZ69v5w7AUIHT+WsEvY5vrJIpFGNQy9k/YzHrer01e1q1HN+5Cu5ok3c7MXj3SK+URORGFg7xljr7cgkA/bqYmd/PtTFWrDz7WCe5pHGk7Y542WY Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 20 Sep 2015 19:06:24 -0000 Date: 20 Sep 2015 12:06:23 -0700 Message-ID: From: "John R. Levine" To: "Sean Leonard" In-Reply-To: <55FBF7F1.3040207@seantek.com> References: <55F6742A.4030806@seantek.com> <55FBF7F1.3040207@seantek.com> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Published Rules for equivalent local-parts 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, 20 Sep 2015 19:06:27 -0000 > Thank you. I will try to write something up in the next 2-3 weeks or so. Not to rain on your parade, but this is a hard problem. The list you're starting from is OK, but there are a lot more address transformations in common use such as BATV, SRS, and VERP (not just by me.) I know that the versions of VERP implemented in qmail, Mailman, and Sympa are semantically similar but syntactically different, not sure about other packages. Since the question will surely come up, it'd be a good idea to explain why this is better than the existing SMTP command that provides the canonical address(es) for an input address. >> >> not sure if DANE is the right working group for this. Other than the two DANE key drafts, all of the recent work on e-mail I can think of has all been in appsawg or small WGs spun out of it. R's, John From nobody Sun Sep 20 13:27:39 2015 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 B33CF1B2C6E for ; Sun, 20 Sep 2015 13:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.69 X-Spam-Level: X-Spam-Status: No, score=0.69 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 6vtkMFkA95AP for ; Sun, 20 Sep 2015 13:27:35 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB0291B2CC9 for ; Sun, 20 Sep 2015 13:27:28 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3nK0nT69rtz37R for ; Sun, 20 Sep 2015 22:27:25 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=LZRllMlA X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id TSXmM62wPd0l for ; Sun, 20 Sep 2015 22:27:23 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Sun, 20 Sep 2015 22:27:23 +0200 (CEST) Received: from [193.111.228.71] (unknown [193.111.228.71]) by bofh.nohats.ca (Postfix) with ESMTPSA id 20236800B0 for ; Sun, 20 Sep 2015 16:27:22 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1442780842; bh=TC3c83WySbexS9yPeBY1aUq/9PS0/2/kaGkZJ2MHAGg=; h=Subject:References:From:In-Reply-To:Date:To; b=LZRllMlAOngTeeuW696MIUwUnO8gBltWJjMKrC2zJBBDfB7H8+4bZmH9BkFHhjfPe prhouX5YlPox1qdPeYieiCnQTYjhYFUTgpX5RzjK1mKYkEmVXRPNrgo5vDIg15TJc1 U+HujX0ziKMUo86GN0+Ayf4Y2C7/4NLRg/DxRbic= References: <55F6742A.4030806@seantek.com> <55FBF7F1.3040207@seantek.com> From: Paul Wouters Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (13A4325c) In-Reply-To: Message-Id: <248BA60D-2C0B-4261-85B8-53AA8CF3BCC1@nohats.ca> Date: Sun, 20 Sep 2015 16:27:10 -0400 To: dane@ietf.org Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Archived-At: Subject: Re: [dane] Published Rules for equivalent local-parts 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, 20 Sep 2015 20:27:37 -0000 On Sep 20, 2015, at 15:06, John R. Levine wrote: > Since the question will surely come up, it'd be a good idea to explain why= this is better than the existing SMTP command that provides the canonical a= ddress(es) for an input address. Because the anti-spam brigade made sure port 25 is unreachable for most end p= oints? Paul= From nobody Sun Sep 20 20:55:14 2015 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 4AB581A86F0 for ; Sun, 20 Sep 2015 20:55:13 -0700 (PDT) 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 HTGIHZofeIu9 for ; Sun, 20 Sep 2015 20:55:12 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B1031A8033 for ; Sun, 20 Sep 2015 20:55:12 -0700 (PDT) Received: (qmail 98437 invoked from network); 21 Sep 2015 03:55:10 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 21 Sep 2015 03:55:10 -0000 Date: 21 Sep 2015 03:54:48 -0000 Message-ID: <20150921035448.5523.qmail@ary.lan> From: "John Levine" To: dane@ietf.org Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: [dane] Encoding local parts in better ways 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, 21 Sep 2015 03:55:13 -0000 I've sent in a new version of draft-levine-dns-mailbox-01 that describes a bunch of ways to encode mail address local parts in ways that don't need canonicalization or address guessing. Take a particular look at section 5, which publishes regular expressions to match a domain's mail addresses. * Can represent any plausible local part syntax including case folding, noise characters, multiple ways to write Unicode characters, suffixes where some are ignored and some aren't, BATV, and VERP. * Reasonably fast lookup (max of one query per localpart character) * Works fine with static zones served by ordinary name servers . * Doesn't make bulk addresss harvesting easy. If you really want to do experiments in publishing mail info in the DNS, I think this would be a rather interesting one. R's, John From nobody Mon Sep 21 10:21:37 2015 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 BB7481ACD44 for ; Mon, 21 Sep 2015 10:21:34 -0700 (PDT) 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 5CU-b1UuqcHh for ; Mon, 21 Sep 2015 10:21:33 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99A4B1ACD25 for ; Mon, 21 Sep 2015 10:21:33 -0700 (PDT) Received: (qmail 25005 invoked from network); 21 Sep 2015 17:21:31 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 21 Sep 2015 17:21:31 -0000 Date: 21 Sep 2015 17:21:09 -0000 Message-ID: <20150921172109.19893.qmail@ary.lan> From: "John Levine" To: ietf@ietf.org In-Reply-To: <931830E6-6B8C-410E-9B57-F3E5CB5AE5B8@dukhovni.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: ietf@ietf.org, dane@ietf.org Subject: Re: [dane] PGP security models, was Summary of IETF LC for draft-ietf-dane-openpgpkey 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, 21 Sep 2015 17:21:34 -0000 >OPENPGP is a data format, WoT is one way to employ that format to >exchange messages. It is not a *required* way to use OPENPGP. Sure, but it's the way that everyone has used PGP for 20 years, and it's the security model that everyone I know expects when they use PGP keys. This draft uses a model in which the key is bound to a mailbox, not any stronger identity, and you have to trust that the domain's management fairly represents its users rather than e.g., publishing MITM keys that it controls. That's not a ridiculous model, but if that's the model, the draft and draft-ietf-dane-openpgpkey-usage need to say so. At this point, neither does. R's, John From nobody Mon Sep 21 12:14:45 2015 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 7A6381B3437; Mon, 21 Sep 2015 12:14:41 -0700 (PDT) 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 n7bLeNxtQwwb; Mon, 21 Sep 2015 12:14:40 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2F651A9171; Mon, 21 Sep 2015 12:14:39 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3nKb722q8Qz37k; Mon, 21 Sep 2015 21:14:38 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=sSTbyX8W X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id SupElxhs4gRV; Mon, 21 Sep 2015 21:14:37 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 21 Sep 2015 21:14:37 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 5DD17800B0; Mon, 21 Sep 2015 15:14:36 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1442862876; bh=rcolSVfCyiDaxjpXdbZXwAMmFpqW3/UvaF5hW7k7by0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=sSTbyX8WlUW2N+FZDAFBxw8rQHrXKLTJt0iD5UiJlfLeqntESzMO7Na6lq44P4eTx PgKkSjNX1Pkx1wSR0pSYNRysU5xAQA3ZsflNukko9xc/STKjwswtLleNXLyG27QNfN 0jNqM7QyPuCmQ1eaSnEIm+01nHmU3ONVAfzdSt5g= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.2/8.15.2/Submit) with ESMTP id t8LJEaK0001150; Mon, 21 Sep 2015 15:14:36 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 21 Sep 2015 15:14:36 -0400 (EDT) From: Paul Wouters To: ietf@ietf.org In-Reply-To: <20150921172109.19893.qmail@ary.lan> Message-ID: References: <20150921172109.19893.qmail@ary.lan> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Cc: dane WG list Subject: Re: [dane] PGP security models, was Summary of IETF LC for draft-ietf-dane-openpgpkey 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, 21 Sep 2015 19:14:41 -0000 On Mon, 21 Sep 2015, John Levine wrote: >> OPENPGP is a data format, WoT is one way to employ that format to >> exchange messages. It is not a *required* way to use OPENPGP. > > Sure, but it's the way that everyone has used PGP for 20 years, > and it's the security model that everyone I know expects when they > use PGP keys. Actually, nmost people I know never use the WoT. They only use keys obtained directly from the person they want to exchange encrypted email with. > This draft uses a model in which the key is bound to a mailbox openpgp keys are bound to ID's, which can ultimately end up in a mailbox but is not required to do so. For instance, the gpg key used to sign fedora21 packages with an openpgp key ID containing "fedora21@fedoraproject.org" might not have any mailbox associated with it. It is merely shared in the DNS under an email address, without a mailbox or valid local-part. > any stronger identity, and you have to trust that the domain's > management fairly represents its users Correct, the domain's management that controls either DNS or SMTP servers, can steal a users email. > That's not a ridiculous model, but if > that's the model, the draft and draft-ietf-dane-openpgpkey-usage need > to say so. At this point, neither does. >From the Introduction: This document specifies a method for publishing and locating OpenPGP public keys in DNS for a specific email address using a new OPENPGPKEY DNS Resource Record. Security is provided via DNSSEC. So your point is made already pretty clear in the introduction already. Security comes from DNSSEC, so whoever controls the domain, controls the publishing of openpgp keys. Section 5.2 also contains some advise. Section 7.4 also mentions this, but not under a section title that makes that very clear. Some clarifications will be made, especially in the security considerations section, to clarify this, based on the IETF LC comments. Thank you, Paul From nobody Mon Sep 21 16:25:34 2015 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 6F6D61ACF60; Mon, 21 Sep 2015 16:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.809 X-Spam-Level: X-Spam-Status: No, score=-2.809 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, NO_DNS_FOR_FROM=0.001, 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 i4cJ6EAyxbwj; Mon, 21 Sep 2015 16:24:53 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id 279D71ACF56; Mon, 21 Sep 2015 16:24:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by vacation.karoshi.com (Postfix) with ESMTP id F0C07BFCC08; Mon, 21 Sep 2015 16:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at karoshi.com Received: from vacation.karoshi.com ([127.0.0.1]) by localhost (vacation.karoshi.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLSYmu97ChoD; Mon, 21 Sep 2015 16:23:58 -0700 (PDT) Received: from [198.32.4.206] (unknown [198.32.4.206]) by vacation.karoshi.com (Postfix) with ESMTPSA id 02F09BFCBFE; Mon, 21 Sep 2015 16:23:57 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=us-ascii From: manning In-Reply-To: Date: Mon, 21 Sep 2015 16:24:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150921172109.19893.qmail@ary.lan> To: Paul Wouters X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: ietf@ietf.org, dane WG list Subject: Re: [dane] PGP security models, was Summary of IETF LC for draft-ietf-dane-openpgpkey 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, 21 Sep 2015 23:25:28 -0000 I think Paul nails it, at least for the more aware folks around. Using = the WoT to gauge anything other than confidence in choice of = friends/associates is asking for trouble. See Also: Robin Sage : en.wikipedia.org/wiki/Robin_Sage manning bmanning@karoshi.com PO Box 6151 Playa del Rey, CA 90296 310.322.8102 On 21September2015Monday, at 12:14, Paul Wouters wrote: > On Mon, 21 Sep 2015, John Levine wrote: >=20 >>> OPENPGP is a data format, WoT is one way to employ that format to >>> exchange messages. It is not a *required* way to use OPENPGP. >>=20 >> Sure, but it's the way that everyone has used PGP for 20 years, >> and it's the security model that everyone I know expects when they >> use PGP keys. >=20 > Actually, nmost people I know never use the WoT. They only use keys > obtained directly from the person they want to exchange encrypted = email > with. >=20 >> This draft uses a model in which the key is bound to a mailbox >=20 > openpgp keys are bound to ID's, which can ultimately end up in a > mailbox but is not required to do so. >=20 > For instance, the gpg key used to sign fedora21 packages with an = openpgp > key ID containing "fedora21@fedoraproject.org" might not have any = mailbox > associated with it. It is merely shared in the DNS under an email = address, > without a mailbox or valid local-part. >=20 >> any stronger identity, and you have to trust that the domain's >> management fairly represents its users >=20 > Correct, the domain's management that controls either DNS or SMTP = servers, > can steal a users email. >=20 >> That's not a ridiculous model, but if >> that's the model, the draft and draft-ietf-dane-openpgpkey-usage need >> to say so. At this point, neither does. >=20 >> =46rom the Introduction: >=20 > This document specifies a method for publishing and > locating OpenPGP public keys in DNS for a specific email address > using a new OPENPGPKEY DNS Resource Record. Security is provided = via > DNSSEC. >=20 > So your point is made already pretty clear in the introduction > already. Security comes from DNSSEC, so whoever controls the domain, > controls the publishing of openpgp keys. >=20 > Section 5.2 also contains some advise. Section 7.4 also mentions this, > but not under a section title that makes that very clear. >=20 > Some clarifications will be made, especially in the security > considerations section, to clarify this, based on the IETF LC = comments. >=20 > Thank you, >=20 > Paul >=20 From nobody Mon Sep 21 16:56:56 2015 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 0EC2C1A923E; Mon, 21 Sep 2015 16:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NO_DNS_FOR_FROM=0.001, 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 2BFHCgq-sqg0; Mon, 21 Sep 2015 16:56:19 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id E62741A92A9; Mon, 21 Sep 2015 16:55:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by vacation.karoshi.com (Postfix) with ESMTP id 1CD5EBFCDAD; Mon, 21 Sep 2015 16:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at karoshi.com Received: from vacation.karoshi.com ([127.0.0.1]) by localhost (vacation.karoshi.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0pU36tbVgD2; Mon, 21 Sep 2015 16:55:28 -0700 (PDT) Received: from [198.32.4.206] (unknown [198.32.4.206]) by vacation.karoshi.com (Postfix) with ESMTPSA id 2C375BFCDA3; Mon, 21 Sep 2015 16:55:28 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: manning In-Reply-To: Date: Mon, 21 Sep 2015 16:55:40 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <51D457C2-974C-4714-BB92-7B9BBA015304@karoshi.com> References: <20150921172109.19893.qmail@ary.lan> To: Manning Bill X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Paul Wouters , ietf@ietf.org, dane WG list Subject: Re: [dane] PGP security models, was Summary of IETF LC for draft-ietf-dane-openpgpkey 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, 21 Sep 2015 23:56:55 -0000 Or, if your just going to nail this to email, its a whole lot easier to = just insert this header.. xkcd.com/1181/ no real need to be fancy and do the actual PGP verification. Takes far = to long. manning bmanning@karoshi.com PO Box 6151 Playa del Rey, CA 90296 310.322.8102 On 21September2015Monday, at 16:24, manning = wrote: > I think Paul nails it, at least for the more aware folks around. = Using the WoT to gauge anything other than confidence in choice of = friends/associates is asking for trouble. > See Also: Robin Sage : en.wikipedia.org/wiki/Robin_Sage >=20 > manning > bmanning@karoshi.com > PO Box 6151 > Playa del Rey, CA 90296 > 310.322.8102 >=20 >=20 >=20 >=20 >=20 >=20 > On 21September2015Monday, at 12:14, Paul Wouters = wrote: >=20 >> On Mon, 21 Sep 2015, John Levine wrote: >>=20 >>>> OPENPGP is a data format, WoT is one way to employ that format to >>>> exchange messages. It is not a *required* way to use OPENPGP. >>>=20 >>> Sure, but it's the way that everyone has used PGP for 20 years, >>> and it's the security model that everyone I know expects when they >>> use PGP keys. >>=20 >> Actually, nmost people I know never use the WoT. They only use keys >> obtained directly from the person they want to exchange encrypted = email >> with. >>=20 >>> This draft uses a model in which the key is bound to a mailbox >>=20 >> openpgp keys are bound to ID's, which can ultimately end up in a >> mailbox but is not required to do so. >>=20 >> For instance, the gpg key used to sign fedora21 packages with an = openpgp >> key ID containing "fedora21@fedoraproject.org" might not have any = mailbox >> associated with it. It is merely shared in the DNS under an email = address, >> without a mailbox or valid local-part. >>=20 >>> any stronger identity, and you have to trust that the domain's >>> management fairly represents its users >>=20 >> Correct, the domain's management that controls either DNS or SMTP = servers, >> can steal a users email. >>=20 >>> That's not a ridiculous model, but if >>> that's the model, the draft and draft-ietf-dane-openpgpkey-usage = need >>> to say so. At this point, neither does. >>=20 >>> =46rom the Introduction: >>=20 >> This document specifies a method for publishing and >> locating OpenPGP public keys in DNS for a specific email address >> using a new OPENPGPKEY DNS Resource Record. Security is provided = via >> DNSSEC. >>=20 >> So your point is made already pretty clear in the introduction >> already. Security comes from DNSSEC, so whoever controls the domain, >> controls the publishing of openpgp keys. >>=20 >> Section 5.2 also contains some advise. Section 7.4 also mentions = this, >> but not under a section title that makes that very clear. >>=20 >> Some clarifications will be made, especially in the security >> considerations section, to clarify this, based on the IETF LC = comments. >>=20 >> Thank you, >>=20 >> Paul >>=20 >=20 From nobody Mon Sep 21 18:25:24 2015 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 5C8F31AD1EE; Mon, 21 Sep 2015 18:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 S10VpekHsGvy; Mon, 21 Sep 2015 18:25:18 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38CA61AD1EC; Mon, 21 Sep 2015 18:25:18 -0700 (PDT) Received: from [10.225.121.139] (mobile-166-173-248-210.mycingular.net [166.173.248.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id B4E95C405C5; Mon, 21 Sep 2015 20:25:15 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1442885116; bh=8O2Lwo99eteOW0VHdrKM7D1z9Yfvt7TNhX8iq/x6hD8=; h=In-Reply-To:References:Subject:From:Date:To:From; b=KIL4bM3AhnWf23z/9O10aHoqLtzEOEfHMVmFZg++Pkk6r7sn3fJpLCYhAx164Uc6M TSvdZVLM7ON+mMc5Z8DuZu4tr2ehKzZZUWne3koom0V8ftgUqOlRYOCg2PYhK0+WL7 vOqEWzexRX6ULvIwZS3gaDUlTNMdtyssF7XsfQDs= User-Agent: K-9 Mail for Android In-Reply-To: References: <20150921172109.19893.qmail@ary.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Mon, 21 Sep 2015 18:58:43 -0500 To: ietf@ietf.org,dane WG list Message-ID: <356DD678-92FD-4B7B-8204-B25B24CBF536@kitterman.com> Archived-At: Subject: Re: [dane] PGP security models, was Summary of IETF LC for draft-ietf-dane-openpgpkey 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, 22 Sep 2015 01:25:22 -0000 Nonsense. No security model is perfect. Claiming social media connections and gpg signatures are the same thing is a logical fallacy. Personally, I've known people for year on line, but would never sign someone's key without meeting them in person. Complete apples and oranges comparison. Myself, I always have gotten keys from a keyserver, never directly from the party using the key. Scott K On September 21, 2015 7:24:10 PM EDT, manning wrote: >I think Paul nails it, at least for the more aware folks around. Using >the WoT to gauge anything other than confidence in choice of >friends/associates is asking for trouble. >See Also: Robin Sage : en.wikipedia.org/wiki/Robin_Sage > >manning >bmanning@karoshi.com >PO Box 6151 >Playa del Rey, CA 90296 >310.322.8102 > > > > > > >On 21September2015Monday, at 12:14, Paul Wouters >wrote: > >> On Mon, 21 Sep 2015, John Levine wrote: >> >>>> OPENPGP is a data format, WoT is one way to employ that format to >>>> exchange messages. It is not a *required* way to use OPENPGP. >>> >>> Sure, but it's the way that everyone has used PGP for 20 years, >>> and it's the security model that everyone I know expects when they >>> use PGP keys. >> >> Actually, nmost people I know never use the WoT. They only use keys >> obtained directly from the person they want to exchange encrypted >email >> with. >> >>> This draft uses a model in which the key is bound to a mailbox >> >> openpgp keys are bound to ID's, which can ultimately end up in a >> mailbox but is not required to do so. >> >> For instance, the gpg key used to sign fedora21 packages with an >openpgp >> key ID containing "fedora21@fedoraproject.org" might not have any >mailbox >> associated with it. It is merely shared in the DNS under an email >address, >> without a mailbox or valid local-part. >> >>> any stronger identity, and you have to trust that the domain's >>> management fairly represents its users >> >> Correct, the domain's management that controls either DNS or SMTP >servers, >> can steal a users email. >> >>> That's not a ridiculous model, but if >>> that's the model, the draft and draft-ietf-dane-openpgpkey-usage >need >>> to say so. At this point, neither does. >> >>> From the Introduction: >> >> This document specifies a method for publishing and >> locating OpenPGP public keys in DNS for a specific email address >> using a new OPENPGPKEY DNS Resource Record. Security is provided >via >> DNSSEC. >> >> So your point is made already pretty clear in the introduction >> already. Security comes from DNSSEC, so whoever controls the domain, >> controls the publishing of openpgp keys. >> >> Section 5.2 also contains some advise. Section 7.4 also mentions >this, >> but not under a section title that makes that very clear. >> >> Some clarifications will be made, especially in the security >> considerations section, to clarify this, based on the IETF LC >comments. >> >> Thank you, >> >> Paul >> From nobody Tue Sep 22 07:12:26 2015 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 0B2F01A884E; Tue, 22 Sep 2015 07:12:23 -0700 (PDT) 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 WbCDX0-1Q-xe; Tue, 22 Sep 2015 07:12:21 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 907291A884D; Tue, 22 Sep 2015 07:12:21 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ZeOIt-000Mum-2z; Tue, 22 Sep 2015 10:12:19 -0400 Date: Tue, 22 Sep 2015 10:12:14 -0400 From: John C Klensin To: Paul Wouters , ietf@ietf.org Message-ID: <754374D2DB528FC99BE470A8@JcK-HP8200.jck.com> In-Reply-To: References: <20150921172109.19893.qmail@ary.lan> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: dane WG list Subject: Re: [dane] PGP security models, was Summary of IETF LC for draft-ietf-dane-openpgpkey 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, 22 Sep 2015 14:12:23 -0000 --On Monday, September 21, 2015 15:14 -0400 Paul Wouters wrote: >> Sure, but it's the way that everyone has used PGP for 20 >> years, and it's the security model that everyone I know >> expects when they use PGP keys. > > Actually, nmost people I know never use the WoT. They only use > keys > obtained directly from the person they want to exchange > encrypted email with. Paul, I have no doubt that is true, but I think it has a lot to do with Harald's comments about tools and George's comments about models. First, I know a lot of people who insist on keys who are handed to them directly (or mailed with in-person or other out of band transfer and verification of fingerprints). I know almost as many who almost exclusively pull things off keyservers. Especially with those tools that will not allow using a key unless if bears one's personal signature (even if non-exportable), all of those keys are incorporated into that individual's WOT, even if the key is a self-signed one obtained from a keyserver that no person who understood the issues and was sane would rely upon. Consequently, "never use the WOT" either involves a different definition than I've used or I don't understand what it means. Whether those "who to trust and why" decisions are wise or not is another matter (and I think closer to George's concerns). However, if you believe that, because of trust issues, people get keys only from personal contacts rather than indirectly from public databases, why are we discussing yet another public database-based approach? Or are you convinced that the problem with the other public databases is that the DNS is inherently better for some reason such as the inability of third parties not associated with the domain in the address to add keys? Or that the DNS is somehow, inherently, the One True Database to Rule Them All for the Internet? (That is, of course, another variation of my desire that the next version of the document be much more clear about the problem(s) it is trying to solve.) john From nobody Tue Sep 22 07:44:22 2015 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 91AB41A8ABE for ; Tue, 22 Sep 2015 07:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=unavailable 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 GHQrtb6QeE6l for ; Tue, 22 Sep 2015 07:44:19 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B0231A8ABD for ; Tue, 22 Sep 2015 07:44:19 -0700 (PDT) Received: by qkfq186 with SMTP id q186so4735047qkf.1 for ; Tue, 22 Sep 2015 07:44:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-type; bh=qw+9PWZe5+XOezsrg5XGag5V9replWVlrplb0KxgzXo=; b=KfVWhWzlaY4VK+z5jq6vn0C4bbFRGEdm2xBQDjGJLp3MKG1lrMi2SHz3HfugI8VaEG OzxGOLGaRFWCccZpCH5NYcDe+GTWnB7FOY7JJZkMYtYgkoxC+c0qGr4wXwPwuY8hZzao 7r9monl/05ggntBQRC0+F+4OsSDz82AcLbV4Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-type; bh=qw+9PWZe5+XOezsrg5XGag5V9replWVlrplb0KxgzXo=; b=AgxteLBZx4DJB9cfobJeDws8ZBx1ahexEsKQcMsIJMnfx6zhpqqEwlwUWuDwNx3IZK EGT8GWXwBCBRmV8lqcSdEaR17/VqtnW5YHIbiwKx4iEWDnIgvQZC/1/RejLa9KMva0kW YQQrqpFjbUBXLimc2R6FVB/dsooTz9etlCiOHywLmL9O+peER7NiegmR0lQ7BXcLlrII Uwf2fPjPTF9O8IERUVtkcoLN2hHh5yoJbatteOqNT2b0wpb40kGWG92VKBjax7os6wZ3 b0usO1/id/oTN2eOt1I1icysyfciZo+Wu4siVvjB4IlOqfYVsoK+VEn2JiMmg1Y9CWHo HaUQ== X-Gm-Message-State: ALoCoQk0yJ9oVm/R7DoMKeX5JBlov70IaJmMSykohRJ3qZbciyhPivHae+RNZUtAPARYbndujQBB X-Received: by 10.55.214.5 with SMTP id t5mr29761925qki.66.1442933058553; Tue, 22 Sep 2015 07:44:18 -0700 (PDT) Received: from [172.16.30.154] (nat-07-mht.dyndns.com. [216.146.45.246]) by smtp.gmail.com with ESMTPSA id 78sm698628qhd.40.2015.09.22.07.44.17 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 22 Sep 2015 07:44:18 -0700 (PDT) From: "Joe Abley" To: "Paul Wouters" Date: Tue, 22 Sep 2015 10:44:07 -0400 Message-ID: In-Reply-To: References: <20150921172109.19893.qmail@ary.lan> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5103) Archived-At: Cc: ietf@ietf.org, dane WG list Subject: Re: [dane] PGP security models, was Summary of IETF LC for draft-ietf-dane-openpgpkey 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, 22 Sep 2015 14:44:20 -0000 Hi Paul, On 21 Sep 2015, at 15:14, Paul Wouters wrote: > On Mon, 21 Sep 2015, John Levine wrote: > >>> OPENPGP is a data format, WoT is one way to employ that format to >>> exchange messages. It is not a *required* way to use OPENPGP. >> >> Sure, but it's the way that everyone has used PGP for 20 years, >> and it's the security model that everyone I know expects when they >> use PGP keys. > > Actually, nmost people I know never use the WoT. They only use keys > obtained directly from the person they want to exchange encrypted > email > with. I think most people who use any trust model use the WoT, because that's what the common implementations make easy. I think most people don't use any useful trust model, though. I see a lot of "send me your public key in plain text so I can talk privately about this thing", but no appreciation for the threat models in such a key exchange. Joe From nobody Tue Sep 22 08:11:24 2015 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 BE5D81A90E1; Tue, 22 Sep 2015 08:11:21 -0700 (PDT) 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 zQlHRLNzRHVd; Tue, 22 Sep 2015 08:11:20 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1107B1A9240; Tue, 22 Sep 2015 08:11:16 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3nL5gk1hSbz3CT; Tue, 22 Sep 2015 17:11:14 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=OQPLq3vs X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 2_HCdIXJkZrU; Tue, 22 Sep 2015 17:11:13 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 22 Sep 2015 17:11:13 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 87B49800B0; Tue, 22 Sep 2015 11:11:12 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1442934672; bh=KfuxHPDRAXR07a6xHGTSHZpFBLqGhn1UKPaFyShu8hs=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=OQPLq3vsdHo7UJXbZusJRKoviBTwVqZV6SrYkkVAh42W+Ogr+kfvQP0cOHuAaQi+D PnKXQ1siEIkV0efHODiKA0Pa9wJuZZ50FstsIvXTw5gGTwxwafLM7hcFLoB94M0fbO CzFbr6o6EAKHrCIii8xvEqfIl0TCke/U6IOKgpxw= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.2/8.15.2/Submit) with ESMTP id t8MFBBjU005820; Tue, 22 Sep 2015 11:11:12 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 22 Sep 2015 11:11:11 -0400 (EDT) From: Paul Wouters To: John C Klensin In-Reply-To: <754374D2DB528FC99BE470A8@JcK-HP8200.jck.com> Message-ID: References: <20150921172109.19893.qmail@ary.lan> <754374D2DB528FC99BE470A8@JcK-HP8200.jck.com> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: ietf@ietf.org, dane WG list Subject: Re: [dane] PGP security models, was Summary of IETF LC for draft-ietf-dane-openpgpkey 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, 22 Sep 2015 15:11:21 -0000 On Tue, 22 Sep 2015, John C Klensin wrote: > However, if you believe that, because of trust issues, people > get keys only from personal contacts rather than indirectly from > public databases, why are we discussing yet another public > database-based approach? Or are you convinced that the problem > with the other public databases is that the DNS is inherently > better for some reason such as the inability of third parties > not associated with the domain in the address to add keys? Yes. The other common use problem is not being able to delete keys, so you end up using a keyserver, get a (verified by WoT) key and then in response you get a plaintext message saying "I forgot my passphrase so i cannot delete/revoke my old key". With DNS, you can remove the key from DNS without needing the private key or passphrase to it. Paul From nobody Tue Sep 22 13:11:50 2015 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 20FC61B2D42 for ; Tue, 22 Sep 2015 13:11:49 -0700 (PDT) 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 m3uPcjTobv3p for ; Tue, 22 Sep 2015 13:11:48 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5E411B2D40 for ; Tue, 22 Sep 2015 13:11:47 -0700 (PDT) Received: (qmail 8587 invoked from network); 22 Sep 2015 20:11:46 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 22 Sep 2015 20:11:46 -0000 Date: 22 Sep 2015 20:11:24 -0000 Message-ID: <20150922201124.4334.qmail@ary.lan> From: "John Levine" To: dane@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dane] provisioning assumptions, was PGP security models, was Summary 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, 22 Sep 2015 20:11:49 -0000 >The other common use problem is not being able to delete keys, so you end >up using a keyserver, get a (verified by WoT) key and then in response >you get a plaintext message saying "I forgot my passphrase so i cannot >delete/revoke my old key". With DNS, you can remove the key from DNS >without needing the private key or passphrase to it. There's a whole bunch of unsupported assumptions here about how mail and DNS provisioning systems work. While there's often a way to recover your account if you lose your password, at large mail systems they don't work very well, particularly if the account's been compromised and taken over by a bad guy, which happens thousands of times a day. (I know people at Yahoo whose full time jobs are to deal with this.) Even without a compromise, it's often more hassle than it's worth to recover the account, so you create a new one and the old one sits there unused--that's why I'm jrlevine2@yahoo.com rather than jrlevine. Also, this introduces a downgrade attack. User creates a key, gets lots of WoT signatures, publishes it through key servers and DANE. Bad guy takes over the account, publishes a new key with no signatures. According to sec 5.2 of the draft, a mail sender looks up the key, finds they disagree, and the verification fails. Now what? The draft suggests dumping the question on the MUA user, which we know is never a good idea. As likely as not a naive user would pick the newer key, the one that says "USE THIS KEY OLD ONE WAS STOLEN." Finally, if the problem with existing key servers is that they won't delete dead keys, that does not strike me as an insoluble problem. Talk to the people who run them, suggest they add an "it's dead" button that sends a confirmation message to the address in the key and when confirmed, deletes the key. The security risk is small, it is just as secure as the DANE approach (with the advantage that existing PGP clients work unchanged), and we're all done. R's, John From nobody Tue Sep 22 13:47:28 2015 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 A2E2B1B2DDA for ; Tue, 22 Sep 2015 13:47:26 -0700 (PDT) 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 hsH_tMoXo03k for ; Tue, 22 Sep 2015 13:47:24 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 965591B2DD9 for ; Tue, 22 Sep 2015 13:47:24 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3nLF7X50YZz3QZ for ; Tue, 22 Sep 2015 22:47:20 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=XD4bXteS X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id BTyyoG5PB9ZF for ; Tue, 22 Sep 2015 22:47:19 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Tue, 22 Sep 2015 22:47:19 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 97719800AD for ; Tue, 22 Sep 2015 16:47:18 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1442954838; bh=o9UP9LH5lwavLR7txjN3hEs20nnwF4qNv93pc9F2iok=; h=Date:From:To:Subject:In-Reply-To:References; b=XD4bXteS/8zFGelyv15jA00wP0FZd1IQ18oVJiOMJlAnEnDzAE3cpandcL/RLZXN2 jpE88YOZgQOjXO5oP3LGOIpiJ08ej88FCBmSgvbpRvkPnTe0mEKtnHiyfX+rTp+DY7 UieUo0psRkFMyWrdGld3DPS1LUeSHUuMlKgE60Dk= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.2/8.15.2/Submit) with ESMTP id t8MKlIBv030834 for ; Tue, 22 Sep 2015 16:47:18 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 22 Sep 2015 16:47:18 -0400 (EDT) From: Paul Wouters To: dane WG list In-Reply-To: <20150922201124.4334.qmail@ary.lan> Message-ID: References: <20150922201124.4334.qmail@ary.lan> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dane] provisioning assumptions, was PGP security models, was Summary 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, 22 Sep 2015 20:47:26 -0000 On Tue, 22 Sep 2015, John Levine wrote: > Also, this introduces a downgrade attack. User creates a key, gets > lots of WoT signatures, publishes it through key servers and DANE. > Bad guy takes over the account, publishes a new key with no > signatures. According to sec 5.2 of the draft, a mail sender looks up > the key, finds they disagree, and the verification fails. Now what? > The draft suggests dumping the question on the MUA user, which we know > is never a good idea. As likely as not a naive user would pick the > newer key, the one that says "USE THIS KEY OLD ONE WAS STOLEN." The attacker already receives all email to the stolen account. And can reset all services that require only email verification for a password reset. This is pretty identical to the situation where you do not use DNS and the attacker takes over the email account and mails all address book entries a new PGP key. If encryption is required for life saving, and you are confronted with a new key, then you better check either with the person or at the minimum check it was signed with the old known key. The fact that you pull a new key from DNS versus a new key from a keyserver is irrelevant to this. > Finally, if the problem with existing key servers is that they won't > delete dead keys, that does not strike me as an insoluble problem. > Talk to the people who run them Please do. But it is out of scope for this draft that is specifying a different method of publishing your openpgp keys. > and we're all done. That's your goal, not the goal of the dane working group when they adopted this draft. Paul From nobody Tue Sep 22 20:45:09 2015 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 D4B6B1B3138; Tue, 22 Sep 2015 20:45:06 -0700 (PDT) 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 1JTLqhjUkEAx; Tue, 22 Sep 2015 20:45:05 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A62A1B312B; Tue, 22 Sep 2015 20:45:05 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1ZeazM-0000JU-FL; Wed, 23 Sep 2015 03:45:01 +0000 Date: Wed, 23 Sep 2015 09:44:57 +0600 Message-ID: From: Randy Bush To: Paul Wouters In-Reply-To: <356DD678-92FD-4B7B-8204-B25B24CBF536@kitterman.com> <5600FC4D.9010904@alvestrand.no> References: <20150921172109.19893.qmail@ary.lan> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: ietf@ietf.org, dane WG list Subject: Re: [dane] PGP security models, was Summary of IETF LC for draft-ietf-dane-openpgpkey X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2015 03:45:07 -0000 Paul Wouters wrote: > Actually, nmost people I know never use the WoT. They only use keys > obtained directly from the person they want to exchange encrypted email > with. this is not my experience it will be a long time before i trust a dane/dnssec identity binding over pgp's. At Mon, 21 Sep 2015 16:24:10 -0700, Bill Manning wrote: > I think Paul nails it, at least for the more aware folks around. > Using the WoT to gauge anything other than confidence in choice of > friends/associates is asking for trouble. i think bill nails it. trust in identity is what it is about for me. i am communicating with a person, not a dns or smtp server; the latter are agents, and ones which have failed repeatedly over the decades. using one hierarchy to reinforce the weaknesses of another may increase reliability (or fragility), which is good. it does not increase trust in identity. At Mon, 21 Sep 2015 18:58:43 -0500, Scott Kitterman wrote: > Personally, I've known people for year on line, but would never sign > someone's key without meeting them in person. bingo! and seeing a high level out of band assertion of identy such as a passport. At Tue, 22 Sep 2015 08:59:25 +0200, Harald Tveit Alvestrand wrote: > it's been obvious to me since the 90s that the hierarchical models of > trust (CAs, corp signing authorities) are simply restricted webs of > trust. So the WoT model is a more general one than the hierarchical one: > you can represent hierarchy as a WoT (the user trusts the root keys, > trust flows from there), but not vice versa. bingo! > I've been saddened by the crippled state of WoT-manipulating user > interfaces since roughly forever. but x.509 and dns end user tools are sooo much better :) > I believe the Web of Trust has a great potential as a basis on which to > represent many different trust policies. But the current state of tools > to interrogate and update a trustdb according to those policies is > simply not fit for the task. the state of tools for the entire trust and identity ecosystem sucks. and we are spending our time mucking below the waterline. to a dns/dane hammer, everything looks like a nail. a solution looking for a problem. At Tue, 22 Sep 2015 13:55:22 -0400, Phillip Hallam-Baker wrote: > A few months back I realized that I had the criteria wrong. It is even > tougher than 'do no harm'. To get people using strong crypto you have > to do better than not making things any worse. You have to make life > easier for the user. 'cept we're not doing that. while i am still digging through your latest, at least you're talking about some parts of the elephant that i perceive. At Tue, 22 Sep 2015 11:11:11 -0400 (EDT), Paul Wouters wrote: > With DNS, you can remove the key from DNS without needing the private > key or passphrase to it. is this a feature or a bug? good discussion in acme about having the credentialials to add/change/delete. in current pgp, if you think you may ever want to revoke, gen a revocation credential. in all these worlds, you need credentials to change or negate; to do otherwise is a big vulnerability. randy From nobody Tue Sep 22 20:57:38 2015 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 A86451A8872; Tue, 22 Sep 2015 20:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 J44CKSelhpeq; Tue, 22 Sep 2015 20:57:33 -0700 (PDT) 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 F3E801B3143; Tue, 22 Sep 2015 20:57:32 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 9EC9A28494F; Wed, 23 Sep 2015 03:57:31 +0000 (UTC) Date: Wed, 23 Sep 2015 03:57:31 +0000 From: Viktor Dukhovni To: dane@ietf.org, ietf@ietf.org Message-ID: <20150923035731.GZ21942@mournblade.imrryr.org> References: <20150921172109.19893.qmail@ary.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [dane] PGP security models, was Summary of IETF LC for draft-ietf-dane-openpgpkey X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ietf@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, 23 Sep 2015 03:57:34 -0000 On Wed, Sep 23, 2015 at 09:44:57AM +0600, Randy Bush wrote: > Paul Wouters wrote: > > > Actually, nmost people I know never use the WoT. They only use keys > > obtained directly from the person they want to exchange encrypted email > > with. > > this is not my experience > > it will be a long time before i trust a dane/dnssec identity binding > over pgp's. > > At Mon, 21 Sep 2015 16:24:10 -0700, Bill Manning wrote: > > > I think Paul nails it, at least for the more aware folks around. > > Using the WoT to gauge anything other than confidence in choice of > > friends/associates is asking for trouble. > > i think bill nails it. trust in identity is what it is about for me. > i am communicating with a person, not a dns or smtp server; the latter > are agents, and ones which have failed repeatedly over the decades. We'll likely never meet in person. You have a sensitive message to send me about Postfix or OpenSSL or something like that. Now what? Or more likely you have nothing sensitive to send me at all, but prefer not to have your communications routinely intercepted or stored in the clear. Now what? The draft strives to make PGP scale, with an inevitable trade-off in identity assurance. The security needs of covert-agents are not the same as the security needs of most ordinary citizens. Folks who want "covert agent security" need to know what tools and systems they can't avoid trusting (a trusted party is one that can betray you), and then, if they are careful, avoid trusting everything/everyone else. The rest of us need to make reasonable compromises, that protect most of us most of the time, ideally keeping Orwellian nightmares in check. -- Viktor. From nobody Wed Sep 23 01:12:44 2015 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 86D531A9027; Wed, 23 Sep 2015 01:12:43 -0700 (PDT) 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 VthKC6gljDgs; Wed, 23 Sep 2015 01:12:42 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B3FE1A900B; Wed, 23 Sep 2015 01:12:42 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1ZefAO-0001Ch-CD; Wed, 23 Sep 2015 08:12:40 +0000 Date: Wed, 23 Sep 2015 14:12:37 +0600 Message-ID: From: Randy Bush To: Viktor Dukhovni In-Reply-To: <20150923035731.GZ21942@mournblade.imrryr.org> References: <20150921172109.19893.qmail@ary.lan> <20150923035731.GZ21942@mournblade.imrryr.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: ietf@ietf.org, dane@ietf.org Subject: Re: [dane] PGP security models, was Summary of IETF LC for draft-ietf-dane-openpgpkey X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2015 08:12:43 -0000 > We'll likely never meet in person. You have a sensitive message to > send me about Postfix or OpenSSL or something like that. Now what? > > Or more likely you have nothing sensitive to send me at all, but > prefer not to have your communications routinely intercepted or stored > in the clear. Now what? > > The draft strives to make PGP scale, with an inevitable trade-off in > identity assurance. The security needs of covert-agents are not the > same as the security needs of most ordinary citizens. if i think of it as a form of opportunistic encryption with very weak authentication it seems useful. but when i want strong authentication i want strong introduction. randy From nobody Wed Sep 23 08:29:10 2015 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 318021A7005; Wed, 23 Sep 2015 08:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] 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 OOyov-pnvRKI; Wed, 23 Sep 2015 08:29:08 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A9681A6FFD; Wed, 23 Sep 2015 08:29:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 1B2DB20809; Wed, 23 Sep 2015 11:28:29 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bg3m32yWeNgL; Wed, 23 Sep 2015 11:28:28 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-136-30-120.hsd1.ma.comcast.net [50.136.30.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Wed, 23 Sep 2015 11:28:28 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4FD0E80CE0; Wed, 23 Sep 2015 11:29:05 -0400 (EDT) From: Sam Hartman To: Randy Bush References: <20150921172109.19893.qmail@ary.lan> <20150923035731.GZ21942@mournblade.imrryr.org> Date: Wed, 23 Sep 2015 11:29:05 -0400 In-Reply-To: (Randy Bush's message of "Wed, 23 Sep 2015 14:12:37 +0600") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: dane@ietf.org, ietf@ietf.org Subject: Re: [dane] PGP security models, was Summary of IETF LC for draft-ietf-dane-openpgpkey X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2015 15:29:09 -0000 My take here is that there are a lot of different thoughts about trust models, and as such, I tend to agree with John and others who have suggested the document should be more clear about its assumptions. From nobody Wed Sep 23 08:36:33 2015 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 54A611A6FD1; Wed, 23 Sep 2015 08:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 p6KBx8IFR7gh; Wed, 23 Sep 2015 08:36:21 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 792CC1A700F; Wed, 23 Sep 2015 08:35:47 -0700 (PDT) Received: from [192.168.1.87] (76-218-10-206.lightspeed.sntcca.sbcglobal.net [76.218.10.206]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t8NFZkGB015898 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 23 Sep 2015 08:35:47 -0700 To: Sam Hartman , Randy Bush References: <20150921172109.19893.qmail@ary.lan> <20150923035731.GZ21942@mournblade.imrryr.org> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <5602C6CD.2050200@dcrocker.net> Date: Wed, 23 Sep 2015 08:35:41 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 23 Sep 2015 08:35:47 -0700 (PDT) Archived-At: Cc: ietf@ietf.org, dane@ietf.org Subject: Re: [dane] PGP security models, was Summary of IETF LC for draft-ietf-dane-openpgpkey X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2015 15:36:22 -0000 On 9/23/2015 8:29 AM, Sam Hartman wrote: > I tend to agree with John and others who have > suggested the document should be more clear about its assumptions. Assumptions, models, details, etc., with operational and risk implications. The document has a number of places that need considerable elaboration of these. In the case of the trust model, the document is, apparently, introducing an entirely new 'model'. As has been noted, the challenge of local-part handling is another, surprisingly-basic component to the mechanism that needs careful -- and complete -- handling in the spec, if the spec is to be a full protocol specification. And so on. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Sep 23 09:01:27 2015 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 6D4C11A8716; Wed, 23 Sep 2015 09:01:24 -0700 (PDT) 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 Yp2jXXdjSbfU; Wed, 23 Sep 2015 09:01:22 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67F071A8712; Wed, 23 Sep 2015 09:01:22 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3nLkl36W6jz3Qk; Wed, 23 Sep 2015 18:01:19 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=E2pUecaH X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id tIXwOlYoLrLJ; Wed, 23 Sep 2015 18:01:18 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 23 Sep 2015 18:01:18 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 7D2878009F; Wed, 23 Sep 2015 12:01:17 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1443024077; bh=AVFVmEiRdqGOsuY6M9hVPZeKVOAJgVvXamHoRpmtAPI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=E2pUecaH2peIL2ttkIo3hUE9+iGAfH4NRHMoRbAdDumbOHtaZuDkwiX3FgnG+/rHf o338wyKJEY6Eh/YP09gEQ9xNVbngD6wDqdpsx0u75kZc+PxJ0Fs2nOvp/stMxvfNxs 28ymWvWydalHmKWQRX7Fichm+MG7+hXqXZ43/JWI= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.2/8.15.2/Submit) with ESMTP id t8NG1Gu4009735; Wed, 23 Sep 2015 12:01:17 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Wed, 23 Sep 2015 12:01:16 -0400 (EDT) From: Paul Wouters To: Randy Bush In-Reply-To: Message-ID: References: <20150921172109.19893.qmail@ary.lan> <20150923035731.GZ21942@mournblade.imrryr.org> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: ietf@ietf.org, dane WG list Subject: Re: [dane] PGP security models, was Summary of IETF LC for draft-ietf-dane-openpgpkey X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2015 16:01:24 -0000 On Wed, 23 Sep 2015, Randy Bush wrote: > if i think of it as a form of opportunistic encryption with very weak > authentication it seems useful. right. > but when i want strong authentication i want strong introduction. So pull the key from DNSSEC, check for sigs. If not good enough, you could also pull the same key from the keyservers (now that you know that's the key you are looking for in the pile of garbage keys on the keyservers) and possibly get more signatures on it. Still not good enough, don't send the email and find some humans. Paul From nobody Wed Sep 23 09:07:27 2015 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 8FDAF1A87AD; Wed, 23 Sep 2015 09:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] 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 pGY3LHQ4jdzN; Wed, 23 Sep 2015 09:07:25 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4E331A879F; Wed, 23 Sep 2015 09:07:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 747AC2080C; Wed, 23 Sep 2015 12:06:47 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cs5XLkKJauMZ; Wed, 23 Sep 2015 12:06:47 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-136-30-120.hsd1.ma.comcast.net [50.136.30.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Wed, 23 Sep 2015 12:06:47 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id BD94080CE0; Wed, 23 Sep 2015 12:07:23 -0400 (EDT) From: Sam Hartman To: dcrocker@bbiw.net References: <20150921172109.19893.qmail@ary.lan> <20150923035731.GZ21942@mournblade.imrryr.org> <5602C6CD.2050200@dcrocker.net> Date: Wed, 23 Sep 2015 12:07:23 -0400 In-Reply-To: <5602C6CD.2050200@dcrocker.net> (Dave Crocker's message of "Wed, 23 Sep 2015 08:35:41 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: Randy Bush , Sam Hartman , ietf@ietf.org, dane@ietf.org Subject: Re: [dane] PGP security models, was Summary of IETF LC for draft-ietf-dane-openpgpkey X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2015 16:07:26 -0000 >>>>> "Dave" == Dave Crocker writes: Dave> On 9/23/2015 8:29 AM, Sam Hartman wrote: >> I tend to agree with John and others who have suggested the >> document should be more clear about its assumptions. Dave> Assumptions, models, details, etc., with operational and risk Dave> implications. Hi, Dave. It would be easy to read the above as trying to restate my position to be broader than I intended. I'm specifically supporting the idea that the document should clearly state its trust model. I understand other comments have been made; I'm not expressing an opinion on those. From nobody Wed Sep 23 09:50:08 2015 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 CB8A21A702B; Wed, 23 Sep 2015 09:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 1wADIZPCDJOS; Wed, 23 Sep 2015 09:50:03 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C806A1A7028; Wed, 23 Sep 2015 09:50:03 -0700 (PDT) Received: from [192.168.1.87] (76-218-10-206.lightspeed.sntcca.sbcglobal.net [76.218.10.206]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t8NGo3bY019452 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 23 Sep 2015 09:50:03 -0700 To: Sam Hartman References: <20150921172109.19893.qmail@ary.lan> <20150923035731.GZ21942@mournblade.imrryr.org> <5602C6CD.2050200@dcrocker.net> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <5602D835.9070305@dcrocker.net> Date: Wed, 23 Sep 2015 09:49:57 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 23 Sep 2015 09:50:03 -0700 (PDT) Archived-At: Cc: ietf@ietf.org, dane@ietf.org Subject: Re: [dane] PGP security models, was Summary of IETF LC for draft-ietf-dane-openpgpkey X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2015 16:50:05 -0000 On 9/23/2015 9:07 AM, Sam Hartman wrote: >>>>>> "Dave" == Dave Crocker writes: > Dave> On 9/23/2015 8:29 AM, Sam Hartman wrote: > >> I tend to agree with John and others who have suggested the > >> document should be more clear about its assumptions. > > Dave> Assumptions, models, details, etc., with operational and risk > Dave> implications. > > Hi, Dave. > It would be easy to read the above as trying to restate my position to > be broader than I intended. > > I'm specifically supporting the idea that the document should clearly > state its trust model. > I understand other comments have been made; I'm not expressing an > opinion on those. My note intended to build from yours, not clarify it. So my note stated my views, and wasn't trying to state yours. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net