From hallam@gmail.com Fri May 3 04:47:17 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED6A21F95EB for ; Fri, 3 May 2013 04:47:17 -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, HTML_MESSAGE=0.001, 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 WX8CMEkUAjcI for ; Fri, 3 May 2013 04:47:16 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 275B521F95E5 for ; Fri, 3 May 2013 04:47:15 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id m6so511863wiv.13 for ; Fri, 03 May 2013 04:47:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=QzS4/YijTXqlVZF2aEfJz+i2kwd8vTkPv3Lg1z9rNfw=; b=vzDxH342wdBaWiQCpUpooXmpprMesJDaSi/Bab8oSU6YVWDjHGElB7tOAZRsP3X56m lhmgUwDNqGZ0ZAQlzJx18Hkn84ctLYUqTWv5AzNp4XpNsrxH35kZ0zXo1LEQnINIAgyX /nWNJL+DK/TL7nX+EJx1k5ye5Cu4R25uNIPcPWlno2fQGHn/wDf/qRZBTJOHsewvS77M lTQZwo6IKVJqN9OLUBe7ftUhBspK3ERnXfx1zHbCvzdHGduhLRgZOTsB5jVJX+XdqFka Cpu/Ih0Juc0/MWWp8HgHo/cXW0W18F+9l3nXwuTto2NYRNjsiStrNjTr46tFLEK0PDBJ snKQ== MIME-Version: 1.0 X-Received: by 10.194.104.102 with SMTP id gd6mr18323wjb.48.1367581635282; Fri, 03 May 2013 04:47:15 -0700 (PDT) Received: by 10.194.121.161 with HTTP; Fri, 3 May 2013 04:47:15 -0700 (PDT) In-Reply-To: <2B53BDB5-1F1C-43E6-B7F7-904E8BB3E87A@vpnc.org> References: <2B53BDB5-1F1C-43E6-B7F7-904E8BB3E87A@vpnc.org> Date: Fri, 3 May 2013 07:47:15 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=047d7bf19840928ec104dbcee911 Cc: "dane@ietf.org" Subject: Re: [dane] To DANE or to WebFinger? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2013 11:47:17 -0000 --047d7bf19840928ec104dbcee911 Content-Type: text/plain; charset=ISO-8859-1 +1 to the original post and Paul's. Putting per user data in the DNS is a lousy approach, it has never been a succes because the DNS administrators are typically network admins and they are a separate class to DNS admins. A better approach would be to use WebFinger/XKMS/LDAP/TBS to serve up an EE cert for the end user and to use DANE to establish a trust anchor under which the EE cert is issued. The amount of email that is protected by message layer security is a negligible fraction of that protected by STARTTLS. One of the main reasons for that is that the per client user model is fundamentally broken. On Fri, Apr 19, 2013 at 5:03 PM, Paul Hoffman wrote: > On Apr 19, 2013, at 1:29 PM, Richard Barnes wrote: > > > Just a thought: It might be simpler to do S/MIME certificate discovery > using WebFinger than using DANE. You would just have to do an HTTPS query > to a URI of the form... > > > > < > https://example.com/.well-known/webfinger?resource=mailto:rlb@example.com&rel=certificate > > > > > > ... then parse a JSON object to find the certificate. As opposed to > having an appropriately upgraded DNS library, being able to do DNSSEC, and > parsing the binary record format. > > That might be a good way to do certificate discovery, but not really a > good way to have a second trust anchor if one wanted to get away from the > distributed PKIX hierarchies. > > There are plenty of ways to do certificate discovery. The question is how > to be sure that the certificate you get is one you want to use. > > > This process could still benefit from DANE, via TLSA validation on the > HTTPS connection. And basically the only documentation you would need > would be to define the "certificate" relation type. > > Um, doesn't that wipe out the supposed advantages you list above? > > --Paul Hoffman > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > -- Website: http://hallambaker.com/ --047d7bf19840928ec104dbcee911 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+1 to the original post and Paul's.

Putting per user data in the DNS is a lousy approach, it has never b= een a succes because the DNS administrators are typically network admins an= d they are a separate class to DNS admins.

A better approach would be to use WebFinger= /XKMS/LDAP/TBS to serve up an EE cert for the end user and to use DANE to e= stablish a trust anchor under which the EE cert is issued.


The amount of email that is prote= cted by message layer security is a negligible fraction of that protected b= y STARTTLS. One of the main reasons for that is that the per client user mo= del is fundamentally broken.



On Fri, Apr 19, 2013 at 5:03 PM, Paul Hoffman <paul.hoff= man@vpnc.org> wrote:
On Apr 19, 2013, at 1:29 P= M, Richard Barnes <rlb@ipv.sx> wrote:

> Just a thought: It might be simpler to do S/MIME certificate discovery= using WebFinger than using DANE. =A0You would just have to do an HTTPS que= ry to a URI of the =A0form...
>
> <https://examp= le.com/.well-known/webfinger?resource=3Dmailto:rlb@example.com&rel=3Dce= rtificate>
>
> ... then parse a JSON object to find the certificate. =A0As opposed to= having an appropriately upgraded DNS library, being able to do DNSSEC, and= parsing the binary record format.

That might be a good way to do certificate discovery, but not really = a good way to have a second trust anchor if one wanted to get away from the= distributed PKIX hierarchies.

There are plenty of ways to do certificate discovery. The question is how t= o be sure that the certificate you get is one you want to use.

> This process could still benefit from DANE, via TLSA validation on the= HTTPS connection. =A0And basically the only documentation you would need w= ould be to define the "certificate" relation type.

Um, doesn't that wipe out the supposed advantages you list above?=

--Paul Hoffman
_____________________= __________________________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane



--
= Website: http://hallambaker.com/
--047d7bf19840928ec104dbcee911-- From leifj@mnt.se Fri May 3 05:15:48 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 181A621F93E1 for ; Fri, 3 May 2013 05:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[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 dLzLDOiwvAO4 for ; Fri, 3 May 2013 05:15:43 -0700 (PDT) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) by ietfa.amsl.com (Postfix) with ESMTP id 1E48B21F86B1 for ; Fri, 3 May 2013 05:15:42 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id v1so1462330lbd.39 for ; Fri, 03 May 2013 05:15:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:x-gm-message-state; bh=YyLmSfdugJOxMCQw2aNZNgsd/x3tHc/ZaYHdZeXI82g=; b=PO2Ug1VWlNALzxgaMAcdojShJP5VCwCzJaJqgTvozRkOo/le/0dv6SDezjEspsJrJ7 iPoYQiLUnfkQBBPB9VoopCI2RM3ub8JK91Yu0eD6Czii0belt9PA8cZRkfjLWX1KGRRd SyQKj142EVnhKhD0CGRH6J9ZuZsqAfYfMUrAqh50Rwst6Sl/lQdc8JBq3oywhV8UDaRf 6wJHHdaGcQPZfX9WPFGLFsyrlVTye+mfTnGmGm7xhVrzBi7Bg+Ktziya/IA5Cih5DEe6 kywdhbosch/Q4Jaej4NJBs8vreMzLbZY8DUPKqW9rw6a2ZZAne/+l5Ikb9uodWK3vLm0 fWCw== X-Received: by 10.152.5.2 with SMTP id o2mr4086368lao.31.1367583342030; Fri, 03 May 2013 05:15:42 -0700 (PDT) Received: from [78.64.168.232] (host-78-64-168-232.homerun.telia.com. [78.64.168.232]) by mx.google.com with ESMTPSA id s1sm4249161lag.2.2013.05.03.05.15.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 03 May 2013 05:15:41 -0700 (PDT) Message-ID: <5183AA6B.7050701@mnt.se> Date: Fri, 03 May 2013 14:15:39 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: dane@ietf.org References: <2B53BDB5-1F1C-43E6-B7F7-904E8BB3E87A@vpnc.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010808020408060808090700" X-Gm-Message-State: ALoCoQkNqx+o72RpeGeFsp8LVfhblkq/gDIeOWFikaLPKNwY3NpHdl9OorXpCITRvNxvwJjBuFb9 Subject: Re: [dane] To DANE or to WebFinger? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2013 12:15:48 -0000 This is a multi-part message in MIME format. --------------010808020408060808090700 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 05/03/2013 01:47 PM, Phillip Hallam-Baker wrote: > +1 to the original post and Paul's. > > Putting per user data in the DNS is a lousy approach, it has never > been a succes because the DNS administrators are typically network > admins and they are a separate class to DNS admins. Hey, DNS is just a protocol. I don't think anybody is suggesting running end-user data off of bind9 :-) The critical question is one of trust management: using webfinger ties you to the "web pki" for all practical purposes. Using dane ties you to the dnssec root. Personally I'd prefer more options. > > A better approach would be to use WebFinger/XKMS/LDAP/TBS to serve up > an EE cert for the end user and to use DANE to establish a trust > anchor under which the EE cert is issued. > > > The amount of email that is protected by message layer security is a > negligible fraction of that protected by STARTTLS. One of the main > reasons for that is that the per client user model is fundamentally > broken. > > > > On Fri, Apr 19, 2013 at 5:03 PM, Paul Hoffman > wrote: > > On Apr 19, 2013, at 1:29 PM, Richard Barnes wrote: > > > Just a thought: It might be simpler to do S/MIME certificate > discovery using WebFinger than using DANE. You would just have to > do an HTTPS query to a URI of the form... > > > > > > > > > ... then parse a JSON object to find the certificate. As > opposed to having an appropriately upgraded DNS library, being > able to do DNSSEC, and parsing the binary record format. > > That might be a good way to do certificate discovery, but not > really a good way to have a second trust anchor if one wanted to > get away from the distributed PKIX hierarchies. > > There are plenty of ways to do certificate discovery. The question > is how to be sure that the certificate you get is one you want to use. > > > This process could still benefit from DANE, via TLSA validation > on the HTTPS connection. And basically the only documentation you > would need would be to define the "certificate" relation type. > > Um, doesn't that wipe out the supposed advantages you list above? > > --Paul Hoffman > _______________________________________________ > 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 --------------010808020408060808090700 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 05/03/2013 01:47 PM, Phillip Hallam-Baker wrote:
+1 to the original post and Paul's.

Putting per user data in the DNS is a lousy approach, it has never been a succes because the DNS administrators are typically network admins and they are a separate class to DNS admins.
Hey, DNS is just a protocol. I don't think anybody is suggesting
running end-user data off of bind9 :-)

The critical question is one of trust management: using webfinger
ties you to the "web pki" for all practical purposes. Using dane ties
you to the dnssec root.  Personally I'd prefer more options.



A better approach would be to use WebFinger/XKMS/LDAP/TBS to serve up an EE cert for the end user and to use DANE to establish a trust anchor under which the EE cert is issued.


The amount of email that is protected by message layer security is a negligible fraction of that protected by STARTTLS. One of the main reasons for that is that the per client user model is fundamentally broken.



On Fri, Apr 19, 2013 at 5:03 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
On Apr 19, 2013, at 1:29 PM, Richard Barnes <rlb@ipv.sx> wrote:

> Just a thought: It might be simpler to do S/MIME certificate discovery using WebFinger than using DANE.  You would just have to do an HTTPS query to a URI of the  form...
>
> <https://example.com/.well-known/webfinger?resource=mailto:rlb@example.com&rel=certificate>
>
> ... then parse a JSON object to find the certificate.  As opposed to having an appropriately upgraded DNS library, being able to do DNSSEC, and parsing the binary record format.

That might be a good way to do certificate discovery, but not really a good way to have a second trust anchor if one wanted to get away from the distributed PKIX hierarchies.

There are plenty of ways to do certificate discovery. The question is how to be sure that the certificate you get is one you want to use.

> This process could still benefit from DANE, via TLSA validation on the HTTPS connection.  And basically the only documentation you would need would be to define the "certificate" relation type.

Um, doesn't that wipe out the supposed advantages you list above?

--Paul Hoffman
_______________________________________________
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

--------------010808020408060808090700-- From hallam@gmail.com Fri May 3 09:13:45 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEB1121F863B for ; Fri, 3 May 2013 09:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 StTDEeUdJmCv for ; Fri, 3 May 2013 09:13:43 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 79ABE21F85CB for ; Fri, 3 May 2013 08:14:06 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id s43so1399992wey.20 for ; Fri, 03 May 2013 08:14:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=OLiGAEV/uV/OkHath5yEvcePdFANhbDV+r7Q3ycl87s=; b=bAWSlMwvuWN8E2WgUlN8sFLwKV60tC3nxqi2tYU4U3NLkuVsAgdIbXUullyxXAmegP moZVz7XD+wDuSeJ55k3Q6xx3QAgGfp69WpQEG59x0y8sMJ/COBxBpzvxMA5IVjrxOu2g +kILE1uXxW3fu2tSlP3HawestoJfwMcwGazJQzAhqXsoQn2LZ0ro03/sZ+NhH63i27fp LofLQsAm3ft7++cJwAPkIiW+T4wWH30ads7y9JT9us8uGZlIl5CaY1QP12/B2coI6GMy 2CSeXJ2UN1noh4gD3w3bXT2hMaKtaHkKy0GbMFjCPRI2WFFeIsN4SOwbucxMxFkTeml2 pkAw== MIME-Version: 1.0 X-Received: by 10.180.86.230 with SMTP id s6mr14008608wiz.6.1367594045302; Fri, 03 May 2013 08:14:05 -0700 (PDT) Received: by 10.194.121.161 with HTTP; Fri, 3 May 2013 08:14:05 -0700 (PDT) In-Reply-To: <5183AA6B.7050701@mnt.se> References: <2B53BDB5-1F1C-43E6-B7F7-904E8BB3E87A@vpnc.org> <5183AA6B.7050701@mnt.se> Date: Fri, 3 May 2013 11:14:05 -0400 Message-ID: From: Phillip Hallam-Baker To: Leif Johansson Content-Type: multipart/alternative; boundary=f46d04428624446f7c04dbd1cd5e Cc: "dane@ietf.org" Subject: Re: [dane] To DANE or to WebFinger? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2013 16:13:45 -0000 --f46d04428624446f7c04dbd1cd5e Content-Type: text/plain; charset=ISO-8859-1 What I was proposing was the following: example.com wants to issue S/MIME certs for all its account holders, to do this they: 1) Establish a PKIX CA 2) Create a self signed root cert or a request a cert chained to a public root [in which case it MUST be constrained to only issue S/MIME certs and only for the specified domain] 3) Create a DANE record to attest to the certificate signing certificate. 4) Issue S/MIME certs under the CA. This approach uses DANE for certificate attestation but does not attempt to turn DANE into a certificate discovery protocol for end user certificates. On Fri, May 3, 2013 at 8:15 AM, Leif Johansson wrote: > On 05/03/2013 01:47 PM, Phillip Hallam-Baker wrote: > > +1 to the original post and Paul's. > > Putting per user data in the DNS is a lousy approach, it has never been > a succes because the DNS administrators are typically network admins and > they are a separate class to DNS admins. > > Hey, DNS is just a protocol. I don't think anybody is suggesting > running end-user data off of bind9 :-) > > The critical question is one of trust management: using webfinger > ties you to the "web pki" for all practical purposes. Using dane ties > you to the dnssec root. Personally I'd prefer more options. > > > > > A better approach would be to use WebFinger/XKMS/LDAP/TBS to serve up an > EE cert for the end user and to use DANE to establish a trust anchor under > which the EE cert is issued. > > > The amount of email that is protected by message layer security is a > negligible fraction of that protected by STARTTLS. One of the main reasons > for that is that the per client user model is fundamentally broken. > > > > On Fri, Apr 19, 2013 at 5:03 PM, Paul Hoffman wrote: > >> On Apr 19, 2013, at 1:29 PM, Richard Barnes wrote: >> >> > Just a thought: It might be simpler to do S/MIME certificate discovery >> using WebFinger than using DANE. You would just have to do an HTTPS query >> to a URI of the form... >> > >> > < >> https://example.com/.well-known/webfinger?resource=mailto:rlb@example.com&rel=certificate >> > >> > >> > ... then parse a JSON object to find the certificate. As opposed to >> having an appropriately upgraded DNS library, being able to do DNSSEC, and >> parsing the binary record format. >> >> That might be a good way to do certificate discovery, but not really a >> good way to have a second trust anchor if one wanted to get away from the >> distributed PKIX hierarchies. >> >> There are plenty of ways to do certificate discovery. The question is how >> to be sure that the certificate you get is one you want to use. >> >> > This process could still benefit from DANE, via TLSA validation on the >> HTTPS connection. And basically the only documentation you would need >> would be to define the "certificate" relation type. >> >> Um, doesn't that wipe out the supposed advantages you list above? >> >> --Paul Hoffman >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >> > > > > -- > Website: http://hallambaker.com/ > > > _______________________________________________ > dane mailing listdane@ietf.orghttps://www.ietf.org/mailman/listinfo/dane > > > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > > -- Website: http://hallambaker.com/ --f46d04428624446f7c04dbd1cd5e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
What I was proposing was the following:

example.com wants to issue S/MIME= certs for all its account holders, to do this they:

1) Establish a PKIX CA=A0

2= ) Create a self signed root cert or a request a cert chained to a public ro= ot [in which case it MUST be constrained to only issue S/MIME certs and onl= y for the specified domain]

3) Create a DANE record to attest to the ce= rtificate signing certificate.

4) Issu= e S/MIME certs under the CA.


This approach uses DANE for certificate attestation but does not= attempt to turn DANE into a certificate discovery protocol for end user ce= rtificates.





O= n Fri, May 3, 2013 at 8:15 AM, Leif Johansson <leifj@mnt.se> wrot= e:
=20 =20 =20
On 05/03/2013 01:47 PM, Phillip Hallam-Baker wrote:
+1 to the original post and Paul's.

Putting per user data in the DNS is a lousy approach, it has never been a succes because the DNS administrators are typically network admins and they are a separate class to DNS admins.
Hey, DNS is just a protocol. I don't think anybody is suggesting running end-user data off of bind9 :-)

The critical question is one of trust management: using webfinger
ties you to the "web pki" for all practical purposes. Using d= ane ties
you to the dnssec root.=A0 Personally I'd prefer more options.




A better approach would be to use WebFinger/XKMS/LDAP/TBS to serve up an EE cert for the end user and to use DANE to establish a trust anchor under which the EE cert is issued.


The amount of email that is protected by message layer security is a negligible fraction of that protected by STARTTLS. One of the main reasons for that is that the per client user model is fundamentally broken.



On Fri, Apr 19, 2013 at 5:03 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
On Apr 19, 2013, at 1:29 PM, Richard Barnes <rlb@ipv.s= x> wrote:

> Just a thought: It might be simpler to do S/MIME certificate discovery using WebFinger than using DANE. =A0You would just have to do an HTTPS query to a URI of the =A0form...
>
> <https://example.com/.well-known/webfinger?resource=3Dmailto:rlb@example.co= m&rel=3Dcertificate>
>
> ... then parse a JSON object to find the certificate. =A0As opposed to having an appropriately upgraded DNS library, being able to do DNSSEC, and parsing the binary record format.

That might be a good way to do certificate discovery, but not really a good way to have a second trust anchor if one wanted to get away from the distributed PKIX hierarchies.

There are plenty of ways to do certificate discovery. The question is how to be sure that the certificate you get is one you want to use.

> This process could still benefit from DANE, via TLSA validation on the HTTPS connection. =A0And basically the only documentation you would need would be to define the "certificate" relation type.

Um, doesn't that wipe out the supposed advantages you list above?

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



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


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


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




--
Website:= http://hallambaker.com/
--f46d04428624446f7c04dbd1cd5e-- From rlb@ipv.sx Fri May 3 09:46:23 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2D721F96D3 for ; Fri, 3 May 2013 09:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[AWL=-1.276, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 m8HZy81S2L8B for ; Fri, 3 May 2013 09:46:10 -0700 (PDT) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 2D92D21F882A for ; Fri, 3 May 2013 08:49:22 -0700 (PDT) Received: by mail-ob0-f179.google.com with SMTP id xn12so1539775obc.38 for ; Fri, 03 May 2013 08:49:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=wGDXF+AEqgc+ekWtWsiC74HgShAfDkVZpn4g/2LY+BY=; b=ExAqLhwE/JDgXGhf3SOx59hyA4M5/BvmLolL1MFXwXtxtgIK45KQdcJymSAe93BSxw /+onOoI7tJ9RxRU8WYxauFXtK+fLV6TwW+1/I87FqijKAsoVdQ15TsX41otUu2hehl4H 0Gx2Q3Nviq3+Kgcqu/2Ox2RNb3kfGJe2HHgjiJ9qfYsVfb+RRDxli27OAcIDVghx7zcg Qw8mr18dRvkytWPRFxDf3GKg4UL/ffg+W0Pul9z4TiZNPK4hWUZf59DtztcCV6aC0CHh MraAo/4wuZU/GEzJ1I+9S0SFh8B6agYd1Fuj5RxQ+NuwE4uCmzIxxe2bDLLvcsrVdTft 80zA== MIME-Version: 1.0 X-Received: by 10.60.133.134 with SMTP id pc6mr3152005oeb.87.1367596156668; Fri, 03 May 2013 08:49:16 -0700 (PDT) Received: by 10.60.132.172 with HTTP; Fri, 3 May 2013 08:49:16 -0700 (PDT) X-Originating-IP: [192.1.51.16] In-Reply-To: <5183AA6B.7050701@mnt.se> References: <2B53BDB5-1F1C-43E6-B7F7-904E8BB3E87A@vpnc.org> <5183AA6B.7050701@mnt.se> Date: Fri, 3 May 2013 11:49:16 -0400 Message-ID: From: Richard Barnes To: Leif Johansson Content-Type: multipart/alternative; boundary=047d7b47249e1ea85704dbd24b1b X-Gm-Message-State: ALoCoQm8ciDHCrcTUS4rLUzxHv4BY8n4yWKQcTULWCp47iOwd6ImxmCZofgWwBN/ERBlk8bLv01B Cc: "dane@ietf.org" Subject: Re: [dane] To DANE or to WebFinger? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2013 16:46:23 -0000 --047d7b47249e1ea85704dbd24b1b Content-Type: text/plain; charset=ISO-8859-1 On Fri, May 3, 2013 at 8:15 AM, Leif Johansson wrote: > On 05/03/2013 01:47 PM, Phillip Hallam-Baker wrote: > > +1 to the original post and Paul's. > > Putting per user data in the DNS is a lousy approach, it has never been > a succes because the DNS administrators are typically network admins and > they are a separate class to DNS admins. > > Hey, DNS is just a protocol. I don't think anybody is suggesting > running end-user data off of bind9 :-) > > The critical question is one of trust management: using webfinger > ties you to the "web pki" for all practical purposes. Using dane ties > you to the dnssec root. Personally I'd prefer more options. > Then use DANE to authenticate the HTTPS server in the WebFinger transaction.... --Richard > > > > > A better approach would be to use WebFinger/XKMS/LDAP/TBS to serve up an > EE cert for the end user and to use DANE to establish a trust anchor under > which the EE cert is issued. > > > The amount of email that is protected by message layer security is a > negligible fraction of that protected by STARTTLS. One of the main reasons > for that is that the per client user model is fundamentally broken. > > > > On Fri, Apr 19, 2013 at 5:03 PM, Paul Hoffman wrote: > >> On Apr 19, 2013, at 1:29 PM, Richard Barnes wrote: >> >> > Just a thought: It might be simpler to do S/MIME certificate discovery >> using WebFinger than using DANE. You would just have to do an HTTPS query >> to a URI of the form... >> > >> > < >> https://example.com/.well-known/webfinger?resource=mailto:rlb@example.com&rel=certificate >> > >> > >> > ... then parse a JSON object to find the certificate. As opposed to >> having an appropriately upgraded DNS library, being able to do DNSSEC, and >> parsing the binary record format. >> >> That might be a good way to do certificate discovery, but not really a >> good way to have a second trust anchor if one wanted to get away from the >> distributed PKIX hierarchies. >> >> There are plenty of ways to do certificate discovery. The question is how >> to be sure that the certificate you get is one you want to use. >> >> > This process could still benefit from DANE, via TLSA validation on the >> HTTPS connection. And basically the only documentation you would need >> would be to define the "certificate" relation type. >> >> Um, doesn't that wipe out the supposed advantages you list above? >> >> --Paul Hoffman >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >> > > > > -- > Website: http://hallambaker.com/ > > > _______________________________________________ > dane mailing listdane@ietf.orghttps://www.ietf.org/mailman/listinfo/dane > > > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > > --047d7b47249e1ea85704dbd24b1b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On F= ri, May 3, 2013 at 8:15 AM, Leif Johansson <leifj@mnt.se> wrote:<= br>
=20 =20 =20
On 05/03/2013 01:47 PM, Phillip Hallam-Baker wrote:
+1 to the original post and Paul's.

Putting per user data in the DNS is a lousy approach, it has never been a succes because the DNS administrators are typically network admins and they are a separate class to DNS admins.
Hey, DNS is just a protocol. I don't think anybody is suggesting running end-user data off of bind9 :-)

The critical question is one of trust management: using webfinger
ties you to the "web pki" for all practical purposes. Using d= ane ties
you to the dnssec root.=A0 Personally I'd prefer more options.

Then use DANE to authenticate the HTTPS s= erver in the WebFinger transaction....

--Richard


=A0




A better approach would be to use WebFinger/XKMS/LDAP/TBS to serve up an EE cert for the end user and to use DANE to establish a trust anchor under which the EE cert is issued.


The amount of email that is protected by message layer security is a negligible fraction of that protected by STARTTLS. One of the main reasons for that is that the per client user model is fundamentally broken.



On Fri, Apr 19, 2013 at 5:03 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
On Apr 19, 2013, at 1:29 PM, Richard Barnes <rlb@ipv.s= x> wrote:

> Just a thought: It might be simpler to do S/MIME certificate discovery using WebFinger than using DANE. =A0You would just have to do an HTTPS query to a URI of the =A0form...
>
> <https://example.com/.well-known/webfinger?resource=3Dmailto:rlb@example.co= m&rel=3Dcertificate>
>
> ... then parse a JSON object to find the certificate. =A0As opposed to having an appropriately upgraded DNS library, being able to do DNSSEC, and parsing the binary record format.

That might be a good way to do certificate discovery, but not really a good way to have a second trust anchor if one wanted to get away from the distributed PKIX hierarchies.

There are plenty of ways to do certificate discovery. The question is how to be sure that the certificate you get is one you want to use.

> This process could still benefit from DANE, via TLSA validation on the HTTPS connection. =A0And basically the only documentation you would need would be to define the "certificate" relation type.

Um, doesn't that wipe out the supposed advantages you list above?

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



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


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


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


--047d7b47249e1ea85704dbd24b1b-- From warren@kumari.net Fri May 3 10:08:33 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A8A321F9890 for ; Fri, 3 May 2013 10:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100 X-Spam-Level: X-Spam-Status: No, score=-100 tagged_above=-999 required=5 tests=[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 xNrdcPyPcN8U for ; Fri, 3 May 2013 10:08:25 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C27D21F997B for ; Fri, 3 May 2013 09:39:27 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.117]) by vimes.kumari.net (Postfix) with ESMTPSA id 4375C1B405DF; Fri, 3 May 2013 12:39:24 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Warren Kumari In-Reply-To: <5183AA6B.7050701@mnt.se> Date: Fri, 3 May 2013 12:39:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <54F0487D-B8DD-4879-8599-977CF9A6F229@kumari.net> References: <2B53BDB5-1F1C-43E6-B7F7-904E8BB3E87A@vpnc.org> <5183AA6B.7050701@mnt.se> To: Leif Johansson X-Mailer: Apple Mail (2.1503) Cc: dane@ietf.org Subject: Re: [dane] To DANE or to WebFinger? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2013 17:08:33 -0000 On May 3, 2013, at 8:15 AM, Leif Johansson wrote: > On 05/03/2013 01:47 PM, Phillip Hallam-Baker wrote: >> +1 to the original post and Paul's. >>=20 >> Putting per user data in the DNS is a lousy approach, it has never = been a succes because the DNS administrators are typically network = admins and they are a separate class to DNS admins. > Hey, DNS is just a protocol. I don't think anybody is suggesting=20 > running end-user data off of bind9 :-) >=20 > The critical question is one of trust management: using webfinger > ties you to the "web pki" for all practical purposes. Using dane ties > you to the dnssec root. Personally I'd prefer more options. >=20 Using webfinger, but requiring that you get there with DANE ties you to = *both* -- if that good or not is left as an exercise to the reader :-) W >=20 >>=20 >> A better approach would be to use WebFinger/XKMS/LDAP/TBS to serve up = an EE cert for the end user and to use DANE to establish a trust anchor = under which the EE cert is issued. >>=20 >>=20 >> The amount of email that is protected by message layer security is a = negligible fraction of that protected by STARTTLS. One of the main = reasons for that is that the per client user model is fundamentally = broken. >>=20 >>=20 >>=20 >> On Fri, Apr 19, 2013 at 5:03 PM, Paul Hoffman = wrote: >> On Apr 19, 2013, at 1:29 PM, Richard Barnes wrote: >>=20 >> > Just a thought: It might be simpler to do S/MIME certificate = discovery using WebFinger than using DANE. You would just have to do an = HTTPS query to a URI of the form... >> > >> > = >> > >> > ... then parse a JSON object to find the certificate. As opposed = to having an appropriately upgraded DNS library, being able to do = DNSSEC, and parsing the binary record format. >>=20 >> That might be a good way to do certificate discovery, but not really = a good way to have a second trust anchor if one wanted to get away from = the distributed PKIX hierarchies. >>=20 >> There are plenty of ways to do certificate discovery. The question is = how to be sure that the certificate you get is one you want to use. >>=20 >> > This process could still benefit from DANE, via TLSA validation on = the HTTPS connection. And basically the only documentation you would = need would be to define the "certificate" relation type. >>=20 >> Um, doesn't that wipe out the supposed advantages you list above? >>=20 >> --Paul Hoffman >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >>=20 >>=20 >>=20 >> --=20 >> Website: http://hallambaker.com/ >>=20 >>=20 >> _______________________________________________ >> dane mailing list >>=20 >> 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 A. No Q. Is it sensible to top-post? From hallam@gmail.com Fri May 3 10:15:33 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C9E621F92F4 for ; Fri, 3 May 2013 10:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, 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 kh0C7ndWyUAG for ; Fri, 3 May 2013 10:15:24 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF7121F979C for ; Fri, 3 May 2013 09:49:03 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id r3so1417279wey.4 for ; Fri, 03 May 2013 09:49:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=4Eoii/BFh7E1buHUPxOGkAfrAIfvf2bK6/OnQcaSeI0=; b=iQSRooLQWFiaT5KxGQQNaeOL+Pn0t3mr0hWx/Pjn2zAzjY/jf1aEATJMBDaCRPDc0e 6PCJUxsV6+odzwk4jXGcXi3flbwjB3ik8Q9xiwEdyOGHHFL0tmL6aacrqPn7RkO1S536 /6B91IbGjlRJNghV/TzUXWYpzhKotqybHuE6y/o6yiI+O51tdRO5f9ssS0eher8k3ZuB RP7i3QKHRMUGTEvwpyvXIHUjuTtrwbv8TWxDRZjCGzPDT/9xwjk+mmEDVQH4Y+O9VdHM NcwKC3T66Mtefw9DJhfZwqyXy5lNA7SevfZCzsOoFdgynP3ThFKIR9Les5BQGwmBbFuO rnmw== MIME-Version: 1.0 X-Received: by 10.180.95.106 with SMTP id dj10mr13724627wib.1.1367599742279; Fri, 03 May 2013 09:49:02 -0700 (PDT) Received: by 10.194.121.161 with HTTP; Fri, 3 May 2013 09:49:02 -0700 (PDT) Date: Fri, 3 May 2013 12:49:02 -0400 Message-ID: From: Phillip Hallam-Baker To: "dane@ietf.org" Content-Type: multipart/alternative; boundary=f46d04428d92d5658504dbd320f8 Subject: [dane] A different approach to SRV discovery. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2013 17:15:37 -0000 --f46d04428d92d5658504dbd320f8 Content-Type: text/plain; charset=ISO-8859-1 It has been apparent to me for several years that the IETF needs to have a better approach to service discovery and that SRV like technologies should be a part of that solution. Making DANE work with SRV discovery seems to be a good idea. But it is a piecemeal approach that I think is unlikely to help adoption of DANE or SRV type discovery. Rather than look at the problem from the point of view of making two existing technologies play nice together, it is better to approach the bigger problem we are trying to solve. I don't think DANE can be made to work nicely with SRV, NAPTR and the rest as people would like. But working the other way around and proposing a new discovery record that has support for DANE built in does allow a 'fluent' result. Proposing new discovery mechanisms is not to be done lightly but neither SRV nor NAPTR is adequate for Web Services in any case. SRV only provides a redirection to a domain name, Web Services require the ability to host multiple Web Services on the same server under the same domain name. Hence the need for the URI proposal. SRV records don't have quite enough power, NAPTR records have too much. They were designed to support URN discovery and not service discovery. Constraints: 1) The IETF has three separate prefix based discovery mechanisms: SRV, NAPTR and URI (proposed) in addition to A and AAAA. 1a) Protocol designers should not choose the discovery mechanism because the constraints that affect the choice of mechanism are all constraints that fall on the network administrator deploying the system. 1b) The design of DNS makes the use of multiple records for the same purpose highly unsatisfactory and inefficient. 1c) SRV and NAPTR are already deployed and so any accommodations have to be made in DANE. 2) The IETF has also proposed two separate mechanisms for asserting a PKI policy information. There is DANE and there is HTTP certificate pinning. 3) Application providers tell us that they will only perform a limited number of DNS lookups to support discovery. At the moment they are required to do A, AAAA, and possibly SRV or NAPTR as well plus potentially a whole additional resolution chain afterward. Assertions A1: There should not be a choice between mechanisms, there should instead be an order of precedence so that if there is a record of type X it will take precedence over all the other types of record. A2: Rather than trying to force a choice between mechanisms asserting or pinning a public key, the discovery mechanism should be agnostic and support both. These considerations result in the following design. We introduce a new record, the URII record that has the same syntax as the existing URI record proposal but instead of the target being just a URI, it is a URI followed by optional discovery parameters: _service1.example.com URII 10 10 "https://ws.example.com/service1/" _service2.example.com URII 10 10 "https://ws.example.com/service2/ dane" _service3.example.com URII 10 10 "https://ws.example.com/service3/ pin=foo" Service1 simply redirects to a Web Service URI just like the current URI scheme does. Service2 and Service3 have a redirect but also provide TLS policy information. In the first case the discovery record says 'look for DANE records' in the second case the HTTP pinning data is specified. Note that the discovery parameters could also tell us other things we might want to know, whether to look for an A or AAAA record for example. Rules for processing URII records would be as follows: 1) If a URII record set is present it takes precedence over all A, AAAA, SRV, NAPTR and URI record sets. 2) Unless the specification of the Web Service explicitly states that other record types are not supported, Web Services MUST specify A, AAAA, SRV or NAPTR records to support discovery by clients that do not support URII. The motivation behind this particular dance is to enable optimization and rationalization of the discovery process as a whole rather than piecemeal additions that create even more complexity. The DNS protocol only supports queries for one RR type at a time, there are multiple areas of interest that would all like to add in a little nugget of information into the discovery process. Special pleading is not going to work. There is never going to be consensus that applications should support DANE or TLS cert pinning or any one of the dozens of schemes that have been proposed. At the moment everyone concentrates on the arguments why their pet project should have priority. That is not productive. If we are going to get anywhere then it has got to stop being a choice between extended discovery for DANE vs extended discovery for other purposes. We have to have one mechanism that can satisfy every requirement to hook a little bit of extra data into the discovery process if any of those requirements is going to be satisfied. -- Website: http://hallambaker.com/ --f46d04428d92d5658504dbd320f8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
It has been apparent to me for several years that the IETF= needs to have a better approach to service discovery and that SRV like tec= hnologies should be a part of that solution.

Makin= g DANE work with SRV discovery seems to be a good idea. But it is a pieceme= al approach that I think is unlikely to help adoption of DANE or SRV type d= iscovery. Rather than look at the problem from the point of view of making = two existing technologies play nice together, it is better to approach the = bigger problem we are trying to solve.

I don't think DANE can be made to work = nicely with SRV, NAPTR and the rest as people would like. But working the o= ther way around and proposing a new discovery record that has support for D= ANE built in does allow a 'fluent' result.

Proposing new discovery mechanisms is not t= o be done lightly but neither SRV nor NAPTR is adequate for Web Services in= any case. SRV only provides a redirection to a domain name, Web Services r= equire the ability to host multiple Web Services on the same server under t= he same domain name. Hence the need for the URI proposal. SRV records don&#= 39;t have quite enough power, NAPTR records have too much. They were design= ed to support URN discovery and not service discovery.


Constraints:

1) The IETF has three separate prefix based dis= covery mechanisms: SRV, NAPTR and URI (proposed) in addition to A and AAAA.=

1a) Protocol designers should not choose th= e discovery mechanism because the constraints that affect the choice of mec= hanism are all constraints that fall on the network administrator deploying= the system.

1b) The design of DNS makes the use of mult= iple records for the same purpose highly unsatisfactory and inefficient.=A0=

1c) SRV and NAPTR are already deploye= d and so any=A0accommodations have to be made in DANE.=A0


2) The IETF has also p= roposed two separate mechanisms for asserting a PKI policy information. The= re is DANE and there is HTTP certificate pinning.


3) Application providers tell us that they = will only perform a limited number of DNS lookups to support discovery. At = the moment they are required to do A, AAAA, and possibly SRV or NAPTR as we= ll plus potentially a whole additional resolution chain afterward.


Assertions

A1: There should not be a choice between mechanis= ms, there should instead be an order of precedence so that if there is a re= cord of type X it will take precedence over all the other types of record.<= /div>

A2: Rather than trying to force a choice = between mechanisms asserting or pinning a public key, the discovery mechani= sm should be agnostic and support both.


These considerations result in the following design. W= e introduce a new record, the URII record that has the same syntax as the e= xisting URI record proposal but instead of the target being just a URI, it = is a URI followed by optional discovery parameters:


Service1 simply redirects to a Web Service URI just like the cur= rent URI scheme does.

Service2 and Ser= vice3 have a redirect but also provide TLS policy information. In the first= case the discovery record says 'look for DANE records' in the seco= nd case the HTTP pinning data is specified.

Note that the discovery parameters could also tel= l us other things we might want to know, whether to look for an A or AAAA r= ecord for example.=A0


Rules f= or processing URII records would be as follows:

1) If a URII record set is present it takes= precedence over all A, AAAA, SRV, NAPTR and URI record sets.=A0

2) Unless the specification of the Web Service e= xplicitly states that other record types are not supported, Web Services MU= ST specify A, AAAA, SRV or NAPTR records to support discovery by clients th= at do not support URII.


The motivation behind = this particular dance is to enable optimization and rationalization of the = discovery process as a whole rather than piecemeal additions that create ev= en more complexity.

The DNS protocol only supports queries for = one RR type at a time, there are multiple areas of interest that would all = like to add in a little nugget of information into the discovery process.= =A0

Special pleading is not going to work. Ther= e is never going to be consensus that applications should support DANE or T= LS cert pinning or any one of the dozens of schemes that have been proposed= . At the moment everyone concentrates on the arguments why their pet projec= t should have priority. That is not productive.

If we are going to get anywhere then it has= got to stop being a choice between extended discovery for DANE vs extended= discovery for other purposes. We have to have one mechanism that can satis= fy every requirement to hook a little bit of extra data into the discovery = process if any of those requirements is going to be satisfied.



--
Website: http://hallambaker.com/
--f46d04428d92d5658504dbd320f8-- From hallam@gmail.com Fri May 3 17:24:08 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7355D21F8E99 for ; Fri, 3 May 2013 17:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.328 X-Spam-Level: X-Spam-Status: No, score=-1.328 tagged_above=-999 required=5 tests=[AWL=1.272, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 8V4ervqBVM5x for ; Fri, 3 May 2013 17:24:07 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 50C0221F85DB for ; Fri, 3 May 2013 17:24:04 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id h11so1227885wiv.0 for ; Fri, 03 May 2013 17:24:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=CUxgxO0wt8k/tWtNvCy5r9TmnM8ktQ1I4B5XRNSYpiA=; b=rC+c6Z8xL6H1RBsmwq6iMZ+A8YsBJ51TPJiAudLrhn45VhrzKyHrIgiBkU9SaSZg9N YjYyBtHzqnYmYBLzUWTL+oVdrTvDY2UJK73SC5n3nluyeQA5KrksiVBkfGd7g7+jBSuT DnDnyTyUEYDh41/1ehl+rVKk+xHHDYYh9sagUkAA20My/JHXIhPOjJ3XX1sUIP0temkS KqiZecGlBGXVanORx5Su2eJkRjyk8I3wj10+y6V84cEBPNv5A+jd1yMzaOAVCllpwvo9 srmfI9R5fCBJIHc9RRjZY2lfZ0aoLtqDO68zSsXEfnwF6jsnFu2FPmQs8RNGEVIEmk37 XN2A== MIME-Version: 1.0 X-Received: by 10.180.185.179 with SMTP id fd19mr365050wic.1.1367627043523; Fri, 03 May 2013 17:24:03 -0700 (PDT) Received: by 10.194.121.161 with HTTP; Fri, 3 May 2013 17:24:03 -0700 (PDT) In-Reply-To: References: <2B53BDB5-1F1C-43E6-B7F7-904E8BB3E87A@vpnc.org> <5183AA6B.7050701@mnt.se> Date: Fri, 3 May 2013 20:24:03 -0400 Message-ID: From: Phillip Hallam-Baker To: Richard Barnes Content-Type: multipart/alternative; boundary=001a11c25e4c1d544c04dbd97cf0 Cc: "dane@ietf.org" Subject: Re: [dane] To DANE or to WebFinger? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2013 00:24:08 -0000 --001a11c25e4c1d544c04dbd97cf0 Content-Type: text/plain; charset=ISO-8859-1 On Fri, May 3, 2013 at 11:49 AM, Richard Barnes wrote: > On Fri, May 3, 2013 at 8:15 AM, Leif Johansson wrote: > >> On 05/03/2013 01:47 PM, Phillip Hallam-Baker wrote: >> >> +1 to the original post and Paul's. >> >> Putting per user data in the DNS is a lousy approach, it has never been >> a succes because the DNS administrators are typically network admins and >> they are a separate class to DNS admins. >> >> Hey, DNS is just a protocol. I don't think anybody is suggesting >> running end-user data off of bind9 :-) >> >> The critical question is one of trust management: using webfinger >> ties you to the "web pki" for all practical purposes. Using dane ties >> you to the dnssec root. Personally I'd prefer more options. >> > > Then use DANE to authenticate the HTTPS server in the WebFinger > transaction.... > If you are going to do that you might as well just use TLS for the SMTP transaction, it would be much stronger. It is bad enough overloading the DNS to be a key centric PKI. The DNS is at least a trusted infrastructure. But people who run Web servers do not make security promises to the people who run the email server and your proposal would make the security of their email hostage to the security of the Web server. Web servers have active code crawling on them. They are connected up to network file systems. They are 50 shades of yuk from a security point of view. -- Website: http://hallambaker.com/ --001a11c25e4c1d544c04dbd97cf0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, May 3, 2013 at 11:49 AM, Richard Barnes &= lt;rlb@ipv.sx> wrote:
=
On Fri, May 3, 2013 at 8:15 AM= , Leif Johansson <leifj@mnt.se> wrote:
=20 =20 =20
On 05/03/2013 01:47 PM, Phillip Hallam-Baker wrote:
+1 to the original post and Paul's.

Putting per user data in the DNS is a lousy approach, it has never been a succes because the DNS administrators are typically network admins and they are a separate class to DNS admins.
Hey, DNS is just a protocol. I don't think anybody is suggesting running end-user data off of bind9 :-)

The critical question is one of trust management: using webfinger
ties you to the "web pki" for all practical purposes. Using d= ane ties
you to the dnssec root.=A0 Personally I'd prefer more options.

Then use DANE to authenticate the H= TTPS server in the WebFinger transaction....

If you are going to do that you might as well jus= t use TLS for the SMTP transaction, it would be much stronger.

It is bad enough overloading the DNS to be a key c= entric PKI. The DNS is at least a trusted infrastructure. But people who ru= n Web servers do not make security promises to the people who run the email= server and your proposal would make the security of their email hostage to= the security of the Web server.

Web servers have active code crawling on th= em. They are connected up to network file systems. They are 50 shades of yu= k from a security point of view.

=A0
--
Website: http://hallambaker.com/=
--001a11c25e4c1d544c04dbd97cf0-- From rlb@ipv.sx Fri May 3 19:01:28 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E34C21F8F6E for ; Fri, 3 May 2013 19:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.357 X-Spam-Level: * X-Spam-Status: No, score=1.357 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, 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 iKNiVyT5LtrC for ; Fri, 3 May 2013 19:01:23 -0700 (PDT) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id A9D3421F8F02 for ; Fri, 3 May 2013 19:01:23 -0700 (PDT) Received: by mail-ob0-f176.google.com with SMTP id er7so1861042obc.7 for ; Fri, 03 May 2013 19:01:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=xtCuBm8wFKqxT+jJCu/+bH4ui0Qis1kdQ0OOG3miqo8=; b=Qm00vBmb2XUmyrM1UY0l9MOzqpv9JFCDrvvjimY7mnHeuJcJ7pQui5X5Phxrkyw/+g q+dORE8/SDYZ3aEJXpUtANeDI9skQHHadil2hwKkR+dJqnPMgMmSGDgvhJe5dX3gha6Y SBKm4LytVfyjW8d9EE0qcq03kK3hsUyMTyKrBsvtyCs+EMWQCPWNsY3IwV7jcV22A8mB fmcqUERoh/x/YKAyaV5rk21FYR00t+k3RuqAj3lIhZ2jpFXturRBZiCJp2x3R99nmL66 W8GKw/XB8HNKusnrsifjOvyhr1Ga2u1qwdbBfnw594h22DNFvo56W2CCIpdLJfFbeaol WGAw== MIME-Version: 1.0 X-Received: by 10.60.173.196 with SMTP id bm4mr3423541oec.108.1367632883026; Fri, 03 May 2013 19:01:23 -0700 (PDT) Received: by 10.60.132.172 with HTTP; Fri, 3 May 2013 19:01:22 -0700 (PDT) X-Originating-IP: [108.18.40.68] In-Reply-To: References: <2B53BDB5-1F1C-43E6-B7F7-904E8BB3E87A@vpnc.org> <5183AA6B.7050701@mnt.se> Date: Fri, 3 May 2013 22:01:22 -0400 Message-ID: From: Richard Barnes To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=089e01184cf82d2b3804dbdad8f3 X-Gm-Message-State: ALoCoQmTL3GQxgM3j3hT6QiYenBmR52B/w3GFn1mk0pHX2ZIrKVzo/fYsEgjW9Ppe4GL33qqWpVa Cc: "dane@ietf.org" Subject: Re: [dane] To DANE or to WebFinger? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2013 02:01:28 -0000 --089e01184cf82d2b3804dbdad8f3 Content-Type: text/plain; charset=ISO-8859-1 On Friday, May 3, 2013, Phillip Hallam-Baker wrote: > > > > On Fri, May 3, 2013 at 11:49 AM, Richard Barnes > > wrote: > >> On Fri, May 3, 2013 at 8:15 AM, Leif Johansson >> > wrote: >> >>> On 05/03/2013 01:47 PM, Phillip Hallam-Baker wrote: >>> >>> +1 to the original post and Paul's. >>> >>> Putting per user data in the DNS is a lousy approach, it has never >>> been a succes because the DNS administrators are typically network admins >>> and they are a separate class to DNS admins. >>> >>> Hey, DNS is just a protocol. I don't think anybody is suggesting >>> running end-user data off of bind9 :-) >>> >>> The critical question is one of trust management: using webfinger >>> ties you to the "web pki" for all practical purposes. Using dane ties >>> you to the dnssec root. Personally I'd prefer more options. >>> >> >> Then use DANE to authenticate the HTTPS server in the WebFinger >> transaction.... >> > > If you are going to do that you might as well just use TLS for the SMTP > transaction, it would be much stronger. > > It is bad enough overloading the DNS to be a key centric PKI. The DNS is > at least a trusted infrastructure. But people who run Web servers do not > make security promises to the people who run the email server and your > proposal would make the security of their email hostage to the security of > the Web server. > > Web servers have active code crawling on them. They are connected up to > network file systems. They are 50 shades of yuk from a security point of > view. > I know, good thing there's nothing security-critical on the web! > > -- > Website: http://hallambaker.com/ > --089e01184cf82d2b3804dbdad8f3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Friday, May 3, 2013, Phillip Hallam-Baker wrote:



On Fri, May 3, 2013 at 11:49 AM, Richard Barnes <rlb@ipv.sx> wrote:
=
On Fri, May 3, 2013 at 8:15 AM, Leif Johans= son <leifj@mnt.se> wrote:<= br>
=20 =20 =20
On 05/03/2013 01:47 PM, Phillip Hallam-Baker wrote:
+1 to the original post and Paul's.

Putting per user data in the DNS is a lousy approach, it has never been a succes because the DNS administrators are typically network admins and they are a separate class to DNS admins.
Hey, DNS is just a protocol. I don't think anybody is suggesting running end-user data off of bind9 :-)

The critical question is one of trust management: using webfinger
ties you to the "web pki" for all practical purposes. Using d= ane ties
you to the dnssec root.=A0 Personally I'd prefer more options.

Then use DANE to authenticate the H= TTPS server in the WebFinger transaction....

If you are going to do that you might as well just use = TLS for the SMTP transaction, it would be much stronger.

It is bad enough overloading the DNS to be a key centric PKI. The DN= S is at least a trusted infrastructure. But people who run Web servers do n= ot make security promises to the people who run the email server and your p= roposal would make the security of their email hostage to the security of t= he Web server.

Web servers have active code crawling on them. They are= connected up to network file systems. They are 50 shades of yuk from a sec= urity point of view.

I know, good thing there's nothing security-critical on the web!

</irony>

=A0
=A0
--
Website: http:= //hallambaker.com/
--089e01184cf82d2b3804dbdad8f3-- From paul@nohats.ca Sun May 5 09:46:28 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5785521F96E4 for ; Sun, 5 May 2013 09:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 ZmvVL3y8ub5d for ; Sun, 5 May 2013 09:46:22 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 79B8921F96EA for ; Sun, 5 May 2013 09:46:13 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3b3Xyp1TCgz24C; Sun, 5 May 2013 12:46:10 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 6MSYL50FTJDI; Sun, 5 May 2013 12:46:09 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Sun, 5 May 2013 12:46:09 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 2078681126; Sun, 5 May 2013 12:46:10 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 11F9A81125; Sun, 5 May 2013 12:46:10 -0400 (EDT) Date: Sun, 5 May 2013 12:46:10 -0400 (EDT) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: User-Agent: Alpine 2.10 (LFD 1266 2009-07-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] A different approach to SRV discovery. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 05 May 2013 16:46:28 -0000 On Fri, 3 May 2013, Phillip Hallam-Baker wrote: > 2) The IETF has also proposed two separate mechanisms for asserting a PKI policy information. There is DANE and there is HTTP > certificate pinning. > _service3.example.com URII 10 10 "https://ws.example.com/service3/ pin=foo" If you trust the DNS for certificate information, then pinning is not needed. The whole idea behind pinning as I understood it was that people don't want trust the DNS. > Note that the discovery parameters could also tell us other things we might want to know, whether to look for an A or AAAA record > for example.  And then you can merge in the HASTLS requirements too :P > Special pleading is not going to work. There is never going to be consensus that applications should support DANE or TLS cert > pinning or any one of the dozens of schemes that have been proposed. At the moment everyone concentrates on the arguments why > their pet project should have priority. That is not productive. > > If we are going to get anywhere then it has got to stop being a choice between extended discovery for DANE vs extended discovery > for other purposes. We have to have one mechanism that can satisfy every requirement to hook a little bit of extra data into the > discovery process if any of those requirements is going to be satisfied. I'm unclear what problem you are trying to solve. If you trust the dns, you don't need pinning. If you don't trust the dns, you cannot trust your new discovery scheme either? Paul From viktor1dane@dukhovni.org Sun May 5 10:36:13 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 847C021F9707 for ; Sun, 5 May 2013 10:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_54=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 8MHHR251CTtf for ; Sun, 5 May 2013 10:36:08 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 5E22D21F9703 for ; Sun, 5 May 2013 10:36:08 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id A00B82AB9B3; Sun, 5 May 2013 17:36:07 +0000 (UTC) Date: Sun, 5 May 2013 17:36:07 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130505173607.GT22116@mournblade.imrryr.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] A different approach to SRV discovery. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 May 2013 17:36:13 -0000 On Sun, May 05, 2013 at 12:46:10PM -0400, Paul Wouters wrote: > If you trust the DNS for certificate information, then pinning is not > needed. The whole idea behind pinning as I understood it was that people > don't want trust the DNS. I thought pinning had more to do with not trusting rogue/compromised public CAs, than not trusting DNS. Or in any case little to do with not trusting DNSSEC. But either way, publishing DANE TLSA scales substantially better than pinning, so I agree that pinning via DNSSEC makes little sense. > I'm unclear what problem you are trying to solve. If you trust the dns, > you don't need pinning. If you don't trust the dns, you cannot trust > your new discovery scheme either? The problem as I understand it is a generalization of DCE's CDS which supported secure registration and discovery of DCE service endpoints (which proto,addr,port hosts a particular service UUID). We have MX records for SMTP and SRV records for Kerberos, LDAP, and now also POP and IMAP. We also have NAPTR for SIP. Now that TLS is potentially subject to one of two PKIs, when one publishes a service address (whether directly as with a URL in an HTML element or indirectly via some sort of DNS lookup) complications may arise when the address specifies TLS without specifying the relevant PKI. SMTP is lucky in that (email addresses unlike https URLs) can't specify TLS, thereforre clients can use DANE to securely discover support for DANE TLS, and thus have on hand not only the protocol to use, but also the authentication parameters required to use it. With other services, (where the endpoint is say an https URL) TLS is signalled separately from DANE, and clients and servers may need to support two PKIs in parallel at the same service endpoint. The simplest solution, if one introduce new DNS-based service location records, is to note that trusting the DNS is unavoidable, since that's where one gets service location and security parameters. Therefore, to the extent that any such new mechanism explicitly specifies TLS, it should I think require and use some form of DANE key management (be it TLSA or other forms public keys in DNS) unconditionally. With new "better than SRV" records there is no legacy install base to worry about. -- Viktor. From huitema@huitema.net Sun May 5 19:22:51 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37F2821F8A4E for ; Sun, 5 May 2013 19:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 CwTnAHNDnlCB for ; Sun, 5 May 2013 19:22:45 -0700 (PDT) Received: from xsmtp02.mail2web.com (xsmtp02.mail2web.com [168.144.250.215]) by ietfa.amsl.com (Postfix) with ESMTP id 19AE521F8A48 for ; Sun, 5 May 2013 19:22:43 -0700 (PDT) Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp02.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1UZB4b-0005rB-Nj for dane@ietf.org; Sun, 05 May 2013 22:22:42 -0400 Received: (qmail 27994 invoked from network); 6 May 2013 02:22:39 -0000 Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[24.18.205.153]) (envelope-sender ) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 6 May 2013 02:22:39 -0000 From: "Christian Huitema" To: References: <20130505173607.GT22116@mournblade.imrryr.org> In-Reply-To: <20130505173607.GT22116@mournblade.imrryr.org> Date: Sun, 5 May 2013 19:22:38 -0700 Message-ID: <000c01ce4a00$948ee050$bdaca0f0$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLO+M038XqP7fHHySe6fIJuyc7TpQHAKFIzAkvfcGWW1a5vQA== Content-Language: en-us Subject: Re: [dane] A different approach to SRV discovery. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 06 May 2013 02:22:51 -0000 > Viktor wrote: > > The simplest solution, if one introduce new DNS-based service location records, > is to note that trusting the DNS is unavoidable, since that's where one gets > service location and security parameters. I agree with you, up to this point. Yes, the client has no recourse but to trust the publisher of the service location, since that publisher could choose to publish whatever it pleases. But then, we have a layer of indirection. What if the names published in the SRV record are not related to the name published of the service? What if these were different domains? -- Christian Huitema From hallam@gmail.com Mon May 6 15:54:38 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 279A121F9352 for ; Mon, 6 May 2013 15:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, 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 wnYP-9rEkCSc for ; Mon, 6 May 2013 15:54:37 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id D3D1A21F9180 for ; Mon, 6 May 2013 15:54:33 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id z2so3369490wey.5 for ; Mon, 06 May 2013 15:54:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Pv6AwB3z/pG5fcY3pRDUvV1/9hFLAUJcPZo8Y7NvKRk=; b=C3ocPmRjZauvLA/kwasxTYR5ryae0evcgohAw/i49egaRCJCEvflh162tFxQB+pyQT sRYaR4ypIn5ZJaIl/t0Izo+GDOzMeUGha5FpJmsXfBHihKkqLc/xkXzruMlRFbJrXd3M i5UjDC5H7Y9RtX/Bwh2obsRDYBDaVVT0VnL//PIH1u1a9dFGLWrlykYXBF4C2fwQ3fUt Md4rhnt0XFadfy7ylXcONYWHmkQ0hNooWpaoYviQQQRLTQpq5+1cJhLAAFNA78KAnt+P EMNLlv4crW5M4DjT4nxKezGnDhEIDo6buwJwAyZQvKsui6GQS9ne0AemV2Q/H+K01U80 BsnQ== MIME-Version: 1.0 X-Received: by 10.180.95.106 with SMTP id dj10mr11028434wib.1.1367880872978; Mon, 06 May 2013 15:54:32 -0700 (PDT) Received: by 10.194.121.161 with HTTP; Mon, 6 May 2013 15:54:32 -0700 (PDT) In-Reply-To: References: Date: Tue, 7 May 2013 00:54:32 +0200 Message-ID: From: Phillip Hallam-Baker To: Paul Wouters Content-Type: multipart/alternative; boundary=f46d04428d9287747304dc1495ee Cc: "dane@ietf.org" Subject: Re: [dane] A different approach to SRV discovery. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 06 May 2013 22:54:38 -0000 --f46d04428d9287747304dc1495ee Content-Type: text/plain; charset=ISO-8859-1 On Sun, May 5, 2013 at 6:46 PM, Paul Wouters wrote: > On Fri, 3 May 2013, Phillip Hallam-Baker wrote: > > 2) The IETF has also proposed two separate mechanisms for asserting a PKI >> policy information. There is DANE and there is HTTP >> certificate pinning. >> > > _service3.example.com URII 10 10 "https://ws.example.com/**service3/pin=foo" >> > > If you trust the DNS for certificate information, then pinning is not > needed. The whole idea behind pinning as I understood it was that people > don't want trust the DNS. No, the main reason they were doing pinning was that they did not want to be dependent on the vagaries and constraints of the DNS infrastructure or hostage to deployment of DNSSEC. This is a way to merge that approach back into a DNS-centric approach in a clean way. > Note that the discovery parameters could also tell us other things we >> might want to know, whether to look for an A or AAAA record >> for example. >> > > And then you can merge in the HASTLS requirements too :P Yes, those too, in fact they are quite easy, specify HTTPS as the transport. > Special pleading is not going to work. There is never going to be >> consensus that applications should support DANE or TLS cert >> pinning or any one of the dozens of schemes that have been proposed. At >> the moment everyone concentrates on the arguments why >> their pet project should have priority. That is not productive. >> >> If we are going to get anywhere then it has got to stop being a choice >> between extended discovery for DANE vs extended discovery >> for other purposes. We have to have one mechanism that can satisfy every >> requirement to hook a little bit of extra data into the >> discovery process if any of those requirements is going to be satisfied. >> > > I'm unclear what problem you are trying to solve. If you trust the dns, > you don't need pinning. If you don't trust the dns, you cannot trust > your new discovery scheme either? It has nothing to do with whether you trust the DNS or not. Trust is not a binary quality for a start. The issue is how the application discovers that there is useful information to acquire. At present a client that is using extended discovery typically has to perform three parallel queries: A, AAAA, SRV. Adding in DANE makes four and only provides value if the probability of there being a DANE record is high enough to make the effort worthwhile. I am suggesting that instead of making three requests we prune it down to two, the legacy A record request and an additional request that is extensible and so can tell us if we need to make additional requests. -- Website: http://hallambaker.com/ --f46d04428d9287747304dc1495ee Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, May 5, 2013 at 6:46 PM, Paul Wouters <paul@nohats.ca= > wrote:
On Fri, 3 May 2013, Phillip Hallam-Baker wrote:

2) The IETF has also proposed two separate mechanisms for asserting a PKI p= olicy information. There is DANE and there is HTTP
certificate pinning.

_service3.example= .com URII 10 10 "https://ws.example.com/service3/ pin=3Dfoo"

If you trust the DNS for certificate information, then pinning is not
needed. The whole idea behind pinning as I understood it was that people don't want trust the DNS.

No, the= main reason they were doing pinning was that they did not want to be depen= dent on the vagaries and constraints of the DNS infrastructure or hostage t= o deployment of DNSSEC.

This is a way to merge that approach back i= nto a DNS-centric approach in a clean way.

= =A0
Note that the discovery parameters could also tell us other things we might= want to know, whether to look for an A or AAAA record
for example.=A0

And then you can merge in the HASTLS requirements too :P
<= br>
Yes, those too, in fact they are quite easy, specify HT= TPS as the transport.
=A0
Special pleading is not going to work. There is never going to be consensus= that applications should support DANE or TLS cert
pinning or any one of the dozens of schemes that have been proposed. At the= moment everyone concentrates on the arguments why
their pet project should have priority. That is not productive.

If we are going to get anywhere then it has got to stop being a choice betw= een extended discovery for DANE vs extended discovery
for other purposes. We have to have one mechanism that can satisfy every re= quirement to hook a little bit of extra data into the
discovery process if any of those requirements is going to be satisfied.

I'm unclear what problem you are trying to solve. If you trust the dns,=
you don't need pinning. If you don't trust the dns, you cannot trus= t
your new discovery scheme either?

It has no= thing to do with whether you trust the DNS or not. Trust is not a binary qu= ality for a start.

The issue is ho= w the application discovers that there is useful information to acquire. At= present a client that is using extended discovery typically has to perform= three parallel queries: A, AAAA, SRV. Adding in DANE makes four and only p= rovides value if the probability of there being a DANE record is high enoug= h to make the effort worthwhile.

I am suggesting that instead of making thre= e requests we prune it down to two, the legacy A record request and an addi= tional request that is extensible and so can tell us if we need to make add= itional requests.

=A0

--
Websit= e: http://hallambaker.com/
--f46d04428d9287747304dc1495ee-- From oej@edvina.net Fri May 10 05:14:29 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 419BC21F8F07 for ; Fri, 10 May 2013 05:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-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 wD-7pgd4q+cM for ; Fri, 10 May 2013 05:14:28 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id A064621F8D0B for ; Fri, 10 May 2013 05:14:28 -0700 (PDT) Received: from [IPv6:2001:16d8:cc57:1000::42:1004] (unknown [IPv6:2001:16d8:cc57:1000::42:1004]) by smtp7.webway.se (Postfix) with ESMTPA id 818AF93DE3F; Fri, 10 May 2013 12:14:27 +0000 (UTC) From: "Olle E. Johansson" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 10 May 2013 14:14:26 +0200 Message-Id: To: dane WG list Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [dane] draft-hoffman-dane-smime X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 10 May 2013 12:14:29 -0000 Hi! This draft only talks about "Mail user agents" but as far as I see it it = applies to SIP user agents as well. One difference is that in a SIP uri, the username part is optional: sip:chris@example.com sip:conference.example.com Are both valid URI's. But that doesn't seem to make much of a = difference. The records would become: MNUHE2LT._smimecert.example.com _smimecert.conference.example.com Would it make sense to incorporate SIP into this draft? /O= From paul.hoffman@vpnc.org Fri May 10 08:40:34 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB77521F8A18 for ; Fri, 10 May 2013 08:40:34 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XodfOtMoSkjj for ; Fri, 10 May 2013 08:40:34 -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 775D321F81FE for ; Fri, 10 May 2013 08:40:34 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r4AFeMD9096001 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 10 May 2013 08:40:25 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Paul Hoffman In-Reply-To: Date: Fri, 10 May 2013 08:40:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <53CAE660-A114-4C59-B795-169A9844C4B4@vpnc.org> References: To: "Olle E. Johansson" X-Mailer: Apple Mail (2.1503) Cc: dane WG list Subject: Re: [dane] draft-hoffman-dane-smime X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 10 May 2013 15:40:35 -0000 On May 10, 2013, at 5:14 AM, Olle E. Johansson wrote: > This draft only talks about "Mail user agents" but as far as I see it = it applies to SIP user agents as well. Nope, it only applies to MUAs. > One difference is that in a SIP uri, the username part is optional: >=20 > sip:chris@example.com > sip:conference.example.com Yes, exactly. > Are both valid URI's. But that doesn't seem to make much of a = difference. The records would become: >=20 > MNUHE2LT._smimecert.example.com > _smimecert.conference.example.com >=20 > Would it make sense to incorporate SIP into this draft? I don't think so. It would be better to do that as a separate document = with separate considerations for the SIP protocol. --Paul Hoffman= From oej@edvina.net Fri May 10 09:37:18 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDEC621F8E46 for ; Fri, 10 May 2013 09:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-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 1tjbtRqMdK3O for ; Fri, 10 May 2013 09:37:17 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 82B4621F8D84 for ; Fri, 10 May 2013 09:37:17 -0700 (PDT) Received: from [IPv6:2001:16d8:cc57:1000::42:1004] (unknown [IPv6:2001:16d8:cc57:1000::42:1004]) by smtp7.webway.se (Postfix) with ESMTPA id 37BAD93C1AF; Fri, 10 May 2013 16:37:16 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: "Olle E. Johansson" In-Reply-To: <53CAE660-A114-4C59-B795-169A9844C4B4@vpnc.org> Date: Fri, 10 May 2013 18:37:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7A7C9B3A-02B0-455A-AFD1-5ECE2B2252AF@edvina.net> References: <53CAE660-A114-4C59-B795-169A9844C4B4@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1503) Cc: dane WG list Subject: Re: [dane] draft-hoffman-dane-smime X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 10 May 2013 16:37:19 -0000 10 maj 2013 kl. 17:40 skrev Paul Hoffman : > On May 10, 2013, at 5:14 AM, Olle E. Johansson wrote: >=20 >> This draft only talks about "Mail user agents" but as far as I see it = it applies to SIP user agents as well. >=20 > Nope, it only applies to MUAs. >=20 >> One difference is that in a SIP uri, the username part is optional: >>=20 >> sip:chris@example.com >> sip:conference.example.com >=20 > Yes, exactly. >=20 >> Are both valid URI's. But that doesn't seem to make much of a = difference. The records would become: >>=20 >> MNUHE2LT._smimecert.example.com >> _smimecert.conference.example.com >>=20 >> Would it make sense to incorporate SIP into this draft? >=20 > I don't think so. It would be better to do that as a separate document = with separate considerations for the SIP protocol. Ok. Can the "_smimecert" tag be used for this as well or should this be = exclusive for S/MIME-Email? /O= From mamille2@cisco.com Fri May 10 10:41:28 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CDB521F8976 for ; Fri, 10 May 2013 10:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 ZvWbJA182g0n for ; Fri, 10 May 2013 10:41:23 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id D23CD21F84AF for ; Fri, 10 May 2013 10:41:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7617; q=dns/txt; s=iport; t=1368207682; x=1369417282; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ZtVUoVgg/Y9SaQJTqMxTk8zN6lwDbLBiYrZa4BDagfs=; b=mkAnyMMSVN9uS/DSp1OrPB1OkLJD3PFYOYFM9fyAcd6rK/SbSS58goxX oVq8kAAvZfs3oMWcG3NE3mZzdHq6Z4zkaORwgNro3WbGVwRXJizK/5Vnf UWdNUEmJ1OIefml5gp1O9kxf9ZNBnOmfR3aEoZtXRGspxAE0nFva0aiNz A=; X-Files: smime.p7s : 4136 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAF4wjVGtJXHB/2dsb2JhbABSgwc3wBt8FnSCHwEBAQMBaBEQAgEIGAokAjAlAgQOBQgGh3gGDL1pjWYQgQExBwmCa2EDj3SBKYc1kA+DD4FyNQ X-IronPort-AV: E=Sophos;i="4.87,650,1363132800"; d="p7s'?scan'208";a="209005153" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 10 May 2013 17:41:22 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r4AHfM5R007199 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 10 May 2013 17:41:22 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.178]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Fri, 10 May 2013 12:41:21 -0500 From: "Matt Miller (mamille2)" To: "Olle E. Johansson" Thread-Topic: [dane] draft-hoffman-dane-smime Thread-Index: AQHOTXfuIKnVifsW902WBLBWdLpCVZj+4j4AgAAP5YCAABHpgA== Date: Fri, 10 May 2013 17:41:21 +0000 Message-ID: References: <53CAE660-A114-4C59-B795-169A9844C4B4@vpnc.org> <7A7C9B3A-02B0-455A-AFD1-5ECE2B2252AF@edvina.net> In-Reply-To: <7A7C9B3A-02B0-455A-AFD1-5ECE2B2252AF@edvina.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.129.24.59] Content-Type: multipart/signed; boundary="Apple-Mail=_3778C945-4A34-44BE-9446-573219F10359"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: Paul Hoffman , dane WG list Subject: Re: [dane] draft-hoffman-dane-smime X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 10 May 2013 17:41:28 -0000 --Apple-Mail=_3778C945-4A34-44BE-9446-573219F10359 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 10, 2013, at 10:37 AM, Olle E. Johansson wrote: >=20 > 10 maj 2013 kl. 17:40 skrev Paul Hoffman : >=20 >> On May 10, 2013, at 5:14 AM, Olle E. Johansson = wrote: >>=20 >>> This draft only talks about "Mail user agents" but as far as I see = it it applies to SIP user agents as well. >>=20 >> Nope, it only applies to MUAs. >>=20 >>> One difference is that in a SIP uri, the username part is optional: >>>=20 >>> sip:chris@example.com >>> sip:conference.example.com >>=20 >> Yes, exactly. >>=20 >>> Are both valid URI's. But that doesn't seem to make much of a = difference. The records would become: >>>=20 >>> MNUHE2LT._smimecert.example.com >>> _smimecert.conference.example.com >>>=20 >>> Would it make sense to incorporate SIP into this draft? >>=20 >> I don't think so. It would be better to do that as a separate = document with separate considerations for the SIP protocol. >=20 > Ok. >=20 > Can the "_smimecert" tag be used for this as well or should this be = exclusive for S/MIME-Email? XMPP could also benefit from something very much like this, forTLS = mutual auth, E2E, etc. =46rom my reading, I think there are just enough = semantic differences that _smimecert is probably not resuable for us, = and I suspect the same is true for SIP. However, the syntax is going to be nearly identical, so maybe we can = find some common ground to build on? - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. --Apple-Mail=_3778C945-4A34-44BE-9446-573219F10359 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMezCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGPzCCBSeg AwIBAgIDBoRIMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTMwNDMwMjE1NDQyWhcNMTQwNTAyMDUzOTA0WjBbMRkwFwYDVQQNExBiN2F6NndOY0t0R3JtMEpF MRswGQYDVQQDDBJtYW1pbGxlMkBjaXNjby5jb20xITAfBgkqhkiG9w0BCQEWEm1hbWlsbGUyQGNp c2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJbKBMsG+9UFTx9uq/bhhXgu vJvO8z7cwKaqqwZhVf5z/kHFyCNijtmTOE+YXjA8mWR4aoBwB5SvGypI/cJUofJ+AlBTC4g+RMx/ K0Ab4/jQqTQz9CDzMOB+Wm+rt8ZJ7A8ZzOJmNDAsf/VvB8l2A1SQz1UsAixgH16NTr8SlblAXEKk 4hwpCudUiNjjQokqJ0H686UBKVorcZSgXaza8XMqGtJF/8mNhR9GQYi7Xht1ky+9LFOrto2daZto KJRwMeVusVdHUeKEQSu7jztw8HchH3KEb7Q+r5X+hhDZoddfKE8d5eyPuhiZdrzv7OlNZ0fSLdx7 3AE3nx9/R5YlXucCAwEAAaOCAtgwggLUMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQW MBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUxGd+/qrdVudHrIKkw5xOMY7eaLUwHwYD VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHQYDVR0RBBYwFIESbWFtaWxsZTJAY2lzY28u Y29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBp c3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9m IHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBw dXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYG A1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4G CCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIv Y2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2Vy dHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAlDhXbGEI7lbqUcu5r2JHZaMsbRZda/99ZqODzWGX 0llou9jGccsAWDPPwRRe2+ROpXfH4cuJZElTcLDeZSp/qpXKhjYieFSX8+Ml9sKEj5UOSqQLyoLk PtrIJV12Jk3nuG2Jc0UeEnGwK/aqtzy7+bfEVI0ziyVM2gChHh0RH74KyiwYWknbOTRIkZcz/ulE DVFQp63uj6wfmDNvAUHBAdhKVqA1S/rfP1KcDZpf1NfvwXJibiqTRA6K1EOxTJOP41n/XdvHqHXL RWL2xrOUI9/URANr/ok3OrsuZEMFnAAGefS1bWS/hFtUGVkHGiKEBbyDW7da2ULXbuC7umrQnzGC A28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDAJBgUrDgMCGgUA oIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA1MTAxNzQx MjFaMCMGCSqGSIb3DQEJBDEWBBQ7R7JXEPRkpS9ZqmWq9BW5xCXaFzCBpQYJKwYBBAGCNxAEMYGX MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3Mg MSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDCBpwYLKoZIhvcNAQkQAgsxgZeg gZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1 cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAx IFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBoRIMA0GCSqGSIb3DQEBAQUABIIBAJGb 5XXe88psI8ILXcrsDBmNMd6pP+oo0s6QvI3dtSrRwJZTooMR86DkTtUy3MmdPTCnYOleeg+ek5rO 0gQVRWbtUqiA1+zvGMQMEEfz/GhUSpQB8HJ00/1u0BBLvH0YOBJ/URZX4MSbhfUOX+UvAjCnU/re Zef5W9FnxiW8Z5iU8vDv1SI7Abmq8ChA1aYE64A4M8mdjWPhOwAbRZxZEjDiOCSxBPrV2FoFPB7N PPYYEBPDWHASzwaGjaMgRtL6O4OCbsqyQHjUJ2F0fRVVI+wKFTdV31z4eNyy654fvRrlVatHZxSz vaeCisJhDQiJDQl21eBEcM66bfnGCltmB4cAAAAAAAA= --Apple-Mail=_3778C945-4A34-44BE-9446-573219F10359-- From oej@edvina.net Fri May 10 10:50:16 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A026F21F901F for ; Fri, 10 May 2013 10:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-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 VleuqY2VTV5g for ; Fri, 10 May 2013 10:50:15 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 38EDE21F89A6 for ; Fri, 10 May 2013 10:50:14 -0700 (PDT) Received: from [IPv6:2001:16d8:cc57:1000::42:1004] (unknown [IPv6:2001:16d8:cc57:1000::42:1004]) by smtp7.webway.se (Postfix) with ESMTPA id 443D293C1AF; Fri, 10 May 2013 17:50:13 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: "Olle E. Johansson" In-Reply-To: Date: Fri, 10 May 2013 19:50:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <81EEFE26-C6C1-4D0B-83B6-F7FB5CD3DB71@edvina.net> References: <53CAE660-A114-4C59-B795-169A9844C4B4@vpnc.org> <7A7C9B3A-02B0-455A-AFD1-5ECE2B2252AF@edvina.net> To: "Matt Miller (mamille2)" X-Mailer: Apple Mail (2.1503) Cc: Paul Hoffman , dane WG list Subject: Re: [dane] draft-hoffman-dane-smime X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 10 May 2013 17:50:17 -0000 10 maj 2013 kl. 19:41 skrev "Matt Miller (mamille2)" = : >=20 > On May 10, 2013, at 10:37 AM, Olle E. Johansson = wrote: >=20 >>=20 >> 10 maj 2013 kl. 17:40 skrev Paul Hoffman : >>=20 >>> On May 10, 2013, at 5:14 AM, Olle E. Johansson = wrote: >>>=20 >>>> This draft only talks about "Mail user agents" but as far as I see = it it applies to SIP user agents as well. >>>=20 >>> Nope, it only applies to MUAs. >>>=20 >>>> One difference is that in a SIP uri, the username part is optional: >>>>=20 >>>> sip:chris@example.com >>>> sip:conference.example.com >>>=20 >>> Yes, exactly. >>>=20 >>>> Are both valid URI's. But that doesn't seem to make much of a = difference. The records would become: >>>>=20 >>>> MNUHE2LT._smimecert.example.com >>>> _smimecert.conference.example.com >>>>=20 >>>> Would it make sense to incorporate SIP into this draft? >>>=20 >>> I don't think so. It would be better to do that as a separate = document with separate considerations for the SIP protocol. >>=20 >> Ok. >>=20 >> Can the "_smimecert" tag be used for this as well or should this be = exclusive for S/MIME-Email? >=20 >=20 > XMPP could also benefit from something very much like this, forTLS = mutual auth, E2E, etc. =46rom my reading, I think there are just enough = semantic differences that _smimecert is probably not resuable for us, = and I suspect the same is true for SIP. >=20 > However, the syntax is going to be nearly identical, so maybe we can = find some common ground to build on? >=20 Maybe the tag can be application agnostic, like _usernamesep There's no real need that the name is depending upon the application, as = we have a record type that indicates the app.=20 /O= From carl@redhoundsoftware.com Fri May 10 10:59:22 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3D8A21F8EED for ; Fri, 10 May 2013 10:59:22 -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 Hb0+nUWY0mgZ for ; Fri, 10 May 2013 10:59:12 -0700 (PDT) Received: from mail-qe0-f51.google.com (mail-qe0-f51.google.com [209.85.128.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8150E21F89A6 for ; Fri, 10 May 2013 10:59:12 -0700 (PDT) Received: by mail-qe0-f51.google.com with SMTP id x7so2654142qeu.10 for ; Fri, 10 May 2013 10:59:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:user-agent:date:subject:from:to:cc:message-id :thread-topic:in-reply-to:mime-version:content-type :content-transfer-encoding:x-gm-message-state; bh=DKsKbEL40UnxZlqvlQLNCc0VsP1H90JHBO30+CCaq1o=; b=bWzJ8oPAArKhDqsYJ8mUg46NbOYJyaL9Q7tRKIjKM2DfeYwjg0TOmI5471AGrGtJc9 ySCi0UZY0i3tGi8KAjuzmie2qkK2Zjreq8B4oIAqQ8lT7A5xGsR66WwLe/JNQDBlbrqb NiOruG/Xj70SDcGWrSFkEjdJciVlqExx8SMCSYpdaurG+9QBm3UcNCx5FxaPP32RBXMd YRm8PnBt/72Qy9MJ9oejuNwVoFyIjDdhjTOOwC8LEWIRE/KK0F9SYIbBjP20jZlmG/7F IBZCdDo6UCYytOZpjghALs9NqwcCvIrAvN/XTTJ2LfRacG2jxpvPJHGTiLzCNR8gqhvQ 8Zew== X-Received: by 10.224.179.202 with SMTP id br10mr12690114qab.83.1368208751648; Fri, 10 May 2013 10:59:11 -0700 (PDT) Received: from [192.168.2.7] (pool-173-79-106-247.washdc.fios.verizon.net. [173.79.106.247]) by mx.google.com with ESMTPSA id n3sm2710941qat.6.2013.05.10.10.59.09 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 10 May 2013 10:59:11 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.3.1.130117 Date: Fri, 10 May 2013 13:59:07 -0400 From: Carl Wallace To: "Olle E. Johansson" , "Matt Miller (mamille2)" Message-ID: Thread-Topic: [dane] draft-hoffman-dane-smime In-Reply-To: <81EEFE26-C6C1-4D0B-83B6-F7FB5CD3DB71@edvina.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Gm-Message-State: ALoCoQn7r0YvsOKKz4FLXS98MeBR5mZ9LgtCMR5lDEF2mLyOlv+rnJxxSMRmZdOhnIH3/EIhbtT/ Cc: Paul Hoffman , dane WG list Subject: Re: [dane] draft-hoffman-dane-smime X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 10 May 2013 17:59:22 -0000 On 5/10/13 1:50 PM, "Olle E. Johansson" wrote: > >10 maj 2013 kl. 19:41 skrev "Matt Miller (mamille2)" : > >> >> On May 10, 2013, at 10:37 AM, Olle E. Johansson wrote: >> >>> >>> 10 maj 2013 kl. 17:40 skrev Paul Hoffman : >>> >>>> On May 10, 2013, at 5:14 AM, Olle E. Johansson wrote: >>>> >>>>> This draft only talks about "Mail user agents" but as far as I see >>>>>it it applies to SIP user agents as well. >>>> >>>> Nope, it only applies to MUAs. >>>> >>>>> One difference is that in a SIP uri, the username part is optional: >>>>> >>>>> sip:chris@example.com >>>>> sip:conference.example.com >>>> >>>> Yes, exactly. >>>> >>>>> Are both valid URI's. But that doesn't seem to make much of a >>>>>difference. The records would become: >>>>> >>>>> MNUHE2LT._smimecert.example.com >>>>> _smimecert.conference.example.com >>>>> >>>>> Would it make sense to incorporate SIP into this draft? >>>> >>>> I don't think so. It would be better to do that as a separate >>>>document with separate considerations for the SIP protocol. >>> >>> Ok. >>> >>> Can the "_smimecert" tag be used for this as well or should this be >>>exclusive for S/MIME-Email? >> >> >> XMPP could also benefit from something very much like this, forTLS >>mutual auth, E2E, etc. From my reading, I think there are just enough >>semantic differences that _smimecert is probably not resuable for us, >>and I suspect the same is true for SIP. >> >> However, the syntax is going to be nearly identical, so maybe we can >>find some common ground to build on? >> > >Maybe the tag can be application agnostic, like _usernamesep > >There's no real need that the name is depending upon the application, as >we have a record type that indicates the app. > Seems like this could result in encrypting mail for the wrong certificate. The current spec should probably address the case where a user has one certificate for signing and one for encrypting independent of whether the spec supports multiple applications. Noting the application must check key usage/EKU is probably good enough. > >/O >_______________________________________________ >dane mailing list >dane@ietf.org >https://www.ietf.org/mailman/listinfo/dane From cloos@jhcloos.com Fri May 10 13:46:00 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC24521F8916 for ; Fri, 10 May 2013 13:46:00 -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 Mr4AfzJ3e7G2 for ; Fri, 10 May 2013 13:45:56 -0700 (PDT) Received: from eagle.jhcloos.com (eagle.jhcloos.com [207.210.242.212]) by ietfa.amsl.com (Postfix) with ESMTP id 94C4D21F885A for ; Fri, 10 May 2013 13:45:56 -0700 (PDT) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 28D7A40158; Fri, 10 May 2013 20:45:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1368218755; bh=iPWw+rboeITmAi7wgxtlhNtYw8/igOqI06b9McG4y3Y=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=YNlcHTchDlHPGhn30wdWtnxFgC16K37+EeIUMeiNAR9e69pyOl2jTIBg6EEsOvpot 11AMMi3+V8bvmtq5v3Z9B4VoVDuqfLeGroBweQ7ULV8JmutvYiSQubuoR4X2/oetcj hr2GfB2ivKfG7HNhZQFSHhD83Aif71iWJirnCHns= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 61B1FDF517; Fri, 10 May 2013 20:42:33 +0000 (UTC) From: James Cloos To: "Olle E. Johansson" In-Reply-To: <81EEFE26-C6C1-4D0B-83B6-F7FB5CD3DB71@edvina.net> (Olle E. Johansson's message of "Fri, 10 May 2013 19:50:11 +0200") References: <53CAE660-A114-4C59-B795-169A9844C4B4@vpnc.org> <7A7C9B3A-02B0-455A-AFD1-5ECE2B2252AF@edvina.net> <81EEFE26-C6C1-4D0B-83B6-F7FB5CD3DB71@edvina.net> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.3.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2013 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: Fri, 10 May 2013 16:42:33 -0400 Message-ID: Lines: 14 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:28:130510:oej@edvina.net::udc05Ex4a6xrRNCS:002VojP X-Hashcash: 1:28:130510:mamille2@cisco.com::oZ+8JLUyyqnoDmj+:000000000000000000000000000000000000000000HBke7 X-Hashcash: 1:28:130510:paul.hoffman@vpnc.org::0yaX/jbtdCew/i0b:0000000000000000000000000000000000000002n5G8 X-Hashcash: 1:28:130510:dane@ietf.org::BEmQrhv6MuAmUv5C:000h9xv3 Cc: dane WG list , Paul Hoffman Subject: Re: [dane] draft-hoffman-dane-smime X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 10 May 2013 20:46:00 -0000 >>>>> "OEJ" == Olle E Johansson writes: OEJ> Maybe the tag can be application agnostic, like _usernamesep OEJ> There's no real need that the name is depending upon the OEJ> application, as we have a record type that indicates the app. I suggested _at at some point in the past. Short and apt. But the newer idea of using webfinger seems more usable and reliable. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From jakob@kirei.se Wed May 15 06:43:18 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA1E21F8F83 for ; Wed, 15 May 2013 06:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.716 X-Spam-Level: * X-Spam-Status: No, score=1.716 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 GTtrQz+0lw2O for ; Wed, 15 May 2013 06:43:09 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id 474B221F8F7A for ; Wed, 15 May 2013 06:43:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:from:content-type:content-transfer-encoding:subject:message-id:date: to:mime-version:x-mailer; bh=CK3hiujdv/Msss3jglKBTDHSX/Ws3gSfc1AQnQQiaak=; b=dsCLsxJeJMo3uRJUZtUuFgsid+ZMOves76JkdeUKj4h7ib4FAEZP85PmlS62blhuDDlj+s7oa1w0W k8yYk4MZJvW8Sy6UsaGpZ3wRaHgc98rzAccds6efEhJrd8qfrPmxI5IFdqav7e4/xqwlRAwpByIfcL Cx+Ac+2xXnaGdTyM= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS for ; Wed, 15 May 2013 15:43:04 +0200 (CEST) From: Jakob Schlyter Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <1CC18C6E-EE83-466B-A083-1C3E9F289352@kirei.se> Date: Wed, 15 May 2013 15:43:01 +0200 To: dane WG list Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [dane] DANE for OpenSSL X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2013 13:43:18 -0000 Andy Polyakov has committed initial support for DANE in OpenSSL - please = see http://rt.openssl.org/Ticket/Display.html?id=3D3003 for more = information. jakob From richard.lamb@icann.org Wed May 15 08:27:19 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D7FE21F86DD for ; Wed, 15 May 2013 08:27:18 -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 RS7mlUOXh+cR for ; Wed, 15 May 2013 08:27:14 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id E9C4821F8FB6 for ; Wed, 15 May 2013 08:27:13 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Wed, 15 May 2013 08:27:08 -0700 From: Richard Lamb To: Jakob Schlyter , dane WG list Date: Wed, 15 May 2013 08:26:09 -0700 Thread-Topic: [dane] DANE for OpenSSL Thread-Index: Ac5Rcjb7f3qHA57sRZ+od/V2DWTOpwADjYVw Message-ID: <5648A8908CCB564EBF46E2BC904A75B15FF1C38B30@EXVPMBX100-1.exc.icann.org> References: <1CC18C6E-EE83-466B-A083-1C3E9F289352@kirei.se> In-Reply-To: <1CC18C6E-EE83-466B-A083-1C3E9F289352@kirei.se> 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] DANE for OpenSSL X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2013 15:27:19 -0000 Woo hoo.. now if I can use MSFT Detours (or something free) to make it part= of windows crypto api... ;-)=20 -----Original Message----- From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of Jak= ob Schlyter Sent: Wednesday, May 15, 2013 6:43 AM To: dane WG list Subject: [dane] DANE for OpenSSL Andy Polyakov has committed initial support for DANE in OpenSSL - please se= e http://rt.openssl.org/Ticket/Display.html?id=3D3003 for more information. jakob _______________________________________________ dane mailing list dane@ietf.org https://www.ietf.org/mailman/listinfo/dane From Marco.Davids@sidn.nl Wed May 15 08:33:28 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 477F421F90BB for ; Wed, 15 May 2013 08:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_DYNAMIC_DHCP=1.398, RDNS_DYNAMIC=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 IN1Qx4fMMRlg for ; Wed, 15 May 2013 08:33:24 -0700 (PDT) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) by ietfa.amsl.com (Postfix) with ESMTP id 685B921F90CC for ; Wed, 15 May 2013 08:33:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn_nl; c=relaxed/relaxed; h=message-id:date:from:organization:user-agent:mime-version:to:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding:x-originating-ip; bh=jA+3ZqxMvhPb9H6rgpdw4juY5lAD+vFSs5XrD9bNtro=; b=X+JeOh+AhyjbdwM2ISqG4F6BpZMxLGy7V5jfwcR9vSrEOb4Zq/Kvw1n5Mm/ow9a0fGA0sTyR+eR05bRh1b3zxCBIX9Upc6HyAK14G0DO46KzRDKeUdkQVSNLYAT9BWiLZQ9+pbC3hvCB7No1gNanEZ5nqrrStg9a3fVeTZrx+wY= Received: from kahubcasn02.SIDN.local ([192.168.2.74]) by ede1-kamx.sidn.nl with ESMTP id r4FFXNgH028315-r4FFXNgJ028315 (version=TLSv1 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Wed, 15 May 2013 17:33:23 +0200 Received: from KAHUBCAS1.SIDN.local (192.168.2.41) by kahubcasn02.SIDN.local (192.168.2.74) with Microsoft SMTP Server (TLS) id 14.2.328.9; Wed, 15 May 2013 17:33:23 +0200 Received: from dhcp-27-94.ripemtg.ripe.net (94.198.152.219) by KAHUBCAS1.SIDN.local (192.168.2.41) with Microsoft SMTP Server (TLS) id 14.2.328.9; Wed, 15 May 2013 17:33:23 +0200 Message-ID: <5193AAC0.8020509@sidn.nl> Date: Wed, 15 May 2013 16:33:20 +0100 From: "Marco Davids (SIDN)" Organization: SIDN User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: References: <1CC18C6E-EE83-466B-A083-1C3E9F289352@kirei.se> <5648A8908CCB564EBF46E2BC904A75B15FF1C38B30@EXVPMBX100-1.exc.icann.org> In-Reply-To: <5648A8908CCB564EBF46E2BC904A75B15FF1C38B30@EXVPMBX100-1.exc.icann.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [94.198.152.219] Subject: Re: [dane] DANE for OpenSSL X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2013 15:33:28 -0000 On 5/15/13 4:26 PM, Richard Lamb wrote: > Woo hoo.. now if I can use MSFT Detours (or something free) to make it part of windows crypto api... ;-) Has anyone had time to play with GnuTLS already? http://gnutls.org/manual/html_node/DANE-API.html Experiences, thoughts? -- Marco > > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of Jakob Schlyter > Sent: Wednesday, May 15, 2013 6:43 AM > To: dane WG list > Subject: [dane] DANE for OpenSSL > > Andy Polyakov has committed initial support for DANE in OpenSSL - please see http://rt.openssl.org/Ticket/Display.html?id=3003 for more information. > > 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 viktor1dane@dukhovni.org Wed May 15 08:55:27 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C09D21F87BB for ; Wed, 15 May 2013 08:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=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 JqT1ecQBnwnh for ; Wed, 15 May 2013 08:55:23 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 287C521F8765 for ; Wed, 15 May 2013 08:55:18 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 0597B2AAD96; Wed, 15 May 2013 15:55:18 +0000 (UTC) Date: Wed, 15 May 2013 15:55:17 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130515155517.GI14521@mournblade.imrryr.org> References: <1CC18C6E-EE83-466B-A083-1C3E9F289352@kirei.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1CC18C6E-EE83-466B-A083-1C3E9F289352@kirei.se> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] DANE for OpenSSL X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 15:55:27 -0000 On Wed, May 15, 2013 at 03:43:01PM +0200, Jakob Schlyter wrote: > Andy Polyakov has committed initial support for DANE in OpenSSL > - please see http://rt.openssl.org/Ticket/Display.html?id=3003 for > more information. Note, this "initial support", does not yet perform any verification based on TLSA records, it just adds a convenience TLSA RR lookup function that is conditional on libunbound. The application will need to call SSL_get_tlsa_record_byname() and then provide the output to the OpenSSL library via a control operation before the handshake. There are complications because EE certificate usage (1/3) TLSA records are different from TA (0/2) TLSA records. The former (or least 3 in any case) require no name checks, and the latter do. OpenSSL has no means to communicate the distinction, the result of the verification engine is either "verified" (as in trust chain verified) or not. Since with DANE it is not enough to know whether the chain is trusted, one needs to know whether name checks are still required, applications will have to also communicate the the names to accept (plural per draft-ietf-dane-srv) to the OpenSSL library. Further complications can arise with session reuse, depending on how client applications associate cached sessions with a particular peer. There is still a bunch of work before this is usable. This will by the way fail to compile if one defines OPENSSL_NO_LIBUNBOUND $ unifdef -DOPENSSL_NO_LIBUNBOUND ssl/dnssec.c | head -20 #include #include #include #include #include /* * Output is array packed as [len][data][len][data][0] */ unsigned char *SSL_get_tlsa_record_byname (const char *name,int port,int type) { unsigned char *ret=NULL; char *query=NULL; size_t qlen; if (ctx == NULL) return NULL; qlen = 7+5+strlen(name)+1; because "ctx" is not declared in that case, the declartion requires unbound.h: #include static struct ub_ctx *ctx = NULL; -- Viktor. From viktor1dane@dukhovni.org Wed May 15 11:21:03 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C56B21F88EA for ; Wed, 15 May 2013 11:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 FqJlywnXR5NT for ; Wed, 15 May 2013 11:20:58 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 55FCE21F8517 for ; Wed, 15 May 2013 11:20:58 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 78AB72AB9CB; Wed, 15 May 2013 18:20:57 +0000 (UTC) Date: Wed, 15 May 2013 18:20:57 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130515182057.GO14521@mournblade.imrryr.org> References: <1CC18C6E-EE83-466B-A083-1C3E9F289352@kirei.se> <20130515155517.GI14521@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130515155517.GI14521@mournblade.imrryr.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] DANE for OpenSSL X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 18:21:03 -0000 On Wed, May 15, 2013 at 03:55:17PM +0000, Viktor Dukhovni wrote: > Note, this "initial support", does not yet perform any verification > based on TLSA records, it just adds a convenience TLSA RR lookup > function that is conditional on libunbound. The application will > need to call SSL_get_tlsa_record_byname() and then provide the output > to the OpenSSL library via a control operation before the handshake. A few more comments: 0. The TLSA lookup function does not check the "bogus" field, which is documented as possibly set together with "secure", indicating a bogus DNS reply (unbound still returns the data it seems) and lets the caller decide. So the new TLSA lookup function is not safe. 1. The introduction of a dependency on libunbound is I think a mistake, applications should obtain TLSA RRs via whatever library they see fit. It is sufficient for OpenSSL to specify a suitable encoding of the TLSA RRs to be passed to the verification routine. 2. The packed encoding chosen is rather unnatural. A data structure would have been better than a packed array of lenghts and data buffers. struct SSL_TLSA_DATA { size_t rrcount; struct { size_t len; unsigned char *data; } rrdata[1]; } I don't think Andy Polykov reads this list. I'll forward him my comments under separate cover. -- Viktor. From appro@openssl.org Wed May 15 12:07:53 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3D9821F901D for ; Wed, 15 May 2013 12:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.215 X-Spam-Level: X-Spam-Status: No, score=-2.215 tagged_above=-999 required=5 tests=[AWL=0.034, 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 63bhi87iktAy for ; Wed, 15 May 2013 12:07:48 -0700 (PDT) Received: from stty.me.chalmers.se (stty.me.chalmers.se [129.16.50.165]) by ietfa.amsl.com (Postfix) with ESMTP id A5C6021F90FC for ; Wed, 15 May 2013 12:07:45 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by stty.me.chalmers.se (Postfix) with ESMTP id ADF9F2004; Wed, 15 May 2013 21:08:03 +0200 (CEST) Message-ID: <5193DCFE.9040708@openssl.org> Date: Wed, 15 May 2013 21:07:42 +0200 From: Andy Polyakov User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: dane@ietf.org References: <1CC18C6E-EE83-466B-A083-1C3E9F289352@kirei.se> <20130515155517.GI14521@mournblade.imrryr.org> <20130515182057.GO14521@mournblade.imrryr.org> In-Reply-To: <20130515182057.GO14521@mournblade.imrryr.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dane] DANE for OpenSSL X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2013 19:07:53 -0000 >> Note, this "initial support", does not yet perform any verification >> based on TLSA records, it just adds a convenience TLSA RR lookup >> function that is conditional on libunbound. The application will >> need to call SSL_get_tlsa_record_byname() and then provide the output >> to the OpenSSL library via a control operation before the handshake. I've replied to first message and it went to moderator for approval. > A few more comments: > > 0. The TLSA lookup function does not check the "bogus" field, which is > documented as possibly set together with "secure", indicating a bogus > DNS reply (unbound still returns the data it seems) and lets the caller > decide. So the new TLSA lookup function is not safe. OK. > 1. The introduction of a dependency on libunbound is I think a mistake, > applications should obtain TLSA RRs via whatever library they see fit. > It is sufficient for OpenSSL to specify a suitable encoding of the > TLSA RRs to be passed to the verification routine. Goal is to have libssl check config file for [libunbound] section and link to libunbound only if there is such section. In other words run-time link to libunbound will be optional. > 2. The packed encoding chosen is rather unnatural. A data structure > would have been better than a packed array of lenghts and data buffers. > > struct SSL_TLSA_DATA { > size_t rrcount; > struct { > size_t len; > unsigned char *data; > } rrdata[1]; > } Rationale behind the unnatural choice is to have possibility to generate record from scripting languages without having to create glue code. > I don't think Andy Polykov reads this list. I'll forward him my > comments under separate cover. I've now subscribed to the list. From appro@openssl.org Wed May 15 12:19:46 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3647E11E80A3 for ; Wed, 15 May 2013 12:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.022, 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 EL5aLEnRJniC for ; Wed, 15 May 2013 12:19:42 -0700 (PDT) Received: from stty.me.chalmers.se (stty.me.chalmers.se [129.16.50.165]) by ietfa.amsl.com (Postfix) with ESMTP id E104011E80AD for ; Wed, 15 May 2013 12:19:41 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by stty.me.chalmers.se (Postfix) with ESMTP id 50CAA2004 for ; Wed, 15 May 2013 21:20:00 +0200 (CEST) Message-ID: <5193DFCB.7030909@openssl.org> Date: Wed, 15 May 2013 21:19:39 +0200 From: Andy Polyakov User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: dane@ietf.org References: <1CC18C6E-EE83-466B-A083-1C3E9F289352@kirei.se> <20130515155517.GI14521@mournblade.imrryr.org> <20130515182057.GO14521@mournblade.imrryr.org> <5193DCFE.9040708@openssl.org> In-Reply-To: <5193DCFE.9040708@openssl.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dane] DANE for OpenSSL X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2013 19:19:46 -0000 >> 0. The TLSA lookup function does not check the "bogus" field, >> which is >> documented as possibly set together with "secure", indicating a bogus >> DNS reply (unbound still returns the data it seems) and lets the >> caller >> decide. So the new TLSA lookup function is not safe. > > OK. Or? Manual page says if both are zero, then no security for domain. It says nothing about both being set to 1. And example at unbound.net suggests that they can't be set together: if(result->secure) printf("Result is secure\n"); else if(result->bogus) From viktor1dane@dukhovni.org Wed May 15 14:30:38 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CEC111E80E2 for ; Wed, 15 May 2013 14:30:38 -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] 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 DQeMFSFtX9Pi for ; Wed, 15 May 2013 14:30:34 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 1B3F011E80DF for ; Wed, 15 May 2013 14:30:34 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 0C74B2AB9CB; Wed, 15 May 2013 21:30:33 +0000 (UTC) Date: Wed, 15 May 2013 21:30:32 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130515213032.GR14521@mournblade.imrryr.org> References: <1CC18C6E-EE83-466B-A083-1C3E9F289352@kirei.se> <20130515155517.GI14521@mournblade.imrryr.org> <20130515182057.GO14521@mournblade.imrryr.org> <5193DCFE.9040708@openssl.org> <5193DFCB.7030909@openssl.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5193DFCB.7030909@openssl.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] DANE for OpenSSL X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 21:30:38 -0000 On Wed, May 15, 2013 at 09:19:39PM +0200, Andy Polyakov wrote: > >> 0. The TLSA lookup function does not check the "bogus" > >>field, which is > >> documented as possibly set together with "secure", indicating a bogus > >> DNS reply (unbound still returns the data it seems) and lets > >>the caller > >> decide. So the new TLSA lookup function is not safe. > > > >OK. > > Or? Manual page says if both are zero, then no security for domain. > It says nothing about both being set to 1. And example at > unbound.net suggests that they can't be set together: > > if(result->secure) > printf("Result is secure\n"); > else if(result->bogus) Yes, it seems I did not find a sufficiently clear reference in my quick search for ub_resolve() documentation. The "secure" bit precludes bogus. When you're implementing the verification code for TLSA RRs, we should talk. I have a working implementation via the verify callback, and have spent a bunch of time thinking through some of the more subtle issues. You can look at tls_verify_certificate_callback() in: https://github.com/vdukhovni/postfix/blob/20130405-nonprod/postfix/src/tls/tls_verify.c -- Viktor. From appro@openssl.org Wed May 15 11:47:27 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A368921F8F69 for ; Wed, 15 May 2013 11:47:27 -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 CnZ9c5VhOwGR for ; Wed, 15 May 2013 11:47:23 -0700 (PDT) Received: from stty.me.chalmers.se (stty.me.chalmers.se [129.16.50.165]) by ietfa.amsl.com (Postfix) with ESMTP id 7777E21F8ECB for ; Wed, 15 May 2013 11:47:22 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by stty.me.chalmers.se (Postfix) with ESMTP id 09F062004; Wed, 15 May 2013 20:47:41 +0200 (CEST) Message-ID: <5193D838.6050204@openssl.org> Date: Wed, 15 May 2013 20:47:20 +0200 From: Andy Polyakov User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: dane@ietf.org References: <1CC18C6E-EE83-466B-A083-1C3E9F289352@kirei.se> <20130515155517.GI14521@mournblade.imrryr.org> In-Reply-To: <20130515155517.GI14521@mournblade.imrryr.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 15 May 2013 23:25:54 -0700 Subject: Re: [dane] DANE for OpenSSL X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2013 19:00:28 -0000 >> Andy Polyakov has committed initial support for DANE in OpenSSL >> - please see http://rt.openssl.org/Ticket/Display.html?id=3003 for >> more information. > > Note, this "initial support", does not yet perform any verification > based on TLSA records, it just adds a convenience TLSA RR lookup > function that is conditional on libunbound. Oops! Git noob mistake. http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=e815d72b1f489c2c38adf3eee87c02e1c5dd8f3c > There is still a bunch of work before this is usable. Yes, please get involved. > This will by the way fail to compile if one defines OPENSSL_NO_LIBUNBOUND > > $ unifdef -DOPENSSL_NO_LIBUNBOUND ssl/dnssec.c | head -20 http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=ddf918673d2d163fc0a6a6c9774b05dd1efb9857 From viktor1dane@dukhovni.org Thu May 16 00:14:17 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25D5221F8EFC for ; Thu, 16 May 2013 00:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 bR9TZmwzli9U for ; Thu, 16 May 2013 00:14:12 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id EF9BE21F882A for ; Thu, 16 May 2013 00:14:11 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 5A7B82AABCE; Thu, 16 May 2013 07:14:08 +0000 (UTC) Date: Thu, 16 May 2013 07:14:08 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130516071408.GA25466@mournblade.imrryr.org> References: <1CC18C6E-EE83-466B-A083-1C3E9F289352@kirei.se> <20130515155517.GI14521@mournblade.imrryr.org> <5193D838.6050204@openssl.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5193D838.6050204@openssl.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] DANE for OpenSSL X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 07:14:17 -0000 On Wed, May 15, 2013 at 08:47:20PM +0200, Andy Polyakov wrote: > >Note, this "initial support", does not yet perform any verification > >based on TLSA records, it just adds a convenience TLSA RR lookup > >function that is conditional on libunbound. > > Oops! Git noob mistake. Got the new code. Thanks. > >There is still a bunch of work before this is usable. > > Yes, please get involved. There are a number of immediate issues to address, some quite significant. I encourage you to take a look at the corresponding Postfix verification callback. I contributed it to Postfix under the Postfix license, but you may borrow from it under any license that meets your needs. The list below is not necessarily comprehensive. - At depth 0, dane_verify_callback() unconditionally returns "0" for certificate usages 0, 1. This aborts the handshake. The intent is probably to return "ok", not "0". But if you're raising an error for lack of a suitable TLSA "witness" certificate, you're obligated to call the application callback to vet the error. if (depth==0) { switch (s->tlsa_witness&0xff) { /* witnessed usage */ case 0: /* CA constraint */ if (s->tlsa_witness<0 && ctx->error==X509_V_OK) ctx->error = X509_V_ERR_INVALID_CA; return 0; case 1: /* service certificate constraint */ if (tlsa_ret!=0 && ctx->error==X509_V_OK) ctx->error = X509_V_ERR_CERT_UNTRUSTED; return 0; ... - At any depth, dane_verify_callback() must clear any witness for most errors (parent-child signature errors, expiration, ...) that are found at an equal or lower depth. The only errors that TLSA records can preempt are those relating lack of a trusted root. Otherwise, you may end up calling a chain valid, for containing a CA that did not actually sign the next certificate, or when that certificate expired. - There is no code to handle "IN TLSA 2 1 0", where a public key is given for a CA that may not be present in the peer's chain, but may the signer of the top certificate in the chain. - The application cannot distinguish between a usage 3 match, in which name checks don't apply, and other usages where name checks are still required. Both cases given X509_V_OK, but this is not sufficient. The Postfix implementation never sets X509_V_OK with EE certs, instead applications can check that condition against the leaf certificate when the handshake completes. This way (CA) verified certificates always need name checks, and if EE TLSA records are present the application calls suitable code to check these at the end. - The "IN TLSA x 0 0" comparisons are done via SHA-1 hashes, these are IMHO too weak in this context. The comparison should be bit for bit, or use at least SHA-256. - When the TLSA RRset is invalid, instead of returning an error when the user is setting SSL->tlsa_record to -1, the handshake proceeds only to be aborted unconditionally. if (tlsa_record == (void*)-1) { ctx->error = X509_V_ERR_INVALID_CA; /* temporary code? */ return 0; } This is needlessly late, and once again does not give the application callback a chance to continue. Which violates the application callback contract (it must be able to choose to continue despite all errors). The SSL_CTRL_PULL_TLSA_RECORD control should return an error when TLSA record lookups fail, and applications should decide what to do at that point, rather than in mid handshake. Of course with SSL_CTRL_SET_TLSA_RECORD, the application already knows when the value is ((void *)-1) and should again decide at that time. So I would say that this value should never be set at handshake time, it should be valid or NULL. Attempts to set it to "-1" should fail. - When allocating an SSL pointer via SSL_new() the ssl->tlsa_record element must be initialized to NULL. The memset( , 0, ) is not sufficient, the binary representation of a NULL pointer is implementation dependent and may not be all zero. - witness_usage is an unused variable. -- Viktor. From viktor1dane@dukhovni.org Thu May 16 08:17:32 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEC9421F9227 for ; Thu, 16 May 2013 08:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 JUajiIV58Y2Q for ; Thu, 16 May 2013 08:17:27 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 9F53421F918C for ; Thu, 16 May 2013 08:17:27 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id B103F2AB9C5; Thu, 16 May 2013 15:17:26 +0000 (UTC) Date: Thu, 16 May 2013 15:17:26 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130516151726.GC25466@mournblade.imrryr.org> References: <1CC18C6E-EE83-466B-A083-1C3E9F289352@kirei.se> <20130515155517.GI14521@mournblade.imrryr.org> <5193D838.6050204@openssl.org> <20130516071408.GA25466@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130516071408.GA25466@mournblade.imrryr.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] DANE for OpenSSL X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 15:17:32 -0000 On Thu, May 16, 2013 at 07:14:08AM +0000, Viktor Dukhovni wrote: > - At any depth, dane_verify_callback() must clear any witness for most > errors (parent-child signature errors, expiration, ...) that are found > at an equal or lower depth. The only errors that TLSA records can > preempt are those relating lack of a trusted root. > > Otherwise, you may end up calling a chain valid, for containing a CA > that did not actually sign the next certificate, or when that > certificate expired. I think the larger issue is model mismatch between the new dane callback which makes a global decision based observation of the entire chain, and the legacy application callback it consults, which previously only made decisions one error at a time. Specifically, it is not reasonable to propagate errors to the application callback that you'll later want to "retract" because you finally found the trusted CA. With applications that provide TLSA records via either the PULL or the SET controls, it is likely necessary to *document* and implement a new contract with the application verification callback. - If none of the TLSA records are usable (unknown usage, selector or matching type or perhaps invalid length) the dane callback sets the verification status to a new value say: ctx->error = X509_V_ERR_UNUSABLE_TLSA_RRS and invokes the application callback (cert/depth TBD). The application can decide to clear this error and revert to normal PKIX processing, or to leave it set and consider the chain unverified. - Otherwise, the dane callback will only call the application callback (at least once) when the dane callback is itself called at depth 0. On successful verification of the chain via trust anchor (usage 0 or 2), which means that one the following is true: 1. A TA RR was matched at some higher depth. The trust depth (as with PKIX) is set one lower indicating the first certificate in the chain that is issued by the TA, provided no errors other than trust errors were found at or below the trust depth. 2. An explicit public key whose certificate is not in the chain signed the topmost certificate, which is not expired. The top depth becomes the trust depth, unless errors other than trust errors are found at any depth in the chain. 3. The depth 0 cert is a self-signed TLSA TA with acceptable usage bits to be both a CA and an SSL server and no errors other trust errors have yet been found at depth 0. The certificate verification status will be set to X509_V_OK and the application callback will be called with ok=1, depth set to 0, and the current certificate set to the depth zero certificate. The application callback is responsible for performing peer name checks on the leaf certificate setting the store error if name checks fail. If there is an EE TLSA record with certificate usage 3, and the only error is that the chain is not trusted, the store error must be set by the dane callback to X509_V_ERR_CERT_UNTRUSTED, and the application callback must be called with depth = 0 and cert equal to the depth 0 certificate. The application callback should be able to call a new documented function to perform EE verification of the leaf certificate. Otherwise, the application callback will be called with the "error certificate" (see the Postfix code) and corresponding error state and depth. This allows the application can do proper error reporting and decide whether to complete the handshake. Modifications to the above may be necessary, or some other approach entirely may be better, but the current approach is I think unreasonable. The application callback is blind to the DANE checks and is being called with misleading error indications that may be retracted, and is not called with ok=1 at depth 0 when DANE decides that the chain is trusted after all. I don't think it is possible to implement sensible application callbacks within the current model. -- Viktor. From warren@kumari.net Thu May 16 08:25:49 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F76D21F8B18 for ; Thu, 16 May 2013 08:25:37 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fw-pA1rA1ypT for ; Thu, 16 May 2013 08:25:32 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id D137C21F87CD for ; Thu, 16 May 2013 08:25:30 -0700 (PDT) Received: from dhcp-25-116.ripemtg.ripe.net (dhcp-25-116.ripemtg.ripe.net [193.0.25.116]) by vimes.kumari.net (Postfix) with ESMTPSA id D84591B403A5; Thu, 16 May 2013 11:25:23 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Warren Kumari In-Reply-To: <5193DCFE.9040708@openssl.org> Date: Thu, 16 May 2013 11:25:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1CC18C6E-EE83-466B-A083-1C3E9F289352@kirei.se> <20130515155517.GI14521@mournblade.imrryr.org> <20130515182057.GO14521@mournblade.imrryr.org> <5193DCFE.9040708@openssl.org> To: Andy Polyakov X-Mailer: Apple Mail (2.1503) Cc: dane@ietf.org Subject: Re: [dane] DANE for OpenSSL X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 May 2013 15:25:50 -0000 On May 15, 2013, at 3:07 PM, Andy Polyakov wrote: >>> Note, this "initial support", does not yet perform any verification >>> based on TLSA records, it just adds a convenience TLSA RR lookup >>> function that is conditional on libunbound. The application will >>> need to call SSL_get_tlsa_record_byname() and then provide the = output >>> to the OpenSSL library via a control operation before the handshake. >=20 > I've replied to first message and it went to moderator for approval. Yes, yes you did -- We did get: ---- As list administrator, your authorization is requested for the following mailing list posting: List: dane@ietf.org From: appro@openssl.org Subject: Re: [dane] DANE for OpenSSL Reason: Post by non-member to a members-only list At your convenience, visit: https://www.ietf.org/mailman/admindb/dane to approve or deny the request. ----- I went to go approve the message and got:=20 ----- dane Administrative Database There are no pending requests. Click here to reload this page. ---- I assumed that a: my co-chair had clicked approve or b: you had clicked = the "Don't bother" link.=20 Seeing as this didn't hit the list (and seems to have disappeared into = the Ether / been eaten by the angry bit gods) can you please resubmit = it=85 Somehow we, or mailman, screwed up... W >=20 >> A few more comments: >> 0. The TLSA lookup function does not check the "bogus" = field, which is >> documented as possibly set together with "secure", indicating a = bogus >> DNS reply (unbound still returns the data it seems) and lets the = caller >> decide. So the new TLSA lookup function is not safe. >=20 > OK. >=20 >> 1. The introduction of a dependency on libunbound is I think a = mistake, >> applications should obtain TLSA RRs via whatever library they = see fit. >> It is sufficient for OpenSSL to specify a suitable encoding of = the >> TLSA RRs to be passed to the verification routine. >=20 > Goal is to have libssl check config file for [libunbound] section and = link to libunbound only if there is such section. In other words = run-time link to libunbound will be optional. >=20 >> 2. The packed encoding chosen is rather unnatural. A data = structure >> would have been better than a packed array of lenghts and data = buffers. >> struct SSL_TLSA_DATA { >> size_t rrcount; >> struct { >> size_t len; >> unsigned char *data; >> } rrdata[1]; >> } >=20 > Rationale behind the unnatural choice is to have possibility to = generate record from scripting languages without having to create glue = code. >=20 >> I don't think Andy Polykov reads this list. I'll forward him my >> comments under separate cover. >=20 > I've now subscribed to the list. >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 --=20 "Does Emacs have the Buddha nature? Why not? It has bloody well = everything else..." From viktor1dane@dukhovni.org Mon May 20 07:09:57 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C220D21F926E for ; Mon, 20 May 2013 07:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 0sKbvyKlSD9o for ; Mon, 20 May 2013 07:09:52 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 3E31821F8454 for ; Mon, 20 May 2013 07:09:52 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 404912AB9CA; Mon, 20 May 2013 14:09:51 +0000 (UTC) Date: Mon, 20 May 2013 14:09:51 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130520140950.GR582@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [dane] Discussion: New draft: DANE opportunistic TLS for SMTP X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 14:09:58 -0000 https://tools.ietf.org/id/draft-dukhovni-smtp-opportunistic-tls-00.html This proposed protocol supports opportunistic TLS with DANE authentication resistant to MITM downgrade attacks. Domains that publish DNSSEC signed MX records and corresponding TLSA records support security via the DANE PKI when the sender implements opportunistic DANE TLS. Feedback welcome. The goal is encourage interoperable implementations that incrementally increase the security of the Internet SMTP backbone as DNSSEC and DANE are adopted. This protocol does not promise unconditional secure delivery, the sender will send via unauthenticated TLS or even plain-text when a destination does not publish secure TLSA records for secure MX hosts. However, it can be used for unconditional security with sender-selected destinations by requiring a DANE authenticated connection when the recipient domain is known/expected to publish secure DANE TLSA RRs. -- Viktor. From viktor1dane@dukhovni.org Mon May 20 07:14:03 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EB4B21F95E0 for ; Mon, 20 May 2013 07:14:03 -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 bZHKJoqKhB7K for ; Mon, 20 May 2013 07:13:59 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE8721F9593 for ; Mon, 20 May 2013 07:13:59 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 8F2732AB9CA; Mon, 20 May 2013 14:13:58 +0000 (UTC) Date: Mon, 20 May 2013 14:13:58 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130520141358.GS582@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [dane] Discussion: New draft: DANE ops X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 14:14:03 -0000 https://tools.ietf.org/id/draft-dukhovni-dane-ops-00.html This draft covers the operational guidance from lessons learned while implementing DANE TLSA support for Postfix. This is not claimed to be comprehensive, and would likely benefit from additional contributions. -- Viktor. From paul.hoffman@vpnc.org Mon May 20 08:16:13 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D279921F9344 for ; Mon, 20 May 2013 08:16:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.624 X-Spam-Level: X-Spam-Status: No, score=-102.624 tagged_above=-999 required=5 tests=[AWL=-0.025, 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 znIyFoTG3cSv for ; Mon, 20 May 2013 08:16: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 4B34A21F92B7 for ; Mon, 20 May 2013 08:16:13 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r4KFGBn1030925 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 20 May 2013 08:16:12 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Paul Hoffman In-Reply-To: <20130520140950.GR582@mournblade.imrryr.org> Date: Mon, 20 May 2013 08:16:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1397CFB2-7197-4C28-93D5-C8602468787C@vpnc.org> References: <20130520140950.GR582@mournblade.imrryr.org> To: dane@ietf.org X-Mailer: Apple Mail (2.1503) Subject: Re: [dane] Discussion: New draft: DANE opportunistic TLS for SMTP X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 20 May 2013 15:16:13 -0000 On May 20, 2013, at 7:09 AM, Viktor Dukhovni = wrote: > This proposed protocol supports opportunistic TLS with DANE > authentication resistant to MITM downgrade attacks. This seems like really important work. Lots of people turn on STARTTLS = in SMTP with no actual certificate verification because the want better = than nothing security but don't want the operational overhead of = actually rejecting bad TLS. It seems like this proposal actually gets = them better protection with the same lack of overhead if they don't want = to reject. It also gives those who want to reject bad TLS a better basis = to do so. --Paul Hoffman= From paul.hoffman@vpnc.org Mon May 20 08:16:55 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 020C721F9362 for ; Mon, 20 May 2013 08:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.621 X-Spam-Level: X-Spam-Status: No, score=-102.621 tagged_above=-999 required=5 tests=[AWL=-0.022, 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 PillN3yHBVZp for ; Mon, 20 May 2013 08:16: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 4945621F934B for ; Mon, 20 May 2013 08:16:53 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r4KFGBn2030925 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 20 May 2013 08:16:53 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Paul Hoffman In-Reply-To: <20130520141358.GS582@mournblade.imrryr.org> Date: Mon, 20 May 2013 08:16:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0A36533D-D7E8-4379-B670-46F630D06EC1@vpnc.org> References: <20130520141358.GS582@mournblade.imrryr.org> To: dane@ietf.org X-Mailer: Apple Mail (2.1503) Subject: Re: [dane] Discussion: New draft: DANE ops X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 20 May 2013 15:16:55 -0000 > This draft covers the operational guidance from lessons learned > while implementing DANE TLSA support for Postfix. This is not > claimed to be comprehensive, and would likely benefit from > additional contributions. This seems like an excellent start on a document that could come from = this WG. --Paul Hoffman= From viktor1dane@dukhovni.org Mon May 20 09:01:40 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F37DF21F86F5 for ; Mon, 20 May 2013 09:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 SqKkPa2qnobL for ; Mon, 20 May 2013 09:01:35 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id E929021F93B9 for ; Mon, 20 May 2013 09:01:30 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 6786C2AAD96; Mon, 20 May 2013 16:01:30 +0000 (UTC) Date: Mon, 20 May 2013 16:01:30 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130520160130.GT582@mournblade.imrryr.org> References: <20130520140950.GR582@mournblade.imrryr.org> <1397CFB2-7197-4C28-93D5-C8602468787C@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1397CFB2-7197-4C28-93D5-C8602468787C@vpnc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Discussion: New draft: DANE opportunistic TLS for SMTP X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 16:01:40 -0000 On Mon, May 20, 2013 at 08:16:11AM -0700, Paul Hoffman wrote: > On May 20, 2013, at 7:09 AM, Viktor Dukhovni wrote: > > > This proposed protocol supports opportunistic TLS with DANE > > authentication resistant to MITM downgrade attacks. > > This seems like really important work. Lots of people turn on > STARTTLS in SMTP with no actual certificate verification because > the want better than nothing security but don't want the operational > overhead of actually rejecting bad TLS. It seems like this proposal > actually gets them better protection with the same lack of overhead > if they don't want to reject. It also gives those who want to reject > bad TLS a better basis to do so. I should note that my draft substantively overlaps draft-ietf-dane-smtp-01. Core differences: - The new draft includes a more expansive treatment of the semantics of the various TLSA RR types in the context of SMTP. - The new draft addresses SMTP submission with RFC 6409 SRV records. - The new draft specifies the target of a CNAME as the base name for TLSA lookups with MX hosts (and with non-MX domains). Since https://tools.ietf.org/html/draft-ietf-dane-smtp-01#section-3 also specifies opportunistic security, the core premise is common to the two drafts. Perhaps the two drafts can be merged. -- Viktor. From turners@ieca.com Tue May 21 13:05:46 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0E021F94DF for ; Tue, 21 May 2013 13:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.42 X-Spam-Level: X-Spam-Status: No, score=-102.42 tagged_above=-999 required=5 tests=[AWL=0.179, 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 EdTQlFEDUoUi for ; Tue, 21 May 2013 13:05:41 -0700 (PDT) Received: from gateway12.websitewelcome.com (gateway12.websitewelcome.com [70.85.6.5]) by ietfa.amsl.com (Postfix) with ESMTP id 2F20921F93F6 for ; Tue, 21 May 2013 13:05:41 -0700 (PDT) Received: by gateway12.websitewelcome.com (Postfix, from userid 5007) id 7249DF4A0395; Tue, 21 May 2013 15:05:40 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway12.websitewelcome.com (Postfix) with ESMTP id 5D9EDF4A0322 for ; Tue, 21 May 2013 15:05:40 -0500 (CDT) Received: from [173.73.135.101] (port=64924 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UesoW-0001Fy-5M for dane@ietf.org; Tue, 21 May 2013 15:05:40 -0500 Message-ID: <519BD393.7020302@ieca.com> Date: Tue, 21 May 2013 16:05:39 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: dane@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [173.73.135.101]:64924 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [dane] making ietf.org eat the DANE dogfood X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 21 May 2013 20:05:46 -0000 I've been informally asking around about what people might think about requesting that ietf.org add support for DANE. Support isn't there yet in the browsers but folks have to deploy it on the server side and I think it might as well be us. I know it's likely not going to be be as simple just asking, but I'd hear what the WG thinks about the idea. spt From stpeter@stpeter.im Tue May 21 13:08:34 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 244F911E80F7 for ; Tue, 21 May 2013 13:08:34 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KFa5Uysi+pFw for ; Tue, 21 May 2013 13:08:30 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 071A211E80DC for ; Tue, 21 May 2013 13:08:29 -0700 (PDT) Received: from ergon.local (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 823DA41148 for ; Tue, 21 May 2013 14:20:52 -0600 (MDT) Message-ID: <519BD433.6090609@stpeter.im> Date: Tue, 21 May 2013 14:08:19 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: dane@ietf.org References: <519BD393.7020302@ieca.com> In-Reply-To: <519BD393.7020302@ieca.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dane] making ietf.org eat the DANE dogfood X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 21 May 2013 20:08:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 5/21/13 2:05 PM, Sean Turner wrote: > I've been informally asking around about what people might think > about requesting that ietf.org add support for DANE. Support isn't > there yet in the browsers but folks have to deploy it on the server > side and I think it might as well be us. I know it's likely not > going to be be as simple just asking, but I'd hear what the WG > thinks about the idea. +1 to eating our own dogfood. In this case, what exactly does that mean? DANE support for the website(s) (HTTPS), mailing lists (SMTP), chatrooms (XMPP), other? Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRm9QzAAoJEOoGpJErxa2pz34QAJTar762fZ64ed8WzZ21NF1p F9XYCinXT6LPiborRFkPrXzcqNbGTlccmfr7VJyxlz2lfranzXfdjiEc9KRG4lGG dL9s5Q3cX2BAWRqiQOPRFpT6wpRjvDwL5OjRBbWkLILyi5tUJdsPl+iKGKI4LVZ/ 9Knx5JHKM11NR2Y6Db1zYGiuaiQxHTrCSfH0o6qAqVH58AWppY+7H7C4byGplfrS foDs2w8ec0DNndvFk7rSs6ixdaWFFZ6zBOHLjXX6ifd00WxJb7XhweZhzHvP+uYN 9DmB/cVW5JTw9yqPZy/2Lypx65SsxfP9XAyTdRR6otkQj5M1faPMBIm5iDXHH3kI c9yyE+Wvo6xxyM/Hee98WDWcJpHvkB4+LVfvKA8LL8GdJnICBf/ysv0rgK7L980A jcp2piWZrPrZq9yed9tl4czhA/HiGNGO42/jc/pF3QknksxOvt5nvhz1UCs6tDQv /kcrv7lCSN58Q5fe50DWK4HqWq8HSzNMoVRGFk8OFV7yc5mrKkupvjiNQ89fD7f5 EQHfcnPU5dzKxY1S01VsfskL/rz8g3h+Ujv0COasnR3MV9/eMb9t/c2JG1rsZkVZ ZezScCNuqWEeTqyJqu3NknnrplxY9Ry3o2cMOHEN2m95OoBq32hqoRvsrO14fzcJ duX8RGO0nu3y1VH9vnca =vs/M -----END PGP SIGNATURE----- From paul.hoffman@vpnc.org Tue May 21 13:35:55 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C11911E810F for ; Tue, 21 May 2013 13:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.612 X-Spam-Level: X-Spam-Status: No, score=-102.612 tagged_above=-999 required=5 tests=[AWL=-0.013, 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 Kj1XbzFtDKoH for ; Tue, 21 May 2013 13:35: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 625B711E8109 for ; Tue, 21 May 2013 13:35:54 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r4LKZrmu008893 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 21 May 2013 13:35:53 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Paul Hoffman In-Reply-To: <519BD433.6090609@stpeter.im> Date: Tue, 21 May 2013 13:35:55 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <519BD393.7020302@ieca.com> <519BD433.6090609@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1503) Cc: dane@ietf.org Subject: Re: [dane] making ietf.org eat the DANE dogfood X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 21 May 2013 20:35:55 -0000 On May 21, 2013, at 1:08 PM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 5/21/13 2:05 PM, Sean Turner wrote: >> I've been informally asking around about what people might think >> about requesting that ietf.org add support for DANE. Support isn't >> there yet in the browsers but folks have to deploy it on the server >> side and I think it might as well be us. I know it's likely not >> going to be be as simple just asking, but I'd hear what the WG >> thinks about the idea. > > +1 to eating our own dogfood. > > In this case, what exactly does that mean? DANE support for the > website(s) (HTTPS), mailing lists (SMTP), chatrooms (XMPP), other? Say, didn't we just see two new drafts answering that question? :-) --Paul Hoffman From stpeter@stpeter.im Tue May 21 13:38:13 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5AFB11E80FD for ; Tue, 21 May 2013 13:38:13 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oq1qs9eOoxc5 for ; Tue, 21 May 2013 13:38:09 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA5F11E8109 for ; Tue, 21 May 2013 13:38:09 -0700 (PDT) Received: from che-vpn-cluster-2-269.cisco.com (unknown [198.135.0.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1754641148; Tue, 21 May 2013 14:50:31 -0600 (MDT) Message-ID: <519BDB2E.90805@stpeter.im> Date: Tue, 21 May 2013 14:38:06 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Paul Hoffman References: <519BD393.7020302@ieca.com> <519BD433.6090609@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dane@ietf.org Subject: Re: [dane] making ietf.org eat the DANE dogfood X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 21 May 2013 20:38:14 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 5/21/13 2:35 PM, Paul Hoffman wrote: > On May 21, 2013, at 1:08 PM, Peter Saint-Andre > wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> On 5/21/13 2:05 PM, Sean Turner wrote: >>> I've been informally asking around about what people might >>> think about requesting that ietf.org add support for DANE. >>> Support isn't there yet in the browsers but folks have to >>> deploy it on the server side and I think it might as well be >>> us. I know it's likely not going to be be as simple just >>> asking, but I'd hear what the WG thinks about the idea. >> >> +1 to eating our own dogfood. >> >> In this case, what exactly does that mean? DANE support for the >> website(s) (HTTPS), mailing lists (SMTP), chatrooms (XMPP), >> other? > > Say, didn't we just see two new drafts answering that question? > :-) I didn't see that they proposed deployment scenarios for ietf.org... Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRm9suAAoJEOoGpJErxa2pJy0P/1TIVX6z22eKqqUc3exyX1Gb hn51CASyYaxJuGsj1h2kDtDXFuUBZxLY0Q0YwKhru1kx+/+QYvgNsVfz1YV9sPvQ wL1nFdyg84YWk4bQnQBHUN8Qvo972bMzimaZSD6Oh0rVix5wKqRNuNrl31wTzkMr R8IFX0w+JfmbHUqopNl/RGqBBg8F6Mk9Dq3aPedF72wrfWdaYuQXjl8ZMIC/7GOU pqjKY87Avxbusv/9S8equdGsqsPUz0MDvdB7zLp+pZF28kov5qwP7/+FM1xLeiB5 JG4I1pHWO2qmiiypwMIrm+o6TdUsA65xTBEgNmGs3qyg+wsSwZ43B4SbaOQTLGZv LpAYlViY8XJetBrFFvy+7pDhv1P72iny05jCU18yZKfjVd5yEIaBxpXnE3Tptwr2 yFxGms4SrcVAjFZi4SX3lwUS71LxxnaqXF8FFv+9ZqnsFkFMWrp12v3p8Q9Nu93Y oy47H7+MWGLuTGhWhzZTBVX5rtwvLMmVBiYYVk+3JEwA5WsW4cFRUimC8iggS7ps 7lpwLRHIcaIY1ML6+JcVwFDna7NBB5fpCOLgRF/5pMco1BtsyNQvxCPfjnhp4RpG RJ6yefJdRF55KJ0Gj3Hb0xKMP+qQhIDR+nVRb2+PORvmkgJhFOrQZdEzD6OjWal5 AsOY1hlx+hXVYLhihlDc =VsV6 -----END PGP SIGNATURE----- From paul.hoffman@vpnc.org Tue May 21 13:52:33 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE6A31F0D32 for ; Tue, 21 May 2013 13:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.612 X-Spam-Level: X-Spam-Status: No, score=-102.612 tagged_above=-999 required=5 tests=[AWL=-0.013, 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 dL5djrRfICzY for ; Tue, 21 May 2013 13:52: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 4ACD41F0D23 for ; Tue, 21 May 2013 13:52:32 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r4LKqVmf009361 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 21 May 2013 13:52:31 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Paul Hoffman In-Reply-To: <519BDB2E.90805@stpeter.im> Date: Tue, 21 May 2013 13:52:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2375B9D3-9A93-499F-A31C-8F6CB887FA05@vpnc.org> References: <519BD393.7020302@ieca.com> <519BD433.6090609@stpeter.im> <519BDB2E.90805@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1503) Cc: dane@ietf.org Subject: Re: [dane] making ietf.org eat the DANE dogfood X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 21 May 2013 20:52:33 -0000 On May 21, 2013, at 1:38 PM, Peter Saint-Andre = wrote: > I didn't see that they proposed deployment scenarios for ietf.org... They explain some of the operational issues that the IETF would want to = consider when making the decision to add TLSA records. --Paul Hoffman= From viktor1dane@dukhovni.org Tue May 21 15:52:37 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5883521F9318 for ; Tue, 21 May 2013 15:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.555 X-Spam-Level: X-Spam-Status: No, score=-1.555 tagged_above=-999 required=5 tests=[AWL=-0.969, BAYES_00=-2.599, FAKE_REPLY_C=2.012, WEIRD_PORT=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 f0jLG+zkcX3E for ; Tue, 21 May 2013 15:52:33 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 6559221F92C5 for ; Tue, 21 May 2013 15:52:33 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 6AD8E2AAD96; Tue, 21 May 2013 22:52:32 +0000 (UTC) Date: Tue, 21 May 2013 22:52:32 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130521225232.GB582@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <519BDB2E.90805@stpeter.im> <2375B9D3-9A93-499F-A31C-8F6CB887FA05@vpnc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] making ietf.org eat the DANE dogfood X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 22:52:37 -0000 On Tue, May 21, 2013 at 01:52:33PM -0700, Paul Hoffman wrote: > On May 21, 2013, at 1:38 PM, Peter Saint-Andre wrote: > > > I didn't see that they proposed deployment scenarios for ietf.org... > > They explain some of the operational issues that the IETF would > want to consider when making the decision to add TLSA records. Thanks for championing the drafts Paul, much appreciated. In terms of SMTP, given: ietf.org. 1800 IN MX 0 mail.ietf.org. and assuming this is a "secure" result (I am behind the wrong kind of firewalls to check just at the moment), all the IETF would have to do is publish: _25._tcp.mail.ietf.org. IN TLSA 3 1 1 after first enabling STARTTLS support on the MTA: posttls-finger: Connected to mail.ietf.org[2001:1890:123a::1:1e]:25 posttls-finger: < 220 ietfa.amsl.com ESMTP Postfix posttls-finger: > EHLO amnesiac.local posttls-finger: < 250-ietfa.amsl.com posttls-finger: < 250-PIPELINING posttls-finger: < 250-SIZE 67108864 posttls-finger: < 250-ETRN posttls-finger: < 250-AUTH LOGIN PLAIN posttls-finger: < 250-AUTH=LOGIN PLAIN posttls-finger: < 250-ENHANCEDSTATUSCODES posttls-finger: < 250-8BITMIME posttls-finger: < 250 DSN posttls-finger: > QUIT posttls-finger: < 221 2.0.0 Bye For some reason this MX host supports SASL (more suitable for an MSA, where one would also want TLS for PLAIN or LOGIN), but not TLS which is appropriate for an inbound MX. main.cf: smtpd_tls_cert_file = ${config_directory}/smtpd.pem smtpd_tls_security_level = may # Optional, but recommended: cache TLS sessions: scache = btree:${data_directory}/ smtpd_tls_session_cache_database = ${scache}smtpd_scache The cert can be self-signed. Just a couple of minutes of admin time and "postfix reload". makecert.sh: #! /bin/sh umask 077 tmp=$(mktemp .smtpd.pem.XXXXXX) dst=smtpd.pem openssl req -new >> $tmp \ -newkey rsa:2048 -nodes -keyout /dev/stdout \ -x509 -sha1 -set_serial 1 -subj "/" -days 3650 \ -config <(printf "[req]\n%s\n[dn]\n[exts]\n%s\n[alts]\n%s\n" \ "$(printf "%s\n%s\n" \ "distinguished_name=dn" \ "x509_extensions=exts")" \ "$(printf "%s\n%s\n" \ "extendedKeyUsage=serverAuth,clientAuth" \ "subjectAltName=@alts" \ )" \ "$(printf "DNS.1 = %s\n" $(uname -n))") && mv $tmp "$dst" To generate the digest for the DNS TLSA record: openssl pkey -in "$dst" -pubout | openssl pkey -pubin -outform DER | openssl dgst -sha256 -- Viktor. From viktor1dane@dukhovni.org Tue May 21 16:06:39 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0465B21F9397 for ; Tue, 21 May 2013 16:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, 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 NMBi5v0yAWFp for ; Tue, 21 May 2013 16:06:35 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 25E3B21F9399 for ; Tue, 21 May 2013 16:06:34 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id BD8822AAD96; Tue, 21 May 2013 23:06:33 +0000 (UTC) Date: Tue, 21 May 2013 23:06:33 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130521230633.GC582@mournblade.imrryr.org> References: <519BDB2E.90805@stpeter.im> <2375B9D3-9A93-499F-A31C-8F6CB887FA05@vpnc.org> <20130521225232.GB582@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130521225232.GB582@mournblade.imrryr.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] making ietf.org eat the DANE dogfood X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 23:06:39 -0000 On Tue, May 21, 2013 at 10:52:32PM +0000, Viktor Dukhovni wrote: > makecert.sh: > #! /bin/sh > umask 077 > tmp=$(mktemp .smtpd.pem.XXXXXX) > dst=smtpd.pem > openssl req -new >> $tmp \ > -newkey rsa:2048 -nodes -keyout /dev/stdout \ > -x509 -sha1 -set_serial 1 -subj "/" -days 3650 \ > -config <(printf "[req]\n%s\n[dn]\n[exts]\n%s\n[alts]\n%s\n" \ > "$(printf "%s\n%s\n" \ > "distinguished_name=dn" \ > "x509_extensions=exts")" \ > "$(printf "%s\n%s\n" \ > "extendedKeyUsage=serverAuth,clientAuth" \ > "subjectAltName=@alts" \ > )" \ > "$(printf "DNS.1 = %s\n" $(uname -n))") && > mv $tmp "$dst" For the record, the script uses bash <(command) syntax, so it should be a /bin/bash not a /bin/sh script when the two are not the same. -- Viktor. From listsebby@me.com Tue May 21 21:59:59 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E395921F913E for ; Tue, 21 May 2013 21:59:59 -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 g38RvWEOVP4e for ; Tue, 21 May 2013 21:59:55 -0700 (PDT) Received: from nk11p04mm-asmtp002.mac.com (nk11p04mm-asmtpout002.mac.com [17.158.236.237]) by ietfa.amsl.com (Postfix) with ESMTP id 0987221F85B4 for ; Tue, 21 May 2013 21:59:54 -0700 (PDT) Received: from [192.168.1.5] (natbox.sabahattin-gucukoglu.com [213.123.192.30]) by nk11p04mm-asmtp002.mac.com (Oracle Communications Messaging Server 7u4-26.01(7.0.4.26.0) 64bit (built Jul 13 2012)) with ESMTPSA id <0MN600KXFOJPVK30@nk11p04mm-asmtp002.mac.com> for dane@ietf.org; Wed, 22 May 2013 04:59:52 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626,1.0.431,0.0.0000 definitions=2013-05-21_05:2013-05-21, 2013-05-21, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1305010000 definitions=main-1305210353 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Sabahattin Gucukoglu In-reply-to: <519BD393.7020302@ieca.com> Date: Wed, 22 May 2013 05:59:54 +0100 Content-transfer-encoding: quoted-printable Message-id: <99143AF0-D6F9-4454-8DBC-69E22965E7F4@me.com> References: <519BD393.7020302@ieca.com> To: Sean Turner X-Mailer: Apple Mail (2.1503) Cc: dane@ietf.org Subject: Re: [dane] making ietf.org eat the DANE dogfood X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2013 05:00:00 -0000 On 21 May 2013, at 21:05, Sean Turner wrote: > I've been informally asking around about what people might think about = requesting that ietf.org add support for DANE. Support isn't there yet = in the browsers but folks have to deploy it on the server side and I = think it might as well be us. I know it's likely not going to be be as = simple just asking, but I'd hear what the WG thinks about the idea. A fantastic idea, but while 99.99% of all browsers don't yet support = DANE, I think it would be imprudent to drop the CA-signed requirement at = the moment. This isn't a problem; just use the hashes for CA-signed = certs in the TLSA records. Cheers, Sabahattin From mikem@airspayce.com Tue May 21 23:16:58 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F76B21F939E for ; Tue, 21 May 2013 23:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 fK9HPxC-V62e for ; Tue, 21 May 2013 23:16:53 -0700 (PDT) Received: from gateway14.websitewelcome.com (gateway14.websitewelcome.com [69.56.150.9]) by ietfa.amsl.com (Postfix) with ESMTP id 1F47621F936E for ; Tue, 21 May 2013 23:16:52 -0700 (PDT) Received: by gateway14.websitewelcome.com (Postfix, from userid 5007) id 12B7B1D8DE323; Wed, 22 May 2013 01:16:48 -0500 (CDT) Received: from gator1422.hostgator.com (gator1422.hostgator.com [184.172.141.222]) by gateway14.websitewelcome.com (Postfix) with ESMTP id EE0351D8DE2BD for ; Wed, 22 May 2013 01:16:47 -0500 (CDT) Received: from [58.96.35.135] (port=38932 helo=zulu.localnet) by gator1422.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1Uf2M0-0007On-2J for dane@ietf.org; Wed, 22 May 2013 01:16:52 -0500 From: Mike McCauley To: dane@ietf.org Date: Wed, 22 May 2013 16:16:49 +1000 Message-ID: <10226251.e1kDrvCT86@zulu> Organization: AirSpayce Pty Ltd User-Agent: KMail/4.8.5 (Linux/3.4.33-2.24-desktop; KDE/4.8.5; i686; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1422.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - airspayce.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (zulu.localnet) [58.96.35.135]:38932 X-Source-Auth: mikem@airspayce.com X-Email-Count: 1 X-Source-Cap: bWlrZW07bWlrZW07Z2F0b3IxNDIyLmhvc3RnYXRvci5jb20= Subject: [dane] OpenSSL DANE support added to Net::SSLeay X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2013 07:50:22 -0000 Hi All, I have now added support for SSL_get_tlsa_record_byname() to Net::SSLeay. It is available in SVN. Cheers. -- Mike McCauley mikem@airspayce.com Airspayce Pty Ltd 9 Bulbul Place Currumbin Waters QLD 4223 Australia http://www.airspayce.com Phone +61 7 5598-7474 Fax +61 7 5598-7070 From christian.becker@tu-harburg.de Wed May 22 02:17:02 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F04821F960E for ; Wed, 22 May 2013 02:17:02 -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_DE=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 o6NFoOO8cTTd for ; Wed, 22 May 2013 02:16:56 -0700 (PDT) Received: from smtp3.rz.tu-harburg.de (smtp3.rz.tu-harburg.de [134.28.202.138]) by ietfa.amsl.com (Postfix) with ESMTP id D653A21F9285 for ; Wed, 22 May 2013 02:16:52 -0700 (PDT) Received: from mail.tu-harburg.de (mail.tu-harburg.de [134.28.202.179]) by smtp3.rz.tu-harburg.de (8.13.8/8.13.8) with ESMTP id r4M9Gpro032177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 22 May 2013 11:16:51 +0200 Received: from [0.0.0.0] (manning1.torservers.net [96.44.189.100]) (user=secb0840 mech=PLAIN bits=0) by mail.tu-harburg.de (8.13.8/8.13.8) with ESMTP id r4M9GlPQ017702 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 22 May 2013 11:16:49 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tu-harburg.de; s=x2013-21; t=1369214210; bh=4OvI4J0Jttus93APyDM8GutTcpecCPSlyJQaWQaG5+8=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=m9FoiUTkGlUE6qityt71BvUXJ9+7Ie2B+7Qx2Hji/Hu0EI74bKC8a9sK0KebojOex pIPGXcOG3ub6Z1eTMzb+g1iORNz8l/IIKlufwAY8okG2Q5RqsO78anW8BWLbhFpg5X tLaEW3fom0FTyuYyxmY5Ts78yczqb14F6wuje85E= Message-ID: <519C8C46.1090200@tu-harburg.de> Date: Wed, 22 May 2013 11:13:42 +0200 From: Christian Becker User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20121215 Icedove/3.0.11 MIME-Version: 1.0 To: dane@ietf.org X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Scanned-By: TUHH Rechenzentrum content checker on 134.28.202.138 X-Scanned-By: TUHH Rechenzentrum content checker on 134.28.202.179 Subject: [dane] Certificate Usage 2 with revoked trust anchor certificate X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2013 09:17:02 -0000 Hi, what is the intended outcome validating a record TLSA 2 x x, where the specified trust anchor certificate was already revoked by a CA? Does PKIX certification path validation include revocation checks? RFC 6698 says "The target certificate MUST pass PKIX certification path validation, with any certificate matching the TLSA record considered to be a trust anchor for this certification path validation." Thanks, Christian From stephen.farrell@cs.tcd.ie Wed May 22 03:57:46 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F144621F961C for ; Wed, 22 May 2013 03:57:45 -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 g7mETbkBCiSD for ; Wed, 22 May 2013 03:57:41 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 9F15F21F9600 for ; Wed, 22 May 2013 03:57:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 94444BE88; Wed, 22 May 2013 11:57:15 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W9rcBcwQSD-l; Wed, 22 May 2013 11:57:15 +0100 (IST) Received: from [IPv6:2001:770:10:203:2d35:f3c0:f38c:289f] (unknown [IPv6:2001:770:10:203:2d35:f3c0:f38c:289f]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 741CBBE77; Wed, 22 May 2013 11:57:15 +0100 (IST) Message-ID: <519CA48B.4060903@cs.tcd.ie> Date: Wed, 22 May 2013 11:57:15 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Peter Saint-Andre References: <519BD393.7020302@ieca.com> <519BD433.6090609@stpeter.im> In-Reply-To: <519BD433.6090609@stpeter.im> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dane@ietf.org Subject: Re: [dane] making ietf.org eat the DANE dogfood X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2013 10:57:46 -0000 On 05/21/2013 09:08 PM, Peter Saint-Andre wrote: > On 5/21/13 2:05 PM, Sean Turner wrote: >> I've been informally asking around about what people might think >> about requesting that ietf.org add support for DANE. Support isn't >> there yet in the browsers but folks have to deploy it on the server >> side and I think it might as well be us. I know it's likely not >> going to be be as simple just asking, but I'd hear what the WG >> thinks about the idea. > > +1 to eating our own dogfood. > > In this case, what exactly does that mean? DANE support for the > website(s) (HTTPS), mailing lists (SMTP), chatrooms (XMPP), other? Taking a guess, the initial thing will probably be to get the tools/AMS folks familiar with whatever tools are out there, then probably publish TLSA records for the web sites (while keeping the CA certs of course) and after that we'll see. I wouldn't be surprised if the SMTP/TLS with DANE thing was the first one to offer benefits, but its maybe still a little early for that just yet. Cheers, S. > > Peter > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > From turners@ieca.com Wed May 22 05:08:16 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A13921F9289 for ; Wed, 22 May 2013 05:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.263 X-Spam-Level: X-Spam-Status: No, score=-102.263 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 hk9gTYDL4+tR for ; Wed, 22 May 2013 05:08:08 -0700 (PDT) Received: from gateway12.websitewelcome.com (gateway12.websitewelcome.com [67.18.21.19]) by ietfa.amsl.com (Postfix) with ESMTP id A5CAB21F9057 for ; Wed, 22 May 2013 05:08:08 -0700 (PDT) Received: by gateway12.websitewelcome.com (Postfix, from userid 5007) id 5261910F14BFA; Wed, 22 May 2013 07:08:08 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway12.websitewelcome.com (Postfix) with ESMTP id 437EB10F14BC7 for ; Wed, 22 May 2013 07:08:08 -0500 (CDT) Received: from [173.73.135.101] (port=52548 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1Uf7pv-0004Tx-UR; Wed, 22 May 2013 07:08:08 -0500 Message-ID: <519CB527.4040108@ieca.com> Date: Wed, 22 May 2013 08:08:07 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Peter Saint-Andre References: <519BD393.7020302@ieca.com> <519BD433.6090609@stpeter.im> <519CA48B.4060903@cs.tcd.ie> In-Reply-To: <519CA48B.4060903@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [173.73.135.101]:52548 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 3 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: dane@ietf.org Subject: Re: [dane] making ietf.org eat the DANE dogfood X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2013 12:08:17 -0000 On 5/22/13 6:57 AM, Stephen Farrell wrote: > > > On 05/21/2013 09:08 PM, Peter Saint-Andre wrote: >> On 5/21/13 2:05 PM, Sean Turner wrote: >>> I've been informally asking around about what people might think >>> about requesting that ietf.org add support for DANE. Support isn't >>> there yet in the browsers but folks have to deploy it on the server >>> side and I think it might as well be us. I know it's likely not >>> going to be be as simple just asking, but I'd hear what the WG >>> thinks about the idea. >> >> +1 to eating our own dogfood. >> >> In this case, what exactly does that mean? DANE support for the >> website(s) (HTTPS), mailing lists (SMTP), chatrooms (XMPP), other? > > Taking a guess, the initial thing will probably be to get the > tools/AMS folks familiar with whatever tools are out there, > then probably publish TLSA records for the web sites (while > keeping the CA certs of course) and after that we'll see. I > wouldn't be surprised if the SMTP/TLS with DANE thing was the > first one to offer benefits, but its maybe still a little > early for that just yet. Yeah I was thinking website then smtp and then whatever comes next. spt >> >> Peter >> >> _______________________________________________ >> 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 viktor1dane@dukhovni.org Wed May 22 05:41:37 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA4121F96B3 for ; Wed, 22 May 2013 05:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.131, 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 YW4vaGHeEx0g for ; Wed, 22 May 2013 05:41:33 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 7099221F96B6 for ; Wed, 22 May 2013 05:41:17 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 998B62AB9C6; Wed, 22 May 2013 12:41:16 +0000 (UTC) Date: Wed, 22 May 2013 12:41:16 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130522124116.GD582@mournblade.imrryr.org> References: <519BD393.7020302@ieca.com> <519BD433.6090609@stpeter.im> <519CA48B.4060903@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <519CA48B.4060903@cs.tcd.ie> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] making ietf.org eat the DANE dogfood X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 12:41:37 -0000 On Wed, May 22, 2013 at 11:57:15AM +0100, Stephen Farrell wrote: > I wouldn't be surprised if the SMTP/TLS with DANE thing was the > first one to offer benefits, but its maybe still a little > early for that just yet. It is early to expect "benefits", since very few clients are deployed as yet, but not at all early to deploy, the TLSA record does no harm. There is no downside, no existing SMTP clients refuse to deliver to sites with unauthenticated certificates. A Postfix production snapshot (Wietse code review complete) will likely be available in June, at which point more people will be in a position to deploy DANE TLSA capable SMTP clients. They'll also need a DNSSEC enabled local (127.0.0.1) caching DNS resolver. So this is a good time to deploy server TLSA records: ; SHA256 digest of public key or full certificate. mail.example.com. IN TLSA 3 1 1 ... mail.example.com. IN TLSA 3 0 1 ... ; Or SHA256 of issuing trust-anchor CA public key. With the trust-anchor ; issuer certificate included in the server chain file! ; mail.example.com. IN TLSA 2 1 1 ... mail.example.com. IN TLSA 2 0 1 ... -- Viktor. From viktor1dane@dukhovni.org Wed May 22 05:49:44 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 498AC21F8693 for ; Wed, 22 May 2013 05:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.119, 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 iRTFqrA382mP for ; Wed, 22 May 2013 05:49:40 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 3110F21F856D for ; Wed, 22 May 2013 05:49:40 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D473B2AB9C6; Wed, 22 May 2013 12:49:39 +0000 (UTC) Date: Wed, 22 May 2013 12:49:39 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130522124939.GE582@mournblade.imrryr.org> References: <519BD393.7020302@ieca.com> <519BD433.6090609@stpeter.im> <519CA48B.4060903@cs.tcd.ie> <519CB527.4040108@ieca.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <519CB527.4040108@ieca.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] making ietf.org eat the DANE dogfood X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 12:49:44 -0000 On Wed, May 22, 2013 at 08:08:07AM -0400, Sean Turner wrote: > Yeah I was thinking website then smtp and then whatever comes next. Based on deployment risk, perceived security benefit or gut feel? For SMTP there is little to no risk, and few barriers to client deployment (the Exim folks are also implementing, more to follow I'm sure). Also far more likely to be universally usable than with browsers, where the existing PKI will still dominate for a long time. At the office I am behind an SSL MITM proxy appliance. It will be some time before the proxy does DANE, and the browser will not be able to help, the proxy's fake certificates will never match DANE records... -- Viktor. From viktor1dane@dukhovni.org Wed May 22 06:06:38 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFE8021F95F9 for ; Wed, 22 May 2013 06:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 9cfDreKtbzFU for ; Wed, 22 May 2013 06:06:33 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id B7AC921F9590 for ; Wed, 22 May 2013 06:06:33 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 1E4BD2AAD96; Wed, 22 May 2013 13:06:26 +0000 (UTC) Date: Wed, 22 May 2013 13:06:26 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130522130626.GG582@mournblade.imrryr.org> References: <519C8C46.1090200@tu-harburg.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <519C8C46.1090200@tu-harburg.de> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Certificate Usage 2 with revoked trust anchor certificate X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 13:06:39 -0000 On Wed, May 22, 2013 at 11:13:42AM +0200, Christian Becker wrote: > what is the intended outcome validating a record TLSA 2 x x, where the > specified trust anchor certificate was already revoked by a CA? Does > PKIX certification path validation include revocation checks? With certificate usages "2" and "3" there is no PKIX validation above the trust-anchor or EE certificate respectively. The party publishing the TLSA RR is responsible for updating the TLSA record when the certificate in question is no longer trustworthy. This is properly a responsibility of the domain owner, I should add a note about this to the next revision of the ops draft... Any other feedback for the draft? > RFC 6698 says "The target certificate MUST pass PKIX certification path > validation, with any certificate matching the TLSA record considered to > be a trust anchor for this certification path validation." Trust anchors can't be revoked, the verifier has to remove to them from their trust store. With DANE the picture is better, the domain owner can do this once for all verifiers by publishing a new TLSA RRset that uses a non-compromised TA. -- Viktor. From viktor1dane@dukhovni.org Wed May 22 06:20:47 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C16C21F8E96 for ; Wed, 22 May 2013 06:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, 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 4OFhv2AquBQA for ; Wed, 22 May 2013 06:20:42 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 840F721F93D2 for ; Wed, 22 May 2013 06:20:38 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 667862AAA84; Wed, 22 May 2013 13:20:37 +0000 (UTC) Date: Wed, 22 May 2013 13:20:37 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130522132037.GB25080@mournblade.imrryr.org> References: <10226251.e1kDrvCT86@zulu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <10226251.e1kDrvCT86@zulu> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] OpenSSL DANE support added to Net::SSLeay X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 13:20:47 -0000 On Wed, May 22, 2013 at 04:16:49PM +1000, Mike McCauley wrote: > I have now added support for SSL_get_tlsa_record_byname() to > Net::SSLeay. It is available in SVN. The DANE support in OpenSSL has not stabilized yet, it may be premature to add features to other products that depend on it. For example, I think it that the OpenSSL library should NOT be dynamically loading libunbound for DNSSEC TLSA lookups. Rather, it should be using the platform resolver with the "DO" bit set to get validated responses ("DO" bit set) from the local cache. Only applications that want to do their own validation should use libunbound or similar, and should do so by using their own choice DNSSEC client library. The control interface for passing this data back to OpenSSL may also change, at least in so far as I believe it should return errors when all TLSA RRs are malformed or unusable, ... I think you should wait until there is an OpenSSL release with documented interfaces for DANE before adding support for said interfaces. -- Viktor. From christian.becker@tu-harburg.de Wed May 22 06:34:42 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7490621F85C3 for ; Wed, 22 May 2013 06:34:42 -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_DE=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 bQc3xO53lwTJ for ; Wed, 22 May 2013 06:34:37 -0700 (PDT) Received: from smtp3.rz.tu-harburg.de (smtp3.rz.tu-harburg.de [134.28.202.138]) by ietfa.amsl.com (Postfix) with ESMTP id C0F6021F84D8 for ; Wed, 22 May 2013 06:34:32 -0700 (PDT) Received: from mail.tu-harburg.de (mail.tu-harburg.de [134.28.202.179]) by smtp3.rz.tu-harburg.de (8.13.8/8.13.8) with ESMTP id r4MDYV42008695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 22 May 2013 15:34:31 +0200 Received: from [0.0.0.0] (tor4.anonymizer.ccc.de [80.237.226.74]) (user=secb0840 mech=PLAIN bits=0) by mail.tu-harburg.de (8.13.8/8.13.8) with ESMTP id r4MDYQro013714 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 22 May 2013 15:34:30 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tu-harburg.de; s=x2013-21; t=1369229671; bh=7byZuM8vAzEQbi7wrqqWzwKtXJAuGpoCpLigTSAapxo=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=VORibLhBB/LQxhWa1O9Cp6RPqt9ncZ4w/DVYBU48C0csiAJ/gL+84gr4cUDxtXwtn iAmhGe7guvMrD2hBiXdADGgTZcMZqG2EmNqNjLNjHP7f2iKZpXt98ckxXZrnsc8Z6k 2SRVyOWtV6OnfqfwRszH8t9WtJa62y/6PCkngUoo= Message-ID: <519CC8A9.1020609@tu-harburg.de> Date: Wed, 22 May 2013 15:31:21 +0200 From: Christian Becker User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20121215 Icedove/3.0.11 MIME-Version: 1.0 To: dane@ietf.org References: <519C8C46.1090200@tu-harburg.de> <20130522130626.GG582@mournblade.imrryr.org> In-Reply-To: <20130522130626.GG582@mournblade.imrryr.org> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: TUHH Rechenzentrum content checker on 134.28.202.138 X-Scanned-By: TUHH Rechenzentrum content checker on 134.28.202.179 Subject: Re: [dane] Certificate Usage 2 with revoked trust anchor certificate X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: christian.becker@tu-harburg.de List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 13:34:42 -0000 Viktor Dukhovni: > On Wed, May 22, 2013 at 11:13:42AM +0200, Christian Becker wrote: > >> what is the intended outcome validating a record TLSA 2 x x, where the >> specified trust anchor certificate was already revoked by a CA? Does >> PKIX certification path validation include revocation checks? > > With certificate usages "2" and "3" there is no PKIX validation > above the trust-anchor or EE certificate respectively. The party > publishing the TLSA RR is responsible for updating the TLSA record > when the certificate in question is no longer trustworthy. This > is properly a responsibility of the domain owner, I should add a note > about this to the next revision of the ops draft... Thanks for your answer. I only supposed that there is or should be an answer on the protocol level as well to this situation where there might be conflicting information from PKIX validation and DANE. Christian From wes@hardakers.net Wed May 22 07:29:10 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB78521F9418 for ; Wed, 22 May 2013 07:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-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 31Xap6n3qlaP for ; Wed, 22 May 2013 07:29:10 -0700 (PDT) Received: from mail.hardakers.net (unknown [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6C221F9416 for ; Wed, 22 May 2013 07:29:09 -0700 (PDT) Received: from localhost (unknown [IPv6:2001:470:1f00:187:e0e3:558d:9d62:634f]) by mail.hardakers.net (Postfix) with ESMTPSA id 3A2292AFAE; Wed, 22 May 2013 07:29:08 -0700 (PDT) From: Wes Hardaker To: Sean Turner References: <519BD393.7020302@ieca.com> Date: Wed, 22 May 2013 07:29:07 -0700 In-Reply-To: <519BD393.7020302@ieca.com> (Sean Turner's message of "Tue, 21 May 2013 16:05:39 -0400") Message-ID: <0l8v37cclo.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: dane@ietf.org Subject: Re: [dane] making ietf.org eat the DANE dogfood X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2013 14:29:11 -0000 Sean Turner writes: > I've been informally asking around about what people might think about > requesting that ietf.org add support for DANE. Support isn't there > yet in the browsers but folks have to deploy it on the server side and > I think it might as well be us. I know it's likely not going to be be > as simple just asking, but I'd hear what the WG thinks about the idea. Definitely a good thing to at least add the TLSA record. I'm not sure why anyone would object to that (unless they hate the concept of DANE entirely so much that they'll fight anything about it, and I know there are a few random people like that). (and I know people using the DNSSEC-Tools' bloodhound browser would be happy) -- Wes Hardaker My Pictures: http://capturedonearth.com/ My Thoughts: http://pontifications.hardakers.net/ From viktor1dane@dukhovni.org Wed May 22 08:50:31 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24CEE21F8EEC for ; Wed, 22 May 2013 08:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 AwFo6SeTIwZk for ; Wed, 22 May 2013 08:50:26 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id D24B721F9360 for ; Wed, 22 May 2013 08:50:25 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3E58F2AAD96; Wed, 22 May 2013 15:50:25 +0000 (UTC) Date: Wed, 22 May 2013 15:50:25 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130522155025.GD25080@mournblade.imrryr.org> References: <519C8C46.1090200@tu-harburg.de> <20130522130626.GG582@mournblade.imrryr.org> <519CC8A9.1020609@tu-harburg.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <519CC8A9.1020609@tu-harburg.de> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Certificate Usage 2 with revoked trust anchor certificate X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 15:50:31 -0000 On Wed, May 22, 2013 at 03:31:21PM +0200, Christian Becker wrote: > Viktor Dukhovni: > > On Wed, May 22, 2013 at 11:13:42AM +0200, Christian Becker wrote: > > > >> what is the intended outcome validating a record TLSA 2 x x, where the > >> specified trust anchor certificate was already revoked by a CA? Does > >> PKIX certification path validation include revocation checks? > > > > With certificate usages "2" and "3" there is no PKIX validation > > above the trust-anchor or EE certificate respectively. The party > > publishing the TLSA RR is responsible for updating the TLSA record > > when the certificate in question is no longer trustworthy. This > > is properly a responsibility of the domain owner, I should add a note > > about this to the next revision of the ops draft... > > Thanks for your answer. I only supposed that there is or should be an > answer on the protocol level as well to this situation where there might > be conflicting information from PKIX validation and DANE. The whole point of "2" and "3" is that the existing public CA PKI (I think that's what you mean by PKIX) is out of scope, neither trusted nor consulted. Thus a DANE trust anchor with usage 2/3 is never revoked, it is simply replaced by the domain owner publishing updated TLSA records. >From where I sit, this is much better than revocation lists, OCSP, ... Eventually the TA is domain issued (not just a transitional reference to a public CA) and so updating the DNS is a simple local matter, more convenient than pushing revocations to a CA. The operational requirement is to avoid excessively long signature validity, which means resigning the DNS zone at least daily for sites with high value keys. For my personal domain, weekly resigning will likely do just fine. -- Viktor. From paul@cypherpunks.ca Wed May 22 21:21:12 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3419B11E8134 for ; Wed, 22 May 2013 21:21: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1J7Oy65DiCF2 for ; Wed, 22 May 2013 21:21:07 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 60F6511E813B for ; Wed, 22 May 2013 21:21:06 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3bGHZl2PjTz78p for ; Thu, 23 May 2013 00:21:03 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 2JA4yeJEw70P for ; Thu, 23 May 2013 00:21:02 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP for ; Thu, 23 May 2013 00:21:02 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id EEB6A82C46; Thu, 23 May 2013 00:21:02 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id E188982C45 for ; Thu, 23 May 2013 00:21:02 -0400 (EDT) Date: Thu, 23 May 2013 00:21:02 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: dane WG list In-Reply-To: <20130522124116.GD582@mournblade.imrryr.org> Message-ID: References: <519BD393.7020302@ieca.com> <519BD433.6090609@stpeter.im> <519CA48B.4060903@cs.tcd.ie> <20130522124116.GD582@mournblade.imrryr.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: Re: [dane] making ietf.org eat the DANE dogfood X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 04:21:12 -0000 On Wed, 22 May 2013, Viktor Dukhovni wrote: > So this is a good time to deploy server TLSA records: > > ; SHA256 digest of public key or full certificate. > mail.example.com. IN TLSA 3 1 1 ... > mail.example.com. IN TLSA 3 0 1 ... > > ; Or SHA256 of issuing trust-anchor CA public key. With the trust-anchor > ; issuer certificate included in the server chain file! > ; > mail.example.com. IN TLSA 2 1 1 ... > mail.example.com. IN TLSA 2 0 1 ... Would these be better located at _25._tcp.mail.example.com ? :) Paul From viktor1dane@dukhovni.org Wed May 22 21:30:22 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 185A411E8145 for ; Wed, 22 May 2013 21:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, 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 vHklGjIDS5Nc for ; Wed, 22 May 2013 21:30:13 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id D706B11E813B for ; Wed, 22 May 2013 21:30:12 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id EFA852AB9D5; Thu, 23 May 2013 04:30:11 +0000 (UTC) Date: Thu, 23 May 2013 04:30:11 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130523043011.GJ25080@mournblade.imrryr.org> References: <519BD393.7020302@ieca.com> <519BD433.6090609@stpeter.im> <519CA48B.4060903@cs.tcd.ie> <20130522124116.GD582@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] making ietf.org eat the DANE dogfood X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 04:30:23 -0000 On Thu, May 23, 2013 at 12:21:02AM -0400, Paul Wouters wrote: > On Wed, 22 May 2013, Viktor Dukhovni wrote: > > >So this is a good time to deploy server TLSA records: > > > > ; SHA256 digest of public key or full certificate. > > mail.example.com. IN TLSA 3 1 1 ... > > mail.example.com. IN TLSA 3 0 1 ... > > > > ; Or SHA256 of issuing trust-anchor CA public key. With the trust-anchor > > ; issuer certificate included in the server chain file! > > ; > > mail.example.com. IN TLSA 2 1 1 ... > > mail.example.com. IN TLSA 2 0 1 ... > > Would these be better located at _25._tcp.mail.example.com ? :) Responding as a matter of courtesy rather than necessity. Yes, of course! Anyway, if anyone knows the sysadmins who operate mail.ietf.org, please nudge them to enable STARTTLS and publish TLSA RRs. The DNSSEC signature is already in place: $ drill -D -t mx ietf.org ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 64505 ;; flags: qr rd ra ad ; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 8 ;; QUESTION SECTION: ;; ietf.org. IN MX ;; ANSWER SECTION: ietf.org. 1800 IN MX 0 mail.ietf.org. ietf.org. 1800 IN RRSIG MX ...copious line noise... https://xkcd.com/1181/ -- Viktor. From viktor1dane@dukhovni.org Thu May 23 08:26:12 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9BBA21F8ACD for ; Thu, 23 May 2013 08:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, WEIRD_PORT=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 2qt7dKMclGgu for ; Thu, 23 May 2013 08:26:09 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id C534621F8A09 for ; Thu, 23 May 2013 08:26:08 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id C567E2AAA84; Thu, 23 May 2013 15:26:07 +0000 (UTC) Date: Thu, 23 May 2013 15:26:07 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130523152607.GL25080@mournblade.imrryr.org> References: <519BDB2E.90805@stpeter.im> <2375B9D3-9A93-499F-A31C-8F6CB887FA05@vpnc.org> <20130521225232.GB582@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130521225232.GB582@mournblade.imrryr.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] making ietf.org eat the DANE dogfood X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 15:26:12 -0000 On Tue, May 21, 2013 at 10:52:32PM +0000, Viktor Dukhovni wrote: > posttls-finger: Connected to mail.ietf.org[2001:1890:123a::1:1e]:25 > posttls-finger: < 220 ietfa.amsl.com ESMTP Postfix > posttls-finger: > EHLO amnesiac.local > posttls-finger: < 250-ietfa.amsl.com > posttls-finger: < 250-PIPELINING > posttls-finger: < 250-SIZE 67108864 > posttls-finger: < 250-ETRN > posttls-finger: < 250-AUTH LOGIN PLAIN > posttls-finger: < 250-AUTH=LOGIN PLAIN > posttls-finger: < 250-ENHANCEDSTATUSCODES > posttls-finger: < 250-8BITMIME > posttls-finger: < 250 DSN > posttls-finger: > QUIT > posttls-finger: < 221 2.0.0 Bye > > For some reason this MX host supports SASL (more suitable for an > MSA, where one would also want TLS for PLAIN or LOGIN), but not > TLS which is appropriate for an inbound MX. FWIW, AMS (aka amsl.com) are no strangers to SMTP + STARTTLS: $ posttls-finger amsl.com posttls-finger: Connected to mail.amsl.com[64.170.98.20]:25 posttls-finger: < 220 c8a.amsl.com ESMTP Postfix posttls-finger: > EHLO amnesiac.localhost posttls-finger: < 250-c8a.amsl.com posttls-finger: < 250-PIPELINING posttls-finger: < 250-SIZE 67108864 posttls-finger: < 250-ETRN posttls-finger: < 250-STARTTLS posttls-finger: < 250-AUTH PLAIN LOGIN posttls-finger: < 250-AUTH=PLAIN LOGIN posttls-finger: < 250-ENHANCEDSTATUSCODES posttls-finger: < 250-8BITMIME posttls-finger: < 250 DSN posttls-finger: > STARTTLS posttls-finger: < 220 2.0.0 Ready to start TLS posttls-finger: mail.amsl.com[64.170.98.20]:25 CommonName smtp.amsl.com posttls-finger: certificate verification failed for mail.amsl.com[64.170.98.20]:25: self-signed certificate posttls-finger: mail.amsl.com[64.170.98.20]:25: subject_CN=smtp.amsl.com, issuer_CN=smtp.amsl.com, fingerprint=A8:39:D3:5D:90:65:96:D4:BB:DB:0A:E5:F9:C8:0E:14:99:15:7D:6C, pkey_fingerprint=0F:E2:FB:2F:A6:AA:69:3B:B6:4A:A3:40:6B:FD:2D:09:95:03:74:38 posttls-finger: Untrusted TLS connection established to mail.amsl.com[64.170.98.20]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) posttls-finger: > EHLO amnesiac.localhost posttls-finger: < 250-c8a.amsl.com posttls-finger: < 250-PIPELINING posttls-finger: < 250-SIZE 67108864 posttls-finger: < 250-ETRN posttls-finger: < 250-AUTH PLAIN LOGIN posttls-finger: < 250-AUTH=PLAIN LOGIN posttls-finger: < 250-ENHANCEDSTATUSCODES posttls-finger: < 250-8BITMIME posttls-finger: < 250 DSN posttls-finger: > QUIT posttls-finger: < 221 2.0.0 Bye -- Viktor. From oneofthem@lavabit.com Sat May 25 03:31:28 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1A7121F937B for ; Sat, 25 May 2013 03:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 4VhrC5Yep9nZ for ; Sat, 25 May 2013 03:31:24 -0700 (PDT) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by ietfa.amsl.com (Postfix) with ESMTP id 09A1B21F901A for ; Sat, 25 May 2013 03:31:17 -0700 (PDT) Received: from a.earth.lavabit.com (a.earth.lavabit.com [192.168.111.10]) by karen.lavabit.com (Postfix) with ESMTP id A0E0311B88E for ; Sat, 25 May 2013 05:31:16 -0500 (CDT) Received: from lavabit.com (ppp118-208-155-110.lns20.bne1.internode.on.net [118.208.155.110]) by lavabit.com with ESMTP id CXZMSF7NLH24 for ; Sat, 25 May 2013 05:31:16 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=lavabit; d=lavabit.com; b=Iv0SVOrZuH4lhQKUt+3YVgg1WObUezLW5/0t3PBNrBFUUv3ezkIyvTG6T4PPW9qvqeq4MR6gwYOITJYXjoEZygckL13wBAmnjEGKcaqNowEYNbH5Ia8L+PyrAMCAOYrL/nBj8NVWLN7cmknu0KIHYxIIReGa2624lt5s3mc/ZQU=; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type:Content-Disposition:User-Agent; Date: Sat, 25 May 2013 20:30:52 +1000 From: oneofthem To: dane@ietf.org Message-ID: <20130525103051.GC12066@lavabit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [dane] Few questions X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 25 May 2013 11:06:50 -0000 1. Is DANE finished? Ready to go, rock and roll? 2. Is it possible for DANE to replace the CA system currently in place? Thanks. From leifj@mnt.se Sat May 25 05:14:22 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09FD721F946F for ; Sat, 25 May 2013 05:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.691 X-Spam-Level: X-Spam-Status: No, score=-1.691 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, 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 sMntzp3KokvF for ; Sat, 25 May 2013 05:14:17 -0700 (PDT) Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) by ietfa.amsl.com (Postfix) with ESMTP id 1D25021F94F5 for ; Sat, 25 May 2013 05:14:16 -0700 (PDT) Received: by mail-lb0-f179.google.com with SMTP id r11so5405367lbv.24 for ; Sat, 25 May 2013 05:14:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=cFMB3ntNMZ6zkl+ieslpDVsLRXPPGcL88IUp8+w6pcY=; b=Y2oZwdATfQs57n10ulBmU92Nzc7EIRL3Tz/vYAchA02UdV3qZW7DZG4Zsrt21J4zW1 Jcbg4IIU7PdBA9WXIMvz9btREdloweWBPCpifp2pzPYY+1RoDeTj8ntY8RgwU6ZSGX2s 9gxonaLKM1nKTA0dZIuegnT4gTBOzKpj6Zw84TnxeTStXouKrcpSY8AlOKuiidxP3O2f H+OlBzWrFT/scYMbeQhOw9ncXNx4QoLRkPPdUYU6+dexeg6I/cq7TpxCT5eJlBJS9qDN a7DhxNvh0agtLdkjBtJgyfFNR+zob9VsWFZTRaNp9Zhne5zZZdOBmk4+6jHPlUzbQnQr zXhQ== X-Received: by 10.112.1.38 with SMTP id 6mr4849019lbj.100.1369484055545; Sat, 25 May 2013 05:14:15 -0700 (PDT) Received: from [2.71.21.130] (2.71.21.130.mobile.tre.se. [2.71.21.130]) by mx.google.com with ESMTPSA id g10sm8382100lag.10.2013.05.25.05.14.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 25 May 2013 05:14:14 -0700 (PDT) References: <20130525103051.GC12066@lavabit.com> Mime-Version: 1.0 (1.0) In-Reply-To: <20130525103051.GC12066@lavabit.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (10B350) From: Leif Johansson Date: Sat, 25 May 2013 14:14:10 +0200 To: oneofthem X-Gm-Message-State: ALoCoQneylhmVkg6tIzEZ4DZGW9VQXs583YOC8SGvYjPIyFO1yNBEnka5c0IW0qdlA9n2BRuPNjj Cc: "dane@ietf.org" Subject: Re: [dane] Few questions X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 25 May 2013 12:14:22 -0000 25 maj 2013 kl. 12:30 skrev oneofthem : > 1. Is DANE finished? Ready to go, rock and roll? yes > 2. Is it possible for DANE to replace the CA system currently in place? depends on what you need to do > > Thanks. > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From viktor1dane@dukhovni.org Sat May 25 07:42:21 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 352E621F89FD for ; Sat, 25 May 2013 07:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 Cqv-KspwQqud for ; Sat, 25 May 2013 07:42:16 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 163DD21F84A7 for ; Sat, 25 May 2013 07:42:16 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 6B1B22AAFA5; Sat, 25 May 2013 14:42:14 +0000 (UTC) Date: Sat, 25 May 2013 14:42:14 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130525144214.GD9380@mournblade.imrryr.org> References: <20130525103051.GC12066@lavabit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130525103051.GC12066@lavabit.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Few questions X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 May 2013 14:42:21 -0000 On Sat, May 25, 2013 at 08:30:52PM +1000, oneofthem wrote: > 1. Is DANE finished? Ready to go, rock and roll? The TLSA RR has been standardized. What remains to do is to define how TLSA records are to be used in various application protocols. For application protocols that use SRV records there is a draft in progress. There is another draft for SMTP based on the SRV draft since MX records are similar to SRV records. I have proposed two recent drafts (see the list archives) that address in more detail how applications that can't use the existing public CA PKI should interact with DANE (in particular SMTP) and also some implications for various corner cases. I have also proposed that applications "follow CNAMEs" to derive the base domain for TLSA records. It remains to be seen whether this will gain any traction. OpenSSL does not yet provide ready-to-use DANE verification code, so applications based on OpenSSL have to roll their own. This will change at some point, though I hope in not too soon, since the required changes are invasive, and need some time for the design and implementation to be validated. > 2. Is it possible for DANE to replace the CA system currently in place? For server domains that have deployed DNSSEC, and applications where clients have DNSSEC validating caching resolvers (or have chosen to embed DNSSEC capable stub-resolvers directly in application code) it is possible to bypass the existing public CA PKI. Just publish TLSA records with usage "3" or perhaps "2", and with usage "2" make sure to include the TA cert in the server's TLS handshake certificate chain. -- Viktor. From oneofthem@lavabit.com Sat May 25 07:54:17 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7B2021F8B15 for ; Sat, 25 May 2013 07:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 K981D5r07f3O for ; Sat, 25 May 2013 07:54:04 -0700 (PDT) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by ietfa.amsl.com (Postfix) with ESMTP id DF16221F8AF4 for ; Sat, 25 May 2013 07:54:00 -0700 (PDT) Received: from a.earth.lavabit.com (a.earth.lavabit.com [192.168.111.10]) by karen.lavabit.com (Postfix) with ESMTP id 6BCB511B878 for ; Sat, 25 May 2013 09:54:00 -0500 (CDT) Received: from lavabit.com (ppp118-208-155-110.lns20.bne1.internode.on.net [118.208.155.110]) by lavabit.com with ESMTP id IE2N8P9TUSDU for ; Sat, 25 May 2013 09:54:00 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=lavabit; d=lavabit.com; b=CWUOq4C0Fst2T1nIvvpuKyyJWQKVowc/3HkRGXXHOXuS8TziAojmfJDY5dYvZaUB/sSeRp2ZLWXGLNY4Q6dbEfdJ+KiABhccibTuBpyxvGRbkzwYYHRMxrdPWNRay8SCMJMi1mSWhEbYgo87k1ITf9U0qSLeTSqfquuyea4mNo0=; h=Date:From:To:Subject:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:User-Agent; Date: Sun, 26 May 2013 00:53:35 +1000 From: oneofthem To: dane@ietf.org Message-ID: <20130525145334.GA17763@lavabit.com> References: <20130525103051.GC12066@lavabit.com> <20130525144214.GD9380@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130525144214.GD9380@mournblade.imrryr.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Few questions X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 25 May 2013 14:54:18 -0000 On Sat, May 25, 2013 at 02:42:14PM +0000, Viktor Dukhovni wrote: > On Sat, May 25, 2013 at 08:30:52PM +1000, oneofthem wrote: > > > 1. Is DANE finished? Ready to go, rock and roll? > > The TLSA RR has been standardized. What remains to do is to define > how TLSA records are to be used in various application protocols. > > For application protocols that use SRV records there is a draft in progress. > There is another draft for SMTP based on the SRV draft since MX records > are similar to SRV records. > > I have proposed two recent drafts (see the list archives) that address in > more detail how applications that can't use the existing public CA PKI > should interact with DANE (in particular SMTP) and also some implications > for various corner cases. > > I have also proposed that applications "follow CNAMEs" to derive > the base domain for TLSA records. It remains to be seen whether > this will gain any traction. > > OpenSSL does not yet provide ready-to-use DANE verification code, > so applications based on OpenSSL have to roll their own. This will > change at some point, though I hope in not too soon, since the > required changes are invasive, and need some time for the design > and implementation to be validated. > > > 2. Is it possible for DANE to replace the CA system currently in place? > > For server domains that have deployed DNSSEC, and applications > where clients have DNSSEC validating caching resolvers (or have > chosen to embed DNSSEC capable stub-resolvers directly in application > code) it is possible to bypass the existing public CA PKI. > > Just publish TLSA records with usage "3" or perhaps "2", and with > usage "2" make sure to include the TA cert in the server's TLS > handshake certificate chain. > > -- > Viktor. > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane Thank you for your in depth response! From warren@kumari.net Sat May 25 10:09:49 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 069CC21F8618 for ; Sat, 25 May 2013 10:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.74 X-Spam-Level: X-Spam-Status: No, score=-100.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 uP6187WCpGe9 for ; Sat, 25 May 2013 10:09:43 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3277E21F8689 for ; Sat, 25 May 2013 10:09:42 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.124]) by vimes.kumari.net (Postfix) with ESMTPSA id BF23C1B40478; Sat, 25 May 2013 13:09:41 -0400 (EDT) From: Warren Kumari Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 25 May 2013 13:09:41 -0400 Message-Id: <0B5C8480-BF7C-4404-AC90-7A231DE51D1C@kumari.net> To: "dane@ietf.org list" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [dane] Call for Agenda items X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 25 May 2013 17:09:49 -0000 Hi all, It seems that we probably have enough new material / discussions to = warrant meeting in Berlin. So, please let us know, by the end of the month, if you'd like time on = the agenda. As always, we give preference to issues / documents that have had some = discussion on the mailing list, but need real-time, fact-to-face = discussions to properly resolve. Seeing as we now have some implementations (thanks!), we'd welcome = discussions of those as well. W P.S: Apologies for this coming somewhat late -- I picked up (what I'm = convinced is) bird flu at RIPE in Dublin the week before last... -- I once absend-mindedly ordered Three Mile Island dressing in a = restaurant and, with great presence of mind, they brought Thousand = Island Dressing and a bottle of chili sauce. -- Terry Pratchett From wes@hardakers.net Tue May 28 07:20:34 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 485EF21F978E for ; Tue, 28 May 2013 07:20:34 -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 rbKo3s-BM8Vz for ; Tue, 28 May 2013 07:20:30 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by ietfa.amsl.com (Postfix) with ESMTP id DEAFA21F973F for ; Tue, 28 May 2013 07:20:18 -0700 (PDT) Received: from localhost (wjh.hardakers.net [IPv6:2001:470:1f00:187:f2de:f1ff:fee6:e6e8]) by mail.hardakers.net (Postfix) with ESMTPSA id C068A229FF; Tue, 28 May 2013 07:20:16 -0700 (PDT) From: Wes Hardaker To: Viktor Dukhovni References: <20130525103051.GC12066@lavabit.com> <20130525144214.GD9380@mournblade.imrryr.org> Date: Tue, 28 May 2013 07:20:15 -0700 In-Reply-To: <20130525144214.GD9380@mournblade.imrryr.org> (Viktor Dukhovni's message of "Sat, 25 May 2013 14:42:14 +0000") Message-ID: <0lr4gryyn4.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: dane@ietf.org Subject: Re: [dane] Few questions X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 28 May 2013 14:20:34 -0000 Viktor Dukhovni writes: > On Sat, May 25, 2013 at 08:30:52PM +1000, oneofthem wrote: > >> 1. Is DANE finished? Ready to go, rock and roll? > > The TLSA RR has been standardized. What remains to do is to define > how TLSA records are to be used in various application protocols. It's worth noting, since Viktor unintentionally glossed over it, that the base TLSA definition does include definitions for how to use it over TLS and targeted toward HTTPS specifically, so another document isn't needed for that case. The other protocols he mentioned still need some definition and binding, however. > OpenSSL does not yet provide ready-to-use DANE verification code, > so applications based on OpenSSL have to roll their own. Or use another library that provides DANE validation hooks to use for OpenSSL verification links. (eg: https://www.dnssec-tools.org/svn/dnssec-tools/trunk/htdocs/docs/tool-description/val_getdaneinfo.html ) It shouldn't be hard to get up and running today, and many applications and examples exist for you to glance at and study: https://www.dnssec-tools.org/svn/dnssec-tools/trunk/dnssec-tools/apps/curl/curl-7.29.0.patch >> 2. Is it possible for DANE to replace the CA system currently in place? > > For server domains that have deployed DNSSEC, and applications > where clients have DNSSEC validating caching resolvers (or have > chosen to embed DNSSEC capable stub-resolvers directly in application > code) it is possible to bypass the existing public CA PKI. Different people have different security needs and beliefs. So can DANE be used to bootstrap your security needs? Absolutely, if it meets your security requirements (and I think it meets the needs of most people quite well). -- Wes Hardaker My Pictures: http://capturedonearth.com/ My Thoughts: http://pontifications.hardakers.net/ From viktor1dane@dukhovni.org Tue May 28 08:51:21 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8567621F8CA5 for ; Tue, 28 May 2013 08:51:21 -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 ZDaLJVhSGgqY for ; Tue, 28 May 2013 08:51:12 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id C463E21F8C03 for ; Tue, 28 May 2013 08:51:12 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id E03222AABA9; Tue, 28 May 2013 15:51:11 +0000 (UTC) Date: Tue, 28 May 2013 15:51:11 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130528155111.GG9380@mournblade.imrryr.org> References: <20130525103051.GC12066@lavabit.com> <20130525144214.GD9380@mournblade.imrryr.org> <0lr4gryyn4.fsf@wjh.hardakers.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0lr4gryyn4.fsf@wjh.hardakers.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Few questions X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 15:51:21 -0000 On Tue, May 28, 2013 at 07:20:15AM -0700, Wes Hardaker wrote: > It's worth noting, since Viktor unintentionally glossed over it, that > the base TLSA definition does include definitions for how to use it over > TLS and targeted toward HTTPS specifically, so another document isn't > needed for that case. The other protocols he mentioned still need some > definition and binding, however. Yes, my response was perhaps too brief. For HTTPS, RFC 6698 is largely sufficient. There is a corner case with "2 1 [12]" TLSA RRs and an unstated requirement for servers to include the TA certificate in their chain. Many verifier implementations don't correctly handle "2 1 0" TLSA RRs. > > OpenSSL does not yet provide ready-to-use DANE verification code, > > so applications based on OpenSSL have to roll their own. > > Or use another library that provides DANE validation hooks to use for > OpenSSL verification links. > > (eg: https://www.dnssec-tools.org/svn/dnssec-tools/trunk/htdocs/docs/tool-description/val_getdaneinfo.html ) > This library's (latest 2.0 release) implementation of certificate usage 2 is rather broken none of the "2 x y" cases are implemented correctly. More fundamentally, this library is (as evidenced by the curl patch) intended to be used after a permissive SSL verification callback which ignores all errors (or equivalently with any callback and SSL_VERIFY_NONE set). This will ignore parent-child signature errors and expiration problems in the certificate chain. Since applications generally expect PKIX validation to performed during the handshake, application code that runs post-handshake rarely if ever performs a complete set of PKIX checks. Thus also with certificate usage 0 and 1 the patched curl will not in fact validate the PKIX certificate chain. So only certificate usage 3 may work (at first glance), the others are definitely broken. > It shouldn't be hard to get up and running today, and many applications > and examples exist for you to glance at and study: > > https://www.dnssec-tools.org/svn/dnssec-tools/trunk/dnssec-tools/apps/curl/curl-7.29.0.patch Which in turn breaks the patched curl. Support for DANE in this library needs to be fixed or withdrawn. -- Viktor. From suresh@tislabs.com Tue May 28 12:29:26 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 390DD21F9600 for ; Tue, 28 May 2013 12:29:26 -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 zgstP6Q6zgJJ for ; Tue, 28 May 2013 12:29:21 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) by ietfa.amsl.com (Postfix) with ESMTP id 3C70F21F955E for ; Tue, 28 May 2013 12:29:21 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 4014528B0017 for ; Tue, 28 May 2013 15:29:20 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 2C05A1F8032; Tue, 28 May 2013 15:29:20 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Suresh Krishnaswamy In-Reply-To: <20130528155111.GG9380@mournblade.imrryr.org> Date: Tue, 28 May 2013 15:29:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5E8A5A01-3D8B-4FF3-B773-B51D800F4024@tislabs.com> References: <20130525103051.GC12066@lavabit.com> <20130525144214.GD9380@mournblade.imrryr.org> <0lr4gryyn4.fsf@wjh.hardakers.net> <20130528155111.GG9380@mournblade.imrryr.org> To: dane@ietf.org X-Mailer: Apple Mail (2.1085) Subject: Re: [dane] Few questions X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 28 May 2013 19:29:26 -0000 Hi Viktor, On May 28, 2013, at 11:51 AM, Viktor Dukhovni wrote: > On Tue, May 28, 2013 at 07:20:15AM -0700, Wes Hardaker wrote: >>> OpenSSL does not yet provide ready-to-use DANE verification code, >>> so applications based on OpenSSL have to roll their own. >>=20 >> Or use another library that provides DANE validation hooks to use for >> OpenSSL verification links. >>=20 >> (eg: = https://www.dnssec-tools.org/svn/dnssec-tools/trunk/htdocs/docs/tool-descr= iption/val_getdaneinfo.html ) >>=20 >=20 > This library's (latest 2.0 release) implementation of certificate > usage 2 is rather broken none of the "2 x y" cases are implemented > correctly. >=20 Yep, the implementation of usage 2 in the 2.0 release is quite broken. = However, the svn version should be better = (https://www.dnssec-tools.org/svn/dnssec-tools/trunk/dnssec-tools/validato= r/libval/val_dane.c). Feedback is always welcome.=20 You're also welcome to try out the DANE-capable Bloodhound browser = (http://www.dnssec-tools.org/download/#gotoBloodhound), which links = against a more recent (post-2.0) version of libval primarily for this = reason. > More fundamentally, this library is (as evidenced by the curl patch) > intended to be used after a permissive SSL verification callback > which ignores all errors (or equivalently with any callback and > SSL_VERIFY_NONE set). This will ignore parent-child signature > errors and expiration problems in the certificate chain. >=20 > Since applications generally expect PKIX validation to performed > during the handshake, application code that runs post-handshake > rarely if ever performs a complete set of PKIX checks. >=20 I agree with you that we'd normally want the DANE checks to occur during = the SSL hand-shake itself for all the reasons you've given above. In the = case of libcurl, though, it appears that the application performs its = own set of certificate checks in ossl_connect_step3(). Now, I'm by no = means an expert in the libcurl code-base and could still be way wrong, = but a quick test seemed to confirm that expired TLS certs are in fact = caught even with the patch applied.=20 Thanks! Suresh= From viktor1dane@dukhovni.org Tue May 28 12:59:24 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C56D121F9246 for ; Tue, 28 May 2013 12:59:24 -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 96rRLgyGVsOT for ; Tue, 28 May 2013 12:59:20 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 873E521F9195 for ; Tue, 28 May 2013 12:59:20 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id BC9112AB9A4; Tue, 28 May 2013 19:59:19 +0000 (UTC) Date: Tue, 28 May 2013 19:59:19 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130528195919.GO9380@mournblade.imrryr.org> References: <20130525103051.GC12066@lavabit.com> <20130525144214.GD9380@mournblade.imrryr.org> <0lr4gryyn4.fsf@wjh.hardakers.net> <20130528155111.GG9380@mournblade.imrryr.org> <5E8A5A01-3D8B-4FF3-B773-B51D800F4024@tislabs.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5E8A5A01-3D8B-4FF3-B773-B51D800F4024@tislabs.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Few questions X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 19:59:24 -0000 On Tue, May 28, 2013 at 03:29:20PM -0400, Suresh Krishnaswamy wrote: > > This library's (latest 2.0 release) implementation of certificate > > usage 2 is rather broken none of the "2 x y" cases are implemented > > correctly. > > > > Yep, the implementation of usage 2 in the 2.0 release is quite > broken. However, the svn version should be better > (https://www.dnssec-tools.org/svn/dnssec-tools/trunk/dnssec-tools/validator/libval/val_dane.c). > > Feedback is always welcome. This version is much better, it does not handle "IN TLSA 2 1 0", where only the public key is in DNS, and the chain omits the corresponding TA certificate (it starts with a certificate signed by the TLSA public key). It is also somewhat inefficient, since it repeats the checks in X509_verify_cert() performed during the handshake. Doing this via a verify callback rather than via a post-handshake function is more natural. Also the result of val_dane_check() does not distinguish between usage 2 (which requires name checks on the leaf cert) and usage 3 (which does not!). Neither require PKIX checks, so usage 2 is still insecure since applications will likely skip all further checks. This interface likely needs to take of name checks. > > > More fundamentally, this library is (as evidenced by the curl patch) > > intended to be used after a permissive SSL verification callback > > which ignores all errors (or equivalently with any callback and > > SSL_VERIFY_NONE set). This will ignore parent-child signature > > errors and expiration problems in the certificate chain. > > > > Since applications generally expect PKIX validation to performed > > during the handshake, application code that runs post-handshake > > rarely if ever performs a complete set of PKIX checks. > > > > I agree with you that we'd normally want the DANE checks to occur > during the SSL hand-shake itself for all the reasons you've given > above. In the case of libcurl, though, it appears that the application > performs its own set of certificate checks in ossl_connect_step3(). > Now, I'm by no means an expert in the libcurl code-base and could > still be way wrong, but a quick test seemed to confirm that expired > TLS certs are in fact caught even with the patch applied. Curl only looks at the expiration times of the leaf certificate, not the intermediate certificates, much more importantly it does not check that any of the certificates in the chain are actually signed by the certificate one layer deeper in the chain. Therefore, with the 2.0 release, certificate usage 0 is trivially forged by a MITM attack. With usage 1, the PKIX checks are not correctly applied, and it is no stronger than 3. The version 2.0 code is unsafe for most certificate usages and should be withdrawn. Designing a robust library extension to OpenSSL that handles the needs of multiple applications is non-trivial. Since And Polyakov of OpenSSL has started this work, perhaps the dnsval features for this should be withdrawn rather than extended/improved further. I know that some of the issues I'm reporting here apply equally to the OpenSSL git version, but with luck those will be fixed, and in time should obviate the need for add-on libraries. Though it may take some time, my view is that in the interim "no code" is better than "some code", when "some" means incomplete and likely insecure. -- Viktor. From viktor1dane@dukhovni.org Tue May 28 15:37:34 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3159E21F8F1E for ; Tue, 28 May 2013 15:37:34 -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 jDl6VQ8qMtgf for ; Tue, 28 May 2013 15:37:29 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id AA2BA21F8F0E for ; Tue, 28 May 2013 15:37:26 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 585DF2AB9D7; Tue, 28 May 2013 22:37:24 +0000 (UTC) Date: Tue, 28 May 2013 22:37:24 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130528223724.GP9380@mournblade.imrryr.org> References: <20130525103051.GC12066@lavabit.com> <20130525144214.GD9380@mournblade.imrryr.org> <0lr4gryyn4.fsf@wjh.hardakers.net> <20130528155111.GG9380@mournblade.imrryr.org> <5E8A5A01-3D8B-4FF3-B773-B51D800F4024@tislabs.com> <20130528195919.GO9380@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130528195919.GO9380@mournblade.imrryr.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Few questions X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 22:37:34 -0000 On Tue, May 28, 2013 at 07:59:19PM +0000, Viktor Dukhovni wrote: > > Yep, the implementation of usage 2 in the 2.0 release is quite > > broken. However, the svn version should be better > > (https://www.dnssec-tools.org/svn/dnssec-tools/trunk/dnssec-tools/validator/libval/val_dane.c). > > > > Feedback is always welcome. > > This version is much better, it does not handle "IN TLSA 2 1 0", > where only the public key is in DNS, and the chain omits the > corresponding TA certificate (it starts with a certificate signed > by the TLSA public key). It is also somewhat inefficient, since > it repeats the checks in X509_verify_cert() performed during the > handshake. Doing this via a verify callback rather than via a > post-handshake function is more natural. In fact X509_verify_cert() is called for each usage 0/2 TLSA record, until one matches, each time re-verifying chain properties unrelated to PKI trust (PKIX or DANE) and calling the application verify callback multiple times with the same certificates, sometimes reporting failure, sometimes not. Another substantial problem is that X509_verify_cert() only checks the trust store against the top of the peer's certificate chain, so with usage 0 or 2 if the TLSA record trust anchor is in the middle of the chain DANE verification incorrectly fails. To fix this, the chain needs to be copied to a new chain that is truncated at the top to ensure that the matching TA certificate is its first element. Full support for "IN TLSA 2 1 0" requires further non-trivial code (until a future RFC updates 6698 and spells out a requirement for usage 2 servers to include the TA cert in their TLS handshake chain in all usage "2 x y" cases except "2 0 0"). My view is that applications should not use this library for DANE support except on an experimental basis. -- Viktor. From bry8star@inventati.org Tue May 28 17:56:22 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 894C421F8503 for ; Tue, 28 May 2013 17:56:21 -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 N-D5O2KjMZ7g for ; Tue, 28 May 2013 17:56:18 -0700 (PDT) Received: from latitanza.investici.org (latitanza.investici.org [IPv6:2002:525e:f9ea::1]) by ietfa.amsl.com (Postfix) with ESMTP id BC79321F84A6 for ; Tue, 28 May 2013 17:56:11 -0700 (PDT) Received: from [82.94.249.234] (latitanza [82.94.249.234]) (Authenticated sender: bry8star@inventati.org) by localhost (Postfix) with ESMTPSA id 76238980C7 for ; Wed, 29 May 2013 00:56:06 +0000 (UTC) X-DKIM: Sendmail DKIM Filter v2.8.2 latitanza.investici.org 76238980C7 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inventati.org; s=stigmate; t=1369788970; bh=7geR13xIKX5EgEUOXsUgIWQ2reUa1DuNWWRWzcxk4Ds=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=g+yB3mC5B/GGkrANXtsuF7w6BXeq57HBmRziBxuGOl4UcJ/+7PkmuLzgNed0E0706 I02g8YNyUmnRActUTlJusq415Km3hUNJ1e3bcrEIeJek9HVxdQrfOVaYiHzEFJFLQw pmQa1ZOTprYs98oJuQGlTXFNloTe3JWprGldjGuA= Message-ID: <51A55222.7020800@inventati.org> Date: Tue, 28 May 2013 17:56:02 -0700 From: Bry8 Star User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dane@ietf.org References: <20130525103051.GC12066@lavabit.com> <20130525144214.GD9380@mournblade.imrryr.org> <0lr4gryyn4.fsf@wjh.hardakers.net> <20130528155111.GG9380@mournblade.imrryr.org> In-Reply-To: <20130528155111.GG9380@mournblade.imrryr.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dane] Few questions X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: bry8star@inventati.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 00:56:22 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 on windows side, users (including me) are using, two firefox addons: "Extended DNSSSEC Validator" (www.os3sec.org), "DNSSEC Validator" (www.dnssec-validator.cz), and these two are able to use a local or remote DNSSEC validation supported DNS-Resolver/Server, and seems to be able to handle at-least "2 s m" and "3 s m" TLSA cases. - -- Bright Star. (Bry8Star). Received from Viktor Dukhovni, on 2013-05-28 8:51 AM: > On Tue, May 28, 2013 at 07:20:15AM -0700, Wes Hardaker wrote: > >> It's worth noting, since Viktor unintentionally glossed over it, that >> the base TLSA definition does include definitions for how to use it over >> TLS and targeted toward HTTPS specifically, so another document isn't >> needed for that case. The other protocols he mentioned still need some >> definition and binding, however. > > Yes, my response was perhaps too brief. For HTTPS, RFC 6698 is > largely sufficient. There is a corner case with "2 1 [12]" TLSA RRs > and an unstated requirement for servers to include the TA certificate > in their chain. Many verifier implementations don't correctly handle > "2 1 0" TLSA RRs. > >>> OpenSSL does not yet provide ready-to-use DANE verification code, >>> so applications based on OpenSSL have to roll their own. >> >> Or use another library that provides DANE validation hooks to use for >> OpenSSL verification links. >> >> (eg: https://www.dnssec-tools.org/svn/dnssec-tools/trunk/htdocs/docs/tool-description/val_getdaneinfo.html ) >> > > This library's (latest 2.0 release) implementation of certificate > usage 2 is rather broken none of the "2 x y" cases are implemented > correctly. > > More fundamentally, this library is (as evidenced by the curl patch) > intended to be used after a permissive SSL verification callback > which ignores all errors (or equivalently with any callback and > SSL_VERIFY_NONE set). This will ignore parent-child signature > errors and expiration problems in the certificate chain. > > Since applications generally expect PKIX validation to performed > during the handshake, application code that runs post-handshake > rarely if ever performs a complete set of PKIX checks. > > Thus also with certificate usage 0 and 1 the patched curl will not > in fact validate the PKIX certificate chain. So only certificate > usage 3 may work (at first glance), the others are definitely > broken. > >> It shouldn't be hard to get up and running today, and many applications >> and examples exist for you to glance at and study: >> >> https://www.dnssec-tools.org/svn/dnssec-tools/trunk/dnssec-tools/apps/curl/curl-7.29.0.patch > > Which in turn breaks the patched curl. Support for DANE in this > library needs to be fixed or withdrawn. > -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJRpVIiAAoJEID2ikYfWSP62DsP/idb4arInNFAZFFLugYMazHi fhP4do634WqCHMm3nG9z1U8mtngC9S5LYMCv0Vuwx8/1l2yKJipvsG3C0V1emzVZ z0c1ybVAEcFud6VHoKDEmn8FLtnO1M9wUMoX5g7QaKM5UHJqkaCglTulRt9FcYS9 acQf4boldRA7dPrtE4LMZhFfTZyzOM2rYgi/nYmeqqNg3jWYe4vrDlqTALeBA6a4 6bieB+KkfLkgKmLQCprw3kx3XQ5DOZRonmnvLIAtrlR8UX3UeKHKz902vhqve7N2 os0p0l9P592XKDfKL77GwSv8fl0ql1WC6088cJdvM5qor4ytrM8QbfZYG/ms5+cL 4XyooZGHLjBXdg2lmbuKJSLWuLzov87D9mxjmSqVKVVyLWGoMdi4ilWCZS8eBY7Y ZS+4vxLDjsk7gSgXV9ugywQP+/lwRbvPOlSa5LMUF4pVv6eRwXfmx+ZU5JFGLhPF 4UfNAaVXgfmVIH2o1LtykTf0hxNg1+dKiyX5XfykySlFkQB1hnnvEcOvLBIZvmtp quBw0bAKvK5R2rXIoEtw1zD640Zg+01AdYT+H1eU9QIGPaRw27Y+oY3bToCOZKwA wGMu6Z2xy40J5amPBEobvqIGoEZhrjjzPTFliqUHKgLGoPH0WRxCCoFMZftL8MjW iOX6LmUNp0V31QZdhFky =F+jg -----END PGP SIGNATURE----- From viktor1dane@dukhovni.org Tue May 28 18:29:57 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE1D21F87FB for ; Tue, 28 May 2013 18:29:57 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhhWgRHIZeRC for ; Tue, 28 May 2013 18:29:51 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 20B0221F8709 for ; Tue, 28 May 2013 18:29:51 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3524A2AB9CD; Wed, 29 May 2013 01:29:50 +0000 (UTC) Date: Wed, 29 May 2013 01:29:50 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130529012949.GR9380@mournblade.imrryr.org> References: <20130525103051.GC12066@lavabit.com> <20130525144214.GD9380@mournblade.imrryr.org> <0lr4gryyn4.fsf@wjh.hardakers.net> <20130528155111.GG9380@mournblade.imrryr.org> <51A55222.7020800@inventati.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51A55222.7020800@inventati.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Few questions X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 01:29:57 -0000 On Tue, May 28, 2013 at 05:56:02PM -0700, Bry8 Star wrote: > -----BEGIN PGP SIGNED MESSAGE----- http://xkcd.com/1181 > on windows side, users (including me) are using, two firefox addons: > "Extended DNSSSEC Validator" (www.os3sec.org), The code I found for this on github does not support certificate usage 0 or 1 and ignores the TLSA RR selector, always matching the certificate and not the public key. It appears to hardcode port 443 for TLSA RR lookups, rather than use the port from the URI. It is far from clear how it handles name checks. Likely many more problems. At first glance it is a toy not suitable for serious use. > "DNSSEC Validator" > (www.dnssec-validator.cz), and these two are able to use a local or > remote DNSSEC validation supported DNS-Resolver/Server, and seems to > be able to handle at-least "2 s m" and "3 s m" TLSA cases. I have not had a chance to look at this in detail and I don't know much about writing browser plugins, so it is not clear how one robustly hooks into the browser's HTTPS connection establishment process. I would recommend using browsers that support DANE natively, via a properly reviewed implementation in the browser itself. I'd be suspicious of the safety of addons. Perhaps someone else can take a stab at it. My impression is that a non-trivial fraction of the early implementations are substantively flawed. Caveat emptor. -- Viktor. From bry8star@inventati.org Tue May 28 21:11:45 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 441AE21F86C4 for ; Tue, 28 May 2013 21:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_64=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 Vqk9+rI8JXGS for ; Tue, 28 May 2013 21:11:44 -0700 (PDT) Received: from latitanza.investici.org (latitanza.investici.org [IPv6:2002:525e:f9ea::1]) by ietfa.amsl.com (Postfix) with ESMTP id 282F221F8681 for ; Tue, 28 May 2013 21:11:43 -0700 (PDT) Received: from [82.94.249.234] (latitanza [82.94.249.234]) (Authenticated sender: bry8star@inventati.org) by localhost (Postfix) with ESMTPSA id 89734980C7 for ; Wed, 29 May 2013 04:11:38 +0000 (UTC) X-DKIM: Sendmail DKIM Filter v2.8.2 latitanza.investici.org 89734980C7 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inventati.org; s=stigmate; t=1369800702; bh=SPWJ6TaKu2ALRda01CbsFswEcHPrW9eDUiCdTlnR7L4=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject:References: In-Reply-To:Content-Type; b=WO+J0B1r2h5qtj32/8r0DH0CkqFRNET90lbbitLvJEEjAGd1CcebrgCe2EYEjefwn EE7mZ/csQ+G9pXewbEo/HfzgtdrXgsrD3f5ghJQcMMUQJ2E9RYMTx5j9z+FA/l6MVc +g63lHRZTnmcCgrUVXASnzlOP3+GiZ6gomB7Oydw= Message-ID: <51A57FE1.2060805@inventati.org> Date: Tue, 28 May 2013 21:11:13 -0700 From: Bry8 Star User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dane@ietf.org References: <20130525103051.GC12066@lavabit.com> <20130525144214.GD9380@mournblade.imrryr.org> <0lr4gryyn4.fsf@wjh.hardakers.net> <20130528155111.GG9380@mournblade.imrryr.org> <51A55222.7020800@inventati.org> <20130529012949.GR9380@mournblade.imrryr.org> In-Reply-To: <20130529012949.GR9380@mournblade.imrryr.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2NDCLCSCOHLBAAFMUISMD" Subject: Re: [dane] Few questions X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: bry8star@inventati.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 04:11:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2NDCLCSCOHLBAAFMUISMD Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable unfortunately, Bloodhound web-browser (which is tweaked for native support of DNSSEC & TLSA/DANE) does not yet have a windows port/release :( I would agree completely, these addons have many more bugs and far from perfect. Even in "3 s m" or "2 s m" detection & verification, not very consistent yet. For example, even by using last release of these addons, when such sites/zones are visited : "mozilla.org" or on "addons.mozilla.org" , both are DNSSEC signed zones/sites (though, no TLSA rr yet). Addons showed those are not signed or secured by DNSSEC ! But for other major or more publicly known dnssec signed + TLSA based sites/zones, these addons do seem to show DNSSEC+DANE info/icon correctly, specially when "3 s m" based (aka: end-entity cert, domain-issued cert) TLSA exists for _443._tcp (HTTPS). In an attempt to create and test a TLSA "2 s m" implementation for HTTPS, apparently these addons did not show correct info. But it could also be that, our test RR implementation were wrong, or, TA cert and other cert were not in chain properly. So very likely internal source-codes are tuned for limited TLSA cases only. BTW, "Cipherfox" firefox-addon can visually show PKI cert chain, it appears inside (early mentioned) DNSSEC addon's popup/info window (when icon is clicked on), but afaiu this addon does not do any DNSSEC or DANE. It would have been great, if those two addons could show cert chain or debug info on which exact certs or chain of certs these addons have checked/verified. And even when configured in firefox to show debug info, those two addons do not actually show detail debug info. And if those two addons are further improved for using with Thunderbird for _993 , _995 , _25 , _465 based services then that would have been very helpful. Currently those two addons do not understand those DNS RR. -- Bright Star. Received from Viktor Dukhovni, on 2013-05-28 6:29 PM: > On Tue, May 28, 2013 at 05:56:02PM -0700, Bry8 Star wrote: >=20 >> -----BEGIN PGP SIGNED MESSAGE----- >=20 > http://xkcd.com/1181 >=20 >> on windows side, users (including me) are using, two firefox addons: >> "Extended DNSSSEC Validator" (www.os3sec.org), >=20 > The code I found for this on github does not support certificate > usage 0 or 1 and ignores the TLSA RR selector, always matching the > certificate and not the public key. It appears to hardcode port > 443 for TLSA RR lookups, rather than use the port from the URI. > It is far from clear how it handles name checks. Likely many more > problems. >=20 > At first glance it is a toy not suitable for serious use. >=20 >> "DNSSEC Validator" >> (www.dnssec-validator.cz), and these two are able to use a local or >> remote DNSSEC validation supported DNS-Resolver/Server, and seems to >> be able to handle at-least "2 s m" and "3 s m" TLSA cases. >=20 > I have not had a chance to look at this in detail and I don't know > much about writing browser plugins, so it is not clear how one > robustly hooks into the browser's HTTPS connection establishment > process. I would recommend using browsers that support DANE natively, > via a properly reviewed implementation in the browser itself. I'd be > suspicious of the safety of addons. >=20 > Perhaps someone else can take a stab at it. My impression is that > a non-trivial fraction of the early implementations are substantively > flawed. Caveat emptor. >=20 ------enig2NDCLCSCOHLBAAFMUISMD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJRpX/qAAoJEID2ikYfWSP6rxUP/25Lud/bbbbaw1keHziLHTNm 5ebzZ10GtGgbxksKkqXISpetj0m3NRTwj+b57JyPCspmUD9IoKNIfN9KFLNLyoT/ ZlWwlYXwz4tTgscyoVboeIw8Q5Y0IYSOTPAoEIoWJSrnsevoFuFrSVAY5DrPkOYe n+wn/z3BmgA8pynMYlgtY4vstUhZYXoxPBjsaQfeFmvzdnkbizRA+Y6UBXZkRVc5 PfJIIVsOfHIJIaEuO/OofMEZjxgTizCiPzcymKCfWgyg9/nFmh3Hc4aziYRHD1Jp 8vi9EtnE8+bycVug8uU8luh/hPF3KP4+FjOUJG3xpv22HPx9QjoegUoqaTZB7rBy jVAqBrMDuOsTyJ2VBXrYagw4kbDcx3hijTm++giFiSh9/55x1Nqq5yXAqriCGV3U payC0ty/G/Itf9uE+e0W7JUv8FiIh9R2KwxI6WOymPeOX2B3sa4Y6HlmfRwfy9kV Dfa71FLOhfT/W0PJqTXg1nioGq19Pva3I4h1WiWtOFKl+LNwKsLFM/wH6feXjtSJ A8yPdBHu9kPH9ZZTUJVynH2efO1RzW+Q05ILPtPNblDsPjV4pMYjbp5HsfxqU+6U sbdmLI4JlWFWxe+ssgdOtqrcOKlA//pwTWTZK0GSxmNBRXgMrfjvW4N7CrrLfaPZ 7DGQ1s9krd+PZPPzCVI+ =o1dV -----END PGP SIGNATURE----- ------enig2NDCLCSCOHLBAAFMUISMD-- From viktor1dane@dukhovni.org Tue May 28 22:00:15 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3081821F8B16 for ; Tue, 28 May 2013 22:00:15 -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 RMlFN-bRFmrc for ; Tue, 28 May 2013 22:00:10 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id CCF6021F8AD8 for ; Tue, 28 May 2013 22:00:09 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id A27A92AB9A4; Wed, 29 May 2013 05:00:08 +0000 (UTC) Date: Wed, 29 May 2013 05:00:08 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130529050008.GS9380@mournblade.imrryr.org> References: <20130525103051.GC12066@lavabit.com> <20130525144214.GD9380@mournblade.imrryr.org> <0lr4gryyn4.fsf@wjh.hardakers.net> <20130528155111.GG9380@mournblade.imrryr.org> <51A55222.7020800@inventati.org> <20130529012949.GR9380@mournblade.imrryr.org> <51A57FE1.2060805@inventati.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51A57FE1.2060805@inventati.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Few questions X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 05:00:15 -0000 On Tue, May 28, 2013 at 09:11:13PM -0700, Bry8 Star wrote: > I would agree completely, these addons have many more bugs and far > from perfect. Even in "3 s m" or "2 s m" detection & verification, > not very consistent yet. You are much more charitable to major design and implementation flaws than I am willing to be. > So very likely internal source-codes are tuned for limited TLSA > cases only. Why promote the use implementations that don't even correctly implement the subset of parameters they set out to support? > It would have been great, if those two addons could show cert chain > or debug info on which exact certs or chain of certs these addons > have checked/verified. IMHO it would have been even better if at least the one I read was never released to the public. Don't confuse the feature set with the implementation. How do you know they do what they claim to do? Be skeptical of new implementations of security mechanisms (including mine). They need to be thoroughly vetted before they are fit for use by the public. > And if those two addons are further improved for using with > Thunderbird for _993 , _995 , _25 , _465 based services then that > would have been very helpful. Currently those two addons do not > understand those DNS RR. More flawed security code used more broadly is not progress. Yes, there should be multiple implementations, but not very many. Security libraries and plugins need to be written with above average attention to detail and must stand the test of time. The design should be feature complete and generally correct, before any code is written. -- Viktor. From bry8star@inventati.org Tue May 28 22:52:34 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF6321F8F7A for ; Tue, 28 May 2013 22:52:34 -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] 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 F5jQjUPdjyMR for ; Tue, 28 May 2013 22:52:33 -0700 (PDT) Received: from latitanza.investici.org (latitanza.investici.org [IPv6:2002:525e:f9ea::1]) by ietfa.amsl.com (Postfix) with ESMTP id 97A7C21F8F43 for ; Tue, 28 May 2013 22:52:33 -0700 (PDT) Received: from [82.94.249.234] (latitanza [82.94.249.234]) (Authenticated sender: bry8star@inventati.org) by localhost (Postfix) with ESMTPSA id 9BAF1980DD for ; Wed, 29 May 2013 05:52:29 +0000 (UTC) X-DKIM: Sendmail DKIM Filter v2.8.2 latitanza.investici.org 9BAF1980DD DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inventati.org; s=stigmate; t=1369806752; bh=IIYmvMzzk1dWEZg3IpJ8Gw0gdS4sE8YqddPIbdUlgpY=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=JxMkhbMDtSIBV7Dq6JUFzsdqf/SrW0gTsWj4UUUbkVX2O1NXo/JzzxEE2y/UCYqFe Aoq8rEG47gZll32sQZDzQNEwCU/ryccZcvhFXjsja22iXMKa8qKQv1Q7LJ2jV/S46Z JZIcPQnrgkvRmRFpdFl2542bsH5M8sdOtE+tiCTs= Message-ID: <51A5979B.3060409@inventati.org> Date: Tue, 28 May 2013 22:52:27 -0700 From: Bry8 Star User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dane@ietf.org References: <20130525103051.GC12066@lavabit.com> <20130525144214.GD9380@mournblade.imrryr.org> <0lr4gryyn4.fsf@wjh.hardakers.net> <20130528155111.GG9380@mournblade.imrryr.org> <51A55222.7020800@inventati.org> <20130529012949.GR9380@mournblade.imrryr.org> <51A57FE1.2060805@inventati.org> <20130529050008.GS9380@mournblade.imrryr.org> In-Reply-To: <20130529050008.GS9380@mournblade.imrryr.org> X-Enigmail-Draft-Status: 513 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dane] Few questions X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: bry8star@inventati.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 05:52:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 i mentioned, because, in windows side, these are the only choices so far for firefox which at-least can be used easily. So it seems, for windows users, best (and probably only one, current) alternative is : using a VirtualBox or using your own choice of Virtualization software based Linux/Unix VM instance, with a minimal X / GUI / Desktop (LXDE, XFCE, etc), and then doing tests using the Bloodhound web-browser from such VM. - -- Bright Star. Received from Viktor Dukhovni, on 2013-05-28 10:00 PM: > On Tue, May 28, 2013 at 09:11:13PM -0700, Bry8 Star wrote: > > >> I would agree completely, these addons have many more bugs and far >> from perfect. Even in "3 s m" or "2 s m" detection & verification, >> not very consistent yet. > > You are much more charitable to major design and implementation > flaws than I am willing to be. > >> So very likely internal source-codes are tuned for limited TLSA >> cases only. > > Why promote the use implementations that don't even correctly > implement the subset of parameters they set out to support? > >> It would have been great, if those two addons could show cert chain >> or debug info on which exact certs or chain of certs these addons >> have checked/verified. > > IMHO it would have been even better if at least the one I read was > never released to the public. Don't confuse the feature set with > the implementation. > > How do you know they do what they claim to do? Be skeptical of > new implementations of security mechanisms (including mine). They > need to be thoroughly vetted before they are fit for use by the > public. > >> And if those two addons are further improved for using with >> Thunderbird for _993 , _995 , _25 , _465 based services then that >> would have been very helpful. Currently those two addons do not >> understand those DNS RR. > > More flawed security code used more broadly is not progress. > > Yes, there should be multiple implementations, but not very many. > Security libraries and plugins need to be written with above average > attention to detail and must stand the test of time. The design > should be feature complete and generally correct, before any code is > written. > -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJRpZebAAoJEID2ikYfWSP6rhMP/093gh5eCTFV5gpRys0E9ete zL6ht+eYuyn2zlIaPk33WnN9EzZVbnOTgVN4+QiCh+bxcT2wMbAi/RSNgbyHUH0E CxrTULWfFQcqW4rHGUxRvAg2v49FK8Bi/k2uoE8DNflGtvvC13EVh8BmqR54y+6p ytIpIDspoKJs7TYhk6tQ7w/RWdfjuJChbX1bSK1osJoBDp6z4ocp4PnVZyMZiiWd 1iC0S7izPYb6KmIodRRtFMKW2k5VPI9RBfCpbQOG/YqX5MhAKd/bzBeHUrhuIJKY nv9VAAbdmqNrUU9ECxnraTy7VazNTD6MkCnSI8LialOelVV8IeMFDRLatEKF0IH7 YGdqC8RMuz/hTLitTWVLqW8IjsyB4D5Iwxpk/2+rZvVdRth5Fe7ve8k9r1KaHFTs fNksOm2GiR7gpebSNlcSkzdTX0BS5AmQZwcTyi5RIq00+v2NCYM7+uZOgaM1eGyx E1lbdxN7xJSKPWvaR6OukR99A35/jb5ZX9nabqqGFJiescX6XLoO+nzXpYHQJPZM Hwn5poAzP1Uzo8+a8VglmJLpT/VTt4I/zq27o8abShpgdMWVO73y0fWSe3PzWyu1 Rbfqx22mYGT4t5xB2LPekbDwN870dQ/Yn6oXL5p1138GkWtnc7evhTvx4fEWm+sS eCXsKoUyx0ZWJsljj5/J =HFf/ -----END PGP SIGNATURE----- From bry8star@inventati.org Tue May 28 23:32:53 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2565921F8FCB for ; Tue, 28 May 2013 23:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 qH-yY2v8Aefd for ; Tue, 28 May 2013 23:32:52 -0700 (PDT) Received: from latitanza.investici.org (latitanza.investici.org [IPv6:2002:525e:f9ea::1]) by ietfa.amsl.com (Postfix) with ESMTP id 23EBA21F8F83 for ; Tue, 28 May 2013 23:32:51 -0700 (PDT) Received: from [82.94.249.234] (latitanza [82.94.249.234]) (Authenticated sender: bry8star@inventati.org) by localhost (Postfix) with ESMTPSA id 7F50C980A5 for ; Wed, 29 May 2013 06:32:47 +0000 (UTC) X-DKIM: Sendmail DKIM Filter v2.8.2 latitanza.investici.org 7F50C980A5 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inventati.org; s=stigmate; t=1369809170; bh=KPzbgsO+qGgzvgUVsoGsqhSjfjpSYEr8p9SLWA8fRhc=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject:References: In-Reply-To:Content-Type; b=PZyAtAzJMGbdaoMEDR2dTaQwIjQ9EOu+onD1uC+kTteb5MA2Pitwvh+zXRKzgpbR1 eIkUwlUQEFHmFUtNCgFZFtzLuNsJN7Ydz8Vsk2cl7Govb33VVMcnqkudxq1ov3o2nw qGMfJ32MoFGI9Of8z74P5IHWC5YIvDUQM9loM/Ac= Message-ID: <51A5A109.3070409@inventati.org> Date: Tue, 28 May 2013 23:32:41 -0700 From: Bry8 Star User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dane@ietf.org References: <20130525103051.GC12066@lavabit.com> <20130525144214.GD9380@mournblade.imrryr.org> In-Reply-To: <20130525144214.GD9380@mournblade.imrryr.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2KGLJQMMNNEMQTNJKQTWT" Subject: Re: [dane] Few questions X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: bry8star@inventati.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 06:32:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2KGLJQMMNNEMQTNJKQTWT Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In which exact IETF mailing-list or which exact group are doing discussion on SRV rr draft, and on SMTP rr draft ? I think i have seen SMTP rr draft here (in dane@ietf.org), am i wrong ? -- Bright Star. Received from Viktor Dukhovni, on 2013-05-25 7:42 AM: > On Sat, May 25, 2013 at 08:30:52PM +1000, oneofthem wrote: >=20 >> 1. Is DANE finished? Ready to go, rock and roll? >=20 > The TLSA RR has been standardized. What remains to do is to define > how TLSA records are to be used in various application protocols. >=20 > For application protocols that use SRV records there is a draft in prog= ress. > There is another draft for SMTP based on the SRV draft since MX records= > are similar to SRV records. >=20 > I have proposed two recent drafts (see the list archives) that address = in > more detail how applications that can't use the existing public CA PKI > should interact with DANE (in particular SMTP) and also some implicatio= ns > for various corner cases. >=20 > I have also proposed that applications "follow CNAMEs" to derive > the base domain for TLSA records. It remains to be seen whether > this will gain any traction. >=20 > OpenSSL does not yet provide ready-to-use DANE verification code, > so applications based on OpenSSL have to roll their own. This will > change at some point, though I hope in not too soon, since the > required changes are invasive, and need some time for the design > and implementation to be validated. >=20 >> 2. Is it possible for DANE to replace the CA system currently in place= ? >=20 > For server domains that have deployed DNSSEC, and applications > where clients have DNSSEC validating caching resolvers (or have > chosen to embed DNSSEC capable stub-resolvers directly in application > code) it is possible to bypass the existing public CA PKI. >=20 > Just publish TLSA records with usage "3" or perhaps "2", and with > usage "2" make sure to include the TA cert in the server's TLS > handshake certificate chain. >=20 ------enig2KGLJQMMNNEMQTNJKQTWT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJRpaEQAAoJEID2ikYfWSP6GkoP/RPDfgaJGzgWMUt8+QjevaO3 M9fz4Xlid/4JgJtuFp0x0F2MWm2TFYxREpHT3T3weZRwPXQL3Ty/mTuOntzFpjFv nK9BoOQzGu8s3aLRBeDVGNQi8tw/21x+ltBZyP22ww7YfOEbEGcMgGWxXykLLFPV fTQ+RjZej/d2rhLhq61oqNPwVFjB6EwXfZa+saaWm4mz86CcCtWb6BmsV5TDB+qi 8r/fJbKks2120AAdahAFyII1dtLoSiLubNFB/gJCMJFe16TereGwqEHjg7r31zin CMcbVa5mwK+yjNWaxxrMN2nqJeQoXJMo0p0hYwLwPGnGipyn9WiaR+xG7GXRKdRZ 3OpxHZOgDF4NhBmhk9zXb4E8WoV9514eSxIz/yEuJxDyQC4MOfTria8QG1KdVz/N H1Ai5DeCwqYEYWjDTMm6Dm6/zkdfz/BBIp9G2OgNz0iLNUBDsB01OHLzSCVspifD qHSvmNRXNu0peRrihfjhoPAuJzJ00sNF0m/9sGP2KI0qjSxqHy7IHeJ0TK4lS8Cx ZFu6Ha2v8++VnrY+eNKcJj+OGZpW4aaLXv6Fdnl/raXzUUSm9btDl/nkNVgVLdye uvoL+wLtnd3I1XR1BSVVN0gCDZHDqwrTx62Fhub9t6FjqnJRsuceqxXNqrTuhYpR Qpf4VKWKAEMqbYti8dI1 =RO9a -----END PGP SIGNATURE----- ------enig2KGLJQMMNNEMQTNJKQTWT-- From bry8star@inventati.org Wed May 29 02:16:45 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4366921F90F1 for ; Wed, 29 May 2013 02:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 LCAYwUr5+qDa for ; Wed, 29 May 2013 02:16:44 -0700 (PDT) Received: from latitanza.investici.org (latitanza.investici.org [IPv6:2002:525e:f9ea::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A66921F90EE for ; Wed, 29 May 2013 02:16:43 -0700 (PDT) Received: from [82.94.249.234] (latitanza [82.94.249.234]) (Authenticated sender: bry8star@inventati.org) by localhost (Postfix) with ESMTPSA id 2A749980DC for ; Wed, 29 May 2013 09:16:37 +0000 (UTC) X-DKIM: Sendmail DKIM Filter v2.8.2 latitanza.investici.org 2A749980DC DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inventati.org; s=stigmate; t=1369819001; bh=y/PQrQ3ikXbBUshw3u4BTRpy+0Hj9pkAWm5ZNKfdXxM=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject: Content-Type:Content-Transfer-Encoding; b=VfWR81lJVNYvFo7zEteH9o6qgqhAMP7WQn40oz/95teF7IuaGNvCffNfLQX0984Py BUDVdKWyCeGGb+IIgCnk1eI9XAAkZFRBEcffxv/4/Vppcl+HcOQjXOplzYZdJbq5sT ywOOTSA4ITKa1bbJzNMIK0zYHWGK4ciuHpKwGg6w= Message-ID: <51A5C775.7020707@inventati.org> Date: Wed, 29 May 2013 02:16:37 -0700 From: Bry8 Star User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dane@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [dane] How to use TLSA "2 s m", "3 s m" X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: bry8star@inventati.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 09:16:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 How to use TLSA "2 s m" , "3 s m" ? Please correct me anytime, my understanding is: zone/domain-owners/holders can use simple tools like openssl/gnutls, to create their own various types of self-signed private (aka: non-public) CA cert or server certs, and then combine such with DNSSEC + DANE based implementation in DNS records, when basic/simple level of HTTPS/TLS secured web solution/service is expected. For those (above) approaches to work: * domain-owners/holders can, either use TLSA "2 s m" when they want to use their own CA cert and other certs based on that CA cert (these approach is aka : TA, non-public CA cert, self-signed private CA cert, etc), * or, domain-owners/holders can use TLSA "3 s m" when they want to provide a secure service by using a very specific & single server cert from a very specific server (these approach is aka : domain-issued cert, domain cert, EE cert, server cert, no cert chain, etc). Since domain-owner's/holder's self created certificate is not included in any web-browser software, when any visitor/user will try to visit such site/zone securely using HTTPS/TLS encrypted connections, then web-browser will ask/prompt visitors/users with 1 or more questions/messages that if visitor/user wants to load+trust+use that unknown cert from that site or not. cert = certificate , aka = also known as , CA = Certificate Authority , TA = Trust Anchor, EE = end entity. And, when higher level of secured solution is expected AND when extra info are needed to be shown to visitors/users verified by a mutually/known Trusted notarizing/vouching type of party, then TLSA "u s m" would be "0 s m" or "1 s m". These type of cert comes from public CA cert based company, such CA cert are usually pre-included in web-browsers or in client software, and usually these companies charge a fee/money to issue such domain cert or intermediate CA cert. Both of these ("0 s m" , "1 s m") solutions are favored by web-browser developing groups, so they kept it in such a condition that : it will not create any extra warning and it will not ask/prompt visitors/users with a question/message, when a HTTPS/TLS based secured site is visited or web service is used. Since, domain-owner/holder has publicly declared what exact cert he/she/they trusts using TLSA "2 s m" or "3 s m" based dns rr, then why web-browser will ask question/prompt visitor/user ? ! it is not unknown anymore, it is already+clearly declared+known+shown. More practical use cases, guidance are needed to be shown publicly for both "3 s m" and "2 s m" cases, specially for "2 s m" as it involves extra configurations. - - - - - - - - - - - - - - - - - - - - - - - - - - For example, I own 3 domain-names which are related, and want to use a common root CA cert for all these 3 domains/zones, so i did these, as i have 3 set of server computers tuned for 3 different type of tasks, and located in 3 different network locations : Self-signed private non-public root CA cert (My_root_CA_cert) --> intermediate high-strength CA cert (My_i_CA_1_cert) --> dom1.tld_cert --> { www.dom1.tld_cert , m.dom1.tld_cert , mail.dom1.tld_cert , mail2.dom1.tld_cert , ns.dom1.tld_cert , ns2.dom1.tld_cert , livemsg.dom1.tld_cert } and then i created for dom2.tld : intermediate high-strength CA cert (My_i_CA_1_cert) --> dom2.tld_cert --> { www.dom2.tld_cert , m.dom2.tld_cert , mail.dom2.tld_cert , mail2.dom2.tld_cert , ns.dom2.tld_cert , ns2.dom2.tld_cert , livemsg.dom2.tld_cert } and so on. Physical_Server_1 has: * 'www', 'ns' and 'mail' hosts of "dom1.tld" in 3 separate VM instance. * above hosts of "dom2.tld". * above hosts of "dom3.tld". Physical_Server_2 has: * 'm', 'ns2' and 'mail2' hosts of "dom1.tld" in 3 separate VM instance. * above hosts of "dom2.tld". * above hosts of "dom3.tld". Physical_Server_3 has: * 'livemsg' host of "dom1.tld" in a VM instance, * 'livemsg' host of "dom2.tld", * 'livemsg' host of "dom3.tld" "dom1.tld" is for providing certain set of tasks/services/projects 01. "dom2.tld" is for providing another set of tasks/services/projects 02. "dom3.tld" is for providing images, videos, etc and may be placed in another server location. If Physical_Server_01 is restarted or updated or downed or disconnected for some reason, all essential services will be delivered to visitors/users from redundant services from Physical_Server_02. So how many & what DNS RR will "www" host/server for "dom1.tld" will exactly need/have for providing DANE based HTTPS service ? In apache/nginx server software (HTTPS service daemon), in what order it will have to provide those tls/ssl certs ? What else need to be configured ? Thanks in advance, - -- Bright Star. -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJRpcd1AAoJEID2ikYfWSP6a0IP/jnU05dv1SYZ2cALBx1x0klE cYa1OzMPSkZiS04kzTBcu/FH9X0QHKzY4qFDgloV21APRRG/JYEPrhRMgdqERQaK qP5+w91w9lhKNXv1wvkwsPjXuYu7S/ULg1Lco6KeCpcZpssemE/lYuPevnGv+RCF upEJnJq5Fa+xT2bxSmClUvnH3e70n614BwHoh+64a5C03S235AbsauAVy2z0wWg/ lNxbevfUuFr7jzSNb3frvVxr0Dwf53aafRuN2i8T1I0Gj2ss6KqFpdyFbpnWY3GP 9ZIR9UAqL2GgryB6t11rg5SZ3APDc4hFYPo4obhJ7V9JNlTGln3wfvdwQhwwuAzt ayaY3iO9yzUHhIsBYGjPbSmybkvxfdgEpWQ8GHVUwcONk6dajZ28YWCdIG02LF0f 6pGr19MfSF8MJngKYB5FhAFs0HqJ2KieS7ClmJ5GF9gj3Kbl9BKNnCF7HQVY/sMd MRPKYfhytA5+rSjkzorRR2f4lv26wboi9RlONdtJMUru1AH/GsWUcce+myyH+5gN 6mLKXQ+yBJsXgPFBpO2Ofup6Fs4jVEA54YLahcidBkEzEtKGbl5fbAvy5t7S90S5 cwaBzHIAVFFKubd8siCjZfIdr3MRBPblC2Xxdc2vlIoo4qTBA/zXY9yVitNMinYG ISuDUPn39Y3XW5ZsZhpZ =9MYe -----END PGP SIGNATURE----- From suresh@tislabs.com Wed May 29 06:07:03 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D385B21F8F4A for ; Wed, 29 May 2013 06:07:03 -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 KYihHCiuwZhg for ; Wed, 29 May 2013 06:06:58 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) by ietfa.amsl.com (Postfix) with ESMTP id 477F021F8F12 for ; Wed, 29 May 2013 06:06:58 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id CD76728B003A for ; Wed, 29 May 2013 09:06:57 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id A8E621F8032; Wed, 29 May 2013 09:06:57 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Suresh Krishnaswamy In-Reply-To: <20130528195919.GO9380@mournblade.imrryr.org> Date: Wed, 29 May 2013 09:06:57 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8995015F-C273-41BB-83A7-BA7B50BD28D4@tislabs.com> References: <20130525103051.GC12066@lavabit.com> <20130525144214.GD9380@mournblade.imrryr.org> <0lr4gryyn4.fsf@wjh.hardakers.net> <20130528155111.GG9380@mournblade.imrryr.org> <5E8A5A01-3D8B-4FF3-B773-B51D800F4024@tislabs.com> <20130528195919.GO9380@mournblade.imrryr.org> To: dane@ietf.org X-Mailer: Apple Mail (2.1085) Subject: Re: [dane] Few questions X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 29 May 2013 13:07:03 -0000 On May 28, 2013, at 3:59 PM, Viktor Dukhovni wrote: - a number of very useful comments.-=20 Hi Victor, I believe that having multiple independent implementations of TLSA = validation code is "a good thing" in that it allows us to flag and fix = issues early and build more confidence in the code we use down the line. = So your comments in that respect are particularly useful. For the purpose of this list I'll try and summarize the broad problems = that you're flagging with the libval DANE implementation and will = attempt to move the gory details of the implementation to our project = mailing list. Feel free to suggest corrections if I've not captured all = the points you were trying to bring up. 1. There are issues with the usage 2 implementation. Specifically = (paraphrasing what you've said earlier): a) The code is inefficient b) It does not handle "IN TLSA 2 1 0" where only the public key = is in DNS, and the chain omits the corresponding TA certificate. c) if the TLSA record trust anchor is in the middle of the = chain, DANE verification incorrectly fails. d) There needs to be additional name checks on the leaf cert 2. The curl patch is broken with respect to DANE usage 2. I wasn't able to tell if you were pointing out any specific issues with = the implementation for the other usage types, but if there are any I'd = be happy to add them to my list. Thanks! Suresh From viktor1dane@dukhovni.org Wed May 29 07:21:43 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1611621F9017 for ; Wed, 29 May 2013 07:21:43 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Q5qdUnZRGiw for ; Wed, 29 May 2013 07:21:37 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 00DD221F8FDD for ; Wed, 29 May 2013 07:21:36 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 0374C2AABA9; Wed, 29 May 2013 14:21:35 +0000 (UTC) Date: Wed, 29 May 2013 14:21:35 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130529142135.GT9380@mournblade.imrryr.org> References: <20130525103051.GC12066@lavabit.com> <20130525144214.GD9380@mournblade.imrryr.org> <0lr4gryyn4.fsf@wjh.hardakers.net> <20130528155111.GG9380@mournblade.imrryr.org> <5E8A5A01-3D8B-4FF3-B773-B51D800F4024@tislabs.com> <20130528195919.GO9380@mournblade.imrryr.org> <8995015F-C273-41BB-83A7-BA7B50BD28D4@tislabs.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8995015F-C273-41BB-83A7-BA7B50BD28D4@tislabs.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Few questions X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 14:21:43 -0000 On Wed, May 29, 2013 at 09:06:57AM -0400, Suresh Krishnaswamy wrote: > For the purpose of this list I'll try and summarize the broad > problems that you're flagging with the libval DANE implementation > and will attempt to move the gory details of the implementation to > our project mailing list. Feel free to suggest corrections if I've > not captured all the points you were trying to bring up. > > 1. There are issues with the usage 2 implementation. Specifically > (paraphrasing what you've said earlier): > a) The code is inefficient > b) It does not handle "IN TLSA 2 1 0" where only the public key > is in DNS, and the chain omits the corresponding TA certificate. > c) if the TLSA record trust anchor is in the middle of the chain, > DANE verification incorrectly fails. > d) There needs to be additional name checks on the leaf cert a). The inefficiency increases the number of public-key signature verification operations performed on the peer's chain. Not generally a big deal, but can be a problem. More importantly the application callback is now invoked multiple times for the same chain, and we don't know what state it accumulates, whether it logs errors, ... so the "contract" between the OpenSSL library and the application changes. Another inefficiency is that the matching routine is passed a DER encoded cert even when the TLSA selector is for a public key, it then decodes the DER cert, extracts a key and DER encodes that. This should be handled "upstairs", with the match routine given the right DER object to (optionally digest) and compare. b). Also "2 0 0" fails, because the provided certificate may only be in DNS and not in the peer's chain. The "0 1 0" and "0 0 0" cases work only because OpenSSL's verification check during the handshake (see inefficiency above) augments that chain to include any missing root CA. c). Here also all usage 0 cases fail when the TLSA RR specifies a non-root certificate (see above about augmented chain). d). Yes, it is best to perform name checks on the leaf cert with 0/2 comparing against at least the base TLSA domain, but applications should be able to provide a list of names (see the Tony Finch SRV draft which specifies two names). This does not punt name checks to the application and simplifies the return logic. > 2. The curl patch is broken with respect to DANE usage 2. Because the application skips name checks, and for the complex case of "2 1 0". And usage 0 with a non-root CA TLSA RR. You could choose to not support "2 1 0" without the matching certificate in the peer's chain. There is no clear language covering this in RFC 6698. In Postfix I chose to implement "2 1 0" support because I expect some servers to get this wrong, and I did not want to punish them for their ignorance. Since it is possible to make it work, I did. If my operational guidance draft gets adopted, perhaps this and similar issues will be more clear to server operators. It is not yet clear whether client implementations are obligated to deal with "2 1 0" without a matching certificate on the wire in the server's TLS handshake. > I wasn't able to tell if you were pointing out any specific issues > with the implementation for the other usage types, but if there > are any I'd be happy to add them to my list. I may have missed some, your design review (see below) should uncover these. > I believe that having multiple independent implementations of > TLSA validation code is "a good thing" in that it allows us to flag > and fix issues early and build more confidence in the code we use > down the line. So your comments in that respect are particularly > useful. It is good to have early implementations, that are not yet mature with respect to field testing, ... I do however believe that design errors should not be present even at this stage. Field testing should not be needed to shake out design errors. I found the issues I reported by reading the code, not by running it. Were the code in production there would need to be a security advisory. This is not necessary. While my comment about more implementations not being progress was inspired much more by the clearly incomplete design of the Firefox plugin, which was a college project. I do encourage you do go through all the use-cases, write down the verification requirements, then read the source code of OpenSSL's X509_verify_cert() in crypto/x509/x509_vfy.c. Having understood how the legacy verification process works, what errors it detects and reports to the application callback and in what order, you are ready to design an extension that implements DANE verification. - Consider the "2 0 0" and "2 1 0" edge cases, where the full certificate or public key is provided via DNS and may not appear on the wire in TLS. - Consider the "2 [01] [12]" edge cases where the full cert or key is not in DNS, and also may not be in TLS, document that server operators must provide the TA key or else verification fails. - Consider the "2 1 1" use cases where after trust chain verification completes, though PKIX verifiction relative to the existing public CA PKI is not required, name checks are still required to make the peer has the right certificate issued by the trust anchor. Compare with "3 1 1" where a TLSA record match is definitive, and no name checks apply (in fact the certificate may have an empty sequence for its subject DN). This has implications for API design. Either the DANE verification API takes care of name checks (and perhaps also PKIX checks for 0/1), or it needs to report multiple success states: - with/without name checks required - with/without PKIX ckecks with public CA PKI required Failure with all TLSA RRs unusable is different from failure with some usable, but none matched (see the SRV draft). The existing public CA PKI is not compatible with some application protocols (see my drafts recently posted to this list). A library implementing DANE should likely support these, in which case it may need to provide controls (flags, ...) to treat some types of TLSA RRs as unusable and/or to ignore PKIX requirements by treating 0/1 as 2/3 respectively. These are all design issues that must be considered before code is first released to the public. Some early code may be written to explore the space in aid of fleshing out the design, but code should not be released until the design is complete. -- Viktor. From viktor1dane@dukhovni.org Wed May 29 07:37:20 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C952721F8B07 for ; Wed, 29 May 2013 07:37:20 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oWKCjRZRGZcT for ; Wed, 29 May 2013 07:37:15 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 28E0821F8CEC for ; Wed, 29 May 2013 07:37:11 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id BC5F62AABA9; Wed, 29 May 2013 14:37:10 +0000 (UTC) Date: Wed, 29 May 2013 14:37:10 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130529143710.GV9380@mournblade.imrryr.org> References: <51A5C775.7020707@inventati.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51A5C775.7020707@inventati.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] How to use TLSA "2 s m", "3 s m" X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 14:37:21 -0000 On Wed, May 29, 2013 at 02:16:37AM -0700, Bry8 Star wrote: > How to use TLSA "2 s m" , "3 s m" ? > > Please correct me anytime, my understanding is: > > zone/domain-owners/holders can use simple tools like openssl/gnutls, > to create their own various types of self-signed private (aka: > non-public) CA cert or server certs, and then combine such with > DNSSEC + DANE based implementation in DNS records, when basic/simple > level of HTTPS/TLS secured web solution/service is expected. > > For those (above) approaches to work: > > * domain-owners/holders can, either use TLSA "2 s m" when they want > to use their own CA cert and other certs based on that CA cert > (these approach is aka : TA, non-public CA cert, self-signed private > CA cert, etc), In which case they'd better make sure that the server's certificate chain (sent during the TLS handshake) includes the TA certificate, because the verifier can't be expected to have a copy. Naive implementations may not even handle 2 0 0 correctly. > * or, domain-owners/holders can use TLSA "3 s m" when they want to > provide a secure service by using a very specific & single server > cert from a very specific server (these approach is aka : > domain-issued cert, domain cert, EE cert, server cert, no cert > chain, etc). This is the most robust use case. The name in the certificate should not matter, but naive implementations may perform erroneous name checks here, so if possible include the TLSA RR base domain as a DNS subjectAltName in the peer certificate. > Since domain-owner's/holder's self created certificate is not > included in any web-browser software, when any visitor/user will try > to visit such site/zone securely using HTTPS/TLS encrypted > connections, then web-browser will ask/prompt visitors/users with 1 > or more questions/messages that if visitor/user wants to > load+trust+use that unknown cert from that site or not. Until browsers support DANE. Browser support for DANE should be reasonably common before HTTPS servers (serving the public at large) start employing usage 2/3 certificates that are not valid with respect to the existing public CA PKI. > And, when higher level of secured solution is expected AND when > extra info are needed to be shown to visitors/users verified by a > mutually/known Trusted notarizing/vouching type of party, then TLSA > "u s m" would be "0 s m" or "1 s m". These type of cert comes from > public CA cert based company, such CA cert are usually pre-included > in web-browsers or in client software, and usually these companies > charge a fee/money to issue such domain cert or intermediate CA cert. IMHO the public CA PKI is irreparably broken, and provides little additional assurance. There is little reason to public 0/1 or even 2 when 3 is substantially more robust. > Both of these ("0 s m" , "1 s m") solutions are favored by > web-browser developing groups, so they kept it in such a condition > that : it will not create any extra warning and it will not > ask/prompt visitors/users with a question/message, when a HTTPS/TLS > based secured site is visited or web service is used. No, all that's required is that during the transition your certificates are still issued by a public CA that non DANE aware clients can verify. There is no reason to public 0/1 when 3 matches the same certificate. I expect that browsers will support all the usages. > Since, domain-owner/holder has publicly declared what exact cert > he/she/they trusts using TLSA "2 s m" or "3 s m" based dns rr, then > why web-browser will ask question/prompt visitor/user ? ! They should not, and I expect will not, once they support DANE. -- Viktor. From ch@psw.net Wed May 29 11:22:53 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38D5321F9007 for ; Wed, 29 May 2013 11:22: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdp6lMj4q3hk for ; Wed, 29 May 2013 11:22:47 -0700 (PDT) Received: from vm2710.psw.net (vm2710-2.psw.net [217.24.222.125]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC7E21F95DC for ; Wed, 29 May 2013 11:22:45 -0700 (PDT) Received: from vm2710.psw.net (localhost [127.0.0.1]) by vm2710.psw.net (Postfix) with ESMTP id 6526D4FE1F for ; Wed, 29 May 2013 20:22:38 +0200 (CEST) Received: from psw39.psw.net (psw39.psw.net [62.216.172.60]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by vm2710.psw.net (Postfix) with ESMTPS id 3763E4FE1E for ; Wed, 29 May 2013 20:22:38 +0200 (CEST) Received: from vs34980a.psw.mx (vs34980a.psw.mx [81.20.84.203]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by psw39.psw.net (Postfix) with ESMTP id 1A182CE9BE for ; Wed, 29 May 2013 20:22:38 +0200 (CEST) From: Christian Heutger To: "dane@ietf.org" Thread-Topic: [dane] How to use TLSA "2 s m", "3 s m" Thread-Index: AQHOXE1HPkVIgW05/02JFrGhf/A1wpkcGd4AgABgfwA= Date: Wed, 29 May 2013 18:22:32 +0000 Message-ID: In-Reply-To: <20130529143710.GV9380@mournblade.imrryr.org> Accept-Language: de-DE, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 X-TBoneOriginalFrom: Christian Heutger X-TBoneOriginalTo: "dane@ietf.org" X-TBoneDomainSigned: false MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="----A60BB622A3B9C9E6A2188DFAFE03B9D6" Subject: Re: [dane] How to use TLSA "2 s m", "3 s m" X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 29 May 2013 18:22:53 -0000 This is an S/MIME signed message ------A60BB622A3B9C9E6A2188DFAFE03B9D6 Content-Language: de-DE Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Hi, >IMHO the public CA PKI is irreparably broken, and provides little >additional assurance. There is little reason to public 0/1 or even >2 when 3 is substantially more robust. in my opinion, CA PKI model get hardened / recent issues fixed with DANE but DANE is not able to replace it by sense. See below. >>Since, domain-owner/holder has publicly declared what exact cert >> he/she/they trusts using TLSA "2 s m" or "3 s m" based dns rr, then >> why web-browser will ask question/prompt visitor/user ? ! > >They should not, and I expect will not, once they support DANE. Finally DANE can replace the so called domain validation certificates as how ever a domain control may be proofed when by a certificate stored in the DNS. However the pressure to renew certificates (and generating new private keys), limited validity of a certificate and additional third party check of revocation status (especially if the webmaster and hostmaster is not the same and there is a need of quick reaction) are open topics. But public certs beside the encryption and domain binding topic have another reason: a third party proof the website owners existence, legal name, address, depend on the certificate a minimum of 3 years doing business etc. So finally DANE can't prevent from Phishing (similar domains), can't prevent from unknown business partners, =8A That still requires someone verifying identity and warrantying for the job done. DANE can ensure here, that this certificate is the real one and it's not been "rewritten" by anyone else. Regards, Christian ------A60BB622A3B9C9E6A2188DFAFE03B9D6 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIIOgYJKoZIhvcNAQcCoIIIKzCCCCcCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3 DQEHAaCCBX0wggV5MIIEYaADAgECAhEAjvkMSfywKjIsvYKwPMSxXzANBgkqhkiG 9w0BAQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0 ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNl Y3VyZSBFbWFpbCBDQTAeFw0xMjEyMDMwMDAwMDBaFw0xNTEyMDMyMzU5NTlaMIGT MQ4wDAYDVQQHEwVGdWxkYTEPMA0GA1UECBMGSGVzc2VuMQswCQYDVQQGEwJERTEa MBgGA1UEAxMRQ2hyaXN0aWFuIEhldXRnZXIxCjAIBgNVBAsTAS0xIDAeBgNVBAoU F1BTVyBHUk9VUCBHbWJIICYgQ28uIEtHMRkwFwYJKoZIhvcNAQkBFgpjaEBwc3cu bmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1jWSXXiV2jUEn/9v Ciu0XjjHkb7GoLu4fqX76UIrgL6CMuj5NHxII9MaxLHE/okdtPE3uF46Xxs+dqlf /bGIWhlzSQ+M7GBcGjhkynagMnfPx+rr6JJsNEkBivkFYEFwYs5E7uA0+EfM2zmc 0J1NKBNwYAWxoGatnfCAkIFVG/b1MnQgRinau3ZVveto2iX1JTV0WPBdXwM7w/PR c4ybPAuY4k1TEXfnoyG2614Ov7N0s6kKKd2gBBCqvNdOpWMO36zIZe9/r1LYPnrN bgbz/XJmvvkUTf+okHuvZJ4o+XFGEOOa3bSirMgQJXwKB29cyEmcmlCgDF3gDnIV qpV9+QIDAQABo4IBxDCCAcAwHwYDVR0jBBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5 xXswHQYDVR0OBBYEFCUdN0WVp5HFhAsP3QPh+taSjcRAMA4GA1UdDwEB/wQEAwIF oDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjBG BgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1odHRwczov L3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8v Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl Y3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0 dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNv bW9kb2NhLmNvbTAVBgNVHREEDjAMgQpjaEBwc3cubmV0MA0GCSqGSIb3DQEBBQUA A4IBAQB2tp2OEKCRwDWsHjGPMzbN98s+FJdHKqVBA7uwut80O/ui8/eGI/8kh0TN vlPSIGun3mOGrOMcdjNleNwU+yH2mM1KCod3Wryq1wvP7brKLlChWLieHaBUfilw j8rRWBMOCULR0oxYwjArDUiEaRXli0Q6Hw8QiFzNYRaHTPH0GN9ERqpauzkFgE/u Vb7t7OHOVHJaAOhVfB/AtADkB794j2RIaSGnMmfhHEPA0DChOy8v4UC+uF48VoqA E05zv6JngbN9gpRj+uzjTzV7K7P6spfoTeywqXtEMJIP6BxHp3RHfcPPxyiDySSL 5S2U6wKo3CsAbhfnoZgBCw/Ogv+BMYIChTCCAoECAQEwgakwgZMxCzAJBgNVBAYT AkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8g Q2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCO+QxJ /LAqMiy9grA8xLFfMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNTI5MTgyMjM4WjAjBgkqhkiG9w0BCQQx FgQU7/CHs/EASN4fB4UaFbPGufJz0CQwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAahlGu3NDX6n6/iFVIJCUt2CD Wkt7plxin0vFjXg5vQJqojH70g6S19Jitrn6DPLfHa/gTScxT4HOUIBEXLwIGQKD fMQTw6fIDydXIg8Aes/iHVmvXF6OVdDMJeXe8Dli425i048Cg6PqY002JLKpkhrU AdyEFJlj7r5poaK4hPLRjPPvBizHIhLOnlbvI6xMY85PWchU2H0DiEEqYD7My3/q IYd+q5PF+AALMG9YGG/MvNEtOQgMWjX4fX2j5ThgyYk3xItaEEztp70fBn6My10G /DpUUsANWjmipT4284uq0EL45azxTbfS/KORpnDxW/D08IJWNTQ0eF/t70hYZA== ------A60BB622A3B9C9E6A2188DFAFE03B9D6-- From viktor1dane@dukhovni.org Wed May 29 11:46:01 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F4DC21F8EB1 for ; Wed, 29 May 2013 11:46:01 -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 u+Xced6w4Za2 for ; Wed, 29 May 2013 11:45:56 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id C43E921F90F4 for ; Wed, 29 May 2013 11:45:55 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 18E312AABB3; Wed, 29 May 2013 18:45:55 +0000 (UTC) Date: Wed, 29 May 2013 18:45:55 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130529184555.GY9380@mournblade.imrryr.org> References: <20130529143710.GV9380@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] How to use TLSA "2 s m", "3 s m" X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 18:46:01 -0000 On Wed, May 29, 2013 at 06:22:32PM +0000, Christian Heutger wrote: > >> Since, domain-owner/holder has publicly declared what exact cert > >> he/she/they trusts using TLSA "2 s m" or "3 s m" based dns rr, then > >> why web-browser will ask question/prompt visitor/user ? ! > > > >They should not, and I expect will not, once they support DANE. > > Finally DANE can replace the so called domain validation certificates as > how ever a domain control may be proofed when by a certificate stored in > the DNS. We should not debate the merits and demerits of various PKI models here. The OP's question was about browser behaviour, and my comment on the existing public CA PKI was mostly irrelevant personal opinion, intended to justify the expectation that browsers will not only support certificate usage 0/1 to the exclusion of 2/3. Since browsers accept DV certs today, they most likely will also support DANE validated certs when they implement DANE. I would expect Mozilla, Chrome, IE, ... to eventually include native reasonably well designed DANE implementations without the need for third-party plugins. It is important that this happens, so if any of you can influence browser vendors in that direction, do it! [ Additional security beyond DV might be gained in the context of DANE via new TLDs where membership policies provide appropriate assurance against brand confusion. Let's not get distracted by this issue, it is largely off topic. ] -- Viktor. From viktor1dane@dukhovni.org Wed May 29 12:28:43 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10F1221F90C3 for ; Wed, 29 May 2013 12:28:41 -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 EY4HiiTjIGZ9 for ; Wed, 29 May 2013 12:28:33 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 70EC921F96C6 for ; Wed, 29 May 2013 12:28:32 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D2F7C2AABB3; Wed, 29 May 2013 19:28:31 +0000 (UTC) Date: Wed, 29 May 2013 19:28:31 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130529192831.GA9380@mournblade.imrryr.org> References: <20130525103051.GC12066@lavabit.com> <20130525144214.GD9380@mournblade.imrryr.org> <0lr4gryyn4.fsf@wjh.hardakers.net> <20130528155111.GG9380@mournblade.imrryr.org> <5E8A5A01-3D8B-4FF3-B773-B51D800F4024@tislabs.com> <20130528195919.GO9380@mournblade.imrryr.org> <8995015F-C273-41BB-83A7-BA7B50BD28D4@tislabs.com> <20130529142135.GT9380@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130529142135.GT9380@mournblade.imrryr.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Few questions X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 19:28:44 -0000 On Wed, May 29, 2013 at 02:21:35PM +0000, Viktor Dukhovni wrote: > Having understood how the legacy verification process works, what > errors it detects and reports to the application callback and in > what order, you are ready to design an extension that implements > DANE verification. One more design consideration is a choice of where DNSSEC validation takes place. The application should be free to use any DNSSEC validating library of its choice, and then provide validated TLSA records to the library. The library may provide a mechanism to find and validate TLSA records, but this should be optional, and should try to avoid compatibility constraints on the application (DLL hell) caused by linking to additional third-party (not bundled with the base platform) libraries. The proposed OpenSSL implementation attempts to deal with this by dynamically loading (rather than linking with) libunbound, but this brings in its own issues since libunbound links to OpenSSL 1.0.x, which makes it difficult to test with OpenSSL 1.1.0-dev. By far the simplest choice is to rely on the system libresolv and delegate DNSSEC validation to the local (ideally 127.0.0.1) nameserver. This is what Postfix does, and I believe OpenSSL should do. Applications that want to validate each time they make a DNS request via their own trust anchor, can link to a suitable library of their choice and pass their own TLSA RRs for DANE verification. Thus OpenSSL should only (directly) support DNSSEC via libresolv, and should encourage applications that use untrusted remote DNS caches to link to whatever validating DNS library they see fit. -- Viktor. From Rick_Andrews@symantec.com Wed May 29 19:24:34 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA60121F937B for ; Wed, 29 May 2013 19:24:34 -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 uAnrj7HdW8Kz for ; Wed, 29 May 2013 19:24:28 -0700 (PDT) Received: from tus1smtoutpex01.symantec.com (tus1smtoutpex01.symantec.com [216.10.195.241]) by ietfa.amsl.com (Postfix) with ESMTP id 9F6A621F9355 for ; Wed, 29 May 2013 19:24:28 -0700 (PDT) X-AuditID: d80ac3f1-b7fa16d000002315-a8-51a6b85ba007 Received: from ecl1mtahubpin01.ges.symantec.com (ecl1mtahubpin01.ges.symantec.com [10.48.69.201]) by tus1smtoutpex01.symantec.com (Symantec Brightmail Gateway out) with SMTP id 49.42.08981.B58B6A15; Thu, 30 May 2013 02:24:28 +0000 (GMT) Received: from [155.64.220.139] (helo=TUS1XCHHUBPIN03.SYMC.SYMANTEC.COM) by ecl1mtahubpin01.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1UhsXT-0007gS-F5 for dane@ietf.org; Thu, 30 May 2013 02:24:27 +0000 Received: from TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM ([155.64.220.146]) by TUS1XCHHUBPIN03.SYMC.SYMANTEC.COM ([155.64.220.139]) with mapi; Wed, 29 May 2013 19:24:27 -0700 From: Rick Andrews To: "dane@ietf.org" Date: Wed, 29 May 2013 19:24:25 -0700 Thread-Topic: [dane] How to use TLSA "2 s m", "3 s m" Thread-Index: Ac5cnMgiuUTjE8c6TJW6RN9zsernCAAPwmfA Message-ID: <544B0DD62A64C1448B2DA253C011414607ACD1048F@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> References: <20130529143710.GV9380@mournblade.imrryr.org> <20130529184555.GY9380@mournblade.imrryr.org> In-Reply-To: <20130529184555.GY9380@mournblade.imrryr.org> 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 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnkeLIzCtJLcpLzFFi42LhMnA9qRuzY1mgweLJzBZ7jk9kdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtafP5kLtrBVvLr8lbmBsZu1i5GTQ0LARGLNnp1sELaYxIV7 64FsLg4hgXeMEhdPT2eGcP4xStw6sBfKWcUoseHgdyaQFjYBPYktj6+wg9giAsoSW6/vBIpz cLAIqEo8vG0FEhYG2vDmwCVGiBJTiV3L+5ggbCOJSzu2gtm8AlESbx8eYIGY38Io8WZtF1gD p4CVxPNtb8HmMwKd9/3UGrAGZgFxiVtP5jNBnC0gsWTPeWYIW1Ti5eN/rBD1ohJ32tczQtTr SCzY/YkNwtaWWLbwNTPEYkGJkzOfsExgFJuFZOwsJC2zkLTMQtKygJFlFaNMSWmxYXFuSX5p SUFqhYGhXnFlbiIwcpL1kvNzNzECo+cG1+GPOxivL1U8xCjAwajEw/to5bJAIdbEMqDKQ4wS HMxKIrxrtIFCvCmJlVWpRfnxRaU5qcWHGKU5WJTEeb92TQ8UEkhPLEnNTk0tSC2CyTJxcEo1 MMr7vZrHWcTZF60WseLI6Zvlu8JNN5ll3QtbmfW+PWdKA+N337/z5prIeqaaOJ7eUjFzgk1Z lZq6S9bfib/ifrlFrTLZyLnneEKClqjIvcDToQmeR8W3vHpUF96/MHTpuyS/rU+3SB181+hr xqv+xrvzkHghD3P2Xilfc4Ylc2e3f0rWWDHrvRJLcUaioRZzUXEiANDaRh+aAgAA Subject: Re: [dane] How to use TLSA "2 s m", "3 s m" X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 May 2013 02:24:35 -0000 > -----Original Message----- > We should not debate the merits and demerits of various PKI models > here. The OP's question was about browser behaviour, and my comment > on the existing public CA PKI was mostly irrelevant personal opinion, > intended to justify the expectation that browsers will not only > support certificate usage 0/1 to the exclusion of 2/3. Viktor, Is there another list that's right for discussing the merits and demerits o= f the different DANE options? I work for a CA, so of course I believe that = the current PKI is *not* irreparably broken, nor do I agree that modes 2 an= d 3 are "substantially more robust". Because I believe your voice is respec= ted in this forum, I wanted to speak up to make it clear that this opinion = is not shared by all. -Rick Andrews=20 From viktor1dane@dukhovni.org Wed May 29 20:02:09 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF2B621F92B2 for ; Wed, 29 May 2013 20:02:09 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Vi8+1KjDCVJ for ; Wed, 29 May 2013 20:02:04 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id C56BE21F928C for ; Wed, 29 May 2013 20:02:03 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id E34AF2AABB3; Thu, 30 May 2013 03:02:02 +0000 (UTC) Date: Thu, 30 May 2013 03:02:02 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130530030202.GB9380@mournblade.imrryr.org> References: <20130529143710.GV9380@mournblade.imrryr.org> <20130529184555.GY9380@mournblade.imrryr.org> <544B0DD62A64C1448B2DA253C011414607ACD1048F@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <544B0DD62A64C1448B2DA253C011414607ACD1048F@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] How to use TLSA "2 s m", "3 s m" X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 03:02:10 -0000 On Wed, May 29, 2013 at 07:24:25PM -0700, Rick Andrews wrote: > > -----Original Message----- > > We should not debate the merits and demerits of various PKI models > > here. The OP's question was about browser behaviour, and my comment > > on the existing public CA PKI was mostly irrelevant personal opinion, > > intended to justify the expectation that browsers will not only > > support certificate usage 0/1 to the exclusion of 2/3. > > Viktor, > > Is there another list that's right for discussing the merits and > demerits of the different DANE options? I work for a CA, so of > course I believe that the current PKI is *not* irreparably broken, > nor do I agree that modes 2 and 3 are "substantially more robust". > Because I believe your voice is respected in this forum, I wanted > to speak up to make it clear that this opinion is not shared by > all. You have little to worry about. There's plenty of disagreement all around, and I am a relative newcomer here, whatever respect I may have earned here is limited in scope. I expect my drafts will prove a tough sell on various points. I think we can all agree that my answer to the OP's question about browser support for 2/3 is not controversial. -- Viktor. P.S. [ Explanation of personal views, not intended to change anyone's mind. ] My concerns with respect certificate usages 0, 1 (and even 2) are rather pragmatic. Security systems that generate too many false positives (false alarms of something wrong) and require users to "click OK" to get past the annoying FPs ultimately fail to protect users, even when the false negative rate is lower than with competing systems. My view is that a system with fewer FPs is better even if it has more FNs, provided these are in balance. Pulling numbers out of thin air (not to be taken as carefully considered values), I'd prefer a system with 0.01% FPs and 0.01% FNs over one with 5% FPs and 0.00002% FNs. The point being that with a 5% FP rate, the user won't believe the verdict even when the system detects a real problem. In implementing DANE support for Postfix, I've found that usage 3 is by far the easiest to implement correctly for both the verifying client and the verified server. All the other use cases exhibit subtleties that make FPs (verification failures with no actual MITM in sight) more likely. With public CAs this includes incomplete list of CAs on the client side, problems with CRLs, ... And I don't buy the FN story for public CAs since there are so many of them one needs to trust to avoid FPs. With email reliable/timely delivery generally outweighs security considerations, MTAs are store and forward, there is no user to click OK, so high FP rates are simply unacceptable. The KISS principle leads me to conclude that with SMTP usage "3" wins over all the others. There are other reasons I dislike the public CA PKI, but I don't bring particularly relevant expertise to those topics beyond what others have said many times in the past. From jakob@kirei.se Thu May 30 00:37:30 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C55E21F96EA for ; Thu, 30 May 2013 00:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[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 YG22RJ1d8kSc for ; Thu, 30 May 2013 00:37: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 CC04221F96E9 for ; Thu, 30 May 2013 00:37:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:content-type:mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=a6tvDU0hoWta2lnEEeka3LbVoXmjvasWtrZwd1DfeXI=; b=yn+3KogNIXYIhk+CER0cCHzrvNjnxXpOlCGu0BG/8Kh7Ljr0ISwuh3/QLe1pojAW8VDH8ZUcXpQG4 q0EWQaDP+FjEOS2pMG3JCJOf5iyEV2LrnQkiF+d8I74QSq4aPzm8VxW9ElJzstk9xrYtzibdED0zK1 xXoQbqQqweSd3kNQ= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Thu, 30 May 2013 09:37:22 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jakob Schlyter In-Reply-To: <544B0DD62A64C1448B2DA253C011414607ACD1048F@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Date: Thu, 30 May 2013 09:37:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130529143710.GV9380@mournblade.imrryr.org> <20130529184555.GY9380@mournblade.imrryr.org> <544B0DD62A64C1448B2DA253C011414607ACD1048F@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> To: Rick Andrews X-Mailer: Apple Mail (2.1503) Cc: "dane@ietf.org" Subject: [dane] Classic PKI and DANE in harmony X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 May 2013 07:37:30 -0000 On 30 maj 2013, at 04:24, Rick Andrews = wrote: > Is there another list that's right for discussing the merits and = demerits of the different DANE options? I work for a CA, so of course I = believe that the current PKI is *not* irreparably broken, nor do I agree = that modes 2 and 3 are "substantially more robust". Because I believe = your voice is respected in this forum, I wanted to speak up to make it = clear that this opinion is not shared by all. Unless the chairs do not object, I believe this mailing list is a good = place to discuss this matters. IMHO, classic PKI augmented by DANE would be a very strong package. = However, I would argue that without the extra identity proofing and = other controls set by by Extended Validation (EV), DANE has equally = security properties to a plain Domain Validation (DV) certificate. For a foreseeable future, we definitely need to combine DANE with = classic PKI in order for the general Internet user to be able to = validate certificates. For limited deployments, or applications where = classic PKI has not yet gained significant traction (such as TLS for = SMTP), a pure DANE solution makes sense (unless EV is required). jakob From ch@psw.net Thu May 30 01:09:53 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B4F421F97FC for ; Thu, 30 May 2013 01:09: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zaFNWwaAe5oQ for ; Thu, 30 May 2013 01:09:39 -0700 (PDT) Received: from vm2710.psw.net (vm2710-2.psw.net [217.24.222.125]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9D121F9802 for ; Thu, 30 May 2013 01:09:39 -0700 (PDT) Received: from vm2710.psw.net (localhost [127.0.0.1]) by vm2710.psw.net (Postfix) with ESMTP id 72E404FE1C; Thu, 30 May 2013 10:09:37 +0200 (CEST) Received: from psw39.psw.net (psw39.psw.net [62.216.172.60]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by vm2710.psw.net (Postfix) with ESMTPS id 28AF44FE17; Thu, 30 May 2013 10:09:37 +0200 (CEST) Received: from vs34980a.psw.mx (vs34980a.psw.mx [81.20.84.203]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by psw39.psw.net (Postfix) with ESMTP id 10EE0CE9BE; Thu, 30 May 2013 10:09:37 +0200 (CEST) From: Christian Heutger To: Jakob Schlyter Thread-Topic: [dane] Classic PKI and DANE in harmony Thread-Index: AQHOXQia1isxSa947UuU2cjP4UipMpkdX/sA Date: Thu, 30 May 2013 08:09:36 +0000 Message-ID: In-Reply-To: Accept-Language: de-DE, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 X-TBoneOriginalFrom: Christian Heutger X-TBoneOriginalTo: Jakob Schlyter X-TBoneOriginalCC: "dane@ietf.org" X-TBoneDomainSigned: false MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="----307325157261481CD0C452B802ADF180" Cc: "dane@ietf.org" Subject: Re: [dane] Classic PKI and DANE in harmony X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 May 2013 08:09:53 -0000 This is an S/MIME signed message ------307325157261481CD0C452B802ADF180 Content-Language: de-DE Content-Type: text/plain; charset="us-ascii" Content-ID: <680b663d-f638-41cc-a707-5ff65d945ca3> Content-Transfer-Encoding: quoted-printable Hi Jakob, I support your point of view, however domain validation also has some advantages with public certificates over DANE. The requirement for renewing (create new private key), the instant revoke with CRL and OCSP (against caching DNS) but finally also to aware against hackers and spammers. So if you look at DANE, everyone can run a valid site with https and e.g. spread malware through that as often https traffic is not scanned and usually be trusted, like recent mentioned phishing attacks. In addition with SMTP over TLS running mail servers, the assumption would be, that it is a valid mail server. If everyone can go with SMTP over TLS, giving more trust to valid SMTP connections will be undergone. Regards, Christian=20 Am 30.05.13 09:37 schrieb "Jakob Schlyter" unter : >On 30 maj 2013, at 04:24, Rick Andrews wrote: > >> Is there another list that's right for discussing the merits and >>demerits of the different DANE options? I work for a CA, so of course I >>believe that the current PKI is *not* irreparably broken, nor do I agree >>that modes 2 and 3 are "substantially more robust". Because I believe >>your voice is respected in this forum, I wanted to speak up to make it >>clear that this opinion is not shared by all. > >Unless the chairs do not object, I believe this mailing list is a good >place to discuss this matters. > >IMHO, classic PKI augmented by DANE would be a very strong package. >However, I would argue that without the extra identity proofing and other >controls set by by Extended Validation (EV), DANE has equally security >properties to a plain Domain Validation (DV) certificate. > >For a foreseeable future, we definitely need to combine DANE with classic >PKI in order for the general Internet user to be able to validate >certificates. For limited deployments, or applications where classic PKI >has not yet gained significant traction (such as TLS for SMTP), a pure >DANE solution makes sense (unless EV is required). > > jakob > >_______________________________________________ >dane mailing list >dane@ietf.org >https://www.ietf.org/mailman/listinfo/dane > >-- >This message was scanned by ESVA and is believed to be clean. > ------307325157261481CD0C452B802ADF180 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIIOgYJKoZIhvcNAQcCoIIIKzCCCCcCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3 DQEHAaCCBX0wggV5MIIEYaADAgECAhEAjvkMSfywKjIsvYKwPMSxXzANBgkqhkiG 9w0BAQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0 ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNl Y3VyZSBFbWFpbCBDQTAeFw0xMjEyMDMwMDAwMDBaFw0xNTEyMDMyMzU5NTlaMIGT MQ4wDAYDVQQHEwVGdWxkYTEPMA0GA1UECBMGSGVzc2VuMQswCQYDVQQGEwJERTEa MBgGA1UEAxMRQ2hyaXN0aWFuIEhldXRnZXIxCjAIBgNVBAsTAS0xIDAeBgNVBAoU F1BTVyBHUk9VUCBHbWJIICYgQ28uIEtHMRkwFwYJKoZIhvcNAQkBFgpjaEBwc3cu bmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1jWSXXiV2jUEn/9v Ciu0XjjHkb7GoLu4fqX76UIrgL6CMuj5NHxII9MaxLHE/okdtPE3uF46Xxs+dqlf /bGIWhlzSQ+M7GBcGjhkynagMnfPx+rr6JJsNEkBivkFYEFwYs5E7uA0+EfM2zmc 0J1NKBNwYAWxoGatnfCAkIFVG/b1MnQgRinau3ZVveto2iX1JTV0WPBdXwM7w/PR c4ybPAuY4k1TEXfnoyG2614Ov7N0s6kKKd2gBBCqvNdOpWMO36zIZe9/r1LYPnrN bgbz/XJmvvkUTf+okHuvZJ4o+XFGEOOa3bSirMgQJXwKB29cyEmcmlCgDF3gDnIV qpV9+QIDAQABo4IBxDCCAcAwHwYDVR0jBBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5 xXswHQYDVR0OBBYEFCUdN0WVp5HFhAsP3QPh+taSjcRAMA4GA1UdDwEB/wQEAwIF oDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjBG BgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1odHRwczov L3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8v Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl Y3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0 dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNv bW9kb2NhLmNvbTAVBgNVHREEDjAMgQpjaEBwc3cubmV0MA0GCSqGSIb3DQEBBQUA A4IBAQB2tp2OEKCRwDWsHjGPMzbN98s+FJdHKqVBA7uwut80O/ui8/eGI/8kh0TN vlPSIGun3mOGrOMcdjNleNwU+yH2mM1KCod3Wryq1wvP7brKLlChWLieHaBUfilw j8rRWBMOCULR0oxYwjArDUiEaRXli0Q6Hw8QiFzNYRaHTPH0GN9ERqpauzkFgE/u Vb7t7OHOVHJaAOhVfB/AtADkB794j2RIaSGnMmfhHEPA0DChOy8v4UC+uF48VoqA E05zv6JngbN9gpRj+uzjTzV7K7P6spfoTeywqXtEMJIP6BxHp3RHfcPPxyiDySSL 5S2U6wKo3CsAbhfnoZgBCw/Ogv+BMYIChTCCAoECAQEwgakwgZMxCzAJBgNVBAYT AkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8g Q2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCO+QxJ /LAqMiy9grA8xLFfMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNTMwMDgwOTM3WjAjBgkqhkiG9w0BCQQx FgQUb7kyhdMdhaCG+TkzuZo5T4K3r+owUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAKH/BVYMFUpw91NLlALYI3Yok nqubkh/+g31k9g18/ak7uxJvT6LsDL3Uymf2Er4hLJTtjO2UGJ1vjSNYThox5KTm QwQs7+Li9hYgcFEwItXtLTcJoxf1bPeUn6xc0DvjP1ENZ2Yi1ffiBha88XjSd2oj g9gfJXmZ/SyZiOnrEuuKCcJsYbBzuZ3nc2EyXH7Z7j6QSxn6EA1HaOdCHTp5xnbe 0DapTcaUgNwOAPOKEH3ZrkUYoorIp8FpCpGUWBDb2H93gs6J/5XmHI4dWJyG7kov 5dfd8/bF7p/5SFxs+/e61h/asy9/gbfqjXa2/Z/NFpk9+u9SWW4FObyyD6sMBw== ------307325157261481CD0C452B802ADF180-- From olaf@NLnetLabs.nl Thu May 30 03:03:28 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9049221F96CF for ; Thu, 30 May 2013 03:03:28 -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, HTML_MESSAGE=0.001, 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 Xu-SHIhnk1Wz for ; Thu, 30 May 2013 03:03:27 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id A724121F96CE for ; Thu, 30 May 2013 03:03:26 -0700 (PDT) Received: from [IPv6:2001:7b8:206:1:7211:24ff:fe8c:627a] ([IPv6:2001:7b8:206:1:7211:24ff:fe8c:627a]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.7/8.14.4) with ESMTP id r4UA3MoL058191 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 30 May 2013 12:03:23 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) Authentication-Results: open.nlnetlabs.nl; dmarc=none header.from=NLnetLabs.nl DKIM-Filter: OpenDKIM Filter v2.8.2 open.nlnetlabs.nl r4UA3MoL058191 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1369908204; bh=Uco7i3Fg1df+Bq2jccleHt+qDsAJb7CI7eXOzqT7Zr8=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=kVkDlMV38gf6yP/7yJEd2A7m+y6DzfVlDyc7XUmJIFVyxwi09LsqDfP/chR8DyoWM leR7W1yVVvDDcy145RorkGlMnTKInEegODPw3SpIrdmS3dYXSiolNMtY+X0WMdAa6e FDZ/kE3uvadBO2UWrtnqZ+pe7cNNBhh367ZLIS/4= Content-Type: multipart/alternative; boundary="Apple-Mail=_E8BB424B-1C56-465A-B44F-464EA847A46B" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Olaf Kolkman In-Reply-To: Date: Thu, 30 May 2013 12:03:22 +0200 Message-Id: <65F77DB9-E63C-4D73-AAFC-6339811A8D34@NLnetLabs.nl> References: <20130529143710.GV9380@mournblade.imrryr.org> <20130529184555.GY9380@mournblade.imrryr.org> <544B0DD62A64C1448B2DA253C011414607ACD1048F@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> To: Jakob Schlyter X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Thu, 30 May 2013 12:03:23 +0200 (CEST) Cc: "dane@ietf.org" Subject: Re: [dane] Classic PKI and DANE in harmony X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 May 2013 10:03:28 -0000 --Apple-Mail=_E8BB424B-1C56-465A-B44F-464EA847A46B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 30, 2013, at 9:37 AM, Jakob Schlyter wrote: > On 30 maj 2013, at 04:24, Rick Andrews = wrote: >=20 >> Is there another list that's right for discussing the merits and = demerits of the different DANE options? I work for a CA, so of course I = believe that the current PKI is *not* irreparably broken, nor do I agree = that modes 2 and 3 are "substantially more robust". Because I believe = your voice is respected in this forum, I wanted to speak up to make it = clear that this opinion is not shared by all. >=20 > Unless the chairs do not object, I believe this mailing list is a good = place to discuss this matters. >=20 > IMHO, classic PKI augmented by DANE would be a very strong package. = However, I would argue that without the extra identity proofing and = other controls set by by Extended Validation (EV), DANE has equally = security properties to a plain Domain Validation (DV) certificate. >=20 > For a foreseeable future, we definitely need to combine DANE with = classic PKI in order for the general Internet user to be able to = validate certificates. For limited deployments, or applications where = classic PKI has not yet gained significant traction (such as TLS for = SMTP), a pure DANE solution makes sense (unless EV is required). +1 !!! --Olaf=20= --Apple-Mail=_E8BB424B-1C56-465A-B44F-464EA847A46B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii jakob@kirei.se> wrote:

On 30 maj 2013, at 04:24, = Rick Andrews <> wrote:



For a foreseeable future, we = definitely need to combine DANE with classic PKI in order for the = general Internet user to be able to validate certificates. For limited = deployments, or applications where classic PKI has not yet gained = significant traction (such as TLS for SMTP), a pure DANE solution makes = sense (unless EV is required).
In-Reply-To: Date: Thu, 30 May 2013 12:13:36 +0200 Message-Id: References: To: Christian Heutger X-Mailer: Apple Mail (2.1503) Cc: "dane@ietf.org" Subject: Re: [dane] Classic PKI and DANE in harmony X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 May 2013 10:13:49 -0000 --Apple-Mail=_31C8C35B-DCD9-4A74-A962-4F3DA0481896 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 30 maj 2013, at 10:09, Christian Heutger wrote: > I support your point of view, however domain validation also has some > advantages with public certificates over DANE. The requirement for > renewing (create new private key), the instant revoke with CRL and = OCSP > (against caching DNS) but finally also to aware against hackers and > spammers. So if you look at DANE, everyone can run a valid site with = https > and e.g. spread malware through that as often https traffic is not = scanned > and usually be trusted, like recent mentioned phishing attacks. In > addition with SMTP over TLS running mail servers, the assumption would = be, > that it is a valid mail server. If everyone can go with SMTP over TLS, > giving more trust to valid SMTP connections will be undergone. The additional services you mention are optional and not part of = WebTrust and/or ETSI certifications. There is no guarantee that such = services are performed on services served under a classic PKI = certificate. Regarding revocation we've seen too many examples where CRLs are not = checked properly by the clients and/or OCSP responders are not = responding (or responding so slow that users disable them). This might = not be how the PKI infrastructure was designed, but it is the reality. Anyone can do SMTP with TLS today and most (sane) mail servers do that. = Without classic PKI. And the SMTP servers they talk to do no validation = whatsoever. DANE can only make things better here. jakob --Apple-Mail=_31C8C35B-DCD9-4A74-A962-4F3DA0481896 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMmDCCBTcw ggMfoAMCAQICAwD8bDANBgkqhkiG9w0BAQUFADBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwG A1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290 MB4XDTEyMDYwMzE5MTgyOVoXDTEzMDYwMzE5MTgyOVowazELMAkGA1UEBhMCU0UxETAPBgNVBAcT CEdvdGVib3JnMREwDwYDVQQKEwhLaXJlaSBBQjEXMBUGA1UEAxMOSmFrb2IgU2NobHl0ZXIxHTAb BgkqhkiG9w0BCQEWDmpha29iQGtpcmVpLnNlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEA0fPL1331N8n0urnmz7IHyNVUOYapIJx/y1BVWuQUBiGl6SmylIxnnWQhk1dSJWD224zaoSf5 ey1B44wI1vA5olSy0xx8QXrXUCxyLYXPAlDYBJruFJRH+Wc0tXOKgdUrEDDPpmTrPtkTLm8CkK8f IfpolHNn4DipfeMcnBrTTLRNV3tZOMp25yCKevppX/GE9fK8a8MRnEf4q2aZN0uf1rycaYRrSSsr cp9mn3A8dBwv+X/V/u9PYYkX/yUhiSOjcdux7a0x0yZyARlNs54Bg5BAJDwneer92mVsW///Txp7 9DQOxFAXS7/bV7MNV2wmI4sdgYedk7SpsY3OCM2W2QIDAQABo4H6MIH3MAwGA1UdEwEB/wQCMAAw VgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFk IG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEF BQcDAgYKKwYBBAGCNwoDBAYKKwYBBAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAi BggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzAZBgNVHREEEjAQgQ5qYWtvYkBraXJl aS5zZTANBgkqhkiG9w0BAQUFAAOCAgEAMOWwip4KhQthaGrMTHn11iU6yWWVwUFOAPuR8EaCOxBT 7dLURbff7xHhM4ui2YsuWzCF78zpNKekWVYjg+YaJ4B3Gd0nm5dFXQhJDztns2D2XxQZA1p2+zaQ 5lnWAbyhTHj8F/uPXSe0OkCPIYZ7eEFCzznXerKxPRJWMP3paK6J/TYqmIpl7/79OhUOTUCCyMh2 5JFwtTz/90E6TwhdZK/K4W4UlrbM+t8P4xuLgDDueOs98RT/xiZketFOOZiQWxZ6vQEJoYrE7lPO aT9SPNJTaobP+SuKbHv/lVf33Ljca7D9XEZc8sSImgPcV7Y0q3U006Cin36kfP9NkBMExB84+BkP RSgv/Sp3uGYxVhGAmNOuJhOsMUFT1PAhiQAESjclkcYTjaNrMj7uaoHt2v0i5FE9Uhs5Dpy0//Mf SKfWmBWz0Sz3MIENt6QbIhpi2FDswdjGS+IGNuL+r5AcB9titC+1C0I0/aVTu2tsLEdHFLXki4Th S4ZY8Hx3dnxLz86EyhHtm2yyOywsUOLW5ttxIpv+r8YdGCz9Ki8q+lubBnhyY2kFtYAuyA9qrJL/ 7U9PMF8XI9WIpydpCEkT5Pdx0p0uOMnD+c2UNAXo3QMzBWl8dU+cLIPtm/1PgxigffZaqGee0wEa d/7k4fpd1N/tJPk6c9DzPy4ALl9kzsowggdZMIIFQaADAgECAgMKQYowDQYJKoZIhvcNAQELBQAw eTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYD VQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNh Y2VydC5vcmcwHhcNMTEwNTIzMTc0ODAyWhcNMjEwNTIwMTc0ODAyWjBUMRQwEgYDVQQKEwtDQWNl cnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNlcnQg Q2xhc3MgMyBSb290MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAq0k1EUh80iZ+U5TP Q6ndKNdCKovzh3gZWHwPntqJfeH763KQDXShlmSrn6AkmXPa4lV2xxd79QSsRrjDvn9kjRBsJPNh nMDykPpR5vVpAWPDD1biSkLP4kSMJSioxXkJfUa5ivPp8zQpCEXkHJ/LlAQcgagUs5hlxEPsToKN CdG9qluNktDs3pDFfwrC4+vmMVpedD6XM1nowwM9YDO/99FvR8TN7mKDUm4uCJqk2RUYkaaFkkew rkjrbbch7IUaaHI1q//wEF3A9JSnatU7kn5MkAV+k8Esi6SOYnQVcW4LcQPqrxU4mtTSBXJvjPkr 61pyJfk5RuNyGz4Ew2QnIhAqik9YpwOtvrQuE+1dqkjX1X3UKntc+kYEUOTMDkJbjO3b8s/8lpPg 2xE2VGI0OI8MYJs7l1Y4rfPSW4ugW+pOlrh819WghnBA05Ept6I8rfWMu88akorkNHvA2Gxf6QrC w6cgmlrfLF1SXLpH1ZvvJChwOCAv1X8pwLJBA2iSzOCczJdLRe86EAqrcDqYlXCtNbHqhSukHIAh MamuYHqAJkgAuAHAk2NVIpE8Vuev2zol848xVOomi4FZ+aHRUxHFe50D9nQR4G2xLD8shpGZcZqm d4s0YNEUtCysna+MENOfxGr4bxP8c1n3ZkJ0Horj+NzSb5icy0eYlUAF++kCAwEAAaOCAg0wggIJ MB0GA1UdDgQWBBR1qHFgTIgT8HjZiXe1bcWJ37yxejCBowYDVR0jBIGbMIGYgBQWtTIb1Mfz4OaO 873SsDrusjkY0aF9pHsweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5j YWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcN AQkBFhJzdXBwb3J0QGNhY2VydC5vcmeCAQAwDwYDVR0TAQH/BAUwAwEB/zBdBggrBgEFBQcBAQRR ME8wIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLkNBY2VydC5vcmcvMCgGCCsGAQUFBzAChhxodHRw Oi8vd3d3LkNBY2VydC5vcmcvY2EuY3J0MEoGA1UdIARDMEEwPwYIKwYBBAGBkEowMzAxBggrBgEF BQcCARYlaHR0cDovL3d3dy5DQWNlcnQub3JnL2luZGV4LnBocD9pZD0xMDA0BglghkgBhvhCAQgE JxYlaHR0cDovL3d3dy5DQWNlcnQub3JnL2luZGV4LnBocD9pZD0xMDBQBglghkgBhvhCAQ0EQxZB VG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFLCBnbyB0byBodHRwOi8vd3d3LkNB Y2VydC5vcmcwDQYJKoZIhvcNAQELBQADggIBACkoha5EqbmvpHkT8KijK5dg81zu4y/B9uJmoBGu Njc6dhUEU+pC9fnqwBXYpoLZ5GGucgspXJBD6EGy4XfbAhNEeEdVr1j8zJj2RbnRIPjYIQf+bapz 1LPGB+kJhcw78ra+LBwl1XGMObUu6r4Ygbqwk7gP4+bXJowxWnIDhFLmpvUzIkUKyAsNirg2b5AJ oau919VOLnGi1K76p1Qr6zWNWrdUiC/udJ/tSBbKDUjQlNOspKL2JN+S473rQ0CRbhwYjla0ghLz qZOf1LycrZx17lqXG5XndC0cD7Asl5/7qTM5eucDOpKOIvaMDeTZfg12GPcB+e+WlqJVc8A8cbQd GlZDt8MKjXL84hAJC0HOjJSg+QP9cXNLilcz5Y50fhUBAObMShznf5UZLcWlDIu7te2Fs1zT37i5 8srHDQEUrHBYxYyNM9SdZqMaUJUj/EjgBkMS2c2nhjkvNnKjgBDk4fPRy1sawOSAmnwTcwZP26Nr JAq6sxy8Sni75eN1OKVIp6Ier3bUXvc4hlZaic7Ww6d5slKgxvGFtCWM8j+WsxDZjWxXO59vhjoY giI2yLCRONsqoZOqhD/1J2Wuc9XI1dN36kudx0G7x8DjoD/kfaSNc+YSS9+hc3NzOoDo1cuOL8vq E6fWQYus+jyJ1yT1TrTgYZK38zeYxL6Wo7eKMYICvTCCArkCAQEwWzBUMRQwEgYDVQQKEwtDQWNl cnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNlcnQg Q2xhc3MgMyBSb290AgMA/GwwCQYFKw4DAhoFAKCCATcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTMwNTMwMTAxMzM3WjAjBgkqhkiG9w0BCQQxFgQUUn2zKR7GmEWs vqMSXffT0Y32gMkwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwG A1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290 AgMA/GwwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQL ExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAwD8 bDANBgkqhkiG9w0BAQEFAASCAQC8TeZHr9YmfZWgYw5B59jEJVT1tNlLzlEQaifE+qeCEn+UVO1V W1Wt/oWTf72GEM7PMttyYkOI9Ly+smk25gNnVqjUevi5hdx5ni1RGCKAZ2PBrTD5hHBtM0gZ2A6I AItRa8BNFCmzMYaQAhYzKrT0jxu358RSSvwkI/xlADiB2HqiQzwajSyYfbcDWni27NgUBODjL+7b 5h6cdnfnlBVeMD2Ms2iqq0MTkwDWDVVdYcO1YIf+tVqgISR9KUhEJfih+AdRDKggKYVSfLguCNQl JdZ0hAwXOgQJj9vcpB4/NAtU4/hjoCTT0o1voOGX6bDTwgmea36fME3A7mncN+8vAAAAAAAA --Apple-Mail=_31C8C35B-DCD9-4A74-A962-4F3DA0481896-- From tom@ritter.vg Thu May 30 04:33:37 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1935621F9579 for ; Thu, 30 May 2013 04:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, 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 ncbLHpI3QsCJ for ; Thu, 30 May 2013 04:33:35 -0700 (PDT) Received: from mail-pb0-x230.google.com (mail-pb0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 9D2E321F955E for ; Thu, 30 May 2013 04:33:33 -0700 (PDT) Received: by mail-pb0-f48.google.com with SMTP id md4so186055pbc.7 for ; Thu, 30 May 2013 04:33:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=L6Hvnpo9brJS4/pqMpeXD+wgaMWR4+zSkMiwjinH+pI=; b=upEWpDVRLtruyqfuLEpXTc9QlKZl0vu6Mh4KFOw+fyXuyjWIhuv44GGlSv9exxGxOw vgAZf1r+4z7JFYvCAkn4hrs6vmGh/50uBJVZqUU/Xo2F1v33i3U4m0N3vmRLGuSfS164 Shu1c6TM8IM9cio2d0g1sNmWzrkxNYEa0eNFg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=L6Hvnpo9brJS4/pqMpeXD+wgaMWR4+zSkMiwjinH+pI=; b=OsSZGBos/sxcrED+2mr7guXn9GT/e6zEAJRvAIoo1Cghoz0+WLkWAXtOwxnJw9Zo1Y PpNs0591QRGV7p4YpPGOEf7aiHkCwhQ538DkNBYnn45planYHqJGsaZ5P0JGxWFsOgQP G2qpMeNOqyV0sJ3QIhFcuin9kEdfh7ta4cbqjcFB3sn0wGFmK6qDFZuuhUrCjHOgJD3d cGdmjx6fxTvNGsE5lHTd6l7AwpvYGV1UMRYSyV0aOKwc89OH7X8EFSazR0WnJG5PKLUF C3HTHIHe5ggErfuH/ye8/uQpe1AYf0ZkJqma1t+SdBISsfAIY/BEZMO/RrifNC3vl5Uw ERwA== X-Received: by 10.66.231.7 with SMTP id tc7mr7923848pac.143.1369913613375; Thu, 30 May 2013 04:33:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.121.11 with HTTP; Thu, 30 May 2013 04:33:13 -0700 (PDT) In-Reply-To: References: From: Tom Ritter Date: Thu, 30 May 2013 07:33:13 -0400 Message-ID: To: Christian Heutger Content-Type: multipart/alternative; boundary=047d7b111d034c76fc04ddeddeb8 X-Gm-Message-State: ALoCoQl1rkPrbQLD5gyGKWU1KCwVv20W3FFORZ9oPuin/Q0u/yWWTVTeUB0qffFZclBn/IWo1d9J Cc: "dane@ietf.org" Subject: Re: [dane] Classic PKI and DANE in harmony X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 May 2013 11:33:37 -0000 --047d7b111d034c76fc04ddeddeb8 Content-Type: text/plain; charset=ISO-8859-1 I don't disagree with the idea that CAs+DANE provides a greater barrier for HTTPS domain impersonation than just DANE. But... On 30 May 2013 04:09, Christian Heutger wrote: > the instant revoke with CRL and OCSP > (against caching DNS) I don't agree with this. Revocation through TTL expiry on a domain can provide the same revocation delay as CRLs and OCSP. CRLs have a "window of replay" up to a week, OCSP from 6 hours to a day (usually). TTLs are in the same ballpark, and are configurable. > like recent mentioned phishing attacks. As part of my job I run phishing attacks on companies, fairly regularly. While most CAs do a decent job of protecting against the highest-profile domains, obtaining a DV cert for the other 99.9% of companies is never a problem. A long lived or extremely popular phishing attack may get detected in time to protect some users, but a single-day or two-operation does not. This is an advantage of CAs, but not a large one due to the lack of protections supplied for 99.9% of companies, the fact that all CAs are trusted equally so I can go to the weakest one, and that there is a natural desire for CAs to issue certificates fast and only flag certificates for manual review if absolutely necessary. > In > addition with SMTP over TLS running mail servers, the assumption would be, > that it is a valid mail server. If everyone can go with SMTP over TLS, > giving more trust to valid SMTP connections will be undergone. > PKIX Validation + SMTP is all sorts of wonky. I'm just throwing it out there ;) On 30 May 2013 03:37, Jakob Schlyter wrote: > Unless the chairs do not object, I believe this mailing list is a good > place to discuss this matters. I'll occasionally join in if the consensus is to allow this type of discussion, but unless it's directly related to a standard we're working on or implementing, I don't really think this type of conversation is productive at this point. These arguments and debates have been hashed and rehashed over and over. There is a difference of opinion, and people feel strongly on both sides. Civil discussion is fine, but a lot of people are tired of the topic, so the level of civility and interest is decreasing - making the conversations less enlightening as time goes on. -tom --047d7b111d034c76fc04ddeddeb8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I don't disagree with the idea that CAs+DAN= E provides a greater barrier for HTTPS domain impersonation than just DANE.= =A0But...

On 30 May 2013 04:09, Christian Heutger <ch@psw.ne= t> wrote:
the = instant revoke with CRL and OCSP
(against caching DNS)

I don't ag= ree with this. =A0Revocation through TTL expiry on a domain can provide the= same revocation delay as CRLs and OCSP. =A0CRLs have a "window of rep= lay" up to a week, OCSP from 6 hours to a day (usually). =A0TTLs are i= n the same ballpark, and are configurable.
=A0
like recent mentioned phishing attacks.

As part of my job I run phishing attacks on compa= nies, fairly regularly. =A0While most CAs do a decent job of protecting aga= inst the highest-profile domains, obtaining a DV cert for the other 99.9% o= f companies is never a problem. =A0A long lived or extremely popular phishi= ng attack may get detected in time to protect some users, but a single-day = or two-operation does not. =A0This is an advantage of CAs, but not a large = one due to the lack of protections supplied for 99.9% of companies, the fac= t that all CAs are trusted equally so I can go to the weakest one, and that= there is a natural desire for CAs to issue certificates fast and only flag= certificates for manual review if absolutely necessary. =A0
=A0
In
addition with SMTP over TLS running mail servers, the assumption would be,<= br> that it is a valid mail server. If everyone can go with SMTP over TLS,
giving more trust to valid SMTP connections will be undergone.

PKIX Validation + SMTP is all sorts of wonky.= =A0I'm just throwing it out there ;)


--047d7b111d034c76fc04ddeddeb8-- From Rick_Andrews@symantec.com Thu May 30 04:59:17 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B21A21F9354 for ; Thu, 30 May 2013 04:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_24=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 e4PmuRZcKzk8 for ; Thu, 30 May 2013 04:59:11 -0700 (PDT) Received: from ecl1mtaoutpex02.symantec.com (ecl1mtaoutpex02.symantec.com [166.98.1.210]) by ietfa.amsl.com (Postfix) with ESMTP id B8A0021F9371 for ; Thu, 30 May 2013 04:59:10 -0700 (PDT) X-AuditID: a66201d2-b7f2b6d000005658-aa-51a73f0d6901 Received: from ecl1mtahubpin02.ges.symantec.com (ecl1mtahubpin02.ges.symantec.com [10.48.69.202]) by ecl1mtaoutpex02.symantec.com (Symantec Brightmail Gateway out) with SMTP id C6.31.22104.D0F37A15; Thu, 30 May 2013 11:59:09 +0000 (GMT) Received: from [155.64.220.138] (helo=TUS1XCHHUBPIN02.SYMC.SYMANTEC.COM) by ecl1mtahubpin02.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1Ui1Vc-0007vX-U0; Thu, 30 May 2013 07:59:09 -0400 Received: from TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM ([155.64.220.146]) by TUS1XCHHUBPIN02.SYMC.SYMANTEC.COM ([155.64.220.138]) with mapi; Thu, 30 May 2013 04:58:29 -0700 From: Rick Andrews To: Jakob Schlyter , Christian Heutger Date: Thu, 30 May 2013 04:58:26 -0700 Thread-Topic: [dane] Classic PKI and DANE in harmony Thread-Index: Ac5dHpYtL9qN4vkVRTyP/jM9Sbt8WQAC6zaA Message-ID: <544B0DD62A64C1448B2DA253C011414607ACD10519@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> References: In-Reply-To: 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 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKIsWRmVeSWpSXmKPExsXCZeB6SpfXfnmgwd6FrBZ316xjtdhzfCKr xaX5/SwOzB5Llvxk8nh07Rm7R8exvewBzFFcNimpOZllqUX6dglcGe3H57EU3JKrOPfwDmMD 43WJLkZODgkBE4nFLyezQthiEhfurWfrYuTiEBJ4xyix7ctcJgjnFaPEsZ6trBDOKkaJe7+e s4G0sAnoSWx5fIUdxBYRcJZ4feEeWJxZQFni0uK/YGNZBFQlPi5bABTn4BAWMJZoOMMNUW4i cez3VBYI20ji8p97TCAlvAJREkc32oKEhQQiJB5PXsIEYnMK2Ei0nXoGZjMCHfr91BomiE3i EreezGeCeEBAYsme88wQtqjEy8f/WCHqRSXutK9nhKjXkViw+xPUldoSyxa+BqvnFRCUODnz CcsERvFZSMbOQtIyC0nLLCQtCxhZVjHKpCbnGOaWJOaXlhSkVhgY6RVX5iYCoy5ZLzk/dxMj MPKWJTFe2sF4/7DuIUYBDkYlHt7LVssDhVgTy4AqDzFKcDArifAqmACFeFMSK6tSi/Lji0pz UosPMUpzsCiJ8wapTQ0UEkhPLEnNTk0tSC2CyTJxcEo1MDJoh15iv6K0xrQ++Xfuu86lovtD //W0R35U77p9vPgUe8G2yXZxktXfyixPaqWc9T7f/jxI8tAMJ8N9l7i7/iUp/VFvO5xxriGw pPao2Z9jlyXnFOhf5Myym7DnR8QMp0TNbbpWf9fYPPgjFfu9+/Cq/cHlPPEHA54/WaBy50f7 3kk9GedEziuxFGckGmoxFxUnAgAAnVMOuAIAAA== Cc: "dane@ietf.org" Subject: Re: [dane] Classic PKI and DANE in harmony X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 May 2013 11:59:17 -0000 > On 30 maj 2013, at 10:09, Christian Heutger wrote: >=20 > > I support your point of view, however domain validation also has some > > advantages with public certificates over DANE. The requirement for > > renewing (create new private key), the instant revoke with CRL and > > OCSP (against caching DNS) but finally also to aware against hackers > > and spammers. So if you look at DANE, everyone can run a valid site > > with https and e.g. spread malware through that as often https > traffic > > is not scanned and usually be trusted, like recent mentioned phishing > > attacks. In addition with SMTP over TLS running mail servers, the > > assumption would be, that it is a valid mail server. If everyone can > > go with SMTP over TLS, giving more trust to valid SMTP connections > will be undergone. >=20 > The additional services you mention are optional and not part of > WebTrust and/or ETSI certifications. There is no guarantee that such > services are performed on services served under a classic PKI > certificate. It seems that there are enough differences between PKI use in SMTP and SSL/= TLS that we should probably separate them for discussion. I'm most familiar= with SSL. The services you mention are not entirely optional. SSL certs mu= st be frequently renewed (the max validity period is being reduced over the= next few years thanks to CA/Browser Forum requirements). IIS requires you = to generate a new key pair when you renew. CRLs and OCSP responses are upda= ted when a certificate is revoked. > Regarding revocation we've seen too many examples where CRLs are not > checked properly by the clients and/or OCSP responders are not > responding (or responding so slow that users disable them). This might > not be how the PKI infrastructure was designed, but it is the reality. Things have been improving here. Several CAs have moved to or are consideri= ng moving to Content Distribution Networks (CDNs) for their CRLs and/or OCS= P responses, which provide very low latency and very high availability. I h= ope browser vendors will reevaluate their behavior with respect to revocati= on as the situation improves. Browsers that don't check CRLs properly shoul= d address this problem in their implementations. I would say for SSL at least, a DV cert from a public CA is superior to DAN= E without PKIX validation (DANE modes 2 and 3) because: - The DV cert will conform to Baseline Requirements (minimum key size, stro= ng signing and hashing algorithm, acceptable validity period, proper extens= ions) - The DV cert would be very likely to have undergone automated checks for w= eak keys, weak exponents, not on Debian weak key list, not on internal phis= h lists, etc. - The DV cert would contain AIA and/or CDP extensions, so if the CA detects= that the site is fraudulent, it can revoke the cert. - The CA issuing the cert would have undergone a WebTrust or ETSI audit. Au= dits aren't perfect, but I feel strongly that the threat of failing and aud= it makes CAs pay more attention to detail. If I create my own self-signed SSL certificate, I can give it a 30-year val= idity, use MD2 or MD5, include a Debian weak key, add no basicConstraints e= xtension or have CA=3Dtrue. Such practices put my site and my users at risk= . > Anyone can do SMTP with TLS today and most (sane) mail servers do that. > Without classic PKI. And the SMTP servers they talk to do no validation > whatsoever. DANE can only make things better here. I'm not familiar with SMTP. I wonder if both ends of the connection do prop= er chain validation and checks for the particular cert that is expected? Ha= s anyone attempted MITM attacks against mail servers to see if they can be = tricked? If they're not doing "classic PKI", it may be trivial to spoof one= end of an SMTP connection and cause all kinds of trouble. -Rick=20 From ch@psw.net Thu May 30 05:13:30 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 308BD21F8E6E for ; Thu, 30 May 2013 05:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_24=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 RyPwfnsNqXGA for ; Thu, 30 May 2013 05:13:24 -0700 (PDT) Received: from vm2710.psw.net (vm2710-2.psw.net [217.24.222.125]) by ietfa.amsl.com (Postfix) with ESMTP id C06C821F8CB4 for ; Thu, 30 May 2013 05:13:22 -0700 (PDT) Received: from vm2710.psw.net (localhost [127.0.0.1]) by vm2710.psw.net (Postfix) with ESMTP id CDC214FE17; Thu, 30 May 2013 14:13:20 +0200 (CEST) Received: from psw39.psw.net (psw39.psw.net [62.216.172.60]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by vm2710.psw.net (Postfix) with ESMTPS id 4B53F4FE14; Thu, 30 May 2013 14:13:20 +0200 (CEST) Received: from vs34980a.psw.mx (vs34980a.psw.mx [81.20.84.203]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by psw39.psw.net (Postfix) with ESMTP id 401B5CE9BE; Thu, 30 May 2013 14:13:20 +0200 (CEST) From: Christian Heutger To: Rick Andrews , Jakob Schlyter Thread-Topic: [dane] Classic PKI and DANE in harmony Thread-Index: AQHOXR5Y1isxSa947UuU2cjP4UipMpkdfjgAgAAlrgA= Date: Thu, 30 May 2013 12:13:18 +0000 Message-ID: In-Reply-To: <544B0DD62A64C1448B2DA253C011414607ACD10519@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Accept-Language: de-DE, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 X-TBoneOriginalFrom: Christian Heutger X-TBoneOriginalTo: Rick Andrews , Jakob Schlyter X-TBoneOriginalCC: "dane@ietf.org" X-TBoneDomainSigned: false MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="----672E30A5D4AC7283B763FB491D47DE6D" Cc: "dane@ietf.org" Subject: Re: [dane] Classic PKI and DANE in harmony X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 May 2013 12:13:30 -0000 This is an S/MIME signed message ------672E30A5D4AC7283B763FB491D47DE6D Content-Language: de-DE Content-Type: text/plain; charset="us-ascii" Content-ID: <7e1f0159-e0e0-4d43-a1b2-c8330cad1b1f> Content-Transfer-Encoding: quoted-printable Thanks Rick, there need to be added, that for Usage 2 there also rises up the issue, on how secure the "own CA" is. CAs pay huge amounts to keep their infrastructure secure, like Hardware Key Modules, like Offline-Signing etc. So with Usage 2 the own CA can be everything, from an online CA, storing the private key in the public accessible webroot, enabling everyone who recognized it to issue certs for the domain by himself. Am 30.05.13 13:58 schrieb "Rick Andrews" unter : >> On 30 maj 2013, at 10:09, Christian Heutger wrote: >>=20 >> > I support your point of view, however domain validation also has some >> > advantages with public certificates over DANE. The requirement for >> > renewing (create new private key), the instant revoke with CRL and >> > OCSP (against caching DNS) but finally also to aware against hackers >> > and spammers. So if you look at DANE, everyone can run a valid site >> > with https and e.g. spread malware through that as often https >> traffic >> > is not scanned and usually be trusted, like recent mentioned phishing >> > attacks. In addition with SMTP over TLS running mail servers, the >> > assumption would be, that it is a valid mail server. If everyone can >> > go with SMTP over TLS, giving more trust to valid SMTP connections >> will be undergone. >>=20 >> The additional services you mention are optional and not part of >> WebTrust and/or ETSI certifications. There is no guarantee that such >> services are performed on services served under a classic PKI >> certificate. > >It seems that there are enough differences between PKI use in SMTP and >SSL/TLS that we should probably separate them for discussion. I'm most >familiar with SSL. The services you mention are not entirely optional. >SSL certs must be frequently renewed (the max validity period is being >reduced over the next few years thanks to CA/Browser Forum requirements). >IIS requires you to generate a new key pair when you renew. CRLs and OCSP >responses are updated when a certificate is revoked. > >> Regarding revocation we've seen too many examples where CRLs are not >> checked properly by the clients and/or OCSP responders are not >> responding (or responding so slow that users disable them). This might >> not be how the PKI infrastructure was designed, but it is the reality. > >Things have been improving here. Several CAs have moved to or are >considering moving to Content Distribution Networks (CDNs) for their CRLs >and/or OCSP responses, which provide very low latency and very high >availability. I hope browser vendors will reevaluate their behavior with >respect to revocation as the situation improves. Browsers that don't >check CRLs properly should address this problem in their implementations. > >I would say for SSL at least, a DV cert from a public CA is superior to >DANE without PKIX validation (DANE modes 2 and 3) because: >- The DV cert will conform to Baseline Requirements (minimum key size, >strong signing and hashing algorithm, acceptable validity period, proper >extensions) >- The DV cert would be very likely to have undergone automated checks for >weak keys, weak exponents, not on Debian weak key list, not on internal >phish lists, etc. >- The DV cert would contain AIA and/or CDP extensions, so if the CA >detects that the site is fraudulent, it can revoke the cert. >- The CA issuing the cert would have undergone a WebTrust or ETSI audit. >Audits aren't perfect, but I feel strongly that the threat of failing and >audit makes CAs pay more attention to detail. > >If I create my own self-signed SSL certificate, I can give it a 30-year >validity, use MD2 or MD5, include a Debian weak key, add no >basicConstraints extension or have CA=3Dtrue. Such practices put my site >and my users at risk. > >> Anyone can do SMTP with TLS today and most (sane) mail servers do that. >> Without classic PKI. And the SMTP servers they talk to do no validation >> whatsoever. DANE can only make things better here. > >I'm not familiar with SMTP. I wonder if both ends of the connection do >proper chain validation and checks for the particular cert that is >expected? Has anyone attempted MITM attacks against mail servers to see >if they can be tricked? If they're not doing "classic PKI", it may be >trivial to spoof one end of an SMTP connection and cause all kinds of >trouble. > >-Rick=20 > >-- >This message was scanned by ESVA and is believed to be clean. ------672E30A5D4AC7283B763FB491D47DE6D Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIIOgYJKoZIhvcNAQcCoIIIKzCCCCcCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3 DQEHAaCCBX0wggV5MIIEYaADAgECAhEAjvkMSfywKjIsvYKwPMSxXzANBgkqhkiG 9w0BAQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0 ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNl Y3VyZSBFbWFpbCBDQTAeFw0xMjEyMDMwMDAwMDBaFw0xNTEyMDMyMzU5NTlaMIGT MQ4wDAYDVQQHEwVGdWxkYTEPMA0GA1UECBMGSGVzc2VuMQswCQYDVQQGEwJERTEa MBgGA1UEAxMRQ2hyaXN0aWFuIEhldXRnZXIxCjAIBgNVBAsTAS0xIDAeBgNVBAoU F1BTVyBHUk9VUCBHbWJIICYgQ28uIEtHMRkwFwYJKoZIhvcNAQkBFgpjaEBwc3cu bmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1jWSXXiV2jUEn/9v Ciu0XjjHkb7GoLu4fqX76UIrgL6CMuj5NHxII9MaxLHE/okdtPE3uF46Xxs+dqlf /bGIWhlzSQ+M7GBcGjhkynagMnfPx+rr6JJsNEkBivkFYEFwYs5E7uA0+EfM2zmc 0J1NKBNwYAWxoGatnfCAkIFVG/b1MnQgRinau3ZVveto2iX1JTV0WPBdXwM7w/PR c4ybPAuY4k1TEXfnoyG2614Ov7N0s6kKKd2gBBCqvNdOpWMO36zIZe9/r1LYPnrN bgbz/XJmvvkUTf+okHuvZJ4o+XFGEOOa3bSirMgQJXwKB29cyEmcmlCgDF3gDnIV qpV9+QIDAQABo4IBxDCCAcAwHwYDVR0jBBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5 xXswHQYDVR0OBBYEFCUdN0WVp5HFhAsP3QPh+taSjcRAMA4GA1UdDwEB/wQEAwIF oDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjBG BgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1odHRwczov L3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8v Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl Y3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0 dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNv bW9kb2NhLmNvbTAVBgNVHREEDjAMgQpjaEBwc3cubmV0MA0GCSqGSIb3DQEBBQUA A4IBAQB2tp2OEKCRwDWsHjGPMzbN98s+FJdHKqVBA7uwut80O/ui8/eGI/8kh0TN vlPSIGun3mOGrOMcdjNleNwU+yH2mM1KCod3Wryq1wvP7brKLlChWLieHaBUfilw j8rRWBMOCULR0oxYwjArDUiEaRXli0Q6Hw8QiFzNYRaHTPH0GN9ERqpauzkFgE/u Vb7t7OHOVHJaAOhVfB/AtADkB794j2RIaSGnMmfhHEPA0DChOy8v4UC+uF48VoqA E05zv6JngbN9gpRj+uzjTzV7K7P6spfoTeywqXtEMJIP6BxHp3RHfcPPxyiDySSL 5S2U6wKo3CsAbhfnoZgBCw/Ogv+BMYIChTCCAoECAQEwgakwgZMxCzAJBgNVBAYT AkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8g Q2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCO+QxJ /LAqMiy9grA8xLFfMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNTMwMTIxMzIwWjAjBgkqhkiG9w0BCQQx FgQU8mbnJbqj3aiNhLwRBrJ2vFrjdlowUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAhg0Uwhs0fAkdBJrT+1Nr/ZZ3 M7Foq8g+QZ+am2eogcLCv6UvI3kEdJ0jOm+HICXSPvVQu9NKY5i9znSlT+lr0pfO miw8eI03xQ5U/90HAXOEpbor+viQbVAXnrAlfLrMNtfid42jyHHM/yXCKNPv62f/ yXT+KsceSWz9vnxtuMcDNFOQZm/w8s9phkXcHAo0BL+hmJyhzggqMwDQnlL4L2DT TSG+oK/Ay8mR1OJtc92k909juq4v2ZduwwCeq/4JtfEANHGhq0OYoOvNlzFpqwu3 PadKYYDR1WHtnSm8Z4qswdwDWh69QtLt5Hm3N5sAH6oMwbNXqNZgOW/VxxMT1Q== ------672E30A5D4AC7283B763FB491D47DE6D-- From jakob@kirei.se Thu May 30 05:53:32 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 805DB21F8CE9 for ; Thu, 30 May 2013 05:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[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 RUwtIpgHZ-zm for ; Thu, 30 May 2013 05:53: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 7682F21F8A6B for ; Thu, 30 May 2013 05:53:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:content-type:mime-version:subject:from:in-reply-to:date:cc: message-id:references:to:x-mailer; bh=l7nwNGZAy66HbpEyorx7pzv5od5jEgEtiCTxOgd722A=; b=UKAxK2EULwNQ4HHkuGJdedK+w2JzrYzooJEXqFMmIiZ6ggZvTm0AOCTjGD8b5te9QCRnmbwcUZU8G gBtU59isbLb83RXAmbN/sEpBk4swrp7a/672qjn0g9BNcjIFdK7NC66SSIVoI3RxNA0DKkMivvmkP4 k7FT8GJxyF2MtqxE= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Thu, 30 May 2013 14:53:24 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_2D4ED739-5106-4A42-8B0D-9A7EBF79EE0D"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jakob Schlyter In-Reply-To: Date: Thu, 30 May 2013 14:53:21 +0200 Message-Id: <72C4F0E4-9A12-4FA9-9B25-4724F5E4AAB5@kirei.se> References: To: Christian Heutger X-Mailer: Apple Mail (2.1503) Cc: "dane@ietf.org" Subject: Re: [dane] Classic PKI and DANE in harmony X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 May 2013 12:53:32 -0000 --Apple-Mail=_2D4ED739-5106-4A42-8B0D-9A7EBF79EE0D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 30 maj 2013, at 14:13, Christian Heutger wrote: > So with Usage 2 the own CA can be everything, from an online CA, > storing the private key in the public accessible webroot, enabling > everyone who recognized it to issue certs for the domain by himself. There is not practical difference between usage 2 and 3 - it is just a = choice of levels of indirection. The core of the DV problem is that as long as you control the DNS (and = therefore the mail server), you can get any certificate for anything = within the domain. DANE just makes this issue more apparent (and adds = actual security by requiring DNSSEC). jakob --Apple-Mail=_2D4ED739-5106-4A42-8B0D-9A7EBF79EE0D Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMmDCCBTcw ggMfoAMCAQICAwD8bDANBgkqhkiG9w0BAQUFADBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwG A1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290 MB4XDTEyMDYwMzE5MTgyOVoXDTEzMDYwMzE5MTgyOVowazELMAkGA1UEBhMCU0UxETAPBgNVBAcT CEdvdGVib3JnMREwDwYDVQQKEwhLaXJlaSBBQjEXMBUGA1UEAxMOSmFrb2IgU2NobHl0ZXIxHTAb BgkqhkiG9w0BCQEWDmpha29iQGtpcmVpLnNlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEA0fPL1331N8n0urnmz7IHyNVUOYapIJx/y1BVWuQUBiGl6SmylIxnnWQhk1dSJWD224zaoSf5 ey1B44wI1vA5olSy0xx8QXrXUCxyLYXPAlDYBJruFJRH+Wc0tXOKgdUrEDDPpmTrPtkTLm8CkK8f IfpolHNn4DipfeMcnBrTTLRNV3tZOMp25yCKevppX/GE9fK8a8MRnEf4q2aZN0uf1rycaYRrSSsr cp9mn3A8dBwv+X/V/u9PYYkX/yUhiSOjcdux7a0x0yZyARlNs54Bg5BAJDwneer92mVsW///Txp7 9DQOxFAXS7/bV7MNV2wmI4sdgYedk7SpsY3OCM2W2QIDAQABo4H6MIH3MAwGA1UdEwEB/wQCMAAw VgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFk IG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEF BQcDAgYKKwYBBAGCNwoDBAYKKwYBBAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAi BggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzAZBgNVHREEEjAQgQ5qYWtvYkBraXJl aS5zZTANBgkqhkiG9w0BAQUFAAOCAgEAMOWwip4KhQthaGrMTHn11iU6yWWVwUFOAPuR8EaCOxBT 7dLURbff7xHhM4ui2YsuWzCF78zpNKekWVYjg+YaJ4B3Gd0nm5dFXQhJDztns2D2XxQZA1p2+zaQ 5lnWAbyhTHj8F/uPXSe0OkCPIYZ7eEFCzznXerKxPRJWMP3paK6J/TYqmIpl7/79OhUOTUCCyMh2 5JFwtTz/90E6TwhdZK/K4W4UlrbM+t8P4xuLgDDueOs98RT/xiZketFOOZiQWxZ6vQEJoYrE7lPO aT9SPNJTaobP+SuKbHv/lVf33Ljca7D9XEZc8sSImgPcV7Y0q3U006Cin36kfP9NkBMExB84+BkP RSgv/Sp3uGYxVhGAmNOuJhOsMUFT1PAhiQAESjclkcYTjaNrMj7uaoHt2v0i5FE9Uhs5Dpy0//Mf SKfWmBWz0Sz3MIENt6QbIhpi2FDswdjGS+IGNuL+r5AcB9titC+1C0I0/aVTu2tsLEdHFLXki4Th S4ZY8Hx3dnxLz86EyhHtm2yyOywsUOLW5ttxIpv+r8YdGCz9Ki8q+lubBnhyY2kFtYAuyA9qrJL/ 7U9PMF8XI9WIpydpCEkT5Pdx0p0uOMnD+c2UNAXo3QMzBWl8dU+cLIPtm/1PgxigffZaqGee0wEa d/7k4fpd1N/tJPk6c9DzPy4ALl9kzsowggdZMIIFQaADAgECAgMKQYowDQYJKoZIhvcNAQELBQAw eTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYD VQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNh Y2VydC5vcmcwHhcNMTEwNTIzMTc0ODAyWhcNMjEwNTIwMTc0ODAyWjBUMRQwEgYDVQQKEwtDQWNl cnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNlcnQg Q2xhc3MgMyBSb290MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAq0k1EUh80iZ+U5TP Q6ndKNdCKovzh3gZWHwPntqJfeH763KQDXShlmSrn6AkmXPa4lV2xxd79QSsRrjDvn9kjRBsJPNh nMDykPpR5vVpAWPDD1biSkLP4kSMJSioxXkJfUa5ivPp8zQpCEXkHJ/LlAQcgagUs5hlxEPsToKN CdG9qluNktDs3pDFfwrC4+vmMVpedD6XM1nowwM9YDO/99FvR8TN7mKDUm4uCJqk2RUYkaaFkkew rkjrbbch7IUaaHI1q//wEF3A9JSnatU7kn5MkAV+k8Esi6SOYnQVcW4LcQPqrxU4mtTSBXJvjPkr 61pyJfk5RuNyGz4Ew2QnIhAqik9YpwOtvrQuE+1dqkjX1X3UKntc+kYEUOTMDkJbjO3b8s/8lpPg 2xE2VGI0OI8MYJs7l1Y4rfPSW4ugW+pOlrh819WghnBA05Ept6I8rfWMu88akorkNHvA2Gxf6QrC w6cgmlrfLF1SXLpH1ZvvJChwOCAv1X8pwLJBA2iSzOCczJdLRe86EAqrcDqYlXCtNbHqhSukHIAh MamuYHqAJkgAuAHAk2NVIpE8Vuev2zol848xVOomi4FZ+aHRUxHFe50D9nQR4G2xLD8shpGZcZqm d4s0YNEUtCysna+MENOfxGr4bxP8c1n3ZkJ0Horj+NzSb5icy0eYlUAF++kCAwEAAaOCAg0wggIJ MB0GA1UdDgQWBBR1qHFgTIgT8HjZiXe1bcWJ37yxejCBowYDVR0jBIGbMIGYgBQWtTIb1Mfz4OaO 873SsDrusjkY0aF9pHsweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5j YWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcN AQkBFhJzdXBwb3J0QGNhY2VydC5vcmeCAQAwDwYDVR0TAQH/BAUwAwEB/zBdBggrBgEFBQcBAQRR ME8wIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLkNBY2VydC5vcmcvMCgGCCsGAQUFBzAChhxodHRw Oi8vd3d3LkNBY2VydC5vcmcvY2EuY3J0MEoGA1UdIARDMEEwPwYIKwYBBAGBkEowMzAxBggrBgEF BQcCARYlaHR0cDovL3d3dy5DQWNlcnQub3JnL2luZGV4LnBocD9pZD0xMDA0BglghkgBhvhCAQgE JxYlaHR0cDovL3d3dy5DQWNlcnQub3JnL2luZGV4LnBocD9pZD0xMDBQBglghkgBhvhCAQ0EQxZB VG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFLCBnbyB0byBodHRwOi8vd3d3LkNB Y2VydC5vcmcwDQYJKoZIhvcNAQELBQADggIBACkoha5EqbmvpHkT8KijK5dg81zu4y/B9uJmoBGu Njc6dhUEU+pC9fnqwBXYpoLZ5GGucgspXJBD6EGy4XfbAhNEeEdVr1j8zJj2RbnRIPjYIQf+bapz 1LPGB+kJhcw78ra+LBwl1XGMObUu6r4Ygbqwk7gP4+bXJowxWnIDhFLmpvUzIkUKyAsNirg2b5AJ oau919VOLnGi1K76p1Qr6zWNWrdUiC/udJ/tSBbKDUjQlNOspKL2JN+S473rQ0CRbhwYjla0ghLz qZOf1LycrZx17lqXG5XndC0cD7Asl5/7qTM5eucDOpKOIvaMDeTZfg12GPcB+e+WlqJVc8A8cbQd GlZDt8MKjXL84hAJC0HOjJSg+QP9cXNLilcz5Y50fhUBAObMShznf5UZLcWlDIu7te2Fs1zT37i5 8srHDQEUrHBYxYyNM9SdZqMaUJUj/EjgBkMS2c2nhjkvNnKjgBDk4fPRy1sawOSAmnwTcwZP26Nr JAq6sxy8Sni75eN1OKVIp6Ier3bUXvc4hlZaic7Ww6d5slKgxvGFtCWM8j+WsxDZjWxXO59vhjoY giI2yLCRONsqoZOqhD/1J2Wuc9XI1dN36kudx0G7x8DjoD/kfaSNc+YSS9+hc3NzOoDo1cuOL8vq E6fWQYus+jyJ1yT1TrTgYZK38zeYxL6Wo7eKMYICvTCCArkCAQEwWzBUMRQwEgYDVQQKEwtDQWNl cnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNlcnQg Q2xhc3MgMyBSb290AgMA/GwwCQYFKw4DAhoFAKCCATcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTMwNTMwMTI1MzIxWjAjBgkqhkiG9w0BCQQxFgQU8/kXSqbZjj2t rkoPeAtSE1dA0s8wagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwG A1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290 AgMA/GwwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQL ExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAwD8 bDANBgkqhkiG9w0BAQEFAASCAQC302yWwVV5YfkNU/3spGksfxPx33xf2lRpjsUIgEP9DdZVzKuJ kEMMBwQj9xHhK60i6QDTKxA6q5qFv/q6SLClxNxHiwGLf1CNHaF7TttNMn9IIEzUAZ1Fv2+raR+X XK4Hd8R7nIcr+DyHdtw6IUREEz+8uRSZ8DZssuaMtqDaHBDbGiCiU1nEjdC5+yX9fdgjXeYujN+3 K4wt/BZ8o12GNxr9kJCjJtiq3WxLgFNHeMwRDNL0kqItfaqHYr20G9U3jNjeAJLvtR8Fxxcetmep m2aor5nMZansUgCzN+WdaX0hXgnoQ4WtMsmwk3EG3TahLTjrkxdfzPwPbgNkS93YAAAAAAAA --Apple-Mail=_2D4ED739-5106-4A42-8B0D-9A7EBF79EE0D-- From warren@kumari.net Thu May 30 07:37:29 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 570CE21F856D for ; Thu, 30 May 2013 07:37:29 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Qtu3-pgs-61 for ; Thu, 30 May 2013 07:37:17 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id E840B21F8E6E for ; Thu, 30 May 2013 07:37:09 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.124]) by vimes.kumari.net (Postfix) with ESMTPSA id EF2981B40A41; Thu, 30 May 2013 10:37:08 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Warren Kumari In-Reply-To: Date: Thu, 30 May 2013 10:37:08 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5B925F3A-B122-469D-97F5-7DF8A2262795@kumari.net> References: <20130529143710.GV9380@mournblade.imrryr.org> <20130529184555.GY9380@mournblade.imrryr.org> <544B0DD62A64C1448B2DA253C011414607ACD1048F@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> To: Jakob Schlyter X-Mailer: Apple Mail (2.1503) Cc: "dane@ietf.org" Subject: Re: [dane] Classic PKI and DANE in harmony X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 May 2013 14:37:29 -0000 On May 30, 2013, at 3:37 AM, Jakob Schlyter wrote: > On 30 maj 2013, at 04:24, Rick Andrews = wrote: >=20 >> Is there another list that's right for discussing the merits and = demerits of the different DANE options? I work for a CA, so of course I = believe that the current PKI is *not* irreparably broken, nor do I agree = that modes 2 and 3 are "substantially more robust". Because I believe = your voice is respected in this forum, I wanted to speak up to make it = clear that this opinion is not shared by all. >=20 > Unless the chairs do not object, I believe this mailing list is a good = place to discuss this matters. The chairs do not object. Obviously though, as always, standard mailing = list etiquette is expected -- if this turns into ad hominem attack (or = simply ads :-) ) we'll stomp on it=85.=20 >=20 > IMHO, classic PKI augmented by DANE would be a very strong package. = However, I would argue that without the extra identity proofing and = other controls set by by Extended Validation (EV), DANE has equally = security properties to a plain Domain Validation (DV) certificate. Well, yes and no=85 It all (to me at least) depends on what all the attacker has managed to = compromise. If (one day, fingers crossed) end hosts are all doing DNSSEC = then an attacker who gets a mi-sissued cert shouldn't be able to = actually use it, unless they have also compromised the DNS. As an example, the Diginotar incident. If a site has a DV (or whatever = other cert) and were using DANE, the attacker (who we assume has on the = wire MITM capabilities) would not be able to actually *use* the cert.=20 If the compromise happens because you lost control of your DNS = infrastructure (including your registrar account, etc) then yeah, no = huge difference=85 >=20 > For a foreseeable future, we definitely need to combine DANE with = classic PKI in order for the general Internet user to be able to = validate certificates. Agreed. > For limited deployments, or applications where classic PKI has not yet = gained significant traction (such as TLS for SMTP), a pure DANE solution = makes sense (unless EV is required). Also agreed.=20 >=20 > jakob >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 -- "Have you got any previous convictions?" "Well, I dunno... I suppose I used to believe very firmly that a penny = saved is a penny earned--" -- Terry Pratchett From benl@google.com Thu May 30 07:40:21 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF1B21F8FA3 for ; Thu, 30 May 2013 07:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.499, 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 h-neHE3VohnL for ; Thu, 30 May 2013 07:40:15 -0700 (PDT) Received: from mail-qe0-f45.google.com (mail-qe0-f45.google.com [209.85.128.45]) by ietfa.amsl.com (Postfix) with ESMTP id A2ECB21F900C for ; Thu, 30 May 2013 07:39:43 -0700 (PDT) Received: by mail-qe0-f45.google.com with SMTP id q19so167247qeb.32 for ; Thu, 30 May 2013 07:39:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mtHE6TqomUwQU87gsjDP7l/GD+U06hkXMGWPFvyvQVQ=; b=ndufecvOWrSR4DeHF/266ctSV7MT/MagYUbYiIeQYV6EzDTlPY8Ik+SiWoS66RdHqG OvuX82jXPnIb0ZZ7eUGiV+Z9cv+4x7FaxTkgc+mJILkm1TbwMSYZq0dZtbxpqKNM/lSv wT3WuQhQctmXVFbLIhQMS32c8qYZla0LXSRjYjsLOAjUKpeBUORB6KVHX+Qnxc1c4tx7 jNXXmrgJkDSHL5NcLVyn1Y+gJcncJew/dVgC4rqudK+oaz64Sj9h+Y8oy5/LJAfXLxlw mGxqaRQ0L3vCpJiB+68iwtlX8WiusG/4lRaSZR1jIluV88WGz36+ue1FDEfi8Txz+1iq wLjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=mtHE6TqomUwQU87gsjDP7l/GD+U06hkXMGWPFvyvQVQ=; b=a3ZzFGiFVE7ZyWlugHL311GH6xUoVXA6gWKQsilfNr/LHmchsNMV5Od3iTmTz4/Qjb J/qRKzrGqtgUPkr2TFhgUqy9aOGuGMrf0LwQDn91pDDA9+q70YPmBD1/kvmMRUognwKe 9ISkWXfvyw/FtjFUQAjEwWtAszy7mrSQv8RC/caB9Hf4bIC4bhIVbEM1ye8Zc3YWdCUQ S+/me11Q64YK2D/sAeQT9PRr+a4LMVWrC7FPh+UnSe8cKgWdwNME8LLLpfNvjZRaACMG CLdpjA7k4YdXI+qoJEd5z6HsAhZnevni5J4ywb3Fdkseckf8CBXjVLqL/qub00hhuNJW uyWw== MIME-Version: 1.0 X-Received: by 10.49.118.38 with SMTP id kj6mr7170021qeb.48.1369924782947; Thu, 30 May 2013 07:39:42 -0700 (PDT) Received: by 10.49.86.67 with HTTP; Thu, 30 May 2013 07:39:42 -0700 (PDT) In-Reply-To: <5B925F3A-B122-469D-97F5-7DF8A2262795@kumari.net> References: <20130529143710.GV9380@mournblade.imrryr.org> <20130529184555.GY9380@mournblade.imrryr.org> <544B0DD62A64C1448B2DA253C011414607ACD1048F@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <5B925F3A-B122-469D-97F5-7DF8A2262795@kumari.net> Date: Thu, 30 May 2013 15:39:42 +0100 Message-ID: From: Ben Laurie To: Warren Kumari Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnVaXtZPFy8NxuhNgXEOFnoVR4eTNxzs8eO/Z5cJN0PNopP2y/L86jkTOsZiuZiRNvarADZ3ZZSaXB3RhbUYU+h7sx2yZoR3qpkw7OfUhSovKIfSm0UIUYIWrI140+XbfBLX9iWnPXMxLcwoGIGWh059S8nY6/hWpvI5jJuzWVF0nyhKS38qRQevTkwK8OPX9uoPptL Cc: "dane@ietf.org" Subject: Re: [dane] Classic PKI and DANE in harmony X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 May 2013 14:40:21 -0000 On 30 May 2013 15:37, Warren Kumari wrote: > As an example, the Diginotar incident. If a site has a DV (or whatever other cert) and were using DANE, the attacker (who we assume has on the wire MITM capabilities) would not be able to actually *use* the cert. You are imagining a future in which browsers suddenly decide that out-of-band checking is acceptable, which seems unlikely to actually occur other than in fantasy. From olaf@NLnetLabs.nl Thu May 30 07:54:15 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 785E221F8CE9 for ; Thu, 30 May 2013 07:54:06 -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, HTML_MESSAGE=0.001, 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 HuNP+ccVSQqO for ; Thu, 30 May 2013 07:54:03 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C043221F8FBE for ; Thu, 30 May 2013 07:54:00 -0700 (PDT) Received: from [IPv6:2001:7b8:206:1:7211:24ff:fe8c:627a] ([IPv6:2001:7b8:206:1:7211:24ff:fe8c:627a]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.7/8.14.4) with ESMTP id r4UEruk6010729 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 30 May 2013 16:53:57 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) Authentication-Results: open.nlnetlabs.nl; dmarc=none header.from=NLnetLabs.nl DKIM-Filter: OpenDKIM Filter v2.8.2 open.nlnetlabs.nl r4UEruk6010729 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1369925638; bh=ibJI8XvI/PtuXh8vs42lvUbvVgUdCcOEEJyek/iM/w8=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=NSDEHC/T7tXunxjDPOSV1Gx0j3sLSktzFav89M1mEkcck5IeU/84pm9kahjK1dhLi XTrCaYE3iKXcs5RcM324UKW4sg5KoClwcwMylBoHJsbGPm/W+8wr7EzeNVK/z+hAUH ITZdBZVtqwpL0QAdGnqs5xhKyORcjIDfrpw0T0Uo= Content-Type: multipart/alternative; boundary="Apple-Mail=_5CC61D17-0F13-4168-BEEB-9DF526C62A06" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Olaf Kolkman In-Reply-To: Date: Thu, 30 May 2013 16:53:55 +0200 Message-Id: <69DCBEB1-396E-4EDF-A86B-CB2483CAD094@NLnetLabs.nl> References: <20130529143710.GV9380@mournblade.imrryr.org> <20130529184555.GY9380@mournblade.imrryr.org> <544B0DD62A64C1448B2DA253C011414607ACD1048F@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <5B925F3A-B122-469D-97F5-7DF8A2262795@kumari.net> To: Ben Laurie X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Thu, 30 May 2013 16:53:58 +0200 (CEST) Cc: "dane@ietf.org" Subject: Re: [dane] Classic PKI and DANE in harmony X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 May 2013 14:54:15 -0000 --Apple-Mail=_5CC61D17-0F13-4168-BEEB-9DF526C62A06 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 30, 2013, at 4:39 PM, Ben Laurie wrote: > On 30 May 2013 15:37, Warren Kumari wrote: >> As an example, the Diginotar incident. If a site has a DV (or = whatever other cert) and were using DANE, the attacker (who we assume = has on the wire MITM capabilities) would not be able to actually *use* = the cert. >=20 > You are imagining a future in which browsers suddenly decide that > out-of-band checking is acceptable, which seems unlikely to actually > occur other than in fantasy. Why? --Apple-Mail=_5CC61D17-0F13-4168-BEEB-9DF526C62A06 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii benl@google.com> wrote:

On 30 May 2013 15:37, Warren = Kumari <
You are imagining a future in which = browsers suddenly decide that
out-of-band checking is = acceptable, which seems unlikely to actually
Subject: Re: [dane] Classic PKI and DANE in harmony X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 May 2013 14:55:18 -0000 On 30 May 2013 15:53, Olaf Kolkman wrote: > > On May 30, 2013, at 4:39 PM, Ben Laurie wrote: > > On 30 May 2013 15:37, Warren Kumari wrote: > > As an example, the Diginotar incident. If a site has a DV (or whatever other > cert) and were using DANE, the attacker (who we assume has on the wire MITM > capabilities) would not be able to actually *use* the cert. > > > You are imagining a future in which browsers suddenly decide that > out-of-band checking is acceptable, which seems unlikely to actually > occur other than in fantasy. > > > Why? Because: a) It introduces latency, and b) It isn't reliable, so cannot be hard-fail. From viktor1dane@dukhovni.org Thu May 30 08:18:16 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88FE821F93BA for ; Thu, 30 May 2013 08:18:16 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65xj1+Wx1D2N for ; Thu, 30 May 2013 08:18:12 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 4209921F8FA3 for ; Thu, 30 May 2013 08:18:12 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 887B72AB9D4; Thu, 30 May 2013 15:18:10 +0000 (UTC) Date: Thu, 30 May 2013 15:18:10 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130530151810.GD9380@mournblade.imrryr.org> References: <20130529143710.GV9380@mournblade.imrryr.org> <20130529184555.GY9380@mournblade.imrryr.org> <544B0DD62A64C1448B2DA253C011414607ACD1048F@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <5B925F3A-B122-469D-97F5-7DF8A2262795@kumari.net> <69DCBEB1-396E-4EDF-A86B-CB2483CAD094@NLnetLabs.nl> 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] Classic PKI and DANE in harmony X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 15:18:16 -0000 On Thu, May 30, 2013 at 03:55:06PM +0100, Ben Laurie wrote: > > You are imagining a future in which browsers suddenly decide that > > out-of-band checking is acceptable, which seems unlikely to actually > > occur other than in fantasy. > > > > > > Why? > > Because: > > a) It introduces latency, and Negligible because DNS RRs are cached near the client, ideally at 127.0.0.1 (a forwarding DNSSEC validating cache on every computer, mobile phone, ...), thereby eliminating issues wrt. MITM attacks between the client and the caching resolver. Also with a DNSSEC-validating cache, the client does not need to repeatedly re-validate the same data. The Postfix SMTP client maintains a small in-memory working-set of such records, which further reduces latency to completely negligible levels. > b) It isn't reliable, so cannot be hard-fail. I have to click "OK" multiple times a day with the current PKI, often with ietf.org sites when the URL uses an different name for the site than is found in its certificate, or because I don't trust a bunch of questionable CAs, ... will likely be far *more* reliable (fewer false rejections) than the existing public CA PKI. With a "3 1 1" TLSA RR (matching a leaf cert ultimately signed by a public CA for now), a DANE-aware browser can reliably succeed where the public CA PKI fails, due to: - A rogue CA publishing unauthorized certificates. - An incomplete (whatever that means) CA list on the client - Problems with CRLs What specific problems do you anticipate with DANE TLSA that make it unsafe to "hard-fail"? -- Viktor. From viktor1dane@dukhovni.org Thu May 30 08:30:11 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB89E21F9552 for ; Thu, 30 May 2013 08:30:11 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q94YzZbaF-kC for ; Thu, 30 May 2013 08:30:07 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 3E34321F8F3E for ; Thu, 30 May 2013 08:30:02 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 288F02AB9D4; Thu, 30 May 2013 15:29:59 +0000 (UTC) Date: Thu, 30 May 2013 15:29:59 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130530152959.GF9380@mournblade.imrryr.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [dane] TLS and SMTP X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 15:30:12 -0000 On Thu, May 30, 2013 at 07:33:13AM -0400, Tom Ritter wrote: > PKIX Validation + SMTP is all sorts of wonky. I'm just throwing it out > there ;) Please, please, find ~10 free minutes and read the draft! https://tools.ietf.org/html/draft-dukhovni-smtp-opportunistic-tls-00 Then you will see that: - The existing public CA PKI and SMTP with MX indirection are incompatible. - The same likely applies to submission via SRV records. - DANE is well suited to securing both, via 2/3 TLSA RRs only. and perhaps you can help to improve the draft. Thanks. -- Viktor. From benl@google.com Thu May 30 08:41:03 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD5D21F9607 for ; Thu, 30 May 2013 08:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 QfbOC+BtedPg for ; Thu, 30 May 2013 08:41:02 -0700 (PDT) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 0A4C821F9579 for ; Thu, 30 May 2013 08:41:00 -0700 (PDT) Received: by mail-qa0-f43.google.com with SMTP id j11so2961337qag.16 for ; Thu, 30 May 2013 08:41:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=z+KINKY/8h8SBPiHHO5cCfSTHI2IS82OpsGaT0s5Ubo=; b=DrZS3cj3d753c37YvvvWBSpFdyXXivgSmYxpFJde2P4c0vU4cC7iY19nWgufWnRSaS 2VFdIAWMCK/lBUZ847/Z9XYY5AgM7YM+46GpkFh4jarH8qrQzEpgKIVrQO/3I9iiEXGF vj8AMgzwg/EiGDgjJpPlHdL3kTXjYUEBrLfT1BazBE9vINUqE0xPhhETpOycWR/oeYTh iTH9N6ri25CpAM7ScxL0F4nvn0jdMk9V10emIdobO1o3HmRzgj5Z91m1smEpXMGOUKrI RiZCK90c7cd4MeknoJyfJsgUZeJ7/ndrQa0xuQgQdTY5PC5vS5pNBlZk/tRnqa38ky3g W9yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=z+KINKY/8h8SBPiHHO5cCfSTHI2IS82OpsGaT0s5Ubo=; b=iZbUua4gA05jo7S0su6Ud7M+xPnd5cafOpdZ4r0MY7gOrqRLn/vJ0hKWOTE/Ebf3lb k0OKB7Zi7UA4zQ/9X2HnEL1uJDIkYy+K02EfPtPbC9obD3PE7KBJnRAMBHz0av6oqCVi ttU3O+d3Bxr3CXJLRTS8Aag00fy/hCN3sEMqiyAhQ1j0Q6SH/SQPouxLJRtcXkBsT5F7 p04mOJAIZ92NCdDs0qdgm9FTO7ZXlXd5b3npreGHzG6wqwX9wbC9eOqeJVgKn50RcauB V2bjS0nA8eSDCHu9RVgBo2qlYJUV24zcRJqpyaPHRfJsNDUfdPC5WPUIg4A4EXr4KJSL kpYQ== MIME-Version: 1.0 X-Received: by 10.49.118.38 with SMTP id kj6mr7391273qeb.48.1369928460405; Thu, 30 May 2013 08:41:00 -0700 (PDT) Received: by 10.49.86.67 with HTTP; Thu, 30 May 2013 08:41:00 -0700 (PDT) In-Reply-To: <20130530151810.GD9380@mournblade.imrryr.org> References: <20130529143710.GV9380@mournblade.imrryr.org> <20130529184555.GY9380@mournblade.imrryr.org> <544B0DD62A64C1448B2DA253C011414607ACD1048F@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <5B925F3A-B122-469D-97F5-7DF8A2262795@kumari.net> <69DCBEB1-396E-4EDF-A86B-CB2483CAD094@NLnetLabs.nl> <20130530151810.GD9380@mournblade.imrryr.org> Date: Thu, 30 May 2013 16:41:00 +0100 Message-ID: From: Ben Laurie To: IETF DANE WG list Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmLh8m6ml3Hjp+E8IDrNuUbXHj3NTjZzVv8XA1ymquPLqruYCDMbnNQfAU3btMrYnhHFU6esYYIcPLLiko35TCI3VASAnX/jZXUNElF7GHG8NahD5ccZmjJOVNb/g4ty9bmmSyt7fYz/NTC2kzTLbAxmzofPGPSOnMHsNSR6Hc1GMoG7jbj42EL7Y8PjJ4+P7JdmNYY Subject: Re: [dane] Classic PKI and DANE in harmony X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 May 2013 15:41:03 -0000 On 30 May 2013 16:18, Viktor Dukhovni wrote: > On Thu, May 30, 2013 at 03:55:06PM +0100, Ben Laurie wrote: > >> > You are imagining a future in which browsers suddenly decide that >> > out-of-band checking is acceptable, which seems unlikely to actually >> > occur other than in fantasy. >> > >> > >> > Why? >> >> Because: >> >> a) It introduces latency, and > > Negligible because DNS RRs are cached near the client, ideally at > 127.0.0.1 (a forwarding DNSSEC validating cache on every computer, > mobile phone, ...), thereby eliminating issues wrt. MITM attacks > between the client and the caching resolver. Even if this were true, first hit latency matters, too. As anecdotal evidence, I just resolved a name unlikely to be cached locally: $ dig www.disney.com ;; Query time: 535 msec Unacceptable. > Also with a DNSSEC-validating cache, the client does not need to > repeatedly re-validate the same data. Our experiments suggest that a _large_ percentage of clients cannot see DNSSEC records at all. > The Postfix SMTP client maintains a small in-memory working-set of > such records, which further reduces latency to completely negligible > levels. > >> b) It isn't reliable, so cannot be hard-fail. > > I have to click "OK" multiple times a day with the current PKI, > often with ietf.org sites when the URL uses an different name for > the site than is found in its certificate, or because I don't trust > a bunch of questionable CAs, ... will likely be far *more* reliable > (fewer false rejections) than the existing public CA PKI. > > With a "3 1 1" TLSA RR (matching a leaf cert ultimately signed by > a public CA for now), a DANE-aware browser can reliably succeed > where the public CA PKI fails, due to: > > - A rogue CA publishing unauthorized certificates. > - An incomplete (whatever that means) CA list on the client > - Problems with CRLs > > What specific problems do you anticipate with DANE TLSA that make > it unsafe to "hard-fail"? See above. > > -- > Viktor. From nweaver@icsi.berkeley.edu Thu May 30 08:51:18 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A71321F9690 for ; Thu, 30 May 2013 08:51:18 -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 5khvTg6wGIj4 for ; Thu, 30 May 2013 08:51:10 -0700 (PDT) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 6896621F967F for ; Thu, 30 May 2013 08:51:10 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 309D12C4027; Thu, 30 May 2013 08:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id q++7Z4qi6hsA; Thu, 30 May 2013 08:51:09 -0700 (PDT) Received: from gala.icir.org (gala [192.150.187.49]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 87E832C4023; Thu, 30 May 2013 08:51:09 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Nicholas Weaver In-Reply-To: Date: Thu, 30 May 2013 08:51:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130529143710.GV9380@mournblade.imrryr.org> <20130529184555.GY9380@mournblade.imrryr.org> <544B0DD62A64C1448B2DA253C011414607ACD1048F@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <5B925F3A-B122-469D-97F5-7DF8A2262795@kumari.net> <69DCBEB1-396E-4EDF-A86B-CB2483CAD094@NLnetLabs.nl> <20130530151810.GD9380@mournblade.imrryr.org> To: Ben Laurie X-Mailer: Apple Mail (2.1503) Cc: IETF DANE WG list Subject: Re: [dane] Classic PKI and DANE in harmony X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 May 2013 15:51:18 -0000 On May 30, 2013, at 8:41 AM, Ben Laurie wrote: >>> a) It introduces latency, and >>=20 >> Negligible because DNS RRs are cached near the client, ideally at >> 127.0.0.1 (a forwarding DNSSEC validating cache on every computer, >> mobile phone, ...), thereby eliminating issues wrt. MITM attacks >> between the client and the caching resolver. >=20 > Even if this were true, first hit latency matters, too. As anecdotal > evidence, I just resolved a name unlikely to be cached locally: >=20 > $ dig www.disney.com > ;; Query time: 535 msec >=20 > Unacceptable. Except that, thanks to glue records and parallelism and speculative = prefetch, you can ALSO fetch TYPE=3DDANE along with the TYPE=3DA and = TYPE=3DAAAA records that are already having to be fetched, and the = DNSSEC related records (DS, DNSKEY, etc) can also be speculatively = fetched, so there should be NO latency hit for fetching the records, = with the only latency hit involving signature validation. Although I disagree about the cache local. The VALIDATION should be = local, but it should still use the ISP-level recursive resolver cache, = as that IS a huge win in practical performance and, thanks to DNSSEC in = general, you don't have to trust that lying, MitMing SOB. >> Also with a DNSSEC-validating cache, the client does not need to >> repeatedly re-validate the same data. >=20 > Our experiments suggest that a _large_ percentage of clients cannot > see DNSSEC records at all. This is the bigger problem, and I agree. We should have some detailed = data soon from Netalyzr, the tests that have been running for a while = are: Direct to the Internet fetching of DNSSEC records (DNSSEC to all roots = for DS, DNSKEY, RRSIG, and NSEC, DNSSEC to .com for NSEC3) Recursive resolver fetching of DNSSEC records using DO Recursive resolver fetching of DNSSEC records without using DO to see if = you can get the full necessary RRSIG for .com (e.g. OpenDNS fails the latter: If you query without DNSSEC, you don't = get the RRSIG for the DS record for .com! But then again, OpenDNS is = vocal that DNSSEC runs counter to their business model, so they will = never support it) I suspect that a non-trivial (>.1%, probably >1%) of sessions will fail = all three tests, but I haven't conducted that data analysis yet. From viktor1dane@dukhovni.org Thu May 30 08:55:46 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 209CF21F9660 for ; Thu, 30 May 2013 08:55:46 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzraigY74EAU for ; Thu, 30 May 2013 08:55:41 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 8231621F9602 for ; Thu, 30 May 2013 08:55:41 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id C2A5B2AB9D4; Thu, 30 May 2013 15:55:39 +0000 (UTC) Date: Thu, 30 May 2013 15:55:39 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130530155539.GG9380@mournblade.imrryr.org> References: <20130529184555.GY9380@mournblade.imrryr.org> <544B0DD62A64C1448B2DA253C011414607ACD1048F@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <5B925F3A-B122-469D-97F5-7DF8A2262795@kumari.net> <69DCBEB1-396E-4EDF-A86B-CB2483CAD094@NLnetLabs.nl> <20130530151810.GD9380@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Classic PKI and DANE in harmony X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 15:55:46 -0000 On Thu, May 30, 2013 at 04:41:00PM +0100, Ben Laurie wrote: > >> a) It introduces latency, and > > > > Negligible because DNS RRs are cached near the client, ideally at > > 127.0.0.1 (a forwarding DNSSEC validating cache on every computer, > > mobile phone, ...), thereby eliminating issues wrt. MITM attacks > > between the client and the caching resolver. > > Even if this were true, first hit latency matters, too. As anecdotal > evidence, I just resolved a name unlikely to be cached locally: > > $ dig www.disney.com > ;; Query time: 535 msec > > Unacceptable. That's how long it took to get the A record, which the browser needs anyway! So it must be acceptable. - This is I assume why Google does DNS pre-fetching, and the same can be done for TLSA RRs. - With a suitable asynchronous DNS lookup API, multiple DNS queries can be sent in parallel, the A record, AAAA record and TLSA RRs can all arrive in parallel. What slows down page loads for me is not DNS, but the "skip this ad" links that come up before the real page loads :-) > > Also with a DNSSEC-validating cache, the client does not need to > > repeatedly re-validate the same data. > > Our experiments suggest that a _large_ percentage of clients cannot > see DNSSEC records at all. This is fine, they can continue to use legacy PKI. DANE does not apply when the client has no DNSSEC support. DANE is not intended to "hard fail" when the client can't use DNSSEC. It only hardfails when it can and the returned RRs are "bogus". A more serious issue for browsers is corporate MITM proxies. Browsers behind such proxies (much as Chrome does now, since it "knows" about the certificates of some sites) need to be configured to enable alternatives to the default TLS security policy. > > With a "3 1 1" TLSA RR (matching a leaf cert ultimately signed by > > a public CA for now), a DANE-aware browser can reliably succeed > > where the public CA PKI fails, due to: > > > > - A rogue CA publishing unauthorized certificates. > > - An incomplete (whatever that means) CA list on the client > > - Problems with CRLs > > > > What specific problems do you anticipate with DANE TLSA that make > > it unsafe to "hard-fail"? > > See above. You have not yet mentioned anything that makes it unsafe to hardfail when TLSA RRs don't match, or DNSSEC replies are bogus. Otherwise, DANE does not hard fail. I really don't want to be oppositional, sorry if it seems that way, difficult to seem otherwise in email. It seems there may be some misconceptions about the DANE TLSA PKI validation model, are you open to exploring this possibility? -- Viktor. From viktor1dane@dukhovni.org Thu May 30 09:09:47 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0F9721F9701 for ; Thu, 30 May 2013 09:09:46 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqjS6oCQt-YO for ; Thu, 30 May 2013 09:09:41 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id C710E21F968D for ; Thu, 30 May 2013 09:09:41 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 86B0D2AB9D4; Thu, 30 May 2013 16:09:37 +0000 (UTC) Date: Thu, 30 May 2013 16:09:37 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130530160937.GH9380@mournblade.imrryr.org> References: <20130529184555.GY9380@mournblade.imrryr.org> <544B0DD62A64C1448B2DA253C011414607ACD1048F@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <5B925F3A-B122-469D-97F5-7DF8A2262795@kumari.net> <69DCBEB1-396E-4EDF-A86B-CB2483CAD094@NLnetLabs.nl> <20130530151810.GD9380@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Classic PKI and DANE in harmony X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 16:09:47 -0000 On Thu, May 30, 2013 at 08:51:09AM -0700, Nicholas Weaver wrote: > Although I disagree about the cache local. The VALIDATION should > be local, but it should still use the ISP-level recursive resolver > cache, as that IS a huge win in practical performance and, thanks > to DNSSEC in general, you don't have to trust that lying, MitMing > SOB. A local cache should typically forward all requests to the ISP, and validate the result locally. There is no need to saddle applications with DNSSEC validating code and library dependency DLL hell. DNSSEC via IPC to "unbound" or similar is much cleaner. I'm not suggesting side-stepping the ISP cache, just placing a local cache between that and the application. For example, there should I believe be a DNSSEC validating cache on Android phones, to complement the DNSSEC validation on 8.8.8.8. That way the MITM at a Starbucks Wifi hotspot can't tamper with 8.8.8.8 DNS replies. > > Our experiments suggest that a _large_ percentage of clients cannot > > see DNSSEC records at all. > > This is the bigger problem, and I agree. We should have some > detailed data soon from Netalyzr, the tests that have been running > for a while are: IMHO a DNSSEC-aware local resolver that can't see DNSSEC RRs through its DHCP discovered forwarder should have a fallback strategy that either uses the root servers directly, or uses 8.8.8.8 or similar services that are publically accessible and don't fail to support DNSSEC. This would give Google more intel on DNS lookup traffic, so I doubt they would mind. It would be nice to have a DNSSEC-aware local cache on my Android phone. -- Viktor. From warren@kumari.net Thu May 30 09:16:58 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60DC521F9686 for ; Thu, 30 May 2013 09:16:58 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqQ4qV865q3y for ; Thu, 30 May 2013 09:16:53 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ACC221F8FBE for ; Thu, 30 May 2013 09:16:40 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.127]) by vimes.kumari.net (Postfix) with ESMTPSA id 707D51B40A41; Thu, 30 May 2013 12:16:39 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Warren Kumari In-Reply-To: Date: Thu, 30 May 2013 11:10:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0C025A66-FC8B-4008-9BCB-47C296FAE024@kumari.net> References: <20130529143710.GV9380@mournblade.imrryr.org> <20130529184555.GY9380@mournblade.imrryr.org> <544B0DD62A64C1448B2DA253C011414607ACD1048F@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <5B925F3A-B122-469D-97F5-7DF8A2262795@kumari.net> <69DCBEB1-396E-4EDF-A86B-CB2483CAD094@NLnetLabs.nl> To: Ben Laurie X-Mailer: Apple Mail (2.1503) Cc: "dane@ietf.org" Subject: Re: [dane] Classic PKI and DANE in harmony X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 May 2013 16:16:58 -0000 On May 30, 2013, at 10:55 AM, Ben Laurie wrote: > On 30 May 2013 15:53, Olaf Kolkman wrote: >>=20 >> On May 30, 2013, at 4:39 PM, Ben Laurie wrote: >>=20 >> On 30 May 2013 15:37, Warren Kumari wrote: >>=20 >> As an example, the Diginotar incident. If a site has a DV (or = whatever other >> cert) and were using DANE, the attacker (who we assume has on the = wire MITM >> capabilities) would not be able to actually *use* the cert. >>=20 >>=20 >> You are imagining a future in which browsers suddenly decide that >> out-of-band checking is acceptable, which seems unlikely to actually >> occur other than in fantasy. Yes, I am, but 'tis a very pretty fantasy, filled with unicorns, = rainbows, kittens and a Bloodhound = (http://www.dnssec-tools.org/download/#gotoBloodhound). Obviously this = is a niche browser, but... Damn kids, git off of my fantasy... >>=20 >> Why? >=20 > Because: >=20 > a) It introduces latency, and Yes, this is true. One option (less than ideal, but still better than nothing) would be for = the DANE lookup / processing to be done in parallel with the normal A = record, but not block the page. If, after the page is rendered / = displayed it turns out that DANE says that something is wrong, the page = could be replaced with the big, red, scary thing. Yes, by then it is = possibly too late (you have already shipped cookies, etc to the = attacker), but better than blithely thinking you are in the right place. "Always do DANE" could also be an option that folk could decide to turn = on, if they are more paranoid than the average user. Some folk might = prefer a latency hit for the added peace of mind.=20 It could also be that DANE is triggered only for "self signed" / other = places where the "There is something odd here" bit happens. Would allow = for some of the benefits, and (IMO) not that large a latency hit, as = reading the "We couldn't validate this cert, what do you ant to do?!" = bit takes some time anyway=85 But yes, I get the issue.=20 W > b) It isn't reliable, so cannot be hard-fail. >=20 -- Curse the dark, or light a match. You decide, it's your dark. -- Valdis Kletnieks From benl@google.com Thu May 30 09:18:44 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F4BA21F96D8 for ; Thu, 30 May 2013 09:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 AVe0dU58BQWR for ; Thu, 30 May 2013 09:18:43 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1D421F9418 for ; Thu, 30 May 2013 09:18:43 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id f4so1058723iea.37 for ; Thu, 30 May 2013 09:18:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=LYoCXiMXQPrh9OYHDq8gSJzijWfzJnCrrGR5D7REkVI=; b=U6l3cZUu5e3wgwsB04BqaXyBwNdCnG+DyDqEjy+euXnQZZlR/l2kPgsIWQgI2WQh9b FeG7L8XmjvTdtskn0AXTjOaB7FuGAP9lPVefp1IdJVayCDA4lltMWILeaXQvvJ62/E5F x44p4USSogWtgRi9Ua9XJGbX0hCuo5tRMFjO4NIhmYHUdGRoXoQ/tJpcvMlme6dXK/Z6 DGhlP7yxr8Xdn493MKp6QG+2x4dJ++Yb6pHknxRY4x1nccOcYzrVNEHVuh4f8+8TxRkv DK3B1PWo5EopR1dDjQXz1266SrEEFO88h/lBhq4XU3jlCStmBtqg3DOIn9MKnlfES+l3 7n+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=LYoCXiMXQPrh9OYHDq8gSJzijWfzJnCrrGR5D7REkVI=; b=dGImCFczzLuhcawmxug8EAnx+pnOqNwkvL+iMaOyf5N+a+0NI2wAD2mdMqEVeB32uH CrQp3cR7liCi48lnoPHf0YPlGrw/3v4ETcvucbX0uI4/YQJDXT7yuqA73UpYwSadTk22 t+1sfNTNOg38ksht0CkYaf7+t2ATjlIaof8vla0VxVxr3LfuDwllTZFIcSwRgv+mJ1OY WRhUbt/PwtETwq1QygojoFX1WXwLln2VOsW0FSquXiSVZtlHNICnI6LgwPYykXxVQgC0 Bf6ggjus76xfFZJYxnOBY4oBZDHC77R4wGRHnFW6wWrZadZecAc0fyEkJbm5qLP9hrAZ ye0g== MIME-Version: 1.0 X-Received: by 10.50.128.102 with SMTP id nn6mr12038954igb.26.1369930722832; Thu, 30 May 2013 09:18:42 -0700 (PDT) Received: by 10.64.24.137 with HTTP; Thu, 30 May 2013 09:18:42 -0700 (PDT) In-Reply-To: <20130530155539.GG9380@mournblade.imrryr.org> References: <20130529184555.GY9380@mournblade.imrryr.org> <544B0DD62A64C1448B2DA253C011414607ACD1048F@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <5B925F3A-B122-469D-97F5-7DF8A2262795@kumari.net> <69DCBEB1-396E-4EDF-A86B-CB2483CAD094@NLnetLabs.nl> <20130530151810.GD9380@mournblade.imrryr.org> <20130530155539.GG9380@mournblade.imrryr.org> Date: Thu, 30 May 2013 17:18:42 +0100 Message-ID: From: Ben Laurie To: IETF DANE WG list Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkMRpuW5+K+KBDDHR9Bm/jt25IA2aitImIJkz5kntGJ0WTE0d9rLf8KJFW76yOWimffc8ZD7Q0VC8i7+SmJlNy58F35qyuNS1OMWVNuN3mZg9+faETUXbKGitUY7nTP+tc9SvUvS9UCEI1irOSOZae1upZ21yZ1HOTnhusgfv5nMQtjEPP3wvRS6bHqeU02YxZpZP5R Subject: Re: [dane] Classic PKI and DANE in harmony X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 May 2013 16:18:44 -0000 On 30 May 2013 16:55, Viktor Dukhovni wrote: > On Thu, May 30, 2013 at 04:41:00PM +0100, Ben Laurie wrote: > >> >> a) It introduces latency, and >> > >> > Negligible because DNS RRs are cached near the client, ideally at >> > 127.0.0.1 (a forwarding DNSSEC validating cache on every computer, >> > mobile phone, ...), thereby eliminating issues wrt. MITM attacks >> > between the client and the caching resolver. >> >> Even if this were true, first hit latency matters, too. As anecdotal >> evidence, I just resolved a name unlikely to be cached locally: >> >> $ dig www.disney.com >> ;; Query time: 535 msec >> >> Unacceptable. > > That's how long it took to get the A record, which the browser > needs anyway! So it must be acceptable. > > - This is I assume why Google does DNS pre-fetching, and the > same can be done for TLSA RRs. > > - With a suitable asynchronous DNS lookup API, multiple DNS queries > can be sent in parallel, the A record, AAAA record and TLSA RRs > can all arrive in parallel. > > What slows down page loads for me is not DNS, but the "skip this ad" > links that come up before the real page loads :-) > >> > Also with a DNSSEC-validating cache, the client does not need to >> > repeatedly re-validate the same data. >> >> Our experiments suggest that a _large_ percentage of clients cannot >> see DNSSEC records at all. > > This is fine, they can continue to use legacy PKI. DANE does not > apply when the client has no DNSSEC support. DANE is not intended > to "hard fail" when the client can't use DNSSEC. It only hardfails > when it can and the returned RRs are "bogus". The issue is not that the clients can't use DNSSEC, the issue is that they cannot retrieve DNSSEC records. > A more serious issue for browsers is corporate MITM proxies. > Browsers behind such proxies (much as Chrome does now, since it > "knows" about the certificates of some sites) need to be configured > to enable alternatives to the default TLS security policy. > >> > With a "3 1 1" TLSA RR (matching a leaf cert ultimately signed by >> > a public CA for now), a DANE-aware browser can reliably succeed >> > where the public CA PKI fails, due to: >> > >> > - A rogue CA publishing unauthorized certificates. >> > - An incomplete (whatever that means) CA list on the client >> > - Problems with CRLs >> > >> > What specific problems do you anticipate with DANE TLSA that make >> > it unsafe to "hard-fail"? >> >> See above. > > You have not yet mentioned anything that makes it unsafe to hardfail > when TLSA RRs don't match, or DNSSEC replies are bogus. Otherwise, > DANE does not hard fail. I really don't want to be oppositional, > sorry if it seems that way, difficult to seem otherwise in email. > > It seems there may be some misconceptions about the DANE TLSA PKI > validation model, are you open to exploring this possibility? > > -- > Viktor. > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From viktor1dane@dukhovni.org Thu May 30 09:43:21 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBC9421F9709 for ; Thu, 30 May 2013 09:43:20 -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 w6ZzgV6ALuHB for ; Thu, 30 May 2013 09:43:15 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id BD54521F96FD for ; Thu, 30 May 2013 09:43:15 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 1A8B52AB9CD; Thu, 30 May 2013 16:43:15 +0000 (UTC) Date: Thu, 30 May 2013 16:43:15 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130530164315.GI9380@mournblade.imrryr.org> References: <544B0DD62A64C1448B2DA253C011414607ACD1048F@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <5B925F3A-B122-469D-97F5-7DF8A2262795@kumari.net> <69DCBEB1-396E-4EDF-A86B-CB2483CAD094@NLnetLabs.nl> <20130530151810.GD9380@mournblade.imrryr.org> <20130530155539.GG9380@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Classic PKI and DANE in harmony X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 16:43:21 -0000 On Thu, May 30, 2013 at 05:18:42PM +0100, Ben Laurie wrote: > >> > What specific problems do you anticipate with DANE TLSA that make > >> > it unsafe to "hard-fail"? > >> > >> See above [ I moved it below, so see below ] > > > > You have not yet mentioned anything that makes it unsafe to hardfail > > when TLSA RRs don't match, or DNSSEC replies are bogus. Otherwise, > > DANE does not hard fail. I really don't want to be oppositional, > > sorry if it seems that way, difficult to seem otherwise in email. > > > > It seems there may be some misconceptions about the DANE TLSA PKI > > validation model, are you open to exploring this possibility? So is your concern that at this time DNSSEC lookup are too likely to return "bogus" (rather than with anything specific in DANE itself)? If so, then indeed we're relatively early on the DNSSEC adoption curve, and some issues remain to be addressed in hostile environments such as Hotel/Cafe/Airplane/... public Wifi hotspots that MITM DNS for the terms-of-use click-through and/or customer authentication. The state of the art here is regrettable, we need to have better mechanisms than that for joining public networks, ideally ones that authenticate not only the customer, but also the provider. > >> Our experiments suggest that a _large_ percentage of clients cannot > >> see DNSSEC records at all. > > > > This is fine, they can continue to use legacy PKI. DANE does not > > apply when the client has no DNSSEC support. DANE is not intended > > to "hard fail" when the client can't use DNSSEC. It only hardfails > > when it can and the returned RRs are "bogus". > > The issue is not that the clients can't use DNSSEC, the issue is that > they cannot retrieve DNSSEC records. Well, there's always 8.8.8.8: $ drill -D -t ns com. @8.8.8.8 ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 25827 ;; flags: qr rd ra ad ; QUERY: 1, ANSWER: 14, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;; com. IN NS ;; ANSWER SECTION: com. 21033 IN NS a.gtld-servers.net. ... com. 21033 IN NS m.gtld-servers.net. com. 21033 IN RRSIG NS 8 1 172800 20130603042012 20130527031012 35519 com. nETo/p1pX2mJo+BHZI20iQkgIGVTgbnqZ8vNf+CDy3w4/LJwrtP/r0NLBVzaQ/xpSLrxnkoxY9aRGtuwJp7oTOdTcq9gCN/QYyPuLK4gZT6BwjnOZmlVvyIQK8GKpafpsLniYX2xVGg07f7lpYdmRpMMZS4t5HXo46WZABXyYYU= ;; AUTHORITY SECTION: ;; ADDITIONAL SECTION: ;; Query time: 42 msec ;; EDNS: version 0; flags: do ; udp: 512 ;; SERVER: 8.8.8.8 ;; WHEN: Thu May 30 12:24:24 2013 ;; MSG SIZE rcvd: 419 and while some clients can't get to 8.8.8.8 either (WiFi hot-spot browser MITM use-terms click-through), one simply uses HTTP for that, it is an MITM attack regardless of PKI model. The browser's DNS requests can include the "CD" bit when connecting to non-HTTPS sites, or for mobile devices the O/S can provide a suitable UI for joining mobile networks with the browser employing "CD" just for that context. [ The "CD" bit is "checking disabled" and solicits raw results from the validating cache. ] -- Viktor. From benl@google.com Thu May 30 09:51:35 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3233421F89A5 for ; Thu, 30 May 2013 09:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.727 X-Spam-Level: X-Spam-Status: No, score=-2.727 tagged_above=-999 required=5 tests=[AWL=0.250, 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 kjHwEPdzL2bo for ; Thu, 30 May 2013 09:51:31 -0700 (PDT) Received: from mail-qe0-f42.google.com (mail-qe0-f42.google.com [209.85.128.42]) by ietfa.amsl.com (Postfix) with ESMTP id 1788221F92FB for ; Thu, 30 May 2013 09:51:28 -0700 (PDT) Received: by mail-qe0-f42.google.com with SMTP id cz11so281472qeb.15 for ; Thu, 30 May 2013 09:51:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=osrH5EB+h6XLYCGjFtVIP+pFzYnVJej6Vrk4ym9t6l8=; b=C8PmllvzDQgPAxXKn/EUDLkobCOWRo95dGxxgm/KvTgew6iFxGMRWmHL/31oIrpjXF W/JFhh7XFkQb1hqTHLTjv3QTHB6wXmzKCzL9htSy3sCMsSWpQQtwwURjQeU+fKu2G57s VMQ6iz6yM97Xsi+XZTkYSia6gjPZ2kocgVXuX6t4Um5pWQG4gJmD0g6lTMU0bw6UJnol rKXg8kBHevS9sRdoVewUfZ4BbrwjxsJ0pDpNt3dPSKUAqQDMDkL7K2ugvfNauXr9sysZ +qdMTiL9cl4kd/i4y38AEaA8nd/PuEUbubghUDjouOet/FdbfGQ8abebcBzROTxU3mND KYzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=osrH5EB+h6XLYCGjFtVIP+pFzYnVJej6Vrk4ym9t6l8=; b=UNp5W8BfOM+OU210PecC9YvXvMF+FsKpYEj+9zKAxIWteyWiLcP4WX2o0sgFTL2hG1 k1nwLKNJ5PVZ0G0gvugQbVC0Yj668q1pi/Y/ZLfvi245MLD0jRrXUvo2AC9Epx1yltXh /h4rQVFSvCiPIP+gkGk18ToDe+gIPNpQN0UhQVKRFYmj69E5GsVEi3zU2wDrC3PiJQ7f VpbhYwmbqkdeB0z0m9hUGVbIynW9aQ+qJ7hdBztcfobHgg9RxX2CDpGg438PlP5toPUm z2OB/VJ6mjlrAQAfpSkqDhzkC518FchFfM64VNCRU+V62TFyRYlSVxD0+Xh8/onzL0Dt mfXQ== MIME-Version: 1.0 X-Received: by 10.224.58.135 with SMTP id g7mr7163769qah.49.1369932688279; Thu, 30 May 2013 09:51:28 -0700 (PDT) Received: by 10.49.87.225 with HTTP; Thu, 30 May 2013 09:51:28 -0700 (PDT) In-Reply-To: <20130530164315.GI9380@mournblade.imrryr.org> References: <544B0DD62A64C1448B2DA253C011414607ACD1048F@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <5B925F3A-B122-469D-97F5-7DF8A2262795@kumari.net> <69DCBEB1-396E-4EDF-A86B-CB2483CAD094@NLnetLabs.nl> <20130530151810.GD9380@mournblade.imrryr.org> <20130530155539.GG9380@mournblade.imrryr.org> <20130530164315.GI9380@mournblade.imrryr.org> Date: Thu, 30 May 2013 17:51:28 +0100 Message-ID: From: Ben Laurie To: IETF DANE WG list Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmA47KP78B5BjNbKTmLv1OgnYkEhDkGlSJ2VHmEdt7Hdu3Gkux/a02mVkpe6/NEzofgYhLTLi5zNEueT0Ylukk2PlxNUHSniD3nb1bGccKnorM8LwIoU7GHnkLytws0+/7v01U9iy9kvvIfjLPd4NfEPMnyGNfBt1bUzfVMvd54bJ2pXV5oH0spr827H75/8Pg7FSz5 Subject: Re: [dane] Classic PKI and DANE in harmony X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 May 2013 16:51:35 -0000 On 30 May 2013 17:43, Viktor Dukhovni wrote: > On Thu, May 30, 2013 at 05:18:42PM +0100, Ben Laurie wrote: > >> >> > What specific problems do you anticipate with DANE TLSA that make >> >> > it unsafe to "hard-fail"? >> >> >> >> See above [ I moved it below, so see below ] >> > >> > You have not yet mentioned anything that makes it unsafe to hardfail >> > when TLSA RRs don't match, or DNSSEC replies are bogus. Otherwise, >> > DANE does not hard fail. I really don't want to be oppositional, >> > sorry if it seems that way, difficult to seem otherwise in email. >> > >> > It seems there may be some misconceptions about the DANE TLSA PKI >> > validation model, are you open to exploring this possibility? > > So is your concern that at this time DNSSEC lookup are too likely to > return "bogus" (rather than with anything specific in DANE itself)? Indeed. > If so, then indeed we're relatively early on the DNSSEC adoption > curve, and some issues remain to be addressed in hostile environments > such as Hotel/Cafe/Airplane/... public Wifi hotspots that MITM DNS > for the terms-of-use click-through and/or customer authentication. > > The state of the art here is regrettable, we need to have better > mechanisms than that for joining public networks, ideally ones that > authenticate not only the customer, but also the provider. > >> >> Our experiments suggest that a _large_ percentage of clients cannot >> >> see DNSSEC records at all. >> > >> > This is fine, they can continue to use legacy PKI. DANE does not >> > apply when the client has no DNSSEC support. DANE is not intended >> > to "hard fail" when the client can't use DNSSEC. It only hardfails >> > when it can and the returned RRs are "bogus". >> >> The issue is not that the clients can't use DNSSEC, the issue is that >> they cannot retrieve DNSSEC records. > > Well, there's always 8.8.8.8: How does that help if you can't retrieve DNSSEC records? > $ drill -D -t ns com. @8.8.8.8 > ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 25827 > ;; flags: qr rd ra ad ; QUERY: 1, ANSWER: 14, AUTHORITY: 0, ADDITIONAL: 0 > ;; QUESTION SECTION: > ;; com. IN NS > > ;; ANSWER SECTION: > com. 21033 IN NS a.gtld-servers.net. > ... > com. 21033 IN NS m.gtld-servers.net. > com. 21033 IN RRSIG NS 8 1 172800 20130603042012 20130527031012 > 35519 com. > nETo/p1pX2mJo+BHZI20iQkgIGVTgbnqZ8vNf+CDy3w4/LJwrtP/r0NLBVzaQ/xpSLrxnkoxY9aRGtuwJp7oTOdTcq9gCN/QYyPuLK4gZT6BwjnOZmlVvyIQK8GKpafpsLniYX2xVGg07f7lpYdmRpMMZS4t5HXo46WZABXyYYU= > > ;; AUTHORITY SECTION: > > ;; ADDITIONAL SECTION: > > ;; Query time: 42 msec > ;; EDNS: version 0; flags: do ; udp: 512 > ;; SERVER: 8.8.8.8 > ;; WHEN: Thu May 30 12:24:24 2013 > ;; MSG SIZE rcvd: 419 > > and while some clients can't get to 8.8.8.8 either (WiFi hot-spot > browser MITM use-terms click-through), one simply uses HTTP for > that, it is an MITM attack regardless of PKI model. > > The browser's DNS requests can include the "CD" bit when connecting > to non-HTTPS sites, or for mobile devices the O/S can provide a > suitable UI for joining mobile networks with the browser employing > "CD" just for that context. > > [ The "CD" bit is "checking disabled" and solicits raw results from > the validating cache. ] > > -- > Viktor. > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From viktor1dane@dukhovni.org Thu May 30 10:02:58 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7D921F8733 for ; Thu, 30 May 2013 10:02:58 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T+8pHUhy9mst for ; Thu, 30 May 2013 10:02:53 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id DBB2021F8E6E for ; Thu, 30 May 2013 10:02:52 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 7B5A62AB9CD; Thu, 30 May 2013 17:02:52 +0000 (UTC) Date: Thu, 30 May 2013 17:02:52 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130530170252.GK9380@mournblade.imrryr.org> References: <5B925F3A-B122-469D-97F5-7DF8A2262795@kumari.net> <69DCBEB1-396E-4EDF-A86B-CB2483CAD094@NLnetLabs.nl> <20130530151810.GD9380@mournblade.imrryr.org> <20130530155539.GG9380@mournblade.imrryr.org> <20130530164315.GI9380@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Classic PKI and DANE in harmony X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 17:02:58 -0000 On Thu, May 30, 2013 at 05:51:28PM +0100, Ben Laurie wrote: > > So is your concern that at this time DNSSEC lookup are too likely to > > return "bogus" (rather than with anything specific in DANE itself)? > > Indeed. Understood. There are perhaps work-arounds, and this should improve over time. > >> The issue is not that the clients can't use DNSSEC, the issue is that > >> they cannot retrieve DNSSEC records. > > > > Well, there's always 8.8.8.8: > > How does that help if you can't retrieve DNSSEC records? The Google 8.8.8.8 DNS cache does return DNSSEC records, as shown below: So clients that can reach 8.8.8.8 or similar, can bypass their ISP's cache when the ISP cache is DNSSEC hostile. The remaining issue is jailed clients joining hotspots, ... that may not be able to reach any external DNS servers. This too can be addressed (for example via the "CD" bit and HTTP and perhaps a UI for joining networks that disables DNSSEC until the mobile device is out of jail). Longer term joining public networks should be handled at the 802.1X layer with suitable mobile devices UIs. Not via MITM on DNS and browsers. > > $ drill -D -t ns com. @8.8.8.8 > > ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 25827 > > ;; flags: qr rd ra ad ; QUERY: 1, ANSWER: 14, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > > ;; com. IN NS > > > > ;; ANSWER SECTION: > > com. 21033 IN NS a.gtld-servers.net. > > ... > > com. 21033 IN NS m.gtld-servers.net. > > com. 21033 IN RRSIG NS 8 1 172800 20130603042012 20130527031012 35519 com. nETo/p1pX2mJo+BHZI20iQkgIGVTgbnqZ8vNf+CDy3w4/LJwrtP/r0NLBVzaQ/xpSLrxnkoxY9aRGtuwJp7oTOdTcq9gCN/QYyPuLK4gZT6BwjnOZmlVvyIQK8GKpafpsLniYX2xVGg07f7lpYdmRpMMZS4t5HXo46WZABXyYYU= -- Viktor. From guido@witmond.nl Thu May 30 15:46:59 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D95C21F85C9 for ; Thu, 30 May 2013 15:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.503 X-Spam-Level: X-Spam-Status: No, score=-0.503 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, WEIRD_PORT=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 HGuqIQSNSxcy for ; Thu, 30 May 2013 15:46:55 -0700 (PDT) Received: from smtp-vbr13.xs4all.nl (smtp-vbr13.xs4all.nl [194.109.24.33]) by ietfa.amsl.com (Postfix) with ESMTP id 16BE821F85BB for ; Thu, 30 May 2013 15:46:53 -0700 (PDT) Received: from [10.1.2.6] (mail.witmond.nl [80.100.189.3] (may be forged)) by smtp-vbr13.xs4all.nl (8.13.8/8.13.8) with ESMTP id r4UMkqPT096168 for ; Fri, 31 May 2013 00:46:52 +0200 (CEST) (envelope-from guido@witmond.nl) Message-ID: <51A7D6DC.9040706@witmond.nl> Date: Fri, 31 May 2013 00:46:52 +0200 From: Guido Witmond User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: dane@ietf.org References: <20130525103051.GC12066@lavabit.com> <20130525144214.GD9380@mournblade.imrryr.org> <0lr4gryyn4.fsf@wjh.hardakers.net> <20130528155111.GG9380@mournblade.imrryr.org> <51A55222.7020800@inventati.org> <20130529012949.GR9380@mournblade.imrryr.org> In-Reply-To: <20130529012949.GR9380@mournblade.imrryr.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Subject: Re: [dane] Few questions X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 May 2013 22:46:59 -0000 On 29-05-13 03:29, Viktor Dukhovni wrote: > On Tue, May 28, 2013 at 05:56:02PM -0700, Bry8 Star wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- > > http://xkcd.com/1181 > >> on windows side, users (including me) are using, two firefox addons: >> "Extended DNSSSEC Validator" (www.os3sec.org), > > The code I found for this on github does not support certificate > usage 0 or 1 and ignores the TLSA RR selector, always matching the > certificate and not the public key. It appears to hardcode port > 443 for TLSA RR lookups, rather than use the port from the URI. > It is far from clear how it handles name checks. Likely many more > problems. > > At first glance it is a toy not suitable for serious use. > > > Perhaps someone else can take a stab at it. My impression is that > a non-trivial fraction of the early implementations are substantively > flawed. Caveat emptor. > I've updated the Extended DNSSEC Validator up to 0.8 in the past and got its maintainer Danny to incorporate my changes. Is has all the flaws mentioned before but I consider it a good start. And no, not ready for production, yet. I've got some more updates. It validates TLSA 2 0 0 correctly. Just check out https://dating.wtmnd.nl:10443/ with it. It has a valid 2 0 0 certificate. It should validate. You can find my toy at: https://github.com/gwitmond/Extended-DNSSEC-Validator.git Cheers, Guido Witmond. From sm@resistor.net Thu May 30 17:27:59 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3704D21F8FEB for ; Thu, 30 May 2013 17:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.363 X-Spam-Level: X-Spam-Status: No, score=-102.363 tagged_above=-999 required=5 tests=[AWL=0.236, 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 3yeK-pkZkAov for ; Thu, 30 May 2013 17:27:58 -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 58DFC21F8FBE for ; Thu, 30 May 2013 17:27:58 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r4V0RqNJ001381 for ; Thu, 30 May 2013 17:27:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1369960076; bh=+fGttqU4hIhXFo7FavzWzZPpqz5irYbiBFWV2zidl6Q=; h=Date:To:From:Subject:In-Reply-To:References; b=HEN31GS6PiNYRIDOgEtIYNgziTHysqaTdzpK5Er7OUoob5oyOz1iGKXNldEU3Pa7S spEQ+scxCD+FRX6lXvTFSVMJPKAHLYB2ZoFkqGsfU0neD9AMHYtiRZkgJn+dge+Bc3 eUu1uw/e61mviGgSgqeBPLGKUAc51EwtDrAvdPRU= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1369960076; i=@resistor.net; bh=+fGttqU4hIhXFo7FavzWzZPpqz5irYbiBFWV2zidl6Q=; h=Date:To:From:Subject:In-Reply-To:References; b=KX4bTeLi9ATi/VRuQ9dAnNj48yKtqjxfqTl5DEuU2nkCP91rg/7QtsKz9HLHeYZaA VDx98dC8QEaZJVEGZW6v5ho4U4Kn1wnYQMcc0MDiVUKqkyo47a7Ayo6fuHKGurbzF2 HeTLNAi5XtaB3NKG8aGGx9R9AhR0hyvMuzXDgeS4= Message-Id: <6.2.5.6.2.20130530172233.0cf302f0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 30 May 2013 17:23:40 -0700 To: dane@ietf.org From: SM In-Reply-To: References: <20130529143710.GV9380@mournblade.imrryr.org> <20130529184555.GY9380@mournblade.imrryr.org> <544B0DD62A64C1448B2DA253C011414607ACD1048F@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <5B925F3A-B122-469D-97F5-7DF8A2262795@kumari.net> <69DCBEB1-396E-4EDF-A86B-CB2483CAD094@NLnetLabs.nl> <20130530151810.GD9380@mournblade.imrryr.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [dane] Classic PKI and DANE in harmony X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2013 00:27:59 -0000 At 08:41 30-05-2013, Ben Laurie wrote: >Even if this were true, first hit latency matters, too. As anecdotal >evidence, I just resolved a name unlikely to be cached locally: > >$ dig www.disney.com >;; Query time: 535 msec > >Unacceptable. ;; Query time: 1221 msec Regards, -sm From viktor1dane@dukhovni.org Thu May 30 20:11:04 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD9C221F896D for ; Thu, 30 May 2013 20:11:04 -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 LbSfaBc7-EIu for ; Thu, 30 May 2013 20:10:57 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 4053721F992E for ; Thu, 30 May 2013 20:10:57 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 480092AB9D4; Fri, 31 May 2013 03:10:56 +0000 (UTC) Date: Fri, 31 May 2013 03:10:56 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130531031056.GO9380@mournblade.imrryr.org> References: <20130525103051.GC12066@lavabit.com> <20130525144214.GD9380@mournblade.imrryr.org> <0lr4gryyn4.fsf@wjh.hardakers.net> <20130528155111.GG9380@mournblade.imrryr.org> <51A55222.7020800@inventati.org> <20130529012949.GR9380@mournblade.imrryr.org> <51A7D6DC.9040706@witmond.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51A7D6DC.9040706@witmond.nl> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Few questions X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 03:11:05 -0000 On Fri, May 31, 2013 at 12:46:52AM +0200, Guido Witmond wrote: > >Perhaps someone else can take a stab at it. My impression is that > >a non-trivial fraction of the early implementations are substantively > >flawed. Caveat emptor. > > > > I've updated the Extended DNSSEC Validator up to 0.8 in the past and > got its maintainer Danny to incorporate my changes. Is has all the > flaws mentioned before but I consider it a good start. > And no, not ready for production, yet. More than "not ready for production" it is deeply flawed. It fails to check that the certificates in the "chain" are actually linked to each other with each issuer at depth n+1 verified as the signer of an unexpired subject certificate at depth n. It also does not check basic constraints or key usage bits. It is trivial to concoct bogus chains that pass validation via this extension. Testing that it validates correct chains is the easy part, it MUST fail to validate invalid chains, and here it bombs spectularly. Programmers inexperienced in writing security code (thinking like an attacker and handling not only the expected but also malicious input) should not attempt DANE implementations. Users should steer clear of amateur DANE implementations. -- Viktor. From olaf@NLnetLabs.nl Fri May 31 01:42:28 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14B0A21F8C20 for ; Fri, 31 May 2013 01:42:28 -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, HTML_MESSAGE=0.001, 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 5jwq4lI-TtBO for ; Fri, 31 May 2013 01:42:26 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id A881521F8930 for ; Fri, 31 May 2013 01:42:25 -0700 (PDT) Received: from [IPv6:2001:7b8:206:1:7211:24ff:fe8c:627a] ([IPv6:2001:7b8:206:1:7211:24ff:fe8c:627a]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.7/8.14.4) with ESMTP id r4V8gMBt043717 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 31 May 2013 10:42:23 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) Authentication-Results: open.nlnetlabs.nl; dmarc=none header.from=NLnetLabs.nl DKIM-Filter: OpenDKIM Filter v2.8.2 open.nlnetlabs.nl r4V8gMBt043717 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1369989744; bh=6iqfThwsBtsmuCeVA8T2WtEf0RXLxu9zbhh+ba7Hfd8=; h=From:Subject:Date:References:To:In-Reply-To; b=hwNG4nDDucZjd+wg6v/XIyhPrC6BBwxA1fZhW9bdXPxpJIGZUki6+41PnKYS/rCFA grN5zfBQfnZn1ZyTdOcqrX3qAFQTeMaFIPYLUzBTViIBVPZPdGcdxCMO6PArxOxkFY bgF7GImFAfSF14h/OGZEzqaAziEKX8gjRbsSjDnA= From: Olaf Kolkman Content-Type: multipart/alternative; boundary="Apple-Mail=_DE6126EB-F715-4C3F-92D4-BEBF354CFAF6" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Date: Fri, 31 May 2013 10:42:22 +0200 References: <5B925F3A-B122-469D-97F5-7DF8A2262795@kumari.net> <69DCBEB1-396E-4EDF-A86B-CB2483CAD094@NLnetLabs.nl> <20130530151810.GD9380@mournblade.imrryr.org> <20130530155539.GG9380@mournblade.imrryr.org> <20130530164315.GI9380@mournblade.imrryr.org> <20130530170252.GK9380@mournblade.imrryr.org> To: dane@ietf.org In-Reply-To: <20130530170252.GK9380@mournblade.imrryr.org> X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Fri, 31 May 2013 10:42:23 +0200 (CEST) Subject: [dane] DNSSEC-last-mile experience ( Was: Classic PKI and DANE in harmony ) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2013 08:42:28 -0000 --Apple-Mail=_DE6126EB-F715-4C3F-92D4-BEBF354CFAF6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 30, 2013, at 7:02 PM, Viktor Dukhovni = wrote: >> How does that help if you can't retrieve DNSSEC records? >=20 > The Google 8.8.8.8 DNS cache does return DNSSEC records, as shown > below: So clients that can reach 8.8.8.8 or similar, can bypass > their ISP's cache when the ISP cache is DNSSEC hostile. >=20 > The remaining issue is jailed clients joining hotspots, ... that > may not be able to reach any external DNS servers. This too can > be addressed (for example via the "CD" bit and HTTP and perhaps > a UI for joining networks that disables DNSSEC until the mobile > device is out of jail). I am very interested in the last-mile and one of the ways we've tried to = approach the last mile is by allowing folk to try. Enter = dnssec-trigger, a tool that does some config magic and allows you to run = a validating resolver on 127.0.0.1. At this moment it is clear to me that what we've done is not yet at the = consumer level, on the other hand we are building a corpus of = operational experience on the type of problems people run into. I = invite/encourage folk to try the tool and help us build experience by = sharing their experiences on the dnssec-trigger mailinglist. My = personal experience is that you will need to understand a bit of = troubleshooting and an occassional "unbound-control flush_zone ." to get = you out of misery. (See https://www.nlnetlabs.nl/projects/dnssec-trigger/ which is signed = by CACERT, for which most of you will not have a trust-anchor in their = browser, however it www.nlnetlabs.nl comes with a TLSA record, oh irony) --Olaf PS Chairs, I accept a slap if this is on the wrong side of the border of = promotion. --Apple-Mail=_DE6126EB-F715-4C3F-92D4-BEBF354CFAF6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii viktor1dane@dukhovni.org> = wrote:
How = does that help if you can't retrieve DNSSEC records?

below:  So clients that can reach = 8.8.8.8 or similar, can bypass
their ISP's cache when the = ISP cache is DNSSEC hostile.

may not be able to reach any external = DNS servers.  This too can
be addressed (for example via = the "CD" bit and HTTP and perhaps
a UI for joining networks = that disables DNSSEC until the mobile
device is out of = jail).


I am very = interested in the last-mile and one of the ways we've tried to approach = the last mile is by allowing folk to try.  Enter dnssec-trigger, a = tool that does some config magic and allows you to run a validating = resolver on 127.0.0.1.

At this moment it is = clear to me that what we've done is not yet at the consumer level, on = the other hand we are building a corpus of  operational experience = on the type of problems people run into. I invite/encourage folk to try = the tool and help us build experience by sharing their experiences on = the dnssec-trigger mailinglist.  My personal experience is that you = will need to understand a bit of troubleshooting and an occassional = "unbound-control flush_zone ." to get you out of = misery.

(See https://www.nln= etlabs.nl/projects/dnssec-trigger/ which is signed by CACERT, for = which most of you will not have a trust-anchor in their browser, however = it www.nlnetlabs.nl comes with a = TLSA record, oh = irony)


--Olaf

=
PS Chairs, I accept a slap if this is on the wrong side of the = border of promotion.

= --Apple-Mail=_DE6126EB-F715-4C3F-92D4-BEBF354CFAF6-- From guido@witmond.nl Fri May 31 02:56:05 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCFCD21F967F for ; Fri, 31 May 2013 02:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 yMMJTVpwkSwv for ; Fri, 31 May 2013 02:56:00 -0700 (PDT) Received: from smtp-vbr13.xs4all.nl (smtp-vbr13.xs4all.nl [194.109.24.33]) by ietfa.amsl.com (Postfix) with ESMTP id 967A421F86C4 for ; Fri, 31 May 2013 02:55:59 -0700 (PDT) Received: from [10.1.2.6] (mail.witmond.nl [80.100.189.3] (may be forged)) by smtp-vbr13.xs4all.nl (8.13.8/8.13.8) with ESMTP id r4V9txvT061268 for ; Fri, 31 May 2013 11:55:59 +0200 (CEST) (envelope-from guido@witmond.nl) Message-ID: <51A873AE.9030705@witmond.nl> Date: Fri, 31 May 2013 11:55:58 +0200 From: Guido Witmond User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: dane@ietf.org References: <20130525103051.GC12066@lavabit.com> <20130525144214.GD9380@mournblade.imrryr.org> <0lr4gryyn4.fsf@wjh.hardakers.net> <20130528155111.GG9380@mournblade.imrryr.org> <51A55222.7020800@inventati.org> <20130529012949.GR9380@mournblade.imrryr.org> <51A7D6DC.9040706@witmond.nl> <20130531031056.GO9380@mournblade.imrryr.org> In-Reply-To: <20130531031056.GO9380@mournblade.imrryr.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Subject: Re: [dane] Few questions X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2013 09:56:06 -0000 On 31-05-13 05:10, Viktor Dukhovni wrote: > On Fri, May 31, 2013 at 12:46:52AM +0200, Guido Witmond wrote: > >>> Perhaps someone else can take a stab at it. My impression is >>> that a non-trivial fraction of the early implementations are >>> substantively flawed. Caveat emptor. >>> >> >> I've updated the Extended DNSSEC Validator up to 0.8 in the past >> and got its maintainer Danny to incorporate my changes. Is has all >> the flaws mentioned before but I consider it a good start. And no, >> not ready for production, yet. > > More than "not ready for production" it is deeply flawed. It fails > to check that the certificates in the "chain" are actually linked to > each other with each issuer at depth n+1 verified as the signer of an > unexpired subject certificate at depth n. It also does not check > basic constraints or key usage bits. It is trivial to concoct bogus > chains that pass validation via this extension. > > Testing that it validates correct chains is the easy part, it MUST > fail to validate invalid chains, and here it bombs spectularly. You are completely right. Thank you for pointing those out, it helps me on my journey to become an expert. One has to start somewhere... :-) For me, this plug in is what got me interested in DNSSEC and DANE. I'm very grateful of all the hard work that the real experts have done on it. Without it we cannot leave the current PKI(X) mess of having other people to decide which Certificate Authorities I have to trust. With DANE usage 2 0 0, we can do even more than just authenticate a web site to a browser. We can bootstrap secure, private, anonymous client certificates for the web. [1] > Users should steer clear of amateur DANE implementations. Flamebait: I hope that users, developers, journalists, politicians, all start to use this flawed plug in to see what can be done and demand a more safe and secure internet without global CA's violating our trust by selling root certificates for MitM-spydevices. Respectfully, Guido Witmond. [1]: http://eccentric-authentication.org/ From viktor1dane@dukhovni.org Fri May 31 06:29:25 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 381B021F9058 for ; Fri, 31 May 2013 06:29:25 -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 jfZljItTpF9s for ; Fri, 31 May 2013 06:29:19 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id A889C21F9050 for ; Fri, 31 May 2013 06:29:19 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 9C9FF2AB9D9; Fri, 31 May 2013 13:29:18 +0000 (UTC) Date: Fri, 31 May 2013 13:29:18 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130531132918.GR9380@mournblade.imrryr.org> References: <72C4F0E4-9A12-4FA9-9B25-4724F5E4AAB5@kirei.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <72C4F0E4-9A12-4FA9-9B25-4724F5E4AAB5@kirei.se> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Classic PKI and DANE in harmony X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 13:29:25 -0000 On Thu, May 30, 2013 at 02:53:21PM +0200, Jakob Schlyter wrote: > > So with Usage 2 the own CA can be everything, from an online CA, > > storing the private key in the public accessible webroot, enabling > > everyone who recognized it to issue certs for the domain by himself. > > There is not practical difference between usage 2 and 3 - it is > just a choice of levels of indirection. There is a big difference in the implementation robustness. With usage 3 the client looks only at the peer certificate or public key. - The server operator cannot accidentally leave out the required intermediate CAs from his chain (one of the most frequent administrator caused failure modes for TLS). - The client does not perform name checks, so a lot less can fail. Therefore, while 2 and 3 are very similar in theory (when administrators don't make mistakes and client implementations are bug free), the usage 3 TLSA RR is far more likely to be robust in practice. I'll add something to the operations draft about usage 3: - Servers SHOULD use a certificate with subjectAltname DNS entries that matches the base domains of all relevant TLSA RRs even with usage 3, because some client implementations may erroneously insist on checking the subject name in usage 3 certificates. - Clients MUST ignore the subject name in usage 3 cerficates, checking for a matching certificate or public key is the only check the client needs to perform. -- Viktor. From ondrej.sury@nic.cz Fri May 31 07:12:37 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEFE421F89C3 for ; Fri, 31 May 2013 07:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[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 BaGvfsLTqqiw for ; Fri, 31 May 2013 07:12:37 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id BAEB021F896D for ; Fri, 31 May 2013 07:12:36 -0700 (PDT) Received: from labs.ondrej.sury.ws.eth.9.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 89FBF13F778 for ; Fri, 31 May 2013 16:12:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1370009554; bh=7o4zZQgrkcLZzLrrXPOAofgmpInuno6HpKsx6M9BmPY=; h=From:Content-Type:Message-Id:Mime-Version:Subject:Date:References: To:In-Reply-To; b=FzNZCXk4BOhBd2FNZG3sM1HHokGldpM4hSHOvidvhjJ06hSq338ek/OpDRB4nta43 Ko7uJyPFCKdFgurZOkjazyMV6QI/vsjBtT6clb2LGrjbun++HDbnoX2n8UAhjyVB3a ss0fPwhx2cGyywASbRwHcimBiMa67YZB0+QadlTc= From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= Content-Type: multipart/signed; boundary="Apple-Mail=_FED52447-6B2B-44B0-990A-AE8DF726E949"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: <771A63D5-F0E2-4830-95CA-F15410A1088B@nic.cz> Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Date: Fri, 31 May 2013 16:12:32 +0200 References: <20130525103051.GC12066@lavabit.com> <20130525144214.GD9380@mournblade.imrryr.org> <0lr4gryyn4.fsf@wjh.hardakers.net> <20130528155111.GG9380@mournblade.imrryr.org> <51A55222.7020800@inventati.org> <20130529012949.GR9380@mournblade.imrryr.org> To: dane@ietf.org In-Reply-To: <20130529012949.GR9380@mournblade.imrryr.org> X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Subject: Re: [dane] Few questions X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2013 14:12:37 -0000 --Apple-Mail=_FED52447-6B2B-44B0-990A-AE8DF726E949 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 29. 5. 2013, at 3:29, Viktor Dukhovni = wrote: > I have not had a chance to look at this in detail and I don't know > much about writing browser plugins, so it is not clear how one > robustly hooks into the browser's HTTPS connection establishment > process. Generally it's a post-connection hook. (Same as Cert Patrol, etc.) DNSSEC-Validator (we are the authors) doesn't have DANE support yet, = it's planned to be in 2.1.0 version of the add-on. > I would recommend using browsers that support DANE natively, > via a properly reviewed implementation in the browser itself. I'd be > suspicious of the safety of addons. I do agree with you, but there are none usable native-DANE-support = browsers. > Perhaps someone else can take a stab at it. My impression is that > a non-trivial fraction of the early implementations are substantively > flawed. Caveat emptor. -- Ond=C5=99ej Sur=C3=BD -- Chief Science Officer ------------------------------------------- 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 ------------------------------------------- --Apple-Mail=_FED52447-6B2B-44B0-990A-AE8DF726E949 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMKTCCBgYw ggTuoAMCAQICAQIwDQYJKoZIhvcNAQEFBQAwga8xCzAJBgNVBAYTAk5MMSAwHgYDVQQKExdUcnVz dGVkIEludHJvZHVjZXIgKFRJKTEgMB4GA1UECxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxMzAx BgNVBAMTKlRydXN0ZWQgSW50cm9kdWNlciAoVEkpIFRvcGxldmVsIENBIC0gRzAwMTEnMCUGCSqG SIb3DQEJARYYY2FAdHJ1c3RlZC1pbnRyb2R1Y2VyLm5sMB4XDTA0MTIwNzEwMzYxN1oXDTMwMTIw NjAwMDAwMFowga0xCzAJBgNVBAYTAk5MMSAwHgYDVQQKExdUcnVzdGVkIEludHJvZHVjZXIgKFRJ KTEgMB4GA1UECxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxMTAvBgNVBAMTKFRydXN0ZWQgSW50 cm9kdWNlciAoVEkpIENsaWVudCBDQSAtIEcwMDExJzAlBgkqhkiG9w0BCQEWGGNhQHRydXN0ZWQt aW50cm9kdWNlci5ubDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOKQxMR3KDUpfJBz AhY2BPCByKo9SMp/V0RIboLBD6vO0miSYO9FmP3Q07OKPYR5WdlQyrpKqB1zl0SRz2cDjnYkzvDF vK5kvMvlTYeQlHypQlvhkTsYWD4ZZxxEhAYBb1s7cYaIahLw6H/RZz+kyWTOc9TncPBvBWIQ1Ypo S+uQqpopH8s5ebtB/17SbUty5yXiHoaPh/ScdMKqxbyJiL0YRM6SU4YX4HVZ5YGS9aWuiUSiA0YF 8dCR56nErx67wgq8O1GtsSKKOf/ueUxSmrqwgQNlfM9Or5O8kb61s1O2iACHtixoV3ENanylBafU mRYpNo5tSZsElGfntMoGBy8CAwEAAaOCAiswggInMB0GA1UdDgQWBBSeX93lU8ExaSlN1ZaXxfOP h2iHTjCB3AYDVR0jBIHUMIHRgBRdbehwJx/8iwlxnguJECc7MUXvoqGBtaSBsjCBrzELMAkGA1UE BhMCTkwxIDAeBgNVBAoTF1RydXN0ZWQgSW50cm9kdWNlciAoVEkpMSAwHgYDVQQLExdDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTEzMDEGA1UEAxMqVHJ1c3RlZCBJbnRyb2R1Y2VyIChUSSkgVG9wbGV2 ZWwgQ0EgLSBHMDAxMScwJQYJKoZIhvcNAQkBFhhjYUB0cnVzdGVkLWludHJvZHVjZXIubmyCAQAw DwYDVR0TAQH/BAUwAwEB/zAjBgNVHRIEHDAagRhjYUB0cnVzdGVkLWludHJvZHVjZXIubmwwgasG A1UdHwSBozCBoDBOoEygSoZIaHR0cDovL2NybDEudHJ1c3RlZC1pbnRyb2R1Y2VyLm5sL2NhL3g1 MDkvZzEvZGF0YS9jcmxzL2NybC1yb290LWNhLTEuY3JsME6gTKBKhkhodHRwOi8vY3JsMi50cnVz dGVkLWludHJvZHVjZXIubmwvY2EveDUwOS9nMS9kYXRhL2NybHMvY3JsLXJvb3QtY2EtMS5jcmww IwYDVR0RBBwwGoEYY2FAdHJ1c3RlZC1pbnRyb2R1Y2VyLm5sMAsGA1UdDwQEAwIBBjARBglghkgB hvhCAQEEBAMCAAcwDQYJKoZIhvcNAQEFBQADggEBAI1sC2l8st3ElC74az6gH7tGXSiS7jicpHeI 10A3KY+7OEPT7BAJDpjMXxSvAwU1vBDFfwEAXGj42xAPB6cynOTDn0OiFpYGvi3EZV3khXYkGPLs fxZttUyDKqhXcWYy4nnI3fBxqCgLboJFw6OO/SVj5qQdXMZ7VhyFBWJMQkVOnlt6i3xFkG3O5LMI BDmdL5bZPEe8b6bJkMr+rUYEvorPJmV+CkiewYMaruCbdhwRkpkhXB3qLwB2ppnKxSinAU4f9Rcp p73h8iDVQ9389iliUKomVQqj9NJv2G6SyJdDQdN2vrldLszNpw6t+zIzCjpgQ//kem5BJ1k4YG3L CpAwggYbMIIFA6ADAgECAgIGSDANBgkqhkiG9w0BAQUFADCBrTELMAkGA1UEBhMCTkwxIDAeBgNV BAoTF1RydXN0ZWQgSW50cm9kdWNlciAoVEkpMSAwHgYDVQQLExdDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTExMC8GA1UEAxMoVHJ1c3RlZCBJbnRyb2R1Y2VyIChUSSkgQ2xpZW50IENBIC0gRzAwMTEn MCUGCSqGSIb3DQEJARYYY2FAdHJ1c3RlZC1pbnRyb2R1Y2VyLm5sMB4XDTEyMDgwMTA3NTEyNloX DTE0MDgwMTA3NTEyNlowejELMAkGA1UEBhMCTkwxGzAZBgNVBAoTElRydXN0ZWQgSW50cm9kdWNl cjEVMBMGA1UECxMMQ1ouTklDLUNTSVJUMRQwEgYDVQQDEwtPbmRyZWogU3VyeTEhMB8GCSqGSIb3 DQEJARYSb25kcmVqLnN1cnlAbmljLmN6MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA xlmN+hSg6RxWm1X6QOI3OXHSAqhRzWGb8ismR2+3LGDS640luS8x4VdWo490Ceqz+BZvMhQJwfny 9mb0IejFpx7kBOM7k2rMfOYUXa/pq07ysWEI8bXDcXRBf2ZcG0B/gajLPFA9MADlCWHSf7cNZF6S XnIHwTn5DowxpbF403NqLWFnTM08wTJkFgGB7WZAtE6KoSigztI39NrtKRsnosZoBMNZS/JG1CLt VdZPvkHVuiVQWEGYgswBEMGXoR7jtzVNhHr2F1atoBICJVGWFNA8fHvQRLAcXWJTXhKxb2uSq9Yp kKaZPZ6rrp88qtemvwVnQKE9r3/iPFeTARY7AQIDAQABo4ICdTCCAnEwDAYDVR0TAQH/BAIwADAd BgNVHQ4EFgQUgizwG0IeMZQlCSduLVeM1zDBdUEwgdwGA1UdIwSB1DCB0YAUnl/d5VPBMWkpTdWW l8Xzj4doh06hgbWkgbIwga8xCzAJBgNVBAYTAk5MMSAwHgYDVQQKExdUcnVzdGVkIEludHJvZHVj ZXIgKFRJKTEgMB4GA1UECxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxMzAxBgNVBAMTKlRydXN0 ZWQgSW50cm9kdWNlciAoVEkpIFRvcGxldmVsIENBIC0gRzAwMTEnMCUGCSqGSIb3DQEJARYYY2FA dHJ1c3RlZC1pbnRyb2R1Y2VyLm5sggECMCMGA1UdEgQcMBqBGGNhQHRydXN0ZWQtaW50cm9kdWNl ci5ubDAdBgNVHREEFjAUgRJvbmRyZWouc3VyeUBuaWMuY3owCwYDVR0PBAQDAgSwMCcGA1UdJQQg MB4GCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwEQYJYIZIAYb4QgEBBAQDAgSwMIHVBgNV HR8Egc0wgcowY6BhoF+GXWh0dHA6Ly9jcmwxLnRydXN0ZWQtaW50cm9kdWNlci5ubC9jYS94NTA5 L2cxL2NhLXNzbC1jbGllbnQvZzEvZGF0YS9jcmxzL2NybC1jbGllbnQtY2EtMS0xLmNybDBjoGGg X4ZdaHR0cDovL2NybDIudHJ1c3RlZC1pbnRyb2R1Y2VyLm5sL2NhL3g1MDkvZzEvY2Etc3NsLWNs aWVudC9nMS9kYXRhL2NybHMvY3JsLWNsaWVudC1jYS0xLTEuY3JsMA0GCSqGSIb3DQEBBQUAA4IB AQAZP/dznHW3BWajBVQ3fTaDsx/3csUE6+jX83r1dgzYjUOmapOzXQVZ2/VTwZTzJSsD7rDgzUN6 sk6YWmUJOwqoEcPasYG9zt9e+bpwc/PURjSowb+WjEE2e4L47x3mPgL0dtlGj4guhRaj247K9N1f grvlyX0h/IL9JO4CN0I5lAuOaZ3Yfl0euHpHLlXZ9czxkc6dCbtGSZwr3RrltNmMjhp0O3D51fDd D6mG1vvOEV9Kj1JfSE2cQI5j3GpMlNleZA6noZ93drs2G9/D7WP4uVLCtJfGmG6PJsy4+qN46qXu ekJR/8WH1aNcH0Ya+JsYrwIFPwL4Cr+JXrbFqUOFMYIDzzCCA8sCAQEwgbQwga0xCzAJBgNVBAYT Ak5MMSAwHgYDVQQKExdUcnVzdGVkIEludHJvZHVjZXIgKFRJKTEgMB4GA1UECxMXQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkxMTAvBgNVBAMTKFRydXN0ZWQgSW50cm9kdWNlciAoVEkpIENsaWVudCBD QSAtIEcwMDExJzAlBgkqhkiG9w0BCQEWGGNhQHRydXN0ZWQtaW50cm9kdWNlci5ubAICBkgwCQYF Kw4DAhoFAKCCAe8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMw NTMxMTQxMjM0WjAjBgkqhkiG9w0BCQQxFgQUlVToKKZVaLwpH8A4KUkER1btfOgwgcUGCSsGAQQB gjcQBDGBtzCBtDCBrTELMAkGA1UEBhMCTkwxIDAeBgNVBAoTF1RydXN0ZWQgSW50cm9kdWNlciAo VEkpMSAwHgYDVQQLExdDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTExMC8GA1UEAxMoVHJ1c3RlZCBJ bnRyb2R1Y2VyIChUSSkgQ2xpZW50IENBIC0gRzAwMTEnMCUGCSqGSIb3DQEJARYYY2FAdHJ1c3Rl ZC1pbnRyb2R1Y2VyLm5sAgIGSDCBxwYLKoZIhvcNAQkQAgsxgbeggbQwga0xCzAJBgNVBAYTAk5M MSAwHgYDVQQKExdUcnVzdGVkIEludHJvZHVjZXIgKFRJKTEgMB4GA1UECxMXQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxMTAvBgNVBAMTKFRydXN0ZWQgSW50cm9kdWNlciAoVEkpIENsaWVudCBDQSAt IEcwMDExJzAlBgkqhkiG9w0BCQEWGGNhQHRydXN0ZWQtaW50cm9kdWNlci5ubAICBkgwDQYJKoZI hvcNAQEBBQAEggEAQTblYnPVgpccID1ioh9P+jT1omsiCoGx5nXVV7HxsVOvBy5/v8hER8lR2u5r Fd5adD1VW1RIBmLPrpjIykKI6UIPc5qKXqranaQ71VC9cXGMEBFduY3UH/kR0oq6Cy690ZLlr9Bg t6q5OkY7ROLHBoqMdJDSZQQIGyaULm01SSJ/9PDYRpFS9Q/mQ94O9bP5PoDYHqAGtoFGlxNyJUgu U05udMJZX0n6aKJRbrpZmmvwKs6gXQuHLzcxuN0BbJx6uMQ2xSHe95LCDeDJUl720LaBWGoP/LPX IXdoUlA81hrFfHCK0ETkrW0Ta5kpMC+4zuSt+PbEVxGQjLfFjn+v7gAAAAAAAA== --Apple-Mail=_FED52447-6B2B-44B0-990A-AE8DF726E949-- From jakob@kirei.se Fri May 31 08:34:47 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 514C421F9622 for ; Fri, 31 May 2013 08:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[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 V5C-VTyyyq5C for ; Fri, 31 May 2013 08:34: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 AF74821F9344 for ; Fri, 31 May 2013 08:34:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:content-type:mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=fuqcxrWuw53NC43g9qywB9zoeK+tCY5IEaeQwOyKV1k=; b=bUEwoc8bvyf/lpfY57euG2fmH1lys9PZHEg0rAktALhjbBGtfgMPm8vhqdcneqxJnOIJEsARO3wPH +SlzhNc7NVeh0BQ28cKrUDA1e0vSDw2GuJoLVwCpNEBVfJAvH5h3pV5VdbY1iIZSuiCNgGnj5+epmv 97ZPY5r6T6dCS2Ho= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Fri, 31 May 2013 17:34:36 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jakob Schlyter In-Reply-To: Date: Fri, 31 May 2013 17:34:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130529143710.GV9380@mournblade.imrryr.org> <20130529184555.GY9380@mournblade.imrryr.org> <544B0DD62A64C1448B2DA253C011414607ACD1048F@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <5B925F3A-B122-469D-97F5-7DF8A2262795@kumari.net> <69DCBEB1-396E-4EDF-A86B-CB2483CAD094@NLnetLabs.nl> To: Ben Laurie X-Mailer: Apple Mail (2.1503) Cc: "dane@ietf.org" Subject: Re: [dane] Classic PKI and DANE in harmony X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2013 15:34:47 -0000 On 30 maj 2013, at 16:55, Ben Laurie wrote: > a) It introduces latency, and so does checking revocation lists and OCSP. > b) It isn't reliable, so cannot be hard-fail. I'm a bit disappointed that browsers vendors are not willing to = implement new protocols, like DANE, just because there exists clients = out there that cannot reliable use them. I'm not saying we should enable = these features by default, but to be able to test them and learn more we = need them in something that is not an experimental build. I would even stretch my neck out and claim that the additional controls = provided by using DANE with certificate use 0/1 (i.e. backed by classic = PKIX) would make sense even without DNSSEC. I know this is a very = dangerous path and may dragons lure along it, but I still believe this = is something we should explore further. jakob From hallam@gmail.com Fri May 31 08:36:26 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 717A021F96E8 for ; Fri, 31 May 2013 08:36:26 -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.001, BAD_CREDIT=0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 NNk9VWis1xz8 for ; Fri, 31 May 2013 08:36:25 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id 0321221F962B for ; Fri, 31 May 2013 08:36:24 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id hr14so815053wib.16 for ; Fri, 31 May 2013 08:36:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=06f/ztnRdz91Efe1X9esxl/VLyK6dwZ5NOLnSglKGtE=; b=RL17EYrX7E4gZvI1AUQWzhLWVtjO66QFoTRGy/ypVHBTrrQUgUE8sZlfuWmNWx4CDK CO0ccDWsU7EZaojPLbTaEF4IA0gKxQJZrytzOs9a6LuRSKNlqGqlbStDi7S+lzWZxGFG NPXhH4kgdjyWXlM+GH8AFv9s564buExtSaw2dNoQlvK2Z1HTEAdeaCxqPVFCN5+buEL5 irC17Zye7/mVQQyIylqZ0tFk1gNrVCZTZf/+Jdvq5N4of21DOCJ0p4wMNhv7+bTS7AOQ nw07J74LCL6ZOc6Wd8Ynic+xxH3HO0sORWL/STStIujJb47xyd8xYJ7GNZmxaxUX3t0W BVgw== MIME-Version: 1.0 X-Received: by 10.180.212.49 with SMTP id nh17mr3776256wic.60.1370014584133; Fri, 31 May 2013 08:36:24 -0700 (PDT) Received: by 10.194.44.100 with HTTP; Fri, 31 May 2013 08:36:23 -0700 (PDT) In-Reply-To: References: Date: Fri, 31 May 2013 11:36:23 -0400 Message-ID: From: Phillip Hallam-Baker To: Jakob Schlyter Content-Type: multipart/alternative; boundary=001a11c34c849fe0da04de056068 Cc: Christian Heutger , "dane@ietf.org" Subject: Re: [dane] Classic PKI and DANE in harmony X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2013 15:36:26 -0000 --001a11c34c849fe0da04de056068 Content-Type: text/plain; charset=ISO-8859-1 On Thu, May 30, 2013 at 6:13 AM, Jakob Schlyter wrote: > On 30 maj 2013, at 10:09, Christian Heutger wrote: > > > I support your point of view, however domain validation also has some > > advantages with public certificates over DANE. The requirement for > > renewing (create new private key), the instant revoke with CRL and OCSP > > (against caching DNS) but finally also to aware against hackers and > > spammers. So if you look at DANE, everyone can run a valid site with > https > > and e.g. spread malware through that as often https traffic is not > scanned > > and usually be trusted, like recent mentioned phishing attacks. In > > addition with SMTP over TLS running mail servers, the assumption would > be, > > that it is a valid mail server. If everyone can go with SMTP over TLS, > > giving more trust to valid SMTP connections will be undergone. > > The additional services you mention are optional and not part of WebTrust > and/or ETSI certifications. There is no guarantee that such services are > performed on services served under a classic PKI certificate. > > Regarding revocation we've seen too many examples where CRLs are not > checked properly by the clients and/or OCSP responders are not responding > (or responding so slow that users disable them). This might not be how the > PKI infrastructure was designed, but it is the reality. > > Anyone can do SMTP with TLS today and most (sane) mail servers do that. > Without classic PKI. And the SMTP servers they talk to do no validation > whatsoever. DANE can only make things better here. > I agree with Jacob here but for a slightly different set of reasons. First and most important, SMTP certs are only ever seen by SMTP clients which are almost always MTAs in the modern Internet. It is not possible to send SMTP on port 25 from 95% of IP addresses. You have to use submit. So even if someone wanted to put a user experience onto STARTTLS they can't. And doing so would be a silly idea because STARTTLS is not end to end at the receiver. So STARTTLS is an application where we only ever require confirmation of the DNS name and nothing more. There is no need for accountability in a receiver. There is no need to validate a claim to a real world identity and reputation. The Web is a very different environment because many sites do accept payments and phishing is a threat. We are finding that the number of sites that require accountability or establishing an identity or external reputation claim is actually greater than the number of sites with CA certs. So reducing the validation criteria to nothing more than a domain name check is really not acceptable for those Web applications. DANE is certainly relevant for the 95%+ of Web sites without any TLS at all. Just as anything is better than a self signed unbound cert, anything is better than no crypto. Just don't tell people to have confidence in it. Do the crypto and don't mention that you did. Whatever techies think the padlock icon SHOULD mean, the only meaning the users will ever understand is 'I am safe'. So unless you think DANE alone makes people SAFE then there should be no user interface. The main reason that the WebPKI is designed the way that it is is that Marc Andressen wanted to tell people that it is safe to shop online and the Netscape lawyers told him that they were not going to let him take that liability. Rather ironically, SSL was Marc's real contribution to the Web. He gets no credit for it for two reasons. First he had a non-compete with EIT that stopped him working on security (ever wondered why they chose Kipp knowing he had no crypto experience?). Second, well you all know that one. The liability concern is still there. Any browser provider that tells their users that it is safe to use a site validated on DANE alone is accepting an indeterminate liability. [I think they are also kind of blowing it by not implementing revocation checking properly but that is an easy fix for them. One morning there will be some case and some lawyer will say 'hardfail OCSP'. And suddenly a bunch of CAs with rubbish OCSP responders are going to be finding that they have to fix them before they get their roots renewed.] Which gets me back to STARTTLS and certs there. Sure DANE is better than nothing and it is actually a good fit administratively. As a commercial model it makes perfect sense for CAs to package DNSSEC administration up with SSL certage and why not present through DNS and DANE? Its a good sales package for the CAs to offer. But I would not want to offer that package without putting the standard disclaimers and warranties etc. in the certificate or else my liability is going to be a problem. And I am probably going to want to offer something for the outbound mail server as well (Using DKIM) where accountability is a real issue and so the customer would want the cert issued off a public root. So yes, DANE is synergistic with SMTP but it is an adjunct to rather than a replacement for traditional PKI. -- Website: http://hallambaker.com/ --001a11c34c849fe0da04de056068 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, May 30, 2013 at 6:13 AM, Jakob Schlyter <jakob@kire= i.se> wrote:
On 30 maj 2013, at 10:09, Christian Heutger <ch@psw.net> wrote:

> I support your point of view, however domain validation also has some<= br> > advantages with public certificates over DANE. The requirement for
> renewing (create new private key), the instant revoke with CRL and OCS= P
> (against caching DNS) but finally also to aware against hackers and > spammers. So if you look at DANE, everyone can run a valid site with h= ttps
> and e.g. spread malware through that as often https traffic is not sca= nned
> and usually be trusted, like recent mentioned phishing attacks. In
> addition with SMTP over TLS running mail servers, the assumption would= be,
> that it is a valid mail server. If everyone can go with SMTP over TLS,=
> giving more trust to valid SMTP connections will be undergone.

The additional services you mention are optional and not part of WebT= rust and/or ETSI certifications. There is no guarantee that such services a= re performed on services served under a classic PKI certificate.

Regarding revocation we've seen too many examples where CRLs are not ch= ecked properly by the clients and/or OCSP responders are not responding (or= responding so slow that users disable them). This might not be how the PKI= infrastructure was designed, but it is the reality.

Anyone can do SMTP with TLS today and most (sane) mail servers do that. Wit= hout classic PKI. And the SMTP servers they talk to do no validation whatso= ever. DANE can only make things better here.


I agree with Jacob here but for a slightly different set of reasons.

First and most important, SMTP certs are only ever seen by SMTP clients whi= ch are almost always MTAs in the modern Internet. It is not possible to sen= d SMTP on port 25 from 95% of IP addresses. You have to use submit. So even= if someone wanted to put a user experience onto STARTTLS they can't. A= nd doing so would be a silly idea because STARTTLS is not end to end at the= receiver.

So=A0STARTTLS=A0is an application where we only ever require confirmation = of the DNS name and nothing more. There is no need for accountability in a = receiver. There is no need to validate a claim to a real world identity and= reputation.


The Web is a very different environment because many = sites do accept payments and phishing is a threat. We are finding that the = number of sites that require accountability or establishing an identity or = external reputation claim is actually greater than the number of sites with= CA certs. So reducing the validation criteria to nothing more than a domai= n name check is really not acceptable for those Web applications.=A0

DANE is certainly relevant for the 95%+ of = Web sites without any TLS at all. Just as anything is better than a self si= gned unbound cert, anything is better than no crypto. Just don't tell p= eople to have confidence in it. Do the crypto and don't mention that yo= u did.

Whatever techies think the padlock icon SHO= ULD mean, the only meaning the users will ever understand is 'I am safe= '. So unless you think DANE alone makes people SAFE then there should b= e no user interface.

The main reason that the WebPKI is designed= the way that it is is that Marc Andressen wanted to tell people that it is= safe to shop online and the Netscape lawyers told him that they were not g= oing to let him take that liability. Rather ironically, SSL was Marc's = real contribution to the Web. He gets no credit for it for two reasons. Fir= st he had a non-compete with EIT that stopped him working on security (ever= wondered why they chose Kipp knowing he had no crypto experience?). Second= , well you all know that one.

The liability concern is still there. Any b= rowser provider that tells their users that it is safe to use a site valida= ted on DANE alone is accepting an indeterminate liability.=A0

[I think they are also kind of blowing it by not imple= menting revocation checking properly but that is an easy fix for them. One = morning there will be some case and some lawyer will say 'hardfail OCSP= '. And suddenly a bunch of CAs with rubbish OCSP responders are going t= o be finding that they have to fix them before they get their roots renewed= .]


Which gets me back to = STARTTLS and certs there. Sure DANE is better than nothing and it is actual= ly a good fit administratively. As a commercial model it makes perfect sens= e for CAs to package DNSSEC administration up with SSL certage and why not = present through DNS and DANE? Its a good sales package for the CAs to offer= .=A0

But I would not want to offer that package withou= t putting the standard disclaimers and warranties etc. in the certificate o= r else my liability is going to be a problem. And I am probably going to wa= nt to offer something for the outbound mail server as well (Using DKIM) whe= re accountability is a real issue and so the customer would want the cert i= ssued off a public root.

So yes, DANE is synergistic with SMTP but it is a= n adjunct to rather than a replacement for traditional PKI.

<= /div>

--
Website: htt= p://hallambaker.com/
--001a11c34c849fe0da04de056068-- From hallam@gmail.com Fri May 31 08:43:44 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DFCF21F8F83 for ; Fri, 31 May 2013 08:43:44 -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, HTML_MESSAGE=0.001, 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 XEq7D5PPxZHk for ; Fri, 31 May 2013 08:43:43 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA3721F87CD for ; Fri, 31 May 2013 08:43:43 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id a12so1348173wgh.11 for ; Fri, 31 May 2013 08:43:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LKWqdu6K9V4kOSnBJujVoA1YDOrvBdFDnf/HprZzxnc=; b=XB4NkMH+4dCZYX42U5qtv9VxV977ozq78tHqOo0w087nLh60knKj5XsHSUpEKBlJ75 SRLmQYFKRMqp50JcOM/RdfLqOtgvsT7LevZCDcv7E9fTqIek7IP4tp9Kku9fp2knZIe/ WL3l1n455hF6klH9Fg5v42NZz9rI5enLdHespFQlpizJOWD9eIAg72rrQSIOQUbQ1kTU rUAmKNAgzHdA0WHE3d9QMBkYz6bEtokCetLEN6xz6Mszh5vNNtRrXdkJap0GHRo/vxH5 xr2sQHH4+uGHOcu/C3Vg6Ji2/2QC0OUCEFC0tDNRuDPCFEknIOKkzVdqZoxc7KBtOZgX jMHw== MIME-Version: 1.0 X-Received: by 10.194.78.12 with SMTP id x12mr10041293wjw.28.1370015022665; Fri, 31 May 2013 08:43:42 -0700 (PDT) Received: by 10.194.44.100 with HTTP; Fri, 31 May 2013 08:43:42 -0700 (PDT) In-Reply-To: References: <20130529184555.GY9380@mournblade.imrryr.org> <544B0DD62A64C1448B2DA253C011414607ACD1048F@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <5B925F3A-B122-469D-97F5-7DF8A2262795@kumari.net> <69DCBEB1-396E-4EDF-A86B-CB2483CAD094@NLnetLabs.nl> <20130530151810.GD9380@mournblade.imrryr.org> <20130530155539.GG9380@mournblade.imrryr.org> Date: Fri, 31 May 2013 11:43:42 -0400 Message-ID: From: Phillip Hallam-Baker To: Ben Laurie Content-Type: multipart/alternative; boundary=047d7bd91752c358de04de057a61 Cc: IETF DANE WG list Subject: Re: [dane] Classic PKI and DANE in harmony X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2013 15:43:44 -0000 --047d7bd91752c358de04de057a61 Content-Type: text/plain; charset=ISO-8859-1 On Thu, May 30, 2013 at 12:18 PM, Ben Laurie wrote: > The issue is not that the clients can't use DNSSEC, the issue is that > they cannot retrieve DNSSEC records. +1 That is why the place to put the DNSSEC validator is in the DNS server and why we need to change the client to DNS server protocol so that the client can get the authenticated decision of the validator. Hence omnibroker. Omnibroker brokers will probably consume DANE records just like every other piece of data that might affect the trustworthiness of an Internet destination. But once there is a broker in the loop there is no need to worry about latency as the broker can pre-fetch cert status information. In fact we could go back to using CRLs for revocation. [Omnibroker also good for consuming CT data Ben] -- Website: http://hallambaker.com/ --047d7bd91752c358de04de057a61 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, May 30, 2013 at 12:18 PM, Ben Laurie <benl@google.c= om> wrote:
The issue is not that the clients can't use DNSSEC, the issue is that they cannot retrieve DNSSEC records.

+1

That is why the place to put = the DNSSEC validator is in the DNS server and why we need to change the cli= ent to DNS server protocol so that the client can get the authenticated dec= ision of the validator.

Hence omnibroker.=A0

Omnibroker brokers will probably consume DANE records just l= ike every other piece of data that might affect the trustworthiness of an I= nternet destination. But once there is a broker in the loop there is no nee= d to worry about latency as the broker can pre-fetch cert status informatio= n. In fact we could go back to using CRLs for revocation.

[Omnibroker also good for consuming CT data= Ben]


--
Website: http://hallambaker.com/
--047d7bd91752c358de04de057a61-- From hallam@gmail.com Fri May 31 08:57:40 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6847C21F8CB4 for ; Fri, 31 May 2013 08:57: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=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 tAVjbt2BP3vO for ; Fri, 31 May 2013 08:57:39 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id A4BF121F85F7 for ; Fri, 31 May 2013 08:57:38 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id hi5so844156wib.6 for ; Fri, 31 May 2013 08:57:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=56bMuqBky3FSKzZT3eVbsFGAwfOZh+xiq37eDFyftpQ=; b=lqcKGv5cNElP1PObADwjpB3mlz7EM0AZfW0fpEljDQrOA5UzRjPcJcHvPjypaYztir ra1Y8fDXUMrnHFlG4ueu2AbcfRtaV49UOSyR2yV3x85SjoYB5GeOtsV8Jk6jKjx1A6pW BlrF7xhkd9vaT2H4ousAdZSjPDEU/R2sVLl905ir+Uuk7qbpJ0aygglwkv/PxXZfi/sX /Xht9fAGukUXs3kNYwUJ+KeHnmyPL9t0Cwdac0Fz0/XAN04nRvPra8UN/TNj1GK1u74N vzMqlzvvsbhlwEaZOElst5e9GvLycsrPJOxdjChOGXD/wC45N1SS8irJeqtjtEScToNl IWmg== MIME-Version: 1.0 X-Received: by 10.180.79.200 with SMTP id l8mr3839728wix.60.1370015857770; Fri, 31 May 2013 08:57:37 -0700 (PDT) Received: by 10.194.44.100 with HTTP; Fri, 31 May 2013 08:57:37 -0700 (PDT) In-Reply-To: References: <20130529143710.GV9380@mournblade.imrryr.org> <20130529184555.GY9380@mournblade.imrryr.org> <544B0DD62A64C1448B2DA253C011414607ACD1048F@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <5B925F3A-B122-469D-97F5-7DF8A2262795@kumari.net> <69DCBEB1-396E-4EDF-A86B-CB2483CAD094@NLnetLabs.nl> Date: Fri, 31 May 2013 11:57:37 -0400 Message-ID: From: Phillip Hallam-Baker To: Jakob Schlyter Content-Type: multipart/alternative; boundary=f46d043bd7768a06ff04de05ac89 Cc: "dane@ietf.org" Subject: Re: [dane] Classic PKI and DANE in harmony X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2013 15:57:41 -0000 --f46d043bd7768a06ff04de05ac89 Content-Type: text/plain; charset=ISO-8859-1 On Fri, May 31, 2013 at 11:34 AM, Jakob Schlyter wrote: > On 30 maj 2013, at 16:55, Ben Laurie wrote: > > > a) It introduces latency, and > > so does checking revocation lists and OCSP. > > > b) It isn't reliable, so cannot be hard-fail. > > I'm a bit disappointed that browsers vendors are not willing to implement > new protocols, like DANE, just because there exists clients out there that > cannot reliable use them. I'm not saying we should enable these features by > default, but to be able to test them and learn more we need them in > something that is not an experimental build. > > I would even stretch my neck out and claim that the additional controls > provided by using DANE with certificate use 0/1 (i.e. backed by classic > PKIX) would make sense even without DNSSEC. I know this is a very dangerous > path and may dragons lure along it, but I still believe this is something > we should explore further. > > jakob I did tell everyone that I have been banging my head against that particular wall for the past 20 years. But did anyone listen? I predicted phishing back in 1993 and proposed DIGEST to pre-empt the problem. But it was rejected due to a UNIX superstition against shadow passwords and Rob and Ari's desire to be able to use the existing UNIX password file to validate requests. The reason I am proposing Omnibroker is because changing the browser is hard and if we are going to improve Web security we need to decouple security research from the need to deploy new browsers. If we can get them to do omnibroker then we make one change and we move the security nexus out to a place where we can do interesting stuff. -- Website: http://hallambaker.com/ --f46d043bd7768a06ff04de05ac89 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, May 31, 2013 at 11:34 AM, Jakob Schlyter <jakob@kire= i.se> wrote:
On 30 maj 2013, at 16:55, = Ben Laurie <benl@google.com> w= rote:

> a) It introduces latency, and

so does checking revocation lists and OCSP.

> b) It isn't reliable, so cannot be hard-fail.

I'm a bit disappointed that browsers vendors are not willing to i= mplement new protocols, like DANE, just because there exists clients out th= ere that cannot reliable use them. I'm not saying we should enable thes= e features by default, but to be able to test them and learn more we need t= hem in something that is not an experimental build.

I would even stretch my neck out and claim that the additional controls pro= vided by using DANE with certificate use 0/1 (i.e. backed by classic PKIX) = would make sense even without DNSSEC. I know this is a very dangerous path = and may dragons lure along it, but I still believe this is something we sho= uld explore further.

=A0 =A0 =A0 =A0 jakob

I= did tell everyone that I have been banging my head against that particular= wall for the past 20 years. But did anyone listen?

I predicted phishing back in 1993 and proposed DIGEST to pre-emp= t the problem. But it was rejected due to a UNIX superstition against shado= w passwords and Rob and Ari's desire to be able to use the existing UNI= X password file to validate requests.

The reason I am proposing Omnibroker is bec= ause changing the browser is hard and if we are going to improve Web securi= ty we need to decouple security research from the need to deploy new browse= rs. If we can get them to do omnibroker then we make one change and we move= the security nexus out to a place where we can do interesting stuff.

--
Website: http://h= allambaker.com/
--f46d043bd7768a06ff04de05ac89-- From guido@witmond.nl Fri May 31 10:08:45 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA01A21F992B for ; Fri, 31 May 2013 10:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.095 X-Spam-Level: ** X-Spam-Status: No, score=2.095 tagged_above=-999 required=5 tests=[HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 cebIjsr5QfCU for ; Fri, 31 May 2013 10:08:39 -0700 (PDT) Received: from smtp-vbr5.xs4all.nl (smtp-vbr5.xs4all.nl [194.109.24.25]) by ietfa.amsl.com (Postfix) with ESMTP id C8C2D21F8FA3 for ; Fri, 31 May 2013 10:08:34 -0700 (PDT) Received: from [10.1.2.6] (mail.witmond.nl [80.100.189.3] (may be forged)) by smtp-vbr5.xs4all.nl (8.13.8/8.13.8) with ESMTP id r4VH8XeT086578 for ; Fri, 31 May 2013 19:08:33 +0200 (CEST) (envelope-from guido@witmond.nl) Message-ID: <51A8D910.2040300@witmond.nl> Date: Fri, 31 May 2013 19:08:32 +0200 From: Guido Witmond User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: dane@ietf.org References: <20130529143710.GV9380@mournblade.imrryr.org> <20130529184555.GY9380@mournblade.imrryr.org> <544B0DD62A64C1448B2DA253C011414607ACD1048F@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <5B925F3A-B122-469D-97F5-7DF8A2262795@kumari.net> <69DCBEB1-396E-4EDF-A86B-CB2483CAD094@NLnetLabs.nl> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Subject: Re: [dane] Classic PKI and DANE in harmony X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2013 17:08:45 -0000 On 31-05-13 17:34, Jakob Schlyter wrote: > On 30 maj 2013, at 16:55, Ben Laurie wrote: > >> a) It introduces latency, and > > so does checking revocation lists and OCSP. > >> b) It isn't reliable, so cannot be hard-fail. > > I'm a bit disappointed that browsers vendors are not willing to > implement new protocols, like DANE, just because there exists > clients out there that cannot reliable use them. I'm not saying we > should enable these features by default, but to be able to test them > and learn more we need them in something that is not an experimental > build. > To Jacob. As you work at a CA, I have this wish: I would love to see the CA-industry promote TLSA records for every server certificate they sign. When I apply/renew a certificate the CA gives me the correct RR-line, ready to include in my DNS(SEC)-records. DANE usage 0 is the missing link between (domain)name and signer, something that was envisioned with ISO-x500 directory but never materialised. Could you poke some people from the inside at your CA to consider it. I don't think it is a lot of work. If I'm not mistaken, with usage 0, it would be the same for each certificate signed with the CA's Root. (But what do I know, I'm just a beginner. ;-) ) > I would even stretch my neck out and claim that the additional > controls provided by using DANE with certificate use 0/1 (i.e. > backed by classic PKIX) would make sense even without DNSSEC. I know > this is a very dangerous path and may dragons lure along it, but I > still believe this is something we should explore further. It would not give much security benefits without Perspectives, Cert Patrol and others, but it is a little extra work for MitM-boxes to keep up their appearance. And it certainly help solving the chicken and egg problem we have now. So please pursue that path. Respectfully, Guido. From warren@kumari.net Fri May 31 10:35:33 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01E4321F8F00 for ; Fri, 31 May 2013 10:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100 X-Spam-Level: X-Spam-Status: No, score=-100 tagged_above=-999 required=5 tests=[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 2T8atB-GFQWh for ; Fri, 31 May 2013 10:35:27 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 121D021F8E8F for ; Fri, 31 May 2013 10:35:26 -0700 (PDT) Received: from [192.168.0.187] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id BADC11B40A6B; Fri, 31 May 2013 13:35:25 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Warren Kumari In-Reply-To: <0B5C8480-BF7C-4404-AC90-7A231DE51D1C@kumari.net> Date: Fri, 31 May 2013 13:35:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5815F378-9A44-4105-BC98-68FE21A8B73F@kumari.net> References: <0B5C8480-BF7C-4404-AC90-7A231DE51D1C@kumari.net> To: "dane@ietf.org list" X-Mailer: Apple Mail (2.1503) Subject: Re: [dane] Call for Agenda items X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2013 17:35:33 -0000 On May 25, 2013, at 1:09 PM, Warren Kumari wrote: > Hi all, >=20 > It seems that we probably have enough new material / discussions to = warrant meeting in Berlin. >=20 > So, please let us know, by the end of the month, if you'd like time on = the agenda. So far it seems we only have a request from Viktor to discuss his drafts = / lessons learnt from implementing -- this is also a gentle nudge to = read and comment on them. It is not 100% clear yet that Viktor will be able to attend in person, = but it seems like we may have a proxy if not. I'm guessing that more folk have things to discuss? Like Tony's docs? Or = is everything so happy that we don't need to meet? W > As always, we give preference to issues / documents that have had some = discussion > on the mailing list, but need real-time, fact-to-face discussions to = properly resolve. > Seeing as we now have some implementations (thanks!), we'd welcome = discussions of those as well. >=20 > W >=20 > P.S: Apologies for this coming somewhat late -- I picked up (what I'm = convinced is) bird flu at RIPE in Dublin the week before last... >=20 >=20 > -- > I once absend-mindedly ordered Three Mile Island dressing in a = restaurant and, with great presence of mind, they brought Thousand = Island Dressing and a bottle of chili sauce. > -- Terry Pratchett >=20 >=20 -- I once absend-mindedly ordered Three Mile Island dressing in a = restaurant and, with great presence of mind, they brought Thousand = Island Dressing and a bottle of chili sauce. -- Terry Pratchett From jakob@kirei.se Fri May 31 23:47:59 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03DB021F8B60 for ; Fri, 31 May 2013 23:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[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 uxEbZKzo4nUi for ; Fri, 31 May 2013 23:47: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 5F48A21F8B21 for ; Fri, 31 May 2013 23:47:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:content-type:mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=/Kpygf9JIe6jZrw0GopPZhxWipPaRHqt8U1txoXMgOc=; b=aPQ8AeveRHU8xfJ2Kf0+bWvIgQSSrJkaKaHK0mQZqk98kPNv6aRxtaJET9hFP1HcjVd3VOjSQMMFt bU5k+CFjWzr5ztNEph/+BDS3dHtFIt6yNGJNi7djP0ABE0iL7YMm3SoxUe5+ehJhl+rtzydUVjQ0JU Pb6qpeGqC62+KEDA= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Sat, 1 Jun 2013 08:47:48 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jakob Schlyter In-Reply-To: <51A8D910.2040300@witmond.nl> Date: Sat, 1 Jun 2013 08:47:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <32E2F18C-CFDD-4169-A963-6EE7D5CBAE64@kirei.se> References: <20130529143710.GV9380@mournblade.imrryr.org> <20130529184555.GY9380@mournblade.imrryr.org> <544B0DD62A64C1448B2DA253C011414607ACD1048F@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <5B925F3A-B122-469D-97F5-7DF8A2262795@kumari.net> <69DCBEB1-396E-4EDF-A86B-CB2483CAD094@NLnetLabs.nl> <51A8D910.2040300@witmond.nl> To: Guido Witmond X-Mailer: Apple Mail (2.1503) Cc: dane@ietf.org Subject: Re: [dane] Classic PKI and DANE in harmony X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 01 Jun 2013 06:47:59 -0000 On 31 maj 2013, at 19:08, Guido Witmond wrote: > To Jacob. As you work at a CA, I have this wish: I don't work at any CA - I'm just one of the crypto plumbers who wrote = RFC 6698. > I would love to see the CA-industry promote TLSA records for every > server certificate they sign. When I apply/renew a certificate the CA > gives me the correct RR-line, ready to include in my DNS(SEC)-records. That sounds like an excellent idea. jakob