From nobody Tue Dec 1 12:23:36 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 08D961B34DC for ; Tue, 1 Dec 2015 12:23:34 -0800 (PST) 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 Jn71e4t5-Mhd for ; Tue, 1 Dec 2015 12:23:33 -0800 (PST) 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 4B7681B34B3 for ; Tue, 1 Dec 2015 12:23:33 -0800 (PST) Received: from [10.32.60.80] (50-1-98-110.dsl.dynamic.fusionbroadband.com [50.1.98.110]) (authenticated bits=0) by hoffman.proper.com (8.15.2/8.14.9) with ESMTPSA id tB1KNWnP006066 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 1 Dec 2015 13:23:32 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-110.dsl.dynamic.fusionbroadband.com [50.1.98.110] claimed to be [10.32.60.80] From: "Paul Hoffman" To: dane@ietf.org Date: Tue, 01 Dec 2015 12:23:31 -0800 Message-ID: <479DFDB1-94C0-478F-B204-34053B850CCC@vpnc.org> In-Reply-To: <22DCFC67-C65D-45E1-A5EB-EC8BD4F887B9@vpnc.org> References: <55D857EA.80107@strotmann.de> <8321AB9D-ADCD-44BD-8A0F-1D6B5CF1971C@ogud.com> <55DC74A3.6060206@posteo.de> <55E82512.2080507@posteo.de> <55E85082.1050008@posteo.de> <22DCFC67-C65D-45E1-A5EB-EC8BD4F887B9@vpnc.org> MIME-Version: 1.0 X-Mailer: MailMate (1.9.3r5187) 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: Tue, 01 Dec 2015 20:23:34 -0000 IANA has registered the following RR Type: SMIMEA 53 S/MIME cert assocication [draft-ietf-dane-smime] Please see http://www.iana.org/assignments/dns-parameters From nobody Tue Dec 1 14:18: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 8C3B71AD0CD for ; Tue, 1 Dec 2015 14:18:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.431 X-Spam-Level: X-Spam-Status: No, score=-3.431 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, 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 LUJJRbMD5OWc for ; Tue, 1 Dec 2015 14:18:17 -0800 (PST) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72BDD1AD0B9 for ; Tue, 1 Dec 2015 14:18:17 -0800 (PST) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Tue, 1 Dec 2015 14:18:15 -0800 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1044.021; Tue, 1 Dec 2015 14:18:15 -0800 From: Richard Lamb To: Paul Hoffman , "dane@ietf.org" Thread-Topic: [dane] DNS-Record type for SMIMEA Thread-Index: AQHQ3MrbmOrBuNpT4UWHSO81lCRL3Z4YfdeAgAS6TYCAADtCgIAAOBIAgAANq4CADW5DAIAALHsAgAAHTQCAACnRAICMM9GA//+ZxPA= Date: Tue, 1 Dec 2015 22:18:15 +0000 Message-ID: <599d7779fe7e49bfb30939c610536393@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> References: <55D857EA.80107@strotmann.de> <8321AB9D-ADCD-44BD-8A0F-1D6B5CF1971C@ogud.com> <55DC74A3.6060206@posteo.de> <55E82512.2080507@posteo.de> <55E85082.1050008@posteo.de> <22DCFC67-C65D-45E1-A5EB-EC8BD4F887B9@vpnc.org> <479DFDB1-94C0-478F-B204-34053B850CCC@vpnc.org> In-Reply-To: <479DFDB1-94C0-478F-B204-34053B850CCC@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Tue, 01 Dec 2015 22:18:19 -0000 Yippie.. that what all my test systems are using now. Thanks. -R -----Original Message----- From: dane [mailto:dane-bounces@ietf.org] On Behalf Of Paul Hoffman Sent: Tuesday, December 1, 2015 12:24 PM To: dane@ietf.org Subject: Re: [dane] DNS-Record type for SMIMEA IANA has registered the following RR Type: SMIMEA 53 S/MIME cert assocication [draft-ietf-dane-smime] Please see http://www.iana.org/assignments/dns-parameters _______________________________________________ dane mailing list dane@ietf.org https://www.ietf.org/mailman/listinfo/dane From nobody Thu Dec 3 06:40: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 F042E1A8940 for ; Thu, 3 Dec 2015 06:40:45 -0800 (PST) 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 QgJ3pvqz7jyt for ; Thu, 3 Dec 2015 06:40:43 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 978761A893F for ; Thu, 3 Dec 2015 06:40:42 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CEY92462; Thu, 03 Dec 2015 14:40:38 +0000 (GMT) Received: from LHREML504-MBS.china.huawei.com ([10.125.30.107]) by lhreml401-hub.china.huawei.com ([10.201.5.240]) with mapi id 14.03.0235.001; Thu, 3 Dec 2015 14:40:29 +0000 From: Hosnieh Rafiee To: "dane@ietf.org" Thread-Topic: Any comment? Bounding of authentication and authorization Thread-Index: AQHRLdiOWWnWrKl8C0OvSOji5isIiw== Date: Thu, 3 Dec 2015 14:40:29 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A715AFA7CD@lhreml504-mbs> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.204.65.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.56605467.003E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: b200b31f24eacefd9dff90c0c7486891 Archived-At: Subject: [dane] Any comment? Bounding of authentication and authorization 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 Dec 2015 14:40:46 -0000 Anybody had a chance to take a look on this? Any comment?=20 > -----Original Message----- > From: DNSOP [mailto:dnsop-bounces@ietf.org] On Behalf Of Hosnieh Rafiee > Sent: 29 November, 2015 11:52 PM > To: dane@ietf.org > Cc: DNSOP@ietf.org > Subject: [DNSOP] a new draft?? Bounding of authentication and > authorization >=20 > Dear All, >=20 > Before writing a draft (since I have had some unused drafts so far and > ... > do not want to repeat the same mistake...), I would like to know the > opinion of WG on the overview of an idea for the extension of DANE so > that it can be used for other use cases beyond Email and web, > especially for certificates based authentication (known as TLS based > authentication) of single devices in the network where we have DANE as > a complete option in place of PKI model and the first A of AAA model. > In other word, the extension focuses on not only giving the TLSA record > back to the verifier node but also the references of policy templates > in resource policy storage. >=20 >=20 > Let me give you an example to be clearer ( I did not use the real > example so that it can be simpler to avoid the use of network related > concept) In Alice's enterprise, instead of AAA method, we assume that > it is TLS based authentication where authentication is based on the > devices' certificates and not the username and password. Therefore, > DANE is in use as a way to authenticate the Alice's laptop. Alice need > to access business server C and B in her enterprise network after her > laptop is being authenticated. For authentication, Alice can herself > generates a public/private key and self-sign it. then it goes to the > administrator of her enterprise network called Bob to generate the TLSA > record of her certificate and store it in the DNS server so that later > on business server C can verify Alice by query the DNS server. Further, > Bob also creates two new templates in resource policy server and call > them template AliceB and AliceC. Then in AliceB it includes the > authorization access to business server B and in AliceC it defines > Business server C. >=20 > To provide the binding of the Alice template with the authentication > information (certificates), Bob stores the template reference number of > Alice policy in a new resource record so called Parent policy Indices > (PP > RR) on DNS server (This is the extension to DNS to bound the > authentication and authorization). > Now, Alice tries to access business server C, the business server C > asks the certificates of Alice to establish a secure TLS channel. > Alice's laptop submits its certificates to business server C. Business > server C needs to verify this certificates, it queries the DNS server > and asks for TLSA record of Alice. DNS server checks Alice's laptop > FQDN that includes in the query of Business server C and retrieves > Alice's laptop TLSA record. Further it needs to retrieve the > authorization information of Alice's laptop. >=20 > The extension is that business server C also retrieves the reference > numbers that Bob stored it before in PP RR from DNS server along with > TLSA record. > Then it can query the resource policy storage based on this reference > number that is the reference to the Alice template in resource policy > and retrieves the ALiCE's authorization information to make sure Alice > is authorized to use business server C. >=20 > With this simple resource record, we added this bounding of > authentication and authorization. There might be some questions here > such as: >=20 > 1- Why not to store the whole authorization information on DNS server > instead of only storing the reference number > Answer: because at the moment in most network infrastructure, there are > already resource policy servers that stored the authorization > information and it is so costly to restore them all again in a new > place otherwise there is easy way of conversion. > Further, since DNS is usually publicly available to its local network > or global network, therefore, for security reason, not all nodes should > be able to know the content of the authorization information. It might > leak some critical information about the infrastructure and resources > in the network which might be both security and privacy issue. This is > why, only reference number and a small readable human text is enough > for that. >=20 >=20 > 2- Why not to store the TLSA record also in the resource policy so that > the business server C (as in my example) query the resource policy > based on the TLSA record. > By doing that, we limit the DANE use case and it can no longer be used > for some other use cases that we have in our mind for multi-tenancy > where each tenants can create subdomain on its own zone and re-assign > these policies to its sub-domain. > This is because a resource policy usually cannot be shared with the > tenant but DNS power allows a tenant to only access its own zone and > update its own resources. Therefore, this tenant can also create a sub > domain on its own zone and assign a part of its resources to third > parties. In my example, Alice can allow David, her employee to access > business server B but not business server C by updating DNS server with > the TLSA record of David's laptop's certificate and in PP RR adding the > template of business server B (AliceB). Therefore, Alice, without the > need to ask Bob again, could authorize someone else to only access a > part of its authorized resources in the network. >=20 > The concept can be to some extend similar to OAuth, but the difference > is that we want also to reduce CapEx in the network by eliminating the > use of PKI infrastructure and any other extra servers or services and > the idea is to use the existing resources that is supported by almost > all networks for both authentication and authorization purposes. >=20 > As I said the use case is for network infrastructure but it might have > several other use cases that might come to your mind according to my > simple example. It would be good to hear some other use cases and > ideas. >=20 > Therefore, the proposed extension is this PP record and the processes > of this new resource record so that, TLSA and PP are able to be updated > via the DDNS but only by authorized owner, further, PP RR is also given > to the verifier node when a node query the TLSA record in case for > instance, it sets a flag. >=20 > I would love to hear your opinion about this and if you think this > worth to write it as a draft , I would appreciate any volunteers for > that. >=20 > Thank you, > Best, > Hosnieh >=20 >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Fri Dec 4 06:56:11 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 987AC1A8722 for ; Fri, 4 Dec 2015 06:56:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.561 X-Spam-Level: X-Spam-Status: No, score=-0.561 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=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 xK-SJI3MQ8pR for ; Fri, 4 Dec 2015 06:56:08 -0800 (PST) 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 2245B1A8720 for ; Fri, 4 Dec 2015 06:56:07 -0800 (PST) Received: from dovecot03.posteo.de (dovecot03.posteo.de [172.16.0.13]) by mout01.posteo.de (Postfix) with ESMTPS id D8E3A2088A for ; Fri, 4 Dec 2015 15:56:04 +0100 (CET) Received: from mail.posteo.de (localhost [127.0.0.1]) by dovecot03.posteo.de (Postfix) with ESMTPSA id 3pBxtX0jj6z5vN9 for ; Fri, 4 Dec 2015 15:56:03 +0100 (CET) Message-ID: <5661A978.4000901@posteo.de> Date: Fri, 04 Dec 2015 15:55:52 +0100 From: =?windows-1252?Q?Patrik_L=F6hr?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: dane@ietf.org References: <55D857EA.80107@strotmann.de> <8321AB9D-ADCD-44BD-8A0F-1D6B5CF1971C@ogud.com> <55DC74A3.6060206@posteo.de> <55E82512.2080507@posteo.de> <55E85082.1050008@posteo.de> <22DCFC67-C65D-45E1-A5EB-EC8BD4F887B9@vpnc.org> <479DFDB1-94C0-478F-B204-34053B850CCC@vpnc.org> In-Reply-To: <479DFDB1-94C0-478F-B204-34053B850CCC@vpnc.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit 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: Fri, 04 Dec 2015 14:56:10 -0000 Hello Paul and all, Thanks a lot. That was the missing piece for the release of SMIMEA and OPENPGPKEY for our customers. Today we are happy to announce the implementation of these standards, which we hope will soon be accepted: Best regards Patrik Am 01.12.2015 um 21:23 schrieb Paul Hoffman: > IANA has registered the following RR Type: > > SMIMEA 53 S/MIME cert assocication [draft-ietf-dane-smime] > > Please see http://www.iana.org/assignments/dns-parameters > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > -- Patrik Löhr Posteo e.K. Methfesselstr. 38 10965 Berlin tel. +49 30 85074618 mail web USt-IdNr.: DE186713958 Handelsregister: Berlin-Charlottenburg · HRA 47592 B From nobody Fri Dec 4 15:28:23 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 751CB1B3387 for ; Fri, 4 Dec 2015 15:28:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.977 X-Spam-Level: X-Spam-Status: No, score=-0.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d8x5td7ETg01 for ; Fri, 4 Dec 2015 15:28:20 -0800 (PST) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (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 274151B3385 for ; Fri, 4 Dec 2015 15:28:20 -0800 (PST) Received: by pfbg73 with SMTP id g73so33812302pfb.1 for ; Fri, 04 Dec 2015 15:28:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=e9mdkhD73eQ1FvHQ82+mnhuemh5jhgEzRX4a0atDJCQ=; b=a1nbPPDYtSwEbV5570D3wF2I5ORwkixFgr/hRVrXL9LWzjFw6773kAFPSmi7/MFyLA 39kgxkOwrjZMGUvE94gGW71VzSP/yiDWpwWfyoOBoqKzp2U8mzoiEtMCWxJSkE62/e/M j5vKcWJEXDlRRA5/tYolxW+Pd2tHoQc4NnfsrV3vyGmDGNpTzs8apgvogKMEvB5FAjtS CxBv6DRWd+ZaQr0P5q/+cpOi0E8nm6gCy3P4buoJZGV3QFzgXXvo/zbodtOPC7eSO6rB /AlSLPHAFW7hJenDnnim8uwOE/rlNkXBYKVJkYftjgnFQPpc5kfe4TN26/tdQ9a/RSEc DDhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type; bh=e9mdkhD73eQ1FvHQ82+mnhuemh5jhgEzRX4a0atDJCQ=; b=KEjqDN0xpOuAOK+sSvh/HAyaoyLYdiz1SXy8wRfTUR4reCS2v/aRqTBMeUHACYxecW 4tqzR7EcJmyHzqoeDfJkXz7uvR9BuSS7+DFEVc/UdHvtC7jdCG9OjMXg7GIqoN47Diiu DPbegapb4zUsQPvexDC4a4irjZqfzPbVg3MzJUzypXE+yjnjl/4Te6ItlRartgdp1JvA WYwfY7ZVMU/uchqo4It80U3hQ3Pa5Q0VT1yi3zPAUOseJw45wW5K4mTaRVkIlGWnqi35 4mrJhl2Oa/+Bme2IyXx5eyYsRJ2xKQHjRyWHs1uPy9yWG7pi7s9y63SqutClrQWmA+8g wM7Q== X-Gm-Message-State: ALoCoQk5Z9zzmPJU5Eij1ibIMwwf5xQ4zrmE1GSeeLtVPXPP8+eP6pDv0kJxTdGi/BKpk4dlWsb5 X-Received: by 10.98.13.22 with SMTP id v22mr25058264pfi.125.1449271699625; Fri, 04 Dec 2015 15:28:19 -0800 (PST) MIME-Version: 1.0 References: <55D857EA.80107@strotmann.de> <8321AB9D-ADCD-44BD-8A0F-1D6B5CF1971C@ogud.com> <55DC74A3.6060206@posteo.de> <55E82512.2080507@posteo.de> <55E85082.1050008@posteo.de> <22DCFC67-C65D-45E1-A5EB-EC8BD4F887B9@vpnc.org> <479DFDB1-94C0-478F-B204-34053B850CCC@vpnc.org> <5661A978.4000901@posteo.de> In-Reply-To: <5661A978.4000901@posteo.de> From: Warren Kumari Date: Fri, 04 Dec 2015 23:28:10 +0000 Message-ID: To: =?UTF-8?B?UGF0cmlrIEzDtmhy?= , dane@ietf.org Content-Type: multipart/alternative; boundary=001a114955d0d6edaa05261adc35 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: Fri, 04 Dec 2015 23:28:21 -0000 --001a114955d0d6edaa05261adc35 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Dec 4, 2015 at 9:56 AM Patrik L=C3=B6hr wr= ote: > Hello Paul and all, > > Thanks a lot. > > That was the missing piece for the release of SMIMEA and OPENPGPKEY for > our customers. Today we are happy to announce the implementation of > these standards, which we hope will soon be accepted: > > > Wow, this is excellent news. Thank you for implementing this, I'm signing up for an account to give it a whirl... W > Best regards > Patrik > > > Am 01.12.2015 um 21:23 schrieb Paul Hoffman: > > IANA has registered the following RR Type: > > > > SMIMEA 53 S/MIME cert assocication > [draft-ietf-dane-smime] > > > > Please see http://www.iana.org/assignments/dns-parameters > > > > _______________________________________________ > > 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 > --001a114955d0d6edaa05261adc35 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri= , Dec 4, 2015 at 9:56 AM Patrik L=C3=B6hr <patrik.loehr@posteo.de> wrote:
Hello Paul and all,

