From leifj@mnt.se Mon Aug 1 01:47:19 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5385421F8663 for ; Mon, 1 Aug 2011 01:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BrDHaLBjR0X8 for ; Mon, 1 Aug 2011 01:47:18 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id C93BE21F8658 for ; Mon, 1 Aug 2011 01:47:13 -0700 (PDT) Received: from [192.36.125.212] (dhcp.pilsnet.sunet.se [192.36.125.212]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p718lEhJ017148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 1 Aug 2011 10:47:17 +0200 (CEST) Message-ID: <4E366812.5090206@mnt.se> Date: Mon, 01 Aug 2011 10:47:14 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: dane@ietf.org References: <4B7B160E-B835-44E3-A5A8-8DC50E3498FD@vpnc.org> <20110731161210.GH9434@shinkuro.com> <20110731202601.GJ9434@shinkuro.com> <20110801014459.GD20015@shinkuro.com> In-Reply-To: <20110801014459.GD20015@shinkuro.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 08:47:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Explain to me what the problem is, ideally by walking through an > example. +1 I would love to see an example explaining the issue! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk42aBEACgkQ8Jx8FtbMZnf1DwCbB1sI6xaZWw2fiwdLstdqMHao 5boAnj2iH/KJ+vMFZCvEfgdTKKJyyHsi =oM2T -----END PGP SIGNATURE----- From hallam@gmail.com Mon Aug 1 12:47:22 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C63D11E8156 for ; Mon, 1 Aug 2011 12:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.902 X-Spam-Level: X-Spam-Status: No, score=-2.902 tagged_above=-999 required=5 tests=[AWL=-0.504, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_51=0.6, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sU7tpIMdxq7W for ; Mon, 1 Aug 2011 12:47:21 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB3411E8155 for ; Mon, 1 Aug 2011 12:47:20 -0700 (PDT) Received: by yie30 with SMTP id 30so4394415yie.31 for ; Mon, 01 Aug 2011 12:47:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7unLX1MYS7AAEX5K9IaId7TvwmHqlbp6D+8fDhfX/x8=; b=HXsaxUrrGpE6/KXmcpm8xXMBj+hDyrKE+pJfLuq/2EkokDx87QbnA1cUISkkdvYBZU aXXCizkjsei3/tYhhNnngUu/3XCzLpwlD8kH2mBLd02b2ne4AxwEAr2ihuSRvqZoXV42 E0IAMKk5VG6EUyl0JRmoXwF/AWC04qCQPZO0c= MIME-Version: 1.0 Received: by 10.100.254.3 with SMTP id b3mr3446850ani.116.1312228045964; Mon, 01 Aug 2011 12:47:25 -0700 (PDT) Received: by 10.100.34.3 with HTTP; Mon, 1 Aug 2011 12:47:25 -0700 (PDT) In-Reply-To: <4E366812.5090206@mnt.se> References: <4B7B160E-B835-44E3-A5A8-8DC50E3498FD@vpnc.org> <20110731161210.GH9434@shinkuro.com> <20110731202601.GJ9434@shinkuro.com> <20110801014459.GD20015@shinkuro.com> <4E366812.5090206@mnt.se> Date: Mon, 1 Aug 2011 15:47:25 -0400 Message-ID: From: Phillip Hallam-Baker To: Leif Johansson Content-Type: multipart/alternative; boundary=00163691ff518b486904a976e6ae Cc: dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 19:47:22 -0000 --00163691ff518b486904a976e6ae Content-Type: text/plain; charset=ISO-8859-1 On Mon, Aug 1, 2011 at 4:47 AM, Leif Johansson wrote: > > > Explain to me what the problem is, ideally by walking through an > > example. > > +1 I would love to see an example explaining the issue! The issue is that DANE has to use prefixed DNS records and these do not work in the way that we would want them to. In particular DNS does not allow wildcards of the form _prefix.*.example.com Aliases are another problem. If a web site has an alias to map www.example.com to another domain name we want the user who is following the alias to still have the security benefit Aliases are very widely used in the Web world. In most cases the DNS administration and Web hosting administration are separate (even if handled by the same company). If a customer edits the 'domain name' of their web site they are actually changing a CNAME to it. In other words, if we don't get this right nobody will be able to use DANE without major changes to their infrastructure which most of the Web hosting companies are not capable of doing. For example, a common web hosting approach: www.hallambaker.com CNAME host293939.hostprovider.com www.dotcrimemanifesto.com CNAME doftuturemanifesto.blogspot.com I have two sites there, one is hosted locally by my DNS provider, another is a blog on blogger. I don't want to be managing the crypto for either on my DNS provider account as it is not plugged into the SSL management scheme at either hosting site. The CNAME is simply a pointer to where the action is. The problem is that the above will only work for TLSA if I also create CNAMEs to map the subordinate nodes. On Sun, Jul 31, 2011 at 9:44 PM, Andrew Sullivan wrote: > On Sun, Jul 31, 2011 at 07:34:08PM -0400, Phillip Hallam-Baker wrote: > > > Sending text would be appropriate if the issue was a disagreement over > the > > precise wording. In this case we do not appear to have agreement on the > > principle so asking for wording seems premature. > > Well, then, perhaps you can explain to me what it is that is wrong > about "TLSA is another RRTYPE like all other RRTYPES, and it resolves > in exactly the same way." >From an implementation point of view the above does not give developers enough information to have a chance of creating an inter-operable implementations. Your language looks simple because you are ignoring the problem entirely. You are not telling the client what to do when an alias is discovered. You are not even giving them a definite citation for where they should find out what to do. I don't think we need to agree on language. But we do need to agree on a specification that sets out what steps the client is required to take to resolve the DANE records for a specific address and in particular what steps to take when a CNAME or a DNAME is encountered. For example: Resolution of TLSA records. A relying party resolves the TLSA records for the Internet service at port X of domain D as follows: 1) A prefix label P is formed by appending the underscore '_' character (ASCII ...) to the decimal value of the port number. 2) The RP issues a query for the TLSA Qtype at P.D 2a) If the query returns a result, the resolution process is complete and the result is the records returned. 3) The RP issues a query to determine if D is aliased. To do this the RP MAY issue a query for any Qtype at D. 3a) If the query result does not contain a record indicating an alias mapping, the resolution process is complete and the result is null. 3b) The query result returns an alias mapping D to A. 4) The RP issues queries for QTYPE TLSA at P.A and for any Qtype at A 4a) If the query for the TLSA record returns a result, the resolution is complete and the result is the result of the query, otherwise 4b) If the query for A returns an alias mapping to AA and the alias count limit has not been reached, the RP sets A = AA and repeats step 4 4c) Otherwise the result of the resolution is null. It looks a little complex set out but it is pretty straightforward in practice and can be implemented by any DNS interface library that allows arbitrary DNS records to be resolved. I do not believe that there is any library out there that will allow you to obtain a TLSA record without being able to resolve CNAME. In practice what I would expect to see is: www.example.com CNAME example.com _443._port.example.com TLSA fooooo example.com A 10.1.1.1 Resolve D=example.com X=443 [P= _443._port] Parallel: example.com ? QTYPE=A example.com A 10.1.1.1 _443._port.example.com TLSA ? QTYPE=TLSA _443._port.example.com TLSA fooooo Resolve D=example.com X=443 [P= _443._port] Parallel: www.example.com ? QTYPE=A www.example.com CNAME example.com _443._port.example.com TLSA ? QTYPE=TLSA Parallel: example.com ? QTYPE=A example.com A 10.1.1.1 _443._port.example.com TLSA ? QTYPE=TLSA _443._port.example.com TLSA fooooo The overhead of doing this is irrelevant. The process only requires the RP to do more work in the case that they would otherwise fail. -- Website: http://hallambaker.com/ --00163691ff518b486904a976e6ae Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
=A0On Mon, Aug 1, 2011 at 4:47 AM, Leif Johansson=A0= <leifj@mnt.se>=A0wrote:
> Explain to me what the problem is, ideally by walkin= g through an
> example.

+1 I would love to see an exampl= e explaining the issue!

The issue is = that DANE has to use prefixed DNS records and these do not work in the way = that we would want them to.=A0

In particular DNS does not allow wildcards of the form = _prefix.*.example.com

Aliases are another problem. If a web site has an alias to map www.example.com to another domain name we= want the user who is following the alias to still have the security benefi= t

Aliases are very widely used in the Web world. In most = cases the DNS administration and Web hosting administration are separate (e= ven if handled by the same company). If a customer edits the 'domain na= me' of their web site they are actually changing a CNAME to it.

In other words, if we don't get this right nobody w= ill be able to use DANE without major changes to their infrastructure which= most of the Web hosting companies are not capable of doing.


For example, a common web hosting approach:

www.hallamba= ker.com =A0 =A0 =A0 =A0 =A0 =A0 =A0 CNAME=A0=A0host293939.hostprovider.com

I have two sites there,= one is hosted locally by my DNS provider, another is a blog on blogger.=A0=

I don't want to be managing the crypto for either o= n my DNS provider account as it is not plugged into the SSL management sche= me at either hosting site. The CNAME is simply a pointer to where the actio= n is.

The problem is that the above will only work for TLSA i= f I also create CNAMEs to map the subordinate nodes.
On Sun, Jul 31, 2= 011 at 9:44 PM, Andrew Sullivan=A0<ajs@anvilwalrusden.com>=A0wrote:
On Sun, Jul 31, 2011 at 07:34:08PM -0400, Phillip Hallam-= Baker wrote:

> Sending text would be appropriate if the issue was= a disagreement over the
> precise wording. In this case we do not ap= pear to have agreement on the
> principle so asking for wording seems premature.

Well, th= en, perhaps you can explain to me what it is that is wrong
about "T= LSA is another RRTYPE like all other RRTYPES, and it resolves
in exactly= the same way."

From an implementation point of view the above does not= give developers enough information to have a chance of creating an inter-o= perable implementations.

Your language looks simpl= e because you are ignoring the problem entirely. You are not telling the cl= ient what to do when an alias is discovered. You are not even giving them a= definite citation for where they should find out what to do.


I don't think we need to agree on la= nguage. But we do need to agree on a specification that sets out what steps= the client is required to take to resolve the DANE records for a specific = address and in particular what steps to take when a CNAME or a DNAME is enc= ountered.

For example:

Resolution of TLS= A records.

A relying party resolves the TLSA recor= ds for the Internet service at port X of domain D as follows:

1) A prefix label P is formed by appending the underscore &#= 39;_' character (ASCII ...) to the decimal value of the port number.

2) The RP issues a query for the TLSA Qtype at P.D

2a) If the query returns a result, the resolution proce= ss is complete and the result is the records returned.

=
3) The RP issues a query to determine if D is aliased. To do this the = RP MAY issue a query for any Qtype at D.

3a) If the query result does not contain a record indic= ating an alias mapping, the resolution process is complete and the result i= s null.

3b) The query result returns an alias mapp= ing D to A.=A0

4) The RP issues queries for QTYPE TLSA at P.A and for = any Qtype at A

4a) If the query for the TLSA recor= d returns a result, the resolution is complete and the result is the result= of the query, otherwise

4b) If the query for A returns an alias mapping to AA a= nd the alias count limit has not been reached, the RP sets A =3D AA and rep= eats step 4

4c) Otherwise the result of the resolu= tion is null.


It looks a little complex set out but it= is pretty straightforward in practice and can be implemented by any DNS in= terface library that allows arbitrary DNS records to be resolved. I do not = believe that there is any library out there that will allow you to obtain a= TLSA record without being able to resolve CNAME.

In practice what I would expect to see is:
www.example.com CNAME <= a href=3D"http://example.com">example.com
_443._port.example.com TLSA fooooo=A0
example.com A 10.1.1.1
Resolve D=3Dexample.com X= =3D443 =A0 [P=3D _443._port]

Parallel:=A0
=A0 =A0example.com ? QTYPE=3DA
=A0 =A0 =A0=A0example.com A 10.1.1.= 1



Resolve D=3Dexample.com X=3D443 =A0 [P=3D _443._port]
=

Parallel:=A0
=A0 =A0www.example.com ? QTYPE=3DA
=A0 =A0 =A0=A0www.example.com C= NAME example.com
=A0 _443._port.example.com TLSA ? QTYPE=3DTLSA
=A0 =A0 =A0 <null>

Parallel:=A0
=A0 =A0example.com ? QTYPE=3DA
=A0 =A0 =A0= =A0example.com A 10.1.1.1
=A0 = _443._port.example.com TLSA ? QTYPE= =3DTLSA
=A0 =A0 =A0 _443._port.example.com= TLSA fooooo


The overhead= of doing this is irrelevant. The process only requires the RP to do more w= ork in the case that they would otherwise fail.


--
Website: http://hallambaker.com/

--00163691ff518b486904a976e6ae-- From mrex@sap.com Mon Aug 1 14:23:58 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A07A1F0C3B for ; Mon, 1 Aug 2011 14:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.932 X-Spam-Level: X-Spam-Status: No, score=-9.932 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1p01DZuNZ6aG for ; Mon, 1 Aug 2011 14:23:57 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id E90B61F0C39 for ; Mon, 1 Aug 2011 14:23:56 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p71LNwXA020978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Aug 2011 23:23:58 +0200 (MEST) From: Martin Rex Message-Id: <201108012123.p71LNwGA007523@fs4113.wdf.sap.corp> To: hallam@gmail.com (Phillip Hallam-Baker) Date: Mon, 1 Aug 2011 23:23:58 +0200 (MEST) In-Reply-To: from "Phillip Hallam-Baker" at Aug 1, 11 03:47:25 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 21:23:58 -0000 I have an extremely bad feeling about the CNAME/DNAME discussions. What has been proposed/discusses appears to create a security gap in the DANE architecture, and would make things with DANE work opposite to without DANE, which is something that looks very dangerous to me. In all of the example usage scenarios described in rfc6125, CNAME are irrelevant to the verification of the server certificate, they're only a less efficient way to obtain an IP-Address for the purpose of connect()ing the server, they're otherwise invisible/irrelevant to the server endpoint identification. The idea and architecture behind DANE is either to provide an independent confirmation from the authoritative domain owner about a server certificate from a commercial CA, or to have the DNS domain admin directly provide the confirmation of a server's certificate and cut the commercial CA out of the loop (obviating the domain admin to ask a commercial CA to assert that the domain owner requested a specific server certificate). With DANE, it is the domain admin who has to add TLSA records into his zone for his servers, performing a similar role to the CA when it issues server certificates, and only TLSA records for the original name should be looked at by DANE clients. With the original model, if a domain admin wants to outsource a server to some hosting company, the domain owner would either have to obtain the server certificate and pass it along to the hosting company, or pass along an authorization from the DNS admin to the the hosting company to obtain a server certificate for the outsourced server. If a DANE-using DNS admin wants to outsource a web-server to a hosting company, the DNS admin will also have to publish the relevant TLSA record in his domain, independent of whether the DNS admin creates the server keypair himself and passes the credential along to the hosting service or wether the hosting service creates the keypair and passes the certificate back to the DNS admin for creation of the TLSA record. The DNSSEC verification for TLSA only needs to cover the TLSA record in that case (A records are irrelevant, because IPs are untrusted in absence of IPsec and presence of NATs anyways). (btw. has the original limitation that a CNAME must not point to another CNAME been removed from DNS?) The idea that TLSA is retrieved for what a CNAME resolves to would make current practise/architecture considerably differ from DANE. And I might prefer a "well-known" fallback label for DANE to a DNS "*" wildcard in order to specify a domain-wide preference of a (PKIX) CA. -Martin Phillip Hallam-Baker wrote: > > The issue is that DANE has to use prefixed DNS records and these do not work > in the way that we would want them to. > > In particular DNS does not allow wildcards of the form _prefix.*.example.com > > Aliases are another problem. If a web site has an alias to map > www.example.com to another domain name we want the user who is following the > alias to still have the security benefit > > Aliases are very widely used in the Web world. In most cases the DNS > administration and Web hosting administration are separate (even if handled > by the same company). If a customer edits the 'domain name' of their web > site they are actually changing a CNAME to it. > > In other words, if we don't get this right nobody will be able to use DANE > without major changes to their infrastructure which most of the Web hosting > companies are not capable of doing. > > > For example, a common web hosting approach: > > www.hallambaker.com CNAME host293939.hostprovider.com > www.dotcrimemanifesto.com CNAME doftuturemanifesto.blogspot.com > > I have two sites there, one is hosted locally by my DNS provider, another is > a blog on blogger. > > I don't want to be managing the crypto for either on my DNS provider account > as it is not plugged into the SSL management scheme at either hosting site. > The CNAME is simply a pointer to where the action is. > > The problem is that the above will only work for TLSA if I also create > CNAMEs to map the subordinate nodes. From ondrej.sury@nic.cz Mon Aug 1 15:35:34 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6AC1F0C4D for ; Mon, 1 Aug 2011 15:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.211 X-Spam-Level: * X-Spam-Status: No, score=1.211 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_43=0.6, MIME_8BIT_HEADER=0.3, SARE_URGBIZ=0.725, URG_BIZ=1.585] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ND3imr7m6UNW for ; Mon, 1 Aug 2011 15:35:32 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id A4C421F0C49 for ; Mon, 1 Aug 2011 15:35:31 -0700 (PDT) Received: from [10.0.0.12] (247.78.broadband13.iol.cz [90.180.78.247]) by mail.nic.cz (Postfix) with ESMTPSA id 088562A06BC; Tue, 2 Aug 2011 00:35:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1312238138; bh=a6qAkHjUmcvrktiK9HO9jLfs8L5RBbs9zlMMgEDyy10=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=a+ID7crU2eBeZKaQH5ylVsbrYKj7NbHeQnn70yVLY0YSQW2gZJSzeHzIYAZk2AYHc dbLZFYH7GBZyW2uuzZYCJt+Xox+H4ydxkzg6w2kjlbCHGmncWi2QjOI4lW2Pv0VJ5S trkqFR7Lwzn0r+ShaRx75KaBRL0mt20AMVQjCUAc= Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: Date: Tue, 2 Aug 2011 00:35:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <51F8554A-0F52-404C-AA93-1F1990FCD51E@nic.cz> References: <4B7B160E-B835-44E3-A5A8-8DC50E3498FD@vpnc.org> <20110731161210.GH9434@shinkuro.com> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1244.3) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: Andrew Sullivan , dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 22:35:34 -0000 On 31. 7. 2011, at 20:54, Phillip Hallam-Baker wrote: >=20 >=20 > On Sun, Jul 31, 2011 at 12:12 PM, Andrew Sullivan = wrote: >> Dear colleagues, >>=20 >> I am sorry I was unable to make the DANE meeting on Friday either in >> person or remotely. I was called away on urgent family business. >> Nevertheless, I have read the document. I have yet to read a = complete >> and coherent critique of the current text in the document. In = particular, >>=20 >> On Sun, Jul 31, 2011 at 11:23:31AM -0400, Phillip Hallam-Baker wrote: >> > >> > By fully addressed I mean that there is a defined algorithm for = resolving >> > DANE DNS RRs that is compatible with administrative use cases for = use of >> > Wildcare and alias (CNAME, DNAME) records. >> > >> > The current appendix suggests options but does not mandate a = particular >> > behavior. Thus DNS administrators deploying DANE cannot rely on = these >> > records actually working. >>=20 >> that requirement is completely bogus. DNS zone operators have and >> have always had a wide degree of operational freedom with their = zones. >=20 > They can stuff records in zones. >=20 > But they can't predict what effect the records will have unless the = resolution semantics are defined. And if they can't predict the effect = of a configuration they can't use it. Can you please send an examples where and when do you think the = resolution semantics is not defined. With my DNS glasses on I am just = unable to see the problem you are referring to. CNAME is an internal = DNS mechanism and should not be interpreted by end clients, just by DNS = resolvers. Thus the DANE client asks for TLSA at _prefix.example.com = and gets the result (or NXDOMAIN) with no knowledge of CNAMEs at all = (and the knowledge is not needed). I clearly doesn't understand what is the case you are worried about. = Could you please clarify more? Use case or an example would be much = appreciated, so we don't get entangled into the words. > =20 >> The above seems to suggest that DANE might try to require one and = only >> one way to use DNAME and CNAME records (not to mention wildcards) in = a >> zone in the presence of RRTYPEs that are the result of DANE work. = But >> we don't get to make those rules. All we can do is say, "Here's what >> you need to take into consideration." It's the operator's zone. = S/he >> will do as s/he pleases. All we can do is suggest tactics to = maximize >> interoperation. >=20 > What is at issue here is a requirement for client application = developers. >=20 > The operator can't make an informed decision if different client take = different approaches. >=20 > That is why it is a standards issue. I feel you are probably right that we need to be more specific how the = clients should behave (aka just ask for _prefix.example.com). However I = propose that we put this into the DANE operations document the WG agreed = to work on instead into the DANE protocol document. The chairs will work on starting the work on this issue shortly. O. P.S.: Sorry for not wrapping. If somebody knows how to force Mail.app = to wrap lines, please send me the hint off-list. -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From hallam@gmail.com Mon Aug 1 15:36:31 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F42201F0C53 for ; Mon, 1 Aug 2011 15:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.485 X-Spam-Level: X-Spam-Status: No, score=-3.485 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qmjU6ItPKbc4 for ; Mon, 1 Aug 2011 15:36:29 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 679741F0C49 for ; Mon, 1 Aug 2011 15:36:29 -0700 (PDT) Received: by gwb20 with SMTP id 20so4617462gwb.31 for ; Mon, 01 Aug 2011 15:36:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=U511h0RDwyqgUetDF65Mb8QA4yP0rjnN23Xn9ukrV8Q=; b=QDpUhJmnPfOkCjA2jm64uHrbO9SSdcnXPX5zLtG7z3TvCZApE342rsyAAwZpPTkNnQ SDmdczJeaWAmOhOWjB9SydroGELR4LZjaz5X5W4vRDeCdejAZ+sACZyMWIAIgc9cgWQv +sSCBZuIQFsrgmyh57ktTw1VCxFsu3EghCyZ0= MIME-Version: 1.0 Received: by 10.101.164.25 with SMTP id r25mr3511756ano.94.1312238195345; Mon, 01 Aug 2011 15:36:35 -0700 (PDT) Received: by 10.100.34.3 with HTTP; Mon, 1 Aug 2011 15:36:35 -0700 (PDT) In-Reply-To: <201108012123.p71LNwGA007523@fs4113.wdf.sap.corp> References: <201108012123.p71LNwGA007523@fs4113.wdf.sap.corp> Date: Mon, 1 Aug 2011 18:36:35 -0400 Message-ID: From: Phillip Hallam-Baker To: mrex@sap.com Content-Type: multipart/alternative; boundary=0016e6d26d727e87f804a97943bd Cc: dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 22:36:31 -0000 --0016e6d26d727e87f804a97943bd Content-Type: text/plain; charset=ISO-8859-1 That is not how it works in practice with DV certs and there are very good reasons why 6125 is different. Reason #1 With a traditional DV cert the objective is to secure the domain name that the user originally typed in. In other words, user types in www.example.com, that is the domain that is attested to by the EE cert. If www.example.com is CNAME to host782832.hostserve.net, we don't want a cert for hostserve.net appearing in browser chrome. And that trumps use cases we might otherwise want to support but can't because we can't differentiate them. But in the most common hosting case, the customer pays for the cert and never touches it. The cert is created at the hosting co and never leaves. So your administrative example does not reflect how certs are managed in the real world. Reason #2 RFC 6125 is the way it is because we didn't have deployed DNSSEC at the time. It is a description of a historical approach. On Mon, Aug 1, 2011 at 5:23 PM, Martin Rex wrote: > I have an extremely bad feeling about the CNAME/DNAME discussions. > What has been proposed/discusses appears to create a security gap > in the DANE architecture, and would make things with DANE work opposite > to without DANE, which is something that looks very dangerous to me. > > In all of the example usage scenarios described in rfc6125, > CNAME are irrelevant to the verification of the server certificate, > they're only a less efficient way to obtain an IP-Address for the > purpose of connect()ing the server, they're otherwise invisible/irrelevant > to the server endpoint identification. > > > The idea and architecture behind DANE is either to provide an independent > confirmation from the authoritative domain owner about a server certificate > from a commercial CA, or to have the DNS domain admin directly provide > the confirmation of a server's certificate and cut the commercial CA > out of the loop (obviating the domain admin to ask a commercial CA > to assert that the domain owner requested a specific server certificate). > > > With DANE, it is the domain admin who has to add TLSA records into > his zone for his servers, performing a similar role to the CA when > it issues server certificates, and only TLSA records for the original name > should be looked at by DANE clients. > > With the original model, if a domain admin wants to outsource a server > to some hosting company, the domain owner would either have to obtain > the server certificate and pass it along to the hosting company, or > pass along an authorization from the DNS admin to the the hosting company > to obtain a server certificate for the outsourced server. > > If a DANE-using DNS admin wants to outsource a web-server to a hosting > company, the DNS admin will also have to publish the relevant TLSA > record in his domain, independent of whether the DNS admin creates > the server keypair himself and passes the credential along to the > hosting service or wether the hosting service creates the keypair > and passes the certificate back to the DNS admin for creation > of the TLSA record. > > > The DNSSEC verification for TLSA only needs to cover the TLSA record > in that case (A records are irrelevant, because IPs are untrusted > in absence of IPsec and presence of NATs anyways). > > > (btw. has the original limitation that a CNAME must not point to > another CNAME been removed from DNS?) > > > The idea that TLSA is retrieved for what a CNAME resolves to would > make current practise/architecture considerably differ from DANE. > > And I might prefer a "well-known" fallback label for DANE to a DNS "*" > wildcard in order to specify a domain-wide preference of a (PKIX) CA. > > > -Martin > > Phillip Hallam-Baker wrote: > > > > The issue is that DANE has to use prefixed DNS records and these do not > work > > in the way that we would want them to. > > > > In particular DNS does not allow wildcards of the form _prefix.*. > example.com > > > > Aliases are another problem. If a web site has an alias to map > > www.example.com to another domain name we want the user who is following > the > > alias to still have the security benefit > > > > Aliases are very widely used in the Web world. In most cases the DNS > > administration and Web hosting administration are separate (even if > handled > > by the same company). If a customer edits the 'domain name' of their web > > site they are actually changing a CNAME to it. > > > > In other words, if we don't get this right nobody will be able to use > DANE > > without major changes to their infrastructure which most of the Web > hosting > > companies are not capable of doing. > > > > > > For example, a common web hosting approach: > > > > www.hallambaker.com CNAME host293939.hostprovider.com > > www.dotcrimemanifesto.com CNAME doftuturemanifesto.blogspot.com > > > > I have two sites there, one is hosted locally by my DNS provider, another > is > > a blog on blogger. > > > > I don't want to be managing the crypto for either on my DNS provider > account > > as it is not plugged into the SSL management scheme at either hosting > site. > > The CNAME is simply a pointer to where the action is. > > > > The problem is that the above will only work for TLSA if I also create > > CNAMEs to map the subordinate nodes. > > > -- Website: http://hallambaker.com/ --0016e6d26d727e87f804a97943bd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That is not how it works in practice with DV certs and there are very good = reasons why 6125 is different.


Reason #1<= /div>

With a traditional DV cert the objective is to sec= ure the domain name that the user originally typed in. In other words, user= types in www.example.com, that is t= he domain that is attested to by the EE cert.=A0

If www.example.com is CNAME to host782832.hosts= erve.net, we don't want a cert for hostserve.net appearing in browser chrome. And that trumps use cases w= e might otherwise want to support but can't because we can't differ= entiate them.


But in the most common hosting case= , the customer pays for the cert and never touches it. The cert is created = at the hosting co and never leaves. So your administrative example does not= reflect how certs are managed in the real world.


Reason #2

RFC 6125 is the = way it is because we didn't have deployed DNSSEC at the time. It is a d= escription of a historical approach.=A0




On Mon, Aug 1, 2011 at 5= :23 PM, Martin Rex <mr= ex@sap.com> wrote:
I have an extremely bad feeling about the CNAME/DNAME discussions.
What has been proposed/discusses appears to create a security gap
in the DANE architecture, and would make things with DANE work opposite
to without DANE, which is something that looks very dangerous to me.

In all of the example usage scenarios described in rfc6125,
CNAME are irrelevant to the verification of the server certificate,
they're only a less efficient way to obtain an IP-Address for the
purpose of connect()ing the server, they're otherwise invisible/irrelev= ant
to the server endpoint identification.


The idea and architecture behind DANE is either to provide an independent confirmation from the authoritative domain owner about a server certificate=
from a commercial CA, or to have the DNS domain admin directly provide
the confirmation of a server's certificate and cut the commercial CA out of the loop (obviating the domain admin to ask a commercial CA
to assert that the domain owner requested a specific server certificate).

With DANE, it is the domain admin who has to add TLSA records into
his zone for his servers, performing a similar role to the CA when
it issues server certificates, and only TLSA records for the original name<= br> should be looked at by DANE clients.

With the original model, if a domain admin wants to outsource a server
to some hosting company, the domain owner would either have to obtain
the server certificate and pass it along to the hosting company, or
pass along an authorization from the DNS admin to the the hosting company to obtain a server certificate for the outsourced server.

If a DANE-using DNS admin wants to outsource a web-server to a hosting
company, the DNS admin will also have to publish the relevant TLSA
record in his domain, independent of whether the DNS admin creates
the server keypair himself and passes the credential along to the
hosting service or wether the hosting service creates the keypair
and passes the certificate back to the DNS admin for creation
of the TLSA record.


The DNSSEC verification for TLSA only needs to cover the TLSA record
in that case (A records are irrelevant, because IPs are untrusted
in absence of IPsec and presence of NATs anyways).


(btw. has the original limitation that a CNAME must not point to
=A0another CNAME been removed from DNS?)


The idea that TLSA is retrieved for what a CNAME resolves to would
make current practise/architecture considerably differ from DANE.

And I might prefer a "well-known" fallback label for DANE to a DN= S "*"
wildcard in order to specify a domain-wide preference of a (PKIX) CA.


-Martin

Phillip Hallam-Baker wrote:
>
> The issue is that DANE has to use prefixed DNS records and these do no= t work
> in the way that we would want them to.
>
> In particular DNS does not allow wildcards of the form _prefix.*.example.com
>
> Aliases are another problem. If a web site has an alias to map
> www.example.com to another domain name we want the user who is following the
> alias to still have the security benefit
>
> Aliases are very widely used in the Web world. In most cases the DNS > administration and Web hosting administration are separate (even if ha= ndled
> by the same company). If a customer edits the 'domain name' of= their web
> site they are actually changing a CNAME to it.
>
> In other words, if we don't get this right nobody will be able to = use DANE
> without major changes to their infrastructure which most of the Web ho= sting
> companies are not capable of doing.
>
>
> For example, a common web hosting approach:
>
> www.hallambak= er.com =A0 =A0 =A0 =A0 =A0 =A0 =A0 CNAME =A0host293939.hostprovider.com
> www.dot= crimemanifesto.com =A0 CNAME doftuturemanifesto.blogspot.com
>
> I have two sites there, one is hosted locally by my DNS provider, anot= her is
> a blog on blogger.
>
> I don't want to be managing the crypto for either on my DNS provid= er account
> as it is not plugged into the SSL management scheme at either hosting = site.
> The CNAME is simply a pointer to where the action is.
>
> The problem is that the above will only work for TLSA if I also create=
> CNAMEs to map the subordinate nodes.





--
Website: http://hallambaker.com/

--0016e6d26d727e87f804a97943bd-- From hallam@gmail.com Mon Aug 1 15:37:23 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C45B71F0C53 for ; Mon, 1 Aug 2011 15:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.588 X-Spam-Level: X-Spam-Status: No, score=-1.588 tagged_above=-999 required=5 tests=[AWL=-1.800, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, J_CHICKENPOX_43=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_URGBIZ=0.725, URG_BIZ=1.585] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8RgYhz9Ka1PI for ; Mon, 1 Aug 2011 15:37:22 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id A15DA1F0C4D for ; Mon, 1 Aug 2011 15:37:22 -0700 (PDT) Received: by gyd5 with SMTP id 5so4474707gyd.31 for ; Mon, 01 Aug 2011 15:37:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LexUulmLDAAGzznA2MYxRT0WRVf+V2MkBS5O4x9NsIQ=; b=DAcjiaENrH6FkryA9DtyIHJ+ahA1wwBPRFLVJkYscPqrkIeFouiWBPJAYA8tUEOBdG YTyZ9KNhYOw/dthiE0Jk1Mgh8j+bX+DmVDqalmfZch+WR+y4RHBNTWQB62ujmeW7ItDM MEzKZ89YZyJ7kQqU3Y00bZ/hOGNWrbWzH+dMg= MIME-Version: 1.0 Received: by 10.101.189.1 with SMTP id r1mr1835473anp.6.1312238249805; Mon, 01 Aug 2011 15:37:29 -0700 (PDT) Received: by 10.100.34.3 with HTTP; Mon, 1 Aug 2011 15:37:29 -0700 (PDT) In-Reply-To: <51F8554A-0F52-404C-AA93-1F1990FCD51E@nic.cz> References: <4B7B160E-B835-44E3-A5A8-8DC50E3498FD@vpnc.org> <20110731161210.GH9434@shinkuro.com> <51F8554A-0F52-404C-AA93-1F1990FCD51E@nic.cz> Date: Mon, 1 Aug 2011 18:37:29 -0400 Message-ID: From: Phillip Hallam-Baker To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Content-Type: multipart/alternative; boundary=001636c5bbf3bd871204a979468e Cc: Andrew Sullivan , dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 22:37:24 -0000 --001636c5bbf3bd871204a979468e Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Really, the description of the FSM for resolving records to go in the OPERATIONS document? Are you serious? On Mon, Aug 1, 2011 at 6:35 PM, Ond=F8ej Sur=FD wrote: > > On 31. 7. 2011, at 20:54, Phillip Hallam-Baker wrote: > > > > > > > On Sun, Jul 31, 2011 at 12:12 PM, Andrew Sullivan > wrote: > >> Dear colleagues, > >> > >> I am sorry I was unable to make the DANE meeting on Friday either in > >> person or remotely. I was called away on urgent family business. > >> Nevertheless, I have read the document. I have yet to read a complete > >> and coherent critique of the current text in the document. In > particular, > >> > >> On Sun, Jul 31, 2011 at 11:23:31AM -0400, Phillip Hallam-Baker wrote: > >> > > >> > By fully addressed I mean that there is a defined algorithm for > resolving > >> > DANE DNS RRs that is compatible with administrative use cases for us= e > of > >> > Wildcare and alias (CNAME, DNAME) records. > >> > > >> > The current appendix suggests options but does not mandate a > particular > >> > behavior. Thus DNS administrators deploying DANE cannot rely on thes= e > >> > records actually working. > >> > >> that requirement is completely bogus. DNS zone operators have and > >> have always had a wide degree of operational freedom with their zones. > > > > They can stuff records in zones. > > > > But they can't predict what effect the records will have unless the > resolution semantics are defined. And if they can't predict the effect of= a > configuration they can't use it. > > Can you please send an examples where and when do you think the resolutio= n > semantics is not defined. With my DNS glasses on I am just unable to see > the problem you are referring to. CNAME is an internal DNS mechanism and > should not be interpreted by end clients, just by DNS resolvers. Thus th= e > DANE client asks for TLSA at _prefix.example.com and gets the result (or > NXDOMAIN) with no knowledge of CNAMEs at all (and the knowledge is not > needed). > > I clearly doesn't understand what is the case you are worried about. Cou= ld > you please clarify more? Use case or an example would be much appreciate= d, > so we don't get entangled into the words. > > > > >> The above seems to suggest that DANE might try to require one and only > >> one way to use DNAME and CNAME records (not to mention wildcards) in a > >> zone in the presence of RRTYPEs that are the result of DANE work. But > >> we don't get to make those rules. All we can do is say, "Here's what > >> you need to take into consideration." It's the operator's zone. S/he > >> will do as s/he pleases. All we can do is suggest tactics to maximize > >> interoperation. > > > > What is at issue here is a requirement for client application developer= s. > > > > The operator can't make an informed decision if different client take > different approaches. > > > > That is why it is a standards issue. > > I feel you are probably right that we need to be more specific how the > clients should behave (aka just ask for _prefix.example.com). However I > propose that we put this into the DANE operations document the WG agreed = to > work on instead into the DANE protocol document. > > The chairs will work on starting the work on this issue shortly. > > O. > P.S.: Sorry for not wrapping. If somebody knows how to force Mail.app to > wrap lines, please send me the hint off-list. > -- > Ond=F8ej Sur=FD > vedouc=ED v=FDzkumu/Head of R&D department > ------------------------------------------- > CZ.NIC, z.s.p.o. -- Laborato=F8e CZ.NIC > Americka 23, 120 00 Praha 2, Czech Republic > mailto:ondrej.sury@nic.cz http://nic.cz/ > tel:+420.222745110 fax:+420.222745112 > ------------------------------------------- > > --=20 Website: http://hallambaker.com/ --001636c5bbf3bd871204a979468e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Really, the description of the FSM for resolving records to go in the OPERA= TIONS document?

Are you serious?


On Mon, Aug 1, 2011 at 6:35 PM, Ond= =C5=99ej Sur=C3=BD <ondrej.sury@nic.cz> wrote:

On 31. 7. 2011, at 20:54, Phillip Hallam-Baker wrote:

>
>
> On Sun, Jul 31, 2011 at 12:12 PM, Andrew Sullivan <ajs@crankycanuck.ca> wrote:
>> Dear colleagues,
>>
>> I am sorry I was unable to make the DANE meeting on Friday either = in
>> person or remotely. =C2=A0I was called away on urgent family busin= ess.
>> Nevertheless, I have read the document. =C2=A0I have yet to read a= complete
>> and coherent critique of the current text in the document. =C2=A0I= n particular,
>>
>> On Sun, Jul 31, 2011 at 11:23:31AM -0400, Phillip Hallam-Baker wro= te:
>> >
>> > By fully addressed I mean that there is a defined algorithm f= or resolving
>> > DANE DNS RRs that is compatible with administrative use cases= for use of
>> > Wildcare and alias (CNAME, DNAME) records.
>> >
>> > The current appendix suggests options but does not mandate a = particular
>> > behavior. Thus DNS administrators deploying DANE cannot rely = on these
>> > records actually working.
>>
>> that requirement is completely bogus. =C2=A0DNS zone operators hav= e and
>> have always had a wide degree of operational freedom with their zo= nes.
>
> They can stuff records in zones.
>
> But they can't predict what effect the records will have unless th= e resolution semantics are defined. And if they can't predict the effec= t of a configuration they can't use it.

Can you please send an examples where and when do you think the resol= ution semantics is not defined. =C2=A0With my DNS glasses on I am just unab= le to see the problem you are referring to. =C2=A0CNAME is an internal DNS = mechanism and should not be interpreted by end clients, just by DNS resolve= rs. =C2=A0Thus the DANE client asks for TLSA at _prefix.example.com and gets the result (o= r NXDOMAIN) with no knowledge of CNAMEs at all (and the knowledge is not ne= eded).

I clearly doesn't understand what is the case you are worried about. = =C2=A0Could you please clarify more? =C2=A0Use case or an example would be = much appreciated, so we don't get entangled into the words.

>
>> The above seems to suggest that DANE might try to require one and = only
>> one way to use DNAME and CNAME records (not to mention wildcards) = in a
>> zone in the presence of RRTYPEs that are the result of DANE work. = =C2=A0But
>> we don't get to make those rules. =C2=A0All we can do is say, = "Here's what
>> you need to take into consideration." =C2=A0It's the oper= ator's zone. =C2=A0S/he
>> will do as s/he pleases. =C2=A0All we can do is suggest tactics to= maximize
>> interoperation.
>
> What is at issue here is a requirement for client application develope= rs.
>
> The operator can't make an informed decision if different client t= ake different approaches.
>
> That is why it is a standards issue.

I feel you are probably right that we need to be more specific how th= e clients should behave (aka just ask for _prefix.example.com). =C2=A0However I propose th= at we put this into the DANE operations document the WG agreed to work on i= nstead into the DANE protocol document.

The chairs will work on starting the work on this issue shortly.

O.
P.S.: Sorry for not wrapping. =C2=A0If somebody knows how to force Mail.app= to wrap lines, please send me the hint off-list.
--
=C2=A0Ond=C5=99ej Sur=C3=BD
=C2=A0vedouc=C3=AD v=C3=BDzkumu/Head of R&D department
=C2=A0-------------------------------------------
=C2=A0CZ.NIC, z.s.p.o. =C2=A0 =C2=A0-- =C2=A0 =C2=A0Laborato=C5=99e CZ.NIC<= br> =C2=A0Americka 23, 120 00 Praha 2, Czech Republic
=C2=A0mailto:ondrej.sury@nic.cz = =C2=A0 =C2=A0http://nic.cz/
=C2=A0tel:+420.222= 745110 =C2=A0 =C2=A0 =C2=A0 fax:+420.222745112
=C2=A0-------------------------------------------




--
Website: http://hallambaker.com/

--001636c5bbf3bd871204a979468e-- From ondrej.sury@nic.cz Mon Aug 1 15:46:35 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D90D1F0C4E for ; Mon, 1 Aug 2011 15:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.244 X-Spam-Level: X-Spam-Status: No, score=-0.244 tagged_above=-999 required=5 tests=[AWL=1.455, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQNEOSvXZuRU for ; Mon, 1 Aug 2011 15:46:34 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 312C21F0C49 for ; Mon, 1 Aug 2011 15:46:34 -0700 (PDT) Received: from [10.0.0.12] (247.78.broadband13.iol.cz [90.180.78.247]) by mail.nic.cz (Postfix) with ESMTPSA id EF9262A06BC; Tue, 2 Aug 2011 00:46:40 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1312238801; bh=gnZI2F0SvGqemUiDnt4UikRSJp9iCNtEcundFBCEmVI=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=t1eNwXftHKKottblcF2QYPECwavqZLNpCywNUfrZ1/N52rUVw1GWw1bk2o855bfDp Gy+WZJdUxLMPljWnMF1QCRc/j2tqfxUjYQFvVj4c34rjXJK5J7JfrlRTM4v9JoZgDl 1T+E8TMjUm3sOxlxZwyiat5PjOA2ByhxmKb1d2/I= Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: Date: Tue, 2 Aug 2011 00:46:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8C4317B9-1F7C-49BB-8503-AA906B930252@nic.cz> References: <4B7B160E-B835-44E3-A5A8-8DC50E3498FD@vpnc.org> <20110731161210.GH9434@shinkuro.com> <20110731202601.GJ9434@shinkuro.com> <20110801014459.GD20015@shinkuro.com> <4E366812.5090206@mnt.se> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1244.3) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 22:46:35 -0000 On 1. 8. 2011, at 21:47, Phillip Hallam-Baker wrote: > For example: >=20 > Resolution of TLSA records. >=20 > A relying party resolves the TLSA records for the Internet service at = port X of domain D as follows: >=20 > 1) A prefix label P is formed by appending the underscore '_' = character (ASCII ...) to the decimal value of the port number. >=20 > 2) The RP issues a query for the TLSA Qtype at P.D >=20 > 2a) If the query returns a result, the resolution process is complete = and the result is the records returned. >=20 > 3) The RP issues a query to determine if D is aliased. To do this the = RP MAY issue a query for any Qtype at D. >=20 > 3a) If the query result does not contain a record indicating an alias = mapping, the resolution process is complete and the result is null. >=20 > 3b) The query result returns an alias mapping D to A.=20 >=20 > 4) The RP issues queries for QTYPE TLSA at P.A and for any Qtype at A >=20 > 4a) If the query for the TLSA record returns a result, the resolution = is complete and the result is the result of the query, otherwise >=20 > 4b) If the query for A returns an alias mapping to AA and the alias = count limit has not been reached, the RP sets A =3D AA and repeats step = 4 >=20 > 4c) Otherwise the result of the resolution is null. >=20 >=20 > It looks a little complex set out but it is pretty straightforward in = practice and can be implemented by any DNS interface library that allows = arbitrary DNS records to be resolved. I do not believe that there is any = library out there that will allow you to obtain a TLSA record without = being able to resolve CNAME. >=20 > In practice what I would expect to see is: >=20 > www.example.com CNAME example.com > _443._port.example.com TLSA fooooo=20 > example.com A 10.1.1.1 I still don't understand why you are so worried by saying: If you want to secure the www.example.com and example.com you need to = have TLSA at both of them. The current doc is clear on that: ; TLSA record for original domin has CNAME to target domain ; sub5.example.com. IN CNAME sub6.example.com. _443_tcp.sub5.example.com. IN CNAME _443_tcp.sub6.example.com. sub6.example.com. IN A 10.0.0.0 _443_tcp.sub6.example.com. IN TLSA 1 1 536a570ac49d9ba4... Your proposal changes the semantics of how the CNAME is interpreted by = applications (currently it should not be interpreted at all) and from my = viewpoint it doesn't solve any protocol problem. The problem can be = easily solved by provisioning. And I have seen more then one lengthy = argument on DNSEXT that the DNS should not solve the provisioning = problems. Although my position is still the same. I want to see this clearly = stated and explained in the operational document, so it leaves no doubts = what the implementors, operators and domain owners should do. O. -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From ondrej.sury@nic.cz Mon Aug 1 15:54:24 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B94F61F0C50 for ; Mon, 1 Aug 2011 15:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.484 X-Spam-Level: X-Spam-Status: No, score=0.484 tagged_above=-999 required=5 tests=[AWL=-0.728, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_43=0.6, MIME_8BIT_HEADER=0.3, SARE_URGBIZ=0.725, URG_BIZ=1.585] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZtNfki4RYC6 for ; Mon, 1 Aug 2011 15:54:24 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 7ECD41F0C49 for ; Mon, 1 Aug 2011 15:54:23 -0700 (PDT) Received: from [10.0.0.12] (247.78.broadband13.iol.cz [90.180.78.247]) by mail.nic.cz (Postfix) with ESMTPSA id 3EF4C2A06BC; Tue, 2 Aug 2011 00:54:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1312239270; bh=Z6+Lh/goAM0X9YN4okG3BNhjZ/qQQlBqZp2ieO/1de0=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=O+hoeTPK3j/urZQRJEuy1+uhZfbPur1O301Xzdx+0yjoOPn6MJeDHagt9I+GV9EsQ X6QP3e60yoNRkA6Lct/naBRwAom8auuM2nt6KMz/nMyENNFTajI1YJtaKWDTySGe6L J9kqKmxCuRW1kasCvuThTBHa/Iemgxr8foRBrZS0= Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: Date: Tue, 2 Aug 2011 00:54:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <894CA6A7-F245-4A36-8B49-D5ED1E9CEE49@nic.cz> References: <4B7B160E-B835-44E3-A5A8-8DC50E3498FD@vpnc.org> <20110731161210.GH9434@shinkuro.com> <51F8554A-0F52-404C-AA93-1F1990FCD51E@nic.cz> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1244.3) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: Andrew Sullivan , dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 22:54:24 -0000 On 2. 8. 2011, at 0:37, Phillip Hallam-Baker wrote: > Really, the description of the FSM for resolving records to go in the = OPERATIONS document? >=20 > Are you serious? I am serious. I think that current wording in the draft: The TLSA RR is not special in the DNS; it acts exactly like any other RRtype where the queried name has one or more labels prefixed to the base name, such as the SRV RRtype [RFC2782]. This sometimes causes confusion for some developers when using DNS aliasing and wildcards. clearly defines the behaviour from the DNS view. =46rom DNS point of = view there is nothing special about the TLSA record. DANE wants only = one thing from DNS - the new RRtype. That's all, no more jingles and = bells are needed, since the rest will be handled by standard behaviour = of the DNS. However we can go further and explain it more in the operations = document, where I think explanatory stuff belongs. O. > On Mon, Aug 1, 2011 at 6:35 PM, Ond=C5=99ej Sur=C3=BD = wrote: >=20 > On 31. 7. 2011, at 20:54, Phillip Hallam-Baker wrote: >=20 > > > > > > On Sun, Jul 31, 2011 at 12:12 PM, Andrew Sullivan = wrote: > >> Dear colleagues, > >> > >> I am sorry I was unable to make the DANE meeting on Friday either = in > >> person or remotely. I was called away on urgent family business. > >> Nevertheless, I have read the document. I have yet to read a = complete > >> and coherent critique of the current text in the document. In = particular, > >> > >> On Sun, Jul 31, 2011 at 11:23:31AM -0400, Phillip Hallam-Baker = wrote: > >> > > >> > By fully addressed I mean that there is a defined algorithm for = resolving > >> > DANE DNS RRs that is compatible with administrative use cases for = use of > >> > Wildcare and alias (CNAME, DNAME) records. > >> > > >> > The current appendix suggests options but does not mandate a = particular > >> > behavior. Thus DNS administrators deploying DANE cannot rely on = these > >> > records actually working. > >> > >> that requirement is completely bogus. DNS zone operators have and > >> have always had a wide degree of operational freedom with their = zones. > > > > They can stuff records in zones. > > > > But they can't predict what effect the records will have unless the = resolution semantics are defined. And if they can't predict the effect = of a configuration they can't use it. >=20 > Can you please send an examples where and when do you think the = resolution semantics is not defined. With my DNS glasses on I am just = unable to see the problem you are referring to. CNAME is an internal = DNS mechanism and should not be interpreted by end clients, just by DNS = resolvers. Thus the DANE client asks for TLSA at _prefix.example.com = and gets the result (or NXDOMAIN) with no knowledge of CNAMEs at all = (and the knowledge is not needed). >=20 > I clearly doesn't understand what is the case you are worried about. = Could you please clarify more? Use case or an example would be much = appreciated, so we don't get entangled into the words. >=20 > > > >> The above seems to suggest that DANE might try to require one and = only > >> one way to use DNAME and CNAME records (not to mention wildcards) = in a > >> zone in the presence of RRTYPEs that are the result of DANE work. = But > >> we don't get to make those rules. All we can do is say, "Here's = what > >> you need to take into consideration." It's the operator's zone. = S/he > >> will do as s/he pleases. All we can do is suggest tactics to = maximize > >> interoperation. > > > > What is at issue here is a requirement for client application = developers. > > > > The operator can't make an informed decision if different client = take different approaches. > > > > That is why it is a standards issue. >=20 > I feel you are probably right that we need to be more specific how the = clients should behave (aka just ask for _prefix.example.com). However I = propose that we put this into the DANE operations document the WG agreed = to work on instead into the DANE protocol document. >=20 > The chairs will work on starting the work on this issue shortly. >=20 > O. > P.S.: Sorry for not wrapping. If somebody knows how to force Mail.app = to wrap lines, please send me the hint off-list. > -- > Ond=C5=99ej Sur=C3=BD > vedouc=C3=AD v=C3=BDzkumu/Head of R&D department > ------------------------------------------- > CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC > Americka 23, 120 00 Praha 2, Czech Republic > mailto:ondrej.sury@nic.cz http://nic.cz/ > tel:+420.222745110 fax:+420.222745112 > ------------------------------------------- >=20 >=20 >=20 >=20 > --=20 > Website: http://hallambaker.com/ >=20 -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From paul.hoffman@vpnc.org Mon Aug 1 16:38:01 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2018D21F8C9A for ; Mon, 1 Aug 2011 16:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59wM9tCEHeI7 for ; Mon, 1 Aug 2011 16:38:00 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id ECEF421F8C99 for ; Mon, 1 Aug 2011 16:37:59 -0700 (PDT) Received: from sn87.proper.com (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p71Nbjcu079139 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 1 Aug 2011 16:37:46 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Paul Hoffman In-Reply-To: Date: Mon, 1 Aug 2011 16:38:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <420783C3-CD43-4F5F-914E-DB13B8CB1169@vpnc.org> References: <4B7B160E-B835-44E3-A5A8-8DC50E3498FD@vpnc.org> <20110731161210.GH9434@shinkuro.com> <20110731202601.GJ9434@shinkuro.com> <20110801014459.GD20015@shinkuro.com> <4E366812.5090206@mnt.se> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1244.3) Cc: DANE WG Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 23:38:01 -0000 On Aug 1, 2011, at 12:47 PM, Phillip Hallam-Baker wrote: > Resolution of TLSA records. >=20 > A relying party resolves the TLSA records for the Internet service at = port X of domain D as follows: >=20 > 1) A prefix label P is formed by appending the underscore '_' = character (ASCII ...) to the decimal value of the port number. >=20 > 2) The RP issues a query for the TLSA Qtype at P.D >=20 > 2a) If the query returns a result, the resolution process is complete = and the result is the records returned. >=20 > 3) The RP issues a query to determine if D is aliased. To do this the = RP MAY issue a query for any Qtype at D. >=20 > 3a) If the query result does not contain a record indicating an alias = mapping, the resolution process is complete and the result is null. >=20 > 3b) The query result returns an alias mapping D to A.=20 >=20 > 4) The RP issues queries for QTYPE TLSA at P.A and for any Qtype at A >=20 > 4a) If the query for the TLSA record returns a result, the resolution = is complete and the result is the result of the query, otherwise >=20 > 4b) If the query for A returns an alias mapping to AA and the alias = count limit has not been reached, the RP sets A =3D AA and repeats step = 4 >=20 > 4c) Otherwise the result of the resolution is null. Does steps 3 and 4 mean that, if the owner of D does not put in a TLSA = record, the owner of A can put in such a record and it will be accepted = by the querying party, even if the owner of D doesn't want a TLSA record = for their zone? --Paul Hoffman From johnl@iecc.com Mon Aug 1 17:13:44 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A707A21F84D7 for ; Mon, 1 Aug 2011 17:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QE9H+TwTAH34 for ; Mon, 1 Aug 2011 17:13:38 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id F2BCA21F84F0 for ; Mon, 1 Aug 2011 17:13:33 -0700 (PDT) Received: (qmail 27467 invoked from network); 2 Aug 2011 00:13:30 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 2 Aug 2011 00:13:30 -0000 Received: (qmail 84058 invoked from network); 2 Aug 2011 00:13:30 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 2 Aug 2011 00:13:30 -0000 Date: 2 Aug 2011 00:13:08 -0000 Message-ID: <20110802001308.26792.qmail@joyce.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: 7bit Subject: [dane] The Curse of The Same, was CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 00:13:45 -0000 This discussion reminds of an equally unsatisfactory one we had a few months ago about what it would mean for two TLDs to be The Same. So here's some examples: Example 1: www.foo.com CNAME www.bar.com www.bar.com A 1.2.3.4 _443._tcp.www.bar.com TLSA "bar stuff" Should an application using DANE and looking at www.foo.com find the bar stuff? Example 2: www.foo.com CNAME www.bar.com www.bar.com A 1.2.3.4 _443._tcp.www.foo.com TLSA "foo stuff" _443._tcp.www.bar.com TLSA "bar stuff" Is this valid? If so, should an application using DANE looking at www.foo.com find the foo stuff or the bar stuff? Example 3: www.foo.com CNAME www.bar.com www.bar.com A 1.2.3.4 _443._tcp.www.foo.com TLSA "foo stuff" Is this valid? If so, should an application using DANE looking at www.foo.com find the foo stuff or nothing? R's, John From hallam@gmail.com Mon Aug 1 17:44:30 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 370511F0C42 for ; Mon, 1 Aug 2011 17:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.464 X-Spam-Level: X-Spam-Status: No, score=-3.464 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-86RHrj+rjj for ; Mon, 1 Aug 2011 17:44:27 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 547731F0C3C for ; Mon, 1 Aug 2011 17:44:27 -0700 (PDT) Received: by yxp4 with SMTP id 4so4344550yxp.31 for ; Mon, 01 Aug 2011 17:44:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xrUGBIxEfHy7X9ka6kciWdsIRPkmB7HocixXsjiaZIo=; b=ikpor+plZJIIBZH3K+9JxN4z0krZkHEkNQEA/heLfKdgoRgg1qQyii9NuhEXFPP0Mx 7dtvj0Wbs3L50RumNAnd+CF9IE7BSBKncYlQmdK74rgmXVZyZzil/GGsK71uSpWc7++Z CTRmt8PdpCDIwB/iWLnSUpLtZObJRZH0kqzM4= MIME-Version: 1.0 Received: by 10.101.205.22 with SMTP id h22mr3517303anq.72.1312245874483; Mon, 01 Aug 2011 17:44:34 -0700 (PDT) Received: by 10.100.34.3 with HTTP; Mon, 1 Aug 2011 17:44:34 -0700 (PDT) In-Reply-To: <20110802001308.26792.qmail@joyce.lan> References: <20110802001308.26792.qmail@joyce.lan> Date: Mon, 1 Aug 2011 20:44:34 -0400 Message-ID: From: Phillip Hallam-Baker To: John Levine Content-Type: multipart/alternative; boundary=0016e6d27c7434e15804a97b0d41 Cc: dane@ietf.org Subject: Re: [dane] The Curse of The Same, was CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 00:44:30 -0000 --0016e6d27c7434e15804a97b0d41 Content-Type: text/plain; charset=ISO-8859-1 1) "bar stuff" 2) "foo stuff" 3) "foo stuff" Telling everyone that they are only allowed (2) is going to fail in deployment. Making analogies to SRV really does not help because SRV is itself an alias and so most of the uses for CNAME can be satisfied using the domain name mapping of SRV itself. Even so it is not possible to use SRV with wildcards and that casuses operational issues. On Mon, Aug 1, 2011 at 8:13 PM, John Levine wrote: > This discussion reminds of an equally unsatisfactory one we had a few > months ago about what it would mean for two TLDs to be The Same. So > here's some examples: > > Example 1: > > www.foo.com CNAME www.bar.com > www.bar.com A 1.2.3.4 > _443._tcp.www.bar.com TLSA "bar stuff" > > Should an application using DANE and looking at www.foo.com find the > bar stuff? > > Example 2: > > www.foo.com CNAME www.bar.com > www.bar.com A 1.2.3.4 > _443._tcp.www.foo.com TLSA "foo stuff" > _443._tcp.www.bar.com TLSA "bar stuff" > > Is this valid? If so, should an application using DANE looking at > www.foo.com find the foo stuff or the bar stuff? > > Example 3: > > www.foo.com CNAME www.bar.com > www.bar.com A 1.2.3.4 > _443._tcp.www.foo.com TLSA "foo stuff" > > Is this valid? If so, should an application using DANE looking at > www.foo.com find the foo stuff or nothing? > > R's, > John > > > > > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > -- Website: http://hallambaker.com/ --0016e6d27c7434e15804a97b0d41 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 1) "bar stuff"
2) "foo stuff"
3) "fo= o stuff"

Telling everyone that they are only allowed= (2) is going to fail in deployment.=A0

Making ana= logies to SRV really does not help because SRV is itself an alias and so mo= st of the uses for CNAME can be satisfied using the domain name mapping of = SRV itself. Even so it is not possible to use SRV with wildcards and that c= asuses operational issues.


On Mon, Aug 1, 2011 at 8= :13 PM, John Levine <johnl@taugh.com> wrote:
This discussion reminds of an equally unsatisfactory one we had a few
months ago about what it would mean for two TLDs to be The Same. =A0So
here's some examples:

Example 1:

www.foo.com CNAME www.bar.com
www.bar.com A =A0 =A0 = 1.2.3.4
_443._tcp.www.bar.com<= /a> TLSA "bar stuff"

Should an application using DANE and looking at www.foo.com find the
bar stuff?

Example 2:

www.foo.com CNAME www.bar.com
www.bar.com A =A0 =A0 = 1.2.3.4
_443._tcp.www.foo.com<= /a> TLSA "foo stuff"
_443._tcp.www.bar.com<= /a> TLSA "bar stuff"

Is this valid? =A0If so, should an application using DANE looking at
www.foo.com find the f= oo stuff or the bar stuff?

Example 3:

www.foo.com CNAME www.bar.com
www.bar.com A =A0 =A0 = 1.2.3.4
_443._tcp.www.foo.com<= /a> TLSA "foo stuff"

Is this valid? =A0If so, should an application using DANE looking at
www.foo.com find the f= oo stuff or nothing?

R's,
John





_______________________________________________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane



--
Website: http://hallambaker.com/

--0016e6d27c7434e15804a97b0d41-- From i.grok@comcast.net Mon Aug 1 20:29:41 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6272111E8156 for ; Mon, 1 Aug 2011 20:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hd-JchR73Mcg for ; Mon, 1 Aug 2011 20:29:40 -0700 (PDT) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [76.96.27.227]) by ietfa.amsl.com (Postfix) with ESMTP id 12BB811E8087 for ; Mon, 1 Aug 2011 20:29:40 -0700 (PDT) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta12.emeryville.ca.mail.comcast.net with comcast id FDDE1h0031u4NiLACFVkQQ; Tue, 02 Aug 2011 03:29:44 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta21.emeryville.ca.mail.comcast.net with comcast id FFTe1h01800PQ6U8hFTfoY; Tue, 02 Aug 2011 03:27:40 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.4/8.14.3) with ESMTP id p723Tjo0017732 for ; Mon, 1 Aug 2011 23:29:46 -0400 Received: (from draco@localhost) by odin.ulthar.us (8.14.4/8.14.4/Submit) id p723TjEi017730 for dane@ietf.org; Mon, 1 Aug 2011 23:29:45 -0400 Date: Mon, 1 Aug 2011 23:29:45 -0400 From: Scott Schmit To: dane@ietf.org Message-ID: <20110802032945.GB7532@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <4B7B160E-B835-44E3-A5A8-8DC50E3498FD@vpnc.org> <20110731161210.GH9434@shinkuro.com> <20110731202601.GJ9434@shinkuro.com> <20110801014459.GD20015@shinkuro.com> <4E366812.5090206@mnt.se> <420783C3-CD43-4F5F-914E-DB13B8CB1169@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <420783C3-CD43-4F5F-914E-DB13B8CB1169@vpnc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 03:29:41 -0000 On Mon, Aug 01, 2011 at 04:38:03PM -0700, Paul Hoffman wrote: > On Aug 1, 2011, at 12:47 PM, Phillip Hallam-Baker wrote: > > 3) The RP issues a query to determine if D is aliased. To do this the RP MAY issue a query for any Qtype at D. > > > > 3a) If the query result does not contain a record indicating an alias mapping, the resolution process is complete and the result is null. > > > > 3b) The query result returns an alias mapping D to A. > > > > 4) The RP issues queries for QTYPE TLSA at P.A and for any Qtype at A > > > > 4a) If the query for the TLSA record returns a result, the resolution is complete and the result is the result of the query, otherwise > > > > 4b) If the query for A returns an alias mapping to AA and the alias count limit has not been reached, the RP sets A = AA and repeats step 4 > > > > 4c) Otherwise the result of the resolution is null. > > Does steps 3 and 4 mean that, if the owner of D does not put in a TLSA > record, the owner of A can put in such a record and it will be > accepted by the querying party, even if the owner of D doesn't want a > TLSA record for their zone? Yes. I understand that this allows the owner of A to present a completely different certificate of its own devising instead of a cert provided by D if D doesn't use DANE to prevent that (maybe the owner of D doesn't know about DANE or can't use it due to lack of software support). But what I don't understand is what benefit that gives to the owner of A that damages the owner of D? Most things I can think of could be done even without DANE. Maybe it's normal practice for the owner of D to provide an HSM with the certificate, and this would allow the owner of A to use a less-secure key? Still, I'd think that contracts could address this, or monitoring, or something else. Even if the owner of D can't use TLSA for some reason, they can always redirect/withdraw the CNAME. After that, the the TLSA record in A will be useless for representing D. Even if it were a problem, I don't know how we'd fix it. Adding support for a NULL TLSA record provides no benefit, because that's just as opt-in as the above. Requiring a TLSA record at the source breaks wildcards. Using some kind of wildcard DNAME for this doesn't work because the DNAME doesn't cover the node itself (need BNAME or the like for that). I suppose we could say that you must check the source and wildcard support requires (still-draft) BNAME, but that will certainly hurt the deployment prospects for DANE. -- Scott Schmit From i.grok@comcast.net Mon Aug 1 21:11:26 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E32CC21F8D19 for ; Mon, 1 Aug 2011 21:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.276 X-Spam-Level: X-Spam-Status: No, score=-102.276 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_00=-2.599, J_CHICKENPOX_17=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F+o3mV1oqImo for ; Mon, 1 Aug 2011 21:11:24 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by ietfa.amsl.com (Postfix) with ESMTP id DD93B21F8D18 for ; Mon, 1 Aug 2011 21:11:18 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta06.westchester.pa.mail.comcast.net with comcast id FF8v1h0051vXlb856GBTB9; Tue, 02 Aug 2011 04:11:27 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta17.westchester.pa.mail.comcast.net with comcast id FGBQ1h00800PQ6U3dGBQH1; Tue, 02 Aug 2011 04:11:26 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.4/8.14.3) with ESMTP id p724BK8l017794 for ; Tue, 2 Aug 2011 00:11:20 -0400 Received: (from draco@localhost) by odin.ulthar.us (8.14.4/8.14.4/Submit) id p724BKgX017792 for dane@ietf.org; Tue, 2 Aug 2011 00:11:20 -0400 Date: Tue, 2 Aug 2011 00:11:20 -0400 From: Scott Schmit To: dane@ietf.org Message-ID: <20110802041120.GC7532@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <4B7B160E-B835-44E3-A5A8-8DC50E3498FD@vpnc.org> <20110731161210.GH9434@shinkuro.com> <51F8554A-0F52-404C-AA93-1F1990FCD51E@nic.cz> <894CA6A7-F245-4A36-8B49-D5ED1E9CEE49@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <894CA6A7-F245-4A36-8B49-D5ED1E9CEE49@nic.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 04:11:26 -0000 On Tue, Aug 02, 2011 at 12:54:29AM +0200, Ondřej Surý wrote: > On 2. 8. 2011, at 0:37, Phillip Hallam-Baker wrote: > > > Really, the description of the FSM for resolving records to go in > > the OPERATIONS document? > > > > Are you serious? > > I am serious. I think that current wording in the draft: > > The TLSA RR is not special in the DNS; it acts exactly like any other > RRtype where the queried name has one or more labels prefixed to the > base name, such as the SRV RRtype [RFC2782]. This sometimes causes > confusion for some developers when using DNS aliasing and wildcards. > > clearly defines the behaviour from the DNS view. From DNS point of > view there is nothing special about the TLSA record. DANE wants only > one thing from DNS - the new RRtype. That's all, no more jingles and > bells are needed, since the rest will be handled by standard behaviour > of the DNS. > > However we can go further and explain it more in the operations > document, where I think explanatory stuff belongs. I disagree. The concern isn't that an operator will do: a.example CNAME b.example b.example AAAA 2001:db8::1 _443._tcp.b.example TLSA bstuff and not realize that a query for TLSA at _443._tcp.a.example will return NXDOMAIN instead of "bstuff". The issue is that: 1) the user & developer don't know if the above should result in "DANE's not in use, fall back to normal processing" or if the CNAME should be followed and the prefix checked there 2) the user & developer don't know what will happen in this case: a.example CNAME b.example _443._tcp.a.example TLSA astuff b.example AAAA 2001:db8::1 _443._tcp.b.example TLSA bstuff 2a) Failure (because the records contradict)? 2b) Fallback (because the records contradict)? 2c) A wins? ("Because it owns the CNAME") 2d) B wins? ("Because that's where the server is & is more likely to be right") 3) if there's a chain of CNAMEs, what then? First hit? Last hit? All must match? All must match & be present? Pick one at random? In other words, nobody is asking about wildcarding or aliasing the TLSA record itself (the focus of Appendix A). We're wondering what happens if you wildcard or alias the name the TLSA record is for (the subject). This is what the wildcard and redirection requirements in the use case document should be about, though the wording fails to make that clear. This is a protocol question, not an element of deployment advice. Well, it can be both, but it has to be clear in the protocol first. Like I've said before, the best option seems to be "follow the CNAME chain of the subject to an address record, check the prefix for each name, and use the first TLSA record you find." -- Scott Schmit From jakob@kirei.se Mon Aug 1 22:43:12 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7CD421F8B07 for ; Mon, 1 Aug 2011 22:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.036 X-Spam-Level: X-Spam-Status: No, score=-0.036 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, J_CHICKENPOX_17=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WgPXJiT9xVBi for ; Mon, 1 Aug 2011 22:43:12 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4C111E8070 for ; Mon, 1 Aug 2011 22:43:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=E17rj5Bb/lSIqX5VA7oBiok0SB9xMmF8lp/J5L3Dahs=; b=yl+gFK0m8t7/QbrootM1ZpT0UjyMCJC2AT86JKcsYmCntE8lvA3vlY055v8WT/smQTnK5OHsBH+5N I8kUJ0eEQ6DTvsdcSVH6Ik1jjUAXyjWGj6v+oaPpYg8PNSPPaPpZPN7kw8dMaEqoCsukSHCqkZTgVv uFpVCZmsjvnpElA8= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Tue, 2 Aug 2011 07:43:10 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: <20110802041120.GC7532@odin.ulthar.us> Date: Tue, 2 Aug 2011 07:43:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7D463057-B31F-4472-B3A8-C197D659E5F8@kirei.se> References: <4B7B160E-B835-44E3-A5A8-8DC50E3498FD@vpnc.org> <20110731161210.GH9434@shinkuro.com> <51F8554A-0F52-404C-AA93-1F1990FCD51E@nic.cz> <894CA6A7-F245-4A36-8B49-D5ED1E9CEE49@nic.cz> <20110802041120.GC7532@odin.ulthar.us> To: Scott Schmit X-Mailer: Apple Mail (2.1244.3) Cc: dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 05:43:13 -0000 On 2 aug 2011, at 06:11, Scott Schmit wrote: > The issue is that: > 1) the user & developer don't know if the above should result in = "DANE's > not in use, fall back to normal processing" or if the CNAME should be > followed and the prefix checked there Why would the developer even consider that, given the current text in = the draft? The developer will do something like getrrsetbyname(_443._tcp.a.example, = TLSA) and get back NXDOMAIN. Trying to detect the end of the CNAME chain = requires a lot more work. > 2) the user & developer don't know what will happen in this case: >=20 > a.example CNAME b.example > _443._tcp.a.example TLSA astuff > b.example AAAA 2001:db8::1 > _443._tcp.b.example TLSA bstuff >=20 > 2a) Failure (because the records contradict)? > 2b) Fallback (because the records contradict)? > 2c) A wins? ("Because it owns the CNAME") > 2d) B wins? ("Because that's where the server is & is more likely to = be > right") What happens depends on what name the user started with - this is a = perfect valid scenario for TLS when using SNI (RFC 4366) and a & b has = different certs (even though they live on the same endpoint). > 3) if there's a chain of CNAMEs, what then? First hit? Last hit? All > must match? All must match & be present? Pick one at random? DANE works just like any other application using DNS - nothing special = here. DNS is QNAME/QCLASS/QTYPE -> ANSWER. You do NOT look at stuff in = the middle of that process. > Like I've said before, the best option seems to be "follow the CNAME > chain of the subject to an address record, check the prefix for each > name, and use the first TLSA record you find." No other protocol is using this approach, it is not easy to implement = and it is not best current practice for developers. jakob From jakob@kirei.se Mon Aug 1 22:45:56 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0916C11E8075 for ; Mon, 1 Aug 2011 22:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.343 X-Spam-Level: X-Spam-Status: No, score=-0.343 tagged_above=-999 required=5 tests=[AWL=0.355, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1yJ3Kj9I4V8j for ; Mon, 1 Aug 2011 22:45:54 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id 48ACF11E8070 for ; Mon, 1 Aug 2011 22:45:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=NO5D4NN7HJILv6RhKyfVAvrNzlIyjOgs7uhpieIrS6U=; b=QItNKI+BLzn8/Aw5NxfnCwxFCmfGeX9wFQCq6yqPKy/BoTNiIoFU4cQ2lIjr2lQH4O+8TYj/hgPFg 66zbs02CR4wb+0+OEVRnNyb5lEk0yoW4BiMFbqitl6kND2PFCHezTqegkxxEW6u+M3qxTAb6w1x5eJ ttkV19Bq1rGZlTSE= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Tue, 2 Aug 2011 07:46:01 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: <20110802001308.26792.qmail@joyce.lan> Date: Tue, 2 Aug 2011 07:46:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110802001308.26792.qmail@joyce.lan> To: John Levine X-Mailer: Apple Mail (2.1244.3) Cc: dane@ietf.org Subject: Re: [dane] The Curse of The Same, was CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 05:45:56 -0000 On 2 aug 2011, at 02:13, John Levine wrote: > This discussion reminds of an equally unsatisfactory one we had a few > months ago about what it would mean for two TLDs to be The Same. So > here's some examples: >=20 > Example 1: >=20 > www.foo.com CNAME www.bar.com > www.bar.com A 1.2.3.4 > _443._tcp.www.bar.com TLSA "bar stuff" >=20 > Should an application using DANE and looking at www.foo.com find the > bar stuff? An application using DANE would not look up www.foo.com, as this name = does not carry any TLSA records. The application would look up = _443._tcp.www.foo.com, which returns nothing. > Example 2: >=20 > www.foo.com CNAME www.bar.com > www.bar.com A 1.2.3.4 > _443._tcp.www.foo.com TLSA "foo stuff" > _443._tcp.www.bar.com TLSA "bar stuff" >=20 > Is this valid? If so, should an application using DANE looking at > www.foo.com find the foo stuff or the bar stuff? Yes, this is valid. See my not on SNI in another thread (foo & bar may = have different certs at the same endpoint). > Example 3: >=20 > www.foo.com CNAME www.bar.com > www.bar.com A 1.2.3.4 > _443._tcp.www.foo.com TLSA "foo stuff" >=20 > Is this valid? If so, should an application using DANE looking at > www.foo.com find the foo stuff or nothing? Yes, it will find foo stuff. If you try to look at bar, you will find = nothing. jakob From ondrej.sury@nic.cz Tue Aug 2 00:46:19 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A85121F8E75 for ; Tue, 2 Aug 2011 00:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cdJCvFJTaPXU for ; Tue, 2 Aug 2011 00:46:18 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id E438E21F8E6F for ; Tue, 2 Aug 2011 00:46:11 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:f8b0:3b9e:90c2:744c] (unknown [IPv6:2001:1488:ac14:1400:f8b0:3b9e:90c2:744c]) by mail.nic.cz (Postfix) with ESMTPSA id 928BE2A2CD6; Tue, 2 Aug 2011 09:46:19 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1312271179; bh=AYYceg1JJDfS6uOJl0DjBAwV1K74wsh8MUZ518cRc6k=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=cjjkeO+Pqa236fPYkpzos0NDxgvX82GH2CzIon4MRpASHaFgZLJ6QwjlUgqLQd8B+ dN3JsnES0L0CYqeByA+n+exr6p/pKLDfJc1M68UPp9LXuKvS09rPexYaEuBgmJD6EG 2d6Q158hv+AlN12C0mSWTo2IWuxYuv/9ecd6XwQ4= Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <20110802001308.26792.qmail@joyce.lan> Date: Tue, 2 Aug 2011 09:46:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4B846C97-EE58-43CC-A324-CD48D69D8D5C@nic.cz> References: <20110802001308.26792.qmail@joyce.lan> To: John Levine X-Mailer: Apple Mail (2.1244.3) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane@ietf.org Subject: Re: [dane] The Curse of The Same, was CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 07:46:19 -0000 On 2. 8. 2011, at 2:13, John Levine wrote: > This discussion reminds of an equally unsatisfactory one we had a few > months ago about what it would mean for two TLDs to be The Same. So > here's some examples: But this is not same as the name sameness. www.foo.com and www.bar.com are different from DANE perspective. > Example 1: >=20 > www.foo.com CNAME www.bar.com > www.bar.com A 1.2.3.4 > _443._tcp.www.bar.com TLSA "bar stuff" >=20 > Should an application using DANE and looking at www.foo.com find the > bar stuff? No. > Example 2: >=20 > www.foo.com CNAME www.bar.com > www.bar.com A 1.2.3.4 > _443._tcp.www.foo.com TLSA "foo stuff" > _443._tcp.www.bar.com TLSA "bar stuff" >=20 > Is this valid? Yes, it is. > If so, should an application using DANE looking at > www.foo.com find the foo stuff or the bar stuff? It should find the foo staff, because it is looking for www.foo.com and not www.bar.com. The same applies to HTTP - you ask the HTTP server for www.foo.com and not for www.bar.com. Same logic applies for DANE. =46rom DNS perspective this case is really same as: www.foo.com A 1.2.3.4 www.bar.com A 1.2.3.4 _443._tcp.www.foo.com TLSA "foo stuff" _443._tcp.www.bar.com TLSA "bar stuff" You don't look at CNAMEs in the application. > Example 3: >=20 > www.foo.com CNAME www.bar.com > www.bar.com A 1.2.3.4 > _443._tcp.www.foo.com TLSA "foo stuff" >=20 > Is this valid? Yes, it is. > If so, should an application using DANE looking at > www.foo.com find the foo stuff or nothing? Application will find the _443._tcp.www.foo.com if it is looking for www.foo.com. Applications looking at www.bar.com will find nothing. Fortunately the usage of prefix has saved us the CNAME-only problem and I am happy to sacrifice wildcards as one use case where DANE cannot be used. Well, to be absolutely precise you can use wildcards (because _443._tcp.www.foo.com IN TLSA=20 will resolve to _443._tcp.www.bar.com IN TLSA), but I think we should discourage the usage of the wildcards. There's really no magic involved. Try asking for these: Example 1 (matches yours) dig IN A nxdomain.rfc1925.org dig IN TYPE65468 _443._tcp.nxdomain.rfc1925.org Example 2 (matches yours) dig IN A no-cname.rfc1925.org dig IN TYPE65468 _443._tcp.no-cname.rfc1925.org # TLSA at dest dig IN TYPE65468 _443._tcp.www.sury.org. Example 3 (matches yours) dig IN A no-dest-tlsa.rfc1925.org dig IN TYPE65468 _443._tcp.no-dest-tlsa.rfc1925.org # no TLSA at dest dig IN TYPE65468 _443._tcp.www2.rfc1925.org Example 4 (both CNAMEs) dig IN A cname.rfc1925.org dig IN TYPE65468 _443._tcp.cname.rfc1925.org Example 5 (no CNAMEs at all, but still sawme IP) dig IN A www.rfc1925.org dig IN TYPE65468 _443._tcp.www.rfc1925.org # Compare results to Example 2 Example 6 (chained CNAMEs works too) dig IN A chain.rfc1925.org dig IN TYPE65468 _443._tcp.chain.rfc1925.org (Kind of) Example #7 (wildcards) dig IN A blah.wildcard.rfc1925.org dig IN TYPE65468 _443._tcp.blah.wildcard.rfc1925.org # But really this is ugly and should not be recommended # If you want TLSA don't use wildcards O. -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From leifj@mnt.se Tue Aug 2 01:30:40 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1867421F8EE1 for ; Tue, 2 Aug 2011 01:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KHlWuzco2s7U for ; Tue, 2 Aug 2011 01:30:39 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 1245821F8CA9 for ; Tue, 2 Aug 2011 01:30:38 -0700 (PDT) Received: from [192.36.125.212] (dhcp.pilsnet.sunet.se [192.36.125.212]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p728UcaQ022337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Aug 2011 10:30:40 +0200 (CEST) Message-ID: <4E37B5AD.9040307@mnt.se> Date: Tue, 02 Aug 2011 10:30:37 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <4B7B160E-B835-44E3-A5A8-8DC50E3498FD@vpnc.org> <20110731161210.GH9434@shinkuro.com> <20110731202601.GJ9434@shinkuro.com> <20110801014459.GD20015@shinkuro.com> <4E366812.5090206@mnt.se> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 08:30:40 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/01/2011 09:47 PM, Phillip Hallam-Baker wrote: > On Mon, Aug 1, 2011 at 4:47 AM, Leif Johansson wrote: >> >>> Explain to me what the problem is, ideally by walking through an >>> example. >> >> +1 I would love to see an example explaining the issue! > > > The issue is that DANE has to use prefixed DNS records and these do not work > in the way that we would want them to. After having read the threads on this I think I understand that the problem is really that you have requirements on DANE beyond what is provided by DNS currently: support for general CNAME and wildcard- based delegation. While these requirements may be interesting I'm not sure why they are particular to DANE. Many uses of SRV records would seem to have the same "problem" for instance. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk43ta0ACgkQ8Jx8FtbMZnf5igCaAvk+F+LV+LkGlxpyaJaRBdu0 jhQAoI4kuvKQHKg1Xrmboqe0Sio3q2S7 =aXvA -----END PGP SIGNATURE----- From hallam@gmail.com Tue Aug 2 04:40:36 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF2F21F8EA7 for ; Tue, 2 Aug 2011 04:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.316 X-Spam-Level: X-Spam-Status: No, score=-3.316 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1V5+qADvJNq for ; Tue, 2 Aug 2011 04:40:35 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 06AE721F8E9E for ; Tue, 2 Aug 2011 04:40:34 -0700 (PDT) Received: by gyd5 with SMTP id 5so4761656gyd.31 for ; Tue, 02 Aug 2011 04:40:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XdIun/HAIi/fk3m9LO2dvKRWSGJ73CofmQHtCOg8tUY=; b=dDCTJNihf5ejiCiVqlYJ0a6H1s/AN2DY5RTBi6pScGa3DyI1rIl/prPni2I+FSWV1X LfHti4XUYftaU4S0HOn1ZzN10GzsMd5HNcDwItpPZ7zsCRy5itKPJNdhSpbXZ8CmZzHY qmY9sp/rBzSncQJoJoFRyuReZYxmlF7dKmCKY= MIME-Version: 1.0 Received: by 10.101.131.33 with SMTP id i33mr3953745ann.28.1312285243565; Tue, 02 Aug 2011 04:40:43 -0700 (PDT) Received: by 10.100.34.3 with HTTP; Tue, 2 Aug 2011 04:40:43 -0700 (PDT) In-Reply-To: <4B846C97-EE58-43CC-A324-CD48D69D8D5C@nic.cz> References: <20110802001308.26792.qmail@joyce.lan> <4B846C97-EE58-43CC-A324-CD48D69D8D5C@nic.cz> Date: Tue, 2 Aug 2011 07:40:43 -0400 Message-ID: From: Phillip Hallam-Baker To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Content-Type: multipart/alternative; boundary=001636c5be92c967cb04a98437df Cc: dane@ietf.org Subject: Re: [dane] The Curse of The Same, was CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 11:40:36 -0000 --001636c5be92c967cb04a98437df Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Aug 2, 2011 at 3:46 AM, Ond=C5=99ej Sur=C3=BD = wrote: > > On 2. 8. 2011, at 2:13, John Levine wrote: > > > This discussion reminds of an equally unsatisfactory one we had a few > > months ago about what it would mean for two TLDs to be The Same. So > > here's some examples: > > But this is not same as the name sameness. www.foo.com and www.bar.com > are different from DANE perspective. So you have made up your mind and we can't change it? I place an objection that the WG does not have my consensus on this point. I suggest you amend the PROTO writeup of all documents necessary to make it clear that there is an objection including the Use Cases document if you intend to use that to pre-empt discussion on this point. --=20 Website: http://hallambaker.com/ --001636c5be92c967cb04a98437df Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, Aug 2, 2011 at 3:46 AM, Ond=C5= =99ej Sur=C3=BD <ondrej.sury@nic.cz> wrote:

On 2. 8. 2011, at 2:13, John Levine wrote:

> This discussion reminds of an equally unsatisfactory one we had a few<= br> > months ago about what it would mean for two TLDs to be The Same. =C2= =A0So
> here's some examples:

But this is not same as the name sameness. =C2=A0www.foo.com and www.bar.com
are different from DANE perspective.

So you= have made up your mind and we can't change it?

I place an objection that the WG does not have my consensus on this point= .


I suggest you amend the PROTO writeup of= all documents necessary to make it clear that there is an objection includ= ing the Use Cases document if you intend to use that to pre-empt discussion= on this point.




--
Website: http://hallambaker.com/

--001636c5be92c967cb04a98437df-- From hallam@gmail.com Tue Aug 2 05:22:38 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C60F21F8581 for ; Tue, 2 Aug 2011 05:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.466 X-Spam-Level: X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WP1u046-gHMN for ; Tue, 2 Aug 2011 05:22:36 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 42B4621F852E for ; Tue, 2 Aug 2011 05:22:35 -0700 (PDT) Received: by gxk19 with SMTP id 19so4782485gxk.31 for ; Tue, 02 Aug 2011 05:22:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gy53X7VexYcygVIGyN8em0fMAsDCuQGY01kiqnK7O1w=; b=HlM+3PAM8uMfQi9YZUuv9mC52zEp8tjeeR7DQwBhe6t29zWeUptS5xN6sQR3fcL4Qd 8jQT8JmCR9+N95Z8Z+32efzEgYzOwFN+5tBWHfoP0ujFmoqvyvpBrXmjsqzITYh/hN6W qHKSzEX+9TIafJvaTdvgt/Y6rVeA3DjUm3nis= MIME-Version: 1.0 Received: by 10.101.131.33 with SMTP id i33mr3987037ann.28.1312287763893; Tue, 02 Aug 2011 05:22:43 -0700 (PDT) Received: by 10.100.34.3 with HTTP; Tue, 2 Aug 2011 05:22:43 -0700 (PDT) In-Reply-To: <4E37B5AD.9040307@mnt.se> References: <4B7B160E-B835-44E3-A5A8-8DC50E3498FD@vpnc.org> <20110731161210.GH9434@shinkuro.com> <20110731202601.GJ9434@shinkuro.com> <20110801014459.GD20015@shinkuro.com> <4E366812.5090206@mnt.se> <4E37B5AD.9040307@mnt.se> Date: Tue, 2 Aug 2011 08:22:43 -0400 Message-ID: From: Phillip Hallam-Baker To: Leif Johansson Content-Type: multipart/alternative; boundary=001636c5be92028c4a04a984ceea Cc: dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 12:22:38 -0000 --001636c5be92028c4a04a984ceea Content-Type: text/plain; charset=ISO-8859-1 On Tue, Aug 2, 2011 at 4:30 AM, Leif Johansson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 08/01/2011 09:47 PM, Phillip Hallam-Baker wrote: > > On Mon, Aug 1, 2011 at 4:47 AM, Leif Johansson wrote: > >> > >>> Explain to me what the problem is, ideally by walking through an > >>> example. > >> > >> +1 I would love to see an example explaining the issue! > > > > > > The issue is that DANE has to use prefixed DNS records and these do not > work > > in the way that we would want them to. > > After having read the threads on this I think I understand that the > problem is really that you have requirements on DANE beyond what is > provided by DNS currently: support for general CNAME and wildcard- > based delegation. > > While these requirements may be interesting I'm not sure why they > are particular to DANE. Many uses of SRV records would seem to have > the same "problem" for instance. > 1) SRV is a form of alias so the issue there is not so critical, the following records have similar effect: www.example.com CNAME alias.example.com www.example.com SRV 1 1 80 alias.example.com 2) Use of SRV has in practice been made much more restrictive than we would wish precisely because it does not address these issues as we would wish. 3) The DNS protocol considers prefixing a name to create a completely different name. That is certainly not the semantics that use of prefixes is trying to create. -- Website: http://hallambaker.com/ --001636c5be92028c4a04a984ceea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Aug 2, 2011 at 4:30 AM, Leif Joh= ansson <leifj@mnt.se> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/01/2011 09:47 PM, Phillip Hallam-Baker wrote:=
> =A0On Mon, Aug 1, 2011 at 4:47 AM, Leif Johansson <leifj@mnt.se> wrote:
>>
>>> Explain to me what the problem is, ideally by walking through = an
>>> example.
>>
>> +1 I would love to see an example explaining the issue!
>
>
> The issue is that DANE has to use prefixed DNS records and these do no= t work
> in the way that we would want them to.

After having read the threads on this I think I understand that the problem is really that you have requirements on DANE beyond what is
provided by DNS currently: support for general CNAME and wildcard-
based delegation.

While these requirements may be interesting I'm not sure why they
are particular to DANE. Many uses of SRV records would seem to have
the same "problem" for instance.

<= div>1) SRV is a form of alias so the issue there is not so critical, the fo= llowing records have similar effect:

www.example.com =A0SRV 1 1 80 <= a href=3D"http://alias.example.com">alias.example.com

=A0
2) Use of SRV has in practice been made much more res= trictive than we would wish precisely because it does not address these iss= ues as we would wish.


3) The DNS protocol considers prefixing = a name to create a completely different name. That is certainly not the sem= antics that use of prefixes is trying to create.

--
Website: http://hallambaker.com/=

--001636c5be92028c4a04a984ceea-- From leifj@mnt.se Tue Aug 2 06:04:37 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1C9221F8D1D for ; Tue, 2 Aug 2011 06:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PD1V1HFBz94i for ; Tue, 2 Aug 2011 06:04:37 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id F288D21F8D1A for ; Tue, 2 Aug 2011 06:04:36 -0700 (PDT) Received: from [192.36.125.212] (dhcp.pilsnet.sunet.se [192.36.125.212]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p72D4cfX009427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Aug 2011 15:04:41 +0200 (CEST) Message-ID: <4E37F5E6.2040708@mnt.se> Date: Tue, 02 Aug 2011 15:04:38 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <4B7B160E-B835-44E3-A5A8-8DC50E3498FD@vpnc.org> <20110731161210.GH9434@shinkuro.com> <20110731202601.GJ9434@shinkuro.com> <20110801014459.GD20015@shinkuro.com> <4E366812.5090206@mnt.se> <4E37B5AD.9040307@mnt.se> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 13:04:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/02/2011 02:22 PM, Phillip Hallam-Baker wrote: > On Tue, Aug 2, 2011 at 4:30 AM, Leif Johansson wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 08/01/2011 09:47 PM, Phillip Hallam-Baker wrote: >>> On Mon, Aug 1, 2011 at 4:47 AM, Leif Johansson wrote: >>>> >>>>> Explain to me what the problem is, ideally by walking through an >>>>> example. >>>> >>>> +1 I would love to see an example explaining the issue! >>> >>> >>> The issue is that DANE has to use prefixed DNS records and these do not >> work >>> in the way that we would want them to. >> >> After having read the threads on this I think I understand that the >> problem is really that you have requirements on DANE beyond what is >> provided by DNS currently: support for general CNAME and wildcard- >> based delegation. >> >> While these requirements may be interesting I'm not sure why they >> are particular to DANE. Many uses of SRV records would seem to have >> the same "problem" for instance. >> > > 1) SRV is a form of alias so the issue there is not so critical, the > following records have similar effect: > > www.example.com CNAME alias.example.com > www.example.com SRV 1 1 80 alias.example.com But that is not the common use of SRV records - a more representative example would be one for the XMPP server for a domain: _xmpp-server._tcp.example.org IN SRV 5 0 5269 xmpp.example.com Evidently users have learned to live with adding not only one but multiple entries like that to their domain (look at any zone enabled for google apps for instance). Note that in this case there are even comparable security implications since the XMPP call-back server-2-server authentication relies on those SRV records. I re-iterate: how is the use of SRV records for locating XMPP servers fundamentally different from TLSA? Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk439eYACgkQ8Jx8FtbMZncWTQCgm3tO0jk9FxYbNwIa69KLBolD KWQAoMLUdDmqjvxNjauDGDlR3COvIbGI =gCNv -----END PGP SIGNATURE----- From lconroy@insensate.co.uk Tue Aug 2 06:21:27 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A94221F87D6 for ; Tue, 2 Aug 2011 06:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OMn1aoJUgZi5 for ; Tue, 2 Aug 2011 06:21:26 -0700 (PDT) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by ietfa.amsl.com (Postfix) with ESMTP id 0479A21F87E2 for ; Tue, 2 Aug 2011 06:21:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 96420845433; Tue, 2 Aug 2011 14:21:30 +0100 (BST) X-Virus-Scanned: amavisd-new at insensate.co.uk Received: from insensate.co.uk ([127.0.0.1]) by localhost (psyche.insensate.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhwn9aeguPz6; Tue, 2 Aug 2011 14:21:30 +0100 (BST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 2F58D845421; Tue, 2 Aug 2011 14:21:28 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Lawrence Conroy In-Reply-To: Date: Tue, 2 Aug 2011 14:21:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <53C4560E-3FEE-424C-ABBE-49508867548A@insensate.co.uk> References: <4B7B160E-B835-44E3-A5A8-8DC50E3498FD@vpnc.org> <20110731161210.GH9434@shinkuro.com> <20110731202601.GJ9434@shinkuro.com> <20110801014459.GD20015@shinkuro.com> <4E366812.5090206@mnt.se> <4E37B5AD.9040307@mnt.se> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1084) Cc: dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 13:21:27 -0000 Hi Folks, I'm sure I will regret this, but sign me up as yet another person who = has no idea what PHB sees is a problem. Your first comment on SRVs seems plain wrong, so I guess I must be = misunderstanding. [example of functional CNAME is:: dig news.bbc.co.uk A. I would not = expect the same effect in my browser if they had put an SRV at the same owner] Your second one invokes a "we" and "wish", but it is really not clear = who we are and what we wish in common. Your third statement is a curate's egg. The first sentence I understand = (although most folk seem to prefer the term different "owner"). The second = sentence seem certain about something, but I have no idea what. Please clarify, as I'm not alone in simply missing the point here. all the best, Lawrence On 2 Aug 2011, at 13:22, Phillip Hallam-Baker wrote: > 1) SRV is a form of alias so the issue there is not so critical, the > following records have similar effect: >=20 > www.example.com CNAME alias.example.com > www.example.com SRV 1 1 80 alias.example.com >=20 >=20 > 2) Use of SRV has in practice been made much more restrictive than we = would > wish precisely because it does not address these issues as we would = wish. >=20 >=20 > 3) The DNS protocol considers prefixing a name to create a completely > different name. That is certainly not the semantics that use of = prefixes is > trying to create. From ondrej.sury@nic.cz Tue Aug 2 06:34:47 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B381021F8561 for ; Tue, 2 Aug 2011 06:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_17=0.6, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iEXUyo3CS-k4 for ; Tue, 2 Aug 2011 06:34:47 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 72EC121F855D for ; Tue, 2 Aug 2011 06:34:46 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:7471:3a24:a5d1:f441] (unknown [IPv6:2001:1488:ac14:1400:7471:3a24:a5d1:f441]) by mail.nic.cz (Postfix) with ESMTPSA id C16602A2CF2; Tue, 2 Aug 2011 15:34:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1312292094; bh=kYqAarv9fyZnZJy4C5y/WyM8h5ZA8eOIcerVopZPeZw=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ryvOeqDvU2ibCSMRQ70+C8dPdNkMeQwbX4fgvnixPy4tH8zxHejk6akAW/fCdJo7i Utz27+CNkYuS/CmAQkVjjSCXwT9E+WqxQkXVnD/CBo2OIKak8F9G0sNrtDODw0ie6m /bibAPWH/qnO7EjaRxTNf+kFHWAnTYcwktXExlf8= Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <20110802041120.GC7532@odin.ulthar.us> Date: Tue, 2 Aug 2011 15:34:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <15EA9477-097B-4191-B539-C24572A20CC9@nic.cz> References: <4B7B160E-B835-44E3-A5A8-8DC50E3498FD@vpnc.org> <20110731161210.GH9434@shinkuro.com> <51F8554A-0F52-404C-AA93-1F1990FCD51E@nic.cz> <894CA6A7-F245-4A36-8B49-D5ED1E9CEE49@nic.cz> <20110802041120.GC7532@odin.ulthar.us> To: Scott Schmit X-Mailer: Apple Mail (2.1244.3) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 13:34:47 -0000 On 2. 8. 2011, at 6:11, Scott Schmit wrote: > On Tue, Aug 02, 2011 at 12:54:29AM +0200, Ond=C5=99ej Sur=C3=BD wrote: >> On 2. 8. 2011, at 0:37, Phillip Hallam-Baker wrote: >>=20 >>> Really, the description of the FSM for resolving records to go in >>> the OPERATIONS document? >>>=20 >>> Are you serious? >>=20 >> I am serious. I think that current wording in the draft: >>=20 >> The TLSA RR is not special in the DNS; it acts exactly like any = other >> RRtype where the queried name has one or more labels prefixed to = the >> base name, such as the SRV RRtype [RFC2782]. This sometimes causes >> confusion for some developers when using DNS aliasing and = wildcards. >>=20 >> clearly defines the behaviour from the DNS view. =46rom DNS point of >> view there is nothing special about the TLSA record. DANE wants only >> one thing from DNS - the new RRtype. That's all, no more jingles and >> bells are needed, since the rest will be handled by standard = behaviour >> of the DNS. >>=20 >> However we can go further and explain it more in the operations >> document, where I think explanatory stuff belongs. >=20 > I disagree. The concern isn't that an operator will do: >=20 > a.example CNAME b.example > b.example AAAA 2001:db8::1 > _443._tcp.b.example TLSA bstuff >=20 > and not realize that a query for TLSA at _443._tcp.a.example will = return > NXDOMAIN instead of "bstuff". >=20 > The issue is that: > 1) the user & developer don't know if the above should result in = "DANE's > not in use, fall back to normal processing" or if the CNAME should be > followed and the prefix checked there user & developer should issue a standard DNS query for = _443._tcp.example.com and use whatever record the DNS resolver returns. CNAME is an internal > 2) the user & developer don't know what will happen in this case: >=20 > a.example CNAME b.example > _443._tcp.a.example TLSA astuff > b.example AAAA 2001:db8::1 > _443._tcp.b.example TLSA bstuff >=20 > 2a) Failure (because the records contradict)? > 2b) Fallback (because the records contradict)? > 2c) A wins? ("Because it owns the CNAME") > 2d) B wins? ("Because that's where the server is & is more likely to = be > right") 2c) is right, because that's how the DNS works right now. > 3) if there's a chain of CNAMEs, what then? First hit? Last hit? All > must match? All must match & be present? Pick one at random? Same algorithm. Issue a standard DNS query for TLSA and use whatever the resolver will return to you. CNAME will be processed by your = resolver (or resolver library). > In other words, nobody is asking about wildcarding or aliasing the = TLSA > record itself (the focus of Appendix A). We're wondering what happens = if > you wildcard or alias the name the TLSA record is for (the subject). > This is what the wildcard and redirection requirements in the use case > document should be about, though the wording fails to make that clear. >=20 > This is a protocol question, not an element of deployment advice. = Well, > it can be both, but it has to be clear in the protocol first. My opinion might be obscured by my DNS-centric view, but I still fail to see what needs to be clarified in the protocol. Application requesting the TLSA will issue _port._proto.example.com for 'example.com'. It's exactly the same way how you request an IP address. You issue a query for IN AAAA / IN A to your resolver library and don't care if there is a CNAME, DNAME or chains of CNAME/DNAMEs. This simplest solution (e.g. don't do any extra processing) also has enough flexibility to keep control over the record for yourself (add TLSA) or to delegate it to your hosting provider (add CNAME). For more examples see one of my previous emails where I list all possible combinations. If it still feels insufficient then maybe a suggested text would help? > Like I've said before, the best option seems to be "follow the CNAME > chain of the subject to an address record, check the prefix for each > name, and use the first TLSA record you find." Is there anything so specific in TLSA record that you think it needs to change current DNS algorithms? I fail to see why. To be even more precise - the mail standard developers did the mistake and specified that MTA should process the CNAMEs and now we have = different implementation and each processes the CNAME differently. O. -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From ondrej.sury@nic.cz Tue Aug 2 08:39:54 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8388B21F859E for ; Tue, 2 Aug 2011 08:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVBU-io0-tKQ for ; Tue, 2 Aug 2011 08:39:53 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 342A321F858D for ; Tue, 2 Aug 2011 08:39:53 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:7471:3a24:a5d1:f441] (unknown [IPv6:2001:1488:ac14:1400:7471:3a24:a5d1:f441]) by mail.nic.cz (Postfix) with ESMTPSA id 0827B2A2BF0; Tue, 2 Aug 2011 17:40:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1312299602; bh=O77DdiblLFGkrQdBlHj0RCyULmc7ncS1/9CvN9CXcNg=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=b0M9dqmU5oiS0fZtkHcj2VXvZsEGL870DzW/t7pHkq4JprMrN6reYOOBkSDQOpIy6 Xiu2tjKgbMZHu+/e3kXey41Ti0LBxIT8NVFFZ5ZoDQ0S0Qm7m8l4QebWJjZOQFInsl +/tglJuF9DqEHIjMnpLNkdq4PAqbp4cCX/a1Eoh0= Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <008501cc457c$2be79400$83b6bc00$@nwlink.com> Date: Tue, 2 Aug 2011 17:40:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2BF4AE99-02CB-4751-B676-339046A420AB@nic.cz> References: <008501cc457c$2be79400$83b6bc00$@nwlink.com> To: Jim Schaad X-Mailer: Apple Mail (2.1244.3) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: Paul Hoffman , dane@ietf.org Subject: Re: [dane] Delegated Services Problems X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 15:39:54 -0000 Jim, On 18. 7. 2011, at 20:54, Jim Schaad wrote: > I have been going through the delegated services cases (3.4 in = use-cases) > and I have decided that I don't understand enough to think that they = are > correct. >=20 > 1. Alice maintains DNSSEC control of the tree and delegates a service = to > Oscar. This case is straight forward from Alice's point of view. = Alice > maintains all DNS records and the coordination needed if either the > addresses or the certificate chain changes is well understood. >=20 > 2. Alice delegates a sub-domain to Oscar and Oscar becomes the = DNSSEC > authority for the sub-tree. This case is also straight forward, the = use > case document is missing the fact that if the DNS keys for Oscar = change then > Alice needs to be notified of this.=20 >=20 > 3. Alice just does a CName reference to Oscar for the service and = Oscar is > the full authority. Again this case is straight forward and requires = zero > coordination between Alice and Oscar at all. >=20 > 4. Alice keeps the DNS records but delegates the address records to = Oscar. > With my limited understanding I can think of a couple of ways that = this > could be implemented. >=20 > 4a. Alice delegates www.alice.com to Oscar and Oscar delegates > _443._tcp._www.alice.com back to Alice. In this case things work as > expected, but Alice does not have any insurance that Oscar is doing = the > delegation back except by doing a routine name resolution and seeing = where > things go. Just to be sure. When you say delegates you mean: www.alice.com IN NS ns1.oscar.com www.alice.com IN NS ns2.oscar.com ? > 4b. Alice uses a CName to Oscar and Oscar delegates back to Alice. In = this > case alice.com contains a CName to alice.oscar.com and Oscar delegates > _443._tcp._alice.oscar.com back to Alice. Note that one would not be = able > to CName to Oscar.com as this would mess up both Oscar and anyone else = that > Oscar is giving services to. CNAME applies only to owner, so if Alice uses a CName to Oscar it = applies only to 'alice.com' and hence the Oscar cannot delegate anything back to = Alice. [Ignoring the fact that you normally cannot create CNAMEs at second = level domain.] E.g. it's valid zone to have alice.com IN CNAME alice.oscar.com _443._tcp.alice.com IN TLSA To tell the truth I think that 4b and 4c is same. > 4c. Alice uses a CName to get the A/AAAA record for the service, but = the > TLSA records are kept in Alice's DNS tree. This changes the way that = I have > always thought that the DNS lookups will occur for DANE and thus needs = both > consideration and documentation if it is to be used. NOTE: This is = the > only method that can be used by Alice if she really wants to keep full > control of the certificates/keys and trust anchors used by Oscar. >=20 > Look up for Addresses: > www.alice.com - returns nothing > alice.com - returns CName to Oscar.com > Oscar.com - returns AAAA record for server. >=20 > Look up for TLSA records: > _443._tcp.www.alice.com - returns nothing > _443._tcp.alice.com - if returns TLSA records - then use them > Else > Use the CName record from alice.com > _443._tcp.oscar.com - returns TLSA records. > I am sure that the above sequence of what things to look up is both > incomplete and wrong, but it will give me enough rope to show the = sequence > of events that I want to see happen. The address look ups proceed as > currently defined. However for the TLSA look ups a new sequence of = events > is done. >=20 > 1. Start by using the ORIGINAL address you were looking for and make = the > TLSA modifications for it.=20 > 2. Resolve for a TLSA record - if found then stop I still fail to understand what is wrong with simply doing: If not found then stop? > 3. Resolve for a CName record - if found then change to the search = address > to the TSLA modifications on the new CName record go to step 2 I think that this is just a big security rathole. The whole purpose of = DANE was to keep control close to domain owner and this steps would allow = Oscar to control the Alice TLSA records without her consent. Please let's not = go this way. > 4. Move to parent in tree - if "too high" stop > 5. Go to step 2 I would like to keep these two issues separate (the "CNAME" and "DANE = for whole domain"). The fact that the application doesn't know what is "too high" (and we = see the same problem with cookie domains) and not only it doesn't know, but it also = cannot know even with parsing the whole DNS tree and comparing the domains at = zonecuts. We have this as an open issue #23 = (http://tools.ietf.org/wg/dane/trac/ticket/23) and we will talk about that, but let's not make the CNAME/wildcards more = complicated, please. O. -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From ondrej.sury@nic.cz Tue Aug 2 08:54:22 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2B9E11E8080 for ; Tue, 2 Aug 2011 08:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWgDzBAOcZsX for ; Tue, 2 Aug 2011 08:54:21 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 879DB11E8083 for ; Tue, 2 Aug 2011 08:54:20 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:7471:3a24:a5d1:f441] (unknown [IPv6:2001:1488:ac14:1400:7471:3a24:a5d1:f441]) by mail.nic.cz (Postfix) with ESMTPSA id D5B1D2A2A58; Tue, 2 Aug 2011 17:54:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1312300468; bh=3KROk9DZXs7Wic1iROtbiXu75bIsADGL71Qc56i0yJk=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=BonL5EUB/4tX1L9WM231b5aILrrd4iUItR9frZXNkzZtIJP182oiOMNb9M94EujJY XJivYZBUIVdI+dMF3s88jTDWnqgUoXex4dLEehCY1Owe8/1VBHzJY8vvhGNqYJaILi IjFdW2BjKe9Smn7hnhbPlAHpz1E10kO9Xybv2RII= Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <4E37F5E6.2040708@mnt.se> Date: Tue, 2 Aug 2011 17:54:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B7B160E-B835-44E3-A5A8-8DC50E3498FD@vpnc.org> <20110731161210.GH9434@shinkuro.com> <20110731202601.GJ9434@shinkuro.com> <20110801014459.GD20015@shinkuro.com> <4E366812.5090206@mnt.se> <4E37B5AD.9040307@mnt.se> <4E37F5E6.2040708@mnt.se> To: Leif Johansson X-Mailer: Apple Mail (2.1244.3) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 15:54:23 -0000 On 2. 8. 2011, at 15:04, Leif Johansson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 08/02/2011 02:22 PM, Phillip Hallam-Baker wrote: >> On Tue, Aug 2, 2011 at 4:30 AM, Leif Johansson wrote: >>=20 >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>>=20 >>> On 08/01/2011 09:47 PM, Phillip Hallam-Baker wrote: >>>> On Mon, Aug 1, 2011 at 4:47 AM, Leif Johansson = wrote: >>>>>=20 >>>>>> Explain to me what the problem is, ideally by walking through an >>>>>> example. >>>>>=20 >>>>> +1 I would love to see an example explaining the issue! >>>>=20 >>>>=20 >>>> The issue is that DANE has to use prefixed DNS records and these do = not >>> work >>>> in the way that we would want them to. >>>=20 >>> After having read the threads on this I think I understand that the >>> problem is really that you have requirements on DANE beyond what is >>> provided by DNS currently: support for general CNAME and wildcard- >>> based delegation. >>>=20 >>> While these requirements may be interesting I'm not sure why they >>> are particular to DANE. Many uses of SRV records would seem to have >>> the same "problem" for instance. >>>=20 >>=20 >> 1) SRV is a form of alias so the issue there is not so critical, the >> following records have similar effect: >>=20 >> www.example.com CNAME alias.example.com >> www.example.com SRV 1 1 80 alias.example.com >=20 > But that is not the common use of SRV records - a more representative > example would be one for the XMPP server for a domain: >=20 > _xmpp-server._tcp.example.org IN SRV 5 0 5269 xmpp.example.com >=20 > Evidently users have learned to live with adding not only one but > multiple entries like that to their domain (look at any zone enabled > for google apps for instance). >=20 > Note that in this case there are even comparable security implications > since the XMPP call-back server-2-server authentication relies on > those SRV records. >=20 > I re-iterate: how is the use of SRV records for locating XMPP servers > fundamentally different from TLSA? To turn this around the jabber records. The equivalent in XMPP would = be: Alice has a jabber account alice@jabber.alice.com. jabber.alice.com IN CNAME jabber.oscar.com _jabber._tcp.jabber.alice.com IN SRV 5 0 5269 jabber.bob.com. _xmpp-client._tcp.jabber.alice.com IN SRV 5 0 5222 jabber.bob.com. _xmpp-server._tcp.jabber.alice.com IN SRV 5 0 5269 jabber.bob.com. jabber.oscar.com IN A 1.2.3.4 1.2.3.4 runs only a webserver. What happens today: - The current compliant clients will talk to jabber.bob.com, because = they use IN SRV _xmpp-server._tcp.jabber.alice.com (and other SRVs). What would happen if PHB's proposal was in effect: - The proposal to resolve the CNAME would cause connections to = alice@jabber.alice.com to connect to jabber.oscar.com and fail. So to continue this discussion please answer: 1. Do you think that TLSA needs to be handled differently? 2. Why do you think that TLSA needs special approach? 3. What is the *problem* you are trying to solve? [I honestly don't see the problem which you are addressing with this = solution.] 3a. Are you afraid that people will not be educated enough to create = TLSA at _443._tcp.www.alice.com? They have learnt how to cope with = jabber. 3b. ??? O. -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From paul.hoffman@vpnc.org Tue Aug 2 09:12:31 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAF5E21F86F6 for ; Tue, 2 Aug 2011 09:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.469 X-Spam-Level: X-Spam-Status: No, score=-102.469 tagged_above=-999 required=5 tests=[AWL=-0.170, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CUhnJ5L16fd7 for ; Tue, 2 Aug 2011 09:12:31 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id F37BC21F86EE for ; Tue, 2 Aug 2011 09:12:30 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p72GCJGe016708 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 2 Aug 2011 09:12:20 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=utf-8 From: Paul Hoffman In-Reply-To: Date: Tue, 2 Aug 2011 09:12:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <057C6FBB-4F99-4FDD-9F4C-D7A35B769A33@vpnc.org> References: <4B7B160E-B835-44E3-A5A8-8DC50E3498FD@vpnc.org> <20110731161210.GH9434@shinkuro.com> <20110731202601.GJ9434@shinkuro.com> <20110801014459.GD20015@shinkuro.com> <4E366812.5090206@mnt.se> <4E37B5AD.9040307@mnt.se> <4E37F5E6.2040708@mnt.se> To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= X-Mailer: Apple Mail (2.1244.3) Cc: dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 16:12:32 -0000 On Aug 2, 2011, at 8:54 AM, Ond=C5=99ej Sur=C3=BD wrote: > To turn this around the jabber records. The equivalent in XMPP would = be: >=20 > Alice has a jabber account alice@jabber.alice.com. >=20 > jabber.alice.com IN CNAME jabber.oscar.com >=20 > _jabber._tcp.jabber.alice.com IN SRV 5 0 5269 jabber.bob.com. > _xmpp-client._tcp.jabber.alice.com IN SRV 5 0 5222 jabber.bob.com. > _xmpp-server._tcp.jabber.alice.com IN SRV 5 0 5269 jabber.bob.com. >=20 > jabber.oscar.com IN A 1.2.3.4 >=20 > 1.2.3.4 runs only a webserver. >=20 > What happens today: > - The current compliant clients will talk to jabber.bob.com, because = they use IN SRV _xmpp-server._tcp.jabber.alice.com (and other SRVs). >=20 > What would happen if PHB's proposal was in effect: > - The proposal to resolve the CNAME would cause connections to = alice@jabber.alice.com to connect to jabber.oscar.com and fail. As much as I hate to put words in Phill's mouth, I don't think that is = correct about his proposal. He said that his proposal is = RRtype-specific, and that it was currently only for TLSA records. Thus, = his proposal would not change any of the above. --Paul Hoffman From hallam@gmail.com Tue Aug 2 10:10:20 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82B7321F8726 for ; Tue, 2 Aug 2011 10:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.468 X-Spam-Level: X-Spam-Status: No, score=-3.468 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BiZ3aMvLKU70 for ; Tue, 2 Aug 2011 10:10:19 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8B3C421F86F6 for ; Tue, 2 Aug 2011 10:10:19 -0700 (PDT) Received: by gxk19 with SMTP id 19so4999313gxk.31 for ; Tue, 02 Aug 2011 10:10:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KQElrGnhjSKwIWKIBirO9y6u6hQBDff5HseyK/k75Rc=; b=LXecJHr7VS/AaXGzAJTBn9Ouh7bbdlrTZoD2nxRMoCHqsPRlk9VHMvhZLQ5PvIq6oN ED3DwtGjfJjR2x+r5/vLgX6YHLUdYe8qMa6hNzhfMnaiDzCw2L53YNSUdlfh/L3EhcbS aVJyeV2vt/W0TfjTz2hSP4Nst54CtJQlMP9Gw= MIME-Version: 1.0 Received: by 10.101.205.22 with SMTP id h22mr4153321anq.72.1312305028810; Tue, 02 Aug 2011 10:10:28 -0700 (PDT) Received: by 10.100.34.3 with HTTP; Tue, 2 Aug 2011 10:10:28 -0700 (PDT) In-Reply-To: <057C6FBB-4F99-4FDD-9F4C-D7A35B769A33@vpnc.org> References: <4B7B160E-B835-44E3-A5A8-8DC50E3498FD@vpnc.org> <20110731161210.GH9434@shinkuro.com> <20110731202601.GJ9434@shinkuro.com> <20110801014459.GD20015@shinkuro.com> <4E366812.5090206@mnt.se> <4E37B5AD.9040307@mnt.se> <4E37F5E6.2040708@mnt.se> <057C6FBB-4F99-4FDD-9F4C-D7A35B769A33@vpnc.org> Date: Tue, 2 Aug 2011 13:10:28 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=0016e6d27c741446eb04a988d3e6 Cc: dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 17:10:20 -0000 --0016e6d27c741446eb04a988d3e6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Aug 2, 2011 at 12:12 PM, Paul Hoffman wrote= : > On Aug 2, 2011, at 8:54 AM, Ond=C5=99ej Sur=C3=BD wrote: > > > To turn this around the jabber records. The equivalent in XMPP would b= e: > > > > Alice has a jabber account alice@jabber.alice.com. > > > > jabber.alice.com IN CNAME jabber.oscar.com > > > > _jabber._tcp.jabber.alice.com IN SRV 5 0 5269 jabber.bob.com. > > _xmpp-client._tcp.jabber.alice.com IN SRV 5 0 5222 jabber.bob.com. > > _xmpp-server._tcp.jabber.alice.com IN SRV 5 0 5269 jabber.bob.com. > > > > jabber.oscar.com IN A 1.2.3.4 > > > > 1.2.3.4 runs only a webserver. > > > > What happens today: > > - The current compliant clients will talk to jabber.bob.com, because > they use IN SRV _xmpp-server._tcp.jabber.alice.com (and other SRVs). > > > > What would happen if PHB's proposal was in effect: > > - The proposal to resolve the CNAME would cause connections to > alice@jabber.alice.com to connect to jabber.oscar.com and fail. > > As much as I hate to put words in Phill's mouth, I don't think that is > correct about his proposal. He said that his proposal is RRtype-specific, > and that it was currently only for TLSA records. Thus, his proposal would > not change any of the above. Exactly. I have two separate concerns 1) Do not create a new hole 2) Try to fill in some of the hole that has already been created. Avoiding creating a new problem with DANE is relatively easy. Fixing the existing issues with SRV, URI, NAPTR, DKIM is much more complex and might not have a sufficiently compelling value proposition. --=20 Website: http://hallambaker.com/ --0016e6d27c741446eb04a988d3e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, Aug 2, 2011 at 12:12 PM, Paul Ho= ffman <paul.h= offman@vpnc.org> wrote:
On Aug 2, 2011, at 8:54 AM, Ond=C5=99ej Sur=C3=BD wrote:<= br>
> To turn this around the jabber records. =C2=A0The equivalent in XMPP w= ould be:
>
> Alice has a jabber account a= lice@jabber.alice.com.
>
> jabber.alice.com= IN CNAME jabber.= oscar.com
>
> _jabber._tcp= .jabber.alice.com IN SRV 5 0 5269 jabber.bob.com.
> _xmpp-client._tcp.jabber.alice.com IN SRV 5 0 5222 jabber.bob.com.
> _xmpp-server._tcp.jabber.alice.com IN SRV 5 0 5269 jabber.bob.com.
>
> jabber.oscar.com= IN A 1.2.3.4
>
> 1.2.3.4 runs only a webserver.
>
> What happens today:
> - The current compliant clients will talk to jabber.bob.com, because they use IN SRV _xmp= p-server._tcp.jab= ber.alice.com (and other SRVs).
>
> What would happen if PHB's proposal was in effect:
> - The proposal to resolve the CNAME would cause connections to alice@jabber.alice.com to connect to= jabber.oscar.com= and fail.

As much as I hate to put words in Phill's mouth, I don't thin= k that is correct about his proposal. He said that his proposal is RRtype-s= pecific, and that it was currently only for TLSA records. Thus, his proposa= l would not change any of the above.

Exactly.

I have two separate c= oncerns

1) Do not create a new hole
2) T= ry to fill in some of the hole that has already been created.

Avoiding creating a new problem with DANE is relatively easy= . Fixing the existing issues with SRV, URI, NAPTR, DKIM is much more comple= x and might not have a sufficiently compelling value proposition.


--
Website: http://hallambaker.com/

--0016e6d27c741446eb04a988d3e6-- From ajs@anvilwalrusden.com Tue Aug 2 11:24:36 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31B8611E8098 for ; Tue, 2 Aug 2011 11:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uwZCYCEv0Bc for ; Tue, 2 Aug 2011 11:24:35 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 4975211E8095 for ; Tue, 2 Aug 2011 11:24:35 -0700 (PDT) Received: from shinkuro.com (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id F2BEC1ECB41C for ; Tue, 2 Aug 2011 18:24:44 +0000 (UTC) Date: Tue, 2 Aug 2011 14:24:38 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20110802182438.GY22542@shinkuro.com> References: <20110802001308.26792.qmail@joyce.lan> <4B846C97-EE58-43CC-A324-CD48D69D8D5C@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] The Curse of The Same, was CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 18:24:36 -0000 On Tue, Aug 02, 2011 at 07:40:43AM -0400, Phillip Hallam-Baker wrote: > > > > But this is not same as the name sameness. www.foo.com and www.bar.com > > are different from DANE perspective. > > > So you have made up your mind and we can't change it? The _DNS_ made up the mind in this case. CNAME redirects _that name_ and _nothing else_. It does not redirect names beneath it. And you can't have a CNAME at the apex. The TLSA record is a name beneath the CNAME. If you want to redirect, you need to redirect it, too. Why is that hard? A -- Andrew Sullivan ajs@anvilwalrusden.com From johnl@iecc.com Tue Aug 2 12:27:52 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 761BD1F0C51 for ; Tue, 2 Aug 2011 12:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jMKXWuybS0OJ for ; Tue, 2 Aug 2011 12:27:51 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 1C60C1F0C4B for ; Tue, 2 Aug 2011 12:27:46 -0700 (PDT) Received: (qmail 22355 invoked from network); 2 Aug 2011 19:27:55 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 2 Aug 2011 19:27:55 -0000 Received: (qmail 93533 invoked from network); 2 Aug 2011 19:27:55 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 2 Aug 2011 19:27:55 -0000 Date: 2 Aug 2011 19:27:33 -0000 Message-ID: <20110802192733.19031.qmail@joyce.lan> From: "John Levine" To: dane@ietf.org In-Reply-To: <20110802182438.GY22542@shinkuro.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [dane] The Curse of The Same, was CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 19:27:52 -0000 >The TLSA record is a name beneath the CNAME. If you want to redirect, >you need to redirect it, too. > >Why is that hard? It's the application view vs. the DNS view. >From a DNS view, you're right, you add another CNAME. >From an application view, if you've been using CNAMEs to map one URL to another, it'll mysteriously stop working if the target URL starts using DANE. One response is "tough noogies", but if that's it, we need to at least document it as a security issue. R's, John From mrex@sap.com Tue Aug 2 12:53:29 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C5951F0C47 for ; Tue, 2 Aug 2011 12:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.939 X-Spam-Level: X-Spam-Status: No, score=-9.939 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mRsr-AXICUSd for ; Tue, 2 Aug 2011 12:53:28 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 0EFCC1F0C39 for ; Tue, 2 Aug 2011 12:53:27 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p72JrYKw022368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Aug 2011 21:53:34 +0200 (MEST) From: Martin Rex Message-Id: <201108021953.p72JrX46023647@fs4113.wdf.sap.corp> To: ajs@anvilwalrusden.com (Andrew Sullivan) Date: Tue, 2 Aug 2011 21:53:33 +0200 (MEST) In-Reply-To: <20110802182438.GY22542@shinkuro.com> from "Andrew Sullivan" at Aug 2, 11 02:24:38 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] The Curse of The Same, was CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 19:53:29 -0000 Andrew Sullivan wrote: > > On Tue, Aug 02, 2011 at 07:40:43AM -0400, Phillip Hallam-Baker wrote: > > > > > > But this is not same as the name sameness. www.foo.com and www.bar.com > > > are different from DANE perspective. > > > > So you have made up your mind and we can't change it? > > The _DNS_ made up the mind in this case. CNAME redirects _that name_ > and _nothing else_. It does not redirect names beneath it. And you > can't have a CNAME at the apex. the current browser behaviour (for TLS Server certs from TLS X.509 PKI) given the URL https://web.example.com/some/path would be: - connect()s to web.example.com:443 - send TLS extension SNI with value "web.example.com" - uses reference identifier "web.example.com" - searches for matches for "web.example.com" in DNS-ID and CN-ID and that behaviour is independent of whether DNS contains a) web.example.com A 10.1.1.2 or b) web.example.com CNAME foo.example.org foo.example.org A 10.7.2.3 except that the connect() for (a) is to 10.1.1.2:443 and for (b) is to 10.7.2.3:443 The logical DNS TLSA lookup is for "_443._tcp.web.example.org" > > The TLSA record is a name beneath the CNAME. If you want to redirect, > you need to redirect it, too. The straightforward case would be a) _443._tcp.web.example.com TLSA "web.example.com stuff" but you're saying it could be b) _443._tcp.web.example.com CNAME _443._tcp.foo.example.org _443._tcp.foo.example.org TLSA "foo.example.org stuff" That means that one needs to check the DNSSEC signatures not only on the TLSA record, but also on the CNAME record leading to it. -Martin From leifj@mnt.se Tue Aug 2 13:09:02 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 527DC21F8610 for ; Tue, 2 Aug 2011 13:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYLZQB928sQv for ; Tue, 2 Aug 2011 13:09:01 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 68AC721F85FF for ; Tue, 2 Aug 2011 13:09:00 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p72K94Yt002349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Aug 2011 22:09:08 +0200 (CEST) Message-ID: <4E38595F.2000705@mnt.se> Date: Tue, 02 Aug 2011 22:09:03 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Paul Hoffman References: <4B7B160E-B835-44E3-A5A8-8DC50E3498FD@vpnc.org> <20110731161210.GH9434@shinkuro.com> <20110731202601.GJ9434@shinkuro.com> <20110801014459.GD20015@shinkuro.com> <4E366812.5090206@mnt.se> <4E37B5AD.9040307@mnt.se> <4E37F5E6.2040708@mnt.se> <057C6FBB-4F99-4FDD-9F4C-D7A35B769A33@vpnc.org> In-Reply-To: <057C6FBB-4F99-4FDD-9F4C-D7A35B769A33@vpnc.org> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 20:09:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > As much as I hate to put words in Phill's mouth, I don't think that is correct about his proposal. He said that his proposal is RRtype-specific, and that it was currently only for TLSA records. Thus, his proposal would not change any of the above. > I missed that point. However it makes me no less confused. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk44WV8ACgkQ8Jx8FtbMZnfjbACfRCHjbHo2ulzdd8yyjSMXy/G/ 3oYAnjHPWmsSAkChbceDV1wdGB+94XCm =dnXL -----END PGP SIGNATURE----- From ajs@anvilwalrusden.com Tue Aug 2 13:09:12 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B18821F865E for ; Tue, 2 Aug 2011 13:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUup8C6ZsSpu for ; Tue, 2 Aug 2011 13:09:12 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 03C1121F85FF for ; Tue, 2 Aug 2011 13:09:12 -0700 (PDT) Received: from shinkuro.com (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id EE14B1ECB41C for ; Tue, 2 Aug 2011 20:09:21 +0000 (UTC) Date: Tue, 2 Aug 2011 16:09:15 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20110802200915.GF22542@shinkuro.com> References: <20110802182438.GY22542@shinkuro.com> <20110802192733.19031.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110802192733.19031.qmail@joyce.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] The Curse of The Same, was CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 20:09:12 -0000 On Tue, Aug 02, 2011 at 07:27:33PM -0000, John Levine wrote: > >From an application view, if you've been using CNAMEs to map one URL > to another, it'll mysteriously stop working if the target URL starts > using DANE. One response is "tough noogies", but if that's it, we > need to at least document it as a security issue. Yes, I am perfectly happy to see such a note. In my view, the current draft's text says exactly enough on this subject, but if someone wants it to say more they should propose text. What I have been objecting to in Phill's argument is that he seems to be suggesting there's something special here, and there isn't. CNAMEs, DNAMEs, and wildcards are sharp, pointy objects in the DNS, and just because people use them without thinking all the time doesn't make them any safer. They've always caused people trouble in this way. A -- Andrew Sullivan ajs@anvilwalrusden.com From leifj@mnt.se Tue Aug 2 13:14:49 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5C3621F8678 for ; Tue, 2 Aug 2011 13:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1rUaMq-ckMb for ; Tue, 2 Aug 2011 13:14:49 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id A01EA21F866A for ; Tue, 2 Aug 2011 13:14:48 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p72KEsj1027998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 2 Aug 2011 22:14:57 +0200 (CEST) Message-ID: <4E385ABE.9060402@mnt.se> Date: Tue, 02 Aug 2011 22:14:54 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: dane@ietf.org References: <4B7B160E-B835-44E3-A5A8-8DC50E3498FD@vpnc.org> <20110731161210.GH9434@shinkuro.com> <20110731202601.GJ9434@shinkuro.com> <20110801014459.GD20015@shinkuro.com> <4E366812.5090206@mnt.se> <4E37B5AD.9040307@mnt.se> <4E37F5E6.2040708@mnt.se> <057C6FBB-4F99-4FDD-9F4C-D7A35B769A33@vpnc.org> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 20:14:49 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Exactly. > > I have two separate concerns > > 1) Do not create a new hole > 2) Try to fill in some of the hole that has already been created. > > Avoiding creating a new problem with DANE is relatively easy. Fixing the > existing issues with SRV, URI, NAPTR, DKIM is much more complex and might > not have a sufficiently compelling value proposition. Arguably your proposed fix then introduces an inconsistency in DNS. In my book that makes the cure worse than the ailment. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk44Wr4ACgkQ8Jx8FtbMZneXqACguRG8rOAU+6uNRFRdBXuJdJSi xAQAnjjvN8G5xC+spxjoSY4TwH8Q7hzY =7X5N -----END PGP SIGNATURE----- From ajs@anvilwalrusden.com Tue Aug 2 13:23:54 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 432F721F87C7 for ; Tue, 2 Aug 2011 13:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0ZpcXSAo3qz for ; Tue, 2 Aug 2011 13:23:53 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id BA37221F84F9 for ; Tue, 2 Aug 2011 13:23:53 -0700 (PDT) Received: from shinkuro.com (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id B126E1ECB41C for ; Tue, 2 Aug 2011 20:24:03 +0000 (UTC) Date: Tue, 2 Aug 2011 16:24:01 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20110802202401.GH22542@shinkuro.com> References: <20110731161210.GH9434@shinkuro.com> <20110731202601.GJ9434@shinkuro.com> <20110801014459.GD20015@shinkuro.com> <4E366812.5090206@mnt.se> <4E37B5AD.9040307@mnt.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 20:23:54 -0000 On Tue, Aug 02, 2011 at 08:22:43AM -0400, Phillip Hallam-Baker wrote: > 3) The DNS protocol considers prefixing a name to create a completely > different name. That is certainly not the semantics that use of prefixes is > trying to create. Tough beans. Prefixing a name in the DNS creates a different name. That's part of its definition of "hierarchical name space". Just because a bunch of people think that DNS names have semantics doesn't make it so. You can impute semantics, and the underscore is a useful hint. But it doesn't change the nature of the DNS name space. You want a CNAME at a node? Put one there. It's your zone to manage. Surely the DANE operator's toolkit is going to have some sort of knowledge that, if there's a CNAME at the DANE-enabled zone, you need a CNAME somewhere else too? A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Tue Aug 2 13:38:22 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9546511E8082 for ; Tue, 2 Aug 2011 13:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TwT3eQHWUTCJ for ; Tue, 2 Aug 2011 13:38:21 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id B1C1311E807F for ; Tue, 2 Aug 2011 13:38:21 -0700 (PDT) Received: from shinkuro.com (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 82E8E1ECB41C for ; Tue, 2 Aug 2011 20:38:31 +0000 (UTC) Date: Tue, 2 Aug 2011 16:38:25 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20110802203823.GJ22542@shinkuro.com> References: <4B7B160E-B835-44E3-A5A8-8DC50E3498FD@vpnc.org> <20110731161210.GH9434@shinkuro.com> <20110731202601.GJ9434@shinkuro.com> <20110801014459.GD20015@shinkuro.com> <4E366812.5090206@mnt.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 20:38:22 -0000 On Mon, Aug 01, 2011 at 03:47:25PM -0400, Phillip Hallam-Baker wrote: > A relying party resolves the TLSA records for the Internet service at port X > of domain D as follows: > > 1) A prefix label P is formed by appending the underscore '_' character > (ASCII ...) to the decimal value of the port number. > > 2) The RP issues a query for the TLSA Qtype at P.D > > 2a) If the query returns a result, the resolution process is complete and > the result is the records returned. > > 3) The RP issues a query to determine if D is aliased. To do this the RP MAY > issue a query for any Qtype at D. > > 3a) If the query result does not contain a record indicating an alias > mapping, the resolution process is complete and the result is null. > > 3b) The query result returns an alias mapping D to A. If I'm reading you correctly, your suggestion in a nutshell is that instead of telling D's administrator to put P.D CNAME [some-target-here] in the D zone, you want every application that might ever rely on TLSA to know about "alias mappings" -- even if such aliases are added to the DNS in the future -- and automatically follow them in cases where they are detected? Also, you want every DANE-implementing application that does a DNS lookup and doesn't get a TLSA response to issue an extra query for the superordinate name -- i.e. you want to make sure that everyone who doesn't implement TLSA gets to see a lot of ANY queries to their authority servers. Do I have that right? > The overhead of doing this is irrelevant. I'm not sure the DNS operators of the world would agree with you. A -- Andrew Sullivan ajs@anvilwalrusden.com From ondrej.sury@nic.cz Tue Aug 2 13:51:34 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4364011E80B6 for ; Tue, 2 Aug 2011 13:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.729 X-Spam-Level: X-Spam-Status: No, score=-0.729 tagged_above=-999 required=5 tests=[AWL=0.970, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVQEncCIRtpf for ; Tue, 2 Aug 2011 13:51:32 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 822EC11E808F for ; Tue, 2 Aug 2011 13:51:31 -0700 (PDT) Received: from [10.0.0.12] (247.78.broadband13.iol.cz [90.180.78.247]) by mail.nic.cz (Postfix) with ESMTPSA id 168D72A2B28; Tue, 2 Aug 2011 22:51:40 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1312318300; bh=bmOAoQXkQ3qHTV/yHGl3/lQj5R5UqYIOFA8HNVD15/Q=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=uJir4yjPAQzUVMxhyoVoHnOsJQdsbFs+4vh98G1bepF3Wl9WcgoM630NPaOu6Dt+6 a0EhC4+gzFOGPmKYeJSo1GnZM03FgbuILnpREMHk/gsTB35rd7a3/bYQoy/2beRpcI zsJ7K8VaaaSxaSTSuKwalYponn82NMGCWZb8vT94= Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <20110802192733.19031.qmail@joyce.lan> Date: Tue, 2 Aug 2011 22:51:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9D204ABE-F03C-4C48-8C23-15AA4E8835A4@nic.cz> References: <20110802192733.19031.qmail@joyce.lan> To: John Levine X-Mailer: Apple Mail (2.1244.3) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane@ietf.org Subject: Re: [dane] The Curse of The Same, was CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 20:51:34 -0000 On 2. 8. 2011, at 21:27, John Levine wrote: >> The TLSA record is a name beneath the CNAME. If you want to = redirect, >> you need to redirect it, too. >>=20 >> Why is that hard? >=20 > It's the application view vs. the DNS view. >=20 > =46rom a DNS view, you're right, you add another CNAME. >=20 > =46rom an application view, if you've been using CNAMEs to map one URL > to another, it'll mysteriously stop working if the target URL starts > using DANE. One response is "tough noogies", but if that's it, we > need to at least document it as a security issue. Fine with me. I already said before that we may put all possible cases with verbose examples to DANE operations document (like "if you want = this, you need to do this" and "if you want that, do that"). It is also fine with me to put a section into the security considerations of dane = protocol. Is something like moving this text from appendix A: The TLSA RR is not special in the DNS; it acts exactly like any other RRtype where the queried name has one or more labels prefixed to the base name, such as the SRV RRtype [RFC2782]. This sometimes causes confusion for some developers when using DNS aliasing and wildcards. to security considerations and adding something like this: That also means that if the queried name is a CNAME record the DANE aware application will not automatically use TLSA RR at the canonical name, the target of CNAME, but the zone operator will have to create appropriate resource records for the queried name. That could be TLSA record at prefixed queried name or CNAME for prefixed queried name which leads to a TLSA record. (Somebody please propose better text not in pidgin :). O. -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From paul.hoffman@vpnc.org Tue Aug 2 14:02:47 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB60A21F877F for ; Tue, 2 Aug 2011 14:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.466 X-Spam-Level: X-Spam-Status: No, score=-102.466 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6KrbOQzmW5b for ; Tue, 2 Aug 2011 14:02:47 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 426B221F876F for ; Tue, 2 Aug 2011 14:02:47 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p72L2Zgf028471 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 2 Aug 2011 14:02:36 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=utf-8 From: Paul Hoffman In-Reply-To: <9D204ABE-F03C-4C48-8C23-15AA4E8835A4@nic.cz> Date: Tue, 2 Aug 2011 14:02:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <933BD0EE-56C0-4B34-A397-F9FBD78FD33F@vpnc.org> References: <20110802192733.19031.qmail@joyce.lan> <9D204ABE-F03C-4C48-8C23-15AA4E8835A4@nic.cz> To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= X-Mailer: Apple Mail (2.1244.3) Cc: DANE WG Subject: Re: [dane] The Curse of The Same, was CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 21:02:48 -0000 On Aug 2, 2011, at 1:51 PM, Ond=C5=99ej Sur=C3=BD wrote: > Fine with me. I already said before that we may put all possible = cases > with verbose examples to DANE operations document (like "if you want = this, > you need to do this" and "if you want that, do that"). It is also = fine > with me to put a section into the security considerations of dane = protocol. >=20 > Is something like moving this text from appendix A: >=20 > The TLSA RR is not special in the DNS; it acts exactly like any = other > RRtype where the queried name has one or more labels prefixed to the > base name, such as the SRV RRtype [RFC2782]. This sometimes causes > confusion for some developers when using DNS aliasing and wildcards. >=20 > to security considerations and adding something like this: >=20 > That also means that if the queried name is a CNAME record the DANE > aware application will not automatically use TLSA RR at the = canonical > name, the target of CNAME, but the zone operator will have to create > appropriate resource records for the queried name. That could be > TLSA record at prefixed queried name or CNAME for prefixed queried > name which leads to a TLSA record. >=20 > (Somebody please propose better text not in pidgin :). Why is that a security consideration? --Paul Hoffman From marc.lampo@eurid.eu Tue Aug 2 22:47:07 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF3D611E80B8 for ; Tue, 2 Aug 2011 22:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.895 X-Spam-Level: X-Spam-Status: No, score=-7.895 tagged_above=-999 required=5 tests=[AWL=0.355, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wi-Vo3Y5FvLq for ; Tue, 2 Aug 2011 22:47:07 -0700 (PDT) Received: from barra.eurid.eu (mx.eurid.eu [212.190.206.103]) by ietfa.amsl.com (Postfix) with ESMTP id E9ACE11E8093 for ; Tue, 2 Aug 2011 22:47:06 -0700 (PDT) X-ASG-Debug-ID: 1312350435-0369494a36558b0001-pGO8SV Received: from zimbra.eurid.eu (zcs-master.vt.eurid.eu [10.19.100.121]) by barra.eurid.eu with ESMTP id 030I1LayZSXvmBK7; Wed, 03 Aug 2011 07:47:15 +0200 (CEST) X-Barracuda-Envelope-From: marc.lampo@eurid.eu X-ASG-Whitelist: Client Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.eurid.eu (Postfix) with ESMTP id 97BBCE4056; Wed, 3 Aug 2011 07:47:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at techmail.eurid.eu Received: from zimbra.eurid.eu ([127.0.0.1]) by localhost (zimbra.eurid.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWg-W3OHXmo6; Wed, 3 Aug 2011 07:47:15 +0200 (CEST) Received: from zimbra.eurid.eu (zimbra.eurid.eu [10.19.100.120]) by zimbra.eurid.eu (Postfix) with ESMTP id 7DB45E4053; Wed, 3 Aug 2011 07:47:15 +0200 (CEST) From: "Marc Lampo" To: =?utf-8?Q?'Ond=C5=99ej_Sur=C3=BD'?= , "'Jim Schaad'" References: <008501cc457c$2be79400$83b6bc00$@nwlink.com> <2BF4AE99-02CB-4751-B676-339046A420AB@nic.cz> In-Reply-To: <2BF4AE99-02CB-4751-B676-339046A420AB@nic.cz> Date: Wed, 3 Aug 2011 07:47:15 +0200 (CEST) X-ASG-Orig-Subj: RE: [dane] Delegated Services Problems Message-ID: <005f01cc51a0$cf598730$6e0c9590$@lampo@eurid.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Mailer: Microsoft Office Outlook 12.0 X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraConnectorForOutlook/5.0.3064.18) Thread-Index: AcxRKnDPMJPT2EH6Rv6q8I2sxWHhJAAddtEQ Content-Language: en-za X-Originating-IP: [172.20.1.97] X-Barracuda-Connect: zcs-master.vt.eurid.eu[10.19.100.121] X-Barracuda-Start-Time: 1312350435 X-Barracuda-URL: http://172.20.1.190:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at eurid.eu Cc: 'Paul Hoffman' , dane@ietf.org Subject: Re: [dane] Delegated Services Problems X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 03 Aug 2011 05:47:08 -0000 Sorry for jumping in on the detail, but alice.com. IN CNAME alice.oscar.com. is most likely invalid because of "CNAME and other data" : If alice.com. is a delegated name in com. (NS records exist), then the zone file for alice.com. already holds SOA, NS records and most probably MX-record(s). Their existence forbids the creation of a CNAME at that level ! Kind regards, Marc -----Original Message----- From: Ondřej Surý [mailto:ondrej.sury@nic.cz] Sent: 02 August 2011 05:40 PM To: Jim Schaad Cc: Paul Hoffman; dane@ietf.org Subject: Re: [dane] Delegated Services Problems ... > 4b. Alice uses a CName to Oscar and Oscar delegates back to Alice. In > this > case alice.com contains a CName to alice.oscar.com and Oscar delegates > _443._tcp._alice.oscar.com back to Alice. Note that one would not be able > to CName to Oscar.com as this would mess up both Oscar and anyone else > that > Oscar is giving services to. CNAME applies only to owner, so if Alice uses a CName to Oscar it applies only to 'alice.com' and hence the Oscar cannot delegate anything back to Alice. [Ignoring the fact that you normally cannot create CNAMEs at second level domain.] E.g. it's valid zone to have alice.com IN CNAME alice.oscar.com _443._tcp.alice.com IN TLSA ... O. -- Ondřej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From marc.lampo@eurid.eu Wed Aug 3 00:08:43 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE7321F85A0 for ; Wed, 3 Aug 2011 00:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.984 X-Spam-Level: X-Spam-Status: No, score=-7.984 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hdf6Bycq6uKC for ; Wed, 3 Aug 2011 00:08:42 -0700 (PDT) Received: from barra.eurid.eu (mx.eurid.eu [212.190.206.103]) by ietfa.amsl.com (Postfix) with ESMTP id 3FBA221F856A for ; Wed, 3 Aug 2011 00:08:41 -0700 (PDT) X-ASG-Debug-ID: 1312355331-0369494a3655af0001-pGO8SV Received: from zimbra.eurid.eu (zcs-master.vt.eurid.eu [10.19.100.121]) by barra.eurid.eu with ESMTP id gZOczdRvhsLdADGB; Wed, 03 Aug 2011 09:08:51 +0200 (CEST) X-Barracuda-Envelope-From: marc.lampo@eurid.eu X-ASG-Whitelist: Client Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.eurid.eu (Postfix) with ESMTP id C88F4E408B; Wed, 3 Aug 2011 09:08:50 +0200 (CEST) X-Virus-Scanned: amavisd-new at techmail.eurid.eu Received: from zimbra.eurid.eu ([127.0.0.1]) by localhost (zimbra.eurid.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id do6NA0PVgWti; Wed, 3 Aug 2011 09:08:50 +0200 (CEST) Received: from zimbra.eurid.eu (zimbra.eurid.eu [10.19.100.120]) by zimbra.eurid.eu (Postfix) with ESMTP id 706A2E4050; Wed, 3 Aug 2011 09:08:50 +0200 (CEST) From: "Marc Lampo" To: "'Marc Lampo'" , =?utf-8?Q?'Ond=C5=99ej_Sur=C3=BD'?= , "'Jim Schaad'" References: <008501cc457c$2be79400$83b6bc00$@nwlink.com> <2BF4AE99-02CB-4751-B676-339046A420AB@nic.cz> In-Reply-To: Date: Wed, 3 Aug 2011 09:08:50 +0200 (CEST) X-ASG-Orig-Subj: RE: [dane] Delegated Services Problems Message-ID: <007d01cc51ac$34e920a0$9ebb61e0$@lampo@eurid.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Mailer: Microsoft Office Outlook 12.0 X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraConnectorForOutlook/5.0.3064.18) Thread-Index: AcxRKnDPMJPT2EH6Rv6q8I2sxWHhJAAddtEQAAHXUtA= Content-Language: en-za X-Originating-IP: [172.20.1.97] X-Barracuda-Connect: zcs-master.vt.eurid.eu[10.19.100.121] X-Barracuda-Start-Time: 1312355331 X-Barracuda-URL: http://172.20.1.190:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at eurid.eu Cc: 'Paul Hoffman' , dane@ietf.org Subject: Re: [dane] Delegated Services Problems X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 03 Aug 2011 07:08:43 -0000 For clarity, Ondrej just pointed out he'd also indicated that CNAME is normally not possible, that line had escaped my attention. Marc -----Original Message----- From: Marc Lampo [mailto:marc.lampo@eurid.eu] Sent: 03 August 2011 07:47 AM To: 'Ondřej Surý'; 'Jim Schaad' Cc: 'Paul Hoffman'; 'dane@ietf.org' Subject: RE: [dane] Delegated Services Problems Sorry for jumping in on the detail, but alice.com. IN CNAME alice.oscar.com. is most likely invalid because of "CNAME and other data" : If alice.com. is a delegated name in com. (NS records exist), then the zone file for alice.com. already holds SOA, NS records and most probably MX-record(s). Their existence forbids the creation of a CNAME at that level ! Kind regards, Marc -----Original Message----- From: Ondřej Surý [mailto:ondrej.sury@nic.cz] Sent: 02 August 2011 05:40 PM To: Jim Schaad Cc: Paul Hoffman; dane@ietf.org Subject: Re: [dane] Delegated Services Problems ... > 4b. Alice uses a CName to Oscar and Oscar delegates back to Alice. In > this > case alice.com contains a CName to alice.oscar.com and Oscar delegates > _443._tcp._alice.oscar.com back to Alice. Note that one would not be able > to CName to Oscar.com as this would mess up both Oscar and anyone else > that > Oscar is giving services to. CNAME applies only to owner, so if Alice uses a CName to Oscar it applies only to 'alice.com' and hence the Oscar cannot delegate anything back to Alice. [Ignoring the fact that you normally cannot create CNAMEs at second level domain.] E.g. it's valid zone to have alice.com IN CNAME alice.oscar.com _443._tcp.alice.com IN TLSA ... O. -- Ondřej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From ietf@augustcellars.com Wed Aug 3 17:20:19 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC2C21F881C for ; Wed, 3 Aug 2011 17:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKp-m1AClcc0 for ; Wed, 3 Aug 2011 17:20:18 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC2321F882E for ; Wed, 3 Aug 2011 17:20:18 -0700 (PDT) Received: from TITUS (173-160-230-153-Washington.hfc.comcastbusiness.net [173.160.230.153]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 494E938F0E; Wed, 3 Aug 2011 17:20:31 -0700 (PDT) From: "Jim Schaad" To: "'Jakob Schlyter'" , "'John Levine'" References: <20110802001308.26792.qmail@joyce.lan> In-Reply-To: Date: Wed, 3 Aug 2011 17:54:35 -0700 Message-ID: <005a01cc5241$15549b80$3ffdd280$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJwqQQSmiVFL2JN3GTUTWLNwg69LAJabmEwk7BcW7A= Content-Language: en-us Cc: dane@ietf.org Subject: Re: [dane] The Curse of The Same, was CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 00:20:19 -0000 > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of > Jakob Schlyter > Sent: Monday, August 01, 2011 10:46 PM > To: John Levine > Cc: dane@ietf.org > Subject: Re: [dane] The Curse of The Same, was CNAMES and Wildcards > > On 2 aug 2011, at 02:13, John Levine wrote: > > > This discussion reminds of an equally unsatisfactory one we had a few > > months ago about what it would mean for two TLDs to be The Same. So > > here's some examples: > > > > Example 1: > > > > www.foo.com CNAME www.bar.com > > www.bar.com A 1.2.3.4 > > _443._tcp.www.bar.com TLSA "bar stuff" > > > > Should an application using DANE and looking at www.foo.com find the > > bar stuff? > > An application using DANE would not look up www.foo.com, as this name > does not carry any TLSA records. The application would look up > _443._tcp.www.foo.com, which returns nothing. I thought that at one point the discussion was to allow www.foo.com to carry TLSA records as they would be considered to be common to all services on the system (unless otherwise overridden). Jim > > > Example 2: > > > > www.foo.com CNAME www.bar.com > > www.bar.com A 1.2.3.4 > > _443._tcp.www.foo.com TLSA "foo stuff" > > _443._tcp.www.bar.com TLSA "bar stuff" > > > > Is this valid? If so, should an application using DANE looking at > > www.foo.com find the foo stuff or the bar stuff? > > Yes, this is valid. See my not on SNI in another thread (foo & bar may have > different certs at the same endpoint). > > > Example 3: > > > > www.foo.com CNAME www.bar.com > > www.bar.com A 1.2.3.4 > > _443._tcp.www.foo.com TLSA "foo stuff" > > > > Is this valid? If so, should an application using DANE looking at > > www.foo.com find the foo stuff or nothing? > > > Yes, it will find foo stuff. If you try to look at bar, you will find nothing. > > > jakob > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From ietf@augustcellars.com Wed Aug 3 18:33:00 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E121C11E80C1 for ; Wed, 3 Aug 2011 18:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DjzpqsmN6Sis for ; Wed, 3 Aug 2011 18:33:00 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 1182111E80B0 for ; Wed, 3 Aug 2011 18:32:59 -0700 (PDT) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id A6BD438F0A; Wed, 3 Aug 2011 18:33:12 -0700 (PDT) From: "Jim Schaad" To: =?utf-8?Q?'Ondrej_Sur=C3=BD'?= , "'Leif Johansson'" References: <4B7B160E-B835-44E3-A5A8-8DC50E3498FD@vpnc.org> <20110731161210.GH9434@shinkuro.com> <20110731202601.GJ9434@shinkuro.com> <20110801014459.GD20015@shinkuro.com> <4E366812.5090206@mnt.se> <4E37B5AD.9040307@mnt.se> <4E37F5E6.2040708@mnt.se> In-Reply-To: Date: Wed, 3 Aug 2011 19:07:18 -0700 Message-ID: <005c01cc524b$3db41a60$b91c4f20$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFXOFpKS8t7Wn1vtSazxIQfzpzBNgGXjSmdAjn1Pf4CxYd7igN5GeYOAOI6ZZcCR8EqeAKB1zd5Ab4FnBACH/P2mwHTbaaMASu091oBx93zTQLCC2YhlR0NQ2A= Content-Language: en-us Cc: dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 01:33:01 -0000 > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf = Of > Ondrej Sur=C3=BD > Sent: Tuesday, August 02, 2011 8:54 AM > To: Leif Johansson > Cc: dane@ietf.org > Subject: Re: [dane] CNAMES and Wildcards >=20 >=20 > On 2. 8. 2011, at 15:04, Leif Johansson wrote: >=20 > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On 08/02/2011 02:22 PM, Phillip Hallam-Baker wrote: > >> On Tue, Aug 2, 2011 at 4:30 AM, Leif Johansson = wrote: > >> > >>> -----BEGIN PGP SIGNED MESSAGE----- > >>> Hash: SHA1 > >>> > >>> On 08/01/2011 09:47 PM, Phillip Hallam-Baker wrote: > >>>> On Mon, Aug 1, 2011 at 4:47 AM, Leif Johansson = wrote: > >>>>> > >>>>>> Explain to me what the problem is, ideally by walking through = an > >>>>>> example. > >>>>> > >>>>> +1 I would love to see an example explaining the issue! > >>>> > >>>> > >>>> The issue is that DANE has to use prefixed DNS records and these = do > >>>> not > >>> work > >>>> in the way that we would want them to. > >>> > >>> After having read the threads on this I think I understand that = the > >>> problem is really that you have requirements on DANE beyond what = is > >>> provided by DNS currently: support for general CNAME and wildcard- > >>> based delegation. > >>> > >>> While these requirements may be interesting I'm not sure why they > >>> are particular to DANE. Many uses of SRV records would seem to = have > >>> the same "problem" for instance. > >>> > >> > >> 1) SRV is a form of alias so the issue there is not so critical, = the > >> following records have similar effect: > >> > >> www.example.com CNAME alias.example.com www.example.com SRV > 1 1 80 > >> alias.example.com > > > > But that is not the common use of SRV records - a more = representative > > example would be one for the XMPP server for a domain: > > > > _xmpp-server._tcp.example.org IN SRV 5 0 5269 xmpp.example.com > > > > Evidently users have learned to live with adding not only one but > > multiple entries like that to their domain (look at any zone enabled > > for google apps for instance). > > > > Note that in this case there are even comparable security = implications > > since the XMPP call-back server-2-server authentication relies on > > those SRV records. > > > > I re-iterate: how is the use of SRV records for locating XMPP = servers > > fundamentally different from TLSA? >=20 > To turn this around the jabber records. The equivalent in XMPP would = be: >=20 > Alice has a jabber account alice@jabber.alice.com. >=20 > jabber.alice.com IN CNAME jabber.oscar.com >=20 > _jabber._tcp.jabber.alice.com IN SRV 5 0 5269 jabber.bob.com. > _xmpp-client._tcp.jabber.alice.com IN SRV 5 0 5222 jabber.bob.com. > _xmpp-server._tcp.jabber.alice.com IN SRV 5 0 5269 jabber.bob.com. For my edification - I would see as the TLSA record as _port._tcp._jabber._tcp.jabber.alice.com IN TLSA For the first one - and so forth. I .e. I would not lookup the records = as _5269._tcp.jabber.bob.com I believe we from what I have read that the client should only try the = first one. Jim >=20 > jabber.oscar.com IN A 1.2.3.4 >=20 > 1.2.3.4 runs only a webserver. >=20 > What happens today: > - The current compliant clients will talk to jabber.bob.com, because = they use > IN SRV _xmpp-server._tcp.jabber.alice.com (and other SRVs). >=20 > What would happen if PHB's proposal was in effect: > - The proposal to resolve the CNAME would cause connections to > alice@jabber.alice.com to connect to jabber.oscar.com and fail. >=20 > So to continue this discussion please answer: >=20 > 1. Do you think that TLSA needs to be handled differently? >=20 > 2. Why do you think that TLSA needs special approach? >=20 > 3. What is the *problem* you are trying to solve? > [I honestly don't see the problem which you are addressing with = this > solution.] >=20 > 3a. Are you afraid that people will not be educated enough to create = TLSA at > _443._tcp.www.alice.com? They have learnt how to cope with jabber. >=20 > 3b. ??? >=20 > O. > -- > Ondrej Sur > vedouc v zkumu/Head of R&D department > ------------------------------------------- > CZ.NIC, z.s.p.o. -- Laboratore CZ.NIC > Americka 23, 120 00 Praha 2, Czech Republic > mailto:ondrej.sury@nic.cz http://nic.cz/ > tel:+420.222745110 fax:+420.222745112 > ------------------------------------------- >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From jimsch@nwlink.com Wed Aug 3 18:29:16 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29C7F21F8ADE for ; Wed, 3 Aug 2011 18:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YA+W+0232zYp for ; Wed, 3 Aug 2011 18:29:15 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id E9FD021F8ADC for ; Wed, 3 Aug 2011 18:29:14 -0700 (PDT) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp3.pacifier.net (Postfix) with ESMTPS id 3704D38F30; Wed, 3 Aug 2011 18:29:27 -0700 (PDT) From: "Jim Schaad" To: =?utf-8?Q?'Ondrej_Sur=C3=BD'?= References: <008501cc457c$2be79400$83b6bc00$@nwlink.com> <2BF4AE99-02CB-4751-B676-339046A420AB@nic.cz> In-Reply-To: <2BF4AE99-02CB-4751-B676-339046A420AB@nic.cz> Date: Wed, 3 Aug 2011 19:03:33 -0700 Message-ID: <005b01cc524a$b76419b0$262c4d10$@nwlink.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHxZ4R2U2M+QIdooZqW73EOOM/37QHv8HiUlLJEGOA= Content-Language: en-us X-Mailman-Approved-At: Wed, 03 Aug 2011 18:42:36 -0700 Cc: 'Paul Hoffman' , dane@ietf.org Subject: Re: [dane] Delegated Services Problems X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 01:29:16 -0000 > -----Original Message----- > From: Ondrej Sur=C3=BD [mailto:ondrej.sury@nic.cz] > Sent: Tuesday, August 02, 2011 8:40 AM > To: Jim Schaad > Cc: Paul Hoffman; jakob@kirei.se; dane@ietf.org > Subject: Re: [dane] Delegated Services Problems >=20 > Jim, >=20 > On 18. 7. 2011, at 20:54, Jim Schaad wrote: >=20 > > I have been going through the delegated services cases (3.4 in > > use-cases) and I have decided that I don't understand enough to = think > > that they are correct. > > > > 1. Alice maintains DNSSEC control of the tree and delegates a = service > > to Oscar. This case is straight forward from Alice's point of view. > > Alice maintains all DNS records and the coordination needed if = either > > the addresses or the certificate chain changes is well understood. > > > > 2. Alice delegates a sub-domain to Oscar and Oscar becomes the > > DNSSEC authority for the sub-tree. This case is also straight > > forward, the use case document is missing the fact that if the DNS > > keys for Oscar change then Alice needs to be notified of this. > > > > 3. Alice just does a CName reference to Oscar for the service and > > Oscar is the full authority. Again this case is straight forward = and > > requires zero coordination between Alice and Oscar at all. > > > > 4. Alice keeps the DNS records but delegates the address records to = Oscar. > > With my limited understanding I can think of a couple of ways that > > this could be implemented. > > > > 4a. Alice delegates www.alice.com to Oscar and Oscar delegates > > _443._tcp._www.alice.com back to Alice. In this case things work = as > > expected, but Alice does not have any insurance that Oscar is doing > > the delegation back except by doing a routine name resolution and > > seeing where things go. >=20 > Just to be sure. When you say delegates you mean: >=20 > www.alice.com IN NS ns1.oscar.com > www.alice.com IN NS ns2.oscar.com >=20 > ? Yes, I had to look it up since I don't know DNS very well but this is = what I was saying >=20 > > 4b. Alice uses a CName to Oscar and Oscar delegates back to Alice. = In > > this case alice.com contains a CName to alice.oscar.com and Oscar > > delegates _443._tcp._alice.oscar.com back to Alice. Note that one > > would not be able to CName to Oscar.com as this would mess up both > > Oscar and anyone else that Oscar is giving services to. >=20 > CNAME applies only to owner, so if Alice uses a CName to Oscar it = applies > only to 'alice.com' and hence the Oscar cannot delegate anything back = to > Alice. > [Ignoring the fact that you normally cannot create CNAMEs at second = level > domain.] What I was doing here was www.alice.com IN CNAME alice.oscar.com _tcp.alice.oscar.com IN NS ns1.alice.com _443._tcp.alice.oscar.com IN TLSA >=20 > E.g. it's valid zone to have >=20 > alice.com IN CNAME alice.oscar.com > _443._tcp.alice.com IN TLSA >=20 > To tell the truth I think that 4b and 4c is same. >=20 > > 4c. Alice uses a CName to get the A/AAAA record for the service, = but > > the TLSA records are kept in Alice's DNS tree. This changes the way > > that I have always thought that the DNS lookups will occur for DANE > > and thus needs both consideration and documentation if it is to be > > used. NOTE: This is the only method that can be used by Alice if = she > > really wants to keep full control of the certificates/keys and trust = anchors > used by Oscar. > > > > Look up for Addresses: > > www.alice.com - returns nothing > > alice.com - returns CName to Oscar.com > > Oscar.com - returns AAAA record for server. > > > > Look up for TLSA records: > > _443._tcp.www.alice.com - returns nothing > > _443._tcp.alice.com - if returns TLSA records - then use them > > Else > > Use the CName record from alice.com > > _443._tcp.oscar.com - returns TLSA records. >=20 > > I am sure that the above sequence of what things to look up is both > > incomplete and wrong, but it will give me enough rope to show the > sequence > > of events that I want to see happen. The address look ups proceed = as > > currently defined. However for the TLSA look ups a new sequence of > > events is done. > > > > 1. Start by using the ORIGINAL address you were looking for and = make > > the TLSA modifications for it. > > 2. Resolve for a TLSA record - if found then stop >=20 > I still fail to understand what is wrong with simply doing: >=20 > If not found then stop? Nothing is wrong with that, it was just that my understanding may be = flawed. I thought that the point might be to find something in a more = general way. This could be completely mistaken. I was also under the = impression that one did not need to prefix the TLSA records and the = system could find them. Thus one could have the records at _443._tcp.alice.com alice.com and if the first did not exist then looking them up at the second = location might find useful ones. This would allow for a single set of = records to be published for all services and then override as necessary = (i.e. you would not need to do *.alice.com and publish there). >=20 > > 3. Resolve for a CName record - if found then change to the search > > address to the TSLA modifications on the new CName record go to step = 2 >=20 > I think that this is just a big security rathole. The whole purpose = of DANE was > to keep control close to domain owner and this steps would allow Oscar = to > control the Alice TLSA records without her consent. Please let's not = go this > way. >=20 An acceptable answer - which means a higher degree of cooperation = between Oscar and Alice than might currently be the case. > > 4. Move to parent in tree - if "too high" stop 5. Go to step 2 >=20 > I would like to keep these two issues separate (the "CNAME" and "DANE = for > whole domain"). >=20 > The fact that the application doesn't know what is "too high" (and we = see the > same problem with cookie domains) and not only it doesn't know, but it = also > cannot know even with parsing the whole DNS tree and comparing the > domains at zonecuts. >=20 > We have this as an open issue #23 > (http://tools.ietf.org/wg/dane/trac/ticket/23) > and we will talk about that, but let's not make the CNAME/wildcards = more > complicated, please. I was just trying to be complete and make sure that all of the cases = were covered. Jim >=20 > O. > -- > Ondrej Sur > vedouc v zkumu/Head of R&D department > ------------------------------------------- > CZ.NIC, z.s.p.o. -- Laboratore CZ.NIC > Americka 23, 120 00 Praha 2, Czech Republic > mailto:ondrej.sury@nic.cz http://nic.cz/ > tel:+420.222745110 fax:+420.222745112 > ------------------------------------------- From jimsch@nwlink.com Wed Aug 3 18:35:54 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4ABF11E80C4 for ; Wed, 3 Aug 2011 18:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6iI9Jn+VlWO for ; Wed, 3 Aug 2011 18:35:54 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 1197011E80CA for ; Wed, 3 Aug 2011 18:35:54 -0700 (PDT) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp3.pacifier.net (Postfix) with ESMTPS id CF0CB38F30; Wed, 3 Aug 2011 18:36:06 -0700 (PDT) From: "Jim Schaad" To: "'Marc Lampo'" , =?utf-8?Q?'Ondrej_Sur=C3=BD'?= References: <008501cc457c$2be79400$83b6bc00$@nwlink.com> <2BF4AE99-02CB-4751-B676-339046A420AB@nic.cz> <005f01cc51a0$cf598730$6e0c9590$@lampo@eurid.eu> In-Reply-To: <005f01cc51a0$cf598730$6e0c9590$@lampo@eurid.eu> Date: Wed, 3 Aug 2011 19:10:12 -0700 Message-ID: <005d01cc524b$a5a4fd60$f0eef820$@nwlink.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHxZ4R2U2M+QIdooZqW73EOOM/37QHv8HiUAjF6T4aUoLzZ4A== Content-Language: en-us X-Mailman-Approved-At: Wed, 03 Aug 2011 18:42:36 -0700 Cc: 'Paul Hoffman' , dane@ietf.org Subject: Re: [dane] Delegated Services Problems X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 01:35:54 -0000 Fine - make it=20 www.alice.com IN CNAME alice.oscar.com > -----Original Message----- > From: Marc Lampo [mailto:marc.lampo@eurid.eu] > Sent: Tuesday, August 02, 2011 10:47 PM > To: 'Ondrej Sur=C3=BD'; 'Jim Schaad' > Cc: 'Paul Hoffman'; dane@ietf.org > Subject: RE: [dane] Delegated Services Problems >=20 > Sorry for jumping in on the detail, but >=20 > alice.com. IN CNAME alice.oscar.com. >=20 > is most likely invalid because of "CNAME and other data" : > If alice.com. is a delegated name in com. (NS records exist), then the = zone > file for alice.com. already holds SOA, NS records and most probably = MX- > record(s). > Their existence forbids the creation of a CNAME at that level ! >=20 > Kind regards, >=20 > Marc >=20 >=20 > -----Original Message----- > From: Ondrej Sur [mailto:ondrej.sury@nic.cz] > Sent: 02 August 2011 05:40 PM > To: Jim Schaad > Cc: Paul Hoffman; dane@ietf.org > Subject: Re: [dane] Delegated Services Problems >=20 > .. >=20 > > 4b. Alice uses a CName to Oscar and Oscar delegates back to Alice. = In > > this case alice.com contains a CName to alice.oscar.com and Oscar > > delegates _443._tcp._alice.oscar.com back to Alice. Note that one > > would not be able to CName to Oscar.com as this would mess up both > > Oscar and anyone else that Oscar is giving services to. >=20 > CNAME applies only to owner, so if Alice uses a CName to Oscar it = applies > only to 'alice.com' and hence the Oscar cannot delegate anything back = to > Alice. > [Ignoring the fact that you normally cannot create CNAMEs at second = level > domain.] >=20 > E.g. it's valid zone to have >=20 > alice.com IN CNAME alice.oscar.com > _443._tcp.alice.com IN TLSA >=20 > .. >=20 > O. > -- > Ondrej Sur > vedouc v zkumu/Head of R&D department > ------------------------------------------- > CZ.NIC, z.s.p.o. -- Laboratore CZ.NIC > Americka 23, 120 00 Praha 2, Czech Republic > mailto:ondrej.sury@nic.cz http://nic.cz/ > tel:+420.222745110 fax:+420.222745112 > ------------------------------------------- >=20 From ondrej.sury@nic.cz Wed Aug 3 23:36:32 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FACC11E80FA for ; Wed, 3 Aug 2011 23:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.625 X-Spam-Level: X-Spam-Status: No, score=-1.625 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id noauXB-7-hLE for ; Wed, 3 Aug 2011 23:36:31 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 09B0111E80F9 for ; Wed, 3 Aug 2011 23:36:31 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:8133:6b23:d7fb:85d5] (unknown [IPv6:2001:1488:ac14:1400:8133:6b23:d7fb:85d5]) by mail.nic.cz (Postfix) with ESMTPSA id E46D32A2B67; Thu, 4 Aug 2011 08:36:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1312439803; bh=MYewl4XqxDZFo9iv9aYaiuLH1CZqzrHQljYZ+GlbyXY=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=LtWVJ3AArGxb3WkuJhUl/GTej2vmbbOBKy3SB7rSWP6C/FdfWeRvwnIgWRQDQzH04 X38HNW0on+C5DZCdbm32hs48Fm1GuegWYCjZkGtRlpCcb5qD4UCktD2N6PeDd56csU f376E23J35mOzzGpo5+MCOM5Fxk0LYvE+SGf8T00= Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <005c01cc524b$3db41a60$b91c4f20$@augustcellars.com> Date: Thu, 4 Aug 2011 08:36:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B7B160E-B835-44E3-A5A8-8DC50E3498FD@vpnc.org> <20110731161210.GH9434@shinkuro.com> <20110731202601.GJ9434@shinkuro.com> <20110801014459.GD20015@shinkuro.com> <4E366812.5090206@mnt.se> <4E37B5AD.9040307@mnt.se> <4E37F5E6.2040708@mnt.se> <005c01cc524b$3db41a60$b91c4f20$@augustcellars.com> To: "Jim Schaad" X-Mailer: Apple Mail (2.1244.3) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 06:36:32 -0000 On 4. 8. 2011, at 4:07, Jim Schaad wrote: >> To turn this around the jabber records. The equivalent in XMPP would = be: >>=20 >> Alice has a jabber account alice@jabber.alice.com. >>=20 >> jabber.alice.com IN CNAME jabber.oscar.com >>=20 >> _jabber._tcp.jabber.alice.com IN SRV 5 0 5269 jabber.bob.com. >> _xmpp-client._tcp.jabber.alice.com IN SRV 5 0 5222 jabber.bob.com. >> _xmpp-server._tcp.jabber.alice.com IN SRV 5 0 5269 jabber.bob.com. >=20 > For my edification - I would see as the TLSA record as >=20 > _port._tcp._jabber._tcp.jabber.alice.com IN TLSA >=20 > For the first one - and so forth. I .e. I would not lookup the = records as >=20 > _5269._tcp.jabber.bob.com >=20 > I believe we from what I have read that the client should only try the = first one. That's an interesting topic. We should probably discuss this more. I am going to open an issue in the tracker covering the interaction between SRV and TLSA records. My opinion is that I would lookup: _5269._tcp.jabber.bob.com. IN TLSA My reasoning is that because I the SRV is a client side redirection, and the client knows that he is connecting to the different server. It is the (jabber) client who has to parse and interpret the SRV = record(s). What others in the WG think? O. -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From trac+dane@trac.tools.ietf.org Wed Aug 3 23:42:40 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D58021F8661 for ; Wed, 3 Aug 2011 23:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id efDyp1Z-sFe8 for ; Wed, 3 Aug 2011 23:42:39 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id A8BC321F8610 for ; Wed, 3 Aug 2011 23:42:39 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1Qordn-0001d5-4Q; Wed, 03 Aug 2011 23:42:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: draft-ietf-dane-protocol@tools.ietf.org, ondrej.sury@nic.cz X-Trac-Project: dane Date: Thu, 04 Aug 2011 06:42:47 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dane/trac/ticket/28 Message-ID: <057.eb22cfc8c145014f66d7c72f9cf864f8@trac.tools.ietf.org> X-Trac-Ticket-ID: 28 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dane-protocol@tools.ietf.org, ondrej.sury@nic.cz, dane@ietf.org X-SA-Exim-Mail-From: trac+dane@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20110804064239.A8BC321F8610@ietfa.amsl.com> Resent-Date: Wed, 3 Aug 2011 23:42:39 -0700 (PDT) Resent-From: trac+dane@trac.tools.ietf.org X-Mailman-Approved-At: Wed, 03 Aug 2011 23:46:48 -0700 Cc: dane@ietf.org Subject: [dane] #28: Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 06:42:40 -0000 #28: Interaction of SRV and TLSA records Issue raised by Jim Schaad in: http://www.ietf.org/mail-archive/web/dane/current/msg03044.html And the issue is, if we have: _jabber._tcp.jabber.alice.com IN SRV 5 0 5269 jabber.bob.com. _xmpp-client._tcp.jabber.alice.com IN SRV 5 0 5222 jabber.bob.com. _xmpp-server._tcp.jabber.alice.com IN SRV 5 0 5269 jabber.bob.com. Should the DANE-aware client look-up: a) _port._tcp._jabber._tcp.jabber.alice.com IN TLSA b) _5269._tcp.jabber.bob.com Or even: c) _5269._tcp.jabber.alice.com when interacting with alice@jabber.alice.com? -- --------------------------------+------------------------------------------- Reporter: ondrej.sury@… | Owner: draft-ietf-dane-protocol@… Type: defect | Status: new Priority: major | Milestone: Component: protocol | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: dane From jakob@kirei.se Thu Aug 4 00:32:40 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93C6221F8610 for ; Thu, 4 Aug 2011 00:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.383 X-Spam-Level: X-Spam-Status: No, score=-0.383 tagged_above=-999 required=5 tests=[AWL=0.315, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Je+xHDh-AiZP for ; Thu, 4 Aug 2011 00:32:40 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id 8D57221F85A7 for ; Thu, 4 Aug 2011 00:32:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=KLS2bpOEFVT5JB3DpEOA4PaVNj5sqaoR30UVJqyi1J8=; b=l27V573zaq0fam6EnA5YpAyInCddWaNuMp/ZfEiQhVZlTBn/tDI0FpGVctO0kTs5EC8LDwRhS208E 2kUwuyc7+90EAX3sLvrHqBJXwLxwC1e19/axpYj7cTthFsHBgb04H973HuBi1QydS+vZY2rYTOq81L l6B5Q69jOkgkW5H8= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Thu, 4 Aug 2011 09:32:49 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: <005c01cc524b$3db41a60$b91c4f20$@augustcellars.com> Date: Thu, 4 Aug 2011 09:32:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2B9FB13C-E6F0-4E8E-A7E5-D7CAC0578BBC@kirei.se> References: <4B7B160E-B835-44E3-A5A8-8DC50E3498FD@vpnc.org> <20110731161210.GH9434@shinkuro.com> <20110731202601.GJ9434@shinkuro.com> <20110801014459.GD20015@shinkuro.com> <4E366812.5090206@mnt.se> <4E37B5AD.9040307@mnt.se> <4E37F5E6.2040708@mnt.se> <005c01cc524b$3db41a60$b91c4f20$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1244.3) Cc: dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 07:32:40 -0000 On 4 aug 2011, at 04:07, Jim Schaad wrote: > For my edification - I would see as the TLSA record as >=20 > _port._tcp._jabber._tcp.jabber.alice.com IN TLSA >=20 > For the first one - and so forth. I .e. I would not lookup the = records as >=20 > _5269._tcp.jabber.bob.com >=20 > I believe we from what I have read that the client should only try the = first one. IMHO, the SRV (or MX) record provides mapping from service name to = hostname, whereas TLSA provides an association between hostname and a = (set of) certificate(s). Let me illustrate with three examples for = traditional mail, jabber and web: 1) Mail Primary and secondary mail server provided by the domain itself, and a = tertiary mail server by some mail provider. Service to server mapping is = provided using MX. Each server has its own certificate association. example.com. IN MX 0 mail-one.example.com. IN MX 1 mail-two.example.com. IN MX 5 relay.provider.com. _25._tcp.mail-one.example.com. IN TLSA ... _25._tcp.mail-two.example.com. IN TLSA ... and in the provider's zone: _25._tcp.relay.provider.com. IN TLSA ... 2) Jabber (XMPP) All jabber services provided by the domain itself, service to server = mapping provided using SRV. The jabber server has one certificate = association per port (although this might be the same cert). _jabber._tcp.example.com. IN SRV 0 0 5269 xmpp.example.com. _xmpp-server._tcp.example.com. IN SRV 0 0 5269 xmpp.example.com. _xmpp-client._tcp.example.com. IN SRV 0 0 5222 xmpp.example.com. _5269._tcp.xmpp.example.com. IN TLSA ... _5222._tcp.xmpp.example.com. IN TLSA ... 3) Web For web servers, there exists no (widely deployed) service to server = mapping. CNAMEs are sometimes used (as in the example below), but = transparent ("invisible") for the client application. www.example.com. IN CNAME server1.example.com. server1.example.com. IN A 192.0.2.1 _443._tcp.www.example.com. IN TLSA ... jakob From trac+dane@trac.tools.ietf.org Thu Aug 4 00:47:21 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3085321F8B77 for ; Thu, 4 Aug 2011 00:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wHsYI72Xd2Xq for ; Thu, 4 Aug 2011 00:47:20 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 86AE321F8B74 for ; Thu, 4 Aug 2011 00:47:13 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QoseK-0007gS-Fg; Thu, 04 Aug 2011 00:47:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: draft-ietf-dane-protocol@tools.ietf.org, jakob@kirei.se X-Trac-Project: dane Date: Thu, 04 Aug 2011 07:47:23 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dane/trac/ticket/28#comment:1 Message-ID: <066.29924e88d80ea30bb6fd19ed2b129f3a@trac.tools.ietf.org> References: <057.eb22cfc8c145014f66d7c72f9cf864f8@trac.tools.ietf.org> X-Trac-Ticket-ID: 28 In-Reply-To: <057.eb22cfc8c145014f66d7c72f9cf864f8@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dane-protocol@tools.ietf.org, jakob@kirei.se, dane@ietf.org X-SA-Exim-Mail-From: trac+dane@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20110804074713.86AE321F8B74@ietfa.amsl.com> Resent-Date: Thu, 4 Aug 2011 00:47:13 -0700 (PDT) Resent-From: trac+dane@trac.tools.ietf.org Cc: dane@ietf.org Subject: Re: [dane] #28: Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 07:47:21 -0000 #28: Interaction of SRV and TLSA records Comment(by jakob@…): Given that DANE provides an association between a hostname and a certificate, and jabber.bob.com is the host where the service is provided, I'd go for (b). I also recommend we provide better examples of this in the draft. -- --------------------------------+------------------------------------------- Reporter: ondrej.sury@… | Owner: draft-ietf-dane-protocol@… Type: defect | Status: new Priority: major | Milestone: Component: protocol | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: dane From mlarson@verisign.com Thu Aug 4 05:58:28 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B80B021F8AD8 for ; Thu, 4 Aug 2011 05:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4vi0UpPqcOp6 for ; Thu, 4 Aug 2011 05:58:28 -0700 (PDT) Received: from exprod6og117.obsmtp.com (exprod6og117.obsmtp.com [64.18.1.39]) by ietfa.amsl.com (Postfix) with ESMTP id D5C1521F8B72 for ; Thu, 4 Aug 2011 05:58:27 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob117.postini.com ([64.18.5.12]) with SMTP ID DSNKTjqXgvzNdAuoaYHzOigT3FNQOH4Xz5Tm@postini.com; Thu, 04 Aug 2011 05:58:42 PDT Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id p74Cwf37013249 for ; Thu, 4 Aug 2011 08:58:41 -0400 Received: from DUL1MLARSON-M2 ([10.131.29.4]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 4 Aug 2011 08:58:41 -0400 Date: Thu, 4 Aug 2011 08:58:41 -0400 From: Matt Larson To: dane@ietf.org Message-ID: <20110804125841.GD4206@DUL1MLARSON-M2.vcorp.ad.vrsn.com> References: <20110801014459.GD20015@shinkuro.com> <4E366812.5090206@mnt.se> <4E37B5AD.9040307@mnt.se> <4E37F5E6.2040708@mnt.se> <005c01cc524b$3db41a60$b91c4f20$@augustcellars.com> <2B9FB13C-E6F0-4E8E-A7E5-D7CAC0578BBC@kirei.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2B9FB13C-E6F0-4E8E-A7E5-D7CAC0578BBC@kirei.se> User-Agent: Mutt/1.5.21 (2010-09-15) X-OriginalArrivalTime: 04 Aug 2011 12:58:41.0449 (UTC) FILETIME=[3C2C5990:01CC52A6] Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 12:58:28 -0000 On Thu, 04 Aug 2011, Jakob Schlyter wrote: > 3) Web > > For web servers, there exists no (widely deployed) service to server mapping. CNAMEs are sometimes used (as in the example below), but transparent ("invisible") for the client application. > > www.example.com. IN CNAME server1.example.com. > server1.example.com. IN A 192.0.2.1 > _443._tcp.www.example.com. IN TLSA ... +1000 to this. A TLSA-aware application should be a user of DNS just as any other application, which means it should not be aware of underlying DNS structure (e.g., aliases): that way lies madness, exceptions to existing practice elsewhere, layer violations, application complexity, pain and suffering. Seriously, changing the semantics of DNS aliasing on a per-application basis to route around fundamental DNS behavior because it is inconvenient is the wrong way to go. Matt From mrex@sap.com Thu Aug 4 07:15:32 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3A3921F8B47 for ; Thu, 4 Aug 2011 07:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.973 X-Spam-Level: X-Spam-Status: No, score=-9.973 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oMlKDXf0Coi2 for ; Thu, 4 Aug 2011 07:15:31 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3367121F8B39 for ; Thu, 4 Aug 2011 07:15:30 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p74EFevp002728 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Aug 2011 16:15:40 +0200 (MEST) From: Martin Rex Message-Id: <201108041415.p74EFdNS023238@fs4113.wdf.sap.corp> To: jakob@kirei.se (Jakob Schlyter) Date: Thu, 4 Aug 2011 16:15:39 +0200 (MEST) In-Reply-To: <2B9FB13C-E6F0-4E8E-A7E5-D7CAC0578BBC@kirei.se> from "Jakob Schlyter" at Aug 4, 11 09:32:48 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 14:15:32 -0000 Jakob Schlyter wrote: > > 1) Mail > > Primary and secondary mail server provided by the domain itself, and a tertiary mail server by some mail provider. Service to server mapping is provided using MX. Each server has its own certificate association. > > example.com. IN MX 0 mail-one.example.com. > IN MX 1 mail-two.example.com. > IN MX 5 relay.provider.com. > > _25._tcp.mail-one.example.com. IN TLSA ... > _25._tcp.mail-two.example.com. IN TLSA ... > > and in the provider's zone: > > _25._tcp.relay.provider.com. IN TLSA ... Whoooops! Security-wise, this is nonsensical, because this precludes authentication of the server. Unfortunately, this is exactly how SMTP-AUTH appears to be specified, ... and documented in rfc6125. http://tools.ietf.org/html/rfc6125#appendix-B.4 resulting in a self-contradictory statement: The client MUST use the server hostname it used to open the connection as the value to compare against the server name as expressed in the server certificate. The client MUST NOT use any form of the server hostname derived from an insecure remote source (e.g., insecure DNS lookup). CNAME canonicalization is not done. First, it says that the client MUST use the server hostname that is resulting from the (insecure) MX DNS lookup. Then it goes on to say that the client MUST NOT use a form of the server hostname derived from an insecure remote source such as insecure DNS lookup. > > 2) Jabber (XMPP) > > All jabber services provided by the domain itself, service to server mapping provided using SRV. The jabber server has one certificate association per port (although this might be the same cert). > > _jabber._tcp.example.com. IN SRV 0 0 5269 xmpp.example.com. > _xmpp-server._tcp.example.com. IN SRV 0 0 5269 xmpp.example.com. > _xmpp-client._tcp.example.com. IN SRV 0 0 5222 xmpp.example.com. > > _5269._tcp.xmpp.example.com. IN TLSA ... > _5222._tcp.xmpp.example.com. IN TLSA ... That seems to be similar to the example here: http://tools.ietf.org/html/rfc6120#section-13.7.1.2.2 and means that rfc6125 would match to dnsName "example.com" and therefore I believe DANE should look for _5222._tcp.example.com. IN TLSA for the client _5269._tcp.example.com. IN TLSA for the server -Martin From paul.hoffman@vpnc.org Thu Aug 4 07:28:33 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 588B921F8A57 for ; Thu, 4 Aug 2011 07:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.614 X-Spam-Level: X-Spam-Status: No, score=-102.614 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ruKkxaFfESY3 for ; Thu, 4 Aug 2011 07:28:32 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 865D321F889D for ; Thu, 4 Aug 2011 07:28:32 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p74ESPTt026384 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 4 Aug 2011 07:28:26 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <201108041415.p74EFdNS023238@fs4113.wdf.sap.corp> Date: Thu, 4 Aug 2011 07:28:44 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9FCCFFE3-466A-40C0-A8EE-FEF67B8242ED@vpnc.org> References: <201108041415.p74EFdNS023238@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1244.3) Cc: dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 14:28:33 -0000 On Aug 4, 2011, at 7:15 AM, Martin Rex wrote: > Jakob Schlyter wrote: >>=20 >> 1) Mail >>=20 >> Primary and secondary mail server provided by the domain itself, and = a tertiary mail server by some mail provider. Service to server mapping = is provided using MX. Each server has its own certificate association. >>=20 >> example.com. IN MX 0 mail-one.example.com. >> IN MX 1 mail-two.example.com. >> IN MX 5 relay.provider.com. >>=20 >> _25._tcp.mail-one.example.com. IN TLSA ... >> _25._tcp.mail-two.example.com. IN TLSA ... >>=20 >> and in the provider's zone: >>=20 >> _25._tcp.relay.provider.com. IN TLSA ... >=20 >=20 > Whoooops! Security-wise, this is nonsensical, because this precludes > authentication of the server. I don't believe that it does. The server in this case is = relay.provider.com. The client knows that because the client got the = server name back from the MX lookup. MX gives a new server name, not a = hidden canonicalization like CNAME. >=20 > Unfortunately, this is exactly how SMTP-AUTH appears to be specified, > ... and documented in rfc6125. >=20 > http://tools.ietf.org/html/rfc6125#appendix-B.4 >=20 > resulting in a self-contradictory statement: >=20 > The client MUST use the server hostname it used to open the > connection as the value to compare against the server name as > expressed in the server certificate. The client MUST NOT use any > form of the server hostname derived from an insecure remote = source > (e.g., insecure DNS lookup). CNAME canonicalization is not done. >=20 > First, it says that the client MUST use the server hostname that is > resulting from the (insecure) MX DNS lookup. Then it goes on to say = that > the client MUST NOT use a form of the server hostname derived from an > insecure remote source such as insecure DNS lookup. Why do you assume that the MX lookup is insecure? > 2) Jabber (XMPP) >>=20 >> All jabber services provided by the domain itself, service to server = mapping provided using SRV. The jabber server has one certificate = association per port (although this might be the same cert). >>=20 >> _jabber._tcp.example.com. IN SRV 0 0 5269 xmpp.example.com. >> _xmpp-server._tcp.example.com. IN SRV 0 0 5269 xmpp.example.com. >> _xmpp-client._tcp.example.com. IN SRV 0 0 5222 xmpp.example.com. >>=20 >> _5269._tcp.xmpp.example.com. IN TLSA ... >> _5222._tcp.xmpp.example.com. IN TLSA ... >=20 > That seems to be similar to the example here: >=20 > http://tools.ietf.org/html/rfc6120#section-13.7.1.2.2 >=20 > and means that rfc6125 would match to dnsName "example.com" > and therefore I believe DANE should look for >=20 > _5222._tcp.example.com. IN TLSA for the client > _5269._tcp.example.com. IN TLSA for the server Hrm. You seem to be mixing up DANE semantics and PKIX semantics, but in = a way that is quite reasonable. It feels like the operations = documentation for DANE needs to pick one of the two targets when using = SRV and state which should be looked up. --Paul Hoffman From johnl@iecc.com Thu Aug 4 08:13:44 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBDD121F8B52 for ; Thu, 4 Aug 2011 08:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3L3CyEc5-BL for ; Thu, 4 Aug 2011 08:13:44 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4D621F8B47 for ; Thu, 4 Aug 2011 08:13:44 -0700 (PDT) Received: (qmail 41721 invoked from network); 4 Aug 2011 15:13:58 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 4 Aug 2011 15:13:58 -0000 Received: (qmail 39298 invoked from network); 4 Aug 2011 15:13:58 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 4 Aug 2011 15:13:58 -0000 Date: 4 Aug 2011 15:13:33 -0000 Message-ID: <20110804151333.30009.qmail@joyce.lan> From: "John Levine" To: dane@ietf.org In-Reply-To: <9FCCFFE3-466A-40C0-A8EE-FEF67B8242ED@vpnc.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: paul.hoffman@vpnc.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 15:13:44 -0000 >relay.provider.com. The client knows that because the client got the >server name back from the MX lookup. MX gives a new server name, not a >hidden canonicalization like CNAME. I don't get it. Why is the indirection in MX semantically different from the indirection in CNAME? Assuming both are DNSSEC signed, they both show an identical intention of one domain to delegate its service to another. R's, John From ondrej.sury@nic.cz Thu Aug 4 08:37:02 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F09721F8B00 for ; Thu, 4 Aug 2011 08:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.04 X-Spam-Level: X-Spam-Status: No, score=-1.04 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_62=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NhIlqFeL2l3z for ; Thu, 4 Aug 2011 08:37:00 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 691D521F8AFD for ; Thu, 4 Aug 2011 08:36:51 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:8133:6b23:d7fb:85d5] (unknown [IPv6:2001:1488:ac14:1400:8133:6b23:d7fb:85d5]) by mail.nic.cz (Postfix) with ESMTPSA id A11A22A06FE; Thu, 4 Aug 2011 17:37:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1312472223; bh=+wepda4HqhWm/svZqrh1hJHvaziUvo0T4cLpRJN0Nyk=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=fwGJtPmtqy/3q1H1o4bJxWg3mwjralq4ItPq+JzCJauWdH1R5FIBCVEyx1HH3ZI+9 xfHZO0lHlw/lXAICa9HfLKqCY/mJ374MDY0T8cjBQ8vk49JAB4mI8B7Q5diH03mrJt mYUIGi+TFw1s94HTl/tRg6FoEC3h8CeyiAPSWnxk= Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <20110804151333.30009.qmail@joyce.lan> Date: Thu, 4 Aug 2011 17:37:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110804151333.30009.qmail@joyce.lan> To: "John Levine" X-Mailer: Apple Mail (2.1244.3) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: paul.hoffman@vpnc.org, dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 15:37:02 -0000 On 4. 8. 2011, at 17:13, John Levine wrote: >> relay.provider.com. The client knows that because the client got the >> server name back from the MX lookup. MX gives a new server name, not = a >> hidden canonicalization like CNAME. >=20 > I don't get it. Why is the indirection in MX semantically different > from the indirection in CNAME? Assuming both are DNSSEC signed, they > both show an identical intention of one domain to delegate its service > to another. The difference is that the CNAME (and DNAME) is interpreted by DNS = resolver and MX (and others) is interpreted by the application. The application (MTA) in this case doesn't do DNS query for 'CNAME', but for MX and AAAA/A records and it should not matter if there is a CNAME somewhere in between or not. So if your MTA wants to deliver an email to remote address bob@bob.com it issues following queries to the DNS: bob.com. IN MX and gets bob.com. IN MX 10 mail.bob.com. then it sends another query: mail.bob.com. IN AAAA and gets: mail.bob.com. IN AAAA 2001:DB8::1 But it could also get: [again I ignore the fact that you cannot get CNAME at bob.com] bob.com. IN CNAME alice.com. alice.com. IN MX 10 mail.alice.com. and for IN AAAA mail.alice.com. IN CNAME mail.oscar.com. mail.oscar.com. IN AAAA 2001:DB8::2 But it doesn't do any processing of CNAMEs, it all happens on the DNS = resolver side. The first sentence in a paragraph from section 3.6 of RFC1034 is = important: CNAME RRs cause special action in DNS software. When a name server fails to find a desired RR in the resource set associated with the domain name, it checks to see if the resource set consists of a = CNAME record with a matching class. If so, the name server includes the = CNAME record in the response and restarts the query at the domain name specified in the data field of the CNAME record. The one exception = to this rule is that queries which match the CNAME type are not = restarted. _CNAME RRs cause special action in DNS software_, the MX, PTR, SRV and = others don't - there could be extra records put into additional section, but it doesn't cause the query to be restarted. For references cross check with MX, PTR and/or SRV: RFC 1035 Section 3.3.9.: MX records cause type A additional section processing for the host specified by EXCHANGE. RFC1035 Section 3.3.12.: PTR records cause no additional section processing. These RRs are = used in special domains to point to some other location in the domain = space. These records are simple data, and don't imply any special = processing similar to that performed by CNAME, which identifies aliases. See = the description of the IN-ADDR.ARPA domain for an example. For SRV see RFC 2782 section Usage rules: A SRV-cognizant client SHOULD use this procedure to locate a list of servers and connect to the preferred one: Do a lookup for QNAME=3D_service._protocol.target, QCLASS=3DIN, QTYPE=3DSRV. [=E2=80=A6snip=E2=80=A6] Notes: [=E2=80=A6snip=E2=80=A6] - If the Additional Data section doesn't contain address records for all the SRV RR's and the client may want to connect to the target host(s) involved, the client MUST look up the address record(s). (This happens quite often when the address record has shorter TTL than the SRV or NS RR's.) There is no DNS server side processing in the RFC2782. O. -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From paul.hoffman@vpnc.org Thu Aug 4 08:38:44 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC4521F8B0F for ; Thu, 4 Aug 2011 08:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.614 X-Spam-Level: X-Spam-Status: No, score=-102.614 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-xWWPrRm5UE for ; Thu, 4 Aug 2011 08:38:43 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5097021F8B05 for ; Thu, 4 Aug 2011 08:38:43 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p74FcbTR029635 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 4 Aug 2011 08:38:38 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <20110804151333.30009.qmail@joyce.lan> Date: Thu, 4 Aug 2011 08:38:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110804151333.30009.qmail@joyce.lan> To: John Levine X-Mailer: Apple Mail (2.1244.3) Cc: dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 15:38:44 -0000 On Aug 4, 2011, at 8:13 AM, John Levine wrote: >> relay.provider.com. The client knows that because the client got the >> server name back from the MX lookup. MX gives a new server name, not = a >> hidden canonicalization like CNAME. >=20 > I don't get it. Why is the indirection in MX semantically different > from the indirection in CNAME? Assuming both are DNSSEC signed, they > both show an identical intention of one domain to delegate its service > to another. If the two were specified in 1034 the same way, I would agree with you. = They don't appear to be. 1034 says: CNAME RRs cause special action in DNS software. When a name server fails to find a desired RR in the resource set associated with the domain name, it checks to see if the resource set consists of a CNAME record with a matching class. If so, the name server includes the CNAME record in the response and restarts the query at the domain name specified in the data field of the CNAME record. The one exception to this rule is that queries which match the CNAME type are not restarted. The text for MX sounds nothing like that. All it says is "identifies a = mail exchange for the domain. See [RFC-974 for details." Why did you think that they were semantically the same? --Paul Hoffman From zack.weinberg@gmail.com Thu Aug 4 08:43:01 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 159D821F8779 for ; Thu, 4 Aug 2011 08:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVYw7rToosX3 for ; Thu, 4 Aug 2011 08:43:00 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 79A0E21F8777 for ; Thu, 4 Aug 2011 08:43:00 -0700 (PDT) Received: by yie30 with SMTP id 30so1315307yie.31 for ; Thu, 04 Aug 2011 08:43:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=uB+/8IW3++BRFn+o3PIbxSovXWTz60m+Y9VCEegKFW8=; b=p2KPWAVi1JS6UMAUXxyPaqIp8vNU1+XGzx0oCRfjbxWURFrwpK0MBIvDc+EpytH7xi 3uLqDWR5MppfQWRJcp0jNGXbzXv3qooETedT9bunW7AGbF9+1686p1Mhjo05ABPrzODY 3zhmaO5NoCj9k3SVgwAL4qLvQv0FdMJa5hZMg= MIME-Version: 1.0 Received: by 10.143.20.2 with SMTP id x2mr926434wfi.220.1312472594787; Thu, 04 Aug 2011 08:43:14 -0700 (PDT) Sender: zack.weinberg@gmail.com Received: by 10.68.62.66 with HTTP; Thu, 4 Aug 2011 08:43:14 -0700 (PDT) In-Reply-To: References: <20110804151333.30009.qmail@joyce.lan> Date: Thu, 4 Aug 2011 08:43:14 -0700 X-Google-Sender-Auth: nP49DAf-MpG7Nut6LhLGnIgnFFI Message-ID: From: Zack Weinberg To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 15:43:01 -0000 >From an operational perspective, it seems to me that the right question to ask here is "what names do existing certificates for these services assert?" zw On Thu, Aug 4, 2011 at 8:38 AM, Paul Hoffman wrote: > > On Aug 4, 2011, at 8:13 AM, John Levine wrote: > >>> relay.provider.com. The client knows that because the client got the >>> server name back from the MX lookup. MX gives a new server name, not a >>> hidden canonicalization like CNAME. >> >> I don't get it. =C2=A0Why is the indirection in MX semantically differen= t >> from the indirection in CNAME? =C2=A0Assuming both are DNSSEC signed, th= ey >> both show an identical intention of one domain to delegate its service >> to another. > > > If the two were specified in 1034 the same way, I would agree with you. T= hey don't appear to be. 1034 says: > > CNAME RRs cause special action in DNS software. =C2=A0When a name server > fails to find a desired RR in the resource set associated with the > domain name, it checks to see if the resource set consists of a CNAME > record with a matching class. =C2=A0If so, the name server includes the C= NAME > record in the response and restarts the query at the domain name > specified in the data field of the CNAME record. =C2=A0The one exception = to > this rule is that queries which match the CNAME type are not restarted. > > The text for MX sounds nothing like that. All it says is "identifies a ma= il exchange for the domain. =C2=A0See [RFC-974 for details." > > Why did you think that they were semantically the same? > > --Paul Hoffman > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > From ondrej.sury@nic.cz Thu Aug 4 08:46:58 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC2A321F8B1C for ; Thu, 4 Aug 2011 08:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WnTFVbzCu-lM for ; Thu, 4 Aug 2011 08:46:58 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id DBA8921F8B17 for ; Thu, 4 Aug 2011 08:46:51 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:8133:6b23:d7fb:85d5] (unknown [IPv6:2001:1488:ac14:1400:8133:6b23:d7fb:85d5]) by mail.nic.cz (Postfix) with ESMTPSA id 5A1452A06FE; Thu, 4 Aug 2011 17:47:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1312472826; bh=QXV+tPWBZTUZ9cNi7/aK2pFzWmeJPAnoWuMnP6DcBBY=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=VaB3z+JomoM6rzgP0eIWkJaLgopW0EmQNXM9l6nyK33q19vz1LOr+D0jSd/H8Y21k TBW+Hof+7WxG9BAONOLbTWNdg9jA3OR1MIFwdGjYEzlwyxfTy55YFEsvGUZ/jYyZD4 +lHPRMUFbxw43FCsFkCb7hBqqIABwSf9tR16zq2c= Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <9FCCFFE3-466A-40C0-A8EE-FEF67B8242ED@vpnc.org> Date: Thu, 4 Aug 2011 17:47:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3B52B531-3E0F-4B31-9098-2A939AA73098@nic.cz> References: <201108041415.p74EFdNS023238@fs4113.wdf.sap.corp> <9FCCFFE3-466A-40C0-A8EE-FEF67B8242ED@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1244.3) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane@ietf.org Subject: [dane] SRVs X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 15:46:59 -0000 On 4. 8. 2011, at 16:28, Paul Hoffman wrote: > On Aug 4, 2011, at 7:15 AM, Martin Rex wrote: >>>=20 >>> All jabber services provided by the domain itself, service to server = mapping provided using SRV. The jabber server has one certificate = association per port (although this might be the same cert). >>>=20 >>> _jabber._tcp.example.com. IN SRV 0 0 5269 xmpp.example.com. >>> _xmpp-server._tcp.example.com. IN SRV 0 0 5269 xmpp.example.com. >>> _xmpp-client._tcp.example.com. IN SRV 0 0 5222 xmpp.example.com. >>>=20 >>> _5269._tcp.xmpp.example.com. IN TLSA ... >>> _5222._tcp.xmpp.example.com. IN TLSA ... >>=20 >> That seems to be similar to the example here: >>=20 >> http://tools.ietf.org/html/rfc6120#section-13.7.1.2.2 >>=20 >> and means that rfc6125 would match to dnsName "example.com" >> and therefore I believe DANE should look for >>=20 >> _5222._tcp.example.com. IN TLSA for the client >> _5269._tcp.example.com. IN TLSA for the server >=20 >=20 > Hrm. You seem to be mixing up DANE semantics and PKIX semantics, but = in a way that is quite reasonable. It feels like the operations = documentation for DANE needs to pick one of the two targets when using = SRV and state which should be looked up. Basically it looks like we might end up saying that the interaction of SRV and TLSA will be processed by the rules implied by the particular protocol using SRV records. For jabber it makes sense to use RFC 6120 approach as pointed out by Martin. And it looks like the SIP took same approach: http://tools.ietf.org/html/rfc5922#section-4 As an example, consider a request that is to be routed to the SIP address "sips:alice@example.com". This address requires a secure connection to the SIP domain "example.com" (the 'sips' scheme mandates a secure connection). Through a series of DNS manipulations, the domain name is mapped to a set of host addresses and transports. The entity attempting to create the connection selects an address appropriate for use with TLS from this set. When the connection is established to that server, the server presents a certificate asserting the identity "sip:example.com". Since the domain part of the SIP AUS matches the subject of the certificate, the server is authenticated [=E2=80=A6] O. -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From mrex@sap.com Thu Aug 4 08:58:54 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 430CC21F8B52 for ; Thu, 4 Aug 2011 08:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.976 X-Spam-Level: X-Spam-Status: No, score=-9.976 tagged_above=-999 required=5 tests=[AWL=0.273, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vkFkvvc83X0M for ; Thu, 4 Aug 2011 08:58:53 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 809E121F8B0C for ; Thu, 4 Aug 2011 08:58:53 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p74Fx521017058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Aug 2011 17:59:06 +0200 (MEST) From: Martin Rex Message-Id: <201108041559.p74Fx5iJ029209@fs4113.wdf.sap.corp> To: johnl@taugh.com (John Levine) Date: Thu, 4 Aug 2011 17:59:05 +0200 (MEST) In-Reply-To: <20110804151333.30009.qmail@joyce.lan> from "John Levine" at Aug 4, 11 03:13:33 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: paul.hoffman@vpnc.org, dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 15:58:54 -0000 John Levine wrote: > > > > relay.provider.com. The client knows that because the client got the > > server name back from the MX lookup. MX gives a new server name, not a > > hidden canonicalization like CNAME. > > I don't get it. Why is the indirection in MX semantically different > from the indirection in CNAME? Assuming both are DNSSEC signed, they > both show an identical intention of one domain to delegate its service > to another. I fully agree with John. With respect to the transformation of the reference name that gets compared, the type of the RR is relevant, the semantics of transforming the reference name is exactly the same. In the original use case "HTTP over TLS", there is _no_ depency on DNS being secure in order for the server endpoint identification to not be susceptible to simple DNS spoofing. DNS MX RRs for Email never were a security feature, they are an operational convenience feature. SMTP over TLS, if it matches the hostname resulting from an MX lookup, creates a vital dependency on DNSSEC protecting that MX lookup in order for the server endpoint identification not being susceptible to simple DNS spoofing. -Martin From mrex@sap.com Thu Aug 4 09:00:42 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9386421F8BB5 for ; Thu, 4 Aug 2011 09:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.978 X-Spam-Level: X-Spam-Status: No, score=-9.978 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPy0bYS1loKw for ; Thu, 4 Aug 2011 09:00:42 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id B4BBC21F8B77 for ; Thu, 4 Aug 2011 09:00:41 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p74G0saQ000945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Aug 2011 18:00:54 +0200 (MEST) From: Martin Rex Message-Id: <201108041600.p74G0r5N029268@fs4113.wdf.sap.corp> To: mrex@sap.com Date: Thu, 4 Aug 2011 18:00:53 +0200 (MEST) In-Reply-To: <201108041559.p74Fx5iJ029209@fs4113.wdf.sap.corp> from "Martin Rex" at Aug 4, 11 05:59:05 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: paul.hoffman@vpnc.org, dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 16:00:42 -0000 Sorry for the typo (IRrelevant) Martin Rex wrote: > > John Levine wrote: > > > > > > relay.provider.com. The client knows that because the client got the > > > server name back from the MX lookup. MX gives a new server name, not a > > > hidden canonicalization like CNAME. > > > > I don't get it. Why is the indirection in MX semantically different > > from the indirection in CNAME? Assuming both are DNSSEC signed, they > > both show an identical intention of one domain to delegate its service > > to another. > > I fully agree with John. With respect to the transformation of > the reference name that gets compared, the type of the RR is - relevant, the semantics of transforming the reference name + IRrelevant, the semantics of transforming the reference name > is exactly the same. > > In the original use case "HTTP over TLS", there is _no_ depency on > DNS being secure in order for the server endpoint identification > to not be susceptible to simple DNS spoofing. > > DNS MX RRs for Email never were a security feature, they are an > operational convenience feature. SMTP over TLS, if it matches > the hostname resulting from an MX lookup, creates a vital > dependency on DNSSEC protecting that MX lookup in order for > the server endpoint identification not being susceptible to > simple DNS spoofing. -Martin From ondrej.sury@nic.cz Thu Aug 4 09:05:31 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A54021F8C08 for ; Thu, 4 Aug 2011 09:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.271 X-Spam-Level: X-Spam-Status: No, score=-1.271 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_82=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mpk2b32wMelX for ; Thu, 4 Aug 2011 09:05:30 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id BF53E21F8BEB for ; Thu, 4 Aug 2011 09:05:29 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:8133:6b23:d7fb:85d5] (unknown [IPv6:2001:1488:ac14:1400:8133:6b23:d7fb:85d5]) by mail.nic.cz (Postfix) with ESMTPSA id 45B9E2A26F8; Thu, 4 Aug 2011 18:05:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1312473944; bh=enh9W4DlGPJMYOho0/rW3ft8k3aMH6GtFKhO8rxfC+Y=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=u0qkNG7scAqBLkeLX1X4x0nj5pCPhzUe/GuX6AKW8ZcpJK+b7ALLl7IgA0zsf7TkP naJgv4ZKfrCKdK8lH2ZsZj268TiWrbUT+9ftkNI8z8/kMATgk/dmF13btwktdEHhPC ZlQShnOQ+chE4rm0A0+R0PasQAQE4sgkwDj7i9C8= Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: Date: Thu, 4 Aug 2011 18:05:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <85A5D402-0935-4793-97CD-5DC211B360F8@nic.cz> References: <20110804151333.30009.qmail@joyce.lan> To: Zack Weinberg X-Mailer: Apple Mail (2.1244.3) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: Paul Hoffman , dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 16:05:31 -0000 On 4. 8. 2011, at 17:43, Zack Weinberg wrote: > =46rom an operational perspective, it seems to me that the right > question to ask here is "what names do existing certificates for these > services assert?" For MX see RFC 3207 Section 4.1: [=E2=80=A6] The decision of whether or not to believe the authenticity of the other party in a TLS negotiation is a local matter. However, some general rules for the decisions are: - A SMTP client would probably only want to authenticate an SMTP server whose server certificate has a domain name that is the domain name that the client thought it was connecting to. [=E2=80=A6] It's a bit vague, but I would assume that the SMTP clients connects to the domain name of the SMTP server and not to the domain part of the email address. And operational practice seems to be just weird: gmail.com servers has CN=3Dmx.google.com (and nothing else, or openssl = trying to hide it from me). fastmail.fm servers has CN=3D*.messagingengine.com, which is OK, because = the MXs are: fastmail.fm. 427 IN MX 10 = in1.smtp.messagingengine.com. fastmail.fm. 427 IN MX 20 = in2.smtp.messagingengine.com. I haven't found any other big email provider using STARTTLS. O. > On Thu, Aug 4, 2011 at 8:38 AM, Paul Hoffman = wrote: >>=20 >> On Aug 4, 2011, at 8:13 AM, John Levine wrote: >>=20 >>>> relay.provider.com. The client knows that because the client got = the >>>> server name back from the MX lookup. MX gives a new server name, = not a >>>> hidden canonicalization like CNAME. >>>=20 >>> I don't get it. Why is the indirection in MX semantically different >>> from the indirection in CNAME? Assuming both are DNSSEC signed, = they >>> both show an identical intention of one domain to delegate its = service >>> to another. >>=20 >>=20 >> If the two were specified in 1034 the same way, I would agree with = you. They don't appear to be. 1034 says: >>=20 >> CNAME RRs cause special action in DNS software. When a name server >> fails to find a desired RR in the resource set associated with the >> domain name, it checks to see if the resource set consists of a CNAME >> record with a matching class. If so, the name server includes the = CNAME >> record in the response and restarts the query at the domain name >> specified in the data field of the CNAME record. The one exception = to >> this rule is that queries which match the CNAME type are not = restarted. >>=20 >> The text for MX sounds nothing like that. All it says is "identifies = a mail exchange for the domain. See [RFC-974 for details." >>=20 >> Why did you think that they were semantically the same? -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From mrex@sap.com Thu Aug 4 09:14:27 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC6021F8B6E for ; Thu, 4 Aug 2011 09:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.981 X-Spam-Level: X-Spam-Status: No, score=-9.981 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPe0rpPothco for ; Thu, 4 Aug 2011 09:14:26 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 4804B21F8B67 for ; Thu, 4 Aug 2011 09:14:26 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p74GEePC018735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Aug 2011 18:14:40 +0200 (MEST) From: Martin Rex Message-Id: <201108041614.p74GEdEr000163@fs4113.wdf.sap.corp> To: paul.hoffman@vpnc.org (Paul Hoffman) Date: Thu, 4 Aug 2011 18:14:39 +0200 (MEST) In-Reply-To: <9FCCFFE3-466A-40C0-A8EE-FEF67B8242ED@vpnc.org> from "Paul Hoffman" at Aug 4, 11 07:28:44 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 16:14:27 -0000 Paul Hoffman wrote: > > Martin Rex wrote: > > > 2) Jabber (XMPP) > >> > >> All jabber services provided by the domain itself, service to server > >> mapping provided using SRV. The jabber server has one certificate > >> association per port (although this might be the same cert). > >> > >> _jabber._tcp.example.com. IN SRV 0 0 5269 xmpp.example.com. > >> _xmpp-server._tcp.example.com. IN SRV 0 0 5269 xmpp.example.com. > >> _xmpp-client._tcp.example.com. IN SRV 0 0 5222 xmpp.example.com. > >> > >> _5269._tcp.xmpp.example.com. IN TLSA ... > >> _5222._tcp.xmpp.example.com. IN TLSA ... > > > > That seems to be similar to the example here: > > > > http://tools.ietf.org/html/rfc6120#section-13.7.1.2.2 > > > > and means that rfc6125 would match to dnsName "example.com" > > and therefore I believe DANE should look for > > > > _5222._tcp.example.com. IN TLSA for the client > > _5269._tcp.example.com. IN TLSA for the server > > Hrm. You seem to be mixing up DANE semantics and PKIX semantics, > but in a way that is quite reasonable. It feels like the operations > documentation for DANE needs to pick one of the two targets when > using SRV and state which should be looked up. I'm trying to align them, yes, and on purpose. I was under the impression that among the DANE TLSA desired options was providing an independent confirmation for a server certificate issued by a traditional SSL Server CA from the TLS X.509 PKI. And simultaneously we will often have a heterogenous installed base with DANE-aware and pre-DANE TLS clients. If we want to make it possible to represent an existing claim from a traditional SSL server CA assertion ("this server is authorized to provide a service for hostname X.Y.Z") with one single TLSA record, we will have to slice things in exactly the same fashion. We could do it differently, but that would make things complex, non-intuitive quickly and require multiple TLSA records to confirm a single assertion from traditional SSL server CAs. -Martin From ondrej.sury@nic.cz Thu Aug 4 09:28:00 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0E2F21F888A for ; Thu, 4 Aug 2011 09:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6rCVE-QnofdU for ; Thu, 4 Aug 2011 09:28:00 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 05DC021F884E for ; Thu, 4 Aug 2011 09:28:00 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:8133:6b23:d7fb:85d5] (unknown [IPv6:2001:1488:ac14:1400:8133:6b23:d7fb:85d5]) by mail.nic.cz (Postfix) with ESMTPSA id 8DE7B2A0955; Thu, 4 Aug 2011 18:28:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1312475294; bh=AfVxnxTALDHTz5WpxHzfIkzLQe8AxZTLJcZHJJInh8s=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=oiNYvCKDuef+D0DpAL2q7K1dNq7rMfWogboR1EFUygjKd3CDb9uFmaKzVyB3IkbNM 5b2fUov08KV0v+ist37535toxXHBFvoQIhquTNCtwkx53lQK3N8RRQsrNu3M+UkKWR sLO+tDCU/IoGIz9s1QL8qrm1NfIyWG3o4mCGanE0= Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <201108041559.p74Fx5iJ029209@fs4113.wdf.sap.corp> Date: Thu, 4 Aug 2011 18:28:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <68F9CAF7-0F13-463A-95DE-97EFAB4D6D3B@nic.cz> References: <201108041559.p74Fx5iJ029209@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1244.3) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: paul.hoffman@vpnc.org, dane@ietf.org Subject: [dane] DNS indirection and TLSA (Was: CNAMES and Wildcards) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 16:28:01 -0000 On 4. 8. 2011, at 17:59, Martin Rex wrote: > John Levine wrote: >>>=20 >>> relay.provider.com. The client knows that because the client got the >>> server name back from the MX lookup. MX gives a new server name, not = a >>> hidden canonicalization like CNAME. >>=20 >> I don't get it. Why is the indirection in MX semantically different >> from the indirection in CNAME? Assuming both are DNSSEC signed, they >> both show an identical intention of one domain to delegate its = service >> to another. >=20 > I fully agree with John. With respect to the transformation of > the reference name that gets compared, the type of the RR is > irrelevant, the semantics of transforming the reference name > is exactly the same. I still think that the difference between DNS server-side processing and client-side processing is important. However... > In the original use case "HTTP over TLS", there is _no_ dependency on > DNS being secure in order for the server endpoint identification > to not be susceptible to simple DNS spoofing. >=20 > DNS MX RRs for Email never were a security feature, they are an > operational convenience feature. SMTP over TLS, if it matches > the hostname resulting from an MX lookup, creates a vital > dependency on DNSSEC protecting that MX lookup in order for > the server endpoint identification not being susceptible to > simple DNS spoofing. I think I understand you and you are probably right. But is this insecurity related to TLSA? I think it's the generic vulnerability of SMTP over TLS. See my other mail on MX with references to RFC 3207. O. -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From mrex@sap.com Thu Aug 4 09:32:45 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87FA221F8698 for ; Thu, 4 Aug 2011 09:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.834 X-Spam-Level: X-Spam-Status: No, score=-9.834 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AdOB5ACTxTtB for ; Thu, 4 Aug 2011 09:32:45 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id BD89C21F85DA for ; Thu, 4 Aug 2011 09:32:44 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p74GWw17008460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Aug 2011 18:32:58 +0200 (MEST) From: Martin Rex Message-Id: <201108041632.p74GWvJB001182@fs4113.wdf.sap.corp> To: ondrej.sury@nic.cz (=?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?=) Date: Thu, 4 Aug 2011 18:32:57 +0200 (MEST) In-Reply-To: <85A5D402-0935-4793-97CD-5DC211B360F8@nic.cz> from "=?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?=" at Aug 4, 11 06:05:44 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: paul.hoffman@vpnc.org, dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 16:32:45 -0000 O. wrote: > > Zack Weinberg wrote: > > > > From an operational perspective, it seems to me that the right > > question to ask here is "what names do existing certificates for these > > services assert?" > > For MX see RFC 3207 Section 4.1: > > The decision of whether or not to believe the authenticity of the > other party in a TLS negotiation is a local matter. However, some > general rules for the decisions are: > > - A SMTP client would probably only want to authenticate an SMTP > server whose server certificate has a domain name that is the > domain name that the client thought it was connecting to. > > It's a bit vague, but I would assume that the SMTP clients connects to > the domain name of the SMTP server and not to the domain part of the > email address. Thanks for quoting. I missed this text in rfc6125 Appendix B.4 just before the part I quoted. IMHO this is a very important security consideration, but the way it is worded, appears slightly marginalized. Basically, it suggests to consider every server certificate a wildcard certificate (do a tail match on the domain rather than a hostname match). > > And operational practice seems to be just weird: > > gmail.com servers has CN=mx.google.com (and nothing else, or openssl trying > to hide it from me). Google neither assigned indepent IPv4 addresses nor configured a multi-SubjectAltName Server cert, so it needs the client to use TLS extension SNI in order to present the correct server cert in the TLS handshake. That is an additional command line option to the openssl client. -Martin From ondrej.sury@nic.cz Thu Aug 4 09:52:23 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4571B21F8B91 for ; Thu, 4 Aug 2011 09:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tU2BgpSKz-Ac for ; Thu, 4 Aug 2011 09:52:22 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id C74B621F8B5C for ; Thu, 4 Aug 2011 09:52:21 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:8133:6b23:d7fb:85d5] (unknown [IPv6:2001:1488:ac14:1400:8133:6b23:d7fb:85d5]) by mail.nic.cz (Postfix) with ESMTPSA id 8EEB22A0A13; Thu, 4 Aug 2011 18:52:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1312476754; bh=wnKGoAL6hYCYqhPapfrlAtzjMhD9nU5pOlAiaRkQcoI=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=eDS+cHeTq0CWMJebYl5dDs1u5kxniC/WaYNaZSbjgKgzNaQdqVjNtCQLr6nKQ7WQM h05IdjY3u9yyQ/FzHsgh0SMeCt9W2izP88i2LP5oJRjt8sOK4FYuOdYDB+PpJqymzR vucRe2BPagdBNHEoWv1TodoTm5ysMi4T7uRaylMk= Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <201108041632.p74GWvJB001182@fs4113.wdf.sap.corp> Date: Thu, 4 Aug 2011 18:52:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201108041632.p74GWvJB001182@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1244.3) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: paul.hoffman@vpnc.org, dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 16:52:23 -0000 On 4. 8. 2011, at 18:32, Martin Rex wrote: > Thanks for quoting. I missed this text in rfc6125 Appendix B.4 just > before the part I quoted. IMHO this is a very important security > consideration, but the way it is worded, appears slightly = marginalized. >=20 > Basically, it suggests to consider every server certificate a wildcard > certificate (do a tail match on the domain rather than a hostname = match). Thanks for pointing RFC 6125, I didn't know this document exists. It seems to be a good idea to align with RFC 6125 where applicable and other XXX over TLS documents. F.e the FTP over TLS, where the rules are same as for HTTP over TLS. RFC 6125 also probably answers the question about CNAMES, since there are many places where it says "CNAME canonicalization is not done." or the same is evident from the text. It also seems to be a good idea (if WG will want it) to create similar section in the DANE operational document which will include a list of the protocols in similar fashion and instruction where to put TLSA record. O. -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From paul.hoffman@vpnc.org Thu Aug 4 09:56:23 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8964E21F8BAC for ; Thu, 4 Aug 2011 09:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.605 X-Spam-Level: X-Spam-Status: No, score=-102.605 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOsuviHNxHBl for ; Thu, 4 Aug 2011 09:56:22 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 8249F21F8BAB for ; Thu, 4 Aug 2011 09:56:22 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p74GuGEe033978 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 4 Aug 2011 09:56:17 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Aug 2011 09:56:35 -0700 Message-Id: <145FFB33-0CC1-489C-8EEB-C2F600F59C8F@vpnc.org> To: DANE WG Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) Subject: [dane] Unintended consequences of CNAME chasing for DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 16:56:23 -0000 As I read the recent threads, I see people who are saying, in essence, = "if I do myname.com CNAME myhostername.com, I mean that I want my hosted = to handle all of the associated parts of running my site". That is = probably true, but not supported in the current DNS. The way around this = proposed by Phill is that one chases the CNAME chain if the TLSA record = is not found at the original name. (Matt McCutchen proposed something = similar as well.) Doing so would match the perception that the hoster = gets to provide all the parts needed. However, if you want to control your own security policy, such as being = able to assert that there is no TLSA record, these proposals fail. That = is, your hoster will be able to insert a TLSA record for myname.com = without your consent. That seems like a bad idea. Further, for the HTTP-over-TLS scenario that most people are talking = about, the hoster can publish just one TLSA record that applies to every = one of the domains that point to myhostername.com. If every hosting = customer uses the same CA, that's probably OK; if every hosting customer = is happy having the hoster use the same self-issued certificate for = their site as for every other customer of the hoster whom they don't = know, that's OK too. However, those seem like a stretch. Given this, I believe that the balance of "helping administrators by not = requiring a second CNAME" versus "forcing a second CNAME but giving more = control to the name owner" tips strongly towards the latter. If we were = creating something that completely prevented a hoster from offering = TLSA, I would not feel this way, but the requirement that "if you want = someone else to host TLSA for you, you need to add a second CNAME" is = not too onerous when compared with "we made a protocol that allows = someone to host TLSA for you even if you don't want to use TLSA". --Paul Hoffman From mrex@sap.com Thu Aug 4 10:54:22 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47A405E800D for ; Thu, 4 Aug 2011 10:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.002 X-Spam-Level: X-Spam-Status: No, score=-9.002 tagged_above=-999 required=5 tests=[AWL=-0.719, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, SARE_URI_EQUALS=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwXLfK3ZCCx5 for ; Thu, 4 Aug 2011 10:54:21 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4734A5E8002 for ; Thu, 4 Aug 2011 10:54:21 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p74HsXS3029166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Aug 2011 19:54:34 +0200 (MEST) From: Martin Rex Message-Id: <201108041754.p74HsXFd006308@fs4113.wdf.sap.corp> To: ondrej.sury@nic.cz (=?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?=) Date: Thu, 4 Aug 2011 19:54:33 +0200 (MEST) In-Reply-To: <85A5D402-0935-4793-97CD-5DC211B360F8@nic.cz> from "=?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?=" at Aug 4, 11 06:05:44 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: paul.hoffman@vpnc.org, dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 17:54:22 -0000 O. wrote: > > For MX see RFC 3207 Section 4.1: > > The decision of whether or not to believe the authenticity of the > other party in a TLS negotiation is a local matter. However, some > general rules for the decisions are: > > - A SMTP client would probably only want to authenticate an SMTP > server whose server certificate has a domain name that is the > domain name that the client thought it was connecting to. > > It's a bit vague, but I would assume that the SMTP clients connects to > the domain name of the SMTP server and not to the domain part of the > email address. Looking at the info in DNS for "@gmail.com", it appears that google expects SMTP clients to _not_ perform any kind of matching ... which does not feel right. gmail.com has the following MX records: gmail.com. 3600 IN MX 5 gmail-smtp-in.l.google.com. gmail.com. 3600 IN MX 10 alt1.gmail-smtp-in.l.google.com. gmail.com. 3600 IN MX 20 alt2.gmail-smtp-in.l.google.com. gmail.com. 3600 IN MX 30 alt3.gmail-smtp-in.l.google.com. gmail.com. 3600 IN MX 40 alt4.gmail-smtp-in.l.google.com. Talking SMTP & STARTTLS to alt4.gmail-smtp-in.l.google.com. (with TLS SNI) yields the following TLS Server cert (no subjectAltNames) below: Subject: CN=mx.google.com,O=Google Inc,L=Mountain View,S=California,C=US There would be some security value in tail-matching the target domain "gmail.com" to the Server certificate, but that is a clear mismatch here. Tail-matching an MX result with the server certificate looks bogus to me (without that MX-record being protected by DNSSEC and the result verified by the SMTP client) and is susceptible to simple DNS spoofing of MX records for gmail.com. -----BEGIN CERTIFICATE----- MIIDWjCCAsOgAwIBAgIKaNJJNQADAAAisDANBgkqhkiG9w0BAQUFADBGMQswCQYD VQQGEwJVUzETMBEGA1UEChMKR29vZ2xlIEluYzEiMCAGA1UEAxMZR29vZ2xlIElu dGVybmV0IEF1dGhvcml0eTAeFw0xMTAyMTYwNDQxMTZaFw0xMjAyMTYwNDUxMTZa MGcxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1N b3VudGFpbiBWaWV3MRMwEQYDVQQKEwpHb29nbGUgSW5jMRYwFAYDVQQDEw1teC5n b29nbGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCy6f/dA6rQoTGx TzHGb42KkWsVc1RIrRtp3EchKMf6syEVXXCmDva134GFe1rVGYuNKI/F9Y0kensM vSOoIbZpb2XkHyhVaxI6p6ixbaE2SL5F8M4A6LAFu94oSu4qDyNwf7TaxRy7B1Wi p9hF4e4170oL9xqK+0+aVVKq11uTvQIDAQABo4IBLDCCASgwHQYDVR0OBBYEFIVr EEiaJybkRFsCTtZVNvdxCV6YMB8GA1UdIwQYMBaAFL/AMOv1QxE+Z7qekfv8atrj axIkMFsGA1UdHwRUMFIwUKBOoEyGSmh0dHA6Ly93d3cuZ3N0YXRpYy5jb20vR29v Z2xlSW50ZXJuZXRBdXRob3JpdHkvR29vZ2xlSW50ZXJuZXRBdXRob3JpdHkuY3Js MGYGCCsGAQUFBwEBBFowWDBWBggrBgEFBQcwAoZKaHR0cDovL3d3dy5nc3RhdGlj LmNvbS9Hb29nbGVJbnRlcm5ldEF1dGhvcml0eS9Hb29nbGVJbnRlcm5ldEF1dGhv cml0eS5jcnQwIQYJKwYBBAGCNxQCBBQeEgBXAGUAYgBTAGUAcgB2AGUAcjANBgkq hkiG9w0BAQUFAAOBgQDD59m7yv9fbVBo5+jeSNHnAyPBsj7hZsgznv7FsRZ54Nkz a5Tc3CePDzzNfoq9KyDYaL5NPdJFoxaI7Dfg84mxvvWB7xpAouHUT4tmmabZtLzd DxVwwfIF0mmHoZUKSyT2257DsQFm1JR7M/CJW6K3ov88bsajXuvwEu+mK6nizA== -----END CERTIFICATE----- -Martin From jakob@kirei.se Thu Aug 4 11:53:55 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC3C521F8B5C for ; Thu, 4 Aug 2011 11:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.414 X-Spam-Level: X-Spam-Status: No, score=-0.414 tagged_above=-999 required=5 tests=[AWL=0.284, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hKPM9Lnp-BY for ; Thu, 4 Aug 2011 11:53:54 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id C2FA321F8B5A for ; Thu, 4 Aug 2011 11:53:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=YOo6cHGGjV8NfujJPC5nSbqb1T43vpnr8XniCx2ZVYM=; b=vJRZyqeNErWWRvVXwFjDyKBrGQvyL81TrvB6Ei1sW/Lh+6J2LpYYXph+ZqqQfZDiMSX2WgGvrxxkw PxgekrKKPgR4BufQe/wI708xGbfN0m0QS/f9Yyt9qdgS9QT25WN5VHsjndaB2CKxulKE4afp4ulB44 lApIG8nG522Q1GAY= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Thu, 4 Aug 2011 20:53:57 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Jakob Schlyter In-Reply-To: <201108041415.p74EFdNS023238@fs4113.wdf.sap.corp> Date: Thu, 4 Aug 2011 20:53:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <66AF96F7-D379-4D9A-82A5-A2E4442260AC@kirei.se> References: <201108041415.p74EFdNS023238@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1244.3) Cc: dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 18:53:55 -0000 On 4 aug 2011, at 16:15, Martin Rex wrote: >> _jabber._tcp.example.com. IN SRV 0 0 5269 xmpp.example.com. >> _xmpp-server._tcp.example.com. IN SRV 0 0 5269 xmpp.example.com. >> _xmpp-client._tcp.example.com. IN SRV 0 0 5222 xmpp.example.com. >>=20 >> _5269._tcp.xmpp.example.com. IN TLSA ... >> _5222._tcp.xmpp.example.com. IN TLSA ... >=20 > That seems to be similar to the example here: >=20 > http://tools.ietf.org/html/rfc6120#section-13.7.1.2.2 >=20 > and means that rfc6125 would match to dnsName "example.com" > and therefore I believe DANE should look for >=20 > _5222._tcp.example.com. IN TLSA for the client > _5269._tcp.example.com. IN TLSA for the server Let's assume the Google Apps XMPP servers serves about 10'000 different = XMPP domains (although it is probably more). Given this line of = reasoning, the certificate for those servers would have 10'000 dnsNames = and would have to be reissued every time Google added (or removed) a new = XMPP domain. This does not make sense to me at all as it would result in = operational an nightmare. jakob From mrex@sap.com Thu Aug 4 12:11:09 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69C8821F87FC for ; Thu, 4 Aug 2011 12:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.978 X-Spam-Level: X-Spam-Status: No, score=-9.978 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2OQfxWQ0dsz for ; Thu, 4 Aug 2011 12:11:09 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE7221F87D9 for ; Thu, 4 Aug 2011 12:11:03 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p74JBDr9020033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Aug 2011 21:11:13 +0200 (MEST) From: Martin Rex Message-Id: <201108041911.p74JBCXl011391@fs4113.wdf.sap.corp> To: jakob@kirei.se (Jakob Schlyter) Date: Thu, 4 Aug 2011 21:11:12 +0200 (MEST) In-Reply-To: <66AF96F7-D379-4D9A-82A5-A2E4442260AC@kirei.se> from "Jakob Schlyter" at Aug 4, 11 08:53:55 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 19:11:09 -0000 Jakob Schlyter wrote: > > On 4 aug 2011, at 16:15, Martin Rex wrote: > > >> _jabber._tcp.example.com. IN SRV 0 0 5269 xmpp.example.com. > >> _xmpp-server._tcp.example.com. IN SRV 0 0 5269 xmpp.example.com. > >> _xmpp-client._tcp.example.com. IN SRV 0 0 5222 xmpp.example.com. > >> > >> _5269._tcp.xmpp.example.com. IN TLSA ... > >> _5222._tcp.xmpp.example.com. IN TLSA ... > > > > That seems to be similar to the example here: > > > > http://tools.ietf.org/html/rfc6120#section-13.7.1.2.2 > > > > and means that rfc6125 would match to dnsName "example.com" > > and therefore I believe DANE should look for > > > > _5222._tcp.example.com. IN TLSA for the client > > _5269._tcp.example.com. IN TLSA for the server > > Let's assume the Google Apps XMPP servers serves about 10'000 different > XMPP domains (although it is probably more). Given this line of reasoning, > the certificate for those servers would have 10'000 dnsNames and would > have to be reissued every time Google added (or removed) a new XMPP > domain. This does not make sense to me at all as it would result in > operational an nightmare. I'm sorry, I'm having difficulties following (and admittedly, my experience with XMPP is *tiny*). While the IETF has a number of working groups, a single "jabber.ietf.org" server sees to be sufficient. What is goggle doing, and how many DNS records do they need for doing this *today* (i.e. pre-DANE) and how many server certs do they need today (from TLS X.509 PKI)? Then what it is solution that you would want from DANE? And would that goal be achievable with DANE-only clients using TLSA types unrelated to TLS X.509 PKI being specified to _not_ perform any host name comparisons on the certificate itself (since the host/domain -> certificate matching can be done with TLSA). -Martin From rbarnes@bbn.com Thu Aug 4 12:22:18 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B965D11E8082 for ; Thu, 4 Aug 2011 12:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 765IthoIwZtf for ; Thu, 4 Aug 2011 12:22:18 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 2D55611E807B for ; Thu, 4 Aug 2011 12:22:18 -0700 (PDT) Received: from [192.1.255.224] (port=57620 helo=col-dhcp-192-1-255-224.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Qp3V0-000BYy-N0; Thu, 04 Aug 2011 15:22:31 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <201108041911.p74JBCXl011391@fs4113.wdf.sap.corp> Date: Thu, 4 Aug 2011 15:22:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1A2F9519-4591-46D1-B9A2-351F3CE90BFB@bbn.com> References: <201108041911.p74JBCXl011391@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1082) Cc: dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 19:22:18 -0000 >>>> _jabber._tcp.example.com. IN SRV 0 0 5269 xmpp.example.com. >>>> _xmpp-server._tcp.example.com. IN SRV 0 0 5269 xmpp.example.com. >>>> _xmpp-client._tcp.example.com. IN SRV 0 0 5222 xmpp.example.com. >>>>=20 >>>> _5269._tcp.xmpp.example.com. IN TLSA ... >>>> _5222._tcp.xmpp.example.com. IN TLSA ... >>>=20 >>> That seems to be similar to the example here: >>>=20 >>> http://tools.ietf.org/html/rfc6120#section-13.7.1.2.2 >>>=20 >>> and means that rfc6125 would match to dnsName "example.com" >>> and therefore I believe DANE should look for >>>=20 >>> _5222._tcp.example.com. IN TLSA for the client >>> _5269._tcp.example.com. IN TLSA for the server >>=20 >> Let's assume the Google Apps XMPP servers serves about 10'000 = different >> XMPP domains (although it is probably more). Given this line of = reasoning, >> the certificate for those servers would have 10'000 dnsNames and = would >> have to be reissued every time Google added (or removed) a new XMPP >> domain. This does not make sense to me at all as it would result in >> operational an nightmare. >=20 > I'm sorry, I'm having difficulties following (and admittedly, my > experience with XMPP is *tiny*). I have slightly more experience with this, mainly as a result of = volunteering for draft-ietf-xmpp-dna. > While the IETF has a number of working groups, a single = "jabber.ietf.org" > server sees to be sufficient. What is goggle doing, and how many > DNS records do they need for doing this *today* (i.e. pre-DANE) and > how many server certs do they need today (from TLS X.509 PKI)? The IETF has a single jabber.ietf.org because "ietf.org" is the only = domain they manage. Google and others, through programs like Google = Apps for your Domain, host thousands of domains, and thus have thousands = of SRVs pointing at them. The upshot with regard to certs is that they don't do it, for precisely = the reasong Jakob mentions. See: The XMPP WG is working on patching XMPP to avoid this problem. The = current draft basically uses DNSSEC on the SRV to secure the delegation, = then has the actual server present its own cert (e.g., via DANE). See: > Then what it is solution that you would want from DANE? As I suggested above, DANE is not a solution for secured delegation in = this case. SRV actually does an application-layer redirection (as = opposed to CNAME's DNS-layer redirect). So DNSSEC on the SRV would = secure the delegation, while a DNSSEC-protected DANE record under the = server's name would secure the actual TLS channel. --Richard From ajs@anvilwalrusden.com Thu Aug 4 12:48:37 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 806D321F8A91 for ; Thu, 4 Aug 2011 12:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-KhE+U0omml for ; Thu, 4 Aug 2011 12:48:37 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 1B21221F8A7D for ; Thu, 4 Aug 2011 12:48:37 -0700 (PDT) Received: from shinkuro.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id A9E221ECB41C for ; Thu, 4 Aug 2011 19:48:52 +0000 (UTC) Date: Thu, 4 Aug 2011 15:48:50 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20110804194850.GN38760@shinkuro.com> References: <201108041911.p74JBCXl011391@fs4113.wdf.sap.corp> <1A2F9519-4591-46D1-B9A2-351F3CE90BFB@bbn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1A2F9519-4591-46D1-B9A2-351F3CE90BFB@bbn.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 19:48:37 -0000 On Thu, Aug 04, 2011 at 03:22:27PM -0400, Richard L. Barnes wrote: > in this case. SRV actually does an application-layer redirection > (as opposed to CNAME's DNS-layer redirect). I think this key distinction is getting lost in the analogy between these two cases, and I thank Richard for stating it so clearly. -- Andrew Sullivan ajs@anvilwalrusden.com From trac+dane@trac.tools.ietf.org Thu Aug 4 19:52:06 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B74211E80B0 for ; Thu, 4 Aug 2011 19:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ElvgSydIGf8Z for ; Thu, 4 Aug 2011 19:52:05 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7DF11E809B for ; Thu, 4 Aug 2011 19:52:05 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QpAWH-00025A-TP; Thu, 04 Aug 2011 19:52:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: draft-ietf-dane-protocol@tools.ietf.org, jakob@kirei.se, matt@mattmccutchen.net X-Trac-Project: dane Date: Fri, 05 Aug 2011 02:52:17 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dane/trac/ticket/28#comment:2 Message-ID: <066.aaadec73af2c30671ce4150b9a6d7b51@trac.tools.ietf.org> References: <057.eb22cfc8c145014f66d7c72f9cf864f8@trac.tools.ietf.org> X-Trac-Ticket-ID: 28 In-Reply-To: <057.eb22cfc8c145014f66d7c72f9cf864f8@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dane-protocol@tools.ietf.org, jakob@kirei.se, matt@mattmccutchen.net, dane@ietf.org X-SA-Exim-Mail-From: trac+dane@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20110805025205.9D7DF11E809B@ietfa.amsl.com> Resent-Date: Thu, 4 Aug 2011 19:52:05 -0700 (PDT) Resent-From: trac+dane@trac.tools.ietf.org Cc: dane@ietf.org Subject: Re: [dane] #28: Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 02:52:06 -0000 #28: Interaction of SRV and TLSA records Comment(by matt@…): To amplify [comment:1 comment 1]: DANE applies to a service endpoint identified by (hostname, transport, port), i.e., after any service discovery process that plays a part in determining this tuple. So (b). For a while, Phill wanted to entangle service discovery with DANE; I don't know that he ever accepted my decomposition, but at least he stopped claiming that I had failed to justify it. -- --------------------------------+------------------------------------------- Reporter: ondrej.sury@… | Owner: draft-ietf-dane-protocol@… Type: defect | Status: new Priority: major | Milestone: Component: protocol | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: dane From rbarnes@bbn.com Fri Aug 5 06:59:29 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E385521F8B90 for ; Fri, 5 Aug 2011 06:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.295 X-Spam-Level: X-Spam-Status: No, score=-106.295 tagged_above=-999 required=5 tests=[AWL=-0.296, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMdsivVzPX+G for ; Fri, 5 Aug 2011 06:59:29 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2954921F8B65 for ; Fri, 5 Aug 2011 06:59:29 -0700 (PDT) Received: from [128.89.254.212] (port=61889 helo=[192.168.1.14]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QpKvy-000MJc-1S; Fri, 05 Aug 2011 09:59:30 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=windows-1252 From: "Richard L. Barnes" In-Reply-To: <066.aaadec73af2c30671ce4150b9a6d7b51@trac.tools.ietf.org> Date: Fri, 5 Aug 2011 09:59:25 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7155FD03-FC81-4DFD-B2B0-4C7B416AF3AE@bbn.com> References: <057.eb22cfc8c145014f66d7c72f9cf864f8@trac.tools.ietf.org> <066.aaadec73af2c30671ce4150b9a6d7b51@trac.tools.ietf.org> To: dane issue tracker X-Mailer: Apple Mail (2.1082) Cc: draft-ietf-dane-protocol@tools.ietf.org, dane@ietf.org Subject: Re: [dane] #28: Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 13:59:30 -0000 Why is this an issue? I thought that there was a fair bit of agreement = that SRV resolution was a step before DANE came into play, and thus that = the two processes are not interrelated. After all, the TLS server is = not the name you start the SRV process with, it's the result, and DANE = addresses only the TLS server, not any application-layer identity of the = server. Opening an XMPP connection to example.com with SRV and DANE 1. Look up SRV _xmpp-server._tcp.example.com 2. Get _xmpp-server._tcp.example.com SRV xmpp1.hoster.com 3. Look up TLSA _5222._tcp.xmpp1.hoster.com 4. [[ follow any requisite CNAMEs ]] 5. Get _5222._tcp.xmpp1.hoster.com TLSA ... [[ or CNAME-redirected ]] 6. Proceed with TLS connection --Richard On Aug 4, 2011, at 10:52 PM, dane issue tracker wrote: > #28: Interaction of SRV and TLSA records >=20 >=20 > Comment(by matt@=85): >=20 > To amplify [comment:1 comment 1]: DANE applies to a service endpoint > identified by (hostname, transport, port), i.e., after any service > discovery process that plays a part in determining this tuple. So = (b). >=20 > For a while, Phill wanted to entangle service discovery with DANE; I = don't > know that he ever accepted my decomposition, but at least he stopped > claiming that I had failed to justify it. >=20 > --=20 > = --------------------------------+-----------------------------------------= -- > Reporter: ondrej.sury@=85 | Owner: = draft-ietf-dane-protocol@=85 =20 > Type: defect | Status: new = =20 > Priority: major | Milestone: = =20 > Component: protocol | Version: = =20 > Severity: - | Keywords: = =20 > = --------------------------------+-----------------------------------------= -- >=20 > Ticket URL: = > dane >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From jakob@kirei.se Fri Aug 5 07:51:03 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D922B21F8C31 for ; Fri, 5 Aug 2011 07:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.44 X-Spam-Level: X-Spam-Status: No, score=-0.44 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hmZkdWEde1oU for ; Fri, 5 Aug 2011 07:51:03 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id 86AEE21F8B98 for ; Fri, 5 Aug 2011 07:51:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=FxGL3VWVuRtlSSLMfBvozKV8BLu6B7mF7eCzIIZ0PRw=; b=Xm14D3/wmb6NZfKqdpg7scmi4+lkqYnQdiGyrpGM2qwGjue352FwkFtM9kbnEk3S0wSBOEcKFX+sH XFp8WknCQi/6eL20FdhENrsyV0VEmvP30pCoRygcWgcAet8JZboFwF6qNxYzFdSyqQD+05JA+6rgnO 9EFrGTZCGD6HYG7A= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Fri, 5 Aug 2011 16:51:13 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=windows-1252 From: Jakob Schlyter In-Reply-To: <7155FD03-FC81-4DFD-B2B0-4C7B416AF3AE@bbn.com> Date: Fri, 5 Aug 2011 16:51:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2507F972-E235-468B-B118-E07D3B47DC18@kirei.se> References: <057.eb22cfc8c145014f66d7c72f9cf864f8@trac.tools.ietf.org> <066.aaadec73af2c30671ce4150b9a6d7b51@trac.tools.ietf.org> <7155FD03-FC81-4DFD-B2B0-4C7B416AF3AE@bbn.com> To: Richard L. Barnes X-Mailer: Apple Mail (2.1244.3) Cc: dane@ietf.org Subject: Re: [dane] #28: Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 14:51:04 -0000 On 5 aug 2011, at 15:59, Richard L. Barnes wrote: > Why is this an issue? I thought that there was a fair bit of = agreement that SRV resolution was a step before DANE came into play, and = thus that the two processes are not interrelated. After all, the TLS = server is not the name you start the SRV process with, it's the result, = and DANE addresses only the TLS server, not any application-layer = identity of the server. +1 jakob From mrex@sap.com Fri Aug 5 09:23:40 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5399121F8B87 for ; Fri, 5 Aug 2011 09:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.98 X-Spam-Level: X-Spam-Status: No, score=-9.98 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id esWewPaU51ed for ; Fri, 5 Aug 2011 09:23:39 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF0321F8B71 for ; Fri, 5 Aug 2011 09:23:39 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p75GNmGp013329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 5 Aug 2011 18:23:48 +0200 (MEST) From: Martin Rex Message-Id: <201108051623.p75GNlMO023764@fs4113.wdf.sap.corp> To: rbarnes@bbn.com (Richard L. Barnes) Date: Fri, 5 Aug 2011 18:23:47 +0200 (MEST) In-Reply-To: <7155FD03-FC81-4DFD-B2B0-4C7B416AF3AE@bbn.com> from "Richard L. Barnes" at Aug 5, 11 09:59:25 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: draft-ietf-dane-protocol@tools.ietf.org, dane@ietf.org, trac+dane@zinfandel.tools.ietf.org Subject: Re: [dane] #28: Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 16:23:40 -0000 Richard L. Barnes wrote: > > Why is this an issue? The purpose of both, traditional TLS server endpoint identification and DANE is similar: provide some means to verify the identity of the server (it is similar to "authentication", but weaker). > > I thought that there was a fair bit of agreement > that SRV resolution was a step before DANE came into play, and thus that > the two processes are not interrelated. There are _very_ interrelated. As long as we cling to the concept that "the user wanted to access 'example.com'", we have to ensure that whatever the user gets is securely authorized by 'example.com'". The answer to the different question "have i connected to server.foobar.net" (by itself) is not a valid substitute to the users stated intend to connect to "example.com", unless there is a TLSA record in example.com that confirms that the certificate presented by server.foobar.net is authorized to provide the service for "example.com". > > After all, the TLS server is not the name you start the SRV process with, > it's the result, and DANE addresses only the TLS server, not any > application-layer identity of the server. > > Opening an XMPP connection to example.com with SRV and DANE > 1. Look up SRV _xmpp-server._tcp.example.com > 2. Get _xmpp-server._tcp.example.com SRV xmpp1.hoster.com > 3. Look up TLSA _5222._tcp.xmpp1.hoster.com > 4. [[ follow any requisite CNAMEs ]] > 5. Get _5222._tcp.xmpp1.hoster.com TLSA ... [[ or CNAME-redirected ]] > 6. Proceed with TLS connection If you want to use SRV as described above, you imply that you do not care about server endpoint identification at all (It might be that you do not intend to say that, but technically, that is what you do by requesting to look at the name that comes _out_of_ a DNS SRV lookup rather than matching against the reference name that the application starts with (and that goes _into_ the SRV lookup). As I described in a previous message, for XMPP the -Martin From ietf@augustcellars.com Fri Aug 5 12:50:55 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0EF021F89A7 for ; Fri, 5 Aug 2011 12:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.074 X-Spam-Level: X-Spam-Status: No, score=-3.074 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SC3Eom23MTVG for ; Fri, 5 Aug 2011 12:50:55 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 08D5C21F89A1 for ; Fri, 5 Aug 2011 12:50:55 -0700 (PDT) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id E0EBD2CA1A; Fri, 5 Aug 2011 12:51:12 -0700 (PDT) From: "Jim Schaad" To: "'Richard L. Barnes'" , "'dane issue tracker'" References: <057.eb22cfc8c145014f66d7c72f9cf864f8@trac.tools.ietf.org> <066.aaadec73af2c30671ce4150b9a6d7b51@trac.tools.ietf.org> <7155FD03-FC81-4DFD-B2B0-4C7B416AF3AE@bbn.com> In-Reply-To: <7155FD03-FC81-4DFD-B2B0-4C7B416AF3AE@bbn.com> Date: Fri, 5 Aug 2011 13:25:29 -0700 Message-ID: <018c01cc53ad$d224b390$766e1ab0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH+teWQlYD0HLCuO1IuVa5JmOsz5AF/wsAJAT9JrqeUk/VOEA== Content-Language: en-us Cc: draft-ietf-dane-protocol@tools.ietf.org, dane@ietf.org Subject: Re: [dane] #28: Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 19:50:56 -0000 So just to be clean in my mind, a client does the following: 1. Map a service name to a server name. This would be done in a service specific manner using things such as MX or SRV records, funny naming (prefix naming) and so forth. 2. Map the server name to an address 3. Retrieve the TSLA records based solely on the server name, protocol and port number. We are therefore ruling out of scope for DANE any matching for the TLS session certificates based on the service/domain name pair as oppose to the server name. If for example, the protocol FOO defined a name form of FOO: and said that it is to be published in a certificate as a SAN and that no server DNS name is to be published then there would be no way to deal with indirecting through a SRV record to get from a service name to a server name. i.e. _FOO.alice.com IN SRV 1 1 5990 alice.oscar.com Could never have a certificate with the SAN of FOO:alice.com but would instead need to have an SAN of FOO:alice.oscar.com as that is the only server name we would have and DANE has stated that we only deal with server names and not service names. Jim > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of > Richard L. Barnes > Sent: Friday, August 05, 2011 6:59 AM > To: dane issue tracker > Cc: draft-ietf-dane-protocol@tools.ietf.org; dane@ietf.org > Subject: Re: [dane] #28: Interaction of SRV and TLSA records > > Why is this an issue? I thought that there was a fair bit of agreement that > SRV resolution was a step before DANE came into play, and thus that the two > processes are not interrelated. After all, the TLS server is not the name you > start the SRV process with, it's the result, and DANE addresses only the TLS > server, not any application-layer identity of the server. > > Opening an XMPP connection to example.com with SRV and DANE 1. Look up > SRV _xmpp-server._tcp.example.com 2. Get _xmpp- > server._tcp.example.com SRV xmpp1.hoster.com 3. Look up TLSA > _5222._tcp.xmpp1.hoster.com 4. [[ follow any requisite CNAMEs ]] 5. Get > _5222._tcp.xmpp1.hoster.com TLSA ... [[ or CNAME-redirected ]] 6. Proceed > with TLS connection > > --Richard > > > > On Aug 4, 2011, at 10:52 PM, dane issue tracker wrote: > > > #28: Interaction of SRV and TLSA records > > > > > > Comment(by matt@.): > > > > To amplify [comment:1 comment 1]: DANE applies to a service endpoint > > identified by (hostname, transport, port), i.e., after any service > > discovery process that plays a part in determining this tuple. So (b). > > > > For a while, Phill wanted to entangle service discovery with DANE; I > > don't know that he ever accepted my decomposition, but at least he > > stopped claiming that I had failed to justify it. > > > > -- > > --------------------------------+------------------------------------- > > --------------------------------+------ > > Reporter: ondrej.sury@. | Owner: draft-ietf-dane-protocol@. > > Type: defect | Status: new > > Priority: major | Milestone: > > Component: protocol | Version: > > Severity: - | Keywords: > > --------------------------------+------------------------------------- > > --------------------------------+------ > > > > Ticket URL: > > > > dane > > > > _______________________________________________ > > 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 marka@isc.org Fri Aug 5 18:10:06 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8FF11E8084 for ; Fri, 5 Aug 2011 18:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.604 X-Spam-Level: X-Spam-Status: No, score=-2.604 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8AC-YnaMI8A for ; Fri, 5 Aug 2011 18:10:05 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id D574E21F85EE for ; Fri, 5 Aug 2011 18:09:36 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 08129C9422; Sat, 6 Aug 2011 01:09:44 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 916BB216C81; Sat, 6 Aug 2011 01:09:43 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id A60931284CF4; Sat, 6 Aug 2011 11:09:42 +1000 (EST) To: mrex@sap.com From: Mark Andrews References: <201108051623.p75GNlMO023764@fs4113.wdf.sap.corp> In-reply-to: Your message of "Fri, 05 Aug 2011 18:23:47 +0200." <201108051623.p75GNlMO023764@fs4113.wdf.sap.corp> Date: Sat, 06 Aug 2011 11:09:42 +1000 Message-Id: <20110806010942.A60931284CF4@drugs.dv.isc.org> Cc: draft-ietf-dane-protocol@tools.ietf.org, trac+dane@zinfandel.tools.ietf.org, dane@ietf.org Subject: Re: [dane] #28: Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2011 01:10:06 -0000 In message <201108051623.p75GNlMO023764@fs4113.wdf.sap.corp>, Martin Rex writes : > Richard L. Barnes wrote: > > > > Why is this an issue? > > The purpose of both, traditional TLS server endpoint identification > and DANE is similar: provide some means to verify the identity of the > server (it is similar to "authentication", but weaker). > > > > > > I thought that there was a fair bit of agreement > > that SRV resolution was a step before DANE came into play, and thus that > > the two processes are not interrelated. > > There are _very_ interrelated. As long as we cling to the concept > that "the user wanted to access 'example.com'", we have to ensure > that whatever the user gets is securely authorized by 'example.com'". > > The answer to the different question "have i connected to server.foobar.net" > (by itself) is not a valid substitute to the users stated intend > to connect to "example.com", unless there is a TLSA record in example.com > that confirms that the certificate presented by server.foobar.net is > authorized to provide the service for "example.com". > > > > > > After all, the TLS server is not the name you start the SRV process with, > > it's the result, and DANE addresses only the TLS server, not any > > application-layer identity of the server. > > > > Opening an XMPP connection to example.com with SRV and DANE > > 1. Look up SRV _xmpp-server._tcp.example.com > > 2. Get _xmpp-server._tcp.example.com SRV xmpp1.hoster.com > > 3. Look up TLSA _5222._tcp.xmpp1.hoster.com > > 4. [[ follow any requisite CNAMEs ]] > > 5. Get _5222._tcp.xmpp1.hoster.com TLSA ... [[ or CNAME-redirected ]] > > 6. Proceed with TLS connection > > If you want to use SRV as described above, you imply that you do > not care about server endpoint identification at all (It might be > that you do not intend to say that, but technically, that is what > you do by requesting to look at the name that comes _out_of_ a > DNS SRV lookup rather than matching against the reference name that > the application starts with (and that goes _into_ the SRV lookup). No, there are just different security models for the different transport models. HTTP uses one model and SMTP uses a different model. HTTP is direct, SMTP is store and forward. > As I described in a previous message, for XMPP the > > > -Martin > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From leifj@mnt.se Sat Aug 6 04:39:53 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 133C421F8752 for ; Sat, 6 Aug 2011 04:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qji7N4idNzz for ; Sat, 6 Aug 2011 04:39:52 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id E157F21F874A for ; Sat, 6 Aug 2011 04:39:51 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p76Be5Wr020523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 6 Aug 2011 13:40:09 +0200 (CEST) Message-ID: <4E3D2814.7090408@mnt.se> Date: Sat, 06 Aug 2011 13:40:04 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: dane@ietf.org References: <057.eb22cfc8c145014f66d7c72f9cf864f8@trac.tools.ietf.org> <066.aaadec73af2c30671ce4150b9a6d7b51@trac.tools.ietf.org> <7155FD03-FC81-4DFD-B2B0-4C7B416AF3AE@bbn.com> <2507F972-E235-468B-B118-E07D3B47DC18@kirei.se> In-Reply-To: <2507F972-E235-468B-B118-E07D3B47DC18@kirei.se> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dane] #28: Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2011 11:39:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/05/2011 04:51 PM, Jakob Schlyter wrote: > On 5 aug 2011, at 15:59, Richard L. Barnes wrote: > >> Why is this an issue? I thought that there was a fair bit of agreement that SRV resolution was a step before DANE came into play, and thus that the two processes are not interrelated. After all, the TLS server is not the name you start the SRV process with, it's the result, and DANE addresses only the TLS server, not any application-layer identity of the server. > > +1 I tried to introduce the SRV analogy to prove that very point. Unfortunately the point was somewhat lost. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk49KBQACgkQ8Jx8FtbMZnf/NQCggnZZhAo0op+fQ2qa9Rg77cGn sosAnAlLR19ANpY7ZRZIFSSU5v58DjN6 =Vw6R -----END PGP SIGNATURE----- From bmanning@karoshi.com Sat Aug 6 07:19:09 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1A0221F875C for ; Sat, 6 Aug 2011 07:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.41 X-Spam-Level: X-Spam-Status: No, score=-6.41 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZS9B+11jHhS4 for ; Sat, 6 Aug 2011 07:19:09 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id 3A5AF21F873D for ; Sat, 6 Aug 2011 07:19:09 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id p76EJSmw003502; Sat, 6 Aug 2011 14:19:29 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id p76EJON9003501; Sat, 6 Aug 2011 14:19:24 GMT Date: Sat, 6 Aug 2011 14:19:24 +0000 From: bmanning@vacation.karoshi.com To: Matt Larson Message-ID: <20110806141924.GA1726@vacation.karoshi.com.> References: <20110801014459.GD20015@shinkuro.com> <4E366812.5090206@mnt.se> <4E37B5AD.9040307@mnt.se> <4E37F5E6.2040708@mnt.se> <005c01cc524b$3db41a60$b91c4f20$@augustcellars.com> <2B9FB13C-E6F0-4E8E-A7E5-D7CAC0578BBC@kirei.se> <20110804125841.GD4206@DUL1MLARSON-M2.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110804125841.GD4206@DUL1MLARSON-M2.vcorp.ad.vrsn.com> User-Agent: Mutt/1.4.1i Cc: dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2011 14:19:09 -0000 On Thu, Aug 04, 2011 at 08:58:41AM -0400, Matt Larson wrote: > On Thu, 04 Aug 2011, Jakob Schlyter wrote: > > 3) Web > > > > For web servers, there exists no (widely deployed) service to server mapping. CNAMEs are sometimes used (as in the example below), but transparent ("invisible") for the client application. > > > > www.example.com. IN CNAME server1.example.com. > > server1.example.com. IN A 192.0.2.1 > > _443._tcp.www.example.com. IN TLSA ... > > +1000 to this. A TLSA-aware application should be a user of DNS just > as any other application, which means it should not be aware of > underlying DNS structure (e.g., aliases): that way lies madness, > exceptions to existing practice elsewhere, layer violations, > application complexity, pain and suffering. > > Seriously, changing the semantics of DNS aliasing on a per-application > basis to route around fundamental DNS behavior because it is > inconvenient is the wrong way to go. > > Matt Have to agree with Matt (and others) on this aspect. As I remember, DANE is supposed to work in -all- parts of the DNS heirarchy - so I have to ask myself if these proposed changes would work in the address/reverse map of the DNS? /bill From paul.hoffman@vpnc.org Sat Aug 6 08:10:08 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 616B721F86C2 for ; Sat, 6 Aug 2011 08:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AupDIN-j+TVX for ; Sat, 6 Aug 2011 08:10:07 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 8D08221F86C1 for ; Sat, 6 Aug 2011 08:10:07 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p76F9gbK035687 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 6 Aug 2011 08:09:44 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <057.eb22cfc8c145014f66d7c72f9cf864f8@trac.tools.ietf.org> Date: Sat, 6 Aug 2011 08:10:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3E11D9A1-E760-4E09-A377-4032BFA81C34@vpnc.org> References: <057.eb22cfc8c145014f66d7c72f9cf864f8@trac.tools.ietf.org> To: dane issue tracker X-Mailer: Apple Mail (2.1244.3) Cc: draft-ietf-dane-protocol@tools.ietf.org, dane@ietf.org Subject: Re: [dane] #28: Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2011 15:10:08 -0000 On Aug 3, 2011, at 11:42 PM, dane issue tracker wrote: > #28: Interaction of SRV and TLSA records >=20 > Issue raised by Jim Schaad in: >=20 > http://www.ietf.org/mail-archive/web/dane/current/msg03044.html >=20 > And the issue is, if we have: >=20 > _jabber._tcp.jabber.alice.com IN SRV 5 0 5269 jabber.bob.com. > _xmpp-client._tcp.jabber.alice.com IN SRV 5 0 5222 jabber.bob.com. > _xmpp-server._tcp.jabber.alice.com IN SRV 5 0 5269 jabber.bob.com. >=20 > Should the DANE-aware client look-up: >=20 > a) _port._tcp._jabber._tcp.jabber.alice.com IN TLSA > b) _5269._tcp.jabber.bob.com >=20 > Or even: > c) _5269._tcp.jabber.alice.com >=20 > when interacting with alice@jabber.alice.com? (b), based on the idea that the user's agent will know that it was = connecting to jabber.bob.com after doing the SRV lookup.=20 --Paul Hoffman From hallam@gmail.com Sat Aug 6 08:17:10 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE15C21F87C6 for ; Sat, 6 Aug 2011 08:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.458 X-Spam-Level: X-Spam-Status: No, score=-3.458 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P290i5f+8ZQ9 for ; Sat, 6 Aug 2011 08:17:10 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id DB2C821F873D for ; Sat, 6 Aug 2011 08:17:09 -0700 (PDT) Received: by gxk19 with SMTP id 19so222822gxk.31 for ; Sat, 06 Aug 2011 08:17:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=19QGamj68Nba7e+DuArWLA0HSiNNP3cK4IEb2BcXM/0=; b=H20wHfJqtcYTwwKbzEa6xB6GsAEGcqiG5HtrNQab9pXesdEBQLTquDOHQmzDXyLCL/ MTBczicRyQhSxqWzT1g77bNtP/P0v5LHRXDYtux/u85Wb1QYTDXBbzT42frXIy32WI1E j3KQkuPQAPhWnVleLJMRV/TVdMgha5jj9N3PM= MIME-Version: 1.0 Received: by 10.101.205.22 with SMTP id h22mr2975488anq.72.1312643849310; Sat, 06 Aug 2011 08:17:29 -0700 (PDT) Received: by 10.100.34.3 with HTTP; Sat, 6 Aug 2011 08:17:29 -0700 (PDT) In-Reply-To: <4e3d4d75.8349e70a.1102.2381SMTPIN_ADDED@mx.google.com> References: <20110801014459.GD20015@shinkuro.com> <4E366812.5090206@mnt.se> <4E37B5AD.9040307@mnt.se> <4E37F5E6.2040708@mnt.se> <005c01cc524b$3db41a60$b91c4f20$@augustcellars.com> <2B9FB13C-E6F0-4E8E-A7E5-D7CAC0578BBC@kirei.se> <20110804125841.GD4206@DUL1MLARSON-M2.vcorp.ad.vrsn.com> <4e3d4d75.8349e70a.1102.2381SMTPIN_ADDED@mx.google.com> Date: Sat, 6 Aug 2011 11:17:29 -0400 Message-ID: From: Phillip Hallam-Baker To: bmanning@vacation.karoshi.com Content-Type: multipart/alternative; boundary=0016e6d27c745ad1af04a9d7b6ce Cc: dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2011 15:17:10 -0000 --0016e6d27c745ad1af04a9d7b6ce Content-Type: text/plain; charset=ISO-8859-1 Nobody is proposing changing the semantics of DNS. That is a gross distortion of what was proposed. I don't think there is much point in engaging in debate on such terms. The reason I made my proposal was to preserve the semantics of the DNS as understood operationally by webmasters and hosting providers. It is really not relevant to these people that _prefix.example.com and example.com are utterly different names in DNS architecture. They want and expect them to behave the same. If they don't they are likely to conclude that DANE is a pointless waste of time because 'it does not work'. What is at issue is what a relying party should do if it is unable to find a TLSA record in the place it first looks for it. My view is that if the initial lookup fails, the client should attempt to follow CNAME references and other aliases to discover a TLSA record that might match. That applies to PTR and SRV as well On Sat, Aug 6, 2011 at 10:19 AM, wrote: > On Thu, Aug 04, 2011 at 08:58:41AM -0400, Matt Larson wrote: > > On Thu, 04 Aug 2011, Jakob Schlyter wrote: > > > 3) Web > > > > > > For web servers, there exists no (widely deployed) service to server > mapping. CNAMEs are sometimes used (as in the example below), but > transparent ("invisible") for the client application. > > > > > > www.example.com. IN CNAME server1.example.com. > > > server1.example.com. IN A 192.0.2.1 > > > _443._tcp.www.example.com. IN TLSA ... > > > > +1000 to this. A TLSA-aware application should be a user of DNS just > > as any other application, which means it should not be aware of > > underlying DNS structure (e.g., aliases): that way lies madness, > > exceptions to existing practice elsewhere, layer violations, > > application complexity, pain and suffering. > > > > Seriously, changing the semantics of DNS aliasing on a per-application > > basis to route around fundamental DNS behavior because it is > > inconvenient is the wrong way to go. > > > > Matt > > Have to agree with Matt (and others) on this aspect. > As I remember, DANE is supposed to work in -all- parts of the > DNS heirarchy - so I have to ask myself if these proposed > changes would work in the address/reverse map of the DNS? > > /bill > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > -- Website: http://hallambaker.com/ --0016e6d27c745ad1af04a9d7b6ce Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Nobody is proposing changing the semantics of DNS.

That = is a gross distortion of what was proposed.

I don&= #39;t think there is much point in engaging in debate on such terms.

The reason I made my proposal was to preserve the seman= tics of the DNS as understood operationally by webmasters and hosting provi= ders.=A0

It is really not relevant to these people= that _prefix.example.com and example.com are utterly different names in = DNS architecture. They want and expect them to behave the same. If they don= 't they are likely to conclude that DANE is a pointless waste of time b= ecause 'it does not work'.


What is at issue is what a relying party= should do if it is unable to find a TLSA record in the place it first look= s for it.

My view is that if the initial lookup fails, th= e client should attempt to follow CNAME references and other aliases to dis= cover a TLSA record that might match. That applies to PTR and SRV as well



On Sat, A= ug 6, 2011 at 10:19 AM, <bmanning@vacation.karoshi.com> wrote:
On Thu, Aug 04, 2011 at 08:58:41AM -0400, Matt Larson wro= te:
> On Thu, 04 Aug 2011, Jakob Schlyter wrote:
> > 3) Web
> >
> > For web servers, there exists no (widely deployed) service to ser= ver mapping. CNAMEs are sometimes used (as in the example below), but trans= parent ("invisible") for the client application.
> >
> > www.example.= com. =A0 =A0 =A0 =A0 =A0 =A0IN CNAME server1.example.com.
> > server1.= example.com. =A0 =A0 =A0 =A0IN A 192.0.2.1
> > _443._tc= p.www.example.com. =A0IN TLSA ...
>
> +1000 to this. =A0A TLSA-aware application should be a user of DNS jus= t
> as any other application, which means it should not be aware of
> underlying DNS structure (e.g., aliases): that way lies madness,
> exceptions to existing practice elsewhere, layer violations,
> application complexity, pain and suffering.
>
> Seriously, changing the semantics of DNS aliasing on a per-application=
> basis to route around fundamental DNS behavior because it is
> inconvenient is the wrong way to go.
>
> Matt

=A0 =A0 =A0 =A0Have to agree with Matt (and others) on this aspect.<= br> =A0 =A0 =A0 =A0As I remember, DANE is supposed to work in -all- parts of t= he
=A0 =A0 =A0 =A0DNS heirarchy - so I have to ask myself if these proposed =A0 =A0 =A0 =A0changes would work in the =A0address/reverse map of the DNS= ?

/bill
_________________________________________= ______
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane



--
Website: http://hallambaker.com/

--0016e6d27c745ad1af04a9d7b6ce-- From paul@xelerance.com Sat Aug 6 12:20:13 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55FCA21F854D for ; Sat, 6 Aug 2011 12:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.545 X-Spam-Level: X-Spam-Status: No, score=-6.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ViLKmyYkLqpQ for ; Sat, 6 Aug 2011 12:20:12 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id A22C421F8532 for ; Sat, 6 Aug 2011 12:20:12 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 31E5D571BC for ; Sat, 6 Aug 2011 15:21:58 -0400 (EDT) Date: Sat, 6 Aug 2011 15:21:57 -0400 (EDT) From: Paul Wouters To: dane@ietf.org In-Reply-To: Message-ID: References: <20110801014459.GD20015@shinkuro.com> <4E366812.5090206@mnt.se> <4E37B5AD.9040307@mnt.se> <4E37F5E6.2040708@mnt.se> <005c01cc524b$3db41a60$b91c4f20$@augustcellars.com> <2B9FB13C-E6F0-4E8E-A7E5-D7CAC0578BBC@kirei.se> <20110804125841.GD4206@DUL1MLARSON-M2.vcorp.ad.vrsn.com> <4e3d4d75.8349e70a.1102.2381SMTPIN_ADDED@mx.google.com> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2011 19:20:13 -0000 On Sat, 6 Aug 2011, Phillip Hallam-Baker wrote: > It is really not relevant to these people that _prefix.example.com and example.com are utterly different names in DNS > architecture. They want and expect them to behave the same. If they don't they are likely to conclude that DANE is a > pointless waste of time because 'it does not work'. I'll add a check to the "dane" command generator to check for cnames and create proper records. Paul From hallam@gmail.com Sat Aug 6 13:13:03 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F24F21F84FC for ; Sat, 6 Aug 2011 13:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.627 X-Spam-Level: X-Spam-Status: No, score=-2.627 tagged_above=-999 required=5 tests=[AWL=-0.695, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yAbSbcR8Ym8N for ; Sat, 6 Aug 2011 13:13:02 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 87F9321F8560 for ; Sat, 6 Aug 2011 13:13:02 -0700 (PDT) Received: by ywm21 with SMTP id 21so2507223ywm.31 for ; Sat, 06 Aug 2011 13:13:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fSrDsOktKDOI8B4pAJG7WGHJzLDy7j7vpojhxkOy3T8=; b=HY9yaQUAHj835vVVbZgxxKKLlEew/NE2qYu6cpewMDTFQELMlbGkljlzn+EILU8C+e 0RXRpBov5Fy0QKzV/7mA29FRR1ydKbl/qJaQ4NlTVAkQbyj82Jr4W+Z8i1xL2HErm5XT jK49qeOTCknFgrg87BkYlnipir8xvx2LvgvE8= MIME-Version: 1.0 Received: by 10.101.164.25 with SMTP id r25mr3151249ano.94.1312661603207; Sat, 06 Aug 2011 13:13:23 -0700 (PDT) Received: by 10.100.34.3 with HTTP; Sat, 6 Aug 2011 13:13:22 -0700 (PDT) In-Reply-To: References: <20110801014459.GD20015@shinkuro.com> <4E366812.5090206@mnt.se> <4E37B5AD.9040307@mnt.se> <4E37F5E6.2040708@mnt.se> <005c01cc524b$3db41a60$b91c4f20$@augustcellars.com> <2B9FB13C-E6F0-4E8E-A7E5-D7CAC0578BBC@kirei.se> <20110804125841.GD4206@DUL1MLARSON-M2.vcorp.ad.vrsn.com> <4e3d4d75.8349e70a.1102.2381SMTPIN_ADDED@mx.google.com> Date: Sat, 6 Aug 2011 16:13:22 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Wouters Content-Type: multipart/alternative; boundary=0016e6d26d7291ca3504a9dbd8fa Cc: dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2011 20:13:03 -0000 --0016e6d26d7291ca3504a9dbd8fa Content-Type: text/plain; charset=ISO-8859-1 That won't help. The problem is that unless CNAMES work the way people expect (i.e. one CNAME redirects both the site and associated TLSA record(s)) then the tool has to be run in two places and not just one. Worse, it means that I have to switch from my DNS hosting provider or wait till they support TLSA records in order to use TLSA. Now from a business point of view, that is not a bad outcome for my employer as a provider of full service DNS resolution services (DNS.com) and I suspect for many others in this thread. My concern here is that if the bar to making this work is set too high then people won't deploy at all. On Sat, Aug 6, 2011 at 3:21 PM, Paul Wouters wrote: > On Sat, 6 Aug 2011, Phillip Hallam-Baker wrote: > > It is really not relevant to these people that _prefix.example.com and >> example.com are utterly different names in DNS >> architecture. They want and expect them to behave the same. If they don't >> they are likely to conclude that DANE is a >> pointless waste of time because 'it does not work'. >> > > I'll add a check to the "dane" command generator to check for cnames and > create proper > records. > > Paul > > ______________________________**_________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/**listinfo/dane > -- Website: http://hallambaker.com/ --0016e6d26d7291ca3504a9dbd8fa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That won't help.

The problem is that unless CNAMES w= ork the way people expect (i.e. one CNAME redirects both the site and assoc= iated TLSA record(s)) then the tool has to be run in two places and not jus= t one.


Worse, it means that I have to switch fr= om my DNS hosting provider or wait till they support TLSA records in order = to use TLSA.

Now from a business point of view, th= at is not a bad outcome for my employer as a provider of full service DNS r= esolution services (DNS.com) and I suspect for many others in this thread. = My concern here is that if the bar to making this work is set too high then= people won't deploy at all.




On Sa= t, Aug 6, 2011 at 3:21 PM, Paul Wouters <paul@xelerance.com> wrote:
On Sat, 6 Aug 2011, Phillip Hallam-Baker wrote:

It is really not relevant to these people that _prefix.example.com and example.com are utterly different names i= n DNS
architecture. They want and expect them to behave the same. If they don'= ;t they are likely to conclude that DANE is a
pointless waste of time because 'it does not work'.

I'll add a check to the "dane" command generator to check for= cnames and create proper
records.

Paul

_______________________________________________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane



--
Website: http://hallambaker.com/

--0016e6d26d7291ca3504a9dbd8fa-- From gnu@toad.com Sat Aug 6 18:40:33 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0161721F873D for ; Sat, 6 Aug 2011 18:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.097 X-Spam-Level: X-Spam-Status: No, score=0.097 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_NJABL_RELAY=2.696] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnnRGoE01pzL for ; Sat, 6 Aug 2011 18:40:32 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id 94B6F21F86F4 for ; Sat, 6 Aug 2011 18:40:29 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id p771emqs001426; Sat, 6 Aug 2011 18:40:48 -0700 Message-Id: <201108070140.p771emqs001426@new.toad.com> To: Phillip Hallam-Baker In-reply-to: References: <20110801014459.GD20015@shinkuro.com> <4E366812.5090206@mnt.se> <4E37B5AD.9040307@mnt.se> <4E37F5E6.2040708@mnt.se> <005c01cc524b$3db41a60$b91c4f20$@augustcellars.com> <2B9FB13C-E6F0-4E8E-A7E5-D7CAC0578BBC@kirei.se> <20110804125841.GD4206@DUL1MLARSON-M2.vcorp.ad.vrsn.com> <4e3d4d75.8349e70a.1102.2381SMTPIN_ADDED@mx.google.com> Comments: In-reply-to Phillip Hallam-Baker message dated "Sat, 06 Aug 2011 16:13:22 -0400." Date: Sat, 06 Aug 2011 18:40:48 -0700 From: John Gilmore Cc: dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 07 Aug 2011 01:40:33 -0000 > The problem is that unless CNAMES work the way people expect (i.e. one CNAME > redirects both the site and associated TLSA record(s)) then the tool has to > be run in two places and not just one. Phillip, there is no "way people expect" TLSA records to work. There are no TLSA records in the wild. We are inventing them out of whole cloth. And we should define them to work in the straightforward way, like any other DNS record, without requiring resolvers to do hop-by-hop checks for intervening CNAMEs. To put it another way, CNAME is a wierd DNS record that has specific semantics that resolvers need to know about if they encounter one. Let's not add ANOTHER wierd DNS record that resolvers need to know about. If we could make TLSA as simple for DNS implementations as TXT, that would be lovely, Occam's Razor would smile at us, and we'd get early and wide deployment with few bugs. We could revisit whether to require SRV-like domain name prefixes on TLSA records; they are the reason why your knickers are in a knot over CNAMEs. But I suspect that the WG thinks that's a settled issue. And weren't you on the "make it like SRV" side of that issue? John From hallam@gmail.com Sat Aug 6 20:46:47 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6EF21F85C7 for ; Sat, 6 Aug 2011 20:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLOsiUC1Cj2N for ; Sat, 6 Aug 2011 20:46:46 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2E74221F85B5 for ; Sat, 6 Aug 2011 20:46:46 -0700 (PDT) Received: by gwb20 with SMTP id 20so920199gwb.31 for ; Sat, 06 Aug 2011 20:47:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=k8Rr1WjH0F0nak2IUZoiU+tYdUsgmfKaWBjbqCHAKzw=; b=SIciVYbzsaUU9j8Euv4nLa/nIQYqLZBxq33g8FYw7r1b34baDfJAe/J7HHqGPXhp/0 Cwfumgb+SotMoOD50N+EiLkbBqiBhsRg6FSd0SQXwcRIi+mRxV1q62xnzbfJVkcHpzYn 5hJcP6+Oi74UpiDR3/ji1h4khB5lk8NFa0UN4= MIME-Version: 1.0 Received: by 10.101.164.25 with SMTP id r25mr3287016ano.94.1312688827741; Sat, 06 Aug 2011 20:47:07 -0700 (PDT) Received: by 10.100.34.3 with HTTP; Sat, 6 Aug 2011 20:47:07 -0700 (PDT) In-Reply-To: <201108070140.p771emqs001426@new.toad.com> References: <20110801014459.GD20015@shinkuro.com> <4E366812.5090206@mnt.se> <4E37B5AD.9040307@mnt.se> <4E37F5E6.2040708@mnt.se> <005c01cc524b$3db41a60$b91c4f20$@augustcellars.com> <2B9FB13C-E6F0-4E8E-A7E5-D7CAC0578BBC@kirei.se> <20110804125841.GD4206@DUL1MLARSON-M2.vcorp.ad.vrsn.com> <4e3d4d75.8349e70a.1102.2381SMTPIN_ADDED@mx.google.com> <201108070140.p771emqs001426@new.toad.com> Date: Sat, 6 Aug 2011 23:47:07 -0400 Message-ID: From: Phillip Hallam-Baker To: John Gilmore Content-Type: multipart/alternative; boundary=0016e6d26d724736b004a9e22fd3 Cc: dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 07 Aug 2011 03:46:47 -0000 --0016e6d26d724736b004a9e22fd3 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Aug 6, 2011 at 9:40 PM, John Gilmore wrote: > > The problem is that unless CNAMES work the way people expect (i.e. one > CNAME > > redirects both the site and associated TLSA record(s)) then the tool has > to > > be run in two places and not just one. > > Phillip, there is no "way people expect" TLSA records to work. There > are no TLSA records in the wild. Wrong, they have 20 years of experience of how the Web works and that is their starting point. If DANE wants to propose a new record that behaves in a way that they consider to be illogical they can but it is going to be ignored. > We are inventing them out of whole > cloth. And we should define them to work in the straightforward way, > like any other DNS record, without requiring resolvers to do > hop-by-hop checks for intervening CNAMEs. > > To put it another way, CNAME is a wierd DNS record that has specific > semantics that resolvers need to know about if they encounter one. > Let's not add ANOTHER wierd DNS record that resolvers need to know > about. If we could make TLSA as simple for DNS implementations as > TXT, that would be lovely, Occam's Razor would smile at us, and > we'd get early and wide deployment with few bugs. > Implementations, implemenshmations. Its the million plus web masters who you want to use this scheme and the billion plus users of the Web that the scheme has to be designed for if it is going to be used. The problem for implementors in the browser space is not writing code, its selling the features to their management. And to do that they have to demonstrate that the scheme is going to work without causing huge customer support costs or pushing complexity into some other area. The status quo has huge inertia. At the moment the point seems to be moot as the browser world seems more interested in the original Kaminsky scheme of pickling the DNSSEC chain into the cert than using DNS records in any flavor. And the Web Services world has other security policy interests that Dane completely ignores. -- Website: http://hallambaker.com/ --0016e6d26d724736b004a9e22fd3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sat, Aug 6, 2011 at 9:40 PM, John Gil= more <gnu@toad.com= > wrote:
> The problem is that unless CNAMES work the way peopl= e expect (i.e. one CNAME
> redirects both the site and associated TLSA record(s)) then the tool h= as to
> be run in two places and not just one.

Phillip, there is no "way people expect" TLSA records to wo= rk. =A0There
are no TLSA records in the wild. =A0

Wrong,= they have 20 years of experience of how the Web works and that is their st= arting point.

If DANE wants to propose a new recor= d that behaves in a way that they consider to be illogical they can but it = is going to be ignored.


=A0
We are inventing them out of whole
cloth. =A0And we should define them to work in the straightforward way,
like any other DNS record, without requiring resolvers to do
hop-by-hop checks for intervening CNAMEs.

To put it another way, CNAME is a wierd DNS record that has specific
semantics that resolvers need to know about if they encounter one.
Let's not add ANOTHER wierd DNS record that resolvers need to know
about. =A0If we could make TLSA as simple for DNS implementations as
TXT, that would be lovely, Occam's Razor would smile at us, and
we'd get early and wide deployment with few bugs.
=
Implementations, implemenshmations.

Its the million plus web masters who you want to use this scheme and the b= illion plus users of the Web that the scheme has to be designed for if it i= s going to be used.

The problem for implementors in the browser space is no= t writing code, its selling the features to their management. And to do tha= t they have to demonstrate that the scheme is going to work without causing= huge customer support costs or pushing complexity into some other area.

The status quo has huge inertia.


At the moment the point seems to be moot as the browser w= orld seems more interested in the original Kaminsky scheme of pickling the = DNSSEC chain into the cert than using DNS records in any flavor. And the We= b Services world has other security policy interests that Dane completely i= gnores.


--
Website: http://hallambaker.com/

--0016e6d26d724736b004a9e22fd3-- From ajs@anvilwalrusden.com Sun Aug 7 11:24:11 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98B3021F8751 for ; Sun, 7 Aug 2011 11:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1P47JGipWUQJ for ; Sun, 7 Aug 2011 11:24:06 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id D0F5321F85FF for ; Sun, 7 Aug 2011 11:24:06 -0700 (PDT) Received: from shinkuro.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 15F361ECB41D for ; Sun, 7 Aug 2011 18:24:25 +0000 (UTC) Date: Sun, 7 Aug 2011 14:24:18 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20110807182417.GA66819@shinkuro.com> References: <4E37F5E6.2040708@mnt.se> <005c01cc524b$3db41a60$b91c4f20$@augustcellars.com> <2B9FB13C-E6F0-4E8E-A7E5-D7CAC0578BBC@kirei.se> <20110804125841.GD4206@DUL1MLARSON-M2.vcorp.ad.vrsn.com> <4e3d4d75.8349e70a.1102.2381SMTPIN_ADDED@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 07 Aug 2011 18:24:11 -0000 On Sat, Aug 06, 2011 at 04:13:22PM -0400, Phillip Hallam-Baker wrote: > The problem is that unless CNAMES work the way people expect (i.e. one CNAME > redirects both the site and associated TLSA record(s)) then the tool has to > be run in two places and not just one. I don't care whether anybody expects CNAMEs to work that way; they don't, and never have. People might expect http to come into their house in the morning and make the coffee, too, but it doesn't do that. I fail completely to see any sense in an argument that starts from, "A bunch of peopl -- trust me -- have this completely wrong idea of how the DNS work," and concludes with, "Therefore I want to do this thing that is really outstandingly different from everything else in the DNS." Even if I grant the premise that people expect the CNAME to work that way -- and, frankly, I'm sceptical, because I don't think most people have any intuition one way or another about how this is supposed to work -- I will not grant further that therefore that expectation has to be met. If you move from Britain to America, you might still exect to drive on the left hand side of the road. But if you try to behave like that, you'll regret it. You have to follow the rules. A -- Andrew Sullivan ajs@anvilwalrusden.com From marka@isc.org Sun Aug 7 15:45:32 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B729D21F87C5 for ; Sun, 7 Aug 2011 15:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.604 X-Spam-Level: X-Spam-Status: No, score=-2.604 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AhZsDif2oHY9 for ; Sun, 7 Aug 2011 15:45:32 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 3A02521F8799 for ; Sun, 7 Aug 2011 15:45:32 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id D7486C941E; Sun, 7 Aug 2011 22:45:45 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 6E27E216C7B; Sun, 7 Aug 2011 22:45:45 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 1DD0F128A238; Mon, 8 Aug 2011 08:45:43 +1000 (EST) To: Andrew Sullivan From: Mark Andrews References: <4E37F5E6.2040708@mnt.se> <005c01cc524b$3db41a60$b91c4f20$@augustcellars.com> <2B9FB13C-E6F0-4E8E-A7E5-D7CAC0578BBC@kirei.se> <20110804125841.GD4206@DUL1MLARSON-M2.vcorp.ad.vrsn.com> <4e3d4d75.8349e70a.1102.2381SMTPIN_ADDED@mx.google.com> <20110807182417.GA66819@shinkuro.com> In-reply-to: Your message of "Sun, 07 Aug 2011 14:24:18 -0400." <20110807182417.GA66819@shinkuro.com> Date: Mon, 08 Aug 2011 08:45:43 +1000 Message-Id: <20110807224543.1DD0F128A238@drugs.dv.isc.org> Cc: dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 07 Aug 2011 22:45:32 -0000 In message <20110807182417.GA66819@shinkuro.com>, Andrew Sullivan writes: > On Sat, Aug 06, 2011 at 04:13:22PM -0400, Phillip Hallam-Baker wrote: > > > The problem is that unless CNAMES work the way people expect (i.e. one CNAM > E > > redirects both the site and associated TLSA record(s)) then the tool has to > > be run in two places and not just one. > > I don't care whether anybody expects CNAMEs to work that way; they > don't, and never have. People might expect http to come into their > house in the morning and make the coffee, too, but it doesn't do that. > > I fail completely to see any sense in an argument that starts from, "A > bunch of peopl -- trust me -- have this completely wrong idea of how > the DNS work," and concludes with, "Therefore I want to do this thing > that is really outstandingly different from everything else in the > DNS." Even if I grant the premise that people expect the CNAME to > work that way -- and, frankly, I'm sceptical, because I don't think > most people have any intuition one way or another about how this is > supposed to work -- I will not grant further that therefore that > expectation has to be met. > > If you move from Britain to America, you might still exect to drive on > the left hand side of the road. But if you try to behave like that, > you'll regret it. You have to follow the rules. > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com Additionally there is a proposal on the table, BNAME, which will do what you want, redirection of the namespace at and below a name. You just need to get it through dnsext. I've argued for a long time that BNAME is a tool that should be in the DNS tool chest. example.com A ... example.com AAAA ... _443._tcp.example.com TLSA .... www.example.com BNAME example.com -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From rbarnes@bbn.com Mon Aug 8 04:56:17 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57F5021F8745 for ; Mon, 8 Aug 2011 04:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.587 X-Spam-Level: X-Spam-Status: No, score=-106.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7BKWCL71sj4 for ; Mon, 8 Aug 2011 04:56:16 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8DE21F86AF for ; Mon, 8 Aug 2011 04:56:16 -0700 (PDT) Received: from [128.89.254.201] (port=49627 helo=[192.168.1.12]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QqORk-000Lc1-8P; Mon, 08 Aug 2011 07:56:40 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Mon, 8 Aug 2011 07:56:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0B62F3C0-3793-4618-9671-5C3F502BE625@bbn.com> References: <20110801014459.GD20015@shinkuro.com> <4E366812.5090206@mnt.se> <4E37B5AD.9040307@mnt.se> <4E37F5E6.2040708@mnt.se> <005c01cc524b$3db41a60$b91c4f20$@augustcellars.com> <2B9FB13C-E6F0-4E8E-A7E5-D7CAC0578BBC@kirei.se> <20110804125841.GD4206@DUL1MLARSON-M2.vcorp.ad.vrsn.com> <4e3d4d75.8349e70a.1102.2381SMTPIN_ADDED@mx.google.com> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1082) Cc: dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 11:56:17 -0000 > The problem is that unless CNAMES work the way people expect (i.e. one = CNAME redirects both the site and associated TLSA record(s)) then the = tool has to be run in two places and not just one. This is true, but a consequence of the CNAME semantics. You have to = redirect each name individually. If you want to redirect a whole = subtree, use DNAME. We don't have to cut slots in the tops of our nails = because you want to use a screwdriver. > Worse, it means that I have to switch from my DNS hosting provider or = wait till they support TLSA records in order to use TLSA. This is not true, precisely because you don't have to redirect both = names. If your hosting provider does support TLSA, then you can = redirect both: alice.com CNAME bob.com _port._tcp.alice.com CNAME _port._tcp.bob.com ... but if they don't, then you can host the TLSA record yourself: alice.com CNAME bob.com _port._tcp.alice.com TLSA _port._tcp.bob.com You'll notice that it's precisely the independent redirection of the two = names that allows you to deploy TLSA without your provider supporting = it. =20 --Richard > Now from a business point of view, that is not a bad outcome for my = employer as a provider of full service DNS resolution services (DNS.com) = and I suspect for many others in this thread. My concern here is that if = the bar to making this work is set too high then people won't deploy at = all. >=20 >=20 >=20 >=20 > On Sat, Aug 6, 2011 at 3:21 PM, Paul Wouters = wrote: > On Sat, 6 Aug 2011, Phillip Hallam-Baker wrote: >=20 > It is really not relevant to these people that _prefix.example.com and = example.com are utterly different names in DNS > architecture. They want and expect them to behave the same. If they = don't they are likely to conclude that DANE is a > pointless waste of time because 'it does not work'. >=20 > I'll add a check to the "dane" command generator to check for cnames = and create proper > records. >=20 > Paul >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 >=20 >=20 > --=20 > Website: http://hallambaker.com/ >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From rbarnes@bbn.com Mon Aug 8 05:21:40 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BEC921F8A35 for ; Mon, 8 Aug 2011 05:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.287 X-Spam-Level: X-Spam-Status: No, score=-106.287 tagged_above=-999 required=5 tests=[AWL=-0.288, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ItDBwiOXkadY for ; Mon, 8 Aug 2011 05:21:39 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8D421F85C0 for ; Mon, 8 Aug 2011 05:21:39 -0700 (PDT) Received: from [128.89.254.201] (port=49678 helo=[192.168.1.12]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QqOpe-000Lv5-0z; Mon, 08 Aug 2011 08:21:23 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <018c01cc53ad$d224b390$766e1ab0$@augustcellars.com> Date: Mon, 8 Aug 2011 08:21:18 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <057.eb22cfc8c145014f66d7c72f9cf864f8@trac.tools.ietf.org> <066.aaadec73af2c30671ce4150b9a6d7b51@trac.tools.ietf.org> <7155FD03-FC81-4DFD-B2B0-4C7B416AF3AE@bbn.com> <018c01cc53ad$d224b390$766e1ab0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1082) Cc: draft-ietf-dane-protocol@tools.ietf.org, dane@ietf.org, 'dane issue tracker' Subject: Re: [dane] #28: Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 12:21:40 -0000 That's not quite correct. The matching of names in certificates happens = a layer above DANE; DANE is about finding a certificate for a name and = verifying its validity as a certificate, not necessarily its validity as = a credential for a particular name or service. That process is = specified by RFC 2818, RFC 6125, etc. So for example, an XMPP hosting provider's server xmpp1.provider.com = might have a cert that has an SRVName SAN for = _xmpp-server._tcp.customer.com. The hosting provider could then = provision that cert in a TLSA record under _port._tcp.xmpp1.provider.com = in order to facilitate discovery. But the SRVName would still be there = for the application to use in authenticating the remote entity. --Richard On Aug 5, 2011, at 4:25 PM, Jim Schaad wrote: > So just to be clean in my mind, a client does the following: >=20 > 1. Map a service name to a server name. This would be done in a = service > specific manner using things such as MX or SRV records, funny naming = (prefix > naming) and so forth. >=20 > 2. Map the server name to an address >=20 > 3. Retrieve the TSLA records based solely on the server name, = protocol and > port number. >=20 > We are therefore ruling out of scope for DANE any matching for the TLS > session certificates based on the service/domain name pair as oppose = to the > server name. If for example, the protocol FOO defined a name form of > FOO: and said that it is to be published in a certificate = as a > SAN and that no server DNS name is to be published then there would be = no > way to deal with indirecting through a SRV record to get from a = service name > to a server name. >=20 > i.e. >=20 > _FOO.alice.com IN SRV 1 1 5990 alice.oscar.com >=20 > Could never have a certificate with the SAN of FOO:alice.com but would > instead need to have an SAN of FOO:alice.oscar.com as that is the only > server name we would have and DANE has stated that we only deal with = server > names and not service names. >=20 > Jim >=20 >=20 >> -----Original Message----- >> From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf = Of >> Richard L. Barnes >> Sent: Friday, August 05, 2011 6:59 AM >> To: dane issue tracker >> Cc: draft-ietf-dane-protocol@tools.ietf.org; dane@ietf.org >> Subject: Re: [dane] #28: Interaction of SRV and TLSA records >>=20 >> Why is this an issue? I thought that there was a fair bit of = agreement > that >> SRV resolution was a step before DANE came into play, and thus that = the > two >> processes are not interrelated. After all, the TLS server is not the = name > you >> start the SRV process with, it's the result, and DANE addresses only = the > TLS >> server, not any application-layer identity of the server. >>=20 >> Opening an XMPP connection to example.com with SRV and DANE 1. Look = up >> SRV _xmpp-server._tcp.example.com 2. Get _xmpp- >> server._tcp.example.com SRV xmpp1.hoster.com 3. Look up TLSA >> _5222._tcp.xmpp1.hoster.com 4. [[ follow any requisite CNAMEs ]] 5. = Get >> _5222._tcp.xmpp1.hoster.com TLSA ... [[ or CNAME-redirected ]] 6. = Proceed >> with TLS connection >>=20 >> --Richard >>=20 >>=20 >>=20 >> On Aug 4, 2011, at 10:52 PM, dane issue tracker wrote: >>=20 >>> #28: Interaction of SRV and TLSA records >>>=20 >>>=20 >>> Comment(by matt@.): >>>=20 >>> To amplify [comment:1 comment 1]: DANE applies to a service endpoint >>> identified by (hostname, transport, port), i.e., after any service >>> discovery process that plays a part in determining this tuple. So = (b). >>>=20 >>> For a while, Phill wanted to entangle service discovery with DANE; I >>> don't know that he ever accepted my decomposition, but at least he >>> stopped claiming that I had failed to justify it. >>>=20 >>> -- >>> = --------------------------------+------------------------------------- >>> --------------------------------+------ >>> Reporter: ondrej.sury@. | Owner: > draft-ietf-dane-protocol@. >>> Type: defect | Status: new >>> Priority: major | Milestone: >>> Component: protocol | Version: >>> Severity: - | Keywords: >>> = --------------------------------+------------------------------------- >>> --------------------------------+------ >>>=20 >>> Ticket URL: >>> >>> dane >>>=20 >>> _______________________________________________ >>> dane mailing list >>> dane@ietf.org >>> https://www.ietf.org/mailman/listinfo/dane >>=20 >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >=20 From jakob@kirei.se Mon Aug 8 05:27:28 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CADBE21F8A4F for ; Mon, 8 Aug 2011 05:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.462 X-Spam-Level: X-Spam-Status: No, score=-0.462 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92gHdOx1AUI1 for ; Mon, 8 Aug 2011 05:27:28 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id A771D21F8556 for ; Mon, 8 Aug 2011 05:27:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=buMd54kN3q8VPEegSJ6YITNgKzMjBemUcEtXKbQLo7Q=; b=xAzRY8uN4l6+iDP0dXNinpVSytAws0QoOHRA9OqR9xozb35qSujYra4nDn5x00mpYBh3BJsGkvZoJ ZbrQG+V9N8qsh+sUWpAAYQvllAgeQv+Iwrvit60ww+8ZCDDqVzF/z2x37aNdFGWlV1qcQxD8TEGG6o dmU5tfasKTQMdpVE= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Mon, 8 Aug 2011 14:27:49 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: <0B62F3C0-3793-4618-9671-5C3F502BE625@bbn.com> Date: Mon, 8 Aug 2011 14:27:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110801014459.GD20015@shinkuro.com> <4E366812.5090206@mnt.se> <4E37B5AD.9040307@mnt.se> <4E37F5E6.2040708@mnt.se> <005c01cc524b$3db41a60$b91c4f20$@augustcellars.com> <2B9FB13C-E6F0-4E8E-A7E5-D7CAC0578BBC@kirei.se> <20110804125841.GD4206@DUL1MLARSON-M2.vcorp.ad.vrsn.com> <4e3d4d75.8349e70a.1102.2381SMTPIN_ADDED@mx.google.com> <0B62F3C0-3793-4618-9671-5C3F502BE625@bbn.com> To: Richard L. Barnes X-Mailer: Apple Mail (2.1244.3) Cc: dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 12:27:28 -0000 On 8 aug 2011, at 13:56, Richard L. Barnes wrote: > You'll notice that it's precisely the independent redirection of the = two names that allows you to deploy TLSA without your provider = supporting it. =20 This is also, IMHO, a very important security feature. FWIW, the = provider you are delegating to does not even have to support DNSSEC. On = the other hand, if you want to delegate TLSA (and they support it), your = free to do so. jakob From bmanning@karoshi.com Tue Aug 9 02:23:37 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52C1721F8B3D for ; Tue, 9 Aug 2011 02:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.125 X-Spam-Level: X-Spam-Status: No, score=-6.125 tagged_above=-999 required=5 tests=[AWL=-0.126, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ysTES47Wko9 for ; Tue, 9 Aug 2011 02:23:36 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id 5145E21F8B2B for ; Tue, 9 Aug 2011 02:23:36 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id p799Ntmw029508; Tue, 9 Aug 2011 09:23:55 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id p799NpH3029507; Tue, 9 Aug 2011 09:23:51 GMT Date: Tue, 9 Aug 2011 09:23:51 +0000 From: bmanning@vacation.karoshi.com To: Jim Schaad Message-ID: <20110809092351.GC29435@vacation.karoshi.com.> References: <057.eb22cfc8c145014f66d7c72f9cf864f8@trac.tools.ietf.org> <066.aaadec73af2c30671ce4150b9a6d7b51@trac.tools.ietf.org> <7155FD03-FC81-4DFD-B2B0-4C7B416AF3AE@bbn.com> <018c01cc53ad$d224b390$766e1ab0$@augustcellars.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <018c01cc53ad$d224b390$766e1ab0$@augustcellars.com> User-Agent: Mutt/1.4.1i Cc: draft-ietf-dane-protocol@tools.ietf.org, dane@ietf.org, 'dane issue tracker' Subject: Re: [dane] #28: Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 09:23:37 -0000 and how are caches folded into this mix? in steps 2 & 3, if I preload a cache w/ data, your resolver is going to use it, right? /bill On Fri, Aug 05, 2011 at 01:25:29PM -0700, Jim Schaad wrote: > So just to be clean in my mind, a client does the following: > > 1. Map a service name to a server name. This would be done in a service > specific manner using things such as MX or SRV records, funny naming (prefix > naming) and so forth. > > 2. Map the server name to an address > > 3. Retrieve the TSLA records based solely on the server name, protocol and > port number. > > We are therefore ruling out of scope for DANE any matching for the TLS > session certificates based on the service/domain name pair as oppose to the > server name. If for example, the protocol FOO defined a name form of > FOO: and said that it is to be published in a certificate as a > SAN and that no server DNS name is to be published then there would be no > way to deal with indirecting through a SRV record to get from a service name > to a server name. > > i.e. > > _FOO.alice.com IN SRV 1 1 5990 alice.oscar.com > > Could never have a certificate with the SAN of FOO:alice.com but would > instead need to have an SAN of FOO:alice.oscar.com as that is the only > server name we would have and DANE has stated that we only deal with server > names and not service names. > > Jim > > > > -----Original Message----- > > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of > > Richard L. Barnes > > Sent: Friday, August 05, 2011 6:59 AM > > To: dane issue tracker > > Cc: draft-ietf-dane-protocol@tools.ietf.org; dane@ietf.org > > Subject: Re: [dane] #28: Interaction of SRV and TLSA records > > > > Why is this an issue? I thought that there was a fair bit of agreement > that > > SRV resolution was a step before DANE came into play, and thus that the > two > > processes are not interrelated. After all, the TLS server is not the name > you > > start the SRV process with, it's the result, and DANE addresses only the > TLS > > server, not any application-layer identity of the server. > > > > Opening an XMPP connection to example.com with SRV and DANE 1. Look up > > SRV _xmpp-server._tcp.example.com 2. Get _xmpp- > > server._tcp.example.com SRV xmpp1.hoster.com 3. Look up TLSA > > _5222._tcp.xmpp1.hoster.com 4. [[ follow any requisite CNAMEs ]] 5. Get > > _5222._tcp.xmpp1.hoster.com TLSA ... [[ or CNAME-redirected ]] 6. Proceed > > with TLS connection > > > > --Richard > > > > > > > > On Aug 4, 2011, at 10:52 PM, dane issue tracker wrote: > > > > > #28: Interaction of SRV and TLSA records > > > > > > > > > Comment(by matt@.): > > > > > > To amplify [comment:1 comment 1]: DANE applies to a service endpoint > > > identified by (hostname, transport, port), i.e., after any service > > > discovery process that plays a part in determining this tuple. So (b). > > > > > > For a while, Phill wanted to entangle service discovery with DANE; I > > > don't know that he ever accepted my decomposition, but at least he > > > stopped claiming that I had failed to justify it. > > > > > > -- > > > --------------------------------+------------------------------------- > > > --------------------------------+------ > > > Reporter: ondrej.sury@. | Owner: > draft-ietf-dane-protocol@. > > > Type: defect | Status: new > > > Priority: major | Milestone: > > > Component: protocol | Version: > > > Severity: - | Keywords: > > > --------------------------------+------------------------------------- > > > --------------------------------+------ > > > > > > Ticket URL: > > > > > > dane > > > > > > _______________________________________________ > > > 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 > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From bmanning@karoshi.com Tue Aug 9 02:32:43 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEC5A21F8B0C for ; Tue, 9 Aug 2011 02:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.416 X-Spam-Level: X-Spam-Status: No, score=-6.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sM2qYbSy0lmk for ; Tue, 9 Aug 2011 02:32:43 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id 2BDD321F8B23 for ; Tue, 9 Aug 2011 02:32:43 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id p799Igmw029497; Tue, 9 Aug 2011 09:18:43 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id p799IffI029496; Tue, 9 Aug 2011 09:18:41 GMT Date: Tue, 9 Aug 2011 09:18:41 +0000 From: bmanning@vacation.karoshi.com To: Jakob Schlyter Message-ID: <20110809091841.GB29435@vacation.karoshi.com.> References: <20110802001308.26792.qmail@joyce.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: dane@ietf.org Subject: Re: [dane] The Curse of The Same, was CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 09:32:44 -0000 On Tue, Aug 02, 2011 at 07:46:00AM +0200, Jakob Schlyter wrote: > On 2 aug 2011, at 02:13, John Levine wrote: > > > Example 2: > > > > www.foo.com CNAME www.bar.com > > www.bar.com A 1.2.3.4 > > _443._tcp.www.foo.com TLSA "foo stuff" > > _443._tcp.www.bar.com TLSA "bar stuff" > > > > Is this valid? If so, should an application using DANE looking at > > www.foo.com find the foo stuff or the bar stuff? > > Yes, this is valid. See my not on SNI in another thread (foo & bar may have different certs at the same endpoint). > > jakob > this seems analogous to this particular configuration... 53.0.0.127.in-addr.arpa. in ptr www.foo.com. in ptr www.bar.com. and asking "is it valid?" (yes) and not "which one gets used?" (the first one? the second one? or both?) and what metrics are used to discriminate. extending Johns example a bit... www.foo.com CNAME www.bar.com www.bar.com A 1.2.3.4 _443._tcp.www.foo.com TLSA "foo stuff" _443._tcp.www.bar.com TLSA "bar stuff" _443._tcp.www.bbss.com TLSA "bbss stuff" _443._tcp.www.example.com TLSA "example stuff" _443._tcp.www.AA.com TLSA "UAL stuff" valid? sure. useful? /bill From jakob@kirei.se Tue Aug 9 05:46:07 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9359321F8AA9 for ; Tue, 9 Aug 2011 05:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.48 X-Spam-Level: X-Spam-Status: No, score=-0.48 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id moCY9UGTDGw8 for ; Tue, 9 Aug 2011 05:46:07 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id 6682321F8ABB for ; Tue, 9 Aug 2011 05:46:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=MYkb5qekblUM2/86J354xPHpzDLKhA0lVkjG0rhWZko=; b=w4WnwiRpmPji7ZLodLc5gHQZ49RQeGBU8RInF5crFUdHxJDpcLM8/ULh4zm5XmlYMqrEA3HbJM3xE TFaxlOziILvDsxTetLDy5IkzTKjkfXcMj9m8vvQ12nCdTZcoOaSSjV+fyWftVrcEfccUhxwdvGaAs3 JvSUQNx62XF6S8Gs= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Tue, 9 Aug 2011 14:46:32 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: <20110809091841.GB29435@vacation.karoshi.com.> Date: Tue, 9 Aug 2011 14:46:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110802001308.26792.qmail@joyce.lan> <20110809091841.GB29435@vacation.karoshi.com.> To: bmanning@vacation.karoshi.com X-Mailer: Apple Mail (2.1244.3) Cc: dane@ietf.org Subject: Re: [dane] The Curse of The Same, was CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 12:46:07 -0000 On 9 aug 2011, at 11:18, bmanning@vacation.karoshi.com wrote: > this seems analogous to this particular configuration... >=20 > 53.0.0.127.in-addr.arpa. in ptr www.foo.com. > in ptr www.bar.com. Bill, are you suggesting that the TLS client should follow the PTR to = fetch security goo from hosts listed in the PTR RDATA? If so, what is = the use-case? jakob From bmanning@karoshi.com Tue Aug 9 08:29:53 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C49E721F8C6A for ; Tue, 9 Aug 2011 08:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.428 X-Spam-Level: X-Spam-Status: No, score=-6.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9SMHrbX4q5Hq for ; Tue, 9 Aug 2011 08:29:53 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id 4A3F221F8B90 for ; Tue, 9 Aug 2011 08:29:53 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id p79FULmw030395; Tue, 9 Aug 2011 15:30:21 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id p79FUIAa030394; Tue, 9 Aug 2011 15:30:18 GMT Date: Tue, 9 Aug 2011 15:30:18 +0000 From: bmanning@vacation.karoshi.com To: Jakob Schlyter Message-ID: <20110809153018.GB29903@vacation.karoshi.com.> References: <20110802001308.26792.qmail@joyce.lan> <20110809091841.GB29435@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: bmanning@vacation.karoshi.com, dane@ietf.org Subject: Re: [dane] The Curse of The Same, was CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 15:29:53 -0000 On Tue, Aug 09, 2011 at 02:46:26PM +0200, Jakob Schlyter wrote: > On 9 aug 2011, at 11:18, bmanning@vacation.karoshi.com wrote: > > > this seems analogous to this particular configuration... > > > > 53.0.0.127.in-addr.arpa. in ptr www.foo.com. > > in ptr www.bar.com. > > Bill, are you suggesting that the TLS client should follow the PTR to fetch security goo from hosts listed in the PTR RDATA? If so, what is the use-case? > that is a possibility - however more to the point, the -first- PTR encountered is used, regardless of other data present in the RRset. Would the same logic be used in the case of multiple TLSA RRs in an RRset? If not, and caching occurs, can I populate a cache w/ spurious TSLA RRs? /bill > > > jakob > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From paul.hoffman@vpnc.org Tue Aug 9 08:52:05 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9EFB21F8661 for ; Tue, 9 Aug 2011 08:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rk1Sz+I6jZNo for ; Tue, 9 Aug 2011 08:52:05 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6877321F865F for ; Tue, 9 Aug 2011 08:52:05 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p79FqCp9093909 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 9 Aug 2011 08:52:12 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <20110809153018.GB29903@vacation.karoshi.com.> Date: Tue, 9 Aug 2011 08:52:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <93FF7F49-84C3-4703-BA16-1D30214C9462@vpnc.org> References: <20110802001308.26792.qmail@joyce.lan> <20110809091841.GB29435@vacation.karoshi.com.> <20110809153018.GB29903@vacation.karoshi.com.> To: bmanning@vacation.karoshi.com X-Mailer: Apple Mail (2.1244.3) Cc: DANE WG Subject: Re: [dane] The Curse of The Same, was CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 15:52:06 -0000 On Aug 9, 2011, at 8:30 AM, bmanning@vacation.karoshi.com wrote: > On Tue, Aug 09, 2011 at 02:46:26PM +0200, Jakob Schlyter wrote: >> On 9 aug 2011, at 11:18, bmanning@vacation.karoshi.com wrote: >>=20 >>> this seems analogous to this particular configuration... >>>=20 >>> 53.0.0.127.in-addr.arpa. in ptr www.foo.com. >>> in ptr www.bar.com. >>=20 >> Bill, are you suggesting that the TLS client should follow the PTR to = fetch security goo from hosts listed in the PTR RDATA? If so, what is = the use-case? >>=20 >=20 > that is a possibility - however more to the point, the -first- = PTR encountered is > used, regardless of other data present in the RRset. Would the = same logic be used > in the case of multiple TLSA RRs in an RRset? If not, and = caching occurs, can I=20 > populate a cache w/ spurious TSLA RRs? When you say "can I populate...", do you mean "I" is the name owner or = an attacker. If you meant "an attacker", the answer is "no" because the = responses are protected by DNSSEC. If you meant "the name owner", then = sure they can. For example, when you are changing from one certificate = to another, you would probably want to put both TLSA records in the DNS. --Paul Hoffman From jakob@kirei.se Tue Aug 9 09:10:58 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B37B621F8C9A for ; Tue, 9 Aug 2011 09:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZjUOsUfhmZA6 for ; Tue, 9 Aug 2011 09:10:57 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id 527E021F8B78 for ; Tue, 9 Aug 2011 09:10:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=zxkDfmhcy6X6LLGV04sClGxhWYYsj3j7G529DFEcWvY=; b=inavw5gy9GB0VQbFLMJgJRgdMqFARiddE5pHX64+8ItPgCJpSJMO2iOxKkao5vh9svcqUyJD6ZNqQ AtlaW2Kr8NE9gV4id2JUZ+VqkZBukrJKW+Oo0nYy2Yp/Gm0HGJIYeYAzMdVr5Mq6VYEdnGZ0qYL80S tmxcOYhaVcjAPVUU= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Tue, 9 Aug 2011 18:11:24 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: <20110809153018.GB29903@vacation.karoshi.com.> Date: Tue, 9 Aug 2011 18:11:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3799032F-F71C-46A7-9981-6D72F76010DC@kirei.se> References: <20110802001308.26792.qmail@joyce.lan> <20110809091841.GB29435@vacation.karoshi.com.> <20110809153018.GB29903@vacation.karoshi.com.> To: bmanning@vacation.karoshi.com X-Mailer: Apple Mail (2.1244.3) Cc: dane@ietf.org Subject: Re: [dane] The Curse of The Same, was CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 16:10:58 -0000 On 9 aug 2011, at 17:30, bmanning@vacation.karoshi.com wrote: > On Tue, Aug 09, 2011 at 02:46:26PM +0200, Jakob Schlyter wrote: >> On 9 aug 2011, at 11:18, bmanning@vacation.karoshi.com wrote: >>=20 >>> this seems analogous to this particular configuration... >>>=20 >>> 53.0.0.127.in-addr.arpa. in ptr www.foo.com. >>> in ptr www.bar.com. >>=20 >> Bill, are you suggesting that the TLS client should follow the PTR to = fetch security goo from hosts listed in the PTR RDATA? If so, what is = the use-case? >>=20 >=20 > that is a possibility - however more to the point, the -first- = PTR encountered is > used, regardless of other data present in the RRset. Would the = same logic be used > in the case of multiple TLSA RRs in an RRset? If not, and = caching occurs, can I=20 > populate a cache w/ spurious TSLA RRs? There is nothing wrong with multiple TLSA records - the current protocol = specification says that the certificate association is valid as long as = any of the listed associations (TLSA RRs) matches (and, of course, = validates). jakob From bmanning@karoshi.com Tue Aug 9 09:30:52 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87C7421F8CE1 for ; Tue, 9 Aug 2011 09:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.439 X-Spam-Level: X-Spam-Status: No, score=-6.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLAhjAGCI3QN for ; Tue, 9 Aug 2011 09:30:52 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id 00C3A21F8CE0 for ; Tue, 9 Aug 2011 09:30:51 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id p79GVKmw030743; Tue, 9 Aug 2011 16:31:21 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id p79GVKcw030742; Tue, 9 Aug 2011 16:31:20 GMT Date: Tue, 9 Aug 2011 16:31:20 +0000 From: bmanning@vacation.karoshi.com To: Jakob Schlyter Message-ID: <20110809163120.GF29903@vacation.karoshi.com.> References: <20110802001308.26792.qmail@joyce.lan> <20110809091841.GB29435@vacation.karoshi.com.> <20110809153018.GB29903@vacation.karoshi.com.> <3799032F-F71C-46A7-9981-6D72F76010DC@kirei.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3799032F-F71C-46A7-9981-6D72F76010DC@kirei.se> User-Agent: Mutt/1.4.1i Cc: bmanning@vacation.karoshi.com, dane@ietf.org Subject: Re: [dane] The Curse of The Same, was CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 16:30:52 -0000 On Tue, Aug 09, 2011 at 06:11:23PM +0200, Jakob Schlyter wrote: > On 9 aug 2011, at 17:30, bmanning@vacation.karoshi.com wrote: > > > On Tue, Aug 09, 2011 at 02:46:26PM +0200, Jakob Schlyter wrote: > >> On 9 aug 2011, at 11:18, bmanning@vacation.karoshi.com wrote: > >> > >>> this seems analogous to this particular configuration... > >>> > >>> 53.0.0.127.in-addr.arpa. in ptr www.foo.com. > >>> in ptr www.bar.com. > >> > >> Bill, are you suggesting that the TLS client should follow the PTR to fetch security goo from hosts listed in the PTR RDATA? If so, what is the use-case? > >> > > > > that is a possibility - however more to the point, the -first- PTR encountered is > > used, regardless of other data present in the RRset. Would the same logic be used > > in the case of multiple TLSA RRs in an RRset? If not, and caching occurs, can I > > populate a cache w/ spurious TSLA RRs? > > There is nothing wrong with multiple TLSA records - the current protocol specification says that the certificate association is valid as long as any of the listed associations (TLSA RRs) matches (and, of course, validates). ok... then plz clarify for me - since it seems to be an emergent property from other threads - can TLSA RRs be queried/matched as individual RRs? e.g. can I "walk" a TLSA "chain" independently of normal namespace queries? (the following CNAMES, chaining, et.al.) which, if true, seems to fly in the face of "atomic" RRsets. /bill > > jakob > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From paul.hoffman@vpnc.org Tue Aug 9 09:41:16 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E52BC21F8CD0 for ; Tue, 9 Aug 2011 09:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0B49zwRkNzos for ; Tue, 9 Aug 2011 09:41:16 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 4F86021F8CC4 for ; Tue, 9 Aug 2011 09:41:16 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p79GfMUZ096363 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 9 Aug 2011 09:41:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <20110809163120.GF29903@vacation.karoshi.com.> Date: Tue, 9 Aug 2011 09:41:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <59491739-46DD-4D52-9264-F769F14863A7@vpnc.org> References: <20110802001308.26792.qmail@joyce.lan> <20110809091841.GB29435@vacation.karoshi.com.> <20110809153018.GB29903@vacation.karoshi.com.> <3799032F-F71C-46A7-9981-6D72F76010DC@kirei.se> <20110809163120.GF29903@vacation.karoshi.com.> To: bmanning@vacation.karoshi.com X-Mailer: Apple Mail (2.1244.3) Cc: dane@ietf.org Subject: Re: [dane] The Curse of The Same, was CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 16:41:17 -0000 On Aug 9, 2011, at 9:31 AM, bmanning@vacation.karoshi.com wrote: > On Tue, Aug 09, 2011 at 06:11:23PM +0200, Jakob Schlyter wrote: >> On 9 aug 2011, at 17:30, bmanning@vacation.karoshi.com wrote: >>=20 >>> On Tue, Aug 09, 2011 at 02:46:26PM +0200, Jakob Schlyter wrote: >>>> On 9 aug 2011, at 11:18, bmanning@vacation.karoshi.com wrote: >>>>=20 >>>>> this seems analogous to this particular configuration... >>>>>=20 >>>>> 53.0.0.127.in-addr.arpa. in ptr www.foo.com. >>>>> in ptr www.bar.com. >>>>=20 >>>> Bill, are you suggesting that the TLS client should follow the PTR = to fetch security goo from hosts listed in the PTR RDATA? If so, what = is the use-case? >>>>=20 >>>=20 >>> that is a possibility - however more to the point, the -first- = PTR encountered is >>> used, regardless of other data present in the RRset. Would the = same logic be used >>> in the case of multiple TLSA RRs in an RRset? If not, and = caching occurs, can I=20 >>> populate a cache w/ spurious TSLA RRs? >>=20 >> There is nothing wrong with multiple TLSA records - the current = protocol specification says that the certificate association is valid as = long as any of the listed associations (TLSA RRs) matches (and, of = course, validates). >=20 > ok... then plz clarify for me - since it seems to be an = emergent property > from other threads - can TLSA RRs be queried/matched as = individual RRs? =20 Absolutely. That is how they are specified in the current draft. > e.g. can I "walk" a TLSA "chain" independently of normal = namespace queries? There is no "TLSA 'chain'". The TLSA record does not refer to other DNS = records. > (the following CNAMES, chaining, et.al.) which, if true, seems = to fly in the=20 > face of "atomic" RRsets. The "other threads" are proposing a change to the normal DNS rules, = specifically for for the TLSA RR; the current document uses the normal = DNS rules. Does that clarify? --Paul Hoffman From bmanning@karoshi.com Tue Aug 9 10:02:38 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F48B21F8B44 for ; Tue, 9 Aug 2011 10:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.448 X-Spam-Level: X-Spam-Status: No, score=-6.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7ICPF5pMemj for ; Tue, 9 Aug 2011 10:02:38 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id A172F21F8A6C for ; Tue, 9 Aug 2011 10:02:37 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id p79H36mw030826; Tue, 9 Aug 2011 17:03:06 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id p79H3657030825; Tue, 9 Aug 2011 17:03:06 GMT Date: Tue, 9 Aug 2011 17:03:06 +0000 From: bmanning@vacation.karoshi.com To: Paul Hoffman Message-ID: <20110809170306.GG29903@vacation.karoshi.com.> References: <20110802001308.26792.qmail@joyce.lan> <20110809091841.GB29435@vacation.karoshi.com.> <20110809153018.GB29903@vacation.karoshi.com.> <3799032F-F71C-46A7-9981-6D72F76010DC@kirei.se> <20110809163120.GF29903@vacation.karoshi.com.> <59491739-46DD-4D52-9264-F769F14863A7@vpnc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <59491739-46DD-4D52-9264-F769F14863A7@vpnc.org> User-Agent: Mutt/1.4.1i Cc: bmanning@vacation.karoshi.com, dane@ietf.org Subject: Re: [dane] The Curse of The Same, was CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 17:02:38 -0000 > >>> that is a possibility - however more to the point, the -first- PTR encountered is > >>> used, regardless of other data present in the RRset. Would the same logic be used > >>> in the case of multiple TLSA RRs in an RRset? If not, and caching occurs, can I > >>> populate a cache w/ spurious TSLA RRs? > >> > >> There is nothing wrong with multiple TLSA records - the current protocol specification says that the certificate association is valid as long as any of the listed associations (TLSA RRs) matches (and, of course, validates). > > > > ok... then plz clarify for me - since it seems to be an emergent property > > from other threads - can TLSA RRs be queried/matched as individual RRs? > > Absolutely. That is how they are specified in the current draft. > > > (the following CNAMES, chaining, et.al.) which, if true, seems to fly in the > > face of "atomic" RRsets. > > The "other threads" are proposing a change to the normal DNS rules, specifically for for the TLSA RR; the current document uses the normal DNS rules. Does that clarify? > > --Paul Hoffman Goodie! a valuable attack vector is re-opened! (normal DNS rules in a DNSSEC enabled environment are pretty clear that while you can query individual RRs, you get the entire RRset back) if I can push/pull TLSA RRs into/outof cache -independently- of the associated RRset, then we have the cache manipulation problem all over again - in spades. /bill From jakob@kirei.se Tue Aug 9 10:18:46 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0CA321F8CC4 for ; Tue, 9 Aug 2011 10:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.509 X-Spam-Level: X-Spam-Status: No, score=-0.509 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EaLCwlprvNrZ for ; Tue, 9 Aug 2011 10:18:46 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id 96A3D21F8CD2 for ; Tue, 9 Aug 2011 10:18:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=sX7kZoglI/6eyBFXvdeYV/SKfIGs9fS0UxQTzrZZ2OI=; b=syQJFfmDcsNI8LdASnVmbZoPsacBFgNnM/gWLOS6dIr4LUAjdtFVPpef3VCK10QDF5z6T/uNitjft Bu6OOgIYSK4IiGG7qA4gYWZtzxIPJkbflBTOsxV/6LG/f3vAhP5U+vSQ4qwbFdvS9f/nbxMNdoW2Tp +V9d1XUjseOZni0U= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Tue, 9 Aug 2011 19:19:12 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: <20110809170306.GG29903@vacation.karoshi.com.> Date: Tue, 9 Aug 2011 19:19:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1E0D2EA6-7C54-4E78-B3D7-FE19A99EC256@kirei.se> References: <20110802001308.26792.qmail@joyce.lan> <20110809091841.GB29435@vacation.karoshi.com.> <20110809153018.GB29903@vacation.karoshi.com.> <3799032F-F71C-46A7-9981-6D72F76010DC@kirei.se> <20110809163120.GF29903@vacation.karoshi.com.> <59491739-46DD-4D52-9264-F769F14863A7@vpnc.org> <20110809170306.GG29903@vacation.karoshi.com.> To: bmanning@vacation.karoshi.com X-Mailer: Apple Mail (2.1244.3) Cc: Paul Hoffman , dane@ietf.org Subject: Re: [dane] The Curse of The Same, was CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 17:18:46 -0000 On 9 aug 2011, at 19:03, bmanning@vacation.karoshi.com wrote: > Goodie! a valuable attack vector is re-opened! =20 > (normal DNS rules in a DNSSEC enabled environment are pretty = clear > that while you can query individual RRs, you get the entire = RRset back) >=20 > if I can push/pull TLSA RRs into/outof cache -independently- of = the=20 > associated RRset, then we have the cache manipulation problem = all over > again - in spades. Yes, if you can compromise the cache - and bypass DNSSEC validation - = you are toast. Please describe how this is a new problem. jakob From hallam@gmail.com Tue Aug 9 10:35:47 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAEBA11E80CE for ; Tue, 9 Aug 2011 10:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.505 X-Spam-Level: X-Spam-Status: No, score=-3.505 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UPvl+304rsNV for ; Tue, 9 Aug 2011 10:35:46 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA4311E809C for ; Tue, 9 Aug 2011 10:35:46 -0700 (PDT) Received: by gwb20 with SMTP id 20so177823gwb.31 for ; Tue, 09 Aug 2011 10:36:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/Mw+7yQAqHBzRgj7/JmIQL+8oFvRy0fDl//8K+9H1cs=; b=Z/cUHtuyzIhoaM15LgSBsrPDEvYlJ/O3+kY2JNLsHZ2qiV25Rj7uw25RcTKIHd9laB MCbsfDyRjhpu+EcqvR/yZf2NUT12Y4wp2pw+EvAeLFvjnUy1gTm3l4rztLAQbuRICuo9 gvQsL1A161h1AtBXu1+LM/+m8UUJNdmUC7afE= MIME-Version: 1.0 Received: by 10.100.254.3 with SMTP id b3mr1436994ani.116.1312911375505; Tue, 09 Aug 2011 10:36:15 -0700 (PDT) Received: by 10.100.34.3 with HTTP; Tue, 9 Aug 2011 10:36:15 -0700 (PDT) In-Reply-To: <59491739-46DD-4D52-9264-F769F14863A7@vpnc.org> References: <20110802001308.26792.qmail@joyce.lan> <20110809091841.GB29435@vacation.karoshi.com.> <20110809153018.GB29903@vacation.karoshi.com.> <3799032F-F71C-46A7-9981-6D72F76010DC@kirei.se> <20110809163120.GF29903@vacation.karoshi.com.> <59491739-46DD-4D52-9264-F769F14863A7@vpnc.org> Date: Tue, 9 Aug 2011 13:36:15 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=00163691ff5128996004aa1600e2 Cc: bmanning@vacation.karoshi.com, dane@ietf.org Subject: Re: [dane] The Curse of The Same, was CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 17:35:47 -0000 --00163691ff5128996004aa1600e2 Content-Type: text/plain; charset=ISO-8859-1 Again, stop misrepresenting the proposal. No changes to the normal DNS rules We are not going to arrive at consensus if people misrepresent proposals. On Tue, Aug 9, 2011 at 12:41 PM, Paul Hoffman wrote: > On Aug 9, 2011, at 9:31 AM, bmanning@vacation.karoshi.com wrote: > > > On Tue, Aug 09, 2011 at 06:11:23PM +0200, Jakob Schlyter wrote: > >> On 9 aug 2011, at 17:30, bmanning@vacation.karoshi.com wrote: > >> > >>> On Tue, Aug 09, 2011 at 02:46:26PM +0200, Jakob Schlyter wrote: > >>>> On 9 aug 2011, at 11:18, bmanning@vacation.karoshi.com wrote: > >>>> > >>>>> this seems analogous to this particular configuration... > >>>>> > >>>>> 53.0.0.127.in-addr.arpa. in ptr www.foo.com. > >>>>> in ptr www.bar.com. > >>>> > >>>> Bill, are you suggesting that the TLS client should follow the PTR to > fetch security goo from hosts listed in the PTR RDATA? If so, what is the > use-case? > >>>> > >>> > >>> that is a possibility - however more to the point, the -first- PTR > encountered is > >>> used, regardless of other data present in the RRset. Would the > same logic be used > >>> in the case of multiple TLSA RRs in an RRset? If not, and caching > occurs, can I > >>> populate a cache w/ spurious TSLA RRs? > >> > >> There is nothing wrong with multiple TLSA records - the current protocol > specification says that the certificate association is valid as long as any > of the listed associations (TLSA RRs) matches (and, of course, validates). > > > > ok... then plz clarify for me - since it seems to be an emergent > property > > from other threads - can TLSA RRs be queried/matched as individual > RRs? > > Absolutely. That is how they are specified in the current draft. > > > e.g. can I "walk" a TLSA "chain" independently of normal namespace > queries? > > There is no "TLSA 'chain'". The TLSA record does not refer to other DNS > records. > > > (the following CNAMES, chaining, et.al.) which, if true, seems to > fly in the > > face of "atomic" RRsets. > > > The "other threads" are proposing a change to the normal DNS rules, > specifically for for the TLSA RR; the current document uses the normal DNS > rules. Does that clarify? > > --Paul Hoffman > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > -- Website: http://hallambaker.com/ --00163691ff5128996004aa1600e2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Again, stop misrepresenting the proposal.

No changes to = the normal DNS rules


We are not goi= ng to arrive at consensus if people misrepresent proposals.


On Tue, Aug 9, 2011 at 12:41 PM, Paul Hoffma= n <paul.hoffm= an@vpnc.org> wrote:
On Aug 9, 2011, at 9:31 AM, bmanning@vacation.karoshi.com wrote:

> On Tue, Aug 09, 2011 at 06:11:23PM +0200, Jakob Schlyter wrote:
>> On 9 aug 2011, at 17:30, bmanning@vacation.karoshi.com wrote:
>>
>>> On Tue, Aug 09, 2011 at 02:46:26PM +0200, Jakob Schlyter wrote= :
>>>> On 9 aug 2011, at 11:18, bmanning@vacation.karoshi.com wrote:
>>>>
>>>>> =A0 this seems analogous to this particular configurat= ion...
>>>>>
>>>>> 53.0.0.127.in-addr.arpa. =A0 in ptr =A0www.foo.com.
>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0in ptr =A0<= a href=3D"http://www.bar.com" target=3D"_blank">www.bar.com.
>>>>
>>>> Bill, are you suggesting that the TLS client should follow= the PTR to fetch security goo from hosts listed in the PTR RDATA? =A0If so= , what is the use-case?
>>>>
>>>
>>> =A0 =A0 that is a possibility - however more to the point, the= -first- PTR encountered is
>>> =A0 =A0 used, regardless of other data present in the RRset. = =A0Would the same logic be used
>>> =A0 =A0 in the case of multiple TLSA RRs in an RRset? =A0If no= t, and caching occurs, can I
>>> =A0 =A0 populate a cache w/ spurious TSLA RRs?
>>
>> There is nothing wrong with multiple TLSA records - the current pr= otocol specification says that the certificate association is valid as long= as any of the listed associations (TLSA RRs) matches (and, of course, vali= dates).
>
> =A0 =A0 =A0 ok... =A0then plz clarify for me -= since it seems to be an emergent property
> =A0 =A0 =A0 from other threads - can TLSA RRs be queried/matched as in= dividual RRs?

Absolutely. That is how they are specified in the current draft.

> =A0 =A0 =A0 e.g. can I "walk" a TLSA "chain" indep= endently of normal namespace queries?

There is no "TLSA 'chain'". The TLSA record does no= t refer to other DNS records.

> =A0 =A0 =A0 (the following CNAMES, chaining, et.al.) =A0which, if true, seems to fly in the
> =A0 =A0 =A0 face of "atomic" RRsets.


The "other threads" are proposing a change to the normal DN= S rules, specifically for for the TLSA RR; the current document uses the no= rmal DNS rules. Does that clarify?

--Paul Hoffman

_______________________________________________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane



--
Website: http://hallambaker.com/

--00163691ff5128996004aa1600e2-- From paul@xelerance.com Tue Aug 9 10:44:56 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15B6B21F8B40 for ; Tue, 9 Aug 2011 10:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.546 X-Spam-Level: X-Spam-Status: No, score=-6.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKQDrxW40MGX for ; Tue, 9 Aug 2011 10:44:55 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id 75F4921F8B32 for ; Tue, 9 Aug 2011 10:44:55 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 92135C5D3; Tue, 9 Aug 2011 13:46:57 -0400 (EDT) Date: Tue, 9 Aug 2011 13:46:57 -0400 (EDT) From: Paul Wouters To: Jakob Schlyter In-Reply-To: <1E0D2EA6-7C54-4E78-B3D7-FE19A99EC256@kirei.se> Message-ID: References: <20110802001308.26792.qmail@joyce.lan> <20110809091841.GB29435@vacation.karoshi.com.> <20110809153018.GB29903@vacation.karoshi.com.> <3799032F-F71C-46A7-9981-6D72F76010DC@kirei.se> <20110809163120.GF29903@vacation.karoshi.com.> <59491739-46DD-4D52-9264-F769F14863A7@vpnc.org> <20110809170306.GG29903@vacation.karoshi.com.> <1E0D2EA6-7C54-4E78-B3D7-FE19A99EC256@kirei.se> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: bmanning@vacation.karoshi.com, Paul Hoffman , dane@ietf.org Subject: Re: [dane] The Curse of The Same, was CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 17:44:56 -0000 On Tue, 9 Aug 2011, Jakob Schlyter wrote: > On 9 aug 2011, at 19:03, bmanning@vacation.karoshi.com wrote: > >> Goodie! a valuable attack vector is re-opened! >> (normal DNS rules in a DNSSEC enabled environment are pretty clear >> that while you can query individual RRs, you get the entire RRset back) >> >> if I can push/pull TLSA RRs into/outof cache -independently- of the >> associated RRset, then we have the cache manipulation problem all over >> again - in spades. > > Yes, if you can compromise the cache - and bypass DNSSEC validation - you are toast. Please describe how this is a new problem. I think there is some confusion here, The RRSIG is over the RRset, not over the individual TLSA RRs. So you cannot pull one TLSA record from the RRset of TLSA records at _443._tcp.example.com. and have it validate. Paul From paul.hoffman@vpnc.org Tue Aug 9 11:23:51 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E624E21F8B6E for ; Tue, 9 Aug 2011 11:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E+cZ30CSgziw for ; Tue, 9 Aug 2011 11:23:51 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 49C9621F8B4F for ; Tue, 9 Aug 2011 11:23:51 -0700 (PDT) Received: from sn87.proper.com (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p79INqbB002376 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 9 Aug 2011 11:23:57 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <20110809170306.GG29903@vacation.karoshi.com.> Date: Tue, 9 Aug 2011 11:24:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <982C81F4-D45C-401F-B40A-807B9E8721D1@vpnc.org> References: <20110802001308.26792.qmail@joyce.lan> <20110809091841.GB29435@vacation.karoshi.com.> <20110809153018.GB29903@vacation.karoshi.com.> <3799032F-F71C-46A7-9981-6D72F76010DC@kirei.se> <20110809163120.GF29903@vacation.karoshi.com.> <59491739-46DD-4D52-9264-F769F14863A7@vpnc.org> <20110809170306.GG29903@vacation.karoshi.com.> To: bmanning@vacation.karoshi.com X-Mailer: Apple Mail (2.1244.3) Cc: dane@ietf.org Subject: Re: [dane] The Curse of The Same, was CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 18:23:52 -0000 On Aug 9, 2011, at 10:03 AM, bmanning@vacation.karoshi.com wrote: >>>>> that is a possibility - however more to the point, the -first- = PTR encountered is >>>>> used, regardless of other data present in the RRset. Would the = same logic be used >>>>> in the case of multiple TLSA RRs in an RRset? If not, and = caching occurs, can I=20 >>>>> populate a cache w/ spurious TSLA RRs? >>>>=20 >>>> There is nothing wrong with multiple TLSA records - the current = protocol specification says that the certificate association is valid as = long as any of the listed associations (TLSA RRs) matches (and, of = course, validates). >>>=20 >>> ok... then plz clarify for me - since it seems to be an = emergent property >>> from other threads - can TLSA RRs be queried/matched as = individual RRs? =20 >>=20 >> Absolutely. That is how they are specified in the current draft. >>=20 >>> (the following CNAMES, chaining, et.al.) which, if true, seems = to fly in the=20 >>> face of "atomic" RRsets. >>=20 >> The "other threads" are proposing a change to the normal DNS rules, = specifically for for the TLSA RR; the current document uses the normal = DNS rules. Does that clarify? >>=20 >> --Paul Hoffman >=20 > Goodie! a valuable attack vector is re-opened! =20 > (normal DNS rules in a DNSSEC enabled environment are pretty = clear > that while you can query individual RRs, you get the entire = RRset back) It looks like you misinterpreted my answer. You asked "can TLSA RRs be = queried/matched as individual RRs?" and I replied that they could be = matched as individual RRs. There is, of course, no way to query them as = individual RRs. If that is unclear in the spec, by all means point out = where so that Jakob and I can clarify there. > if I can push/pull TLSA RRs into/outof cache -independently- of = the=20 > associated RRset, then we have the cache manipulation problem = all over > again - in spades. But we don't, fortunately.=20 --Paul Hoffman From ondrej.sury@nic.cz Tue Aug 9 13:43:59 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7486321F8C93 for ; Tue, 9 Aug 2011 13:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.972 X-Spam-Level: X-Spam-Status: No, score=-0.972 tagged_above=-999 required=5 tests=[AWL=0.727, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8k2+v+zVTAV for ; Tue, 9 Aug 2011 13:43:58 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 9C11C11E80FF for ; Tue, 9 Aug 2011 13:43:57 -0700 (PDT) Received: from [10.0.0.12] (247.78.broadband13.iol.cz [90.180.78.247]) by mail.nic.cz (Postfix) with ESMTPSA id C4FD92A040B for ; Tue, 9 Aug 2011 22:44:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1312922664; bh=jUvKHve8OfsNfMI/O5NUKi+tSV2BYMr6aNRQ1jLQV3U=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Date: Message-Id:To:Mime-Version; b=iHelAD+UU0MAGXxp6A2AVeJBR7PGHPNp/ZrsWqkPEJZD+uGpEU5K2jnjqyBsTlkna nOI7v4kTvf9eXGdBWUdQvfdPJc2QbiCV9Vckw0ZftHy5CsL5okaZQAt6dhJSsmiwjp an4PY7QHru+ckOt+WHFyxuRrnu5uA0oBQlIbeZ7s= From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Aug 2011 22:44:24 +0200 Message-Id: <6B5F4F0A-82F2-4911-81B6-F923D7529E4A@nic.cz> To: dane@ietf.org Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: [dane] Call for consensus for CNAME X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 20:43:59 -0000 Hi, I hereby make a call for a consensus on the CNAME issue. I am specifically asking you if you agree with current contents of DANE protocol draft, which says that TLSA queries and answers follows normal DNS resolution. Please respond just with +1/-1, we already had a lengthy discussion on the subject and it doesn't seem to develop anywhere in last few days. If you really feel an urge to discuss it again, please read the threads from last two weeks on the subject and make an follow-up there, so we can keep this thread loud and clear. And since we already had a discussion on the topic I would like to close this issue next monday.=09 Thanks, -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From matt@mattmccutchen.net Tue Aug 9 13:49:44 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6737221F8A7E for ; Tue, 9 Aug 2011 13:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jsKNs75sEN-G for ; Tue, 9 Aug 2011 13:49:43 -0700 (PDT) Received: from homiemail-a4.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id D1D6921F89C2 for ; Tue, 9 Aug 2011 13:49:43 -0700 (PDT) Received: from homiemail-a4.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a4.g.dreamhost.com (Postfix) with ESMTP id 6590251C063 for ; Tue, 9 Aug 2011 13:50:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=W33msUsF04PYgX5HoGTfstK1GxZnIpSTk0EWrn5wYgZ jH5etpBad7x0lcvG5dBKj/DGu0Q/ObI9V5min2mwd7SFz4vEZxlpCwTPoZq1VIvL fTqq8HigwCusUOiGE/uNhcNlWB+ilxyLH8Xb97IOkySsDMsvV7EbvPImPacJiq/c = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=2Gfh+vOFnYdWM0r8UrnJ7s0aTYk=; b=u1t8P5OOP0 F4//p81RNcxQag8ZNTlzq8y9b380ykrrBwtOWSxN7ad71cT+arf4fsqhtmjSSFgJ jQRBBAH0kEZAnqGAd5OkGWMqCnDLARgZWdxghSeSzosfSkDMKXddiyRC4lK8fUaP 87zYB2EDYkEoVF9v8n227k2bAjWUrn+lY= Received: from [192.168.1.39] (pool-96-231-14-217.washdc.east.verizon.net [96.231.14.217]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a4.g.dreamhost.com (Postfix) with ESMTPSA id 119B351C07C for ; Tue, 9 Aug 2011 13:50:12 -0700 (PDT) From: Matt McCutchen To: dane@ietf.org In-Reply-To: <6B5F4F0A-82F2-4911-81B6-F923D7529E4A@nic.cz> References: <6B5F4F0A-82F2-4911-81B6-F923D7529E4A@nic.cz> Content-Type: text/plain; charset="UTF-8" Date: Tue, 09 Aug 2011 16:50:09 -0400 Message-ID: <1312923009.2122.16.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: quoted-printable Subject: Re: [dane] Call for consensus for CNAME X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 20:49:44 -0000 On Tue, 2011-08-09 at 22:44 +0200, Ond=C5=99ej Sur=C3=BD wrote: > I hereby make a call for a consensus on the CNAME issue. >=20 > I am specifically asking you if you agree with current > contents of DANE protocol draft, which says that TLSA > queries and answers follows normal DNS resolution. >=20 > Please respond just with +1/-1, we already had a lengthy > discussion on the subject and it doesn't seem to develop > anywhere in last few days. -1. FYI, I am working on a new proposed solution and plan to post it (in a separate thread) by the end of the week. --=20 Matt From jakob@kirei.se Tue Aug 9 13:50:42 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B74BE21F8B02 for ; Tue, 9 Aug 2011 13:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.371 X-Spam-Level: X-Spam-Status: No, score=-0.371 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lMM6w3x-uFKu for ; Tue, 9 Aug 2011 13:50:42 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id 8B1AE21F8AEE for ; Tue, 9 Aug 2011 13:50:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=yubnqvOxH5wghrCpYkYGbKsY6Wx8HEC3NSs/FNvj738=; b=JH8/K9MBWdQVG18gLr0NvMrmqpdszZzqF3jqyskJU+yxUQUcYrfA7R1EXxkE2YAVwI+fdR2uuh9+X vc7O4Ln9stBk4p0R9DjAs80QMrxiy2lfW0CP4MZVAtcn9eJnz03gJD743TDnuWAn31rhrQmjUC70+Y ipwntW+iriCQR7EI= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Tue, 9 Aug 2011 22:51:09 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: <6B5F4F0A-82F2-4911-81B6-F923D7529E4A@nic.cz> Date: Tue, 9 Aug 2011 22:51:07 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <6B5F4F0A-82F2-4911-81B6-F923D7529E4A@nic.cz> To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= X-Mailer: Apple Mail (2.1244.3) Cc: dane@ietf.org Subject: Re: [dane] Call for consensus for CNAME X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 20:50:42 -0000 +1 From matthijs@nlnetlabs.nl Tue Aug 9 13:55:47 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2356321F8CB5 for ; Tue, 9 Aug 2011 13:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id If7Esq1+RZDY for ; Tue, 9 Aug 2011 13:55:46 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B80121F8CA2 for ; Tue, 9 Aug 2011 13:55:46 -0700 (PDT) Received: from [192.168.178.22] ([83.160.139.153]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id p79KuCXZ087017 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 9 Aug 2011 22:56:13 +0200 (CEST) (envelope-from matthijs@nlnetlabs.nl) Message-ID: <4E419EEC.4090001@nlnetlabs.nl> Date: Tue, 09 Aug 2011 22:56:12 +0200 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: dane@ietf.org References: <6B5F4F0A-82F2-4911-81B6-F923D7529E4A@nic.cz> In-Reply-To: <6B5F4F0A-82F2-4911-81B6-F923D7529E4A@nic.cz> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [213.154.224.1]); Tue, 09 Aug 2011 22:56:13 +0200 (CEST) Subject: Re: [dane] Call for consensus for CNAME X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 20:55:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 +1 On 08/09/2011 10:44 PM, Ondřej Surý wrote: > Hi, > > I hereby make a call for a consensus on the CNAME issue. > > I am specifically asking you if you agree with current > contents of DANE protocol draft, which says that TLSA > queries and answers follows normal DNS resolution. > > Please respond just with +1/-1, we already had a lengthy > discussion on the subject and it doesn't seem to develop > anywhere in last few days. If you really feel an urge > to discuss it again, please read the threads from last > two weeks on the subject and make an follow-up there, > so we can keep this thread loud and clear. > > And since we already had a discussion on the topic I would > like to close this issue next monday. > > Thanks, > -- > Ondřej Surý > vedoucí výzkumu/Head of R&D department > ------------------------------------------- > CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC > Americka 23, 120 00 Praha 2, Czech Republic > mailto:ondrej.sury@nic.cz http://nic.cz/ > tel:+420.222745110 fax:+420.222745112 > ------------------------------------------- > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOQZ7sAAoJEA8yVCPsQCW5PNQIAMbcom+0VZIC2lUZx4hpQvJb SaKmWLE014ipG5YuHH/IzlCUlrSik/eiHwo2CsKtQvzSDHyH4C6+gfjvTQdsfBfX LJ4ENjShsFIUilPCzvuy+nHiB2BMRRIcsjNAmeFAQyQvtYCmuLImpBWL3hPE4DE9 DK9rUstOzkq+aKEcTRkEqOt2vxva3xt2MjkNHmTwEvcNRNJQ4psXufSiM2rO4Fk3 s+AQgHr9kf0o+OrkioxG9hTK3Gf6spKyL5BkDewYO4KoIeqDV+Pl8HRLZ1N0UO1C 2+G6++91JKu5oUqlygNubFExiQxnfvGIUx9pP4hsuCCOCzgDzMSTJ2gG0SPmO3c= =dwtg -----END PGP SIGNATURE----- From matt@mattmccutchen.net Tue Aug 9 14:05:30 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6F221F8B82 for ; Tue, 9 Aug 2011 14:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.404 X-Spam-Level: X-Spam-Status: No, score=-2.404 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NgjrhMPBrgXY for ; Tue, 9 Aug 2011 14:05:29 -0700 (PDT) Received: from homiemail-a37.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id E411A21F8B81 for ; Tue, 9 Aug 2011 14:05:29 -0700 (PDT) Received: from homiemail-a37.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a37.g.dreamhost.com (Postfix) with ESMTP id 79AAC20806C for ; Tue, 9 Aug 2011 14:05:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=S7HdgPyZi3ENQI71sYxOtDEkwEWnCymresB7oR6j8bT gYlpOQTrvS9x7KwpXHoqI3idu7UJWNM93dLtdvThBjFQxoHvZMZORLzaeYuVYEXi XK/Onw6J+NMyTDiOOH8Fd0UuixZmZGAfnx04I28hrFfBVl0bpMl9jlBMquQad92g = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=HaEbVaI4Ne16fvc6MjXhA+oK07A=; b=g8wUNpsHEa cRevkhIqaAq+ueON+jljm6aac+xUj82PZuB+ZfRmkK+Ovh4PhXTnoqstHCktUVXt 0+PyCUGpk9k/cfEFmCWWB0QaYsyWpwGHQbHDgEvzSRFJ0FI0+HxSdPq6Sj+hyFFo Di1AdwJtsH2EO/ypTunhc6FLVwNyamf34= Received: from [192.168.1.39] (pool-96-231-14-217.washdc.east.verizon.net [96.231.14.217]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a37.g.dreamhost.com (Postfix) with ESMTPSA id 0DCBC208063 for ; Tue, 9 Aug 2011 14:05:58 -0700 (PDT) From: Matt McCutchen To: dane@ietf.org In-Reply-To: <1312923009.2122.16.camel@localhost> References: <6B5F4F0A-82F2-4911-81B6-F923D7529E4A@nic.cz> <1312923009.2122.16.camel@localhost> Content-Type: text/plain; charset="UTF-8" Date: Tue, 09 Aug 2011 17:05:57 -0400 Message-ID: <1312923957.2122.18.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: quoted-printable Subject: Re: [dane] Call for consensus for CNAME X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 21:05:30 -0000 On Tue, 2011-08-09 at 16:50 -0400, Matt McCutchen wrote: > On Tue, 2011-08-09 at 22:44 +0200, Ond=C5=99ej Sur=C3=BD wrote: > > I hereby make a call for a consensus on the CNAME issue. > >=20 > > I am specifically asking you if you agree with current > > contents of DANE protocol draft, which says that TLSA > > queries and answers follows normal DNS resolution. > >=20 > > Please respond just with +1/-1, we already had a lengthy > > discussion on the subject and it doesn't seem to develop > > anywhere in last few days. >=20 > -1. FYI, I am working on a new proposed solution and plan to post it > (in a separate thread) by the end of the week. I should qualify this: +1 to NOT specifying a special interaction between CNAME and TLSA. -1 to closing ticket #24 (I have a different proposal to make). --=20 Matt From ondrej.sury@nic.cz Tue Aug 9 14:12:19 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA1D21F8C77 for ; Tue, 9 Aug 2011 14:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.117 X-Spam-Level: X-Spam-Status: No, score=-1.117 tagged_above=-999 required=5 tests=[AWL=0.582, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qr03wzFCe1C9 for ; Tue, 9 Aug 2011 14:12:18 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 940A321F8C75 for ; Tue, 9 Aug 2011 14:12:18 -0700 (PDT) Received: from [10.0.0.12] (247.78.broadband13.iol.cz [90.180.78.247]) by mail.nic.cz (Postfix) with ESMTPSA id B7A6B2A2C64; Tue, 9 Aug 2011 23:12:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1312924367; bh=5hLOHj+9E92hrOfX22AxUxJNfbnPeaFDWkjHDRcJs3g=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=pcNlDKRq6y7T9xjsDGkXtGk/ex+IsoTljxusZyS3xMWp4D6YgPiw3Y7bMj2Qc1MFy /YHyDu16gt2CDTYrTnvChxU0xVB8j5gdpsBkxHUgRP6gN5HsBvrfvcv7jmt9rUVcpX 4VVXtcBupSdfOvlFk/Ef/+bZRfYQmKYu2evk4MPw= Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <1312923957.2122.18.camel@localhost> Date: Tue, 9 Aug 2011 23:12:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3CE7EC5A-4A66-41A1-AD61-436956CBF540@nic.cz> References: <6B5F4F0A-82F2-4911-81B6-F923D7529E4A@nic.cz> <1312923009.2122.16.camel@localhost> <1312923957.2122.18.camel@localhost> To: Matt McCutchen X-Mailer: Apple Mail (2.1244.3) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane@ietf.org Subject: Re: [dane] Call for consensus for CNAME X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 21:12:19 -0000 On 9. 8. 2011, at 23:05, Matt McCutchen wrote: > On Tue, 2011-08-09 at 16:50 -0400, Matt McCutchen wrote: >> On Tue, 2011-08-09 at 22:44 +0200, Ond=C5=99ej Sur=C3=BD wrote: >>> I hereby make a call for a consensus on the CNAME issue. >>>=20 >>> I am specifically asking you if you agree with current >>> contents of DANE protocol draft, which says that TLSA >>> queries and answers follows normal DNS resolution. >>>=20 >>> Please respond just with +1/-1, we already had a lengthy >>> discussion on the subject and it doesn't seem to develop >>> anywhere in last few days. >>=20 >> -1. FYI, I am working on a new proposed solution and plan to post it >> (in a separate thread) by the end of the week. >=20 > I should qualify this: >=20 > +1 to NOT specifying a special interaction between CNAME and TLSA. >=20 > -1 to closing ticket #24 (I have a different proposal to make). To clarify - this call is about closing issue #24. Sorry for not mentioning it in the call. O. -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From paul.hoffman@vpnc.org Tue Aug 9 14:19:08 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 913EB5E8016 for ; Tue, 9 Aug 2011 14:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.382 X-Spam-Level: X-Spam-Status: No, score=-102.382 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRQuDRYu08Et for ; Tue, 9 Aug 2011 14:19:08 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 198B35E8010 for ; Tue, 9 Aug 2011 14:19:08 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p79LJF6P010189 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 9 Aug 2011 14:19:15 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=utf-8 From: Paul Hoffman In-Reply-To: <6B5F4F0A-82F2-4911-81B6-F923D7529E4A@nic.cz> Date: Tue, 9 Aug 2011 14:19:36 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3DD60FC8-69AD-4F09-929E-7343390AF418@vpnc.org> References: <6B5F4F0A-82F2-4911-81B6-F923D7529E4A@nic.cz> To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= X-Mailer: Apple Mail (2.1244.3) Cc: dane@ietf.org Subject: Re: [dane] Call for consensus for CNAME X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 21:19:08 -0000 On Aug 9, 2011, at 1:44 PM, Ond=C5=99ej Sur=C3=BD wrote: > Hi, >=20 > I hereby make a call for a consensus on the CNAME issue. >=20 > I am specifically asking you if you agree with current > contents of DANE protocol draft, which says that TLSA > queries and answers follows normal DNS resolution. >=20 > Please respond just with +1/-1, we already had a lengthy > discussion on the subject and it doesn't seem to develop > anywhere in last few days. If you really feel an urge > to discuss it again, please read the threads from last > two weeks on the subject and make an follow-up there, > so we can keep this thread loud and clear. >=20 > And since we already had a discussion on the topic I would > like to close this issue next monday.=09 +1 --Paul Hoffman From hallam@gmail.com Tue Aug 9 14:20:23 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B53745E802B for ; Tue, 9 Aug 2011 14:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.06 X-Spam-Level: X-Spam-Status: No, score=-3.06 tagged_above=-999 required=5 tests=[AWL=-0.362, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pGd4j0ExcahF for ; Tue, 9 Aug 2011 14:20:23 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id E99115E8023 for ; Tue, 9 Aug 2011 14:20:22 -0700 (PDT) Received: by gwb20 with SMTP id 20so333561gwb.31 for ; Tue, 09 Aug 2011 14:20:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=A/b/4qdFoAVvq1WK4WPpd9YWn+vSLJ//1GFBqEZ1OiU=; b=pBeOs0XSFg2dGIhzi4MLA5PFC5oiWn8pnRygPzY8SJPQI8T9HIGd1VK6A1OSMuz0vG bF1ReRSO8/Ni2OWkHkKU4sRfN0O7DybiIFoewhDtNaPEXn7VN55haQyInbfm5Zp0IYVK +tN5tyR/EAtzm9u7ijU4hxnap0kHUpkpJu7R0= MIME-Version: 1.0 Received: by 10.100.254.3 with SMTP id b3mr1682845ani.116.1312924852196; Tue, 09 Aug 2011 14:20:52 -0700 (PDT) Received: by 10.100.34.3 with HTTP; Tue, 9 Aug 2011 14:20:52 -0700 (PDT) In-Reply-To: <6B5F4F0A-82F2-4911-81B6-F923D7529E4A@nic.cz> References: <6B5F4F0A-82F2-4911-81B6-F923D7529E4A@nic.cz> Date: Tue, 9 Aug 2011 17:20:52 -0400 Message-ID: From: Phillip Hallam-Baker To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Content-Type: multipart/alternative; boundary=00163691ff516e960504aa19236c Cc: dane@ietf.org Subject: Re: [dane] Call for consensus for CNAME X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 21:20:23 -0000 --00163691ff516e960504aa19236c Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable -1 On Tue, Aug 9, 2011 at 4:44 PM, Ond=F8ej Sur=FD wrote: > Hi, > > I hereby make a call for a consensus on the CNAME issue. > > I am specifically asking you if you agree with current > contents of DANE protocol draft, which says that TLSA > queries and answers follows normal DNS resolution. > > Please respond just with +1/-1, we already had a lengthy > discussion on the subject and it doesn't seem to develop > anywhere in last few days. If you really feel an urge > to discuss it again, please read the threads from last > two weeks on the subject and make an follow-up there, > so we can keep this thread loud and clear. > > And since we already had a discussion on the topic I would > like to close this issue next monday. > > Thanks, > -- > Ond=F8ej Sur=FD > vedouc=ED v=FDzkumu/Head of R&D department > ------------------------------------------- > CZ.NIC, z.s.p.o. -- Laborato=F8e CZ.NIC > Americka 23, 120 00 Praha 2, Czech Republic > mailto:ondrej.sury@nic.cz http://nic.cz/ > tel:+420.222745110 fax:+420.222745112 > ------------------------------------------- > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > --=20 Website: http://hallambaker.com/ --00163691ff516e960504aa19236c Content-Type: text/html; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable -1

On Tue, Aug 9, 2011 at 4:44 PM, Ond=F8= ej Sur=FD <ondre= j.sury@nic.cz> wrote:
Hi,

I hereby make a call for a consensus on the CNAME issue.

I am specifically asking you if you agree with current
contents of DANE protocol draft, which says that TLSA
queries and answers follows normal DNS resolution.

Please respond just with +1/-1, we already had a lengthy
discussion on the subject and it doesn't seem to develop
anywhere in last few days. =A0If you really feel an urge
to discuss it again, please read the threads from last
two weeks on the subject and make an follow-up there,
so we can keep this thread loud and clear.

And since we already had a discussion on the topic I would
like to close this issue next monday.

Thanks,
--
=A0Ond=F8ej Sur=FD
=A0vedouc=ED v=FDzkumu/Head of R&D department
=A0-------------------------------------------
=A0CZ.NIC, z.s.p.o. =A0 =A0-- =A0 =A0Laborato=F8e CZ.NIC
=A0Americka 23, 120 00 Praha 2, Czech Republic
=A0mailto:ondrej.sury@nic.cz =A0 = =A0http://nic.cz/
=A0tel:+420.222745= 110 =A0 =A0 =A0 fax:+420.222745112
=A0-------------------------------------------

_______________________________________________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane



--
Website: http://hallambaker.com/

--00163691ff516e960504aa19236c-- From ajs@anvilwalrusden.com Tue Aug 9 14:48:45 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7617021F8C69 for ; Tue, 9 Aug 2011 14:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.27 X-Spam-Level: X-Spam-Status: No, score=-2.27 tagged_above=-999 required=5 tests=[AWL=-0.271, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uV4r8Xdgg9to for ; Tue, 9 Aug 2011 14:48:44 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id D645D21F8C65 for ; Tue, 9 Aug 2011 14:48:44 -0700 (PDT) Received: from shinkuro.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id B34051ECB41D for ; Tue, 9 Aug 2011 21:49:14 +0000 (UTC) Date: Tue, 9 Aug 2011 17:49:12 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20110809214911.GG81036@shinkuro.com> References: <6B5F4F0A-82F2-4911-81B6-F923D7529E4A@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6B5F4F0A-82F2-4911-81B6-F923D7529E4A@nic.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Call for consensus for CNAME X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 21:48:45 -0000 +1 On Tue, Aug 09, 2011 at 10:44:24PM +0200, OndÅ™ej Surý wrote: > Hi, > > I hereby make a call for a consensus on the CNAME issue. > > I am specifically asking you if you agree with current > contents of DANE protocol draft, which says that TLSA > queries and answers follows normal DNS resolution. > > Please respond just with +1/-1, we already had a lengthy > discussion on the subject and it doesn't seem to develop > anywhere in last few days. If you really feel an urge > to discuss it again, please read the threads from last > two weeks on the subject and make an follow-up there, > so we can keep this thread loud and clear. > > And since we already had a discussion on the topic I would > like to close this issue next monday. > > Thanks, > -- > OndÅ™ej Surý > vedoucí výzkumu/Head of R&D department > ------------------------------------------- > CZ.NIC, z.s.p.o. -- LaboratoÅ™e CZ.NIC > Americka 23, 120 00 Praha 2, Czech Republic > mailto:ondrej.sury@nic.cz http://nic.cz/ > tel:+420.222745110 fax:+420.222745112 > ------------------------------------------- > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- Andrew Sullivan ajs@crankycanuck.ca From paul@xelerance.com Tue Aug 9 15:12:21 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD27221F8B64 for ; Tue, 9 Aug 2011 15:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.602 X-Spam-Level: X-Spam-Status: No, score=-5.602 tagged_above=-999 required=5 tests=[AWL=-0.895, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JdpMvomNrYVJ for ; Tue, 9 Aug 2011 15:12:21 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id 1B91721F8B72 for ; Tue, 9 Aug 2011 15:12:21 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 3EE82C5D3 for ; Tue, 9 Aug 2011 18:14:25 -0400 (EDT) Date: Tue, 9 Aug 2011 18:14:25 -0400 (EDT) From: Paul Wouters cc: dane@ietf.org In-Reply-To: <6B5F4F0A-82F2-4911-81B6-F923D7529E4A@nic.cz> Message-ID: References: <6B5F4F0A-82F2-4911-81B6-F923D7529E4A@nic.cz> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Subject: Re: [dane] Call for consensus for CNAME X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 22:12:21 -0000 On Tue, 9 Aug 2011, Ond?ej Surý wrote: > I am specifically asking you if you agree with current > contents of DANE protocol draft, which says that TLSA > queries and answers follows normal DNS resolution. +1 Paul From cloos@jhcloos.com Tue Aug 9 16:36:06 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE4711E80EB for ; Tue, 9 Aug 2011 16:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.045 X-Spam-Level: X-Spam-Status: No, score=-2.045 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AfQzVwOcURRo for ; Tue, 9 Aug 2011 16:36:05 -0700 (PDT) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by ietfa.amsl.com (Postfix) with ESMTP id 4E7C611E80E9 for ; Tue, 9 Aug 2011 16:36:05 -0700 (PDT) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 6A54A40186; Tue, 9 Aug 2011 23:36:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1312932993; bh=FeqdoEAO2EEbGAtm9cJq0Wlnak0UF1uDdKP9bACEKo8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=PCp/uECiEAx8L2c8Yt53tqNCIEDglUv0C3Q+tMh18qqZRT2uaKForkda76nZDdgxj aTx6kZdRKxqPx2BJH8Kifw/mXXLHEOjWtRTgrDbfqSlZMOBneXO1O3DbhD1ecFxVJO 3lds7pJTtSP6hqlKlovgQyenORgtvqUgPEYLk4s0= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 40FB4260042; Tue, 9 Aug 2011 23:31:32 +0000 (UTC) From: James Cloos To: dane@ietf.org In-Reply-To: <6B5F4F0A-82F2-4911-81B6-F923D7529E4A@nic.cz> (=?utf-8?Q?=22O?= =?utf-8?Q?nd=C5=99ej_Sur=C3=BD=22's?= message of "Tue, 9 Aug 2011 22:44:24 +0200") References: <6B5F4F0A-82F2-4911-81B6-F923D7529E4A@nic.cz> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2011 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Tue, 09 Aug 2011 19:31:32 -0400 Message-ID: Lines: 7 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:110809:dane@ietf.org::1d9Nj6DByin5/wPP:0008MAB+ X-Hashcash: 1:30:110809:ondrej.sury@nic.cz::WkxcRXaxU+bGTR5y:000000000000000000000000000000000000000000F+1d9 Subject: Re: [dane] Call for consensus for CNAME X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 23:36:06 -0000 >TLSA queries and answers follows normal DNS resolution. +1 -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From rbarnes@bbn.com Tue Aug 9 16:48:47 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9865F21F8AAC for ; Tue, 9 Aug 2011 16:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.131 X-Spam-Level: X-Spam-Status: No, score=-106.131 tagged_above=-999 required=5 tests=[AWL=-0.432, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dys4Gn3RF0s8 for ; Tue, 9 Aug 2011 16:48:46 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id AA0A021F8AB8 for ; Tue, 9 Aug 2011 16:48:46 -0700 (PDT) Received: from [128.89.254.163] (port=58635 helo=[192.168.1.12]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Qqw2u-000NTZ-4Q; Tue, 09 Aug 2011 19:49:16 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=utf-8 From: "Richard L. Barnes" In-Reply-To: <6B5F4F0A-82F2-4911-81B6-F923D7529E4A@nic.cz> Date: Tue, 9 Aug 2011 19:49:12 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6B5F4F0A-82F2-4911-81B6-F923D7529E4A@nic.cz> To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= X-Mailer: Apple Mail (2.1082) Cc: dane@ietf.org Subject: Re: [dane] Call for consensus for CNAME X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 23:48:47 -0000 +1 On Aug 9, 2011, at 4:44 PM, Ond=C5=99ej Sur=C3=BD wrote: > Hi, >=20 > I hereby make a call for a consensus on the CNAME issue. >=20 > I am specifically asking you if you agree with current > contents of DANE protocol draft, which says that TLSA > queries and answers follows normal DNS resolution. >=20 > Please respond just with +1/-1, we already had a lengthy > discussion on the subject and it doesn't seem to develop > anywhere in last few days. If you really feel an urge > to discuss it again, please read the threads from last > two weeks on the subject and make an follow-up there, > so we can keep this thread loud and clear. >=20 > And since we already had a discussion on the topic I would > like to close this issue next monday.=09 >=20 > Thanks, > -- > Ond=C5=99ej Sur=C3=BD > vedouc=C3=AD v=C3=BDzkumu/Head of R&D department > ------------------------------------------- > CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC > Americka 23, 120 00 Praha 2, Czech Republic > mailto:ondrej.sury@nic.cz http://nic.cz/ > tel:+420.222745110 fax:+420.222745112 > ------------------------------------------- >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From bmanning@karoshi.com Wed Aug 10 03:52:11 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9459521F84F4 for ; Wed, 10 Aug 2011 03:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.35 X-Spam-Level: X-Spam-Status: No, score=-6.35 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YtlIQG0FaD1W for ; Wed, 10 Aug 2011 03:52:11 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id 22B6521F84FE for ; Wed, 10 Aug 2011 03:52:10 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id p7AAqfmw001235; Wed, 10 Aug 2011 10:52:41 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id p7AAqdco001233; Wed, 10 Aug 2011 10:52:39 GMT Date: Wed, 10 Aug 2011 10:52:39 +0000 From: bmanning@vacation.karoshi.com To: Jakob Schlyter Message-ID: <20110810105239.GA1194@vacation.karoshi.com.> References: <20110802001308.26792.qmail@joyce.lan> <20110809091841.GB29435@vacation.karoshi.com.> <20110809153018.GB29903@vacation.karoshi.com.> <3799032F-F71C-46A7-9981-6D72F76010DC@kirei.se> <20110809163120.GF29903@vacation.karoshi.com.> <59491739-46DD-4D52-9264-F769F14863A7@vpnc.org> <20110809170306.GG29903@vacation.karoshi.com.> <1E0D2EA6-7C54-4E78-B3D7-FE19A99EC256@kirei.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1E0D2EA6-7C54-4E78-B3D7-FE19A99EC256@kirei.se> User-Agent: Mutt/1.4.1i Cc: bmanning@vacation.karoshi.com, Paul Hoffman , dane@ietf.org Subject: Re: [dane] The Curse of The Same, was CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 10 Aug 2011 10:52:11 -0000 On Tue, Aug 09, 2011 at 07:19:06PM +0200, Jakob Schlyter wrote: > On 9 aug 2011, at 19:03, bmanning@vacation.karoshi.com wrote: > > > Goodie! a valuable attack vector is re-opened! > > (normal DNS rules in a DNSSEC enabled environment are pretty clear > > that while you can query individual RRs, you get the entire RRset back) > > > > if I can push/pull TLSA RRs into/outof cache -independently- of the > > associated RRset, then we have the cache manipulation problem all over > > again - in spades. > > Yes, if you can compromise the cache - and bypass DNSSEC validation - you are toast. Please describe how this is a new problem. > > jakob ah... so the TLSA rr -is/remains- bound to the RRset. happier camper. btw, what happens when a zone w/ TLSA rr's goes insecure, e.g. the zone admin reverts to unsigned state? /bill From jakob@kirei.se Wed Aug 10 03:54:35 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D121321F86BD for ; Wed, 10 Aug 2011 03:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.522 X-Spam-Level: X-Spam-Status: No, score=-0.522 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QtuivEePbCtg for ; Wed, 10 Aug 2011 03:54:35 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id A890C21F86B3 for ; Wed, 10 Aug 2011 03:54:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=5nN2JPG4O/nUkFZ6zC1PudMV2U86JOJB58UhKJ/TMbo=; b=FnHjSbB4ONAguax4WWoQGYTlGxTKiQei1/q1AlsB9fwp6t0UB6V8/8v2o+b/lC6fYO+fbz9arIxOU HD49p1xKVH0yrO7akfSW7PPeb1yEdoXz8+l8Skp1+Zp5oUtzfN8CpyGdzyfmZRg7O3aSXi1l9kdt5E GnQDcZuyJrSLH84o= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Wed, 10 Aug 2011 12:55:03 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: <20110810105239.GA1194@vacation.karoshi.com.> Date: Wed, 10 Aug 2011 12:54:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <54050536-9B7C-430F-8165-1C3DAFE74CC1@kirei.se> References: <20110802001308.26792.qmail@joyce.lan> <20110809091841.GB29435@vacation.karoshi.com.> <20110809153018.GB29903@vacation.karoshi.com.> <3799032F-F71C-46A7-9981-6D72F76010DC@kirei.se> <20110809163120.GF29903@vacation.karoshi.com.> <59491739-46DD-4D52-9264-F769F14863A7@vpnc.org> <20110809170306.GG29903@vacation.karoshi.com.> <1E0D2EA6-7C54-4E78-B3D7-FE19A99EC256@kirei.se> <20110810105239.GA1194@vacation.karoshi.com.> To: bmanning@vacation.karoshi.com X-Mailer: Apple Mail (2.1244.3) Cc: Paul Hoffman , dane@ietf.org Subject: Re: [dane] The Curse of The Same, was CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 10 Aug 2011 10:54:35 -0000 On 10 aug 2011, at 12:52, bmanning@vacation.karoshi.com wrote: > ah... so the TLSA rr -is/remains- bound to the RRset. happier = camper. > btw, what happens when a zone w/ TLSA rr's goes insecure, e.g. = the zone > admin reverts to unsigned state? =20 TLSA DNSSEC validation results in INSECURE and the TLSA records are = ignored (as TLSA requires data to be secure). jakob From bmanning@karoshi.com Wed Aug 10 03:57:55 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 737D921F8742 for ; Wed, 10 Aug 2011 03:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.362 X-Spam-Level: X-Spam-Status: No, score=-6.362 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0bhjaKQVZdV for ; Wed, 10 Aug 2011 03:57:54 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id D81C021F86D6 for ; Wed, 10 Aug 2011 03:57:54 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id p7AAwQmw001273; Wed, 10 Aug 2011 10:58:26 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id p7AAwQdb001271; Wed, 10 Aug 2011 10:58:26 GMT Date: Wed, 10 Aug 2011 10:58:26 +0000 From: bmanning@vacation.karoshi.com To: Jakob Schlyter Message-ID: <20110810105826.GB1194@vacation.karoshi.com.> References: <20110809091841.GB29435@vacation.karoshi.com.> <20110809153018.GB29903@vacation.karoshi.com.> <3799032F-F71C-46A7-9981-6D72F76010DC@kirei.se> <20110809163120.GF29903@vacation.karoshi.com.> <59491739-46DD-4D52-9264-F769F14863A7@vpnc.org> <20110809170306.GG29903@vacation.karoshi.com.> <1E0D2EA6-7C54-4E78-B3D7-FE19A99EC256@kirei.se> <20110810105239.GA1194@vacation.karoshi.com.> <54050536-9B7C-430F-8165-1C3DAFE74CC1@kirei.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54050536-9B7C-430F-8165-1C3DAFE74CC1@kirei.se> User-Agent: Mutt/1.4.1i Cc: bmanning@vacation.karoshi.com, Paul Hoffman , dane@ietf.org Subject: Re: [dane] The Curse of The Same, was CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 10 Aug 2011 10:57:55 -0000 On Wed, Aug 10, 2011 at 12:54:57PM +0200, Jakob Schlyter wrote: > On 10 aug 2011, at 12:52, bmanning@vacation.karoshi.com wrote: > > > ah... so the TLSA rr -is/remains- bound to the RRset. happier camper. > > btw, what happens when a zone w/ TLSA rr's goes insecure, e.g. the zone > > admin reverts to unsigned state? > > TLSA DNSSEC validation results in INSECURE and the TLSA records are ignored (as TLSA requires data to be secure). returned and ignored or not returned at all? /bill From jakob@kirei.se Wed Aug 10 03:59:44 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73D6C21F875E for ; Wed, 10 Aug 2011 03:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.532 X-Spam-Level: X-Spam-Status: No, score=-0.532 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8qbkSFmF-k7 for ; Wed, 10 Aug 2011 03:59:43 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id 4C5FB21F8757 for ; Wed, 10 Aug 2011 03:59:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=c5/xPPb0B1k7LsCuVX6LXA6cqD4udqC7DtoMf55F5vc=; b=xOCMcpXb8rPU47X2zkFqCNodhjYzzvpPNDft8VR30Sgf87WoG703GKf9EmkTAz5jLTkde2eIq/sWB fck5+RWonVPK04ifPiAX/npgGtfh1Bae2DvuSXzj8sjfKvqx8hNGC1M12pyWWRmmJT6r/j4rZWGe5V X4Q7I7qhXi0UCqpw= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Wed, 10 Aug 2011 13:00:13 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: <20110810105826.GB1194@vacation.karoshi.com.> Date: Wed, 10 Aug 2011 13:00:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110809091841.GB29435@vacation.karoshi.com.> <20110809153018.GB29903@vacation.karoshi.com.> <3799032F-F71C-46A7-9981-6D72F76010DC@kirei.se> <20110809163120.GF29903@vacation.karoshi.com.> <59491739-46DD-4D52-9264-F769F14863A7@vpnc.org> <20110809170306.GG29903@vacation.karoshi.com.> <1E0D2EA6-7C54-4E78-B3D7-FE19A99EC256@kirei.se> <20110810105239.GA1194@vacation.karoshi.com.> <54050536-9B7C-430F-8165-1C3DAFE74CC1@kirei.se> <20110810105826.GB1194@vacation.karoshi.com.> To: bmanning@vacation.karoshi.com X-Mailer: Apple Mail (2.1244.3) Cc: Paul Hoffman , dane@ietf.org Subject: Re: [dane] The Curse of The Same, was CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 10 Aug 2011 10:59:44 -0000 On 10 aug 2011, at 12:58, bmanning@vacation.karoshi.com wrote: > returned and ignored or not returned at all? The DNS (stub) resolver library will of course find them, it is up to = the application to ignore them as they are not secure. jakob From bmanning@karoshi.com Wed Aug 10 04:02:11 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 358B021F84E8 for ; Wed, 10 Aug 2011 04:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.373 X-Spam-Level: X-Spam-Status: No, score=-6.373 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvyWM4eDKcNv for ; Wed, 10 Aug 2011 04:02:10 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id C09F921F84DD for ; Wed, 10 Aug 2011 04:02:10 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id p7AB2gmw001297; Wed, 10 Aug 2011 11:02:42 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id p7AB2fQ6001296; Wed, 10 Aug 2011 11:02:41 GMT Date: Wed, 10 Aug 2011 11:02:41 +0000 From: bmanning@vacation.karoshi.com To: Jakob Schlyter Message-ID: <20110810110241.GC1194@vacation.karoshi.com.> References: <20110809153018.GB29903@vacation.karoshi.com.> <3799032F-F71C-46A7-9981-6D72F76010DC@kirei.se> <20110809163120.GF29903@vacation.karoshi.com.> <59491739-46DD-4D52-9264-F769F14863A7@vpnc.org> <20110809170306.GG29903@vacation.karoshi.com.> <1E0D2EA6-7C54-4E78-B3D7-FE19A99EC256@kirei.se> <20110810105239.GA1194@vacation.karoshi.com.> <54050536-9B7C-430F-8165-1C3DAFE74CC1@kirei.se> <20110810105826.GB1194@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: bmanning@vacation.karoshi.com, Paul Hoffman , dane@ietf.org Subject: Re: [dane] The Curse of The Same, was CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 10 Aug 2011 11:02:11 -0000 On Wed, Aug 10, 2011 at 01:00:12PM +0200, Jakob Schlyter wrote: > On 10 aug 2011, at 12:58, bmanning@vacation.karoshi.com wrote: > > > returned and ignored or not returned at all? > > The DNS (stub) resolver library will of course find them, it is up to the application to ignore them as they are not secure. > > jakob ok. TLSA spec advice to API/Apps developers v. actual protocol spec. /bill From bmanning@karoshi.com Wed Aug 10 04:41:52 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B347A21F876A for ; Wed, 10 Aug 2011 04:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.234 X-Spam-Level: X-Spam-Status: No, score=-6.234 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xawhMjldv9fr for ; Wed, 10 Aug 2011 04:41:52 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id 38A5021F8761 for ; Wed, 10 Aug 2011 04:41:52 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id p7ABgLmw001379; Wed, 10 Aug 2011 11:42:22 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id p7ABgKhB001378; Wed, 10 Aug 2011 11:42:20 GMT Date: Wed, 10 Aug 2011 11:42:20 +0000 From: bmanning@vacation.karoshi.com To: =?utf-8?B?T25kxZllaiBTdXLDvQ==?= Message-ID: <20110810114220.GD1194@vacation.karoshi.com.> References: <6B5F4F0A-82F2-4911-81B6-F923D7529E4A@nic.cz> <1312923009.2122.16.camel@localhost> <1312923957.2122.18.camel@localhost> <3CE7EC5A-4A66-41A1-AD61-436956CBF540@nic.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3CE7EC5A-4A66-41A1-AD61-436956CBF540@nic.cz> User-Agent: Mutt/1.4.1i Cc: dane@ietf.org Subject: Re: [dane] Call for consensus for CNAME X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 10 Aug 2011 11:41:52 -0000 On Tue, Aug 09, 2011 at 11:12:47PM +0200, OndEej SurC= wrote: > > To clarify - this call is about closing issue #24. Sorry for notmentioning it in the call. as far as i understand ... +1 but I would like to see Matt's alternative - which may open #24+i :) /bill From paul@xelerance.com Wed Aug 10 06:53:38 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3EE21F87DA for ; Wed, 10 Aug 2011 06:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.459 X-Spam-Level: X-Spam-Status: No, score=-6.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id edb3gyLsuKCq for ; Wed, 10 Aug 2011 06:53:38 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id 4B66F21F87D9 for ; Wed, 10 Aug 2011 06:53:37 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id A0EBCC612; Wed, 10 Aug 2011 09:55:45 -0400 (EDT) Date: Wed, 10 Aug 2011 09:55:45 -0400 (EDT) From: Paul Wouters To: Jakob Schlyter In-Reply-To: <54050536-9B7C-430F-8165-1C3DAFE74CC1@kirei.se> Message-ID: References: <20110802001308.26792.qmail@joyce.lan> <20110809091841.GB29435@vacation.karoshi.com.> <20110809153018.GB29903@vacation.karoshi.com.> <3799032F-F71C-46A7-9981-6D72F76010DC@kirei.se> <20110809163120.GF29903@vacation.karoshi.com.> <59491739-46DD-4D52-9264-F769F14863A7@vpnc.org> <20110809170306.GG29903@vacation.karoshi.com.> <1E0D2EA6-7C54-4E78-B3D7-FE19A99EC256@kirei.se> <20110810105239.GA1194@vacation.karoshi.com.> <54050536-9B7C-430F-8165-1C3DAFE74CC1@kirei.se> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: bmanning@vacation.karoshi.com, Paul Hoffman , dane@ietf.org Subject: Re: [dane] The Curse of The Same, was CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 10 Aug 2011 13:53:38 -0000 On Wed, 10 Aug 2011, Jakob Schlyter wrote: > TLSA DNSSEC validation results in INSECURE and the TLSA records are ignored (as TLSA requires data to be secure). Is that in the protocol document? There has been a lot of discussion about whether or not DNSSEC for dane records is mandatory with some rather odd theoretical use cases specified that could benefit without it. In any way, I think any sane TLS client supporting TLSA will not trust TLSA/HASTLS records without proper dnssec validation. Paul From jakob@kirei.se Wed Aug 10 07:28:52 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AEEA21F8AA8 for ; Wed, 10 Aug 2011 07:28:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.605 X-Spam-Level: X-Spam-Status: No, score=-0.605 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6VFbjq9JXXd for ; Wed, 10 Aug 2011 07:28:51 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id 1F2DE21F8A69 for ; Wed, 10 Aug 2011 07:28:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=DxF0COPlLuaIetL5BS3FmdivyhBixMmjLt7ZetoLfzk=; b=GK74+HeIA9d//EfAJAZNahh2uG1RRPLJLAyJFGmFFAt+59cKFykF0LE3DYnLTb5p4+dV4rGSUTC/I fB2rI5FiFK7DDpPtJSgU4Oy0uSmgWRxyAYdAFADQZGIoXilDX2NY5BBVc6VlcaJ430DRIlaiwinHa8 HiuwyCA4ZNy3Mdyo= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Wed, 10 Aug 2011 16:29:19 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: Date: Wed, 10 Aug 2011 16:29:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4C05DB2D-3BC5-4034-B489-3C4EE0D01F78@kirei.se> References: <20110802001308.26792.qmail@joyce.lan> <20110809091841.GB29435@vacation.karoshi.com.> <20110809153018.GB29903@vacation.karoshi.com.> <3799032F-F71C-46A7-9981-6D72F76010DC@kirei.se> <20110809163120.GF29903@vacation.karoshi.com.> <59491739-46DD-4D52-9264-F769F14863A7@vpnc.org> <20110809170306.GG29903@vacation.karoshi.com.> <1E0D2EA6-7C54-4E78-B3D7-FE19A99EC256@kirei.se> <20110810105239.GA1194@vacation.karoshi.com.> <54050536-9B7C-430F-8165-1C3DAFE74CC1@kirei.se> To: Paul Wouters X-Mailer: Apple Mail (2.1244.3) Cc: bmanning@vacation.karoshi.com, Paul Hoffman , dane@ietf.org Subject: Re: [dane] The Curse of The Same, was CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 10 Aug 2011 14:28:52 -0000 On 10 aug 2011, at 15:55, Paul Wouters wrote: > On Wed, 10 Aug 2011, Jakob Schlyter wrote: >=20 >> TLSA DNSSEC validation results in INSECURE and the TLSA records are = ignored (as TLSA requires data to be secure). >=20 > Is that in the protocol document? There has been a lot of discussion = about whether or > not DNSSEC for dane records is mandatory with some rather odd = theoretical use cases > specified that could benefit without it. The current draft says: "In order to use one or more TLS certificate associations described in this document obtained from the DNS, an application MUST assure that the certificates were obtained using DNS protected by DNSSEC." jakob From fanf2@hermes.cam.ac.uk Wed Aug 10 09:14:11 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1925621F8ACC for ; Wed, 10 Aug 2011 09:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fSEBZ6KC7Sma for ; Wed, 10 Aug 2011 09:14:10 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id BBD2421F8AB8 for ; Wed, 10 Aug 2011 09:14:09 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:33014) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1QrBQW-00036Q-WT (Exim 4.72) (return-path ); Wed, 10 Aug 2011 17:14:40 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1QrBQW-00086e-1u (Exim 4.67) (return-path ); Wed, 10 Aug 2011 17:14:40 +0100 Date: Wed, 10 Aug 2011 17:14:40 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Martin Rex In-Reply-To: <201108041415.p74EFdNS023238@fs4113.wdf.sap.corp> Message-ID: References: <201108041415.p74EFdNS023238@fs4113.wdf.sap.corp> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 10 Aug 2011 16:14:11 -0000 Martin Rex wrote: > > Unfortunately, this is exactly how SMTP-AUTH appears to be specified, > ... and documented in rfc6125. > > http://tools.ietf.org/html/rfc6125#appendix-B.4 > > resulting in a self-contradictory statement: > > The client MUST use the server hostname it used to open the > connection as the value to compare against the server name as > expressed in the server certificate. The client MUST NOT use any > form of the server hostname derived from an insecure remote source > (e.g., insecure DNS lookup). CNAME canonicalization is not done. > > First, it says that the client MUST use the server hostname that is > resulting from the (insecure) MX DNS lookup. Then it goes on to say that > the client MUST NOT use a form of the server hostname derived from an > insecure remote source such as insecure DNS lookup. Note that SMTP AUTH is used pretty much exclusively with the message submission protocol, not with server-to-server SMTP. Message submission does not use MX lookups, so the service name is the same as the hostname (like HTTP) or (if you are very advanced) indirected using SRV - see RFC 6186. That quote from RFC 6125 is in an informative appendix which is in turn quoting from RFC 4954 which uses the same wording as RFC 2595. All three documents are consistently (if not always clearly) requiring that the certificate is checked against the name entered by the user, NOT by some name derived from an indirection in the DNS (whether it be CNAME or MX or SRV). I think we should stick with service name authentication, and not switch to host name authentication. Tony. -- f.anthony.n.finch http://dotat.at/ Viking, North Utsire, South Utsire, Northeast Forties: Northwesterly veering northeasterly 4 or 5, decreasing 3 at times later. Moderate becoming slight at times. Mainly fair. Moderate or good. From fanf2@hermes.cam.ac.uk Wed Aug 10 09:28:17 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 293F421F8797 for ; Wed, 10 Aug 2011 09:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nAgfe7AVmAqf for ; Wed, 10 Aug 2011 09:28:16 -0700 (PDT) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by ietfa.amsl.com (Postfix) with ESMTP id 5599021F8788 for ; Wed, 10 Aug 2011 09:28:16 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:52950) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1QrBe4-0003dt-S7 (Exim 4.72) (return-path ); Wed, 10 Aug 2011 17:28:40 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1QrBe4-0001dK-Mg (Exim 4.67) (return-path ); Wed, 10 Aug 2011 17:28:40 +0100 Date: Wed, 10 Aug 2011 17:28:40 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: "Richard L. Barnes" In-Reply-To: Message-ID: References: <057.eb22cfc8c145014f66d7c72f9cf864f8@trac.tools.ietf.org> <066.aaadec73af2c30671ce4150b9a6d7b51@trac.tools.ietf.org> <7155FD03-FC81-4DFD-B2B0-4C7B416AF3AE@bbn.com> <018c01cc53ad$d224b390$766e1ab0$@augustcellars.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: draft-ietf-dane-protocol@tools.ietf.org, 'dane issue tracker' , dane@ietf.org Subject: Re: [dane] #28: Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 10 Aug 2011 16:28:17 -0000 Richard L. Barnes wrote: > > So for example, an XMPP hosting provider's server xmpp1.provider.com > might have a cert that has an SRVName SAN for > _xmpp-server._tcp.customer.com. The hosting provider could then > provision that cert in a TLSA record under _port._tcp.xmpp1.provider.com > in order to facilitate discovery. But the SRVName would still be there > for the application to use in authenticating the remote entity. If the certificate matches the customer domain, why isn't the TLSA record attached to the customer domain too? Tony. -- f.anthony.n.finch http://dotat.at/ Fisher: Northwest 5 to 7, veering northeast 3 or 4. Moderate, occasionally rough at first. Rain in south. Good, occasionally moderate or poor in south. From fanf2@hermes.cam.ac.uk Wed Aug 10 10:06:42 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F04421F8ACC for ; Wed, 10 Aug 2011 10:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOETQMiH5vgU for ; Wed, 10 Aug 2011 10:06:41 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id 5F50C21F8A95 for ; Wed, 10 Aug 2011 10:06:41 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:49291) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1QrCFL-0002LY-Z3 (Exim 4.72) (return-path ); Wed, 10 Aug 2011 18:07:11 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1QrCFL-0006lr-Rc (Exim 4.67) (return-path ); Wed, 10 Aug 2011 18:07:11 +0100 Date: Wed, 10 Aug 2011 18:07:11 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: =?ISO-8859-2?Q?Ond=F8ej_Sur=FD?= In-Reply-To: <6B5F4F0A-82F2-4911-81B6-F923D7529E4A@nic.cz> Message-ID: References: <6B5F4F0A-82F2-4911-81B6-F923D7529E4A@nic.cz> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1870870024-1355468802-1312996031=:2480" Sender: Tony Finch Cc: dane@ietf.org Subject: Re: [dane] Call for consensus for CNAME X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 10 Aug 2011 17:06:42 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1870870024-1355468802-1312996031=:2480 Content-Type: TEXT/PLAIN; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Ond=C5=99ej Sur=C3=BD wrote: > > I am specifically asking you if you agree with current > contents of DANE protocol draft, which says that TLSA > queries and answers follows normal DNS resolution. +1 Tony. --=20 f.anthony.n.finch http://dotat.at/ Humber, Thames, Dover, Wight, Portland, Plymouth: Southwest 5 to 7, increas= ing gale 8 for a time in Thames and Dover. Moderate or rough. Occasional rain. Moderate or good, occasionally poor. --1870870024-1355468802-1312996031=:2480-- From hallam@gmail.com Wed Aug 10 11:06:13 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA8D521F8AF2 for ; Wed, 10 Aug 2011 11:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[AWL=-0.688, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id appb8eQcq5Za for ; Wed, 10 Aug 2011 11:06:13 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0ECAD21F8A80 for ; Wed, 10 Aug 2011 11:06:12 -0700 (PDT) Received: by ywm21 with SMTP id 21so925686ywm.31 for ; Wed, 10 Aug 2011 11:06:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oYJXg03p1jlgqocVeK5vSsMq0ms3SXLNHkElQrizke0=; b=QDMtF73ciB/JSiffEmzBvRgKXc467IW0J3zZJLCpLuOi75dij4QUgy3fnal1031kIi qv7qMaFlGKwZYhxg8Dn/BiHykN3s0hNNiWpDhyZuH2Qnra8ko+fikE/j8JJLMunRRlTs oRbJEo1SJTxgSZv1rep478M7yTN2KxcJDHGO8= MIME-Version: 1.0 Received: by 10.101.94.14 with SMTP id w14mr621628anl.28.1312999604494; Wed, 10 Aug 2011 11:06:44 -0700 (PDT) Received: by 10.100.34.3 with HTTP; Wed, 10 Aug 2011 11:06:44 -0700 (PDT) In-Reply-To: References: <20110802001308.26792.qmail@joyce.lan> <20110809091841.GB29435@vacation.karoshi.com.> <20110809153018.GB29903@vacation.karoshi.com.> <3799032F-F71C-46A7-9981-6D72F76010DC@kirei.se> <20110809163120.GF29903@vacation.karoshi.com.> <59491739-46DD-4D52-9264-F769F14863A7@vpnc.org> <20110809170306.GG29903@vacation.karoshi.com.> <1E0D2EA6-7C54-4E78-B3D7-FE19A99EC256@kirei.se> <20110810105239.GA1194@vacation.karoshi.com.> <54050536-9B7C-430F-8165-1C3DAFE74CC1@kirei.se> Date: Wed, 10 Aug 2011 19:06:44 +0100 Message-ID: From: Phillip Hallam-Baker To: Paul Wouters Content-Type: multipart/alternative; boundary=001636ed6c8c04233a04aa2a8b5d Cc: bmanning@vacation.karoshi.com, Paul Hoffman , dane@ietf.org Subject: Re: [dane] The Curse of The Same, was CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 10 Aug 2011 18:06:13 -0000 --001636ed6c8c04233a04aa2a8b5d Content-Type: text/plain; charset=ISO-8859-1 All the document can say is that without DNSSEC there is limited reason to trust a TLSA record. Clients currently accept completely unauthenticated keys for certain transactions, unauthenticated TLSA are going to be better than self-signed certs. So what it comes down to is what, if anything the user is told. And if the User Experience is out of scope there is nowt the spec can say on that. I doubt it really matters what the draft says on this particular point. On Wed, Aug 10, 2011 at 2:55 PM, Paul Wouters wrote: > On Wed, 10 Aug 2011, Jakob Schlyter wrote: > > TLSA DNSSEC validation results in INSECURE and the TLSA records are >> ignored (as TLSA requires data to be secure). >> > > Is that in the protocol document? There has been a lot of discussion about > whether or > not DNSSEC for dane records is mandatory with some rather odd theoretical > use cases > specified that could benefit without it. > > In any way, I think any sane TLS client supporting TLSA will not trust > TLSA/HASTLS records > without proper dnssec validation. > > Paul > > ______________________________**_________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/**listinfo/dane > -- Website: http://hallambaker.com/ --001636ed6c8c04233a04aa2a8b5d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable All the document can say is that without DNSSEC there is limited reason to = trust a TLSA record.

Clients currently accept completely unauth= enticated keys for certain transactions, unauthenticated TLSA are going to = be better than self-signed certs.=A0

So what it comes down to is what, if anything the user = is told. And if the User Experience is out of scope there is nowt the spec = can say on that.


I doubt it really = matters what the draft says on this particular point.=A0


On Wed, Aug 10, 2011 at = 2:55 PM, Paul Wouters <paul@xelerance.com> wrote:
On Wed, 10 Aug 2011, Jakob Schlyter wrote:

TLSA DNSSEC validation results in INSECURE and the TLSA records are ignored= (as TLSA requires data to be secure).

Is that in the protocol document? There has been a lot of discussion about = whether or
not DNSSEC for dane records is mandatory with some rather odd theoretical u= se cases
specified that could benefit without it.

In any way, I think any sane TLS client supporting TLSA will not trust TLSA= /HASTLS records
without proper dnssec validation.

Paul

_______________________________________________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane



--
Website: http://hallambaker.com/

--001636ed6c8c04233a04aa2a8b5d-- From paul@xelerance.com Wed Aug 10 11:29:25 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0065521F874F for ; Wed, 10 Aug 2011 11:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.462 X-Spam-Level: X-Spam-Status: No, score=-6.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5JXOm2bd7rSa for ; Wed, 10 Aug 2011 11:29:24 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id 65F6221F86FF for ; Wed, 10 Aug 2011 11:29:24 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 8E0E4C612; Wed, 10 Aug 2011 14:31:33 -0400 (EDT) Date: Wed, 10 Aug 2011 14:31:33 -0400 (EDT) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <20110802001308.26792.qmail@joyce.lan> <20110809091841.GB29435@vacation.karoshi.com.> <20110809153018.GB29903@vacation.karoshi.com.> <3799032F-F71C-46A7-9981-6D72F76010DC@kirei.se> <20110809163120.GF29903@vacation.karoshi.com.> <59491739-46DD-4D52-9264-F769F14863A7@vpnc.org> <20110809170306.GG29903@vacation.karoshi.com.> <1E0D2EA6-7C54-4E78-B3D7-FE19A99EC256@kirei.se> <20110810105239.GA1194@vacation.karoshi.com.> <54050536-9B7C-430F-8165-1C3DAFE74CC1@kirei.se> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Cc: dane@ietf.org Subject: Re: [dane] The Curse of The Same, was CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 10 Aug 2011 18:29:25 -0000 On Wed, 10 Aug 2011, Phillip Hallam-Baker wrote: > unauthenticated keys for certain transactions, unauthenticated TLSA are going to be better > than self-signed certs.  I don't see that. Either can be MITMs and should be treated equally bad. Paul From hallam@gmail.com Wed Aug 10 12:00:05 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65FC721F8B2A for ; Wed, 10 Aug 2011 12:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.445 X-Spam-Level: X-Spam-Status: No, score=-3.445 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J9N4bTxs48xq for ; Wed, 10 Aug 2011 12:00:03 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 48E1F21F8B35 for ; Wed, 10 Aug 2011 12:00:03 -0700 (PDT) Received: by gxk19 with SMTP id 19so1007362gxk.31 for ; Wed, 10 Aug 2011 12:00:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2/TJ82q+TfahEuIjLaVDAnZ2MF82QDCkZNr5aiyP770=; b=sPFQY6BCl/Im5CvTlris/x6h3KZBrO5jAzLwNG2UsJMiIpd6Ykk+cAyURhgLmz+Kst qcLKOi2RK0elSXJ8G1rh8e3+X2UuBrU1+C0ILX+mAxgLK2fiAKOh+CexETKKJYzfo/QS 5ghK/PsLWovfSpgklmgzVxD3LIids72FiYf4Y= MIME-Version: 1.0 Received: by 10.101.164.25 with SMTP id r25mr7556283ano.94.1313002834507; Wed, 10 Aug 2011 12:00:34 -0700 (PDT) Received: by 10.100.34.3 with HTTP; Wed, 10 Aug 2011 12:00:34 -0700 (PDT) In-Reply-To: References: <20110802001308.26792.qmail@joyce.lan> <20110809091841.GB29435@vacation.karoshi.com.> <20110809153018.GB29903@vacation.karoshi.com.> <3799032F-F71C-46A7-9981-6D72F76010DC@kirei.se> <20110809163120.GF29903@vacation.karoshi.com.> <59491739-46DD-4D52-9264-F769F14863A7@vpnc.org> <20110809170306.GG29903@vacation.karoshi.com.> <1E0D2EA6-7C54-4E78-B3D7-FE19A99EC256@kirei.se> <20110810105239.GA1194@vacation.karoshi.com.> <54050536-9B7C-430F-8165-1C3DAFE74CC1@kirei.se> Date: Wed, 10 Aug 2011 20:00:34 +0100 Message-ID: From: Phillip Hallam-Baker To: Paul Wouters Content-Type: multipart/alternative; boundary=0016e6d26d728a377304aa2b4be3 Cc: dane@ietf.org Subject: Re: [dane] The Curse of The Same, was CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 10 Aug 2011 19:00:05 -0000 --0016e6d26d728a377304aa2b4be3 Content-Type: text/plain; charset=ISO-8859-1 It depends on what you think the reaction is going to be to lack of crypto 1) Abort the communication 2) Communicate in plaintext All empirical evidence points to the second being what real people do. On Wed, Aug 10, 2011 at 7:31 PM, Paul Wouters wrote: > On Wed, 10 Aug 2011, Phillip Hallam-Baker wrote: > > unauthenticated keys for certain transactions, unauthenticated TLSA are >> going to be better >> than self-signed certs. >> > > I don't see that. Either can be MITMs and should be treated equally bad. > > Paul > -- Website: http://hallambaker.com/ --0016e6d26d728a377304aa2b4be3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It depends on what you think the reaction is going to be to lack of crypto<= div>
1) Abort the communication
2) Communicate in p= laintext

All empirical evidence points to the seco= nd being what real people do.


On Wed, Aug 10, 2011 at = 7:31 PM, Paul Wouters <paul@xelerance.com> wrote:
On Wed, 10 Aug 2011, Phillip Hallam-Baker wrote:

unauthenticated keys for certain transactions, unauthenticated TLSA are goi= ng to be better
than self-signed certs.=A0

I don't see that. Either can be MITMs and should be treated equally bad= .

Paul



--
Website: http://hallambaker.com/

--0016e6d26d728a377304aa2b4be3-- From paul@xelerance.com Wed Aug 10 12:23:58 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B403C11E8078 for ; Wed, 10 Aug 2011 12:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.466 X-Spam-Level: X-Spam-Status: No, score=-6.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3H04Gd-mU3I for ; Wed, 10 Aug 2011 12:23:54 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id 3512721F8A35 for ; Wed, 10 Aug 2011 12:23:54 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 7BFEAC612; Wed, 10 Aug 2011 15:26:04 -0400 (EDT) Date: Wed, 10 Aug 2011 15:26:04 -0400 (EDT) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <20110802001308.26792.qmail@joyce.lan> <20110809091841.GB29435@vacation.karoshi.com.> <20110809153018.GB29903@vacation.karoshi.com.> <3799032F-F71C-46A7-9981-6D72F76010DC@kirei.se> <20110809163120.GF29903@vacation.karoshi.com.> <59491739-46DD-4D52-9264-F769F14863A7@vpnc.org> <20110809170306.GG29903@vacation.karoshi.com.> <1E0D2EA6-7C54-4E78-B3D7-FE19A99EC256@kirei.se> <20110810105239.GA1194@vacation.karoshi.com.> <54050536-9B7C-430F-8165-1C3DAFE74CC1@kirei.se> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Cc: dane@ietf.org Subject: Re: [dane] The Curse of The Same, was CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 10 Aug 2011 19:23:58 -0000 On Wed, 10 Aug 2011, Phillip Hallam-Baker wrote: > It depends on what you think the reaction is going to be to lack of crypto > 1) Abort the communication > 2) Communicate in plaintext How is it different if the lack of crypto comes from unauthenticated TLSA or selfsigned certs? Even you lumped them together in the above explanation. So I still don't understand how unauthenticated TLSA are better then selfsigned certs. the only far fetched reason i can come up with is that dns is "out of band", but really, when being MITMed for https, they can MITM DNS too. Paul > All empirical evidence points to the second being what real people do. > > > On Wed, Aug 10, 2011 at 7:31 PM, Paul Wouters wrote: > On Wed, 10 Aug 2011, Phillip Hallam-Baker wrote: > > unauthenticated keys for certain transactions, unauthenticated TLSA are going to be better > than self-signed certs.  > > > I don't see that. Either can be MITMs and should be treated equally bad. > > Paul > > > > > -- > Website: http://hallambaker.com/ > > > From ietf@augustcellars.com Wed Aug 10 12:57:47 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 214B921F8B6C for ; Wed, 10 Aug 2011 12:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.899 X-Spam-Level: X-Spam-Status: No, score=-2.899 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JwAh2d0zy7qF for ; Wed, 10 Aug 2011 12:57:46 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 00B2F21F8751 for ; Wed, 10 Aug 2011 12:57:45 -0700 (PDT) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 36F3E38EF9; Wed, 10 Aug 2011 12:58:18 -0700 (PDT) From: "Jim Schaad" To: =?UTF-8?Q?'Ondrej_Sur=C3=BD'?= , References: <6B5F4F0A-82F2-4911-81B6-F923D7529E4A@nic.cz> In-Reply-To: <6B5F4F0A-82F2-4911-81B6-F923D7529E4A@nic.cz> Date: Wed, 10 Aug 2011 13:32:14 -0700 Message-ID: <003701cc579c$96ff9a30$c4fece90$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHgTiynM519JBkmb0ro3WSOdbgBr5TunKWg Content-Language: en-us Subject: Re: [dane] Call for consensus for CNAME X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 10 Aug 2011 19:57:47 -0000 +1 - way forward - I can live with this -1 - current text - I am trying to figure out what I do and don't like = and will be offering comments to the editors. > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf = Of > Ondrej Sur=C3=BD > Sent: Tuesday, August 09, 2011 1:44 PM > To: dane@ietf.org > Subject: [dane] Call for consensus for CNAME >=20 > Hi, >=20 > I hereby make a call for a consensus on the CNAME issue. >=20 > I am specifically asking you if you agree with current contents of = DANE > protocol draft, which says that TLSA queries and answers follows = normal DNS > resolution. >=20 > Please respond just with +1/-1, we already had a lengthy discussion on = the > subject and it doesn't seem to develop anywhere in last few days. If = you > really feel an urge to discuss it again, please read the threads from = last two > weeks on the subject and make an follow-up there, so we can keep this > thread loud and clear. >=20 > And since we already had a discussion on the topic I would > like to close this issue next monday. >=20 > Thanks, > -- > Ondrej Sur > vedouc v zkumu/Head of R&D department > ------------------------------------------- > CZ.NIC, z.s.p.o. -- Laboratore CZ.NIC > Americka 23, 120 00 Praha 2, Czech Republic > mailto:ondrej.sury@nic.cz http://nic.cz/ > tel:+420.222745110 fax:+420.222745112 > ------------------------------------------- >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From marka@isc.org Wed Aug 10 16:48:43 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89ED522800D for ; Wed, 10 Aug 2011 16:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.603 X-Spam-Level: X-Spam-Status: No, score=-2.603 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3iypu+2H3os for ; Wed, 10 Aug 2011 16:48:42 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 950B921F8B34 for ; Wed, 10 Aug 2011 16:48:42 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 04211C9422; Wed, 10 Aug 2011 23:49:04 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 8FFF6216C7B; Wed, 10 Aug 2011 23:49:03 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 4324512B5401; Thu, 11 Aug 2011 09:49:00 +1000 (EST) To: Tony Finch From: Mark Andrews References: <201108041415.p74EFdNS023238@fs4113.wdf.sap.corp> In-reply-to: Your message of "Wed, 10 Aug 2011 17:14:40 +0100." Date: Thu, 11 Aug 2011 09:49:00 +1000 Message-Id: <20110810234900.4324512B5401@drugs.dv.isc.org> Cc: dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 10 Aug 2011 23:48:43 -0000 In message , Tony Fi nch writes: > Martin Rex wrote: > > > > Unfortunately, this is exactly how SMTP-AUTH appears to be specified, > > ... and documented in rfc6125. > > > > http://tools.ietf.org/html/rfc6125#appendix-B.4 > > > > resulting in a self-contradictory statement: > > > > The client MUST use the server hostname it used to open the > > connection as the value to compare against the server name as > > expressed in the server certificate. The client MUST NOT use any > > form of the server hostname derived from an insecure remote source > > (e.g., insecure DNS lookup). CNAME canonicalization is not done. > > > > First, it says that the client MUST use the server hostname that is > > resulting from the (insecure) MX DNS lookup. Then it goes on to say that > > the client MUST NOT use a form of the server hostname derived from an > > insecure remote source such as insecure DNS lookup. > > Note that SMTP AUTH is used pretty much exclusively with the message > submission protocol, not with server-to-server SMTP. Message submission > does not use MX lookups, so the service name is the same as the hostname > (like HTTP) or (if you are very advanced) indirected using SRV - see RFC > 6186. There is no contradition above. SMTP AUTH is useless unless the entire path to identify the server is secure. The above is saying don't do SMTP AUTH unless you have *secure* referrals. DNSSEC gives you secure referrals. It isn't saying ignore the referrals. And if you are using SRV you use the target of the SRV record to authenticate and it should match the name presented in the greeting when you connect. Same with MX. This goes all the way back RFC 821. 3.5. OPENING AND CLOSING At the time the transmission channel is opened there is an exchange to ensure that the hosts are communicating with the hosts they think they are. We have DNSSEC. We can authenticate SRV and MX records. They can, *securely*, tell you who you are supposed to be talking to. > That quote from RFC 6125 is in an informative appendix which is in turn > quoting from RFC 4954 which uses the same wording as RFC 2595. All three > documents are consistently (if not always clearly) requiring that the > certificate is checked against the name entered by the user, NOT by some > name derived from an indirection in the DNS (whether it be CNAME or MX or > SRV). No, it isn't saying that. > I think we should stick with service name authentication, and not switch > to host name authentication. > > Tony. > -- > f.anthony.n.finch http://dotat.at/ > Viking, North Utsire, South Utsire, Northeast Forties: Northwesterly veering > northeasterly 4 or 5, decreasing 3 at times later. Moderate becoming slight a > t > times. Mainly fair. Moderate or good. > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From mrex@sap.com Wed Aug 10 19:51:08 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 207FC11E8086 for ; Wed, 10 Aug 2011 19:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.996 X-Spam-Level: X-Spam-Status: No, score=-9.996 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjOYSgT8RW4D for ; Wed, 10 Aug 2011 19:51:07 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 6B07F11E8083 for ; Wed, 10 Aug 2011 19:51:07 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p7B2pbJN021537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 11 Aug 2011 04:51:37 +0200 (MEST) From: Martin Rex Message-Id: <201108110251.p7B2pajv016484@fs4113.wdf.sap.corp> To: dot@dotat.at (Tony Finch) Date: Thu, 11 Aug 2011 04:51:36 +0200 (MEST) In-Reply-To: from "Tony Finch" at Aug 10, 11 05:14:40 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 02:51:08 -0000 Tony Finch wrote: > > > > > First, it says that the client MUST use the server hostname that is > > resulting from the (insecure) MX DNS lookup. Then it goes on to say that > > the client MUST NOT use a form of the server hostname derived from an > > insecure remote source such as insecure DNS lookup. > > Note that SMTP AUTH is used pretty much exclusively with the message > submission protocol, not with server-to-server SMTP. Message submission > does not use MX lookups, so the service name is the same as the hostname > (like HTTP) or (if you are very advanced) indirected using SRV - see RFC > 6186. I somehow fail to see conformance to rfc6186 with respect to the TLS server cert for both, MUAs and Server-to-Server, for @gmail.com SMTP. The TLS server certificate presented seems to be from a private CA (not from one of the CAs of the TLS X.509 PKI), so it doesn't really matter that it also fails to match the "gmail.com" reference identifier. -Martin From marka@isc.org Wed Aug 10 20:02:56 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DFE811E80BB for ; Wed, 10 Aug 2011 20:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.603 X-Spam-Level: X-Spam-Status: No, score=-2.603 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p0pkiYGYgBfw for ; Wed, 10 Aug 2011 20:02:55 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id BDFA911E8086 for ; Wed, 10 Aug 2011 20:02:55 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 9FC8A5F99A5; Thu, 11 Aug 2011 03:01:47 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 876AA216C81; Thu, 11 Aug 2011 03:01:45 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 7A1BB12B6FCB; Thu, 11 Aug 2011 13:01:42 +1000 (EST) To: mrex@sap.com From: Mark Andrews References: <201108110251.p7B2pajv016484@fs4113.wdf.sap.corp> In-reply-to: Your message of "Thu, 11 Aug 2011 04:51:36 +0200." <201108110251.p7B2pajv016484@fs4113.wdf.sap.corp> Date: Thu, 11 Aug 2011 13:01:42 +1000 Message-Id: <20110811030142.7A1BB12B6FCB@drugs.dv.isc.org> Cc: dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 03:02:56 -0000 In message <201108110251.p7B2pajv016484@fs4113.wdf.sap.corp>, Martin Rex writes : > Tony Finch wrote: > > > > > > > > First, it says that the client MUST use the server hostname that is > > > resulting from the (insecure) MX DNS lookup. Then it goes on to say that > > > the client MUST NOT use a form of the server hostname derived from an > > > insecure remote source such as insecure DNS lookup. > > > > Note that SMTP AUTH is used pretty much exclusively with the message > > submission protocol, not with server-to-server SMTP. Message submission > > does not use MX lookups, so the service name is the same as the hostname > > (like HTTP) or (if you are very advanced) indirected using SRV - see RFC > > 6186. > > I somehow fail to see conformance to rfc6186 with respect to the > TLS server cert for both, MUAs and Server-to-Server, for @gmail.com SMTP. > > The TLS server certificate presented seems to be from a private CA > (not from one of the CAs of the TLS X.509 PKI), so it doesn't really > matter that it also fails to match the "gmail.com" reference identifier. Just because operators are doing the wrong thing today it doesn't mean they can't do the right thing tomorrow. > -Martin > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From mrex@sap.com Wed Aug 10 20:57:23 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59ADB21F8A4F for ; Wed, 10 Aug 2011 20:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.848 X-Spam-Level: X-Spam-Status: No, score=-9.848 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSaNnZbAb665 for ; Wed, 10 Aug 2011 20:57:22 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 6424821F8A35 for ; Wed, 10 Aug 2011 20:57:22 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p7B3vmHr029011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 11 Aug 2011 05:57:53 +0200 (MEST) From: Martin Rex Message-Id: <201108110357.p7B3vm38020305@fs4113.wdf.sap.corp> To: ondrej.sury@nic.cz (=?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?=) Date: Thu, 11 Aug 2011 05:57:48 +0200 (MEST) In-Reply-To: <3CE7EC5A-4A66-41A1-AD61-436956CBF540@nic.cz> from "=?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?=" at Aug 9, 11 11:12:47 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] Call for consensus for CNAME X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 03:57:23 -0000 ondrej.sury@nic.cz wrote: > > I hereby make a call for a consensus on the CNAME issue. > > I am specifically asking you if you agree with current > contents of DANE protocol draft, which says that TLSA > queries and answers follows normal DNS resolution. > > To clarify - this call is about closing issue #24. Sorry for not > mentioning it in the call. +1 (I think). I'll note that find the 2nd/middle example in http://tools.ietf.org/html/draft-ietf-dane-protocol-09#appendix-A.1 midly confusing: ; TLSA record is duplicated in target domain ; sub5.example.com. IN CNAME sub6.example.com. _443_tcp.sub5.example.com. IN TLSA 2 0 308202c5308201ab... sub6.example.com. IN A 10.0.0.0 _443_tcp.sub6.example.com. IN TLSA 2 0 308202c5308201ab... because I believe the _intersection_ of clients asking for _443_tcp.sub5.example.com. and clients asking for _443_tcp.sub6.example.com. ought to be empty. -Martin From ondrej.sury@nic.cz Thu Aug 11 01:51:03 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56A7421F8B18 for ; Thu, 11 Aug 2011 01:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.58 X-Spam-Level: X-Spam-Status: No, score=-1.58 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDZX1pnsldqh for ; Thu, 11 Aug 2011 01:51:02 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 9F96521F86C7 for ; Thu, 11 Aug 2011 01:51:01 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:98ec:5317:70c9:e230] (unknown [IPv6:2001:1488:ac14:1400:98ec:5317:70c9:e230]) by mail.nic.cz (Postfix) with ESMTPSA id B9B3C2A2CB4; Thu, 11 Aug 2011 10:51:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1313052692; bh=pp2EwzOQycDW3mrrEf6VSZUIUraNmZcgSytUEefmZu0=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=CfRQWvmqbIr4xrml08lMqE1KGDRB+eg4V1chIh/M9mEAC0sXxBZbXiQyIuFbkrvi2 z/7iktohq3u1c2BA5+eR8OU3UBZlKaUG9ZHbHRDLCdXBl/EAmS6kcGBk4Vxr2Z2jjs f+O0Sp3rQupHOl0nworu5vz/cFQgaMQkkDiW9mgA= Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <201108110357.p7B3vm38020305@fs4113.wdf.sap.corp> Date: Thu, 11 Aug 2011 10:51:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <73DE2143-F9B2-4DD3-B301-B9FE1D872EC4@nic.cz> References: <201108110357.p7B3vm38020305@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1244.3) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane@ietf.org Subject: [dane] Clarifying 2nd CNAME example from dane-protocol draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 08:51:03 -0000 On 11. 8. 2011, at 5:57, Martin Rex wrote: > ondrej.sury@nic.cz wrote: >>=20 >> I hereby make a call for a consensus on the CNAME issue. >>=20 >> I am specifically asking you if you agree with current >> contents of DANE protocol draft, which says that TLSA >> queries and answers follows normal DNS resolution. >>=20 >> To clarify - this call is about closing issue #24. Sorry for not >> mentioning it in the call. >=20 > +1 (I think). >=20 >=20 > I'll note that find the 2nd/middle example in > http://tools.ietf.org/html/draft-ietf-dane-protocol-09#appendix-A.1 >=20 > midly confusing: >=20 > ; TLSA record is duplicated in target domain > ; > sub5.example.com. IN CNAME sub6.example.com. > _443_tcp.sub5.example.com. IN TLSA 2 0 308202c5308201ab... > sub6.example.com. IN A 10.0.0.0 > _443_tcp.sub6.example.com. IN TLSA 2 0 308202c5308201ab... >=20 > because I believe the _intersection_ > of clients asking for _443_tcp.sub5.example.com. True. > and clients asking for _443_tcp.sub6.example.com. > ought to be empty. Nope, you can have certificate for sub6.example.com. and clients accessing sub6.example.com. will ask for _443_tcp.sub6.example.com. The important thing is that _443_tcp.sub6.example.com. is not related to sub5.example.com. O. -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From fanf2@hermes.cam.ac.uk Thu Aug 11 02:01:36 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE5A921F8B02 for ; Thu, 11 Aug 2011 02:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.293 X-Spam-Level: X-Spam-Status: No, score=-6.293 tagged_above=-999 required=5 tests=[AWL=-0.294, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ko3WulMHYvr for ; Thu, 11 Aug 2011 02:01:36 -0700 (PDT) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id DDE0521F8AFE for ; Thu, 11 Aug 2011 02:01:35 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:48095) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1QrR9T-0004a3-rG (Exim 4.72) (return-path ); Thu, 11 Aug 2011 10:02:07 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1QrR9T-0005Wh-G2 (Exim 4.67) (return-path ); Thu, 11 Aug 2011 10:02:07 +0100 Date: Thu, 11 Aug 2011 10:02:07 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Martin Rex In-Reply-To: <201108110251.p7B2pajv016484@fs4113.wdf.sap.corp> Message-ID: References: <201108110251.p7B2pajv016484@fs4113.wdf.sap.corp> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 09:01:36 -0000 Martin Rex wrote: > > I somehow fail to see conformance to rfc6186 with respect to the > TLS server cert for both, MUAs and Server-to-Server, for @gmail.com SMTP. Do you have evidence of non-conformance for MUAs? Following Google's instructions gets me to servers that present valid certificates with the expected common name. http://mail.google.com/support/bin/answer.py?answer=78799 On the other hand, the situation with inter-domain SMTP+TLS is indeed a complete disaster. See http://www.imc.org/ietf-smtp/mail-archive/msg05366.html Tony. -- f.anthony.n.finch http://dotat.at/ Humber: Southwest 5 to 7, becoming cyclonic, then northeast 4 or 5 later. Moderate or rough. Occasional rain, fog patches. Moderate or good, occasionally very poor. From fanf2@hermes.cam.ac.uk Thu Aug 11 02:16:05 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC34821F89BE for ; Thu, 11 Aug 2011 02:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.581 X-Spam-Level: X-Spam-Status: No, score=-6.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5dGyV5p9eWs for ; Thu, 11 Aug 2011 02:16:04 -0700 (PDT) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0F3E021F8853 for ; Thu, 11 Aug 2011 02:16:03 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:54903) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1QrRNU-0007EI-QX (Exim 4.72) (return-path ); Thu, 11 Aug 2011 10:16:36 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1QrRNU-0007oV-6q (Exim 4.67) (return-path ); Thu, 11 Aug 2011 10:16:36 +0100 Date: Thu, 11 Aug 2011 10:16:36 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Mark Andrews In-Reply-To: <20110810234900.4324512B5401@drugs.dv.isc.org> Message-ID: References: <201108041415.p74EFdNS023238@fs4113.wdf.sap.corp> <20110810234900.4324512B5401@drugs.dv.isc.org> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 09:16:05 -0000 Mark Andrews wrote: > > There is no contradition above. SMTP AUTH is useless unless the entire > path to identify the server is secure. The above is saying don't do > SMTP AUTH unless you have *secure* referrals. DNSSEC gives you secure > referrals. It isn't saying ignore the referrals. But see the text in RFC 6125 about "derived" domains (i.e. targets of SRV and MX etc.), for instance: Each reference identifier in the list SHOULD be based on the source domain and SHOULD NOT be based on a derived domain (e.g., a host name or domain name discovered through DNS resolution of the source domain). This rule is important because only a match between the user inputs and a presented identifier enables the client to be sure that the certificate can legitimately be used to secure the client's communication with the server. There is only one scenario in which it is acceptable for an interactive client to override the recommendation in this rule and therefore communicate with a domain name other than the source domain: because a human user has "pinned" the application service's certificate to the alternative domain name as further discussed under Section 6.6.4 and Section 7.1. You are suggesting that in the presence of DNSSEC the app should check the certificate against the derived domain instead of the source domain. This would be a big change to standard practice, and it would add a lot of complexity to certificate verification code. What benefits would it actually provide? The stuff in SMTP about servers exchanging their hostnames is for debugging. It has nothing to do with automated server name authentication. Tony. -- f.anthony.n.finch http://dotat.at/ South Biscay: Variable 3 or 4. Slight or moderate. Fair. Good. From hallam@gmail.com Thu Aug 11 04:06:13 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3EDC21F8A64 for ; Thu, 11 Aug 2011 04:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.447 X-Spam-Level: X-Spam-Status: No, score=-3.447 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ERRGh-OPa+Ty for ; Thu, 11 Aug 2011 04:06:13 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 028E321F8888 for ; Thu, 11 Aug 2011 04:06:12 -0700 (PDT) Received: by gyf3 with SMTP id 3so1449575gyf.31 for ; Thu, 11 Aug 2011 04:06:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=T2CdLiLtSoO0n9+YQCGsGS3MB9St6RYBl66DjUxtsN8=; b=sxQtEqd0MJoSRsII0bvzVlpzkvHeMdY7IzqCZkoe+xdfWMe54GiKS8DTJPjv8ULMjQ 8K12JNoh08/MOukhTypef1ZRQDxWhBKY/wmZo0lyXJ8LhExwV6FfgOwlMk6n6X8OzH+8 XBkl/TRDSaAcGpR4mTetQ/YlSARLnxtV9Lals= MIME-Version: 1.0 Received: by 10.101.164.25 with SMTP id r25mr8361425ano.94.1313060806866; Thu, 11 Aug 2011 04:06:46 -0700 (PDT) Received: by 10.100.34.3 with HTTP; Thu, 11 Aug 2011 04:06:46 -0700 (PDT) In-Reply-To: <20110811030142.7A1BB12B6FCB@drugs.dv.isc.org> References: <201108110251.p7B2pajv016484@fs4113.wdf.sap.corp> <20110811030142.7A1BB12B6FCB@drugs.dv.isc.org> Date: Thu, 11 Aug 2011 12:06:46 +0100 Message-ID: From: Phillip Hallam-Baker To: Mark Andrews Content-Type: multipart/alternative; boundary=0016e6d26d72f638aa04aa38ca7b Cc: dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 11:06:13 -0000 --0016e6d26d72f638aa04aa38ca7b Content-Type: text/plain; charset=ISO-8859-1 On Thu, Aug 11, 2011 at 4:01 AM, Mark Andrews wrote: > > Just because operators are doing the wrong thing today it doesn't mean > they can't do the right thing tomorrow. And you think that we get to decide what is the right way? There are several million of them and twenty of us. You don't listen to them so why on earth would they bother to listen to you? The Internet is defined by actual bits on actual wires. -- Website: http://hallambaker.com/ --0016e6d26d72f638aa04aa38ca7b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Aug 11, 2011 at 4:01 AM, Mark An= drews <marka@isc.org<= /a>> wrote:

Just because operators are doing the wrong thing today it doesn't= mean
they can't do the right thing tomorrow.

And you think that we get to decide what is the right way?

--
Website: http://hallambaker.com/

--0016e6d26d72f638aa04aa38ca7b-- From hallam@gmail.com Thu Aug 11 04:10:21 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDD7D21F8A64 for ; Thu, 11 Aug 2011 04:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LbU6VRsOro96 for ; Thu, 11 Aug 2011 04:10:15 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id C1B2921F86AB for ; Thu, 11 Aug 2011 04:10:15 -0700 (PDT) Received: by yxp4 with SMTP id 4so1448178yxp.31 for ; Thu, 11 Aug 2011 04:10:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5ecOfv2fvKaX1EyKN/F3rgtcXxQdd7hVU3gVJNoyMXg=; b=EgO48DoZr7tDFVix+Z882q2JCDSC0Z8sey2MBbfWztoHqpqPJBLqPtv9w4975I95YU T4nW8kqGCR568qW18696jVy6zUayfGItbXyofENSM8PXnj9O0KpSSVdPAUHV8+s1FGdR ppfcIJ0kLwxgiCcx+UO8cDLk+c8vmbhE/h0i4= MIME-Version: 1.0 Received: by 10.101.190.6 with SMTP id s6mr8271372anp.50.1313061041048; Thu, 11 Aug 2011 04:10:41 -0700 (PDT) Received: by 10.100.34.3 with HTTP; Thu, 11 Aug 2011 04:10:40 -0700 (PDT) In-Reply-To: References: <201108110251.p7B2pajv016484@fs4113.wdf.sap.corp> Date: Thu, 11 Aug 2011 12:10:40 +0100 Message-ID: From: Phillip Hallam-Baker To: Tony Finch Content-Type: multipart/alternative; boundary=00163691fc2deb8bde04aa38d888 Cc: dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 11:10:21 -0000 --00163691fc2deb8bde04aa38d888 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Aug 11, 2011 at 10:02 AM, Tony Finch wrote: > Martin Rex wrote: > > > > I somehow fail to see conformance to rfc6186 with respect to the > > TLS server cert for both, MUAs and Server-to-Server, for @gmail.comSMTP. > > Do you have evidence of non-conformance for MUAs? Following Google's > instructions gets me to servers that present valid certificates with the > expected common name. > http://mail.google.com/support/bin/answer.py?answer=78799 > > On the other hand, the situation with inter-domain SMTP+TLS is indeed a > complete disaster. See > http://www.imc.org/ietf-smtp/mail-archive/msg05366.html No question this is a disaster, but how to fix it. The only way that I can see to fix it is to automate the process of installing the cert and the DNS advertisement that there is a cert in use and having the mail server check that its actions are consistent with externally advertised policy. In other words, I don't think that we have any chance of modifying user behavior or educating administrators. What we might have a chance with is to deploy code that causes the right thing to be done. -- Website: http://hallambaker.com/ --00163691fc2deb8bde04aa38d888 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Aug 11, 2011 at 10:02 AM, Tony F= inch <dot@dotat.at= > wrote:
Martin Rex <mrex@sap.c= om> wrote:
>
> I somehow fail to see conformance to rfc6186 w= ith respect to the
> TLS server cert for both, MUAs and Server-to-Server, for @gmail.com SMTP.

Do you have evidence of non-conformance for MUAs? Following Google= 9;s
instructions gets me to servers that present valid certificates with the expected common name.
http://mail.google.com/support/bin/answer.py?answer=3D78799<= /a>

On the other hand, the situation with inter-domain SMTP+TLS is indeed a
complete disaster. See http://www.imc.org/ietf-smtp/mail-archive= /msg05366.html

No question this is a di= saster, but how to fix it.

The only way that I can see to fix it is to automate th= e process of installing the cert and the DNS advertisement that there is a = cert in use and having the mail server check that its actions are consisten= t with externally advertised policy.


In other words, I don't think that w= e have any chance of modifying user behavior or educating administrators. W= hat we might have a chance with is to deploy code that causes the right thi= ng to be done.
=A0
--
Website: htt= p://hallambaker.com/

--00163691fc2deb8bde04aa38d888-- From fanf2@hermes.cam.ac.uk Thu Aug 11 05:08:22 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D28F921F8A71 for ; Thu, 11 Aug 2011 05:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.582 X-Spam-Level: X-Spam-Status: No, score=-6.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vg+rQz2zHbac for ; Thu, 11 Aug 2011 05:08:22 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id 03A2021F85FF for ; Thu, 11 Aug 2011 05:08:21 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:33576) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1QrU4F-0007SG-XD (Exim 4.72) (return-path ); Thu, 11 Aug 2011 13:08:55 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1QrU4F-00070v-9F (Exim 4.67) (return-path ); Thu, 11 Aug 2011 13:08:55 +0100 Date: Thu, 11 Aug 2011 13:08:55 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <201108110251.p7B2pajv016484@fs4113.wdf.sap.corp> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 12:08:22 -0000 Phillip Hallam-Baker wrote: > > No question this is a disaster, but how to fix it. Restrict the existing STARTTLS extension to message submission only (it works fine in that context). Create a new TLS service extension for inter-domain SMTP which has clear requirements for which identities the certificates authenticate and how they must be verified. Tony. -- f.anthony.n.finch http://dotat.at/ Hebrides, Bailey: East or northeast, 5 to 7, decreasing 4 for a time. Moderate or rough. Rain. Moderate or good. From oej@edvina.net Thu Aug 11 05:29:50 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6EC621F88DC for ; Thu, 11 Aug 2011 05:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v60eN8qoPtrb for ; Thu, 11 Aug 2011 05:29:50 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 9407C21F888A for ; Thu, 11 Aug 2011 05:29:47 -0700 (PDT) Received: from [IPv6:2001:470:1f15:d79:f8a4:a377:8bdb:f615] (unknown [IPv6:2001:470:1f15:d79:f8a4:a377:8bdb:f615]) by smtp7.webway.se (Postfix) with ESMTPA id 10BBC754BD0D; Thu, 11 Aug 2011 12:30:18 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: "Olle E. Johansson" In-Reply-To: Date: Thu, 11 Aug 2011 14:30:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <433AE615-2828-483F-A30E-168A39B6C83A@edvina.net> References: <201108110251.p7B2pajv016484@fs4113.wdf.sap.corp> To: Tony Finch X-Mailer: Apple Mail (2.1244.3) Cc: dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 12:29:50 -0000 11 aug 2011 kl. 14:08 skrev Tony Finch: > Phillip Hallam-Baker wrote: >>=20 >> No question this is a disaster, but how to fix it. >=20 > Restrict the existing STARTTLS extension to message submission only = (it > works fine in that context). Create a new TLS service extension for > inter-domain SMTP which has clear requirements for which identities = the > certificates authenticate and how they must be verified. >=20 The same issues exist in SIP where it's still unclear to most developers = what the SIp server certificate needs to have in CN and subj alt names. = Current proposals include IP-adresses. /O From i.grok@comcast.net Thu Aug 11 05:39:35 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 966B621F86BD for ; Thu, 11 Aug 2011 05:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.651 X-Spam-Level: X-Spam-Status: No, score=-102.651 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-59MLGKU7Km for ; Thu, 11 Aug 2011 05:39:35 -0700 (PDT) Received: from qmta14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [76.96.27.212]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5EC21F85DE for ; Thu, 11 Aug 2011 05:39:35 -0700 (PDT) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta14.emeryville.ca.mail.comcast.net with comcast id K0H61h0071u4NiLAE0g5Tb; Thu, 11 Aug 2011 12:40:05 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta21.emeryville.ca.mail.comcast.net with comcast id K0fz1h00H00PQ6U8h0g0oK; Thu, 11 Aug 2011 12:40:00 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.4/8.14.3) with ESMTP id p7BCe6BY015339 for ; Thu, 11 Aug 2011 08:40:06 -0400 Received: (from draco@localhost) by odin.ulthar.us (8.14.4/8.14.4/Submit) id p7BCe6MU015337 for dane@ietf.org; Thu, 11 Aug 2011 08:40:06 -0400 Date: Thu, 11 Aug 2011 08:40:06 -0400 From: Scott Schmit To: dane@ietf.org Message-ID: <20110811124006.GA14341@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <3CE7EC5A-4A66-41A1-AD61-436956CBF540@nic.cz> <201108110357.p7B3vm38020305@fs4113.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201108110357.p7B3vm38020305@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Call for consensus for CNAME X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 12:39:35 -0000 On Thu, Aug 11, 2011 at 05:57:48AM +0200, Martin Rex wrote: > I'll note that find the 2nd/middle example in > http://tools.ietf.org/html/draft-ietf-dane-protocol-09#appendix-A.1 > > midly confusing: > > ; TLSA record is duplicated in target domain > ; > sub5.example.com. IN CNAME sub6.example.com. > _443_tcp.sub5.example.com. IN TLSA 2 0 308202c5308201ab... > sub6.example.com. IN A 10.0.0.0 > _443_tcp.sub6.example.com. IN TLSA 2 0 308202c5308201ab... > > because I believe the _intersection_ > of clients asking for _443_tcp.sub5.example.com. > and clients asking for _443_tcp.sub6.example.com. > ought to be empty. Stronger than that, no one should be querying for either TLSA record at all. The prefix should be "_443._tcp" and not "_443_tcp". -- Scott Schmit From mrex@sap.com Thu Aug 11 06:51:11 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 704EE21F8B0A for ; Thu, 11 Aug 2011 06:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.849 X-Spam-Level: X-Spam-Status: No, score=-9.849 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uxiv9hBipll9 for ; Thu, 11 Aug 2011 06:51:11 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id A92D421F8AF8 for ; Thu, 11 Aug 2011 06:51:10 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p7BDpgaH020681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 11 Aug 2011 15:51:42 +0200 (MEST) From: Martin Rex Message-Id: <201108111351.p7BDpfbE023481@fs4113.wdf.sap.corp> To: ondrej.sury@nic.cz (=?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?=) Date: Thu, 11 Aug 2011 15:51:41 +0200 (MEST) In-Reply-To: <73DE2143-F9B2-4DD3-B301-B9FE1D872EC4@nic.cz> from "=?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?=" at Aug 11, 11 10:51:32 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] Clarifying 2nd CNAME example from dane-protocol draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 13:51:11 -0000 =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= wrote: > > On 11. 8. 2011, at 5:57, Martin Rex wrote: > > > > I'll note that find the 2nd/middle example in > > http://tools.ietf.org/html/draft-ietf-dane-protocol-09#appendix-A.1 > > > > midly confusing: > > > > ; TLSA record is duplicated in target domain > > ; > > sub5.example.com. IN CNAME sub6.example.com. > > _443_tcp.sub5.example.com. IN TLSA 2 0 308202c5308201ab... > > sub6.example.com. IN A 10.0.0.0 > > _443_tcp.sub6.example.com. IN TLSA 2 0 308202c5308201ab... btw. shouldn't there be a dot between port number an protocol? _443._tcp.sub5.example.com. IN TLSA 2 0 308202c5308201ab... ^ > > > > because I believe the _intersection_ > > of clients asking for _443_tcp.sub5.example.com. > > True. > > > and clients asking for _443_tcp.sub6.example.com. > > ought to be empty. > > > Nope, you can have certificate for sub6.example.com. and clients > accessing sub6.example.com. will ask for _443_tcp.sub6.example.com. Of course, you can. > > The important thing is that _443_tcp.sub6.example.com. is not related > to sub5.example.com. Yes. I failed to explain what I meant... What I meant to say is that for clients that want to connect to sub5.example.com, the TLSA record _443._tcp.sub6.example.com is _not_ a fallback / alternative. That should only be of interest to clients connecting to sub6.example.com. -Martin From ondrej.sury@nic.cz Thu Aug 11 06:54:16 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D545C21F86BA for ; Thu, 11 Aug 2011 06:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.59 X-Spam-Level: X-Spam-Status: No, score=-1.59 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-g3DgYM-XYX for ; Thu, 11 Aug 2011 06:54:03 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id BADEA21F865F for ; Thu, 11 Aug 2011 06:54:03 -0700 (PDT) Received: from kimac.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 1B2E42A0A03; Thu, 11 Aug 2011 15:54:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1313070877; bh=fGvkN1YZ3fUubx76RWCyOHfmEsljTfTe/oIfkOVEJO8=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=xh4aJ14G/h6XDmJwKdbCELuHaofePIR5GumBysfyqoH3MgOtdL6Hr+p7jE8+I/EIF 4pLGtOBD+rLC1SCVgkiaSDNb0fzoPb4iVIFDbhoa3uqXWa2ENJEE2qF05aTAlMajQ8 9Mim7HqMVY29ITkc0bpdFWDGxZeN3NyieRNFn428= Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <20110811124006.GA14341@odin.ulthar.us> Date: Thu, 11 Aug 2011 15:54:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3DEA9C22-F580-4698-9522-C9F4CBE40946@nic.cz> References: <3CE7EC5A-4A66-41A1-AD61-436956CBF540@nic.cz> <201108110357.p7B3vm38020305@fs4113.wdf.sap.corp> <20110811124006.GA14341@odin.ulthar.us> To: Scott Schmit , Paul Hoffman , Jakob Schlyter X-Mailer: Apple Mail (2.1244.3) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane@ietf.org Subject: [dane] Typo in Appendix.A _port_proto vs _port._proto X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 13:54:16 -0000 On 11. 8. 2011, at 14:40, Scott Schmit wrote: > On Thu, Aug 11, 2011 at 05:57:48AM +0200, Martin Rex wrote: >> I'll note that find the 2nd/middle example in >> http://tools.ietf.org/html/draft-ietf-dane-protocol-09#appendix-A.1 >>=20 >> midly confusing: >>=20 >> ; TLSA record is duplicated in target domain >> ; >> sub5.example.com. IN CNAME sub6.example.com. >> _443_tcp.sub5.example.com. IN TLSA 2 0 308202c5308201ab... >> sub6.example.com. IN A 10.0.0.0 >> _443_tcp.sub6.example.com. IN TLSA 2 0 308202c5308201ab... >>=20 >> because I believe the _intersection_ >> of clients asking for _443_tcp.sub5.example.com. >> and clients asking for _443_tcp.sub6.example.com. >> ought to be empty. >=20 > Stronger than that, no one should be querying for either TLSA record = at > all. The prefix should be "_443._tcp" and not "_443_tcp". Scott, Good catch, thanks. I believe this is just a typo. Paul, Jakob, care = to fix that in next version of the draft? Thanks, -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From ondrej.sury@nic.cz Thu Aug 11 06:57:53 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 895AC21F86C2 for ; Thu, 11 Aug 2011 06:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id djZcsFL8yb50 for ; Thu, 11 Aug 2011 06:57:53 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id E5CD121F86BC for ; Thu, 11 Aug 2011 06:57:52 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:98ec:5317:70c9:e230] (unknown [IPv6:2001:1488:ac14:1400:98ec:5317:70c9:e230]) by mail.nic.cz (Postfix) with ESMTPSA id E5B8C2A2AD0; Thu, 11 Aug 2011 15:58:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1313071106; bh=wpGkrdXT3PcIHVpAEKPmCvUDF9KvqL8Q8QKpNEh976M=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=J2ICYCp0M0QmsDecfscnbwZN3WvfCTY6VGZMqLapncEbfRug51x70/aUeSfylNwzm YvzTFNeIRceyzUdiwqYTDzTWuiSX+nomylAwGqlqS6/KJZeDGg5aNgDXijXgJ4XTFJ gWHzFjH7uDvssLXBBUmjFZUdFO9uD66rM+/8zwto= Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <201108111351.p7BDpfbE023481@fs4113.wdf.sap.corp> Date: Thu, 11 Aug 2011 15:58:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201108111351.p7BDpfbE023481@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1244.3) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane@ietf.org Subject: Re: [dane] Clarifying 2nd CNAME example from dane-protocol draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 13:57:53 -0000 On 11. 8. 2011, at 15:51, Martin Rex wrote: > btw. shouldn't there be a dot between port number an protocol? >=20 > _443._tcp.sub5.example.com. IN TLSA 2 0 308202c5308201ab... > ^ Yep, I already pinged Paul and Jakob. > I failed to explain what I meant... >=20 > What I meant to say is that for clients that want to connect to > sub5.example.com, the TLSA record _443._tcp.sub6.example.com > is _not_ a fallback / alternative. That should only be of interest > to clients connecting to sub6.example.com. That's correct. O. -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From jakob@kirei.se Thu Aug 11 06:59:26 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A95A21F8757 for ; Thu, 11 Aug 2011 06:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.459 X-Spam-Level: X-Spam-Status: No, score=-0.459 tagged_above=-999 required=5 tests=[AWL=-0.061, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58aQjK34TpqN for ; Thu, 11 Aug 2011 06:59:26 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id 8402E21F86C4 for ; Thu, 11 Aug 2011 06:59:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=UOTa+5TfoaWz58x4RUYcqzUZF7sHC5M66Yc/q9AXMes=; b=FRctNyrgFl2mXNVK+PQy5og/HQbGSUGGuwRsc1HBhKWSiXgyi8mmEt9r/UjJeqEWju6JagrMJTcpe foRErNnTpMw4CrqC4IWHhPMWH0kRcy1oXogeWOPn8gdypYKoXh1Aj9eAwSrOsXo8xfGdJGDbKORXcq pqpRxRaAmQsb5Uus= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Thu, 11 Aug 2011 15:59:57 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=utf-8 From: Jakob Schlyter In-Reply-To: <3DEA9C22-F580-4698-9522-C9F4CBE40946@nic.cz> Date: Thu, 11 Aug 2011 15:59:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6E6D4CB6-6E9C-44A1-979C-5F2FC4D5BB8C@kirei.se> References: <3CE7EC5A-4A66-41A1-AD61-436956CBF540@nic.cz> <201108110357.p7B3vm38020305@fs4113.wdf.sap.corp> <20110811124006.GA14341@odin.ulthar.us> <3DEA9C22-F580-4698-9522-C9F4CBE40946@nic.cz> To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= X-Mailer: Apple Mail (2.1244.3) Cc: Paul Hoffman , dane@ietf.org Subject: Re: [dane] Typo in Appendix.A _port_proto vs _port._proto X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 13:59:26 -0000 On 11 aug 2011, at 15:54, Ond=C5=99ej Sur=C3=BD wrote: > Good catch, thanks. I believe this is just a typo. Paul, Jakob, care = to > fix that in next version of the draft? Yes, it is already fixed. jakob From mlarson@verisign.com Thu Aug 11 08:15:01 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 891DC21F8B10 for ; Thu, 11 Aug 2011 08:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdrA27vz6w61 for ; Thu, 11 Aug 2011 08:15:01 -0700 (PDT) Received: from exprod6og103.obsmtp.com (exprod6og103.obsmtp.com [64.18.1.185]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6BA21F8B0E for ; Thu, 11 Aug 2011 08:15:00 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob103.postini.com ([64.18.5.12]) with SMTP ID DSNKTkPyFmCSiKanfcqQv47jSdPT5fCrSKnN@postini.com; Thu, 11 Aug 2011 08:15:35 PDT Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id p7BFFYSK002674 for ; Thu, 11 Aug 2011 11:15:34 -0400 Received: from DUL1MLARSON-M2 ([10.131.29.4]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 11 Aug 2011 11:15:33 -0400 Date: Thu, 11 Aug 2011 11:15:34 -0400 From: Matt Larson To: dane@ietf.org Message-ID: <20110811151533.GR55272@DUL1MLARSON-M2.vcorp.ad.vrsn.com> References: <6B5F4F0A-82F2-4911-81B6-F923D7529E4A@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6B5F4F0A-82F2-4911-81B6-F923D7529E4A@nic.cz> User-Agent: Mutt/1.5.21 (2010-09-15) X-OriginalArrivalTime: 11 Aug 2011 15:15:33.0688 (UTC) FILETIME=[83F0D380:01CC5839] Subject: Re: [dane] Call for consensus for CNAME X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 15:15:01 -0000 On Tue, 09 Aug 2011, Ond??ej Sur wrote: > Please respond just with +1/-1, we already had a lengthy > discussion on the subject and it doesn't seem to develop > anywhere in last few days. +1 Matt From sm@resistor.net Thu Aug 11 08:45:03 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81D4921F8B46 for ; Thu, 11 Aug 2011 08:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LjcpgkJZYl1C for ; Thu, 11 Aug 2011 08:45:00 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9603621F8781 for ; Thu, 11 Aug 2011 08:45:00 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5.Beta0) with ESMTP id p7BFjNoZ024809; Thu, 11 Aug 2011 08:45:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1313077528; bh=JkGf+nPjy3XuU+/pXF5LXT5D0OOO+/sBxSPZURUFqtM=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=orrD37SdXEoRmgzi/3594ROJQ81ML0F3HEgdXJcNkjKhpt9Ea91eNF8X4GsuBFy+s 463xVpOmYChFQpsBo/EuuqgLN97D8RFOMgQx7f1tK7+EoOB/8pqXRHcp6I/RHxerR4 ESTv4IYZ0TFfVvOe8TJ4KfJ64V08YFvW/Z0EbX8w= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1313077528; bh=JkGf+nPjy3XuU+/pXF5LXT5D0OOO+/sBxSPZURUFqtM=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=J8ya0ieIslo6Bx/Ljkj+8SqZGzZljkyxmqV09yYtQMTrkb6skv+TaH932jkj2ThF3 tBupHE7DjzkzIF5TPH/KNm06bvwEILE7E9ysFTYY2GEl5Tvdl3bFBa9gIdO9V24brv NXC9EEB6iF11bAuoO3Jcthkdgsxe7oFb3AY7mAN4= Message-Id: <6.2.5.6.2.20110811081506.0bbc3238@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 11 Aug 2011 08:21:11 -0700 To: "Olle E. Johansson" From: SM In-Reply-To: <433AE615-2828-483F-A30E-168A39B6C83A@edvina.net> References: <201108110251.p7B2pajv016484@fs4113.wdf.sap.corp> <433AE615-2828-483F-A30E-168A39B6C83A@edvina.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 15:45:03 -0000 Hi Olle, At 05:30 11-08-2011, Olle E. Johansson wrote: >The same issues exist in SIP where it's still unclear to most >developers what the SIp server certificate needs to have in CN and >subj alt names. Current proposals include IP-adresses. RFC 6125 discusses about application service identity verification. Regards, -sm From oej@edvina.net Thu Aug 11 08:48:15 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67F0021F8B63 for ; Thu, 11 Aug 2011 08:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORhPpkpmjAgp for ; Thu, 11 Aug 2011 08:48:15 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id BE21421F8751 for ; Thu, 11 Aug 2011 08:48:14 -0700 (PDT) Received: from [192.168.40.44] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id EE586754BD0D; Thu, 11 Aug 2011 15:48:46 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: "Olle E. Johansson" In-Reply-To: <6.2.5.6.2.20110811081506.0bbc3238@resistor.net> Date: Thu, 11 Aug 2011 17:48:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201108110251.p7B2pajv016484@fs4113.wdf.sap.corp> <433AE615-2828-483F-A30E-168A39B6C83A@edvina.net> <6.2.5.6.2.20110811081506.0bbc3238@resistor.net> To: SM X-Mailer: Apple Mail (2.1244.3) Cc: dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 15:48:15 -0000 11 aug 2011 kl. 17:21 skrev SM: > Hi Olle, > At 05:30 11-08-2011, Olle E. Johansson wrote: >> The same issues exist in SIP where it's still unclear to most = developers what the SIp server certificate needs to have in CN and subj = alt names. Current proposals include IP-adresses. >=20 > RFC 6125 discusses about application service identity verification. yes, and in addition to that, there's an RFC for SIP certificates and = the big confusion about SIPS: as an URI. Believe me, developers are very = confused and it's a big mess involving usage of IP adresses in headers = that we need to match to certificates. But thanks for the feedback :-) /O= From sm@resistor.net Thu Aug 11 12:02:08 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51A9921F882E for ; Thu, 11 Aug 2011 12:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8xE8XXHDBdI for ; Thu, 11 Aug 2011 12:02:06 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 24F5C21F89C2 for ; Thu, 11 Aug 2011 12:02:06 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5) with ESMTP id p7BJ2Tjg027036; Thu, 11 Aug 2011 12:02:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1313089355; bh=G1U3b+F9HYVYEPORpyKvW01H1yb9gQmSXfQp8D0al5Q=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=KhkcJLVEOBlnVr8qWd05VG1J5fjxR/9+vrV+Bsoi1p5ku8xXWCu8/nmTu2HpHo79V Lyenj0zkORjEFbL8hnUB0ZKqg1y0QlFpQFwrfwnYk3Y1moWLv60O3cu5y8mxYqdhNl i6oycTsWqgwDcuCsGadOv8u51srMTRnmYATzO96U= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1313089355; bh=G1U3b+F9HYVYEPORpyKvW01H1yb9gQmSXfQp8D0al5Q=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=GlPdR2UwaqXtSLrDgY6seQ07jvhUUc97jhJUXPKNVtcp1gkbZAAfxZWBRmB0+8FUL SigNmTY4XJxapU45l0GiXwCBNF67snA87UiMDuTG5f0N3NUpTYaB56KWFAix0AyiEZ Lm5dmhur15EJ8CAHt5whYvsAZ9AZQ5GZkQ3hMKsk= Message-Id: <6.2.5.6.2.20110811112837.0a675180@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 11 Aug 2011 12:01:16 -0700 To: "Olle E. Johansson" From: SM In-Reply-To: References: <201108110251.p7B2pajv016484@fs4113.wdf.sap.corp> <433AE615-2828-483F-A30E-168A39B6C83A@edvina.net> <6.2.5.6.2.20110811081506.0bbc3238@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 19:02:08 -0000 Hi Olle, At 08:48 11-08-2011, Olle E. Johansson wrote: >yes, and in addition to that, there's an RFC for SIP certificates >and the big confusion about SIPS: as an URI. Believe me, developers >are very confused and it's a big mess involving usage of IP adresses >in headers that we need to match to certificates. Section 1.7.2 of RFC 6125 mentions that IP addresses are out of scope. Although RFC 6125 does not update RFC 5922, the intent is for application services to use the advice in RFC 6125 for future specifications and for updates to existing specifications. There are several people with an interest in URI on the apps-discuss@ietf.org mailing list. You could ask about SIPS: as a URI on that list. Regards, -sm From marka@isc.org Thu Aug 11 20:01:57 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D62A121F84FC for ; Thu, 11 Aug 2011 20:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hdAhBupDqcpP for ; Thu, 11 Aug 2011 20:01:56 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC0321F869D for ; Thu, 11 Aug 2011 20:01:56 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 4369EC953C; Fri, 12 Aug 2011 03:01:36 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id B957D216C80; Fri, 12 Aug 2011 03:01:35 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id E5C3B12BE2BD; Fri, 12 Aug 2011 13:01:32 +1000 (EST) To: Tony Finch From: Mark Andrews References: <201108041415.p74EFdNS023238@fs4113.wdf.sap.corp> <20110810234900.4324512B5401@drugs.dv.isc.org> In-reply-to: Your message of "Thu, 11 Aug 2011 10:16:36 +0100." Date: Fri, 12 Aug 2011 13:01:32 +1000 Message-Id: <20110812030132.E5C3B12BE2BD@drugs.dv.isc.org> Cc: dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 03:01:58 -0000 In message , Tony Fin ch writes: > Mark Andrews wrote: > > > > There is no contradition above. SMTP AUTH is useless unless the entire > > path to identify the server is secure. The above is saying don't do > > SMTP AUTH unless you have *secure* referrals. DNSSEC gives you secure > > referrals. It isn't saying ignore the referrals. > > But see the text in RFC 6125 about "derived" domains (i.e. targets of SRV > and MX etc.), for instance: > > Each reference identifier in the list SHOULD be based on the source > domain and SHOULD NOT be based on a derived domain (e.g., a host name > or domain name discovered through DNS resolution of the source > domain). This rule is important because only a match between the > user inputs and a presented identifier enables the client to be sure > that the certificate can legitimately be used to secure the client's > communication with the server. There is only one scenario in which > it is acceptable for an interactive client to override the > recommendation in this rule and therefore communicate with a domain > name other than the source domain: because a human user has "pinned" > the application service's certificate to the alternative domain name > as further discussed under Section 6.6.4 and Section 7.1. I would argue that SMTP is the exception that SHOULD was designed for. SMTP is store and forward. SUBMISSION is direct. HTTP is direct. SIP is direct. A large proportion of Australia's email was delivered via a wildcard MX record at one stage. Are you saying that the relay should have a signature for every address covered by the MX? Note: no sane CA would have issued a wildcard cert for that level of the heirarchy. Are you saying that communication to the relay shouldn't be protected by TLS. > You are suggesting that in the presence of DNSSEC the app should check the > certificate against the derived domain instead of the source domain. This > would be a big change to standard practice, and it would add a lot of > complexity to certificate verification code. What benefits would it > actually provide? > > The stuff in SMTP about servers exchanging their hostnames is for > debugging. It has nothing to do with automated server name authentication. > > Tony. > -- > f.anthony.n.finch http://dotat.at/ > South Biscay: Variable 3 or 4. Slight or moderate. Fair. Good. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From fanf2@hermes.cam.ac.uk Fri Aug 12 01:25:39 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46F7621F85C4 for ; Fri, 12 Aug 2011 01:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.582 X-Spam-Level: X-Spam-Status: No, score=-6.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hc-86-CS5Oin for ; Fri, 12 Aug 2011 01:25:38 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id 280A121F85BB for ; Fri, 12 Aug 2011 01:25:38 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:59906) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1Qrn3k-0006uc-Z8 (Exim 4.72) (return-path ); Fri, 12 Aug 2011 09:25:40 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Qrn3k-00062I-S3 (Exim 4.67) (return-path ); Fri, 12 Aug 2011 09:25:40 +0100 Date: Fri, 12 Aug 2011 09:25:40 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Mark Andrews In-Reply-To: <20110812030132.E5C3B12BE2BD@drugs.dv.isc.org> Message-ID: References: <201108041415.p74EFdNS023238@fs4113.wdf.sap.corp> <20110810234900.4324512B5401@drugs.dv.isc.org> <20110812030132.E5C3B12BE2BD@drugs.dv.isc.org> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 08:25:39 -0000 Mark Andrews wrote: > > Are you saying that the relay should have a signature for every address > covered by the MX? In the absence of DNSSEC that is the only thing that makes sense. Tony. -- f.anthony.n.finch http://dotat.at/ North Utsire, South Utsire: Variable, becoming southeasterly, 3 or 4, increasing 5 or 6. Slight, occasionally moderate. Fair. Good. From jakob@kirei.se Fri Aug 12 02:49:15 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A715A21F8764 for ; Fri, 12 Aug 2011 02:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.607 X-Spam-Level: X-Spam-Status: No, score=-0.607 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Ap+s1yP0Db3 for ; Fri, 12 Aug 2011 02:49:14 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id B8E0C21F86D7 for ; Fri, 12 Aug 2011 02:49:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=qYd7Gy7BKD9mmjMpMU0Ho4y1ZZAJBDsPy/wqttmF3Kw=; b=ZtJIDxpVMZCJ1kpsqr6FIhUbdJJhCRoDs85ownZEL2pjiWFsxy6wxSsYulFh1u12iLTUGDW4i3KoV 9ar1opzpTJqGqq4yxR4ITU/0dF+r23eR7lUTVZecmM4VKYZz9VY3CawFXC1Sdurx3s7DEqICql1UuM di8sEQFi5WSKA0a0= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Fri, 12 Aug 2011 11:49:43 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: Date: Fri, 12 Aug 2011 11:49:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <92ACEFFC-FD11-4A1F-821F-ECDDA5C41A1B@kirei.se> References: <201108041415.p74EFdNS023238@fs4113.wdf.sap.corp> <20110810234900.4324512B5401@drugs.dv.isc.org> <20110812030132.E5C3B12BE2BD@drugs.dv.isc.org> To: Tony Finch X-Mailer: Apple Mail (2.1244.3) Cc: dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 09:49:15 -0000 On 12 aug 2011, at 10:25, Tony Finch wrote: > Mark Andrews wrote: >>=20 >> Are you saying that the relay should have a signature for every = address >> covered by the MX? >=20 > In the absence of DNSSEC that is the only thing that makes sense. In some theoretical world perhaps, but for people doing real operations. = Google or any other large scale mail hosting provider would simply = ignore such a requirement. We can do better now that we have DNSSEC. We can do service to server = mapping (e.g., MX or SRV) in a secure way and we can do secure server to = certificate mapping (i.e., DANE) as well. Such an architecture would be = both secure and deployable. jakob From hallam@gmail.com Fri Aug 12 03:33:01 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 624AE21F8665 for ; Fri, 12 Aug 2011 03:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.447 X-Spam-Level: X-Spam-Status: No, score=-3.447 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxymFYvyTezt for ; Fri, 12 Aug 2011 03:33:00 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 718C921F84EC for ; Fri, 12 Aug 2011 03:33:00 -0700 (PDT) Received: by yie12 with SMTP id 12so2192117yie.31 for ; Fri, 12 Aug 2011 03:33:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=rYdtK1UmiQL3qu632EleVtY65ArpdttN8apLbnWKU9k=; b=HbyuprQtplYEUg4YndJPqdYT8ioW0k7Z9TK7H39A3DhrzmiWWP96GVsud3bDh73E2Z g++Uya4H4ATPbImXXMSSZIf9V8JN6sXeFjrZL9Zl359NWrJaGuWfePtzdLhnxcotMi+2 appe6yhfLzdcwNHDfZ7r20lEG6QkpfzTO6MZM= MIME-Version: 1.0 Received: by 10.100.250.1 with SMTP id x1mr767943anh.58.1313145213304; Fri, 12 Aug 2011 03:33:33 -0700 (PDT) Received: by 10.100.227.8 with HTTP; Fri, 12 Aug 2011 03:33:33 -0700 (PDT) Date: Fri, 12 Aug 2011 11:33:33 +0100 Message-ID: From: Phillip Hallam-Baker To: Mark Andrews Content-Type: multipart/alternative; boundary=0016368e1e44fa3f1904aa4c71ae Cc: dane@ietf.org Subject: [dane] On SMTP and SUBMIT X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 10:33:01 -0000 --0016368e1e44fa3f1904aa4c71ae Content-Type: text/plain; charset=ISO-8859-1 On Fri, Aug 12, 2011 at 4:01 AM, Mark Andrews wrote: There is a very basic misunderstanding that some members of this WG seem to be unable to get out of their heads, that the purpose of the group should be to stop people using bad crypto rather than to get people to use good (or at least better) crypto. If the alternative is to communicate in plaintext, you can accept a certificate minted by satan himself and you will be more secure than communicating in plaintext. It follows that it is only relevant to worry about the quality of a certificate after one can establish that the security mechanism is offered. It is of course highly desirable to get to a state where a system fails safe. But that requires a lot more than simply telling people to reject misconfigured crypto. It requires that there is a mechanism to explicitly inform the counterparty that it should expect crypto. In other words it requires a security policy mechanism. In the browser world, the padlock icon stands for a substitute for a security policy mechanism. That is why the matching of the domain name is relevant. If you have DNSSEC then the whole game changes completely. Security policy is not that hard, but it does require security policy to be the starting point for the design. It also requires DNSSEC, in fact that was the whole point of DNSSEC. Security policy does not work particularly well in the DKIM world because email is a rather peculiar system. It is the only major protocol where messages are habitually routed through a fan out distribution (mailing lists) that is outside the direct control of both sender and receiver. If people want to work on certificate quality then they should first accept that they are doing security policy and then start from the most important criteria, whether security is going to be used at all. Otherwise you will end up chasing an infinite series of apparent contradictions in deployment like the ones Mark and other give. If we were going to do that, the sensible approach would be to talk to the email server providers and get them engaged. That is a heck of a lot easier than getting the browser providers engaged. -- Website: http://hallambaker.com/ --0016368e1e44fa3f1904aa4c71ae Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Aug 12, 2011 at 4:01 AM, Mark Andrews <marka@isc.org> wrote:

There is a very basic misunderstanding that some members of this WG s= eem to be unable to get out of their heads, that the purpose of the group s= hould be to stop people using bad crypto rather than to get people to use g= ood (or at least better) crypto.

If the alternative is to communicate in plaintext, you = can accept a certificate minted by satan himself and you will be more secur= e than communicating in plaintext.

It follows that= it is only relevant to worry about the quality of a certificate after one = can establish that the security mechanism is offered.


It is of course highly desirable to get = to a state where a system fails safe. But that requires a lot more than sim= ply telling people to reject misconfigured crypto. It requires that there i= s a mechanism to explicitly inform the counterparty that it should expect c= rypto. In other words it requires a security policy mechanism.

In the browser world, the padlock icon stands for a sub= stitute for a security policy mechanism. That is why the matching of the do= main name is relevant. If you have DNSSEC then the whole game changes compl= etely.

Security policy is not that hard, but it does require s= ecurity policy to be the starting point for the design. It also requires DN= SSEC, in fact that was the whole point of DNSSEC.


Security policy does not work particularly well in the DKIM = world because email is a rather peculiar system. It is the only major proto= col where messages are habitually routed through a fan out distribution (ma= iling lists) that is outside the direct control of both sender and receiver= .

If people want to work on certificate quality then they= should first accept that they are doing security policy and then start fro= m the most important criteria, whether security is going to be used at all.=

Otherwise you will end up chasing an infinite series of= apparent contradictions in deployment like the ones Mark and other give.= =A0


If we were going to do that, th= e sensible approach would be to talk to the email server providers and get = them engaged. That is a heck of a lot easier than getting the browser provi= ders engaged.

--0016368e1e44fa3f1904aa4c71ae-- From ajs@anvilwalrusden.com Fri Aug 12 05:18:01 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16BE021F8593 for ; Fri, 12 Aug 2011 05:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6dEhlVnxSU0A for ; Fri, 12 Aug 2011 05:18:00 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA3921F84F1 for ; Fri, 12 Aug 2011 05:18:00 -0700 (PDT) Received: from shinkuro.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 822AF1ECB41D for ; Fri, 12 Aug 2011 12:18:37 +0000 (UTC) Date: Fri, 12 Aug 2011 08:18:29 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20110812121828.GA3724@shinkuro.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] On SMTP and SUBMIT X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 12:18:01 -0000 On Fri, Aug 12, 2011 at 11:33:33AM +0100, Phillip Hallam-Baker wrote: > If the alternative is to communicate in plaintext, you can accept a > certificate minted by satan himself and you will be more secure than > communicating in plaintext. I think there are some (perhaps many) people who simply disagree with you about that premise, and without that premise the rest of your argument falls apart. Some would argue, for instance, that it is actually _worse_ security to use certificates to which you don't have a good trust path, because it gives you a sense of security you might not have in communicating in plaintext. If the certificate comes from Moriarty and you have accepted it and then do things that you would not have done in plaintext, then your security situation is worse. I think both of those situations actually obtain on the Internet today: some people blindly accept certificates and are actually better off because their communication is better secured than it otherwise would be; other people are wary of such certificates and therefore simply don't do what they would have done in the presence of a certificate they had obtained securely (for some value of "securely"). I also think arguing about the empirical matter on this list is a waste of time, because I haven't seen any good studies on this and I don't even know how you'd conduct one. In any case, I don't see how the debate is relevant. There is a proposed mechanism for getting a TLSA record, and the only debatable matter relevant to this topic is whether you MUST have DNSSEC validation in order to use that TLSA record data. My personal opinion is that we already have plenty of unsecured ways to bootstrap secured communication, and so we don't need another; therefore, as a matter of protocol I support the MUST. A -- Andrew Sullivan ajs@anvilwalrusden.com From wes@hardakers.net Fri Aug 12 06:33:14 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F12ED21F8A62 for ; Fri, 12 Aug 2011 06:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CouND6zTSvEC for ; Fri, 12 Aug 2011 06:33:14 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by ietfa.amsl.com (Postfix) with ESMTP id 48B5521F8A51 for ; Fri, 12 Aug 2011 06:33:14 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id ECA8D1AB; Fri, 12 Aug 2011 06:33:20 -0700 (PDT) From: Wes Hardaker To: Phillip Hallam-Baker References: Date: Fri, 12 Aug 2011 06:33:21 -0700 In-Reply-To: (Phillip Hallam-Baker's message of "Fri, 12 Aug 2011 11:33:33 +0100") Message-ID: User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Mailman-Approved-At: Fri, 12 Aug 2011 06:48:09 -0700 Cc: dane@ietf.org Subject: Re: [dane] On SMTP and SUBMIT X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 13:33:15 -0000 >>>>> On Fri, 12 Aug 2011 11:33:33 +0100, Phillip Hallam-Baker said: PH> Security policy does not work particularly well in the DKIM world because PH> email is a rather peculiar system. It is the only major protocol where PH> messages are habitually routed through a fan out distribution (mailing PH> lists) that is outside the direct control of both sender and PH> receiver. Security policy has been shown to not work well in the web world either. I'll take "Countries who's governments install border http and https proxies for 1000" Alex. -- Wes Hardaker My Pictures: http://capturedonearth.com/ My Thoughts: http://pontifications.hardakers.net/ From hallam@gmail.com Fri Aug 12 08:46:48 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DBF821F880C for ; Fri, 12 Aug 2011 08:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDmoZLEZ5RoN for ; Fri, 12 Aug 2011 08:46:47 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id C844921F86DC for ; Fri, 12 Aug 2011 08:46:40 -0700 (PDT) Received: by gyf3 with SMTP id 3so2386828gyf.31 for ; Fri, 12 Aug 2011 08:47:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=t6nSP29vNQczGmLihNcGgqCjzD+5lkat2WcpJYIFwZg=; b=Y0cFeqUNftPor7MnzMLXsyKc48qwDBJd0whgLNOsR9LIz73+IcNy9QYW5mG4CTP2X8 aOP9FmHiigRrvXLJKRP1XTwhTwfU3r/o+GvG8sHoFqQpyk09IeB8TQZ2xvMLCI0Fwjj4 mDKxMh2e58LkQHuLSJcpIDN+NPBDAp/U5LfaI= MIME-Version: 1.0 Received: by 10.100.55.24 with SMTP id d24mr1127108ana.7.1313164038006; Fri, 12 Aug 2011 08:47:18 -0700 (PDT) Received: by 10.100.227.8 with HTTP; Fri, 12 Aug 2011 08:47:17 -0700 (PDT) In-Reply-To: <20110812121828.GA3724@shinkuro.com> References: <20110812121828.GA3724@shinkuro.com> Date: Fri, 12 Aug 2011 16:47:17 +0100 Message-ID: From: Phillip Hallam-Baker To: Andrew Sullivan Content-Type: multipart/alternative; boundary=001485f9a6380468d504aa50d4c5 Cc: dane@ietf.org Subject: Re: [dane] On SMTP and SUBMIT X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 15:46:48 -0000 --001485f9a6380468d504aa50d4c5 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Aug 12, 2011 at 1:18 PM, Andrew Sullivan wrote: > On Fri, Aug 12, 2011 at 11:33:33AM +0100, Phillip Hallam-Baker wrote: > > > If the alternative is to communicate in plaintext, you can accept a > > certificate minted by satan himself and you will be more secure than > > communicating in plaintext. > > I think there are some (perhaps many) people who simply disagree with > you about that premise, and without that premise the rest of your > argument falls apart. > Which is what I believed twenty years ago. Since then we have had research into security usability that has forced me to re-evaluate that position. > Some would argue, for instance, that it is actually _worse_ security > to use certificates to which you don't have a good trust path, Bad security would be worse than no security if people were more likely to rely on a system because they thought it was secure. Unfortunately all the evidence we have of real people using the Internet is that the expect it to be secure regardless of whether cryptography is used or not. > because > it gives you a sense of security you might not have in communicating > in plaintext. If the certificate comes from Moriarty and you have > accepted it and then do things that you would not have done in > plaintext, then your security situation is worse > That is why some of us want to get rid of the padlock icon completely, including for CA issued certs. Incidentally, we use the name Mallet because Mallory objected to the use of his name. I would guess Kathleen would prefer you use Mallet for the same reason. > In any case, I don't see how the debate is relevant. It is relevant if you are going to set criteria for name matching. In the case of SMTP the message will be sent in plaintext if crypto is not used and so any cert is better than none. -- Website: http://hallambaker.com/ --001485f9a6380468d504aa50d4c5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Aug 12, 2011 at 1:18 PM, Andrew = Sullivan <aj= s@anvilwalrusden.com> wrote:
On Fri, Aug 12, 2011 at 11:33:33AM +0100, Phillip Hallam-= Baker wrote:

> If the alternative is to communicate in plaintext, you can accept a > certificate minted by satan himself and you will be more secure than > communicating in plaintext.

I think there are some (perhaps many) people who simply disagree with=
you about that premise, and without that premise the rest of your
argument falls apart.

Which is what I b= elieved twenty years ago.

Since then we have had r= esearch into security usability that has forced me to re-evaluate that posi= tion.=A0

=A0
Some would argue, for instance, that it is actually _worse_ security
to use certificates to which you don't have a good trust path,

Bad security would be worse than no security if pe= ople were more likely to rely on a system because they thought it was secur= e. Unfortunately all the evidence we have of real people using the Internet= is that the expect it to be secure regardless of whether cryptography is u= sed or not.

=A0
because
it gives you a sense of security you might not have in communicating
in plaintext. =A0If the certificate comes from Moriarty and you have
accepted it and then do things that you would not have done in
plaintext, then your security situation is worse

<= /div>
That is why some of us want to get rid of the padlock icon comple= tely, including for CA issued certs.=A0

Incidental= ly, we use the name Mallet because Mallory objected to the use of his name.= I would guess Kathleen would prefer you use Mallet for the same reason.

=A0
In any case, I don't see how the debate is relevant.
=
It is relevant if you are going to set criteria for name mat= ching.

In the case of SMTP the message will be sen= t in plaintext if crypto is not used and so any cert is better than none.= =A0

--
Website: ht= tp://hallambaker.com/

--001485f9a6380468d504aa50d4c5-- From paul.hoffman@vpnc.org Fri Aug 12 08:58:43 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1103521F87D9 for ; Fri, 12 Aug 2011 08:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rjg-UajmGj6i for ; Fri, 12 Aug 2011 08:58:42 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 90EEA21F86E6 for ; Fri, 12 Aug 2011 08:58:42 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p7CFwulA069954 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 12 Aug 2011 08:58:57 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1244.3) From: Paul Hoffman In-Reply-To: Date: Fri, 12 Aug 2011 08:59:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <14CF2F59-33AE-4A0C-91B6-57E1D4996D64@vpnc.org> References: To: DANE WG X-Mailer: Apple Mail (2.1244.3) Subject: Re: [dane] On SMTP and SUBMIT X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 15:58:43 -0000 If there is an issue for the TLSA protocol document in this thread, I am = not seeing it, and I would really like to. Even if this is about future = work for the DANE WG, making what that work will be clearer will help = Jakob and I say the right things (and not say the wrong things) in the = TLSA protocol document. --Paul Hoffman From ajs@anvilwalrusden.com Fri Aug 12 09:07:15 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC8DA21F84EE for ; Fri, 12 Aug 2011 09:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWrpO8gUIRjN for ; Fri, 12 Aug 2011 09:07:15 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 6BECB21F84E6 for ; Fri, 12 Aug 2011 09:07:04 -0700 (PDT) Received: from shinkuro.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 23B7C1ECB41D for ; Fri, 12 Aug 2011 16:07:42 +0000 (UTC) Date: Fri, 12 Aug 2011 12:07:39 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20110812160738.GG3724@shinkuro.com> References: <20110812121828.GA3724@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] On SMTP and SUBMIT X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 16:07:15 -0000 On Fri, Aug 12, 2011 at 04:47:17PM +0100, Phillip Hallam-Baker wrote: > Incidentally, we use the name Mallet because Mallory objected to the use of > his name. I would guess Kathleen would prefer you use Mallet for the same > reason. I guess I don't know Kathleen Moriarty, but where I come from the villain Moriarty is an evil suuuuper-genius invented by Sir Arthur Conan Doyle. I am willing to switch to Wile E. if you prefer. You seemed in any case to be suggesting accepting certificates from Satan, but I do not pretend that human crypto is going to foil the supernatural powers of a guy whose metaphysics are impenetrable to me. (I guess he'd just shake his magick pitch-fork, thereby unlocking the code, getting a fiddle down in Georgia, and condemning non-right-thinking voters in one spell.) Professor Moriarty, however, is supposed to be human, and I thought as a super-genius he might do. My deepest apologies. Let's call our villain M. and be done with it, shall we? > > In any case, I don't see how the debate is relevant. > > It is relevant if you are going to set criteria for name matching. > > In the case of SMTP the message will be sent in plaintext if crypto is not > used and so any cert is better than none. Oh, so now I understand: you're back on that hobby-horse. The proposed rules so far exactly match the way the DNS works. You match the QNAME and you follow the alias records according to the rules for those alias records. I don't know what the problem is supposed to be here. If you think there is a problem, I urge you to state it succinctly and specifically. The last time I asked you to do this, you responded with an argument dependent on claims about what random people on the Internet expect from a completely new RRTYPE -- the premise of which I doubt and the conclusion of which I reject in any case on other grounds. I am entirely open to the possibility that there is a problem here, but so far I haven't seen even the shred of a plausible argument to that effect. Other things, like what people ought to do about MX records and so on, are just not part of this WG's problem, AFAICS. Are you arguing otherwise? I can't tell. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From kathleen.moriarty@emc.com Fri Aug 12 11:48:16 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF12321F86B1 for ; Fri, 12 Aug 2011 11:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.453 X-Spam-Level: X-Spam-Status: No, score=-6.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpcfbJRp2Dww for ; Fri, 12 Aug 2011 11:48:16 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 53E0921F8661 for ; Fri, 12 Aug 2011 11:48:15 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p7CImqF1028135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 12 Aug 2011 14:48:52 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.130]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor) for ; Fri, 12 Aug 2011 14:48:38 -0400 Received: from mxhub13.corp.emc.com (mxhub13.corp.emc.com [128.221.56.102]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p7CImbt2011716 for ; Fri, 12 Aug 2011 14:48:37 -0400 Received: from mx06a.corp.emc.com ([169.254.1.199]) by mxhub13.corp.emc.com ([128.221.56.102]) with mapi; Fri, 12 Aug 2011 14:48:37 -0400 From: To: Date: Fri, 12 Aug 2011 14:48:34 -0400 Thread-Topic: Re: [dane] On SMTP and SUBMIT Thread-Index: AcxZIHBqZYaZyau6QMm7StcCySFdew== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dane] On SMTP and SUBMIT X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 18:48:17 -0000 Hello, For the record, I am fine with the use of Moriarty as an evil super genius = mathematician character... just have the supernatural references associated= with another character which seems to be irrelevant anyway. BTW, I do have a degree in Mathematics and are you sure he was created ;-) -Kathleen From leifj@mnt.se Mon Aug 15 00:21:09 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA5F811E807F for ; Mon, 15 Aug 2011 00:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6+n9pobEOfBc for ; Mon, 15 Aug 2011 00:21:08 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 4312B11E8082 for ; Mon, 15 Aug 2011 00:21:08 -0700 (PDT) Received: from [192.36.125.212] (dhcp.pilsnet.sunet.se [192.36.125.212]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p7F7Lmul019241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 15 Aug 2011 09:21:51 +0200 (CEST) Message-ID: <4E48C90C.90902@mnt.se> Date: Mon, 15 Aug 2011 09:21:48 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: dane@ietf.org References: <6B5F4F0A-82F2-4911-81B6-F923D7529E4A@nic.cz> In-Reply-To: <6B5F4F0A-82F2-4911-81B6-F923D7529E4A@nic.cz> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [dane] Call for consensus for CNAME X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 Aug 2011 07:21:09 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/09/2011 10:44 PM, OndÅ™ej Surý wrote: > Hi, > > I hereby make a call for a consensus on the CNAME issue. > > I am specifically asking you if you agree with current > contents of DANE protocol draft, which says that TLSA > queries and answers follows normal DNS resolution. > > Please respond just with +1/-1, we already had a lengthy > discussion on the subject and it doesn't seem to develop > anywhere in last few days. If you really feel an urge > to discuss it again, please read the threads from last > two weeks on the subject and make an follow-up there, > so we can keep this thread loud and clear. > > And since we already had a discussion on the topic I would > like to close this issue next monday. +1 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5IyQwACgkQ8Jx8FtbMZnegwACfRMNohPykdyjO5dAjIkzmOXFZ AcIAoJJqs7iBZQ0MH2/Z5DucRq0QpxNp =Fkio -----END PGP SIGNATURE----- From peter@denic.de Mon Aug 15 01:44:43 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ABF521F8ABD for ; Mon, 15 Aug 2011 01:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.541 X-Spam-Level: X-Spam-Status: No, score=-101.541 tagged_above=-999 required=5 tests=[AWL=-0.954, BAYES_00=-2.599, FAKE_REPLY_C=2.012, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPvgzWX+QYUa for ; Mon, 15 Aug 2011 01:44:42 -0700 (PDT) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::4]) by ietfa.amsl.com (Postfix) with ESMTP id 9B8C121F8AB0 for ; Mon, 15 Aug 2011 01:44:42 -0700 (PDT) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1QssnX-0003hs-9p; Mon, 15 Aug 2011 10:45:27 +0200 Received: from localhost by x27.adm.denic.de with local id 1QssnX-0003YQ-5q; Mon, 15 Aug 2011 10:45:27 +0200 Date: Mon, 15 Aug 2011 10:45:27 +0200 From: Peter Koch To: IETF DANE WG Message-ID: <20110815084527.GM11178@x27.adm.denic.de> Mail-Followup-To: IETF DANE WG Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: Re: [dane] Call for consensus for CNAME X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 Aug 2011 08:44:43 -0000 On Tue, Aug 09, 2011 at 10:44:24PM +0200, Ond??ej Surý wrote: > I am specifically asking you if you agree with current > contents of DANE protocol draft, which says that TLSA > queries and answers follows normal DNS resolution. i am not convinced that the question is that easy. Sure the processing of CNAME RRs (and DNAME and what have you) ought to be transparent to the application. However, the problem is one of semantics of the namespace and was actually initiated back when we started this funny idea of extending the query type space by prefixing the QNAME. The reason a CNAME RR cannot have siblings is that the owner itself is only considered an alias and all data associated with the node is to be found at the canonical name, i.e., at the target of the CNAME RR. Now, since the prefixed data is considered belonging to the (aliased) node, the same logic should apply - but at the same time even though the protocol does not allow CNAME siblings, it apparently allows CNAME descendants. So it isn't obvious to me why the only interpretation, given a foo.example.org. CNAME bar.example.net. should be that the _443_tcp (or _443._tcp) prefix has to be applied to foo.example.org. rather than bar.example.net. And this has nothing to do with wildcards, just plain protocol semantics. -Peter From fanf2@hermes.cam.ac.uk Mon Aug 15 02:45:46 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD8E21F8B31 for ; Mon, 15 Aug 2011 02:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.583 X-Spam-Level: X-Spam-Status: No, score=-6.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6rEc8xpnBuy for ; Mon, 15 Aug 2011 02:45:45 -0700 (PDT) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB3621F8B2A for ; Mon, 15 Aug 2011 02:45:44 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:56097) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1Qstka-0004lQ-FQ (Exim 4.72) (return-path ); Mon, 15 Aug 2011 10:46:28 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Qstka-0003yh-Or (Exim 4.67) (return-path ); Mon, 15 Aug 2011 10:46:28 +0100 Date: Mon, 15 Aug 2011 10:46:28 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Peter Koch In-Reply-To: <20110815084527.GM11178@x27.adm.denic.de> Message-ID: References: <20110815084527.GM11178@x27.adm.denic.de> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: IETF DANE WG Subject: Re: [dane] Call for consensus for CNAME X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 Aug 2011 09:45:46 -0000 Peter Koch wrote: > > The reason a CNAME RR cannot have siblings is that the owner itself is > only considered an alias and all data associated with the node is to be > found at the canonical name, i.e., at the target of the CNAME RR. Now, > since the prefixed data is considered belonging to the (aliased) node, > the same logic should apply - but at the same time even though the > protocol does not allow CNAME siblings, it apparently allows CNAME > descendants. There is IDNA work which might result in the specification of a new RRtype (possibly called BNAME) which aliases a name and its descendents, i.e. a combination of both CNAME and DNAME. I think it would be more consistent with the layering for DANE clients to always apply the prefix to the original query name, and leave questions of how aliasing is implemented (parallel CNAMEs or BNALE etc.) to the DNS protocol. Tony. -- f.anthony.n.finch http://dotat.at/ Shannon, South Rockall: Southerly or southwesterly becoming cyclonic, 5 to 7, decreasing 4 for a time. Moderate or rough. Showers then rain. Good, becoming moderate or poor. From hallam@gmail.com Mon Aug 15 03:22:46 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7EF721F8B32 for ; Mon, 15 Aug 2011 03:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.45 X-Spam-Level: X-Spam-Status: No, score=-3.45 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dE34VN0Kmf5M for ; Mon, 15 Aug 2011 03:22:46 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id DB85B21F8B29 for ; Mon, 15 Aug 2011 03:22:45 -0700 (PDT) Received: by yie12 with SMTP id 12so3527247yie.31 for ; Mon, 15 Aug 2011 03:23:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+ByTPfM09cjWfKCCTEuyDrArZRP4uWYTaUxg6eIFNEk=; b=wQMuWVprBs/y3ViyDOBrat0t/aLmKtHFuZrPU2ylzvt2xil/vIgA5I19+EmmqfXYP2 h56W2QBjHJxtWwCcW3V/TRt3P94zWg26OQdg9w3DY/EvzfaxViUniYdzAdSOCu8hx8Zo kwpEaLeT6WDmZ8j19AgyHxTRd80305xM8WmzA= MIME-Version: 1.0 Received: by 10.100.16.17 with SMTP id 17mr3717992anp.13.1313403810709; Mon, 15 Aug 2011 03:23:30 -0700 (PDT) Received: by 10.100.94.14 with HTTP; Mon, 15 Aug 2011 03:23:30 -0700 (PDT) In-Reply-To: References: <20110815084527.GM11178@x27.adm.denic.de> Date: Mon, 15 Aug 2011 11:23:30 +0100 Message-ID: From: Phillip Hallam-Baker To: Tony Finch Content-Type: multipart/alternative; boundary=001485f7c3b89580cf04aa88a772 Cc: Peter Koch , IETF DANE WG Subject: Re: [dane] Call for consensus for CNAME X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 Aug 2011 10:22:47 -0000 --001485f7c3b89580cf04aa88a772 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Aug 15, 2011 at 10:46 AM, Tony Finch wrote: > Peter Koch wrote: > > > > The reason a CNAME RR cannot have siblings is that the owner itself is > > only considered an alias and all data associated with the node is to be > > found at the canonical name, i.e., at the target of the CNAME RR. Now, > > since the prefixed data is considered belonging to the (aliased) node, > > the same logic should apply - but at the same time even though the > > protocol does not allow CNAME siblings, it apparently allows CNAME > > descendants. > > There is IDNA work which might result in the specification of a new RRtype > (possibly called BNAME) which aliases a name and its descendents, i.e. a > combination of both CNAME and DNAME. > > I think it would be more consistent with the layering for DANE clients to > always apply the prefix to the original query name, and leave questions of > how aliasing is implemented (parallel CNAMEs or BNALE etc.) to the DNS > protocol. Clients never get to decide where the prefix is applied. Only the DNS admin can do that. All that clients can do is to decide on which places that they will look for records. So what you are really arguing for is that the client should only look for the prefix in one place and not two. All I was proposing was that we respect the fact that the original DNS architecture did not anticipate prefixed records and that the aliasing mechanism does not by default provide the semantics that DNS admins are likely to desire. Instead people decided to demagogue the issue with claims about changing the semantics of the DNS. Seems to me that someone got the idea that they couldn't understand what I was up to and decided there must be a conspiratorial explanation and decided to go out to block it. Introducing BNAME might fix the problem, but that will take several years to deploy and DANE will not have that long a trial. If there is no deployment in the browsers within a couple of years then those of us who want to do keying and security policy in the DNS are going to have to start again. BNAME is not going to address the administration problems related to DNS and Web site admin. -- Website: http://hallambaker.com/ --001485f7c3b89580cf04aa88a772 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Aug 15, 2011 at 10:46 AM, Tony F= inch <dot@dotat.at= > wrote:
Peter Koch <pk@ISOC.DE> wrote:
>
> The reason a CNAME RR cannot have siblings is that the owner itself is=
> only considered an alias and all data associated with the node is to b= e
> found at the canonical name, i.e., at the target of the CNAME RR. Now,=
> since the prefixed data is considered belonging to the (aliased) node,=
> the same logic should apply - but at the same time even though the
> protocol does not allow CNAME siblings, it apparently allows CNAME
> descendants.

There is IDNA work which might result in the specification of a new R= Rtype
(possibly called BNAME) which aliases a name and its descendents, i.e. a combination of both CNAME and DNAME.

I think it would be more consistent with the layering for DANE clients to always apply the prefix to the original query name, and leave questions of<= br> how aliasing is implemented (parallel CNAMEs or BNALE etc.) to the DNS
protocol.


All that clients can do is to decide on which places that they will l= ook for records. So what you are really arguing for is that the client shou= ld only look for the prefix in one place and not two.


All I was proposing was that we respect = the fact that the original DNS architecture did not anticipate prefixed rec= ords and that the aliasing mechanism does not by default provide the semant= ics that DNS admins are likely to desire.

Instead people decided to demagogue the issue with clai= ms about changing the semantics of the DNS. Seems to me that someone got th= e idea that they couldn't understand what I was up to and decided there= must be a conspiratorial explanation and decided to go out to block it.

Introducing BNAME might fix the problem, but that will = take several years to deploy and DANE will not have that long a trial. If t= here is no deployment in the browsers within a couple of years then those o= f us who want to do keying and security policy in the DNS are going to have= to start again.

BNAME is not going to address the administration proble= ms related to DNS and Web site admin.

--
Webs= ite: http://hallambaker.com/
--001485f7c3b89580cf04aa88a772-- From i.grok@comcast.net Mon Aug 15 07:16:07 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDCF221F8B56 for ; Mon, 15 Aug 2011 07:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.646 X-Spam-Level: X-Spam-Status: No, score=-102.646 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0C55FE2Ky2g for ; Mon, 15 Aug 2011 07:16:07 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by ietfa.amsl.com (Postfix) with ESMTP id 30A8C21F8B54 for ; Mon, 15 Aug 2011 07:16:07 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta04.westchester.pa.mail.comcast.net with comcast id Le7J1h0071YDfWL54eGtu4; Mon, 15 Aug 2011 14:16:53 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta20.westchester.pa.mail.comcast.net with comcast id LeGq1h00m00PQ6U3geGqro; Mon, 15 Aug 2011 14:16:52 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.4/8.14.3) with ESMTP id p7FEGkgE024727 for ; Mon, 15 Aug 2011 10:16:46 -0400 Received: (from draco@localhost) by odin.ulthar.us (8.14.4/8.14.4/Submit) id p7FEGkbZ024725 for dane@ietf.org; Mon, 15 Aug 2011 10:16:46 -0400 Date: Mon, 15 Aug 2011 10:16:46 -0400 From: Scott Schmit To: dane@ietf.org Message-ID: <20110815141646.GA22918@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <20110815084527.GM11178@x27.adm.denic.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Call for consensus for CNAME X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 Aug 2011 14:16:08 -0000 On Mon, Aug 15, 2011 at 10:46:28AM +0100, Tony Finch wrote: > Peter Koch wrote: > > The reason a CNAME RR cannot have siblings is that the owner itself is > > only considered an alias and all data associated with the node is to be > > found at the canonical name, i.e., at the target of the CNAME RR. Now, > > since the prefixed data is considered belonging to the (aliased) node, > > the same logic should apply - but at the same time even though the > > protocol does not allow CNAME siblings, it apparently allows CNAME > > descendants. > > There is IDNA work which might result in the specification of a new RRtype > (possibly called BNAME) which aliases a name and its descendents, i.e. a > combination of both CNAME and DNAME. > > I think it would be more consistent with the layering for DANE clients to > always apply the prefix to the original query name, and leave questions of > how aliasing is implemented (parallel CNAMEs or BNALE etc.) to the DNS > protocol. I agree that this is the best solution. However, the fate of BNAME is considerably less clear than you imply. The IDNA/ICANN folks went to dnsext about making names "the same". In the process of trying to solve that issue, the dnsext WG came up with a number of different proposals, of which BNAME was one. However, everything pretty much died when ICANN was asked to clarify the requirements with their stakeholders (IIRC). So, BNAME isn't just around the corner--the dnsext WG wants to solve the "the same problem" (if there is one, and there's some question there) once, so until they get clear requirements on "sameness", they aren't going to extend DNS. That said, I think it's the only way wildcards will work well, because there's another use case for wildcards we haven't talked about: wildcard address records. For those, there is nowhere to look for TLSA records after the A other than the reverse DNS (for each and every address returned). From my limited poking around, that seems to be at least as common as wildcard CNAMEs. That said, this is probably something better examined through the SSL observatory data, if the commonness matters. If the wildcard CNAME usage makes up a high percentage of TLS usage (and we think that they are likely to use DANE), then we need to prioritize this use case and consider hacks like clients chasing CNAME chains. But we'd still have no solution for the wildcard address records. If not, then what we have is good enough, and will only get better when BNAME (or one of the other suggestions for resolving the "the same problem") is deployed. Lacking data saying otherwise, I'm finding myself in the latter camp now. So: +1 to closing #24. -- Scott Schmit From fanf2@hermes.cam.ac.uk Mon Aug 15 07:24:15 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 120F821F8B8C for ; Mon, 15 Aug 2011 07:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.583 X-Spam-Level: X-Spam-Status: No, score=-6.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3nVyVMWAyADv for ; Mon, 15 Aug 2011 07:24:14 -0700 (PDT) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by ietfa.amsl.com (Postfix) with ESMTP id 5471221F8B8B for ; Mon, 15 Aug 2011 07:24:14 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:42503) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1Qsy67-00006y-FE (Exim 4.72) (return-path ); Mon, 15 Aug 2011 15:24:59 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Qsy67-0000zX-Ms (Exim 4.67) (return-path ); Mon, 15 Aug 2011 15:24:59 +0100 Date: Mon, 15 Aug 2011 15:24:59 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Scott Schmit In-Reply-To: <20110815141646.GA22918@odin.ulthar.us> Message-ID: References: <20110815084527.GM11178@x27.adm.denic.de> <20110815141646.GA22918@odin.ulthar.us> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dane@ietf.org Subject: Re: [dane] Call for consensus for CNAME X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 Aug 2011 14:24:15 -0000 Scott Schmit wrote: > That said, I think it's the only way wildcards will work well, because > there's another use case for wildcards we haven't talked about: wildcard > address records. For those, there is nowhere to look for TLSA records > after the A other than the reverse DNS (for each and every address > returned). Why not just have a parallel wildcard TLSA record? Does it matter that the record will be returned in reply to more query names than you would normally expect? Tony. -- f.anthony.n.finch http://dotat.at/ Northwest FitzRoy: Southwesterly 4 or 5, but 6 or 7 at first in far northwest, becoming variable 3 or 4 later. Rough at first in far northwest, otherwise moderate. Rain at times. Moderate or good, occasionally poor. From ajs@anvilwalrusden.com Mon Aug 15 07:26:50 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B70B21F8B8C for ; Mon, 15 Aug 2011 07:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.271 X-Spam-Level: X-Spam-Status: No, score=-2.271 tagged_above=-999 required=5 tests=[AWL=-0.272, BAYES_00=-2.599, J_CHICKENPOX_55=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qud19-SnFyIZ for ; Mon, 15 Aug 2011 07:26:50 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 03F1821F8B8B for ; Mon, 15 Aug 2011 07:26:50 -0700 (PDT) Received: from shinkuro.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 2441B1ECB41C for ; Mon, 15 Aug 2011 14:27:36 +0000 (UTC) Date: Mon, 15 Aug 2011 10:27:33 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20110815142732.GD12253@shinkuro.com> References: <20110815084527.GM11178@x27.adm.denic.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110815084527.GM11178@x27.adm.denic.de> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [dane] discussion Re: Call for consensus for CNAME X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 Aug 2011 14:26:50 -0000 On Mon, Aug 15, 2011 at 10:45:27AM +0200, Peter Koch wrote: > the target of the CNAME RR. Now, since the prefixed data > is considered belonging to the (aliased) node, the same logic > should apply - but at the same time even though the protocol > does not allow CNAME siblings, it apparently allows CNAME > descendants. Those two sentences are inconsistent. If CNAME allows subordinate names lower in the tree than the CNAME, then it simply isn't true that "the prefixed data is considered belonging to the (aliased) node." The CNAME points into another tree at that node, but it does not redirect the descendents. That's just how the protocol works, and if people want a different RRTYPE that redirects descendents too, then they need to address the problems with the BNAME or CNAME+DNAME proposals on the back burner in dnsext. > And this has nothing to do with wildcards, just plain > protocol semantics. We don't need semantics to solve this issue. The protocol is clear: CNAME redirects that node, and nothing else. -- Andrew Sullivan ajs@anvilwalrusden.com From ondrej.sury@nic.cz Mon Aug 15 07:28:04 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3C121F8A97 for ; Mon, 15 Aug 2011 07:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c+RaTpGuGc72 for ; Mon, 15 Aug 2011 07:28:03 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 6A51521F8A67 for ; Mon, 15 Aug 2011 07:28:03 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:75ea:719d:e21e:e569] (unknown [IPv6:2001:1488:ac14:1400:75ea:719d:e21e:e569]) by mail.nic.cz (Postfix) with ESMTPSA id EE00E2A2B7B; Mon, 15 Aug 2011 16:28:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1313418527; bh=RrJwyxyE+YkXUsdWln1URnRbWrNzIyFzeUJrV9JqD8c=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=xAtu1nPgRfNr8Yy+W/8A0jkyi82arp01W1Qcet4bF+dm7vLOdtsH0Y2Xj2YjFgoU6 jx50MHL26cNkMitAhsMxBiw5mKJlxcUoWCCIiCHV7xvMuoQqQjzVnHPtwe0KxkbwtF IB2P4aLIPlWohJeSR5C+kTxG4RBo8UVITD/+4loE= Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <6B5F4F0A-82F2-4911-81B6-F923D7529E4A@nic.cz> Date: Mon, 15 Aug 2011 16:28:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8E6F94D0-BD4E-43C1-80B7-226CE6C8C59B@nic.cz> References: <6B5F4F0A-82F2-4911-81B6-F923D7529E4A@nic.cz> To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= X-Mailer: Apple Mail (2.1244.3) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane@ietf.org Subject: [dane] Closing issue #24 (Was: Call for consensus for CNAME) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 Aug 2011 14:28:04 -0000 Hi, seems like we have a strong consensus here: +1 Ond=C5=99ej Sur=C3=BD Matthijs Mekking Matt McCutchen (with follow-up on wildcards) Paul Hoffman Andrew Sullivan Paul Wouters James Cloos Richard L. Barnes Jakob Schlyter Bill Manning Tony Finch Jim Schaad (with future comments on specific text) Martin Rex Matt Larson Leif Johansson Scott Schmit -1 Phillip Hallam-Baker neither -1 nor +1 Peter Koch Based on this I am closing #24 and will work with Matt on opening the wildcards when his proposal is ready. O. On 9. 8. 2011, at 22:44, Ond=C5=99ej Sur=C3=BD wrote: > Hi, >=20 > I hereby make a call for a consensus on the CNAME issue. >=20 > I am specifically asking you if you agree with current > contents of DANE protocol draft, which says that TLSA > queries and answers follows normal DNS resolution. >=20 > Please respond just with +1/-1, we already had a lengthy > discussion on the subject and it doesn't seem to develop > anywhere in last few days. If you really feel an urge > to discuss it again, please read the threads from last > two weeks on the subject and make an follow-up there, > so we can keep this thread loud and clear. >=20 > And since we already had a discussion on the topic I would > like to close this issue next monday.=09 >=20 > Thanks, > -- > Ond=C5=99ej Sur=C3=BD > vedouc=C3=AD v=C3=BDzkumu/Head of R&D department > ------------------------------------------- > CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC > Americka 23, 120 00 Praha 2, Czech Republic > mailto:ondrej.sury@nic.cz http://nic.cz/ > tel:+420.222745110 fax:+420.222745112 > ------------------------------------------- >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From ajs@anvilwalrusden.com Mon Aug 15 07:38:46 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F396F21F8B94 for ; Mon, 15 Aug 2011 07:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HqNvU4VWe+gG for ; Mon, 15 Aug 2011 07:38:45 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 6FBB921F8B85 for ; Mon, 15 Aug 2011 07:38:45 -0700 (PDT) Received: from shinkuro.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 9F4C51ECB41C for ; Mon, 15 Aug 2011 14:39:31 +0000 (UTC) Date: Mon, 15 Aug 2011 10:39:28 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20110815143928.GE12253@shinkuro.com> References: <20110815084527.GM11178@x27.adm.denic.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [dane] discussion Re: Call for consensus for CNAME X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 Aug 2011 14:38:46 -0000 On Mon, Aug 15, 2011 at 11:23:30AM +0100, Phillip Hallam-Baker wrote: > All I was proposing was that we respect the fact that the original DNS > architecture did not anticipate prefixed records and that the aliasing > mechanism does not by default provide the semantics that DNS admins are > likely to desire. It seems to me that if the original DNS design had intended that CNAMEs be terminal (i.e. that things couldn't be lower than them in the tree), that was a rule that was open to be specified. It was not so specified. If DNS admins want such a feature, they can in fact provide it anyway, by adding the relevant CNAME lower in the tree. What exactly is difficult here? > Instead people decided to demagogue the issue with claims about changing the > semantics of the DNS. People disagreeing with you are not "demagogues"; they just have a different opinion. There is absolutely no justification in any protocol document I have been able to find for the suggestion that CNAME redirects names beneath it. You want it in effect to do so, and you proposed language that caused clients to behave as though one particular name beneath a CNAME _is_ redirected. That does effectively change the way the protocol works, and therefore I object. > Seems to me that someone got the idea that they > couldn't understand what I was up to and decided there must be a > conspiratorial explanation and decided to go out to block it. I understand what you're up to, and I even have some sympathy with the view that DNS administrators (and web site operators, and so on) might want things to work this way. But it's too bad: the protocol isn't specified that way. I think changing the way CNAME works for just this case would be a very bad idea, because it means that one cannot rely on the CNAME rules being consistent. A -- Andrew Sullivan ajs@anvilwalrusden.com From trac+dane@trac.tools.ietf.org Mon Aug 15 07:41:13 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 609A121F8BCD for ; Mon, 15 Aug 2011 07:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLO44Rq0gdYn for ; Mon, 15 Aug 2011 07:41:13 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id DE87021F8B94 for ; Mon, 15 Aug 2011 07:41:12 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QsyMJ-0002ap-12; Mon, 15 Aug 2011 07:41:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: draft-ietf-dane-protocol@tools.ietf.org, ondrej.sury@nic.cz X-Trac-Project: dane Date: Mon, 15 Aug 2011 14:41:42 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dane/trac/ticket/24#comment:1 Message-ID: <070.acef7bf7be6b5bb319d9db2d8b0bcc4d@trac.tools.ietf.org> References: <061.ee73b0a357f1a46b8aa646a4c36057d4@trac.tools.ietf.org> X-Trac-Ticket-ID: 24 In-Reply-To: <061.ee73b0a357f1a46b8aa646a4c36057d4@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dane-protocol@tools.ietf.org, ondrej.sury@nic.cz, dane@ietf.org X-SA-Exim-Mail-From: trac+dane@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20110815144112.DE87021F8B94@ietfa.amsl.com> Resent-Date: Mon, 15 Aug 2011 07:41:12 -0700 (PDT) Resent-From: trac+dane@trac.tools.ietf.org Cc: dane@ietf.org Subject: Re: [dane] #24: Use with wildcards, CNAME, DNAME X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 14:41:13 -0000 #24: Use with wildcards, CNAME, DNAME Changes (by ondrej.sury@…): * status: new => closed * resolution: => fixed Comment: Closing based on ml consensus. The -09 version of DANE protocol is OK, no special handling for CNAMEs in necessary. Client connecting to example.com will ask for TLSA a _port._proto.example.com. For more information see the mailing list. -- ------------------------------------+--------------------------------------- Reporter: matt@… | Owner: draft-ietf-dane-protocol@… Type: enhancement | Status: closed Priority: major | Milestone: Component: protocol | Version: Severity: - | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Ticket URL: dane From ajs@anvilwalrusden.com Mon Aug 15 07:43:17 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA47821F8B7F for ; Mon, 15 Aug 2011 07:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9BH0dDLDMiSf for ; Mon, 15 Aug 2011 07:43:17 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 58EE421F8B7E for ; Mon, 15 Aug 2011 07:43:09 -0700 (PDT) Received: from shinkuro.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id D773B1ECB41C for ; Mon, 15 Aug 2011 14:43:55 +0000 (UTC) Date: Mon, 15 Aug 2011 10:43:52 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20110815144352.GF12253@shinkuro.com> References: <20110815084527.GM11178@x27.adm.denic.de> <20110815141646.GA22918@odin.ulthar.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110815141646.GA22918@odin.ulthar.us> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [dane] Clarification of my view on BNAME (was: Call for consensus for CNAME) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 Aug 2011 14:43:17 -0000 On Mon, Aug 15, 2011 at 10:16:46AM -0400, Scott Schmit wrote: > "the same problem" (if there is one, and there's some question there) > once, so until they get clear requirements on "sameness", they aren't > going to extend DNS. Speaking only for myself but as one of the co-chairs who made that call, that isn't quite what the reasoning was. The reasoning was that while there were people who wanted the additional RRTYPE, there were also several voices against the additional protocol complexity, partly on the grounds that it wasn't clear what the problem was, it wasn't clear whether BNAME would actually solve it, and it wasn't clear what trade-offs we were making. None of that is any clearer lo these many months later, and therefore the work hasn't been adopted. A -- Andrew Sullivan ajs@anvilwalrusden.com From ondrej.sury@nic.cz Mon Aug 15 07:47:05 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0305B21F8AAA for ; Mon, 15 Aug 2011 07:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uS6zuVCbw4yx for ; Mon, 15 Aug 2011 07:47:04 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 5948621F8A4E for ; Mon, 15 Aug 2011 07:47:04 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:75ea:719d:e21e:e569] (unknown [IPv6:2001:1488:ac14:1400:75ea:719d:e21e:e569]) by mail.nic.cz (Postfix) with ESMTPSA id AA93C2A084B for ; Mon, 15 Aug 2011 16:47:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1313419669; bh=CCAjcsa+wK8URwHXgxncvdZMRmv7pV8zYmfnZu767d8=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Date: Message-Id:To:Mime-Version; b=qZuvWuMzcbT4qEsUFj/6QQPgW4oTnZR4cFwKRF3erZPmz44hTLz0XW0hIIOt+QnH3 qIeM7qv030QRkDHwFk/KO1zCVCXLsRYMvRfOQvhGeIIzWdquMUKLPIZsiUzHEUuaYY gsq3AE4zqWrFVwT3Fois7XAz/xu7dMjOAJcv+DJM= From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Aug 2011 16:47:49 +0200 Message-Id: <74B71A15-E1E1-4057-9C6B-4721FCC270C2@nic.cz> To: dane@ietf.org Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: [dane] Opening issue #7: Error Handling : What to do when you receive an invalid record X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 Aug 2011 14:47:05 -0000 Hi, I would like to open next issue on the mailing list: http://trac.tools.ietf.org/wg/dane/trac/ticket/7 --cut here-- =46rom email from Jim Schaad: Context -- Issue #7: Error Handling : What to do when you receive an = invalid record -- Addressed in Protocol doc ((e.g Section 4.4)) This is not fully addressed in the spec at present. Specifically what to = do with unknown certificate types is not documented. Also I am not sure = what the correct behavior should be for mal-formatted items. I.e. if bytes = are missing or added to the current records. If you use an ASN.1 parser on = the certificate and compare it, rather than byte comparing it then trailing = bad bytes might be ignored. --cut here-- I might open few more this week based on the traffic. O. -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From internet-drafts@ietf.org Mon Aug 15 08:46:56 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD06A21F8B7E; Mon, 15 Aug 2011 08:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1mOQoUmue5z; Mon, 15 Aug 2011 08:46:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BED821F8B6D; Mon, 15 Aug 2011 08:46:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.58 Message-ID: <20110815154656.835.81125.idtracker@ietfa.amsl.com> Date: Mon, 15 Aug 2011 08:46:56 -0700 Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-protocol-10.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 Aug 2011 15:46:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DNS-based Authentication of Named Ent= ities Working Group of the IETF. Title : Using Secure DNS to Associate Certificates with Domain N= ames For TLS Author(s) : Paul Hoffman Jakob Schlyter Filename : draft-ietf-dane-protocol-10.txt Pages : 18 Date : 2011-08-15 TLS and DTLS use PKIX certificates for authenticating the server. Users want their applications to verify that the certificate provided by the TLS server is in fact associated with the domain name they expect. TLSA provides bindings of keys to domains that are asserted not by external entities, but by the entities that operate the DNS. This document describes how to use secure DNS to associate the TLS server's certificate with the intended domain name. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dane-protocol-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dane-protocol-10.txt From paul.hoffman@vpnc.org Mon Aug 15 08:52:15 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B272621F8BA0 for ; Mon, 15 Aug 2011 08:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tC2GF4ZCsgLo for ; Mon, 15 Aug 2011 08:52:15 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA8E21F8B8B for ; Mon, 15 Aug 2011 08:52:15 -0700 (PDT) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p7FFqaE2092858 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 15 Aug 2011 08:52:36 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Aug 2011 08:53:00 -0700 Message-Id: To: DANE WG Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) Subject: [dane] New protocol draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 Aug 2011 15:52:15 -0000 Diffs at = . Based on the discussion at the meeting in Qu=E9bec, we have made = Appendix A operational issues of deploying TLSA records. We have = rewritten the text in that section to be in a more operational light, = and would very much appreciate input on the wording. We also added a new appendix, B, which is pseudocode for TLS resolution = with DANE. This section definitely needs careful review. If we muffed = the pseudocode, we need to fix it, but we also probably need to be = clearer in the main document about how the resolution works. Neither of these requests should deter people from commenting on the = issues that the WG chairs are opening; we can juggle them all. We hope = that the chairs open a few more issues at once so that we can get this = work finished in a reasonable amount of time. --Paul Hoffman From johnl@iecc.com Mon Aug 15 12:52:52 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7362311E80A4 for ; Mon, 15 Aug 2011 12:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.191 X-Spam-Level: X-Spam-Status: No, score=-111.191 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPLSZaPrOzzE for ; Mon, 15 Aug 2011 12:52:52 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id DA36311E8080 for ; Mon, 15 Aug 2011 12:52:51 -0700 (PDT) Received: (qmail 14305 invoked from network); 15 Aug 2011 19:53:37 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 15 Aug 2011 19:53:37 -0000 Received: (qmail 30893 invoked from network); 15 Aug 2011 19:53:37 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 15 Aug 2011 19:53:37 -0000 Date: 15 Aug 2011 19:53:14 -0000 Message-ID: <20110815195314.38004.qmail@joyce.lan> From: "John Levine" To: dane@ietf.org In-Reply-To: <20110815143928.GE12253@shinkuro.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [dane] discussion Re: Call for consensus for CNAME X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 Aug 2011 19:52:52 -0000 > If DNS admins want such a feature, they can in fact provide it > anyway, by adding the relevant CNAME lower in the tree. What > exactly is difficult here? Basically that it bundles different names together to mean one thing, something the DNS has never done. The whole point of having multiple RRTYPEs is so that you can hang different kinds of information on the same name. Prefixes are a kludge to work around the lack of indexed RRYPEs (for SRV) and the extreme pain involved in adding new RRTYPEs to 50,000 badly written DNS provisioning systems (all the rest of them.) On further reflection, I note that this particular situation has been broken for 15 years, since the invention of SRV, and arguably for over 30 years, since the invention of MX, and nobody's found it urgent enough to fix. If BNAME happens, it'll be a fairly effective band-aid for this particular problem, which is pretty ironic since it's a complete failure for the problem (making two TLDs equivalent) that it is intended to solve. R's, John From hallam@gmail.com Mon Aug 15 13:55:48 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F25521F8CF1 for ; Mon, 15 Aug 2011 13:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.452 X-Spam-Level: X-Spam-Status: No, score=-3.452 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aj7F6HXwPB41 for ; Mon, 15 Aug 2011 13:55:47 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id BE70621F8CE7 for ; Mon, 15 Aug 2011 13:55:47 -0700 (PDT) Received: by yie12 with SMTP id 12so3880351yie.31 for ; Mon, 15 Aug 2011 13:56:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jO3d+dmqpE1kbISavKoYjBXfPAx/p+0M0g89iqwxX9M=; b=fhEt7UujDZ0bHQbcYlxZ9075p/Il+gVxDW8wQnujKU+Fqsy2Xfna76ZEH6xpRk2mCF xDZSkqbLqCflSHcMnztevIVyQFV4TbLOzkWS5Iu9LxV9m1W1+H98Jc9zRgJTSWNiERBu iGl3Rujkrml1dDYnwlu78droQ9lG/e8slUnRY= MIME-Version: 1.0 Received: by 10.101.5.21 with SMTP id h21mr3656995ani.123.1313441793094; Mon, 15 Aug 2011 13:56:33 -0700 (PDT) Received: by 10.100.94.14 with HTTP; Mon, 15 Aug 2011 13:56:33 -0700 (PDT) In-Reply-To: <20110815195314.38004.qmail@joyce.lan> References: <20110815143928.GE12253@shinkuro.com> <20110815195314.38004.qmail@joyce.lan> Date: Mon, 15 Aug 2011 21:56:33 +0100 Message-ID: From: Phillip Hallam-Baker To: John Levine Content-Type: multipart/alternative; boundary=001636c9297d82b3f404aa917fbe Cc: dane@ietf.org Subject: Re: [dane] discussion Re: Call for consensus for CNAME X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 Aug 2011 20:55:48 -0000 --001636c9297d82b3f404aa917fbe Content-Type: text/plain; charset=ISO-8859-1 On Mon, Aug 15, 2011 at 8:53 PM, John Levine wrote: > > If DNS admins want such a feature, they can in fact provide it > > anyway, by adding the relevant CNAME lower in the tree. What > > exactly is difficult here? > > Basically that it bundles different names together to mean one thing, > something the DNS has never done. The whole point of having multiple > RRTYPEs is so that you can hang different kinds of information on the > same name. Prefixes are a kludge to work around the lack of indexed > RRYPEs (for SRV) and the extreme pain involved in adding new RRTYPEs > to 50,000 badly written DNS provisioning systems (all the rest of > them.) > > On further reflection, I note that this particular situation has been > broken for 15 years, since the invention of SRV, and arguably for over > 30 years, since the invention of MX, and nobody's found it urgent > enough to fix. > In my view the use of prefixes is what 'broke the DNS model'. A prefix is a different DNS name that is logically a substitute for a new RR but has different semantics to a new RR because it is a separate name. So in my view the 'last try' resolution approach is merely a mechanism that fixes the breakage introduced by using prefixes to stand for new RRs. > If BNAME happens, it'll be a fairly effective band-aid for this > particular problem, which is pretty ironic since it's a complete > failure for the problem (making two TLDs equivalent) that it is > intended to solve. > That's a bit generous. 'Not even a failure' is probably more accurate. For BNAME to fail there would have to be a defined problem to be solved. -- Website: http://hallambaker.com/ --001636c9297d82b3f404aa917fbe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Aug 15, 2011 at 8:53 PM, John Le= vine <johnl@taugh.c= om> wrote:
> If DNS admins want such a feature, they can in fact = provide it
> anyway, by adding the relevant CNAME lower in the tree. =A0What
> exactly is difficult here?

Basically that it bundles different names together to mean one thing,=
something the DNS has never done. =A0The whole point of having multiple
RRTYPEs is so that you can hang different kinds of information on the
same name. =A0Prefixes are a kludge to work around the lack of indexed
RRYPEs (for SRV) and the extreme pain involved in adding new RRTYPEs
to 50,000 badly written DNS provisioning systems (all the rest of
them.)

On further reflection, I note that this particular situation has been
broken for 15 years, since the invention of SRV, and arguably for over
30 years, since the invention of MX, and nobody's found it urgent
enough to fix.

In my view the use of pr= efixes is what 'broke the DNS model'. A prefix is a different DNS n= ame that is logically a substitute for a new RR but has different semantics= to a new RR because it is a separate name.

So in my view the 'last try' resolution approac= h is merely a mechanism that fixes the breakage introduced by using prefixe= s to stand for new RRs.


=A0
If BNAME happens, it'll be a fairly effective band-aid for this
particular problem, which is pretty ironic since it's a complete
failure for the problem (making two TLDs equivalent) that it is
intended to solve.

That's a bit gen= erous. 'Not even a failure' is probably more accurate. For BNAME to= fail there would have to be a defined problem to be solved.=A0


--
Website: http://hallambaker.com/

--001636c9297d82b3f404aa917fbe-- From ilari.liusvaara@elisanet.fi Mon Aug 15 13:55:49 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E37621F8CE7 for ; Mon, 15 Aug 2011 13:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RFXqQQhJn1VZ for ; Mon, 15 Aug 2011 13:55:48 -0700 (PDT) Received: from emh07.mail.saunalahti.fi (emh07.mail.saunalahti.fi [62.142.5.117]) by ietfa.amsl.com (Postfix) with ESMTP id 6D33B21F8CEA for ; Mon, 15 Aug 2011 13:55:47 -0700 (PDT) Received: from saunalahti-vams (vs3-10.mail.saunalahti.fi [62.142.5.94]) by emh07-2.mail.saunalahti.fi (Postfix) with SMTP id CB05D18CEEA; Mon, 15 Aug 2011 23:56:32 +0300 (EEST) Received: from emh05.mail.saunalahti.fi ([62.142.5.111]) by vs3-10.mail.saunalahti.fi ([62.142.5.94]) with SMTP (gateway) id A056D6C637E; Mon, 15 Aug 2011 23:56:32 +0300 Received: from LK-Perkele-VI (a88-112-55-20.elisa-laajakaista.fi [88.112.55.20]) by emh05.mail.saunalahti.fi (Postfix) with ESMTP id 178CF27D84; Mon, 15 Aug 2011 23:56:30 +0300 (EEST) Date: Mon, 15 Aug 2011 23:51:12 +0300 From: Ilari Liusvaara To: Paul Hoffman Message-ID: <20110815205112.GA3178@LK-Perkele-VI.localdomain> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Ilari Liusvaara X-Antivirus: VAMS Cc: DANE WG Subject: Re: [dane] New protocol draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 Aug 2011 20:55:49 -0000 On Mon, Aug 15, 2011 at 08:53:00AM -0700, Paul Hoffman wrote: > Diffs at . > > We also added a new appendix, B, which is pseudocode for TLS resolution > with DANE. This section definitely needs careful review. If we muffed the > pseudocode, we need to fix it, but we also probably need to be clearer in > the main document about how the resolution works. Looks like you have mismatch between the code and the spec: What happens if one has the following: _443._tcp.foo.example. IN TLSA 1 3 b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c (and nonthing else) I.e. Known certificate type but unknown reference type. Right now the code tries to invoke unknown hash and then presumably rejects the server. AFAIK, the text specifies that fallback to legacy authentication should occur. -Ilari From ilari.liusvaara@elisanet.fi Mon Aug 15 14:21:43 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E1ED21F8D2F for ; Mon, 15 Aug 2011 14:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63QrEJUADMSf for ; Mon, 15 Aug 2011 14:21:42 -0700 (PDT) Received: from emh02.mail.saunalahti.fi (emh02.mail.saunalahti.fi [62.142.5.108]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC7221F8D2E for ; Mon, 15 Aug 2011 14:21:41 -0700 (PDT) Received: from saunalahti-vams (vs3-10.mail.saunalahti.fi [62.142.5.94]) by emh02-2.mail.saunalahti.fi (Postfix) with SMTP id B9F50EF78E; Tue, 16 Aug 2011 00:22:26 +0300 (EEST) Received: from emh02.mail.saunalahti.fi ([62.142.5.108]) by vs3-10.mail.saunalahti.fi ([62.142.5.94]) with SMTP (gateway) id A062DCB9D10; Tue, 16 Aug 2011 00:22:26 +0300 Received: from LK-Perkele-VI (a88-112-55-20.elisa-laajakaista.fi [88.112.55.20]) by emh02.mail.saunalahti.fi (Postfix) with ESMTP id 455DC2BD42; Tue, 16 Aug 2011 00:22:24 +0300 (EEST) Date: Tue, 16 Aug 2011 00:17:07 +0300 From: Ilari Liusvaara To: =?utf-8?B?T25kxZllaiBTdXLDvQ==?= Message-ID: <20110815211707.GB3178@LK-Perkele-VI.localdomain> References: <74B71A15-E1E1-4057-9C6B-4721FCC270C2@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <74B71A15-E1E1-4057-9C6B-4721FCC270C2@nic.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Ilari Liusvaara Content-Transfer-Encoding: quoted-printable X-Antivirus: VAMS Cc: dane@ietf.org Subject: Re: [dane] Opening issue #7: Error Handling : What to do when you receive an invalid record X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 Aug 2011 21:21:43 -0000 On Mon, Aug 15, 2011 at 04:47:49PM +0200, Ond=C5=99ej Sur=C3=BD wrote: > Hi, >=20 > I would like to open next issue on the mailing list: >=20 > http://trac.tools.ietf.org/wg/dane/trac/ticket/7 =20 Out of the 4 examples in the ticket itself, the first two just can't happen (all combinations of reference type and certificatie type are valid and meaningful). The other two examples are still relevant. SHA-1 is in no more, but the same can happen with, say SHA-256: 33 byte record (incomplete) or 35 byte record (excess bytes). And while what happens with unknown reference types is specified, what happens with unknown certificate types isn't. I still think those should be treated as usable-not-matching[1]. [1] Consider a _9418.tcp.foo.example only having one entry for type 4 certificate (unknown) referenced by type 1 (SHA-256, known). You connect to server and request TLS... Case I: You got the right server: The likely answer to ClientHello is: ALERT TLS 1.0 FATAL HANDSHAKE_FAILURE ... As the server lacks certificate recognizable to client. Case II: You got some wrong server: You might very well get X.509 certificate... Except that it is unlikely that type 4 is anything related to X.509... Fall back to legacy vailidation or reject the server? -Ilari From zack.weinberg@gmail.com Mon Aug 15 14:56:54 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A39FC11E80D2 for ; Mon, 15 Aug 2011 14:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwzjyKJYF12B for ; Mon, 15 Aug 2011 14:56:54 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 30FE911E80C5 for ; Mon, 15 Aug 2011 14:56:54 -0700 (PDT) Received: by pzk33 with SMTP id 33so5984545pzk.18 for ; Mon, 15 Aug 2011 14:57:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=FEguMPbSbp0AOeXVrCCi+wy2wvB3t233Itrh8rXZpO8=; b=ujqQzkLLkCATgxNO0w7ct/JCYI2+lUkKdkhTQr7n3pXJdOMjMYvhRZOjqFLmu2hlqO vKRwhWiY0/jcqZ6yzwMwFxUusYgrf7NiE49SGF6Wt1AxQX8nM3o4oBGJyCkTf8DbaQf3 i2VblqpwBATHdNlDEZxL5FqqVjZlfcvyCXuD8= MIME-Version: 1.0 Received: by 10.142.150.9 with SMTP id x9mr2263636wfd.183.1313445460627; Mon, 15 Aug 2011 14:57:40 -0700 (PDT) Sender: zack.weinberg@gmail.com Received: by 10.68.63.228 with HTTP; Mon, 15 Aug 2011 14:57:40 -0700 (PDT) In-Reply-To: <20110815211707.GB3178@LK-Perkele-VI.localdomain> References: <74B71A15-E1E1-4057-9C6B-4721FCC270C2@nic.cz> <20110815211707.GB3178@LK-Perkele-VI.localdomain> Date: Mon, 15 Aug 2011 14:57:40 -0700 X-Google-Sender-Auth: dPaA2p0atGYw0KrbhQoSk7f-dOI Message-ID: From: Zack Weinberg To: dane@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: Re: [dane] Opening issue #7: Error Handling : What to do when you receive an invalid record X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 Aug 2011 21:56:54 -0000 This is about the case where a TLSA record has a valid DNSSEC signature but is incomprehensible to the client, yes? I have not had a chance to read the latest draft, but would suggest these semantics: The client has received N (>=1) TLSA records in response to its query, all of which have valid DNSSEC signatures. Discard from this set all records which are incomprehensible, ill-formed, or semantically invalid. If any TLSA records remain after this step, proceed to try to match them against the TLS certificate chain. But if *no* TLSA records remain, fail hard. Rationale: Server operators should be able to deploy new TLSA record subtypes (most importantly, new hash algorithms) without breaking legacy client access, by serving both the new records and legacy-compatible records. However, if a server operator deploys a set of TLSA records *all* of which are broken in some way, they should get a prompt failure. Note also that if *any* record - TLSA or otherwise - is DNSSEC-bogus, that should cause a hard failure without even considering the comprehensibility of the record's contents. zw From ietf@augustcellars.com Mon Aug 15 15:17:13 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAC9221F8CDE for ; Mon, 15 Aug 2011 15:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8kLXw9vwZRpy for ; Mon, 15 Aug 2011 15:17:13 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 6A52B21F8CDB for ; Mon, 15 Aug 2011 15:17:13 -0700 (PDT) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 134B22CA28; Mon, 15 Aug 2011 15:17:59 -0700 (PDT) From: "Jim Schaad" To: "'Ilari Liusvaara'" References: <74B71A15-E1E1-4057-9C6B-4721FCC270C2@nic.cz> <20110815211707.GB3178@LK-Perkele-VI.localdomain> In-Reply-To: <20110815211707.GB3178@LK-Perkele-VI.localdomain> Date: Mon, 15 Aug 2011 15:52:20 -0700 Message-ID: <004801cc5b9d$ff52a0a0$fdf7e1e0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHzmcrXAa7573k1pdzaApVz2VR52AJIFiH+lL3GS6A= Content-Language: en-us Cc: dane@ietf.org Subject: Re: [dane] Opening issue #7: Error Handling : What to do when you receive an invalid record X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 Aug 2011 22:17:14 -0000 > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf = Of > Ilari Liusvaara > Sent: Monday, August 15, 2011 2:17 PM > To: Ondrej Sur=C3=BD > Cc: dane@ietf.org > Subject: Re: [dane] Opening issue #7: Error Handling : What to do when = you > receive an invalid record >=20 > On Mon, Aug 15, 2011 at 04:47:49PM +0200, Ondrej Sur wrote: > > Hi, > > > > I would like to open next issue on the mailing list: > > > > http://trac.tools.ietf.org/wg/dane/trac/ticket/7 >=20 > Out of the 4 examples in the ticket itself, the first two just can't = happen (all > combinations of reference type and certificatie type are valid and > meaningful). >=20 > The other two examples are still relevant. SHA-1 is in no more, but = the same > can happen with, say SHA-256: 33 byte record (incomplete) or 35 byte = record > (excess bytes). >=20 > And while what happens with unknown reference types is specified, what > happens with unknown certificate types isn't. I still think those = should be > treated as usable-not-matching[1]. I agree that this would be one possible answer - the other answer is = that it is not-usable >=20 > [1] Consider a _9418.tcp.foo.example only having one entry for type 4 > certificate (unknown) referenced by type 1 (SHA-256, known). >=20 > You connect to server and request TLS... >=20 >=20 > Case I: You got the right server: >=20 > The likely answer to ClientHello is: >=20 > ALERT TLS 1.0 FATAL HANDSHAKE_FAILURE >=20 > ... As the server lacks certificate recognizable to client. >=20 I would not agree with this statement. While the certificate may not be = recognizable, the new item may be a restriction on current X.509 = certificates. For example the new certificate type could be - you must = have the following extension in it. Or it could be the one which I keep = wanting which is a non-trust anchor CA certificate. >=20 > Case II: You got some wrong server: >=20 > You might very well get X.509 certificate... Except that it is = unlikely that type 4 > is anything related to X.509... Fall back to legacy vailidation or = reject the > server? >=20 >=20 >=20 >=20 > -Ilari > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From hallam@gmail.com Mon Aug 15 15:33:42 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 110ED21F8C8E for ; Mon, 15 Aug 2011 15:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.013 X-Spam-Level: X-Spam-Status: No, score=-3.013 tagged_above=-999 required=5 tests=[AWL=-0.315, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDXFD2gM6fAp for ; Mon, 15 Aug 2011 15:33:41 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 28D7521F8C83 for ; Mon, 15 Aug 2011 15:33:41 -0700 (PDT) Received: by gwb20 with SMTP id 20so3933757gwb.31 for ; Mon, 15 Aug 2011 15:34:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NOqBSxFOmLNR4hUwAjOY+Psr3a7DugdqOzxeanIab+4=; b=qzPcjX7wfhM6RfOU5QocL75b1GO7AXiRlXImZOcXWQE9xJdT3zLrZooUReZNkbX7Cm T9jOxO9uXu2VJTeQdNNgZVfrIqOv3L/EM1z+y3qsWxN73t0mnOIxIHr2i2cjH3ajBx24 plGXzbAsWiJOeQsB7THB3fp3hMRHRC1jBww+4= MIME-Version: 1.0 Received: by 10.101.170.11 with SMTP id x11mr4338877ano.145.1313447666852; Mon, 15 Aug 2011 15:34:26 -0700 (PDT) Received: by 10.100.94.14 with HTTP; Mon, 15 Aug 2011 15:34:26 -0700 (PDT) In-Reply-To: <74B71A15-E1E1-4057-9C6B-4721FCC270C2@nic.cz> References: <74B71A15-E1E1-4057-9C6B-4721FCC270C2@nic.cz> Date: Mon, 15 Aug 2011 23:34:26 +0100 Message-ID: From: Phillip Hallam-Baker To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Content-Type: multipart/alternative; boundary=001636c92b019d226704aa92dd8d Cc: dane@ietf.org Subject: Re: [dane] Opening issue #7: Error Handling : What to do when you receive an invalid record X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 Aug 2011 22:33:42 -0000 --001636c92b019d226704aa92dd8d Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Conclude that you cannot make any valid inferences from DANE information an= d proceed as if it was not there. That is what is done in DKIM. On Mon, Aug 15, 2011 at 3:47 PM, Ond=F8ej Sur=FD wrote= : > Hi, > > I would like to open next issue on the mailing list: > > http://trac.tools.ietf.org/wg/dane/trac/ticket/7 > > --cut here-- > From email from Jim Schaad: > Context -- Issue #7: Error Handling : What to do when you receive an > invalid record -- Addressed in Protocol doc ((e.g Section 4.4)) > > This is not fully addressed in the spec at present. Specifically what to = do > with unknown certificate types is not documented. Also I am not sure what > the correct behavior should be for mal-formatted items. I.e. if bytes are > missing or added to the current records. If you use an ASN.1 parser on th= e > certificate and compare it, rather than byte comparing it then trailing b= ad > bytes might be ignored. > --cut here-- > > I might open few more this week based on the traffic. > > O. > -- > Ond=F8ej Sur=FD > vedouc=ED v=FDzkumu/Head of R&D department > ------------------------------------------- > CZ.NIC, z.s.p.o. -- Laborato=F8e CZ.NIC > Americka 23, 120 00 Praha 2, Czech Republic > mailto:ondrej.sury@nic.cz http://nic.cz/ > tel:+420.222745110 fax:+420.222745112 > ------------------------------------------- > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > --=20 Website: http://hallambaker.com/ --001636c92b019d226704aa92dd8d Content-Type: text/html; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Conclude that you cannot make any valid inferences from DANE information an= d proceed as if it was not there.

That is what is done i= n DKIM.=A0


On Mon, Aug 15, 201= 1 at 3:47 PM, Ond=F8ej Sur=FD <ondrej.sury@nic.cz> wrote:
Hi,

I would like to open next issue on the mailing list:

http://trac.tools.ietf.org/wg/dane/trac/ticket/7

--cut here--
>From email from Jim Schaad:
Context -- Issue #7: Error Handling : What to do when you receive an invali= d record -- Addressed in Protocol doc ((e.g Section 4.4))

This is not fully addressed in the spec at present. Specifically what to do=
with unknown certificate types is not documented. Also I am not sure what the correct behavior should be for mal-formatted items. I.e. if bytes are missing or added to the current records. If you use an ASN.1 parser on the<= br> certificate and compare it, rather than byte comparing it then trailing bad=
bytes might be ignored.
--cut here--

I might open few more this week based on the traffic.

O.
--
=A0Ond=F8ej Sur=FD
=A0vedouc=ED v=FDzkumu/Head of R&D department
=A0-------------------------------------------
=A0CZ.NIC, z.s.p.o. =A0 =A0-- =A0 =A0Laborato=F8e CZ.NIC
=A0Americka 23, 120 00 Praha 2, Czech Republic
=A0mailto:ondrej.sury@nic.cz =A0 = =A0http://nic.cz/
=A0tel:+420.222745= 110 =A0 =A0 =A0 fax:+420.222745112
=A0-------------------------------------------

_______________________________________________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane



--
Website: http://hallambaker.com/

--001636c92b019d226704aa92dd8d-- From ietf@augustcellars.com Mon Aug 15 16:14:42 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C37E921F8CE0 for ; Mon, 15 Aug 2011 16:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.359 X-Spam-Level: X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mwoy5KPb0uOb for ; Mon, 15 Aug 2011 16:14:42 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 38F9021F8CDF for ; Mon, 15 Aug 2011 16:14:42 -0700 (PDT) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 019932CA41 for ; Mon, 15 Aug 2011 16:15:28 -0700 (PDT) From: "Jim Schaad" To: Date: Mon, 15 Aug 2011 16:49:52 -0700 Message-ID: <004c01cc5ba6$07951010$16bf3030$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcxbpR9EcFwUARMUQNKrb/vy7wNrRg== Content-Language: en-us Subject: [dane] Suggested Appendix A.1.2 Changes X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 Aug 2011 23:14:42 -0000 I would like to suggest the following be added to appendix A.1.2 The desired behavior of aliasing an entire subtree is possible for DANE due to the fact that we are using two layers of prefixing. If one has the following sub5.example.com IN CNAME sub6.example.com. _tcp.sub5.example.com IN DNAME _tcp.sub6.example.com. sub6.example.com IN A 10.0.0.0 _443._tcp.sub6.example.com IN TLSA 1 1 3082... In this case someone looking for the TLSA record for sub5.example.com using TCP would be directed to the _tcp.sub6.example.com tree for resolution of the record. This allows for a wholesale re-assignment of all TLSA records into a different tree. From ietf@augustcellars.com Mon Aug 15 16:19:07 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A127911E8097 for ; Mon, 15 Aug 2011 16:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2T4oLceriwEY for ; Mon, 15 Aug 2011 16:19:07 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 34E5211E8091 for ; Mon, 15 Aug 2011 16:19:07 -0700 (PDT) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id E88262CA56 for ; Mon, 15 Aug 2011 16:19:53 -0700 (PDT) From: "Jim Schaad" To: Date: Mon, 15 Aug 2011 16:54:18 -0700 Message-ID: <004d01cc5ba6$a5927780$f0b76680$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcxbpjlvGMqv4w5MQXeYqHjQKmkigA== Content-Language: en-us Subject: [dane] Adding a new appendix section A.1.4 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 Aug 2011 23:19:07 -0000 At present I do not have any suggested text for this section because I do not know enough details about how this would work. However I would like to see the addition of a new section A.1.4 Delegation of Provisioning TLSA Records. This section would discuss the use of NS records to delegate an entire subtree of an existing name space to a service provider. This should discuss the issues involved with coordination of key records. Jim From ietf@augustcellars.com Mon Aug 15 16:26:59 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C18DF11E80D5 for ; Mon, 15 Aug 2011 16:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.428 X-Spam-Level: X-Spam-Status: No, score=-3.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLYs+Dvr+tK8 for ; Mon, 15 Aug 2011 16:26:59 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 614FF11E8091 for ; Mon, 15 Aug 2011 16:26:59 -0700 (PDT) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id DD26A2CA52 for ; Mon, 15 Aug 2011 16:27:43 -0700 (PDT) From: "Jim Schaad" To: Date: Mon, 15 Aug 2011 17:02:07 -0700 Message-ID: <004e01cc5ba7$bdb0d310$39127930$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcxbpxAga4SnN/twQHaA7JM0iHMdIQ== Content-Language: en-us Subject: [dane] Suggested changes in Section A.1.1 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 Aug 2011 23:26:59 -0000 I believe that some operational comments should be added in at this point. So I would like to see the following text added: After Example #1 as part of the paragraph. If the domain owners of sub5.example.com and sub6.example.com are different, then changes in the TLSA records need to be propagated from one owner to the other before a new certificate can be rolled out. After Example #2 as part of the next paragraph. No coordination is needed between the domain owners of sub5.example.com and sub6.example.com when rolling out new TLSA records. After Example #3 as part of the next paragraph. If the domain owners of sub5.example.com and sub6.example.com are different, then changes in the TLSA records need to be propagated from one owner to the other before a new certificate can be rolled out. Jim From trac+dane@trac.tools.ietf.org Mon Aug 15 16:41:00 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBEAF21F8CB9 for ; Mon, 15 Aug 2011 16:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bMgyR9GOPle for ; Mon, 15 Aug 2011 16:41:00 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 71C5421F8CB7 for ; Mon, 15 Aug 2011 16:41:00 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1Qt6mu-0005Q8-C4; Mon, 15 Aug 2011 16:41:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: draft-ietf-dane-protocol@tools.ietf.org, jimsch@exmsft.com X-Trac-Project: dane Date: Mon, 15 Aug 2011 23:41:44 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dane/trac/ticket/29 Message-ID: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> X-Trac-Ticket-ID: 29 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dane-protocol@tools.ietf.org, jimsch@exmsft.com, dane@ietf.org X-SA-Exim-Mail-From: trac+dane@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20110815234100.71C5421F8CB7@ietfa.amsl.com> Resent-Date: Mon, 15 Aug 2011 16:41:00 -0700 (PDT) Resent-From: trac+dane@trac.tools.ietf.org Cc: dane@ietf.org Subject: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 23:41:01 -0000 #29: Request new Reference Type - Public Key I would like to be able to restrict to a certificate based solely on the public key value of the certificate. This could be used for any of the different Certificate Type fields. EE certificate, Trust Anchor certificate and the missing ones for intermediate certificate and pgp certificate. -- --------------------------------+------------------------------------------- Reporter: jimsch@… | Owner: draft-ietf-dane-protocol@… Type: enhancement | Status: new Priority: major | Milestone: milestone1 Component: protocol | Version: 1.0 Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Ticket URL: dane From ietf@augustcellars.com Mon Aug 15 16:48:42 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15A2F21F8BF8 for ; Mon, 15 Aug 2011 16:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sf4ettwwLkyM for ; Mon, 15 Aug 2011 16:48:41 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id A6A5121F8BDB for ; Mon, 15 Aug 2011 16:48:41 -0700 (PDT) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 5421338F13 for ; Mon, 15 Aug 2011 16:49:28 -0700 (PDT) From: "Jim Schaad" To: Date: Mon, 15 Aug 2011 17:23:52 -0700 Message-ID: <004f01cc5baa$c72943c0$557bcb40$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcxbqAqgcs5C9OCfReCGBaKvcbETwA== Content-Language: en-us Subject: [dane] Comments on Appendex B X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 Aug 2011 23:48:42 -0000 1. The text makes the assumption at all new reference types are going to be hashes. I do not agree that this is true statement. Therefore the second condition should be Else if (R.referenceType is both known and a hash) AND (hash(R.referenceType of C) == R.certAssoc) { 2. The comment for R.certType == 2 is incorrect. I believe it should be: // a PKIX certificate that identifies a Trust Anchor 3. Is there a reason that the hash checks were emitted from the R.certType == 2 logic? If not then this should be tagged as an invalid record and the logic for handling this event is deferred until the end of the loop (i.e. set a state variable and continue). Specifically this text does not distinguish between an unrecognized record type and an ill formed record type in any way. This is a current discussion topic. 4. See comment #1 about the text for R.certType == 3 as well. Jim From paul.hoffman@vpnc.org Mon Aug 15 19:39:25 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A105821F8CED for ; Mon, 15 Aug 2011 19:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.384 X-Spam-Level: X-Spam-Status: No, score=-102.384 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7TXOsc8Ur7JT for ; Mon, 15 Aug 2011 19:39:25 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3033321F8CEB for ; Mon, 15 Aug 2011 19:39:25 -0700 (PDT) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p7G2dlGw015581 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 15 Aug 2011 19:39:47 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <74B71A15-E1E1-4057-9C6B-4721FCC270C2@nic.cz> Date: Mon, 15 Aug 2011 19:40:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <74B71A15-E1E1-4057-9C6B-4721FCC270C2@nic.cz> To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= X-Mailer: Apple Mail (2.1244.3) Cc: dane@ietf.org Subject: Re: [dane] Opening issue #7: Error Handling : What to do when you receive an invalid record X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Aug 2011 02:39:25 -0000 Make it unusable. Current: If a certificate association contains a reference type that is not understood by the TLS client, that certificate association MUST be marked as unusable. Proposed: If a certificate association contains a reference type or certificate = type that is not understood by the TLS client, that certificate association MUST be marked as unusable. If an error occurs when comparing using reference types that are not exact matches (such as hashes), the certificate association MUST be marked as unusable. --Paul Hoffman From paul.hoffman@vpnc.org Mon Aug 15 19:41:54 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7069521F8CF1 for ; Mon, 15 Aug 2011 19:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4aG949TGwNmy for ; Mon, 15 Aug 2011 19:41:54 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 00D7421F8CF0 for ; Mon, 15 Aug 2011 19:41:53 -0700 (PDT) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p7G2gFCv015642 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 15 Aug 2011 19:42:16 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> Date: Mon, 15 Aug 2011 19:42:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6FEA0C14-314B-46FA-B4CB-601EAE1E209A@vpnc.org> References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> To: dane issue tracker X-Mailer: Apple Mail (2.1244.3) Cc: DANE WG Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Aug 2011 02:41:54 -0000 On Aug 15, 2011, at 4:41 PM, dane issue tracker wrote: > #29: Request new Reference Type - Public Key >=20 > I would like to be able to restrict to a certificate based solely on = the > public key value of the certificate. This could be used for any of = the > different Certificate Type fields. EE certificate, Trust Anchor > certificate and the missing ones for intermediate certificate and pgp > certificate. That seems fine. Is there any text in the current draft that prevents = you from doing that? --Paul Hoffman From ietf@augustcellars.com Mon Aug 15 20:14:24 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37F6C21F8C8A for ; Mon, 15 Aug 2011 20:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.282 X-Spam-Level: X-Spam-Status: No, score=-3.282 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0GEby1VlYyzf for ; Mon, 15 Aug 2011 20:14:23 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id BB0B621F8C89 for ; Mon, 15 Aug 2011 20:14:23 -0700 (PDT) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 8A8422C9C5; Mon, 15 Aug 2011 20:15:10 -0700 (PDT) From: "Jim Schaad" To: "'Paul Hoffman'" , =?iso-8859-1?Q?'Ondrej_Sur=FD'?= References: <74B71A15-E1E1-4057-9C6B-4721FCC270C2@nic.cz> In-Reply-To: Date: Mon, 15 Aug 2011 20:49:35 -0700 Message-ID: <006301cc5bc7$860006f0$920014d0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHzmcrXAa7573k1pdzaApVz2VR52AOF76/dlLQq8WA= Content-Language: en-us Cc: dane@ietf.org Subject: Re: [dane] Opening issue #7: Error Handling : What to do when you receive an invalid record X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Aug 2011 03:14:24 -0000 > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf = Of > Paul Hoffman > Sent: Monday, August 15, 2011 7:40 PM > To: Ondrej Sur=FD > Cc: dane@ietf.org > Subject: Re: [dane] Opening issue #7: Error Handling : What to do when = you > receive an invalid record >=20 > Make it unusable. >=20 > Current: > If a certificate association contains a reference type that is not > understood by the TLS client, that certificate association MUST be > marked as unusable. > Proposed: > If a certificate association contains a reference type or = certificate type that > is not > understood by the TLS client, that certificate association MUST be > marked as unusable. If an error occurs when comparing using > reference types that are not exact matches (such as hashes), the > certificate association MUST be marked as unusable. If an error occurs when comparing using reference types, the certificate association MUST be marked as unusable. -- I don't understand why there is a reason for the 'not exact matches', = it should not matter as long as the comparison is done in the correct = manner if you are comparing either the direct bytes or via a function such as a = hash. -- Note that the statement that it be marked as unusable does not match = the pseudo code in appendix B unless there is a check someplace in the code = that I missed for things which are marked unusable as oppose to a usable but failed check. Jim >=20 > --Paul Hoffman >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From ietf@augustcellars.com Mon Aug 15 20:23:58 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87A1321F8CA9 for ; Mon, 15 Aug 2011 20:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.434 X-Spam-Level: X-Spam-Status: No, score=-3.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJ2pBm-FTrhY for ; Mon, 15 Aug 2011 20:23:58 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 084B221F8CA8 for ; Mon, 15 Aug 2011 20:23:57 -0700 (PDT) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 2DCC32CA41; Mon, 15 Aug 2011 20:24:45 -0700 (PDT) From: "Jim Schaad" To: "'Paul Hoffman'" , "'dane issue tracker'" References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <6FEA0C14-314B-46FA-B4CB-601EAE1E209A@vpnc.org> In-Reply-To: <6FEA0C14-314B-46FA-B4CB-601EAE1E209A@vpnc.org> Date: Mon, 15 Aug 2011 20:59:12 -0700 Message-ID: <006401cc5bc8$dc94ae20$95be0a60$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHwXbPL2/IzPDFsf9e9Pk9vZhBFJQH/Ia23lMbasIA= Content-Language: en-us Cc: 'DANE WG' Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Aug 2011 03:23:58 -0000 Other than the fact that there is no reference type defined for public key - no there is no text that would prevent me from doing this. I could write a new draft that would define a new reference type of public key and go forward. If this proposal is accepted, then the following document changes would need to be made: -- Section 2.1.2 would add a new item to the register 3 -- Public Key expressed as PKIX SubjectPublicKeyInfo (Note that the format would be under some debate for PGP bit is clear it would be the best for X.509 and possibly bare keys). -- A new section (or possibly a set of subsections for Section 2.1.2) would need to be created to describe how the comparisons to public keys are done. This would be mostly for completeness and would allow for an easy way of saying which pairs (if any) are to be considered as valid/invalid. Positive statements would be preferred. -- Throughout the document, all places where it is assumed that the only reference types are either exact match or hash would need to be updated to reflect that there are more than two classes of reference types. Jim > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of > Paul Hoffman > Sent: Monday, August 15, 2011 7:43 PM > To: dane issue tracker > Cc: DANE WG > Subject: Re: [dane] #29: Request new Reference Type - Public Key > > > On Aug 15, 2011, at 4:41 PM, dane issue tracker wrote: > > > #29: Request new Reference Type - Public Key > > > > I would like to be able to restrict to a certificate based solely on > > the public key value of the certificate. This could be used for any > > of the different Certificate Type fields. EE certificate, Trust > > Anchor certificate and the missing ones for intermediate certificate > > and pgp certificate. > > That seems fine. Is there any text in the current draft that prevents you from > doing that? > > --Paul Hoffman > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From matt@mattmccutchen.net Mon Aug 15 20:31:20 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E135B11E8086 for ; Mon, 15 Aug 2011 20:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.278 X-Spam-Level: X-Spam-Status: No, score=-2.278 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jRiKen9Uygp for ; Mon, 15 Aug 2011 20:31:20 -0700 (PDT) Received: from homiemail-a5.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 6F32A11E8085 for ; Mon, 15 Aug 2011 20:31:20 -0700 (PDT) Received: from homiemail-a5.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a5.g.dreamhost.com (Postfix) with ESMTP id B2C8F70406F; Mon, 15 Aug 2011 20:32:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=DhUSx9b4wO+otcbXg+BA7APGDDZLGdU1x71zfI4tNhp 5gnd7V4IWOlqnPUQ9AQTA/hQTiZgysRxJCsPNRuxu1gebDKT4dg1ipzIPcUoWx6Z k6fO4BG+vbf97oaSQhooSMJOlM/E+9AZ8BMS/1CSwKgIDs+ZmyV2KyjS7WwX9IJ4 = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=z9jSFJegtzewAjrmAvdDmmlPYvw=; b=mhTNf+XF3W jDC7A2FZKG1S0InBJyl9DgQPZ7XzeUu9ejTyVh1cV+uOlkzu2zE58qyNGu7KHfFl hgRrA/IJieAk1p/ewYEumvipKnlSQ35/oomeRW6NtwfoE4HXf9hRGtxZvBL+K65P RaWATMFPqSsAAIZzWC/jIpYoLDmWWoBlY= Received: from [192.168.1.39] (pool-96-231-14-217.washdc.east.verizon.net [96.231.14.217]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a5.g.dreamhost.com (Postfix) with ESMTPSA id 3240C704014; Mon, 15 Aug 2011 20:32:07 -0700 (PDT) From: Matt McCutchen To: =?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <8E6F94D0-BD4E-43C1-80B7-226CE6C8C59B@nic.cz> References: <6B5F4F0A-82F2-4911-81B6-F923D7529E4A@nic.cz> <8E6F94D0-BD4E-43C1-80B7-226CE6C8C59B@nic.cz> Content-Type: text/plain; charset="UTF-8" Date: Mon, 15 Aug 2011 23:32:05 -0400 Message-ID: <1313465525.3952.0.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: quoted-printable Cc: dane@ietf.org Subject: Re: [dane] Closing issue #24 (Was: Call for consensus for CNAME) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Aug 2011 03:31:21 -0000 On Mon, 2011-08-15 at 16:28 +0200, Ond=C5=99ej Sur=C3=BD wrote: > Based on this I am closing #24 and will work with Matt on opening > the wildcards when his proposal is ready. Umm... #24 includes wildcards. Did you mean to split it up? --=20 Matt From paul.hoffman@vpnc.org Mon Aug 15 20:37:30 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A17221F8888 for ; Mon, 15 Aug 2011 20:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O26ury3EiVW3 for ; Mon, 15 Aug 2011 20:37:30 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id D3B2421F8880 for ; Mon, 15 Aug 2011 20:37:29 -0700 (PDT) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p7G3bpb1017053 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 15 Aug 2011 20:37:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <006401cc5bc8$dc94ae20$95be0a60$@augustcellars.com> Date: Mon, 15 Aug 2011 20:38:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <6FEA0C14-314B-46FA-B4CB-601EAE1E209A@vpnc.org> <006401cc5bc8$dc94ae20$95be0a60$@augustcellars.com> To: DANE WG X-Mailer: Apple Mail (2.1244.3) Cc: dane issue tracker Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Aug 2011 03:37:30 -0000 On Aug 15, 2011, at 8:59 PM, Jim Schaad wrote: > Other than the fact that there is no reference type defined for public = key - > no there is no text that would prevent me from doing this. =20 There is no reference type, but there is a certificate type. Is the problem that 2.1.2 says "certificate" when it means "the value = specified by certificate type field"? --Paul Hoffman From ietf@augustcellars.com Mon Aug 15 21:14:35 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D927E21F8ADC for ; Mon, 15 Aug 2011 21:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eay1EvF5aCIM for ; Mon, 15 Aug 2011 21:14:35 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 1039621F8AD9 for ; Mon, 15 Aug 2011 21:14:35 -0700 (PDT) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 17F952CA20; Mon, 15 Aug 2011 21:15:21 -0700 (PDT) From: "Jim Schaad" To: "'Paul Hoffman'" , "'DANE WG'" References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <6FEA0C14-314B-46FA-B4CB-601EAE1E209A@vpnc.org> <006401cc5bc8$dc94ae20$95be0a60$@augustcellars.com> In-Reply-To: Date: Mon, 15 Aug 2011 21:49:48 -0700 Message-ID: <006b01cc5bcf$ef1a5520$cd4eff60$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHwXbPL2/IzPDFsf9e9Pk9vZhBFJQH/Ia23Aggnm/8B3aWeNZSnvC/Q Content-Language: en-us Cc: 'dane issue tracker' Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Aug 2011 04:14:36 -0000 No - What I want is exactly what I requested - a reference type of public key. This would allow me to say that the EE certificate has a specific public key, I can then roll the EE certificate over to my heart's content. Additionally I could say that the Trust anchor has a specific key value rather than saying this is the certificate for a trust anchor. It is possible that if this is adopted then the public key certificate type could be replaced with a "bare public key" certificate type rather than the current "this is a public key" certificate. I believe that this would be a cleaner division of things. Jim > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of > Paul Hoffman > Sent: Monday, August 15, 2011 8:38 PM > To: DANE WG > Cc: dane issue tracker > Subject: Re: [dane] #29: Request new Reference Type - Public Key > > > On Aug 15, 2011, at 8:59 PM, Jim Schaad wrote: > > > Other than the fact that there is no reference type defined for public > > key - no there is no text that would prevent me from doing this. > > There is no reference type, but there is a certificate type. > > Is the problem that 2.1.2 says "certificate" when it means "the value > specified by certificate type field"? > > --Paul Hoffman > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From peter@denic.de Mon Aug 15 22:14:46 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5838711E8098 for ; Mon, 15 Aug 2011 22:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.174 X-Spam-Level: X-Spam-Status: No, score=-102.174 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lan0ZTogTeGS for ; Mon, 15 Aug 2011 22:14:45 -0700 (PDT) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::4]) by ietfa.amsl.com (Postfix) with ESMTP id B69EA11E8085 for ; Mon, 15 Aug 2011 22:14:45 -0700 (PDT) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1QtBzw-0004FQ-Po; Tue, 16 Aug 2011 07:15:32 +0200 Received: from localhost by x27.adm.denic.de with local id 1QtBzw-00051c-Lz; Tue, 16 Aug 2011 07:15:32 +0200 Date: Tue, 16 Aug 2011 07:15:32 +0200 From: Peter Koch To: dane@ietf.org Message-ID: <20110816051532.GU11178@x27.adm.denic.de> Mail-Followup-To: dane@ietf.org References: <20110815084527.GM11178@x27.adm.denic.de> <20110815142732.GD12253@shinkuro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110815142732.GD12253@shinkuro.com> User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: Re: [dane] discussion Re: Call for consensus for CNAME X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Aug 2011 05:14:46 -0000 On Mon, Aug 15, 2011 at 10:27:33AM -0400, Andrew Sullivan wrote: > Those two sentences are inconsistent. If CNAME allows subordinate > names lower in the tree than the CNAME, then it simply isn't true that > "the prefixed data is considered belonging to the (aliased) node." it might well look inconsistent, but it isn't, because we're dealing with two different layers at the same time. Or it is - but that's exactly the problem. Prefixes are an attempt to extend the QTYPE space to mitigate the subtyping problem and the lack of parametrized query types. This is why both the SRV specification and the protocol document in section 3 provide an algorithm for deriving the QNAME from the name the data is associated with. To that extent, "prefixed names" are inconsistent with regular types. This brokenness isn't new since DANE, but it's a brokenness - or irregularity if you'd prefer slightly milder language. So, when the real name for foo.example.org is bar.example.net, it would be quite logical to say that all derivatives of foo.example.org would instead have to be derived from bar.example.net. However, we do not have a protocol intrinsic way to implement or even enforce that since - in contrast to its CNAME logic - the protocol is "prefix agnostic". > people want a different RRTYPE that redirects descendents too, then > they need to address the problems with the BNAME or CNAME+DNAME > proposals on the back burner in dnsext. This wouldn't help and BNAME can't fly for various reasons to start with. And i do not believe theer is a solution because the prefix irregularity is insoluable. All we can do is acknowledge it and document that while for a connection to foo.example.org you really ought to connect to bar.example.net but nonetheless the properties of that connection are still described based on the alias name foo.example.org. > CNAME redirects that node, and nothing else. True, but already uncontested. -Peter From rbarnes@bbn.com Tue Aug 16 07:03:43 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0F9E21F8B30 for ; Tue, 16 Aug 2011 07:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.549 X-Spam-Level: X-Spam-Status: No, score=-106.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqveVoCWk70y for ; Tue, 16 Aug 2011 07:03:43 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC0921F8B03 for ; Tue, 16 Aug 2011 07:03:43 -0700 (PDT) Received: from ros-dhcp192-1-51-76.bbn.com ([192.1.51.76]:61468) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QtKFn-000ARJ-Fz; Tue, 16 Aug 2011 10:04:27 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <006b01cc5bcf$ef1a5520$cd4eff60$@augustcellars.com> Date: Tue, 16 Aug 2011 10:04:26 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <6FEA0C14-314B-46FA-B4CB-601EAE1E209A@vpnc.org> <006401cc5bc8$dc94ae20$95be0a60$@augustcellars.com> <006b01cc5bcf$ef1a5520$cd4eff60$@augustcellars.com> To: "Jim Schaad" X-Mailer: Apple Mail (2.1082) Cc: 'dane issue tracker' , 'Paul Hoffman' , 'DANE WG' Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Aug 2011 14:03:44 -0000 +1 subjectPublicKeyInfo / digest(subjectPublicKeyInfo) should be a RefType = and not a CertType. (I think I raised this in my earlier review.) = Right now, the draft seems confused about the semantics of the two = fields:=20 CertType =3D=3D How to use the certificate RefType =3D=3D How certificate is identified/encoded If it would help to have better names for these things, I would suggest = something like "Usage" for the first one. --Richard On Aug 16, 2011, at 12:49 AM, Jim Schaad wrote: > No - What I want is exactly what I requested - a reference type of = public > key. >=20 > This would allow me to say that the EE certificate has a specific = public > key, I can then roll the EE certificate over to my heart's content. > Additionally I could say that the Trust anchor has a specific key = value > rather than saying this is the certificate for a trust anchor. >=20 > It is possible that if this is adopted then the public key certificate = type > could be replaced with a "bare public key" certificate type rather = than the > current "this is a public key" certificate. I believe that this would = be a > cleaner division of things. >=20 > Jim >=20 >=20 >> -----Original Message----- >> From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf = Of >> Paul Hoffman >> Sent: Monday, August 15, 2011 8:38 PM >> To: DANE WG >> Cc: dane issue tracker >> Subject: Re: [dane] #29: Request new Reference Type - Public Key >>=20 >>=20 >> On Aug 15, 2011, at 8:59 PM, Jim Schaad wrote: >>=20 >>> Other than the fact that there is no reference type defined for = public >>> key - no there is no text that would prevent me from doing this. >>=20 >> There is no reference type, but there is a certificate type. >>=20 >> Is the problem that 2.1.2 says "certificate" when it means "the value >> specified by certificate type field"? >>=20 >> --Paul Hoffman >>=20 >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From rbarnes@bbn.com Tue Aug 16 07:10:35 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35EB321F8B43 for ; Tue, 16 Aug 2011 07:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.552 X-Spam-Level: X-Spam-Status: No, score=-106.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJqItgGmDzvp for ; Tue, 16 Aug 2011 07:10:34 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id A1AD121F8B37 for ; Tue, 16 Aug 2011 07:10:34 -0700 (PDT) Received: from ros-dhcp192-1-51-76.bbn.com ([192.1.51.76]:61498) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QtKMM-000AXZ-L0 for dane@ietf.org; Tue, 16 Aug 2011 10:11:14 -0400 From: "Richard L. Barnes" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Aug 2011 10:11:14 -0400 Message-Id: <70F5FD47-8862-4A4C-84AE-BC7708AB50C2@bbn.com> To: DANE WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [dane] Protocol / port numbers as prefix X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Aug 2011 14:10:35 -0000 It is clearly causing some people discomfort to have protocols and port = numbers as prefixes. Why not just push them into the RRDATA and = provision the TLSA directly under the affected name? =20 On the one hand... -- CNAME works as Phil expects it to -- Wildcarding works cleanly On the other hand... -- CNAME would always allow target zone to control TLSA=20 -- Easy to enumerate TLSA services on a given host=20 -> But you could do this anyway with a few extra queries -- Large response sizes if a host has many services -> Still probably dominated by DNSSEC overhead I don't really have a dog in this fight, but thought the possibility = worth raising. Thoughts? --Richard= From ondrej.sury@nic.cz Tue Aug 16 08:25:20 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3416321F8BF3 for ; Tue, 16 Aug 2011 08:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R4UMbyXHE6y1 for ; Tue, 16 Aug 2011 08:25:19 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 3447B11E807F for ; Tue, 16 Aug 2011 08:25:18 -0700 (PDT) Received: from kimac.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 13D9F2A2C8C; Tue, 16 Aug 2011 17:26:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1313508366; bh=WDFbGJHi/DNOC62Fk2Srasl3pg81ARd/lzCRyx9kGIE=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=wkRTGzAkRtps/pT7dIFJC/nhXfAfRXhwE7mWjO3It77NU8LcLtk9Rz3cLNLghN6v9 PS9Ka0kIYlfIv3JH3gl1Cai0IaBgQpDVsFbFOer93g0vzNpmggTiYUXGaDbwxNOqtR UYkJ9jj8tYX9O3z8OTd1cBStWrhlKtHOp6CsAEFM= Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <70F5FD47-8862-4A4C-84AE-BC7708AB50C2@bbn.com> Date: Tue, 16 Aug 2011 17:26:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <70F5FD47-8862-4A4C-84AE-BC7708AB50C2@bbn.com> To: Richard L. Barnes X-Mailer: Apple Mail (2.1244.3) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: DANE WG Subject: Re: [dane] Protocol / port numbers as prefix X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Aug 2011 15:25:20 -0000 On 16. 8. 2011, at 16:11, Richard L. Barnes wrote: > It is clearly causing some people discomfort to have protocols and = port numbers as prefixes. Why not just push them into the RRDATA and = provision the TLSA directly under the affected name? =20 Hi Richard, I would like to point out that we already had this discussion (at least = once): http://trac.tools.ietf.org/wg/dane/trac/ticket/1 and here is the mail thread: http://www.ietf.org/mail-archive/web/keyassure/current/msg01631.html While I don't have a problem reopening the issue if that's what the WG wants I would prefer to not reiterate the same issues again and again unless you (all) at least read the mailing list archives. Thanks, O. -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From rbarnes@bbn.com Tue Aug 16 08:45:40 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E9ED21F8A4D for ; Tue, 16 Aug 2011 08:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.105 X-Spam-Level: X-Spam-Status: No, score=-106.105 tagged_above=-999 required=5 tests=[AWL=-0.406, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nyw2HdPsttv for ; Tue, 16 Aug 2011 08:45:39 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 807D611E80A1 for ; Tue, 16 Aug 2011 08:45:39 -0700 (PDT) Received: from ros-dhcp192-1-51-76.bbn.com ([192.1.51.76]:61903) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QtLqP-000Bui-HT; Tue, 16 Aug 2011 11:46:21 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=utf-8 From: "Richard L. Barnes" In-Reply-To: Date: Tue, 16 Aug 2011 11:46:19 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9103D852-36CE-462D-8306-0B348B4FE4F0@bbn.com> References: <70F5FD47-8862-4A4C-84AE-BC7708AB50C2@bbn.com> To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= X-Mailer: Apple Mail (2.1082) Cc: DANE WG Subject: Re: [dane] Protocol / port numbers as prefix X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Aug 2011 15:45:40 -0000 Ah, there it is. I was just summarizing because I hadn't found a record = of this debate having happened. Consider my comment withdrawn. --Richard On Aug 16, 2011, at 11:26 AM, Ond=C5=99ej Sur=C3=BD wrote: > On 16. 8. 2011, at 16:11, Richard L. Barnes wrote: >> It is clearly causing some people discomfort to have protocols and = port numbers as prefixes. Why not just push them into the RRDATA and = provision the TLSA directly under the affected name? =20 >=20 >=20 > Hi Richard, >=20 > I would like to point out that we already had this discussion (at = least once): >=20 > http://trac.tools.ietf.org/wg/dane/trac/ticket/1 >=20 > and here is the mail thread: >=20 > http://www.ietf.org/mail-archive/web/keyassure/current/msg01631.html >=20 > While I don't have a problem reopening the issue if that's what > the WG wants I would prefer to not reiterate the same issues > again and again unless you (all) at least read the mailing list > archives. >=20 > Thanks, > O. >=20 > -- > Ond=C5=99ej Sur=C3=BD > vedouc=C3=AD v=C3=BDzkumu/Head of R&D department > ------------------------------------------- > CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC > Americka 23, 120 00 Praha 2, Czech Republic > mailto:ondrej.sury@nic.cz http://nic.cz/ > tel:+420.222745110 fax:+420.222745112 > ------------------------------------------- >=20 From hallam@gmail.com Tue Aug 16 08:55:41 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E72511E80A5 for ; Tue, 16 Aug 2011 08:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.153 X-Spam-Level: X-Spam-Status: No, score=-3.153 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vxPJWCrlbuai for ; Tue, 16 Aug 2011 08:55:40 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 43D6011E8085 for ; Tue, 16 Aug 2011 08:55:40 -0700 (PDT) Received: by gyf3 with SMTP id 3so30324gyf.31 for ; Tue, 16 Aug 2011 08:56:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5uR1b7ZKghn1fi3iKy8HUOPZ/suCVCNn0xM2G+nLUrA=; b=BVYwBKuK1XLINEejkJyHEWbUhDi6chKwec6d9CXlGyuVN2spI9HPpfGSnmQgnangkj O7XRrx7CINMVBXHF3RlmTreNzV55sPEOCHrE2/VutVVeJPCTRtBD4j/AXgYbYRxKdYN2 2SqUtdn5ufu9G0PLYTweCaZG0xGXF9ksLyHfw= MIME-Version: 1.0 Received: by 10.101.170.11 with SMTP id x11mr5239721ano.145.1313510181831; Tue, 16 Aug 2011 08:56:21 -0700 (PDT) Received: by 10.100.94.14 with HTTP; Tue, 16 Aug 2011 08:56:21 -0700 (PDT) In-Reply-To: <9103D852-36CE-462D-8306-0B348B4FE4F0@bbn.com> References: <70F5FD47-8862-4A4C-84AE-BC7708AB50C2@bbn.com> <9103D852-36CE-462D-8306-0B348B4FE4F0@bbn.com> Date: Tue, 16 Aug 2011 16:56:21 +0100 Message-ID: From: Phillip Hallam-Baker To: "Richard L. Barnes" Content-Type: multipart/alternative; boundary=001636c92b01cc02c104aaa16b19 Cc: DANE WG Subject: Re: [dane] Protocol / port numbers as prefix X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Aug 2011 15:55:41 -0000 --001636c92b01cc02c104aaa16b19 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable The problem then is that DNS does not really allow for 65536 RRs in the sam= e node. So it does not work out the way people think. I still think people are going to be getting rather a shock when they try t= o deploy for large Web farms. Google certainly can't use this for https://www.google.com/. On Tue, Aug 16, 2011 at 4:46 PM, Richard L. Barnes wrote: > Ah, there it is. I was just summarizing because I hadn't found a record = of > this debate having happened. Consider my comment withdrawn. > > --Richard > > > On Aug 16, 2011, at 11:26 AM, Ond=F8ej Sur=FD wrote: > > > On 16. 8. 2011, at 16:11, Richard L. Barnes wrote: > >> It is clearly causing some people discomfort to have protocols and por= t > numbers as prefixes. Why not just push them into the RRDATA and provisio= n > the TLSA directly under the affected name? > > > > > > Hi Richard, > > > > I would like to point out that we already had this discussion (at least > once): > > > > http://trac.tools.ietf.org/wg/dane/trac/ticket/1 > > > > and here is the mail thread: > > > > http://www.ietf.org/mail-archive/web/keyassure/current/msg01631.html > > > > While I don't have a problem reopening the issue if that's what > > the WG wants I would prefer to not reiterate the same issues > > again and again unless you (all) at least read the mailing list > > archives. > > > > Thanks, > > O. > > > > -- > > Ond=F8ej Sur=FD > > vedouc=ED v=FDzkumu/Head of R&D department > > ------------------------------------------- > > CZ.NIC, z.s.p.o. -- Laborato=F8e CZ.NIC > > Americka 23, 120 00 Praha 2, Czech Republic > > mailto:ondrej.sury@nic.cz http://nic.cz/ > > tel:+420.222745110 fax:+420.222745112 > > ------------------------------------------- > > > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > --=20 Website: http://hallambaker.com/ --001636c92b01cc02c104aaa16b19 Content-Type: text/html; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable The problem then is that DNS does not really allow for 65536 RRs in the sam= e node. So it does not work out the way people think.

I = still think people are going to be getting rather a shock when they try to = deploy for large Web farms. Google certainly can't use this for https://www.google.com/.

On Tue, Aug 16, 2011 at 4:46 PM, Richard L. = Barnes <rbarnes@bbn= .com> wrote:
Ah, there it is. =A0I was just summarizing because I hadn't found a rec= ord of this debate having happened. =A0Consider my comment withdrawn.

--Richard


On Aug 16, 2011, at 11:26 AM, Ond=F8ej Sur=FD wrote:

> On 16. 8. 2011, at 16:11, Richard L. Barnes wrote:
>> It is clearly causing some people discomfort to have protocols and= port numbers as prefixes. =A0Why not just push them into the RRDATA and pr= ovision the TLSA directly under the affected name?
>
>
> Hi Richard,
>
> I would like to point out that we already had this discussion (at leas= t once):
>
> http://trac.tools.ietf.org/wg/dane/trac/ticket/1
>
> and here is the mail thread:
>
> http://www.ietf.org/mail-archive/web/keyassure= /current/msg01631.html
>
> While I don't have a problem reopening the issue if that's wha= t
> the WG wants I would prefer to not reiterate the same issues
> again and again unless you (all) at least read the mailing list
> archives.
>
> Thanks,
> O.
>
> --
> Ond=F8ej Sur=FD
> vedouc=ED v=FDzkumu/Head of R&D department
> -------------------------------------------
> CZ.NIC, z.s.p.o. =A0 =A0-- =A0 =A0Laborato=F8e CZ.NIC
> Americka 23, 120 00 Praha 2, Czech Republic
> mailto:ondrej.sury@nic.cz = =A0 =A0http://nic.cz/
> tel:+420.2227= 45110 =A0 =A0 =A0 fax:+420.222745112
> -------------------------------------------
>

_______________________________________________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane



--
= Website: http://hallambaker.com/
--001636c92b01cc02c104aaa16b19-- From ilari.liusvaara@elisanet.fi Tue Aug 16 09:10:57 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F7821F8C17 for ; Tue, 16 Aug 2011 09:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmDsqrRkUTwL for ; Tue, 16 Aug 2011 09:10:57 -0700 (PDT) Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) by ietfa.amsl.com (Postfix) with ESMTP id A459621F8BB7 for ; Tue, 16 Aug 2011 09:10:56 -0700 (PDT) Received: from saunalahti-vams (vs3-12.mail.saunalahti.fi [62.142.5.96]) by emh04-2.mail.saunalahti.fi (Postfix) with SMTP id E23FB13C398; Tue, 16 Aug 2011 19:11:34 +0300 (EEST) Received: from emh05.mail.saunalahti.fi ([62.142.5.111]) by vs3-12.mail.saunalahti.fi ([62.142.5.96]) with SMTP (gateway) id A05516C5AFA; Tue, 16 Aug 2011 19:11:34 +0300 Received: from LK-Perkele-VI (a88-112-55-20.elisa-laajakaista.fi [88.112.55.20]) by emh05.mail.saunalahti.fi (Postfix) with ESMTP id 8F98027D86; Tue, 16 Aug 2011 19:11:20 +0300 (EEST) Date: Tue, 16 Aug 2011 19:06:04 +0300 From: Ilari Liusvaara To: "Richard L. Barnes" Message-ID: <20110816160604.GA23775@LK-Perkele-VI.localdomain> References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <6FEA0C14-314B-46FA-B4CB-601EAE1E209A@vpnc.org> <006401cc5bc8$dc94ae20$95be0a60$@augustcellars.com> <006b01cc5bcf$ef1a5520$cd4eff60$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Ilari Liusvaara X-Antivirus: VAMS Cc: 'DANE WG' , 'Paul Hoffman' , 'dane issue tracker' Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Aug 2011 16:10:57 -0000 On Tue, Aug 16, 2011 at 10:04:26AM -0400, Richard L. Barnes wrote: > +1 > > subjectPublicKeyInfo / digest(subjectPublicKeyInfo) should be a RefType > and not a CertType. (I think I raised this in my earlier review.) What is subjectPublicKeyInfo of OpenPGP certificate? What is subjectPublicKeyInfo of SECSH key? Or will the specs for those certTypes have to specify what subjectPublicKeyInfo means for those types (with option of specifying that it is nonsense and thus not allowed)? Yes, neither has DANE certType now, but they might in the future... -Ilari From jakob@kirei.se Tue Aug 16 09:45:13 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE11F21F8B28 for ; Tue, 16 Aug 2011 09:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.611 X-Spam-Level: X-Spam-Status: No, score=-0.611 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYCJtvo5gtRq for ; Tue, 16 Aug 2011 09:45:13 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id A6D6C21F89BE for ; Tue, 16 Aug 2011 09:45:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=V47qONV14YrpHftjulKCBtuReONfLbNSPLcb+lJnVnI=; b=VKzV4xs5xDyzdhcQU8N9B2wa0b54jrwSC9nkbzsp8ViApQ5YdFaWq+03Jl7ggi6yooEjbElPYCULx 9BwlrGL2dnPw6AniTR7DsJAty+gXDp3oAyVrVLeGy2HZAEjc8uVtAWLYHMGzL/5OHIdhF9fRXucQrw 8M5YqvcUtwBMXeNI= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Tue, 16 Aug 2011 18:45:58 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: Date: Tue, 16 Aug 2011 18:45:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <09C3E819-7146-4157-B666-B6CFE0D5C568@kirei.se> References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <6FEA0C14-314B-46FA-B4CB-601EAE1E209A@vpnc.org> <006401cc5bc8$dc94ae20$95be0a60$@augustcellars.com> <006b01cc5bcf$ef1a5520$cd4eff60$@augustcellars.com> To: Richard L. Barnes X-Mailer: Apple Mail (2.1244.3) Cc: 'DANE WG' , 'Paul Hoffman' , 'dane issue tracker' Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Aug 2011 16:45:14 -0000 On 16 aug 2011, at 16:04, Richard L. Barnes wrote: > subjectPublicKeyInfo / digest(subjectPublicKeyInfo) should be a = RefType and not a CertType. (I think I raised this in my earlier = review.) Right now, the draft seems confused about the semantics of the = two fields:=20 >=20 > CertType =3D=3D How to use the certificate > RefType =3D=3D How certificate is identified/encoded We've tried to have the same reference types for all cert types (where 0 = is the identity encoding and !0 is the different type of hashes). The cert type is used for the different "stuff" to refer, EE cert, CA = cert, EE public key etc. I agree that we could name "CertType" better, "Usage" might be a good = option. Or perhaps "Association Type"? jakob From ietf@augustcellars.com Tue Aug 16 11:58:51 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28CEF21F8BE4 for ; Tue, 16 Aug 2011 11:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.462 X-Spam-Level: X-Spam-Status: No, score=-3.462 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJ+fto3BAeLm for ; Tue, 16 Aug 2011 11:58:50 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id B511121F8BD7 for ; Tue, 16 Aug 2011 11:58:50 -0700 (PDT) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 3B5612C9EE; Tue, 16 Aug 2011 11:59:39 -0700 (PDT) From: "Jim Schaad" To: References: <004d01cc5ba6$a5927780$f0b76680$@augustcellars.com> <20110816133458.GB14894@vacation.karoshi.com.> In-Reply-To: <20110816133458.GB14894@vacation.karoshi.com.> Date: Tue, 16 Aug 2011 12:34:10 -0700 Message-ID: <00b301cc5c4b$79878950$6c969bf0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHqqGx6FIYRvqWedOD9jAm1ISg4rAGttckglNXWsIA= Content-Language: en-us Cc: dane@ietf.org Subject: Re: [dane] Adding a new appendix section A.1.4 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Aug 2011 18:58:51 -0000 The use of NS records is one way to delegate all information about a single server to an outsource provider and allow it to do all of the necessary record maintenance as well as populate the TLSA records as needed for that server. This provides one method that can be used to support the use case of Alice delegating to Oscar the support for a single server in the tree, while allowing for minimal work by Alice. If this method of delegation is used, then Oscar and Alice need to coordinate the rollover of the DNSSEC keys in order to keep the information properly signed. > -----Original Message----- > From: bmanning@vacation.karoshi.com > [mailto:bmanning@vacation.karoshi.com] > Sent: Tuesday, August 16, 2011 6:35 AM > To: Jim Schaad > Cc: dane@ietf.org > Subject: Re: [dane] Adding a new appendix section A.1.4 > > On Mon, Aug 15, 2011 at 04:54:18PM -0700, Jim Schaad wrote: > > At present I do not have any suggested text for this section because I > > do not know enough details about how this would work. However I would > > like to see the addition of a new section A.1.4 Delegation of > > Provisioning TLSA Records. > > > > This section would discuss the use of NS records to delegate an entire > > subtree of an existing name space to a service provider. This should > > discuss the issues involved with coordination of key records. > > > > Jim > > > > what would that look like? > > /bill From zack.weinberg@gmail.com Tue Aug 16 12:01:07 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C264A11E80D5 for ; Tue, 16 Aug 2011 12:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UlQGHu76ed45 for ; Tue, 16 Aug 2011 12:01:07 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 403E311E8098 for ; Tue, 16 Aug 2011 12:00:51 -0700 (PDT) Received: by gyf3 with SMTP id 3so180308gyf.31 for ; Tue, 16 Aug 2011 12:01:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=xCwhtcyb2p6nl49OBNi0GDjQaemIVrFpRFyACBAbh3o=; b=RdziNT+rBcQ0Mu5ANGZ5mKJ2Y226/UKgyWGHLRUAQY9I/yXyBTmllf2RzmKBBxwTPg IO77SoN2sequ7R+Kf1OZXDuPdqkZ9XbmuTwl4fh6a5W6HwXJ+M5u0iOx3ij8FlYRSBC9 9iO4qZv+RbJwyFbwCGvnCDWjQyMuKJRBv4g1g= MIME-Version: 1.0 Received: by 10.143.155.19 with SMTP id h19mr19260wfo.354.1313521297654; Tue, 16 Aug 2011 12:01:37 -0700 (PDT) Sender: zack.weinberg@gmail.com Received: by 10.68.63.228 with HTTP; Tue, 16 Aug 2011 12:01:37 -0700 (PDT) In-Reply-To: References: <70F5FD47-8862-4A4C-84AE-BC7708AB50C2@bbn.com> <9103D852-36CE-462D-8306-0B348B4FE4F0@bbn.com> Date: Tue, 16 Aug 2011 12:01:37 -0700 X-Google-Sender-Auth: HM2oLPXlp3BmL-TRNbEZEDQDvQ8 Message-ID: From: Zack Weinberg To: Phillip Hallam-Baker , Adam Langley Content-Type: text/plain; charset=UTF-8 Cc: DANE WG Subject: Re: [dane] Protocol / port numbers as prefix X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Aug 2011 19:01:07 -0000 2011/8/16 Phillip Hallam-Baker : > The problem then is that DNS does not really allow for 65536 RRs in the same > node. So it does not work out the way people think. > I still think people are going to be getting rather a shock when they try to > deploy for large Web farms. Google certainly can't use this for > https://www.google.com/. Adam, in your opinion, and ignoring the performance concerns that led you to write the TLSA-stapling spec, could Google deploy TLSA records as presently specified? If not, why not? zw From jakob@kirei.se Tue Aug 16 12:05:39 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E54A111E80A3 for ; Tue, 16 Aug 2011 12:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.614 X-Spam-Level: X-Spam-Status: No, score=-0.614 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTitbS58t6it for ; Tue, 16 Aug 2011 12:05:39 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id C8A6311E8082 for ; Tue, 16 Aug 2011 12:05:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=zRkeRlhYxYFa+7I+WBzi2I2p1pBMud7U1YGqdIicRH0=; b=iMComZ8Xn1ZJta9zjFV0WjM3BrQLmskhYVvHu3nBS9qjlmIPw66TiudM3hyRGtARe3xhWdpxXx6sB w/SGJavA6Np6LcQ57/MHUt5O4a8DWcrhRTWtL9pGVFBSkybHDGg2yNexjS56GD5WEV0tzGHPzK/NOE rrDVMLOXZyGXJYNM= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Tue, 16 Aug 2011 21:06:25 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: <004c01cc5ba6$07951010$16bf3030$@augustcellars.com> Date: Tue, 16 Aug 2011 21:06:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <004c01cc5ba6$07951010$16bf3030$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1244.3) Cc: dane@ietf.org Subject: Re: [dane] Suggested Appendix A.1.2 Changes X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Aug 2011 19:05:40 -0000 On 16 aug 2011, at 01:49, Jim Schaad wrote: > I would like to suggest the following be added to appendix A.1.2 >=20 > The desired behavior of aliasing an entire subtree is possible for = DANE due > to the fact that we are using two layers of prefixing. If one has the > following >=20 > sub5.example.com IN CNAME sub6.example.com. > _tcp.sub5.example.com IN DNAME _tcp.sub6.example.com. > sub6.example.com IN A 10.0.0.0 > _443._tcp.sub6.example.com IN TLSA 1 1 3082... >=20 > In this case someone looking for the TLSA record for sub5.example.com = using > TCP would be directed to the _tcp.sub6.example.com tree for resolution = of > the record. This allows for a wholesale re-assignment of all TLSA = records > into a different tree. This is an excellent example of how one can delegate more than one port = without falling back to wildcards. jakob From jakob@kirei.se Tue Aug 16 12:11:46 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6B311E80B2 for ; Tue, 16 Aug 2011 12:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.318 X-Spam-Level: X-Spam-Status: No, score=-0.318 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, J_CHICKENPOX_18=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPNaYjMJR03p for ; Tue, 16 Aug 2011 12:11:45 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id DE9EB11E808C for ; Tue, 16 Aug 2011 12:11:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=9LgOR8VSNDfRAfjKSuK/MtVsJJBiz20feQnYKDNZliE=; b=dCPXLLy72Ni+DNYrnYTTgGFdf7M3kut4B33G04rrpGEIWwM56Yp+OfC4yBYKSSY8x6V8aJminyK9Z iq9V9gK7ncWKEYV8u3nsCUiny3H5e+vKKnRlWzR/ge1aof4ZNDxNt74PPs8xleVf0w9jVeSHhMiJtR 3GJdSXB27AqgwVRY= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Tue, 16 Aug 2011 21:12:32 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: <004f01cc5baa$c72943c0$557bcb40$@augustcellars.com> Date: Tue, 16 Aug 2011 21:12:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1EB458FD-D8C3-4A82-B05E-ABC68B6EACD7@kirei.se> References: <004f01cc5baa$c72943c0$557bcb40$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1244.3) Cc: dane@ietf.org Subject: Re: [dane] Comments on Appendex B X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Aug 2011 19:11:46 -0000 On 16 aug 2011, at 02:23, Jim Schaad wrote: > 1. The text makes the assumption at all new reference types are going = to be > hashes. I do not agree that this is true statement. Therefore the = second > condition should be >=20 > Else if (R.referenceType is both known and a hash) AND = (hash(R.referenceType > of C) =3D=3D R.certAssoc) { I was under the assumption that the reference type is always the = identity reference or a hash. What other types can you think of? > 2. The comment for R.certType =3D=3D 2 is incorrect. I believe it = should be: >=20 > // a PKIX certificate that identifies a Trust Anchor section 2.1.1 says that cert type 2 is "A PKIX certification authority's = certificate". We could of course change that, but it should be = consistent. jakob From hallam@gmail.com Tue Aug 16 12:13:13 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2772D11E80B2 for ; Tue, 16 Aug 2011 12:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.452 X-Spam-Level: X-Spam-Status: No, score=-3.452 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V+B+eFMG51Fo for ; Tue, 16 Aug 2011 12:13:12 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 420CC11E809A for ; Tue, 16 Aug 2011 12:13:12 -0700 (PDT) Received: by ywm21 with SMTP id 21so188493ywm.31 for ; Tue, 16 Aug 2011 12:14:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+I2iLvt5qaCf45+SxErMksapE3meYnkaxkYDBWds83k=; b=H6QrLWB2v8z4F5k9KJ4Zy0pRmdZD6X1RrcuBpZm/JAZ3osDSIwUrAqtRYzwqaVKDEJ zCNsFTTj5znZ87J4CRShT3zP0oG10CNRsJ7bvXhosGXC1SKkobiwpShEjIv5y3MV0F9v 8s6cd47UZ21qjmaYiX8iZvlnYVlduXcpF26Os= MIME-Version: 1.0 Received: by 10.101.5.21 with SMTP id h21mr73817ani.123.1313522040899; Tue, 16 Aug 2011 12:14:00 -0700 (PDT) Received: by 10.100.94.14 with HTTP; Tue, 16 Aug 2011 12:14:00 -0700 (PDT) In-Reply-To: References: <70F5FD47-8862-4A4C-84AE-BC7708AB50C2@bbn.com> <9103D852-36CE-462D-8306-0B348B4FE4F0@bbn.com> Date: Tue, 16 Aug 2011 20:14:00 +0100 Message-ID: From: Phillip Hallam-Baker To: Zack Weinberg Content-Type: multipart/alternative; boundary=001636c9297da7080604aaa42ef1 Cc: Adam Langley , DANE WG Subject: Re: [dane] Protocol / port numbers as prefix X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Aug 2011 19:13:13 -0000 --001636c9297da7080604aaa42ef1 Content-Type: text/plain; charset=ISO-8859-1 There are what, 10K front end Web servers on google.com? Presumably in some sort of round-robin. Each is going to have the same DNS name and port number. So if the records are for EE certs that would be 10K records all with the same name and RR type. Under the DNSSEC design, that whole RR set has to be signed with a single signature. Naive ways of avoiding that restriction are going to fail due to caching constraints. The only solution that I can see in that case is going to be to have the TLSA record certify a cert-signing cert that signs the EE cert. Otherwise every Web server is going to have to have the same (or one of a limited number) SSL cert which is very bad security wise. On Tue, Aug 16, 2011 at 8:01 PM, Zack Weinberg wrote: > 2011/8/16 Phillip Hallam-Baker : > > The problem then is that DNS does not really allow for 65536 RRs in the > same > > node. So it does not work out the way people think. > > I still think people are going to be getting rather a shock when they try > to > > deploy for large Web farms. Google certainly can't use this for > > https://www.google.com/. > > Adam, in your opinion, and ignoring the performance concerns that led > you to write the TLSA-stapling spec, could Google deploy TLSA records > as presently specified? If not, why not? > > zw > -- Website: http://hallambaker.com/ --001636c9297da7080604aaa42ef1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable There are what, 10K front end Web servers on = google.com? Presumably in some sort of round-robin.

= Each is going to have the same DNS name and port number. So if the records = are for EE certs that would be 10K records all with the same name and RR ty= pe.

Under the DNSSEC design, that whole RR set has to be si= gned with a single signature. Naive ways of avoiding that restriction are g= oing to fail due to caching constraints.


The only solution that I can see in that case is going to be to have t= he TLSA record certify a cert-signing cert that signs the EE cert. Otherwis= e every Web server is going to have to have the same (or one of a limited n= umber) SSL cert which is very bad security wise.


On Tue, Aug 16, 2011 at = 8:01 PM, Zack Weinberg <zack.weinberg@sv.cmu.edu> wrote:
2011/8/16 Phillip Hallam-Baker <hall= am@gmail.com>:
> The problem then is that DNS does not really allow f= or 65536 RRs in the same
> node. So it does not work out the way people think.
> I still think people are going to be getting rather a shock when they = try to
> deploy for large Web farms. Google certainly can't use this for > https://www.goog= le.com/.

Adam, in your opinion, and ignoring the performance concerns that led=
you to write the TLSA-stapling spec, could Google deploy TLSA records
as presently specified? =A0If not, why not?

zw



--
Websi= te: http://hallambaker.com/

--001636c9297da7080604aaa42ef1-- From jakob@kirei.se Tue Aug 16 12:18:06 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E632821F86AC for ; Tue, 16 Aug 2011 12:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.609 X-Spam-Level: X-Spam-Status: No, score=-0.609 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 928-yZ9OlLQA for ; Tue, 16 Aug 2011 12:18:06 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id E907821F8634 for ; Tue, 16 Aug 2011 12:18:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=WUb/S280REeQ2cJsdKryFN4ViFSMq5RFvgBpaE7AJiU=; b=o95rupDciwnxKqUmIYWYnyg7Z8PFv38t6EqYWA+uUIcE9enshm/vD8nk74gJxGt1Bf7XBfNKQEU+M uCDjOgIjY/HEDMt3VjHPB1XastTXaBgwOQoIZPiQTFoFqwOe/5DXFLdfjYf6rixpztxTp4EUZDCr7W z5ds2aE3te9+nZuc= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Tue, 16 Aug 2011 21:18:53 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: <004e01cc5ba7$bdb0d310$39127930$@augustcellars.com> Date: Tue, 16 Aug 2011 21:18:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <62920623-B565-49DC-87DA-B72DB8B585E2@kirei.se> References: <004e01cc5ba7$bdb0d310$39127930$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1244.3) Cc: dane@ietf.org Subject: Re: [dane] Suggested changes in Section A.1.1 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Aug 2011 19:18:07 -0000 On 16 aug 2011, at 02:02, Jim Schaad wrote: > I believe that some operational comments should be added in at this = point. >=20 > So I would like to see the following text added: >=20 > After Example #1 as part of the paragraph. >=20 > If the domain owners of sub5.example.com and sub6.example.com are = different, > then changes in the TLSA records need to be propagated from one owner = to the > other before a new certificate can be rolled out. It is the administrator of the TLS server at sub6.example.com that needs = to communicate new TLSA records to the DNS administrator of = sub5.example.com. Even within the same domain, this might not be the = same administrator. jakob From jakob@kirei.se Tue Aug 16 12:26:22 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF3B721F8A56 for ; Tue, 16 Aug 2011 12:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.612 X-Spam-Level: X-Spam-Status: No, score=-0.612 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9ZZHojfgBZ1 for ; Tue, 16 Aug 2011 12:26:22 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB4121F8A35 for ; Tue, 16 Aug 2011 12:26:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=Fu/thXPBebziLAKMS75r4lLrTX6XekxlIzs+UC+9Qyo=; b=wTb5iniqD9G+GgWqRIAOpP617klb2JNF502hHGods+VZX6N9COo1Fr/L/2XlH3NHZMPYKyVCQLyby Mn/R/UZxqfLw0JCdzAw9rsDE+HsChAeaap5UceLRPkI9OZthNagJ2FqRO1EsKaYoqxIpDVi4k/+PQr VFxWkBriOjpyEKjg= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Tue, 16 Aug 2011 21:27:06 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Jakob Schlyter In-Reply-To: Date: Tue, 16 Aug 2011 21:27:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <81AC23CD-FE6A-4FA8-82D2-6D7DA2F0562D@kirei.se> References: <70F5FD47-8862-4A4C-84AE-BC7708AB50C2@bbn.com> <9103D852-36CE-462D-8306-0B348B4FE4F0@bbn.com> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1244.3) Cc: Adam Langley , DANE WG Subject: Re: [dane] Protocol / port numbers as prefix X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Aug 2011 19:26:23 -0000 On 16 aug 2011, at 21:14, Phillip Hallam-Baker wrote: > There are what, 10K front end Web servers on google.com? Presumably in = some sort of round-robin. >=20 > Each is going to have the same DNS name and port number. So if the = records are for EE certs that would be 10K records all with the same = name and RR type. Why do you assume that Google would not issue all certs from a common = issuer CA and put a TLSA for that? Or just use the same keypair on all front ends? (which seems to be the = case from where I'm standing) jakob From ietf@augustcellars.com Tue Aug 16 12:39:07 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD7D11E80A9 for ; Tue, 16 Aug 2011 12:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.172 X-Spam-Level: X-Spam-Status: No, score=-3.172 tagged_above=-999 required=5 tests=[AWL=-0.173, BAYES_00=-2.599, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sKLzXppNsEZK for ; Tue, 16 Aug 2011 12:39:07 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 3136C11E808F for ; Tue, 16 Aug 2011 12:39:07 -0700 (PDT) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 3D1E038F12; Tue, 16 Aug 2011 12:39:56 -0700 (PDT) From: "Jim Schaad" To: "'Jakob Schlyter'" References: <004f01cc5baa$c72943c0$557bcb40$@augustcellars.com> <1EB458FD-D8C3-4A82-B05E-ABC68B6EACD7@kirei.se> In-Reply-To: <1EB458FD-D8C3-4A82-B05E-ABC68B6EACD7@kirei.se> Date: Tue, 16 Aug 2011 13:14:28 -0700 Message-ID: <00ba01cc5c51$1a7fa0e0$4f7ee2a0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFWRVGiCE582KcNwBdvOyKNTvK8AAHUs5b3lf1xsnA= Content-Language: en-us Cc: dane@ietf.org Subject: Re: [dane] Comments on Appendex B X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Aug 2011 19:39:07 -0000 > -----Original Message----- > From: Jakob Schlyter [mailto:jakob@kirei.se] > Sent: Tuesday, August 16, 2011 12:12 PM > To: Jim Schaad > Cc: dane@ietf.org > Subject: Re: [dane] Comments on Appendex B > > On 16 aug 2011, at 02:23, Jim Schaad wrote: > > > 1. The text makes the assumption at all new reference types are going > > to be hashes. I do not agree that this is true statement. Therefore > > the second condition should be > > > > Else if (R.referenceType is both known and a hash) AND > > (hash(R.referenceType of C) == R.certAssoc) { > > I was under the assumption that the reference type is always the identity > reference or a hash. What other types can you think of? Well - I have proposed that it could be a public key in a new tracker item. That would be something that is neither identity or a hash. > > > 2. The comment for R.certType == 2 is incorrect. I believe it should be: > > > > // a PKIX certificate that identifies a Trust Anchor > > section 2.1.1 says that cert type 2 is "A PKIX certification authority's > certificate". We could of course change that, but it should be consistent. In my big review mail - I said that I wanted to this to be consistant and just refer to trust anchors. Jim > > jakob From alangley@gmail.com Tue Aug 16 12:40:41 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83C4011E80D0 for ; Tue, 16 Aug 2011 12:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.944 X-Spam-Level: X-Spam-Status: No, score=-2.944 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HsiQxlSAvgSb for ; Tue, 16 Aug 2011 12:40:40 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id C5C5C11E80A9 for ; Tue, 16 Aug 2011 12:40:40 -0700 (PDT) Received: by qyk35 with SMTP id 35so166215qyk.10 for ; Tue, 16 Aug 2011 12:41:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=vh+E0jFYVTgpTlpIr9frWZ8M8JNt7yNy0w1gEC6f6Uk=; b=qm4S+1f6a7KyvjvZixIJBGyloXFV5cjVhuZ+mWwXBACmKA/79s9WVEcrCE6Z9RBSzS pvWDFteGos40kp81jeGqDbJL48KPngFMUUnpk9zBF9b0tBn7O2719Qg00Guye9hrw9Oj 5vi1mBMC0mQrg7FaSIOgxJXSJfeuG09bBgY9g= MIME-Version: 1.0 Received: by 10.224.199.68 with SMTP id er4mr129788qab.164.1313523689541; Tue, 16 Aug 2011 12:41:29 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.229.187.2 with HTTP; Tue, 16 Aug 2011 12:41:29 -0700 (PDT) In-Reply-To: References: <70F5FD47-8862-4A4C-84AE-BC7708AB50C2@bbn.com> <9103D852-36CE-462D-8306-0B348B4FE4F0@bbn.com> Date: Tue, 16 Aug 2011 15:41:29 -0400 X-Google-Sender-Auth: 3ewov_NitBg0eiqZHa2q9kLxcfU Message-ID: From: Adam Langley To: Zack Weinberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: DANE WG Subject: Re: [dane] Protocol / port numbers as prefix X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Aug 2011 19:40:41 -0000 On Tue, Aug 16, 2011 at 3:01 PM, Zack Weinberg w= rote: > Adam, in your opinion, and ignoring the performance concerns that led > you to write the TLSA-stapling spec, could Google deploy TLSA records > as presently specified? =C2=A0If not, why not? I can't comment on the number of frontend servers that we have but, from public data, you can find out that our certificates are issued from one of three intermediates. We could publish three TLSA records for *.google.com and cover everything that way. I don't see it being a problem assuming that we had DNSSEC enabled. That's on the server side. I've already discussed client-side things in "A browser's myopic view". Cheers AGL --=20 Adam Langley agl@imperialviolet.org http://www.imperialviolet.org From ietf@augustcellars.com Tue Aug 16 12:40:45 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3F2511E80E5 for ; Tue, 16 Aug 2011 12:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.46 X-Spam-Level: X-Spam-Status: No, score=-3.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26K7MLt2LVh8 for ; Tue, 16 Aug 2011 12:40:45 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id CD07F11E80DF for ; Tue, 16 Aug 2011 12:40:44 -0700 (PDT) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 05D0B2CA08; Tue, 16 Aug 2011 12:41:33 -0700 (PDT) From: "Jim Schaad" To: "'Jakob Schlyter'" References: <004e01cc5ba7$bdb0d310$39127930$@augustcellars.com> <62920623-B565-49DC-87DA-B72DB8B585E2@kirei.se> In-Reply-To: <62920623-B565-49DC-87DA-B72DB8B585E2@kirei.se> Date: Tue, 16 Aug 2011 13:16:06 -0700 Message-ID: <00bb01cc5c51$54bcd6b0$fe368410$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQINp/LerW8WaGukwxyoBJSCKmyIGgEYr66GlJSNIzA= Content-Language: en-us Cc: dane@ietf.org Subject: Re: [dane] Suggested changes in Section A.1.1 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Aug 2011 19:40:45 -0000 Actually it could be the DNS administrator of sub5 giving a new certificate to the TLS server at sub6. Jim > -----Original Message----- > From: Jakob Schlyter [mailto:jakob@kirei.se] > Sent: Tuesday, August 16, 2011 12:19 PM > To: Jim Schaad > Cc: dane@ietf.org > Subject: Re: [dane] Suggested changes in Section A.1.1 > > On 16 aug 2011, at 02:02, Jim Schaad wrote: > > > I believe that some operational comments should be added in at this point. > > > > So I would like to see the following text added: > > > > After Example #1 as part of the paragraph. > > > > If the domain owners of sub5.example.com and sub6.example.com are > > different, then changes in the TLSA records need to be propagated from > > one owner to the other before a new certificate can be rolled out. > > It is the administrator of the TLS server at sub6.example.com that needs to > communicate new TLSA records to the DNS administrator of > sub5.example.com. Even within the same domain, this might not be the same > administrator. > > jakob From jakob@kirei.se Tue Aug 16 12:48:33 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FCB611E80DF for ; Tue, 16 Aug 2011 12:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.615 X-Spam-Level: X-Spam-Status: No, score=-0.615 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7z8ytvKIOyl for ; Tue, 16 Aug 2011 12:48:32 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id 42EF211E80C1 for ; Tue, 16 Aug 2011 12:48:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=wVmCRVLipEdbdlrh6QT3BGXiqYXhrdUK8Fk6qQqGUxg=; b=nITXvWElI+t4egl3N+wRdySoVv77on2dseW2HlRqpc2EHQWMcrxEYecy0xS+CVNyZ7+vj5bwoNyhe 8NTgiDkgV2RhKoTWs91hBjs87tjWhBITxEgyJCHoB3O7Wg13g+MFN5wICxXodLu4hCBKSpVe4cjBoG Ylu0YYMcwb+Rk/wo= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Tue, 16 Aug 2011 21:49:18 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: <00bb01cc5c51$54bcd6b0$fe368410$@augustcellars.com> Date: Tue, 16 Aug 2011 21:49:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <004e01cc5ba7$bdb0d310$39127930$@augustcellars.com> <62920623-B565-49DC-87DA-B72DB8B585E2@kirei.se> <00bb01cc5c51$54bcd6b0$fe368410$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1244.3) Cc: dane@ietf.org Subject: Re: [dane] Suggested changes in Section A.1.1 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Aug 2011 19:48:33 -0000 On 16 aug 2011, at 22:16, Jim Schaad wrote: > Actually it could be the DNS administrator of sub5 giving a new = certificate > to the TLS server at sub6. It could be a lot of things and the only thing we know is that careful = coordination are always needed for key rollovers. jakob From ondrej.sury@nic.cz Tue Aug 16 12:49:20 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F8EC228307 for ; Tue, 16 Aug 2011 12:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23SGDewpfYOq for ; Tue, 16 Aug 2011 12:49:15 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 7056911E80AA for ; Tue, 16 Aug 2011 12:49:15 -0700 (PDT) Received: from [10.0.0.12] (247.78.broadband13.iol.cz [90.180.78.247]) by mail.nic.cz (Postfix) with ESMTPSA id 997D62A0D3F for ; Tue, 16 Aug 2011 21:50:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1313524203; bh=0OLhc4ZaSFV86H0Au1eLUvFfW4ErJ8THC2LMjHIW/BM=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Date: Message-Id:To:Mime-Version; b=izB6YrXuYT+tW7qjR3H4iU5xZYk3/bMJ5maWAKswIDonK5984T8PVhkuerK0T7p6+ dHuGx8Zdx3LJZAPcx0jC2RSzHZthFd5utJHigC6vxQnyJQMC1Zw5OxaZRFdxgzZ5GO gyWxljjByj6vCzBGTNvblQBZENIBldlr4Rk6wyns= From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Aug 2011 21:50:03 +0200 Message-Id: <30CCB651-0CC9-4F24-8FB2-7C488626FA1D@nic.cz> To: DANE WG Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: [dane] Opening issue #10: Considerations related to the comprimise of an intermediate CA X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Aug 2011 19:49:20 -0000 Hi, as I promised I am opening another issue to solve. This time I picked = #10 since it seems to be far away from #7 and #29 which are discussed in = the list right now. It's seven months old and says: > If an intermediate CA were compromised, then a DNS admin could > obviate the revocation of the relevant CA cert by adding an RR. > Not that likely, and detectable, but maybe worth a security > consideration paragraph since such a case might be fairly > catastrophic as-is, but would be made worse with DANE. What does WG think? O. http://trac.tools.ietf.org/wg/dane/trac/ticket/10 -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From mrex@sap.com Tue Aug 16 13:00:57 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3252321F87D3 for ; Tue, 16 Aug 2011 13:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.863 X-Spam-Level: X-Spam-Status: No, score=-9.863 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZJOrEIOmf0W for ; Tue, 16 Aug 2011 13:00:56 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 71FF021F87C5 for ; Tue, 16 Aug 2011 13:00:56 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p7GK1ccJ009971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 16 Aug 2011 22:01:43 +0200 (MEST) From: Martin Rex Message-Id: <201108162001.p7GK1cus022105@fs4113.wdf.sap.corp> To: ondrej.sury@nic.cz (=?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?=) Date: Tue, 16 Aug 2011 22:01:38 +0200 (MEST) In-Reply-To: <30CCB651-0CC9-4F24-8FB2-7C488626FA1D@nic.cz> from "=?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?=" at Aug 16, 11 09:50:03 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] Opening issue #10: Considerations related to the comprimise X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 20:00:57 -0000 Ondrej Sury wrote: > > #10 -- It's seven months old and says: > > > If an intermediate CA were compromised, then a DNS admin could > > obviate the revocation of the relevant CA cert by adding an RR. > > Not that likely, and detectable, but maybe worth a security > > consideration paragraph since such a case might be fairly > > catastrophic as-is, but would be made worse with DANE. > > What does WG think? > > http://trac.tools.ietf.org/wg/dane/trac/ticket/10 IMO, DANE should never be conceived to obviate PKIX revocation in any usage scenarios where PKIX revocation was designed and configured into the PKI. If revocation was set up (i.e. a CRL Distribution Point extension or an OCSP AIA extension is present the relevant intermediate cert), then this revocation mechanism MUST be used (as well). DANE may additionally discontinue to provide an independent confirmation for specific certs, but that is an entirely different issue. DANE records work closer to non-negative OCSP-responses than to CRL entries, and OCSP seems to be a scheme to facilitate CRL processing rather than to obviate CRLs/revocation. -Martin From rbarnes@bbn.com Tue Aug 16 13:04:09 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75775228308 for ; Tue, 16 Aug 2011 13:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.531 X-Spam-Level: X-Spam-Status: No, score=-106.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMLgX5W4Uvgd for ; Tue, 16 Aug 2011 13:04:09 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id E68BA228307 for ; Tue, 16 Aug 2011 13:04:08 -0700 (PDT) Received: from ros-dhcp192-1-51-76.bbn.com ([192.1.51.76]:62040) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QtPsU-0006GD-FR; Tue, 16 Aug 2011 16:04:46 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <20110816160604.GA23775@LK-Perkele-VI.localdomain> Date: Tue, 16 Aug 2011 16:04:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9F61C61A-11B3-493B-BBD3-AB18457083D9@bbn.com> References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <6FEA0C14-314B-46FA-B4CB-601EAE1E209A@vpnc.org> <006401cc5bc8$dc94ae20$95be0a60$@augustcellars.com> <006b01cc5bcf$ef1a5520$cd4eff60$@augustcellars.com> <20110816160604.GA23775@LK-Perkele-VI.localdomain> To: Ilari Liusvaara X-Mailer: Apple Mail (2.1082) Cc: 'DANE WG' , 'Paul Hoffman' , 'dane issue tracker' Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Aug 2011 20:04:09 -0000 Argument 1: Not in TLS, thus not in scope right now. They can always = add new refTypes for those protocols. Argument 2: Why would you bother? There's not any semantic difference = between the three. =46rom RFC 5280: SubjectPublicKeyInfo ::=3D SEQUENCE { algorithm AlgorithmIdentifier, subjectPublicKey BIT STRING } =46rom RFC 4880: - A one-octet number giving the public-key algorithm used. - A string of octets that is the encrypted session key. This string takes up the remainder of the packet, and its contents are dependent on the public-key algorithm used. =46rom RFC 4252: string public key algorithm name string public key blob On Aug 16, 2011, at 12:06 PM, Ilari Liusvaara wrote: > On Tue, Aug 16, 2011 at 10:04:26AM -0400, Richard L. Barnes wrote: >> +1 >>=20 >> subjectPublicKeyInfo / digest(subjectPublicKeyInfo) should be a = RefType >> and not a CertType. (I think I raised this in my earlier review.)=20 >=20 > What is subjectPublicKeyInfo of OpenPGP certificate? > What is subjectPublicKeyInfo of SECSH key? >=20 > Or will the specs for those certTypes have to specify what > subjectPublicKeyInfo means for those types (with option of specifying = that > it is nonsense and thus not allowed)? >=20 > Yes, neither has DANE certType now, but they might in the future... >=20 > -Ilari From ietf@augustcellars.com Tue Aug 16 13:07:51 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1C9021F8ABC for ; Tue, 16 Aug 2011 13:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.469 X-Spam-Level: X-Spam-Status: No, score=-3.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GcdgLM4yUjig for ; Tue, 16 Aug 2011 13:07:48 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 9C9ED21F8ABB for ; Tue, 16 Aug 2011 13:07:47 -0700 (PDT) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id A720B38F09; Tue, 16 Aug 2011 13:08:35 -0700 (PDT) From: "Jim Schaad" To: "'Ilari Liusvaara'" , "'Richard L. Barnes'" References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <6FEA0C14-314B-46FA-B4CB-601EAE1E209A@vpnc.org> <006401cc5bc8$dc94ae20$95be0a60$@augustcellars.com> <006b01cc5bcf$ef1a5520$cd4eff60$@augustcellars.com> <20110816160604.GA23775@LK-Perkele-VI.localdomain> In-Reply-To: <20110816160604.GA23775@LK-Perkele-VI.localdomain> Date: Tue, 16 Aug 2011 13:43:08 -0700 Message-ID: <00bc01cc5c55$1c0ad7f0$542087d0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHwXbPL2/IzPDFsf9e9Pk9vZhBFJQH/Ia23Aggnm/8B3aWeNQGAN8ONAVzqYQ8Buar0ZJSEDsFw Content-Language: en-us Cc: 'DANE WG' , 'Paul Hoffman' , 'dane issue tracker' Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Aug 2011 20:07:51 -0000 It is a data structure which holds a public key. A I pointed out in the = tracker item when I opened it up, there may be a discussion about what = format should be used to encode the key. For a TLS implementation, = decoding the public key as an ASN.1 block is relatively easy as it is = always going to support ASN.1. =20 An OpenPGP certificate does have the equivalent of a a = subjectPublicKeyInfo structure - although the exact encoding of the key = is going to be different, the information contained is going to be the = same and thus is readily compared. I don't know about SECSH as I don't know if the key is going to be = transmitted across the network or just kept locally. However again, the = information is the same it is just a question of what the encoding of = the information is going to be. Jim > -----Original Message----- > From: Ilari Liusvaara [mailto:ilari.liusvaara@elisanet.fi] > Sent: Tuesday, August 16, 2011 9:06 AM > To: Richard L. Barnes > Cc: Jim Schaad; 'dane issue tracker'; 'Paul Hoffman'; 'DANE WG' > Subject: Re: [dane] #29: Request new Reference Type - Public Key >=20 > On Tue, Aug 16, 2011 at 10:04:26AM -0400, Richard L. Barnes wrote: > > +1 > > > > subjectPublicKeyInfo / digest(subjectPublicKeyInfo) should be a > > RefType and not a CertType. (I think I raised this in my earlier > > review.) >=20 > What is subjectPublicKeyInfo of OpenPGP certificate? > What is subjectPublicKeyInfo of SECSH key? >=20 > Or will the specs for those certTypes have to specify what > subjectPublicKeyInfo means for those types (with option of specifying = that it is > nonsense and thus not allowed)? >=20 > Yes, neither has DANE certType now, but they might in the future... >=20 > -Ilari From ietf@augustcellars.com Tue Aug 16 13:09:59 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3804021F8AE6 for ; Tue, 16 Aug 2011 13:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id keW1ahQgC7uH for ; Tue, 16 Aug 2011 13:09:58 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 3A73E21F8ABC for ; Tue, 16 Aug 2011 13:09:58 -0700 (PDT) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 2F7CF38F09; Tue, 16 Aug 2011 13:10:47 -0700 (PDT) From: "Jim Schaad" To: , =?iso-8859-1?Q?'Ondrej_Sur=FD'?= References: <30CCB651-0CC9-4F24-8FB2-7C488626FA1D@nic.cz> from "=?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?=" at Aug 16, 11 09:50:03 pm <201108162001.p7GK1cus022105@fs4113.wdf.sap.corp> In-Reply-To: <201108162001.p7GK1cus022105@fs4113.wdf.sap.corp> Date: Tue, 16 Aug 2011 13:45:19 -0700 Message-ID: <00c001cc5c55$69fcc310$3df64930$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIKWk07TYt13vOVjgMwXjjVmIWSWZSj9faA Content-Language: en-us Cc: dane@ietf.org Subject: Re: [dane] Opening issue #10: Considerations related to the comprimise X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Aug 2011 20:09:59 -0000 +1 If it is revoked - then it is revoked. DANE should never be able to un-revoke any certificate. jim > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf = Of > Martin Rex > Sent: Tuesday, August 16, 2011 1:02 PM > To: Ondrej Sur=FD > Cc: dane@ietf.org > Subject: Re: [dane] Opening issue #10: Considerations related to the > comprimise >=20 > Ondrej Sury wrote: > > > > #10 -- It's seven months old and says: > > > > > If an intermediate CA were compromised, then a DNS admin could > > > obviate the revocation of the relevant CA cert by adding an RR. > > > Not that likely, and detectable, but maybe worth a security > > > consideration paragraph since such a case might be fairly > > > catastrophic as-is, but would be made worse with DANE. > > > > What does WG think? > > > > http://trac.tools.ietf.org/wg/dane/trac/ticket/10 >=20 > IMO, DANE should never be conceived to obviate PKIX revocation in any > usage scenarios where PKIX revocation was designed and configured into = the > PKI. If revocation was set up (i.e. a CRL Distribution Point = extension or an > OCSP AIA extension is present the relevant intermediate cert), then = this > revocation mechanism MUST be used (as well). >=20 > DANE may additionally discontinue to provide an independent = confirmation > for specific certs, but that is an entirely different issue. DANE = records work > closer to non-negative OCSP-responses than to CRL entries, and OCSP = seems > to be a scheme to facilitate CRL processing rather than to obviate > CRLs/revocation. >=20 >=20 > -Martin > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From rbarnes@bbn.com Tue Aug 16 13:17:36 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B26921F8A80 for ; Tue, 16 Aug 2011 13:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.235 X-Spam-Level: X-Spam-Status: No, score=-106.235 tagged_above=-999 required=5 tests=[AWL=-0.236, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBgGdmw72RuN for ; Tue, 16 Aug 2011 13:17:35 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 35E5F21F886D for ; Tue, 16 Aug 2011 13:17:35 -0700 (PDT) Received: from ros-dhcp192-1-51-76.bbn.com ([192.1.51.76]:62179) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QtQ5f-0006VX-1r; Tue, 16 Aug 2011 16:18:23 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-2 From: "Richard L. Barnes" In-Reply-To: Date: Tue, 16 Aug 2011 16:18:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <70F5FD47-8862-4A4C-84AE-BC7708AB50C2@bbn.com> <9103D852-36CE-462D-8306-0B348B4FE4F0@bbn.com> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1082) Cc: DANE WG Subject: Re: [dane] Protocol / port numbers as prefix X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Aug 2011 20:17:36 -0000 > The problem then is that DNS does not really allow for 65536 RRs in = the same node. So it does not work out the way people think. Good point, but kind of irrelevant to this discussion unless you've got = at transport protocol in mind that has more than 2**16 ports. --Richard > I still think people are going to be getting rather a shock when they = try to deploy for large Web farms. Google certainly can't use this for = https://www.google.com/. >=20 > On Tue, Aug 16, 2011 at 4:46 PM, Richard L. Barnes = wrote: > Ah, there it is. I was just summarizing because I hadn't found a = record of this debate having happened. Consider my comment withdrawn. >=20 > --Richard >=20 >=20 > On Aug 16, 2011, at 11:26 AM, Ond=F8ej Sur=FD wrote: >=20 > > On 16. 8. 2011, at 16:11, Richard L. Barnes wrote: > >> It is clearly causing some people discomfort to have protocols and = port numbers as prefixes. Why not just push them into the RRDATA and = provision the TLSA directly under the affected name? > > > > > > Hi Richard, > > > > I would like to point out that we already had this discussion (at = least once): > > > > http://trac.tools.ietf.org/wg/dane/trac/ticket/1 > > > > and here is the mail thread: > > > > http://www.ietf.org/mail-archive/web/keyassure/current/msg01631.html > > > > While I don't have a problem reopening the issue if that's what > > the WG wants I would prefer to not reiterate the same issues > > again and again unless you (all) at least read the mailing list > > archives. > > > > Thanks, > > O. > > > > -- > > Ond=F8ej Sur=FD > > vedouc=ED v=FDzkumu/Head of R&D department > > ------------------------------------------- > > CZ.NIC, z.s.p.o. -- Laborato=F8e CZ.NIC > > Americka 23, 120 00 Praha 2, Czech Republic > > mailto:ondrej.sury@nic.cz http://nic.cz/ > > tel:+420.222745110 fax:+420.222745112 > > ------------------------------------------- > > >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 >=20 >=20 > --=20 > Website: http://hallambaker.com/ >=20 From leifj@mnt.se Tue Aug 16 13:25:41 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F47711E80B0 for ; Tue, 16 Aug 2011 13:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.882 X-Spam-Level: X-Spam-Status: No, score=-2.882 tagged_above=-999 required=5 tests=[AWL=-0.283, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id enFapRw6M3qs for ; Tue, 16 Aug 2011 13:25:40 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 337FA11E807F for ; Tue, 16 Aug 2011 13:25:39 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p7GKQN4x024507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 16 Aug 2011 22:26:27 +0200 (CEST) Message-ID: <4E4AD26E.4090707@mnt.se> Date: Tue, 16 Aug 2011 22:26:22 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: dane@ietf.org References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <6FEA0C14-314B-46FA-B4CB-601EAE1E209A@vpnc.org> <006401cc5bc8$dc94ae20$95be0a60$@augustcellars.com> <006b01cc5bcf$ef1a5520$cd4eff60$@augustcellars.com> <20110816160604.GA23775@LK-Perkele-VI.localdomain> <9F61C61A-11B3-493B-BBD3-AB18457083D9@bbn.com> In-Reply-To: <9F61C61A-11B3-493B-BBD3-AB18457083D9@bbn.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Aug 2011 20:25:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/16/2011 10:04 PM, Richard L. Barnes wrote: > Argument 1: Not in TLS, thus not in scope right now. They can always add new refTypes for those protocols. > On that topic - whatever we do for "raw keys" should align with what woes/joes does in that space. It is perhaps unlikely that they will be used for TLS but when we get to signing they will absolutely get used. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5K0m4ACgkQ8Jx8FtbMZndCIQCgut5pz6cUq+DYqSHK8wcEkKlM qcEAoKqQuRsmYVemraPgSr0bTpvzhE41 =T7+n -----END PGP SIGNATURE----- From hallam@gmail.com Tue Aug 16 14:43:05 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 894B811E8101 for ; Tue, 16 Aug 2011 14:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.453 X-Spam-Level: X-Spam-Status: No, score=-3.453 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33p50rnAb1ZA for ; Tue, 16 Aug 2011 14:43:04 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0F711E80F9 for ; Tue, 16 Aug 2011 14:43:04 -0700 (PDT) Received: by yie12 with SMTP id 12so305157yie.31 for ; Tue, 16 Aug 2011 14:43:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7pTnFls5yXNiz8AipWZLYMMol1943pPhztLG2JmXI/g=; b=RLQeZ9+gQosTk23VK2kvwl7EwTPpAmPKFY5pWGS092ahBFtuJovkZKPQcTtoL2CZPl dGQxRMZEt4OyZiIchYxSHQEotuF5TXoESu18j6We4benHWt5xgwMzSH403Uhj6Thsphg pXA0KtLe/w/9aybSSHWsyv1JYPOd9kUynJhiY= MIME-Version: 1.0 Received: by 10.100.16.17 with SMTP id 17mr291728anp.13.1313531031055; Tue, 16 Aug 2011 14:43:51 -0700 (PDT) Received: by 10.100.94.14 with HTTP; Tue, 16 Aug 2011 14:43:50 -0700 (PDT) In-Reply-To: References: <70F5FD47-8862-4A4C-84AE-BC7708AB50C2@bbn.com> <9103D852-36CE-462D-8306-0B348B4FE4F0@bbn.com> Date: Tue, 16 Aug 2011 22:43:50 +0100 Message-ID: From: Phillip Hallam-Baker To: Adam Langley Content-Type: multipart/alternative; boundary=001485f7c3b881efd904aaa64681 Cc: DANE WG Subject: Re: [dane] Protocol / port numbers as prefix X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Aug 2011 21:43:05 -0000 --001485f7c3b881efd904aaa64681 Content-Type: text/plain; charset=ISO-8859-1 I realized this after the initial post. The same argument would hold for eliminating the port number, but only if all that DANE does is publish keys. Sites that have many services could use the same approach of advertising the key for the local CA. The reason it would not work is that people want to do the restriction semantics and that requires the ability to state which protocols the restriction semantics are in use for. On Tue, Aug 16, 2011 at 8:41 PM, Adam Langley wrote: > On Tue, Aug 16, 2011 at 3:01 PM, Zack Weinberg > wrote: > > Adam, in your opinion, and ignoring the performance concerns that led > > you to write the TLSA-stapling spec, could Google deploy TLSA records > > as presently specified? If not, why not? > > I can't comment on the number of frontend servers that we have but, > from public data, you can find out that our certificates are issued > from one of three intermediates. We could publish three TLSA records > for *.google.com and cover everything that way. I don't see it being a > problem assuming that we had DNSSEC enabled. > > That's on the server side. I've already discussed client-side things > in "A browser's myopic view". > > > Cheers > > AGL > > -- > Adam Langley agl@imperialviolet.org http://www.imperialviolet.org > -- Website: http://hallambaker.com/ --001485f7c3b881efd904aaa64681 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I realized this after the initial post.

The same argumen= t would hold for eliminating the port number, but only if all that DANE doe= s is publish keys. Sites that have many services could use the same approac= h of advertising the key for the local CA.


The reason it would not work is that peo= ple want to do the restriction semantics and that requires the ability to s= tate which protocols the restriction semantics are in use for.

On Tue, Aug 16, 2011 at 8:41 PM, Adam Langle= y <agl@imper= ialviolet.org> wrote:
On Tue, Aug 16, 2011 at 3:01 PM, Zack Weinberg <zack.weinberg@sv.cmu.edu> wrot= e:
> Adam, in your opinion, and ignoring the perfor= mance concerns that led
> you to write the TLSA-stapling spec, could Google deploy TLSA records<= br> > as presently specified? =A0If not, why not?

I can't comment on the number of frontend servers that we have bu= t,
from public data, you can find out that our certificates are issued
from one of three intermediates. We could publish three TLSA records
for *.google.com and co= ver everything that way. I don't see it being a
problem assuming that we had DNSSEC enabled.

That's on the server side. I've already discussed client-side thing= s
in "A browser's myopic view".


Cheers

AGL

--
Adam Langley agl@imperialviolet.o= rg http://w= ww.imperialviolet.org



--
Websi= te: http://hallambaker.com/

--001485f7c3b881efd904aaa64681-- From paul@xelerance.com Tue Aug 16 20:10:29 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F66221F8610 for ; Tue, 16 Aug 2011 20:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.469 X-Spam-Level: X-Spam-Status: No, score=-6.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6zFclbZhRRh for ; Tue, 16 Aug 2011 20:10:28 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id A9E4A21F84F3 for ; Tue, 16 Aug 2011 20:10:28 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id F070AC65F; Tue, 16 Aug 2011 23:13:14 -0400 (EDT) Date: Tue, 16 Aug 2011 23:13:14 -0400 (EDT) From: Paul Wouters To: Leif Johansson In-Reply-To: <4E4AD26E.4090707@mnt.se> Message-ID: References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <6FEA0C14-314B-46FA-B4CB-601EAE1E209A@vpnc.org> <006401cc5bc8$dc94ae20$95be0a60$@augustcellars.com> <006b01cc5bcf$ef1a5520$cd4eff60$@augustcellars.com> <20110816160604.GA23775@LK-Perkele-VI.localdomain> <9F61C61A-11B3-493B-BBD3-AB18457083D9@bbn.com> <4E4AD26E.4090707@mnt.se> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dane@ietf.org Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 17 Aug 2011 03:10:29 -0000 On Tue, 16 Aug 2011, Leif Johansson wrote: > On 08/16/2011 10:04 PM, Richard L. Barnes wrote: >> Argument 1: Not in TLS, thus not in scope right now. They can always add new refTypes for those protocols. >> > > On that topic - whatever we do for "raw keys" should align with what > woes/joes does in that space. It is perhaps unlikely that they will > be used for TLS but when we get to signing they will absolutely get > used. It's being worked on in the TLS group. I did a presentation at the TLS WG on out of band public keys, and there will be a followup on that. It might end up being a new "certificate type" holding only a subjectPublidKeyInfo structure. Paul From paul.hoffman@vpnc.org Tue Aug 16 20:19:14 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2FF21F8AC3 for ; Tue, 16 Aug 2011 20:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pjdkk1eLZjEJ for ; Tue, 16 Aug 2011 20:19:13 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 842F521F8ABE for ; Tue, 16 Aug 2011 20:19:13 -0700 (PDT) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p7H3JYEA075043 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 16 Aug 2011 20:19:37 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> Date: Tue, 16 Aug 2011 20:20:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> To: dane issue tracker X-Mailer: Apple Mail (2.1244.3) Cc: DANE WG Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 17 Aug 2011 03:19:14 -0000 When talking with Jim, we realized that the issue is raising here is a = confluence of two things: - He wants to be able to restrict the role that the cert or public key = can be used in (trust anchor, intermediate CA, end entity) - The current names for the two fields in record don't reflect their = actual use The tentative proposal we came up with also has two parts: - Instead of just three types: 1 -- A PKIX certificate that identifies an end entity 2 -- A PKIX certification authority's certificate 3 -- A public key expressed as a PKIX SubjectPublicKeyInfo = structure There should be six: n -- A PKIX certificate that identifies an end entity n+1 -- A PKIX certification authority's certificate that identifies a = trust anchor n+2 -- A PKIX certification authority's certificate that identifies an = intermediate CA n+3 -- A public key expressed as a PKIX SubjectPublicKeyInfo structure = that identifies a trust anchor n+4 -- A public key expressed as a PKIX SubjectPublicKeyInfo structure = that identifies an intermediate CA n+5 -- A public key expressed as a PKIX SubjectPublicKeyInfo structure = that identifies an end entity - Instead of "Certificate Type" and "Reference Type", we need words that = define the fields' roles better. A first guess would be "Restriction = Type" and "Matching Type", but there could easily be better words. --Paul Hoffman= From i.grok@comcast.net Tue Aug 16 20:22:37 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0D7011E80BF for ; Tue, 16 Aug 2011 20:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.642 X-Spam-Level: X-Spam-Status: No, score=-102.642 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10KrXYyR+KRD for ; Tue, 16 Aug 2011 20:22:34 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF4211E808B for ; Tue, 16 Aug 2011 20:22:34 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta04.westchester.pa.mail.comcast.net with comcast id MFHJ1h0071ap0As54FPRaN; Wed, 17 Aug 2011 03:23:25 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta22.westchester.pa.mail.comcast.net with comcast id MFPR1h00400PQ6U3iFPRuR; Wed, 17 Aug 2011 03:23:25 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.4/8.14.3) with ESMTP id p7H3NNEX029084 for ; Tue, 16 Aug 2011 23:23:23 -0400 Received: (from draco@localhost) by odin.ulthar.us (8.14.4/8.14.4/Submit) id p7H3NNBw029082 for dane@ietf.org; Tue, 16 Aug 2011 23:23:23 -0400 Date: Tue, 16 Aug 2011 23:23:23 -0400 From: Scott Schmit To: dane@ietf.org Message-ID: <20110817032323.GA28819@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <30CCB651-0CC9-4F24-8FB2-7C488626FA1D@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <30CCB651-0CC9-4F24-8FB2-7C488626FA1D@nic.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Opening issue #10: Considerations related to the comprimise of an intermediate CA X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 17 Aug 2011 03:22:37 -0000 On Tue, Aug 16, 2011 at 09:50:03PM +0200, Ondřej Surý wrote: > as I promised I am opening another issue to solve. This time I picked > #10 since it seems to be far away from #7 and #29 which are discussed > in the list right now. > > It's seven months old and says: > > > If an intermediate CA were compromised, then a DNS admin could > > obviate the revocation of the relevant CA cert by adding an RR. > > Not that likely, and detectable, but maybe worth a security > > consideration paragraph since such a case might be fairly > > catastrophic as-is, but would be made worse with DANE. > > What does WG think? The cases that come to mind are: 1) we've associated to an EE, but that EE is revoked A couple of things could have happened here: 1a) the CA revoked the EE certificate because the EE certificate key has been compromised (likely because owner said so), and the DNS hasn't updated to reflect it--possibly because the cache hasn't expired yet or the DNS admin hasn't gotten around to updating the DNS yet. This is probably the typical case. - In this case, we definitely want to respect the revocation 1b) the CA mistakenly or maliciously revoked the EE certificate. I imagine this is rare. - While this is certainly inconvenient, the DNS admin can work around the problem by acquiring/generating a new certificate and updating the DNS accordingly. For this case, it's better to treat the EE cert as revoked. CAs with a habit of revoking EE certs inappropriately will not stay in business long. 2) we've associated to an EE, but some CA is revoked In this case, we can do the same as the above, but should we? The DNS admin has said that the EE cert is correct. Why would revocation of a CA cast doubt on the correctness of the EE certificate? I suppose my attitude would change if people think it'll become common practice for DNS admins to allow CAs to update the admin's zones automatically on certificate issue. In that case, I'd suggest a security consideration advising against it. ;-) Of course, realistically, the cert and DANE record will probably need replacement anyway if there is still a significant population of RPs that are either unaware of or unwilling/unable to use DANE, because they will be rejecting the certificate (unless they don't look at revocation at all, in which case this whole issue is moot). But IMHO, that would be the admin's/owner's call. 3) we've associated to a CA, but the EE is revoked This case doesn't even affect the DANE association. Normal processing applies. 4) we've associated to a CA, but that CA is revoked In this case, we certainly want to treat the certificate as revoked--if the CA certificate is revoked, it was probably compromised, and we can't trust that the EE cert seen by the RP is not a fake. 5) we've associated to a CA, but some CA above it is revoked This is equivalent to case 2. So, in summary, I think that if the certificate associated to by the DANE record is revoked, the revocation should be respected. If a CA above it is revoked, I don't think that should matter. If a CA/EE cert below it is revoked, normal PKIX processing applies, and DANE isn't even involved. -- Scott Schmit From i.grok@comcast.net Tue Aug 16 21:09:19 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66C7D21F8AF9 for ; Tue, 16 Aug 2011 21:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.639 X-Spam-Level: X-Spam-Status: No, score=-102.639 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iR1h-ayF5aH8 for ; Tue, 16 Aug 2011 21:09:18 -0700 (PDT) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by ietfa.amsl.com (Postfix) with ESMTP id E13BB21F8AF5 for ; Tue, 16 Aug 2011 21:09:18 -0700 (PDT) Received: from omta13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by qmta09.emeryville.ca.mail.comcast.net with comcast id MG901h00217UAYkA9GA5kM; Wed, 17 Aug 2011 04:10:05 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta13.emeryville.ca.mail.comcast.net with comcast id MGA51h00m00PQ6U8ZGA6Np; Wed, 17 Aug 2011 04:10:06 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.4/8.14.3) with ESMTP id p7H4A6cZ029143 for ; Wed, 17 Aug 2011 00:10:06 -0400 Received: (from draco@localhost) by odin.ulthar.us (8.14.4/8.14.4/Submit) id p7H4A6TX029141 for dane@ietf.org; Wed, 17 Aug 2011 00:10:06 -0400 Date: Wed, 17 Aug 2011 00:10:06 -0400 From: Scott Schmit To: dane@ietf.org Message-ID: <20110817041006.GA22852@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <004f01cc5baa$c72943c0$557bcb40$@augustcellars.com> <1EB458FD-D8C3-4A82-B05E-ABC68B6EACD7@kirei.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1EB458FD-D8C3-4A82-B05E-ABC68B6EACD7@kirei.se> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Comments on Appendex B X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 17 Aug 2011 04:09:19 -0000 On Tue, Aug 16, 2011 at 09:12:26PM +0200, Jakob Schlyter wrote: > On 16 aug 2011, at 02:23, Jim Schaad wrote: > > > 1. The text makes the assumption at all new reference types are going to be > > hashes. I do not agree that this is true statement. Therefore the second > > condition should be > > > > Else if (R.referenceType is both known and a hash) AND (hash(R.referenceType > > of C) == R.certAssoc) { > > I was under the assumption that the reference type is always the identity reference or a hash. What other types can you think of? URI URN Fingerprint Anyway, all other things equal, it's just better not to close future growth unnecessarily. -- Scott Schmit From bmanning@karoshi.com Tue Aug 16 21:56:21 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5306221F8888 for ; Tue, 16 Aug 2011 21:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.395 X-Spam-Level: X-Spam-Status: No, score=-6.395 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2uuZhTj0umoM for ; Tue, 16 Aug 2011 21:56:20 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7E421F8880 for ; Tue, 16 Aug 2011 21:56:19 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id p7GMwqCD017468; Tue, 16 Aug 2011 22:58:52 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id p7GMwpln017467; Tue, 16 Aug 2011 22:58:51 GMT Date: Tue, 16 Aug 2011 22:58:51 +0000 From: bmanning@vacation.karoshi.com To: Jim Schaad Message-ID: <20110816225851.GD14894@vacation.karoshi.com.> References: <004d01cc5ba6$a5927780$f0b76680$@augustcellars.com> <20110816133458.GB14894@vacation.karoshi.com.> <00b301cc5c4b$79878950$6c969bf0$@augustcellars.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00b301cc5c4b$79878950$6c969bf0$@augustcellars.com> User-Agent: Mutt/1.4.1i Cc: bmanning@vacation.karoshi.com, dane@ietf.org Subject: Re: [dane] Adding a new appendix section A.1.4 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 17 Aug 2011 04:56:21 -0000 NS rr's are used to define a cut point in the DNS namespace in conjunction with the SOA rr. I'm not sure I can code what you are attempting to describe below with existant DNS rr types. can you show some DNS configuration fragments that clearly articulate your claim that Alice can delegte to Oscar a single entry in the dns namespace? or are you suggesting something like this:: example.net. in soa ( ); in ns foo in ns bar ; bill in a 127.0.53.12 in tlsa [bill-goop] ; jim in soa ( ); jim.example.com. in ns tick in ns tock in tlsa [jim-goop] ; $ORIGIN example.net. paul in a 127.0.53.13 On Tue, Aug 16, 2011 at 12:34:10PM -0700, Jim Schaad wrote: > The use of NS records is one way to delegate all information about a single > server to an outsource provider and allow it to do all of the necessary > record maintenance as well as populate the TLSA records as needed for that > server. This provides one method that can be used to support the use case > of Alice delegating to Oscar the support for a single server in the tree, > while allowing for minimal work by Alice. If this method of delegation is > used, then Oscar and Alice need to coordinate the rollover of the DNSSEC > keys in order to keep the information properly signed. > > > -----Original Message----- > > From: bmanning@vacation.karoshi.com > > [mailto:bmanning@vacation.karoshi.com] > > Sent: Tuesday, August 16, 2011 6:35 AM > > To: Jim Schaad > > Cc: dane@ietf.org > > Subject: Re: [dane] Adding a new appendix section A.1.4 > > > > On Mon, Aug 15, 2011 at 04:54:18PM -0700, Jim Schaad wrote: > > > At present I do not have any suggested text for this section because I > > > do not know enough details about how this would work. However I would > > > like to see the addition of a new section A.1.4 Delegation of > > > Provisioning TLSA Records. > > > > > > This section would discuss the use of NS records to delegate an entire > > > subtree of an existing name space to a service provider. This should > > > discuss the issues involved with coordination of key records. > > > > > > Jim > > > > > > > what would that look like? > > > > /bill From bmanning@karoshi.com Tue Aug 16 21:56:21 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 594E521F89A1 for ; Tue, 16 Aug 2011 21:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.403 X-Spam-Level: X-Spam-Status: No, score=-6.403 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yT-cdepzS6IG for ; Tue, 16 Aug 2011 21:56:20 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id BC88621F888A for ; Tue, 16 Aug 2011 21:56:20 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id p7GDYxCD016510; Tue, 16 Aug 2011 13:34:59 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id p7GDYwxr016509; Tue, 16 Aug 2011 13:34:58 GMT Date: Tue, 16 Aug 2011 13:34:58 +0000 From: bmanning@vacation.karoshi.com To: Jim Schaad Message-ID: <20110816133458.GB14894@vacation.karoshi.com.> References: <004d01cc5ba6$a5927780$f0b76680$@augustcellars.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004d01cc5ba6$a5927780$f0b76680$@augustcellars.com> User-Agent: Mutt/1.4.1i Cc: dane@ietf.org Subject: Re: [dane] Adding a new appendix section A.1.4 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 17 Aug 2011 04:56:21 -0000 On Mon, Aug 15, 2011 at 04:54:18PM -0700, Jim Schaad wrote: > At present I do not have any suggested text for this section because I do > not know enough details about how this would work. However I would like to > see the addition of a new section A.1.4 Delegation of Provisioning TLSA > Records. > > This section would discuss the use of NS records to delegate an entire > subtree of an existing name space to a service provider. This should > discuss the issues involved with coordination of key records. > > Jim > what would that look like? /bill From jakob@kirei.se Wed Aug 17 02:27:11 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2D5C21F855A for ; Wed, 17 Aug 2011 02:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.618 X-Spam-Level: X-Spam-Status: No, score=-0.618 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BjD23w-Ctw12 for ; Wed, 17 Aug 2011 02:27:10 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id EFE5021F8551 for ; Wed, 17 Aug 2011 02:27:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=ztPFBSZ0sJl4mi3t8G2kJvrlpvntd5pWr+sbkmFbObs=; b=EmgvTdVTinRsxOPt94/TAUwpxxHMJPKutZFZk5xXkqwMytccmnaWwfoBOJfQ6t1fjdmD30Pso998V KjlDlZpR0wf3RymbXJYZnZPASbBOuwjrNVh+mrCJ2kBeisITP0ftNy873QpiCYhNCmvmtJirzciTKp IlbQ/iymVS62nxuw= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Wed, 17 Aug 2011 11:27:55 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: <20110817041006.GA22852@odin.ulthar.us> Date: Wed, 17 Aug 2011 11:27:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <48589EA3-71BD-4571-B39C-05E86C9629EE@kirei.se> References: <004f01cc5baa$c72943c0$557bcb40$@augustcellars.com> <1EB458FD-D8C3-4A82-B05E-ABC68B6EACD7@kirei.se> <20110817041006.GA22852@odin.ulthar.us> To: Scott Schmit X-Mailer: Apple Mail (2.1244.3) Cc: dane@ietf.org Subject: Re: [dane] Comments on Appendex B X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 17 Aug 2011 09:27:12 -0000 On 17 aug 2011, at 06:10, Scott Schmit wrote: > URI > URN How can these ever be cryptograpphicaly secure?=20 > Fingerprint That is a hash, right? > Anyway, all other things equal, it's just better not to close future > growth unnecessarily. Implementationwise, I believe it is good make things simple and limit = the reference type to be either the identity or a hash. jakob From jakob@kirei.se Wed Aug 17 02:35:19 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4E6521F8AC3 for ; Wed, 17 Aug 2011 02:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.621 X-Spam-Level: X-Spam-Status: No, score=-0.621 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qdkDuFJBUJcu for ; Wed, 17 Aug 2011 02:35:19 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id 5BE6721F859F for ; Wed, 17 Aug 2011 02:35:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=sNvbP6yLgid8PWsZc59gcDIfXI6sSQWAFRWLXD/yfhk=; b=SCuHAf4+MraVDDmsoUbvwZlZ8QQSWGL7GPrdfrfOf2AFf8rzpS12QgOUuVLEdNXNnrexeG/aBYyM5 Aor1WWhnlvp0l4vJYPVvEd99xFYJDY7fUCIa/2FdfgCb/yQhWLqClGv6snQqsHkuLPm5cbZFpjy6i3 sioxWZJSNpOgzi/Q= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Wed, 17 Aug 2011 11:36:02 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> Date: Wed, 17 Aug 2011 11:35:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <49E3FC12-24E5-40EE-B3D5-E851D3446F5A@kirei.se> References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1244.3) Cc: DANE WG , dane issue tracker Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 17 Aug 2011 09:35:19 -0000 On 17 aug 2011, at 05:20, Paul Hoffman wrote: > The tentative proposal we came up with also has two parts: >=20 > - Instead of just three types: > 1 -- A PKIX certificate that identifies an end entity > 2 -- A PKIX certification authority's certificate > 3 -- A public key expressed as a PKIX SubjectPublicKeyInfo = structure > There should be six: > n -- A PKIX certificate that identifies an end entity > n+1 -- A PKIX certification authority's certificate that identifies a = trust anchor > n+2 -- A PKIX certification authority's certificate that identifies an = intermediate CA > n+3 -- A public key expressed as a PKIX SubjectPublicKeyInfo structure = that identifies a trust anchor > n+4 -- A public key expressed as a PKIX SubjectPublicKeyInfo structure = that identifies an intermediate CA > n+5 -- A public key expressed as a PKIX SubjectPublicKeyInfo structure = that identifies an end entity I like this approach and believe it would easier to implement than what = we have now. >=20 > - Instead of "Certificate Type" and "Reference Type", we need words = that define the fields' roles better. A first guess would be = "Restriction Type" and "Matching Type", but there could easily be better = words. Works for me. jakob From hallam@gmail.com Wed Aug 17 02:51:26 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE8B21F8B1B for ; Wed, 17 Aug 2011 02:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.455 X-Spam-Level: X-Spam-Status: No, score=-3.455 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5EGjenRrcFDz for ; Wed, 17 Aug 2011 02:51:25 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0F57921F8B02 for ; Wed, 17 Aug 2011 02:51:24 -0700 (PDT) Received: by ywm21 with SMTP id 21so626460ywm.31 for ; Wed, 17 Aug 2011 02:52:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=iUYDw34KKFYXnsY+9ORLPeagmhTgtdCeIvJtTgOPnoE=; b=gC7rRl7M7oEYMmX0ur//NJ6+SaRaozCgens6hbCuifCSAjhdRZ53DhkzSdGA6HthQE aSa7bfOx2KBC5pt0gOwGlKq7QcWC1aNfZtnWJvuDe+19yelknATcumDtPtvwrAqvyMdX IJAbVzgmXAeIrJvw/huwlsbTalF82jz3L0jrg= MIME-Version: 1.0 Received: by 10.100.232.8 with SMTP id e8mr813264anh.86.1313574735295; Wed, 17 Aug 2011 02:52:15 -0700 (PDT) Received: by 10.100.94.14 with HTTP; Wed, 17 Aug 2011 02:52:15 -0700 (PDT) In-Reply-To: <20110817032323.GA28819@odin.ulthar.us> References: <30CCB651-0CC9-4F24-8FB2-7C488626FA1D@nic.cz> <20110817032323.GA28819@odin.ulthar.us> Date: Wed, 17 Aug 2011 10:52:15 +0100 Message-ID: From: Phillip Hallam-Baker To: dane@ietf.org Content-Type: multipart/alternative; boundary=0016368e1fa97bb6dd04aab07349 Subject: Re: [dane] Opening issue #10: Considerations related to the comprimise of an intermediate CA X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 17 Aug 2011 09:51:26 -0000 --0016368e1fa97bb6dd04aab07349 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Aug 17, 2011 at 4:23 AM, Scott Schmit wrote: > > 2) we've associated to an EE, but some CA is revoked > > In this case, we can do the same as the above, but should we? The DNS > admin has said that the EE cert is correct. Why would revocation of a > CA cast doubt on the correctness of the EE certificate? > Because DANE is currently trying to be two things. 1) a mechanism for publishing keys 2) a mechanism for enforcing restrictions on CA issue If a site is using DANE for the second it cannot be assumed that the site is even aware of the CA cert revocation. Automating the process of deregistering the revoked certs is certainly going to be difficult. And then there is the additional complication of DNSSEC caching. If people want to do 2 then RPs have to perform the full CRL checking. > I suppose my attitude would change if people think it'll become common > practice for DNS admins to allow CAs to update the admin's zones > automatically on certificate issue. In that case, I'd suggest a security > consideration advising against it. ;-) > I can't see any chance of DANE being deployed without automation. A security consideration that requires manual intervention is very costly. > So, in summary, I think that if the certificate associated to by the > DANE record is revoked, the revocation should be respected. If a CA > above it is revoked, I don't think that should matter. If a CA/EE cert > below it is revoked, normal PKIX processing applies, and DANE isn't even > involved. > This comes under the heading changing PKIX semantics. PKIX is a security infrastructure. I tend to think that is not going to happen. -- Website: http://hallambaker.com/ --0016368e1fa97bb6dd04aab07349 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Aug 17, 2011 at 4:23 AM, Scott S= chmit <i.grok@co= mcast.net> wrote:
2) we've associated to an EE, but some CA is revoked

In this case, we can do the same as the above, but should we? The DNS
admin has said that the EE cert is correct. Why would revocation of a
CA cast doubt on the correctness of the EE certificate?

Because DANE is currently trying to be two things.

1) a mechanism for publishing keys
2) a mechani= sm for enforcing restrictions on CA issue

If a site is using DANE for the second it cannot be ass= umed that the site is even aware of the CA cert revocation. Automating the = process of deregistering the revoked certs is certainly going to be difficu= lt. And then there is the additional complication of DNSSEC caching.

If people want to do 2 then RPs have to perform the ful= l CRL checking.

=A0
I suppose my attitude would change if people think it'll become common<= br> practice for DNS admins to allow CAs to update the admin's zones
automatically on certificate issue. In that case, I'd suggest a securit= y
consideration advising against it. ;-)

= I can't see any chance of DANE being deployed without automation.=A0

A security consideration that requires manual interv= ention is very costly.
=A0
So, in summary, I think that if the certificate associated to by the
DANE record is revoked, the revocation should be respected. If a CA
above it is revoked, I don't think that should matter. If a CA/EE cert<= br> below it is revoked, normal PKIX processing applies, and DANE isn't eve= n
involved.

This comes under the heading = changing PKIX semantics.

PKIX is a security infras= tructure. I tend to think that is not going to happen.

=A0

--
Website: http://hallambaker.com/

--0016368e1fa97bb6dd04aab07349-- From rbarnes@bbn.com Wed Aug 17 04:58:51 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD3C121F8B4A for ; Wed, 17 Aug 2011 04:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.271 X-Spam-Level: X-Spam-Status: No, score=-106.271 tagged_above=-999 required=5 tests=[AWL=-0.272, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41og2Y-NG6vV for ; Wed, 17 Aug 2011 04:58:50 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id A6C3921F8B49 for ; Wed, 17 Aug 2011 04:58:50 -0700 (PDT) Received: from [128.89.255.133] (port=64697 helo=[192.168.1.13]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QtemZ-000Mub-8i; Wed, 17 Aug 2011 07:59:39 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <20110817051226.GB17498@vacation.karoshi.com.> Date: Wed, 17 Aug 2011 07:59:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <70F5FD47-8862-4A4C-84AE-BC7708AB50C2@bbn.com> <9103D852-36CE-462D-8306-0B348B4FE4F0@bbn.com> <20110817051226.GB17498@vacation.karoshi.com.> To: bmanning@vacation.karoshi.com X-Mailer: Apple Mail (2.1082) Cc: DANE WG Subject: Re: [dane] Protocol / port numbers as prefix X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 17 Aug 2011 11:58:51 -0000 Can't by spec: The "number of answer RRs" field in DNS responses is = only 16 bits wide, so there can only be 65536 RRs in the answer. --Richard On Aug 17, 2011, at 1:12 AM, bmanning@vacation.karoshi.com wrote: > can't by spec or implementations have set an artifical boundary? >=20 > (of course I'd not want to see the path to TCP delivery for large = RRsets > become commonplace... but does one -require- a full enumeration of all=20= > ports at each RRset?) >=20 > /bill >=20 > On Tue, Aug 16, 2011 at 04:56:21PM +0100, Phillip Hallam-Baker wrote: >> The problem then is that DNS does not really allow for 65536 RRs in = the same >> node. So it does not work out the way people think. >>=20 >> I still think people are going to be getting rather a shock when they = try to >> deploy for large Web farms. Google certainly can't use this for >> https://www.google.com/. >>=20 >> On Tue, Aug 16, 2011 at 4:46 PM, Richard L. Barnes = wrote: >>=20 >>> Ah, there it is. I was just summarizing because I hadn't found a = record of >>> this debate having happened. Consider my comment withdrawn. >>>=20 >>> --Richard >>>=20 >>>=20 >>> On Aug 16, 2011, at 11:26 AM, OndE=19ej SurC=3D wrote: >>>=20 >>>> On 16. 8. 2011, at 16:11, Richard L. Barnes wrote: >>>>> It is clearly causing some people discomfort to have protocols and = port >>> numbers as prefixes. Why not just push them into the RRDATA and = provision >>> the TLSA directly under the affected name? >>>>=20 >>>>=20 >>>> Hi Richard, >>>>=20 >>>> I would like to point out that we already had this discussion (at = least >>> once): >>>>=20 >>>> http://trac.tools.ietf.org/wg/dane/trac/ticket/1 >>>>=20 >>>> and here is the mail thread: >>>>=20 >>>> = http://www.ietf.org/mail-archive/web/keyassure/current/msg01631.html >>>>=20 >>>> While I don't have a problem reopening the issue if that's what >>>> the WG wants I would prefer to not reiterate the same issues >>>> again and again unless you (all) at least read the mailing list >>>> archives. >>>>=20 >>>> Thanks, >>>> O. >>>>=20 >>>> -- >>>> OndE=19ej SurC=3D >>>> vedoucC- vC=3Dzkumu/Head of R&D department >>>> ------------------------------------------- >>>> CZ.NIC, z.s.p.o. -- LaboratoE=19e CZ.NIC >>>> Americka 23, 120 00 Praha 2, Czech Republic >>>> mailto:ondrej.sury@nic.cz http://nic.cz/ >>>> tel:+420.222745110 fax:+420.222745112 >>>> ------------------------------------------- >>>>=20 >>>=20 >>> _______________________________________________ >>> dane mailing list >>> dane@ietf.org >>> https://www.ietf.org/mailman/listinfo/dane >>>=20 >>=20 >>=20 >>=20 >> --=20 >> Website: http://hallambaker.com/ >=20 >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >=20 From i.grok@comcast.net Wed Aug 17 07:13:45 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 631FA21F8B18 for ; Wed, 17 Aug 2011 07:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.636 X-Spam-Level: X-Spam-Status: No, score=-102.636 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tmBVRA99PX8h for ; Wed, 17 Aug 2011 07:13:44 -0700 (PDT) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by ietfa.amsl.com (Postfix) with ESMTP id 6891D21F8B16 for ; Wed, 17 Aug 2011 07:13:44 -0700 (PDT) Received: from omta11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by qmta09.emeryville.ca.mail.comcast.net with comcast id MRGR1h0040mlR8UA9SEXSS; Wed, 17 Aug 2011 14:14:31 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta11.emeryville.ca.mail.comcast.net with comcast id MSEV1h01L00PQ6U8XSEZAj; Wed, 17 Aug 2011 14:14:35 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.4/8.14.3) with ESMTP id p7HEESt0000830 for ; Wed, 17 Aug 2011 10:14:28 -0400 Received: (from draco@localhost) by odin.ulthar.us (8.14.4/8.14.4/Submit) id p7HEESIS000828 for dane@ietf.org; Wed, 17 Aug 2011 10:14:28 -0400 Date: Wed, 17 Aug 2011 10:14:28 -0400 From: Scott Schmit To: dane@ietf.org Message-ID: <20110817141428.GB22852@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <30CCB651-0CC9-4F24-8FB2-7C488626FA1D@nic.cz> <20110817032323.GA28819@odin.ulthar.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Opening issue #10: Considerations related to the comprimise of an intermediate CA X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 17 Aug 2011 14:13:45 -0000 On Wed, Aug 17, 2011 at 10:52:15AM +0100, Phillip Hallam-Baker wrote: > On Wed, Aug 17, 2011 at 4:23 AM, Scott Schmit wrote: > > 2) we've associated to an EE, but some CA is revoked > > > > In this case, we can do the same as the above, but should we? The DNS > > admin has said that the EE cert is correct. Why would revocation of a > > CA cast doubt on the correctness of the EE certificate? > > Because DANE is currently trying to be two things. > > 1) a mechanism for publishing keys > 2) a mechanism for enforcing restrictions on CA issue 3) a mechanism for authenticating an EE certificate via DNSSEC instead of/in addition to a CA. > If a site is using DANE for the second it cannot be assumed that the site is > even aware of the CA cert revocation. Automating the process of > deregistering the revoked certs is certainly going to be difficult. And then > there is the additional complication of DNSSEC caching. If they are using DANE for the second, then case 2 doesn't apply (it would be case 4 instead ["we've associated to a CA, but that CA is revoked"]). For case 2/5 [good EE/CA cert with revoked CA], they will find out when users complain that their non-DANE clients are unable to connect because of the revoked CA. Since it would be the users of non-DANE clients complaining, it's obviously not new to DANE, and the problem already exists now. Yes, the DNS cache adds latency to fixing things. This can be made less bad by associating to the key instead of the certificate or avoiding very long TTLs. > If people want to do 2 then RPs have to perform the full CRL checking. If the associated-to CA is what's being revoked, I agree with you. If it's above that, not so much. See below, under my response to your statement that this changes PKIX semantics. > > I suppose my attitude would change if people think it'll become common > > practice for DNS admins to allow CAs to update the admin's zones > > automatically on certificate issue. In that case, I'd suggest a security > > consideration advising against it. ;-) > > I can't see any chance of DANE being deployed without automation. > > A security consideration that requires manual intervention is very costly. For the CAs I've looked at, it's expected that the user configure the certificate-using services themselves, but perhaps for the pricier certs, CAs offer more services. The threat model I was thinking about, where I would no longer trust an EE cert if its CA was compromised, is if the EE allowed the CA to make CA-initiated changes to the EE's server configurations to replace the EE certificate whenever the CA felt like it. And yet, the EE doesn't trust the CA enough to set the DANE record to associate to the CA cert instead of the EE cert. It just seemed...odd. I suppose even that would be ok, provided that the EE actually checks (automated or otherwise) that the subject key in the EE cert actually matches the public key held by the EE (and any other relevant fields in the cert that have security implications for the EE) before accepting the update. That assumes, of course, that the private key wasn't provided by the CA as well. If that's the case, the CA is equivalent to the EE, and I really don't understand why you don't just associate to the CA instead. > > So, in summary, I think that if the certificate associated to by the > > DANE record is revoked, the revocation should be respected. If a CA > > above it is revoked, I don't think that should matter. If a CA/EE cert > > below it is revoked, normal PKIX processing applies, and DANE isn't even > > involved. > This comes under the heading changing PKIX semantics. I'm not exactly sure what you mean by "changing PKIX semantics" or at least, which ones you think this changes. What I think you're suggesting is that it's one thing for DANE to add restrictions, but another for DANE to allow things that were previously not allowed. Except we are already doing that by allowing the DNSSEC chain of trust add a trust anchor to the certificate store (for the name in question). All I'm saying is that there are essentially two entities vouching for the associated certificate in this case--the DNSSEC tree and the PKIX CA. There is a big difference between saying "I, the still-valid PKIX CA, no longer believe that the subject private key is under the control of the subject" and "I, the PKIX CA, recuse [revoke] myself, so you should no longer trust any assertions I made about other certs [possibly after X date?]". We're in agreement on the former, and in the latter case, the RP would previously have had to distrust the cert (having no other source of information), but now DNSSEC can vouch for the associated cert. I suppose this is a change for CA processing, in that previously they could revoke a CA and consider all the certs under it revoked as well, whereas now, to have the same effect, they'd need to revoke all the certificates. I can see how that's a bad thing for CAs, but I'm not sure how this is a bad thing for RPs or EEs. This way, everyone knows exactly which certs are believed to be misissued or entities compromised. -- Scott Schmit From paul.hoffman@vpnc.org Wed Aug 17 08:10:22 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35C8021F8B44 for ; Wed, 17 Aug 2011 08:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wIlv-vmwuLNb for ; Wed, 17 Aug 2011 08:10:20 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id A286621F8B47 for ; Wed, 17 Aug 2011 08:10:19 -0700 (PDT) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p7HFAXeG005121 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 17 Aug 2011 08:10:34 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Paul Hoffman In-Reply-To: <006301cc5bc7$860006f0$920014d0$@augustcellars.com> Date: Wed, 17 Aug 2011 08:10:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <74B71A15-E1E1-4057-9C6B-4721FCC270C2@nic.cz> <006301cc5bc7$860006f0$920014d0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1244.3) Cc: DANE WG Subject: Re: [dane] Opening issue #7: Error Handling : What to do when you receive an invalid record X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 17 Aug 2011 15:10:22 -0000 On Aug 15, 2011, at 8:49 PM, Jim Schaad wrote: >=20 >=20 >> -----Original Message----- >> From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf = Of >> Paul Hoffman >> Sent: Monday, August 15, 2011 7:40 PM >> To: Ondrej Sur=FD >> Cc: dane@ietf.org >> Subject: Re: [dane] Opening issue #7: Error Handling : What to do = when you >> receive an invalid record >>=20 >> Make it unusable. >>=20 >> Current: >> If a certificate association contains a reference type that is not >> understood by the TLS client, that certificate association MUST be >> marked as unusable. >> Proposed: >> If a certificate association contains a reference type or = certificate > type that >> is not >> understood by the TLS client, that certificate association MUST be >> marked as unusable. If an error occurs when comparing using >> reference types that are not exact matches (such as hashes), the >> certificate association MUST be marked as unusable. >=20 > If an error occurs when comparing using reference types, the = certificate > association MUST be marked as unusable. >=20 > -- I don't understand why there is a reason for the 'not exact = matches', it > should not matter as long as the comparison is done in the correct = manner if > you are comparing either the direct bytes or via a function such as a = hash. Good point. >=20 > -- Note that the statement that it be marked as unusable does not = match the > pseudo code in appendix B unless there is a check someplace in the = code that > I missed for things which are marked unusable as oppose to a usable = but > failed check. The pseudocode in Appendix B is incomplete. We will add the following = (or something like it) near the beginning: // unusable records include unknown certType, unknown certAssoc // and erroneous RDATA strip unusable records if (no good TLSA record(s) received) { fall back to "normal" cert validation } Proposed: If a certificate association contains a reference type or certificate = type that is not understood by the TLS client, that certificate association MUST be marked as unusable. If an error occurs when comparing, the certificate association MUST be marked as unusable. Does that resolve your concern? --Paul Hoffman From paul.hoffman@vpnc.org Wed Aug 17 08:16:57 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7593121F8B76 for ; Wed, 17 Aug 2011 08:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lnKyywtcNXaX for ; Wed, 17 Aug 2011 08:16:57 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id F0B6B21F8B51 for ; Wed, 17 Aug 2011 08:16:56 -0700 (PDT) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p7HFHMoo005477 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 17 Aug 2011 08:17:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Aug 2011 08:17:47 -0700 Message-Id: <3C0A5855-3773-49AB-B0FB-E5D205EBCE05@vpnc.org> To: DANE WG Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) Subject: [dane] Fixing the wording for the last paragraph of Section 4.4 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 17 Aug 2011 15:16:57 -0000 Greetings again. Earlier, Jim said: =3D=3D=3D=3D=3D 3. The text in para 6 of section 4.4 is very out of date. It does not discuss any certificate type except end-entity and states that if an end-entity certificate is not found (i.e. you cannot do a trust anchor = only DANE record) then the handshake aborts =3D=3D=3D=3D=3D The current text in the document is: If a match between one of the certificate association(s) and the = server's end entity certificate in TLS is found, the TLS client continues the TLS handshake. If no match between the usable certificate association(s) and = the server's end entity certificate in TLS is found, the TLS client MUST = abort the handshake with an "access_denied" error. I propose the following fix: If a match between one of the certificate association(s) and the = server's certificate chain in TLS is found, the TLS client continues the TLS handshake. If no match between the usable certificate association(s) and = the server's certificate chain in TLS is found, the TLS client MUST abort = the handshake with an "access_denied" error. Does that match what people would have expected? --Paul Hoffman From trac+dane@trac.tools.ietf.org Wed Aug 17 08:31:49 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82A3221F8AFF for ; Wed, 17 Aug 2011 08:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBEZYZHu7iQn for ; Wed, 17 Aug 2011 08:31:49 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1F821F84AC for ; Wed, 17 Aug 2011 08:31:48 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1Qti6e-0005kK-JJ; Wed, 17 Aug 2011 08:32:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: draft-ietf-dane-protocol@tools.ietf.org, paul.hoffman@vpnc.org X-Trac-Project: dane Date: Wed, 17 Aug 2011 15:32:36 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dane/trac/ticket/30 Message-ID: <060.d9d7d9eb5ef585fc2a7f1726d8ad15bf@trac.tools.ietf.org> X-Trac-Ticket-ID: 30 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dane-protocol@tools.ietf.org, paul.hoffman@vpnc.org, dane@ietf.org X-SA-Exim-Mail-From: trac+dane@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20110817153149.0F1F821F84AC@ietfa.amsl.com> Resent-Date: Wed, 17 Aug 2011 08:31:48 -0700 (PDT) Resent-From: trac+dane@trac.tools.ietf.org Cc: dane@ietf.org Subject: [dane] #30: Better coverage for certificate association wording X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 15:31:49 -0000 #30: Better coverage for certificate association wording Earlier, Jim Schaad said: ===== 3. The text in para 6 of section 4.4 is very out of date. It does not discuss any certificate type except end-entity and states that if an end-entity certificate is not found (i.e. you cannot do a trust anchor only DANE record) then the handshake aborts ===== The current text in the document is: If a match between one of the certificate association(s) and the server's end entity certificate in TLS is found, the TLS client continues the TLS handshake. If no match between the usable certificate association(s) and the server's end entity certificate in TLS is found, the TLS client MUST abort the handshake with an "access_denied" error. -- -----------------------------------+---------------------------------------- Reporter: paul.hoffman@… | Owner: draft-ietf-dane-protocol@… Type: defect | Status: new Priority: major | Milestone: Component: protocol | Version: Severity: - | Keywords: -----------------------------------+---------------------------------------- Ticket URL: dane From trac+dane@trac.tools.ietf.org Wed Aug 17 08:32:09 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F67321F8569 for ; Wed, 17 Aug 2011 08:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVk6rzpAGh6h for ; Wed, 17 Aug 2011 08:32:09 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 223BA21F8565 for ; Wed, 17 Aug 2011 08:32:09 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1Qti72-0006ws-HU; Wed, 17 Aug 2011 08:33:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: draft-ietf-dane-protocol@tools.ietf.org, paul.hoffman@vpnc.org X-Trac-Project: dane Date: Wed, 17 Aug 2011 15:33:00 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dane/trac/ticket/30#comment:1 Message-ID: <069.d8e01ab70c49d6573b5d7adf8899f7a9@trac.tools.ietf.org> References: <060.d9d7d9eb5ef585fc2a7f1726d8ad15bf@trac.tools.ietf.org> X-Trac-Ticket-ID: 30 In-Reply-To: <060.d9d7d9eb5ef585fc2a7f1726d8ad15bf@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dane-protocol@tools.ietf.org, paul.hoffman@vpnc.org, dane@ietf.org X-SA-Exim-Mail-From: trac+dane@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20110817153209.223BA21F8565@ietfa.amsl.com> Resent-Date: Wed, 17 Aug 2011 08:32:09 -0700 (PDT) Resent-From: trac+dane@trac.tools.ietf.org Cc: dane@ietf.org Subject: Re: [dane] #30: Better coverage for certificate association wording X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 15:32:09 -0000 #30: Better coverage for certificate association wording Comment(by paul.hoffman@…): I propose the following fix: If a match between one of the certificate association(s) and the server's certificate chain in TLS is found, the TLS client continues the TLS handshake. If no match between the usable certificate association(s) and the server's certificate chain in TLS is found, the TLS client MUST abort the handshake with an "access_denied" error. -- -----------------------------------+---------------------------------------- Reporter: paul.hoffman@… | Owner: draft-ietf-dane-protocol@… Type: defect | Status: new Priority: major | Milestone: Component: protocol | Version: Severity: - | Keywords: -----------------------------------+---------------------------------------- Ticket URL: dane From paul.hoffman@vpnc.org Wed Aug 17 08:33:03 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7033521F8B3E for ; Wed, 17 Aug 2011 08:33:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WdccpiB9lImK for ; Wed, 17 Aug 2011 08:33:03 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id E5F7B21F8B3A for ; Wed, 17 Aug 2011 08:33:02 -0700 (PDT) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p7HFXRe5006058 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 17 Aug 2011 08:33:28 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1244.3) From: Paul Hoffman In-Reply-To: <3C0A5855-3773-49AB-B0FB-E5D205EBCE05@vpnc.org> Date: Wed, 17 Aug 2011 08:33:53 -0700 Content-Transfer-Encoding: 7bit Message-Id: <4785AD59-201B-4BB0-AD93-E3619B0FCECC@vpnc.org> References: <3C0A5855-3773-49AB-B0FB-E5D205EBCE05@vpnc.org> To: DANE WG X-Mailer: Apple Mail (2.1244.3) Subject: Re: [dane] Fixing the wording for the last paragraph of Section 4.4 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 17 Aug 2011 15:33:03 -0000 (Sorry, should have used the issue tracker; now is issue #30) --Paul Hoffman From trac+dane@trac.tools.ietf.org Wed Aug 17 08:37:51 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D545721F8ABE for ; Wed, 17 Aug 2011 08:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLsOzyuRzsSp for ; Wed, 17 Aug 2011 08:37:51 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 671DB21F8AB8 for ; Wed, 17 Aug 2011 08:37:51 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QtiCY-00014f-8t; Wed, 17 Aug 2011 08:38:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: draft-ietf-dane-protocol@tools.ietf.org, paul.hoffman@vpnc.org X-Trac-Project: dane Date: Wed, 17 Aug 2011 15:38:42 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dane/trac/ticket/31 Message-ID: <060.d55c279a583dd38213fda7e1f7c9e46d@trac.tools.ietf.org> X-Trac-Ticket-ID: 31 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dane-protocol@tools.ietf.org, paul.hoffman@vpnc.org, dane@ietf.org X-SA-Exim-Mail-From: trac+dane@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20110817153751.671DB21F8AB8@ietfa.amsl.com> Resent-Date: Wed, 17 Aug 2011 08:37:51 -0700 (PDT) Resent-From: trac+dane@trac.tools.ietf.org Cc: dane@ietf.org Subject: [dane] #31: Multiple TLSA records in a response X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 15:37:52 -0000 #31: Multiple TLSA records in a response The document never actually states the semantics of what it means when a single DNS request returns multiple TLSA records. It should. -- -----------------------------------+---------------------------------------- Reporter: paul.hoffman@… | Owner: draft-ietf-dane-protocol@… Type: defect | Status: new Priority: major | Milestone: Component: protocol | Version: Severity: - | Keywords: -----------------------------------+---------------------------------------- Ticket URL: dane From trac+dane@trac.tools.ietf.org Wed Aug 17 08:42:41 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A00B21F8B1C for ; Wed, 17 Aug 2011 08:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTDTAdoY40S9 for ; Wed, 17 Aug 2011 08:42:40 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id D012721F8B10 for ; Wed, 17 Aug 2011 08:42:38 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QtiHB-0001F5-SQ; Wed, 17 Aug 2011 08:43:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: draft-ietf-dane-protocol@tools.ietf.org, paul.hoffman@vpnc.org X-Trac-Project: dane Date: Wed, 17 Aug 2011 15:43:29 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dane/trac/ticket/31#comment:1 Message-ID: <069.63b756414a8d964317fe74f502fd4d93@trac.tools.ietf.org> References: <060.d55c279a583dd38213fda7e1f7c9e46d@trac.tools.ietf.org> X-Trac-Ticket-ID: 31 In-Reply-To: <060.d55c279a583dd38213fda7e1f7c9e46d@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dane-protocol@tools.ietf.org, paul.hoffman@vpnc.org, dane@ietf.org X-SA-Exim-Mail-From: trac+dane@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20110817154240.D012721F8B10@ietfa.amsl.com> Resent-Date: Wed, 17 Aug 2011 08:42:38 -0700 (PDT) Resent-From: trac+dane@trac.tools.ietf.org Cc: dane@ietf.org Subject: Re: [dane] #31: Multiple TLSA records in a response X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 15:42:41 -0000 #31: Multiple TLSA records in a response Comment(by paul.hoffman@…): Proposal: in section 4.4, add a short paragraph that says "A domain name can have more than one TLSA record. A typical use for multiple TLSA records would be when the site is changing from one certificate to another. If a DNS response contains multiple TLSA records, any record from the set returned can be used to make certificate associations." -- -----------------------------------+---------------------------------------- Reporter: paul.hoffman@… | Owner: draft-ietf-dane-protocol@… Type: defect | Status: new Priority: major | Milestone: Component: protocol | Version: Severity: - | Keywords: -----------------------------------+---------------------------------------- Ticket URL: dane From hallam@gmail.com Wed Aug 17 11:47:24 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A99621F8514 for ; Wed, 17 Aug 2011 11:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.156 X-Spam-Level: X-Spam-Status: No, score=-3.156 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4+ZgfqpT6bT for ; Wed, 17 Aug 2011 11:47:23 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 449F021F84DF for ; Wed, 17 Aug 2011 11:47:23 -0700 (PDT) Received: by yie12 with SMTP id 12so1069932yie.31 for ; Wed, 17 Aug 2011 11:48:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JpADC37prwxRzC5UBBD5ui63pFDJzHijFykuFTz2JXY=; b=W5IjOHuWchWvCjRix22qd2QHudMWTCcqh4RQWCa4CMtjdB41jPNpw93zWz4AsgVc39 wQBbaWEpjjU/ECghpy7UjJ4uTh5fxy15Gqkz3eFkvtErELIthtrYrwwkFGbfgNthDYKH L9P93RWJbMdv7tvGFaVJ4MMgFALo8TScvedis= MIME-Version: 1.0 Received: by 10.101.133.22 with SMTP id k22mr1401527ann.90.1313606894738; Wed, 17 Aug 2011 11:48:14 -0700 (PDT) Received: by 10.100.94.14 with HTTP; Wed, 17 Aug 2011 11:48:14 -0700 (PDT) In-Reply-To: <4e4c0a61.8d26cc0a.3f38.ffffa76aSMTPIN_ADDED@mx.google.com> References: <70F5FD47-8862-4A4C-84AE-BC7708AB50C2@bbn.com> <9103D852-36CE-462D-8306-0B348B4FE4F0@bbn.com> <20110817051226.GB17498@vacation.karoshi.com.> <4e4c0a61.8d26cc0a.3f38.ffffa76aSMTPIN_ADDED@mx.google.com> Date: Wed, 17 Aug 2011 19:48:14 +0100 Message-ID: From: Phillip Hallam-Baker To: bmanning@vacation.karoshi.com Content-Type: multipart/alternative; boundary=0016e68d378655dcd504aab7f0c0 Cc: DANE WG Subject: Re: [dane] Protocol / port numbers as prefix X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 17 Aug 2011 18:47:24 -0000 --0016e68d378655dcd504aab7f0c0 Content-Type: text/plain; charset=ISO-8859-1 Well we are revisiting an old point here. But while it may be technically possible to do that, I don't think DNS works well with 64K x 100b records = 6.4Mb That would mean back off to TCP for a start and blow through caches. On Wed, Aug 17, 2011 at 7:35 PM, wrote: > er... 16 bits sez the spec -allows- up to 65536 RR 's in an RRset. > so Phillip is incorrect in his statement that "the DNS does not really > allow for 65536 RRs in > the same node" - if I parse "same node" as single RRset. > > /bill > > > On Wed, Aug 17, 2011 at 07:59:30AM -0400, Richard L. Barnes wrote: > > Can't by spec: The "number of answer RRs" field in DNS responses is only > 16 bits wide, so there can only be 65536 RRs in the answer. > > > > --Richard > > > > > > On Aug 17, 2011, at 1:12 AM, bmanning@vacation.karoshi.com wrote: > > > > > can't by spec or implementations have set an artifical boundary? > > > > > > (of course I'd not want to see the path to TCP delivery for large > RRsets > > > become commonplace... but does one -require- a full enumeration of all > > > ports at each RRset?) > > > > > > /bill > > > > > > On Tue, Aug 16, 2011 at 04:56:21PM +0100, Phillip Hallam-Baker wrote: > > >> The problem then is that DNS does not really allow for 65536 RRs in > the same > > >> node. So it does not work out the way people think. > > >> > > >> I still think people are going to be getting rather a shock when they > try to > > >> deploy for large Web farms. Google certainly can't use this for > > >> https://www.google.com/. > > >> > > >> On Tue, Aug 16, 2011 at 4:46 PM, Richard L. Barnes > wrote: > > >> > > >>> Ah, there it is. I was just summarizing because I hadn't found a > record of > > >>> this debate having happened. Consider my comment withdrawn. > > >>> > > >>> --Richard > > >>> > > >>> > > >>> On Aug 16, 2011, at 11:26 AM, OndE ej SurC= wrote: > > >>> > > >>>> On 16. 8. 2011, at 16:11, Richard L. Barnes wrote: > > >>>>> It is clearly causing some people discomfort to have protocols and > port > > >>> numbers as prefixes. Why not just push them into the RRDATA and > provision > > >>> the TLSA directly under the affected name? > > >>>> > > >>>> > > >>>> Hi Richard, > > >>>> > > >>>> I would like to point out that we already had this discussion (at > least > > >>> once): > > >>>> > > >>>> http://trac.tools.ietf.org/wg/dane/trac/ticket/1 > > >>>> > > >>>> and here is the mail thread: > > >>>> > > >>>> > http://www.ietf.org/mail-archive/web/keyassure/current/msg01631.html > > >>>> > > >>>> While I don't have a problem reopening the issue if that's what > > >>>> the WG wants I would prefer to not reiterate the same issues > > >>>> again and again unless you (all) at least read the mailing list > > >>>> archives. > > >>>> > > >>>> Thanks, > > >>>> O. > > >>>> > > >>>> -- > > >>>> OndE ej SurC= > > >>>> vedoucC- vC=zkumu/Head of R&D department > > >>>> ------------------------------------------- > > >>>> CZ.NIC, z.s.p.o. -- LaboratoE e CZ.NIC > > >>>> Americka 23, 120 00 Praha 2, Czech Republic > > >>>> mailto:ondrej.sury@nic.cz http://nic.cz/ > > >>>> tel:+420.222745110 fax:+420.222745112 > > >>>> ------------------------------------------- > > >>>> > > >>> > > >>> _______________________________________________ > > >>> dane mailing list > > >>> dane@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/dane > > >>> > > >> > > >> > > >> > > >> -- > > >> Website: http://hallambaker.com/ > > > > > >> _______________________________________________ > > >> dane mailing list > > >> dane@ietf.org > > >> https://www.ietf.org/mailman/listinfo/dane > > > > > > -- Website: http://hallambaker.com/ --0016e68d378655dcd504aab7f0c0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Well we are revisiting an old point here.

But while it m= ay be technically possible to do that, I don't think DNS works well wit= h 64K x 100b records =3D 6.4Mb=A0

That would mean = back off to TCP for a start and blow through caches.

=A0

On Wed, Aug 17, 2= 011 at 7:35 PM, <bmanning@vacation.karoshi.com> wrote:
=A0er... 16 bits sez the spec -allows- up to 65536 RR 's =A0in an RRset= .
=A0so Phillip is incorrect in his statement that "the DNS does not rea= lly allow for 65536 RRs in
=A0the same node" =A0- if I parse "same node" as single RRse= t.

/bill


On Wed, Aug 17, 2011 at 07:59:30AM -0400, Richard L. Barnes wrote:
> Can't by spec: The "number of answer RRs" field in =A0DN= S responses is only 16 bits wide, so there can only be 65536 RRs in the ans= wer.
>
> --Richard
>
>
> On Aug 17, 2011, at 1:12 AM, bmanning@vacation.karoshi.com wrote:
>
> > can't by spec or implementations have set an artifical bounda= ry?
> >
> > (of course I'd not want to see the path to TCP delivery for l= arge RRsets
> > become commonplace... but does one -require- a full enumeration o= f all
> > ports at each RRset?)
> >
> > /bill
> >
> > On Tue, Aug 16, 2011 at 04:56:21PM +0100, Phillip Hallam-Baker wr= ote:
> >> The problem then is that DNS does not really allow for 65536 = RRs in the same
> >> node. So it does not work out the way people think.
> >>
> >> I still think people are going to be getting rather a shock w= hen they try to
> >> deploy for large Web farms. Google certainly can't use th= is for
> >> https:/= /www.google.com/.
> >>
> >> On Tue, Aug 16, 2011 at 4:46 PM, Richard L. Barnes <rbarnes@bbn.com> wrote:
> >>
> >>> Ah, there it is. =A0I was just summarizing because I hadn= 't found a record of
> >>> this debate having happened. =A0Consider my comment withd= rawn.
> >>>
> >>> --Richard
> >>>
> >>>
> >>> On Aug 16, 2011, at 11:26 AM, OndE ej SurC=3D wrote:
> >>>
> >>>> On 16. 8. 2011, at 16:11, Richard L. Barnes wrote: > >>>>> It is clearly causing some people discomfort to h= ave protocols and port
> >>> numbers as prefixes. =A0Why not just push them into the R= RDATA and provision
> >>> the TLSA directly under the affected name?
> >>>>
> >>>>
> >>>> Hi Richard,
> >>>>
> >>>> I would like to point out that we already had this di= scussion (at least
> >>> once):
> >>>>
> >>>> http://trac.tools.ietf.org/wg/dane/trac/ticket/1<= /a>
> >>>>
> >>>> and here is the mail thread:
> >>>>
> >>>> http://www.ietf.org/mail-arch= ive/web/keyassure/current/msg01631.html
> >>>>
> >>>> While I don't have a problem reopening the issue = if that's what
> >>>> the WG wants I would prefer to not reiterate the same= issues
> >>>> again and again unless you (all) at least read the ma= iling list
> >>>> archives.
> >>>>
> >>>> Thanks,
> >>>> O.
> >>>>
> >>>> --
> >>>> OndE ej SurC=3D
> >>>> vedoucC- vC=3Dzkumu/Head of R&D department
> >>>> -------------------------------------------
> >>>> CZ.NIC, z.s.p.o. =A0 =A0-- =A0 =A0LaboratoE e CZ.NIC<= br> > >>>> Americka 23, 120 00 Praha 2, Czech Republic
> >>>> mailto:ondrej.s= ury@nic.cz =A0 =A0http://n= ic.cz/
> >>>> tel:+420.222745110 =A0 =A0 =A0 fax:+420.222745112
> >>>> -------------------------------------------
> >>>>
> >>>
> >>> _______________________________________________
> >>> dane mailing list
> >>> dane@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/dane
> >>>
> >>
> >>
> >>
> >> --
> >> Website: http://hallambaker.com/
> >
> >> _______________________________________________
> >> dane mailing list
> >> dane@ietf.org
> >> https://www.ietf.org/mailman/listinfo/dane
> >
>



--
= Website: http://hallambaker.com/
--0016e68d378655dcd504aab7f0c0-- From warren@kumari.net Wed Aug 17 11:48:10 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7714221F8B23 for ; Wed, 17 Aug 2011 11:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yoboLhrNVXxU for ; Wed, 17 Aug 2011 11:48:10 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 06BF821F851A for ; Wed, 17 Aug 2011 11:48:10 -0700 (PDT) Received: from dot.her.corp.google.com (unknown [74.202.225.33]) by vimes.kumari.net (Postfix) with ESMTPSA id B2C261B403ED; Wed, 17 Aug 2011 14:49:01 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <4785AD59-201B-4BB0-AD93-E3619B0FCECC@vpnc.org> Date: Wed, 17 Aug 2011 14:49:00 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <3C0A5855-3773-49AB-B0FB-E5D205EBCE05@vpnc.org> <4785AD59-201B-4BB0-AD93-E3619B0FCECC@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1084) Cc: DANE WG Subject: Re: [dane] Fixing the wording for the last paragraph of Section 4.4 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 17 Aug 2011 18:48:10 -0000 On Aug 17, 2011, at 11:33 AM, Paul Hoffman wrote: > (Sorry, should have used the issue tracker; now is issue #30) Thank you Paul! W > > --Paul Hoffman > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > From ietf@augustcellars.com Wed Aug 17 13:20:40 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9512421F8B34 for ; Wed, 17 Aug 2011 13:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.475 X-Spam-Level: X-Spam-Status: No, score=-3.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id teN5XfcmiJzC for ; Wed, 17 Aug 2011 13:20:39 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6367A21F8B7C for ; Wed, 17 Aug 2011 13:20:39 -0700 (PDT) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 1F99F2CA0B; Wed, 17 Aug 2011 13:21:28 -0700 (PDT) From: "Jim Schaad" To: References: <004d01cc5ba6$a5927780$f0b76680$@augustcellars.com> <20110816133458.GB14894@vacation.karoshi.com.> <00b301cc5c4b$79878950$6c969bf0$@augustcellars.com> <20110816225851.GD14894@vacation.karoshi.com.> In-Reply-To: <20110816225851.GD14894@vacation.karoshi.com.> Date: Wed, 17 Aug 2011 13:55:59 -0700 Message-ID: <006a01cc5d20$178a2d90$469e88b0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHqqGx6FIYRvqWedOD9jAm1ISg4rAGttckgAeO1JisCQSRswZS2WpAQ Content-Language: en-us Cc: dane@ietf.org Subject: Re: [dane] Adding a new appendix section A.1.4 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 17 Aug 2011 20:20:40 -0000 I do not know enough about DNS to be able to give you the correct items. Note however that I am not trying to delegate a single entry but an entire subtree. This should make it easier. Jim > -----Original Message----- > From: bmanning@vacation.karoshi.com > [mailto:bmanning@vacation.karoshi.com] > Sent: Tuesday, August 16, 2011 3:59 PM > To: Jim Schaad > Cc: bmanning@vacation.karoshi.com; dane@ietf.org > Subject: Re: [dane] Adding a new appendix section A.1.4 > > > NS rr's are used to define a cut point in the DNS namespace in conjunction > with the SOA rr. > > I'm not sure I can code what you are attempting to describe below with > existant DNS rr types. > > can you show some DNS configuration fragments that clearly articulate your > claim that Alice can delegte to Oscar a single entry in the dns namespace? > > or are you suggesting something like this:: > > example.net. in soa ( ); > > in ns foo > in ns bar > ; > bill in a 127.0.53.12 > in tlsa [bill-goop] > ; > jim in soa ( ); > jim.example.com. in ns tick > in ns tock > in tlsa [jim-goop] > ; > $ORIGIN example.net. > paul in a 127.0.53.13 > > > On Tue, Aug 16, 2011 at 12:34:10PM -0700, Jim Schaad wrote: > > The use of NS records is one way to delegate all information about a > > single server to an outsource provider and allow it to do all of the > > necessary record maintenance as well as populate the TLSA records as > needed for that > > server. This provides one method that can be used to support the use > case > > of Alice delegating to Oscar the support for a single server in the > > tree, while allowing for minimal work by Alice. If this method of > > delegation is used, then Oscar and Alice need to coordinate the > > rollover of the DNSSEC keys in order to keep the information properly > signed. > > > > > -----Original Message----- > > > From: bmanning@vacation.karoshi.com > > > [mailto:bmanning@vacation.karoshi.com] > > > Sent: Tuesday, August 16, 2011 6:35 AM > > > To: Jim Schaad > > > Cc: dane@ietf.org > > > Subject: Re: [dane] Adding a new appendix section A.1.4 > > > > > > On Mon, Aug 15, 2011 at 04:54:18PM -0700, Jim Schaad wrote: > > > > At present I do not have any suggested text for this section > > > > because I do not know enough details about how this would work. > > > > However I would like to see the addition of a new section A.1.4 > > > > Delegation of Provisioning TLSA Records. > > > > > > > > This section would discuss the use of NS records to delegate an > > > > entire subtree of an existing name space to a service provider. > > > > This should discuss the issues involved with coordination of key records. > > > > > > > > Jim > > > > > > > > > > what would that look like? > > > > > > /bill From ietf@augustcellars.com Wed Aug 17 13:24:21 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82FE021F8BF4 for ; Wed, 17 Aug 2011 13:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.482 X-Spam-Level: X-Spam-Status: No, score=-3.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ux7nJDak53g for ; Wed, 17 Aug 2011 13:24:21 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id E8F3321F8BEF for ; Wed, 17 Aug 2011 13:24:20 -0700 (PDT) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id D16DE38F6D; Wed, 17 Aug 2011 13:25:10 -0700 (PDT) From: "Jim Schaad" To: "'Scott Schmit'" , References: <004f01cc5baa$c72943c0$557bcb40$@augustcellars.com> <1EB458FD-D8C3-4A82-B05E-ABC68B6EACD7@kirei.se> <20110817041006.GA22852@odin.ulthar.us> In-Reply-To: <20110817041006.GA22852@odin.ulthar.us> Date: Wed, 17 Aug 2011 13:59:44 -0700 Message-ID: <006b01cc5d20$9b960aa0$d2c21fe0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFWRVGiCE582KcNwBdvOyKNTvK8AAHUs5b3AgQuuEyV7u6l4A== Content-Language: en-us Subject: Re: [dane] Comments on Appendex B X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 17 Aug 2011 20:24:21 -0000 The reference type field can be thought of as a reference type - this would be a statement of how you find the certificate in question. Or it can be through of as a matching rule, the certificate in question must have this property in order to be acceptable. I think that the concept of calling a hash of a certificate a "reference type" leaves something to be desired as there is no way to find the certificate from the hash unless you already have it. However calling it a matching rule makes sense because you can check if a certificate you already have meets the criteria that has been laid out in the rule. If this is the case, it is a matching rule rather than a location rule, then it makes sense to have any number of different items here along with a set of rules for matching. Thus the proposal that I made of doing a public key matching rule is possible. Jim > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of > Scott Schmit > Sent: Tuesday, August 16, 2011 9:10 PM > To: dane@ietf.org > Subject: Re: [dane] Comments on Appendex B > > On Tue, Aug 16, 2011 at 09:12:26PM +0200, Jakob Schlyter wrote: > > On 16 aug 2011, at 02:23, Jim Schaad wrote: > > > > > 1. The text makes the assumption at all new reference types are > > > going to be hashes. I do not agree that this is true statement. > > > Therefore the second condition should be > > > > > > Else if (R.referenceType is both known and a hash) AND > > > (hash(R.referenceType of C) == R.certAssoc) { > > > > I was under the assumption that the reference type is always the identity > reference or a hash. What other types can you think of? > > URI > URN > Fingerprint > > Anyway, all other things equal, it's just better not to close future growth > unnecessarily. > > -- > Scott Schmit > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From ietf@augustcellars.com Wed Aug 17 13:25:01 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3FEC21F8C13 for ; Wed, 17 Aug 2011 13:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.888 X-Spam-Level: X-Spam-Status: No, score=-2.888 tagged_above=-999 required=5 tests=[AWL=-0.489, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBHNDL6s831L for ; Wed, 17 Aug 2011 13:25:01 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 54DE421F8BF4 for ; Wed, 17 Aug 2011 13:25:01 -0700 (PDT) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id E24FC38F1D; Wed, 17 Aug 2011 13:25:51 -0700 (PDT) From: "Jim Schaad" To: "'Paul Hoffman'" , "'dane issue tracker'" References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> In-Reply-To: <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> Date: Wed, 17 Aug 2011 14:00:25 -0700 Message-ID: <006c01cc5d20$b4033ef0$1c09bcd0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHwXbPL2/IzPDFsf9e9Pk9vZhBFJQMMON3xlMEkG6A= Content-Language: en-us Cc: 'DANE WG' Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 17 Aug 2011 20:25:02 -0000 This is not my ideal method of doing it, but it is one that I can live with. > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of > Paul Hoffman > Sent: Tuesday, August 16, 2011 8:20 PM > To: dane issue tracker > Cc: DANE WG > Subject: Re: [dane] #29: Request new Reference Type - Public Key > > When talking with Jim, we realized that the issue is raising here is a > confluence of two things: > - He wants to be able to restrict the role that the cert or public key can be > used in (trust anchor, intermediate CA, end entity) > - The current names for the two fields in record don't reflect their actual use > > The tentative proposal we came up with also has two parts: > > - Instead of just three types: > 1 -- A PKIX certificate that identifies an end entity > 2 -- A PKIX certification authority's certificate > 3 -- A public key expressed as a PKIX SubjectPublicKeyInfo structure There > should be six: > n -- A PKIX certificate that identifies an end entity > n+1 -- A PKIX certification authority's certificate that identifies a > n+trust anchor > n+2 -- A PKIX certification authority's certificate that identifies an > n+intermediate CA > n+3 -- A public key expressed as a PKIX SubjectPublicKeyInfo structure > n+that identifies a trust anchor > n+4 -- A public key expressed as a PKIX SubjectPublicKeyInfo structure > n+that identifies an intermediate CA > n+5 -- A public key expressed as a PKIX SubjectPublicKeyInfo structure > n+that identifies an end entity > > - Instead of "Certificate Type" and "Reference Type", we need words that > define the fields' roles better. A first guess would be "Restriction Type" and > "Matching Type", but there could easily be better words. > > --Paul Hoffman > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From ietf@augustcellars.com Wed Aug 17 13:31:14 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D05E21F0C53 for ; Wed, 17 Aug 2011 13:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.464 X-Spam-Level: X-Spam-Status: No, score=-3.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ekm4pQ0nA5mV for ; Wed, 17 Aug 2011 13:31:14 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 484AE1F0C51 for ; Wed, 17 Aug 2011 13:31:14 -0700 (PDT) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 42FD12CA1C; Wed, 17 Aug 2011 13:32:04 -0700 (PDT) From: "Jim Schaad" To: "'Paul Hoffman'" References: <74B71A15-E1E1-4057-9C6B-4721FCC270C2@nic.cz> <006301cc5bc7$860006f0$920014d0$@augustcellars.com> In-Reply-To: Date: Wed, 17 Aug 2011 14:06:39 -0700 Message-ID: <006d01cc5d21$922d7ba0$b68872e0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHzmcrXAa7573k1pdzaApVz2VR52AOF76/dA4kNKCUCWt6zX5SHwEUw Content-Language: en-us Cc: 'DANE WG' Subject: Re: [dane] Opening issue #7: Error Handling : What to do when you receive an invalid record X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 17 Aug 2011 20:31:14 -0000 > -----Original Message----- > From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] > Sent: Wednesday, August 17, 2011 8:11 AM > To: Jim Schaad > Cc: DANE WG > Subject: Re: [dane] Opening issue #7: Error Handling : What to do when = you > receive an invalid record >=20 >=20 > On Aug 15, 2011, at 8:49 PM, Jim Schaad wrote: >=20 > > > > > >> -----Original Message----- > >> From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On = Behalf > >> Of Paul Hoffman > >> Sent: Monday, August 15, 2011 7:40 PM > >> To: Ondrej Sur=FD > >> Cc: dane@ietf.org > >> Subject: Re: [dane] Opening issue #7: Error Handling : What to do > >> when you receive an invalid record > >> > >> Make it unusable. > >> > >> Current: > >> If a certificate association contains a reference type that is = not > >> understood by the TLS client, that certificate association MUST = be > >> marked as unusable. > >> Proposed: > >> If a certificate association contains a reference type or > >> certificate > > type that > >> is not > >> understood by the TLS client, that certificate association MUST = be > >> marked as unusable. If an error occurs when comparing using > >> reference types that are not exact matches (such as hashes), the > >> certificate association MUST be marked as unusable. > > > > If an error occurs when comparing using reference types, the > > certificate association MUST be marked as unusable. > > > > -- I don't understand why there is a reason for the 'not exact > > matches', it should not matter as long as the comparison is done in > > the correct manner if you are comparing either the direct bytes or = via a > function such as a hash. >=20 > Good point. > > > > -- Note that the statement that it be marked as unusable does not > > match the pseudo code in appendix B unless there is a check = someplace > > in the code that I missed for things which are marked unusable as > > oppose to a usable but failed check. >=20 > The pseudocode in Appendix B is incomplete. We will add the following = (or > something like it) near the beginning: >=20 > // unusable records include unknown certType, unknown certAssoc > // and erroneous RDATA > strip unusable records > if (no good TLSA record(s) received) { > fall back to "normal" cert validation > } >=20 > Proposed: > If a certificate association contains a reference type or = certificate type that is > not > understood by the TLS client, that certificate association MUST be > marked as unusable. If an error occurs when comparing, the > certificate association MUST be marked as unusable. >=20 > Does that resolve your concern? It all looks good except for the last line in the proposed text. An comparison failure could be thought of as an error and in that case you = do not want to be marked as unusable. I think what you meant was: If the comparison data for a certificate is malformed, the certificate association MUST be marked as unusable. Jim >=20 > --Paul Hoffman From ietf@augustcellars.com Wed Aug 17 13:32:02 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50AAF1F0C59 for ; Wed, 17 Aug 2011 13:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.47 X-Spam-Level: X-Spam-Status: No, score=-3.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MwRXi0hGgFxv for ; Wed, 17 Aug 2011 13:32:01 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id CFF8B1F0C51 for ; Wed, 17 Aug 2011 13:32:01 -0700 (PDT) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 489A438F28; Wed, 17 Aug 2011 13:32:50 -0700 (PDT) From: "Jim Schaad" To: "'Paul Hoffman'" , "'DANE WG'" References: <3C0A5855-3773-49AB-B0FB-E5D205EBCE05@vpnc.org> In-Reply-To: <3C0A5855-3773-49AB-B0FB-E5D205EBCE05@vpnc.org> Date: Wed, 17 Aug 2011 14:07:22 -0700 Message-ID: <006e01cc5d21$ae5fa730$0b1ef590$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLEDoANonWfpDr737giJG/CTIFxf5MyJkww Content-Language: en-us Subject: Re: [dane] Fixing the wording for the last paragraph of Section 4.4 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 17 Aug 2011 20:32:02 -0000 +1 > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of > Paul Hoffman > Sent: Wednesday, August 17, 2011 8:18 AM > To: DANE WG > Subject: [dane] Fixing the wording for the last paragraph of Section 4.4 > > Greetings again. Earlier, Jim said: > ===== > 3. The text in para 6 of section 4.4 is very out of date. It does not discuss any > certificate type except end-entity and states that if an end-entity certificate > is not found (i.e. you cannot do a trust anchor only DANE record) then the > handshake aborts ===== > > The current text in the document is: > > If a match between one of the certificate association(s) and the server's end > entity certificate in TLS is found, the TLS client continues the TLS handshake. > If no match between the usable certificate association(s) and the server's > end entity certificate in TLS is found, the TLS client MUST abort the > handshake with an "access_denied" error. > > I propose the following fix: > > If a match between one of the certificate association(s) and the server's > certificate chain in TLS is found, the TLS client continues the TLS handshake. If > no match between the usable certificate association(s) and the server's > certificate chain in TLS is found, the TLS client MUST abort the handshake > with an "access_denied" error. > > Does that match what people would have expected? > > --Paul Hoffman > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From warren@kumari.net Wed Aug 17 14:16:19 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3B6E21F8C20 for ; Wed, 17 Aug 2011 14:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRCtb4kXXf7j for ; Wed, 17 Aug 2011 14:16:19 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id A8D6021F8C2A for ; Wed, 17 Aug 2011 14:16:18 -0700 (PDT) Received: from dot.her.corp.google.com (unknown [74.202.225.33]) by vimes.kumari.net (Postfix) with ESMTPSA id 5F7441B403ED; Wed, 17 Aug 2011 17:17:10 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> Date: Wed, 17 Aug 2011 17:17:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> To: dane issue tracker X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-dane-protocol@tools.ietf.org, jimsch@exmsft.com, dane@ietf.org Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 17 Aug 2011 21:16:19 -0000 Just an admin note:=20 We will be calling consensus on Monday on this topic... W On Aug 15, 2011, at 7:41 PM, dane issue tracker wrote: > #29: Request new Reference Type - Public Key >=20 > I would like to be able to restrict to a certificate based solely on = the > public key value of the certificate. This could be used for any of = the > different Certificate Type fields. EE certificate, Trust Anchor > certificate and the missing ones for intermediate certificate and pgp > certificate. >=20 > --=20 > = --------------------------------+-----------------------------------------= -- > Reporter: jimsch@=85 | Owner: = draft-ietf-dane-protocol@=85 =20 > Type: enhancement | Status: new = =20 > Priority: major | Milestone: milestone1 = =20 > Component: protocol | Version: 1.0 = =20 > Severity: Active WG Document | Keywords: = =20 > = --------------------------------+-----------------------------------------= -- >=20 > Ticket URL: > dane >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From rbarnes@bbn.com Wed Aug 17 17:57:11 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9A421F8508 for ; Wed, 17 Aug 2011 17:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.565 X-Spam-Level: X-Spam-Status: No, score=-106.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07G5iE5T95C5 for ; Wed, 17 Aug 2011 17:57:10 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7A221F8B21 for ; Wed, 17 Aug 2011 17:57:03 -0700 (PDT) Received: from [128.89.254.216] (port=51864 helo=[192.168.1.13]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Qtqvh-000Py2-HK; Wed, 17 Aug 2011 20:57:54 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> Date: Wed, 17 Aug 2011 20:57:48 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <54C1B56E-7673-4F32-8E7B-25959C121A03@bbn.com> References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1082) Cc: DANE WG , dane issue tracker Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 18 Aug 2011 00:57:11 -0000 This suggestion seems to be missing the point. You're still conflating = the identifier for a certificate for how it's used. Suggest the = following taxonomy, which aligns much better with the use cases: Association Type: 0. Service cert should be accepted ONLY IF matching cert is in cert = chain 1. Service cert should be accepted ONLY IF it matches=20 2. Service cert should be accepted IF any cert in the chain matches Reference Type: 0. X.509 certificate (match(cert) =3D byte-wise equality) 1. SubjectPublicKeyInfo structure (match(cert) =3D SPKI in cert) *. Digest of X.509 certificate *. Digest of SubjectPublicKeyInfo Of course, one could also argue that the SPKI stuff is out of scope, = since there's nothing in the use case document that calls for it. --Richard On Aug 16, 2011, at 11:20 PM, Paul Hoffman wrote: > When talking with Jim, we realized that the issue is raising here is a = confluence of two things: > - He wants to be able to restrict the role that the cert or public key = can be used in (trust anchor, intermediate CA, end entity) > - The current names for the two fields in record don't reflect their = actual use >=20 > The tentative proposal we came up with also has two parts: >=20 > - Instead of just three types: > 1 -- A PKIX certificate that identifies an end entity > 2 -- A PKIX certification authority's certificate > 3 -- A public key expressed as a PKIX SubjectPublicKeyInfo = structure > There should be six: > n -- A PKIX certificate that identifies an end entity > n+1 -- A PKIX certification authority's certificate that identifies a = trust anchor > n+2 -- A PKIX certification authority's certificate that identifies an = intermediate CA > n+3 -- A public key expressed as a PKIX SubjectPublicKeyInfo structure = that identifies a trust anchor > n+4 -- A public key expressed as a PKIX SubjectPublicKeyInfo structure = that identifies an intermediate CA > n+5 -- A public key expressed as a PKIX SubjectPublicKeyInfo structure = that identifies an end entity >=20 > - Instead of "Certificate Type" and "Reference Type", we need words = that define the fields' roles better. A first guess would be = "Restriction Type" and "Matching Type", but there could easily be better = words. >=20 > --Paul Hoffman > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From jakob@kirei.se Wed Aug 17 23:18:11 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 860F521F87D6 for ; Wed, 17 Aug 2011 23:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.623 X-Spam-Level: X-Spam-Status: No, score=-0.623 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id limVnHFr8YAx for ; Wed, 17 Aug 2011 23:18:10 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id 0983E11E8091 for ; Wed, 17 Aug 2011 23:18:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=aVDXq6hqajoihSf1hqF3nxbEvW9I2NHXOWPX3K16bYc=; b=hpNl1rGmD9+Z/C55LYPotslFouJ1E08Cf3/yiLjzFWG0XZKweUK0FKVJn2VOIzJD48jBi1s62gNEF lC+Mk/1GCOfGkcuNdcXiiF+rKOMLFJNkKqPBp5/dK4zjkJIH+OURUDOgRyIGSEWruHQuVmatQ2aFwU Ix18wxo1Qqw0+d9w= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Thu, 18 Aug 2011 08:18:58 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: <54C1B56E-7673-4F32-8E7B-25959C121A03@bbn.com> Date: Thu, 18 Aug 2011 08:18:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1A26AD12-8E76-45BA-BB21-CE758D353620@kirei.se> References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> <54C1B56E-7673-4F32-8E7B-25959C121A03@bbn.com> To: Richard L. Barnes X-Mailer: Apple Mail (2.1244.3) Cc: Paul Hoffman , DANE WG Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 18 Aug 2011 06:18:11 -0000 On 18 aug 2011, at 02:57, Richard L. Barnes wrote: > Of course, one could also argue that the SPKI stuff is out of scope, = since there's nothing in the use case document that calls for it. I find the following exactly the SPKI stuff: Simple Key Management: DANE should have a mode in which the domain holder only needs to maintain a single long-lived public/private key pair. jakob From rbarnes@bbn.com Thu Aug 18 04:51:49 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9AD21F8B1D for ; Thu, 18 Aug 2011 04:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.566 X-Spam-Level: X-Spam-Status: No, score=-106.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K+ymxBk3+2QM for ; Thu, 18 Aug 2011 04:51:48 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 878FA21F8AF0 for ; Thu, 18 Aug 2011 04:51:48 -0700 (PDT) Received: from [128.89.254.246] (port=53455 helo=[192.168.1.10]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Qu19M-0004Zo-FL; Thu, 18 Aug 2011 07:52:40 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <1A26AD12-8E76-45BA-BB21-CE758D353620@kirei.se> Date: Thu, 18 Aug 2011 07:52:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> <54C1B56E-7673-4F32-8E7B-25959C121A03@bbn.com> <1A26AD12-8E76-45BA-BB21-CE758D353620@kirei.se> To: Jakob Schlyter X-Mailer: Apple Mail (2.1082) Cc: Paul Hoffman , DANE WG Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 18 Aug 2011 11:51:49 -0000 Single key pair doesn't imply SPKI. Single key pair could imply = self-signed certificate, or even multiple different certificates with = the same key pair. For example, if you wanted to be really PKIX-friendly and not use a CA = cert as your service certificate, you could create a self-signed cert = (therefore a CA cert) with your key pair and issue an EE cert under it = (your service cert) with the same key pair. --Richard On Aug 18, 2011, at 2:18 AM, Jakob Schlyter wrote: > On 18 aug 2011, at 02:57, Richard L. Barnes wrote: >=20 >> Of course, one could also argue that the SPKI stuff is out of scope, = since there's nothing in the use case document that calls for it. >=20 > I find the following exactly the SPKI stuff: >=20 > Simple Key Management: DANE should have a mode in which the domain > holder only needs to maintain a single long-lived public/private > key pair. >=20 >=20 >=20 > jakob >=20 From stephen.farrell@cs.tcd.ie Thu Aug 18 06:01:19 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51CAE21F8B3C for ; Thu, 18 Aug 2011 06:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.024 X-Spam-Level: X-Spam-Status: No, score=-106.024 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3JO9mIfVV3P for ; Thu, 18 Aug 2011 06:01:17 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id BF5D021F8B32 for ; Thu, 18 Aug 2011 06:01:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 03CA6171CFD; Thu, 18 Aug 2011 14:01:59 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1313672518; bh=K+3xSH5Hyn+eeU PEi5Y7haIv6RIoLMwaTKQvia6seXg=; b=nOPxNMXOr3ul4zDD5IkHoXqEdS1NB3 C8kCN1Ss7+lmSyN2fFxmDcWElGS9qYXrH5hLtJs4zeYnfnwvm5/qIbOwHrbGwxZE xL890KUCNrZBPSqMC+7YCkaP7gJJMLbcXw5pDpybwUTRn8qyGpZccXwXrwCPhUP2 pmzzNbnagS05wRaSTxvvjGrJvenVKRA29SkyqB+Ymva7id2xYSD8457aPXHlqQTR YLzHaROOrDHmurK13y0T61Gmzb7TzGOUVA+om4ITYW294fMOIcFjyfzoSZ10U7nJ IKqbhLv6zgFlY6+S3UqFTVBGtizlj8FJl27DV6HySQjI9rdC0sx7kmuw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id D+4F5431zYmZ; Thu, 18 Aug 2011 14:01:58 +0100 (IST) Received: from [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c] (unknown [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 5226B171BFE; Thu, 18 Aug 2011 14:01:53 +0100 (IST) Message-ID: <4E4D0D37.5030604@cs.tcd.ie> Date: Thu, 18 Aug 2011 14:01:43 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: "Richard L. Barnes" References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> <54C1B56E-7673-4F32-8E7B-25959C121A03@bbn.com> In-Reply-To: <54C1B56E-7673-4F32-8E7B-25959C121A03@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dane issue tracker , Paul Hoffman , DANE WG Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 18 Aug 2011 13:01:19 -0000 Just one wrinkle on this: On 08/18/2011 01:57 AM, Richard L. Barnes wrote: > 1. SubjectPublicKeyInfo structure (match(cert) = SPKI in cert) There'd need to be a statement about the case where the cert inherits relevant parameters from a superior cert that affect the subject public key info. That's a corner case that could maybe be ruled as not matching for DANE (perhaps), or else this matching rule gets complex. Look in 5280 for working_public_key_parameters for more info. I don't know of any actually useful algorithms where this is a deal. ECC in 5480 has MUST NOTs for this kind of inheritance, GOST in 4491 does allow it, but I don't know if that's a deal for DANE, and there might be others as well, I dunno. It could also be that this kind of inheritance also affects reference type 0 as well, someone probably needs to consider that. If some other public key format (pgp, ssh, whatever) handles algorithm parameters with some other inheritance mechanism, then that might also cause a problem and so also needs a bit of consideration. That's yet another thing I don't know:-) I don't care how this is solved, so long as its solved. Not solving this would probably cause nasty security issues, at least in principle. S. PS: I think I mentioned this before at the mic in Prague, not sure if its covered in the current protocol draft or was discussed on the list though - if so, sorry for being redundant:-) From mrex@sap.com Thu Aug 18 06:06:18 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4E5521F8B3C for ; Thu, 18 Aug 2011 06:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.012 X-Spam-Level: X-Spam-Status: No, score=-10.012 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRl4oKi7H8Uz for ; Thu, 18 Aug 2011 06:06:18 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0D521F8A7E for ; Thu, 18 Aug 2011 06:06:17 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p7ID74qJ010541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 18 Aug 2011 15:07:04 +0200 (MEST) From: Martin Rex Message-Id: <201108181307.p7ID74sK012025@fs4113.wdf.sap.corp> To: rbarnes@bbn.com (Richard L. Barnes) Date: Thu, 18 Aug 2011 15:07:04 +0200 (MEST) In-Reply-To: from "Richard L. Barnes" at Aug 18, 11 07:52:30 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: paul.hoffman@vpnc.org, dane@ietf.org Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 13:06:18 -0000 Richard L. Barnes wrote: > > Single key pair doesn't imply SPKI. Single key pair could imply > self-signed certificate, or even multiple different certificates > with the same key pair. > > For example, if you wanted to be really PKIX-friendly and not use > a CA cert as your service certificate, you could create a self-signed > cert (therefore a CA cert) with your key pair and issue an EE cert > under it (your service cert) with the same key pair. I firmly believe that reusing a "CA keypair" for an end entity key signed by that CA sounds like a very bad idea. Ideally, self-signed end-entity certs should be X.509v1 certs. Very unfortunately, the maintainers of OpenSSL and of Java (as of v1.6) seemed to have goofed up seriously, because more recent versions of these softwares seems to no longer create X.509v1 certs, but instead self-signed non-CA X.509v3 certs -- even when the certs is created without X.509v3 extensions. The problem of X.509v3 self-signed no-CA certs is that they're BOGUS certificates. Both X.509-2008 and rfc5280 explicitly do *NOT* apply to self-signed non-CA certs at all. X.509v1 are at least covered by older versions of the X.509 standard (e.g. -1988) and is still fairly well supported by most PKI software. self-signed X.509v3 non-CA certs, on the other hand, are not only outside of all standars, they create interop problems, e.g. a sensible TLS server implementation would not send the subject name of an X.509v3 non-CA cert in the "certification_authorities" element of a CertificateRequest handshake message. A workaround to such interop problems seems to be to include the Basic Constraint "Allowed to act as CA = TRUE" in the self-signed cert (making it appear to be a valid RootCA of a private PKI), and use it as End-Entity cert in application protocols. -Martin From paul.hoffman@vpnc.org Thu Aug 18 07:35:15 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C82ED21F8B44 for ; Thu, 18 Aug 2011 07:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yqshksIvPEoz for ; Thu, 18 Aug 2011 07:35:15 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 51BC921F8B3B for ; Thu, 18 Aug 2011 07:35:15 -0700 (PDT) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p7IEZa5j062869 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 18 Aug 2011 07:35:36 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <54C1B56E-7673-4F32-8E7B-25959C121A03@bbn.com> Date: Thu, 18 Aug 2011 07:36:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> <54C1B56E-7673-4F32-8E7B-25959C121A03@bbn.com> To: "Richard L. Barnes" X-Mailer: Apple Mail (2.1244.3) Cc: dane issue tracker , DANE WG Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 18 Aug 2011 14:35:15 -0000 On Aug 17, 2011, at 5:57 PM, Richard L. Barnes wrote: > Association Type: > 0. Service cert should be accepted ONLY IF matching cert is in cert = chain > 1. Service cert should be accepted ONLY IF it matches=20 > 2. Service cert should be accepted IF any cert in the chain matches I don't understand this list: they all seem the same. Can you give = examples where each is different? --Paul Hoffman From kent@bbn.com Thu Aug 18 07:48:23 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E432021F8B95 for ; Thu, 18 Aug 2011 07:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.609 X-Spam-Level: X-Spam-Status: No, score=-106.609 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXEOa0YG+5Wm for ; Thu, 18 Aug 2011 07:48:23 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 7187121F8B8A for ; Thu, 18 Aug 2011 07:48:23 -0700 (PDT) Received: from dhcp89-089-143.bbn.com ([128.89.89.143]:49294) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Qu3u8-0007ZH-A4; Thu, 18 Aug 2011 10:49:08 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <201108181307.p7ID74sK012025@fs4113.wdf.sap.corp> References: <201108181307.p7ID74sK012025@fs4113.wdf.sap.corp> Date: Thu, 18 Aug 2011 10:35:50 -0400 To: mrex@sap.com From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: paul.hoffman@vpnc.org, dane@ietf.org Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 18 Aug 2011 14:48:24 -0000 At 3:07 PM +0200 8/18/11, Martin Rex wrote: >Richard L. Barnes wrote: >> >> Single key pair doesn't imply SPKI. Single key pair could imply >> self-signed certificate, or even multiple different certificates >> with the same key pair. >> >> For example, if you wanted to be really PKIX-friendly and not use >> a CA cert as your service certificate, you could create a self-signed >> cert (therefore a CA cert) with your key pair and issue an EE cert >> under it (your service cert) with the same key pair. > >I firmly believe that reusing a "CA keypair" for an end entity key >signed by that CA sounds like a very bad idea. > >Ideally, self-signed end-entity certs should be X.509v1 certs. Since PKIX has deprecated v1 certs for many years, I find it hard to agree with the term "ideally" :-). Steve From mrex@sap.com Thu Aug 18 07:59:57 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAA9F21F8B89 for ; Thu, 18 Aug 2011 07:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.016 X-Spam-Level: X-Spam-Status: No, score=-10.016 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLzTAeL+vM3E for ; Thu, 18 Aug 2011 07:59:57 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC5F21F8B74 for ; Thu, 18 Aug 2011 07:59:56 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p7IF0eoF007527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 18 Aug 2011 17:00:45 +0200 (MEST) From: Martin Rex Message-Id: <201108181500.p7IF0eID018564@fs4113.wdf.sap.corp> To: kent@bbn.com (Stephen Kent) Date: Thu, 18 Aug 2011 17:00:40 +0200 (MEST) In-Reply-To: from "Stephen Kent" at Aug 18, 11 10:35:50 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: paul.hoffman@vpnc.org, dane@ietf.org Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 14:59:58 -0000 Stephen Kent wrote: > > At 3:07 PM +0200 8/18/11, Martin Rex wrote: > >Richard L. Barnes wrote: > >> > >> Single key pair doesn't imply SPKI. Single key pair could imply > >> self-signed certificate, or even multiple different certificates > >> with the same key pair. > >> > >> For example, if you wanted to be really PKIX-friendly and not use > >> a CA cert as your service certificate, you could create a self-signed > >> cert (therefore a CA cert) with your key pair and issue an EE cert > >> under it (your service cert) with the same key pair. > > > >I firmly believe that reusing a "CA keypair" for an end entity key > >signed by that CA sounds like a very bad idea. > > > >Ideally, self-signed end-entity certs should be X.509v1 certs. > > Since PKIX has deprecated v1 certs for many years, I find it hard to agree > with the term "ideally" :-). On the contrary, it really is "ideally". The newer PKIX specifications (X.509-2008 and rfc5280) explicitly do _NOT_ apply to self-signed end-entity certs, so the deprecation does *NOT* apply to self-signed X.509v1 EE certs. X.509-2008 is actually clearer on this than rfc5280. X.509-2008, page 6: 3.4.61 self-signed certificate: A special case of self-issued certificates where the private key used by the CA to sign the certificate corresponds to the public key that is certified within the certificate. A CA might use a self-signed certificate, for example, to advertise their public key or other information about their operations. NOTE Use of self-issued certificates and self-signed certificates issued by other than CAs are outside the scope of this Recommendation | International Standard. -Martin From kent@bbn.com Thu Aug 18 09:27:49 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80FFC21F8B77 for ; Thu, 18 Aug 2011 09:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.608 X-Spam-Level: X-Spam-Status: No, score=-106.608 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMAmSFj4fIe1 for ; Thu, 18 Aug 2011 09:27:49 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id E70DC21F8B75 for ; Thu, 18 Aug 2011 09:27:48 -0700 (PDT) Received: from dhcp89-089-143.bbn.com ([128.89.89.143]:49303) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Qu5SR-000E2D-UD; Thu, 18 Aug 2011 12:28:40 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <201108181500.p7IF0eID018564@fs4113.wdf.sap.corp> References: <201108181500.p7IF0eID018564@fs4113.wdf.sap.corp> Date: Thu, 18 Aug 2011 12:17:46 -0400 To: mrex@sap.com From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: paul.hoffman@vpnc.org, dane@ietf.org Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 18 Aug 2011 16:27:49 -0000 At 5:00 PM +0200 8/18/11, Martin Rex wrote: >... > > >Ideally, self-signed end-entity certs should be X.509v1 certs. >> >> Since PKIX has deprecated v1 certs for many years, I find it hard to agree >> with the term "ideally" :-). > > >On the contrary, it really is "ideally". The newer PKIX specifications >(X.509-2008 and rfc5280) explicitly do _NOT_ apply to self-signed end-entity >certs, so the deprecation does *NOT* apply to self-signed X.509v1 EE certs. Self-signed v1 certs are deprecated along with all other v1 certs, period. The publication of 2459 (in 1999), 3280 (in 2002) and 5280 (2008) all provide a profile for v3 certs, and thus deprecate v1 certs. V1 certs were profiled for use in the Internet in RFC 1422 (1993). Also, I anticipate that the 5280 clarifications doc, will have text clarifying the status of self-signed v3 certs. Steve From mrex@sap.com Thu Aug 18 10:28:54 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4714621F8BA7 for ; Thu, 18 Aug 2011 10:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.017 X-Spam-Level: X-Spam-Status: No, score=-10.017 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxXIiE25T7HO for ; Thu, 18 Aug 2011 10:28:53 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE4621F8A7D for ; Thu, 18 Aug 2011 10:28:53 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p7IHTa6i024134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 18 Aug 2011 19:29:41 +0200 (MEST) From: Martin Rex Message-Id: <201108181729.p7IHTZsl027659@fs4113.wdf.sap.corp> To: kent@bbn.com (Stephen Kent) Date: Thu, 18 Aug 2011 19:29:35 +0200 (MEST) In-Reply-To: from "Stephen Kent" at Aug 18, 11 12:17:46 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: paul.hoffman@vpnc.org, dane@ietf.org Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 17:28:54 -0000 Stephen Kent wrote: > > At 5:00 PM +0200 8/18/11, Martin Rex wrote: > >... > > > >Ideally, self-signed end-entity certs should be X.509v1 certs. > >> > >> Since PKIX has deprecated v1 certs for many years, I find it hard to agree > >> with the term "ideally" :-). > > > > > >On the contrary, it really is "ideally". The newer PKIX specifications > >(X.509-2008 and rfc5280) explicitly do _NOT_ apply to self-signed end-entity > >certs, so the deprecation does *NOT* apply to self-signed X.509v1 EE certs. > > Self-signed v1 certs are deprecated along with all other v1 certs, period. I know you do not like self-signed end-entity certs, but exhibiting ostrich-like behaviour is not going to make them go away. The ISO X.509 and PKIX inaction seem to have caused a significant fraction of the installed base to move from X.509v1 self-signed EE certs to X.509v3 EE certs, and thereby making the situation worse. The the principal three options for self-signed non-CA certs: 1.) self-signed X.509v1 2.) self-signed X.509v3 non-CA 3.) self-signed X.509v3 Basic Constraint "allowed to act as CA=TRUE" (2) is explicitly excluded by X.509-2008 and therefore from any profile based on X.509v3, such as PKIX (rfc5280). (1) is based on an old X.509 standard and basically still works fine (3) is indistinguishable from a rootCA by X.509-2008 and PKIX/rfc5280 with all the ramification this has on trust anchor management. It would be sensible to use (1) exclusively for self-signed end-entity certs, because it is fairly simple and straightforward to account for this in the certificate path validation algorithm and ensure that X.509v1 are no longer acceptable as signers of _other_ certs. > > The publication of 2459 (in 1999), 3280 (in 2002) and 5280 (2008) all > provide a profile for v3 certs, and thus deprecate v1 certs. V1 > certs were profiled for use in the Internet in RFC 1422 (1993). X.509-2008 makes it very clear that this deprecation does NOT apply to non-CA issued X.509 certificates, and that is inherited by every profile of X.509. So no, there was no such deprecation for self-signed non-CA certs at all. > > Also, I anticipate that the 5280 clarifications doc, will have text > clarifying the status of self-signed v3 certs. I would be much more interested in a specification that describes what self-signed non-CA X.509 certificates should look like and how they should be dealt with in specifications -- to make all those tools that are currently creating such beasts as X.509v3 certs no longer work in an undefined fantasy land. Since rfc5280 limits itself very explicitly to being a profile of X.509v3 certs and X.509v2 CRLs, and X.509-2008 completely and clearly excludes non-CA selfsigned certs, such a change would require more than a few words of clarification, but a real document update. -Martin From hallam@gmail.com Thu Aug 18 10:48:32 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E544C11E80B7 for ; Thu, 18 Aug 2011 10:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.155 X-Spam-Level: X-Spam-Status: No, score=-3.155 tagged_above=-999 required=5 tests=[AWL=-0.156, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7s-LUTOWNb3 for ; Thu, 18 Aug 2011 10:48:32 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0A9F711E80BF for ; Thu, 18 Aug 2011 10:48:31 -0700 (PDT) Received: by gyf3 with SMTP id 3so1840145gyf.31 for ; Thu, 18 Aug 2011 10:49:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=h3EBlHbJWTy6wyiC9ThI6GlP7bmrx7x1YQjOV8fXlds=; b=eSYcCW2Nagu/uo/eh7dZV5/GqUd/hPHXToNi7S9KIgibz9Jv/vlinjPO6dphLpaT6S OaHzCH1zV/VEEmn5fBLnJEz4d04c5u4hCTQFidt8YST6L3mFnEsdGYlDgqIboIjf0m76 En+OF5xWGrRqCF2HajvzOWaFKrNqknYkNhKzk= MIME-Version: 1.0 Received: by 10.101.202.29 with SMTP id e29mr1046088anq.8.1313689764318; Thu, 18 Aug 2011 10:49:24 -0700 (PDT) Received: by 10.100.94.14 with HTTP; Thu, 18 Aug 2011 10:49:24 -0700 (PDT) In-Reply-To: <069.63b756414a8d964317fe74f502fd4d93@trac.tools.ietf.org> References: <060.d55c279a583dd38213fda7e1f7c9e46d@trac.tools.ietf.org> <069.63b756414a8d964317fe74f502fd4d93@trac.tools.ietf.org> Date: Thu, 18 Aug 2011 18:49:24 +0100 Message-ID: From: Phillip Hallam-Baker To: dane issue tracker Content-Type: multipart/alternative; boundary=0016e6d27cc9bf4f7c04aacb3be5 Cc: draft-ietf-dane-protocol@tools.ietf.org, paul.hoffman@vpnc.org, dane@ietf.org Subject: Re: [dane] #31: Multiple TLSA records in a response X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 18 Aug 2011 17:48:33 -0000 --0016e6d27cc9bf4f7c04aacb3be5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Should probably add in a caution here to the effect that if the number of records returned is prohibitively large, clients and middleboxen may not accept the response (possible DoS attack). So publishers of records should probably use the cert signing approach there. On Wed, Aug 17, 2011 at 4:43 PM, dane issue tracker < trac+dane@trac.tools.ietf.org> wrote: > #31: Multiple TLSA records in a response > > > Comment(by paul.hoffman@=85): > > Proposal: in section 4.4, add a short paragraph that says "A domain name > can have more than one TLSA record. A typical use for multiple TLSA > records would be when the site is changing from one certificate to > another. If a DNS response contains multiple TLSA records, any record fr= om > the set returned can be used to make certificate associations." > > -- > > -----------------------------------+-------------------------------------= --- > Reporter: paul.hoffman@=85 | Owner: > draft-ietf-dane-protocol@=85 > Type: defect | Status: new > Priority: major | Milestone: > Component: protocol | Version: > Severity: - | Keywords: > > -----------------------------------+-------------------------------------= --- > > Ticket URL: > dane > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > --=20 Website: http://hallambaker.com/ --0016e6d27cc9bf4f7c04aacb3be5 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Should probably add in a caution here to the effect that if the number of r= ecords returned is prohibitively large, clients and middleboxen may not acc= ept the response (possible DoS attack). So publishers of records should pro= bably use the cert signing approach there.

On Wed, Aug 17, 2011 at 4:43 PM, dane issue = tracker <trac+dane@trac.tools.ietf.org> wrote:
#31: Multiple TLSA records in a response


Comment(by paul.hoffman@=85):

=A0Proposal: in section 4.4, add a short paragraph that says "A domain= name
=A0can have more than one TLSA record. A typical use for multiple TLSA
=A0records would be when the site is changing from one certificate to
=A0another. If a DNS response contains multiple TLSA records, any record fr= om
=A0the set returned can be used to make certificate associations."

--
-----------------------------------+---------------------------------------= -
=A0Reporter: =A0paul.hoffman@=85 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 Owner: =A0dr= aft-ietf-dane-protocol@=85
=A0 =A0 Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0Statu= s: =A0new
=A0Priority: =A0major =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 Milestone: Component: =A0protocol =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 Version:
=A0Severity: =A0- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0Keywo= rds:
-----------------------------------+---------------------------------------= -

Ticket URL: <http://trac.tools.ietf.org/wg/dane/tra= c/ticket/31#comment:1>
dane <http://tools.ietf.org/dane/>

_______________________________________________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane



--
= Website: http://hallambaker.com/
--0016e6d27cc9bf4f7c04aacb3be5-- From rbarnes@bbn.com Thu Aug 18 11:45:52 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E68621F8BE7 for ; Thu, 18 Aug 2011 11:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.533 X-Spam-Level: X-Spam-Status: No, score=-106.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnC4CX47ka3C for ; Thu, 18 Aug 2011 11:45:51 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id D584221F8BDC for ; Thu, 18 Aug 2011 11:45:51 -0700 (PDT) Received: from ros-dhcp192-1-51-76.bbn.com ([192.1.51.76]:53763) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Qu7c5-000Buh-US; Thu, 18 Aug 2011 14:46:46 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Thu, 18 Aug 2011 14:46:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2369D32C-0DEA-4112-AA87-428E675EDA46@bbn.com> References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> <54C1B56E-7673-4F32-8E7B-25959C121A03@bbn.com> To: Paul Hoffman X-Mailer: Apple Mail (2.1082) Cc: dane issue tracker , DANE WG Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 18 Aug 2011 18:45:52 -0000 Those are precisely the conditions in the use case document, in sections = 3.1, 3.2, and 3.3. (3.4 is a more detailed case covered by the others) =20= The major difference is "IF" versus "ONLY IF": The first two cases = specify an additional constraint on certificate validation; they do not = require the RP to accept a cert. The third case requires the RP to = accept a cert that chains to a matching cert; in effect, a matching cert = is regarded as a trust anchor. The first two differ in that for (0), any cert in the chain can match, = while for (1) the service cert *itself* must match. =20 Consider two cases: Well-known CA ---> EE Service Cert This case would be accepted by types (0), pointing to the CA, and type = (1), pointing to the EE cert, as long as the CA is a trust anchor for = the RP. This case would be accepted by type (2), pointing to either = cert, regardless of the RP's trust anchor selection. Private CA ---> EE Service Cert This case would be rejected by types (0) and (1), since the RP would not = have the CA as a trust anchor. This case would be accepted by type (2), = pointing to either cert. So the distinctions are=20 1. Whether PKIX validation and chaining to a trust anchor are done (0,1, = not 2) 2. Whether the constraint has to match the service cert itself (not 0, = 1, not 2) --Richard On Aug 18, 2011, at 10:36 AM, Paul Hoffman wrote: > On Aug 17, 2011, at 5:57 PM, Richard L. Barnes wrote: >=20 >> Association Type: >> 0. Service cert should be accepted ONLY IF matching cert is in cert = chain >> 1. Service cert should be accepted ONLY IF it matches=20 >> 2. Service cert should be accepted IF any cert in the chain matches >=20 > I don't understand this list: they all seem the same. Can you give = examples where each is different? >=20 > --Paul Hoffman >=20 From bmanning@karoshi.com Thu Aug 18 13:26:06 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AED21F0C3D for ; Thu, 18 Aug 2011 13:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.93 X-Spam-Level: X-Spam-Status: No, score=-4.93 tagged_above=-999 required=5 tests=[AWL=-1.035, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yS04BvbwQhoE for ; Thu, 18 Aug 2011 13:26:04 -0700 (PDT) Received: from vacation.karoshi.com (unknown [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id 80A5E21F8A7D for ; Thu, 18 Aug 2011 13:25:59 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id p7HIZrCD020093; Wed, 17 Aug 2011 18:35:54 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id p7HIZr9W020092; Wed, 17 Aug 2011 18:35:53 GMT Date: Wed, 17 Aug 2011 18:35:53 +0000 From: bmanning@vacation.karoshi.com To: "Richard L. Barnes" Message-ID: <20110817183553.GA19852@vacation.karoshi.com.> References: <70F5FD47-8862-4A4C-84AE-BC7708AB50C2@bbn.com> <9103D852-36CE-462D-8306-0B348B4FE4F0@bbn.com> <20110817051226.GB17498@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: User-Agent: Mutt/1.4.1i Cc: bmanning@vacation.karoshi.com, DANE WG Subject: Re: [dane] Protocol / port numbers as prefix X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 18 Aug 2011 20:26:06 -0000 er... 16 bits sez the spec -allows- up to 65536 RR 's in an RRset. =20 so Phillip is incorrect in his statement that "the DNS does not really all= ow for 65536 RRs in the same node" - if I parse "same node" as single RRset. /bill On Wed, Aug 17, 2011 at 07:59:30AM -0400, Richard L. Barnes wrote: > Can't by spec: The "number of answer RRs" field in DNS responses is only= 16 bits wide, so there can only be 65536 RRs in the answer. >=20 > --Richard >=20 >=20 > On Aug 17, 2011, at 1:12 AM, bmanning@vacation.karoshi.com wrote: >=20 > > can't by spec or implementations have set an artifical boundary? > >=20 > > (of course I'd not want to see the path to TCP delivery for large RRsets > > become commonplace... but does one -require- a full enumeration of all= =20 > > ports at each RRset?) > >=20 > > /bill > >=20 > > On Tue, Aug 16, 2011 at 04:56:21PM +0100, Phillip Hallam-Baker wrote: > >> The problem then is that DNS does not really allow for 65536 RRs in th= e same > >> node. So it does not work out the way people think. > >>=20 > >> I still think people are going to be getting rather a shock when they = try to > >> deploy for large Web farms. Google certainly can't use this for > >> https://www.google.com/. > >>=20 > >> On Tue, Aug 16, 2011 at 4:46 PM, Richard L. Barnes w= rote: > >>=20 > >>> Ah, there it is. I was just summarizing because I hadn't found a rec= ord of > >>> this debate having happened. Consider my comment withdrawn. > >>>=20 > >>> --Richard > >>>=20 > >>>=20 > >>> On Aug 16, 2011, at 11:26 AM, OndE=19ej SurC=3D wrote: > >>>=20 > >>>> On 16. 8. 2011, at 16:11, Richard L. Barnes wrote: > >>>>> It is clearly causing some people discomfort to have protocols and = port > >>> numbers as prefixes. Why not just push them into the RRDATA and prov= ision > >>> the TLSA directly under the affected name? > >>>>=20 > >>>>=20 > >>>> Hi Richard, > >>>>=20 > >>>> I would like to point out that we already had this discussion (at le= ast > >>> once): > >>>>=20 > >>>> http://trac.tools.ietf.org/wg/dane/trac/ticket/1 > >>>>=20 > >>>> and here is the mail thread: > >>>>=20 > >>>> http://www.ietf.org/mail-archive/web/keyassure/current/msg01631.html > >>>>=20 > >>>> While I don't have a problem reopening the issue if that's what > >>>> the WG wants I would prefer to not reiterate the same issues > >>>> again and again unless you (all) at least read the mailing list > >>>> archives. > >>>>=20 > >>>> Thanks, > >>>> O. > >>>>=20 > >>>> -- > >>>> OndE=19ej SurC=3D > >>>> vedoucC- vC=3Dzkumu/Head of R&D department > >>>> ------------------------------------------- > >>>> CZ.NIC, z.s.p.o. -- LaboratoE=19e CZ.NIC > >>>> Americka 23, 120 00 Praha 2, Czech Republic > >>>> mailto:ondrej.sury@nic.cz http://nic.cz/ > >>>> tel:+420.222745110 fax:+420.222745112 > >>>> ------------------------------------------- > >>>>=20 > >>>=20 > >>> _______________________________________________ > >>> dane mailing list > >>> dane@ietf.org > >>> https://www.ietf.org/mailman/listinfo/dane > >>>=20 > >>=20 > >>=20 > >>=20 > >> --=20 > >> Website: http://hallambaker.com/ > >=20 > >> _______________________________________________ > >> dane mailing list > >> dane@ietf.org > >> https://www.ietf.org/mailman/listinfo/dane > >=20 >=20 From bmanning@karoshi.com Thu Aug 18 13:26:06 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27CBB21F8A7D for ; Thu, 18 Aug 2011 13:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.899 X-Spam-Level: X-Spam-Status: No, score=-4.899 tagged_above=-999 required=5 tests=[AWL=-1.004, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5HYb9FXyBhb for ; Thu, 18 Aug 2011 13:26:05 -0700 (PDT) Received: from vacation.karoshi.com (unknown [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id E2AC01F0C3C for ; Thu, 18 Aug 2011 13:26:04 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id p7H5CQCD018575; Wed, 17 Aug 2011 05:12:26 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id p7H5CQec018574; Wed, 17 Aug 2011 05:12:26 GMT Date: Wed, 17 Aug 2011 05:12:26 +0000 From: bmanning@vacation.karoshi.com To: Phillip Hallam-Baker Message-ID: <20110817051226.GB17498@vacation.karoshi.com.> References: <70F5FD47-8862-4A4C-84AE-BC7708AB50C2@bbn.com> <9103D852-36CE-462D-8306-0B348B4FE4F0@bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.1i Cc: DANE WG Subject: Re: [dane] Protocol / port numbers as prefix X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 18 Aug 2011 20:26:06 -0000 can't by spec or implementations have set an artifical boundary? (of course I'd not want to see the path to TCP delivery for large RRsets become commonplace... but does one -require- a full enumeration of all ports at each RRset?) /bill On Tue, Aug 16, 2011 at 04:56:21PM +0100, Phillip Hallam-Baker wrote: > The problem then is that DNS does not really allow for 65536 RRs in the same > node. So it does not work out the way people think. > > I still think people are going to be getting rather a shock when they try to > deploy for large Web farms. Google certainly can't use this for > https://www.google.com/. > > On Tue, Aug 16, 2011 at 4:46 PM, Richard L. Barnes wrote: > > > Ah, there it is. I was just summarizing because I hadn't found a record of > > this debate having happened. Consider my comment withdrawn. > > > > --Richard > > > > > > On Aug 16, 2011, at 11:26 AM, OndEej SurC= wrote: > > > > > On 16. 8. 2011, at 16:11, Richard L. Barnes wrote: > > >> It is clearly causing some people discomfort to have protocols and port > > numbers as prefixes. Why not just push them into the RRDATA and provision > > the TLSA directly under the affected name? > > > > > > > > > Hi Richard, > > > > > > I would like to point out that we already had this discussion (at least > > once): > > > > > > http://trac.tools.ietf.org/wg/dane/trac/ticket/1 > > > > > > and here is the mail thread: > > > > > > http://www.ietf.org/mail-archive/web/keyassure/current/msg01631.html > > > > > > While I don't have a problem reopening the issue if that's what > > > the WG wants I would prefer to not reiterate the same issues > > > again and again unless you (all) at least read the mailing list > > > archives. > > > > > > Thanks, > > > O. > > > > > > -- > > > OndEej SurC= > > > vedoucC- vC=zkumu/Head of R&D department > > > ------------------------------------------- > > > CZ.NIC, z.s.p.o. -- LaboratoEe CZ.NIC > > > Americka 23, 120 00 Praha 2, Czech Republic > > > mailto:ondrej.sury@nic.cz http://nic.cz/ > > > tel:+420.222745110 fax:+420.222745112 > > > ------------------------------------------- > > > > > > > _______________________________________________ > > dane mailing list > > dane@ietf.org > > https://www.ietf.org/mailman/listinfo/dane > > > > > > -- > Website: http://hallambaker.com/ > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From pgut001@login01.cs.auckland.ac.nz Fri Aug 19 00:05:43 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01ABD5E8004 for ; Fri, 19 Aug 2011 00:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.594 X-Spam-Level: X-Spam-Status: No, score=-3.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GeZC1z9ywk87 for ; Fri, 19 Aug 2011 00:05:42 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id BEFF65E8003 for ; Fri, 19 Aug 2011 00:05:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1313737598; x=1345273598; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20mrex@sap.com|Subject:=20Re:=20[dane]=20#29:=20Requ est=20new=20Reference=20Type=20-=20Public=20Key|Cc:=20dan e@ietf.org|In-Reply-To:=20<201108181729.p7IHTZsl027659@fs 4113.wdf.sap.corp>|Message-Id:=20|Date:=20Fri,=2019=20Aug=202011=201 9:06:32=20+1200; bh=Uo9cBAI0PdbQJicOFZufuQLJWidqvAtKxCOsfXl2+L4=; b=p8+xGKNSRRwXoi73J7Ko2LVCdSmFYfKIdnpmtwuQ4SV83soth4XiV0qK D9o9ycqyoDazX5N7xxBykhk2x5lD8z5BcxlDgQkNas9D8XEbKhWGl1Dwo H8rR3ME5tN21NUJNafMjrYSHmdfmbIE4YCk7FYiz8uKA13cD/LKq+6YUo g=; X-IronPort-AV: E=Sophos;i="4.68,249,1312113600"; d="scan'208";a="79188927" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 19 Aug 2011 19:06:32 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QuJA0-00058y-Gs; Fri, 19 Aug 2011 19:06:32 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QuJA0-0003Ib-6G; Fri, 19 Aug 2011 19:06:32 +1200 From: Peter Gutmann To: mrex@sap.com In-Reply-To: <201108181729.p7IHTZsl027659@fs4113.wdf.sap.corp> Message-Id: Date: Fri, 19 Aug 2011 19:06:32 +1200 Cc: dane@ietf.org Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 19 Aug 2011 07:05:43 -0000 Martin Rex writes: >The ISO X.509 and PKIX inaction seem to have caused a significant fraction of >the installed base to move from X.509v1 self-signed EE certs to X.509v3 EE >certs, and thereby making the situation worse. I wrote a fairly comprehensive draft to deal with this more than ten years ago: http://www.cs.auckland.ac.nz/~pgut001/pubs/autonomous.txt The WG chair's reaction at the time was "we don't want to turn PKIX into PGP", so it was never published. It would be pretty trivial to change the dates on this and re-publish it as a draft. I tried doing this at the time by laundering it through alternative channels to bypass PKIX' resistance to it but was informed that the IETF would take a rather dim view of someone trying to do an end-run around a standards committee. >I would be much more interested in a specification that describes what self- >signed non-CA X.509 certificates should look like and how they should be >dealt with in specifications -- to make all those tools that are currently >creating such beasts as X.509v3 certs no longer work in an undefined fantasy >land. It was tried more than a decade ago, but PKIX seems really keen to keep living in their fantasy land. Peter. From kent@bbn.com Mon Aug 22 11:11:50 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3C2921F8AFC for ; Mon, 22 Aug 2011 11:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.608 X-Spam-Level: X-Spam-Status: No, score=-106.608 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iO5BlObPoYpV for ; Mon, 22 Aug 2011 11:11:50 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 32CCE21F8AF0 for ; Mon, 22 Aug 2011 11:11:47 -0700 (PDT) Received: from dhcp89-089-129.bbn.com ([128.89.89.129]:49168) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QvYzR-0002v1-CE; Mon, 22 Aug 2011 14:12:49 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <201108181729.p7IHTZsl027659@fs4113.wdf.sap.corp> References: <201108181729.p7IHTZsl027659@fs4113.wdf.sap.corp> Date: Mon, 22 Aug 2011 14:12:44 -0400 To: mrex@sap.com From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: paul.hoffman@vpnc.org, dane@ietf.org Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 22 Aug 2011 18:11:50 -0000 At 7:29 PM +0200 8/18/11, Martin Rex wrote: >Stephen Kent wrote: >> >> At 5:00 PM +0200 8/18/11, Martin Rex wrote: >> >... >> > > >Ideally, self-signed end-entity certs should be X.509v1 certs. >> >> >> >> Since PKIX has deprecated v1 certs for many years, I find it >>hard to agree >> >> with the term "ideally" :-). >> > >> > >> >On the contrary, it really is "ideally". The newer PKIX specifications >> >(X.509-2008 and rfc5280) explicitly do _NOT_ apply to self-signed >>end-entity >> >certs, so the deprecation does *NOT* apply to self-signed X.509v1 EE certs. >> >> Self-signed v1 certs are deprecated along with all other v1 certs, period. > >I know you do not like self-signed end-entity certs, but exhibiting >ostrich-like behaviour is not going to make them go away. I was not addressing the broader topic of self-signed EE certs. I was addressing the narrower topic of the status of X.509 v1 certs in the IETF. As for self-signed v3 certs, Sean Turner and I discussed this, and he agrees that text will be added to the 5280 update/calcifications I-D to cover this topic. I will suggest that we clarify the status of v1 certs at the same time. Steve From ajs@anvilwalrusden.com Mon Aug 22 14:52:46 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B13D821F8C8B for ; Mon, 22 Aug 2011 14:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hT2X44TrBrK9 for ; Mon, 22 Aug 2011 14:52:46 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 256A721F8B01 for ; Mon, 22 Aug 2011 14:52:46 -0700 (PDT) Received: from shinkuro.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id C6CE71ECB41D for ; Mon, 22 Aug 2011 21:53:52 +0000 (UTC) Date: Mon, 22 Aug 2011 17:53:51 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20110822215351.GJ46378@shinkuro.com> References: <004d01cc5ba6$a5927780$f0b76680$@augustcellars.com> <20110816133458.GB14894@vacation.karoshi.com.> <00b301cc5c4b$79878950$6c969bf0$@augustcellars.com> <20110816225851.GD14894@vacation.karoshi.com.> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110816225851.GD14894@vacation.karoshi.com.> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Adding a new appendix section A.1.4 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 22 Aug 2011 21:52:46 -0000 On Tue, Aug 16, 2011 at 10:58:51PM +0000, bmanning@vacation.karoshi.com wrote: > or are you suggesting something like this:: > > example.net. in soa ( ); > > in ns foo > in ns bar > ; > bill in a 127.0.53.12 > in tlsa [bill-goop] > ; > jim in soa ( ); > jim.example.com. in ns tick > in ns tock > in tlsa [jim-goop] > ; > $ORIGIN example.net. > paul in a 127.0.53.13 My reading of the thread is that the above is exactly what's being suggested. That is, it causes a delegation of jim.example.com away (although I think the .com is a typo, right? Shouldn't it be .net?) The confusion here is the "subtree" thing. You'll need glue on the parent side of this cut too, I expect, but then you'll be able to put the records you want on the child side, I should think, since the child is authoritative for the data. A -- Andrew Sullivan ajs@anvilwalrusden.com From paul.hoffman@vpnc.org Mon Aug 22 16:27:09 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0060821F8B17 for ; Mon, 22 Aug 2011 16:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcQVZWdUeQIx for ; Mon, 22 Aug 2011 16:27:08 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5019F21F8B15 for ; Mon, 22 Aug 2011 16:27:08 -0700 (PDT) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p7MNS8Z7082101 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 22 Aug 2011 16:28:09 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <54C1B56E-7673-4F32-8E7B-25959C121A03@bbn.com> Date: Mon, 22 Aug 2011 16:28:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <91A5DF74-6DCB-4530-96A4-46786AB62FCB@vpnc.org> References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> <54C1B56E-7673-4F32-8E7B-25959C121A03@bbn.com> To: DANE WG X-Mailer: Apple Mail (2.1244.3) Cc: dane issue tracker Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 22 Aug 2011 23:27:09 -0000 On Aug 17, 2011, at 5:57 PM, Richard L. Barnes wrote: > This suggestion seems to be missing the point. You're still = conflating the identifier for a certificate for how it's used. Suggest = the following taxonomy, which aligns much better with the use cases: >=20 > Association Type: > 0. Service cert should be accepted ONLY IF matching cert is in cert = chain > 1. Service cert should be accepted ONLY IF it matches=20 > 2. Service cert should be accepted IF any cert in the chain matches >=20 > Reference Type: > 0. X.509 certificate (match(cert) =3D byte-wise equality) > 1. SubjectPublicKeyInfo structure (match(cert) =3D SPKI in cert) > *. Digest of X.509 certificate > *. Digest of SubjectPublicKeyInfo After a bit of off-list discussion with Richard, we came up with some = rewording for his association types that make them clearer: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Service Certificate: The first certificate in the TLS Server Certificate = message, that is, the certificate whose public key is used for TLS key = negotiation. 0. The service certificate MUST pass standard PKIX validation (including = chaining to a trust anchor), and MUST chain to or through a CA = certificate matching the TLSA record 1. The service certificate MUST pass standard PKIX validation (including = chaining to a trust anchor), and MUST match the TLSA record 2. The service certificate MUST pass standard PKIX validation, with any = certificate matching the TLSA record considered to be a trust anchor for = this validation =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D After some thought, I like Richard's proposal very much. It puts the = requirements for PKIX validation in the types definition, and makes it = clear right there what is being matched. I note that it is very different than the proposal that I put forward = last week: > On Aug 16, 2011, at 11:20 PM, Paul Hoffman wrote: >=20 >> When talking with Jim, we realized that the issue is raising here is = a confluence of two things: >> - He wants to be able to restrict the role that the cert or public = key can be used in (trust anchor, intermediate CA, end entity) >> - The current names for the two fields in record don't reflect their = actual use >>=20 >> The tentative proposal we came up with also has two parts: >>=20 >> - Instead of just three types: >> 1 -- A PKIX certificate that identifies an end entity >> 2 -- A PKIX certification authority's certificate >> 3 -- A public key expressed as a PKIX SubjectPublicKeyInfo = structure >> There should be six: >> n -- A PKIX certificate that identifies an end entity >> n+1 -- A PKIX certification authority's certificate that identifies a = trust anchor >> n+2 -- A PKIX certification authority's certificate that identifies = an intermediate CA >> n+3 -- A public key expressed as a PKIX SubjectPublicKeyInfo = structure that identifies a trust anchor >> n+4 -- A public key expressed as a PKIX SubjectPublicKeyInfo = structure that identifies an intermediate CA >> n+5 -- A public key expressed as a PKIX SubjectPublicKeyInfo = structure that identifies an end entity >>=20 >> - Instead of "Certificate Type" and "Reference Type", we need words = that define the fields' roles better. A first guess would be = "Restriction Type" and "Matching Type", but there could easily be better = words. >>=20 So, I guess the question splits into three (or more) possibilities. Keep = the current wording, go with my earlier proposed split (based on Jim's = suggestion), or go with Richard's very different proposal. --Paul Hoffman From rbarnes@bbn.com Tue Aug 23 06:10:29 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EBA321F8AD3 for ; Tue, 23 Aug 2011 06:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.565 X-Spam-Level: X-Spam-Status: No, score=-106.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TFsonHS2EiVn for ; Tue, 23 Aug 2011 06:10:29 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id E777F21F8574 for ; Tue, 23 Aug 2011 06:10:28 -0700 (PDT) Received: from dhcp89-089-029.bbn.com ([128.89.89.29]:49814) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QvqlU-000E9f-72; Tue, 23 Aug 2011 09:11:36 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <91A5DF74-6DCB-4530-96A4-46786AB62FCB@vpnc.org> Date: Tue, 23 Aug 2011 09:11:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> <54C1B56E-7673-4F32-8E7B-25959C121A03@bbn.com> <91A5DF74-6DCB-4530-96A4-46786AB62FCB@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1082) Cc: dane issue tracker , DANE WG Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 23 Aug 2011 13:10:29 -0000 Thanks to Paul for summarizing our discussion. One clarification: Along = with the three criteria below, which correspond to "usages" or "cert = types", there would still be a set of ways to reference a certificate = (RefTypes), of the character described below. The cert itself, a = SubjectPublicKeyInfo structure, digests of these, etc. --Richard On Aug 22, 2011, at 7:28 PM, Paul Hoffman wrote: >=20 > On Aug 17, 2011, at 5:57 PM, Richard L. Barnes wrote: >=20 >> This suggestion seems to be missing the point. You're still = conflating the identifier for a certificate for how it's used. Suggest = the following taxonomy, which aligns much better with the use cases: >>=20 >> Association Type: >> 0. Service cert should be accepted ONLY IF matching cert is in cert = chain >> 1. Service cert should be accepted ONLY IF it matches=20 >> 2. Service cert should be accepted IF any cert in the chain matches >>=20 >> Reference Type: >> 0. X.509 certificate (match(cert) =3D byte-wise equality) >> 1. SubjectPublicKeyInfo structure (match(cert) =3D SPKI in cert) >> *. Digest of X.509 certificate >> *. Digest of SubjectPublicKeyInfo >=20 > After a bit of off-list discussion with Richard, we came up with some = rewording for his association types that make them clearer: >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Service Certificate: The first certificate in the TLS Server = Certificate message, that is, the certificate whose public key is used = for TLS key negotiation. >=20 > 0. The service certificate MUST pass standard PKIX validation = (including chaining to a trust anchor), and MUST chain to or through a = CA certificate matching the TLSA record >=20 > 1. The service certificate MUST pass standard PKIX validation = (including chaining to a trust anchor), and MUST match the TLSA record >=20 > 2. The service certificate MUST pass standard PKIX validation, with = any certificate matching the TLSA record considered to be a trust anchor = for this validation > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > After some thought, I like Richard's proposal very much. It puts the = requirements for PKIX validation in the types definition, and makes it = clear right there what is being matched. >=20 > I note that it is very different than the proposal that I put forward = last week: >=20 >> On Aug 16, 2011, at 11:20 PM, Paul Hoffman wrote: >>=20 >>> When talking with Jim, we realized that the issue is raising here is = a confluence of two things: >>> - He wants to be able to restrict the role that the cert or public = key can be used in (trust anchor, intermediate CA, end entity) >>> - The current names for the two fields in record don't reflect their = actual use >>>=20 >>> The tentative proposal we came up with also has two parts: >>>=20 >>> - Instead of just three types: >>> 1 -- A PKIX certificate that identifies an end entity >>> 2 -- A PKIX certification authority's certificate >>> 3 -- A public key expressed as a PKIX SubjectPublicKeyInfo = structure >>> There should be six: >>> n -- A PKIX certificate that identifies an end entity >>> n+1 -- A PKIX certification authority's certificate that identifies = a trust anchor >>> n+2 -- A PKIX certification authority's certificate that identifies = an intermediate CA >>> n+3 -- A public key expressed as a PKIX SubjectPublicKeyInfo = structure that identifies a trust anchor >>> n+4 -- A public key expressed as a PKIX SubjectPublicKeyInfo = structure that identifies an intermediate CA >>> n+5 -- A public key expressed as a PKIX SubjectPublicKeyInfo = structure that identifies an end entity >>>=20 >>> - Instead of "Certificate Type" and "Reference Type", we need words = that define the fields' roles better. A first guess would be = "Restriction Type" and "Matching Type", but there could easily be better = words. >>>=20 >=20 > So, I guess the question splits into three (or more) possibilities. = Keep the current wording, go with my earlier proposed split (based on = Jim's suggestion), or go with Richard's very different proposal. >=20 > --Paul Hoffman >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From warren@kumari.net Tue Aug 23 08:29:02 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4C2E21F8B7F for ; Tue, 23 Aug 2011 08:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.439 X-Spam-Level: X-Spam-Status: No, score=-102.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WR+B-T2pNaR for ; Tue, 23 Aug 2011 08:29:02 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 2C76821F8B78 for ; Tue, 23 Aug 2011 08:29:02 -0700 (PDT) Received: from dhcp-172-19-118-113.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 98B661B416FF; Tue, 23 Aug 2011 11:30:09 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Warren Kumari Date: Tue, 23 Aug 2011 11:30:07 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5A597342-BE70-4DFD-B113-2B881C9BF25A@kumari.net> References: <20110822223218.94D9E21F8BF9@ietfa.amsl.com> To: dane@ietf.org X-Mailer: Apple Mail (2.1084) Subject: [dane] Fwd: Nomcom 2011-2012: Call for Nominations X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 23 Aug 2011 15:29:02 -0000 [ Incase you didn't see this on the Discuss list ]=20 Hi all, The NomCom is seeking nominations for a number of positions -- if you = know of anyone who would be a great fit, please nominate them. The NomCom serves a very important (and unfun) role, lets try make this = easy for them... W Begin forwarded message: > From: NomCom Chair > Date: August 22, 2011 6:32:18 PM EDT > To: IETF Announcement list > Cc: ietf@ietf.org > Subject: Nomcom 2011-2012: Call for Nominations=20 >=20 > Hi All, >=20 > The 2011-2012 Nominating committee is seeking nominations from now=20 > until October 2, 2011. The list of open positions can be found at: >=20 > https://www.ietf.org/group/nomcom/2011/ >=20 > Nominations may be made directly on the NomCom 2011-2012 pages by=20 > selecting the Nominate link at the top of the page. The URL for > NomCom 2011-2012 pages is:=20 >=20 > https://www.ietf.org/group/nomcom/2011/ >=20 > Nominations may also be made by email to nomcom11@ietf.org. > If you do so, please include the word "Nominate" in the Subject and=20 > indicate in the email who is being nominated, their email address (to > confirm acceptance of the nomination), and the position for which you=20= > are making the nomination. If you wish to nominate someone via email=20= > for more than one position, please use separate emails to do so. >=20 > Self nomination is welcome.=20 >=20 > NomCom 2011-2012 will follow the policy for "Open Disclosure of = Willing=20 > Nominees" described in RFC 5680. As stated in RFC 5680: "The list of=20= > nominees willing to be considered for positions under review in the=20 > current NomCom cycle is not confidential". Willing Nominees for each=20= > position will be publicly listed. The public nominee list will be=20 > updated at least once a week and possibly more often as nominations = are=20 > received. >=20 > With the exception of publicly listing willing nominees, the=20 > confidentiality requirements of RFC 3777 remain in effect. All=20 > feedback and NomCom deliberations will remain confidential and not=20 > disclosed.=20 >=20 > Because the list of nominees this year is public, we will accept=20 > feedback on the nominees starting August 23, 2011. Per RFC 5680, we=20 > will accept feedback from the entire IETF community on all the = nominees.=20 >=20 > If you wish to provide anonymous feedback, the chair or any of the=20 > members will be happy to handle this for you. The Nominating = Committee=20 > chair can be reached at nomcom-chair@ietf.org and the entire = nominating=20 > committee can be reached at nomcom11@ietf.org. The email addresses of=20= > individual NomCom members is also on the NomCom 2011-2012 pages. >=20 > In addition to nominations, the Nominating Committee is actively > seeking community input on the jobs that need to be filled. We have > received the job descriptions from the IAB, IESG, and IAOC and they = can > be found at: >=20 > https://www.ietf.org/group/nomcom/2011/iab-requirements > https://www.ietf.org/group/nomcom/2011/iesg-requirements > https://www.ietf.org/group/nomcom/2011/iaoc-requirements >=20 > However, we also need the community's views and input on the jobs=20 > within each organization. If you have ideas on job responsibilities=20 > (more, less, different), please let us know. Please send suggestions=20= > and feedback to nomcom11@ietf.org.=20 >=20 > Thank you, >=20 > Suresh Krishnan > Chair, NomCom 2011-2012 > nomcom-chair@ietf.org > suresh.krishnan@ericsson.com > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce >=20 From ietf@augustcellars.com Tue Aug 23 11:49:37 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42E4021F8C3F for ; Tue, 23 Aug 2011 11:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKGRBbtHfIyi for ; Tue, 23 Aug 2011 11:49:36 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id C966D21F8C61 for ; Tue, 23 Aug 2011 11:49:35 -0700 (PDT) Received: from TITUS (176.120.168.69.static.onlinenw.com [69.168.120.176]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id F175F2CA23; Tue, 23 Aug 2011 11:50:43 -0700 (PDT) From: "Jim Schaad" To: "'Paul Hoffman'" , "'DANE WG'" References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> <54C1B56E-7673-4F32-8E7B-25959C121A03@bbn.com> <91A5DF74-6DCB-4530-96A4-46786AB62FCB@vpnc.org> In-Reply-To: <91A5DF74-6DCB-4530-96A4-46786AB62FCB@vpnc.org> Date: Tue, 23 Aug 2011 12:25:49 -0700 Message-ID: <008e01cc61ca$7748ce90$65da6bb0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQHwXbPL2/IzPDFsf9e9Pk9vZhBFJQMMON3xAq/8BzAA6q5ZtJStoimg Cc: 'dane issue tracker' Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 23 Aug 2011 18:49:37 -0000 > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of > Paul Hoffman > Sent: Monday, August 22, 2011 4:28 PM > To: DANE WG > Cc: dane issue tracker > Subject: Re: [dane] #29: Request new Reference Type - Public Key > > > On Aug 17, 2011, at 5:57 PM, Richard L. Barnes wrote: > > > This suggestion seems to be missing the point. You're still conflating the > identifier for a certificate for how it's used. Suggest the following taxonomy, > which aligns much better with the use cases: > > > > Association Type: > > 0. Service cert should be accepted ONLY IF matching cert is in cert > > chain 1. Service cert should be accepted ONLY IF it matches 2. Service > > cert should be accepted IF any cert in the chain matches > > > > Reference Type: > > 0. X.509 certificate (match(cert) = byte-wise equality) 1. > > SubjectPublicKeyInfo structure (match(cert) = SPKI in cert) *. Digest > > of X.509 certificate *. Digest of SubjectPublicKeyInfo > > After a bit of off-list discussion with Richard, we came up with some > rewording for his association types that make them clearer: > > ========== > Service Certificate: The first certificate in the TLS Server Certificate message, > that is, the certificate whose public key is used for TLS key negotiation. > > 0. The service certificate MUST pass standard PKIX validation (including > chaining to a trust anchor), and MUST chain to or through a CA certificate > matching the TLSA record I have a little bit of an issue with saying that it can chain "to" a CA certificate. It would imply that this certificate is at the "root" of the certificate chain and thus would be a trust anchor. Is this the intent? Jim > > 1. The service certificate MUST pass standard PKIX validation (including > chaining to a trust anchor), and MUST match the TLSA record > > 2. The service certificate MUST pass standard PKIX validation, with any > certificate matching the TLSA record considered to be a trust anchor for this > validation ========== > > After some thought, I like Richard's proposal very much. It puts the > requirements for PKIX validation in the types definition, and makes it clear > right there what is being matched. > > I note that it is very different than the proposal that I put forward last week: > > > On Aug 16, 2011, at 11:20 PM, Paul Hoffman wrote: > > > >> When talking with Jim, we realized that the issue is raising here is a > confluence of two things: > >> - He wants to be able to restrict the role that the cert or public > >> key can be used in (trust anchor, intermediate CA, end entity) > >> - The current names for the two fields in record don't reflect their > >> actual use > >> > >> The tentative proposal we came up with also has two parts: > >> > >> - Instead of just three types: > >> 1 -- A PKIX certificate that identifies an end entity > >> 2 -- A PKIX certification authority's certificate > >> 3 -- A public key expressed as a PKIX SubjectPublicKeyInfo > >> structure There should be six: > >> n -- A PKIX certificate that identifies an end entity > >> n+1 -- A PKIX certification authority's certificate that identifies a > >> n+trust anchor > >> n+2 -- A PKIX certification authority's certificate that identifies > >> n+an intermediate CA > >> n+3 -- A public key expressed as a PKIX SubjectPublicKeyInfo > >> n+structure that identifies a trust anchor > >> n+4 -- A public key expressed as a PKIX SubjectPublicKeyInfo > >> n+structure that identifies an intermediate CA > >> n+5 -- A public key expressed as a PKIX SubjectPublicKeyInfo > >> n+structure that identifies an end entity > >> > >> - Instead of "Certificate Type" and "Reference Type", we need words that > define the fields' roles better. A first guess would be "Restriction Type" and > "Matching Type", but there could easily be better words. > >> > > So, I guess the question splits into three (or more) possibilities. Keep the > current wording, go with my earlier proposed split (based on Jim's > suggestion), or go with Richard's very different proposal. > > --Paul Hoffman > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From ietf@augustcellars.com Tue Aug 23 11:50:31 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE2B21F8C6B for ; Tue, 23 Aug 2011 11:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.819 X-Spam-Level: X-Spam-Status: No, score=-2.819 tagged_above=-999 required=5 tests=[AWL=-0.420, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehKUUg8iFYpf for ; Tue, 23 Aug 2011 11:50:30 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7E4C121F8C54 for ; Tue, 23 Aug 2011 11:50:30 -0700 (PDT) Received: from TITUS (176.120.168.69.static.onlinenw.com [69.168.120.176]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id C6E5A2CA28; Tue, 23 Aug 2011 11:51:38 -0700 (PDT) From: "Jim Schaad" To: "'Richard L. Barnes'" , "'Paul Hoffman'" References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> <54C1B56E-7673-4F32-8E7B-25959C121A03@bbn.com> <91A5DF74-6DCB-4530-96A4-46786AB62FCB@vpnc.org> In-Reply-To: Date: Tue, 23 Aug 2011 12:26:44 -0700 Message-ID: <008f01cc61ca$98125c90$c83715b0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQHwXbPL2/IzPDFsf9e9Pk9vZhBFJQMMON3xAq/8BzAA6q5ZtAFwOnZXlKIgoFA= Cc: 'DANE WG' , 'dane issue tracker' Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 23 Aug 2011 18:50:31 -0000 I am happier with the SubjectPublicKeyInfo being a RefType, but it should be noted this was not in Paul's original message. Paul, have you changed your mind on this issue? Jim > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of > Richard L. Barnes > Sent: Tuesday, August 23, 2011 6:11 AM > To: Paul Hoffman > Cc: dane issue tracker; DANE WG > Subject: Re: [dane] #29: Request new Reference Type - Public Key > > Thanks to Paul for summarizing our discussion. One clarification: Along with > the three criteria below, which correspond to "usages" or "cert types", there > would still be a set of ways to reference a certificate (RefTypes), of the > character described below. The cert itself, a SubjectPublicKeyInfo structure, > digests of these, etc. > > --Richard > > > > On Aug 22, 2011, at 7:28 PM, Paul Hoffman wrote: > > > > > On Aug 17, 2011, at 5:57 PM, Richard L. Barnes wrote: > > > >> This suggestion seems to be missing the point. You're still conflating the > identifier for a certificate for how it's used. Suggest the following taxonomy, > which aligns much better with the use cases: > >> > >> Association Type: > >> 0. Service cert should be accepted ONLY IF matching cert is in cert > >> chain 1. Service cert should be accepted ONLY IF it matches 2. > >> Service cert should be accepted IF any cert in the chain matches > >> > >> Reference Type: > >> 0. X.509 certificate (match(cert) = byte-wise equality) 1. > >> SubjectPublicKeyInfo structure (match(cert) = SPKI in cert) *. Digest > >> of X.509 certificate *. Digest of SubjectPublicKeyInfo > > > > After a bit of off-list discussion with Richard, we came up with some > rewording for his association types that make them clearer: > > > > ========== > > Service Certificate: The first certificate in the TLS Server Certificate > message, that is, the certificate whose public key is used for TLS key > negotiation. > > > > 0. The service certificate MUST pass standard PKIX validation > > (including chaining to a trust anchor), and MUST chain to or through a > > CA certificate matching the TLSA record > > > > 1. The service certificate MUST pass standard PKIX validation > > (including chaining to a trust anchor), and MUST match the TLSA record > > > > 2. The service certificate MUST pass standard PKIX validation, with > > any certificate matching the TLSA record considered to be a trust > > anchor for this validation ========== > > > > After some thought, I like Richard's proposal very much. It puts the > requirements for PKIX validation in the types definition, and makes it clear > right there what is being matched. > > > > I note that it is very different than the proposal that I put forward last > week: > > > >> On Aug 16, 2011, at 11:20 PM, Paul Hoffman wrote: > >> > >>> When talking with Jim, we realized that the issue is raising here is a > confluence of two things: > >>> - He wants to be able to restrict the role that the cert or public > >>> key can be used in (trust anchor, intermediate CA, end entity) > >>> - The current names for the two fields in record don't reflect their > >>> actual use > >>> > >>> The tentative proposal we came up with also has two parts: > >>> > >>> - Instead of just three types: > >>> 1 -- A PKIX certificate that identifies an end entity > >>> 2 -- A PKIX certification authority's certificate > >>> 3 -- A public key expressed as a PKIX SubjectPublicKeyInfo > >>> structure There should be six: > >>> n -- A PKIX certificate that identifies an end entity > >>> n+1 -- A PKIX certification authority's certificate that identifies > >>> n+a trust anchor > >>> n+2 -- A PKIX certification authority's certificate that identifies > >>> n+an intermediate CA > >>> n+3 -- A public key expressed as a PKIX SubjectPublicKeyInfo > >>> n+structure that identifies a trust anchor > >>> n+4 -- A public key expressed as a PKIX SubjectPublicKeyInfo > >>> n+structure that identifies an intermediate CA > >>> n+5 -- A public key expressed as a PKIX SubjectPublicKeyInfo > >>> n+structure that identifies an end entity > >>> > >>> - Instead of "Certificate Type" and "Reference Type", we need words > that define the fields' roles better. A first guess would be "Restriction Type" > and "Matching Type", but there could easily be better words. > >>> > > > > So, I guess the question splits into three (or more) possibilities. Keep the > current wording, go with my earlier proposed split (based on Jim's > suggestion), or go with Richard's very different proposal. > > > > --Paul Hoffman > > > > _______________________________________________ > > 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 paul.hoffman@vpnc.org Tue Aug 23 12:38:19 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2650F21F8B9C for ; Tue, 23 Aug 2011 12:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b703CRhOSD2k for ; Tue, 23 Aug 2011 12:38:18 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id A777E21F8B7F for ; Tue, 23 Aug 2011 12:38:18 -0700 (PDT) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p7NJdNBr013465 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 23 Aug 2011 12:39:24 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <008e01cc61ca$7748ce90$65da6bb0$@augustcellars.com> Date: Tue, 23 Aug 2011 12:39:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> <54C1B56E-7673-4F32-8E7B-25959C121A03@bbn.com> <91A5DF74-6DCB-4530-96A4-46786AB62FCB@vpnc.org> <008e01cc61ca$7748ce90$65da6bb0$@augustcellars.com> To: DANE WG X-Mailer: Apple Mail (2.1244.3) Cc: dane issue tracker Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 23 Aug 2011 19:38:19 -0000 On Aug 23, 2011, at 12:25 PM, Jim Schaad wrote: >> 0. The service certificate MUST pass standard PKIX validation = (including >> chaining to a trust anchor), and MUST chain to or through a CA = certificate >> matching the TLSA record >=20 > I have a little bit of an issue with saying that it can chain "to" a = CA > certificate. It would imply that this certificate is at the "root" of = the > certificate chain and thus would be a trust anchor. Is this the = intent? Saying that something chains to certificate X does not indicate that X = is at the root of a tree, nor that X is a trust anchor. For example: TA = -> Y -> X -> EE. If the TLSA record of type 0 here was X, X is not a = root or a trust anchor. --Paul Hoffman From paul.hoffman@vpnc.org Tue Aug 23 12:39:32 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AAAA21F8C35 for ; Tue, 23 Aug 2011 12:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k4OXgxxgXbmZ for ; Tue, 23 Aug 2011 12:39:31 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id B2CEE21F8C75 for ; Tue, 23 Aug 2011 12:39:31 -0700 (PDT) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p7NJedkg013870 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 23 Aug 2011 12:40:40 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <008f01cc61ca$98125c90$c83715b0$@augustcellars.com> Date: Tue, 23 Aug 2011 12:40:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <480C0497-1A28-4543-AE17-6DBE1AF1230E@vpnc.org> References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> <54C1B56E-7673-4F32-8E7B-25959C121A03@bbn.com> <91A5DF74-6DCB-4530-96A4-46786AB62FCB@vpnc.org> <008f01cc61ca$98125c90$c83715b0$@augustcellars.com> To: DANE WG X-Mailer: Apple Mail (2.1244.3) Cc: dane issue tracker Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 23 Aug 2011 19:39:32 -0000 On Aug 23, 2011, at 12:26 PM, Jim Schaad wrote: > I am happier with the SubjectPublicKeyInfo being a RefType, but it = should be > noted this was not in Paul's original message. Paul, have you changed = your > mind on this issue? If we go with Richard's taxonomy for association types, yes: making the = SubjectPublicKeyInfo be a reference type makes good sense. --Paul Hoffman From warren@kumari.net Tue Aug 23 13:35:47 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1285F21F89B8 for ; Tue, 23 Aug 2011 13:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.44 X-Spam-Level: X-Spam-Status: No, score=-102.44 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLhPU-iZmdDM for ; Tue, 23 Aug 2011 13:35:46 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3D821F8A97 for ; Tue, 23 Aug 2011 13:35:46 -0700 (PDT) Received: from dhcp-172-19-118-113.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 124C21B416FF; Tue, 23 Aug 2011 16:36:52 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <91A5DF74-6DCB-4530-96A4-46786AB62FCB@vpnc.org> Date: Tue, 23 Aug 2011 16:36:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5F91C397-05BE-4A8A-A5DD-B02B0A832C21@kumari.net> References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> <54C1B56E-7673-4F32-8E7B-25959C121A03@bbn.com> <91A5DF74-6DCB-4530-96A4-46786AB62FCB@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1084) Cc: dane issue tracker , DANE WG Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 23 Aug 2011 20:35:47 -0000 In order to help focus the discussions (and provide guidance to our = authors), I'm asking the WG to please indicate a preference for text = based on: 1: The current wording. 2: The proposed split (based upon Jim's suggestion ( = http://www.ietf.org/mail-archive/web/dane/current/msg03223.html )) 3: Richard's "very different" proposal (outlined below). I personally like #3 -- while it involves the largest amount of change, = I view it as the cleanest and (at least for me) easiest to understand, = especially from the "I'm just a monkey that operates a server" = standpoint.... W On Aug 22, 2011, at 7:28 PM, Paul Hoffman wrote: >=20 > On Aug 17, 2011, at 5:57 PM, Richard L. Barnes wrote: >=20 >> This suggestion seems to be missing the point. You're still = conflating the identifier for a certificate for how it's used. Suggest = the following taxonomy, which aligns much better with the use cases: >>=20 >> Association Type: >> 0. Service cert should be accepted ONLY IF matching cert is in cert = chain >> 1. Service cert should be accepted ONLY IF it matches=20 >> 2. Service cert should be accepted IF any cert in the chain matches >>=20 >> Reference Type: >> 0. X.509 certificate (match(cert) =3D byte-wise equality) >> 1. SubjectPublicKeyInfo structure (match(cert) =3D SPKI in cert) >> *. Digest of X.509 certificate >> *. Digest of SubjectPublicKeyInfo >=20 > After a bit of off-list discussion with Richard, we came up with some = rewording for his association types that make them clearer: >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Service Certificate: The first certificate in the TLS Server = Certificate message, that is, the certificate whose public key is used = for TLS key negotiation. >=20 > 0. The service certificate MUST pass standard PKIX validation = (including chaining to a trust anchor), and MUST chain to or through a = CA certificate matching the TLSA record >=20 > 1. The service certificate MUST pass standard PKIX validation = (including chaining to a trust anchor), and MUST match the TLSA record >=20 > 2. The service certificate MUST pass standard PKIX validation, with = any certificate matching the TLSA record considered to be a trust anchor = for this validation > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > After some thought, I like Richard's proposal very much. It puts the = requirements for PKIX validation in the types definition, and makes it = clear right there what is being matched. >=20 > I note that it is very different than the proposal that I put forward = last week: >=20 >> On Aug 16, 2011, at 11:20 PM, Paul Hoffman wrote: >>=20 >>> When talking with Jim, we realized that the issue is raising here is = a confluence of two things: >>> - He wants to be able to restrict the role that the cert or public = key can be used in (trust anchor, intermediate CA, end entity) >>> - The current names for the two fields in record don't reflect their = actual use >>>=20 >>> The tentative proposal we came up with also has two parts: >>>=20 >>> - Instead of just three types: >>> 1 -- A PKIX certificate that identifies an end entity >>> 2 -- A PKIX certification authority's certificate >>> 3 -- A public key expressed as a PKIX SubjectPublicKeyInfo = structure >>> There should be six: >>> n -- A PKIX certificate that identifies an end entity >>> n+1 -- A PKIX certification authority's certificate that identifies = a trust anchor >>> n+2 -- A PKIX certification authority's certificate that identifies = an intermediate CA >>> n+3 -- A public key expressed as a PKIX SubjectPublicKeyInfo = structure that identifies a trust anchor >>> n+4 -- A public key expressed as a PKIX SubjectPublicKeyInfo = structure that identifies an intermediate CA >>> n+5 -- A public key expressed as a PKIX SubjectPublicKeyInfo = structure that identifies an end entity >>>=20 >>> - Instead of "Certificate Type" and "Reference Type", we need words = that define the fields' roles better. A first guess would be = "Restriction Type" and "Matching Type", but there could easily be better = words. >>>=20 >=20 > So, I guess the question splits into three (or more) possibilities. = Keep the current wording, go with my earlier proposed split (based on = Jim's suggestion), or go with Richard's very different proposal. >=20 > --Paul Hoffman >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 From zack.weinberg@gmail.com Tue Aug 23 13:39:58 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F44021F8C75 for ; Tue, 23 Aug 2011 13:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id euYjd7dAMDHV for ; Tue, 23 Aug 2011 13:39:58 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id E354C21F8C72 for ; Tue, 23 Aug 2011 13:39:57 -0700 (PDT) Received: by gxk19 with SMTP id 19so479006gxk.31 for ; Tue, 23 Aug 2011 13:41:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=9SYVDdD/MyOHrTDCSvLDrr1kWYruOTn8cx2jP8pujGI=; b=WthbQxKGHb9cgxF2LToS+tAdDZpK+V2FHaWa2Pe6PmG+arsOBPchWd0W16DZbE6PSb CijtmrDCURPkEVPOblPAPxPbX923fLL9OHUYmr6em0XudnCgXe8Y/I7GUv0TcQzAoVlt KqrevSsmozZ2Y4n6xY9LuuQNaUMlKLElr1RaA= Received: by 10.101.160.27 with SMTP id m27mr4128142ano.74.1314132066286; Tue, 23 Aug 2011 13:41:06 -0700 (PDT) Received: from visnet-136.csl.sri.com (visnet-136.csl.sri.com [130.107.98.136]) by mx.google.com with ESMTPS id p34sm264675ann.17.2011.08.23.13.41.04 (version=SSLv3 cipher=OTHER); Tue, 23 Aug 2011 13:41:05 -0700 (PDT) Sender: Zack Weinberg Message-ID: <4E54105F.2050305@sv.cmu.edu> Date: Tue, 23 Aug 2011 13:41:03 -0700 From: Zack Weinberg User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: dane@ietf.org References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> <54C1B56E-7673-4F32-8E7B-25959C121A03@bbn.com> <91A5DF74-6DCB-4530-96A4-46786AB62FCB@vpnc.org> <5F91C397-05BE-4A8A-A5DD-B02B0A832C21@kumari.net> In-Reply-To: <5F91C397-05BE-4A8A-A5DD-B02B0A832C21@kumari.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 23 Aug 2011 20:39:58 -0000 On 2011-08-23 1:36 PM, Warren Kumari wrote: > In order to help focus the discussions (and provide guidance to our authors), I'm asking the WG to please indicate a preference for text based on: > > 1: The current wording. > > 2: The proposed split (based upon Jim's suggestion ( http://www.ietf.org/mail-archive/web/dane/current/msg03223.html )) > > 3: Richard's "very different" proposal (outlined below). 3 > 1 > 2 that is, I like Richard's proposal, but find Jim's suggestion more confusing than what we have now. zw From ietf@augustcellars.com Tue Aug 23 15:19:54 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE3C721F8D5E for ; Tue, 23 Aug 2011 15:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPQT7pqvUDef for ; Tue, 23 Aug 2011 15:19:54 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 514F221F8D63 for ; Tue, 23 Aug 2011 15:19:54 -0700 (PDT) Received: from TITUS (176.120.168.69.static.onlinenw.com [69.168.120.176]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 3404B2CA44; Tue, 23 Aug 2011 15:21:03 -0700 (PDT) From: "Jim Schaad" To: "'Paul Hoffman'" , "'DANE WG'" References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> <54C1B56E-7673-4F32-8E7B-25959C121A03@bbn.com> <91A5DF74-6DCB-4530-96A4-46786AB62FCB@vpnc.org> <008e01cc61ca$7748ce90$65da6bb0$@augustcellars.com> In-Reply-To: Date: Tue, 23 Aug 2011 15:56:08 -0700 Message-ID: <00a101cc61e7$d9348820$8b9d9860$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQHwXbPL2/IzPDFsf9e9Pk9vZhBFJQMMON3xAq/8BzAA6q5ZtAI1VgtCAfprM5iUjF8N4A== Cc: 'dane issue tracker' Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 23 Aug 2011 22:19:54 -0000 To me that is chains through X - the text is "chain to or through" Jim > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of > Paul Hoffman > Sent: Tuesday, August 23, 2011 12:39 PM > To: DANE WG > Cc: dane issue tracker > Subject: Re: [dane] #29: Request new Reference Type - Public Key > > On Aug 23, 2011, at 12:25 PM, Jim Schaad wrote: > > >> 0. The service certificate MUST pass standard PKIX validation > >> (including chaining to a trust anchor), and MUST chain to or through > >> a CA certificate matching the TLSA record > > > > I have a little bit of an issue with saying that it can chain "to" a > > CA certificate. It would imply that this certificate is at the "root" > > of the certificate chain and thus would be a trust anchor. Is this the intent? > > > Saying that something chains to certificate X does not indicate that X is at the > root of a tree, nor that X is a trust anchor. For example: TA -> Y -> X -> EE. If > the TLSA record of type 0 here was X, X is not a root or a trust anchor. > > --Paul Hoffman > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From ietf@augustcellars.com Tue Aug 23 15:20:19 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 914C421F8D6B for ; Tue, 23 Aug 2011 15:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.785 X-Spam-Level: X-Spam-Status: No, score=-2.785 tagged_above=-999 required=5 tests=[AWL=-0.386, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hOpaYldlRYzH for ; Tue, 23 Aug 2011 15:20:18 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id BB2C321F8D5E for ; Tue, 23 Aug 2011 15:20:18 -0700 (PDT) Received: from TITUS (176.120.168.69.static.onlinenw.com [69.168.120.176]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 8A53738F01; Tue, 23 Aug 2011 15:21:27 -0700 (PDT) From: "Jim Schaad" To: "'Warren Kumari'" , "'Paul Hoffman'" References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> <54C1B56E-7673-4F32-8E7B-25959C121A03@bbn.com> <91A5DF74-6DCB-4530-96A4-46786AB62FCB@vpnc.org> <5F91C397-05BE-4A8A-A5DD-B02B0A832C21@kumari.net> In-Reply-To: <5F91C397-05BE-4A8A-A5DD-B02B0A832C21@kumari.net> Date: Tue, 23 Aug 2011 15:56:33 -0700 Message-ID: <00a201cc61e7$e7b0e010$b712a030$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQHwXbPL2/IzPDFsf9e9Pk9vZhBFJQMMON3xAq/8BzAA6q5ZtAEt7WdelKRt3bA= Cc: 'DANE WG' , 'dane issue tracker' Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 23 Aug 2011 22:20:19 -0000 #3 > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of > Warren Kumari > Sent: Tuesday, August 23, 2011 1:37 PM > To: Paul Hoffman > Cc: dane issue tracker; DANE WG > Subject: Re: [dane] #29: Request new Reference Type - Public Key > > In order to help focus the discussions (and provide guidance to our authors), > I'm asking the WG to please indicate a preference for text based on: > > 1: The current wording. > > 2: The proposed split (based upon Jim's suggestion ( > http://www.ietf.org/mail-archive/web/dane/current/msg03223.html )) > > 3: Richard's "very different" proposal (outlined below). > > > > I personally like #3 -- while it involves the largest amount of change, I view it > as the cleanest and (at least for me) easiest to understand, especially from > the "I'm just a monkey that operates a server" standpoint.... > > W > > > > On Aug 22, 2011, at 7:28 PM, Paul Hoffman wrote: > > > > > On Aug 17, 2011, at 5:57 PM, Richard L. Barnes wrote: > > > >> This suggestion seems to be missing the point. You're still conflating the > identifier for a certificate for how it's used. Suggest the following taxonomy, > which aligns much better with the use cases: > >> > >> Association Type: > >> 0. Service cert should be accepted ONLY IF matching cert is in cert > >> chain 1. Service cert should be accepted ONLY IF it matches 2. > >> Service cert should be accepted IF any cert in the chain matches > >> > >> Reference Type: > >> 0. X.509 certificate (match(cert) = byte-wise equality) 1. > >> SubjectPublicKeyInfo structure (match(cert) = SPKI in cert) *. Digest > >> of X.509 certificate *. Digest of SubjectPublicKeyInfo > > > > After a bit of off-list discussion with Richard, we came up with some > rewording for his association types that make them clearer: > > > > ========== > > Service Certificate: The first certificate in the TLS Server Certificate > message, that is, the certificate whose public key is used for TLS key > negotiation. > > > > 0. The service certificate MUST pass standard PKIX validation > > (including chaining to a trust anchor), and MUST chain to or through a > > CA certificate matching the TLSA record > > > > 1. The service certificate MUST pass standard PKIX validation > > (including chaining to a trust anchor), and MUST match the TLSA record > > > > 2. The service certificate MUST pass standard PKIX validation, with > > any certificate matching the TLSA record considered to be a trust > > anchor for this validation ========== > > > > After some thought, I like Richard's proposal very much. It puts the > requirements for PKIX validation in the types definition, and makes it clear > right there what is being matched. > > > > I note that it is very different than the proposal that I put forward last > week: > > > >> On Aug 16, 2011, at 11:20 PM, Paul Hoffman wrote: > >> > >>> When talking with Jim, we realized that the issue is raising here is a > confluence of two things: > >>> - He wants to be able to restrict the role that the cert or public > >>> key can be used in (trust anchor, intermediate CA, end entity) > >>> - The current names for the two fields in record don't reflect their > >>> actual use > >>> > >>> The tentative proposal we came up with also has two parts: > >>> > >>> - Instead of just three types: > >>> 1 -- A PKIX certificate that identifies an end entity > >>> 2 -- A PKIX certification authority's certificate > >>> 3 -- A public key expressed as a PKIX SubjectPublicKeyInfo > >>> structure There should be six: > >>> n -- A PKIX certificate that identifies an end entity > >>> n+1 -- A PKIX certification authority's certificate that identifies > >>> n+a trust anchor > >>> n+2 -- A PKIX certification authority's certificate that identifies > >>> n+an intermediate CA > >>> n+3 -- A public key expressed as a PKIX SubjectPublicKeyInfo > >>> n+structure that identifies a trust anchor > >>> n+4 -- A public key expressed as a PKIX SubjectPublicKeyInfo > >>> n+structure that identifies an intermediate CA > >>> n+5 -- A public key expressed as a PKIX SubjectPublicKeyInfo > >>> n+structure that identifies an end entity > >>> > >>> - Instead of "Certificate Type" and "Reference Type", we need words > that define the fields' roles better. A first guess would be "Restriction Type" > and "Matching Type", but there could easily be better words. > >>> > > > > So, I guess the question splits into three (or more) possibilities. Keep the > current wording, go with my earlier proposed split (based on Jim's > suggestion), or go with Richard's very different proposal. > > > > --Paul Hoffman > > > > _______________________________________________ > > 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 gnu@toad.com Tue Aug 23 15:56:01 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A67221F8C0F for ; Tue, 23 Aug 2011 15:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.097 X-Spam-Level: X-Spam-Status: No, score=0.097 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, RCVD_IN_NJABL_RELAY=2.696] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7NdJtYo4tGF9 for ; Tue, 23 Aug 2011 15:56:01 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id EC4D821F8C0B for ; Tue, 23 Aug 2011 15:56:00 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id p7NMv886004365; Tue, 23 Aug 2011 15:57:08 -0700 Message-Id: <201108232257.p7NMv886004365@new.toad.com> To: Warren Kumari In-reply-to: <5F91C397-05BE-4A8A-A5DD-B02B0A832C21@kumari.net> References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> <54C1B56E-7673-4F32-8E7B-25959C121A03@bbn.com> <91A5DF74-6DCB-4530-96A4-46786AB62FCB@vpnc.org> <5F91C397-05BE-4A8A-A5DD-B02B0A832C21@kumari.net> Comments: In-reply-to Warren Kumari message dated "Tue, 23 Aug 2011 16:36:51 -0400." Date: Tue, 23 Aug 2011 15:57:08 -0700 From: John Gilmore Cc: DANE WG , Paul Hoffman , dane issue tracker Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 23 Aug 2011 22:56:01 -0000 > In order to help focus the discussions (and provide guidance to our authors), I'm asking the WG to please indicate a preference for text based on: > 1: The current wording. > 2: The proposed split (based upon Jim's suggestion ( http://www.ietf.org/mail-archive/web/dane/current/msg03223.html )) > 3: Richard's "very different" proposal (outlined below). It seems to me that you're arguing about the contents of data fields without clearly specifying what algorithms will be used to process those data fields. If we started with a clear description of the algorithms, it would be a lot more obvious what data needs to exist to support them. For example, Richard's revised proposal says things like "The service certificate MUST pass standard PKIX validation (including chaining to a trust anchor)". That seems to beg the entire question, by leaving "standard PKIX validation" undefined. Two sentences later it says that with a different Association Type value, "The service certificate MUST pass standard PKIX validation" while implying that this means WITHOUT chaining to a trust anchor. So does standard PKIX validation include ... what exactly? Making sure that the internal length fields are all valid? Checking the values of the dozens of fields in a certificate -- against what validators, exactly? Checking for the presence or absence of what fields, exactly? All unspecified. Not very helpful for a committee trying to decide whether this proposal is what the draft standard should say. Richard's formulation also seems to explicitly eliminate the ability to specify the "service certificate" (or its public key) in the TLSA record and yet not require ANY old-style trust anchors. But that depends on the subtleties of his Association Type 2: can the service certificate itself be treated as a "trust anchor" in his "standard PKIX validation" algorithm? Or does a trust anchor need to be a separate key/cert from the service certificate? Answer: it doesn't say! The whole thing seems symptomatic of the unnecessary complexity of the nested certificate model. Each TLS session's security is based on correctly associating a public key with the domain name provided in the URL that was used to begin the session. (If you associate the wrong public key, then your session can be hijacked or MITM'd, or merely will never connect successfully, DOS'd.) Both Paul's and Richard's proposals, as well as draft 10, seem to gild that lily by saying at what level of indirection the TLSA record "is permitted to" authenticate a key or certificate. While I'm sure we can think up an infinite number of possible indirections that would lead to that public key, each one that we add produces another set of security challenges to be analyzed and another opportunity to screw it up. All the serious cryptographers threw up their hands in trying to analyze IPSEC/IKE because it had so many options that they could never complete a security analysis in less than a career. Do we really want to define another protocol like that? Why don't we just specify: * If no TLSA record exists, do what the older RFCs say. * If the public key in the TLSA record is identical to the public key that the TLS session is based on (the "service certificate") then the protocol deems that public key trustworthy for the purposes of the TLS session. * If a TLSA record exists but its key does not match, break off the protocol and do not trust the server-supplied public key. and be done? (I also note that the whole draft is written as if it's about "certificates" and "certificate associations", though it also contains wording that purports to make plain public keys useful. There's small print that giveth plain public keys, but the main flow of text seems to taketh them away.) John From rbarnes@bbn.com Tue Aug 23 19:39:02 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2C4521F8B28 for ; Tue, 23 Aug 2011 19:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.605 X-Spam-Level: X-Spam-Status: No, score=-106.605 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHI-kGBmhZO4 for ; Tue, 23 Aug 2011 19:39:02 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2222821F8ABC for ; Tue, 23 Aug 2011 19:39:02 -0700 (PDT) Received: from [128.89.255.107] (port=53962 helo=[192.168.1.12]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Qw3Ny-000Nx5-4p; Tue, 23 Aug 2011 22:40:10 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <201108232257.p7NMv886004365@new.toad.com> Date: Tue, 23 Aug 2011 22:40:06 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> <54C1B56E-7673-4F32-8E7B-25959C121A03@bbn.com> <91A5DF74-6DCB-4530-96A4-46786AB62FCB@vpnc.org> <5F91C397-05BE-4A8A-A5DD-B02B0A832C21@kumari.net> <201108232257.p7NMv886004365@new.toad.com> To: John Gilmore X-Mailer: Apple Mail (2.1082) Cc: dane issue tracker , Paul Hoffman , DANE WG Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 24 Aug 2011 02:39:03 -0000 Hi John, Responses inline. On Aug 23, 2011, at 6:57 PM, John Gilmore wrote: >> In order to help focus the discussions (and provide guidance to our = authors), I'm asking the WG to please indicate a preference for text = based on: >> 1: The current wording. >> 2: The proposed split (based upon Jim's suggestion ( = http://www.ietf.org/mail-archive/web/dane/current/msg03223.html )) >> 3: Richard's "very different" proposal (outlined below). >=20 > It seems to me that you're arguing about the contents of data fields > without clearly specifying what algorithms will be used to process > those data fields. If we started with a clear description of the > algorithms, it would be a lot more obvious what data needs to exist to > support them. I actually think we're more or less on the same page here. The idea of = my proposal was to describe the relying party actions that each = association type entails, and in particular, how it differs from how a = client normally processes a certificate according to RFC 5280. I think = a lot of the differences you mentions below are really just ambiguities = that can and will be clarified in eventual text for the document. > For example, Richard's revised proposal says things like "The service > certificate MUST pass standard PKIX validation (including chaining to > a trust anchor)". That seems to beg the entire question, by leaving > "standard PKIX validation" undefined. Two sentences later it says > that with a different Association Type value, "The service certificate > MUST pass standard PKIX validation" while implying that this means > WITHOUT chaining to a trust anchor. So does standard PKIX validation > include ... what exactly? Making sure that the internal length fields > are all valid? Checking the values of the dozens of fields in a > certificate -- against what validators, exactly? Checking for the > presence or absence of what fields, exactly? All unspecified. Not > very helpful for a committee trying to decide whether this proposal is > what the draft standard should say. Sorry, it was understood that "standard PKIX validation" is the process = described in RFC 5280: > Richard's formulation also seems to explicitly eliminate the ability > to specify the "service certificate" (or its public key) in the TLSA > record and yet not require ANY old-style trust anchors. But that = depends > on the subtleties of his Association Type 2: can the service = certificate > itself be treated as a "trust anchor" in his "standard PKIX = validation" > algorithm? Or does a trust anchor need to be a separate key/cert from > the service certificate? Answer: it doesn't say! You cannot validate an X.509 certificate without reference to one or = more trust anchors. (I'm not sure what "old-style" means.) In = Association Type 2, the certificate itself can indeed be used as a trust = anchor material, in which case the PKIX validation algorithm will just = verify that it is a properly formed self-signed certificate. > >=20 > Both Paul's and Richard's proposals, as well as draft 10, seem to gild > that lily by saying at what level of indirection the TLSA record "is > permitted to" authenticate a key or certificate. While I'm sure we > can think up an infinite number of possible indirections that would > lead to that public key, each one that we add produces another set of > security challenges to be analyzed and another opportunity to screw it > up. All the serious cryptographers threw up their hands in trying to > analyze IPSEC/IKE because it had so many options that they could never > complete a security analysis in less than a career. Do we really want > to define another protocol like that? Why don't we just specify: >=20 > * If no TLSA record exists, do what the older RFCs say. >=20 > * If the public key in the TLSA record is identical to the public > key that the TLS session is based on (the "service certificate") > then the protocol deems that public key trustworthy for the=20 > purposes of the TLS session. >=20 > * If a TLSA record exists but its key does not match, break off the > protocol and do not trust the server-supplied public key. >=20 > and be done? That's exactly what [Association Type 2, Reference Type =3D SPKI] does. = We're not done by doing that because there are other use cases: > (I also note that the whole draft is written as if it's about > "certificates" and "certificate associations", though it also contains > wording that purports to make plain public keys useful. There's small > print that giveth plain public keys, but the main flow of text seems > to taketh them away.) This working group is about supporting TLS. TLS does not support bare = public keys. So the function of public keys in this context is to = identify certificates. =20 --Richard From rbarnes@bbn.com Tue Aug 23 19:40:00 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC0021F857D for ; Tue, 23 Aug 2011 19:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.604 X-Spam-Level: X-Spam-Status: No, score=-106.604 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7gmWRnCF-v34 for ; Tue, 23 Aug 2011 19:39:59 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id C3A2521F8B27 for ; Tue, 23 Aug 2011 19:39:53 -0700 (PDT) Received: from [128.89.255.107] (port=53962 helo=[192.168.1.12]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Qw3On-000Nx5-Dr; Tue, 23 Aug 2011 22:41:02 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <5F91C397-05BE-4A8A-A5DD-B02B0A832C21@kumari.net> Date: Tue, 23 Aug 2011 22:41:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8016CD0E-E247-436C-8098-E8FF49E85488@bbn.com> References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> <54C1B56E-7673-4F32-8E7B-25959C121A03@bbn.com> <91A5DF74-6DCB-4530-96A4-46786AB62FCB@vpnc.org> <5F91C397-05BE-4A8A-A5DD-B02B0A832C21@kumari.net> To: Warren Kumari X-Mailer: Apple Mail (2.1082) Cc: DANE WG , Paul Hoffman , dane issue tracker Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 24 Aug 2011 02:40:00 -0000 For the record, I like #3 as a starting point, with clarifications and = details to be filled in as it gets incorporated in the text. =20 --Richard On Aug 23, 2011, at 4:36 PM, Warren Kumari wrote: > In order to help focus the discussions (and provide guidance to our = authors), I'm asking the WG to please indicate a preference for text = based on: >=20 > 1: The current wording. >=20 > 2: The proposed split (based upon Jim's suggestion ( = http://www.ietf.org/mail-archive/web/dane/current/msg03223.html )) >=20 > 3: Richard's "very different" proposal (outlined below). >=20 >=20 > > I personally like #3 -- while it involves the largest amount of = change, I view it as the cleanest and (at least for me) easiest to = understand, especially from the "I'm just a monkey that operates a = server" standpoint.... > > W >=20 >=20 >=20 > On Aug 22, 2011, at 7:28 PM, Paul Hoffman wrote: >=20 >>=20 >> On Aug 17, 2011, at 5:57 PM, Richard L. Barnes wrote: >>=20 >>> This suggestion seems to be missing the point. You're still = conflating the identifier for a certificate for how it's used. Suggest = the following taxonomy, which aligns much better with the use cases: >>>=20 >>> Association Type: >>> 0. Service cert should be accepted ONLY IF matching cert is in cert = chain >>> 1. Service cert should be accepted ONLY IF it matches=20 >>> 2. Service cert should be accepted IF any cert in the chain matches >>>=20 >>> Reference Type: >>> 0. X.509 certificate (match(cert) =3D byte-wise equality) >>> 1. SubjectPublicKeyInfo structure (match(cert) =3D SPKI in cert) >>> *. Digest of X.509 certificate >>> *. Digest of SubjectPublicKeyInfo >>=20 >> After a bit of off-list discussion with Richard, we came up with some = rewording for his association types that make them clearer: >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> Service Certificate: The first certificate in the TLS Server = Certificate message, that is, the certificate whose public key is used = for TLS key negotiation. >>=20 >> 0. The service certificate MUST pass standard PKIX validation = (including chaining to a trust anchor), and MUST chain to or through a = CA certificate matching the TLSA record >>=20 >> 1. The service certificate MUST pass standard PKIX validation = (including chaining to a trust anchor), and MUST match the TLSA record >>=20 >> 2. The service certificate MUST pass standard PKIX validation, with = any certificate matching the TLSA record considered to be a trust anchor = for this validation >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> After some thought, I like Richard's proposal very much. It puts the = requirements for PKIX validation in the types definition, and makes it = clear right there what is being matched. >>=20 >> I note that it is very different than the proposal that I put forward = last week: >>=20 >>> On Aug 16, 2011, at 11:20 PM, Paul Hoffman wrote: >>>=20 >>>> When talking with Jim, we realized that the issue is raising here = is a confluence of two things: >>>> - He wants to be able to restrict the role that the cert or public = key can be used in (trust anchor, intermediate CA, end entity) >>>> - The current names for the two fields in record don't reflect = their actual use >>>>=20 >>>> The tentative proposal we came up with also has two parts: >>>>=20 >>>> - Instead of just three types: >>>> 1 -- A PKIX certificate that identifies an end entity >>>> 2 -- A PKIX certification authority's certificate >>>> 3 -- A public key expressed as a PKIX SubjectPublicKeyInfo = structure >>>> There should be six: >>>> n -- A PKIX certificate that identifies an end entity >>>> n+1 -- A PKIX certification authority's certificate that identifies = a trust anchor >>>> n+2 -- A PKIX certification authority's certificate that identifies = an intermediate CA >>>> n+3 -- A public key expressed as a PKIX SubjectPublicKeyInfo = structure that identifies a trust anchor >>>> n+4 -- A public key expressed as a PKIX SubjectPublicKeyInfo = structure that identifies an intermediate CA >>>> n+5 -- A public key expressed as a PKIX SubjectPublicKeyInfo = structure that identifies an end entity >>>>=20 >>>> - Instead of "Certificate Type" and "Reference Type", we need words = that define the fields' roles better. A first guess would be = "Restriction Type" and "Matching Type", but there could easily be better = words. >>>>=20 >>=20 >> So, I guess the question splits into three (or more) possibilities. = Keep the current wording, go with my earlier proposed split (based on = Jim's suggestion), or go with Richard's very different proposal. >>=20 >> --Paul Hoffman >>=20 >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >>=20 >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From ietf@augustcellars.com Tue Aug 23 21:00:01 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE9A21F8ADC for ; Tue, 23 Aug 2011 21:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xBn6hcBeV7Qy for ; Tue, 23 Aug 2011 21:00:00 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 9407821F8A70 for ; Tue, 23 Aug 2011 21:00:00 -0700 (PDT) Received: from TITUS (50-39-220-175.bvtn.or.frontiernet.net [50.39.220.175]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id E22C638EF0; Tue, 23 Aug 2011 21:01:08 -0700 (PDT) From: "Jim Schaad" To: "'Richard L. Barnes'" , "'John Gilmore'" References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> <54C1B56E-7673-4F32-8E7B-25959C121A03@bbn.com> <91A5DF74-6DCB-4530-96A4-46786AB62FCB@vpnc.org> <5F91C397-05BE-4A8A-A5DD-B02B0A832C21@kumari.net> <201108232257.p7NMv886004365@new.toad.com> In-Reply-To: Date: Tue, 23 Aug 2011 21:36:13 -0700 Message-ID: <00cd01cc6217$5c758fc0$1560af40$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQHwXbPL2/IzPDFsf9e9Pk9vZhBFJQMMON3xAq/8BzAA6q5ZtAEt7WdeAgh00uACAAlkZpSEiKAg Cc: 'DANE WG' , 'Paul Hoffman' , 'dane issue tracker' Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 24 Aug 2011 04:00:01 -0000 > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of > Richard L. Barnes > Sent: Tuesday, August 23, 2011 7:40 PM > To: John Gilmore > Cc: dane issue tracker; Paul Hoffman; DANE WG > Subject: Re: [dane] #29: Request new Reference Type - Public Key > > Hi John, > > Responses inline. > > On Aug 23, 2011, at 6:57 PM, John Gilmore wrote: > > >> In order to help focus the discussions (and provide guidance to our > authors), I'm asking the WG to please indicate a preference for text based > on: > >> 1: The current wording. > >> 2: The proposed split (based upon Jim's suggestion ( > >> http://www.ietf.org/mail-archive/web/dane/current/msg03223.html )) > >> 3: Richard's "very different" proposal (outlined below). > > > > It seems to me that you're arguing about the contents of data fields > > without clearly specifying what algorithms will be used to process > > those data fields. If we started with a clear description of the > > algorithms, it would be a lot more obvious what data needs to exist to > > support them. > > I actually think we're more or less on the same page here. The idea of my > proposal was to describe the relying party actions that each association type > entails, and in particular, how it differs from how a client normally processes > a certificate according to RFC 5280. I think a lot of the differences you > mentions below are really just ambiguities that can and will be clarified in > eventual text for the document. > > > > For example, Richard's revised proposal says things like "The service > > certificate MUST pass standard PKIX validation (including chaining to > > a trust anchor)". That seems to beg the entire question, by leaving > > "standard PKIX validation" undefined. Two sentences later it says > > that with a different Association Type value, "The service certificate > > MUST pass standard PKIX validation" while implying that this means > > WITHOUT chaining to a trust anchor. So does standard PKIX validation > > include ... what exactly? Making sure that the internal length fields > > are all valid? Checking the values of the dozens of fields in a > > certificate -- against what validators, exactly? Checking for the > > presence or absence of what fields, exactly? All unspecified. Not > > very helpful for a committee trying to decide whether this proposal is > > what the draft standard should say. > > Sorry, it was understood that "standard PKIX validation" is the process > described in RFC 5280: > > > > > Richard's formulation also seems to explicitly eliminate the ability > > to specify the "service certificate" (or its public key) in the TLSA > > record and yet not require ANY old-style trust anchors. But that > > depends on the subtleties of his Association Type 2: can the service > > certificate itself be treated as a "trust anchor" in his "standard PKIX > validation" > > algorithm? Or does a trust anchor need to be a separate key/cert from > > the service certificate? Answer: it doesn't say! > > You cannot validate an X.509 certificate without reference to one or more > trust anchors. (I'm not sure what "old-style" means.) In Association Type 2, > the certificate itself can indeed be used as a trust anchor material, in which > case the PKIX validation algorithm will just verify that it is a properly formed > self-signed certificate. > Actually as a trust anchor there is no need for the certificate to be self-signed. The key is used without reference to any contents of the certificate except for the public key information. > > > > > > > Both Paul's and Richard's proposals, as well as draft 10, seem to gild > > that lily by saying at what level of indirection the TLSA record "is > > permitted to" authenticate a key or certificate. While I'm sure we > > can think up an infinite number of possible indirections that would > > lead to that public key, each one that we add produces another set of > > security challenges to be analyzed and another opportunity to screw it > > up. All the serious cryptographers threw up their hands in trying to > > analyze IPSEC/IKE because it had so many options that they could never > > complete a security analysis in less than a career. Do we really want > > to define another protocol like that? Why don't we just specify: > > > > * If no TLSA record exists, do what the older RFCs say. > > > > * If the public key in the TLSA record is identical to the public > > key that the TLS session is based on (the "service certificate") > > then the protocol deems that public key trustworthy for the > > purposes of the TLS session. > > > > * If a TLSA record exists but its key does not match, break off the > > protocol and do not trust the server-supplied public key. > > > > and be done? > > That's exactly what [Association Type 2, Reference Type = SPKI] does. We're > not done by doing that because there are other use cases: > > > > > (I also note that the whole draft is written as if it's about > > "certificates" and "certificate associations", though it also contains > > wording that purports to make plain public keys useful. There's small > > print that giveth plain public keys, but the main flow of text seems > > to taketh them away.) > > This working group is about supporting TLS. TLS does not support bare public > keys. So the function of public keys in this context is to identify certificates. > > --Richard > > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From paul@xelerance.com Tue Aug 23 21:22:33 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C901E21F8548 for ; Tue, 23 Aug 2011 21:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.478 X-Spam-Level: X-Spam-Status: No, score=-6.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h+Ri+KdpG2eH for ; Tue, 23 Aug 2011 21:22:33 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id 4116321F8540 for ; Tue, 23 Aug 2011 21:22:33 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 1B9DB571C2; Wed, 24 Aug 2011 00:26:00 -0400 (EDT) Date: Wed, 24 Aug 2011 00:25:59 -0400 (EDT) From: Paul Wouters To: "Richard L. Barnes" In-Reply-To: Message-ID: References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> <54C1B56E-7673-4F32-8E7B-25959C121A03@bbn.com> <91A5DF74-6DCB-4530-96A4-46786AB62FCB@vpnc.org> <5F91C397-05BE-4A8A-A5DD-B02B0A832C21@kumari.net> <201108232257.p7NMv886004365@new.toad.com> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Paul Hoffman , DANE WG , dane issue tracker Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 24 Aug 2011 04:22:33 -0000 On Tue, 23 Aug 2011, Richard L. Barnes wrote: > This working group is about supporting TLS. TLS does not support bare public keys. So the function of public keys in this context is to identify certificates. That's a weak argument. The TLS WG choose to take on this item in the working group, and some proposals are already floating around on how to implement it. It seems likely a new CertType of "SubjectPublicKeyInfo" will be used to identify TLS using bare public keys without certificates. Postponing this now will just create more bureaucracy in a few months, or your "identifying a cert by a public key" will simply get overloaded for tls-oob. Paul From ietf@augustcellars.com Tue Aug 23 22:08:09 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2D1721F8BB8 for ; Tue, 23 Aug 2011 22:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JcGrLzNiuBYO for ; Tue, 23 Aug 2011 22:08:09 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 3980D21F8BB5 for ; Tue, 23 Aug 2011 22:08:08 -0700 (PDT) Received: from TITUS (50-39-220-175.bvtn.or.frontiernet.net [50.39.220.175]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id AC38A38F33; Tue, 23 Aug 2011 22:09:16 -0700 (PDT) From: "Jim Schaad" To: "'Paul Wouters'" , "'Richard L. Barnes'" References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> <54C1B56E-7673-4F32-8E7B-25959C121A03@bbn.com> <91A5DF74-6DCB-4530-96A4-46786AB62FCB@vpnc.org> <5F91C397-05BE-4A8A-A5DD-B02B0A832C21@kumari.net> <201108232257.p7NMv886004365@new.toad.com> In-Reply-To: Date: Tue, 23 Aug 2011 22:44:21 -0700 Message-ID: <00dd01cc6220$e0e63300$a2b29900$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQHwXbPL2/IzPDFsf9e9Pk9vZhBFJQMMON3xAq/8BzAA6q5ZtAEt7WdeAgh00uACAAlkZgFdIomelHmySvA= Cc: 'dane issue tracker' , 'Paul Hoffman' , 'DANE WG' Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 24 Aug 2011 05:08:09 -0000 In my opinion the fact that the "identifying a cert by a public key" get overloaded is the correct answer. We should define a new "cert-type" of bare key, the bare key "cert-type" (which is what is being recommended by the TLS people) would match if the public keys match. I don't think there is any true overloading, just a question of how the public key reference (or match) type is defined > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of > Paul Wouters > Sent: Tuesday, August 23, 2011 9:26 PM > To: Richard L. Barnes > Cc: Paul Hoffman; DANE WG; dane issue tracker > Subject: Re: [dane] #29: Request new Reference Type - Public Key > > On Tue, 23 Aug 2011, Richard L. Barnes wrote: > > > This working group is about supporting TLS. TLS does not support bare > public keys. So the function of public keys in this context is to identify > certificates. > > That's a weak argument. The TLS WG choose to take on this item in the > working group, and some proposals are already floating around on how to > implement it. > > It seems likely a new CertType of "SubjectPublicKeyInfo" will be used to > identify TLS using bare public keys without certificates. > > Postponing this now will just create more bureaucracy in a few months, or > your "identifying a cert by a public key" will simply get overloaded for tls-oob. > > Paul > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From jakob@kirei.se Wed Aug 24 01:06:50 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56EE921F8B15 for ; Wed, 24 Aug 2011 01:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.626 X-Spam-Level: X-Spam-Status: No, score=-0.626 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EzIddzrOBH4T for ; Wed, 24 Aug 2011 01:06:49 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id 01C8521F8ACC for ; Wed, 24 Aug 2011 01:06:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=TpfX/VeaWAMnLRG19ddD862MOMWKttyIFZ1oPO/SeyI=; b=T11Eqj8FX3drRjdrHa0dzN8CeTdCNC7opl0vM5cnYSlpoTOm302qVnI5bXiHrAvF1TqVY3V7BmCSh 2tqQncOAxXm0Rjmyjf3KZNiWADl8YNU8p10wRMFBrD27RiU8oP0mov0ahnXGaYGrkg3dFM/Q04sF7X /eZOuRBNnyc1tFac= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Wed, 24 Aug 2011 10:07:55 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: <5F91C397-05BE-4A8A-A5DD-B02B0A832C21@kumari.net> Date: Wed, 24 Aug 2011 10:07:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <53597CBD-8E3F-4A66-98BE-720C609B2B0C@kirei.se> References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> <54C1B56E-7673-4F32-8E7B-25959C121A03@bbn.com> <91A5DF74-6DCB-4530-96A4-46786AB62FCB@vpnc.org> <5F91C397-05BE-4A8A-A5DD-B02B0A832C21@kumari.net> To: Warren Kumari X-Mailer: Apple Mail (2.1244.3) Cc: Paul Hoffman , DANE WG Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 24 Aug 2011 08:06:50 -0000 On 23 aug 2011, at 22:36, Warren Kumari wrote: > In order to help focus the discussions (and provide guidance to our = authors), I'm asking the WG to please indicate a preference for text = based on: >=20 > 1: The current wording. >=20 > 2: The proposed split (based upon Jim's suggestion ( = http://www.ietf.org/mail-archive/web/dane/current/msg03223.html )) >=20 > 3: Richard's "very different" proposal (outlined below). I like 3, but I also see some problems with this approach. In the = current wording, we have a very simple structure where the certificate = type (describing what to compare) is independent of the reference type = (how to compare it) and I'd recommend that we try to keep this split. In = Richards proposal, the reference type is depending on the certificate = type. This effectively means that not all reference types are good for a = given certificate type, making it more complex to use and implement. My preference is to go with Rickard's RP-centric certificate/association = types, but add separate types where the input to the comparison function = (the reference type) is the SubjectPublicKeyInfo. This would keep the = reference type generic (identity comparison or hash comparison) and ease = future extensions (e.g. PGP). - 0. Certificate MUST pass PKIX validation and MUST chain through a CA = certificate matching the TLSA record - 1. Certificate MUST pass PKIX validation and MUST match the TLSA = record - 2. Certificate MUST pass PKIX validation, with any certificate = matching the TLSA record considered to be a trust anchor for this = validation - 3. as (0) but the comparison is done using SubjectPublicKeyInfo - 4. as (1) but the comparison is done using SubjectPublicKeyInfo - 5. as (2) but the comparison is done using SubjectPublicKeyInfo N.B.: an association type of 2 or 5 with a reference type other than 0 = wouldn't be very useful unless the TLS server provides a full = certificate chain (form the EE to the CA). jakob From gnu@toad.com Wed Aug 24 02:29:56 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10D9121F8888 for ; Wed, 24 Aug 2011 02:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.097 X-Spam-Level: X-Spam-Status: No, score=0.097 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_NJABL_RELAY=2.696] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4hfkcZBXTA2 for ; Wed, 24 Aug 2011 02:29:55 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id 2D85321F84CB for ; Wed, 24 Aug 2011 02:29:55 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id p7O9Ux86019874; Wed, 24 Aug 2011 02:30:59 -0700 Message-Id: <201108240930.p7O9Ux86019874@new.toad.com> To: "Richard L. Barnes" In-reply-to: References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> <54C1B56E-7673-4F32-8E7B-25959C121A03@bbn.com> <91A5DF74-6DCB-4530-96A4-46786AB62FCB@vpnc.org> <5F91C397-05BE-4A8A-A5DD-B02B0A832C21@kumari.net> <201108232257.p7NMv886004365@new.toad.com> Comments: In-reply-to "Richard L. Barnes" message dated "Tue, 23 Aug 2011 22:40:06 -0400." Date: Wed, 24 Aug 2011 02:30:59 -0700 From: John Gilmore Cc: Paul Hoffman , dane issue tracker , DANE WG Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 24 Aug 2011 09:29:56 -0000 Richard, thank you for the clarifications. > Sorry, it was understood that "standard PKIX validation" is the process described in RFC 5280: > That's more than 20 pages of pseudocode -- which starts off with a basic assumption that there is some a-priori set of "trust anchors". It does provide an algorithm in 6.1 that takes a single trust anchor and a certificate list and attempts to validate it. But it is quite vague (e.g. in section 6.2) about how or whether the algorithm iterates through these trust anchors, perhaps trying each one, perhaps not. RFC 5280 does not provide an algorithm that takes a (possibly null or unitary, or multiple) vector of trust anchors and validates a certificate list with respect to that vector. And it says little or nothing about where these trust anchors come from. There's a lot of arm-waving going on in that RFC. It's really crufty pseudocode, too, with statements like "For each P-OID in the user-initial-policy-set that is not the valid_policy of a node in the valid_policy_node_set, create a child node whose parent is the node of depth n-1 with the valid_policy anyPolicy. Set the values in the child node as follows: set the valid_policy to P-OID, set the qualifier_set to P-Q, and set the expected_policy_set to {P-OID}." Has anyone ever formally analyzed it, or even translated it directly to an executable language so we can see if it crashes or runs? That pseudocode also requires support for CRLs, and the realtime fetching of CRLs, which apparently has been all but abandoned in real life (so I heard on this list). Do we intend to require CRL processing for DANE-supported TLS? If not, we can't reference this RFC 5280 pseudocode as the master reference for the algorithm our implementers should follow. If and when we do choose to invoke that pseudocode, we should formalize the arguments to it (e.g. when the TLSA record(s) say XXX, and the set of preconfigured trust anchors is YYY, then the inputs to the pseudocode in section 6.1 are exactly X, Y, and Z). And if DANE requires modifications to that pseudocode, e.g. to interleave TLSA processing with certificate processing, then we should be extremely precise about what those mods are. (Of course, patching "diffs" into a complex piece of code is likely to make it even more broken than it was, unless very carefully done. Especially if you have no way to run it, no way to debug it, and no automated test cases for it.) For many reasons, I don't think that DANE should require that anybody use that 20+ pages of pseudocode. As Jim Schaad has pointed out, DANE should allow someone to put a public key (or an unsigned certificate, i.e. a public key with some syntactic sugar around it) into the DNS TLSA record, and provide a public key (or an unsigned certificate) in the TLS handshake, and if the keys match, be done. Without ever even *invoking* that error-prone PKIX validation subroutine. A major impetus for DANE is that enough people on the net don't trust that whole system of error-prone certificate validation. We should not require its use for users who wish to avoid it. For straightforward cases, we should specifically *not* dummy-up arguments to that validation pseudo-algorithm, and then make assumptions about what results the algorithm would reach when processing those dummy arguments (like saying "in which case the PKIX validation algorithm will just verify that it is a properly formed self-signed certificate"). I know you *think* it'll do that, Richard, but I don't think you can prove it. John From pgut001@login01.cs.auckland.ac.nz Wed Aug 24 03:06:02 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3148721F863A for ; Wed, 24 Aug 2011 03:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.57 X-Spam-Level: X-Spam-Status: No, score=-3.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6vLB1FXbzaP for ; Wed, 24 Aug 2011 03:06:01 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2F021F851A for ; Wed, 24 Aug 2011 03:05:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1314180431; x=1345716431; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20gnu@toad.com,=20rbarnes@bbn.com|Subject:=20Re:=20[ dane]=20#29:=20Request=20new=20Reference=20Type=20-=20Pub lic=20Key|Cc:=20dane@ietf.org,=20paul.hoffman@vpnc.org, =0D=0A=20=20=20=20trac+dane@zinfandel.tools.ietf.org |In-Reply-To:=20<201108240930.p7O9Ux86019874@new.toad.com >|Message-Id:=20|Date:=20Wed,=2024=20Aug=202011=2022:07:01=20+1200; bh=vKn2LLkDMYYYrcJvHwc9ih+4T6o0el8wCqSzt9DHpnY=; b=bd70YOp+TVR2j5cNhElud+I/vX2FFOTcbPzvYKIfaHdFgcJHw0bNk8Jo mNvVUuPfpm7MwfBB6Nft8320+jjrpmkDHtCXqNeR5a6QhEOS06S0eKvN0 PxQrWM6tWuSuLgjbb4lk2293gpmYVxo8pPyR6mzDtFz/EEKgMgvWLEnHo k=; X-IronPort-AV: E=Sophos;i="4.68,274,1312113600"; d="scan'208";a="80164766" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 24 Aug 2011 22:07:01 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QwAMP-0002Mr-IL; Wed, 24 Aug 2011 22:07:01 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QwAMP-0007c6-Km; Wed, 24 Aug 2011 22:07:01 +1200 From: Peter Gutmann To: gnu@toad.com, rbarnes@bbn.com In-Reply-To: <201108240930.p7O9Ux86019874@new.toad.com> Message-Id: Date: Wed, 24 Aug 2011 22:07:01 +1200 Cc: trac+dane@zinfandel.tools.ietf.org, paul.hoffman@vpnc.org, dane@ietf.org Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 24 Aug 2011 10:06:02 -0000 John Gilmore writes: >Richard, thank you for the clarifications. > >> Sorry, it was understood that "standard PKIX validation" is the process described in RFC 5280: >> > >That's more than 20 pages of pseudocode -- which starts off with a >[...] >it, no way to debug it, and no automated test cases for it.) Another point is that I suspect whoever came up with that pseudocode probably hasn't written ten lines of actual code in as many years, or at least has never tried to implement what's in there, because alongside the obvious ambiguities you mention it also contradicts both itself and the body text of the RFC in various places. You have to implement it to see this, I ended up with code comments that sometimes ran to two or three *pages* trying to sort out what interpretation to apply at different points when I was trying to untangle the mess (in the end I took the body text as definitive, assuming that the pseudocode would be a buggy attempt to implement the text). OTOH it may simply be that the PKIX requirements just can't be expressed/implemented rigorously, which was the case when some University researchers tried it using the (far simpler) RFC 2459 version some years ago. In any case though it seems that virtually nothing actually implements what's in that RFC, because if you turn on full PKIX-compliant cert processing you'll end up rejecting, oh, about 90% of all certs in creation [0]. Some years ago I did a quick test whose results I posted to the PKIX list where I grabbed cert chains from eleven large public CAs. Ten of the eleven failed full-PKIX validation. Heck, even NIST's own PKI test vectors fail full PKIX validation in a number of cases. So it seems unreasonable for DANE to expect people to go through the whole PKIX silly-walk if almost no-one else is doing it either. Alternatively, if anyone wants to require this, perhaps we could require them to go away and define exactly what's required, unambiguously, in some formal notation. They can come back when they're done. Peter. [0] Figure pulled out of my *ss and used for demonstration purposes only. From pgut001@login01.cs.auckland.ac.nz Wed Aug 24 03:10:15 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B23A21F851A for ; Wed, 24 Aug 2011 03:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.57 X-Spam-Level: X-Spam-Status: No, score=-3.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plqa99do87mW for ; Wed, 24 Aug 2011 03:10:14 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 44AF421F863A for ; Wed, 24 Aug 2011 03:10:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1314180685; x=1345716685; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20gnu@toad.com,=20rbarnes@bbn.com|Subject:=20Re:=20[ dane]=20#29:=20Request=20new=20Reference=20Type=20-=20Pub lic=20Key|Cc:=20dane@ietf.org,=20paul.hoffman@vpnc.org, =0D=0A=20=20=20=20trac+dane@zinfandel.tools.ietf.org |In-Reply-To:=20<201108240930.p7O9Ux86019874@new.toad.com >|Message-Id:=20|Date:=20Wed,=2024=20Aug=202011=2022:10:51=20+1200; bh=XVEysxmdORiZFn7dCQrOMFFLOBVXBwMUpHZ3uDlaJp8=; b=C/kshDoOVrHBYD/bIm2t925abMH6p0fs+JtjNw6vPhf26reozETFbKET d+Lf86T6/4UDbdJry0PSWr2KtG5JVHUASzdAzIsBifFY9fnoxsU799h+T osX75QZUKYbhY9Lt5WcxoPIhPxtYo8xrmwhlWPnZ/Uycm2ndI46cPG5ik Q=; X-IronPort-AV: E=Sophos;i="4.68,274,1312113600"; d="scan'208";a="80168400" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 24 Aug 2011 22:10:51 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QwAQ7-0002Tw-Hz; Wed, 24 Aug 2011 22:10:51 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QwAQ7-0007kg-F3; Wed, 24 Aug 2011 22:10:51 +1200 From: Peter Gutmann To: gnu@toad.com, rbarnes@bbn.com In-Reply-To: <201108240930.p7O9Ux86019874@new.toad.com> Message-Id: Date: Wed, 24 Aug 2011 22:10:51 +1200 Cc: trac+dane@zinfandel.tools.ietf.org, paul.hoffman@vpnc.org, dane@ietf.org Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 24 Aug 2011 10:10:15 -0000 John Gilmore writes: >Has anyone ever formally analyzed it, or even translated it directly to an >executable language so we can see if it crashes or runs? Argh, sorry, hit ^D too early: We know, from a prior attempt at doing this, that it *cannot* be formalised or analysed, even in its much, much simpler RFC 2459 form. See: .A State-Based Model for Certificate Management., Chuchang Liu, Maris Ozols, Marie Henderson and Tony Cant, Proceedings of the 3rd Workshop on Practice and Theory in Public Key Cryptography (PKC.00), Springer-Verlag LNCS No.1751, January 2000, p.75. (Why do you think it's presented as hand-wavy pseudocode rather than any formal description? :-). Peter. From i.grok@comcast.net Wed Aug 24 04:37:48 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDD7221F8B17 for ; Wed, 24 Aug 2011 04:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.633 X-Spam-Level: X-Spam-Status: No, score=-102.633 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydd9sQ-GhzfM for ; Wed, 24 Aug 2011 04:37:48 -0700 (PDT) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [76.96.27.243]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF3021F8B03 for ; Wed, 24 Aug 2011 04:37:48 -0700 (PDT) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta13.emeryville.ca.mail.comcast.net with comcast id QBeV1h0011Y3wxoADBeuwQ; Wed, 24 Aug 2011 11:38:54 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta15.emeryville.ca.mail.comcast.net with comcast id QBf41h00500PQ6U8bBf463; Wed, 24 Aug 2011 11:39:05 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.4/8.14.3) with ESMTP id p7OBcv7d009644 for ; Wed, 24 Aug 2011 07:38:57 -0400 Received: (from draco@localhost) by odin.ulthar.us (8.14.4/8.14.4/Submit) id p7OBcuLX009642 for dane@ietf.org; Wed, 24 Aug 2011 07:38:56 -0400 Date: Wed, 24 Aug 2011 07:38:56 -0400 From: Scott Schmit To: dane@ietf.org Message-ID: <20110824113856.GA2115@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <38e2b669.11f2c.131f99460de.Coremail.yzw_iplab@163.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <38e2b669.11f2c.131f99460de.Coremail.yzw_iplab@163.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Certificate update timing X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 24 Aug 2011 11:37:48 -0000 On Wed, Aug 24, 2011 at 10:17:56AM +0800, 延志伟 wrote: > I have a confused question and I am not sure whether it has been > considered in this WG. > > When the certificate will be updated, the TLS server may maintain both > old and new certificates for some time in order to achieve the smooth > transfer. However, if the new certificate material cannot be updated > in the DNS before it is deleted from the TLS server, the old > certificate will be stored and learned from DNS for some time while > the new certificate is used in the TLS server. > > I think because the certificate may be stored and used in different > places (e.g., DNS and TLS server), this timing issue should be > considered in the DANE protocol. This is no different than any other DNS thing. Initial state: _123._tcp.blah.example. IN TLSA TLS server has certificate chain associated with . Announce new certificate information in DNS: _123._tcp.blah.example. IN TLSA _123._tcp.blah.example. IN TLSA TLS server has certificate chain associated with . Update TLS server: _123._tcp.blah.example. IN TLSA _123._tcp.blah.example. IN TLSA TLS server has certificate chain associated with . Clean up DNS: _123._tcp.blah.example. IN TLSA TLS server has certificate chain associated with . Since the DANE spec says that only one record has to match what the server says, at no point (provided you move no faster than 2x your TTL) will any client see DNS w/ old only + TLS w/ new or DNS w/ new only + TLS w/ old. If the DNS admin gets the timing wrong, it's no different than changing a NS or DNSKEY record too quickly--things will break until the TTLs expire. -- Scott Schmit From rbarnes@bbn.com Wed Aug 24 05:59:20 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABBA921F8AD3 for ; Wed, 24 Aug 2011 05:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.536 X-Spam-Level: X-Spam-Status: No, score=-106.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AxlpI7Slh2vv for ; Wed, 24 Aug 2011 05:59:20 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 233B821F8876 for ; Wed, 24 Aug 2011 05:59:20 -0700 (PDT) Received: from [192.1.255.224] (port=49308 helo=col-dhcp-192-1-255-224.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QwD4F-0003HH-VE; Wed, 24 Aug 2011 09:00:28 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <00dd01cc6220$e0e63300$a2b29900$@augustcellars.com> Date: Wed, 24 Aug 2011 09:00:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> <54C1B56E-7673-4F32-8E7B-25959C121A03@bbn.com> <91A5DF74-6DCB-4530-96A4-46786AB62FCB@vpnc.org> <5F91C397-05BE-4A8A-A5DD-B02B0A832C21@kumari.net> <201108232257.p7NMv886004365@new.toad.com> <00dd01cc6220$e0e63300$a2b29900$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1082) Cc: 'dane issue tracker' , 'Paul Hoffman' , 'DANE WG' Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 24 Aug 2011 12:59:20 -0000 Right. If/when TLS comes along, you'll need to update the spec anyway = with a new CertType/AssocType. --Richard On Aug 24, 2011, at 1:44 AM, Jim Schaad wrote: > In my opinion the fact that the "identifying a cert by a public key" = get > overloaded is the correct answer. >=20 > We should define a new "cert-type" of bare key, the bare key = "cert-type" > (which is what is being recommended by the TLS people) would match if = the > public keys match. I don't think there is any true overloading, just = a > question of how the public key reference (or match) type is defined >=20 >=20 >> -----Original Message----- >> From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf = Of >> Paul Wouters >> Sent: Tuesday, August 23, 2011 9:26 PM >> To: Richard L. Barnes >> Cc: Paul Hoffman; DANE WG; dane issue tracker >> Subject: Re: [dane] #29: Request new Reference Type - Public Key >>=20 >> On Tue, 23 Aug 2011, Richard L. Barnes wrote: >>=20 >>> This working group is about supporting TLS. TLS does not support = bare >> public keys. So the function of public keys in this context is to > identify >> certificates. >>=20 >> That's a weak argument. The TLS WG choose to take on this item in the >> working group, and some proposals are already floating around on how = to >> implement it. >>=20 >> It seems likely a new CertType of "SubjectPublicKeyInfo" will be used = to >> identify TLS using bare public keys without certificates. >>=20 >> Postponing this now will just create more bureaucracy in a few = months, or >> your "identifying a cert by a public key" will simply get overloaded = for > tls-oob. >>=20 >> Paul >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >=20 From rbarnes@bbn.com Wed Aug 24 06:04:47 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78C2421F86C1 for ; Wed, 24 Aug 2011 06:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.539 X-Spam-Level: X-Spam-Status: No, score=-106.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A19jBkR1+yPJ for ; Wed, 24 Aug 2011 06:04:46 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id C0AA821F86AF for ; Wed, 24 Aug 2011 06:04:46 -0700 (PDT) Received: from [192.1.255.224] (port=49342 helo=col-dhcp-192-1-255-224.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QwD9X-0001wN-W4; Wed, 24 Aug 2011 09:05:56 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <201108240930.p7O9Ux86019874@new.toad.com> Date: Wed, 24 Aug 2011 09:05:48 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <53EB605F-9859-4529-8641-F70A2C5038CD@bbn.com> References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> <54C1B56E-7673-4F32-8E7B-25959C121A03@bbn.com> <91A5DF74-6DCB-4530-96A4-46786AB62FCB@vpnc.org> <5F91C397-05BE-4A8A-A5DD-B02B0A832C21@kumari.net> <201108232257.p7NMv886004365@new.toad.com> <201108240930.p7O9Ux86019874@new.toad.com> To: John Gilmore X-Mailer: Apple Mail (2.1082) Cc: dane issue tracker , Paul Hoffman , DANE WG Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 24 Aug 2011 13:04:47 -0000 I don't think re-visiting the concept of PKIX validation is in scope for = this group. For better or worse, that's the starting point for what = we're doing. --Richard=20 On Aug 24, 2011, at 5:30 AM, John Gilmore wrote: > Richard, thank you for the clarifications. >=20 >> Sorry, it was understood that "standard PKIX validation" is the = process described in RFC 5280: >> >=20 > That's more than 20 pages of pseudocode -- which starts off with a > basic assumption that there is some a-priori set of "trust anchors". > It does provide an algorithm in 6.1 that takes a single trust anchor > and a certificate list and attempts to validate it. But it is quite > vague (e.g. in section 6.2) about how or whether the algorithm > iterates through these trust anchors, perhaps trying each one, perhaps > not. RFC 5280 does not provide an algorithm that takes a (possibly > null or unitary, or multiple) vector of trust anchors and validates a > certificate list with respect to that vector. And it says little or > nothing about where these trust anchors come from. There's a lot of > arm-waving going on in that RFC. >=20 > It's really crufty pseudocode, too, with statements like "For each > P-OID in the user-initial-policy-set that is not the valid_policy of a > node in the valid_policy_node_set, create a child node whose parent is > the node of depth n-1 with the valid_policy anyPolicy. Set the values > in the child node as follows: set the valid_policy to P-OID, set the > qualifier_set to P-Q, and set the expected_policy_set to {P-OID}." > Has anyone ever formally analyzed it, or even translated it directly > to an executable language so we can see if it crashes or runs? >=20 > That pseudocode also requires support for CRLs, and the realtime > fetching of CRLs, which apparently has been all but abandoned in real > life (so I heard on this list). Do we intend to require CRL > processing for DANE-supported TLS? If not, we can't reference this > RFC 5280 pseudocode as the master reference for the algorithm our > implementers should follow. >=20 > If and when we do choose to invoke that pseudocode, we should > formalize the arguments to it (e.g. when the TLSA record(s) say XXX, > and the set of preconfigured trust anchors is YYY, then the inputs to > the pseudocode in section 6.1 are exactly X, Y, and Z). And if DANE > requires modifications to that pseudocode, e.g. to interleave TLSA > processing with certificate processing, then we should be extremely > precise about what those mods are. (Of course, patching "diffs" into > a complex piece of code is likely to make it even more broken than it > was, unless very carefully done. Especially if you have no way to run > it, no way to debug it, and no automated test cases for it.) >=20 > For many reasons, I don't think that DANE should require that > anybody use that 20+ pages of pseudocode. As Jim Schaad has pointed > out, DANE should allow someone to put a public key (or an unsigned > certificate, i.e. a public key with some syntactic sugar around it) > into the DNS TLSA record, and provide a public key (or an unsigned > certificate) in the TLS handshake, and if the keys match, be done. > Without ever even *invoking* that error-prone PKIX validation > subroutine. >=20 > A major impetus for DANE is that enough people on the net don't trust > that whole system of error-prone certificate validation. We should > not require its use for users who wish to avoid it. For > straightforward cases, we should specifically *not* dummy-up arguments > to that validation pseudo-algorithm, and then make assumptions about > what results the algorithm would reach when processing those dummy > arguments (like saying "in which case the PKIX validation algorithm > will just verify that it is a properly formed self-signed > certificate"). I know you *think* it'll do that, Richard, but I don't > think you can prove it. >=20 > John From paul.hoffman@vpnc.org Wed Aug 24 08:42:30 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4030F21F8C26 for ; Wed, 24 Aug 2011 08:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0bVSG1kQtTdJ for ; Wed, 24 Aug 2011 08:42:29 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id D0AB021F8C1F for ; Wed, 24 Aug 2011 08:42:29 -0700 (PDT) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p7OFhW3I046087 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 24 Aug 2011 08:43:33 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <00a101cc61e7$d9348820$8b9d9860$@augustcellars.com> Date: Wed, 24 Aug 2011 08:43:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0800A44C-382E-4843-8458-DA7AB3B2E6FD@vpnc.org> References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> <54C1B56E-7673-4F32-8E7B-25959C121A03@bbn.com> <91A5DF74-6DCB-4530-96A4-46786AB62FCB@vpnc.org> <008e01cc61ca$7748ce90$65da6bb0$@augustcellars.com> <00a101cc61e7$d9348820$8b9d9860$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1244.3) Cc: 'dane issue tracker' , 'DANE WG' Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 24 Aug 2011 15:42:30 -0000 On Aug 23, 2011, at 3:56 PM, Jim Schaad wrote: > To me that is chains through X - the text is "chain to or through" OK, then I misunderstood your question. Do you have an issue with the = TLSA certificate identifying the trust anchor? --Paul Hoffman From paul.hoffman@vpnc.org Wed Aug 24 08:52:44 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22BEE21F8C4E for ; Wed, 24 Aug 2011 08:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tkz2exOdD9Yp for ; Wed, 24 Aug 2011 08:52:43 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9667B21F8C48 for ; Wed, 24 Aug 2011 08:52:43 -0700 (PDT) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p7OFrmNv049792 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 24 Aug 2011 08:53:48 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <008e01cc61ca$7748ce90$65da6bb0$@augustcellars.com> Date: Wed, 24 Aug 2011 08:53:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> <54C1B56E-7673-4F32-8E7B-25959C121A03@bbn.com> <91A5DF74-6DCB-4530-96A4-46786AB62FCB@vpnc.org> <008e01cc61ca$7748ce90$65da6bb0$@augustcellars.com> To: DANE WG X-Mailer: Apple Mail (2.1244.3) Cc: dane issue tracker Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 24 Aug 2011 15:52:44 -0000 I'm happy with #3 and believe that it will be easier to get the wording = right with it than with our current text. The other two proposals are = also workable, but #3 feels easier to document. #3 is also much closer than the other two proposals to what this WG has = agreed on as the use cases we are aiming at. I disagree with people who think that this WG can affect how TLS uses = PKIX. If you believe that TLS's use of PKIX is wrong, take it to the TLS = WG. I think this WG needs to eventually provide a way to match any = standards-track identification used in TLS. We should not try to predict = how the TLS WG will standardize non-PKIX keys, but we should not do = anything that would make them hard to use in TLSA. --Paul Hoffman= From ietf@augustcellars.com Wed Aug 24 10:34:19 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27E4421F8B9D for ; Wed, 24 Aug 2011 10:34:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.337 X-Spam-Level: X-Spam-Status: No, score=-3.337 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UmPoyZ3KJJJv for ; Wed, 24 Aug 2011 10:34:18 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4B221F8B9B for ; Wed, 24 Aug 2011 10:34:18 -0700 (PDT) Received: from TITUS (176.120.168.69.static.onlinenw.com [69.168.120.176]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id E3C312CA1C; Wed, 24 Aug 2011 10:35:28 -0700 (PDT) From: "Jim Schaad" To: "'John Gilmore'" , "'Richard L. Barnes'" References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> <54C1B56E-7673-4F32-8E7B-25959C121A03@bbn.com> <91A5DF74-6DCB-4530-96A4-46786AB62FCB@vpnc.org> <5F91C397-05BE-4A8A-A5DD-B02B0A832C21@kumari.net> <201108232257.p7NMv886004365@new.toad.com> <201108240930.p7O9Ux86019874@new.toad.com> In-Reply-To: <201108240930.p7O9Ux86019874@new.toad.com> Date: Wed, 24 Aug 2011 11:10:34 -0700 Message-ID: <011d01cc6289$1ee18700$5ca49500$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQHwXbPL2/IzPDFsf9e9Pk9vZhBFJQMMON3xAq/8BzAA6q5ZtAEt7WdeAgh00uACAAlkZgJmTdLclHI5nGA= Cc: 'DANE WG' , 'Paul Hoffman' , 'dane issue tracker' Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 24 Aug 2011 17:34:19 -0000 > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of > John Gilmore > Sent: Wednesday, August 24, 2011 2:31 AM > To: Richard L. Barnes > Cc: Paul Hoffman; dane issue tracker; DANE WG > Subject: Re: [dane] #29: Request new Reference Type - Public Key > > Richard, thank you for the clarifications. > > > Sorry, it was understood that "standard PKIX validation" is the process > described in RFC 5280: > > > > That's more than 20 pages of pseudocode -- which starts off with a basic > assumption that there is some a-priori set of "trust anchors". > It does provide an algorithm in 6.1 that takes a single trust anchor and a > certificate list and attempts to validate it. But it is quite vague (e.g. in section > 6.2) about how or whether the algorithm iterates through these trust > anchors, perhaps trying each one, perhaps not. RFC 5280 does not provide > an algorithm that takes a (possibly null or unitary, or multiple) vector of trust > anchors and validates a certificate list with respect to that vector. And it says > little or nothing about where these trust anchors come from. There's a lot of > arm-waving going on in that RFC. > > It's really crufty pseudocode, too, with statements like "For each P-OID in the > user-initial-policy-set that is not the valid_policy of a node in the > valid_policy_node_set, create a child node whose parent is the node of > depth n-1 with the valid_policy anyPolicy. Set the values in the child node as > follows: set the valid_policy to P-OID, set the qualifier_set to P-Q, and set > the expected_policy_set to {P-OID}." > Has anyone ever formally analyzed it, or even translated it directly to an > executable language so we can see if it crashes or runs? > > That pseudocode also requires support for CRLs, and the realtime fetching of > CRLs, which apparently has been all but abandoned in real life (so I heard on > this list). Do we intend to require CRL processing for DANE-supported TLS? If > not, we can't reference this RFC 5280 pseudocode as the master reference > for the algorithm our implementers should follow. > > If and when we do choose to invoke that pseudocode, we should formalize > the arguments to it (e.g. when the TLSA record(s) say XXX, and the set of > preconfigured trust anchors is YYY, then the inputs to the pseudocode in > section 6.1 are exactly X, Y, and Z). And if DANE requires modifications to > that pseudocode, e.g. to interleave TLSA processing with certificate > processing, then we should be extremely precise about what those mods > are. (Of course, patching "diffs" into a complex piece of code is likely to > make it even more broken than it was, unless very carefully done. Especially > if you have no way to run it, no way to debug it, and no automated test cases > for it.) > > For many reasons, I don't think that DANE should require that anybody use > that 20+ pages of pseudocode. As Jim Schaad has pointed out, DANE should > allow someone to put a public key (or an unsigned certificate, i.e. a public key > with some syntactic sugar around it) into the DNS TLSA record, and provide a > public key (or an unsigned > certificate) in the TLS handshake, and if the keys match, be done. > Without ever even *invoking* that error-prone PKIX validation subroutine. Jim Schaad also things that doing standard PKIX validation is a well understood and doable process. He has also said that in many circumstances the fact that a trust anchor is being advertised in DANE is not a good reason for accepting it. So He is not totally on your side in many issues. > > A major impetus for DANE is that enough people on the net don't trust that > whole system of error-prone certificate validation. We should not require its > use for users who wish to avoid it. For straightforward cases, we should > specifically *not* dummy-up arguments to that validation pseudo-algorithm, > and then make assumptions about what results the algorithm would reach > when processing those dummy arguments (like saying "in which case the > PKIX validation algorithm will just verify that it is a properly formed self- > signed certificate"). I know you *think* it'll do that, Richard, but I don't think > you can prove it. > > John > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From ietf@augustcellars.com Wed Aug 24 10:37:20 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D55721F8BDE for ; Wed, 24 Aug 2011 10:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.366 X-Spam-Level: X-Spam-Status: No, score=-3.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3dBwkRjSgLI for ; Wed, 24 Aug 2011 10:37:20 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id E830921F8B2A for ; Wed, 24 Aug 2011 10:37:19 -0700 (PDT) Received: from TITUS (176.120.168.69.static.onlinenw.com [69.168.120.176]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 8AFFB38F33; Wed, 24 Aug 2011 10:38:30 -0700 (PDT) From: "Jim Schaad" To: "'Paul Hoffman'" References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> <54C1B56E-7673-4F32-8E7B-25959C121A03@bbn.com> <91A5DF74-6DCB-4530-96A4-46786AB62FCB@vpnc.org> <008e01cc61ca$7748ce90$65da6bb0$@augustcellars.com> <00a101cc61e7$d9348820$8b9d9860$@augustcellars.com> <0800A44C-382E-4843-8458-DA7AB3B2E6FD@vpnc.org> In-Reply-To: <0800A44C-382E-4843-8458-DA7AB3B2E6FD@vpnc.org> Date: Wed, 24 Aug 2011 11:13:35 -0700 Message-ID: <011e01cc6289$8b06c4e0$a1144ea0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQHwXbPL2/IzPDFsf9e9Pk9vZhBFJQMMON3xAq/8BzAA6q5ZtAI1VgtCAfprM5gB1aomXAHwAwZClG909dA= Cc: 'dane issue tracker' , 'DANE WG' Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 24 Aug 2011 17:37:20 -0000 No I think that you can define a trust anchor w/ TLSA - but that would be item # 3 not item #2. Jim > -----Original Message----- > From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] > Sent: Wednesday, August 24, 2011 8:44 AM > To: Jim Schaad > Cc: 'DANE WG'; 'dane issue tracker' > Subject: Re: [dane] #29: Request new Reference Type - Public Key > > On Aug 23, 2011, at 3:56 PM, Jim Schaad wrote: > > > To me that is chains through X - the text is "chain to or through" > > OK, then I misunderstood your question. Do you have an issue with the TLSA > certificate identifying the trust anchor? > > --Paul Hoffman From zack.weinberg@gmail.com Wed Aug 24 12:47:18 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F11321F8CE7 for ; Wed, 24 Aug 2011 12:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovMVNSRaNntX for ; Wed, 24 Aug 2011 12:47:18 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id F2FF221F8C98 for ; Wed, 24 Aug 2011 12:47:17 -0700 (PDT) Received: by pzk33 with SMTP id 33so2962674pzk.18 for ; Wed, 24 Aug 2011 12:48:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=QgzM3lxwXFK/xevLRQPOCEwIc3iEcc55TLmloqZSUPw=; b=DMTZt12pyd7Uarg6GhnzaLKtFxsJdvssP3iE9Lw/9eYK99zn1Ru8KfZ2Yf9p+TjKVD EExPXMQpJU36zTvt+Dxg+rpAxSojxKI56nk2/iW/h1ZqFmIdn/w/13kn6P0iykX6h6cJ x9lWLUIxBW23CRd1ERSFa0Fe7X0k8T5WhFKTc= MIME-Version: 1.0 Received: by 10.142.155.6 with SMTP id c6mr2888200wfe.240.1314215309157; Wed, 24 Aug 2011 12:48:29 -0700 (PDT) Sender: zack.weinberg@gmail.com Received: by 10.68.63.228 with HTTP; Wed, 24 Aug 2011 12:48:29 -0700 (PDT) In-Reply-To: <53EB605F-9859-4529-8641-F70A2C5038CD@bbn.com> References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> <54C1B56E-7673-4F32-8E7B-25959C121A03@bbn.com> <91A5DF74-6DCB-4530-96A4-46786AB62FCB@vpnc.org> <5F91C397-05BE-4A8A-A5DD-B02B0A832C21@kumari.net> <201108232257.p7NMv886004365@new.toad.com> <201108240930.p7O9Ux86019874@new.toad.com> <53EB605F-9859-4529-8641-F70A2C5038CD@bbn.com> Date: Wed, 24 Aug 2011 12:48:29 -0700 X-Google-Sender-Auth: g1yBPl7Km3lFkCYMn4FDMCZ42fc Message-ID: From: Zack Weinberg To: "Richard L. Barnes" Content-Type: text/plain; charset=UTF-8 Cc: Paul Hoffman , DANE WG , dane issue tracker Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 24 Aug 2011 19:47:18 -0000 On Wed, Aug 24, 2011 at 6:05 AM, Richard L. Barnes wrote: > I don't think re-visiting the concept of PKIX validation is in scope for this group. > For better or worse, that's the starting point for what we're doing. I see no _technical_ reason why DANE cannot specify that, when DANE-compliant clients detect TLSA records, they are to follow a novel certificate matching algorithm specified by DANE rather than the legacy algorithm used for in-band certificates. I agree with John and Peter: PKIX validation is a big ball of hair, it's poorly specified, and actual implementations don't follow the specification. If we can offer a tightly specified, easy-to-implement alternative in DANE that is going to be a selling point. zw From Jeff.Hodges@KingsMountain.com Wed Aug 24 13:04:29 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEFC321F8B36 for ; Wed, 24 Aug 2011 13:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.985 X-Spam-Level: X-Spam-Status: No, score=-100.985 tagged_above=-999 required=5 tests=[AWL=-0.490, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1w8Uth0L1Ka for ; Wed, 24 Aug 2011 13:04:29 -0700 (PDT) Received: from oproxy3-pub.bluehost.com (oproxy3.bluehost.com [IPv6:2605:dc00:100:2::a3]) by ietfa.amsl.com (Postfix) with SMTP id 5950B21F8B1D for ; Wed, 24 Aug 2011 13:04:29 -0700 (PDT) Received: (qmail 21819 invoked by uid 0); 24 Aug 2011 20:05:39 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy3.bluehost.com with SMTP; 24 Aug 2011 20:05:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=oXSx8enDQITBNL1JqY+Jk2ROObbzqD6gjweYI0QIXE8=; b=7pgAbGLtwRshELmXcv+9qcnD07T9VXV2dpZCUN4Q4GdGcEa5LWbLZzWGsiLdGw1bTCDLpXtzjhjaR5J8zgbhcemfE6SvnjRLtiFUoNfWYnAcTEGGsgGPq1zz+Lh2FgK1; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.136.235]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1QwJhj-0001j6-50 for dane@ietf.org; Wed, 24 Aug 2011 14:05:39 -0600 Message-ID: <4E555993.2040500@KingsMountain.com> Date: Wed, 24 Aug 2011 13:05:39 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: IETF DANE WG list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 24 Aug 2011 20:04:30 -0000 > I'm happy with #3 and believe that it will be easier to get the wording > right with it than with our current text. The other two proposals are also > workable, but #3 feels easier to document. > > #3 is also much closer than the other two proposals to what this WG has > agreed on as the use cases we are aiming at. +1 > I think this WG needs to eventually provide a way to match any > standards-track identification used in TLS. We should not try to predict how > the TLS WG will standardize non-PKIX keys, but we should not do anything > that would make them hard to use in TLSA. +1 HTH, =JeffH From paul.hoffman@vpnc.org Wed Aug 24 13:20:06 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA9BB21F8ACA for ; Wed, 24 Aug 2011 13:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.645 X-Spam-Level: X-Spam-Status: No, score=-102.645 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVpHYdqQD1F1 for ; Wed, 24 Aug 2011 13:20:06 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0B11F21F8C1D for ; Wed, 24 Aug 2011 13:20:05 -0700 (PDT) Received: from sn87.proper.com (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p7OKLCBd039835 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 24 Aug 2011 13:21:13 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Wed, 24 Aug 2011 13:21:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> <54C1B56E-7673-4F32-8E7B-25959C121A03@bbn.com> <91A5DF74-6DCB-4530-96A4-46786AB62FCB@vpnc.org> <5F91C397-05BE-4A8A-A5DD-B02B0A832C21@kumari.net> <201108232257.p7NMv886004365@new.toad.com> <201108240930.p7O9Ux86019874@new.toad.com> <53EB605F-9859-4529-8641-F70A2C5038CD@bbn.com> To: Zack Weinberg X-Mailer: Apple Mail (2.1244.3) Cc: dane issue tracker , DANE WG Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 24 Aug 2011 20:20:06 -0000 On Aug 24, 2011, at 12:48 PM, Zack Weinberg wrote: > I see no _technical_ reason why DANE cannot specify that, when > DANE-compliant clients detect TLSA records, they are to follow a novel > certificate matching algorithm specified by DANE rather than the > legacy algorithm used for in-band certificates. Me neither. The WG has to agree on the mechanism, of course, but we = should not prevent such a thing. > I agree with John and Peter: PKIX validation is a big ball of hair, > it's poorly specified, and actual implementations don't follow the > specification. If we can offer a tightly specified, easy-to-implement > alternative in DANE that is going to be a selling point. Exact matching of a non-PKIX public key structure from TLS to the same = structure (or a hash of it) from TLSA seems about as simple as you can = get. --Paul Hoffman From zack.weinberg@gmail.com Wed Aug 24 14:13:05 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBD7421F8D2A for ; Wed, 24 Aug 2011 14:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hoiAwUVK5TQ1 for ; Wed, 24 Aug 2011 14:13:05 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 25C2E21F8CE6 for ; Wed, 24 Aug 2011 14:13:05 -0700 (PDT) Received: by gxk19 with SMTP id 19so1412073gxk.31 for ; Wed, 24 Aug 2011 14:14:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=WDF5lAY0GfAKDQEt8AV1kGng3iB8VFJMaNov3VlPha4=; b=kHgaZJWuh48ZOCANCh5Jm4zsfAot5tThSlgU3BES50IMU9WEX90TX2hWIon8yKCPOu zzWVwwCDfaFAHvb0GCwIXth4GU+q/cO/mD5ZLnDW5xujIgi16ACHrQb6iaUt85g1UqkH sxkLckx/PmSNKzdGHSTs4CQcLaNxFQ0vawv4Y= Received: by 10.101.212.15 with SMTP id o15mr5148997anq.103.1314220456392; Wed, 24 Aug 2011 14:14:16 -0700 (PDT) Received: from visnet-136.csl.sri.com (visnet-136.csl.sri.com [130.107.98.136]) by mx.google.com with ESMTPS id c40sm1220249anp.0.2011.08.24.14.14.14 (version=SSLv3 cipher=OTHER); Wed, 24 Aug 2011 14:14:15 -0700 (PDT) Sender: Zack Weinberg Message-ID: <4E5569A5.1070900@sv.cmu.edu> Date: Wed, 24 Aug 2011 14:14:13 -0700 From: Zack Weinberg User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Paul Hoffman , dane@ietf.org, bsmith@mozilla.org References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> <54C1B56E-7673-4F32-8E7B-25959C121A03@bbn.com> <91A5DF74-6DCB-4530-96A4-46786AB62FCB@vpnc.org> <5F91C397-05BE-4A8A-A5DD-B02B0A832C21@kumari.net> <201108232257.p7NMv886004365@new.toad.com> <201108240930.p7O9Ux86019874@new.toad.com> <53EB605F-9859-4529-8641-F70A2C5038CD@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [dane] Matching entire non-end-entity certs (was Re: #29: Request new Reference Type - Public Key) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 24 Aug 2011 21:13:05 -0000 On 2011-08-24 1:21 PM, Paul Hoffman wrote: > On Aug 24, 2011, at 12:48 PM, Zack Weinberg wrote: >> I see no _technical_ reason why DANE cannot specify that, when >> DANE-compliant clients detect TLSA records, they are to follow a novel >> certificate matching algorithm specified by DANE rather than the >> legacy algorithm used for in-band certificates. > > Me neither. The WG has to agree on the mechanism, of course, but > we should not prevent such a thing. Good to hear. >> I agree with John and Peter: PKIX validation is a big ball of hair, >> it's poorly specified, and actual implementations don't follow the >> specification. If we can offer a tightly specified, easy-to-implement >> alternative in DANE that is going to be a selling point. > > Exact matching of a non-PKIX public key structure from TLS to the > same structure (or a hash of it) from TLSA seems about as simple > as you can get. There is one wrinkle that I am worried about: it's not quite the same thing as what we were talking about here, but I'm informed by Brian Smith of Mozilla (cc:ed) that matching TLSA records against entire non-end-entity certificates may not be reliable in practice, because of the following scenario: Suppose server E presents this chain in its TLS handshake EE <-- B <-- A where EE is the end-entity certificate, and B and A are CA certificates, A being in the legacy trust-anchor pool. However, the client has in the recent past connected to server F, which presented this chain FF <-- B' <-- A where FF is a completely unrelated end-entity certificate, but B' is a *variant* of B that has the same SubjectPublicKeyInfo but different ancillary data. Well, the client may decide to evaluate the TLS chain *for E* as if it had been EE <-- B' <-- A At which point, if F's TLSA record was B or hash(B) instead of SPKI(B) or hash(SPKI(B)), we get a mismatch which was not intended by the server operator. I personally would be okay with resolving this problem by adding a line reading "DANE clients MUST apply [our matching algorithm] to the certificate chain presented by the server they are presently talking to, not any modification of it based on local information, except that any locally-configured certificate blacklist SHOULD be honored" (or words to that effect) to the RFC, but I have a suspicion that Brian will say that's going to be very hard to implement...? Failing that, it may be that we should specify _only_ SPKI(cert) and hash(SPKI(cert)) records, not entire-cert and hash(entire-cert) records. zw From ietf@augustcellars.com Wed Aug 24 17:32:32 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6A8121F8B39 for ; Wed, 24 Aug 2011 17:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YhhYckz29J6V for ; Wed, 24 Aug 2011 17:32:32 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 07D9E21F8B38 for ; Wed, 24 Aug 2011 17:32:31 -0700 (PDT) Received: from TITUS (50-39-220-175.bvtn.or.frontiernet.net [50.39.220.175]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id C4D002CA22; Wed, 24 Aug 2011 17:33:43 -0700 (PDT) From: "Jim Schaad" To: "'Zack Weinberg'" , , References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> <54C1B56E-7673-4F32-8E7B-25959C121A03@bbn.com> <91A5DF74-6DCB-4530-96A4-46786AB62FCB@vpnc.org> <5F91C397-05BE-4A8A-A5DD-B02B0A832C21@kumari.net> <201108232257.p7NMv886004365@new.toad.com> <201108240930.p7O9Ux86019874@new.toad.com> <53EB605F-9859-4529-8641-F70A2C5038CD@bbn.com> <4E5569A5.1070900@sv.cmu.edu> In-Reply-To: <4E5569A5.1070900@sv.cmu.edu> Date: Wed, 24 Aug 2011 18:08:49 -0700 Message-ID: <016501cc62c3$8c599e50$a50cdaf0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQHwXbPL2/IzPDFsf9e9Pk9vZhBFJQMMON3xAq/8BzAA6q5ZtAEt7WdeAgh00uACAAlkZgJmTdLcApBd05gCzK4T+wEJOgTEAjw+nvmULZnVUA== Subject: Re: [dane] Matching entire non-end-entity certs (was Re: #29: Request new Reference Type - Public Key) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 25 Aug 2011 00:32:32 -0000 This is and always has been a potential problem with any system where a client wants to impose additional restrictions on path construction where the code being used does not permit any client input into the process. In this case there are multiple valid paths, at least from the point of view of the path construction code, and the additional restrictions that need to be added by the client are not allowed as inputs to the Mozilla code. The same thing can be true for enforcement extensions in the path which is not supported by the base code. This is one of the reasons why path construction code needs to either return all paths for later checking by the client or allow for the client to impose itself in the path construction code. I do not consider this to be an issue that DANE needs to solve. Jim > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of > Zack Weinberg > Sent: Wednesday, August 24, 2011 2:14 PM > To: Paul Hoffman; dane@ietf.org; bsmith@mozilla.org > Subject: [dane] Matching entire non-end-entity certs (was Re: #29: Request > new Reference Type - Public Key) > > On 2011-08-24 1:21 PM, Paul Hoffman wrote: > > On Aug 24, 2011, at 12:48 PM, Zack Weinberg wrote: > >> I see no _technical_ reason why DANE cannot specify that, when > >> DANE-compliant clients detect TLSA records, they are to follow a > >> novel certificate matching algorithm specified by DANE rather than > >> the legacy algorithm used for in-band certificates. > > > > Me neither. The WG has to agree on the mechanism, of course, but > > we should not prevent such a thing. > > Good to hear. > > >> I agree with John and Peter: PKIX validation is a big ball of hair, > >> it's poorly specified, and actual implementations don't follow the > >> specification. If we can offer a tightly specified, > >> easy-to-implement alternative in DANE that is going to be a selling point. > > > > Exact matching of a non-PKIX public key structure from TLS to the > > same structure (or a hash of it) from TLSA seems about as simple > as you > can get. > > There is one wrinkle that I am worried about: it's not quite the same thing as > what we were talking about here, but I'm informed by Brian Smith of Mozilla > (cc:ed) that matching TLSA records against entire non-end-entity certificates > may not be reliable in practice, because of the following scenario: Suppose > server E presents this chain in its TLS handshake > > EE <-- B <-- A > > where EE is the end-entity certificate, and B and A are CA certificates, A being > in the legacy trust-anchor pool. However, the client has in the recent past > connected to server F, which presented this chain > > FF <-- B' <-- A > > where FF is a completely unrelated end-entity certificate, but B' is a > *variant* of B that has the same SubjectPublicKeyInfo but different ancillary > data. Well, the client may decide to evaluate the TLS chain *for E* as if it had > been > > EE <-- B' <-- A > > At which point, if F's TLSA record was B or hash(B) instead of SPKI(B) or > hash(SPKI(B)), we get a mismatch which was not intended by the server > operator. > > I personally would be okay with resolving this problem by adding a line > reading "DANE clients MUST apply [our matching algorithm] to the certificate > chain presented by the server they are presently talking to, not any > modification of it based on local information, except that any locally- > configured certificate blacklist SHOULD be honored" (or words to that effect) > to the RFC, but I have a suspicion that Brian will say that's going to be very > hard to implement...? Failing that, it may be that we should specify _only_ > SPKI(cert) and hash(SPKI(cert)) records, not entire-cert and hash(entire-cert) > records. > > zw > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From rbarnes@bbn.com Wed Aug 24 18:35:54 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 147A021F8A69 for ; Wed, 24 Aug 2011 18:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.604 X-Spam-Level: X-Spam-Status: No, score=-106.604 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RG26pH3Wl7S2 for ; Wed, 24 Aug 2011 18:35:53 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7B121F8A67 for ; Wed, 24 Aug 2011 18:35:53 -0700 (PDT) Received: from [128.89.255.198] (port=51759 helo=[192.168.1.12]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QwOsQ-000EOO-IV; Wed, 24 Aug 2011 21:37:03 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <53597CBD-8E3F-4A66-98BE-720C609B2B0C@kirei.se> Date: Wed, 24 Aug 2011 21:36:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> <54C1B56E-7673-4F32-8E7B-25959C121A03@bbn.com> <91A5DF74-6DCB-4530-96A4-46786AB62FCB@vpnc.org> <5F91C397-05BE-4A8A-A5DD-B02B0A832C21@kumari.net> <53597CBD-8E3F-4A66-98BE-720C609B2B0C@kirei.se> To: Jakob Schlyter X-Mailer: Apple Mail (2.1082) Cc: Paul Hoffman , DANE WG Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 25 Aug 2011 01:35:54 -0000 It's not really clear why you need all six. It seems like (3,4,5) is = just (0,1,2) with the SPKI reference type. With that reference type = "match the TLSA record" means that the SPKI in the cert equals the SPKI = in the TLSA. --Richard On Aug 24, 2011, at 4:07 AM, Jakob Schlyter wrote: > On 23 aug 2011, at 22:36, Warren Kumari wrote: >=20 >> In order to help focus the discussions (and provide guidance to our = authors), I'm asking the WG to please indicate a preference for text = based on: >>=20 >> 1: The current wording. >>=20 >> 2: The proposed split (based upon Jim's suggestion ( = http://www.ietf.org/mail-archive/web/dane/current/msg03223.html )) >>=20 >> 3: Richard's "very different" proposal (outlined below). >=20 > I like 3, but I also see some problems with this approach. In the = current wording, we have a very simple structure where the certificate = type (describing what to compare) is independent of the reference type = (how to compare it) and I'd recommend that we try to keep this split. In = Richards proposal, the reference type is depending on the certificate = type. This effectively means that not all reference types are good for a = given certificate type, making it more complex to use and implement. >=20 > My preference is to go with Rickard's RP-centric = certificate/association types, but add separate types where the input to = the comparison function (the reference type) is the = SubjectPublicKeyInfo. This would keep the reference type generic = (identity comparison or hash comparison) and ease future extensions = (e.g. PGP). >=20 > - 0. Certificate MUST pass PKIX validation and MUST chain through a CA = certificate matching the TLSA record > - 1. Certificate MUST pass PKIX validation and MUST match the TLSA = record > - 2. Certificate MUST pass PKIX validation, with any certificate = matching the TLSA record considered to be a trust anchor for this = validation > - 3. as (0) but the comparison is done using SubjectPublicKeyInfo > - 4. as (1) but the comparison is done using SubjectPublicKeyInfo > - 5. as (2) but the comparison is done using SubjectPublicKeyInfo >=20 > N.B.: an association type of 2 or 5 with a reference type other than 0 = wouldn't be very useful unless the TLS server provides a full = certificate chain (form the EE to the CA). >=20 >=20 > jakob >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From jakob@kirei.se Thu Aug 25 00:04:35 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C15121F8B0D for ; Thu, 25 Aug 2011 00:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.628 X-Spam-Level: X-Spam-Status: No, score=-0.628 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yc9TjwVTdjny for ; Thu, 25 Aug 2011 00:04:33 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id D14C121F8B1D for ; Thu, 25 Aug 2011 00:04:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=uFLUDLO2OQUjliTLD1AfTDl4MeHr0ax0Ecd/+0RLLYM=; b=MbsNrvbnD/JSXC9l/F8SKXvmr9haEm5BC7xDsTslTtsTD2GujsFCCuoERewm7mijkNXenzk7DXrl1 z49q7DHWzm48cMcJoenoviK/Vahcm6yVFeweb7Fciaoi27sMqgDxWRcB/GMc2EUGWn1MmbpuXaYBks UOMUvYRScSp8QUpo= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Thu, 25 Aug 2011 09:05:41 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: Date: Thu, 25 Aug 2011 07:26:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> <54C1B56E-7673-4F32-8E7B-25959C121A03@bbn.com> <91A5DF74-6DCB-4530-96A4-46786AB62FCB@vpnc.org> <5F91C397-05BE-4A8A-A5DD-B02B0A832C21@kumari.net> <53597CBD-8E3F-4A66-98BE-720C609B2B0C@kirei.se> To: Richard L. Barnes X-Mailer: Apple Mail (2.1244.3) Cc: Paul Hoffman , DANE WG Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 25 Aug 2011 07:04:35 -0000 On 25 aug 2011, at 03:36, Richard L. Barnes wrote: > It's not really clear why you need all six. It seems like (3,4,5) is = just (0,1,2) with the SPKI reference type. With that reference type = "match the TLSA record" means that the SPKI in the cert equals the SPKI = in the TLSA. In the current draft, the matching type is either the identity = transformation or a hash transformation on the data indicated by the = certificate type. This is simple and is easy to reuse for future = certificate types (e.g. PGP). In your proposal - if I understand it = correctly - the reference type depends on the certificate type, i.e. it = is not only a transformation before comparison as it can also be = "extract the SubjectPublicKeyInfo and hash the contents using sha256". I'd like us to try and keep the simplicity of the old proposal, and I = believe it would be wise the keep the hash algorithm separate from the = rest of the logic. This can be achieved either by moving the CERT/SPKI = selection into certificate type, or by adding a subtype to the = certificate type. The former is what I presented in my previous mail: - 0. Certificate MUST pass PKIX validation and MUST chain through a CA = certificate matching the TLSA record - 1. Certificate MUST pass PKIX validation and MUST match the TLSA = record - 2. Certificate MUST pass PKIX validation, with any certificate = matching the TLSA record considered to be a trust anchor for this = validation - 3. as (0) but the comparison is done using SubjectPublicKeyInfo - 4. as (1) but the comparison is done using SubjectPublicKeyInfo - 5. as (2) but the comparison is done using SubjectPublicKeyInfo The latter could be done by having separate RDATA fields for - certificate type; aka usage (i.e., 0/1/2 in your proposal) - selector; CERT or SPKI - matching type; identity or various hash algorithms In short; I like your proposal but do keep the reference type field to = plain identity/hash and the CERT/SPKI selector separate. jakob From paul@xelerance.com Thu Aug 25 07:30:16 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C711921F86C0 for ; Thu, 25 Aug 2011 07:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.48 X-Spam-Level: X-Spam-Status: No, score=-6.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9GKpQYMUNqo for ; Thu, 25 Aug 2011 07:30:16 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id 46EA921F86B3 for ; Thu, 25 Aug 2011 07:30:16 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id B980BC681; Thu, 25 Aug 2011 10:33:51 -0400 (EDT) Date: Thu, 25 Aug 2011 10:33:51 -0400 (EDT) From: Paul Wouters To: "Richard L. Barnes" In-Reply-To: <53EB605F-9859-4529-8641-F70A2C5038CD@bbn.com> Message-ID: References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> <54C1B56E-7673-4F32-8E7B-25959C121A03@bbn.com> <91A5DF74-6DCB-4530-96A4-46786AB62FCB@vpnc.org> <5F91C397-05BE-4A8A-A5DD-B02B0A832C21@kumari.net> <201108232257.p7NMv886004365@new.toad.com> <201108240930.p7O9Ux86019874@new.toad.com> <53EB605F-9859-4529-8641-F70A2C5038CD@bbn.com> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: DANE WG , dane issue tracker Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 25 Aug 2011 14:30:16 -0000 On Wed, 24 Aug 2011, Richard L. Barnes wrote: > I don't think re-visiting the concept of PKIX validation is in scope for this group. For better or worse, that's the starting point for what we're doing. For a significant group of people, DANE is the method to get OUT of this mess, not to get in deeper. Or to paraphrase others, "we have 20 years of experience......" Paul From paul@xelerance.com Thu Aug 25 07:40:20 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEE4721F8620 for ; Thu, 25 Aug 2011 07:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.483 X-Spam-Level: X-Spam-Status: No, score=-6.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6f95A3PCH6YC for ; Thu, 25 Aug 2011 07:40:20 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id 0F4CB21F86CA for ; Thu, 25 Aug 2011 07:40:20 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 0D85BC681; Thu, 25 Aug 2011 10:43:55 -0400 (EDT) Date: Thu, 25 Aug 2011 10:43:54 -0400 (EDT) From: Paul Wouters To: "Richard L. Barnes" In-Reply-To: Message-ID: References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> <54C1B56E-7673-4F32-8E7B-25959C121A03@bbn.com> <91A5DF74-6DCB-4530-96A4-46786AB62FCB@vpnc.org> <5F91C397-05BE-4A8A-A5DD-B02B0A832C21@kumari.net> <53597CBD-8E3F-4A66-98BE-720C609B2B0C@kirei.se> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: DANE WG Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 25 Aug 2011 14:40:21 -0000 On Wed, 24 Aug 2011, Richard L. Barnes wrote: > It's not really clear why you need all six. It seems like (3,4,5) is just (0,1,2) with the SPKI reference type. With that reference type "match the TLSA record" means that the SPKI in the cert equals the SPKI in the TLSA. Not cert, public key. We can get creative and add "cert types" to TLS and DANE that are really SubjectPublicKeyInfo's, and beat around to bush with clever wording, but in the end DANE (and TLS) has to provide a method for TLS SubjectPublicKeyInfo identification without certificates, no matter what those people are left with to use as container. Paul > --Richard > > > > On Aug 24, 2011, at 4:07 AM, Jakob Schlyter wrote: > >> On 23 aug 2011, at 22:36, Warren Kumari wrote: >> >>> In order to help focus the discussions (and provide guidance to our authors), I'm asking the WG to please indicate a preference for text based on: >>> >>> 1: The current wording. >>> >>> 2: The proposed split (based upon Jim's suggestion ( http://www.ietf.org/mail-archive/web/dane/current/msg03223.html )) >>> >>> 3: Richard's "very different" proposal (outlined below). >> >> I like 3, but I also see some problems with this approach. In the current wording, we have a very simple structure where the certificate type (describing what to compare) is independent of the reference type (how to compare it) and I'd recommend that we try to keep this split. In Richards proposal, the reference type is depending on the certificate type. This effectively means that not all reference types are good for a given certificate type, making it more complex to use and implement. >> >> My preference is to go with Rickard's RP-centric certificate/association types, but add separate types where the input to the comparison function (the reference type) is the SubjectPublicKeyInfo. This would keep the reference type generic (identity comparison or hash comparison) and ease future extensions (e.g. PGP). >> >> - 0. Certificate MUST pass PKIX validation and MUST chain through a CA certificate matching the TLSA record >> - 1. Certificate MUST pass PKIX validation and MUST match the TLSA record >> - 2. Certificate MUST pass PKIX validation, with any certificate matching the TLSA record considered to be a trust anchor for this validation >> - 3. as (0) but the comparison is done using SubjectPublicKeyInfo >> - 4. as (1) but the comparison is done using SubjectPublicKeyInfo >> - 5. as (2) but the comparison is done using SubjectPublicKeyInfo >> >> N.B.: an association type of 2 or 5 with a reference type other than 0 wouldn't be very useful unless the TLS server provides a full certificate chain (form the EE to the CA). >> >> >> jakob >> >> _______________________________________________ >> 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 paul@xelerance.com Thu Aug 25 07:42:21 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D351221F8804 for ; Thu, 25 Aug 2011 07:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.485 X-Spam-Level: X-Spam-Status: No, score=-6.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-ciAJRDxfqo for ; Thu, 25 Aug 2011 07:42:20 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id 56B3C21F86FF for ; Thu, 25 Aug 2011 07:42:20 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 8CB34C681; Thu, 25 Aug 2011 10:45:56 -0400 (EDT) Date: Thu, 25 Aug 2011 10:45:56 -0400 (EDT) From: Paul Wouters To: Jakob Schlyter In-Reply-To: Message-ID: References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> <54C1B56E-7673-4F32-8E7B-25959C121A03@bbn.com> <91A5DF74-6DCB-4530-96A4-46786AB62FCB@vpnc.org> <5F91C397-05BE-4A8A-A5DD-B02B0A832C21@kumari.net> <53597CBD-8E3F-4A66-98BE-720C609B2B0C@kirei.se> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Paul Hoffman , DANE WG Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 25 Aug 2011 14:42:21 -0000 On Thu, 25 Aug 2011, Jakob Schlyter wrote: > In the current draft, the matching type is either the identity transformation or a hash transformation on the data indicated by the certificate type. This is simple and is easy to reuse for future certificate types (e.g. PGP). In your proposal - if I understand it correctly - the reference type depends on the certificate type, i.e. it is not only a transformation before comparison as it can also be "extract the SubjectPublicKeyInfo and hash the contents using sha256". > > I'd like us to try and keep the simplicity of the old proposal, and I believe it would be wise the keep the hash algorithm separate from the rest of the logic. This can be achieved either by moving the CERT/SPKI selection into certificate type, or by adding a subtype to the certificate type. The former is what I presented in my previous mail: > > - 0. Certificate MUST pass PKIX validation and MUST chain through a CA certificate matching the TLSA record > - 1. Certificate MUST pass PKIX validation and MUST match the TLSA record > - 2. Certificate MUST pass PKIX validation, with any certificate matching the TLSA record considered to be a trust anchor for this validation > - 3. as (0) but the comparison is done using SubjectPublicKeyInfo > - 4. as (1) but the comparison is done using SubjectPublicKeyInfo > - 5. as (2) but the comparison is done using SubjectPublicKeyInfo +1 Paul From paul.hoffman@vpnc.org Thu Aug 25 08:23:28 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85BE821F8586 for ; Thu, 25 Aug 2011 08:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jdyIW4aDp+wc for ; Thu, 25 Aug 2011 08:23:28 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id E2EC221F857D for ; Thu, 25 Aug 2011 08:23:27 -0700 (PDT) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p7PFOedH057361 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 25 Aug 2011 08:24:40 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Thu, 25 Aug 2011 08:24:40 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <277BA539-7794-4B97-9D40-A235225940FB@vpnc.org> References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> <54C1B56E-7673-4F32-8E7B-25959C121A03@bbn.com> <91A5DF74-6DCB-4530-96A4-46786AB62FCB@vpnc.org> <5F91C397-05BE-4A8A-A5DD-B02B0A832C21@kumari.net> <201108232257.p7NMv886004365@new.toad.com> <201108240930.p7O9Ux86019874@new.toad.com> <53EB605F-9859-4529-8641-F70A2C5038CD@bbn.com> To: Paul Wouters X-Mailer: Apple Mail (2.1244.3) Cc: dane issue tracker , DANE WG Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 25 Aug 2011 15:23:28 -0000 On Aug 25, 2011, at 7:33 AM, Paul Wouters wrote: > On Wed, 24 Aug 2011, Richard L. Barnes wrote: >=20 >> I don't think re-visiting the concept of PKIX validation is in scope = for this group. For better or worse, that's the starting point for what = we're doing. >=20 > For a significant group of people, DANE is the method to get OUT of = this mess, not to > get in deeper. Or to paraphrase others, "we have 20 years of = experience......" The WG's use cases document covers multiple cases where DANE interacts = with TLS in ways that continue to use PKIX validation of end entity = certificates. It sounds like you are asking us to re-open the use cases = document after both WG Last Call and IETF Last Call. If so, please be = more explicit. If not, please consider allowing both "significant = groups" of people to get value of DANE instead of just your own group. --Paul Hoffman From paul.hoffman@vpnc.org Thu Aug 25 08:26:44 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 933FE21F85A4 for ; Thu, 25 Aug 2011 08:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KS1sNaQ1ssXA for ; Thu, 25 Aug 2011 08:26:44 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1B02821F8538 for ; Thu, 25 Aug 2011 08:26:44 -0700 (PDT) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p7PFRuNS058311 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 25 Aug 2011 08:27:57 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Thu, 25 Aug 2011 08:27:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> <54C1B56E-7673-4F32-8E7B-25959C121A03@bbn.com> <91A5DF74-6DCB-4530-96A4-46786AB62FCB@vpnc.org> <5F91C397-05BE-4A8A-A5DD-B02B0A832C21@kumari.net> <53597CBD-8E3F-4A66-98BE-720C609B2B0C@kirei.se> To: Paul Wouters X-Mailer: Apple Mail (2.1244.3) Cc: DANE WG Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 25 Aug 2011 15:26:44 -0000 On Aug 25, 2011, at 7:43 AM, Paul Wouters wrote: > On Wed, 24 Aug 2011, Richard L. Barnes wrote: >=20 >> It's not really clear why you need all six. It seems like (3,4,5) is = just (0,1,2) with the SPKI reference type. With that reference type = "match the TLSA record" means that the SPKI in the cert equals the SPKI = in the TLSA. >=20 > Not cert, public key. >=20 > We can get creative and add "cert types" to TLS and DANE that are = really > SubjectPublicKeyInfo's, and beat around to bush with clever wording, > but in the end DANE (and TLS) has to provide a method for TLS > SubjectPublicKeyInfo identification without certificates, no matter = what > those people are left with to use as container. If by "in the end" you mean "once there is a way in TLS to use keys that = are not part of certificates", we fully agree. However, until that time, = asking developers to be able to match something from TLSA that does not = exist in TLS seems premature. --Paul Hoffman From paul.hoffman@vpnc.org Thu Aug 25 08:55:23 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BBDF21F855A for ; Thu, 25 Aug 2011 08:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0um1A0+wEsud for ; Thu, 25 Aug 2011 08:55:22 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id BB02C21F8515 for ; Thu, 25 Aug 2011 08:55:22 -0700 (PDT) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p7PFuYk7067142 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 25 Aug 2011 08:56:36 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1244.3) From: Paul Hoffman In-Reply-To: Date: Thu, 25 Aug 2011 08:56:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <71E8458F-CC74-4AFB-B3B7-520A711F56A4@vpnc.org> References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> <54C1B56E-7673-4F32-8E7B-25959C121A03@bbn.com> <91A5DF74-6DCB-4530-96A4-46786AB62FCB@vpnc.org> <5F91C397-05BE-4A8A-A5DD-B02B0A832C21@kumari.net> <53597CBD-8E3F-4A66-98BE-720C609B2B0C@kirei.se> To: DANE WG X-Mailer: Apple Mail (2.1244.3) Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 25 Aug 2011 15:55:23 -0000 On Aug 24, 2011, at 10:26 PM, Jakob Schlyter wrote: > On 25 aug 2011, at 03:36, Richard L. Barnes wrote: >=20 >> It's not really clear why you need all six. It seems like (3,4,5) is = just (0,1,2) with the SPKI reference type. With that reference type = "match the TLSA record" means that the SPKI in the cert equals the SPKI = in the TLSA. >=20 > In the current draft, the matching type is either the identity = transformation or a hash transformation on the data indicated by the = certificate type. This is simple and is easy to reuse for future = certificate types (e.g. PGP). In your proposal - if I understand it = correctly - the reference type depends on the certificate type, i.e. it = is not only a transformation before comparison as it can also be = "extract the SubjectPublicKeyInfo and hash the contents using sha256". >=20 > I'd like us to try and keep the simplicity of the old proposal, and I = believe it would be wise the keep the hash algorithm separate from the = rest of the logic. This can be achieved either by moving the CERT/SPKI = selection into certificate type, or by adding a subtype to the = certificate type. The former is what I presented in my previous mail: >=20 > - 0. Certificate MUST pass PKIX validation and MUST chain through a CA = certificate matching the TLSA record > - 1. Certificate MUST pass PKIX validation and MUST match the TLSA = record > - 2. Certificate MUST pass PKIX validation, with any certificate = matching the TLSA record considered to be a trust anchor for this = validation > - 3. as (0) but the comparison is done using SubjectPublicKeyInfo > - 4. as (1) but the comparison is done using SubjectPublicKeyInfo > - 5. as (2) but the comparison is done using SubjectPublicKeyInfo >=20 > The latter could be done by having separate RDATA fields for >=20 > - certificate type; aka usage (i.e., 0/1/2 in your proposal) > - selector; CERT or SPKI > - matching type; identity or various hash algorithms >=20 >=20 > In short; I like your proposal but do keep the reference type field to = plain identity/hash and the CERT/SPKI selector separate. The problem we are having in agreeing on terms is that we don't agree to = the use cases for a TLSA record that has a SPKI-not-in-a-cert in it. The = most vocal proponents of providing an SPKI-not-in-a-cert is no PKIX = validation, just exact matching with the end entity certificate or = SPKI-not-in-a-cert provided in TLS. Others want to maybe also be able to = use SPKI-not-in-a-cert for the kinds of matching that will also involve = PKIX validation. My feeling is that the easiest way out of this is to let the = SPKI-not-in-a-cert folks have their own usage type that explicitly says = "SPKI-not-in-a-cert from the TLS Certificate message MUST match the TLSA = record". Using Jakob's three-part taxonomy, there would be a fourth = usage type, and any record with that usage type would have to use "SPKI" = and otherwise be ignored as bad; the matching type could be either full = or hashed. I don't think that adding a usage type that has to have a = specific selector type is that dangerous. --Paul Hoffman From paul@xelerance.com Thu Aug 25 09:01:29 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A29F21F8781 for ; Thu, 25 Aug 2011 09:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.487 X-Spam-Level: X-Spam-Status: No, score=-6.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d5VZj4t0wEmy for ; Thu, 25 Aug 2011 09:01:27 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5F1D321F8760 for ; Thu, 25 Aug 2011 09:01:27 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id F0EBCC681; Thu, 25 Aug 2011 12:05:03 -0400 (EDT) Date: Thu, 25 Aug 2011 12:05:03 -0400 (EDT) From: Paul Wouters To: Paul Hoffman In-Reply-To: <277BA539-7794-4B97-9D40-A235225940FB@vpnc.org> Message-ID: References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> <54C1B56E-7673-4F32-8E7B-25959C121A03@bbn.com> <91A5DF74-6DCB-4530-96A4-46786AB62FCB@vpnc.org> <5F91C397-05BE-4A8A-A5DD-B02B0A832C21@kumari.net> <201108232257.p7NMv886004365@new.toad.com> <201108240930.p7O9Ux86019874@new.toad.com> <53EB605F-9859-4529-8641-F70A2C5038CD@bbn.com> <277BA539-7794-4B97-9D40-A235225940FB@vpnc.org> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dane issue tracker , DANE WG Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 25 Aug 2011 16:01:29 -0000 On Thu, 25 Aug 2011, Paul Hoffman wrote: > On Aug 25, 2011, at 7:33 AM, Paul Wouters wrote: > >> On Wed, 24 Aug 2011, Richard L. Barnes wrote: >> >>> I don't think re-visiting the concept of PKIX validation is in scope for this group. For better or worse, that's the starting point for what we're doing. >> >> For a significant group of people, DANE is the method to get OUT of this mess, not to >> get in deeper. Or to paraphrase others, "we have 20 years of experience......" > > The WG's use cases document covers multiple cases where DANE interacts with TLS in ways that continue to use PKIX validation of end entity certificates. It sounds like you are asking us to re-open the use cases document after both WG Last Call and IETF Last Call. If so, please be more explicit. If not, please consider allowing both "significant groups" of people to get value of DANE instead of just your own group. "just your own group"? Where did I state that? For all I care there is a chocolate fountain option in DANE. Local client policy can always interpret what they want to use from any DANE certtype/reftype. All I am asking for is not closing the option for those people working actively on using DANE without PKIX. The current thoughts of a TLS certtype handshake message with cert type of subjectPublicKeyInfo and a matching DANE certtype/reftype not mandating PKIX CA/EE validation is all I'm asking for. Anyone who wants to create another 20 years of PKIX innovation is welcome to do so in my opinion. Was that not clear? Paul From ietf@augustcellars.com Thu Aug 25 09:01:55 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB1D21F87E2 for ; Thu, 25 Aug 2011 09:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGnS4Hwq20j0 for ; Thu, 25 Aug 2011 09:01:54 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id C8F0A21F877B for ; Thu, 25 Aug 2011 09:01:54 -0700 (PDT) Received: from TITUS (unknown [207.55.8.2]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 7DF8B2CA16; Thu, 25 Aug 2011 09:03:08 -0700 (PDT) From: "Jim Schaad" To: "'Jakob Schlyter'" , "'Richard L.Barnes'" References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> <54C1B56E-7673-4F32-8E7B-25959C121A03@bbn.com> <91A5DF74-6DCB-4530-96A4-46786AB62FCB@vpnc.org> <5F91C397-05BE-4A8A-A5DD-B02B0A832C21@kumari.net> <53597CBD-8E3F-4A66-98BE-720C609B2B0C@kirei.se> In-Reply-To: Date: Thu, 25 Aug 2011 09:38:14 -0700 Message-ID: <01d001cc6345$62c172c0$28445840$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQHwXbPL2/IzPDFsf9e9Pk9vZhBFJQMMON3xAq/8BzAA6q5ZtAEt7WdeArvAUjQCFyarxgF99AaOlHShbqA= Cc: 'Paul Hoffman' , 'DANE WG' Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 25 Aug 2011 16:01:55 -0000 I don't think that Richard has suggested that what you do for a SPKI reference is to extract and hash. One could create a match type that does that but I know that I have not suggested that. I have just said that SPKI should be an acceptable match type. The rules for the SPKI match type would need to be defined (i.e. is it identity or is it some type of smarter match), but I have not suggested extract and hash as I don't see that as being useful. That is something that would be lost, on the other hand I don't know that it is useful. Jim > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of > Jakob Schlyter > Sent: Wednesday, August 24, 2011 10:26 PM > To: Richard L.Barnes > Cc: Paul Hoffman; DANE WG > Subject: Re: [dane] #29: Request new Reference Type - Public Key > > On 25 aug 2011, at 03:36, Richard L. Barnes wrote: > > > It's not really clear why you need all six. It seems like (3,4,5) is just (0,1,2) > with the SPKI reference type. With that reference type "match the TLSA > record" means that the SPKI in the cert equals the SPKI in the TLSA. > > In the current draft, the matching type is either the identity transformation > or a hash transformation on the data indicated by the certificate type. This is > simple and is easy to reuse for future certificate types (e.g. PGP). In your > proposal - if I understand it correctly - the reference type depends on the > certificate type, i.e. it is not only a transformation before comparison as it can > also be "extract the SubjectPublicKeyInfo and hash the contents using > sha256". > > I'd like us to try and keep the simplicity of the old proposal, and I believe it > would be wise the keep the hash algorithm separate from the rest of the > logic. This can be achieved either by moving the CERT/SPKI selection into > certificate type, or by adding a subtype to the certificate type. The former is > what I presented in my previous mail: > > - 0. Certificate MUST pass PKIX validation and MUST chain through a CA > certificate matching the TLSA record > - 1. Certificate MUST pass PKIX validation and MUST match the TLSA record > - 2. Certificate MUST pass PKIX validation, with any certificate matching the > TLSA record considered to be a trust anchor for this validation > - 3. as (0) but the comparison is done using SubjectPublicKeyInfo > - 4. as (1) but the comparison is done using SubjectPublicKeyInfo > - 5. as (2) but the comparison is done using SubjectPublicKeyInfo > > The latter could be done by having separate RDATA fields for > > - certificate type; aka usage (i.e., 0/1/2 in your proposal) > - selector; CERT or SPKI > - matching type; identity or various hash algorithms > > > In short; I like your proposal but do keep the reference type field to plain > identity/hash and the CERT/SPKI selector separate. > > > jakob > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From jakob@kirei.se Thu Aug 25 10:55:55 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8F221F8C63 for ; Thu, 25 Aug 2011 10:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.63 X-Spam-Level: X-Spam-Status: No, score=-0.63 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TA6-frNUuDg7 for ; Thu, 25 Aug 2011 10:55:54 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id 1B58521F8C5D for ; Thu, 25 Aug 2011 10:55:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=AiVGClfOhq28v+Q4Pp00FzLxdYT2jcA8dTCVjtqX/e8=; b=J2Nw9k+iotrinwuvJiEphLWwKPBWw1MaNhw6Vo3uc+9Wj8HictOwvKANJEMnGWKz4GRIRR8DjsPgL 1GUsbrEpCuRq1C9YUGvFEU0WGU2DfNHFpHEt77H+HNPHoR1PHjNyd6Laq6ZIRO0WwwZlTJz4l79SpF iFzX4kKFps2bfu9k= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Thu, 25 Aug 2011 19:57:04 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: <71E8458F-CC74-4AFB-B3B7-520A711F56A4@vpnc.org> Date: Thu, 25 Aug 2011 19:57:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <833020D5-E3F1-4253-9876-B54748B92DDA@kirei.se> References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> <54C1B56E-7673-4F32-8E7B-25959C121A03@bbn.com> <91A5DF74-6DCB-4530-96A4-46786AB62FCB@vpnc.org> <5F91C397-05BE-4A8A-A5DD-B02B0A832C21@kumari.net> <53597CBD-8E3F-4A66-98BE-720C609B2B0C@kirei.se> <71E8458F-CC74-4AFB-B3B7-520A711F56A4@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1244.3) Cc: DANE WG Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 25 Aug 2011 17:55:55 -0000 On 25 aug 2011, at 17:56, Paul Hoffman wrote: > The problem we are having in agreeing on terms is that we don't agree = to the use cases for a TLSA record that has a SPKI-not-in-a-cert in it. = The most vocal proponents of providing an SPKI-not-in-a-cert is no PKIX = validation, just exact matching with the end entity certificate or = SPKI-not-in-a-cert provided in TLS. Others want to maybe also be able to = use SPKI-not-in-a-cert for the kinds of matching that will also involve = PKIX validation. Yes, I forgot about the difference between "require PKIX, match on SPKI" = and "ignore PKIX, match on SPKI" - thanks for pointing that out. > My feeling is that the easiest way out of this is to let the = SPKI-not-in-a-cert folks have their own usage type that explicitly says = "SPKI-not-in-a-cert from the TLS Certificate message MUST match the TLSA = record". Using Jakob's three-part taxonomy, there would be a fourth = usage type, and any record with that usage type would have to use "SPKI" = and otherwise be ignored as bad; the matching type could be either full = or hashed. I don't think that adding a usage type that has to have a = specific selector type is that dangerous. Given Paul's feedback, my proposal would have three fields (in addition = to the association data itself): usage: - 0. Certificate MUST pass PKIX validation and MUST chain through a CA = certificate matching the TLSA record - 1. Certificate MUST pass PKIX validation and MUST match the TLSA = record - 2. Certificate MUST pass PKIX validation, with any certificate = matching the TLSA record considered to be a trust anchor for this = validation - (future) 3. Ignore PKIX, match the TLSA record selector: - 0. Certificate - 1. SubjectPublicKeyInfo matching type: - 0. match on exact selected contents - 1. sha-256 hash of selected contents - 2. sha-512 hash of selected contents jakob From kent@bbn.com Thu Aug 25 15:38:29 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E16521F8B94 for ; Thu, 25 Aug 2011 15:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.554 X-Spam-Level: X-Spam-Status: No, score=-106.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n0WWpyyhgRiy for ; Thu, 25 Aug 2011 15:38:29 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id EC18A21F8B8D for ; Thu, 25 Aug 2011 15:38:28 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:59639 helo=[192.168.1.13]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Qwi6l-0003oZ-Ks; Thu, 25 Aug 2011 18:09:08 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> <54C1B56E-7673-4F32-8E7B-25959C121A03@bbn.com> <91A5DF74-6DCB-4530-96A4-46786AB62FCB@vpnc.org> <5F91C397-05BE-4A8A-A5DD-B02B0A832C21@kumari.net> <201108232257.p7NMv886004365@new.toad.com> <201108240930.p7O9Ux86019874@new.toad.com> <53EB605F-9859-4529-8641-F70A2C5038CD@bbn.com> Date: Thu, 25 Aug 2011 15:25:11 -0400 To: Zack Weinberg From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: dane issue tracker , Paul Hoffman , DANE WG Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 25 Aug 2011 22:38:29 -0000 At 12:48 PM -0700 8/24/11, Zack Weinberg wrote: >On Wed, Aug 24, 2011 at 6:05 AM, Richard L. Barnes wrote: >> I don't think re-visiting the concept of PKIX validation is in >>scope for this group. >> For better or worse, that's the starting point for what we're doing. > >I see no _technical_ reason why DANE cannot specify that, when >DANE-compliant clients detect TLSA records, they are to follow a novel >certificate matching algorithm specified by DANE rather than the >legacy algorithm used for in-band certificates. > >I agree with John and Peter: PKIX validation is a big ball of hair, >it's poorly specified, and actual implementations don't follow the >specification. If we can offer a tightly specified, easy-to-implement >alternative in DANE that is going to be a selling point. > >zw Zack, DANE is free to specify how to validate key and associated data obtained through the DNS. Validation of X.509 certs is the province of the PKIX WG. Steve From zack.weinberg@gmail.com Thu Aug 25 20:57:09 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C1FD21F8ABD for ; Thu, 25 Aug 2011 20:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ce+NaAO3fXa9 for ; Thu, 25 Aug 2011 20:57:09 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1335721F8A57 for ; Thu, 25 Aug 2011 20:57:09 -0700 (PDT) Received: by pzk33 with SMTP id 33so8261764pzk.18 for ; Thu, 25 Aug 2011 20:58:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=FJKQziU2tZRNlPrNm97K4HzLHyRqBJI9aucSte6fj1o=; b=IPniMqvAulYMPjxgjbF+yDkSJlxllolNvo8l4q0dHexHKNd8HBAkc4v/WJaL6wDbD8 yoPynMhLCSdl/i3kX9EbQDu/WuUjBnFiD4BBzniQ+HJCSt9oebGr+4fFligfveA+/Ywo TZmsRL9rRA5o1nhJk8zUC+LXr2ia39SJXzdjY= MIME-Version: 1.0 Received: by 10.142.222.5 with SMTP id u5mr296829wfg.126.1314331104124; Thu, 25 Aug 2011 20:58:24 -0700 (PDT) Sender: zack.weinberg@gmail.com Received: by 10.68.63.228 with HTTP; Thu, 25 Aug 2011 20:58:24 -0700 (PDT) In-Reply-To: References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> <54C1B56E-7673-4F32-8E7B-25959C121A03@bbn.com> <91A5DF74-6DCB-4530-96A4-46786AB62FCB@vpnc.org> <5F91C397-05BE-4A8A-A5DD-B02B0A832C21@kumari.net> <201108232257.p7NMv886004365@new.toad.com> <201108240930.p7O9Ux86019874@new.toad.com> <53EB605F-9859-4529-8641-F70A2C5038CD@bbn.com> Date: Thu, 25 Aug 2011 20:58:24 -0700 X-Google-Sender-Auth: UN4yjAXAdkii3ZGQKamYg5NSWIk Message-ID: From: Zack Weinberg To: Stephen Kent Content-Type: text/plain; charset=UTF-8 Cc: dane issue tracker , Paul Hoffman , DANE WG Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 26 Aug 2011 03:57:09 -0000 On Thu, Aug 25, 2011 at 12:25 PM, Stephen Kent wrote: > At 12:48 PM -0700 8/24/11, Zack Weinberg wrote: >> >> I see no _technical_ reason why DANE cannot specify that, when >> DANE-compliant clients detect TLSA records, they are to follow a novel >> certificate matching algorithm specified by DANE rather than the >> legacy algorithm used for in-band certificates. > > DANE is free to specify how to validate key and associated data obtained through the DNS. > > Validation of X.509 certs is the province of the PKIX WG. That is not a _technical_ reason to do anything. I am not sure whether or not DANE _needs_ to override or even mention PKIX validation -- I am more than a little behind wrt the current state of the spec -- but I think it would be a great shame if the Right Thing in technical terms were blocked because of IETF politics. zw From sm@resistor.net Thu Aug 25 23:55:09 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0742D21F8B13 for ; Thu, 25 Aug 2011 23:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVfuEX+de5vl for ; Thu, 25 Aug 2011 23:55:07 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id F1CCE21F8B11 for ; Thu, 25 Aug 2011 23:55:06 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5) with ESMTP id p7Q6u9T3008467 for ; Thu, 25 Aug 2011 23:56:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1314341775; bh=PPiUgCYfg23oBMPDxg9Hmsvv10xLyGHxSRCs8ZocN9o=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=a6Z13AZDr/v4BxuB5txQfMVrlUBiTRwBKmuXa5Zwl/61cyGr/ml1OIeIKQq2ilc+S 62T2yQNAhnr74G8k7jpFBq/lgriBazAPh50oSPscIBbkaNbgw9YqvoZpWqaMdB2QXj APESXoJYUsc3/EJLZSTJsTs5lcj3qk0TTi25sdkE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1314341775; bh=PPiUgCYfg23oBMPDxg9Hmsvv10xLyGHxSRCs8ZocN9o=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=Uc5ByottRImwTxgJ0cr0OkpQ5p7B42ML9nlzzPos9m+rr+LdRq8w6rAHZFKsuhpRC LcfZU9GQJSEWh1ChuWJj+X2HfOOVa/k1/mqz5Rh+vmarLpugkqNhMS6Diggl0eY7/w 2TYGYTw9dpnRqOG1E5wGboBRex6qxeD6UzS8ViF4= Message-Id: <6.2.5.6.2.20110825233222.0ac345c0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 25 Aug 2011 23:34:59 -0700 To: DANE WG From: SM In-Reply-To: References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> <54C1B56E-7673-4F32-8E7B-25959C121A03@bbn.com> <91A5DF74-6DCB-4530-96A4-46786AB62FCB@vpnc.org> <5F91C397-05BE-4A8A-A5DD-B02B0A832C21@kumari.net> <201108232257.p7NMv886004365@new.toad.com> <201108240930.p7O9Ux86019874@new.toad.com> <53EB605F-9859-4529-8641-F70A2C5038CD@bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 26 Aug 2011 06:55:09 -0000 At 20:58 25-08-2011, Zack Weinberg wrote: >state of the spec -- but I think it would be a great shame if the >Right Thing in technical terms were blocked because of IETF politics. IETF politics is about figuring out the Right Thing is technical terms. Regards, -sm From hallam@gmail.com Fri Aug 26 04:25:37 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA57221F8B1E for ; Fri, 26 Aug 2011 04:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ui-IXNyRJHwr for ; Fri, 26 Aug 2011 04:25:36 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8E121F8A91 for ; Fri, 26 Aug 2011 04:25:36 -0700 (PDT) Received: by gwb20 with SMTP id 20so3196382gwb.31 for ; Fri, 26 Aug 2011 04:26:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Xqpj2u5+DlBbXwrwXEccSy2WZg3u3y/Kbu3u/TqWkvY=; b=YLCc387+0HsqXqSK78Wn0I2nAxuK1ejIuJS6ApjJxx2TMlihBVnlt3GicTMnsDSmWn yea86zPH6+fIfq7U7GdIpWgET5IK69okg6I3Qa9R6Dkt/YaH/xRzZVqhj7irp+ABW0ad V5oY5F9/GxNnLyTshn9Tfk4PfdWCv4pYn8EhQ= MIME-Version: 1.0 Received: by 10.100.193.5 with SMTP id q5mr957133anf.36.1314358012169; Fri, 26 Aug 2011 04:26:52 -0700 (PDT) Received: by 10.100.94.14 with HTTP; Fri, 26 Aug 2011 04:26:51 -0700 (PDT) In-Reply-To: References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> <54C1B56E-7673-4F32-8E7B-25959C121A03@bbn.com> <91A5DF74-6DCB-4530-96A4-46786AB62FCB@vpnc.org> <5F91C397-05BE-4A8A-A5DD-B02B0A832C21@kumari.net> <201108232257.p7NMv886004365@new.toad.com> <201108240930.p7O9Ux86019874@new.toad.com> <53EB605F-9859-4529-8641-F70A2C5038CD@bbn.com> Date: Fri, 26 Aug 2011 07:26:51 -0400 Message-ID: From: Phillip Hallam-Baker To: Zack Weinberg Content-Type: multipart/alternative; boundary=0016e64134786c4fed04ab66d2fc Cc: Paul Hoffman , DANE WG , dane issue tracker Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 26 Aug 2011 11:25:37 -0000 --0016e64134786c4fed04ab66d2fc Content-Type: text/plain; charset=ISO-8859-1 On Thu, Aug 25, 2011 at 11:58 PM, Zack Weinberg wrote: > On Thu, Aug 25, 2011 at 12:25 PM, Stephen Kent wrote: > > At 12:48 PM -0700 8/24/11, Zack Weinberg wrote: > >> > >> I see no _technical_ reason why DANE cannot specify that, when > >> DANE-compliant clients detect TLSA records, they are to follow a novel > >> certificate matching algorithm specified by DANE rather than the > >> legacy algorithm used for in-band certificates. > > > > DANE is free to specify how to validate key and associated data obtained > through the DNS. > > > > Validation of X.509 certs is the province of the PKIX WG. > > That is not a _technical_ reason to do anything. > This is a political process, not a technical one. If I want to do technical design I get a review club of four to five people who are leading experts plus maybe a few bright grad students and we have some fun. Whatever else it has been, DANE has not been fun. The CA industry has spent the past five years trying to work out how to get the browser providers to do hard fail on existing revocation mechanisms. Proposing a new cause of revocation on the basis of an infrastructure that is inevitably more incomplete and less dependable in operation than the existing ones was never going to happen. > I am not sure whether or not DANE _needs_ to override or even mention > PKIX validation -- I am more than a little behind wrt the current > state of the spec -- but I think it would be a great shame if the > Right Thing in technical terms were blocked because of IETF politics. No, what you believe to be the right thing and what a clique of ten to twenty people believe is the right thing. There are two billion users of the Internet and they did not elect you as commissars. Consensus was formed in this working group by excluding the stakeholders that had contrary opinions and interests. That is an expedient way to get to WG consensus on an Internet Draft but it is totally counterproductive with respect to IETF consensus. IETF consensus is the real test to get an RFC and that is in turn only a proxy for obtaining the industry consensus you need to change the infrastructure. -- Website: http://hallambaker.com/ --0016e64134786c4fed04ab66d2fc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Aug 25, 2011 at 11:58 PM, Zack W= einberg <z= ack.weinberg@sv.cmu.edu> wrote:
On Thu, Aug 25, 2011 at 12:25 PM, Stephen Kent <kent@bbn.com> wrote:
> At 12:48 PM -0700 8/24/11, Zack Weinberg wrote:
>>
>> I see no _technical_ reason why DANE canno= t specify that, when
>> DANE-compliant clients detect TLSA records, they are to follow a n= ovel
>> certificate matching algorithm specified by DANE rather than the >> legacy algorithm used for in-band certificates.
>
> DANE is free to specify how to validate key an= d associated data obtained through the DNS.
>
> Validation of X.509 certs is the province of the PKIX WG.

That is not a _technical_ reason to do anything.

This is a political process, not a technical one.

If I want to do technical design I get a review club of fou= r to five people who are leading experts plus maybe a few bright grad stude= nts and we have some fun. Whatever else it has been, DANE has not been fun.=

The CA industry has spent the past five years trying to= work out how to get the browser providers to do hard fail on existing revo= cation mechanisms.=A0

Proposing a new cause of rev= ocation on the basis of an infrastructure that is inevitably more incomplet= e and less dependable in operation than the existing ones was never going t= o happen.=A0

=A0
I am not sure whether or not DANE _needs_ to override or even mention
PKIX validation -- I am more than a little behind wrt the current
state of the spec -- but I think it would be a great shame if the
Right Thing in technical terms were blocked because of IETF politics.

No, what you believe to be the right thing and w= hat a clique of ten to twenty people believe is the right thing. There are = two billion users of the Internet and they did not elect you as commissars.=

Consensus was formed in this working group by excluding= the stakeholders that had contrary opinions and interests. That is an expe= dient way to get to WG consensus on an Internet Draft but it is totally cou= nterproductive with respect to IETF consensus.


IETF consensus is the real test to get a= n RFC and that is in turn only a proxy for obtaining the industry consensus= you need to change the infrastructure.


--
Website: http://hallam= baker.com/

--0016e64134786c4fed04ab66d2fc-- From paul.hoffman@vpnc.org Fri Aug 26 08:12:46 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E97F21F8C0C for ; Fri, 26 Aug 2011 08:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rn4ia6DJZMB9 for ; Fri, 26 Aug 2011 08:12:45 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0FB21F8B98 for ; Fri, 26 Aug 2011 08:12:44 -0700 (PDT) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p7QFE0Cb064255 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 26 Aug 2011 08:14:01 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Fri, 26 Aug 2011 08:14:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <00BD9453-17EE-43CC-8F9B-7697D83165DE@vpnc.org> References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> <54C1B56E-7673-4F32-8E7B-25959C121A03@bbn.com> <91A5DF74-6DCB-4530-96A4-46786AB62FCB@vpnc.org> <5F91C397-05BE-4A8A-A5DD-B02B0A832C21@kumari.net> <201108232257.p7NMv886004365@new.toad.com> <201108240930.p7O9Ux86019874@new.toad.com> <53EB605F-9859-4529-8641-F70A2C5038CD@bbn.com> To: Zack Weinberg X-Mailer: Apple Mail (2.1244.3) Cc: DANE WG Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 26 Aug 2011 15:12:46 -0000 On Aug 25, 2011, at 8:58 PM, Zack Weinberg wrote: > I am not sure whether or not DANE _needs_ to override or even mention > PKIX validation -- I am more than a little behind wrt the current > state of the spec -- but I think it would be a great shame if the > Right Thing in technical terms were blocked because of IETF politics. To catch up on the spec, you should certainly read = draft-ietf-dane-use-cases-05.txt, the spec that the WG agreed to base = our work on. The current protocol spec is still in flux as the WG decides what it = wants and how to do it. My reading of the use cases document is that PKIX validation needs to be = dealt with in some cases, but not in all cases. Others may disagree. --Paul Hoffman From paul.hoffman@vpnc.org Fri Aug 26 12:02:47 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3E021F8C59 for ; Fri, 26 Aug 2011 12:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWY1-vaV7+VI for ; Fri, 26 Aug 2011 12:02:46 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 37B0921F8C58 for ; Fri, 26 Aug 2011 12:02:46 -0700 (PDT) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p7QJ41fa034493 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 26 Aug 2011 12:04:01 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <833020D5-E3F1-4253-9876-B54748B92DDA@kirei.se> Date: Fri, 26 Aug 2011 12:04:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> <54C1B56E-7673-4F32-8E7B-25959C121A03@bbn.com> <91A5DF74-6DCB-4530-96A4-46786AB62FCB@vpnc.org> <5F91C397-05BE-4A8A-A5DD-B02B0A832C21@kumari.net> <53597CBD-8E3F-4A66-98BE-720C609B2B0C@kirei.se> <71E8458F-CC74-4AFB-B3B7-520A711F56A4@vpnc.org> <833020D5-E3F1-4253-9876-B54748B92DDA@kirei.se> To: DANE WG X-Mailer: Apple Mail (2.1244.3) Cc: dane issue tracker Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 26 Aug 2011 19:02:47 -0000 Just realized I had not responded directly to this... On Aug 25, 2011, at 10:57 AM, Jakob Schlyter wrote: > usage: > - 0. Certificate MUST pass PKIX validation and MUST chain through a CA = certificate matching the TLSA record > - 1. Certificate MUST pass PKIX validation and MUST match the TLSA = record > - 2. Certificate MUST pass PKIX validation, with any certificate = matching the TLSA record considered to be a trust anchor for this = validation > - (future) 3. Ignore PKIX, match the TLSA record >=20 > selector: > - 0. Certificate > - 1. SubjectPublicKeyInfo >=20 > matching type: > - 0. match on exact selected contents > - 1. sha-256 hash of selected contents > - 2. sha-512 hash of selected contents This seems like the best proposal so far. It makes the three major use = cases clear, it allows for people who want to do a self-signed cert to = do so now (with usage #2), and it does not impede future proposals from = extending the record. Of the "future proposals", I would guess that = "spki-not-in-a-cert" would be done as a new usage that would mandate = that the selector be #1 and would allow all matching types; I would = guess that "OpenPGP assertion" would be done as a new usage that would = mandate a selector of #0 (or would add another selector) and would allow = all matching types. --Paul Hoffman From kent@bbn.com Sat Aug 27 09:37:02 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4241121F8A51 for ; Sat, 27 Aug 2011 09:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.558 X-Spam-Level: X-Spam-Status: No, score=-106.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwXfnD9xwH-6 for ; Sat, 27 Aug 2011 09:37:01 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id C4D8E21F886D for ; Sat, 27 Aug 2011 09:37:01 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:47610 helo=[10.242.10.130]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QxLKk-0000hk-8x; Sat, 27 Aug 2011 12:02:11 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> <54C1B56E-7673-4F32-8E7B-25959C121A03@bbn.com> <91A5DF74-6DCB-4530-96A4-46786AB62FCB@vpnc.org> <5F91C397-05BE-4A8A-A5DD-B02B0A832C21@kumari.net> <201108232257.p7NMv886004365@new.toad.com> <201108240930.p7O9Ux86019874@new.toad.com> <53EB605F-9859-4529-8641-F70A2C5038CD@bbn.com> Date: Sat, 27 Aug 2011 12:01:48 -0400 To: Zack Weinberg From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: dane issue tracker , Paul Hoffman , DANE WG Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2011 16:37:02 -0000 At 8:58 PM -0700 8/25/11, Zack Weinberg wrote: >On Thu, Aug 25, 2011 at 12:25 PM, Stephen Kent wrote: >> At 12:48 PM -0700 8/24/11, Zack Weinberg wrote: >>> >>> I see no _technical_ reason why DANE cannot specify that, when >>> DANE-compliant clients detect TLSA records, they are to follow a novel >>> certificate matching algorithm specified by DANE rather than the >>> legacy algorithm used for in-band certificates. >> >> DANE is free to specify how to validate key and associated data >>obtained through the DNS. >> >> Validation of X.509 certs is the province of the PKIX WG. > >That is not a _technical_ reason to do anything. it is an IETF procedural reason, and the DANE WG exists in the IETF. Steve From warren@kumari.net Tue Aug 30 07:42:19 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 881C921F84CD for ; Tue, 30 Aug 2011 07:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.453 X-Spam-Level: X-Spam-Status: No, score=-102.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYRN0FFGDX-X for ; Tue, 30 Aug 2011 07:42:18 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id C7B0621F8B14 for ; Tue, 30 Aug 2011 07:42:18 -0700 (PDT) Received: from dhcp-172-19-118-113.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 117351B416DA; Tue, 30 Aug 2011 10:43:44 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <833020D5-E3F1-4253-9876-B54748B92DDA@kirei.se> Date: Tue, 30 Aug 2011 10:43:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5ED4A3CB-0064-4809-9799-0D5A52552C81@kumari.net> References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> <54C1B56E-7673-4F32-8E7B-25959C121A03@bbn.com> <91A5DF74-6DCB-4530-96A4-46786AB62FCB@vpnc.org> <5F91C397-05BE-4A8A-A5DD-B02B0A832C21@kumari.net> <53597CBD-8E3F-4A66-98BE-720C609B2B0C@kirei.se> <71E8458F-CC74-4AFB-B3B7-520A711F56A4@vpnc.org> <833020D5-E3F1-4253-9876-B54748B92DDA@kirei.se> To: Jakob Schlyter X-Mailer: Apple Mail (2.1084) Cc: Paul Hoffman , DANE WG Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 Aug 2011 14:42:19 -0000 On Aug 25, 2011, at 1:57 PM, Jakob Schlyter wrote: > On 25 aug 2011, at 17:56, Paul Hoffman wrote: >=20 >> The problem we are having in agreeing on terms is that we don't agree = to the use cases for a TLSA record that has a SPKI-not-in-a-cert in it. = The most vocal proponents of providing an SPKI-not-in-a-cert is no PKIX = validation, just exact matching with the end entity certificate or = SPKI-not-in-a-cert provided in TLS. Others want to maybe also be able to = use SPKI-not-in-a-cert for the kinds of matching that will also involve = PKIX validation. >=20 > Yes, I forgot about the difference between "require PKIX, match on = SPKI" and "ignore PKIX, match on SPKI" - thanks for pointing that out. >=20 >> My feeling is that the easiest way out of this is to let the = SPKI-not-in-a-cert folks have their own usage type that explicitly says = "SPKI-not-in-a-cert from the TLS Certificate message MUST match the TLSA = record". Using Jakob's three-part taxonomy, there would be a fourth = usage type, and any record with that usage type would have to use "SPKI" = and otherwise be ignored as bad; the matching type could be either full = or hashed. I don't think that adding a usage type that has to have a = specific selector type is that dangerous. So, from the "Please indicate a preference" mail = (http://www.ietf.org/mail-archive/web/dane/current/msg03272.html) the = chairs see consensus for option #3 ('Richard's "very different" = proposal'). This below suggestions is a small revision to that, and I wanted to = confirm with the WG that this 3 fields revision is acceptable (just the = 3 fields revision, not the "Ignore PKIX, match the TLSA record" bit). This feels like a minor cleanup to us, no on has objected on list, and = so: a: silence will be taken as consent b: we will call this at 16:00GMT on September 2nd. W > Given Paul's feedback, my proposal would have three fields (in = addition to the association data itself): >=20 > usage: > - 0. Certificate MUST pass PKIX validation and MUST chain through a CA = certificate matching the TLSA record > - 1. Certificate MUST pass PKIX validation and MUST match the TLSA = record > - 2. Certificate MUST pass PKIX validation, with any certificate = matching the TLSA record considered to be a trust anchor for this = validation > - (future) 3. Ignore PKIX, match the TLSA record >=20 > selector: > - 0. Certificate > - 1. SubjectPublicKeyInfo >=20 > matching type: > - 0. match on exact selected contents > - 1. sha-256 hash of selected contents > - 2. sha-512 hash of selected contents >=20 >=20 > jakob >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 From paul@xelerance.com Tue Aug 30 12:28:29 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF25B21F8CA0 for ; Tue, 30 Aug 2011 12:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.34 X-Spam-Level: X-Spam-Status: No, score=-6.34 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iqhtBR2y70yO for ; Tue, 30 Aug 2011 12:28:29 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id 14B0A21F8C8E for ; Tue, 30 Aug 2011 12:28:29 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 75341571C4; Tue, 30 Aug 2011 15:32:34 -0400 (EDT) Date: Tue, 30 Aug 2011 15:32:34 -0400 (EDT) From: Paul Wouters To: Warren Kumari , =?ISO-8859-2?Q?Ond=F8ej_Sur=FD?= In-Reply-To: <5ED4A3CB-0064-4809-9799-0D5A52552C81@kumari.net> Message-ID: References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> <54C1B56E-7673-4F32-8E7B-25959C121A03@bbn.com> <91A5DF74-6DCB-4530-96A4-46786AB62FCB@vpnc.org> <5F91C397-05BE-4A8A-A5DD-B02B0A832C21@kumari.net> <53597CBD-8E3F-4A66-98BE-720C609B2B0C@kirei.se> <71E8458F-CC74-4AFB-B3B7-520A711F56A4@vpnc.org> <833020D5-E3F1-4253-9876-B54748B92DDA@kirei.se> <5ED4A3CB-0064-4809-9799-0D5A52552C81@kumari.net> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: Paul Hoffman , DANE WG Subject: Re: [dane] #29: Request new Reference Type - Public Key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 Aug 2011 19:28:29 -0000 On Tue, 30 Aug 2011, Warren Kumari wrote: > This feels like a minor cleanup to us, no on has objected on list, and so: > a: silence will be taken as consent > b: we will call this at 16:00GMT on September 2nd. > > W > >> Given Paul's feedback, my proposal would have three fields (in addition to the association data itself): >> >> usage: >> - 0. Certificate MUST pass PKIX validation and MUST chain through a CA certificate matching the TLSA record >> - 1. Certificate MUST pass PKIX validation and MUST match the TLSA record >> - 2. Certificate MUST pass PKIX validation, with any certificate matching the TLSA record considered to be a trust anchor for this validation >> - (future) 3. Ignore PKIX, match the TLSA record This seems awefully close to trying to dictate local policy to the client. I thought a lot of people objected to that? If you want DANE to be able to say a local policy "MUST pass PKIX", then you also have to allow dictating a local policy that says "MUST NOT accept PKIX". I am also not sure that if/when we create a new TLS cert type containing just a subjectPublicKeyInfo, what "Certificate MUST pass PKIX validation" even means..... So like John, I have problems which these statements. If we do go along the suggested "new approach" lines, I would like to propose: 3 Certificate MUST match TLSA record That leaves the door open for the TLS client to use or not use PKIX based on whatever local circumstances or policy. And the statement itself does not depend on any drafts or other incomplete TLS extensions currently being discussed. Furthermore, TLSA should be able to pin the TLS client with a "no PKIX", as that is a valid use case as per dane-use-cases Ssection 4: Minimal Dependencies: It should be possible for a site to deploy DANE without also deploying anything else, except DNSSEC. With this addition of (3) that is not relegated to some undecided point in the future, I am okay with this new proposal. Otherwise, I am strongly opposed. Paul From warren@kumari.net Tue Aug 30 12:29:00 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD1F321F8D6D for ; Tue, 30 Aug 2011 12:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.459 X-Spam-Level: X-Spam-Status: No, score=-102.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AAGfzY6FuuN2 for ; Tue, 30 Aug 2011 12:29:00 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 017ED21F8C8E for ; Tue, 30 Aug 2011 12:28:59 -0700 (PDT) Received: from dhcp-172-19-118-113.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id B55491B416DA; Tue, 30 Aug 2011 15:30:25 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Warren Kumari In-Reply-To: <006d01cc5d21$922d7ba0$b68872e0$@augustcellars.com> Date: Tue, 30 Aug 2011 15:30:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8E693634-83A1-49D4-84E0-648A1A050B7B@kumari.net> References: <74B71A15-E1E1-4057-9C6B-4721FCC270C2@nic.cz> <006301cc5bc7$860006f0$920014d0$@augustcellars.com> <006d01cc5d21$922d7ba0$b68872e0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1084) Cc: 'Paul Hoffman' , 'DANE WG' Subject: Re: [dane] Opening issue #7: Error Handling : What to do when you receive an invalid record X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 Aug 2011 19:29:00 -0000 Hi there all, We would like to call this on Friday at 16:00UTC, but would delay like = some additional input. Is the proposed text (below) acceptable to the WG? W On Aug 17, 2011, at 5:06 PM, Jim Schaad wrote: >=20 >=20 >> -----Original Message----- >> From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] >> Sent: Wednesday, August 17, 2011 8:11 AM >> To: Jim Schaad >> Cc: DANE WG >> Subject: Re: [dane] Opening issue #7: Error Handling : What to do = when you >> receive an invalid record >>=20 >>=20 >> On Aug 15, 2011, at 8:49 PM, Jim Schaad wrote: >>=20 >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On = Behalf >>>> Of Paul Hoffman >>>> Sent: Monday, August 15, 2011 7:40 PM >>>> To: Ondrej Sur=FD >>>> Cc: dane@ietf.org >>>> Subject: Re: [dane] Opening issue #7: Error Handling : What to do >>>> when you receive an invalid record >>>>=20 >>>> Make it unusable. >>>>=20 >>>> Current: >>>> If a certificate association contains a reference type that is not >>>> understood by the TLS client, that certificate association MUST be >>>> marked as unusable. >>>> Proposed: >>>> If a certificate association contains a reference type or >>>> certificate >>> type that >>>> is not >>>> understood by the TLS client, that certificate association MUST be >>>> marked as unusable. If an error occurs when comparing using >>>> reference types that are not exact matches (such as hashes), the >>>> certificate association MUST be marked as unusable. >>>=20 >>> If an error occurs when comparing using reference types, the >>> certificate association MUST be marked as unusable. >>>=20 >>> -- I don't understand why there is a reason for the 'not exact >>> matches', it should not matter as long as the comparison is done in >>> the correct manner if you are comparing either the direct bytes or = via a >> function such as a hash. >>=20 >> Good point. >>>=20 >>> -- Note that the statement that it be marked as unusable does not >>> match the pseudo code in appendix B unless there is a check = someplace >>> in the code that I missed for things which are marked unusable as >>> oppose to a usable but failed check. >>=20 >> The pseudocode in Appendix B is incomplete. We will add the following = (or >> something like it) near the beginning: >>=20 >> // unusable records include unknown certType, unknown certAssoc >> // and erroneous RDATA >> strip unusable records >> if (no good TLSA record(s) received) { >> fall back to "normal" cert validation >> } >>=20 >> Proposed: >> If a certificate association contains a reference type or = certificate > type that is >> not >> understood by the TLS client, that certificate association MUST be >> marked as unusable. If an error occurs when comparing, the >> certificate association MUST be marked as unusable. >>=20 >> Does that resolve your concern? >=20 > It all looks good except for the last line in the proposed text. An > comparison failure could be thought of as an error and in that case = you do > not want to be marked as unusable. I think what you meant was: >=20 > If the comparison data for a certificate is malformed, the certificate > association MUST be marked as unusable. >=20 > Jim >=20 >>=20 >> --Paul Hoffman >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 From ietf@augustcellars.com Tue Aug 30 13:13:53 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37FA321F8EDD for ; Tue, 30 Aug 2011 13:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGL7h+W-3dNr for ; Tue, 30 Aug 2011 13:13:52 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7881F21F8EEB for ; Tue, 30 Aug 2011 13:13:49 -0700 (PDT) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 49B382CA0A; Tue, 30 Aug 2011 13:15:14 -0700 (PDT) From: "Jim Schaad" To: "'Warren Kumari'" References: <74B71A15-E1E1-4057-9C6B-4721FCC270C2@nic.cz> <006301cc5bc7$860006f0$920014d0$@augustcellars.com> <006d01cc5d21$922d7ba0$b68872e0$@augustcellars.com> <8E693634-83A1-49D4-84E0-648A1A050B7B@kumari.net> In-Reply-To: <8E693634-83A1-49D4-84E0-648A1A050B7B@kumari.net> Date: Tue, 30 Aug 2011 13:51:12 -0700 Message-ID: <03e501cc6756$8da06810$a8e13830$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQHzmcrXAa7573k1pdzaApVz2VR52AOF76/dA4kNKCUCWt6zXwEYKnuFATRBKgCUiccnIA== Cc: 'Paul Hoffman' , 'DANE WG' Subject: Re: [dane] Opening issue #7: Error Handling : What to do when you receive an invalid record X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 Aug 2011 20:13:53 -0000 Which proposed text are we looking at, the text from Paul or the text = from Paul with my modification? Jim > -----Original Message----- > From: Warren Kumari [mailto:warren@kumari.net] > Sent: Tuesday, August 30, 2011 12:30 PM > To: Jim Schaad > Cc: Warren Kumari; 'Paul Hoffman'; 'DANE WG' > Subject: Re: [dane] Opening issue #7: Error Handling : What to do when = you > receive an invalid record >=20 > Hi there all, >=20 > We would like to call this on Friday at 16:00UTC, but would delay like some > additional input. >=20 > Is the proposed text (below) acceptable to the WG? >=20 > W >=20 >=20 > On Aug 17, 2011, at 5:06 PM, Jim Schaad wrote: >=20 > > > > > >> -----Original Message----- > >> From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] > >> Sent: Wednesday, August 17, 2011 8:11 AM > >> To: Jim Schaad > >> Cc: DANE WG > >> Subject: Re: [dane] Opening issue #7: Error Handling : What to do > >> when you receive an invalid record > >> > >> > >> On Aug 15, 2011, at 8:49 PM, Jim Schaad wrote: > >> > >>> > >>> > >>>> -----Original Message----- > >>>> From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On > >>>> Behalf Of Paul Hoffman > >>>> Sent: Monday, August 15, 2011 7:40 PM > >>>> To: Ondrej Sur=FD > >>>> Cc: dane@ietf.org > >>>> Subject: Re: [dane] Opening issue #7: Error Handling : What to do > >>>> when you receive an invalid record > >>>> > >>>> Make it unusable. > >>>> > >>>> Current: > >>>> If a certificate association contains a reference type that is = not > >>>> understood by the TLS client, that certificate association MUST = be > >>>> marked as unusable. > >>>> Proposed: > >>>> If a certificate association contains a reference type or > >>>> certificate > >>> type that > >>>> is not > >>>> understood by the TLS client, that certificate association MUST = be > >>>> marked as unusable. If an error occurs when comparing using > >>>> reference types that are not exact matches (such as hashes), the > >>>> certificate association MUST be marked as unusable. > >>> > >>> If an error occurs when comparing using reference types, the > >>> certificate association MUST be marked as unusable. > >>> > >>> -- I don't understand why there is a reason for the 'not exact > >>> matches', it should not matter as long as the comparison is done = in > >>> the correct manner if you are comparing either the direct bytes or > >>> via a > >> function such as a hash. > >> > >> Good point. > >>> > >>> -- Note that the statement that it be marked as unusable does not > >>> match the pseudo code in appendix B unless there is a check > >>> someplace in the code that I missed for things which are marked > >>> unusable as oppose to a usable but failed check. > >> > >> The pseudocode in Appendix B is incomplete. We will add the = following > >> (or something like it) near the beginning: > >> > >> // unusable records include unknown certType, unknown certAssoc > >> // and erroneous RDATA > >> strip unusable records > >> if (no good TLSA record(s) received) { fall back to "normal" cert > >> validation } > >> > >> Proposed: > >> If a certificate association contains a reference type or > >> certificate > > type that is > >> not > >> understood by the TLS client, that certificate association MUST be > >> marked as unusable. If an error occurs when comparing, the > >> certificate association MUST be marked as unusable. > >> > >> Does that resolve your concern? > > > > It all looks good except for the last line in the proposed text. An > > comparison failure could be thought of as an error and in that case > > you do not want to be marked as unusable. I think what you meant = was: > > > > If the comparison data for a certificate is malformed, the = certificate > > association MUST be marked as unusable. > > > > Jim > > > >> > >> --Paul Hoffman > > > > _______________________________________________ > > dane mailing list > > dane@ietf.org > > https://www.ietf.org/mailman/listinfo/dane > > From warren@kumari.net Tue Aug 30 13:23:51 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F236F21F8E6E for ; Tue, 30 Aug 2011 13:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.465 X-Spam-Level: X-Spam-Status: No, score=-102.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JcK1ngK3KrVz for ; Tue, 30 Aug 2011 13:23:50 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 30F5721F8C5A for ; Tue, 30 Aug 2011 13:23:49 -0700 (PDT) Received: from dhcp-172-19-118-113.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 80DBF1B40115; Tue, 30 Aug 2011 16:25:16 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Warren Kumari In-Reply-To: <03e501cc6756$8da06810$a8e13830$@augustcellars.com> Date: Tue, 30 Aug 2011 16:25:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <74B71A15-E1E1-4057-9C6B-4721FCC270C2@nic.cz> <006301cc5bc7$860006f0$920014d0$@augustcellars.com> <006d01cc5d21$922d7ba0$b68872e0$@augustcellars.com> <8E693634-83A1-49D4-84E0-648A1A050B7B@kumari.net> <03e501cc6756$8da06810$a8e13830$@augustcellars.com> To: "Jim Schaad" X-Mailer: Apple Mail (2.1084) Cc: 'Paul Hoffman' , 'DANE WG' Subject: Re: [dane] Opening issue #7: Error Handling : What to do when you receive an invalid record X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 Aug 2011 20:23:51 -0000 On Aug 30, 2011, at 4:51 PM, Jim Schaad wrote: > Which proposed text are we looking at, the text from Paul or the text = from > Paul with my modification? Sorry, I really should have been more clear -- the text from Paul WITH = your modification. W >=20 > Jim >=20 >=20 >> -----Original Message----- >> From: Warren Kumari [mailto:warren@kumari.net] >> Sent: Tuesday, August 30, 2011 12:30 PM >> To: Jim Schaad >> Cc: Warren Kumari; 'Paul Hoffman'; 'DANE WG' >> Subject: Re: [dane] Opening issue #7: Error Handling : What to do = when you >> receive an invalid record >>=20 >> Hi there all, >>=20 >> We would like to call this on Friday at 16:00UTC, but would delay = like > some >> additional input. >>=20 >> Is the proposed text (below) acceptable to the WG? >>=20 >> W >>=20 >>=20 >> On Aug 17, 2011, at 5:06 PM, Jim Schaad wrote: >>=20 >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] >>>> Sent: Wednesday, August 17, 2011 8:11 AM >>>> To: Jim Schaad >>>> Cc: DANE WG >>>> Subject: Re: [dane] Opening issue #7: Error Handling : What to do >>>> when you receive an invalid record >>>>=20 >>>>=20 >>>> On Aug 15, 2011, at 8:49 PM, Jim Schaad wrote: >>>>=20 >>>>>=20 >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On >>>>>> Behalf Of Paul Hoffman >>>>>> Sent: Monday, August 15, 2011 7:40 PM >>>>>> To: Ondrej Sur=FD >>>>>> Cc: dane@ietf.org >>>>>> Subject: Re: [dane] Opening issue #7: Error Handling : What to do >>>>>> when you receive an invalid record >>>>>>=20 >>>>>> Make it unusable. >>>>>>=20 >>>>>> Current: >>>>>> If a certificate association contains a reference type that is = not >>>>>> understood by the TLS client, that certificate association MUST = be >>>>>> marked as unusable. >>>>>> Proposed: >>>>>> If a certificate association contains a reference type or >>>>>> certificate >>>>> type that >>>>>> is not >>>>>> understood by the TLS client, that certificate association MUST = be >>>>>> marked as unusable. If an error occurs when comparing using >>>>>> reference types that are not exact matches (such as hashes), the >>>>>> certificate association MUST be marked as unusable. >>>>>=20 >>>>> If an error occurs when comparing using reference types, the >>>>> certificate association MUST be marked as unusable. >>>>>=20 >>>>> -- I don't understand why there is a reason for the 'not exact >>>>> matches', it should not matter as long as the comparison is done = in >>>>> the correct manner if you are comparing either the direct bytes or >>>>> via a >>>> function such as a hash. >>>>=20 >>>> Good point. >>>>>=20 >>>>> -- Note that the statement that it be marked as unusable does not >>>>> match the pseudo code in appendix B unless there is a check >>>>> someplace in the code that I missed for things which are marked >>>>> unusable as oppose to a usable but failed check. >>>>=20 >>>> The pseudocode in Appendix B is incomplete. We will add the = following >>>> (or something like it) near the beginning: >>>>=20 >>>> // unusable records include unknown certType, unknown certAssoc >>>> // and erroneous RDATA >>>> strip unusable records >>>> if (no good TLSA record(s) received) { fall back to "normal" cert >>>> validation } >>>>=20 >>>> Proposed: >>>> If a certificate association contains a reference type or >>>> certificate >>> type that is >>>> not >>>> understood by the TLS client, that certificate association MUST be >>>> marked as unusable. If an error occurs when comparing, the >>>> certificate association MUST be marked as unusable. >>>>=20 >>>> Does that resolve your concern? >>>=20 >>> It all looks good except for the last line in the proposed text. An >>> comparison failure could be thought of as an error and in that case >>> you do not want to be marked as unusable. I think what you meant = was: >>>=20 >>> If the comparison data for a certificate is malformed, the = certificate >>> association MUST be marked as unusable. >>>=20 >>> Jim >>>=20 >>>>=20 >>>> --Paul Hoffman >>>=20 >>> _______________________________________________ >>> dane mailing list >>> dane@ietf.org >>> https://www.ietf.org/mailman/listinfo/dane >>>=20 >=20 From yzw_iplab@163.com Tue Aug 30 17:47:07 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 353E021F8CD9 for ; Tue, 30 Aug 2011 17:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.83 X-Spam-Level: **** X-Spam-Status: No, score=4.83 tagged_above=-999 required=5 tests=[AWL=2.191, BAYES_50=0.001, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8RbzQCiwxpJ for ; Tue, 30 Aug 2011 17:47:06 -0700 (PDT) Received: from m50-134.163.com (m50-134.163.com [123.125.50.134]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA3521F8E4B for ; Tue, 30 Aug 2011 17:47:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=Received:Date:From:To:Cc:Subject:Message-ID: Mime-Version:Content-Type; bh=fpvMXHvupA08GtcaVcP2uhXw2kwsxJbfN/ z8LvMN+qk=; b=N6HOCnDOYYNsZhX0F9Iq4Q8cZIW6RgjiHq9LwICdqEsvmlTMRD QttYz19Hj+3Jy6lmnwR++VuHNdhJLV99LXlBD0HWccmvvAHpjAnM8PjRDBQlNj96 Q9kWokekqz8Slaj5nPtA2mz3zH9wV3cymohHVckz4u+syxi5WkWE8iYLg= Received: from lenovo-THINK (unknown [218.241.111.47]) by smtp4 (Coremail) with SMTP id DtGowEA5k0XahF1OJ00gAA--.3020S2; Wed, 31 Aug 2011 08:48:27 +0800 (CST) Date: Wed, 31 Aug 2011 08:48:00 +0800 From: "yzw_iplab" To: "dane" Message-ID: <201108310848003094902@163.com> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon827525564083_=====" X-CM-TRANSID: DtGowEA5k0XahF1OJ00gAA--.3020S2 X-Coremail-Antispam: 1Uf129KBjvdXoW7Jr4xur48Gw47uw1kAw1UKFg_yoWfuFgE9w nrJFyDJan5Kr4aqF9ayr18Jr15X34jgr48K3sYgFWay398Zw1UWFn7AFsF9F1fJry8trZx Gas5GFWYvrn09jkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUvcSsGvfC2KfnxnUUI43ZEXa7IU0l1v3UUUUU== X-CM-SenderInfo: 512zsxhsoduqqrwthudrp/1tbipReszki7ZuS65AAAs- Cc: "paul.hoffman" , trac+dane Subject: Re: [dane] #31: Multiple TLSA records in a response X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 31 Aug 2011 00:47:07 -0000 This is a multi-part message in MIME format. --=====003_Dragon827525564083_===== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: base64 SGksIA0KQWJzb2x1dGVseSwgaXQgaXMgdXNlZnVsIGZvciBhIGRvbWFpbiB0byBoYXZlIG1vcmUg dGhhbiBvbmUgVExTQSByZWNvcmQuIEl0IG1heSBiZSB1c2VkIGJ5IHRoZSBjbGllbnQgZm9yIHRo ZSBmbGV4aWJsZSBzZWxlY3Rpb24gb2Ygc2VydmVyknMgY2VydGlmaWNhdGUuIEhvd2V2ZXIsIEkg dGhpbmsgdGhpcyBpcyBub3QgbmVjZXNzYXJ5IGluIHRoZSBjZXJ0aWZpY2F0ZSB1cGRhdGUgYW5k IHRoZSBUTFNBIHVwZGF0ZSBwcm9jZXNzIG1heSBmb2xsb3c6DQoxKQ0KSW5pdGlhbGx5LCB0aGUg b2xkIFRMU0EgcmVjb3JkIGlzIG1haW50YWluZWQgaW4gdGhlIEROUzoNCl8xMjMuX3RjcC5leGFt cGxlLmNvbSBJTiBUTFNBIDxvbGQ+DQpUTFMgc2VydmVyIGhhcyBjZXJ0aWZpY2F0ZSBjaGFpbiBh c3NvY2lhdGVkIHdpdGggPG9sZD4uDQoyKQ0KQ2VydGlmaWNhdGUgc2hvdWxkIGJlIHVwZGF0ZWQg YW5kIHRoZSBvbGQgVExTQSByZWNvcmQgaXMgcmVwbGFjZWQ6DQpfMTIzLl90Y3AuZXhhbXBsZS5j b20gSU4gVExTQSA8bmV3Pg0KV2hpbGUgdGhlIFRMUyBzZXJ2ZXIgc2hvdWxkIG1haW50YWluIGJv dGggb2xkIGFuZCBuZXcgY2VydGlmaWNhdGVzIGZvciBzb21lIHRpbWU6DQpUTFMgc2VydmVyIGhh cyBjZXJ0aWZpY2F0ZSBjaGFpbiBhc3NvY2lhdGVkIHdpdGggPG9sZD4uDQpUTFMgc2VydmVyIGhh cyBjZXJ0aWZpY2F0ZSBjaGFpbiBhc3NvY2lhdGVkIHdpdGggPG5ldz4uDQozKQ0KQWZ0ZXIgdGhl IHRpbWVvdXQsIHRoZSBvbGQgY2VydGlmaWNhdGUgaXMgZGVsZXRlZCBmcm9tIFRMUyBzZXJ2ZXI6 DQpfMTIzLl90Y3AuZXhhbXBsZS5jb20gSU4gVExTQSA8bmV3Pg0KVExTIHNlcnZlciBoYXMgY2Vy dGlmaWNhdGUgY2hhaW4gYXNzb2NpYXRlZCB3aXRoIDxuZXc+Lg0KSg0KU2luY2VyZWx5IHlvdXJz LA0KWmhpd2VpIFlhbg0KDQoyMDExLTA4LTMxIA0KDQoNCg0KeXp3X2lwbGFiIA0K --=====003_Dragon827525564083_===== Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit

Hi,

Absolutely, it is useful for a domain to have more than one TLSA record. It may be used by the client for the flexible selection of server’s certificate. However, I think this is not necessary in the certificate update and the TLSA update process may follow:

1)

Initially, the old TLSA record is maintained in the DNS:

_123._tcp.example.com IN TLSA <old>

TLS server has certificate chain associated with <old>.

2)

Certificate should be updated and the old TLSA record is replaced:

_123._tcp.example.com IN TLSA <new>

While the TLS server should maintain both old and new certificates for some time:

TLS server has certificate chain associated with <old>.

TLS server has certificate chain associated with <new>.

3)

After the timeout, the old certificate is deleted from TLS server:

_123._tcp.example.com IN TLSA <new>

TLS server has certificate chain associated with <new>.

J

Sincerely yours,

Zhiwei Yan

 
2011-08-31
yzw_iplab
--=====003_Dragon827525564083_=====-- From jakob@kirei.se Wed Aug 31 22:19:06 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFD0C21F8B59 for ; Wed, 31 Aug 2011 22:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.632 X-Spam-Level: X-Spam-Status: No, score=-0.632 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2mYCYGu6joj for ; Wed, 31 Aug 2011 22:19:06 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id C032721F8B3B for ; Wed, 31 Aug 2011 22:19:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=De8Ad5Yqp0MWsRB1fh7WRXvM7uLQxBg8KNB+8MgMQHA=; b=RK0Srub15kJZzuoXfH6M/t9zhKfAvK7aJyHkCLJClLRWW4bwfQkWKToGK+wbkY+u21SODEkI6o3+L tqnPL8vJXMPO8wEXuGh01CSzLzRLlfhMLV9c/RvVc5GpD/uHeZCGRDIhHLRfh4hlacbKgQoGAJCzp9 X2JfnO/dLmyq5yHI= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Thu, 1 Sep 2011 07:20:24 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: <201108310848003094902@163.com> Date: Thu, 1 Sep 2011 07:20:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201108310848003094902@163.com> To: yzw_iplab X-Mailer: Apple Mail (2.1244.3) Cc: trac+dane , "paul.hoffman" , DANE WG Subject: Re: [dane] #31: Multiple TLSA records in a response X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 01 Sep 2011 05:19:07 -0000 On 31 aug 2011, at 02:48, yzw_iplab wrote: > 2) > Certificate should be updated and the old TLSA record is replaced: > _123._tcp.example.com IN TLSA > While the TLS server should maintain both old and new certificates for = some time: > TLS server has certificate chain associated with . > TLS server has certificate chain associated with . My typical TLS server implementation does not support multiple = concurrent certificates, and I'm pretty sure that's common. Would you see any drawbacks with the more (previously discussed) = traditional approach? 1. generate new certificate, publish both old and new TLSA RR in DNS 2. replace old with new certificate at TLS server 3. remove old TLSA RR from DNS (with the appropriate waiting period for DNS caching timeout in between = the steps of course) jakob From bmanning@karoshi.com Wed Aug 31 23:25:16 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 141AE21F8B12 for ; Wed, 31 Aug 2011 23:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.232 X-Spam-Level: X-Spam-Status: No, score=-6.232 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TkgbJQYkrI+3 for ; Wed, 31 Aug 2011 23:25:15 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id A0DA721F8B17 for ; Wed, 31 Aug 2011 23:25:05 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id p7VEbNqp004747; Wed, 31 Aug 2011 14:37:29 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id p7VEbM6k004746; Wed, 31 Aug 2011 14:37:22 GMT Date: Wed, 31 Aug 2011 14:37:22 +0000 From: bmanning@vacation.karoshi.com To: Warren Kumari Message-ID: <20110831143722.GA4679@vacation.karoshi.com.> References: <74B71A15-E1E1-4057-9C6B-4721FCC270C2@nic.cz> <006301cc5bc7$860006f0$920014d0$@augustcellars.com> <006d01cc5d21$922d7ba0$b68872e0$@augustcellars.com> <8E693634-83A1-49D4-84E0-648A1A050B7B@kumari.net> <03e501cc6756$8da06810$a8e13830$@augustcellars.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: 'Paul Hoffman' , 'DANE WG' Subject: Re: [dane] Opening issue #7: Error Handling : What to do when you receive an invalid record X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 01 Sep 2011 06:25:16 -0000 On Tue, Aug 30, 2011 at 04:25:14PM -0400, Warren Kumari wrote: > > Sorry, I really should have been more clear -- the text from Paul WITH your modification. > > W > > > > >> We would like to call this on Friday at 16:00UTC, but would delay like > > some > >> additional input. > >> > >> Is the proposed text (below) acceptable to the WG? > >> > >> W > >> > >> > >>>> Proposed: > >>>> If a certificate association contains a reference type or > >>>> certificate > >>> type that is > >>>> not > >>>> understood by the TLS client, that certificate association MUST be > >>>> marked as unusable. If an error occurs when comparing, the > >>>> certificate association MUST be marked as unusable. > >>>> > >>>> Does that resolve your concern? > >>> > >>> It all looks good except for the last line in the proposed text. An > >>> comparison failure could be thought of as an error and in that case > >>> you do not want to be marked as unusable. I think what you meant was: > >>> > >>> If the comparison data for a certificate is malformed, the certificate > >>> association MUST be marked as unusable. > >>> > >>> Jim > >>> > >>>> --Paul Hoffman This text looks good to me. /bill