Thanks a lot.

That was the missing piece for the release of SMIMEA and OPENPGPKEY for
our customers. Today we are happy to announce the implementation of
these standards, which we hope will soon be accepted:
<https://posteo.de/en/blog/new-posteo-pu= blic-key-directory>


Wow, this is excellent news. Thank you= for implementing this, I'm signing up for an account to give it a whir= l...


W
=C2=A0
Best regards
Patrik


Am 01.12.2015 um 21:23 schrieb Paul Hoffman:
> IANA has registered the following RR Type:
>
> SMIMEA=C2=A0 =C2=A0 =C2=A0 =C2=A0 53=C2=A0 =C2=A0 =C2=A0 S/MIME cert a= ssocication=C2=A0 =C2=A0 =C2=A0 =C2=A0 [draft-ietf-dane-smime]
>
> Please see http://www.iana.org/assignments/dns-pa= rameters
>
> _______________________________________________
> 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 <patrik= .loehr@posteo.de>
web <= https://posteo.de>

USt-IdNr.: DE186713958
Handelsregister: Berlin-Charlottenburg =C2=B7 HRA 47592 B

_______________________________________________
dane mailing list
dane@ietf.org
https://www.ietf.org/mailman/listinfo/dane
--001a114955d0d6edaa05261adc35-- From nobody Thu Dec 10 18:05:31 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 170F41A0163 for ; Thu, 10 Dec 2015 18:05:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDVqZE0QoQKt for ; Thu, 10 Dec 2015 18:05:25 -0800 (PST) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (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 729311A0116 for ; Thu, 10 Dec 2015 18:05:25 -0800 (PST) Received: by qgcc31 with SMTP id c31so177576422qgc.3 for ; Thu, 10 Dec 2015 18:05:24 -0800 (PST) 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 :content-type; bh=l0T46AtxA8LLwxHYEW6FYj6LDSwVIlLLq2kDbMwCZU4=; b=im+zJZHFxZcwuYVtbKoD13ykGcNopPEGl+o1wvJQOgHakXg8tLobFXLsZruQ8NltG4 U+/A77Zmwuic0wrhuV6+U/O1814yV2gt0b4i4s2MzK0WPsBlCA9ued3JHkAEAG8iOg37 kLkzoIpwnuYZQ3rxl5+os3amUp1SUx7Uu/dm6mIEhSQ4ef6aJlWP/XkBIaid9jBNmbx+ q8NVOn102G9jxG2T68qdXMywtDAwX6+Hgd1grJRuDxbhlzzWezbcxYr89S6SaQClfRBi Sjld1P/p+kf4ip4nEieRk6Cr2nI+l4saVYkmVUFo4XHOSjPE5twr5WuZuORBPCyRFpAk 0zhQ== MIME-Version: 1.0 X-Received: by 10.55.212.92 with SMTP id l89mr20695044qki.70.1449799524639; Thu, 10 Dec 2015 18:05:24 -0800 (PST) Received: by 10.140.87.117 with HTTP; Thu, 10 Dec 2015 18:05:24 -0800 (PST) In-Reply-To: <20151128070913.GJ18315@mournblade.imrryr.org> References: <20151109045334.GU18315@mournblade.imrryr.org> <20151128070913.GJ18315@mournblade.imrryr.org> Date: Thu, 10 Dec 2015 21:05:24 -0500 Message-ID: From: Shumon Huque To: "" Content-Type: multipart/alternative; boundary=001a1149de9ca96bd7052695c1a8 Archived-At: Subject: Re: [dane] New version of tls-dnssec-chain draft (-02) 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, 11 Dec 2015 02:05:30 -0000 --001a1149de9ca96bd7052695c1a8 Content-Type: text/plain; charset=UTF-8 On Sat, Nov 28, 2015 at 2:09 AM, Viktor Dukhovni wrote: > On Mon, Nov 23, 2015 at 08:19:20AM -0500, Shumon Huque wrote: > > > Compression in the DNS protocol is currently defined in terms > > of DNS messages, so we'd have to define a new scheme. The simplest > > would be to redefine (for the purpose of this TLS extension only) the > > compression pointer in the label's 1st octet to refer to an offset from > > the beginning of the chain data structure. Or, switch to DNS messages. > > The potential advantage of switching to DNS messages is that this > is presumably a format already understood by various libraries. Yes, that's true. There are also existing DNS library functions that can generate and consume authentication chains composed of RRset sequences, however they wouldn't understand a custom compression scheme (out of the box) if we cooked one up. One of the possible constraints I've referred to is the desire from some app developers not to link in a large DNS library into their applications to process this extension. I think both you and I (and maybe others) have made the point that DNSSEC is sufficiently complex that it would be best if this function can be shunted to a DNSSEC library that knows how to do it properly including dealing with all the corner cases. But I think the concern expressed about application bloat is a legitimate one that we need to take into account. Perhaps a possible solution is to develop a new streamlined DNSSEC library that doesn't contain extraneous code that this function doesn't need (such as all the DNS transport related code). > > > * Because validation order is not always possible (in presence > > > of DNAME/CNAME indirection), it is I think best to not > > > suggest that the records are so ordered, even in the case > > > when such ordering is possible. > > > > I agree that CNAME/DNAME indirection makes this trickier. A later section > > does describe how ordering is done for CNAME/DNAME chains, essentially > > using multiple sequences of ordered RRsets. > > And therefore I think the ordering requirement is for the most part > needlessly restrictive. The processing logic as I see it is: > > + Bring all the records into a transient empty cache (no external > lookups for cache missses, the cache is the entire universe), > not losing track of which was the first. > > + Starting at the first RRset, if it is a CNAME, validate the > chain of CNAMES leading to the actual target TLSA RRset. > > + Validate the target RRset (often the first RRset absent CNAMEs). > > All the RRsets other than the first are just cached, and so their > order is not significant, with one important exception: NSEC3 > records that validate wildcard responses need arrive directly after > the wildcard response and be stored with that wildcard response. > Finding them is cumbersome after the fact. As I mentioned, I am personally okay with this approach. We need to get input from the application folks who are looking at implementing this. I'm discussing and asking them to chime in. Also, if we're not imposing ordering, I don't think the wildcard NSEC needs to appear after the wildcard. The client is reordering stuff anyway, so it should be able to deal with it. > Which brings us back to the message format, if it is just a stream > of RRsets (rather than a stream of DNS messages), what binds the > NSEC/NSEC3 records to the associated wildcard response? > > ; ANSWER: > ; *._tcp.example.com IN CNAME _dane.example.com. > _25._tcp.example.com. IN CNAME _dane.example.com. > _dane.example.com. IN TLSA 3 1 1 ... > ; AUTHORITY > ; This, or equivalent NSEC3 record > *._tcp.example.com. IN NSEC example.com. CNAME > > In what order should these RRsets appear? How are the NSEC (or > worse NSEC3) records to be associated with the wildcard (first) > answer in a stream of records that is not broken down into the > usual query/answer/authority/additional format if they are not > explicitly grouped with the packet in question? (Broader search > for suitable NSEC3 records across all the returned RRsets?) For the current 'ordered RRset' version of this spec, the wildcard case is underspecified. The simplest thing would be to specify that the NSEC/NSEC3 record (and associated RRSIG) appears right after the wildcard TLSA record. Note that there is a semantic mismatch between DNS wildcards and wildcards in X.509 certificate DNS names - the X.509 wildcard covers all possible names, whereas the DNS wildcard covers all names except those explicitly named in the zone. Some one possible simplification would be to say that for wildcard TLSA records this TLS extension only supports the X.509 wildcard semantics, and exclude the NSEC records. This would require 'tweaking' the DNSSEC validation algorithm to not perform the 'no closer match' proof for wildcard records. I might actually be leaning in this direction now to keep things simple. > > Certificate chains in TLS are ordered > > (from EE cert towards trust anchor), and they'd like the DNS RRsets to be > > similarly ordered, so that the client can authenticate the data in one > > sequential pass through. That was our starting point. > > Except that in practice (and formally in the TLS 1.3) draft the > certificates are not so ordered, and DNS resolution with CNAMEs > and wildcard records is not nearly so "linear". Yes, I'm aware of this .. I'm relaying discussion with others. > > We'll continue to have discussions on this topic (and I'd be happy to > > rope you in), but I am a bit reluctant to expend energy to develop a > > protocol that application developers won't implement, so I'm trying to > > be flexible. > > This protocol is not something "application developers" should even > for a moment consider implementing. It goes into DNS libraries > that are enhanced to support this use case. The application will > just shunt the records from the TLS server to the library, and get > back the validated TLSA RRset or a suitable error. Yes, I generally agree, but see my earlier point .. > > I agree. Making the SNI extension mandatory seems necessary (and > > also an easy requirement since this is a green field application), > > but I wasn't able to get agreement from some of my co-authors on > > this. Will re-open the discussion. > > SNI is already required for DANE clients: > > https://tools.ietf.org/html/rfc7671#section-3 Ah, glad to hear that! > > > So it would seem that the client needs to communicate the > > > target port to the server, as the payload of the proposed > > > extension in the client HELLO (extension would no longer > > > be empty on the client side). > > > > Hmm, I hadn't considered the case of servers behind NATs. But I guess > > IPv4 depletion and CGNs might make this a more prevalent (and reasonable) > > use case we should try to accommodate. > > > > If we're populating the client side extension with data, it could > > carry both the server's name and port. > > Except that SNI already carries the name, so I would not duplicate > that. Right. > > > [TODO: mention that to reduce the size of the chain, the server can > > > deliver exactly one RRsig per RRset, namely the one used to validate > > > the chain as it is built.] > > > > > > This assumes that the server knows which algorithms the client's > > > library supports. The server can definitely do some trimming > > > if multiple signatures are present for the same algorithm as > > > a side-effect of key rotation, but it cannot in general trim > > > the list down to one signature per RRset, unless the client's > > > extension also signals the supported algorithms (too complex > > > I think, and serves to help "fingerprint" the client). > > > > Good point. Maybe it's simplest to remove this requirement, or only > > trim obviously safe signatures due to key rotation or signatures that > > aren't required (such as a ZSK signature over the DNSKEY RRset - > > unnecessary but often seen in the wild). > > > > Having the client indicate its supported algorithms in the extension > > might be worth considering though. > > But complicated, because the client might not know which algorithms > are supported by its DNS library. The library would have to provide > an interface to get that list. If the list is optional, than an > empty list should mean that no algorithms can be dropped. As you > note, with a bit of work some other redundancies can be eliminated. Yes. > > If we migrate to DNS messages, the best format would be the proposed > > EDNS chain query message, which would remove a lot of the overhead: > > > > http://tools.ietf.org/html/draft-ietf-dnsop-edns-chain-query > > > > But we'd need to be to process regular messages for servers that don't > > support this too. I'll start some discussion on this topic. > > It would certainly be good to leverage this if the same format can > be used for both. Much more likely to be implemented in DNS > libraries if it kills two birds with one stone. > > Don't know how this works with non-linear results involving non-sibling > CNAMEs. > > > No, you're not in the rough and I very much appreciate the detailed > > comments Viktor. As I mentioned, we're working with some constraints > > and desires imposed by the likely consumers of this mechanism, but > > there is of course room for discussion and refinement. > > As I mentioned above, if you could be more explicit about these, > that might be helpful. I'm having discussions with my co-authors and collaborators this week, and some of them should be chiming in soon on some of their requirements and/or desires. The ones I'm aware of so far are those already stated earlier in this thread: ordered RRsets and desire to avoid linking in large DNS libraries. There may be others. I'm hoping we can reach agreement on a way forward, although I expect it will require several more rounds of discussion. -- Shumon Huque --001a1149de9ca96bd7052695c1a8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Nov 28, 2015 at 2:09 AM, Viktor Dukhovni <= ietf-dane@dukhovni.org> wr= ote:
> On Mon, Nov 23, 2015 at 08:19:20AM -0500, Shumon Hu= que wrote:
>
> > Compression in the DNS protoc= ol is currently defined in terms
> > of DNS messages, so we= 'd have to define a new scheme. The simplest
> > would = be to redefine (for the purpose of this TLS extension only) the
&= gt; > compression pointer in the label's 1st octet to refer to an of= fset from
> > the beginning of the chain data structure. Or= , switch to DNS messages.
>
> The potential advan= tage of switching to DNS messages is that this
> is presumably= a format already understood by various libraries.

Yes, that's true.

There are also existing DNS= library functions that can generate and consume
authentication c= hains composed of RRset sequences, however they wouldn't
unde= rstand a custom compression scheme (out of the box) if we cooked one up.

One of the possible constraints I've referred to= is the desire from
some app developers not to link in a large DN= S library into their
applications to process this extension.

I think both you and I (and maybe others) have made th= e point that
DNSSEC is sufficiently complex that it would be best= if this function
can be shunted to a DNSSEC library that knows h= ow to do it properly
including dealing with all the corner cases.= But I think the concern
expressed about application bloat is a l= egitimate one that we need to
take into account. Perhaps a possib= le solution is to develop a new
streamlined DNSSEC library that d= oesn't contain extraneous code that
this function doesn't= need (such as all the DNS transport related
code).
> > > =C2=A0 =C2=A0 =C2=A0 * Because validation order = is not always possible (in presence
> > > =C2=A0 =C2=A0 = =C2=A0 =C2=A0 of DNAME/CNAME indirection), it is I think best to not
<= div>> > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 suggest that the records are= so ordered, even in the case
> > > =C2=A0 =C2=A0 =C2=A0= =C2=A0 when such ordering is possible.
> >
> = > I agree that CNAME/DNAME indirection makes this trickier. A later sect= ion
> > does describe how ordering is done for CNAME/DNAME = chains, essentially
> > using multiple sequences of ordered= RRsets.
>
> And therefore I think the ordering r= equirement is for the most part
> needlessly restrictive.=C2= =A0 The processing logic as I see it is:
>
> =C2= =A0 =C2=A0 + Bring all the records into a transient empty cache (no externa= l
> =C2=A0 =C2=A0 =C2=A0 lookups for cache missses, the cache = is the entire universe),
> =C2=A0 =C2=A0 =C2=A0 not losing tra= ck of which was the first.
>
> =C2=A0 =C2=A0 + St= arting at the first RRset, if it is a CNAME, validate the
> = =C2=A0 =C2=A0 =C2=A0 chain of CNAMES leading to the actual target TLSA RRse= t.
>
> =C2=A0 =C2=A0 + Validate the target RRset = (often the first RRset absent CNAMEs).
>
> All th= e RRsets other than the first are just cached, and so their
> = order is not significant, with one important exception: NSEC3
>= ; records that validate wildcard responses need arrive directly after
=
> the wildcard response and be stored with that wildcard response.<= /div>
> Finding them is cumbersome after the fact.

As I mentioned, I am personally okay with this approach. We need to=
get input from the application folks who are looking at implemen= ting
this. I'm discussing and asking them to chime in.
<= div>
Also, if we're not imposing ordering, I don't th= ink the wildcard NSEC
needs to appear after the wildcard. The cli= ent is reordering stuff anyway,
so it should be able to deal with= it.

> Which brings us back to the message form= at, if it is just a stream
> of RRsets (rather than a stream o= f DNS messages), what binds the
> NSEC/NSEC3 records to the as= sociated wildcard response?
>
> =C2=A0 =C2=A0 =C2= =A0 =C2=A0 ; ANSWER:
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 ; *._tcp.example.com IN CNAME _dane.example.com.
> =C2=A0 =C2=A0 =C2= =A0 =C2=A0 _25._tcp.example.com. IN = CNAME _dane.example.com.
= > =C2=A0 =C2=A0 =C2=A0 =C2=A0 _dane.= example.com. IN TLSA 3 1 1 ...
> =C2=A0 =C2=A0 =C2=A0 =C2= =A0 ; AUTHORITY
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 ; This, or equiv= alent NSEC3 record
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 *._tcp.example.com. IN NSEC example.com. CNAME
>
> In what orde= r should these RRsets appear?=C2=A0 How are the NSEC (or
> wor= se NSEC3) records to be associated with the wildcard (first)
>= answer in a stream of records that is not broken down into the
&= gt; usual query/answer/authority/additional format if they are not
> explicitly grouped with the packet in question? =C2=A0(Broader searc= h
> for suitable NSEC3 records across all the returned RRsets?= )

For the current 'ordered RRset' version = of this spec, the wildcard
case is underspecified. The simplest t= hing would be to specify that
the NSEC/NSEC3 record (and associat= ed RRSIG) appears right after the
wildcard TLSA record.

Note that there is a semantic mismatch between DNS wildcard= s and
wildcards in X.509 certificate DNS names - the X.509 wildca= rd
covers all possible names, whereas the DNS wildcard covers all= names
except those explicitly named in the zone. Some one possib= le
simplification would be to say that for wildcard TLSA records = this
TLS extension only supports the X.509 wildcard semantics, an= d
exclude the NSEC records. This would require 'tweaking'= the DNSSEC
validation algorithm to not perform the 'no close= r match' proof
for wildcard records. I might actually be lean= ing in this direction
now to keep things simple.

> > Certificate chains in TLS are ordered
> >= ; (from EE cert towards trust anchor), and they'd like the DNS RRsets t= o be
> > similarly ordered, so that the client can authenti= cate the data in one
> > sequential pass through. That was = our starting point.
>
> Except that in practice (= and formally in the TLS 1.3) draft the
> certificates are not = so ordered, and DNS resolution with CNAMEs
> and wildcard reco= rds is not nearly so "linear".

Yes, I= 9;m aware of this .. I'm relaying discussion with others.
> > We'll continue to have discussions on this topic = (and I'd be happy to
> > rope you in), but I am a bit r= eluctant to expend energy to develop a
> > protocol that ap= plication developers won't implement, so I'm trying to
&g= t; > be flexible.
>
> This protocol is not som= ething "application developers" should even
> for a = moment consider implementing.=C2=A0 It goes into DNS libraries
&g= t; that are enhanced to support this use case.=C2=A0 The application will
> just shunt the records from the TLS server to the library, an= d get
> back the validated TLSA RRset or a suitable error.

Yes, I generally agree, but see my earlier point ..

> > I agree. Making the SNI extension mandato= ry seems necessary (and
> > also an easy requirement since = this is a green field application),
> > but I wasn't ab= le to get agreement from some of my co-authors on
> > this.= Will re-open the discussion.
>
> SNI is already = required for DANE clients:
>

Ah, glad to hear that= !

> > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 So it= would seem that the client needs to communicate the
> > &g= t; =C2=A0 =C2=A0 =C2=A0 =C2=A0 target port to the server, as the payload of= the proposed
> > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 extensio= n in the client HELLO (extension would no longer
> > > = =C2=A0 =C2=A0 =C2=A0 =C2=A0 be empty on the client side).
> &g= t;
> > Hmm, I hadn't considered the case of servers beh= ind NATs. But I guess
> > IPv4 depletion and CGNs might mak= e this a more prevalent (and reasonable)
> > use case we sh= ould try to accommodate.
> >
> > If we'= re populating the client side extension with data, it could
> = > carry both the server's name and port.
>
&g= t; Except that SNI already carries the name, so I would not duplicate
=
> that.

Right.

&g= t; > > =C2=A0 =C2=A0 =C2=A0 =C2=A0[TODO: mention that to reduce the s= ize of the chain, the server can
> > > =C2=A0 =C2=A0 =C2= =A0 =C2=A0 deliver exactly one RRsig per RRset, namely the one used to vali= date
> > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 the chain as it i= s built.]
> > >
> > > =C2=A0 =C2=A0 T= his assumes that the server knows which algorithms the client's
> > > =C2=A0 =C2=A0 library supports.=C2=A0 The server can defi= nitely do some trimming
> > > =C2=A0 =C2=A0 if multiple = signatures are present for the same algorithm as
> > > = =C2=A0 =C2=A0 a side-effect of key rotation, but it cannot in general trim<= /div>
> > > =C2=A0 =C2=A0 the list down to one signature per R= Rset, unless the client's
> > > =C2=A0 =C2=A0 extens= ion also signals the supported algorithms (too complex
> > = > =C2=A0 =C2=A0 I think, and serves to help "fingerprint" the = client).
> >
> > Good point. Maybe it's= simplest to remove this requirement, or only
> > trim obvi= ously safe signatures due to key rotation or signatures that
>= > aren't required (such as a ZSK signature over the DNSKEY RRset -<= /div>
> > unnecessary but often seen in the wild).
>= >
> > Having the client indicate its supported algorith= ms in the extension
> > might be worth considering though.<= /div>
>
> But complicated, because the client might not= know which algorithms
> are supported by its DNS library.=C2= =A0 The library would have to provide
> an interface to get th= at list.=C2=A0 If the list is optional, than an
> empty list s= hould mean that no algorithms can be dropped.=C2=A0 As you
> n= ote, with a bit of work some other redundancies can be eliminated.

Yes.

> > If we migrate to D= NS messages, the best format would be the proposed
> > EDNS= chain query message, which would remove a lot of the overhead:
&= gt; >
> >
> > But = we'd need to be to process regular messages for servers that don't<= /div>
> > support this too. I'll start some discussion on thi= s topic.
>
> It would certainly be good to levera= ge this if the same format can
> be used for both.=C2=A0 Much = more likely to be implemented in DNS
> libraries if it kills t= wo birds with one stone.
>
> Don't know how t= his works with non-linear results involving non-sibling
> CNAM= Es.
>
> > No, you're not in the rough and = I very much appreciate the detailed
> > comments Viktor. As= I mentioned, we're working with some constraints
> > a= nd desires imposed by the likely consumers of this mechanism, but
> > there is of course room for discussion and refinement.
>
> As I mentioned above, if you could be more explicit ab= out these,
> that might be helpful.

I= 'm having discussions with my co-authors and collaborators this week,
and some of them should be chiming in soon on some of their requir= ements
and/or desires.

The ones I'm = aware of so far are those already stated earlier in this
thread: = ordered RRsets and desire to avoid linking in large DNS libraries.
There may be others. I'm hoping we can reach agreement on a way forwa= rd,
although I expect it will require several more rounds of disc= ussion.

--
Shumon Huque

--001a1149de9ca96bd7052695c1a8-- From nobody Thu Dec 10 20:41: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 3A6381A6F49 for ; Thu, 10 Dec 2015 20:41:21 -0800 (PST) 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 CZuGhmMTaWrH for ; Thu, 10 Dec 2015 20:41:19 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 704971A6F41 for ; Thu, 10 Dec 2015 20:41:19 -0800 (PST) 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 2A615283E83; Fri, 11 Dec 2015 04:41:18 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: ietf-dane@dukhovni.org In-Reply-To: Date: Thu, 10 Dec 2015 23:25:07 -0500 Content-Transfer-Encoding: 7bit Message-Id: <23F61F03-764D-4138-9FEF-3A99820C0278@dukhovni.org> References: <20151109045334.GU18315@mournblade.imrryr.org> <20151128070913.GJ18315@mournblade.imrryr.org> To: Shumon Huque X-Mailer: Apple Mail (2.3112) Archived-At: Cc: dane@ietf.org Subject: Re: [dane] New version of tls-dnssec-chain draft (-02) 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, 11 Dec 2015 04:41:21 -0000 > On Dec 10, 2015, at 9:05 PM, Shumon Huque wrote: > > > Which brings us back to the message format, if it is just a stream > > of RRsets (rather than a stream of DNS messages), what binds the > > NSEC/NSEC3 records to the associated wildcard response? > > > > ; ANSWER: > > ; *._tcp.example.com IN CNAME _dane.example.com. > > _25._tcp.example.com. IN CNAME _dane.example.com. > > _dane.example.com. IN TLSA 3 1 1 ... > > ; AUTHORITY > > ; This, or equivalent NSEC3 record > > *._tcp.example.com. IN NSEC example.com. CNAME > > > > In what order should these RRsets appear? How are the NSEC (or > > worse NSEC3) records to be associated with the wildcard (first) > > answer in a stream of records that is not broken down into the > > usual query/answer/authority/additional format if they are not > > explicitly grouped with the packet in question? (Broader search > > for suitable NSEC3 records across all the returned RRsets?) > > For the current 'ordered RRset' version of this spec, the wildcard > case is underspecified. The simplest thing would be to specify that > the NSEC/NSEC3 record (and associated RRSIG) appears right after the > wildcard TLSA record. > > Note that there is a semantic mismatch between DNS wildcards and > wildcards in X.509 certificate DNS names - the X.509 wildcard > covers all possible names, whereas the DNS wildcard covers all names > except those explicitly named in the zone. Some one possible > simplification would be to say that for wildcard TLSA records this > TLS extension only supports the X.509 wildcard semantics, and > exclude the NSEC records. This would require 'tweaking' the DNSSEC > validation algorithm to not perform the 'no closer match' proof > for wildcard records. I might actually be leaning in this direction > now to keep things simple. Doing incorrect validation of DNSSEC wildcards is not a good idea. These are defaults, that are quite deliberately inapplicable in the presence of real records. If a user has a specific TLSA record for port 443, and a different wildcard covering other ports, attackers MUST NOT be able to substitute the wildcard TLSA RRset for the more specific one for port 443. Do not confuse these with the X.509 wildcards. The authority (NSEC/NSEC3) records that provide closest-encloser proofs are not optional. -- Viktor. From nobody Thu Dec 10 21:10:23 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 526031A854C for ; Thu, 10 Dec 2015 21:10:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0g1KRgHVyvf for ; Thu, 10 Dec 2015 21:10:20 -0800 (PST) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1E8E1A854B for ; Thu, 10 Dec 2015 21:10:19 -0800 (PST) Received: by qgea14 with SMTP id a14so184855427qge.0 for ; Thu, 10 Dec 2015 21:10:19 -0800 (PST) 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; bh=VQ/bPvFH/Ll2wYe13Gz3zb+a3xn9t1bPmKNuzCLqJmg=; b=fJAsooKp6DQ6bmFuarxY0OXufzCk8kHqQjwiMRiMUDxtMfh4xS9QQ0CbiYAWQRN87l h+FLL1cj3NmoFNq7gygO+2C188C4POKgkoTZJB+omaYS5pI+jrTxOuOLQ8z4DWk6twZW ogPioDtpXD+FfFrU3XIULth8C23f9otq6xvKTCK639mVqBlMb7MuM3xqFxl9uZeLL4fs UJmiX82n1F7jk0PKcF79yKwCeSpyOllXRFm8z2yHQYNUkAO5ytPsahSeOwPxwRMf8JwN HYT879/RNhf2F4LzBzkXaCuTlPH2nltC8HriQ9blw8LdB4ScWwSA2Iw70xCkTlqIOa2/ c5bg== MIME-Version: 1.0 X-Received: by 10.140.129.198 with SMTP id 189mr12330183qhb.10.1449810619008; Thu, 10 Dec 2015 21:10:19 -0800 (PST) Received: by 10.140.87.117 with HTTP; Thu, 10 Dec 2015 21:10:18 -0800 (PST) In-Reply-To: <23F61F03-764D-4138-9FEF-3A99820C0278@dukhovni.org> References: <20151109045334.GU18315@mournblade.imrryr.org> <20151128070913.GJ18315@mournblade.imrryr.org> <23F61F03-764D-4138-9FEF-3A99820C0278@dukhovni.org> Date: Fri, 11 Dec 2015 00:10:18 -0500 Message-ID: From: Shumon Huque To: Viktor Dukhovni Content-Type: multipart/alternative; boundary=001a1134f4b0f00ca5052698565c Archived-At: Cc: "" Subject: Re: [dane] New version of tls-dnssec-chain draft (-02) 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, 11 Dec 2015 05:10:22 -0000 --001a1134f4b0f00ca5052698565c Content-Type: text/plain; charset=UTF-8 On Thu, Dec 10, 2015 at 11:25 PM, wrote: > > > On Dec 10, 2015, at 9:05 PM, Shumon Huque wrote: > > > > > Which brings us back to the message format, if it is just a stream > > > of RRsets (rather than a stream of DNS messages), what binds the > > > NSEC/NSEC3 records to the associated wildcard response? > > > > > > ; ANSWER: > > > ; *._tcp.example.com IN CNAME _dane.example.com. > > > _25._tcp.example.com. IN CNAME _dane.example.com. > > > _dane.example.com. IN TLSA 3 1 1 ... > > > ; AUTHORITY > > > ; This, or equivalent NSEC3 record > > > *._tcp.example.com. IN NSEC example.com. CNAME > > > > > > In what order should these RRsets appear? How are the NSEC (or > > > worse NSEC3) records to be associated with the wildcard (first) > > > answer in a stream of records that is not broken down into the > > > usual query/answer/authority/additional format if they are not > > > explicitly grouped with the packet in question? (Broader search > > > for suitable NSEC3 records across all the returned RRsets?) > > > > For the current 'ordered RRset' version of this spec, the wildcard > > case is underspecified. The simplest thing would be to specify that > > the NSEC/NSEC3 record (and associated RRSIG) appears right after the > > wildcard TLSA record. > > > > Note that there is a semantic mismatch between DNS wildcards and > > wildcards in X.509 certificate DNS names - the X.509 wildcard > > covers all possible names, whereas the DNS wildcard covers all names > > except those explicitly named in the zone. Some one possible > > simplification would be to say that for wildcard TLSA records this > > TLS extension only supports the X.509 wildcard semantics, and > > exclude the NSEC records. This would require 'tweaking' the DNSSEC > > validation algorithm to not perform the 'no closer match' proof > > for wildcard records. I might actually be leaning in this direction > > now to keep things simple. > > Doing incorrect validation of DNSSEC wildcards is not a good idea. > These are defaults, that are quite deliberately inapplicable in > the presence of real records. If a user has a specific TLSA > record for port 443, and a different wildcard covering other ports, > attackers MUST NOT be able to substitute the wildcard TLSA RRset > for the more specific one for port 443. Do not confuse these > with the X.509 wildcards. > I wasn't confusing anything, rather considering ways to avoid the presence of NSEC records in the chain, as a possible simplification. Presumably the server operator knows what records are in their zone and can judge the risks for themselves, but I know it isn't ideal. Another option, also not ideal, would be to exclude wildcard TLSA records from using this mechanism. Anyway, let's see how the discussion about RRsets vs messages and the use of DNSSEC libraries goes. If we end up shunting everything to a full validation library this is all moot. Shumon. --001a1134f4b0f00ca5052698565c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Dec 10, 2015 at 11:25 PM, <ietf-dane@dukhovni.org>= wrote:

> On Dec 10, 2015, at 9:05 PM, Shumon Huque <shuque@gmail.com> wrote:
>
> > Which brings us back to the message format, if it is just a strea= m
> > of RRsets (rather than a stream of DNS messages), what binds the<= br> > > NSEC/NSEC3 records to the associated wildcard response?
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0; ANSWER:
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0; *._tcp.example.com IN CNAME _= da= ne.example.com.
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_25._tcp.example.com. IN CNAME = _d= ane.example.com.
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_dane.example.com. IN TLSA 3 1= 1 ...
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0; AUTHORITY
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0; This, or equivalent NSEC3 reco= rd
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*._tcp.example.com. IN NSEC example.co= m. CNAME
> >
> > In what order should these RRsets appear?=C2=A0 How are the NSEC = (or
> > worse NSEC3) records to be associated with the wildcard (first) > > answer in a stream of records that is not broken down into the > > usual query/answer/authority/additional format if they are not > > explicitly grouped with the packet in question?=C2=A0 (Broader se= arch
> > for suitable NSEC3 records across all the returned RRsets?)
>
> For the current 'ordered RRset' version of this spec, the wild= card
> case is underspecified. The simplest thing would be to specify that > the NSEC/NSEC3 record (and associated RRSIG) appears right after the > wildcard TLSA record.
>
> Note that there is a semantic mismatch between DNS wildcards and
> wildcards in X.509 certificate DNS names - the X.509 wildcard
> covers all possible names, whereas the DNS wildcard covers all names > except those explicitly named in the zone. Some one possible
> simplification would be to say that for wildcard TLSA records this
> TLS extension only supports the X.509 wildcard semantics, and
> exclude the NSEC records. This would require 'tweaking' the DN= SSEC
> validation algorithm to not perform the 'no closer match' proo= f
> for wildcard records. I might actually be leaning in this direction > now to keep things simple.

Doing incorrect validation of DNSSEC wildcards is not a good id= ea.
These are defaults, that are quite deliberately inapplicable in
the presence of real records.=C2=A0 If a user has a specific TLSA
record for port 443, and a different wildcard covering other ports,
attackers MUST NOT be able to substitute the wildcard TLSA RRset
for the more specific one for port 443.=C2=A0 Do not confuse these
with the X.509 wildcards.

I wasn't = confusing anything, rather considering ways to avoid the presence of NSEC r= ecords in the chain, as a possible simplification. Presumably the server op= erator knows what records are in their zone and can judge the risks for the= mselves, but I know it isn't ideal. Another option, also not ideal, wou= ld be to exclude wildcard TLSA records from using this mechanism.

Anyway, let's see how the discussion about RRsets vs me= ssages and the use of DNSSEC libraries goes. If we end up shunting everythi= ng to a full validation library this is all moot.

= Shumon.

--001a1134f4b0f00ca5052698565c-- From nobody Fri Dec 11 08:51: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 1DE241B2D0E for ; Fri, 11 Dec 2015 08:50:59 -0800 (PST) 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 UGkytLHQcAi5 for ; Fri, 11 Dec 2015 08:50:57 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA3EC1B2B69 for ; Fri, 11 Dec 2015 08:50:57 -0800 (PST) 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 3926B284809; Fri, 11 Dec 2015 16:50:56 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Viktor Dukhovni In-Reply-To: Date: Fri, 11 Dec 2015 11:50:55 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151109045334.GU18315@mournblade.imrryr.org> <20151128070913.GJ18315@mournblade.imrryr.org> <23F61F03-764D-4138-9FEF-3A99820C0278@dukhovni.org> To: Shumon Huque X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "" Subject: Re: [dane] New version of tls-dnssec-chain draft (-02) 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, 11 Dec 2015 16:50:59 -0000 > On Dec 11, 2015, at 12:10 AM, Shumon Huque wrote: >=20 >> Doing incorrect validation of DNSSEC wildcards is not a good idea. >> These are defaults, that are quite deliberately inapplicable in >> the presence of real records. If a user has a specific TLSA >> record for port 443, and a different wildcard covering other ports, >> attackers MUST NOT be able to substitute the wildcard TLSA RRset >> for the more specific one for port 443. Do not confuse these >> with the X.509 wildcards. >=20 > I wasn't confusing anything, rather considering ways to avoid the = presence of NSEC records in the chain, as a possible simplification. = Presumably the server operator knows what records are in their zone and = can judge the risks for themselves, but I know it isn't ideal. Another = option, also not ideal, would be to exclude wildcard TLSA records from = using this mechanism. The server operator may not always be at liberty to ensure that the TLSA RRset is free of wildcards. This might apply for example in intramural corporate deployments of services running on a multiple and perhaps variable ports on a given host. --=20 Viktor. From nobody Sun Dec 27 01:27: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 CC3CB1A008E for ; Sun, 27 Dec 2015 01:27:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 p29Cq87Mr8QP for ; Sun, 27 Dec 2015 01:27:08 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 048821A008B for ; Sun, 27 Dec 2015 01:27:07 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id C80142843A5; Sun, 27 Dec 2015 09:27:06 +0000 (UTC) Date: Sun, 27 Dec 2015 09:27:06 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20151227092706.GN18704@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: [dane] DANE TLSA support in OpenSSL 1.1.0 coming soon... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Dec 2015 09:27:10 -0000 The OpenSSL code for DANE 1.1.0 is done, pending internal team review. I am hoping it will appear in 1.1.0-pre2 in early January. If the review takes too long, it might slip into 1.1.0-pre3 in February. I'm working to avoid that. A quick demo below. Note OpenSSL will *NOT* do the DNS lookups for you. Use a suitable DNS library and feed the validated RRDATA to OpenSSL, which will then use these to validate the peer certificate (with built-in name checks, skipped as required for DANE-EE(3)). [ Bash code for the "danehttps" demo shell function that wraps "openssl s_client" is below my signature): ] # Verisign's "3 0 1" good demo: # $ danehttps good.dane.verisignlabs.com openssl 's_client' '-connect' 'good.dane.verisignlabs.com:443' '-dane_tlsa_domain' 'good.dane.verisignlabs.com' '-dane_tlsa_rrdata' '3 0 1 0332AA2D58B3E0544B65656438937068BA44CE2F14469C4F50C9CC69 33C808D3' DANE TLSA 3 0 1 matched EE certificate at depth 0 Verify return code: 0 (ok) # "3 1 1" from torproject.org for good measure: # $ danehttps torproject.org openssl 's_client' '-connect' 'torproject.org:443' '-dane_tlsa_domain' 'torproject.org' '-dane_tlsa_rrdata' '3 1 1 578582E6B4569A4627AEF5DFE876EEC0539388E605DB170217838B10 D2A58DA5' DANE TLSA 3 1 1 matched EE certificate at depth 0 Verify return code: 0 (ok) # Verisign's "3 0 1" bad hash: # $ danehttps bad-hash.dane.verisignlabs.com openssl 's_client' '-connect' 'bad-hash.dane.verisignlabs.com:443' '-dane_tlsa_domain' 'bad-hash.dane.verisignlabs.com' '-dane_tlsa_rrdata' '3 0 1 99999999999999999999999999999999999999999999999999999999 99999999' Verify return code: 27 (certificate not trusted) # Verisign's unusable TLSA records: # $ danehttps bad-params.dane.verisignlabs.com openssl 's_client' '-connect' 'bad-params.dane.verisignlabs.com:443' '-dane_tlsa_domain' 'bad-params.dane.verisignlabs.com' '-dane_tlsa_rrdata' '3 0 17 0332AA2D58B3E0544B65656438937068BA44CE2F14469C4F50C9CC69 33C808D3' '-dane_tlsa_rrdata' '3 119 1 0332AA2D58B3E0544B65656438937068BA44CE2F14469C4F50C9CC69 33C808D3' '-dane_tlsa_rrdata' '51 0 1 0332AA2D58B3E0544B65656438937068BA44CE2F14469C4F50C9CC69 33C808D3' s_client: warning: unusable TLSA rrdata: 3 0 17 0332AA2D58B3E0544B65656438937068BA44CE2F14469C4F50C9CC69 33C808D3 s_client: warning: unusable TLSA rrdata: 3 119 1 0332AA2D58B3E0544B65656438937068BA44CE2F14469C4F50C9CC69 33C808D3 s_client: warning: unusable TLSA rrdata: 51 0 1 0332AA2D58B3E0544B65656438937068BA44CE2F14469C4F50C9CC69 33C808D3 # It takes an Exim developer to be "man enough" to use non-trivial # chains with DANE and publish multiple TLSA RRs. A non-toy deployment. # $ danehttps www.spodhuis.org openssl 's_client' '-connect' 'www.spodhuis.org:443' '-dane_tlsa_domain' 'www.spodhuis.org' '-dane_tlsa_rrdata' '2 0 1 BDEE0D7C8F9C278F14EA9B6A4F90ED665A9F56DB0A56B1CDDA676591 2F398A5E' '-dane_tlsa_rrdata' '2 0 1 96BCEC06264976F37460779ACF28C5A7CFE8A3C0AAE11A8FFCEE05C0 BDDF08C6' '-dane_tlsa_rrdata' '2 0 1 E4EB54A7FFA552EF64D8E1AE338B69BE909C29E6AF57170A2F6F44DF 225E5A14' '-dane_tlsa_rrdata' '2 0 1 EA99063A0A3BDA9727032CF82DA238698B90BA729300703D39569436 35F96488' DANE TLSA 2 0 1 matched TA certificate at depth 1 Verified peername: www.spodhuis.org Verify return code: 0 (ok) # Doug Barton is is particularly fond of PKIX-EE(1) # $ danehttps dougbarton.us -CAfile /tmp/startcom-root.pem openssl 's_client' '-connect' 'dougbarton.us:443' '-CAfile' '/tmp/sc.pem' '-dane_tlsa_domain' 'dougbarton.us' '-dane_tlsa_rrdata' '1 0 2 437A2A0C21D29C95FA036E982421EAE07FB180935C97D719AEDFAA5E 46FB64AE10C09266A0EC42E5D360785B5233B116F32868DDE7E81B2F BE6870D4B5781C63' DANE TLSA 1 0 2 matched EE certificate at depth 0 Verified peername: dougbarton.us Verify return code: 0 (ok) # Which fails, as it should, if we omit the local PKIX root: # $ danehttps dougbarton.us openssl 's_client' '-connect' 'dougbarton.us:443' '-dane_tlsa_domain' 'dougbarton.us' '-dane_tlsa_rrdata' '1 0 2 437A2A0C21D29C95FA036E982421EAE07FB180935C97D719AEDFAA5E 46FB64AE10C09266A0EC42E5D360785B5233B116F32868DDE7E81B2F BE6870D4B5781C63' Verify return code: 20 (unable to get local issuer certificate) -- Viktor. #! /bin/bash # Uses Bash arrays and local variables danehttps() { local host=$1; shift local args=(s_client -connect "$host:443") args=("${args[@]}" -dane_tlsa_domain "$host") local nlx="$(printf '\nx')" OIFS="$IFS"; IFS="${nlx%x}" rrs=( $( dig +noall +ans +nocl +nottl -t tlsa "_443._tcp.$host." | awk '$2 == "TLSA" {sub(/.*TLSA[^0-9]*/, "", $0); print}' ) ) IFS="$OIFS" for rr in "${rrs[@]}"; do args=("${args[@]}" "-dane_tlsa_rrdata" "$rr") done printf "openssl" for arg in "${args[@]}"; do printf " '%s'" "$arg"; done; echo (printf "HEAD / HTTP/1.0\r\nHost: %s\n" "$host"; sleep 1) | openssl "${args[@]}" 2>&1 | egrep '^ *Verif|^DANE TLSA|: warning:' } danehttps "$1" From nobody Wed Dec 30 15:44: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 9ED2C1A00A8 for ; Wed, 30 Dec 2015 15:44:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.511 X-Spam-Level: X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 k0EyrX8K3zSO for ; Wed, 30 Dec 2015 15:44:05 -0800 (PST) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) (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 464221A00A5 for ; Wed, 30 Dec 2015 15:44:05 -0800 (PST) Received: from localhost (50-1-19-110.dsl.dynamic.fusionbroadband.com [50.1.19.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id 8CDED20BD7; Wed, 30 Dec 2015 15:44:03 -0800 (PST) From: Wes Hardaker To: Viktor Dukhovni References: <20151227092706.GN18704@mournblade.imrryr.org> Date: Wed, 30 Dec 2015 15:44:02 -0800 In-Reply-To: <20151227092706.GN18704@mournblade.imrryr.org> (Viktor Dukhovni's message of "Sun, 27 Dec 2015 09:27:06 +0000") Message-ID: <0lk2nvqz7h.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: dane@ietf.org Subject: Re: [dane] DANE TLSA support in OpenSSL 1.1.0 coming soon... 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, 30 Dec 2015 23:44:06 -0000 Viktor Dukhovni writes: > The OpenSSL code for DANE 1.1.0 is done, pending internal team > review. Excellent news and congratulations! -- Wes Hardaker Parsons