From guido@witmond.nl Sat Jun 1 02:06:36 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 3326721F87CD for ; Sat, 1 Jun 2013 02:06:36 -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=[AWL=-0.000, BAYES_50=0.001, 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 nwiIwHnVCgPO for ; Sat, 1 Jun 2013 02:06:30 -0700 (PDT) Received: from smtp-vbr6.xs4all.nl (smtp-vbr6.xs4all.nl [194.109.24.26]) by ietfa.amsl.com (Postfix) with ESMTP id 19B8C21F86FB for ; Sat, 1 Jun 2013 02:06:28 -0700 (PDT) Received: from [10.1.2.6] (mail.witmond.nl [80.100.189.3] (may be forged)) by smtp-vbr6.xs4all.nl (8.13.8/8.13.8) with ESMTP id r5196RDr075922 for ; Sat, 1 Jun 2013 11:06:27 +0200 (CEST) (envelope-from guido@witmond.nl) Message-ID: <51A9B992.9000804@witmond.nl> Date: Sat, 01 Jun 2013 11:06:26 +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> <51A8D910.2040300@witmond.nl> In-Reply-To: <51A8D910.2040300@witmond.nl> 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: Sat, 01 Jun 2013 09:06:36 -0000 On 31-05-13 19:08, Guido Witmond wrote: > > To Jacob. As you work at a CA, I have this wish: Got that working-at part wrong. My apologies to Jacob. Respectfully, Guido. From viktor1dane@dukhovni.org Sat Jun 1 07:37: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 4CA2E21F9CFB for ; Sat, 1 Jun 2013 07:37: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=[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 GY33yeFFqpi2 for ; Sat, 1 Jun 2013 07:37:10 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 38F8821F9D00 for ; Sat, 1 Jun 2013 07:37:10 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 5FCE72AB9D4; Sat, 1 Jun 2013 14:37:09 +0000 (UTC) Date: Sat, 1 Jun 2013 14:37:09 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130601143709.GA9380@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> <51A8D910.2040300@witmond.nl> <32E2F18C-CFDD-4169-A963-6EE7D5CBAE64@kirei.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <32E2F18C-CFDD-4169-A963-6EE7D5CBAE64@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: Sat, 01 Jun 2013 14:37:16 -0000 On Sat, Jun 01, 2013 at 08:47:42AM +0200, Jakob Schlyter wrote: > > 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. This is I think unlikely to happen. It is easy to compute a SHA256 digest of a certificate or public key from the associated certificate. As we've seen the main obstacle to DANE adoption is DNSSEC deployment, not so much difficulties with DANE itself. Once DNSSEC is more widely implemented, publishing of TLSA RRs will not be held back for lack of knowledge of what to publish or tools to compute the digests. One simple example: #! /bin/sh usage() { echo "usage: $0 base-domain certificate-file" >&2 exit 1 } getopts :h opt && usage [ $# -eq 2] || usage base=$1 cert=$2 openssl x509 -in "$cert" -noout -pubkey | openssl pkey -pubin -outform DER | openssl dgst -sha256 | awk -v base="$base" '{printf "%s IN TLSA 3 1 1 %s\n", base, $2}' Tools for doing this should be included with server software. Some people will likely be trusting enough to have some stranger's web page compute the TLSA RR for them. (This covers the CA case, as end-users of certificates often receive these via email, in which the sender is weakly authenticated if at all). -- Viktor. From benl@google.com Mon Jun 3 02:16: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 4FD3121F934B for ; Mon, 3 Jun 2013 02:16:25 -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 9h2w7bDaGiez for ; Mon, 3 Jun 2013 02:16:24 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id D7BC121F8F0C for ; Mon, 3 Jun 2013 02:16:19 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id c10so3875982ieb.38 for ; Mon, 03 Jun 2013 02:16:14 -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:content-transfer-encoding; bh=7LsAJ6wrNDW9QieYBZXKp1I5xJADhyES4oouY+BPIqE=; b=Endii2uEAUoyCw7e4cCTqCZEPS1R+hqLHSIVmRAnMjHiSlQEUPM+BsL4qJpyBGv+cb taCckbwKVAVQl3+pCaDGF3wb9flgrxpfsXoE9N0VgFC0LZJed8FbECalOLCZmeZhl6VN vrT2qfcBOupR8LAsIl6klqXpd88N0b4Y/TH/gQFmlfq8DTFdNcWGpO6xz7Xb3RKB+ePG NDGnsti8vD4EnTvMGpCuXuA0iS/tYHm9LSVnNtCvO7qDR5oZOjOrd03BpMx53Riun8tq mmDbcSGE2+y2Y6KYwO1dXxb26ap1OwSzNsmAigLeIdW2GIMroNASwu/HOcnGUHZ/pIRi 3eGA== 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:content-transfer-encoding:x-gm-message-state; bh=7LsAJ6wrNDW9QieYBZXKp1I5xJADhyES4oouY+BPIqE=; b=i5JBebMlH7T+TvP9/DnxJKxLejYeGxWRxqtDoWw4XQbqa3rTthDCfZn305D6KvJ5mt +eWHLypbMZSOz9v/nvit6Cocjv8mfdKm7jOhFoWtY1WcO/HOlscrych0dDTt+MV5Pujc j+tXwYNMZjR+wqehFnUPZml4vRBBp3iLa5Gtgez08qPFisH59WxboHdrkxzGEPesvyqs XCL7Y68+2ZuEwqRA5VEhYKD0a4vVFTeBbPfwxQ3x93gAuPZjOZ0uzl47mljDJ1whWxLg JZ6HYWQlomQqQaGsDaddRtUR3Vo8Fh7bxQlhRhkA4BUU1DEiODKTLwEkhbVp9zpE0G0N +eew== MIME-Version: 1.0 X-Received: by 10.50.128.102 with SMTP id nn6mr7421072igb.26.1370250974443; Mon, 03 Jun 2013 02:16:14 -0700 (PDT) Received: by 10.64.24.137 with HTTP; Mon, 3 Jun 2013 02:16:14 -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: Mon, 3 Jun 2013 10:16:14 +0100 Message-ID: From: Ben Laurie To: Jakob Schlyter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmongcVwU9UCTXUCIf0ZC9Y4aF8sEuBHoV4wNbhITliBGJFgS0yticXHz4H7JS6/ibx0fSNRfCJG4cjrcIlbCxA7BsF4+ZOFz7OPXRH8cuOuF1OBAaxHev1+K7tO3oWDYvCsjwrQd38NUxVQAoUPPwZ+JwQMsQwmhvIlLC93rOP5RM5qqAaz6FsTyoVcNz0ljLiWmO6 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: Mon, 03 Jun 2013 09:16:26 -0000 On 31 May 2013 16: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. Which is why they're default off. >> 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 b= y default, but to be able to test them and learn more we need them in somet= hing that is not an experimental build. I don't have any particular view on whether browsers should or should not implement protocols that don't work reliably, but my goal is to accept reality and implement something that _is_ reliable (i.e. Certificate Transparency). > > I would even stretch my neck out and claim that the additional controls p= rovided 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 pat= h and may dragons lure along it, but I still believe this is something we s= hould explore further. > > jakob > From benl@google.com Mon Jun 3 02:19: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 0400121F934B for ; Mon, 3 Jun 2013 02:19:48 -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 qpSG5uhCJi-f for ; Mon, 3 Jun 2013 02:19:44 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 117D521F9455 for ; Mon, 3 Jun 2013 02:19:32 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id tp5so9467692ieb.6 for ; Mon, 03 Jun 2013 02:19:30 -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=mdBbY6WLsfNwE27Wz6GBgs9Z5MBrvleInw8imcmD3lc=; b=ITHKCeWmtTaQyDynkISL9Mr5iTzIYm2D1xpek1g1X1g8/30OSOBst6j2UepJTb23oK 9fmFI0fOZGeP8ofCiztSWRqoulrPYzyjFTZ1GKlzWs28RQW1d2MZvrVwftZz1j5nyaBe I6SwoH2OMLkWg523pTZYAbZ7dcV1cBDN5qBZZ4Xu0lmT3SOZF60hok2EWFVO/Xl25ybP pH+kPd4vPG6ImgXIeq4DOB4NXLOQbN+vM1XG2cezbu02aG5vxX9by/eA8eLuwZyBQqNU gY7xCseKwppRVnlxDpyfamfNbTuPlV+w0NUUvhsbSaG+MNwzI5Av+CRLQNpZUoAmxbxw LR7w== 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=mdBbY6WLsfNwE27Wz6GBgs9Z5MBrvleInw8imcmD3lc=; b=Yk6zIqU3yQ8AE2mvn0DINegATrn8CfR5cgJyVZO96WdYSnVEYhIDlARlK1zmAcTccZ 2Qjo3UNScT8wFa5GpxLY+swIdHSokEdsONpiJ3li0tI61/kGhg4wPA+sM+OEB322ZnRN APE8XUSpA4bHWURjhLjBMXgPLSbTXRp24B9hRcHTJzTaxGtPrnQds4EhYofVhaAgEbgp 6GWg1eUHePe0sv5AOWvZFzZlBxfgnDTCdxdGPnkKl/PAQ+dhbzHD5hXQXz3RUDScRfEE mDzeEJ5rTEwIz10QWTDU2Mpubv0fMkfeG9nPfDC0eCMJNSqwDwLiRgT8CJhzCFw4tpNm gTOw== MIME-Version: 1.0 X-Received: by 10.50.176.202 with SMTP id ck10mr7599634igc.9.1370251170410; Mon, 03 Jun 2013 02:19:30 -0700 (PDT) Received: by 10.64.24.137 with HTTP; Mon, 3 Jun 2013 02:19:30 -0700 (PDT) In-Reply-To: References: Date: Mon, 3 Jun 2013 10:19:30 +0100 Message-ID: From: Ben Laurie To: Phillip Hallam-Baker Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkFYh1F8TAv9m9KLOnSzx2VkhiOzWrmn6U48Pd4GkDB400T2A0+dhoaeCP83OWHal6cMUl7zc9Ch6qLB8AQOXBn/BX2TkQWPXTSdTVjDcM6A4oLsmXn9xG9KTj59B0uIJTD1/55si0wJi4TOqymrIY+cNQ335oi0mCfA+iCAYt2OLiC3872+3w6dmnrgxsmaOupmv/r 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: Mon, 03 Jun 2013 09:19:51 -0000 On 31 May 2013 16:36, Phillip Hallam-Baker wrote: > 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. I don't understand this claim - are you suggesting that DNS itself is a reliable way to link an end entity to a certificate? From benl@google.com Mon Jun 3 02:22: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 544ED21F8651 for ; Mon, 3 Jun 2013 02:21:43 -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 vwZKmG5RkWzP for ; Mon, 3 Jun 2013 02:21:42 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id EFF5D21F92F5 for ; Mon, 3 Jun 2013 02:21:33 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 17so9734473iea.17 for ; Mon, 03 Jun 2013 02:21:30 -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=0C38aLwIP+l5f989CNmxywn1mJq8jFv3N/6dbpmBzPc=; b=gr+WrSh1/eDgDbROFD13HpHWjjVBGu1xjHaUvq5sZR7Rgr7oI+ht9rYGzr2NQ2kppS Gm20ynCauJYUM1tAonhBnPMbswr6KuSOCIDwOFLVAsEhhXkOTaDaRhc7l6em5QO19AJ8 zvv0pJMZSGwouSNjQiYl+qZw3TMIUOXOAW3PZRBDVYJumFD0tBph8Y9OFO40p7acGZzi NZsGI5vd8qrnGgyoA+WBTE7JZfFjI6Y+LHkOkw5pW2tdcxg/Fch7ZiwKOPR1LfozddHH ikQK8lw/1W77kXuA2CRd0x9L9FF7zZy6LrDCouNmLEvCZZR7D4VV36KjWUAqQ14XnSGG 2AAQ== 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=0C38aLwIP+l5f989CNmxywn1mJq8jFv3N/6dbpmBzPc=; b=RD4CsQVeKTdL4pioCjnMhOIXjtQ4wl66OMpv5d4PxK9ojKitMqxW+N3SZos3iYHOPf 5LMfVk6XqwzoRgrOy0m7YVditlY7TClDyNVS375ekX/ZDTZH6V9bD0TUavzMm4Xd/JYe 7Ea5S5AlwQpux2c5bm1TdB8p77MueZ+pnZGZnKAYzBrUfZjzS5hGUwKSTrgDIYJ5GLIx WxTbqn+bI+F8HvB0UqH9g5wjSnZ8fHzOGRfFnT/m5MmDWo4wGglfLLtSj7GFoQ4RzlNf G3js1K3AfASOKg9zXK7qn0KaU6MuVt34dWJBuktRJ3vrpsVjlKJrkPN1ElTJr7NkpxwG SS1w== MIME-Version: 1.0 X-Received: by 10.50.176.202 with SMTP id ck10mr7603301igc.9.1370251290397; Mon, 03 Jun 2013 02:21:30 -0700 (PDT) Received: by 10.64.24.137 with HTTP; Mon, 3 Jun 2013 02:21:30 -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: Mon, 3 Jun 2013 10:21:30 +0100 Message-ID: From: Ben Laurie To: Phillip Hallam-Baker Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlQtDGjs3B0S7T2aRvgS3NBFgKEX/C4XGAwi7LPxillqf2L4vtL9eny6gMPDOSo/5Gat/VWuR1EqQXilEcf1Pk+S50vQLKx2p+65QzbfYOwp7QcoPjBSpR1duiwXhlj89GohxLWNrTGt4v8NltCcntuP0noFQJ56YlNyLRjk3fveIzisymL8LJ4QAMplWS6LLiRhmL6 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: Mon, 03 Jun 2013 09:22:11 -0000 On 31 May 2013 16:43, Phillip Hallam-Baker wrote: > 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] Omnibroker introduces a trusted third party. It may be better than the status quo, but I think we've got adequate proof that we can't actually trust TTPs. From carl@redhoundsoftware.com Mon Jun 3 04:24:06 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 6B2B221F944F for ; Mon, 3 Jun 2013 04:24:06 -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 fvl8GpxfV8OI for ; Mon, 3 Jun 2013 04:24:06 -0700 (PDT) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 9422F21F941F for ; Mon, 3 Jun 2013 04:24:00 -0700 (PDT) Received: by mail-qc0-f179.google.com with SMTP id e1so2085282qcx.10 for ; Mon, 03 Jun 2013 04:23:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=Kp7qQQlGzgccXXuZ0GdlDFxDTcUNAdBORlZHosZ5XhU=; b=FjadsqOVhB8yMr7GJ3++9HO6MJjjdzK9+lk5onrLfMvhgK9n9Pd/vMBAvVgXJIWQEI lLcPBHDEjwNI1i7aoyfCzgI3CyF0Ymf8V5sN6jkvo3uphNjGb6kdVaoTuwpgNpi47Mme SKWgkpYjHXfi8n9OV05UV0/jwJ3gt0o0h2AwvYI+YN6SnhcC7Y03ryBiO4YNvSoddZIp N7Iqxed24PlkRqsR2Di+D5gV55E6FUkrwnc2UuI/TleeVFI7BEfkLy5Q1UDRND93fXaw PsA077ScW7oRlQQn62/fdM1+qsSm2hywtJVxleuoH/lKdCbB3E6ffp4s+6x1Uv2Sqgmf R5mw== X-Received: by 10.224.58.135 with SMTP id g7mr18575328qah.49.1370258633954; Mon, 03 Jun 2013 04:23:53 -0700 (PDT) Received: from [192.168.2.6] (pool-173-79-116-61.washdc.fios.verizon.net. [173.79.116.61]) by mx.google.com with ESMTPSA id c10sm60016814qao.10.2013.06.03.04.23.52 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 03 Jun 2013 04:23:53 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.3.1.130117 Date: Mon, 03 Jun 2013 07:23:50 -0400 From: Carl Wallace To: Ben Laurie , Jakob Schlyter Message-ID: Thread-Topic: [dane] Classic PKI and DANE in harmony In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Gm-Message-State: ALoCoQkFtcgx2UAKfj9YxI2f+jx8VwIMIrpZVHbVVJjDY+FbgtbDAuV+XzRvysmnk0cyJR3mpizz 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: Mon, 03 Jun 2013 11:24:06 -0000 On 6/3/13 5:16 AM, "Ben Laurie" wrote: >On 31 May 2013 16: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. > >Which is why they're default off. > >>> 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 don't have any particular view on whether browsers should or should >not implement protocols that don't work reliably, but my goal is to >accept reality and implement something that _is_ reliable (i.e. >Certificate Transparency). It may be reliable but it does not address the problem the less reliable protocols address so you will still need to implement something else. The CT spec acknowledges this. From viktor1dane@dukhovni.org Mon Jun 3 08:15: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 C9DF021F8481 for ; Mon, 3 Jun 2013 08:15: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] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ej4f7QtJO4uh for ; Mon, 3 Jun 2013 08:15:13 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 8584621F99DE for ; Mon, 3 Jun 2013 08:15:13 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 97BA92AB9DC; Mon, 3 Jun 2013 15:15:12 +0000 (UTC) Date: Mon, 3 Jun 2013 15:15:12 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130603151512.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> 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: Mon, 03 Jun 2013 15:15:18 -0000 On Mon, Jun 03, 2013 at 10:16:14AM +0100, Ben Laurie wrote: > > On 30 maj 2013, at 16:55, Ben Laurie wrote: > > > >> a) It introduces latency, and > > > > so does checking revocation lists and OCSP. > > Which is why they're default off. As does also e.g. SPNEGO, which browser users can and often do enable for specified domains since this supports SSO via Kerberos. So there is a number of precendends for default-off security mechanisms. I think that DANE deserves a chance, and ideally what we should be discussing is "when" not "whether". There is a bit of a chicken/egg issue with DNSSEC, it takes some effort to deploy, and this effort needs to have benefits to encourage more deployment. DANE could be one of the motivating factors driving DNSSEC adoption, but without browser support the impetus is reduced. > >> 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 don't have any particular view on whether browsers should or should > not implement protocols that don't work reliably, but my goal is to > accept reality and implement something that _is_ reliable (i.e. > Certificate Transparency). In what context is the normative languate below ( https://tools.ietf.org/html/draft-laurie-pki-sunlight-12#section-3 ) intended to apply? TLS servers MUST present an SCT from one or more logs to the TLS client together with the certificate. TLS clients MUST reject certificates that do not have a valid SCT for the end-entity certificate. Must private-label internal-only corporate CAs implement this standard? Does this apply only to certificates that chain to designated roots? Are legacy clients that don't implement the new standard no longer allowed to connect to servers? The above requirement seems rather bold without some constraints on its scope. -- Viktor. From benl@google.com Mon Jun 3 08:25: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 D3D0621F92FC for ; Mon, 3 Jun 2013 08:25:27 -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 qeFpLUmnY3LU for ; Mon, 3 Jun 2013 08:25:27 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id B9B2E21F826B for ; Mon, 3 Jun 2013 08:25:26 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id at20so10260441iec.7 for ; Mon, 03 Jun 2013 08:25:21 -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:content-transfer-encoding; bh=+aBoJkef5fhHbvPIpmfd/cHyHEYTHq3dOMopa3X9nOI=; b=edVf1h/eHtNs0YmHbx/hUEdT3Py/1f6JQ/0mCShE6s9H/MlprYdOKxbOP+6oG96wcn b/uTz1pUcDfh0YBTRdRbFJVobTgK9cNPnBGqc54AQNbuuuN8TGT2z6qYzvUf6I+3thdS 2rWooXFP21Am/HxffZpEEf4MxiD6m0yjqEc9sZS/DJwdLiOHb+awgM1yBt2ukP2klNBk ERt8kNL/IBhv2IzicAvz1QEL5MG6u8EvM5m0EoksxNCQdKNeBVtwCCYn275mauP71Uo1 qWozvDeAyjBoezNfsZxnQh7pROdm7IzEWSi46w/Upsd4GBZt+zm02ciw6JlEVG6EtH8X zIXA== 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:content-transfer-encoding:x-gm-message-state; bh=+aBoJkef5fhHbvPIpmfd/cHyHEYTHq3dOMopa3X9nOI=; b=B+K9OmcDqWy6gQTudX7OFtf5NnOW9eisBLoui4bDnLzRjMJzttvneheh1kEXsVJoui 4EOp/SIQ0muu+Q5HnnRV7t22LItWLm3VxuYuPLguG8Fkd9i96vB4HDMNDrI/u1pBD8+j uYtmQZIAMtAur6AmPq1HUkKh7/9gb/8F15r/963ktLbVCK49oouNdPUqjqdmdBbsdSq4 SJgRS4CjNrI9h2TWDINEogy6+HU6HKZF9lgI0RQp7tTdzMLcRiao/KvUlKraAQtU+4Kw j0w3wHXJn8V0SWnJjgHfdzA0gvpnMS6ciFPZkVlnrScb88vSz7B6WwFff/CheM3NYHEN Hvcg== MIME-Version: 1.0 X-Received: by 10.50.178.137 with SMTP id cy9mr8277886igc.16.1370273121574; Mon, 03 Jun 2013 08:25:21 -0700 (PDT) Received: by 10.64.24.137 with HTTP; Mon, 3 Jun 2013 08:25:21 -0700 (PDT) In-Reply-To: <20130603151512.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> <20130603151512.GH9380@mournblade.imrryr.org> Date: Mon, 3 Jun 2013 16:25:21 +0100 Message-ID: From: Ben Laurie To: IETF DANE WG list Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlwbPKgjahjVBw2nUvzOtWJ5V0wAmuEO4vwmp35SVLPYm9f8Kjue4tyXwCWTfUOEY50XWVg48vKel6MvDLpuC42h5YoOXGMi6rpLDVZr1e3mTG7XFDEEGZHQqtjkhlDgd3MoRni5nZc/FEvpxmRjxD9VzGGisaRXLJCm9J0fv7nRusnsBQXxJ8+/OY2EZ1NXiOpv3k5 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: Mon, 03 Jun 2013 15:25:28 -0000 On 3 June 2013 16:15, Viktor Dukhovni wrote: > On Mon, Jun 03, 2013 at 10:16:14AM +0100, Ben Laurie wrote: > >> > On 30 maj 2013, at 16:55, Ben Laurie wrote: >> > >> >> a) It introduces latency, and >> > >> > so does checking revocation lists and OCSP. >> >> Which is why they're default off. > > As does also e.g. SPNEGO, which browser users can and often do > enable for specified domains since this supports SSO via Kerberos. > So there is a number of precendends for default-off security > mechanisms. I think that DANE deserves a chance, and ideally what > we should be discussing is "when" not "whether". > > There is a bit of a chicken/egg issue with DNSSEC, it takes some > effort to deploy, and this effort needs to have benefits to encourage > more deployment. DANE could be one of the motivating factors driving > DNSSEC adoption, but without browser support the impetus is reduced. > >> >> b) It isn't reliable, so cannot be hard-fail. >> > >> > I'm a bit disappointed that browsers vendors are not willing to implem= ent new protocols, like DANE, just because there exists clients out there t= hat cannot reliable use them. I'm not saying we should enable these feature= s by default, but to be able to test them and learn more we need them in so= mething that is not an experimental build. >> >> I don't have any particular view on whether browsers should or should >> not implement protocols that don't work reliably, but my goal is to >> accept reality and implement something that _is_ reliable (i.e. >> Certificate Transparency). > > In what context is the normative languate below ( > https://tools.ietf.org/html/draft-laurie-pki-sunlight-12#section-3 > ) intended to apply? > > TLS servers MUST present an SCT from one or more logs to the > TLS client together with the certificate. TLS clients MUST > reject certificates that do not have a valid SCT for the end-entity > certificate. > > Must private-label internal-only corporate CAs implement this > standard? No. > Does this apply only to certificates that chain to > designated roots? Yes. > Are legacy clients that don't implement the new > standard no longer allowed to connect to servers? Clearly a client that does not implement the standard is not constrained by any MUSTs in the standard. As is true for all standards. > The above > requirement seems rather bold without some constraints on its scope. We should, perhaps, have said something about private CAs. Possibly this was omitted because all interested parties already understood the exemption and so failed to notice we hadn't put it in the I-D. > > -- > Viktor. > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From viktor1dane@dukhovni.org Mon Jun 3 09:38:06 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 06A6221F8EF2 for ; Mon, 3 Jun 2013 09:38:06 -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 Q5IeiXhioaYu for ; Mon, 3 Jun 2013 09:38:01 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id BC8E621F8DDD for ; Mon, 3 Jun 2013 09:38:01 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id C3A002AAE4D; Mon, 3 Jun 2013 16:38:00 +0000 (UTC) Date: Mon, 3 Jun 2013 16:38:00 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130603163800.GI9380@mournblade.imrryr.org> References: <544B0DD62A64C1448B2DA253C011414607ACD1048F@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <5B925F3A-B122-469D-97F5-7DF8A2262795@kumari.net> <69DCBEB1-396E-4EDF-A86B-CB2483CAD094@NLnetLabs.nl> <20130603151512.GH9380@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: Mon, 03 Jun 2013 16:38:06 -0000 On Mon, Jun 03, 2013 at 04:25:21PM +0100, Ben Laurie wrote: > > In what context is the normative languate below ( > > https://tools.ietf.org/html/draft-laurie-pki-sunlight-12#section-3 > > ) intended to apply? > > > > TLS servers MUST present an SCT from one or more logs to the > > TLS client together with the certificate. TLS clients MUST > > reject certificates that do not have a valid SCT for the end-entity > > certificate. > > > > Must private-label internal-only corporate CAs implement this > > standard? > > No. > > > Does this apply only to certificates that chain to > > designated roots? > > Yes. > > > The above > > requirement seems rather bold without some constraints on its scope. > > We should, perhaps, have said something about private CAs. Possibly > this was omitted because all interested parties already understood the > exemption and so failed to notice we hadn't put it in the I-D. I think this is important to add. Otherwise there seems to be an inadvertent conflict with DANE TLSA usage 2 and 3. Clients that implement both standards should be able to verify at least privately issued usage 3 EE certs, and privately issued usage 2 trust-anchors. I think it should be clarified that CT hardens PKIX validation in the context of the existing public CA PKI for trust chained to designated PKIX roots (and eventually clients are expected to only support CT conformant public roots, plus any private roots that CT-exempted by the client). When a client that supports both PKIX + CT and another PKI (say DANE TLSA) is not using PKIX (e.g. DANE usage 2/3), it should be clear that CT does not apply, and the client is still CT conformant when it does not apply CT rules outside their intended scope. Is that a fair statement of the implicit consensus? It may be helpful to make it explicit, so as to avoid confusion. -- Viktor. From benl@google.com Mon Jun 3 09:57:50 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 9D7C421F9007 for ; Mon, 3 Jun 2013 09:57:50 -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 qrN+o+d6TvJq for ; Mon, 3 Jun 2013 09:57:50 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 17C8621F8F38 for ; Mon, 3 Jun 2013 09:57:50 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 17so11357867iea.3 for ; Mon, 03 Jun 2013 09:57:49 -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=nN4q7HaYIjPzr2D+7aleIhaqJdCAskbLU5hGMyoUhjE=; b=SmsDZn1dOF63DwOjQL8U7Ls8kv7v+X29OJagXu96ZpGlgJLJUycBXIL4RYR2w2JR8F o7M0eJaycJsZkvUUg/xJ1zQnfn4+T7vjkn4wK1Zaf9MdHtwQOdZEyPVOjNEzXuricUv+ Y7kcpiT8ygvR2ThdGYjGTVB7XkQwj6CtCeXXpIW2ngTX2bLfI6gAnFGRPCFrXguMkHPw HnAs2ffMgO2qdg2FZ0C9rd9IqS8DnxYj4TNXsoQZPxQI60d0IiVHO1r/B+KSLxwpoz4d kS3qc8IN0cLh/wL2jrLW63Tlc2uD0GW60w60egvKuCRCz0nSqLfgRtSYi+qfZHmlRexJ SJHQ== 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=nN4q7HaYIjPzr2D+7aleIhaqJdCAskbLU5hGMyoUhjE=; b=IJhXl01o8G10DtoAHQ/4IKQfFMytsG5jvH2dIezSTwB7estxIHxXB4JRVjU2P6hsQz SM6coR37zMCRqFwlGyA2tilV/zykHhsK0zFxnuDaq6IvO5oLtDGAOQfdtYloNJ6iQXRT 4n2Exsoln9ROgnwW2lHe5BCRgqCOLPnzpxWxpQfmR30raFauIkVZ65z5clDT6mWqApLW qzBqm7db3NlRm8VQJmrZZDHz4Og5WPVstj0GiqscjmsSqUTfGfxV0fHryOsCSSAj9m2a xe6T/e2Tu1EAvrwK+IibwHVqQMW8SSHmMTuggcclT7YaGsRfK34p9UUGPZC9nBsttOSN zgeA== MIME-Version: 1.0 X-Received: by 10.50.178.137 with SMTP id cy9mr8540071igc.16.1370278669583; Mon, 03 Jun 2013 09:57:49 -0700 (PDT) Received: by 10.64.24.137 with HTTP; Mon, 3 Jun 2013 09:57:49 -0700 (PDT) In-Reply-To: <20130603163800.GI9380@mournblade.imrryr.org> References: <544B0DD62A64C1448B2DA253C011414607ACD1048F@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <5B925F3A-B122-469D-97F5-7DF8A2262795@kumari.net> <69DCBEB1-396E-4EDF-A86B-CB2483CAD094@NLnetLabs.nl> <20130603151512.GH9380@mournblade.imrryr.org> <20130603163800.GI9380@mournblade.imrryr.org> Date: Mon, 3 Jun 2013 17:57:49 +0100 Message-ID: From: Ben Laurie To: IETF DANE WG list Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlPJdixAo+kaMJ1rfR+nXsFM6Zv52TEDvzNebfLjige4JCy3JW8gA7vb0QzfLuXCeD65qxt+QJIDcwqOYllTf/o5qY6tdlHsBWqRSvlKC/CoklTRtDi9Rlmj957dEiLUMWe4FcqACPvHk/dvF0NkKnnQz0lkskfGDmxC9A869752YBaAYSghFrjbnOdqZ/UxYGSRvdk 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: Mon, 03 Jun 2013 16:57:50 -0000 On 3 June 2013 17:38, Viktor Dukhovni wrote: > On Mon, Jun 03, 2013 at 04:25:21PM +0100, Ben Laurie wrote: > >> > In what context is the normative languate below ( >> > https://tools.ietf.org/html/draft-laurie-pki-sunlight-12#section-3 >> > ) intended to apply? >> > >> > TLS servers MUST present an SCT from one or more logs to the >> > TLS client together with the certificate. TLS clients MUST >> > reject certificates that do not have a valid SCT for the end-entity >> > certificate. >> > >> > Must private-label internal-only corporate CAs implement this >> > standard? >> >> No. >> >> > Does this apply only to certificates that chain to >> > designated roots? >> >> Yes. >> >> > The above >> > requirement seems rather bold without some constraints on its scope. >> >> We should, perhaps, have said something about private CAs. Possibly >> this was omitted because all interested parties already understood the >> exemption and so failed to notice we hadn't put it in the I-D. > > I think this is important to add. Otherwise there seems to be an > inadvertent conflict with DANE TLSA usage 2 and 3. Clients that > implement both standards should be able to verify at least privately > issued usage 3 EE certs, and privately issued usage 2 trust-anchors. > > I think it should be clarified that CT hardens PKIX validation in > the context of the existing public CA PKI for trust chained to > designated PKIX roots (and eventually clients are expected to only > support CT conformant public roots, plus any private roots that > CT-exempted by the client). I think the introduction makes that reasonably clear. In any case, no further changes can be made to that document, which has just completed AUTH48. The intent is to follow up with a new document once we have gained some experience with CT. > When a client that supports both PKIX + CT and another PKI (say > DANE TLSA) is not using PKIX (e.g. DANE usage 2/3), it should be > clear that CT does not apply, and the client is still CT conformant > when it does not apply CT rules outside their intended scope. > > Is that a fair statement of the implicit consensus? It may be helpful > to make it explicit, so as to avoid confusion. > > -- > Viktor. > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From wes@hardakers.net Thu Jun 6 15:33: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 0CA4421F9424 for ; Thu, 6 Jun 2013 15:33:45 -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 R25l+O65Ip+O for ; Thu, 6 Jun 2013 15:33:44 -0700 (PDT) Received: from mail.hardakers.net (dawn.hardakers.net [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id F3ECF21F8956 for ; Thu, 6 Jun 2013 15:33:43 -0700 (PDT) Received: from localhost (unknown [IPv6:2001:470:1f00:187:211f:1683:e2b8:8b09]) by mail.hardakers.net (Postfix) with ESMTPSA id 56D6C29099 for ; Thu, 6 Jun 2013 15:33:41 -0700 (PDT) From: Wes Hardaker To: dane@ietf.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> <20130530160937.GH9380@mournblade.imrryr.org> Date: Thu, 06 Jun 2013 15:33:41 -0700 In-Reply-To: <20130530160937.GH9380@mournblade.imrryr.org> (Viktor Dukhovni's message of "Thu, 30 May 2013 16:09:37 +0000") Message-ID: <0lk3m6lvi2.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 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, 06 Jun 2013 22:33:45 -0000 Viktor Dukhovni writes: > It would be nice to have a DNSSEC-aware local cache on my Android > phone. FYI, our DNSSEC library works on android... -- Wes Hardaker My Pictures: http://capturedonearth.com/ My Thoughts: http://pontifications.hardakers.net/ From wes@hardakers.net Thu Jun 6 15:53: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 CA01E21F96F2 for ; Thu, 6 Jun 2013 15:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-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 SxQWQgeFOcFD for ; Thu, 6 Jun 2013 15:53:59 -0700 (PDT) Received: from mail.hardakers.net (unknown [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id E3D0D21F96EF for ; Thu, 6 Jun 2013 15:53:58 -0700 (PDT) Received: from localhost (unknown [IPv6:2001:470:1f00:187:211f:1683:e2b8:8b09]) by mail.hardakers.net (Postfix) with ESMTPSA id 1131F202EE for ; Thu, 6 Jun 2013 15:53:58 -0700 (PDT) From: Wes Hardaker To: dane@ietf.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> <20130530160937.GH9380@mournblade.imrryr.org> <0lk3m6lvi2.fsf@wjh.hardakers.net> Date: Thu, 06 Jun 2013 15:53:57 -0700 In-Reply-To: <0lk3m6lvi2.fsf@wjh.hardakers.net> (Wes Hardaker's message of "Thu, 06 Jun 2013 15:33:41 -0700") Message-ID: <0lfvwuluka.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 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, 06 Jun 2013 22:53:59 -0000 Wes Hardaker writes: > Viktor Dukhovni writes: > >> It would be nice to have a DNSSEC-aware local cache on my Android >> phone. > > FYI, our DNSSEC library works on android... Whoops; that was supposed to be for Viktor and not a general (discouraged) advertisement, but I had failed to notice that the evil "Reply-To: list" setting had been enabled. -- Wes Hardaker My Pictures: http://capturedonearth.com/ My Thoughts: http://pontifications.hardakers.net/ From bry8star@inventati.org Thu Jun 6 21:14: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 3FDFA21F8E9D for ; Thu, 6 Jun 2013 21:14: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=[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 vsnKE9AfQnQj for ; Thu, 6 Jun 2013 21:14:15 -0700 (PDT) Received: from latitanza.investici.org (latitanza.investici.org [IPv6:2002:525e:f9ea::1]) by ietfa.amsl.com (Postfix) with ESMTP id 65DC921F8E93 for ; Thu, 6 Jun 2013 21:14:14 -0700 (PDT) Received: from [82.94.249.234] (latitanza [82.94.249.234]) (Authenticated sender: bry8star@inventati.org) by localhost (Postfix) with ESMTPSA id 35D3098223 for ; Fri, 7 Jun 2013 04:14:10 +0000 (UTC) X-DKIM: Sendmail DKIM Filter v2.8.2 latitanza.investici.org 35D3098223 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inventati.org; s=stigmate; t=1370578453; bh=GNZKWbajejHj387K+RP/0X7XI4Qp3vOJW+apPrGe4kk=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject:References: In-Reply-To:Content-Type; b=QXuul4rZU85QhmNOa7C1hbpJEuNhiR4b+lhNb7tx8Gpsx8PkrenpNjzkMeMTGAtaa fi4NGDi0naHX03DAuebFdZ6nPLBG+T3zs9YmAqQpIDvI4X5mFIrJR2CxIhhBVVezcl ApLx2lZwgju+6KiicMjVAQWuT/GiGaHVZfzNZhKw= Message-ID: <51B15E1C.6090902@inventati.org> Date: Thu, 06 Jun 2013 21:14:20 -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: <544B0DD62A64C1448B2DA253C011414607ACD1048F@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <5B925F3A-B122-469D-97F5-7DF8A2262795@kumari.net> <69DCBEB1-396E-4EDF-A86B-CB2483CAD094@NLnetLabs.nl> <20130603151512.GH9380@mournblade.imrryr.org> <20130603163800.GI9380@mournblade.imrryr.org> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2FSJXVHPCPWUCLSQHTHDX" Subject: Re: [dane] Classic PKI and DANE in harmony 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: Fri, 07 Jun 2013 04:14:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2FSJXVHPCPWUCLSQHTHDX Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Firefox, Chrome, etc clients need to completely support DANE usage 2 (private CA, Trust Anchor) and DANE usage 3 (End Entity, server, domain-issued) certs, obtained via local DNSSEC validation supported DNS-Resolver, or via native DNSSEC libraries. Since these clients already supports Classic PKI, ... DANE usage case 0 and 1 support not needed immediately. I'm sure devs there, have seen RFC 6698, and related, then why are they not implementing it yet ? something still incomplete ? What is/are stopping them ? These clients should show an icon to indicate when HTTPS based site is authenticated via classic PKIX certs, and when authenticated via TLSA/DANE certs. These should have/show simple indicator icon with "S" or "T" to indicate SSL/TLS authenticated / encrypted, or, an indicator icon with "D" to indicate DANE DNSSEC authenticated / encrypted, or, an indicator icon with "T+D" or "S+D" , or, "T/D" or "S/D" to indicate both path Classic PKIX and DANE authenticated. -- Bright. ------enig2FSJXVHPCPWUCLSQHTHDX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJRsV4lAAoJEID2ikYfWSP65+sP/2d+/yv6EaKTF75VFyePJNu4 JFGUuoZtANzK4z36htq6gLE3pKt2JX/r/bbQ55IeCuAhQEF1o320il6bUPdH3/5T j1LifuOoUFGOKH0bB78EWwuDeexGCAcM7umnZ1OkfPJP12RtYl+96kvFtcBMEIpA pvz5WaYsoLN/54duFIf7xM0owxn94z5P/0r4tLKUYNLtvVU62zV2YC1l43F9ylCc bVH8ILzjxF5UVBrpWIOnI8nvz7KDmIQa7I5mZyz3+ez10dY8GEF9t+xW+wFyzOOn zLiZi3gC5lYhwhHkO0GhYeCFgqxoPsD+ZMIfjjAgKR8/sVZWXCkgS5URPADlJxSQ E3P9/Xj4JOtpxzwV9NMlOwXiDyvlCmONcWBpVjfidJC560GoLcn5RUJCnxyv4xZx EJmNRvAN29JUHmsLj4hR+I2mlvlPzsqixyGw4b26f8mN6rc40TpqoSWeguYhvROF tqGe1rm20NsalAeWN/MKu+US8LLaE4SnIrkZaf5MT4y1EEqhDkNhSI/zR4hztt/K Jfa0U5Op/3MtbqwQVCVW2BLezKSVgqvLF6vsuAbOwBJVAdVbfhLNjesGzoUBvixo 0N30dd6dMjwJVglDNX4psNGoBPGJqLnBgaA/fA9jGjYsNe30jxrRk18578EW5LV5 DZ2DT41qdBNLgDY9tdRG =4cow -----END PGP SIGNATURE----- ------enig2FSJXVHPCPWUCLSQHTHDX-- From bry8star@inventati.org Thu Jun 6 22:25:56 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 B96E121F939E for ; Thu, 6 Jun 2013 22:25:56 -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_33=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 mlUzm8psgLeI for ; Thu, 6 Jun 2013 22:25:55 -0700 (PDT) Received: from latitanza.investici.org (latitanza.investici.org [IPv6:2002:525e:f9ea::1]) by ietfa.amsl.com (Postfix) with ESMTP id 417E721F9374 for ; Thu, 6 Jun 2013 22:25:48 -0700 (PDT) Received: from [82.94.249.234] (latitanza [82.94.249.234]) (Authenticated sender: bry8star@inventati.org) by localhost (Postfix) with ESMTPSA id BC997983A5 for ; Fri, 7 Jun 2013 05:25:45 +0000 (UTC) X-DKIM: Sendmail DKIM Filter v2.8.2 latitanza.investici.org BC997983A5 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inventati.org; s=stigmate; t=1370582747; bh=dr/ZFoPvob4YMso95UMaa24qhpbeSg8Ynj8n5JwopKc=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject:References: In-Reply-To:Content-Type; b=uBaXiwDiEqtvjjiGyByNQ0AOK+8JkD6z0Cbu1axEVcoEWdSqxX+qkvhx0nk5aMwlX fNoE9eBLO0E8Fsi6uMeb4nxZDsIo2+cgfyPvlDI4DpDAB17MjHvxfX51uF7ljxAO/3 ypvnJdCh1zHP7zHEaLMBxhN+ajwd3HkNIHrJx8AE= Message-ID: <51B16EE2.7060704@inventati.org> Date: Thu, 06 Jun 2013 22:25:54 -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: <20130529143710.GV9380@mournblade.imrryr.org> <20130529184555.GY9380@mournblade.imrryr.org> <544B0DD62A64C1448B2DA253C011414607ACD1048F@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2FPJSLTLBOTVKTNLNKFRQ" Subject: Re: [dane] Classic PKI Problems And DNSSEC based Solutions 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: Fri, 07 Jun 2013 05:25:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2FPJSLTLBOTVKTNLNKFRQ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Since most domain-owners/holders send their CSR (cert signing request) to their choice of public CA over unencrypted emails, if these emails are intercepted by such entity/group who is/are capable of doing so, ... then can those entities/groups use such CSR file to obtain an alternative cert from another 3rd party or compromised public CA cert ? and then, can they do/run various types of MITM, exploitations, spoofing, forwarding, surveillance, data-collection, DPI (deep packet inspection) type of devices (or servers), etc ? Common/Public CA entities should either get CSR over TLS encrypted pages from domain-owner, or, over GPG/PGP encrypted emails. And should domain-owner(s) move all CSR, csr.pem, prv.key, prv.key.pem, etc files to an external removable portable (and preferably hot-pluggable) storage device which has encrypted partition ? when dealing with, either their own Private self-signed Root CA, IA (Intermediate Authority), i-CA etc type of cert, or, when dealing with public CA signed cert, unless it is a end-entity server cert related prv.key file, as server/service software needs end-entity server cert's prv.key. I understand, it is possible to obtain same domain-name based SSL cert from a 3rd party CA, and use in middle and run a fake same domain-name server. And if TLSA (aka, DANE) dns record declares/publishes what exact SSL cert is trusted by the domain-owner/holder, then web-browser clients which can/will check it, can make sure what is the correct SSL cert. So that is a very large +point numbers for DANE's advantage, to use very correct SSL cert for securing the communication. But, what type of other problems exist with current PKI implementations ? and, How DANE and which other DNSSEC aspects can solve it slightly better ? -- Bright Star. Received from Jakob Schlyter, on 2013-05-30 12:37 AM: > On 30 maj 2013, at 04:24, Rick Andrews wrot= e: >=20 >> Is there another list that's right for discussing the merits and demer= its of the different DANE options? I work for a CA, so of course I believ= e that the current PKI is *not* irreparably broken, nor do I agree that m= odes 2 and 3 are "substantially more robust". Because I believe your voic= e 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. How= ever, I would argue that without the extra identity proofing and other co= ntrols set by by Extended Validation (EV), DANE has equally security prop= erties to a plain Domain Validation (DV) certificate. >=20 > For a foreseeable future, we definitely need to combine DANE with class= ic PKI in order for the general Internet user to be able to validate cert= ificates. For limited deployments, or applications where classic PKI has = not yet gained significant traction (such as TLS for SMTP), a pure DANE s= olution makes sense (unless EV is required). >=20 > jakob >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 ------enig2FPJSLTLBOTVKTNLNKFRQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJRsW7qAAoJEID2ikYfWSP6DbwQAJiK5FKFs1d8n4ld9hY5EJTB 64mbFTkH39nfvUS23Qc4VU2jIlafZfSQr8VfzaattWL76BTIxhJUULddgvrUteAc kpNHqZMktGVNpNRAvppc0DToscVMdKu/S8P2Q/uwO7mXKC4zXvH9PLi99DD6yzdW faFjN1hlym7EtH1Jlgse45RqQmiov3tUmKiQEUtD1XilADGnclvDY3WLEfTzj8nh kG0Ojf8kIbRD3+GvixuAMH+uLxQx3XJ03r04fc3OOLVGT3L5+N7WqRo0Gx9C1mMa wag1G9pczK83zVXitRoHPC6WgiFc9nB/Ki03rdDZeaYiol/inK2zqEanhf7XQ1V9 eh6MF8sAlTW9vyqBNl8O2MyZcdl1a01rjzaYuoStAadGOulS/0hr/QN+fmuJqi5C kalCI9u2mU2z8Y/tP0XqYhbB+H2A/v913/+4lGLr+QT1d01fUlA04+Ygm8UyqH5v vE9X/ahFa5CUPac8NQnRe3sXEIkXG0AyHmuTQlZgKmxCjbt3I/wXP6CHMvlVoFRD bDkmDdGt4a6E6+cSh2wcuz0HgeM7hSmMXXL8nOsLSbbmMl4mgeWp1ynsNfpgPmC9 HDXrDe62LhF80HzH49j1nqH92y6Bb+QOX3MKqsHE1Mf3aKf/oJdg5yl3jkvIaUpL hlXBOTLMbNhdRw5h+9dd =QElv -----END PGP SIGNATURE----- ------enig2FPJSLTLBOTVKTNLNKFRQ-- From ynir@checkpoint.com Thu Jun 6 22:49: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 829DA21F8EB2 for ; Thu, 6 Jun 2013 22:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, 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 eTHI-ZjTak7Z for ; Thu, 6 Jun 2013 22:49:19 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE5021F9347 for ; Thu, 6 Jun 2013 22:49:18 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r575mrBp031155; Fri, 7 Jun 2013 08:48:53 +0300 X-CheckPoint: {51B17445-1-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Fri, 7 Jun 2013 08:48:53 +0300 From: Yoav Nir To: "" Thread-Topic: [dane] Classic PKI Problems And DNSSEC based Solutions Thread-Index: AQHOYz+IknReZQP+p0uy7Y/yNH7WlpkpjJOA Date: Fri, 7 Jun 2013 05:48:52 +0000 Message-ID: References: <20130529143710.GV9380@mournblade.imrryr.org> <20130529184555.GY9380@mournblade.imrryr.org> <544B0DD62A64C1448B2DA253C011414607ACD1048F@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <51B16EE2.7060704@inventati.org> In-Reply-To: <51B16EE2.7060704@inventati.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.81] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 11d63b7a67d1fad871a97d5de3964a4f1d10deed53 Content-Type: text/plain; charset="iso-8859-1" Content-ID: <9A75E6E1608BA6499542A6D87A12E3D9@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dane] Classic PKI Problems And DNSSEC based Solutions X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 05:49:24 -0000 On Jun 7, 2013, at 8:25 AM, Bry8 Star wrote: > Since most domain-owners/holders send their CSR (cert signing > request) to their choice of public CA over unencrypted emails, if > these emails are intercepted by such entity/group who is/are capable > of doing so, ... then can those entities/groups use such CSR file to > obtain an alternative cert from another 3rd party or compromised > public CA cert ? CAs make some effort to only send the signed certificate to the actual doma= in owner, but I suppose if the attacker is able to intercept the domain own= er's mail, they could probably use the CSR to obtain a valid certificate fo= r the domain. > and then, can they do/run various types of MITM, > exploitations, spoofing, forwarding, surveillance, data-collection, > DPI (deep packet inspection) type of devices (or servers), etc ? No. Since they're using the original CSR, their MitM attack will fail. If t= hey generate their own CSR, the keys won't fit the TLSA record (or HPKP pin= ) > Common/Public CA entities should either get CSR over TLS encrypted > pages from domain-owner, or, over GPG/PGP encrypted emails. Many already allow you to upload the CSR through the web site, which is som= etimes protected by TLS. But CSRs, much like certificates, are not consider= ed secret information. > And should domain-owner(s) move all CSR, csr.pem, prv.key, > prv.key.pem, etc files to an external removable portable (and > preferably hot-pluggable) storage device which has encrypted > partition ? when dealing with, either their own Private self-signed > Root CA, IA (Intermediate Authority), i-CA etc type of cert, or, > when dealing with public CA signed cert, unless it is a end-entity > server cert related prv.key file, as server/service software needs > end-entity server cert's prv.key. It depends. The operational security of running HTTPS servers is a complex = issue, and the solution that fits a personal blog is not the same that woul= d fit a small online store, and not the same that would fit Google, Faceboo= k, or a bank. I don't see what Google would gain from placing the private k= ey on an external, removable, portable, and hot-pluggable device - their se= rvers are always on. > I understand, it is possible to obtain same domain-name based SSL > cert from a 3rd party CA, and use in middle and run a fake same > domain-name server. >=20 > And if TLSA (aka, DANE) dns record declares/publishes what exact SSL > cert is trusted by the domain-owner/holder, then web-browser clients > which can/will check it, can make sure what is the correct SSL cert. > So that is a very large +point numbers for DANE's advantage, to use > very correct SSL cert for securing the communication. >=20 > But, what type of other problems exist with current PKI > implementations ? and, How DANE and which other DNSSEC aspects can > solve it slightly better ? >=20 > -- Bright Star. >=20 >=20 >=20 > Received from Jakob Schlyter, on 2013-05-30 12:37 AM: >> On 30 maj 2013, at 04:24, Rick Andrews wrote= : >>=20 >>> Is there another list that's right for discussing the merits and demeri= ts of the different DANE options? I work for a CA, so of course I believe t= hat 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 re= spected in this forum, I wanted to speak up to make it clear that this opin= ion is not shared by all. >>=20 >> Unless the chairs do not object, I believe this mailing list is a good p= lace to discuss this matters. >>=20 >> IMHO, classic PKI augmented by DANE would be a very strong package. Howe= ver, I would argue that without the extra identity proofing and other contr= ols set by by Extended Validation (EV), DANE has equally security propertie= s to a plain Domain Validation (DV) certificate. >>=20 >> For a foreseeable future, we definitely need to combine DANE with classi= c PKI in order for the general Internet user to be able to validate certifi= cates. For limited deployments, or applications where classic PKI has not y= et gained significant traction (such as TLS for SMTP), a pure DANE solution= makes sense (unless EV is required). >>=20 >> jakob >>=20 >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >>=20 >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From jakob@kirei.se Thu Jun 6 23:50: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 0191F21F941D for ; Thu, 6 Jun 2013 23:50: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 ihwENEm441-f for ; Thu, 6 Jun 2013 23:50:25 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id 0B52C21F85F7 for ; Thu, 6 Jun 2013 23:50:18 -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=bJVq0g+xVBnbqUp/6Hxg1h17lx4XdlFaIBNeT46AYGk=; b=AE1h6bdw9DEpbYjvkI5qxf9mYm7VlDHfHbI8XKajVKM0VSfjvNk5ce9E2Z84wn4d0KJMLO11n8HrT 8B1mIbfslL20BQ7UQKiYgfqf055FXOBNplS1hmXRG1bQYj+uUxycUHukOU9e40EOLdhqRdrE/Vra7V Jll/tHhck4VopgZs= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Fri, 7 Jun 2013 08:50:15 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jakob Schlyter In-Reply-To: <51B15E1C.6090902@inventati.org> Date: Fri, 7 Jun 2013 08:50:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <544B0DD62A64C1448B2DA253C011414607ACD1048F@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <5B925F3A-B122-469D-97F5-7DF8A2262795@kumari.net> <69DCBEB1-396E-4EDF-A86B-CB2483CAD094@NLnetLabs.nl> <20130603151512.GH9380@mournblade.imrryr.org> <20130603163800.GI9380@mournblade.imrryr.org> <51B15E1C.6090902@inventati.org> To: bry8star@inventati.org 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, 07 Jun 2013 06:50:30 -0000 On 7 jun 2013, at 06:14, Bry8 Star wrote: > Firefox, Chrome, etc clients need to completely support DANE usage 2 > (private CA, Trust Anchor) and DANE usage 3 (End Entity, server, > domain-issued) certs, obtained via local DNSSEC validation supported > DNS-Resolver, or via native DNSSEC libraries. Since these clients > already supports Classic PKI, ... DANE usage case 0 and 1 support > not needed immediately. I would argue for the the opposite. Augmented PKI with DANE 0/1 would = make a lot more sense riskwise and fit better into the current trust = model. 1/2 could/should be made experimental in order to gain more = experience; once that has been established we can move forward and = enable it by default. > I'm sure devs there, have seen RFC 6698, and related, then why are > they not implementing it yet ? something still incomplete ? What > is/are stopping them ? =46rom what I've heard, some are worried about the different failure = modes. I believe we need to do more work on analyzing these and looking = at the consequences of these in a world where DNSSEC lookups sometimes = does not work and/or result in bad answers. > These clients should show an icon to indicate when HTTPS based site > is authenticated via classic PKIX certs, and when authenticated via > TLSA/DANE certs. These should have/show simple indicator icon with > "S" or "T" to indicate SSL/TLS authenticated / encrypted, or, an > indicator icon with "D" to indicate DANE DNSSEC authenticated / > encrypted, or, an indicator icon with "T+D" or "S+D" , or, "T/D" or > "S/D" to indicate both path Classic PKIX and DANE authenticated. User UI overload will not increase security - it will just confuse the = end user. Some of the users out there has actually managed to tell DV = and EV apart, more UI bloat will fail, IMHO.=20 jakob From bry8star@inventati.org Fri Jun 7 08:02: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 CA52F21F8E2C for ; Fri, 7 Jun 2013 08:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_33=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 0on3Ju3wOb1M for ; Fri, 7 Jun 2013 08:02:19 -0700 (PDT) Received: from latitanza.investici.org (latitanza.investici.org [IPv6:2002:525e:f9ea::1]) by ietfa.amsl.com (Postfix) with ESMTP id 02FF821F86D3 for ; Fri, 7 Jun 2013 08:02:17 -0700 (PDT) Received: from [82.94.249.234] (latitanza [82.94.249.234]) (Authenticated sender: bry8star@inventati.org) by localhost (Postfix) with ESMTPSA id 6EC2F98175 for ; Fri, 7 Jun 2013 15:02:12 +0000 (UTC) X-DKIM: Sendmail DKIM Filter v2.8.2 latitanza.investici.org 6EC2F98175 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inventati.org; s=stigmate; t=1370617334; bh=5bKiCN9EGAprvtx01F4MowrhX76qOvUF5AogLgefsPU=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject:References: In-Reply-To:Content-Type; b=gqMWbaSnGk78Fo/6fNnnbOttunoZGu40G7VA86n+g/vsUXeJ+IcKEBJVpDobL4ATs Q+9KwM1QtGj+DNezD0OZhdo2A2AKZAcE+HAA11mPc3DjaXWcWHWpRbg8CKWRF4sM1b 3AD+1pejEOxqN1aqnt+iLVY+8YqulzorRtdJT4tg= Message-ID: <51B1F5FA.9020407@inventati.org> Date: Fri, 07 Jun 2013 08:02:18 -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: <20130529143710.GV9380@mournblade.imrryr.org> <20130529184555.GY9380@mournblade.imrryr.org> <544B0DD62A64C1448B2DA253C011414607ACD1048F@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <51B16EE2.7060704@inventati.org> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2GPDLNQRAFNHXLEOVVSWL" Subject: Re: [dane] Classic PKI Problems And DNSSEC based Solutions 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: Fri, 07 Jun 2013 15:02:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2GPDLNQRAFNHXLEOVVSWL Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Yoav, thanks for corrections. But i think i failed to convey what i wanted to say for the first half part. Received from Yoav Nir, on 2013-06-06 10:48 PM: >=20 > On Jun 7, 2013, at 8:25 AM, Bry8 Star wrote: >=20 >> Since most domain-owners/holders send their CSR (cert signing >> request) to their choice of public CA over unencrypted emails, if >> these emails are intercepted by such entity/group who is/are capable >> of doing so, ... then can those entities/groups use such CSR file to >> obtain an alternative cert from another 3rd party or compromised >> public CA cert ? >=20 > CAs make some effort to only send the signed certificate to the actual = domain owner, but I suppose if the attacker is able to intercept the doma= in owner's mail, they could probably use the CSR to obtain a valid certif= icate for the domain. >=20 >> and then, can they do/run various types of MITM, >> exploitations, spoofing, forwarding, surveillance, data-collection, >> DPI (deep packet inspection) type of devices (or servers), etc ? >=20 > No. Since they're using the original CSR, their MitM attack will fail. = If they generate their own CSR, the keys won't fit the TLSA record (or HP= KP pin) >=20 Since most domain-owner uses HOSTing/CLOUD based REMOTE-SERVERs, i consider any type of private_keys, secret_keys, etc there are already intercepted / copied / compromised. Since many are known to assist in Surveillance and Data-collection. And most domains are not yet DNSSEC signed, and most domain-owner's do not sign with DNSSEC, yet. *sad* I should have mentioned this in my posted paragraph. I wanted to talk about things, what most domain-owner's normally do and believe. >=20 >> Common/Public CA entities should either get CSR over TLS encrypted >> pages from domain-owner, or, over GPG/PGP encrypted emails. >=20 > Many already allow you to upload the CSR through the web site, which is= sometimes protected by TLS. But CSRs, much like certificates, are not co= nsidered secret information. >=20 Thanks for clarifying. >=20 >> And should domain-owner(s) move all CSR, csr.pem, prv.key, >> prv.key.pem, etc files to an external removable portable (and >> preferably hot-pluggable) storage device which has encrypted >> partition ? when dealing with, either their own Private self-signed >> Root CA, IA (Intermediate Authority), i-CA etc type of cert, or, >> when dealing with public CA signed cert, unless it is a end-entity >> server cert related prv.key file, as server/service software needs >> end-entity server cert's prv.key. >=20 > It depends. The operational security of running HTTPS servers is a comp= lex issue, and the solution that fits a personal blog is not the same tha= t would fit a small online store, and not the same that would fit Google,= Facebook, or a bank. I don't see what Google would gain from placing the= private key on an external, removable, portable, and hot-pluggable devic= e - their servers are always on. >=20 I do not think i said, Google should place private_keys on removable storage device. I mentioned, any private self-signed Root-CA, intermediate CA, intermediate authority, etc cert's private_keys, csr, etc files should be moved into removable storage device, and mentioned NOT to move last level / end-entity, that is, server-cert's private_keys, as service software needs that private_keys. Google suppose to keep server-cert's private_key on their server. >=20 >> I understand, it is possible to obtain same domain-name based SSL >> cert from a 3rd party CA, and use in middle and run a fake same >> domain-name server. >> >> And if TLSA (aka, DANE) dns record declares/publishes what exact SSL >> cert is trusted by the domain-owner/holder, then web-browser clients >> which can/will check it, can make sure what is the correct SSL cert. >> So that is a very large +point numbers for DANE's advantage, to use >> very correct SSL cert for securing the communication. >> >> But, what type of other problems exist with current PKI >> implementations ? and, How DANE and which other DNSSEC aspects can >> solve it slightly better ? >> >> -- Bright Star. >> >> >> >> Received from Jakob Schlyter, on 2013-05-30 12:37 AM: >>> On 30 maj 2013, at 04:24, Rick Andrews wr= ote: >>> >>>> Is there another list that's right for discussing the merits and dem= erits of the different DANE options? I work for a CA, so of course I beli= eve 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 vo= ice is respected in this forum, I wanted to speak up to make it clear tha= t this opinion is not shared by all. >>> >>> Unless the chairs do not object, I believe this mailing list is a goo= d place to discuss this matters. >>> >>> IMHO, classic PKI augmented by DANE would be a very strong package. H= owever, I would argue that without the extra identity proofing and other = controls set by by Extended Validation (EV), DANE has equally security pr= operties to a plain Domain Validation (DV) certificate. >>> >>> For a foreseeable future, we definitely need to combine DANE with cla= ssic PKI in order for the general Internet user to be able to validate ce= rtificates. For limited deployments, or applications where classic PKI ha= s 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 >>> >> >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane ------enig2GPDLNQRAFNHXLEOVVSWL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJRsfYFAAoJEID2ikYfWSP6FMsP+wc9S1HiBzSaIa2iBHgn2xyl wwHPHthg7ihblXe/PVqlvEE7s+ftDLjdtmbX3f9DTE+tn/bCFU8FITpGZIkokDc/ OA2Ig1a+mOtL2n8sNfvCfFcvrPjuCpHby2SbnRqHMq9PnvUpARwgmAwqsun27uN4 wvCkkKr4GTs8/tydiyfjA7d+Ns3YqCHbl9GFB7+ExkaHU7Qa/LAu15a+5obIiNy+ /zJMN0Ldrbp5jvC4jhEXlyuFoovlMr9gRU+38lGYjt+BWWzJ/ssAH7G8GPfrpKSh 0HXuX1pvt4cSi9U7PS7XJ4oCelcOpxUOE6yySYuhTjpbsV4gNWPgulUDELfZBeFw oKAHGEJdgNX+b7C0AtFO7pJKHSXXRcADVkWsOVMWLE6M6ai7eXWTL2rtMXM64JC1 4Um4pG6+9304WAi8ZbPJQ3Fb3/YoJKK9cx1HV5BTTFDmRyL2zxtV2Sv1WlxEnQck 60i4g8uOhx8/ysgaMS9BX38bvIBg9XBmUWE6mqXRRBw5ECyRtXxNTzRho34iKSa6 Mg62tNnmkXQxA23Uhoir97CcemVOP7YY0rEW9c5ycPMP52b2ilSBk3Fj5FrSKyZw zDM/1jdeDLWBV+piE5ABaXNJTgJWjQcTEkBGiU71ITwM8UMjyFfkA8ekZcUz6ABj yCFd041e9zpb4lrkOx4E =lyWE -----END PGP SIGNATURE----- ------enig2GPDLNQRAFNHXLEOVVSWL-- From viktor1dane@dukhovni.org Fri Jun 7 08:59: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 4D16A21F9711 for ; Fri, 7 Jun 2013 08:59: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 AkcYX1oYYsI9 for ; Fri, 7 Jun 2013 08:59:23 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 22A9E21F9051 for ; Fri, 7 Jun 2013 08:59:23 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 523CA2AABAF; Fri, 7 Jun 2013 15:59:22 +0000 (UTC) Date: Fri, 7 Jun 2013 15:59:22 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130607155922.GU9380@mournblade.imrryr.org> References: <20130529143710.GV9380@mournblade.imrryr.org> <20130529184555.GY9380@mournblade.imrryr.org> <544B0DD62A64C1448B2DA253C011414607ACD1048F@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <51B16EE2.7060704@inventati.org> <51B1F5FA.9020407@inventati.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51B1F5FA.9020407@inventati.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Classic PKI Problems And DNSSEC based Solutions 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, 07 Jun 2013 15:59:28 -0000 On Fri, Jun 07, 2013 at 08:02:18AM -0700, Bry8 Star wrote: > Since most domain-owner uses HOSTing/CLOUD based REMOTE-SERVERs, i > consider any type of private_keys, secret_keys, etc there are > already intercepted / copied / compromised. Since many are known to > assist in Surveillance and Data-collection. And most domains are > not yet DNSSEC signed, and most domain-owner's do not sign with > DNSSEC, yet. *sad* I should have mentioned this in my posted > paragraph. I wanted to talk about things, what most domain-owner's > normally do and believe. This thread seems to have veered in a naive direction unrelated to IETF stardards. Perhaps the chairs can bring us back on track. -- Viktor. From hallam@gmail.com Fri Jun 7 09:30: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 B29D121F92EC for ; Fri, 7 Jun 2013 09:30:08 -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 OqDYEfmJOEK0 for ; Fri, 7 Jun 2013 09:30:07 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 208B421F9298 for ; Fri, 7 Jun 2013 09:30:06 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id ey16so1526858wid.3 for ; Fri, 07 Jun 2013 09:30:06 -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=ApyIBMMgcw4xVBg0RPQVH9xvitBY3H3l44Y0T85Ee24=; b=BjDy9sqnIb2yAxRKY46brT9nLVe0u090GEfbdRidkAWJ2XMMxHBLGWfXKbd6OFKL6+ AjyBW9fZhr0521GYH4oyCI/gc1g7MVsiaL4gFt047dGrumZaiCQzXUCpq0+y7f6qhF+Y YS71HvpmdFFGwW8adOFbeLb977YRj3cEqVDN9QsZWRbGa6ut6AS/HdgQplnnnT7WEwD2 56OFyxFO1SbgZAPaJtJAt07zlCZ6jVI9eCvaS56+q1w51N12VExGzXYZDKAd/7ykYB0n lfmbgmkGvFnzgz9xdJXEIYR0+QqWVcX1Q+OINfEMlG5qle+B5f1uIGOq1b7qyXUnT5Nh KuOA== MIME-Version: 1.0 X-Received: by 10.180.189.136 with SMTP id gi8mr1999315wic.11.1370622606249; Fri, 07 Jun 2013 09:30:06 -0700 (PDT) Received: by 10.194.44.100 with HTTP; Fri, 7 Jun 2013 09:30:06 -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, 7 Jun 2013 12:30:06 -0400 Message-ID: From: Phillip Hallam-Baker To: Ben Laurie Content-Type: multipart/alternative; boundary=001a11c2412c9114c904de92f19e 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, 07 Jun 2013 16:30:08 -0000 --001a11c2412c9114c904de92f19e Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 3, 2013 at 5:21 AM, Ben Laurie wrote: > > Omnibroker introduces a trusted third party. It may be better than the > status quo, but I think we've got adequate proof that we can't > actually trust TTPs. > Like the 9 companies allegedly involved in PRISM? I agree that we can't absolutely trust any party. We can't put absolute trust in Google, or ICANN or Comodo. But the current design of the Web requires us to trust all of them and rather more. The situation is not the same with Google however as I can at least decide whether or not to trust Google. I can in fact build an entirely Google-free tool chain if I want. I can eliminate the need to trust Google but not the need to trust at least one browser provider and one search engine[1]. The real point is not that I get to choose whether to trust Google but not whether to trust Comodo or ICANN. And that is the difference between a CA an Omnibroker as TTPs. They are both TTPs but one is an agent of and chosen by the server operator and the other is chosen by the client operator. Ah but now you are going to say that I can compile Chrome from source. Which just leaves me with the task of checking a billion lines of source for a backdoor. Omnibroker is designed to provide the same option. If you install your own Omnibroker service you can do all the checking yourself for every client that supports the protocol. You can do DANE checks and CT and Convergence and anything else that you might invent in the future. You can do all those checks all by yourself or you can ask a Symantec or a Comodo or a Kaspersky for information on possible bad IP addresses, botnets etc. I am working to develop an open source Omnibroker that can be used as the basis for just such a system called Tin-Foil-Hat. Some of the code is already on Sourceforge. SCVP and XKMS make a distinction between Certificate Path Discovery and Certificate Path Validation. You can use either server as simply a service that will find the information you need to make a trust decision or you can outsource your trust decision. Omibroker allows the same thing but it is not limited to PKI. -- Website: http://hallambaker.com/ --001a11c2412c9114c904de92f19e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Jun 3, 2013 at 5:21 AM, Ben Laurie <benl@google.com= > wrote:

Omnibroker introduces a trusted third party. It may be better t= han the
status quo, but I think we've got adequate proof that we can't
actually trust TTPs.

Like the 9 companies allegedly involved in PRISM?

I = agree that we can't absolutely trust any party. We can't put absolu= te trust in Google, or ICANN or Comodo. But the current design of the Web r= equires us to trust all of them and rather more.

The situation is not the same with Google however as I can at least decide= whether or not to trust Google. I can in fact build an entirely Google-fre= e tool chain if I want. I can eliminate the need to trust Google but not th= e need to trust at least one browser provider and one search engine[1].=A0<= /div>


The real point is not that I ge= t to choose whether to trust Google but not whether to trust Comodo or ICAN= N. And that is the difference between a CA an Omnibroker as TTPs. They are = both TTPs but one is an agent of and chosen by the server operator and the = other is chosen by the client operator.

Ah but now you are going to say that I can compile Chrome from sourc= e. Which just leaves me with the task of checking a billion lines of source= for a backdoor. Omnibroker is designed to provide the same option.

If you install your own Omnibroker service you can do all the checki= ng yourself for every client that supports the protocol. You can do DANE ch= ecks and CT and Convergence and anything else that you might invent in the = future. You can do all those checks all by yourself or you can ask a Symant= ec or a Comodo or a Kaspersky for information on possible bad IP addresses,= botnets etc.

I am working to develop an open source Omnibroker that can be used as the = basis for just such a system called Tin-Foil-Hat. Some of the code is alrea= dy on Sourceforge.


SCVP an= d XKMS make a distinction between Certificate Path Discovery and Certificat= e Path Validation. You can use either server as simply a service that will = find the information you need to make a trust decision or you can outsource= your trust decision. Omibroker allows the same thing but it is not limited= to PKI.

--
Website: http://h= allambaker.com/
--001a11c2412c9114c904de92f19e-- From guido@witmond.nl Fri Jun 7 09:47: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 D06D221F96F2 for ; Fri, 7 Jun 2013 09:47:45 -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=[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 Bw8P8PBZK9KG for ; Fri, 7 Jun 2013 09:47:41 -0700 (PDT) Received: from smtp-vbr4.xs4all.nl (smtp-vbr4.xs4all.nl [194.109.24.24]) by ietfa.amsl.com (Postfix) with ESMTP id 89D4821F8EAE for ; Fri, 7 Jun 2013 09:47:40 -0700 (PDT) Received: from [10.1.2.6] (mail.witmond.nl [80.100.189.3] (may be forged)) by smtp-vbr4.xs4all.nl (8.13.8/8.13.8) with ESMTP id r57GlcOu005811 for ; Fri, 7 Jun 2013 18:47:39 +0200 (CEST) (envelope-from guido@witmond.nl) Message-ID: <51B20EAA.7040708@witmond.nl> Date: Fri, 07 Jun 2013 18:47:38 +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 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Subject: [dane] Eccentric Authentication, a DANE application X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2013 16:47:45 -0000 Dear readers, I've been designing a protocol and writing some code to create anonymous client certificates easily. In brief: Each website operator that wants to get rid of passwords can deploy a local CA to sign its users' client certificates. It signs only for his own clients. The site does not trust any other CA for client certificates. Users are free to choose their own account name. We store it in the certificate Common Name at certification time. Lazy users just ask their user agent to come up with a long random number. There is one requirement, each Common name must be unique. To verify that each user publishes his certificate at a global registry. By tying the RootCA certificate in DNSSEC with DANE, the local (self signed) Root certificate becomes the *verifiable identity* of the web site. Only the site operator and a few domain registry people are able to change that. A change that will not go unnoticed with the global registry. The benefits are great: The customers (user agent) can verify the identity of the site before loggin in with the client certificate for that site. This prevents MitM attacks. The customer stays anonymous for as long as he wants. The site can send encrypted messages to the customers. And back. The users can send encrypted messages amongst each other (when the site does the message transfer) or the users use independent channels. Demo I have a demo site and the software to download: http://eccentric-authentication.org/blog/2013/06/07/run-it-yourself.html Regards, Guido Witmond. From benl@google.com Mon Jun 10 07:50: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 D9AC221F93B7 for ; Mon, 10 Jun 2013 07:50:22 -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 6bMAk-5bmjOZ for ; Mon, 10 Jun 2013 07:50:22 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id EED7D21F8F87 for ; Mon, 10 Jun 2013 07:50:21 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id ar20so14070998iec.35 for ; Mon, 10 Jun 2013 07:50:21 -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=d2bWpejg5tRZDVAhxvAiVsO1oVZ/7nltwXxIB7Dffyg=; b=dNWncZH2lbEUPu8taNcQwazoelBzgFP7Y63vfhSM4wdS62MkU1ojWDNSPSdOvpT+Bb MhjbhnENGeo1PN2JLGlbGuAZaDFELMcU5LGXmgW+TIuJZIqFrj/kj2IjeWBH+0INWWor DfDEG7o2oT2E30NXOtpXvS9E4Ahel7J0c3SDiSqpTahVzW1POGJh4JGxxRc5gyF8EoQb 31l+Iw/hlda5NtlLm/B0E3FLkrFQq5QQuteXbG3iVrh+1hDKk3NqISLOA50ip21ASCM+ i4JYlGcaCJAaAnmksWhUFjIqFIyy8AUYZxOMpc+q66WFvD1IOY4TfAbg7SIJj9Ttiqoh SybA== 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=d2bWpejg5tRZDVAhxvAiVsO1oVZ/7nltwXxIB7Dffyg=; b=cQGMeIAPWBMxK3FM/BF7zHbbLheBpbDG8NUrt6vRux8Q08bLVEZShebnVGYm+u8e9z hmAK5Fa2sbDjKiUCzVxLNggupx1Nj54KFVdd4q/pi+agSK76lj0pgqOPaxo+VXKXRJFr r93pZd2VstT7OsIAKQfQELcLmudFVoNBfsqkeZ2VoZYK2mKwsXNT3l7Wuc/Md6UfaHwD amZNm1jj8F31lbnwLTXr623MaUOLCjb0luXCSORm/WaB6C/67UC1QQbQeludu7BU8GQU EfYvbGWJF/Jz5w3o0vbCL/iG8PsU+IKmZcpkOWxR9Wt+nleVfhWUT7CaMIBLv1qQ7Kg0 Z+2g== MIME-Version: 1.0 X-Received: by 10.50.87.4 with SMTP id t4mr4177240igz.76.1370875821499; Mon, 10 Jun 2013 07:50:21 -0700 (PDT) Received: by 10.64.42.72 with HTTP; Mon, 10 Jun 2013 07:50:21 -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: Mon, 10 Jun 2013 15:50:21 +0100 Message-ID: From: Ben Laurie To: Phillip Hallam-Baker Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkHkWugzCsB70YEhfYJyEF1fmmMMk7UXTcCfsgyKnZwJypYDLmPD5x01twqf+FzPev4wde/UgxgaE4ZGao0VcLtUZX5OJGHR9KlhOV7S0dvMvtW6N8OmL+V1lxRDJS5WIsMkxbUARLOILhBoyUoA1hW/Svxv3dow1lwOBjZW6A0tdoiYhTdvBzNb5XIZrfiBBTtUUHC 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: Mon, 10 Jun 2013 14:50:23 -0000 On 7 June 2013 17:30, Phillip Hallam-Baker wrote: > On Mon, Jun 3, 2013 at 5:21 AM, Ben Laurie wrote: >> >> >> Omnibroker introduces a trusted third party. It may be better than the >> status quo, but I think we've got adequate proof that we can't >> actually trust TTPs. > > > Like the 9 companies allegedly involved in PRISM? > > I agree that we can't absolutely trust any party. We can't put absolute > trust in Google, or ICANN or Comodo. But the current design of the Web > requires us to trust all of them and rather more. > > The situation is not the same with Google however as I can at least decide > whether or not to trust Google. I can in fact build an entirely Google-free > tool chain if I want. I can eliminate the need to trust Google but not the > need to trust at least one browser provider and one search engine[1]. > > > The real point is not that I get to choose whether to trust Google but not > whether to trust Comodo or ICANN. And that is the difference between a CA an > Omnibroker as TTPs. They are both TTPs but one is an agent of and chosen by > the server operator and the other is chosen by the client operator. My point is that CT introduces _untrusted_ third parties, and I think that's the way forward. Replacing the UTP with a TTP you trust to verify the UTP seems like a step backwards, regardless of my freedom to choose who I misplace my trust in. > Ah but now you are going to say that I can compile Chrome from source. Which > just leaves me with the task of checking a billion lines of source for a > backdoor. Omnibroker is designed to provide the same option. > > If you install your own Omnibroker service you can do all the checking > yourself for every client that supports the protocol. You can do DANE checks > and CT and Convergence and anything else that you might invent in the > future. You can do all those checks all by yourself or you can ask a > Symantec or a Comodo or a Kaspersky for information on possible bad IP > addresses, botnets etc. Hmm. I think you need to incorporate some way for an evil Omnibroker to be both detectable and possible to bring to justice (i.e. something like CT consistency proofs). Our outline for Revocation Transparency might be a way to do that. > I am working to develop an open source Omnibroker that can be used as the > basis for just such a system called Tin-Foil-Hat. Some of the code is > already on Sourceforge. There's already a Linux distro called that, I believe. > SCVP and XKMS make a distinction between Certificate Path Discovery and > Certificate Path Validation. You can use either server as simply a service > that will find the information you need to make a trust decision or you can > outsource your trust decision. Omibroker allows the same thing but it is not > limited to PKI. > > -- > Website: http://hallambaker.com/ From ogud@ogud.com Mon Jun 10 08:39: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 5DF1B21F9631 for ; Mon, 10 Jun 2013 08:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 H3DF0mPodLOy for ; Mon, 10 Jun 2013 08:39:36 -0700 (PDT) Received: from smtp100.ord1c.emailsrvr.com (smtp100.ord1c.emailsrvr.com [108.166.43.100]) by ietfa.amsl.com (Postfix) with ESMTP id 2DEFF21F9408 for ; Mon, 10 Jun 2013 08:39:36 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp5.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 9804A1B00BB for ; Mon, 10 Jun 2013 11:39:35 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp5.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 00BDC1B0106 for ; Mon, 10 Jun 2013 11:39:34 -0400 (EDT) From: Olafur Gudmundsson Content-Type: multipart/alternative; boundary="Apple-Mail=_A0D582AA-F78A-4943-B10F-D6228C7109D1" Date: Mon, 10 Jun 2013 11:39:35 -0400 References: <20130610153649.3693.4222.idtracker@ietfa.amsl.com> To: "dane@ietf.org" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [dane] Fwd: New Version Notification for draft-ogud-dane-vocabulary-00.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 15:39:40 -0000 --Apple-Mail=_A0D582AA-F78A-4943-B10F-D6228C7109D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii In the process of reviewing number of drafts that attempt to expand DANE = to other protocols, I thought it might be useful=20 to use more structured language an terms.=20 This is an initial version of such definitions, if this is useful I will = ask for WG adoptions Olafur Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-ogud-dane-vocabulary-00.txt > Date: June 10, 2013 11:36:49 AM EDT > To: Olafur Gudmundsson >=20 >=20 > A new version of I-D, draft-ogud-dane-vocabulary-00.txt > has been successfully submitted by Olafur Gudmundsson and posted to = the > IETF repository. >=20 > Filename: draft-ogud-dane-vocabulary > Revision: 00 > Title: Harmonizing how applications specify DANE-like = usage > Creation date: 2013-06-10 > Group: Individual Submission > Number of pages: 7 > URL: = http://www.ietf.org/internet-drafts/draft-ogud-dane-vocabulary-00.txt > Status: = http://datatracker.ietf.org/doc/draft-ogud-dane-vocabulary > Htmlized: = http://tools.ietf.org/html/draft-ogud-dane-vocabulary-00 >=20 >=20 > Abstract: > This document proposes a specific word usage for specifications of > DANE like technology by different protocols/services. DANE is a > method for specifying in DNS records acceptable keys/certificates = for > application servers. >=20 --Apple-Mail=_A0D582AA-F78A-4943-B10F-D6228C7109D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii = Olafur


Begin forwarded = message:

Subject: New Version Notification for = draft-ogud-dane-vocabulary-00.txt
Date: June 10, 2013 = 11:36:49 AM EDT
To: Olafur Gudmundsson <ogud@ogud.com>


A new version of I-D, draft-ogud-dane-vocabulary-00.txt
has = been successfully submitted by Olafur Gudmundsson and posted to = the
IETF repository.

Filename: = draft-ogud-dane-vocabulary
Revision: 00
Title: = Harmonizing how applications specify DANE-like usage
Creation = date: = 2013-06-10
Group: Individual Submission
Number = of pages: 7
URL: =             http://www.ietf.org/internet-drafts/draft-ogud-dane-vocabulary-00.txt=
Status:          http:/= /datatracker.ietf.org/doc/draft-ogud-dane-vocabulary
Htmlized: =        http://t= ools.ietf.org/html/draft-ogud-dane-vocabulary-00


Abstract:<= br>   This document proposes a specific word usage for = specifications of
  DANE like technology by different = protocols/services.  DANE is a
  method for = specifying in DNS records acceptable keys/certificates for
=   application = servers.


= --Apple-Mail=_A0D582AA-F78A-4943-B10F-D6228C7109D1-- From bry8star@inventati.org Tue Jun 11 01:53: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 3E4AC21F9A82 for ; Tue, 11 Jun 2013 01:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 RnVWlJ5eoruG for ; Tue, 11 Jun 2013 01:53:24 -0700 (PDT) Received: from latitanza.investici.org (latitanza.investici.org [IPv6:2002:525e:f9ea::1]) by ietfa.amsl.com (Postfix) with ESMTP id F0F0C21F9A7F for ; Tue, 11 Jun 2013 01:53:23 -0700 (PDT) Received: from [82.94.249.234] (latitanza [82.94.249.234]) (Authenticated sender: bry8star@inventati.org) by localhost (Postfix) with ESMTPSA id 7583298168 for ; Tue, 11 Jun 2013 08:53:18 +0000 (UTC) X-DKIM: Sendmail DKIM Filter v2.8.2 latitanza.investici.org 7583298168 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inventati.org; s=stigmate; t=1370940801; bh=sPbUklcKDhptSU5DPHMdimwNBmXeGehQ1U5UUqkqEFM=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject:References: In-Reply-To:Content-Type; b=WVPsOeXqUoCaGouR6Ky9H/t0AXQK8xZNC0j+q3nKh5+N6HL1cKGTejlTmvq92x8Gi 90VOVWWadvTy1lRVtU0IsXcX9RiMuKzraIbrhhHzICnRUc1q9y6YPMiA2sj24zCbIh /QcgCpgrL+flD5mqbibc+IO+/aZsRA980YUYE+9k= Message-ID: <51B6E556.7040701@inventati.org> Date: Tue, 11 Jun 2013 01:52:38 -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: <51A5C775.7020707@inventati.org> In-Reply-To: <51A5C775.7020707@inventati.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2TAIVRQKTSKMOPLAGSJIL" 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: 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: Tue, 11 Jun 2013 08:53:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2TAIVRQKTSKMOPLAGSJIL Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Can someone kindly give some PRACTICAL pointers ? which can used command by command to create these TLSA dns entries ? for mentioned PKIX structure. -- Bright Star. Received from Bry8 Star, on 2013-05-29 2:16 AM: > How to use TLSA "2 s m" , "3 s m" ? >=20 > Please correct me anytime, my understanding is: >=20 > 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. >=20 > For those (above) approaches to work: >=20 > * 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), >=20 > * 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). >=20 > 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. >=20 > cert =3D certificate , aka =3D also known as , CA =3D Certificate > Authority , TA =3D Trust Anchor, EE =3D end entity. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > - - - - - - - - - - - - - - - - - - - - - - - - - >=20 > 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 : >=20 > 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 } >=20 > and then i created for dom2.tld : >=20 > 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 } >=20 > and so on. >=20 > 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". >=20 > 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". >=20 > Physical_Server_3 has: > * 'livemsg' host of "dom1.tld" in a VM instance, * 'livemsg' host of > "dom2.tld", * 'livemsg' host of "dom3.tld" >=20 > "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. >=20 > 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. >=20 > So how many & what DNS RR will "www" host/server for "dom1.tld" will > exactly need/have for providing DANE based HTTPS service ? >=20 > In apache/nginx server software (HTTPS service daemon), in what > order it will have to provide those tls/ssl certs ? >=20 > What else need to be configured ? >=20 > Thanks in advance, >=20 > -- Bright Star. > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 ------enig2TAIVRQKTSKMOPLAGSJIL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJRtuVkAAoJEID2ikYfWSP6JYgP/3JLbbLG1CzpQcw24JIpniN7 P45NN7zAdsMz0hfsj/iJejzXkYa2iyB7yYbFky9jySBxjM4Lmx9b69qxGdpoyAva cdsWg4xFbb4n59vN6Q4aKcAPonKCGzRx75fVCe0c5IZWPwqd45wYwPpGx3U8+Ie2 TS4ggTEjQQmEcU/wnYAfxVrJMNYAR4gu0JehC3o7KBLJUwoUnskifMpJM6SGU2GL X3vPdkGLXTd8Uq0KFr/bheYji/BiaMPrMsEJaQ1Qy+uzkwqlywLI/zajjG+KPMVf MQomQ9WIZPYH71Z9Wn/h8/3+igISxxLooeTgUs3spyz79NSRQdxgNFP9vp3P4IOP e8SbLOt4HHrD6Cc8U/1V+NYPZEszkGOvXv4zAsizfkgsGhBBzHz6kvaRerO88lrv 9z3yOxQUzdiDeM2Qk2b+j35IeXxqx77fFhrzZgSmTQnnL7r166fcxKXm8TE/ZTld fZS96H+oXpn0IgPd+VUygMRakRiV2NteAFp5U3NldWunUUe1HouokJD2xB5cKafk 5/ggahOa+oYGaUf0+v1AlrKhBHxT6zY8GvNyKab0OqhkaaqmvSKcCVB6e79765Sd Dx+GDiYHKjILgfs1x2DCH4slnn2uQ0seeAcR0gRNwjvyMOMEWCfdyRi1lJL80WSf iWX588zQgWt4tKheHbb8 =01xV -----END PGP SIGNATURE----- ------enig2TAIVRQKTSKMOPLAGSJIL-- From ondrej.sury@nic.cz Tue Jun 11 02:09: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 D352221F91A5 for ; Tue, 11 Jun 2013 02:09:28 -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 3rl1XeDtKLYc for ; Tue, 11 Jun 2013 02:09:28 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id BB90121F919D for ; Tue, 11 Jun 2013 02:09:27 -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 A04AB13F6A6; Tue, 11 Jun 2013 11:09:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1370941766; bh=1pOIMmxlVjw2eAWemj3Hb5DhSuzoiGjEVvVFKiDrdmg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=XmW1REYfDr2iPyMh3//A3z9mamvaDakoDvfs777qhgiibONvLNjyPAfhJuiOtqiyN VKGd4B2szcrZsNLMDoZr9B5rXbf9Z9Aq0ijGfIICqgSkRYaclzH51o6y2mYj6DWCuM yLWJTvUJRRGUsatXuLsaP4K+pld66DQBlR/Av4lI= Content-Type: multipart/signed; boundary="Apple-Mail=_5D22BD85-E064-4EF4-930D-7C164258AB9B"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <5815F378-9A44-4105-BC98-68FE21A8B73F@kumari.net> Date: Tue, 11 Jun 2013 11:09:24 +0200 Message-Id: <6895963C-8DD4-4D3B-92A7-87E7BB2B8E82@nic.cz> References: <0B5C8480-BF7C-4404-AC90-7A231DE51D1C@kumari.net> <5815F378-9A44-4105-BC98-68FE21A8B73F@kumari.net> To: Warren Kumari X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: "dane@ietf.org list" 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: Tue, 11 Jun 2013 09:09:29 -0000 --Apple-Mail=_5D22BD85-E064-4EF4-930D-7C164258AB9B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear WG members, we haven't heard from you and we still don't have any agenda items. I would like to check, if there's any interest to meet in Berlin at all? = And if the answer is yes then we will still need agenda items in that = case =E2=80=93 meeting without agenda could be very calm and serene, but = also a waste of time and time slot. O. On 31. 5. 2013, at 19:35, Warren Kumari wrote: >=20 > On May 25, 2013, at 1:09 PM, Warren Kumari wrote: >=20 >> 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. >=20 > 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. >=20 > 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. >=20 > 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? >=20 > W >=20 >> 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 >=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 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- 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=_5D22BD85-E064-4EF4-930D-7C164258AB9B 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 NjExMDkwOTI2WjAjBgkqhkiG9w0BCQQxFgQUTS5X5Wsy7UhMlhhD3xuv1NN/y04wgcUGCSsGAQQB gjcQBDGBtzCBtDCBrTELMAkGA1UEBhMCTkwxIDAeBgNVBAoTF1RydXN0ZWQgSW50cm9kdWNlciAo VEkpMSAwHgYDVQQLExdDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTExMC8GA1UEAxMoVHJ1c3RlZCBJ bnRyb2R1Y2VyIChUSSkgQ2xpZW50IENBIC0gRzAwMTEnMCUGCSqGSIb3DQEJARYYY2FAdHJ1c3Rl ZC1pbnRyb2R1Y2VyLm5sAgIGSDCBxwYLKoZIhvcNAQkQAgsxgbeggbQwga0xCzAJBgNVBAYTAk5M MSAwHgYDVQQKExdUcnVzdGVkIEludHJvZHVjZXIgKFRJKTEgMB4GA1UECxMXQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxMTAvBgNVBAMTKFRydXN0ZWQgSW50cm9kdWNlciAoVEkpIENsaWVudCBDQSAt IEcwMDExJzAlBgkqhkiG9w0BCQEWGGNhQHRydXN0ZWQtaW50cm9kdWNlci5ubAICBkgwDQYJKoZI hvcNAQEBBQAEggEAabjhuv7P9LX15hlEe/jXmR5cXb+byyRLf8B6SYT+8Ff8zjeB/EZ4wPfq8AxW IiibojMiTDa7SBNFj1jPfJ/7sLgFmf2Rd9i8oQwDDZuT/KLUNsP/nZCRINz16V1BzZKfl5I/UoEk XF6ri5DpeeXvSnxLvTZ9K2IZ0KaXzPad9r2eJd5J3ssbzq9BFHKlaVKl/sq6HbXDXdxvWbGwb97w ky+2Mzud3Zg5Gins/nF8UONBztSJ8GclLvJ85L/5KbD6FvKFql/m934s0X3fodeo0Y29ZvyvWAfp sK/vlb0lg50CuKQgEC28RCgtKOVWYfR5KZmLtIcUOMFBGUYrAzV2yAAAAAAAAA== --Apple-Mail=_5D22BD85-E064-4EF4-930D-7C164258AB9B-- From viktor1dane@dukhovni.org Tue Jun 11 07:30: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 39E5F21F8E8C for ; Tue, 11 Jun 2013 07:30:13 -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_32=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 QPrAjXfed2e0 for ; Tue, 11 Jun 2013 07:30:08 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 1651F21F97E6 for ; Tue, 11 Jun 2013 07:30:08 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id DDDF82AAA00; Tue, 11 Jun 2013 14:30:06 +0000 (UTC) Date: Tue, 11 Jun 2013 14:30:06 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130611143006.GR9380@mournblade.imrryr.org> References: <0B5C8480-BF7C-4404-AC90-7A231DE51D1C@kumari.net> <5815F378-9A44-4105-BC98-68FE21A8B73F@kumari.net> <6895963C-8DD4-4D3B-92A7-87E7BB2B8E82@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6895963C-8DD4-4D3B-92A7-87E7BB2B8E82@nic.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Call for Agenda items 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, 11 Jun 2013 14:30:13 -0000 On Tue, Jun 11, 2013 at 11:09:24AM +0200, Ond?ej Sur? wrote: > Dear WG members, > > we haven't heard from you and we still don't have any agenda items. > > I would like to check, if there's any interest to meet in Berlin > at all? And if the answer is yes then we will still need agenda > items in that case ? meeting without agenda could be very calm and > serene, but also a waste of time and time slot. I have two new drafts, operational guidance and the opportunistic SMTP and a partner-in-crime to present them. There will be at least one (Postfix) and in the new future two (work will be in progress on Exim) implementations of DANE for SMTP aligned with those drafts. * Certificate usage suppress PKIX, map 0 -> 2, 1 -> 3. * With usage 3, the certificate is not inspected beyond matching against a TLSA RR. No name checks, no expiration checks, ... With "IN TLSA 3 1 1" we have a compact binding to just the public key. * "IN TLSA 0 x [12]" -> treated unusable * "IN TLSA 2 x [12]" -> assumed usable (configurable to unusable), server operators expected to universally include the TA cert in TLS handshake chain. * Postfix will chase MX host CNAME RRs to obtain TLSA base domain. Don't know what Exim will do. * Postfix will ignore everything in a trust anchor certificate, except the public key. PKIX rules apply only to the chain below the trust-anchor (a trust anchor is just a public key). Thus, in particular, "IN TLSA 2 1 0" is supported, even without a matching certificate in the chain. One important question is whether to combine Tony's draft with mine. Or whether the group would prefer a more conservative SMTP draft that applies DANE to SMTP "by the book" (and does not reflect fielded implementations. I would prefer to see a combined draft more along the lines of mine that applies DANE in the context of the practical realities (and actual implementations) of SMTP. It would sure be nice to get some constructive feedback before Berlin. If there is interest, and Wes is willing to run it, there could be an implementation BoF. There is evidence that naive implementations miss key security requirements, so if enough people who want to write implementations there could be a session on that. I will not be able to attend, but may be available via Skype or other remote presence. -- Viktor. From hallam@gmail.com Wed Jun 12 05:31: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 4FF5721F9A24 for ; Wed, 12 Jun 2013 05:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.407 X-Spam-Level: X-Spam-Status: No, score=-2.407 tagged_above=-999 required=5 tests=[AWL=0.192, 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 hPhAYMcXf1GI for ; Wed, 12 Jun 2013 05:31:09 -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 DD09921F99F6 for ; Wed, 12 Jun 2013 05:31:08 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id x54so6067472wes.32 for ; Wed, 12 Jun 2013 05:31:08 -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=dJ67BhfiSL8bp0Rci6dt7ovXg6qdkPv3oZd7Ap4hWFE=; b=ebouL+VAn2m6zlTW5DSFsMJEjS677nPKgn+uhefAz+NTuNg4SSTyksiYAECqIiTYjs ZDr5RtktHDGvDeCqUc4PKs12Jb6cW9PTQYuNI2AUuQrt4dXGm0Q5qZi7zSnXbo5/KgbF XtrXrxQeim2aUNky0t1Y74yJ9tQALIJEJcQvfEidtVedM1MF74dYE+cFJYzBHJcbVmQJ nxDLOB79FGpDHN5TtdXDfMkNFFkZfnkwjx+CI8vAgrKG+UlFrZXdFkjHq/Ms3Wl40HNf J+oK+yPP1rdn/lZu9wNPNnb8IaxSxqoa1lGwOUgmos7MNy17f/v8nQafcY9M8VVA5x6j KOrA== MIME-Version: 1.0 X-Received: by 10.180.13.5 with SMTP id d5mr4288886wic.56.1371040267592; Wed, 12 Jun 2013 05:31:07 -0700 (PDT) Received: by 10.194.44.100 with HTTP; Wed, 12 Jun 2013 05:31:07 -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: Wed, 12 Jun 2013 08:31:07 -0400 Message-ID: From: Phillip Hallam-Baker To: Ben Laurie Content-Type: multipart/alternative; boundary=001a11c23fba1f782d04def43088 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: Wed, 12 Jun 2013 12:31:10 -0000 --001a11c23fba1f782d04def43088 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 10, 2013 at 10:50 AM, Ben Laurie wrote: > On 7 June 2013 17:30, Phillip Hallam-Baker wrote: > > On Mon, Jun 3, 2013 at 5:21 AM, Ben Laurie wrote: > >> > >> > >> Omnibroker introduces a trusted third party. It may be better than the > >> status quo, but I think we've got adequate proof that we can't > >> actually trust TTPs. > > > > > > Like the 9 companies allegedly involved in PRISM? > > > The real point is not that I get to choose whether to trust Google but > not > > whether to trust Comodo or ICANN. And that is the difference between a > CA an > > Omnibroker as TTPs. They are both TTPs but one is an agent of and chosen > by > > the server operator and the other is chosen by the client operator. > > My point is that CT introduces _untrusted_ third parties, and I think > that's the way forward. Replacing the UTP with a TTP you trust to > verify the UTP seems like a step backwards, regardless of my freedom > to choose who I misplace my trust in. What CT does is to provide a mechanism that (1) allows any party to audit certain aspects of the operations of a TTP from public data and (2) allows the audit to be performed as part of the certificate validation checking. If your view of the Web is limited to the Web Browser on a capable machine then there is an argument to be made for moving all checking etc into the browser. But I have network enabled light bulbs in the house. I do not want to be configuring trust in every lightbulb. Regardless, Omnibroker supports two models the same as SCVP does: 1) Validation: Client delegates trust to the broker completely, broker makes decision 2) Discovery: Client delegates a veto to the broker which can refuse a connection to a site known to be dangerous and revalidates all the trust data returned by the broker before relying on it. One advantage of Discovery only model is that the broker can collect all the data required to make the choice for the browser ahead of the decision and cache it. So in the case of DANE data, browser checking adds latency so a browser is unlikely to do checking for DANE records unless at least 10% of sites have them. But a broker can do most of its checks offline so they don't add latency. In the case of DANE there is a second point to the discovery mode and that is to provide a bypass round local DNS resolvers that block TLSA / DNSSEC records. A second advantage is that it enables discretion. Any security check that you implement in the browser has to be reduced to a set of codified, completely standard rules. The spam filtering companies don't take that approach, they have a more tactical scheme making use of heuristic data and actively change their strategy in response to changes in opposition tactics. > > Ah but now you are going to say that I can compile Chrome from source. > Which > > just leaves me with the task of checking a billion lines of source for a > > backdoor. Omnibroker is designed to provide the same option. > > > > If you install your own Omnibroker service you can do all the checking > > yourself for every client that supports the protocol. You can do DANE > checks > > and CT and Convergence and anything else that you might invent in the > > future. You can do all those checks all by yourself or you can ask a > > Symantec or a Comodo or a Kaspersky for information on possible bad IP > > addresses, botnets etc. > > Hmm. I think you need to incorporate some way for an evil Omnibroker > to be both detectable and possible to bring to justice (i.e. something > like CT consistency proofs). > The broker can be required to hand over all the data used to make its decision. -- Website: http://hallambaker.com/ --001a11c23fba1f782d04def43088 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Jun 10, 2013 at 10:50 AM, Ben Laurie <= benl@google.com>= ; wrote:
On 7 June 2013 17:30, Phil= lip Hallam-Baker <hallam@gmail.com> wrote:
> On Mon, Jun 3, 2013 at 5:21 AM, Ben Laurie <benl@google.com> wrote:
>>
>>
>> Omnibroker introduces a trusted third party. It may be better than= the
>> status quo, but I think we've got adequate proof that we can&#= 39;t
>> actually trust TTPs.
>
>
> Like the 9 companies allegedly involved in PRISM?

> The real point is not that I get to choose whether to trust Google but= not
> whether to trust Comodo or ICANN. And that is the difference between a= CA an
> Omnibroker as TTPs. They are both TTPs but one is an agent of and chos= en by
> the server operator and the other is chosen by the client operator.
My point is that CT introduces _untrusted_ third parties, and I think=
that's the way forward. Replacing the UTP with a TTP you trust to
verify the UTP seems like a step backwards, regardless of my freedom
to choose who I misplace my trust in.

What CT does is to provide a mechanism that (1) allows any party to audit = certain aspects of the operations of a TTP from public data and (2) allows = the audit to be performed as part of the certificate validation checking.

If your view of the Web is limited to the Web Bro= wser on a capable machine then there is an argument to be made for moving a= ll checking etc into the browser. But I have network enabled light bulbs in= the house. I do not want to be configuring trust in every lightbulb.

Regardless, Omnibroker supports two models = the same as SCVP does:

1) Validation: = Client delegates trust to the broker completely, broker makes decision

2) Discovery: Client delegates a veto to th= e broker which can refuse a connection to a site known to be dangerous and = revalidates all the trust data returned by the broker before relying on it.=


One advantage of Disco= very only model is that the broker can collect all the data required to mak= e the choice for the browser ahead of the decision and cache it. So in the = case of DANE data, browser checking adds latency so a browser is unlikely t= o do checking for DANE records unless at least 10% of sites have them. But = a broker can do most of its checks offline so they don't add latency.

In the case of DANE there is a second point= to the discovery mode and that is to provide a bypass round local DNS reso= lvers that block TLSA / DNSSEC records.


A second advantage is that it enables discretion. Any = security check that you implement in the browser has to be reduced to a set= of codified, completely standard rules. The spam filtering companies don&#= 39;t take that approach, they have a more tactical scheme making use of heu= ristic data and actively change their strategy in response to changes in op= position tactics.


=A0
=
> Ah but now you are going to say that I can compile Chrome from source.= Which
> just leaves me with the task of checking a billion lines of source for= a
> backdoor. Omnibroker is designed to provide the same option.
>
> If you install your own Omnibroker service you can do all the checking=
> yourself for every client that supports the protocol. You can do DANE = checks
> and CT and Convergence and anything else that you might invent in the<= br> > future. You can do all those checks all by yourself or you can ask a > Symantec or a Comodo or a Kaspersky for information on possible bad IP=
> addresses, botnets etc.

Hmm. I think you need to incorporate some way for an evil Omnibroker<= br> to be both detectable and possible to bring to justice (i.e. something
like CT consistency proofs).

The = broker can be required to hand over all the data used to make its decision.= =A0
=A0


--
Websit= e: http://hallambaker.com/
--001a11c23fba1f782d04def43088-- From benl@google.com Wed Jun 12 06:08:50 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 C67CE21F9C38 for ; Wed, 12 Jun 2013 06:08:50 -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 iY2+hwrm8C72 for ; Wed, 12 Jun 2013 06:08:50 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id EFF2C21F9B25 for ; Wed, 12 Jun 2013 06:08:44 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id aq17so5482105iec.36 for ; Wed, 12 Jun 2013 06:08: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=TXz/HWSpDmDksqpmFJ+c5GqWYC8Vi4FkvL1JW+gs7wk=; b=K5fxOxbTd1RH/Or+V9gKyljvxpW095F378JtQ0KVqI7X+O7VMM9oxZyt+qo+ew9sNc 3VdPexVlfB82i0TMMrbBPlf9+06FbtcTmMSdtB+TjSPRnbpU3XkOMUcpcfouizE6v+aV 7evy6UJRiqUB7YcIpqiLJ2kl5HX74aHXOYZyewGrWHERh0YzLQZCqbPspSsVPl6gD5VK AdbfrNlCTS3WGcGWc7kI5NupyFp+Ww9kL+IeFKWsT9ryWPtiatZqZ8VLMd3wQ5UWM72O JoWvBdQfyRoH6GEumYgo2pS+8jP+y2k0TkWUgtzYNk8V0WbQ8iduCreacLMuWKItluh1 pf2A== 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=TXz/HWSpDmDksqpmFJ+c5GqWYC8Vi4FkvL1JW+gs7wk=; b=JPUMns8Dt241nzMGYCC9tIlOAwHGzoM8JEZGawXoyEVh12HvCzJPsu/Fv7REi6nwF7 arnPFkJGrKn/M2FyXzYYtLdNx2Ae45PsrM9YpZCZF/VJSsL00kQs8JWVJD4a6DsZvvKi Ozl3Ux4qxGg1FrVn9apcKMFDZU1vMFydpp2JIkdpRDLbkyyUT/RabIzHNZmBsYVe4P4B EzB78qT1m9u1iFhxiNZmXqiVLY0AbYfs/VAISA1LF+1QIG9S5yHuSdZeSO20brrT0csI w0lgN5P2I4K4htDtejJM73N0trvERNYp17JR+y8ttoq4Zd9FXGJIzaIx6lxkpno5zm7u STyA== MIME-Version: 1.0 X-Received: by 10.50.136.201 with SMTP id qc9mr3313595igb.47.1371042523415; Wed, 12 Jun 2013 06:08:43 -0700 (PDT) Received: by 10.64.42.72 with HTTP; Wed, 12 Jun 2013 06:08:43 -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: Wed, 12 Jun 2013 14:08:43 +0100 Message-ID: From: Ben Laurie To: Phillip Hallam-Baker Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnafPX8VHeHB8hkeOwip1V4FwckQ6aNpjopZyIRtEh4yZecc2P60uHTgCqeqvTQ4jduXHALjaLu8LZblm0gjubI7t8IppxIgDh9VWU4bf+gEpf3f1D1OFUg8z82J/HoYxKCVoKu1XZMfQi5loK+FJPEAjssysdr/SIxk1055m0GL3T/ViJ7RSAWngYuSKx5BeKWPkuv 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: Wed, 12 Jun 2013 13:08:50 -0000 On 12 June 2013 13:31, Phillip Hallam-Baker wrote: > > > > On Mon, Jun 10, 2013 at 10:50 AM, Ben Laurie wrote: >> >> On 7 June 2013 17:30, Phillip Hallam-Baker wrote: >> > On Mon, Jun 3, 2013 at 5:21 AM, Ben Laurie wrote: >> >> >> >> >> >> Omnibroker introduces a trusted third party. It may be better than the >> >> status quo, but I think we've got adequate proof that we can't >> >> actually trust TTPs. >> > >> > >> > Like the 9 companies allegedly involved in PRISM? >> >> > The real point is not that I get to choose whether to trust Google but >> > not >> > whether to trust Comodo or ICANN. And that is the difference between a >> > CA an >> > Omnibroker as TTPs. They are both TTPs but one is an agent of and chosen >> > by >> > the server operator and the other is chosen by the client operator. >> >> My point is that CT introduces _untrusted_ third parties, and I think >> that's the way forward. Replacing the UTP with a TTP you trust to >> verify the UTP seems like a step backwards, regardless of my freedom >> to choose who I misplace my trust in. > > > What CT does is to provide a mechanism that (1) allows any party to audit > certain aspects of the operations of a TTP from public data and (2) allows > the audit to be performed as part of the certificate validation checking. > > If your view of the Web is limited to the Web Browser on a capable machine > then there is an argument to be made for moving all checking etc into the > browser. But I have network enabled light bulbs in the house. I do not want > to be configuring trust in every lightbulb. > > Regardless, Omnibroker supports two models the same as SCVP does: > > 1) Validation: Client delegates trust to the broker completely, broker makes > decision > > 2) Discovery: Client delegates a veto to the broker which can refuse a > connection to a site known to be dangerous and revalidates all the trust > data returned by the broker before relying on it. > > > One advantage of Discovery only model is that the broker can collect all the > data required to make the choice for the browser ahead of the decision and > cache it. So in the case of DANE data, browser checking adds latency so a > browser is unlikely to do checking for DANE records unless at least 10% of > sites have them. But a broker can do most of its checks offline so they > don't add latency. > > In the case of DANE there is a second point to the discovery mode and that > is to provide a bypass round local DNS resolvers that block TLSA / DNSSEC > records. > > > A second advantage is that it enables discretion. Any security check that > you implement in the browser has to be reduced to a set of codified, > completely standard rules. The spam filtering companies don't take that > approach, they have a more tactical scheme making use of heuristic data and > actively change their strategy in response to changes in opposition tactics. Fair points. I note, though, that you still end up configuring every light bulb... >> > Ah but now you are going to say that I can compile Chrome from source. >> > Which >> > just leaves me with the task of checking a billion lines of source for a >> > backdoor. Omnibroker is designed to provide the same option. >> > >> > If you install your own Omnibroker service you can do all the checking >> > yourself for every client that supports the protocol. You can do DANE >> > checks >> > and CT and Convergence and anything else that you might invent in the >> > future. You can do all those checks all by yourself or you can ask a >> > Symantec or a Comodo or a Kaspersky for information on possible bad IP >> > addresses, botnets etc. >> >> Hmm. I think you need to incorporate some way for an evil Omnibroker >> to be both detectable and possible to bring to justice (i.e. something >> like CT consistency proofs). > > > The broker can be required to hand over all the data used to make its > decision. Not much use if the client can't check it? The advantage of a CT (or RT)-like scheme is that anyone can check it, and all the client needs to be able to do is check consistency... From bry8star@inventati.org Thu Jun 13 06:21: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 AB2BD21F9A39 for ; Thu, 13 Jun 2013 06:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, MANGLED_FORM=2.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 OxjE-YxfKfaq for ; Thu, 13 Jun 2013 06:21:36 -0700 (PDT) Received: from diserzione.investici.org (diserzione.investici.org [IPv6:2002:52dd:6399::1]) by ietfa.amsl.com (Postfix) with ESMTP id E699821F9A2C for ; Thu, 13 Jun 2013 06:21:34 -0700 (PDT) Received: from [82.221.99.153] (diserzione [82.221.99.153]) (Authenticated sender: bry8star@inventati.org) by localhost (Postfix) with ESMTPSA id 8BA70180C51 for ; Thu, 13 Jun 2013 13:21:18 +0000 (UTC) X-DKIM: Sendmail DKIM Filter v2.8.2 diserzione.investici.org 8BA70180C51 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inventati.org; s=stigmate; t=1371129681; bh=zHo2f3buOLK20NU43Xt5g6MicwGCnOGuXtMBxMXd1yg=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject: Content-Type; b=TR7wDtDlpajhnBjCe9HJdl5boiqN0dCFUD8fFIB6lYsfUOJqpHiHyUP9E4at4U5sn QbNiBlpi+T1r3rOiohZs1hNLkVn0nq1IEYrXLdDZe+QRh9FucZ/hjSvbJclds/i3gZ 4JQuHj4jW6H/cGxdZ5nXe25sIu61nN0zB3q8BWRA= Message-ID: <51B9C72E.2040706@inventati.org> Date: Thu, 13 Jun 2013 06:20:46 -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: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2BDUTWVUHIOJHNGSMKQXU" Subject: [dane] Combined TLSA TA (2 S M) and TLSA EE (1 S M) Usage 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: Thu, 13 Jun 2013 13:21:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2BDUTWVUHIOJHNGSMKQXU Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Please explain/comment more on these: Conventions, used in this email msg: * The Beginning "%" symbol (and a space after it), is not used in any real zone file. ( I have used this symbol used here for this email post only, just to indicate a begin of a configuration line, as, multiple time email reply can/may change position or remove Line-Feed(LF/EOL) indicator ). * Command-line will start with "$" symbol (and a space after it). Do not use shown '$' when using in real command. * When a command-line ("$ ") will show "\" symbol at-end, then bring below one line after it, and remove the \ symbol. Here "\" symbol is indicating "Next-Line is part of This Line". I'm using such TLS / SSL Chain: SSL / TLS Certificate Pyramid & Levels : 01 =3D Level-01 =3D is TA/Root-CA cert. (My_Root_CA.crt). Self-signed new my own CA/TA cert. 02 =3D Level-02 =3D is an Intermediate CA cert. (My_i-CA.crt). under L-1.= 03 =3D Level-03 =3D is an Intermediate Authority cert for dom1.tld. (dom1_tld_IA.crt). It can only be used to create certs, only under dom1.tld. 04 =3D Level-04 =3D is Server/EE-Certs : { s1.dom1.tld.crt, s2.dom1.tld.crt, im.dom1.tld.crt, im2.dom1.tld.crt, www.dom1.tld.crt, m.dom1.tld.crt } TA =3D Trust Anchor . CA =3D Certificate Authority. IA =3D Intermediate Authority. cert =3D certificate. cert keypair. Both public key portion and private key portion. crt =3D cert's public (key) portion. can be shared. key / prv.pem =3D private key portion of cert. do not share. As a domain-owner, and an operator, etc ... i will be using my own new self-signed TA (Trust Anchor) cert/bundle (aka, self-signed CA), so i will need to do these, i understand this part: % _443._tcp.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA % _443._tcp.s1.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA % _443._tcp.s2.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA % _443._tcp.www.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA % _443._tcp.m.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA % _25._tcp.s1.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA % _993._tcp.s1.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA % _995._tcp.s1.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA % _587._tcp.s1.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA % _25._tcp.s2.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA % _993._tcp.s2.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA % _995._tcp.s2.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA % _587._tcp.s2.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA But when only TLSA TA "2 S M" is used, it is indicating, clients and servers need to use multiple channels (port 80, port 443, port 53) for related various purpose. :( C_A_D =3D Certificate Association Data. Either a Raw/Binary Data, DER-encoded full cert, when s=3D0 & m=3D0. Or, it can be a hash-code (Base64-encoded) of raw-data, when s=3D1, and m=3D1 or m=3D2. In Hex. Here, to create "C_A_D_of_TA" code-portion : i will 1st create a DER file (C_A_D_of_TA.der), based on Level-3 dom1_tld_IA.crt file, and then in 2nd step i will append DER code based on Level-2 My_i-CA.crt file, and then in 3rd step i will append DER code based on Level-1 My_Root_CA.crt file. (Similar to what we do for creating TLS chain cert for httpd server software) : $ openssl x509 -in dom1_tld_IA.crt \ -outform der -out C_A_D_of_TA.der $ openssl x509 -in My_i-CA.crt \ -outform der -out My_i-CA.der $ cat My_i-CA.der >> C_A_D_of_TA.der $ openssl x509 -in My_Root_CA.crt \ -outform der -out My_Root_CA.der $ cat My_Root_CA.der >> C_A_D_of_TA.der I (as Domain-owner) want my side NS/DNS-servers to serve FULL DER TLS certs. Both TA/Root-CA and EE/Server-Cert. Let us assume, i have such dns entries : Here 's1' is server hostname. So is 's2'. Visitors & users will access 's1' srvr via 'www' srvc, and access 's2' srvr via 'm' service (service sub-domain-name) normally. When/if 's1' srvr is down, then user will goto 's2' srvr for 'www' srvc, and when 's2' srvr is down then user will goto 's1' srvr for 'm' srvc: % dom1.tld. 3600 IN SOA s1.dom1.tld. hostmaster.dom1.tld. 2013052910 18000 3600 864000 3600 % dom1.tld. 3000 IN NS s1.dom1.tld. % dom1.tld. 3000 IN NS s2.dom1.tld. % dom1.tld. 300 IN A IP.ADRS_S-1_IPv4 % dom1.tld. 300 IN A IP.ADRS_S-2_IPv4 % dom1.tld. 300 IN AAAA IP::ADRS_S-1_IPv6 % dom1.tld. 300 IN AAAA IP::ADRS_S-2_IPv6 % s1.dom1.tld. 900 IN A IP.ADRS_S-1_IPv4 % s2.dom1.tld. 900 IN A IP.ADRS_S-2_IPv4 % s1.dom1.tld. 900 IN AAAA IP::ADRS_S-1_IPv6 % s2.dom1.tld. 900 IN AAAA IP::ADRS_S-2_IPv6 % www.dom1.tld. 300 IN CNAME dom1.tld. % m.dom1.tld. 300 IN CNAME dom1.tld. % _http._tcp.dom1.tld. 3600 IN SRV 0 0 80 www.dom1.tld. % _https._tcp.dom1.tld. 3600 IN SRV 0 0 443 www.dom1.tld. % _http._tcp.www.dom1.tld. 3600 IN SRV 0 0 80 www.dom1.tld. % _https._tcp.www.dom1.tld. 3600 IN SRV 0 0 443 www.dom1.tld. % _http._tcp.m.dom1.tld. 3600 IN SRV 0 0 80 m.dom1.tld. % _https._tcp.m.dom1.tld. 3600 IN SRV 0 0 443 m.dom1.tld. % dom1.tld. 3600 IN MX 10 s1.dom1.tld. % dom1.tld. 3600 IN MX 20 s2.dom1.tld. % _smtp._tcp.dom1.tld. 3600 IN SRV 10 0 25 s1.dom1.tld. % _smtp._tcp.dom1.tld. 3600 IN SRV 20 0 25 s2.dom1.tld. % _smtp._tcp.s1.dom1.tld. 3600 IN SRV 10 0 25 s1.dom1.tld. % _smtp._tcp.s1.dom1.tld. 3600 IN SRV 20 0 25 s2.dom1.tld. % _smtp._tcp.s2.dom1.tld. 3600 IN SRV 10 0 25 s2.dom1.tld. % _smtp._tcp.s2.dom1.tld. 3600 IN SRV 20 0 25 s1.dom1.tld. % _submission._tcp.dom1.tld. 3600 IN SRV 10 0 587 s1.dom1.tld. % _submission._tcp.dom1.tld. 3600 IN SRV 20 0 587 s2.dom1.tld. % _submission._tcp.s1.dom1.tld. 3600 IN SRV 10 0 587 s1.dom1.tld. % _submission._tcp.s1.dom1.tld. 3600 IN SRV 20 0 587 s2.dom1.tld. % _submission._tcp.s2.dom1.tld. 3600 IN SRV 10 0 587 s2.dom1.tld. % _submission._tcp.s2.dom1.tld. 3600 IN SRV 20 0 587 s1.dom1.tld. % _imaps._tcp.dom1.tld. 3600 IN SRV 0 0 993 s1.dom1.tld. % _imaps._tcp.dom1.tld. 3600 IN SRV 5 0 993 s2.dom1.tld. % _imaps._tcp.s1.dom1.tld. 3600 IN SRV 0 0 993 s1.dom1.tld. % _imaps._tcp.s1.dom1.tld. 3600 IN SRV 5 0 993 s2.dom1.tld. % _imaps._tcp.s2.dom1.tld. 3600 IN SRV 0 0 993 s2.dom1.tld. % _imaps._tcp.s2.dom1.tld. 3600 IN SRV 5 0 993 s1.dom1.tld. % _pop3s._tcp.dom1.tld. 3600 IN SRV 0 0 995 s1.dom1.tld. % _pop3s._tcp.dom1.tld. 3600 IN SRV 5 0 995 s2.dom1.tld. % _pop3s._tcp.s1.dom1.tld. 3600 IN SRV 0 0 995 s1.dom1.tld. % _pop3s._tcp.s1.dom1.tld. 3600 IN SRV 5 0 995 s2.dom1.tld. % _pop3s._tcp.s2.dom1.tld. 3600 IN SRV 0 0 995 s2.dom1.tld. % _pop3s._tcp.s2.dom1.tld. 3600 IN SRV 5 0 995 s1.dom1.tld. I want, FUTURE FULL DANE & DNSSEC supported web-browsers/HTTPS-clients (and httpd (HTTP, HTTPS) servers) to pull/retrieve BOTH TA & EE type of certs from DNS, like : 1st pull/retrieve FULL authentic EE/server-cert from TLSA dns ("1 S M" & "3 S M" cases), and (in 2nd step), also pull/retrieve new self-signed TA ("TLSA 2 S M"), or public CA ("TLSA 0 S M") from DNS record (if it exist there and if required for TLS chain validation), and after verifying TLSA EE cert and TLSA cert chain and authenticity, then use EE/Server-Cert for creating authentic & encrypted secured HTTPS connection. I basically want both HTTPS-client and HTTPS-server, to retrieve, domain-owner declared/published, both TA and EE full certificate from DNS, and then after cert chain validation succeeds, use the EE cert to create encrypted connection. Without depending on any .crt files specified or loaded in/from server or client software. Server-side software will only need cert's private_key file portion for creating encrypted traffic. So based on above expectation, i also want to add these: % _443._tcp.www.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_www_Srvr-Cert % _443._tcp.m.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_m_Srvr-Cert Or, am i suppose to add these ? % _443._tcp.www.dom1.tld. 180 IN TLSA 3 0 0 C_A_D_of_www_Srvr-Cert % _443._tcp.m.dom1.tld. 180 IN TLSA 3 0 0 C_A_D_of_m_Srvr-Cert I will create C_A_D_of_www_Srvr-Cert.der like this: $ openssl x509 -in www_dom1_tld.crt \ -outform der \ -out C_A_D_of_www_Srvr-Cert.der And for other certs: $ openssl x509 -in m_dom1_tld.crt \ -outform der \ -out C_A_D_of_m_Srvr-Cert.der $ openssl x509 -in s1_dom1_tld.crt \ -outform der \ -out C_A_D_of_s1_Srvr-Cert.der $ openssl x509 -in s2_dom1_tld.crt \ -outform der \ -out C_A_D_of_s2_Srvr-Cert.der So for my case, i will be adding both "TLSA 1 0 0" and "TLSA 2 0 0", full certificates. To me, adding both TLSA "2 0 0" and "1 0 0" with full certs, makes more sense, specially when domain-owner will be using their own new self-signed/TA cert based solution. Then client and server both can retrieve the TA and EE type cert using only one channel, DNS-channel, port 53. I want to call it or treat it, as, a Complete TLSA declaration, as it eliminates any chance of confusion, and reduces TLS obtain & validation related steps, as it can easily obtain all necessary full TLS certs from DNS records, authenticated by DNSSEC. I'm trying to say via DNS ... here (TLSA 1 0 0) is my server's self-signed full EE/server-cert, and here (TLSA 2 0 0) is my own & new self-signed full Root-CA/TA cert bundle, ... ( so, you(client) must use these (TA & EE certs) to validate the cert chain. and then on success, use the EE cert for creating HTTPS secured connection). I want to support various & mixed channel based solutions, so i will also do these : I will add both TLSA TA "2 0 0" and TLSA EE "1 0 0" as mentioned in above. So that, clients & servers both side can still obtain both TA & EE type of TLSA records via DNS channel (port 53). And i will also serve/share full TLS cert chain/bundle-file from HTTPS-server (apache/httpd) service software. So that, clients & servers both side can still obtain (1) server/EE-cert and rest of the TLS cert chain's linked certs (if server/EE-cert requires), via HTTPS channel (port 443) and/or using OCSP channel (port 80) for TLS cert's PKIX validity). I want, client & server software able to obtain & use entire EE cert (from TLSA "1 S M" or TLSA "3 S M"), and i want them able to obtain & use entire TA cert chain (from TLSA "2 S M" or TLSA "0 S M"). So for my case i will and want-to, use TLSA like this: % _443._tcp.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA % _443._tcp.s1.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA % _443._tcp.s1.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_s1_dom1_tld % _443._tcp.s2.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA % _443._tcp.s2.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_s2_dom1_tld % _443._tcp.www.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA % _443._tcp.www.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_www_dom1_tld % _443._tcp.m.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA % _443._tcp.m.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_m_dom1_tld % _25._tcp.s1.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA % _25._tcp.s1.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_s1_dom1_tld % _993._tcp.s1.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA % _993._tcp.s1.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_s1_dom1_tld % _995._tcp.s1.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA % _995._tcp.s1.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_s1_dom1_tld % _587._tcp.s1.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA % _587._tcp.s1.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_s1_dom1_tld % _25._tcp.s2.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA % _25._tcp.s2.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_s2_dom1_tld % _993._tcp.s2.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA % _993._tcp.s2.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_s2_dom1_tld % _995._tcp.s2.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA % _995._tcp.s2.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_s2_dom1_tld % _587._tcp.s2.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA % _587._tcp.s2.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_s2_dom1_tld Does DANE currently allow TWO combined TLSA record usage ? i want to use both TLSA TA ("TLSA 2 0 0") and TLSA EE ("TLSA 1 0 0") dns-record, for verifying EE cert created under a self-signed new TA cert, and force both client & server side to validate both type of certs, and after validation succeeds, the EE cert will be used for HTTPS encryption, by both client & server. If such/above is not supported, then please add support for it. Since i will not use partial cert portion or hash, in TLSA EE "1 S M" or "3 S M" cases, so you may avoid referencing on that, and please focus on full EE cert based practice/guidance/example. But if (non-Full) partial cert is appropriate or adequate for TLSA TA "2 S M" or "0 S M" cases without invoking/using extra channel usage, then pls do mention on that. Please point out my errors, and help us/me/domain-owners with better/improved configuration, thanks in advance. -- Bright Star. Jun 13, 2013. ------enig2BDUTWVUHIOJHNGSMKQXU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJRucc/AAoJEID2ikYfWSP6CUUP/RFeCB3DWXgOJCnQeK8sw+SB wI3T+wzky7LJTPA2lTisDR3jlpr/aQVNjtFhTDhtn5xCIuUrkhnGtaWymJFI41bJ SdbYiY51zBclP2t0r+o179IQG8UjktdCVULMMoqTbTxsU/fsDdrlJw68Fr8ZswBt 4G/oIXtFFk0V0N7/zlyXoLFODpTOQjpLTinjZ0rjwSQsGSwAb0Cmbw+88AnMYovP H5tMj+j7jwoVPwIubHc0Qn1GFj1wIS/E7HHd6BWWzXhIHp52vzTu1UzQPcmkEgOs uWRHWFG/IIy5Y5hzl9CWC1SOFnOiQiMK21vqx6EfOPtRtM0uTFtI2nKGsFTERCn0 xaHrH57I9NI/7XSOysE2uu16q0COCWba+gVCyvXfYJrUiIEUJhkJQiB7vl+FMJnT JZhgrp1L4vfMbDIYq6//oat2AUHZempjIA9WdNfnEGdb2QbAJMYymPqtewFN0bFK 29BkVEQNHCFxkyufs365sNuJu4kuDERNfWD1QuscL/r0in7mwHsZGq/Mnjte3ALE cserbETLh5ELDW761ca+wMwtojCwhXETBv9WfM8FU56e5208s1tQ/DIGQU0r/7py v4VJW1GmSVPoDXyKHu8Pf+YPEWW8b3tGU1Uz445FOA7YErXTtQCadTpqNhvyZtdo iIcKVXLgmwd0yxPA7CU9 =uhrd -----END PGP SIGNATURE----- ------enig2BDUTWVUHIOJHNGSMKQXU-- From rlb@ipv.sx Thu Jun 13 07:03: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 A7C1E21F9A92 for ; Thu, 13 Jun 2013 07:03:21 -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=[AWL=-1.374, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, MANGLED_FORM=2.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VMhxWUkzpN6u for ; Thu, 13 Jun 2013 07:03:16 -0700 (PDT) Received: from mail-oa0-x22d.google.com (mail-oa0-x22d.google.com [IPv6:2607:f8b0:4003:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 5131821F901F for ; Thu, 13 Jun 2013 07:02:49 -0700 (PDT) Received: by mail-oa0-f45.google.com with SMTP id j1so4146721oag.18 for ; Thu, 13 Jun 2013 07:02:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=KBgRa3XaE06QnKO5vR5uQ9F1uBCNXP+AolCLirJxwuc=; b=SGCtdBzOLBi223ru6Pco/kvtwIxJ1Wo8bDk2uvg1YdHCK2eVfIlttkzeRJ/opNn9aJ L0IyfVj9VJU8zdiaRN1I+60g0c0gCgnFMiLqg1nlbGjSWCbw+txP59ZzjgRuQeZQeqUR 6htC91HPwHMYLJm0EqvaXil7hBX/T8kzz9y7a+IiJ4aq2jHrxA4u9MJcFUdAFO082rac kLdqAQdBK2Wq0k63ny+slEsIxsYSEmZ/TBFbUMFuhJvb7ZkrHU56ZkNzp61y0AaaSdov rXNwo1V4UZ1tJAu50YGi7ESrdES/5PjtNlMXK2pRarpm+oKsCY98Y3kjHDBvq+PBdrXh WMGA== MIME-Version: 1.0 X-Received: by 10.182.129.42 with SMTP id nt10mr796391obb.54.1371132167947; Thu, 13 Jun 2013 07:02:47 -0700 (PDT) Received: by 10.60.84.8 with HTTP; Thu, 13 Jun 2013 07:02:47 -0700 (PDT) X-Originating-IP: [192.1.51.101] In-Reply-To: <51B9C72E.2040706@inventati.org> References: <51B9C72E.2040706@inventati.org> Date: Thu, 13 Jun 2013 10:02:47 -0400 Message-ID: From: Richard Barnes To: bry8star@inventati.org Content-Type: multipart/alternative; boundary=e89a8fb1fbfecfe55b04df0995f4 X-Gm-Message-State: ALoCoQnUHvBfkQ7GFRUszWH6gSBk+1OwLRgDJ3HRfq5g26NyI8n/abLQcAbDn5zbc/HQmYcZiCw1 Cc: "dane@ietf.org" Subject: Re: [dane] Combined TLSA TA (2 S M) and TLSA EE (1 S M) Usage X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 13 Jun 2013 14:03:25 -0000 --e89a8fb1fbfecfe55b04df0995f4 Content-Type: text/plain; charset=ISO-8859-1 """ If an application receives one or more usable certificate associations, it attempts to match each certificate association with the TLS server's end entity certificate until a successful match is found. During the TLS handshake, if none of the certificate associations matches the certificate given by the TLS server, the TLS client MUST abort the handshake. """ Contrapositively, if the TLS client finds one or more associations that match the certificate, then it MAY proceed with the handshake. On Thu, Jun 13, 2013 at 9:20 AM, Bry8 Star wrote: > Please explain/comment more on these: > > Conventions, used in this email msg: > * The Beginning "%" symbol (and a space after it), is not used in > any real zone file. ( I have used this symbol used here for this > email post only, just to indicate a begin of a configuration line, > as, multiple time email reply can/may change position or remove > Line-Feed(LF/EOL) indicator ). > * Command-line will start with "$" symbol (and a space after it). Do > not use shown '$' when using in real command. > * When a command-line ("$ ") will show "\" symbol at-end, then bring > below one line after it, and remove the \ symbol. Here "\" symbol > is indicating "Next-Line is part of This Line". > > I'm using such TLS / SSL Chain: > > SSL / TLS Certificate Pyramid & Levels : > > 01 = Level-01 = is TA/Root-CA cert. (My_Root_CA.crt). Self-signed > new my own CA/TA cert. > 02 = Level-02 = is an Intermediate CA cert. (My_i-CA.crt). under L-1. > 03 = Level-03 = is an Intermediate Authority cert for dom1.tld. > (dom1_tld_IA.crt). It can only be used to create certs, only under > dom1.tld. > 04 = Level-04 = is Server/EE-Certs : { s1.dom1.tld.crt, > s2.dom1.tld.crt, im.dom1.tld.crt, im2.dom1.tld.crt, > www.dom1.tld.crt, m.dom1.tld.crt } > > TA = Trust Anchor . CA = Certificate Authority. > IA = Intermediate Authority. > cert = certificate. cert keypair. Both public key portion and > private key portion. > crt = cert's public (key) portion. can be shared. > key / prv.pem = private key portion of cert. do not share. > > As a domain-owner, and an operator, etc ... i will be using my own > new self-signed TA (Trust Anchor) cert/bundle (aka, self-signed CA), > so i will need to do these, i understand this part: > > % _443._tcp.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA > % _443._tcp.s1.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA > % _443._tcp.s2.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA > % _443._tcp.www.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA > % _443._tcp.m.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA > % _25._tcp.s1.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA > % _993._tcp.s1.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA > % _995._tcp.s1.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA > % _587._tcp.s1.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA > % _25._tcp.s2.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA > % _993._tcp.s2.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA > % _995._tcp.s2.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA > % _587._tcp.s2.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA > > But when only TLSA TA "2 S M" is used, it is indicating, clients and > servers need to use multiple channels (port 80, port 443, port 53) > for related various purpose. :( > > C_A_D = Certificate Association Data. Either a Raw/Binary Data, > DER-encoded full cert, when s=0 & m=0. Or, it can be a hash-code > (Base64-encoded) of raw-data, when s=1, and m=1 or m=2. In Hex. > > Here, to create "C_A_D_of_TA" code-portion : > i will 1st create a DER file (C_A_D_of_TA.der), based on Level-3 > dom1_tld_IA.crt file, and then in 2nd step i will append DER code > based on Level-2 My_i-CA.crt file, and then in 3rd step i will > append DER code based on Level-1 My_Root_CA.crt file. (Similar to > what we do for creating TLS chain cert for httpd server software) : > > $ openssl x509 -in dom1_tld_IA.crt \ > -outform der -out C_A_D_of_TA.der > $ openssl x509 -in My_i-CA.crt \ > -outform der -out My_i-CA.der > $ cat My_i-CA.der >> C_A_D_of_TA.der > $ openssl x509 -in My_Root_CA.crt \ > -outform der -out My_Root_CA.der > $ cat My_Root_CA.der >> C_A_D_of_TA.der > > I (as Domain-owner) want my side NS/DNS-servers to serve FULL DER > TLS certs. Both TA/Root-CA and EE/Server-Cert. > > Let us assume, i have such dns entries : Here 's1' is server > hostname. So is 's2'. Visitors & users will access 's1' srvr via > 'www' srvc, and access 's2' srvr via 'm' service (service > sub-domain-name) normally. When/if 's1' srvr is down, then user > will goto 's2' srvr for 'www' srvc, and when 's2' srvr is down then > user will goto 's1' srvr for 'm' srvc: > > % dom1.tld. 3600 IN SOA s1.dom1.tld. hostmaster.dom1.tld. 2013052910 > 18000 3600 864000 3600 > % dom1.tld. 3000 IN NS s1.dom1.tld. > % dom1.tld. 3000 IN NS s2.dom1.tld. > % dom1.tld. 300 IN A IP.ADRS_S-1_IPv4 > % dom1.tld. 300 IN A IP.ADRS_S-2_IPv4 > % dom1.tld. 300 IN AAAA IP::ADRS_S-1_IPv6 > % dom1.tld. 300 IN AAAA IP::ADRS_S-2_IPv6 > % s1.dom1.tld. 900 IN A IP.ADRS_S-1_IPv4 > % s2.dom1.tld. 900 IN A IP.ADRS_S-2_IPv4 > % s1.dom1.tld. 900 IN AAAA IP::ADRS_S-1_IPv6 > % s2.dom1.tld. 900 IN AAAA IP::ADRS_S-2_IPv6 > % www.dom1.tld. 300 IN CNAME dom1.tld. > % m.dom1.tld. 300 IN CNAME dom1.tld. > % _http._tcp.dom1.tld. 3600 IN SRV 0 0 80 www.dom1.tld. > % _https._tcp.dom1.tld. 3600 IN SRV 0 0 443 www.dom1.tld. > % _http._tcp.www.dom1.tld. 3600 IN SRV 0 0 80 www.dom1.tld. > % _https._tcp.www.dom1.tld. 3600 IN SRV 0 0 443 www.dom1.tld. > % _http._tcp.m.dom1.tld. 3600 IN SRV 0 0 80 m.dom1.tld. > % _https._tcp.m.dom1.tld. 3600 IN SRV 0 0 443 m.dom1.tld. > % dom1.tld. 3600 IN MX 10 s1.dom1.tld. > % dom1.tld. 3600 IN MX 20 s2.dom1.tld. > % _smtp._tcp.dom1.tld. 3600 IN SRV 10 0 25 s1.dom1.tld. > % _smtp._tcp.dom1.tld. 3600 IN SRV 20 0 25 s2.dom1.tld. > % _smtp._tcp.s1.dom1.tld. 3600 IN SRV 10 0 25 s1.dom1.tld. > % _smtp._tcp.s1.dom1.tld. 3600 IN SRV 20 0 25 s2.dom1.tld. > % _smtp._tcp.s2.dom1.tld. 3600 IN SRV 10 0 25 s2.dom1.tld. > % _smtp._tcp.s2.dom1.tld. 3600 IN SRV 20 0 25 s1.dom1.tld. > % _submission._tcp.dom1.tld. 3600 IN SRV 10 0 587 s1.dom1.tld. > % _submission._tcp.dom1.tld. 3600 IN SRV 20 0 587 s2.dom1.tld. > % _submission._tcp.s1.dom1.tld. 3600 IN SRV 10 0 587 s1.dom1.tld. > % _submission._tcp.s1.dom1.tld. 3600 IN SRV 20 0 587 s2.dom1.tld. > % _submission._tcp.s2.dom1.tld. 3600 IN SRV 10 0 587 s2.dom1.tld. > % _submission._tcp.s2.dom1.tld. 3600 IN SRV 20 0 587 s1.dom1.tld. > % _imaps._tcp.dom1.tld. 3600 IN SRV 0 0 993 s1.dom1.tld. > % _imaps._tcp.dom1.tld. 3600 IN SRV 5 0 993 s2.dom1.tld. > % _imaps._tcp.s1.dom1.tld. 3600 IN SRV 0 0 993 s1.dom1.tld. > % _imaps._tcp.s1.dom1.tld. 3600 IN SRV 5 0 993 s2.dom1.tld. > % _imaps._tcp.s2.dom1.tld. 3600 IN SRV 0 0 993 s2.dom1.tld. > % _imaps._tcp.s2.dom1.tld. 3600 IN SRV 5 0 993 s1.dom1.tld. > % _pop3s._tcp.dom1.tld. 3600 IN SRV 0 0 995 s1.dom1.tld. > % _pop3s._tcp.dom1.tld. 3600 IN SRV 5 0 995 s2.dom1.tld. > % _pop3s._tcp.s1.dom1.tld. 3600 IN SRV 0 0 995 s1.dom1.tld. > % _pop3s._tcp.s1.dom1.tld. 3600 IN SRV 5 0 995 s2.dom1.tld. > % _pop3s._tcp.s2.dom1.tld. 3600 IN SRV 0 0 995 s2.dom1.tld. > % _pop3s._tcp.s2.dom1.tld. 3600 IN SRV 5 0 995 s1.dom1.tld. > > I want, FUTURE FULL DANE & DNSSEC supported > web-browsers/HTTPS-clients (and httpd (HTTP, HTTPS) servers) to > pull/retrieve BOTH TA & EE type of certs from DNS, like : 1st > pull/retrieve FULL authentic EE/server-cert from TLSA dns ("1 S M" & > "3 S M" cases), and (in 2nd step), also pull/retrieve new > self-signed TA ("TLSA 2 S M"), or public CA ("TLSA 0 S M") from DNS > record (if it exist there and if required for TLS chain validation), > and after verifying TLSA EE cert and TLSA cert chain and > authenticity, then use EE/Server-Cert for creating authentic & > encrypted secured HTTPS connection. > > I basically want both HTTPS-client and HTTPS-server, to retrieve, > domain-owner declared/published, both TA and EE full certificate > from DNS, and then after cert chain validation succeeds, use the EE > cert to create encrypted connection. Without depending on any .crt > files specified or loaded in/from server or client software. > Server-side software will only need cert's private_key file portion > for creating encrypted traffic. > > So based on above expectation, i also want to add these: > > % _443._tcp.www.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_www_Srvr-Cert > % _443._tcp.m.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_m_Srvr-Cert > > Or, am i suppose to add these ? > > % _443._tcp.www.dom1.tld. 180 IN TLSA 3 0 0 C_A_D_of_www_Srvr-Cert > % _443._tcp.m.dom1.tld. 180 IN TLSA 3 0 0 C_A_D_of_m_Srvr-Cert > > I will create C_A_D_of_www_Srvr-Cert.der like this: > $ openssl x509 -in www_dom1_tld.crt \ > -outform der \ > -out C_A_D_of_www_Srvr-Cert.der > > And for other certs: > $ openssl x509 -in m_dom1_tld.crt \ > -outform der \ > -out C_A_D_of_m_Srvr-Cert.der > $ openssl x509 -in s1_dom1_tld.crt \ > -outform der \ > -out C_A_D_of_s1_Srvr-Cert.der > $ openssl x509 -in s2_dom1_tld.crt \ > -outform der \ > -out C_A_D_of_s2_Srvr-Cert.der > > So for my case, i will be adding both "TLSA 1 0 0" and "TLSA 2 0 0", > full certificates. To me, adding both TLSA "2 0 0" and "1 0 0" with > full certs, makes more sense, specially when domain-owner will be > using their own new self-signed/TA cert based solution. Then client > and server both can retrieve the TA and EE type cert using only one > channel, DNS-channel, port 53. I want to call it or treat it, as, a > Complete TLSA declaration, as it eliminates any chance of confusion, > and reduces TLS obtain & validation related steps, as it can easily > obtain all necessary full TLS certs from DNS records, authenticated > by DNSSEC. > > I'm trying to say via DNS ... here (TLSA 1 0 0) is my server's > self-signed full EE/server-cert, and here (TLSA 2 0 0) is my own & > new self-signed full Root-CA/TA cert bundle, ... ( so, you(client) > must use these (TA & EE certs) to validate the cert chain. and then > on success, use the EE cert for creating HTTPS secured connection). > > I want to support various & mixed channel based solutions, so i will > also do these : I will add both TLSA TA "2 0 0" and TLSA EE "1 0 0" > as mentioned in above. So that, clients & servers both side can > still obtain both TA & EE type of TLSA records via DNS channel (port > 53). And i will also serve/share full TLS cert chain/bundle-file > from HTTPS-server (apache/httpd) service software. So that, clients > & servers both side can still obtain (1) server/EE-cert and rest of > the TLS cert chain's linked certs (if server/EE-cert requires), via > HTTPS channel (port 443) and/or using OCSP channel (port 80) for TLS > cert's PKIX validity). > > I want, client & server software able to obtain & use entire EE cert > (from TLSA "1 S M" or TLSA "3 S M"), and i want them able to obtain > & use entire TA cert chain (from TLSA "2 S M" or TLSA "0 S M"). > > So for my case i will and want-to, use TLSA like this: > > % _443._tcp.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA > % _443._tcp.s1.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA > % _443._tcp.s1.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_s1_dom1_tld > % _443._tcp.s2.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA > % _443._tcp.s2.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_s2_dom1_tld > % _443._tcp.www.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA > % _443._tcp.www.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_www_dom1_tld > % _443._tcp.m.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA > % _443._tcp.m.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_m_dom1_tld > % _25._tcp.s1.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA > % _25._tcp.s1.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_s1_dom1_tld > % _993._tcp.s1.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA > % _993._tcp.s1.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_s1_dom1_tld > % _995._tcp.s1.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA > % _995._tcp.s1.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_s1_dom1_tld > % _587._tcp.s1.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA > % _587._tcp.s1.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_s1_dom1_tld > % _25._tcp.s2.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA > % _25._tcp.s2.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_s2_dom1_tld > % _993._tcp.s2.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA > % _993._tcp.s2.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_s2_dom1_tld > % _995._tcp.s2.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA > % _995._tcp.s2.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_s2_dom1_tld > % _587._tcp.s2.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA > % _587._tcp.s2.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_s2_dom1_tld > > Does DANE currently allow TWO combined TLSA record usage ? i want to > use both TLSA TA ("TLSA 2 0 0") and TLSA EE ("TLSA 1 0 0") > dns-record, for verifying EE cert created under a self-signed new TA > cert, and force both client & server side to validate both type of > certs, and after validation succeeds, the EE cert will be used for > HTTPS encryption, by both client & server. > If such/above is not supported, then please add support for it. > > Since i will not use partial cert portion or hash, in TLSA EE "1 S > M" or "3 S M" cases, so you may avoid referencing on that, and > please focus on full EE cert based practice/guidance/example. But > if (non-Full) partial cert is appropriate or adequate for TLSA TA "2 > S M" or "0 S M" cases without invoking/using extra channel usage, > then pls do mention on that. > > Please point out my errors, and help us/me/domain-owners with > better/improved configuration, thanks in advance. > > -- Bright Star. > Jun 13, 2013. > > > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > > --e89a8fb1fbfecfe55b04df0995f4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
= """
   If an application
   receives one or more usable certificate associations, it attempts to
   match each certificate association with the TLS server's end entity
   certificate until a successful match is found.  During the TLS
   handshake, if none of the certificate associations matches the
   certificate given by the TLS server, the TLS client MUST abort the
   handshake.
"""

C= ontrapositively, if the TLS client finds one or more associations that matc= h the certificate, then it MAY proceed with the handshake.



O= n Thu, Jun 13, 2013 at 9:20 AM, Bry8 Star <bry8star@inventati.org= > wrote:
Please explain/comment more on these:

Conventions, used in this email msg:
* The Beginning "%" symbol (and a space after it), is not used in=
any real zone file. ( I have used this symbol used here for this
email post only, just to indicate a begin of a configuration line,
as, multiple time email reply can/may change position or remove
Line-Feed(LF/EOL) indicator ).
* Command-line will start with "$" symbol (and a space after it).= Do
not use shown '$' when using in real command.
* When a command-line ("$ ") will show "\" symbol at-en= d, then bring
below one line after it, and remove the \ symbol. =A0Here "\" sym= bol
is indicating "Next-Line is part of This Line".

I'm using such TLS / SSL Chain:

SSL / TLS Certificate Pyramid & Levels :

01 =3D Level-01 =3D is TA/Root-CA cert. (My_Root_CA.crt). Self-signed
new my own CA/TA cert.
02 =3D Level-02 =3D is an Intermediate CA cert. (My_i-CA.crt). under L-1. 03 =3D Level-03 =3D is an Intermediate Authority cert for dom1.tld.
(dom1_tld_IA.crt). =A0It can only be used to create certs, only under
dom1.tld.
04 =3D Level-04 =3D is Server/EE-Certs : { s1.dom1.tld.crt,
s2.dom1.tld.crt, im.dom1.tld.crt, im2.dom1.tld.crt,
www.dom1.tld.crt, m.dom1.tld.crt }

TA =3D Trust Anchor . CA =3D Certificate Authority.
IA =3D Intermediate Authority.
cert =3D certificate. cert keypair. Both public key portion and
private key portion.
crt =3D cert's public (key) portion. can be shared.
key / prv.pem =3D private key portion of cert. do not share.

As a domain-owner, and an operator, etc ... i will be using my own
new self-signed TA (Trust Anchor) cert/bundle (aka, self-signed CA),
so i will need to do these, i understand this part:

% _443._tcp.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _443._tcp.s1.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _443._tcp.s2.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _443._tcp.www.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _443._tcp.m.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _25._tcp.s1.dom1.tld. =A0180 IN TLSA 2 0 0 C_A_D_of_TA
% _993._tcp.s1.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _995._tcp.s1.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _587._tcp.s1.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _25._tcp.s2.dom1.tld. =A0180 IN TLSA 2 0 0 C_A_D_of_TA
% _993._tcp.s2.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _995._tcp.s2.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _587._tcp.s2.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA

But when only TLSA TA "2 S M" is used, it is indicating, clients = and
servers need to use multiple channels (port 80, port 443, port 53)
for related various purpose. :(

C_A_D =3D Certificate Association Data. Either a Raw/Binary Data,
DER-encoded full cert, when s=3D0 & m=3D0. Or, it can be a hash-code (Base64-encoded) of raw-data, when s=3D1, and m=3D1 or m=3D2. In Hex.

Here, to create "C_A_D_of_TA" code-portion :
i will 1st create a DER file (C_A_D_of_TA.der), based on Level-3
dom1_tld_IA.crt file, and then in 2nd step i will append DER code
based on Level-2 My_i-CA.crt file, and then in 3rd step i will
append DER code based on Level-1 My_Root_CA.crt file. (Similar to
what we do for creating TLS chain cert for httpd server software) :

$ openssl x509 -in dom1_tld_IA.crt \
=A0 =A0 =A0 =A0 -outform der -out C_A_D_of_TA.der
$ openssl x509 -in My_i-CA.crt \
=A0 =A0 =A0 =A0 -outform der -out My_i-CA.der
$ cat My_i-CA.der >> C_A_D_of_TA.der
$ openssl x509 -in My_Root_CA.crt \
=A0 =A0 =A0 =A0 -outform der -out My_Root_CA.der
$ cat My_Root_CA.der >> C_A_D_of_TA.der

I (as Domain-owner) want my side NS/DNS-servers to serve FULL DER
TLS certs. Both TA/Root-CA and EE/Server-Cert.

Let us assume, i have such dns entries : Here 's1' is server
hostname. So is 's2'. =A0Visitors & users will access 's1&#= 39; srvr via
'www' srvc, and access 's2' srvr via 'm' service (s= ervice
sub-domain-name) normally. =A0When/if 's1' srvr is down, then user<= br> will goto 's2' srvr for 'www' srvc, and when 's2' s= rvr is down then
user will goto 's1' srvr for 'm' srvc:

% dom1.tld. 3600 IN SOA s1.dom1.tld. hostmaster.dom1.tld. 2013052910
18000 3600 864000 3600
% dom1.tld. 3000 IN NS s1.dom1.tld.
% dom1.tld. 3000 IN NS s2.dom1.tld.
% dom1.tld. 300 IN A =A0 =A0IP.ADRS_S-1_IPv4
% dom1.tld. 300 IN A =A0 =A0IP.ADRS_S-2_IPv4
% dom1.tld. 300 IN AAAA IP::ADRS_S-1_IPv6
% dom1.tld. 300 IN AAAA IP::ADRS_S-2_IPv6
% s1.dom1.tld. 900 IN A =A0 =A0IP.ADRS_S-1_IPv4
% s2.dom1.tld. 900 IN A =A0 =A0IP.ADRS_S-2_IPv4
% s1.dom1.tld. 900 IN AAAA IP::ADRS_S-1_IPv6
% s2.dom1.tld. 900 IN AAAA IP::ADRS_S-2_IPv6
% www.dom1.tld. 300 IN CNAME dom1.tld.
% m.dom1.tld. 300 IN CNAME dom1.tld.
% _http._tcp.dom1.tld. 3600 IN SRV 0 0 80 www.dom1.tld.
% _https._tcp.dom1.tld. 3600 IN SRV 0 0 443 www.dom1.tld.
% _http._tcp.www.dom1.tld. 3600 IN SRV 0 0 80 www.dom1.tld.
% _https._tcp.www.dom1.tld. 3600 IN SRV 0 0 443 www.dom1.tld.
% _http._tcp.m.dom1.tld. 3600 IN SRV 0 0 80 m.dom1.tld.
% _https._tcp.m.dom1.tld. 3600 IN SRV 0 0 443 m.dom1.tld.
% dom1.tld. 3600 IN MX 10 s1.dom1.tld.
% dom1.tld. 3600 IN MX 20 s2.dom1.tld.
% _smtp._tcp.dom1.tld. 3600 IN SRV 10 0 25 s1.dom1.tld.
% _smtp._tcp.dom1.tld. 3600 IN SRV 20 0 25 s2.dom1.tld.
% _smtp._tcp.s1.dom1.tld. 3600 IN SRV 10 0 25 s1.dom1.tld.
% _smtp._tcp.s1.dom1.tld. 3600 IN SRV 20 0 25 s2.dom1.tld.
% _smtp._tcp.s2.dom1.tld. 3600 IN SRV 10 0 25 s2.dom1.tld.
% _smtp._tcp.s2.dom1.tld. 3600 IN SRV 20 0 25 s1.dom1.tld.
% _submission._tcp.dom1.tld. 3600 IN SRV 10 0 587 s1.dom1.tld.
% _submission._tcp.dom1.tld. 3600 IN SRV 20 0 587 s2.dom1.tld.
% _submission._tcp.s1.dom1.tld. 3600 IN SRV 10 0 587 s1.dom1.tld.
% _submission._tcp.s1.dom1.tld. 3600 IN SRV 20 0 587 s2.dom1.tld.
% _submission._tcp.s2.dom1.tld. 3600 IN SRV 10 0 587 s2.dom1.tld.
% _submission._tcp.s2.dom1.tld. 3600 IN SRV 20 0 587 s1.dom1.tld.
% _imaps._tcp.dom1.tld. 3600 IN SRV 0 0 993 s1.dom1.tld.
% _imaps._tcp.dom1.tld. 3600 IN SRV 5 0 993 s2.dom1.tld.
% _imaps._tcp.s1.dom1.tld. 3600 IN SRV 0 0 993 s1.dom1.tld.
% _imaps._tcp.s1.dom1.tld. 3600 IN SRV 5 0 993 s2.dom1.tld.
% _imaps._tcp.s2.dom1.tld. 3600 IN SRV 0 0 993 s2.dom1.tld.
% _imaps._tcp.s2.dom1.tld. 3600 IN SRV 5 0 993 s1.dom1.tld.
% _pop3s._tcp.dom1.tld. 3600 IN SRV 0 0 995 s1.dom1.tld.
% _pop3s._tcp.dom1.tld. 3600 IN SRV 5 0 995 s2.dom1.tld.
% _pop3s._tcp.s1.dom1.tld. 3600 IN SRV 0 0 995 s1.dom1.tld.
% _pop3s._tcp.s1.dom1.tld. 3600 IN SRV 5 0 995 s2.dom1.tld.
% _pop3s._tcp.s2.dom1.tld. 3600 IN SRV 0 0 995 s2.dom1.tld.
% _pop3s._tcp.s2.dom1.tld. 3600 IN SRV 5 0 995 s1.dom1.tld.

I want, FUTURE FULL DANE & DNSSEC supported
web-browsers/HTTPS-clients (and httpd (HTTP, HTTPS) servers) to
pull/retrieve BOTH TA & EE type of certs from DNS, like : 1st
pull/retrieve FULL authentic EE/server-cert from TLSA dns ("1 S M"= ; &
"3 S M" cases), and (in 2nd step), also pull/retrieve new
self-signed TA ("TLSA 2 S M"), or public CA ("TLSA 0 S M&quo= t;) from DNS
record (if it exist there and if required for TLS chain validation),
and after verifying TLSA EE cert and TLSA cert chain and
authenticity, then use EE/Server-Cert for creating authentic &
encrypted secured HTTPS connection.

I basically want both HTTPS-client and HTTPS-server, to retrieve,
domain-owner declared/published, both TA and EE full certificate
from DNS, and then after cert chain validation succeeds, use the EE
cert to create encrypted connection. =A0Without depending on any .crt
files specified or loaded in/from server or client software.
Server-side software will only need cert's private_key file portion
for creating encrypted traffic.

So based on above expectation, i also want to add these:

% _443._tcp.www.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_www_Srvr-Cert
% _443._tcp.m.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_m_Srvr-Cert

Or, am i suppose to add these ?

% _443._tcp.www.dom1.tld. 180 IN TLSA 3 0 0 C_A_D_of_www_Srvr-Cert
% _443._tcp.m.dom1.tld. 180 IN TLSA 3 0 0 C_A_D_of_m_Srvr-Cert

I will create C_A_D_of_www_Srvr-Cert.der like this:
$ openssl x509 -in www_dom1_tld.crt \
=A0 =A0 =A0 =A0 -outform der \
=A0 =A0 =A0 =A0 -out C_A_D_of_www_Srvr-Cert.der

And for other certs:
$ openssl x509 -in m_dom1_tld.crt \
=A0 =A0 =A0 =A0 -outform der \
=A0 =A0 =A0 =A0 -out C_A_D_of_m_Srvr-Cert.der
$ openssl x509 -in s1_dom1_tld.crt \
=A0 =A0 =A0 =A0 -outform der \
=A0 =A0 =A0 =A0 -out C_A_D_of_s1_Srvr-Cert.der
$ openssl x509 -in s2_dom1_tld.crt \
=A0 =A0 =A0 =A0 -outform der \
=A0 =A0 =A0 =A0 -out C_A_D_of_s2_Srvr-Cert.der

So for my case, i will be adding both "TLSA 1 0 0" and "TLSA= 2 0 0",
full certificates. =A0To me, adding both TLSA "2 0 0" and "1= 0 0" with
full certs, makes more sense, specially when domain-owner will be
using their own new self-signed/TA cert based solution. =A0Then client
and server both can retrieve the TA and EE type cert using only one
channel, DNS-channel, port 53. =A0I want to call it or treat it, as, a
Complete TLSA declaration, as it eliminates any chance of confusion,
and reduces TLS obtain & validation related steps, as it can easily
obtain all necessary full TLS certs from DNS records, authenticated
by DNSSEC.

I'm trying to say via DNS ... here (TLSA 1 0 0) is my server's
self-signed full EE/server-cert, and here (TLSA 2 0 0) is my own &
new self-signed full Root-CA/TA cert bundle, ... ( so, you(client)
must use these (TA & EE certs) to validate the cert chain. and then
on success, use the EE cert for creating HTTPS secured connection).

I want to support various & mixed channel based solutions, so i will also do these : I will add both TLSA TA "2 0 0" and TLSA EE "= ;1 0 0"
as mentioned in above. =A0So that, clients & servers both side can
still obtain both TA & EE type of TLSA records via DNS channel (port 53). =A0And i will also serve/share full TLS cert chain/bundle-file
from HTTPS-server (apache/httpd) service software. =A0So that, clients
& servers both side can still obtain (1) server/EE-cert and rest of
the TLS cert chain's linked certs (if server/EE-cert requires), via
HTTPS channel (port 443) and/or using OCSP channel (port 80) for TLS
cert's PKIX validity).

I want, client & server software able to obtain & use entire EE cer= t
(from TLSA "1 S M" or TLSA "3 S M"), and i want them ab= le to obtain
& use entire TA cert chain (from TLSA "2 S M" or TLSA "0= S M").

So for my case i will and want-to, use TLSA like this:

% _443._tcp.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _443._tcp.s1.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _443._tcp.s1.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_s1_dom1_tld
% _443._tcp.s2.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _443._tcp.s2.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_s2_dom1_tld
% _443._tcp.www.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _443._tcp.www.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_www_dom1_tld
% _443._tcp.m.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _443._tcp.m.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_m_dom1_tld
% _25._tcp.s1.dom1.tld. =A0180 IN TLSA 2 0 0 C_A_D_of_TA
% _25._tcp.s1.dom1.tld. =A0180 IN TLSA 1 0 0 C_A_D_of_s1_dom1_tld
% _993._tcp.s1.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _993._tcp.s1.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_s1_dom1_tld
% _995._tcp.s1.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _995._tcp.s1.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_s1_dom1_tld
% _587._tcp.s1.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _587._tcp.s1.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_s1_dom1_tld
% _25._tcp.s2.dom1.tld. =A0180 IN TLSA 2 0 0 C_A_D_of_TA
% _25._tcp.s2.dom1.tld. =A0180 IN TLSA 1 0 0 C_A_D_of_s2_dom1_tld
% _993._tcp.s2.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _993._tcp.s2.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_s2_dom1_tld
% _995._tcp.s2.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _995._tcp.s2.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_s2_dom1_tld
% _587._tcp.s2.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _587._tcp.s2.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_s2_dom1_tld

Does DANE currently allow TWO combined TLSA record usage ? i want to
use both TLSA TA ("TLSA 2 0 0") and TLSA EE ("TLSA 1 0 0&quo= t;)
dns-record, for verifying EE cert created under a self-signed new TA
cert, and force both client & server side to validate both type of
certs, and after validation succeeds, the EE cert will be used for
HTTPS encryption, by both client & server.
If such/above is not supported, then please add support for it.

Since i will not use partial cert portion or hash, in TLSA EE "1 S
M" or "3 S M" cases, so you may avoid referencing on that, a= nd
please focus on full EE cert based practice/guidance/example. =A0But
if (non-Full) partial cert is appropriate or adequate for TLSA TA "2 S M" or "0 S M" cases without invoking/using extra channel u= sage,
then pls do mention on that.

Please point out my errors, and help us/me/domain-owners with
better/improved configuration, thanks in advance.

-- Bright Star.
Jun 13, 2013.



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


--e89a8fb1fbfecfe55b04df0995f4-- From viktor1dane@dukhovni.org Thu Jun 13 12:15: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 60E3821F9A26 for ; Thu, 13 Jun 2013 12:15:42 -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 q8TVAxFTTubn for ; Thu, 13 Jun 2013 12:15:37 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 3502921F9425 for ; Thu, 13 Jun 2013 12:15:37 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 2FAC82AB9E6; Thu, 13 Jun 2013 19:15:36 +0000 (UTC) Date: Thu, 13 Jun 2013 19:15:36 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130613191536.GL29420@mournblade.imrryr.org> References: <51B9C72E.2040706@inventati.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51B9C72E.2040706@inventati.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Combined TLSA TA (2 S M) and TLSA EE (1 S M) Usage 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, 13 Jun 2013 19:15:42 -0000 On Thu, Jun 13, 2013 at 06:20:46AM -0700, Bry8 Star wrote: > % _443._tcp.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA The "2 0 0" TLSA record is unwise, this will give too many naive DNS implementations in firewalls and the like indigestion with overly large records and dramatically increases the payload size in DNS amplification attacks. Avoid "2 0 0" and use "2 1 1" instead, then make sure to include the corresponding TA certificate in the server's TLS handshake. > C_A_D = Certificate Association Data. Either a Raw/Binary Data, > DER-encoded full cert, when s=0 & m=0. Or, it can be a hash-code > (Base64-encoded) of raw-data, when s=1, and m=1 or m=2. In Hex. There is no Base64 encoding of any data in TLSA RRs. For matching type 0, the certificate association data is binary DER, which DNS query tools display in hex, and hex is also what you put into your zone file, but the actual record value and wire-format is binary DER. The selector has no effect on the value encoding, it chooses between an X.509 certificate and its SubjectPublicKeyInfo public key. > $ openssl x509 -in dom1_tld_IA.crt \ > -outform der -out C_A_D_of_TA.der > $ openssl x509 -in My_i-CA.crt \ > -outform der -out My_i-CA.der > $ cat My_i-CA.der >> C_A_D_of_TA.der Do NOT concatenate DER X.509 certificates. Each DER value encodes exactly ONE certificate or public key. > I (as Domain-owner) want my side NS/DNS-servers to serve FULL DER > TLS certs. Both TA/Root-CA and EE/Server-Cert. You should strongly consider the possibility that this choice is misguided. > and after verifying TLSA EE cert and TLSA cert chain and > authenticity, then use EE/Server-Cert for creating authentic & > encrypted secured HTTPS connection. In the DANE TLSA model a server certificate is valid if it matches ANY ONE of the associated TLSA records, you may publish both TA and EE associations, but clients will not require multiple matches, if either the TA or the EE TLSA RR passes, the client is done. > I basically want both HTTPS-client and HTTPS-server, to retrieve, > domain-owner declared/published, both TA and EE full certificate > from DNS, and then after cert chain validation succeeds, use the EE > cert to create encrypted connection. Without depending on any .crt > files specified or loaded in/from server or client software. > Server-side software will only need cert's private_key file portion > for creating encrypted traffic. You won't get what you want. The server will need to configure a complete chain file including the "2 s m" TA. > So based on above expectation, i also want to add these: You can stop there, the "above expectation" is unrealistic. -- Viktor. From hallam@gmail.com Thu Jun 13 12:38: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 8397F21F9A88 for ; Thu, 13 Jun 2013 12:38: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, 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 IU3Z9k2MRwrH for ; Thu, 13 Jun 2013 12:38:33 -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 082CC21F9A9F for ; Thu, 13 Jun 2013 12:38:32 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id c10so1306142wiw.4 for ; Thu, 13 Jun 2013 12:38:32 -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=jINgk1Gp6U+jVc+xLnj/JZm92SDbZxCYUDl2xdW138U=; b=n6KZEAeC6d5/n0b7JBPa/z7W1NG5vpXnol/Je0kd/Wld4DT/NY2lY9PIkX1/QnVxL/ IZYLcTOtFfGiverAaRnQbfDY/bw5eWvKVzXQ+ci7hJWz9ROX6uissp+BhhJyNeaFlN3l pmMiNz5AkNWXfNYP4jelSqf53f0wQWTFU1eTs88ds89n6Jug6GRiJWipm4gwp8i5paxl 9pea1nAV/LeL+cijeBAjY+W/xUdzbxBTexxLFraGKnmLer0XlU4oRykTIquk2C5WTjpJ nMJm5PQA3PVvkwZ5yFtyHkHF1uB5a51y1MRpJ7VCbDr4bFOfdpqncdgnmBYU9jdICbcn my4A== MIME-Version: 1.0 X-Received: by 10.180.206.205 with SMTP id lq13mr8453763wic.56.1371152312153; Thu, 13 Jun 2013 12:38:32 -0700 (PDT) Received: by 10.194.54.10 with HTTP; Thu, 13 Jun 2013 12:38:31 -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: Thu, 13 Jun 2013 15:38:31 -0400 Message-ID: From: Phillip Hallam-Baker To: Ben Laurie Content-Type: multipart/alternative; boundary=001a11c382d47fc14304df0e4665 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, 13 Jun 2013 19:38:34 -0000 --001a11c382d47fc14304df0e4665 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 12, 2013 at 9:08 AM, Ben Laurie wrote: > On 12 June 2013 13:31, Phillip Hallam-Baker wrote: > > > A second advantage is that it enables discretion. Any security check that > > you implement in the browser has to be reduced to a set of codified, > > completely standard rules. The spam filtering companies don't take that > > approach, they have a more tactical scheme making use of heuristic data > and > > actively change their strategy in response to changes in opposition > tactics. > > Fair points. I note, though, that you still end up configuring every > light bulb... I do that once and the protocol allows the configuration to be done with a smart phone with a QR code reader capability: http://tools.ietf.org/html/draft-hallambaker-wsconnect-02 I don't think it is practical to expect a light bulb to have a full IP stack let alone DANE. but it is possible for them to consume DANE and PKIX trust assertions if there is a secure way to delegate those choices to another device. More likely the light bulb is plugging into some low bandwidth, short range wireless network. So what you would want is not connecting to Omnibroker but some sort of general 'home automation' center that will tell the lightbulb how and where to plug into the local site infrastructure. After realizing that I chopped the Omnibroker protocol into two parts. The difficult design decisions are all in the JSON Connect (JCX) Web Service which makes it easy to establish that initial authenticated connection to a trusted Web Service (which can be of any type at all). Omnibroker is then simply one protocol that makes use of JCX to establish the long term trust connection. > The broker can be required to hand over all the data used to make its > > decision. > > Not much use if the client can't check it? The advantage of a CT (or > RT)-like scheme is that anyone can check it, and all the client needs > to be able to do is check consistency... > Come on, you point out yourself that you only need a handful of browsers to perform CT checking in order for CT to be largely effective at detecting a major CA breach. People who don't trust their broker can run a browser that revalidates the chains locally. But as we all know, even a browser with local DNSSEC validation is going to sometimes need help making sure it gets DNSSEC data to work from. So running the omnibroker just as a path discovery agent is still valuable. But for the general consumer, they actually trust us to decide what programs run on their machines at all. CertSentry, the Comodo Ombinbroker-like application is currently bundled on the anti-virus product. The expectation is that that Omnibroker will eventually replace the proprietary protocol in CertSentry 1.0 to power the next generation. -- Website: http://hallambaker.com/ --001a11c382d47fc14304df0e4665 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 12, 2013 at 9:08 AM, Ben Laurie <benl@google.co= m> wrote:
On 12 June 2013 13:31, Phillip Hallam-Bak= er <hallam@gmail.com> wrote:<= br>
> A second advantage is that it enables discretion. Any security check t= hat
> you implement in the browser has to be reduced to a set of codified, > completely standard rules. The spam filtering companies don't take= that
> approach, they have a more tactical scheme making use of heuristic dat= a and
> actively change their strategy in response to changes in opposition ta= ctics.

Fair points. I note, though, that you still end up configuring = every
light bulb...

I do that once and the = protocol allows the configuration to be done with a smart phone with a QR c= ode reader capability:


I don't think it is practical to expect a lig= ht bulb to have a full IP stack let alone DANE. but it is possible for them= to consume DANE and PKIX trust assertions if there is a secure way to dele= gate those choices to another device.

More likely the light bulb is plugging into some = low bandwidth, short range wireless network. So what you would want is not = connecting to Omnibroker but some sort of general 'home automation'= center that will tell the lightbulb how and where to plug into the local s= ite infrastructure.

After realizing that I chopped the Omnibrok= er protocol into two parts. The difficult design decisions are all in the J= SON Connect (JCX) Web Service which makes it easy to establish that initial= authenticated connection to a trusted Web Service (which can be of any typ= e at all). Omnibroker is then simply one protocol that makes use of JCX to = establish the long term trust connection.


>= The broker can be required to hand over all the data used to make its
> decision.

Not much use if the client can't check it? The advantage of a CT = (or
RT)-like scheme is that anyone can check it, and all the client needs
to be able to do is check consistency...

Come on, you point out yourself that you only need a= handful of browsers to perform CT checking in order for CT to be largely e= ffective at detecting a major CA breach.

People who don't trust their broker can run a browser that revalida= tes the chains locally. But as we all know, even a browser with local DNSSE= C validation is going to sometimes need help making sure it gets DNSSEC dat= a to work from. So running the omnibroker just as a path discovery agent is= still valuable.

But for the= general consumer, they actually trust us to decide what programs run on th= eir machines at all. CertSentry, the Comodo Ombinbroker-like application is= currently bundled on the anti-virus product. The expectation is that that = Omnibroker will eventually replace the proprietary protocol in CertSentry 1= .0 to power the next generation.


--
Website: http://hallambaker.com/
--001a11c382d47fc14304df0e4665-- From bry8star@inventati.org Fri Jun 14 00:29:41 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 C07D921F9AA9 for ; Fri, 14 Jun 2013 00:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[AWL=1.450, 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 Kb6Lyr7Y5X0Z for ; Fri, 14 Jun 2013 00:29:40 -0700 (PDT) Received: from diserzione.investici.org (diserzione.investici.org [IPv6:2002:52dd:6399::1]) by ietfa.amsl.com (Postfix) with ESMTP id B2EBC21F9A6A for ; Fri, 14 Jun 2013 00:29:38 -0700 (PDT) Received: from [82.221.99.153] (diserzione [82.221.99.153]) (Authenticated sender: bry8star@inventati.org) by localhost (Postfix) with ESMTPSA id 0E04D180A61 for ; Fri, 14 Jun 2013 07:29:33 +0000 (UTC) X-DKIM: Sendmail DKIM Filter v2.8.2 diserzione.investici.org 0E04D180A61 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inventati.org; s=stigmate; t=1371194976; bh=csBooANsL34n/Dx5reGjBjJIUzKlY1j4gcI3BSNnsu4=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject:References: In-Reply-To:Content-Type; b=f5f6JsyaHe6p9Hs530x/XrdHQbyXXu4XP2z2TVk6RKe7RBodUFuzJHQ2uY3a+MKgO JJb380qeZ5zjUwPJVJ5J7VJZ9WA6FL6dj7JsscxA7tAYuUEwckAff6vJCTSprIPeaz S5qV2hCDYxpi83CTVnuMjD/ezof2JZmSsMM+cGLo= Message-ID: <51BAC647.1060302@inventati.org> Date: Fri, 14 Jun 2013 00:29:11 -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: <51B9C72E.2040706@inventati.org> <20130613191536.GL29420@mournblade.imrryr.org> In-Reply-To: <20130613191536.GL29420@mournblade.imrryr.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2OJPLWEAICLMMBFJOBJVK" Subject: Re: [dane] Combined TLSA TA (2 S M) and TLSA EE (1 S M) Usage 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: Fri, 14 Jun 2013 07:29:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2OJPLWEAICLMMBFJOBJVK Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Received from Viktor Dukhovni, on 2013-06-13 12:15 PM: > On Thu, Jun 13, 2013 at 06:20:46AM -0700, Bry8 Star wrote: >=20 >> % _443._tcp.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA >=20 > The "2 0 0" TLSA record is unwise, this will give too many naive > DNS implementations in firewalls and the like indigestion with > overly large records and dramatically increases the payload size > in DNS amplification attacks. Avoid "2 0 0" and use "2 1 1" instead, > then make sure to include the corresponding TA certificate in the > server's TLS handshake. >=20 >> C_A_D =3D Certificate Association Data. Either a Raw/Binary Data, >> DER-encoded full cert, when s=3D0 & m=3D0. Or, it can be a hash-code >> (Base64-encoded) of raw-data, when s=3D1, and m=3D1 or m=3D2. In Hex. >=20 > There is no Base64 encoding of any data in TLSA RRs. For matching > type 0, the certificate association data is binary DER, which DNS > query tools display in hex, and hex is also what you put into your > zone file, but the actual record value and wire-format is binary DER. >=20 > The selector has no effect on the value encoding, it chooses between > an X.509 certificate and its SubjectPublicKeyInfo public key. >=20 >> $ openssl x509 -in dom1_tld_IA.crt \ >> -outform der -out C_A_D_of_TA.der >> $ openssl x509 -in My_i-CA.crt \ >> -outform der -out My_i-CA.der >> $ cat My_i-CA.der >> C_A_D_of_TA.der >=20 > Do NOT concatenate DER X.509 certificates. Each DER value encodes > exactly ONE certificate or public key. >=20 >> I (as Domain-owner) want my side NS/DNS-servers to serve FULL DER >> TLS certs. Both TA/Root-CA and EE/Server-Cert. >=20 > You should strongly consider the possibility that this choice is > misguided. >=20 >> and after verifying TLSA EE cert and TLSA cert chain and >> authenticity, then use EE/Server-Cert for creating authentic & >> encrypted secured HTTPS connection. >=20 > In the DANE TLSA model a server certificate is valid if it matches > ANY ONE of the associated TLSA records, you may publish both TA > and EE associations, but clients will not require multiple matches, > if either the TA or the EE TLSA RR passes, the client is done. >=20 >> I basically want both HTTPS-client and HTTPS-server, to retrieve, >> domain-owner declared/published, both TA and EE full certificate >> from DNS, and then after cert chain validation succeeds, use the EE >> cert to create encrypted connection. Without depending on any .crt >> files specified or loaded in/from server or client software. >> Server-side software will only need cert's private_key file portion >> for creating encrypted traffic. >=20 > You won't get what you want. The server will need to configure a > complete chain file including the "2 s m" TA. >=20 >> So based on above expectation, i also want to add these: >=20 > You can stop there, the "above expectation" is unrealistic. >=20 Thanks for correction and lesson. My understanding is, current model is designed to depend on TLS certs (or TLS chain certs), either be delivered via server software, or, TLS certs (or TLS chain certs) are pre-loaded into clients software, for creating secured connection. And then check those TLS certs against TLSA/DANE records to make sure those are indeed declared & approved by that domain-name's owner/holder. And then on success, initiate HTTPS (encrypted and) secured communication, and if TLS certs do not match against TLSA, then fallback to HTTP (non-encrypted & non-secured) communication. (I suggested in another post, to show some indicator in client side for these outcomes, and server-side can also add some type of meta-record/meta-indicator in a communication, to indicate if communication is DANE authenticated or not). What i am expecting, is that, in future, (may be only some, not all) clients and servers may want to use only DNS (DNSSEC) channel authenticated TLS cert based encryption, if domain-owner/server-side and visitors/users/client-side wants to do that specifically. These will not work now, as i've learned from you, multiple TLS DER cannot be concatenated in TA TLSA :( *sad* For a DNS channel Based TLS cert sharing System (PDKIX or DPKIX or DPKI) to work : only two type of TLSA, as TA and EE, will not be suffice. Most public CA, and TA PKIX includes, (and self-signed new TA based TLS cert chain should include) at-least 3 certs in a full chain : (1) Root-CA/TA, (2) Intermediate CA Cert (IA, ICA), (3) EE : Server or Domain cert. TLS cert type 1/TA can goto TA TLSA ("2 S M", "0 S M") dns record, TLS cert type 3/EE can goto EE TLSA ("1 S M" or "3 S M") dns record, so for the middle, IA type of TLS cert, or, multiple middle cert, another TLSA indicator dns record is needed, and that also need to have multiple cert support. Or, existing TA standard is modified further to allow specifying multiple certs as cert chain. So if, addition of a new support, for including multiple cert or cert chain in existing TA TLSA ("2 S M" or "0 S M") dns records, ... is not preferred, ... then, ... another new TLSA can be defined & may be it can be called IA (Intermediate Authority) TLSA. May be it can have "5 s m". Usage type 5 ? If declaration/publication of multiple TLS certs for a cert-chain, is added/adopted into TA TLSA or into IA TLSA ("5 S M"), then, can each DER encoded cert be kept separated with a LF or other special binary character ? I'm sure there are some users who will want to take it one step further. Encountering DNS amplification : Improvement and New possibilities cannot be and should not stopped just for this attack ! That would not be smart solution. Something smart & advanced (that is staying one step ahead) need to be done. Since DANE DNS (port 53) channel, and HTTPS (port 443) channel are becoming related and integrated, so apps in server side will need to understand, after a TLSA query if HTTPS is not initiated by the same IP, then may be some type of further limitation/restriction is needed, on both domain server, and in https server. -- Bright Star. ------enig2OJPLWEAICLMMBFJOBJVK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJRusZSAAoJEID2ikYfWSP6vdUQAJsJ9AB22N/4z8r4mDL3ZiYM Bz6jtr7U6VK6bgIjVOmQSx1fUoQd25eeHaP9WdJE+ih+LLhnjf05L2YW2OX9o37O XW+YIXSESTbPvKCFouzlvf9fAc8j0v2mLvxqjpbhjcaPfCMmh51pNigC2Jstq3xc tzmhEXS49NcnK+7bQ97+GYZvlr76b+tcPIa/V8FJ/Ny10qaeOj7Ukh7ty4XrScr/ RQFLWGMHRIeq14tO8SIwN35VDjHpu7ot39QCtDAsAZBbClzOIpesPP5XpK9zkxy2 w9Dw8wUT6qAeuUy5s3yQMteoSef50vmNesikJe8qDLkalEIsWYewPlX4PRMpYn2Z y4xkwW4mEGdIleHGzFIOTSeB5D8lhAv873kjNlr0vY0y2VmDM5A4F9VB0yr2snas LhK6PFkoSFwao0lcENIdIN/Wx1Kn/rYXThfO4M6K8VcF+Y6JrKI9gai0oVksGOdN uuHjL4YHxlasAYAFvf6GRrIidp8geYh9f/4zpR05LCKGI66NRgFqnLV/0elAwAZ6 zcivgRDfh2ePcd1CoyjzdwDm3qRHXJYq9xiGmUg51qbVkirCwljXXljCgQwUBiPT k8Dv0k+/zCQpin2p86Mcbbb7SqBqgnSgDWyGAvMZTjnG1RXpBS9d76bcXslJHh9K kG5r1Ok8fYgNxTC5tqIR =fMPB -----END PGP SIGNATURE----- ------enig2OJPLWEAICLMMBFJOBJVK-- From benl@google.com Fri Jun 14 06:12: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 AA58C21F9CA7 for ; Fri, 14 Jun 2013 06:12:05 -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 DrJqweLmUDL5 for ; Fri, 14 Jun 2013 06:12:04 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id BC70121F9C89 for ; Fri, 14 Jun 2013 06:12:04 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id c10so1392188ieb.10 for ; Fri, 14 Jun 2013 06:12:04 -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=EiMhP0QhinaIQVILW7+FM2xyKdpevKTz7f1A8rtt4vk=; b=FznsCyOodqeZO8MxgiUatusw0eQysJ8lTiXuExu88XJmpJZwDW6ONhecYURuRFeB/I cWHZ8YdUFj12YMVoteU+Temm2lgnPObFYMJ3LW1xR07zACijaa5o9SOqsFyV0Llx3gzg WD16U7pGBFtsskQ2Xrq5aGcUf5yaxiyB3FPxVgHdwacmlCgrOsQyCsOdj2EU0WX1vB0G Oae1QHe2JASA0te8YTcy2cVEEog8J61wVmv8PQ4BFEbLm8+N8iZlA3fnjnNArV1yn85/ owevGVfjPrhk0RMNAAeAvLxV8FGPPBraMFElY54mjhOd8aQSL6Fdi1NnCY8nU4uwo3F3 hHug== 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=EiMhP0QhinaIQVILW7+FM2xyKdpevKTz7f1A8rtt4vk=; b=gfWE5qly9bwYWLwf07Gi1Lz4QFkGt5UN2T/g0lysiKqFsRHcp04kfIAKKUSRgAaofO HcuZnjWutAaPKossySXyEuv8O8rHGI47+xDuFoiBzc641IgTpGYWXlsbhllw73uT4fLT l51GHBBCEQy0OsTr6v9KlnEE8lMI8oiAfly0uCqhvXdZ1cLT04MBQdVviLBZ3SOGYo1d +9upThmol0zm5lpbtguv2BVdUSFvzhZ9/VCR+zDFRlD9GXvdN0iPLkKDN+FOBzaCX55b t5eLfQY9WFh3oXSlC5xvYLvWwJYfXwX2PKJN1afJTYfFYY837G8Tyok5bJUOHa3w3h+h zwyg== MIME-Version: 1.0 X-Received: by 10.50.153.113 with SMTP id vf17mr977509igb.101.1371215524233; Fri, 14 Jun 2013 06:12:04 -0700 (PDT) Received: by 10.64.42.72 with HTTP; Fri, 14 Jun 2013 06:12:04 -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, 14 Jun 2013 14:12:04 +0100 Message-ID: From: Ben Laurie To: Phillip Hallam-Baker Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmKSmToQ+DIjHOqLy5iLG1JKdqLHwUqe4LlLDPn07GoJ+GRcNx5id8v4LYy8SVoZAbEkqvbMoGzQ+sTQckvZiFm//zzOFVr6qSPVtwZtYAMz7lz5x1gM7AukJHH+DkNYGObKkvTpp6lekjJgVgeVbl3BCw52Kmhx0I0GI6qpxPqX/CvqYn8f3mXWLIaVHz0hF3lz2tY 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, 14 Jun 2013 13:12:05 -0000 On 13 June 2013 20:38, Phillip Hallam-Baker wrote: > On Wed, Jun 12, 2013 at 9:08 AM, Ben Laurie wrote: >> >> On 12 June 2013 13:31, Phillip Hallam-Baker wrote: >> >> > A second advantage is that it enables discretion. Any security check >> > that >> > you implement in the browser has to be reduced to a set of codified, >> > completely standard rules. The spam filtering companies don't take that >> > approach, they have a more tactical scheme making use of heuristic data >> > and >> > actively change their strategy in response to changes in opposition >> > tactics. >> >> Fair points. I note, though, that you still end up configuring every >> light bulb... > > > I do that once and the protocol allows the configuration to be done with a > smart phone with a QR code reader capability: > > http://tools.ietf.org/html/draft-hallambaker-wsconnect-02 > > I don't think it is practical to expect a light bulb to have a full IP stack > let alone DANE. but it is possible for them to consume DANE and PKIX trust > assertions if there is a secure way to delegate those choices to another > device. > > More likely the light bulb is plugging into some low bandwidth, short range > wireless network. So what you would want is not connecting to Omnibroker but > some sort of general 'home automation' center that will tell the lightbulb > how and where to plug into the local site infrastructure. > > After realizing that I chopped the Omnibroker protocol into two parts. The > difficult design decisions are all in the JSON Connect (JCX) Web Service > which makes it easy to establish that initial authenticated connection to a > trusted Web Service (which can be of any type at all). Omnibroker is then > simply one protocol that makes use of JCX to establish the long term trust > connection. > > >> > The broker can be required to hand over all the data used to make its >> > decision. >> >> Not much use if the client can't check it? The advantage of a CT (or >> RT)-like scheme is that anyone can check it, and all the client needs >> to be able to do is check consistency... > > > Come on, you point out yourself that you only need a handful of browsers to > perform CT checking in order for CT to be largely effective at detecting a > major CA breach. That is only true because anyone can check that CT is behaving itself. So far, it seems Omnibroker can safely lie to selected clients with no risk of detection. > People who don't trust their broker can run a browser that revalidates the > chains locally. But as we all know, even a browser with local DNSSEC > validation is going to sometimes need help making sure it gets DNSSEC data > to work from. So running the omnibroker just as a path discovery agent is > still valuable. > > But for the general consumer, they actually trust us to decide what programs > run on their machines at all. CertSentry, the Comodo Ombinbroker-like > application is currently bundled on the anti-virus product. The expectation > is that that Omnibroker will eventually replace the proprietary protocol in > CertSentry 1.0 to power the next generation. > > > -- > Website: http://hallambaker.com/ From viktor1dane@dukhovni.org Fri Jun 14 07: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 C674221F9CDE for ; Fri, 14 Jun 2013 07:36:13 -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 DtJdK4LA4UER for ; Fri, 14 Jun 2013 07:36:07 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id CFD2021F9A85 for ; Fri, 14 Jun 2013 07:36:04 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id E83FD2AB9DB; Fri, 14 Jun 2013 14:36:03 +0000 (UTC) Date: Fri, 14 Jun 2013 14:36:03 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130614143603.GO29420@mournblade.imrryr.org> References: <51B9C72E.2040706@inventati.org> <20130613191536.GL29420@mournblade.imrryr.org> <51BAC647.1060302@inventati.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51BAC647.1060302@inventati.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Combined TLSA TA (2 S M) and TLSA EE (1 S M) Usage 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, 14 Jun 2013 14:36:13 -0000 On Fri, Jun 14, 2013 at 12:29:11AM -0700, Bry8 Star wrote: > > You can stop there, the "above expectation" is unrealistic. > > Thanks for correction and lesson. Considering your recent posts to this list, I'd like to suggest that you consider spending a decade or so coming up to speed on the state of the art before posting to an IETF working group mailing list, i.e. an audience consisting largely of domain experts. I hate to be the bearer of bad news, nothing personal, but your posts are quite naive, and I would suggest that it is not a good use of the group's time to disabuse you of all misconceptions about TLS and DANE. Once this technology becomes mainstream, there will be user support forums for various products incorporating DANE, and you'll be able to ask your questions there. Good luck. -- Viktor. From bry8star@inventati.org Fri Jun 14 10:17:56 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 D971121F9D20 for ; Fri, 14 Jun 2013 10:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.874 X-Spam-Level: X-Spam-Status: No, score=-1.874 tagged_above=-999 required=5 tests=[AWL=0.725, 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 WdxyeAiS7UHA for ; Fri, 14 Jun 2013 10:17:56 -0700 (PDT) Received: from diserzione.investici.org (diserzione.investici.org [IPv6:2002:52dd:6399::1]) by ietfa.amsl.com (Postfix) with ESMTP id E058A21F9AF7 for ; Fri, 14 Jun 2013 10:17:55 -0700 (PDT) Received: from [82.221.99.153] (diserzione [82.221.99.153]) (Authenticated sender: bry8star@inventati.org) by localhost (Postfix) with ESMTPSA id 87016180EBF for ; Fri, 14 Jun 2013 17:17:49 +0000 (UTC) X-DKIM: Sendmail DKIM Filter v2.8.2 diserzione.investici.org 87016180EBF DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inventati.org; s=stigmate; t=1371230274; bh=YgSBoEB4JTt5Gk/7kIln9qN0RLSpTpEPMMQQvFcQgxw=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject:References: In-Reply-To:Content-Type; b=JLNktWgd2XWytEO6DT13c1etPATMjNwxujg2plDrtFz5WHzc9nhumAr/pfGndKfEb AdiIr+im8Qs504vlF5fuXhhhISrirMTJpkAtg/ksrGdt71WoI7pl3O/Hb46sKBJZ56 7goAn8t5UO/IOmyqNX+MGF+x2/j/qasaA3oFmvFs= Message-ID: <51BB5029.2080205@inventati.org> Date: Fri, 14 Jun 2013 10:17:29 -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: <51B9C72E.2040706@inventati.org> <20130613191536.GL29420@mournblade.imrryr.org> <51BAC647.1060302@inventati.org> <20130614143603.GO29420@mournblade.imrryr.org> In-Reply-To: <20130614143603.GO29420@mournblade.imrryr.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2THLPSTHGXXJMUXWOFTPT" Subject: Re: [dane] Combined TLSA TA (2 S M) and TLSA EE (1 S M) Usage 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: Fri, 14 Jun 2013 17:17:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2THLPSTHGXXJMUXWOFTPT Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I know, i'm not DNS expert at all. Mailing list is for DANE WG to communicate with other side. It is a public list. All type of users will come here to post their questions or problems or queries or suggestions or discussion or with other motives, when those not answered at other areas. Once mainstream, then there will be more helpful guides in other areas, then posting here will not be necessary. -- Bright Star. Received from Viktor Dukhovni, on 2013-06-14 7:36 AM: > On Fri, Jun 14, 2013 at 12:29:11AM -0700, Bry8 Star wrote: >=20 >>> You can stop there, the "above expectation" is unrealistic. >> >> Thanks for correction and lesson. >=20 > Considering your recent posts to this list, I'd like to suggest > that you consider spending a decade or so coming up to speed on > the state of the art before posting to an IETF working group mailing > list, i.e. an audience consisting largely of domain experts. >=20 > I hate to be the bearer of bad news, nothing personal, but your > posts are quite naive, and I would suggest that it is not a good > use of the group's time to disabuse you of all misconceptions about > TLS and DANE. >=20 > Once this technology becomes mainstream, there will be user support > forums for various products incorporating DANE, and you'll be able > to ask your questions there. Good luck. >=20 ------enig2THLPSTHGXXJMUXWOFTPT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJRu1AyAAoJEID2ikYfWSP6vQYQAIuOlOa7EK2bSnPK30+Q8mmE qq16oHDIcvrbE20KVVYmEDgzcMEKf/UByGFrcuIJATdhYmH7utMDYGGSyPtehxZd zjzptUBFrmy+RKknbV7tLytLvkaznOAJlLPlqVL3/raYfiIyF2Gf8Y8gjiWI2sFF 8yHdfksYwe1aro7RlqjyvbWduphOOva6V3lySSEOyydjcAb1d2jwrWOlX8X1+MdX 4fwy9OzxeDCtBubevwhKeLH1VmPxOKL6j2WwC0kkFAsb1SyB+aXl5pXTz8fgujmA 2a737ZmBhtTZ7G1fCg+xTdnck9ns5rnS8nFtyNUUujXsjB5HlSAQhQ88I8U3Wd5p 7JG8a7Egm9YOsD1n2kNMqE/z2dLMyFxeMk60GMyCi0evw5WXSnDUKp/PqThpy853 Afmm75IsVEWNl5AO+ENF62aAoZS5RwOFLdSh2wWjDC27E5aCpCT4bjhSNeyiP6Bj DANv8h75akP/QHGQEovxKeitMp6tVkiC1PyNUwNi2+UaWSa8XqcZPO+NofJfTWGu jxbnqI/I3ADXi6m3Zku2sWnljcO0ucN4oTeM5oQV1/EMmtN4XrtClncOA3sE5PY7 anoFqOAAsSIQmVeMY2uQhV3TpPxh5g4czGpNpqp3Pk6I4tNsa/7Ssg69+OLaYjPm W5znaD9DTQ5Ye3yn3J8n =bUE8 -----END PGP SIGNATURE----- ------enig2THLPSTHGXXJMUXWOFTPT-- From bry8star@inventati.org Fri Jun 14 13:00: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 2AD1A21F9BA7 for ; Fri, 14 Jun 2013 13:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.116 X-Spam-Level: X-Spam-Status: No, score=-2.116 tagged_above=-999 required=5 tests=[AWL=0.483, 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 3pVH44s2esHl for ; Fri, 14 Jun 2013 13:00:31 -0700 (PDT) Received: from diserzione.investici.org (diserzione.investici.org [IPv6:2002:52dd:6399::1]) by ietfa.amsl.com (Postfix) with ESMTP id C582F21F9B2D for ; Fri, 14 Jun 2013 13:00:29 -0700 (PDT) Received: from [82.221.99.153] (diserzione [82.221.99.153]) (Authenticated sender: bry8star@inventati.org) by localhost (Postfix) with ESMTPSA id CC35E180F94 for ; Fri, 14 Jun 2013 20:00:23 +0000 (UTC) X-DKIM: Sendmail DKIM Filter v2.8.2 diserzione.investici.org CC35E180F94 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inventati.org; s=stigmate; t=1371240027; bh=5jdJJyGZ00VKRtRqfC1DGnBCyNsmj7rG2PtY453/Tho=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject: Content-Type; b=JrGGIliV/zTx1mjttvFfKIhhTQUyCme5XkbFeg7VVnUe95I8Y3kc4PzKk+fiEJX8q w3LxKo7QWe/IHcG3RzZFk9w0E3F4Y7HtB+Bhd7kXU+IEYl/CkRxs/QSAiXcHiBAlWE xWMZZOTyi64mc04lpLFMeIRVDJGSIDrHYmeKm83I= Message-ID: <51BB7629.4070708@inventati.org> Date: Fri, 14 Jun 2013 12:59: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: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2RVXKTORSPMNLVNLNETFA" Subject: [dane] Pls Consider Supporting Intermediate TLS Certificate, TLSA Usage 4 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: Fri, 14 Jun 2013 20:00:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2RVXKTORSPMNLVNLNETFA Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Please consider to add support for Intermediate Authority TLSA RR Type. Please correct & improve below paragraphs. Thanks in advance. In RFC 6698 https://tools.ietf.org/html/rfc6698 Section 7.2 is showing list of TLSA Certificate Usages, 4-254 Unassigned. And showing "Applications to the registry can request specific values that have yet to be assigned." - - - - - - - - - - - - - - - 2.1.1. The Certificate Usage Field : TLSA Usage 4: Certificate usage 4 is used to specify one or more Intermediate Authority certificate, or the public key of such certificates, which MUST be used as intermediate trust anchor when validating the end entity certificate given by the server in TLS. This certificate usage is sometimes referred to as "intermediate trust anchors" (ITA) or "intermediate authority anchors" (IA). When TLSA Usage 2 is used for the domain, then TLSA Usage 4 allows domain name administrator to specify new, one or more intermediate trust anchors (ITA / IA). When TLSA Usage 0 is used, then TLSA Usage 4 allows to specify one or more pre-existing intermediate or subordinate CA. For example, TLSA Usage 4 is used when the domain issues its own one or more intermediate certificate under a CA or under a new Trust Anchor (TA) that may or may not exist in end user' collection of trust anchors. The target certificate MUST pass PKIX certification path validation, with any certificate matching the TLSA record considered to be a intermediate trust anchor for this certification path validation. - - - - - - - - - - - - - - - In RFC 6698 https://tools.ietf.org/html/rfc6698 Section 7.3 is showing list of TLSA Selectors, 2-254 Unassigned. And showing "Applications to the registry can request specific values that have yet to be assigned." - - - - - - - - - - - - - - - 2.1.2. The Selector Field: 64 -- Full Intermediate certificate: the (full) intermediate authority (IA) certificate, at level-1, which issued the End Entity certificate, MUST have selector value 64. The IA certificate at level-2 will use selector value 65 and third full IA will use selector value 66, and so on, upto 74. The Certificate binary structure as defined in [RFC5280] 128 -- SubjectPublicKeyInfo: the intermediate authority (IA) certificate, at level-1, which issued the End Entity certificate, MUST have selector value 128. The IA certificate at level-2 will use selector value 129 and third IA will use selector value 130, and so on, upto 138. DER-encoded binary structure as defined in [RFC5280] - - - - - - - - - - - - - - - So this will allow ( 74 - 64 =3D ) upto 10 intermediate trust anchors or intermediate CA. Selector values 64 - 74 are for FULL TLS certificates. And selector values 128 - 138 are for specifying intermediate certificate's SubjectPublicKeyInfo data portion. And quoting from Section A.1.2.2. : "Using the SubjectPublicKeyInfo selector for association with a certificate in a chain above I1 needs to be decided on a case-by-case basis: there are too many possibilities based on the issuing CA's practices. Unless the full implications of such an association are understood by the administrator, using selector type 0 is a better option from a security perspective." - - - - - - - - - - - - - - - And, using selector type from 64 to 74 for intermediate certificates, is a better option for declaring intermediate certificates. - - - - - - - - - - - - - - - And pls also consider to create such a section: - - - - - - - - - - - - - - - A.1.2.3. Selector Type 64-74 & 128-138 (Intermediate Certificate) For an example, if such certificate chain is used for a domain: EE <-- IA-B <-- IA-A <-- CA/TA. It can also be represented in this form: Level-0 <- Level-1 <- Level-2 <- Level-3. Then, TLSA RR examples: EE, end entity, Level-0 certificate: _443._tcp.www.example.com. IN TLSA ( 1 0 0 30820307308201efa003020102020... ) IA-B, second intermediate authority certificate, which signed the EE certificate, at level-1: _443._tcp.www.example.com. IN TLSA ( 64 0 0 30820454308202BC020900AB58D... ) IA-A, first intermediate authority certificate, at Level-2: _443._tcp.www.example.com. IN TLSA ( 127 0 0 8755CDAA8FE24EF16CC0F2C9180... ) TA root certificate, at Level-3: _443._tcp.www.example.com. IN TLSA ( 2 0 0 D2ABDE240D7CD3EE6B4B28C54DF... ) or, CA root certificate, at Level-3: _443._tcp.www.example.com. IN TLSA ( 0 0 0 D2ABDE240D7CD3EE6B4B28C54DF... ) - - - - - - - - - - - - - - - why such options were not added ? What pros and cons ? -- Bright Star. ------enig2RVXKTORSPMNLVNLNETFA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJRu3Y1AAoJEID2ikYfWSP6/4oQAIABvY7X9/St8jRpT3I3wsCt 6laQVcRyCMIi0DPOx7kijDieXVym+8r5sxRkHxISj0Fv5rEHvyJnWBarWkyVFGum 7Zm+wi31I853aS9ttmu0VrpgNIAvl170E++o22z357irchnC+1xFfPyWPMopta4k al9QIgU2gm1tSz0N9jDVzloIf2mTrqgVU3PCCawmLg2SuCLEUUcdp3WO4l+7TXIt eOtiDLqH0s3DS4tZWxLn1e+47E51l3jxKL0ZNLCGePxqjAbXTZr4dsJttzdMf51o 46UuvlCbwYTShukh0mm0i/KRklul/4s2j5kzekU4aogFO407w9hkyMPFBDXycQwy pjl3iPiJUjQz/cnZKQwtNOJMMUovviOXizpeEI8hbnlHRmTKYC4/6x3LHdvj8Pe2 BWGxk4CDICNvhP5wJPrPmCnLEaEmPEzBFYCYkvt+HqCc6i7b9b3sq3RzhMCwsigS q8yzL4p5X+XjOCI/U+GDyVGU8pYIwIQbKa0HSeQkd7XQcFT/tZ04JdcsExlefxag SGjRAUw1qLPm7jz9F2LmJKgiYtZC5G/LQMuZroDO18t+XnacwKoOdwlnNuYEC4cg cz6UNA7JpL751qhlwnl8e9bBh6uqcBRny7KugBsXMz7nMcrQdq9ux9YGM7yCQfKV cai1yJSM+NkGazuBlNBC =K1ph -----END PGP SIGNATURE----- ------enig2RVXKTORSPMNLVNLNETFA-- From viktor1dane@dukhovni.org Fri Jun 14 13:15: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 7A75021F9AA3 for ; Fri, 14 Jun 2013 13:15:57 -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 Byvfy+UVrwrV for ; Fri, 14 Jun 2013 13:15:42 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id AB1F521F9AA0 for ; Fri, 14 Jun 2013 13:15:42 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id A1EAA2ABA14; Fri, 14 Jun 2013 20:15:41 +0000 (UTC) Date: Fri, 14 Jun 2013 20:15:41 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130614201541.GR29420@mournblade.imrryr.org> References: <51BB7629.4070708@inventati.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51BB7629.4070708@inventati.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Pls Consider Supporting Intermediate TLS Certificate, TLSA Usage 4 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, 14 Jun 2013 20:15:59 -0000 On Fri, Jun 14, 2013 at 12:59:37PM -0700, Bry8 Star wrote: > Please consider to add support for Intermediate Authority TLSA RR Type. No such support is needed or forthcoming. DANE already supports intermediate CAs in usage 0 and usage 2 certificate associations. Perhaps the chairs can clarify whether this list is really for naive questions from the public at large or for working-group discussion and serious questions from implementors. If my view of the list charter is misguided, apologies to the OP. -- Viktor. From bry8star@inventati.org Fri Jun 14 13:42: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 2F14B21F9B0C for ; Fri, 14 Jun 2013 13:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.237 X-Spam-Level: X-Spam-Status: No, score=-2.237 tagged_above=-999 required=5 tests=[AWL=0.363, 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 Gi799rXXN6Dp for ; Fri, 14 Jun 2013 13:42:04 -0700 (PDT) Received: from diserzione.investici.org (diserzione.investici.org [IPv6:2002:52dd:6399::1]) by ietfa.amsl.com (Postfix) with ESMTP id 67D4121F9AE8 for ; Fri, 14 Jun 2013 13:42:04 -0700 (PDT) Received: from [82.221.99.153] (diserzione [82.221.99.153]) (Authenticated sender: bry8star@inventati.org) by localhost (Postfix) with ESMTPSA id 01765180FB6 for ; Fri, 14 Jun 2013 20:41:59 +0000 (UTC) X-DKIM: Sendmail DKIM Filter v2.8.2 diserzione.investici.org 01765180FB6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inventati.org; s=stigmate; t=1371242522; bh=ZqGFBckH09wipmvdfIfxwL4rJTbtUDBhgFdqH8Z0Qgc=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject:References: In-Reply-To:Content-Type; b=ks08MxdHUDDTsfdItxWlNP95k3pSMMQ0gZB2fa2cPx0PlcLg9PDaKdwgfP7kh9un0 kl6kBk4kjZFe56ssOffMSBsYbDAdfNsqQ3xjO5tsNhlh7P0Lo35zdVNl6V4n9zQLGx KlUSutg9Nw2YPD5bE/P7Sj0kRifHCti92isyHbeE= Message-ID: <51BB8001.8050004@inventati.org> Date: Fri, 14 Jun 2013 13:41: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 References: <51BB7629.4070708@inventati.org> In-Reply-To: <51BB7629.4070708@inventati.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2TFXKMCSNQBIJSVIOCWBG" Subject: Re: [dane] Pls Consider Supporting Intermediate TLS Certificate, TLSA Usage 4 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: Fri, 14 Jun 2013 20:42:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2TFXKMCSNQBIJSVIOCWBG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Just spotted one obvious mistake, see below in example area. Received from Bry8 Star, on 2013-06-14 12:59 PM: > Please consider to add support for Intermediate Authority TLSA RR Type.= >=20 =2E..... > Then, TLSA RR examples: >=20 > EE, end entity, Level-0 certificate: >=20 > _443._tcp.www.example.com. IN TLSA ( > 1 0 0 30820307308201efa003020102020... ) >=20 > IA-B, second intermediate authority certificate, which signed the EE > certificate, at level-1: >=20 > _443._tcp.www.example.com. IN TLSA ( > 64 0 0 30820454308202BC020900AB58D... ) >=20 > IA-A, first intermediate authority certificate, at Level-2: >=20 > _443._tcp.www.example.com. IN TLSA ( > 127 0 0 8755CDAA8FE24EF16CC0F2C9180... ) >=20 TLSA for Level-2 IA-A intermediate cert will be: =2E.. TLSA 65 0 0 ... >=20 >=20 > TA root certificate, at Level-3: >=20 > _443._tcp.www.example.com. IN TLSA ( > 2 0 0 D2ABDE240D7CD3EE6B4B28C54DF... ) >=20 > or, CA root certificate, at Level-3: >=20 > _443._tcp.www.example.com. IN TLSA ( > 0 0 0 D2ABDE240D7CD3EE6B4B28C54DF... ) > - - - - - - - - - - - - - - - >=20 =2E.. ------enig2TFXKMCSNQBIJSVIOCWBG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJRu4ATAAoJEID2ikYfWSP6fpQP/jVXVC+EkhD1Jn+xfIlpeQPM GiXN14Ixm8LXTHYcvB71h55NyVKtZ8lhWahwIPI0+vxzNrru7xwD4FHc2C34+rmk rn1sU7N/WTEd/M/hNg6/0qiJYDvE3cCqHcQyNifATGwgJk9ZWiYaY5WHPvmooeDU Tnbv2voocdIvn00XaKlQP53LPBwiNk3NFRoopP4JPbYel2tjIlgxWXxWzmlPZtg2 abxrPvJIpe10zx7VNTPTL4G8FRoAgakAFrxNON5U3YmyDFV/sEgTgo4BJABgdi7c 7KA+Huj4lwUsbLxMQdvK7519NpF9/NatoAebUfYtY9jk7gu8CzXIZVEBynDM06l5 zh1pCEO1kr5C/+blJ2rvkF02UKdrfTu9LIaQr4DwWtTSHnHQJZA/7VXyDUdxqaQm bfZ98RX9tA9E1b+hnX+dfUpripkvKGkN1qh2yhi3/LIGLh31JAvxBlRF56TPd0mt Mibkb5KmGYZ0ruUQJO319SyYbrYyCBtgaUIfMq6OdqgANGF+v182ggpZXoJJBcYY /nbEzv1dtj5ULd0UZsxSQkymBdb+g/XvDq2gB0cAYgLYjPDzamlYJDab43OU4/7x f0lvaODs8eizjLZs8H35oUUbe9XwIC33tMcJ+atogujRPFwpeXGXhBkfrQINPFR+ eYvzRScMaidHE7RopD6l =gDyo -----END PGP SIGNATURE----- ------enig2TFXKMCSNQBIJSVIOCWBG-- From warren@kumari.net Sat Jun 15 07:05: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 4372D21F9CC3 for ; Sat, 15 Jun 2013 07:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.125 X-Spam-Level: X-Spam-Status: No, score=-102.125 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abIiO-xpfH0l for ; Sat, 15 Jun 2013 07:05:31 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3D4021F9C7A for ; Sat, 15 Jun 2013 07:05:30 -0700 (PDT) Received: from [192.168.0.187] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id E49031B401F5; Sat, 15 Jun 2013 10:05:29 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_653DF4A6-34BB-4B35-AF1A-904852EDFC03"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Warren Kumari In-Reply-To: <51BB5029.2080205@inventati.org> Date: Sat, 15 Jun 2013 10:05:25 -0400 Message-Id: <98C0E5EE-BB9F-4E0B-AB9F-A5BED86B4125@kumari.net> References: <51B9C72E.2040706@inventati.org> <20130613191536.GL29420@mournblade.imrryr.org> <51BAC647.1060302@inventati.org> <20130614143603.GO29420@mournblade.imrryr.org> <51BB5029.2080205@inventati.org> To: Bry8 Star X-Mailer: Apple Mail (2.1503) Cc: dane@ietf.org Subject: Re: [dane] Combined TLSA TA (2 S M) and TLSA EE (1 S M) Usage X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 Jun 2013 14:05:35 -0000 --Apple-Mail=_653DF4A6-34BB-4B35-AF1A-904852EDFC03 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Ondrej wrote the below, and asked me to post if I agreed. As I'm posting = it=E2=80=A6 ----------------------------------------------------- Hi, On 14. 6. 2013, at 19:17, Bry8 Star wrote: > I know, i'm not DNS expert at all. And you are welcome to become one. > Mailing list is for DANE WG to communicate with other side Not exactly, the primary purpose of any IETF mailing is to be able to = work collectively on our charter contents: https://datatracker.ietf.org/wg/dane/charter/ That might include communication between people who create standards, = the people who implement the standard. We also welcome a feedback on = existing standards and new drafts where things are not clear for = implementors and educated users. Still this is list is not an user = support forum. > It is a public list. All type of users will come here to post their > questions or problems or queries or suggestions or discussion or > with other motives, when those not answered at other areas. Once > mainstream, then there will be more helpful guides in other areas, > then posting here will not be necessary. We welcome all kinds of contributors in the WG and their opinions, but = the IETF is standards body and you are required to have a little bit of = insight into used technologies. I might suggest any contributor should = spend some time reading the working group RFCs, drafts and the little = bit of the history of the mailing list. Also since your WG is related to DNS, TLS and PKI, you should at least = go read and understand the Normative References from our WG Documents, = e.g. Normative References from RFC 6394 and 6698, going recursive down = (e.g. doing the same with Normative References of Normative = References...). On the other hand any mailing lists subscriber has a right to ignore any = other subscriber's mails. The chairs will step-in only when the = contents of the emails will go off charter. Ondrej -- 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 ------------------------------------------- --------------------------------- > Received from Viktor Dukhovni, on 2013-06-14 7:36 AM: >> On Fri, Jun 14, 2013 at 12:29:11AM -0700, Bry8 Star wrote: >>=20 >>>> You can stop there, the "above expectation" is unrealistic. >>>=20 >>> Thanks for correction and lesson. >>=20 >> Considering your recent posts to this list, I'd like to suggest >> that you consider spending a decade or so coming up to speed on >> the state of the art before posting to an IETF working group mailing >> list, i.e. an audience consisting largely of domain experts. >>=20 >> I hate to be the bearer of bad news, nothing personal, but your >> posts are quite naive, and I would suggest that it is not a good >> use of the group's time to disabuse you of all misconceptions about >> TLS and DANE. >>=20 >> Once this technology becomes mainstream, there will be user support >> forums for various products incorporating DANE, and you'll be able >> to ask your questions there. Good luck. >>=20 >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- Credo quia absurdum est. --Apple-Mail=_653DF4A6-34BB-4B35-AF1A-904852EDFC03 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) iEYEARECAAYFAlG8dKgACgkQ/sGA6gkxszgGFgCeIxFL7MazxHJN+xmbsBZdiv2K ncQAoKdUOhSxzwBxS3UQuGlIa1gfZCrG =diuU -----END PGP SIGNATURE----- --Apple-Mail=_653DF4A6-34BB-4B35-AF1A-904852EDFC03-- From melinda.shore@gmail.com Sat Jun 15 12:16: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 8C5D321F9BBC for ; Sat, 15 Jun 2013 12:16: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 3NZtgIuW+WwE for ; Sat, 15 Jun 2013 12:16:12 -0700 (PDT) Received: from mail-pd0-f172.google.com (mail-pd0-f172.google.com [209.85.192.172]) by ietfa.amsl.com (Postfix) with ESMTP id BB58421F9BB3 for ; Sat, 15 Jun 2013 12:16:12 -0700 (PDT) Received: by mail-pd0-f172.google.com with SMTP id z10so1554686pdj.17 for ; Sat, 15 Jun 2013 12:16:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=tXZtBTDCHbRoaurKiiG6Sj90BXUQJ2/jkE85IXNIy24=; b=bYzLt/laEJ3lrvMPBJgbkLk4mTDGNGnkrL1NKLXu4LNR6Hd+M5nHPmcPjgjfMXMYHt sj4GSEu+uHRP+sBMg3Wr7rumRALEvQiXyz6/LWra+JoXYMJA5G8hNvOaaWbTcH5SYH4H DzA27ZjBVCKhNjX8vfGbi+NPbuCRulgp+Blovp1kaJdz50lA/kAWAY8Bm6OMr7tYvrV2 bZXPPpOeaKVEn1w2A9u10scko/9zXXTpNl4vVGHs7j7Tmuv3z9i+7iyknVILCUvNlGl4 OEwzWU+wHrmuFIKcQCxBiUUGxTbd2TUQBvAcNiYWQoDmygR3ZplBMz4uY/rfJ9vBiB6p ULZw== X-Received: by 10.67.21.226 with SMTP id hn2mr7263348pad.135.1371323772392; Sat, 15 Jun 2013 12:16:12 -0700 (PDT) Received: from spandex.local (66-230-82-15-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.82.15]) by mx.google.com with ESMTPSA id ty8sm7769557pac.8.2013.06.15.12.16.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 15 Jun 2013 12:16:11 -0700 (PDT) Message-ID: <51BCBD79.1040807@gmail.com> Date: Sat, 15 Jun 2013 11:16:09 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: dane@ietf.org References: <51B9C72E.2040706@inventati.org> <20130613191536.GL29420@mournblade.imrryr.org> <51BAC647.1060302@inventati.org> <20130614143603.GO29420@mournblade.imrryr.org> <51BB5029.2080205@inventati.org> <98C0E5EE-BB9F-4E0B-AB9F-A5BED86B4125@kumari.net> In-Reply-To: <98C0E5EE-BB9F-4E0B-AB9F-A5BED86B4125@kumari.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dane] Combined TLSA TA (2 S M) and TLSA EE (1 S M) Usage X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 Jun 2013 19:16:18 -0000 On 6/15/13 6:05 AM, Warren Kumari wrote: > Not exactly, the primary purpose of any IETF mailing is to be able to > work collectively on our charter contents: I agree completely with the substance of your post (IETF mailing lists are for progressing the work of the IETF), although I think it's certainly possible that what looks like a dumb question might actually be raising usability concerns. HOWEVER, the ad hominem nature of some of the comments here have been absolutely unacceptable. Those need to stop, and stop now. Melinda From warren@kumari.net Sun Jun 16 15:52:36 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 E087E21F896D for ; Sun, 16 Jun 2013 15:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.982 X-Spam-Level: X-Spam-Status: No, score=-101.982 tagged_above=-999 required=5 tests=[AWL=0.617, 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 v4MacVD2sZEY for ; Sun, 16 Jun 2013 15:52:31 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A06421F9B9B for ; Sun, 16 Jun 2013 15:52:27 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.90]) by vimes.kumari.net (Postfix) with ESMTPSA id 656811B40C49; Sun, 16 Jun 2013 18:52:17 -0400 (EDT) From: Warren Kumari Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 16 Jun 2013 18:52:15 -0400 Message-Id: <308BB18F-BB9B-4503-A8EF-53FEEACAD12A@kumari.net> To: "dane@ietf.org list" , Bry8 Star Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [dane] The DANE list and psudonmyms... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Jun 2013 22:52:37 -0000 Hi there, I suspect that this might be a contentious call, but I feel that it is = well within my rights as a chair. I have not spoken with my co-chair = about this, so if there is a kerfuffle / centi-thread on discuss@, it is = my fault :-P I would prefer that participants not use pseudonyms on the DANE list. As = an IETF participant contributions fall under the Note Well -- having = contributions coming from a name that is obviously a pseudonym "feels" = wrong, and I'm concerned about the IPR implications. Now, obviously fairly much all of the identities participating *could* = be pseudonyms (e.g has anyone seen John C. Klensin's drivers license / = passport?), but most of the participants / identities hare are known = (e.g. I know and have met the entry that uses the label Richard Barnes = -- no clue if that is his legal name, but I have no reason to suspect it = isn't). W -- "When it comes to glittering objects, wizards have all the taste and = self-control of a deranged magpie." -- Terry Pratchett From bry8star@inventati.org Sun Jun 16 23:04: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 759F621F99CE for ; Sun, 16 Jun 2013 23:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.309 X-Spam-Level: X-Spam-Status: No, score=-2.309 tagged_above=-999 required=5 tests=[AWL=0.290, 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 6g6dT4eoOk-n for ; Sun, 16 Jun 2013 23:04:19 -0700 (PDT) Received: from diserzione.investici.org (diserzione.investici.org [IPv6:2002:52dd:6399::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD8121F99CD for ; Sun, 16 Jun 2013 23:04:18 -0700 (PDT) Received: from [82.221.99.153] (diserzione [82.221.99.153]) (Authenticated sender: bry8star@inventati.org) by localhost (Postfix) with ESMTPSA id D54E118025A for ; Mon, 17 Jun 2013 06:04:11 +0000 (UTC) X-DKIM: Sendmail DKIM Filter v2.8.2 diserzione.investici.org D54E118025A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inventati.org; s=stigmate; t=1371449055; bh=ozwWxewexF8fS862U83zzluB4SGDNwAU00lbZtTkS+o=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject:References: In-Reply-To:Content-Type; b=tfbKWV4VBJd8MFP+DIlGyjUDVNhqdVidgMH7K6LhgfG7diffAKObZe0YTZlCJsPT0 s93RwCFXHrm1r2ZxnLMpO5bWRVrAhuAkiG5grsafTicSCminFo814oDM53U02s8XGC R3/WVsGkjDO791WMDyrFvWQuSiU68b6ubBIrNxv8= Message-ID: <51BEA6C4.5090005@inventati.org> Date: Sun, 16 Jun 2013 23:03:48 -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: <51B9C72E.2040706@inventati.org> <20130613191536.GL29420@mournblade.imrryr.org> <51BAC647.1060302@inventati.org> <20130614143603.GO29420@mournblade.imrryr.org> <51BB5029.2080205@inventati.org> <98C0E5EE-BB9F-4E0B-AB9F-A5BED86B4125@kumari.net> <51BCBD79.1040807@gmail.com> In-Reply-To: <51BCBD79.1040807@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2EAHVBLPHVLGWGBWKCLCH" Subject: Re: [dane] Combined TLSA TA (2 S M) and TLSA EE (1 S M) Usage 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: Mon, 17 Jun 2013 06:04:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2EAHVBLPHVLGWGBWKCLCH Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks again for very valuable helpful directions. That is what i partially expected, thanks. I expected you will outline your guidance far more clearly with clear reference readings to reach solve/solution. That you understand user's condition/state/nature and GUIDE them to correct path. I would like to request to think, think about: [1] What is the percentage of users who are building the standard for DANE ? and the percent who are standardizing DNSSEC ? for whom ? [2] Whats the percentage of users who are software developers who are implementing DANE in software ? and percent who are implementing DNSSEC in software ? [3] Whats the percentage, of users who are domain-name owners, who are dns-operators/domain-operators/system-administrators/etc ? The last one in above, clearly & obviously have far more numbers, than any others. So, please ALSO focus on them ... how you can make direction easy for such vast groups of users. Standards have already described directions for software developers. I'm in every major project (in various forum, mailing-list, irc-channels), i asked them and i have seen others asking as well, how can this/that DANE related settings or DNSSEC related, etc in software can be implemented ? ... most have no clue, or partial & old knowledge ! I asked in other related forums/list/etc areas : as domain-name owner, as dns/domain operator which steps can be done & taken to assist in adoption of DNSSEC & DANE ? the answer is again, and far more negative & ignorant than even some developers or developers-related groups ! Since I've started post here in this WG mailing-list, if anyone noticed, they should find, i tried to ask some of the SAME question what others (including me) already asked in other channels, forums, list. So that those users can read to find at-least some helpful solution. Which I'm observing, no one responding properly or incomplete, or with other un-helpful additions & discouragement ! What is the purpose ? Not that my own posting are without errors, i have lot of mistakes, and I'm requesting others to correct the mistakes/errors. So, what am i to conclude ? that this mailing-list members have far more important things to do, than helping out or guiding, majority of users who are domain-name owners, dns-operators / dns-administrators / system-administrators etc ? ! ! ! Those important things have resulted into what help or what type of help for DNS-Administrators ? ? Why DNS-administrators are saying the do not have enough correct example or information yet to do DANE ! ? And, I'm beginning to think, many here will continue to ignore these questions, and/or, continue to say/response something else other than a real solution ! -- Bright Star. ------enig2EAHVBLPHVLGWGBWKCLCH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJRvqbRAAoJEID2ikYfWSP665gP/1GD36D4y9bhqjJnNkGb0cb7 WhAM6lhS4DAkKa48iMoSyPBUwZKRNS4XVbm2P2eVykk6anFaWrQO87rdGvlruHQA rbd0A11nRs7qdqZCFD1Dl/LCkXSsV2uPw61eqNI3Q46pgs1c+TBuk5D8NmgS4OpA aOchLkkRK3e8p8Gzf3RviRv4SQWbU2QzVX3Mb62x/h6ue3qQ46pA1O7vc91ZYKH/ AgJqTC+7B0bRmuMfg89UMDCEcD6KN3qGsFkkccilO0EuGs8Bi7+DjDWcgljuSGNd USrz47XixFbtXk8KbUejoOTUIOT2akCr34MWuvPG/eMvvh5pMV6mzteLgJLmZIzc paYfunfvk3V5N5wHDx6cyjt4t85YtpDp+OJA+QnpdWX5VISsOqrzOpePfvmHOafW Any4xhbDC5IJAiS2dfg3G5SllwgG4PRrhF+rtnBHYbv7NzlzhCbPPRqAWDaYOBKn EMapfxkSa2DuBp+aWkSPyeQuYuRhJ+bkbtADzjwPolJyo6ei5Ys8zYvpbrKFZzF6 LhfozJ7L5KvOlNUKmxM3lMnQ1pRC4aVzva8tL+4ko8CnAVgDF+bDe6BjSRSIpxLv aUArbC8EhKR7MsXGkcUmN7krWytR88tp6vxAK47UqQDWwLmXV5PjGnv4ll2JESPS DXuCg4vYw3MlhTeR1cPh =xedd -----END PGP SIGNATURE----- ------enig2EAHVBLPHVLGWGBWKCLCH-- From dane.list@iswho.me Sun Jun 16 23:52:14 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 5335B21F9A92 for ; Sun, 16 Jun 2013 23:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h977-6D12ySc for ; Sun, 16 Jun 2013 23:52:10 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id EC1C421F9A91 for ; Sun, 16 Jun 2013 23:52:09 -0700 (PDT) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id E1EE520815; Mon, 17 Jun 2013 02:52:07 -0400 (EDT) Received: from web1.nyi.mail.srv.osa ([10.202.2.211]) by compute2.internal (MEProxy); Mon, 17 Jun 2013 02:52:07 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=iswho.me; h= message-id:from:to:mime-version:content-transfer-encoding :content-type:subject:date:in-reply-to:references; s=mesmtp; bh= 6c1FIRU6xToQ2ix2Mq7Kd3hkYyA=; b=FXRq90U0dM6+9SLdK5xQOqOnerYsKyAZ OYFR+ROmeseNLrHJjaOuaQ4IFKUmWm2wYy+iLvmsgKeS0ULyPXU5DFvPDN0CAxvX SNHQYQEbrCjmSlVqtL5hx4ODb73HrLwZVsmZKci+Z1eUi/Hdn5MfPTPj3ddb3M66 tk0++O9QcjY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:subject:date:in-reply-to :references; s=smtpout; bh=6c1FIRU6xToQ2ix2Mq7Kd3hkYyA=; b=d4np1 +n/L+61YARbmb8xuEbbHTky4AOLmqTp5eOGDAJABI9iFHcBBQSnWbKt5xLha0K/y C17bqJfLM4HWMEc4maP+SYVp29UZuwWYCvybDn7rmuc7G6dlnG+g+EAgdtJP6KKT nrtcfezf/fyQR/5QuAwgvMgFFYXgA0b8u1F/Vc= Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99) id B6F5FF00E7F; Mon, 17 Jun 2013 02:52:07 -0400 (EDT) Message-Id: <1371451927.13192.140661244738717.6F4EF3D6@webmail.messagingengine.com> X-Sasl-Enc: 6GazIlp6R2nGTnnxUn+veHxrqNlbaUDevZFANNz4lR8W 1371451927 From: DANE To: Warren Kumari , dane@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - html Date: Mon, 17 Jun 2013 08:52:07 +0200 In-Reply-To: <308BB18F-BB9B-4503-A8EF-53FEEACAD12A@kumari.net> References: <308BB18F-BB9B-4503-A8EF-53FEEACAD12A@kumari.net> Subject: Re: [dane] The DANE list and psudonmyms... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jun 2013 06:52:14 -0000 On Mon, Jun 17, 2013, at 12:52 AM, Warren Kumari wrote: > Hi there, > > I suspect that this might be a contentious call, but I feel that it is > well within my rights as a chair. I have not spoken with my co-chair > about this, so if there is a kerfuffle / centi-thread on discuss@, it is > my fault :-P > > I would prefer that participants not use pseudonyms on the DANE list. As > an IETF participant contributions fall under the Note Well -- having > contributions coming from a name that is obviously a pseudonym "feels" > wrong, and I'm concerned about the IPR implications. > > Now, obviously fairly much all of the identities participating *could* be > pseudonyms (e.g has anyone seen John C. Klensin's drivers license / > passport?), but most of the participants / identities hare are known > (e.g. I know and have met the entry that uses the label Richard Barnes -- > no clue if that is his legal name, but I have no reason to suspect it > isn't). So basically you're saying that as long as a name appears to be a real one then it's okay, whilst anything that obviously isn't a real name is not ? How will that judgement be made ? If for example someone called 'Poo Ann Wee' from Singapore registers how will you tell if it's fake or not ? Closed Shops have been illegal in the UK since 1990 btw ;) http://en.wikipedia.org/wiki/Closed_Shop n> From olaf@NLnetLabs.nl Mon Jun 17 01:05: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 214DE21F874E for ; Mon, 17 Jun 2013 01:05:24 -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 75ZYQmUsyBQa for ; Mon, 17 Jun 2013 01:05:21 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id A4C0621F99EC for ; Mon, 17 Jun 2013 01:04:51 -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 r5H84HBE012628 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 17 Jun 2013 10:04:18 +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 r5H84HBE012628 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1371456290; bh=EG7L8yLuaA3u+/XrQp2Qj3EsKE3hhahznZQqRrFuudo=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=BpV43scCA7JK/7ykRVGzOF3XruJtGHiUwHjX5YH+YpFxoI7B9ohXcuBb2YK/t3pEQ nA+XiTGigO/t12FvtE66HB/4l9BXYn8GdBH6KBmljWl6CVRrmQBDFuyhhJ43E/wwkR URe8QxP+VYs0Jiq9Z1PVVlTXCQnovZJRBCSCr0hA= Content-Type: multipart/alternative; boundary="Apple-Mail=_500F846B-2DDC-46AD-8CC3-B5B3C5EF86CC" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Olaf Kolkman In-Reply-To: <1371451927.13192.140661244738717.6F4EF3D6@webmail.messagingengine.com> Date: Mon, 17 Jun 2013 10:04:17 +0200 Message-Id: <98344CE3-075E-4C77-8B60-4B42A05485D6@NLnetLabs.nl> References: <308BB18F-BB9B-4503-A8EF-53FEEACAD12A@kumari.net> <1371451927.13192.140661244738717.6F4EF3D6@webmail.messagingengine.com> To: DANE X-Mailer: Apple Mail (2.1508) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Mon, 17 Jun 2013 10:04:19 +0200 (CEST) Cc: dane@ietf.org Subject: Re: [dane] The DANE list and psudonmyms... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jun 2013 08:05:27 -0000 --Apple-Mail=_500F846B-2DDC-46AD-8CC3-B5B3C5EF86CC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 17, 2013, at 8:52 AM, DANE wrote: > On Mon, Jun 17, 2013, at 12:52 AM, Warren Kumari wrote: >> Hi there, >>=20 >> I suspect that this might be a contentious call, but I feel that it = is >> well within my rights as a chair. I have not spoken with my co-chair >> about this, so if there is a kerfuffle / centi-thread on discuss@, it = is >> my fault :-P >>=20 >> I would prefer that participants not use pseudonyms on the DANE list. = As >> an IETF participant contributions fall under the Note Well -- having >> contributions coming from a name that is obviously a pseudonym = "feels" >> wrong, and I'm concerned about the IPR implications. >>=20 >> Now, obviously fairly much all of the identities participating = *could* be >> pseudonyms (e.g has anyone seen John C. Klensin's drivers license / >> passport?), but most of the participants / identities hare are known >> (e.g. I know and have met the entry that uses the label Richard = Barnes -- >> no clue if that is his legal name, but I have no reason to suspect it >> isn't). >=20 > So basically you're saying that as long as a name appears to be a real > one then it's okay, whilst anything that obviously isn't a real name = is > not ? How will that judgement be made ? If for example someone called > 'Poo Ann Wee' from Singapore registers how will you tell if it's fake = or > not ?=20 >=20 > Closed Shops have been illegal in the UK since 1990 btw ;) > http://en.wikipedia.org/wiki/Closed_Shop I can't speak for Warren. But IMHO we have to keep the Note-Well = seriously. If folk contribute technology to the IETF it would be could = if we (collectively) have a reasonable idea who those folk are. It would be very painful if in the future I'd be implementing technology = that was brought to the IETF by john.doe@pseudonymous.example and I = found I was being sued by a very real legal entity by infringing their = patents. It is off course not the case that everybody has to know everybody but = if we _collectively_ do not know who is behind dane.list@iswho.me then I = start to feel uncomfortable about using the technology, specifically if = the contributions are highly innovative and competent and thus = patentable. For debates like this, or any other process issue, I really do not care = if you use Pseudonyms or not[*]. --Olaf Kolkman NLnet Labs PS. As many people on the DANE list will appreciate this is not a = technical issue but a trust issue. I am not proposing mechanisms that = involve authentications, I-Ds and what have you but I personally would = appreciate people to be forthcoming. [*] I know that bert@secret-wg.org has commented on some IETF = discussions in the past. --Apple-Mail=_500F846B-2DDC-46AD-8CC3-B5B3C5EF86CC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii dane.list@iswho.me> = wrote:

Hi there,

I suspect that this = might be a contentious call, but I feel that it is
well within my = rights as a chair. I have not spoken with my co-chair
about this, so = if there is a kerfuffle / centi-thread on discuss@, it is
my fault = :-P

I would prefer that participants not use pseudonyms on the = DANE list. As
an IETF participant contributions fall under the Note = Well -- having
contributions coming from a name that is obviously a = pseudonym "feels"
wrong, and I'm concerned about the IPR = implications.

Now, obviously fairly much all of the identities = participating *could* be
pseudonyms (e.g has anyone seen John C. = Klensin's drivers license /
passport?), but most of the participants = / identities hare are known
(e.g. I know and have met the entry that = uses the label Richard Barnes --
no clue if that is his legal name, = but I have no reason to suspect it
isn't).

one then it's okay, whilst anything = that obviously isn't a real name is
not ? How will that judgement = be made ? If for example someone called
'Poo Ann Wee' from Singapore = registers how will you tell if it's fake or
 
Closed Shops have been illegal in the = UK since 1990 btw ;)
john.doe@pseudonymous.exampl= e and I found I was being sued by a very real legal entity by = infringing their patents.

It is off course not = the case that everybody has to know everybody but if we _collectively_ = do not know who is behind dane.list@iswho.me then I start = to feel uncomfortable about using the technology, specifically if the = contributions are highly innovative and competent and thus = patentable.

For debates like this, or any other = process issue, I really do not care if you use Pseudonyms or = not[*].


--Olaf = Kolkman
  NLnet = Labs


PS. As many people on the = DANE list will appreciate this is not a technical issue but a trust = issue. I am not proposing mechanisms that involve authentications, I-Ds = and what have you but I personally would appreciate people to be = forthcoming.



[*] = I know that bert@secret-wg.org = has commented on some IETF discussions in the = past.

= --Apple-Mail=_500F846B-2DDC-46AD-8CC3-B5B3C5EF86CC-- From viktor1dane@dukhovni.org Mon Jun 17 01:16: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 347AB21F9AEB for ; Mon, 17 Jun 2013 01:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=-0.241, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, 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 Hh2bdcesVK5P for ; Mon, 17 Jun 2013 01:16:17 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id D1B9C21F9AB8 for ; Mon, 17 Jun 2013 01:16:12 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 9AE1D2AAA00; Mon, 17 Jun 2013 08:16:09 +0000 (UTC) Date: Mon, 17 Jun 2013 08:16:09 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130617081609.GF29420@mournblade.imrryr.org> References: <51B9C72E.2040706@inventati.org> <20130613191536.GL29420@mournblade.imrryr.org> <51BAC647.1060302@inventati.org> <20130614143603.GO29420@mournblade.imrryr.org> <51BB5029.2080205@inventati.org> <98C0E5EE-BB9F-4E0B-AB9F-A5BED86B4125@kumari.net> <51BCBD79.1040807@gmail.com> <51BEA6C4.5090005@inventati.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Dx9iWuMxHO1cCoFc" Content-Disposition: inline In-Reply-To: <51BEA6C4.5090005@inventati.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Combined TLSA TA (2 S M) and TLSA EE (1 S M) Usage 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, 17 Jun 2013 08:16:26 -0000 --Dx9iWuMxHO1cCoFc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Jun 16, 2013 at 11:03:48PM -0700, Bry8 Star wrote: > how you can make direction easy for such vast groups of users. A fair question. I won't attempt to explain how to operate a DNSSEC signed zone here, sadly this is still rather complex, since DNSSEC signed zones need to be frequently and automatically resigned, and rotating the KSK DS records in registries is harder still. If that's part of your question, perhaps someone else is willing to tackle this rather weighty topic, maybe on a DNSSEC list, if not here. So let's assume that you've somehow crossed the hurdle of implementing DNSSEC. Let's also assume that you have some TLS-enabled service on TCP port 12345 of host mumble.example.com and you want to publish DANE TLSA records for this host. The certificate association portion of a TLSA record contains binary data that is usually presented in hexadecimal form for ease of entry into zone files. The underlying binary data is either: - A complete X.509 certificate in DER form (IN TLSA X 0 0 ...) - A complete SPKI public-key in DER form (IN TLSA X 1 0 ...) - A binary SHA-256 digest of one of the above (IN TLSA X Y 1 ...) - A binary SHA-512 digest of one of the above (IN TLSA X Y 2 ...) where "X" is the certificate usage. When X is 0 or 2, the certificate association publishes a property of a root or intermediate CA that (possibly through a chain of intermediate CAs) ultimately issued the certificate of mumble.example.com. When X is 1 or 3, the certificate association publishes a property of the actual certificate whose public key is the public key of mumble.example.com. Whether you choose X = 0, 1, 2 or 3 is - part operational considerations (who updates the DNS in your organization, how often are server keys rotated, ...). Do you optimize for robustness in the face of buggy client implementations (simpler is better, and nothing is simpler than X=3) or robustness in the face of lazy operators who neglect to coordinate key rollover with DNS updates (X=0 or 2 requires less work for the DNS operator). - part application considerations, is the client pre-configured with a suitable list of trusted CAs? Does the client have a secure way to determine the service hostname (mumble.example.com), ... - part security considerations? Which risks do you want to mitigate? DNSSEC zone signingkey compromises? Rogue public CAs? Server key compromises? Do your clients consult CA revocation lists? How often are these lists updated? How quickly can you publish a revocation? ... - part PKI politics. Does your organization fervently believe in either of the two PKI models (public CAs or DANE) and distance itself from the other? Keep in mind that when keys change some clients will have older DNSSEC records in their caches, so you may need to publish both the old and the new association values when transitioning between and old and a new certificate (be it a CA or a server certificate). DANE validation will work provided at least association matches. All that remains is to generate the association data. If using OpenSSL (1.0.0 or later) with the relevant certificate in a pem format file any given TLSA record is obtained by running something like the attached shell script. $ ./tlsagen cert.pem mumble.example.com:12345 3 1 1 _12345._tcp.mumble.example.com. IN TLSA 3 1 1 7602662AD394EE1C74D5926454199D3F02C352BA4073E8C87942802277C6D4AA The shell script can be improved to detect more error conditions, so should only be used interactively with the user paying attention to any error messages that may indicate that the output is not usable. The corresponding certificate from which the above output was obtained is: -----BEGIN CERTIFICATE----- MIIBfDCCASKgAwIBAgIBATAKBggqhkjOPQQDAjAAMB4XDTEzMDYxNzA4MDMyNloX DTEzMDcxNzA4MDMyNlowADBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABGa/jQyV hYKu8iEYBuwe+3uyg7iWYNXaAEaX7TLqASVWqCYtXUrFNPVFFHQd2Fb1rLG3WzIV J4RVvFNCyblI3nSjgYwwgYkwCQYDVR0TBAIwADAdBgNVHSUEFjAUBggrBgEFBQcD AQYIKwYBBQUHAwIwHQYDVR0OBBYEFKGA1nZ0MpriCZlTGEap0CGlFuBcMB8GA1Ud IwQYMBaAFKGA1nZ0MpriCZlTGEap0CGlFuBcMB0GA1UdEQQWMBSCEm11bWJsZS5l eGFtcGxlLmNvbTAKBggqhkjOPQQDAgNIADBFAiEA2PR+JLO51F5Ehg6YQRtJJCal yEAp3M6y5ggRJTE+ZbQCIFlFJYanOkiURTrqbYwsS/kHkJ4jbfFvY+K96UDVZcXh -----END CERTIFICATE----- You should be able to reproduce all the combinations (the choice of usage has no effect on the rest of the record, but must match the role of the selected certificate file). $ for m in 1 2 0; do for s in 1 0; do ./tlsagen cert.pem mumble.example.com:12345 3 $s $m done; done _12345._tcp.mumble.example.com. IN TLSA 3 1 1 7602662AD394EE1C74D5926454199D3F02C352BA4073E8C87942802277C6D4AA _12345._tcp.mumble.example.com. IN TLSA 3 0 1 1C9621235642558FE24EF79A154617FB134D1E0F4549DECD2FF7168463E27AB4 _12345._tcp.mumble.example.com. IN TLSA 3 1 2 D578D8B9970A0CDEE928CE306BDCBC115CBB4B36FACD370C85F1F6036FE56F44B4CCEA3FC232B3BD840A719410F4D50F33D96A2A11CBE2BE05F8846A6ECA3715 _12345._tcp.mumble.example.com. IN TLSA 3 0 2 1CD33094C61030BAD34FCAB6EBA37B225F82694A3097E2DF01E179B14079B4BD54B64B5CC8A5482037EB4A6CD9EC7173157E7F2E37896BE0414D650D3BFFA2BE _12345._tcp.mumble.example.com. IN TLSA 3 1 0 3059301306072A8648CE3D020106082A8648CE3D0301070342000466BF8D0C958582AEF2211806EC1EFB7BB283B89660D5DA004697ED32EA012556A8262D5D4AC534F54514741DD856F5ACB1B75B3215278455BC5342C9B948DE74 _12345._tcp.mumble.example.com. IN TLSA 3 0 0 3082017C30820122A003020102020101300A06082A8648CE3D0403023000301E170D3133303631373038303332365A170D3133303731373038303332365A30003059301306072A8648CE3D020106082A8648CE3D0301070342000466BF8D0C958582AEF2211806EC1EFB7BB283B89660D5DA004697ED32EA012556A8262D5D4AC534F54514741DD856F5ACB1B75B3215278455BC5342C9B948DE74A3818C30818930090603551D1304023000301D0603551D250416301406082B0601050507030106082B06010505070302301D0603551D0E04160414A180D67674329AE20999531846A9D021A516E05C301F0603551D23041830168014A180D67674329AE20999531846A9D021A516E05C301D0603551D110416301482126D756D626C652E6578616D706C652E636F6D300A06082A8648CE3D0403020348003045022100D8F47E24B3B9D45E44860E98411B492426A5C84029DCCEB2E6081125313E65B4022059452586A73A4894453AEA6D8C2C4BF907909E236DF16F63E2BDE940D565C5E1 -- Viktor. --Dx9iWuMxHO1cCoFc Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=tlsagen #! /bin/sh error() { echo "$1" 1>&2; exit 1; } usage() { error "Usage: $0 file.pem host[:port] usage selector mtype"; } extract() { case "$2" in 0) openssl x509 -in "$1" -outform DER;; 1) openssl x509 -in "$1" -noout -pubkey | openssl pkey -pubin -outform DER;; *) error "Invalid selector: $2";; esac } digest() { case "$1" in 0) cat;; 1) openssl dgst -sha256 -binary;; 2) openssl dgst -sha512 -binary;; *) error "Invalid matching type: $1";; esac } encode() { perl -e ' ($hostport, $u, $s, $m) = @ARGV; ($host, $port) = split(":", $hostport); $port ||= 443; $/=undef; ($a=) =~ s/(.)/sprintf("%02X", ord($1))/egs; printf "_%d._tcp.%s. IN TLSA %d %d %d %s\n", $port, $host, $u, $s, $m, $a; ' "$1" "$2" "$3" "$4" } if [ $# -ne 5 ]; then usage; fi; c=$1; h=$2; u=$3; s=$4; m=$5 case "$u" in [0123]) : ;; *) error "Invalid certificate usage: $u";; esac extract "$c" "$s" | digest "$m" | encode "$h" "$u" "$s" "$m" --Dx9iWuMxHO1cCoFc-- From dane.list@iswho.me Mon Jun 17 01:24: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 2EAB021F9B41 for ; Mon, 17 Jun 2013 01:24:25 -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 HA10Xek2FCpp for ; Mon, 17 Jun 2013 01:24:20 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id C4C1321F9B31 for ; Mon, 17 Jun 2013 01:24:14 -0700 (PDT) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 191B02097B; Mon, 17 Jun 2013 04:24:11 -0400 (EDT) Received: from web1.nyi.mail.srv.osa ([10.202.2.211]) by compute4.internal (MEProxy); Mon, 17 Jun 2013 04:24:12 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=iswho.me; h= message-id:from:to:cc:mime-version:content-transfer-encoding :content-type:in-reply-to:references:subject:date; s=mesmtp; bh= H8E4PVRYoMD4MeMMnUPLeumxNlk=; b=Ea4/pjYq3QMOO8aHvwN9wUvu84bf0FNn XqNrCfoWIHU4+wlmmHZNSQajAxkPuW6/i0x6I/5OWBhZI8KnqpB7+7EolZwk6GMZ cSjHE0PUnnYtcaU38CMKbBsq012uM5zvwLE25qpXkqllwzfr4f3//N4kRqfp0PUu xBER9+0yZWo= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:cc:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=H8E4PVRYoMD4MeMMnUPLeumxNlk=; b=e7N 2ORabR91xTFs4y4SgbLzqoeKec6m6Rtu8j6rquYXbXY4OmSKhDA2wExjSYffPHFJ 7gZtpLx4+VS+IDGIpjKhqDcR+ZHnPrNlNmCDd1zShqZ7s6+DQvzDVAYCr7PXvlO1 xEqLuJQycGdqTZlXXVTtvuoTH4fSIJrRnE8w2/Kg= Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99) id 3B8F6F00E7F; Mon, 17 Jun 2013 04:24:11 -0400 (EDT) Message-Id: <1371457451.799.140661244763961.79AC933D@webmail.messagingengine.com> X-Sasl-Enc: 0tP+24qVvilBzum2fmWvEreJDsmoavr9NB82u961/e11 1371457451 From: DANE To: Olaf Kolkman MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - html In-Reply-To: <98344CE3-075E-4C77-8B60-4B42A05485D6@NLnetLabs.nl> References: <308BB18F-BB9B-4503-A8EF-53FEEACAD12A@kumari.net> <1371451927.13192.140661244738717.6F4EF3D6@webmail.messagingengine.com> <98344CE3-075E-4C77-8B60-4B42A05485D6@NLnetLabs.nl> Date: Mon, 17 Jun 2013 10:24:11 +0200 Cc: dane@ietf.org Subject: Re: [dane] The DANE list and psudonmyms... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jun 2013 08:24:25 -0000 On Mon, Jun 17, 2013, at 10:04 AM, Olaf Kolkman wrote: > > So basically you're saying that as long as a name appears to be a real > > one then it's okay, whilst anything that obviously isn't a real name is > > not ? How will that judgement be made ? If for example someone called > > 'Poo Ann Wee' from Singapore registers how will you tell if it's fake or > > not ? > > > > Closed Shops have been illegal in the UK since 1990 btw ;) > > http://en.wikipedia.org/wiki/Closed_Shop > > I can't speak for Warren. But IMHO we have to keep the Note-Well > seriously. If folk contribute technology to the IETF it would be could if > we (collectively) have a reasonable idea who those folk are. > > It would be very painful if in the future I'd be implementing technology > that was brought to the IETF by john.doe@pseudonymous.example and I found > I was being sued by a very real legal entity by infringing their patents. > > It is off course not the case that everybody has to know everybody but if > we _collectively_ do not know who is behind dane.list@iswho.me then I > start to feel uncomfortable about using the technology, specifically if > the contributions are highly innovative and competent and thus > patentable. > > For debates like this, or any other process issue, I really do not care > if you use Pseudonyms or not[*]. > > > --Olaf Kolkman > NLnet Labs > > > PS. As many people on the DANE list will appreciate this is not a > technical issue but a trust issue. I am not proposing mechanisms that > involve authentications, I-Ds and what have you but I personally would > appreciate people to be forthcoming. > > > > [*] I know that bert@secret-wg.org has commented on some IETF discussions > in the past. So if it's trust you want then I guess we'll need to find an anchor for that. Trusted domain names, people's real names, now where have I heard that stuff before... Oh, let's have a new DNS RRTYPE 0wnr Is this a technical discussion now ? n> From olaf@NLnetLabs.nl Mon Jun 17 01:38: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 AB5C321F9AEF for ; Mon, 17 Jun 2013 01:38:40 -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 kgFZy7YHluSP for ; Mon, 17 Jun 2013 01:38:39 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5000921F9AAE for ; Mon, 17 Jun 2013 01:38:38 -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 r5H8cYML080592 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 17 Jun 2013 10:38:36 +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 r5H8cYML080592 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1371458317; bh=uxMTc9Wi405neQAJu1QxYKGUNfkSz4s+8K2T2Zd7pAM=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=ocPKfOUIXrkVJ33ayvcN+jalChNq8no1YiF/Aez3exvLskWHge5yx5Cz/WOXgUmk0 sVoNq/uh2uCApNknOaA7kS6alJcS7QbBrVHIFClKMtG7zK42Rrq6obCaYQ6kJzPjw/ TD1ReeyPvZx0U0dFzaXy+jDZivHtRy9B7D/LnKDE= Content-Type: multipart/alternative; boundary="Apple-Mail=_50C3FB38-154E-40B3-9EFE-9DD0A3BF5588" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Olaf Kolkman In-Reply-To: <1371457451.799.140661244763961.79AC933D@webmail.messagingengine.com> Date: Mon, 17 Jun 2013 10:38:34 +0200 Message-Id: References: <308BB18F-BB9B-4503-A8EF-53FEEACAD12A@kumari.net> <1371451927.13192.140661244738717.6F4EF3D6@webmail.messagingengine.com> <98344CE3-075E-4C77-8B60-4B42A05485D6@NLnetLabs.nl> <1371457451.799.140661244763961.79AC933D@webmail.messagingengine.com> To: DANE X-Mailer: Apple Mail (2.1508) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Mon, 17 Jun 2013 10:38:36 +0200 (CEST) Cc: dane@ietf.org Subject: Re: [dane] The DANE list and psudonmyms... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jun 2013 08:38:40 -0000 --Apple-Mail=_50C3FB38-154E-40B3-9EFE-9DD0A3BF5588 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 17, 2013, at 10:24 AM, DANE wrote: >> PS. As many people on the DANE list will appreciate this is not a >> technical issue but a trust issue. I am not proposing mechanisms that >> involve authentications, I-Ds and what have you but I personally = would >> appreciate people to be forthcoming. >> [...] > So if it's trust you want then I guess we'll need to find an anchor = for > that. Trusted domain names, people's real names, now where have I = heard > that stuff before... >=20 I had hoped that that sense of irony came through in the first line of = the PS. > Oh, let's have a new DNS RRTYPE 0wnr > Is this a technical discussion now ? Nope, I believe this is a serious issue that can be solve when people = are forthcoming. There could be reasons not to be forthcoming but those = should be rare, specifically when providing technical and patentable = contributions. --Olaf --Apple-Mail=_50C3FB38-154E-40B3-9EFE-9DD0A3BF5588 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii dane.list@iswho.me> = wrote:

PS. As = many people on the DANE list will appreciate this is not a
technical = issue but a trust issue. I am not proposing mechanisms that
involve = authentications, I-Ds and what have you but I personally = would
appreciate people to be forthcoming.
[...]
So if it's trust you want = then I guess we'll need to find an anchor for
that stuff before...

I had = hoped that that sense of irony came through in the first line of the = PS.

Oh, let's have a new DNS RRTYPE = 0wnr
Is this a technical discussion now = ?

Nope, I = believe this is a serious issue that can be solve when people are = forthcoming. There could be reasons not to be forthcoming but those = should be rare, specifically when providing technical and patentable = contributions.



--Ol= af

= --Apple-Mail=_50C3FB38-154E-40B3-9EFE-9DD0A3BF5588-- From sm@resistor.net Mon Jun 17 03:08: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 C188421F9B9F for ; Mon, 17 Jun 2013 03:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.507 X-Spam-Level: X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 UN0eI9n2d6Nj for ; Mon, 17 Jun 2013 03:08:04 -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 2598121F9B38 for ; Mon, 17 Jun 2013 03:08:02 -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 r5HA7vZ9006287 for ; Mon, 17 Jun 2013 03:08:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1371463681; bh=BKmeWvse7M+KeRD2SWE62aZP9W/vZZt4ZlWeRZNFCxc=; h=Date:To:From:Subject:In-Reply-To:References; b=xxLUf1VU4qp3zDrPezACQjNk+TBynb3HdKl59/gB/IBKbCw+rK7gbp+7ScmqgJOrJ RfYKav8uwwS8VdDRhM4EhtTH7zgOOw3vrhTl+/XQoJ2xPX329SgDpDC8nizeHg24os PYLS8fN+gB70+cBrmIBTHr56VpRYntND7mEHdMik= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1371463681; i=@resistor.net; bh=BKmeWvse7M+KeRD2SWE62aZP9W/vZZt4ZlWeRZNFCxc=; h=Date:To:From:Subject:In-Reply-To:References; b=So7D3cAl1KUcpIpgMNiM0R0wk8NWjAJByNDOrFdl6xL9utH6AhP6id6ukQV/8WqGX MmF6cng6Q83cd+Y25ybRjhsZ+NNIb6VfXA5J7oDErsrVkqUqNEhi0+7KbQVTesfThK cV3+jdrP3TX1oEOcqWHjGSxcCFYyh83hmkyHnffA= Message-Id: <6.2.5.6.2.20130617025432.0d74f038@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 17 Jun 2013 03:07:40 -0700 To: dane@ietf.org From: SM In-Reply-To: <1371451927.13192.140661244738717.6F4EF3D6@webmail.messagin gengine.com> References: <308BB18F-BB9B-4503-A8EF-53FEEACAD12A@kumari.net> <1371451927.13192.140661244738717.6F4EF3D6@webmail.messagingengine.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [dane] The DANE list and psudonmyms... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jun 2013 10:08:09 -0000 At 23:52 16-06-2013, DANE wrote: >So basically you're saying that as long as a name appears to be a real >one then it's okay, whilst anything that obviously isn't a real name is >not ? How will that judgement be made ? If for example someone called Yes. :-) >'Poo Ann Wee' from Singapore registers how will you tell if it's fake or >not ? dig TXT Poo%20Ann%20Wee.sg.profile.gmail.com Regards, -sm P.S. The message was likely about making a good faith effort to provide information to the DANE WG Chairs so that they can assess whether there might be IPR issues. From warren@kumari.net Mon Jun 17 07:44: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 39F4321F9CD4 for ; Mon, 17 Jun 2013 07:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.266 X-Spam-Level: X-Spam-Status: No, score=-101.266 tagged_above=-999 required=5 tests=[AWL=-0.202, BAYES_00=-2.599, FRT_STRONG2=1.535, 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 gum33UsIzXbg for ; Mon, 17 Jun 2013 07:44:35 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 739CC21F9C97 for ; Mon, 17 Jun 2013 07:44:31 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.90]) by vimes.kumari.net (Postfix) with ESMTPSA id 2E67B1B40BB1; Mon, 17 Jun 2013 10:44:30 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Warren Kumari In-Reply-To: <6.2.5.6.2.20130617025432.0d74f038@resistor.net> Date: Mon, 17 Jun 2013 10:44:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5F7D9445-C443-4B5E-A880-969BE37E1ADA@kumari.net> References: <308BB18F-BB9B-4503-A8EF-53FEEACAD12A@kumari.net> <1371451927.13192.140661244738717.6F4EF3D6@webmail.messagingengine.com> <6.2.5.6.2.20130617025432.0d74f038@resistor.net> To: SM X-Mailer: Apple Mail (2.1508) Cc: dane@ietf.org Subject: Re: [dane] The DANE list and psudonmyms... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jun 2013 14:44:40 -0000 On Jun 17, 2013, at 6:07 AM, SM wrote: > At 23:52 16-06-2013, DANE wrote: >> So basically you're saying that as long as a name appears to be a = real >> one then it's okay, whilst anything that obviously isn't a real name = is >> not ? How will that judgement be made ? If for example someone called >=20 > Yes. :-) >=20 >> 'Poo Ann Wee' from Singapore registers how will you tell if it's fake = or >> not ? >=20 > dig TXT Poo%20Ann%20Wee.sg.profile.gmail.com >=20 > Regards, > -sm >=20 > P.S. The message was likely about making a good faith effort to = provide information to the DANE WG Chairs so that they can assess = whether there might be IPR issues.=20 Yup -- when the lawyers come a knockin' I want to be able to say (in = good faith :-)) that I tried to enforce the Note Well. Having an obvious = "That's not a real person" would make that, um, implausible. W > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 -- There were such things as dwarf gods. Dwarfs were not a naturally = religious species, but in a world where pit props could crack without = warning and pockets of fire damp could suddenly explode they'd seen the = need for gods as the sort of supernatural equivalent of a hard hat. = Besides, when you hit your thumb with an eight-pound hammer it's nice to = be able to blaspheme. It takes a very special and straong-minded kind of = atheist to jump up and down with their hand clasped under their other = armpit and shout, "Oh, random-fluctuations-in-the-space-time-continuum!" = or "Aaargh, primitive-and-outmoded-concept on a crutch!" -- Terry Pratchett From warren@kumari.net Thu Jun 20 11:42: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 9D60121E804B for ; Thu, 20 Jun 2013 11:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.326 X-Spam-Level: X-Spam-Status: No, score=-102.326 tagged_above=-999 required=5 tests=[AWL=0.273, 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 0wvHL20d4mR8 for ; Thu, 20 Jun 2013 11:41:57 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE2021F9FEE for ; Thu, 20 Jun 2013 11:41:57 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.90]) by vimes.kumari.net (Postfix) with ESMTPSA id 97AAD1B40227; Thu, 20 Jun 2013 14:41:56 -0400 (EDT) From: Warren Kumari Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Thu, 20 Jun 2013 14:41:56 -0400 Message-Id: <4FFBD2BF-9A73-4463-BAFB-BE3E5E29A6EA@kumari.net> To: "dane@ietf.org list" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [dane] Reviewing / feedback on DANE drafts. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 20 Jun 2013 18:42:02 -0000 Hi there all, We will likely be discussing the following drafts at the IETF meeting in = Berlin.=20 There are (IMO) useful drafts, and it would be great if we could get = some more discussions / review soon, so that we can make better use of = our meeting time=85 "DANE TLSA implementation and operational guidance" -- = https://datatracker.ietf.org/doc/draft-dukhovni-dane-ops/ "SMTP security via opportunistic DANE TLS" -- = http://datatracker.ietf.org/doc/draft-dukhovni-smtp-opportunistic-tls=20 "Harmonizing how applications specify DANE-like usage" -- = http://datatracker.ietf.org/doc/draft-ogud-dane-vocabulary Thanks, W+O -- Consider orang-utans. In all the worlds graced by their presence, it is suspected that they = can talk but choose not to do so in case humans put them to work, = possibly in the television industry. In fact they can talk. It's just = that they talk in Orang-utan. Humans are only capable of listening in = Bewilderment. -- Terry Practhett From stpeter@stpeter.im Thu Jun 20 19:02:52 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 BF3C421E80EB for ; Thu, 20 Jun 2013 19:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tx1mvPvFeuix for ; Thu, 20 Jun 2013 19:02:48 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 699CF1F0D33 for ; Thu, 20 Jun 2013 19:02:48 -0700 (PDT) Received: from sjc-vpn6-1575.cisco.com (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id AB1F4412C9; Thu, 20 Jun 2013 20:02:50 -0600 (MDT) Message-ID: <51C3B445.3050604@stpeter.im> Date: Thu, 20 Jun 2013 20:02:45 -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 X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [dane] while we're waiting for DANE deployment... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jun 2013 02:02:52 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 DANE is awesome and will solve many practical challenges with the existing PKI (e.g., the inability to securely offer proper certificates for hosted domains in multi-tenanted environments). Unfortunately, DANE won't be widely deployed anytime soon. (As one example, we're still struggling with the lack of DNS SRV support among domain registrars for certain major TLDs, let alone DNSSEC support.) Thus we need something that solves some of the same problems as DANE, but that can be deployed much more quickly. Matt Miller and I have been working on this problem for some time in the XMPP community, and we have recently generalized the approach we've defined, called "PKIX Over Secure HTTP" or "POSH": https://datatracker.ietf.org/doc/draft-miller-posh/ As the abstract says: This document defines two methods that make it easier to deploy certificates for proper server identity checking in application protocols. The first method enables a TLS client to obtain a TLS server's end-entity certificate over secure HTTP as an alternative to standard Public Key Infrastructure using X.509 (PKIX) and DNS-Based Authentication of Named Entities (DANE). The second method enables a source domain to securely delegate an application to a derived domain using HTTPS redirects. Feedback from folks in the DANE community is very much welcome on the posh@ietf.org list: https://www.ietf.org/mailman/listinfo/posh Thanks! 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/ iQIcBAEBAgAGBQJRw7RFAAoJEOoGpJErxa2pADUQAJb1A/+Dpv+4w5dch4fU7tQL DOMndNYyMSYPIJ5b74oDZ3oM0eA7nEqJwp79KsWrGweL1GeLhLKXl1kK2Tz8KUls eA5IbaTbfcvT+hBoA8txx/6VeHhoJnTQ3R2wuczDYhREXsh/pzku/5IgFQN9yLEK Q8wLk5XS1OKTvf+kV+t3tJGtuQCKdsaAX++e/8h1ZWnaswuWIKAdTlhImDIWquk4 U14hyni+6/8+TqnewRjxbYsD9VC4DWEjRobB1VT+/ONs6MLQSSnO20pKoHJw0Msu fZP+KBsHJsUHDHhGycyEri4pfHyxGW7mVMD7lvERtD6FiUCY3F/uLNj3ERdOXsi1 rOQ0GHDZiSw/BWt5jAbq1R9pUcj0+KRQgdNM8w1CAHn6hJGVXwL7tZ6J9yjpRFWK M9SUdFDs4mZ4D6ISR9C+nNfP9jUQxBzTxwc4mTZJR6/yt5FUj5QLG4cu3zYIKXwm xrGgR/P+KJfv4rnL64gJwwfc9rZn1eE/maf397SIcQWR0w4d6Wze0hmxGq8BEXu/ dmawAVXJqLQp6aCCRzAns1phh66ls13kbJrUEdfGlIPj6bUNNrwCwyvwzQsjvc41 UBHURPBETx4cSYcc7lNiThXVb8ay+NpHkAy4Ligx7D/TAWfkX2aKgsMKWbGUU1ut 5INgHhhJtA1+h4h/1KyP =5xcL -----END PGP SIGNATURE----- From viktor1dane@dukhovni.org Fri Jun 21 07:23: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 A899F11E8192 for ; Fri, 21 Jun 2013 07:23:37 -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 Wq7hDcJ5xG0k for ; Fri, 21 Jun 2013 07:23:33 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id B783E21F9C93 for ; Fri, 21 Jun 2013 07:23:32 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 7E6B12AAAF8; Fri, 21 Jun 2013 14:23:31 +0000 (UTC) Date: Fri, 21 Jun 2013 14:23:31 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130621142331.GJ29420@mournblade.imrryr.org> References: <51C3B445.3050604@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51C3B445.3050604@stpeter.im> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] while we're waiting for DANE deployment... 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, 21 Jun 2013 14:23:37 -0000 On Thu, Jun 20, 2013 at 08:02:45PM -0600, Peter Saint-Andre wrote: > DANE is awesome and will solve many practical challenges with the > existing PKI (e.g., the inability to securely offer proper > certificates for hosted domains in multi-tenanted environments). Isn't this *supposed* to be solved via SNI? (I personally don't believe SNI scales, but I'm willing to go along with the idea for argument's sake now and then). Is it no longer controversial to say that SNI does not solve the multi-tenant problem? If so, then I'd like to more strongly emphasise my comments on DANE and CNAMEs. If DANE clients chase CNAME RRs (while keeping track of DNSSEC validation at each step), then multi-tenant deployments can avoid SNI depedence, as the TLSA RRs would only need to be published in one place by the service operator. Otherwise, it is not clear how DANE addresses the multi-tenant issue. > Unfortunately, DANE won't be widely deployed anytime soon. (As one > example, we're still struggling with the lack of DNS SRV support among > domain registrars for certain major TLDs, let alone DNSSEC support.) Is the main obstacle in your view lack registrar infrastructure to support customer DNSSEC deployment, or lack of tools for customers to manage DNSSEC zone signing? > https://datatracker.ietf.org/doc/draft-miller-posh/ > > As the abstract says: > > This document defines two methods that make it easier to deploy > certificates for proper server identity checking in application > protocols. The first method enables a TLS client to obtain a TLS > server's end-entity certificate over secure HTTP as an alternative to > standard Public Key Infrastructure using X.509 (PKIX) and DNS-Based > Authentication of Named Entities (DANE). The second method enables a > source domain to securely delegate an application to a derived domain > using HTTPS redirects. This requires TLS clients to also also implement HTTPS, and to able to do PKIX validation of HTTPS peers. Plus additional latency to fetch the certs via HTTPS with no local cache (as with DNS). This certainly looks unappealing from an SMTP perspective. > Feedback from folks in the DANE community is very much welcome on the > posh@ietf.org list: > > https://www.ietf.org/mailman/listinfo/posh I'll take a closer look when I get a chance, but I am skeptical. New standards take a long time from inception to wide adoption. Software released today takes ~2-5 years to be included by O/S distributions (if bundled as with MTAs) or upgraded by a majority of the user base. Browsers with their independent distribution channels are the exception, not the rule. So I think that deployment barriers today should not overly prejudice architectural decisions for software that will only become mainstream in ~5 years. -- Viktor. From viktor1dane@dukhovni.org Fri Jun 21 07:51: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 0992521E812A for ; Fri, 21 Jun 2013 07:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 LjjbC3v7FmWr for ; Fri, 21 Jun 2013 07:50:55 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 47D4621E8136 for ; Fri, 21 Jun 2013 07:50:54 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 229CA2AAAF7; Fri, 21 Jun 2013 14:50:46 +0000 (UTC) Date: Fri, 21 Jun 2013 14:50:46 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130621145045.GK29420@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] Large TLSA RRs (X 0 0) meet reality? 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, 21 Jun 2013 14:51:00 -0000 [ Bcc'd to domain owner of large "2 0 0" TLSA RR. ] In testing various SMTP server's TLSA RRs I found that at least one prominent validating nameserver drops requests for large TLSA RRs over UDP. (The TLSA RR is returned if the request does not set the "DO" bit). With no UDP response at all (not even TC=1) clients don't fall back to TCP. In particular this is observed with Google's 8.8.8.8 DNS service. Queries for a "2 0 0" TLSA RR containing an 1885 byte certificate time out over UDP. And even with TCP forced, the response is returned with the "AD" bit incorrectly not set. $ drill -D -t _25._tcp.mx..org @8.8.8.8 tlsa ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 48420 ;; flags: qr rd ra ; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;; _25._tcp.mx..org. IN TLSA ;; ANSWER SECTION: _25._tcp.mx..org. 0 IN CNAME _cacert-c3-tlsa..org. _25._tcp.mx..org. 0 IN RRSIG CNAME 7 5 7200 20130630103058 20130531094020 56225 .org. ... _cacert-c3-tlsa..org. 0 IN TLSA 2 0 0 <1885 bytes> _cacert-c3-tlsa..org. 0 IN RRSIG TLSA 7 3 7200 20130630103058 20130531094020 56225 .org. ... ;; Query time: 376 msec ;; EDNS: version 0; flags: do ; udp: 512 ;; SERVER: 8.8.8.8 ;; WHEN: Fri Jun 21 09:57:52 2013 ;; MSG SIZE rcvd: 2327 Queries for more modestly sized "X Y 1", RRs are handled just fine. $ drill -D _25._tcp.master.debian.org. tlsa @8.8.8.8 ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 1645 ;; flags: qr rd ra ad ; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;; _25._tcp.master.debian.org. IN TLSA ;; ANSWER SECTION: _25._tcp.master.debian.org. 3600 IN TLSA 3 1 1 b5fcc059553aafb1ba54294208479c154d940d9b36c1a22ca41bd1c041c87b26 _25._tcp.master.debian.org. 3600 IN RRSIG TLSA 7 5 3600 20130718215759 20130620215759 17309 debian.org. cIP8ZqPkITt6flZu2qMXXzZmiHC07SdnGiEtq+FiPlkvhDpx3CZPfQVMboaFDkR5vp4Ql9eMBIBr4N0GoGIfPPI2oV5uYNjjdmRoV9XAsRgBKn9bTCAaiumBOMjWA9+u3/WND9r2/qB13M2j6JAiU/QDSZky7qs5icqhaezjnR7NPcy+89Zk6yS2lU7Qg079 ;; Query time: 400 msec ;; EDNS: version 0; flags: do ; udp: 512 ;; SERVER: 8.8.8.8 ;; WHEN: Fri Jun 21 10:33:53 2013 ;; MSG SIZE rcvd: 288 Though of course one should typically not rely on the "AD" bit from 8.8.8.8 for lack of transport security between the client and the nameserver, this is in indicator of likely trouble. So I think my advice against "X 0 0" stands, these RRs are too large to be reliably used with DNS. -- Viktor. From ajs@anvilwalrusden.com Fri Jun 21 07:57: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 32CC911E8193 for ; Fri, 21 Jun 2013 07:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BF+RMJFdSnUY for ; Fri, 21 Jun 2013 07:57:10 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id DC98C11E8198 for ; Fri, 21 Jun 2013 07:57:05 -0700 (PDT) Received: from mx1.yitter.info (nat-08-mht.dyndns.com [216.146.45.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 0CC538A031 for ; Fri, 21 Jun 2013 14:57:04 +0000 (UTC) Date: Fri, 21 Jun 2013 10:57:04 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20130621145704.GN41900@mx1.yitter.info> References: <20130621145045.GK29420@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130621145045.GK29420@mournblade.imrryr.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Large TLSA RRs (X 0 0) meet reality? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jun 2013 14:57:16 -0000 On Fri, Jun 21, 2013 at 02:50:46PM +0000, Viktor Dukhovni wrote: > service. Queries for a "2 0 0" TLSA RR containing an 1885 byte > certificate time out over UDP. Are you quite sure that your problem isn't that you're sending your UDP query with an EDNS0 buffer size larger than you can actually receive? That's often the problem here. A -- Andrew Sullivan ajs@anvilwalrusden.com From stpeter@stpeter.im Fri Jun 21 08:39: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 CEB3021F9E97; Fri, 21 Jun 2013 08:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 ZyaMSoHxsc+p; Fri, 21 Jun 2013 08:39:09 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9C93A21F9EAC; Fri, 21 Jun 2013 08:39:09 -0700 (PDT) Received: from ergon.local (unknown [64.101.72.59]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 42686412C3; Fri, 21 Jun 2013 09:39:13 -0600 (MDT) Message-ID: <51C4739A.3030508@stpeter.im> Date: Fri, 21 Jun 2013 09:39: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: dane@ietf.org References: <51C3B445.3050604@stpeter.im> <20130621142331.GJ29420@mournblade.imrryr.org> In-Reply-To: <20130621142331.GJ29420@mournblade.imrryr.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: posh@ietf.org Subject: Re: [dane] while we're waiting for DANE deployment... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jun 2013 15:39:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [ + posh@ietf.org - I will drop dane@ietf.org if this thread continues ] On 6/21/13 8:23 AM, Viktor Dukhovni wrote: > On Thu, Jun 20, 2013 at 08:02:45PM -0600, Peter Saint-Andre wrote: > >> DANE is awesome and will solve many practical challenges with >> the existing PKI (e.g., the inability to securely offer proper >> certificates for hosted domains in multi-tenanted environments). > > Isn't this *supposed* to be solved via SNI? (I personally don't > believe SNI scales, but I'm willing to go along with the idea for > argument's sake now and then). The core problem in the PKI context is that BigCompany.com isn't going to hand over its private keys to ConvenientHostingService.com, and the hosting company doesn't want those keys anyway for liability purposes. > Is it no longer controversial to say that SNI does not solve the > multi-tenant problem? If so, then I'd like to more strongly > emphasise my comments on DANE and CNAMEs. If DANE clients chase > CNAME RRs (while keeping track of DNSSEC validation at each step), > then multi-tenant deployments can avoid SNI depedence, as the TLSA > RRs would only need to be published in one place by the service > operator. Otherwise, it is not clear how DANE addresses the > multi-tenant issue. With POSH we are trying to find an interim solution to PKI issues. I *think* (although I have not yet proved it out) that DANE solves those problems, too. But the PKI problems are pressing enough that we need to solve them as soon as possible. >> Unfortunately, DANE won't be widely deployed anytime soon. (As >> one example, we're still struggling with the lack of DNS SRV >> support among domain registrars for certain major TLDs, let alone >> DNSSEC support.) > > Is the main obstacle in your view lack registrar infrastructure to > support customer DNSSEC deployment, or lack of tools for customers > to manage DNSSEC zone signing? IMHO, probably both. But I will ask some folks on the operational side to find out more. >> https://datatracker.ietf.org/doc/draft-miller-posh/ >> >> As the abstract says: >> >> This document defines two methods that make it easier to deploy >> certificates for proper server identity checking in application >> protocols. The first method enables a TLS client to obtain a >> TLS server's end-entity certificate over secure HTTP as an >> alternative to standard Public Key Infrastructure using X.509 >> (PKIX) and DNS-Based Authentication of Named Entities (DANE). >> The second method enables a source domain to securely delegate an >> application to a derived domain using HTTPS redirects. > > This requires TLS clients to also also implement HTTPS, and to > able to do PKIX validation of HTTPS peers. Yes, but we figure that such code is very widely available. > Plus additional latency to fetch the certs via HTTPS with no local > cache (as with DNS). This certainly looks unappealing from an SMTP > perspective. A happy eyeballs approach should help with latency. >> Feedback from folks in the DANE community is very much welcome on >> the posh@ietf.org list: >> >> https://www.ietf.org/mailman/listinfo/posh > > I'll take a closer look when I get a chance, but I am skeptical. Your skepticism is appreciated. > New standards take a long time from inception to wide adoption. > Software released today takes ~2-5 years to be included by O/S > distributions (if bundled as with MTAs) or upgraded by a majority > of the user base. Browsers with their independent distribution > channels are the exception, not the rule. So I think that > deployment barriers today should not overly prejudice architectural > decisions for software that will only become mainstream in ~5 > years. That is a valid point, and one that we'll need to consider at the BoF in Berlin. Pete - -- 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/ iQIcBAEBAgAGBQJRxHOaAAoJEOoGpJErxa2p6Z4P/2R2v9k2v1pVq6oQx7/GzPH2 vab6rFlPLUrPq4JuSRyspCmJcy0fOxzK5er6Mc/cE/70icEqobBDx0z4Swd/yCRm HwKkSJQFQKUI47y2GbtDcaSW3MSC09Y+9qWdiv0gLy9jInVV782tzjKGMlCgupq1 gdOfuDEcSYXorlpI1pjWKD535pO8PRz32mwXR30i8Ov6noxFEou4wTrSnQPMdDm9 RX96v5nyOvOQ9Kw1RCAGWX3GavumNzi6qG8pJDSxNnP57MHeb4eTegMfT2qzPWTs h4PbhX+mp3DIGDirf3x6aF79zia4gcL885tN0qPEDJwqAuOJ84h0BGypotjUrge/ WqYkXzQOIPo7dm+KYEWjnUF5kyuYZ1k+7mk104LDJ+Tyjq8MulXH//huXnZeh6fe 1KJcVltlzpdsxN0fzXk3KxiejADxkSRDXHnvE4Gbd49Nqeb86ORW6SBxzqbUygT2 UQ1n44WLg3eYjAH5uDVpTQzL+DNwcWrrj5b2Vh44VeOR9auBtpNR/6xWe8Yi55Ug SYn5fQ8/kBBZZ57P9vvc1jGbEqsHvz560lnbzYWS+Wekf89MboKH0Jmo425GY252 uIZkr2koOI9OwS3RDIOWV5v/GsDUlUbmMt/y3G4RwFfCmpxUew4rSr4m7tdRylHA 19z4KBbbcsmh4v2HvF9K =Ygon -----END PGP SIGNATURE----- From viktor1dane@dukhovni.org Fri Jun 21 09:34: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 B7F5E21F9D9D for ; Fri, 21 Jun 2013 09:34:16 -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 pTk1fGz+Qv0C for ; Fri, 21 Jun 2013 09:34:11 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 9F2B821F9D72 for ; Fri, 21 Jun 2013 09:34:11 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 1C5AE2AAAF5; Fri, 21 Jun 2013 16:34:10 +0000 (UTC) Date: Fri, 21 Jun 2013 16:34:10 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130621163410.GO29420@mournblade.imrryr.org> References: <20130621145045.GK29420@mournblade.imrryr.org> <20130621145704.GN41900@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130621145704.GN41900@mx1.yitter.info> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Large TLSA RRs (X 0 0) meet reality? 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, 21 Jun 2013 16:34:16 -0000 On Fri, Jun 21, 2013 at 10:57:04AM -0400, Andrew Sullivan wrote: > On Fri, Jun 21, 2013 at 02:50:46PM +0000, Viktor Dukhovni wrote: > > > service. Queries for a "2 0 0" TLSA RR containing an 1885 byte > > certificate time out over UDP. > > Are you quite sure that your problem isn't that you're sending your > UDP query with an EDNS0 buffer size larger than you can actually > receive? That's often the problem here. Fairly confident, I've tested two different platforms at two different sites. I'll send you the domain off list, please verify for yourself. [ I don't want to publish the domain withour the owner's permission. ] -- Viktor. From guido@witmond.nl Fri Jun 21 09:51: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 E210721F8C4C; Fri, 21 Jun 2013 09:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.204 X-Spam-Level: X-Spam-Status: No, score=-0.204 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zDy0i0iPe+3i; Fri, 21 Jun 2013 09:51:19 -0700 (PDT) Received: from smtp-vbr7.xs4all.nl (smtp-vbr7.xs4all.nl [194.109.24.27]) by ietfa.amsl.com (Postfix) with ESMTP id 9A96E11E81A5; Fri, 21 Jun 2013 09:51:04 -0700 (PDT) Received: from [10.1.2.6] (mail.wtmnd.nl [80.100.189.3]) by smtp-vbr7.xs4all.nl (8.13.8/8.13.8) with ESMTP id r5LGouI7009661; Fri, 21 Jun 2013 18:51:03 +0200 (CEST) (envelope-from guido@witmond.nl) Message-ID: <51C48470.6070007@witmond.nl> Date: Fri, 21 Jun 2013 18:50:56 +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: Peter Saint-Andre References: <51C3B445.3050604@stpeter.im> <20130621142331.GJ29420@mournblade.imrryr.org> <51C4739A.3030508@stpeter.im> In-Reply-To: <51C4739A.3030508@stpeter.im> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Cc: posh@ietf.org, dane@ietf.org Subject: Re: [dane] while we're waiting for DANE deployment... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jun 2013 16:51:24 -0000 On 21-06-13 17:39, Peter Saint-Andre wrote: > [ + posh@ietf.org - I will drop dane@ietf.org if this thread continues ] > > On 6/21/13 8:23 AM, Viktor Dukhovni wrote: > >> New standards take a long time from inception to wide adoption. >> Software released today takes ~2-5 years to be included by O/S >> distributions (if bundled as with MTAs) or upgraded by a majority >> of the user base. Browsers with their independent distribution >> channels are the exception, not the rule. So I think that >> deployment barriers today should not overly prejudice architectural >> decisions for software that will only become mainstream in ~5 >> years. > > That is a valid point, and one that we'll need to consider at the BoF > in Berlin. That's a good argument to work on browser plugins. Like the ridiculed Extended DNSSEC validator. Or the next version of CZ.nic's original plugin. Even if the only purpose of these tools is to raise awareness about DNSSEC/DANE, I believe it's worth it. My authentication protocol relies on DANE, so I made it into a browser proxy. [1] Regards, Guido. [1] http://eccentric-authentication.org/blog/2013/06/07/run-it-yourself.html From ajs@anvilwalrusden.com Fri Jun 21 10:47: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 0B58D21F9D98 for ; Fri, 21 Jun 2013 10:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.763 X-Spam-Level: X-Spam-Status: No, score=-0.763 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4qnHY1o5O0j for ; Fri, 21 Jun 2013 10:47:22 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 42AB021F9E6E for ; Fri, 21 Jun 2013 10:47:21 -0700 (PDT) Received: from mx1.yitter.info (nat-08-mht.dyndns.com [216.146.45.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 0A1178A031 for ; Fri, 21 Jun 2013 17:47:21 +0000 (UTC) Date: Fri, 21 Jun 2013 13:47:19 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20130621174719.GQ41900@mx1.yitter.info> References: <20130621145045.GK29420@mournblade.imrryr.org> <20130621145704.GN41900@mx1.yitter.info> <20130621163410.GO29420@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130621163410.GO29420@mournblade.imrryr.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Large TLSA RRs (X 0 0) meet reality? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jun 2013 17:47:28 -0000 On Fri, Jun 21, 2013 at 04:34:10PM +0000, Viktor Dukhovni wrote: > > Fairly confident, I've tested two different platforms at two > different sites. I'll send you the domain off list, please verify > for yourself. [ I don't want to publish the domain withour the owner's > permission. ] Thanks. I tried this. If I use -b up to about 2300, I get back a truncated answer (so I'd retry over TCP). If I go above that, however, it hangs. This makes sense; I'm pretty sure my network is going to fragment at that point, and lots of people don't reassemble UDP fragments. So I think the problem here is that you can't effectively query such a large answer in most networks over UDP, because the EDNS0 buffer size you'd need for the answer to fit is too large for most networks. I'm not sure that's evidence that the particular use is bad. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From rlb@ipv.sx Fri Jun 21 11:28: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 4EAD711E80AD for ; Fri, 21 Jun 2013 11:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.321 X-Spam-Level: X-Spam-Status: No, score=-0.321 tagged_above=-999 required=5 tests=[AWL=0.104, 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 UO++bW8ev9VG for ; Fri, 21 Jun 2013 11:28:54 -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 77FA421F9F51 for ; Fri, 21 Jun 2013 11:28:54 -0700 (PDT) Received: by mail-ob0-f176.google.com with SMTP id v19so8660491obq.7 for ; Fri, 21 Jun 2013 11:28:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=F2HM+Td6ub67g7xpjdoE9gTPJIe5HqNrumeOuD0gep0=; b=l87y+LiVfotkle69OcgphU+/WU4uj+QIV6wA4r1PRc3xeTy3m5HX8Yvm6zDrJ8FZAQ DXY+RC4bM7k6RiuKn/kg8wlQzRCrNS4PJLCcTmuAwD1zqG4Jv83P+nd7P+lqLAwZW215 HOWh40kAbcQkBTsnwRYyo7Y8Kyk6IGAiff1CoyactgPZPz7B+MGMVMGpIWvcgIdbp7Np qsAslTpwZCBy/1QHybX9kv7uyGHcTFMrE4NPEhpzMb+l6YIMMPFySznlylzcffoPCxzr aJYNymBLlPs3YoOM0EK67jFldBw31jnl09SQGur6fzHxj6omJ6+HbwkymzITiyWZxnkD tdqA== MIME-Version: 1.0 X-Received: by 10.60.96.197 with SMTP id du5mr6774344oeb.127.1371839333888; Fri, 21 Jun 2013 11:28:53 -0700 (PDT) Received: by 10.60.28.233 with HTTP; Fri, 21 Jun 2013 11:28:53 -0700 (PDT) X-Originating-IP: [192.1.51.101] In-Reply-To: <20130621174719.GQ41900@mx1.yitter.info> References: <20130621145045.GK29420@mournblade.imrryr.org> <20130621145704.GN41900@mx1.yitter.info> <20130621163410.GO29420@mournblade.imrryr.org> <20130621174719.GQ41900@mx1.yitter.info> Date: Fri, 21 Jun 2013 14:28:53 -0400 Message-ID: From: Richard Barnes To: Andrew Sullivan Content-Type: multipart/alternative; boundary=e89a8f83a4cf2f869604dfae3ccd X-Gm-Message-State: ALoCoQnyqqikNHeEBywBYjWT44yUJJE4cM7OXZW/aIZhyG/VycYAiSejGV5v1+2sXePosrJ/J+Xc Cc: "dane@ietf.org" Subject: Re: [dane] Large TLSA RRs (X 0 0) meet reality? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jun 2013 18:28:59 -0000 --e89a8f83a4cf2f869604dfae3ccd Content-Type: text/plain; charset=ISO-8859-1 So is the answer here just, "Use TCP"? Like for DNSSEC records? On Fri, Jun 21, 2013 at 1:47 PM, Andrew Sullivan wrote: > On Fri, Jun 21, 2013 at 04:34:10PM +0000, Viktor Dukhovni wrote: > > > > Fairly confident, I've tested two different platforms at two > > different sites. I'll send you the domain off list, please verify > > for yourself. [ I don't want to publish the domain withour the owner's > > permission. ] > > Thanks. I tried this. > > If I use -b up to about 2300, I get back a truncated answer (so I'd > retry over TCP). If I go above that, however, it hangs. This makes > sense; I'm pretty sure my network is going to fragment at that point, > and lots of people don't reassemble UDP fragments. > > So I think the problem here is that you can't effectively query such a > large answer in most networks over UDP, because the EDNS0 buffer size > you'd need for the answer to fit is too large for most networks. I'm > not sure that's evidence that the particular use is bad. > > Best, > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > --e89a8f83a4cf2f869604dfae3ccd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
So is the answer here just, "Use TCP"? =A0Like f= or DNSSEC records?


On Fri, Jun 21, 2013 at 1:47 PM, Andrew Sullivan <ajs@anvi= lwalrusden.com> wrote:
On Fri, Jun 21, 2013 at 04= :34:10PM +0000, Viktor Dukhovni wrote:
>
> Fairly confident, I've tested two different platforms at two
> different sites. =A0I'll send you the domain off list, please veri= fy
> for yourself. [ I don't want to publish the domain withour the own= er's
> permission. ]

Thanks. =A0I tried this.

If I use -b up to about 2300, I get back a truncated answer (so I'd
retry over TCP). =A0If I go above that, however, it hangs. =A0This makes sense; I'm pretty sure my network is going to fragment at that point, and lots of people don't reassemble UDP fragments.

So I think the problem here is that you can't effectively query such a<= br> large answer in most networks over UDP, because the EDNS0 buffer size
you'd need for the answer to fit is too large for most networks. =A0I&#= 39;m
not sure that's evidence that the particular use is bad.

Best,

A

--
Andrew Sullivan
ajs@anvilwalrusden.com
_____________________________= __________________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane

--e89a8f83a4cf2f869604dfae3ccd-- From ajs@anvilwalrusden.com Fri Jun 21 11:43:52 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 89C4E21F9CD7 for ; Fri, 21 Jun 2013 11:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.768 X-Spam-Level: X-Spam-Status: No, score=-0.768 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xlgqk1C99STC for ; Fri, 21 Jun 2013 11:43:46 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id B25C621F9AE0 for ; Fri, 21 Jun 2013 11:43:46 -0700 (PDT) Received: from mx1.yitter.info (nat-08-mht.dyndns.com [216.146.45.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 1B86E8A031 for ; Fri, 21 Jun 2013 18:43:40 +0000 (UTC) Date: Fri, 21 Jun 2013 14:43:38 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20130621184338.GR41900@mx1.yitter.info> References: <20130621145045.GK29420@mournblade.imrryr.org> <20130621145704.GN41900@mx1.yitter.info> <20130621163410.GO29420@mournblade.imrryr.org> <20130621174719.GQ41900@mx1.yitter.info> 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] Large TLSA RRs (X 0 0) meet reality? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jun 2013 18:43:52 -0000 You don't have to use TCP for DNSSEC either, but sometimes you do. It seems in this case you need to. On Fri, Jun 21, 2013 at 02:28:53PM -0400, Richard Barnes wrote: > So is the answer here just, "Use TCP"? Like for DNSSEC records? > > > On Fri, Jun 21, 2013 at 1:47 PM, Andrew Sullivan wrote: > > > On Fri, Jun 21, 2013 at 04:34:10PM +0000, Viktor Dukhovni wrote: > > > > > > Fairly confident, I've tested two different platforms at two > > > different sites. I'll send you the domain off list, please verify > > > for yourself. [ I don't want to publish the domain withour the owner's > > > permission. ] > > > > Thanks. I tried this. > > > > If I use -b up to about 2300, I get back a truncated answer (so I'd > > retry over TCP). If I go above that, however, it hangs. This makes > > sense; I'm pretty sure my network is going to fragment at that point, > > and lots of people don't reassemble UDP fragments. > > > > So I think the problem here is that you can't effectively query such a > > large answer in most networks over UDP, because the EDNS0 buffer size > > you'd need for the answer to fit is too large for most networks. I'm > > not sure that's evidence that the particular use is bad. > > > > Best, > > > > A > > > > -- Andrew Sullivan ajs@anvilwalrusden.com From viktor1dane@dukhovni.org Fri Jun 21 14:28: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 25B3721F9DA6 for ; Fri, 21 Jun 2013 14:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 j7hyFJTQY7oG for ; Fri, 21 Jun 2013 14:27:57 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id F157621F9D9B for ; Fri, 21 Jun 2013 14:27:56 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D64D92AAAF5; Fri, 21 Jun 2013 21:27:55 +0000 (UTC) Date: Fri, 21 Jun 2013 21:27:55 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130621212755.GT29420@mournblade.imrryr.org> References: <20130621145045.GK29420@mournblade.imrryr.org> <20130621145704.GN41900@mx1.yitter.info> <20130621163410.GO29420@mournblade.imrryr.org> <20130621174719.GQ41900@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130621174719.GQ41900@mx1.yitter.info> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Large TLSA RRs (X 0 0) meet reality? 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, 21 Jun 2013 21:28:02 -0000 On Fri, Jun 21, 2013 at 01:47:19PM -0400, Andrew Sullivan wrote: > On Fri, Jun 21, 2013 at 04:34:10PM +0000, Viktor Dukhovni wrote: > > > > Fairly confident, I've tested two different platforms at two > > different sites. I'll send you the domain off list, please verify > > for yourself. [ I don't want to publish the domain withour the owner's > > permission. ] > > Thanks. I tried this. > > If I use -b up to about 2300, I get back a truncated answer (so I'd > retry over TCP). If I go above that, however, it hangs. This makes > sense; I'm pretty sure my network is going to fragment at that point, > and lots of people don't reassemble UDP fragments. I don't know why, they would not. It is a pretty basic requirement. The Ethernet IP MTU is <= 1500, so fragment should set in well before 2300 bytes. The problem sets in when the answer is not truncated. Note the TCP response was ;; SERVER: 8.8.8.8 ;; MSG SIZE rcvd: 2327 So the 2300 is not about cross the UDP re-assembly limit, but rather crossing the point at which the entire response fits untrucated. > So I think the problem here is that you can't effectively query such a > large answer in most networks over UDP, because the EDNS0 buffer size > you'd need for the answer to fit is too large for most networks. I'm > not sure that's evidence that the particular use is bad. I bet it is something much more interesting. In any case the point is that it fails pretty badly, hence such RRs are unwise. -- Viktor. From ajs@anvilwalrusden.com Fri Jun 21 15:12: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 B80DA21F9E5C for ; Fri, 21 Jun 2013 15:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.714 X-Spam-Level: X-Spam-Status: No, score=-0.714 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tEwxCje9AgUG for ; Fri, 21 Jun 2013 15:12:08 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id EBD6121F9E2B for ; Fri, 21 Jun 2013 15:12:07 -0700 (PDT) Received: from mx1.yitter.info (nat-08-mht.dyndns.com [216.146.45.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 4F3A58A031 for ; Fri, 21 Jun 2013 22:12:06 +0000 (UTC) Date: Fri, 21 Jun 2013 18:12:05 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20130621221204.GU41900@mx1.yitter.info> References: <20130621145045.GK29420@mournblade.imrryr.org> <20130621145704.GN41900@mx1.yitter.info> <20130621163410.GO29420@mournblade.imrryr.org> <20130621174719.GQ41900@mx1.yitter.info> <20130621212755.GT29420@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130621212755.GT29420@mournblade.imrryr.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Large TLSA RRs (X 0 0) meet reality? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jun 2013 22:12:13 -0000 On Fri, Jun 21, 2013 at 09:27:55PM +0000, Viktor Dukhovni wrote: > > I don't know why, they would not. It is a pretty basic requirement. I've now endured two presentations at IETF meetings in which large operators have said, "We don't reassemble UDP fragments; fragments suck." > The Ethernet IP MTU is <= 1500, so fragment should set in well > before 2300 bytes. Yes, but in this case it doesn't matter. > The problem sets in when the answer is not > truncated. Note the TCP response was > > ;; SERVER: 8.8.8.8 > ;; MSG SIZE rcvd: 2327 > > So the 2300 is not about cross the UDP re-assembly limit, but rather > crossing the point at which the entire response fits untrucated. I clearly didn't explain myself well enough. If you have an EDNS0 bufsize below 2327 bytes, then the answer never fits. Therefore, the server simply responds with a TC bit and no answer. If, however, you say that your bufsize is over 2326, then the server attempts to answer you sending a UDP packet with the necessary buffer size. This doesn't work, because your buffer isn't actually that big, and therefore the whole thing hangs. _That's_ the problem: when you sent the query, your buffer size was too big. Yes, this is a problem, but real resolvers are learning not to work the way drill does: they work to figure out a safe bufsize and then stick to it. (Drill doesn't do this because it's a diagnostic tool. It should do what you tell it.) > I bet it is something much more interesting. Having just performed the exercise that makes my point, I'll cheerfully take that bet! > In any case the point > is that it fails pretty badly, hence such RRs are unwise. I don't believe your illustration using drill shows what you think it does. A properly-behaved resolver shouldn't fail, but should get the TC-bit response and fall back to TCP. There's a live question as to whether falling back to TCP is acceptable; I think the operator of the service gets to make that determination, however. A -- Andrew Sullivan ajs@anvilwalrusden.com From viktor1dane@dukhovni.org Fri Jun 21 21:17:41 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 82AB621E80AC for ; Fri, 21 Jun 2013 21:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.060, 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 bm3l4wa9H2Fg for ; Fri, 21 Jun 2013 21:17:37 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id ED1C411E80AE for ; Fri, 21 Jun 2013 21:17:36 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 10AA22AAAF5; Sat, 22 Jun 2013 04:17:35 +0000 (UTC) Date: Sat, 22 Jun 2013 04:17:35 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130622041735.GU29420@mournblade.imrryr.org> References: <20130621145045.GK29420@mournblade.imrryr.org> <20130621145704.GN41900@mx1.yitter.info> <20130621163410.GO29420@mournblade.imrryr.org> <20130621174719.GQ41900@mx1.yitter.info> <20130621212755.GT29420@mournblade.imrryr.org> <20130621221204.GU41900@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130621221204.GU41900@mx1.yitter.info> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Large TLSA RRs (X 0 0) meet reality? 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, 22 Jun 2013 04:17:41 -0000 On Fri, Jun 21, 2013 at 06:12:05PM -0400, Andrew Sullivan wrote: > I've now endured two presentations at IETF meetings in which large > operators have said, "We don't reassemble UDP fragments; fragments > suck." This is irrelevant, IP reassembly happens at the receiving endpoint (my machine) not in the network core (but sometimes also in NAT devices and firewalls near the sending or receiving system). So whatever large operators are anecdotally reported to do is of little consequence. > > The problem sets in when the answer is not > > truncated. Note the TCP response was > > > > ;; SERVER: 8.8.8.8 > > ;; MSG SIZE rcvd: 2327 > > > > So the 2300 is not about cross the UDP re-assembly limit, but rather > > crossing the point at which the entire response fits untrucated. > > I clearly didn't explain myself well enough. If you have an EDNS0 > bufsize below 2327 bytes, then the answer never fits. Therefore, the > server simply responds with a TC bit and no answer. This is not always how the TC bit works, in many cases as much of the answer is sent as fits in the sender's buffer, for example with a query buffer size of 2200 sent to the authoritative server of the domain in question, I get a truncated response sent in two UDP fragments: 23:19:44.535213 IP (tos 0x0, ttl 63, id 32246, offset 0, flags [none], proto UDP (17), length 81) 192.0.2.1.59702 > 192.0.2.2.53: [udp sum ok] 14849+ [1au] Type52? _25._tcp.mx.censored.org. ar: . OPT UDPsize=2200 OK (53) 23:19:44.625789 IP (tos 0x0, ttl 45, id 29143, offset 0, flags [+], proto UDP (17), length 1396) 192.0.2.2.53 > 192.0.2.1.59702: 14849*-| q: Type52? _25._tcp.mx.censored.org. 3/0/1 _25._tcp.mx.censored.org. [2h] CNAME _cacert-c3-tlsa.censored.org., _25._tcp.mx.censored.org. [2h] RRSIG, _cacert-c3-tlsa.censored.org. [2h] Type52[|domain] 23:19:44.625822 IP (tos 0x0, ttl 45, id 29143, offset 1376, flags [none], proto UDP (17), length 807) 192.0.2.2 > 192.0.2.1: udp showing clearly that in this case TC is sent with a truncated answer. With Google's 8.8.8.8 however, truncation happens sooner and since the answer RRset includes just one RR, indeed truncation sends a TC bit with zero answers. > If, however, you say that your bufsize is over 2326, then the server > attempts to answer you sending a UDP packet with the necessary buffer > size. This doesn't work, because your buffer isn't actually that big, > and therefore the whole thing hangs. My buffer is that big, so if there is a re-assembly issue it could only be in the load-balancer or firewall/NAT hardware handling 8.8.8.8, since core routers don't do or care about reassembly, they just switch IP datagrams. > _That's_ the problem: when you > sent the query, your buffer size was too big. Yes, this is a problem, > but real resolvers are learning not to work the way drill does: they > work to figure out a safe bufsize and then stick to it. (Drill > doesn't do this because it's a diagnostic tool. It should do what you > tell it.) I tested with a "real resolver", the MacOSX 10.8.3 system resolver library is reasonably recent. When I set the nameserver to 8.8.8.8, res_search() DNS lookups time out. # networksetup -setdnsservers Wi-Fi 8.8.8.8 $ posttls-finger -t 30 -T 180 censored.org posttls-finger: warning: DANE TLSA lookup problem: Host or domain name not found. Name service error for name=_25._tcp.mx.censored.org type=TLSA: Host not found, try again posttls-finger: Failed to establish session to censored.org via mx.censored.org: TLSA lookup error for mx.censored.org:25 Using my OpenWRT router: # networksetup -setdnsservers Wi-Fi 192.168.1.1 $ posttls-finger -t 30 -T 180 censored.org posttls-finger: using DANE RR: _25._tcp.mx.censored.org -> _cacert-c3-tlsa.censored.org IN TLSA 2 0 0 ; sha256 digest ... posttls-finger: Connected to mx.censored.org[192.0.2.1]:25 posttls-finger: mx.censored.org[94.142.241.89]:25: depth=0 chain is trust-anchor signed posttls-finger: Verified TLS connection established to mx.censored.org[94.142.241.89]:25: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits) > > In any case the point > > is that it fails pretty badly, hence such RRs are unwise. > > I don't believe your illustration using drill shows what you think it > does. A properly-behaved resolver shouldn't fail, but should get the > TC-bit response and fall back to TCP. If system resolver libraries in MacOSX and NetBSD are not properly- behaved, my point still stands. The bottom line is that large DNS payloads are prone to timeout with no client recovery via TCP. > There's a live question as to whether falling back to TCP is > acceptable; I think the operator of the service gets to make that > determination, however. Not possible unless an answer comes back with the TC bit. The client initiates TCP retries, the server has no TCP listening port on the client to connect back to. Regardless of the details of the failure mode, the point is that it fails with real tests (I was testing the Postfix SMTP stack, and only used "drill" later to show the behaviour I found). Thus "X 0 0" with large certificates is not robust. If various DNS geo load balancers can't handle large UDP responses, publishing large DNS payloads is going to be a problem. The operational consequence for DANE is "shun IN TLSA X 0 0, it is fragile". -- Viktor. From viktor1dane@dukhovni.org Sat Jun 22 14:49:52 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 54BE321F9E51 for ; Sat, 22 Jun 2013 14:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 WQAJu4tRz7j7 for ; Sat, 22 Jun 2013 14:49:47 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 27A9721F9D89 for ; Sat, 22 Jun 2013 14:49:46 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id B5AAE2AAA1E; Sat, 22 Jun 2013 21:49:45 +0000 (UTC) Date: Sat, 22 Jun 2013 21:49:45 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130622214945.GW29420@mournblade.imrryr.org> References: <20130621145045.GK29420@mournblade.imrryr.org> <20130621145704.GN41900@mx1.yitter.info> <20130621163410.GO29420@mournblade.imrryr.org> <20130621174719.GQ41900@mx1.yitter.info> <20130621212755.GT29420@mournblade.imrryr.org> <20130621221204.GU41900@mx1.yitter.info> <20130622041735.GU29420@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130622041735.GU29420@mournblade.imrryr.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Large TLSA RRs (X 0 0) meet reality? 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, 22 Jun 2013 21:49:52 -0000 On Sat, Jun 22, 2013 at 04:17:35AM +0000, Viktor Dukhovni wrote: > > There's a live question as to whether falling back to TCP is > > acceptable; I think the operator of the service gets to make that > > determination, however. > > Not possible unless an answer comes back with the TC bit. The > client initiates TCP retries, the server has no TCP listening port > on the client to connect back to. > > Regardless of the details of the failure mode, the point is that > it fails with real tests (I was testing the Postfix SMTP stack, > and only used "drill" later to show the behaviour I found). Thus > "X 0 0" with large certificates is not robust. > > If various DNS geo load balancers can't handle large UDP responses, > publishing large DNS payloads is going to be a problem. The operational > consequence for DANE is "shun IN TLSA X 0 0, it is fragile". So as not to appear to be engaging in a point-by-point DNS-internals slugfest with Andrew (something neither I nor likely he have any interest in), I just want to return to the original point I was trying to make. Administrators of TLS servers should probably avoid "X 0 0" TLSA records, they are liable to not work (SRVFAIL) with various firewalls, load-balancers, ... at either the server or the resolver end. This does not mean that clients should not implement this combination, after all if the packets get through, by all means support the RR. Rather, server operators should not publish them for operational reliability reasons. So in practice I expect to see minimal deployment of these TLSA RR forms. -- Viktor. From marka@isc.org Sun Jun 23 18:03: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 1EBF921E8051 for ; Sun, 23 Jun 2013 18:03:03 -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 9p3qSqDY2xpy for ; Sun, 23 Jun 2013 18:02:58 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id F0C6721E8050 for ; Sun, 23 Jun 2013 18:02:57 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 83BEAC94AD for ; Mon, 24 Jun 2013 01:02:51 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1372035777; bh=hOqqO9YV85HKyOREYrGXvOFLFlhqJFq8VwmMyRsGzSw=; h=To:From:References:Subject:In-reply-to:Date; b=K7cN/W/B8NVYEB6DmYpCjD/DYDs+T2PqwXlQ4GTcz3XMWJ070yNSVSD6A5hphP8X4 +ANi/22h8O7CSbPaQsNzBrGWkQenh5Pt87ma3UitO/jVbeGxRktcBuyVyKbKbfGxm5 6yEPgHbQgt6fyfQa8JViriCHdIhVwooPVrwFZQRk= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP for ; Mon, 24 Jun 2013 01:02:51 +0000 (UTC) (envelope-from marka@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id C6F0B160051 for ; Mon, 24 Jun 2013 01:03:52 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id ex45iEFpnvAq for ; Mon, 24 Jun 2013 01:03:52 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 75A6F160088 for ; Mon, 24 Jun 2013 01:03:52 +0000 (UTC) X-Virus-Scanned: amavisd-new at zmx1.isc.org Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id hHTTYxKZz3cR for ; Mon, 24 Jun 2013 01:03:52 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) by zmx1.isc.org (Postfix) with ESMTPSA id 230C0160051 for ; Mon, 24 Jun 2013 01:03:52 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id EB97C362E20B for ; Mon, 24 Jun 2013 09:07:14 +1000 (EST) To: dane@ietf.org From: Mark Andrews References: <20130621145045.GK29420@mournblade.imrryr.org> <20130621145704.GN41900@mx1.yitter.info> <20130621163410.GO29420@mournblade.imrryr.org> <20130621174719.GQ41900@mx1.yitter.info> <20130621212755.GT29420@mournblade.imrryr.org> <20130621221204.GU41900@mx1.yitter.info> <20130622041735.GU29420@mournblade.imrryr.org> <20130622214945.GW29420@mournblade.imrryr.org> In-reply-to: Your message of "Sat, 22 Jun 2013 21:49:45 +0000." <20130622214945.GW29420@mournblade.imrryr.org> Date: Mon, 24 Jun 2013 09:07:14 +1000 Message-Id: <20130623230714.EB97C362E20B@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Subject: Re: [dane] Large TLSA RRs (X 0 0) meet reality? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jun 2013 01:03:03 -0000 In message <20130622214945.GW29420@mournblade.imrryr.org>, Viktor Dukhovni writes: > On Sat, Jun 22, 2013 at 04:17:35AM +0000, Viktor Dukhovni wrote: > > > > There's a live question as to whether falling back to TCP is > > > acceptable; I think the operator of the service gets to make that > > > determination, however. > > > > Not possible unless an answer comes back with the TC bit. The > > client initiates TCP retries, the server has no TCP listening port > > on the client to connect back to. > > > > Regardless of the details of the failure mode, the point is that > > it fails with real tests (I was testing the Postfix SMTP stack, > > and only used "drill" later to show the behaviour I found). Thus > > "X 0 0" with large certificates is not robust. > > > > If various DNS geo load balancers can't handle large UDP responses, > > publishing large DNS payloads is going to be a problem. The operational > > consequence for DANE is "shun IN TLSA X 0 0, it is fragile". > > So as not to appear to be engaging in a point-by-point DNS-internals > slugfest with Andrew (something neither I nor likely he have any > interest in), I just want to return to the original point I was > trying to make. Administrators of TLS servers should probably > avoid "X 0 0" TLSA records, they are liable to not work (SRVFAIL) > with various firewalls, load-balancers, ... at either the server > or the resolver end. > > This does not mean that clients should not implement this combination, > after all if the packets get through, by all means support the RR. > Rather, server operators should not publish them for operational > reliability reasons. So in practice I expect to see minimal > deployment of these TLSA RR forms. Or we could just make fragmented UDP work. Add a hop-by-hop option that contains the UDP ports then firewalls can be selective about which fragments they let thrrough. Fragments themselves are not the issue most of the time. It is ensuring the reply packet is part of a flow and the necessary information to do this is not in all of the fragments. One could do this with 8 octets per fragment for UDP fragments. DNS clients shouldn't have to put up with a DoS attack on them by the firewall. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From viktor1dane@dukhovni.org Sun Jun 23 20:33:54 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 223C021E8085 for ; Sun, 23 Jun 2013 20:33:54 -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 iCmBns0MVo+X for ; Sun, 23 Jun 2013 20:33:49 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id F124521E808D for ; Sun, 23 Jun 2013 20:33:48 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3C5F92AAB41; Mon, 24 Jun 2013 03:33:47 +0000 (UTC) Date: Mon, 24 Jun 2013 03:33:47 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130624033347.GA29420@mournblade.imrryr.org> References: <20130621145045.GK29420@mournblade.imrryr.org> <20130621145704.GN41900@mx1.yitter.info> <20130621163410.GO29420@mournblade.imrryr.org> <20130621174719.GQ41900@mx1.yitter.info> <20130621212755.GT29420@mournblade.imrryr.org> <20130621221204.GU41900@mx1.yitter.info> <20130622041735.GU29420@mournblade.imrryr.org> <20130622214945.GW29420@mournblade.imrryr.org> <20130623230714.EB97C362E20B@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130623230714.EB97C362E20B@drugs.dv.isc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Large TLSA RRs (X 0 0) meet reality? 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, 24 Jun 2013 03:33:54 -0000 On Mon, Jun 24, 2013 at 09:07:14AM +1000, Mark Andrews wrote: > > This does not mean that clients should not implement this combination, > > after all if the packets get through, by all means support the RR. > > Rather, server operators should not publish them for operational > > reliability reasons. So in practice I expect to see minimal > > deployment of these TLSA RR forms. > > Or we could just make fragmented UDP work. Add a hop-by-hop option > that contains the UDP ports then firewalls can be selective about > which fragments they let thrrough. Fragments themselves are not > the issue most of the time. It is ensuring the reply packet is > part of a flow and the necessary information to do this is not in > all of the fragments. One could do this with 8 octets per fragment > for UDP fragments. > > DNS clients shouldn't have to put up with a DoS attack on them by > the firewall. I agree that UDP fragments should work, but I can't honestly say that this is an alternative to recommending that administrators not deploy "IN TLSA X 0 0" certificate associations. Devices that don't support UDP fragments are going to be with us for a long time, much longer than the 5 year horizon for DNSSEC and DANE to begin to become mainstream (or else proved unusable and forgotten). Sadly we have an Internet that evolved, not an Internet that might have been designed with 20-20 hindsight. -- Viktor. From marka@isc.org Sun Jun 23 22:25:54 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 7F3C711E811B for ; Sun, 23 Jun 2013 22:25:53 -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 BpNKNCjaBLMd for ; Sun, 23 Jun 2013 22:25:49 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 1776611E80D3 for ; Sun, 23 Jun 2013 22:25:49 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 1FEA9C9422 for ; Mon, 24 Jun 2013 05:25:40 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1372051548; bh=Vc19oS8ZuzXnsLZnSi5e8shsCyGd1oa1aXClSCv5fyo=; h=To:From:References:Subject:In-reply-to:Date; b=Vs7DRFyPBIzXE4lKsVTimne/kGJyvF7Fif/lYeiLderlVjhWQLANebBOH1PmAEhbs /L0oQuvvDW5Sg7oGcMcMzJOGEeZdK5smQeM5Osrh6WKmv5K7C6S/w78+2LGd/hcnQZ ABeNQYlkUGlq8U3mQvSGV9xODfYa37qYx/w+9NyQ= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP for ; Mon, 24 Jun 2013 05:25:40 +0000 (UTC) (envelope-from marka@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 3FEB2160087 for ; Mon, 24 Jun 2013 05:26:42 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id PBIW9iiBdeiW for ; Mon, 24 Jun 2013 05:26:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id A0687160056 for ; Mon, 24 Jun 2013 05:26:40 +0000 (UTC) X-Virus-Scanned: amavisd-new at zmx1.isc.org Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id s5F1c0ejbjJD for ; Mon, 24 Jun 2013 05:26:40 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) by zmx1.isc.org (Postfix) with ESMTPSA id 3ED08160051 for ; Mon, 24 Jun 2013 05:26:40 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id AE5AF36327AE for ; Mon, 24 Jun 2013 15:25:33 +1000 (EST) To: dane@ietf.org From: Mark Andrews References: <20130621145045.GK29420@mournblade.imrryr.org> <20130621145704.GN41900@mx1.yitter.info> <20130621163410.GO29420@mournblade.imrryr.org> <20130621174719.GQ41900@mx1.yitter.info> <20130621212755.GT29420@mournblade.imrryr.org> <20130621221204.GU41900@mx1.yitter.info> <20130622041735.GU29420@mournblade.imrryr.org> <20130622214945.GW29420@mournblade.imrryr.org> <20130623230714.EB97C362E20B@drugs.dv.isc.org> <20130624033347.GA29420@mournblade.imrryr.org> In-reply-to: Your message of "Mon, 24 Jun 2013 03:33:47 +0000." <20130624033347.GA29420@mournblade.imrryr.org> Date: Mon, 24 Jun 2013 15:25:33 +1000 Message-Id: <20130624052533.AE5AF36327AE@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Subject: Re: [dane] Large TLSA RRs (X 0 0) meet reality? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jun 2013 05:25:54 -0000 In message <20130624033347.GA29420@mournblade.imrryr.org>, Viktor Dukhovni writ es: > On Mon, Jun 24, 2013 at 09:07:14AM +1000, Mark Andrews wrote: > > > > This does not mean that clients should not implement this combination, > > > after all if the packets get through, by all means support the RR. > > > Rather, server operators should not publish them for operational > > > reliability reasons. So in practice I expect to see minimal > > > deployment of these TLSA RR forms. > > > > Or we could just make fragmented UDP work. Add a hop-by-hop option > > that contains the UDP ports then firewalls can be selective about > > which fragments they let thrrough. Fragments themselves are not > > the issue most of the time. It is ensuring the reply packet is > > part of a flow and the necessary information to do this is not in > > all of the fragments. One could do this with 8 octets per fragment > > for UDP fragments. > > > > DNS clients shouldn't have to put up with a DoS attack on them by > > the firewall. > > I agree that UDP fragments should work, but I can't honestly say > that this is an alternative to recommending that administrators > not deploy "IN TLSA X 0 0" certificate associations. Devices that > don't support UDP fragments are going to be with us for a long > time, much longer than the 5 year horizon for DNSSEC and DANE to > begin to become mainstream (or else proved unusable and forgotten). > > Sadly we have an Internet that evolved, not an Internet that might > have been designed with 20-20 hindsight. Stub resolvers just need to advertise UDP buffer sizes that work for the firewalls they deploy. Extend DHCP/RA nameserver information to have a edns udp size. Those behind broken firewalls can set to a small value. Those that are not behind broken firewalls can set it to a sane value. We could add EDNS rcode that firewalls could return to say "EDNS UDP too big" along with a working EDNS size. Firewalls would intercept the query and return a reply to it with this rcode set. Firewalls could participate in the protocol instead of destroying it. Mark > -- > Viktor. > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From benl@google.com Mon Jun 24 01:13: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 6300521F9FDE for ; Mon, 24 Jun 2013 01:13:19 -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 NOGoUGwx3BOf for ; Mon, 24 Jun 2013 01:13:18 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF6521F9A72 for ; Mon, 24 Jun 2013 01:11:53 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id x12so24295938ief.12 for ; Mon, 24 Jun 2013 01:11:49 -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=rM1xo7RMQNpCqTPK2NXQxWYyZNSIi5K0Kdg8niwxvjs=; b=IxpfxPTcaQ58NIVsN71L1U0lzhRjfceYc4VBINgR1UUEB3zTc/9fxzqiYaFj14sBYS Y6UD0FJkdRB7e+9l9MNsJz0XBtWkn+R3xtTaQgugfK8j729h4BAdkN6m2LZ1Pt1A5dXW IzI+YrcnNFFV8dghlTColnYM3Np98PLuAG2QEf+JxV1AKijWVy1srGAQPww0i4OF+rpq hf9AKeBVHQOWpea2TQaCX2gyp/PPKcUuFwefs4/tRMZ7QZC39vEAmRhAMLPE8yuFppf+ QBbwCt4g4wdX4AOfHcU06OrJNuElg5DSIBU2g8oQ8FdqHRovBHrUwVBMLlxey9HvWne1 c2+A== 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=rM1xo7RMQNpCqTPK2NXQxWYyZNSIi5K0Kdg8niwxvjs=; b=UjicuU92Fjz7ILx7EIaqoZ5tVHAktgFhFuXpsotbuRiBi09HPwUcJm4CAqQbRNzYZm Lkfr07KD8PJUUq6LFMYRSRH/p2kxRdz6GR6mAINIssjxCnL40pgW60q2sK2ocpDTQE9S 1DCJClbqwESmOcdywmj3KsOc2lXQqInTiJwsImighdVCf64Mb2ukANGe31SujScxSdQ3 +mT3lZ/F59rgJV+NcOG+WNHjw4PMnSxg6uTz3FYZC0tfQzGY7+JX620o8newc6wgvXgR 5Wm9o6Lhq0cvjKL8Hm6Sk/RYVWT6mYEPCSkw3jGQbSuBzCYK8haH6srog+DzmDsT4uJJ KyrA== MIME-Version: 1.0 X-Received: by 10.50.114.229 with SMTP id jj5mr4957712igb.36.1372061509343; Mon, 24 Jun 2013 01:11:49 -0700 (PDT) Received: by 10.64.42.72 with HTTP; Mon, 24 Jun 2013 01:11:49 -0700 (PDT) In-Reply-To: <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> <20130530170252.GK9380@mournblade.imrryr.org> Date: Mon, 24 Jun 2013 09:11:49 +0100 Message-ID: From: Ben Laurie To: IETF DANE WG list Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmYEb7YIQQ7r4sHKV/L1LpXDy+IXvgPCRAO+skNakGuQHktEfZTS+TLcxM7PlzRtwSyFS6F1Cxs0o6D+LXxgcM5fesytz/chZseM2GhJpRyL0/yD4c8xnME+jEw+3Ed/0xa5vYmu40Pom4ZcaOpCH+liuC8DaEqideMnUj8t6uoggmR/vLarCK3IvLAz1wEjyI04Z8h 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: Mon, 24 Jun 2013 08:13:20 -0000 On 30 May 2013 18:02, Viktor Dukhovni wrote: > 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. I didn't respond to this at the time, because I wanted numbers rather than handwaving. Now I have some numbers. :-) Our experience is that ~4% of clients cannot retrieve arbitrary DNSSEC records from their configured resolver. Independently, we have surveyed the ability of clients to contact Google on port 53 (i.e. I don't know how these numbers relate to the 4% but clearly the prognosis is not good): ~13% of the time, UDP doesn't work, and ~60% of the time TCP doesn't work. I think this effectively rules out any reliance on DNS, leaving aside all other considerations. It remains my considered opinion that we can deploy CT a lot faster than we can fix this. From olaf@NLnetLabs.nl Mon Jun 24 01:48: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 5EF3A21E80D0 for ; Mon, 24 Jun 2013 01:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 9TAYY99hBX8B for ; Mon, 24 Jun 2013 01:48:45 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2508421F9377 for ; Mon, 24 Jun 2013 01:46:34 -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 r5O8kUaD094952 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 24 Jun 2013 10:46:31 +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 r5O8kUaD094952 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1372063592; bh=yEDbOIUZ11kHml5XUqJhFDe8+0IqXTYjoeAzREpr46U=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=GvRJuhAFwTV/+oS04iJjKm4V+JAcUQNgO20CQWKKWCMTyPPMxEu/movxi1fBsP6GL F6e3XfG3OUCCv2aS/b6d+/sNWyv2aSUSFYZ6vPaJYrMY5ux5cW4kCNEekyvsYnZRv/ /BdIaweFqOGm0+wZmvLxR1kQLgBs4+ZfQ/KR/w+g= Content-Type: multipart/alternative; boundary="Apple-Mail=_32F0E301-1880-4ADC-A6C8-1942D5B20B43" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Olaf Kolkman In-Reply-To: Date: Mon, 24 Jun 2013 10:46:30 +0200 Message-Id: <87C21F01-D323-4BC0-B583-C943776C12AF@NLnetLabs.nl> 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: Ben Laurie X-Mailer: Apple Mail (2.1508) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Mon, 24 Jun 2013 10:46:32 +0200 (CEST) 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: Mon, 24 Jun 2013 08:48:47 -0000 --Apple-Mail=_32F0E301-1880-4ADC-A6C8-1942D5B20B43 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 24, 2013, at 10:11 AM, Ben Laurie wrote: > I didn't respond to this at the time, because I wanted numbers rather > than handwaving. Now I have some numbers. :-) >=20 > Our experience is that ~4% of clients cannot retrieve arbitrary DNSSEC > records from their configured resolver. Independently, we have > surveyed the ability of clients to contact Google on port 53 (i.e. I > don't know how these numbers relate to the 4% but clearly the > prognosis is not good): ~13% of the time, UDP doesn't work, and ~60% > of the time TCP doesn't work. >=20 > I think this effectively rules out any reliance on DNS, leaving aside > all other considerations. Ben, We could have a long philosophical debate on that last statement, e.g. = on whether innovation on the core of the Internet is still possible but = that is likely to be out of scope for this list. ;-) The reason for this reply is about the numbers you report. I am not doubting those, on first sight they seem plausible. However, I = would like to see a more detailed description of measurement methodology = and an explanation of the effects causing this. Will there be a paper = forthcoming? I am specifically interested possible workarounds around = the blockage, that would be valuable input to some of the last-mile work = Labs is interested in. --Olaf ________________________________ "When you're NAT on the net, you're NOT on the net" -- Hugh Daniel=20 _______________________=20 Olaf Kolkman -- NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail=_32F0E301-1880-4ADC-A6C8-1942D5B20B43 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii benl@google.com> wrote:
I didn't respond to this at = the time, because I wanted numbers rather
than handwaving. Now I have = some numbers. :-)

Our experience is that ~4% of = clients cannot retrieve arbitrary DNSSEC
records from their configured = resolver. Independently, we have
surveyed the ability of = clients to contact Google on port 53 (i.e. I
prognosis is not good): ~13% of the = time, UDP doesn't work, and ~60%
of the time TCP doesn't = work.

I think this effectively = rules out any reliance on DNS, leaving aside
________________________________
"When you're NAT = on the net, you're NOT on the net"  -- = Hugh Daniel 
_______________________ 
O= laf Kolkman -- NLnet Labs
<= br>







= --Apple-Mail=_32F0E301-1880-4ADC-A6C8-1942D5B20B43-- From benl@google.com Mon Jun 24 02:24: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 CDEDD11E80E7 for ; Mon, 24 Jun 2013 02:24:23 -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 u+VKqoaNixwO for ; Mon, 24 Jun 2013 02:24:19 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 8F34211E80D9 for ; Mon, 24 Jun 2013 02:24:09 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id c10so24103922ieb.38 for ; Mon, 24 Jun 2013 02:24:08 -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=SXmsNfsbajOuUKWg9THPJ2C0cW3EnRuXGR3YjJ06Hic=; b=jf4FNvL0M5nPdJcXAStmRgHlcp/6PTovJypmbMcZsGRPw17m4/ftvngMLzeP7WMOef nN/coRi1DMOYasqO9YSxRYNDmJrlSZWAMBXEzJ9x/ZVmdJpVHLHk3YCemMp9Lju6ODw8 EMHGJJ2qDpxcFthUnIy08aqcySlyQwrvI5gPe+gNl1/Av3QgQuFFykYjOig3GmrLsNW2 rfUq1v2PhOyztGOJa4j2U5sTpw8wKyxSWMtoHdW+cgWpWv1pMTRBmzSeobiVaeAZODBz trl8fRT0P/e1e/tw+AaJqAg6SY7OawTG7Mz3LUEZoqRoNExpO/JgaUWqqv5EYKEdrW8q cspw== 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=SXmsNfsbajOuUKWg9THPJ2C0cW3EnRuXGR3YjJ06Hic=; b=mHU04BAY47CzAeaWfFzgfeK6fCtnfJI97k49DEFr7G7lEtAaOgrb3sCjDOqx+yIUvr sQmdYxtM/k/r+YdPLndIoo8TVg+O5YsXpSe3xwRWVVYBHK24ghevFRDcZKPM8dzMDJoP kChPYefRn343hSxrb0wNh5YYSOJQjmQJfBp8flhjKrdMWFFduHpPTHVME2BRf3ruTJpU FOAOSgiKypwCrbAi+hIpciw506qejpKOaKW+Y33XzEIcsTI/q0w0tdFpmgm5WemnlzrW ueGqrGnjZ+0FTd+x9BG+kghouUMw9aaUNZNxCgs0RrdnaN2B2MyiWrPtnUb+do1L6aKV gtug== MIME-Version: 1.0 X-Received: by 10.50.154.106 with SMTP id vn10mr5193583igb.0.1372065847950; Mon, 24 Jun 2013 02:24:07 -0700 (PDT) Received: by 10.64.42.72 with HTTP; Mon, 24 Jun 2013 02:24:07 -0700 (PDT) In-Reply-To: <87C21F01-D323-4BC0-B583-C943776C12AF@NLnetLabs.nl> 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> <87C21F01-D323-4BC0-B583-C943776C12AF@NLnetLabs.nl> Date: Mon, 24 Jun 2013 10:24:07 +0100 Message-ID: From: Ben Laurie To: Olaf Kolkman Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQl/HK6CYukBwVOpikuTdDTi9R5NypVhphaxNf9RIsDKyqzDGr53XaoVZKHDXc8gCT3bRgkhuDHdCEMLqMFN0QltAi5bM59/XhMyUrT0wO20iyPtftf9dWtqiPWR00afCMNueRb0RMdh1EdTey+8wej6MkQQBj2PfweKFx2Vq0Jn3jh4yAIWSbir+ai1UoOKKcTDD0Zw 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: Mon, 24 Jun 2013 09:24:24 -0000 On 24 June 2013 09:46, Olaf Kolkman wrote: > > On Jun 24, 2013, at 10:11 AM, Ben Laurie wrote: > > I didn't respond to this at the time, because I wanted numbers rather > than handwaving. Now I have some numbers. :-) > > Our experience is that ~4% of clients cannot retrieve arbitrary DNSSEC > records from their configured resolver. Independently, we have > surveyed the ability of clients to contact Google on port 53 (i.e. I > don't know how these numbers relate to the 4% but clearly the > prognosis is not good): ~13% of the time, UDP doesn't work, and ~60% > of the time TCP doesn't work. > > I think this effectively rules out any reliance on DNS, leaving aside > all other considerations. > > > > Ben, > > We could have a long philosophical debate on that last statement, e.g. on > whether innovation on the core of the Internet is still possible but that is > likely to be out of scope for this list. ;-) Well, I did mean "right now", and innovation is mostly not about "right now". So we may well violently agree :-) > The reason for this reply is about the numbers you report. > > I am not doubting those, on first sight they seem plausible. However, I > would like to see a more detailed description of measurement methodology and > an explanation of the effects causing this. Will there be a paper > forthcoming? I am specifically interested possible workarounds around the > blockage, that would be valuable input to some of the last-mile work Labs is > interested in. These are measurements done for other reasons that happen to inform this particular problem - I am not aware of any paper planned. From viktor1dane@dukhovni.org Mon Jun 24 06:54: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 304B011E812F for ; Mon, 24 Jun 2013 06:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 QuSOATCeCmbB for ; Mon, 24 Jun 2013 06:54:00 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB4C11E8151 for ; Mon, 24 Jun 2013 06:52:53 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 833B42AAAF5; Mon, 24 Jun 2013 13:52:49 +0000 (UTC) Date: Mon, 24 Jun 2013 13:52:49 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130624135249.GD29420@mournblade.imrryr.org> References: <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> 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: Mon, 24 Jun 2013 13:54:05 -0000 On Mon, Jun 24, 2013 at 09:11:49AM +0100, Ben Laurie wrote: > > 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. > > I didn't respond to this at the time, because I wanted numbers rather > than handwaving. Now I have some numbers. :-) > > Our experience is that ~4% of clients cannot retrieve arbitrary DNSSEC > records from their configured resolver. Isn't this rather good news? Even now, with little DNSSEC use in last mile environments, already 96% of clients can retrieve DNSSEC records! It is unlikely to get worse, especially if browsers start making DNSSEC features available to early adopters who can report problems to their ISPs for remediation. > I think this effectively rules out any reliance on DNS, leaving aside > all other considerations. Absolute "reliance", for each and every end-user all the time sure. Even if DNSSEC faced no network operator impedance, there are today too few domains that are DNSSEC signed for DANE in browsers to secure "the web". Similarly, even with the CT specification published, it will be some time before the majority of web servers are CT capable. > It remains my considered opinion that we can deploy CT a lot faster > than we can fix this. CT and DANE address different problems, the choice between CT and DANE is IMHO a false dichotomy. I see little reason to choose between them. Why not implement both? -- Viktor. From bry8star@inventati.org Mon Jun 24 06: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 8D87B11E814E for ; Mon, 24 Jun 2013 06:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.357 X-Spam-Level: X-Spam-Status: No, score=-2.357 tagged_above=-999 required=5 tests=[AWL=0.242, 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 jbysFSbta9Iy for ; Mon, 24 Jun 2013 06:56:04 -0700 (PDT) Received: from diserzione.investici.org (diserzione.investici.org [IPv6:2002:52dd:6399::1]) by ietfa.amsl.com (Postfix) with ESMTP id 19A1A21E80ED for ; Mon, 24 Jun 2013 06:55:42 -0700 (PDT) Received: from [82.221.99.153] (diserzione [82.221.99.153]) (Authenticated sender: bry8star@inventati.org) by localhost (Postfix) with ESMTPSA id 627BC1800B3 for ; Mon, 24 Jun 2013 13:55:28 +0000 (UTC) X-DKIM: Sendmail DKIM Filter v2.8.2 diserzione.investici.org 627BC1800B3 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inventati.org; s=stigmate; t=1372082131; bh=tCwZ2GSrDIwiCVgHKEBCKv+3pFfCMPo7m0mEPi3sfcU=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject:References: In-Reply-To:Content-Type; b=C3QxrYsS9wMpaTnteo3OeOaUQfUcbQXlf3HweUIi8So+S+HRjuKSB3BDmHCfgNtZ8 OOZH0aX1Cm07F/IoCOKg3VfltckQHBpR5EFJ/TtkouxkkMdPfwgBDMuIlLj+2o4YM8 +GB5zvw8I3n0/pYJKcnei5TNt+TvUcgPnCBkvqgE= Message-ID: <51C84F93.2020104@inventati.org> Date: Mon, 24 Jun 2013 06:54: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: <51BB7629.4070708@inventati.org> <51BB8001.8050004@inventati.org> In-Reply-To: <51BB8001.8050004@inventati.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2GLQBCGNOVXSHJXMOUJOC" Subject: Re: [dane] Pls Consider Supporting Intermediate TLS Certificate, TLSA Usage 4 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: Mon, 24 Jun 2013 13:56:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2GLQBCGNOVXSHJXMOUJOC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I've made mistake, on a response to a mistake, sorry :p forgot to use "Usage 4" indicator, the reason i posted this msg :( According to 1st message, correct records would be: Received from Bry8 Star, on 2013-06-14 12:59 PM: > Please consider to add support for Intermediate Authority TLSA RR Type.= >=20 =2E..... > A.1.2.3. Selector Type 64-74 & 128-138 (Intermediate Certificate) >=20 > For an example, if such certificate chain is used for a domain: >=20 =2E.. if such TLS/SSL certificate ... > EE <-- IA-B <-- IA-A <-- CA/TA. >=20 > It can also be represented in this form: >=20 > Level-0 <- Level-1 <- Level-2 <- Level-3. >=20 > Then, TLSA RR examples: >=20 > EE, end entity, Level-0 certificate: >=20 > _443._tcp.www.example.com. IN TLSA ( > 1 0 0 30820307308201efa003020102020... ) >=20 > IA-B, second intermediate authority certificate, which signed the EE > certificate, at level-1: >=20 > _443._tcp.www.example.com. IN TLSA ( > 64 0 0 30820454308202BC020900AB58D... ) >=20 _443._tcp.www.example.com. IN TLSA ( 4 64 0 30820454308202BC020900AB58D... ) > IA-A, first intermediate authority certificate, at Level-2: >=20 > _443._tcp.www.example.com. IN TLSA ( > 127 0 0 8755CDAA8FE24EF16CC0F2C9180... ) >=20 >=20 _443._tcp.www.example.com. IN TLSA ( 4 65 0 8755CDAA8FE24EF16CC0F2C9180... ) > TA root certificate, at Level-3: >=20 > _443._tcp.www.example.com. IN TLSA ( > 2 0 0 D2ABDE240D7CD3EE6B4B28C54DF... ) >=20 > or, CA root certificate, at Level-3: >=20 > _443._tcp.www.example.com. IN TLSA ( > 0 0 0 D2ABDE240D7CD3EE6B4B28C54DF... ) > - - - - - - - - - - - - - - - >=20 >=20 =2E... _port._proto.[host.]zone.TLD. [TTL] IN TLSA U S M C_A_D DANE/TLSA's one of the goal/purpose is to increase encryption security by eliminating confusions, by adding exact identifiable code for each used TLS public key/cert/component by a server/service software. So nothing will be done that would increase confusion. So TLS related components which are used, EACH will be VERY clearly defined using multiple TLSA dns records, so that there is no confusion, and so that there is no undefined component/portion. If DNS traffic need to be reduced (because of such as, older hardware or narrow bandwidth), zone-operator(s) can use different matching-Type other than 0. In such case, my own preference will be to use : server SSL cert's public-key portion's full DER (S is 0, M is 0) in EE (U is 1 or 3) TLSA dns rr, and for other SSL cert in chain, i would specify M as 1 or 2 and use relevant 256-bit or 512-bit hash in C_A_D. If "Usage 4" (for declaring Intermediate SSL cert) is not required, then, What current DANE (TLSA) related records can be declared/published for declaring the entire mentioned TLS / SSL cert chain ? where, more than one Intermediate TLS/SSL cert already exist in a SSL cert chain. Please show exact example based on SSL cert chain mentioned here : EE <-- IA-B <-- IA-A <-- CA/TA. How to very clearly & very definitively specify in DNS, each component of an entire cert chain ? including clear indication of what SSL cert is after what in a TLS chain ? One of the main objective for adding all these TLSA related DNS records in early, is to reduce, future frequent steps of adding various TLSA related dns records. Another one of the main reason, to declare every approved SSL cert very clearly, which is after what, ... so that, there is no chance of confusion, so that, every/each component of an entire TLS cert chain used by a TLS service software, can be completely 100% authenticated against pre-declared TLSA DNS records. As a zone/DNS/domain-name(s) owner/holder/operator/administrator, I mostly want to carry out DNSSEC KSK/ZSK re-signing & rollover related operations, and spend lesser time on adding/removing various TLSA DNS records too frequently, and also want to reduce consequential steps/operations after such changes, doing again & again too frequently. Based on existing used SSL certs for a specific port for a specific server software, related multiple TLSA dns entries will be decided & added, (and server will be tested if it can withstand for certain numbers of clients & traffic), and then a stable & optimized solution would be applied and it will not be touched/changed until a SSL/TLS cert or component of a chain is changed. TLSA dns record for EE/Server SSL/TLS cert for a specific port & service, should not be required to change before approximately either every 9 months (or 1 yr), or, 18 months (or 2 yrs). Unless, SSL / TLS cert (server's private_keys) compromise occurred or a fault/attack/exploit is/are found, then, obviously new EE/Server TLS cert will need to be created, and older ones revoked, and then, newer EE/Server TLSA DNS records are needed to be added into zone's/domain-name's DNS, and re-sign zone with new KSK/ZSK, ... My logic behind mentioned 9 or 18 months, is, since every (approximately around) 18 months, computational FLOPS/power significantly changes/increases, so should EE/Server TLS/SSL cert's strength. -- Bright Star. ------enig2GLQBCGNOVXSHJXMOUJOC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJRyE+lAAoJEID2ikYfWSP6Dg4P/RBdRhOS5ecazHTPSXpun2KS YFSK5iA2d8ifgFJNjJ2K/aGmzHR2nwdPvAnAu9BrtZ/13rSaYsYxHHfktGSLfgOU FWY/663/aADaFyyEtwyjNllJCkF8M3W5IsMHbCz4GBZ1/grY2uIszrkiyf99nGnh En6xv/FXDbYLSoEKuKRbqpl76oU4/VLQGgQ2VUkALbUpS0asL8FhW4uM1DtYKO0w iUvdrLMLIne/w1/y3GuUQVYovzpXBNGe+yllWibaXx06M8gz78pSZ393iKsvqyVI 4eENRN2zDxTH8IZJ4JSYm0bIIYNWa/rSGTgupeA6N6Qfc58AGefGy64h/D2nprYc nED8r3xTAYgtv4dC08EtSuycEvB3WWO8cnDVA8wdUY3beZUh6XTL6CXwcVJs33/4 Z4JUA40GP6GUmBprNPlI6qkSodCytsjjkb9PyZZtd9RoCZMATb1Bmo7cxCA9M3tL IFPMMtmXT086LW0vT4hfuR6hAp/YjVIoqTRxj0iA1vQzwn9ZkN/rxv6eloefPNq4 0UuNv8n+DlmeLgC7716BCYC9TrtQi3AOzwJKsaaBssScxYagkW12zX0HjFF0Vy/+ /ySR++9lDwSr4Q6Rw3uOvAeoTeH7Oq2u9l1+uLKkCMja33ctOeyTjHMhX24XsZUz cfr9WkBK6p6tXPKD9Sz2 =E5t4 -----END PGP SIGNATURE----- ------enig2GLQBCGNOVXSHJXMOUJOC-- From viktor1dane@dukhovni.org Mon Jun 24 07:09: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 0234E21E80F8 for ; Mon, 24 Jun 2013 07:09:48 -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 KEL3FwqfU6tH for ; Mon, 24 Jun 2013 07:09:42 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id B819D21E80E9 for ; Mon, 24 Jun 2013 07:09:40 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 1D0EF2AAAF5; Mon, 24 Jun 2013 14:09:40 +0000 (UTC) Date: Mon, 24 Jun 2013 14:09:40 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130624140940.GE29420@mournblade.imrryr.org> References: <20130621145704.GN41900@mx1.yitter.info> <20130621163410.GO29420@mournblade.imrryr.org> <20130621174719.GQ41900@mx1.yitter.info> <20130621212755.GT29420@mournblade.imrryr.org> <20130621221204.GU41900@mx1.yitter.info> <20130622041735.GU29420@mournblade.imrryr.org> <20130622214945.GW29420@mournblade.imrryr.org> <20130623230714.EB97C362E20B@drugs.dv.isc.org> <20130624033347.GA29420@mournblade.imrryr.org> <20130624052533.AE5AF36327AE@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130624052533.AE5AF36327AE@drugs.dv.isc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Large TLSA RRs (X 0 0) meet reality? 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, 24 Jun 2013 14:09:48 -0000 On Mon, Jun 24, 2013 at 03:25:33PM +1000, Mark Andrews wrote: > > Sadly we have an Internet that evolved, not an Internet that might > > have been designed with 20-20 hindsight. > > Stub resolvers just need to advertise UDP buffer sizes that work for > the firewalls they deploy. Extend DHCP/RA nameserver information to > have a edns udp size. Those behind broken firewalls can set to > a small value. Those that are not behind broken firewalls can set > it to a sane value. > > We could add EDNS rcode that firewalls could return to say "EDNS > UDP too big" along with a working EDNS size. Firewalls would > intercept the query and return a reply to it with this rcode set. > Firewalls could participate in the protocol instead of destroying > it. The above still looks like wishful thinking. Sure the problems could be solved "in principle", but I see little chance of a solution in practice. The problem I observed was at the DNS nameserver end. My OpenWRT NAT router handles UDP fragments just fine. [ It also runs unbound and handles DNSSEC, so I don't normally use 8.8.8.8 as my nameserver, but the experiment was I believe worthwhile. ] I am afraid I see no alternatives to keeping DNS RRset sizes conservatively small. What could help is, and is a good idea to have on every machine is a local validating caching nameserver on 127.0.0.1:53 on every computer (even mobile devices). Unlike applications using limited functionality stub resolvers, a local cache can quickly learn whether its upstream forwarders support EDNS0 and what EDNS0 buffer sizes are viable. This should be done in a way that does not rely on any new features in network equipment between the device and the forwarder. And yet, it will still be prudent to not publish full certificates in DNS. -- Viktor. From viktor1dane@dukhovni.org Mon Jun 24 07:27: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 91FF111E80DF for ; Mon, 24 Jun 2013 07:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 WPNRjxhXAZ1C for ; Mon, 24 Jun 2013 07:27:15 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD6B21F9C44 for ; Mon, 24 Jun 2013 07:27:15 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 1C8062AAAF5; Mon, 24 Jun 2013 14:27:14 +0000 (UTC) Date: Mon, 24 Jun 2013 14:27:14 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130624142714.GF29420@mournblade.imrryr.org> References: <51BB7629.4070708@inventati.org> <51BB8001.8050004@inventati.org> <51C84F93.2020104@inventati.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51C84F93.2020104@inventati.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Pls Consider Supporting Intermediate TLS Certificate, TLSA Usage 4 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, 24 Jun 2013 14:27:20 -0000 On Mon, Jun 24, 2013 at 06:54:27AM -0700, Bry8 Star wrote: > I've made mistake, on a response to a mistake, sorry :p > forgot to use "Usage 4" indicator, the reason i posted this msg :( > This is a non-problem, so no solution is required. Once you've explicitly associated the leaf certificate via DNSSEC (an EE association), no further certificates are required to authenticate the peer. Any additional chain elements are just wasted bandwidth, and increase the risk of exceeding DNS payload limits. One of the key reasons that TA usages (0 and 2) are defined is that some operators will not want to have to update DNS records every time an EE certificate changes, so they publish a more stable issuing TA. If the DNS is to be updated anyway, simply publishing the EE certificate with usage 3 is sufficient, the rest of the chain can simply be omitted from DNS. With usage 3, DANE-aware clients don't need any additional certificates in the peer's chain. Clients that don't support DANE obviously can't benefit from a hypothentical usage 4. If your is to simplify server deployment, just create a self-signed certificate and publish "IN TLSA 3 1 1 ...". I think I can safely predict that the proposed usage 4 is not going to get any support in this working group. -- Viktor. From benl@google.com Mon Jun 24 07:29: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 9CFF321E812E for ; Mon, 24 Jun 2013 07:29:58 -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=[AWL=-0.000, 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 2oxhHluxSCGM for ; Mon, 24 Jun 2013 07:29:58 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id C994A21E812B for ; Mon, 24 Jun 2013 07:29:54 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id 10so25493062ied.28 for ; Mon, 24 Jun 2013 07:29:54 -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=63oyUGESV6HAg0vMDI9s8MiyZ4RQgVZDnhcXw6lLrjo=; b=DX34JZt1Z4hpGm6+kI0ZO2P0YlW882HcrJQlQUvNkiwl93Nk+rl7bCzdm+SAH03LI6 LJcr3Ni1X3Qz1KxPADfm2vzpKUiucHTK0UgAp0rdimIuVzBilt8aDxQ7Y00ozxfE34Qz WsWD5GrQLMeEL4GEJnFLuYgG+PyrWNQOWHdFsL+h9tmCA/OS5pxEkiK1+Urj96OAOYXI o0rmX/UTvCWSMwptUDkN72jgHVG7bQC9/8iw+PHVwAr7gfZzY4F3Ymx2X0Ylcbw/JACV iX11X6x013xhl7ul+IlulY6oKznO5mlG2r7I6Zf//yPfvnr9Z/qtN5uZzDMTH1MwfbP1 kk8w== 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=63oyUGESV6HAg0vMDI9s8MiyZ4RQgVZDnhcXw6lLrjo=; b=OH1KoAWuEwXI22qZZUzQIDOAOGL+445TpeXojlWR0xZjq4IAXZ1ce2ruXZD+kdVoz4 BoyzVjDl6l8Tym8Cw8l4hhpDKv9pDxGnu22lhVJLsdOxcx6LvdNwl72SA28Gd7lJOTd4 gy1IWDpl7pNpOT/Dj7+RuNkTOVVdjLLxlekMkkx9klBiSzbw7H2LvujotIk3alySrg/R EwSRgz7b5eQmNn1bSqY70vZhYleYsYcoXI5V/ExezRUL7lfwHMVmCdZ4DgBk6pWtL0b4 +6Zaa9eWjmSr3QaiJjoaMyKHi11wbG0jMTSplcfjnxtBxFaSPK1sJu+0RzL/sOhxCGbh +Rog== MIME-Version: 1.0 X-Received: by 10.42.232.142 with SMTP id ju14mr8277260icb.108.1372084194255; Mon, 24 Jun 2013 07:29:54 -0700 (PDT) Received: by 10.64.42.72 with HTTP; Mon, 24 Jun 2013 07:29:54 -0700 (PDT) In-Reply-To: <20130624135249.GD29420@mournblade.imrryr.org> References: <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> <20130624135249.GD29420@mournblade.imrryr.org> Date: Mon, 24 Jun 2013 15:29:54 +0100 Message-ID: From: Ben Laurie To: IETF DANE WG list Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlDJ2r8J22S8EN65HO7iCwMq4AtgibhATa3gQnq7w6jh18QdZmZJfD82dRh6v3SuMMpZ2GNzV1MaU3h6TnMB5COeihf9YOW9vseyD4azECc9qqKbQNP2qPjMAXrDUJOpyfv9qPvQgqXcMLkDIfHc9hLuUcSb222HrjTRMTcNVA7fOHAuzbknAOlAMrjueMDwakz5ND9 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: Mon, 24 Jun 2013 14:29:58 -0000 On 24 June 2013 14:52, Viktor Dukhovni wrote: > On Mon, Jun 24, 2013 at 09:11:49AM +0100, Ben Laurie wrote: > >> > 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. >> >> I didn't respond to this at the time, because I wanted numbers rather >> than handwaving. Now I have some numbers. :-) >> >> Our experience is that ~4% of clients cannot retrieve arbitrary DNSSEC >> records from their configured resolver. > > Isn't this rather good news? Even now, with little DNSSEC use in > last mile environments, already 96% of clients can retrieve DNSSEC > records! It is unlikely to get worse, especially if browsers start > making DNSSEC features available to early adopters who can report > problems to their ISPs for remediation. > >> I think this effectively rules out any reliance on DNS, leaving aside >> all other considerations. > > Absolute "reliance", for each and every end-user all the time sure. > Even if DNSSEC faced no network operator impedance, there are today > too few domains that are DNSSEC signed for DANE in browsers to secure > "the web". > > Similarly, even with the CT specification published, it will be > some time before the majority of web servers are CT capable. CT does not require web server modifications. >> It remains my considered opinion that we can deploy CT a lot faster >> than we can fix this. > > CT and DANE address different problems, the choice between CT and > DANE is IMHO a false dichotomy. I see little reason to choose > between them. Why not implement both? Sure. From warren@kumari.net Mon Jun 24 14:55: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 4CBBD11E8190 for ; Mon, 24 Jun 2013 14:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.373 X-Spam-Level: X-Spam-Status: No, score=-102.373 tagged_above=-999 required=5 tests=[AWL=0.226, 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 cmNBdHLrfP7U for ; Mon, 24 Jun 2013 14:55:16 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC9D11E818C for ; Mon, 24 Jun 2013 14:55:16 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.90]) by vimes.kumari.net (Postfix) with ESMTPSA id 7F5ED1B40341; Mon, 24 Jun 2013 17:55:15 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Warren Kumari In-Reply-To: <20130624142714.GF29420@mournblade.imrryr.org> Date: Mon, 24 Jun 2013 17:55:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <779F96A3-D7CB-4067-9D20-143182CA4AFD@kumari.net> References: <51BB7629.4070708@inventati.org> <51BB8001.8050004@inventati.org> <51C84F93.2020104@inventati.org> <20130624142714.GF29420@mournblade.imrryr.org> To: dane@ietf.org X-Mailer: Apple Mail (2.1508) Subject: Re: [dane] Pls Consider Supporting Intermediate TLS Certificate, TLSA Usage 4 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 21:55:21 -0000 On Jun 24, 2013, at 10:27 AM, Viktor Dukhovni = wrote: > On Mon, Jun 24, 2013 at 06:54:27AM -0700, Bry8 Star wrote: >=20 >> I've made mistake, on a response to a mistake, sorry :p >> forgot to use "Usage 4" indicator, the reason i posted this msg :( >>=20 >=20 > This is a non-problem, so no solution is required. Once you've > explicitly associated the leaf certificate via DNSSEC (an EE > association), no further certificates are required to authenticate > the peer. Any additional chain elements are just wasted bandwidth, > and increase the risk of exceeding DNS payload limits. >=20 > One of the key reasons that TA usages (0 and 2) are defined is that > some operators will not want to have to update DNS records every > time an EE certificate changes, so they publish a more stable > issuing TA. If the DNS is to be updated anyway, simply publishing > the EE certificate with usage 3 is sufficient, the rest of the > chain can simply be omitted from DNS. >=20 > With usage 3, DANE-aware clients don't need any additional = certificates > in the peer's chain. Clients that don't support DANE obviously > can't benefit from a hypothentical usage 4. If your is to simplify > server deployment, just create a self-signed certificate and publish > "IN TLSA 3 1 1 ...". >=20 > I think I can safely predict that the proposed usage 4 is not going > to get any support in this working group. >=20 I do not support the proposed usage 4. The utility seems marginal at = best, and IMO not worth changing anything over. Unless a large number of DANE participants speak up in support of this, = I'm asking that we drop this subject. I'd also like to point back at the pseudonym discussion. W > --=20 > Viktor. > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 --=20 Outside of a dog, a book is your best friend, and inside of a dog, it's = too dark to read=20 From bry8star@inventati.org Tue Jun 25 08:32: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 92E8B21F969F for ; Tue, 25 Jun 2013 08:32:02 -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 dI4xzpa6KPJH for ; Tue, 25 Jun 2013 08:32:00 -0700 (PDT) Received: from latitanza.investici.org (latitanza.investici.org [IPv6:2002:525e:f9ea::1]) by ietfa.amsl.com (Postfix) with ESMTP id 49F2721F94D3 for ; Tue, 25 Jun 2013 08:31:58 -0700 (PDT) Received: from [82.94.249.234] (latitanza [82.94.249.234]) (Authenticated sender: bry8star@inventati.org) by localhost (Postfix) with ESMTPSA id CA176980EF for ; Tue, 25 Jun 2013 15:31:50 +0000 (UTC) X-DKIM: Sendmail DKIM Filter v2.8.2 latitanza.investici.org CA176980EF DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inventati.org; s=stigmate; t=1372174317; bh=BOXZU8h8oSGlIKNsldESUe0Bqd+6+2WTTW1rl+VFh8U=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject: Content-Type; b=I9+xc7qTunWtQkV/FKoojfRnSPK85yUOYvVKV/tuOuy4XTuAlvmEpZyMU1KrMlkOL Mgr2KKvmcy7bb84SZPGywPCmW7B+VziRlKLt/me0bLVXfRY6C4c/Ajx1BmIi0buKoc xX+XexzGCeRjl54qqwQFzjSM7f+WTTbMn0du3hrc= Message-ID: <51C9B7B8.1040403@inventati.org> Date: Tue, 25 Jun 2013 08:31:04 -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: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2MFSCPFERDLBDWBILXESF" Subject: [dane] How to Reduce Multiple TA/CA "2 s m"/"0 s m" Or Same C_A_D TLSAs Using Wildcard TLSA 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: Tue, 25 Jun 2013 15:32:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2MFSCPFERDLBDWBILXESF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable When specifying multiple DANE TLSA records for various TLS / SSL supported encrypted communication: Then, if each service port has Two TLSAs, where, one "TLSA 2 s m" (or one "TLSA 0 s m") RR is for declaring Root-CA or TA TLS/SSL cert, and, another "TLSA 1 s m" (or one "TLSA 3 s m") is for declaring EE/Server TLS/SSL cert. Then, it results into lot of same "TLSA 2 s m" (or "TLSA 0 s m") RR for all those services/ports. And, if only one TLSA is declared for each service/port, even then, it results into lot of exact same C_A_D. What can be done to reduce it ? C_A_D =3D Certificate Association Data. SLD =3D Second/2nd Level Domain. TLD =3D Top Level Domain. [x] =3D The portion inside 3rd-Brace is optional. Depends on user's own preferences. TTL =3D Time To Live. [host.] =3D Third/3rd Level Domain / Service Domain / Hostname. EE =3D End Entity. Here, its used to indicate toward a service in a server. IA =3D Intermediate Authority. CA =3D Certificate Authority. TA =3D Trust Anchor. I see RFC 6698 Section A.2.1.3. (Provisioning TLSA Records with Wildcards) showing common location can be *._tcp.host.SLD.TLD. IN TLSA u s m C_A_D It can also be written like these: _port._proto.[host.]SLD.TLD. [TTL] IN TLSA u s m C_A_D *._proto.[host.]SLD.TLD. [TTL] IN TLSA u s m C_A_D And such TLS / SSL cert chain is in use: EE/Server <-- IA <-- CA/TA. or, Level-0 <- Level-1 <- Level-2. or, EE/Server {s1, s2, im1, im2, www, m} <-- IA (domA.tld) <-- CA/TA (Root-CA). A zone file: domA.tld. 3600 IN SOA s1.domA.tld. hostmaster.domA.tld. 2013052910 18000 3600 864000 3600 domA.tld. 3000 IN NS s1.domA.tld. domA.tld. 3000 IN NS s2.domA.tld. domA.tld. 300 IN A IP.ADRS_S-1_IPv4 domA.tld. 300 IN A IP.ADRS_S-2_IPv4 domA.tld. 300 IN A IP.ADRS_S-IM-1_IPv4 domA.tld. 300 IN A IP.ADRS_S-IM-2_IPv4 domA.tld. 300 IN AAAA IP::ADRS_S-1_IPv6 domA.tld. 300 IN AAAA IP::ADRS_S-2_IPv6 domA.tld. 300 IN AAAA IP::ADRS_S-IM-1_IPv6 domA.tld. 300 IN AAAA IP::ADRS_S-IM-2_IPv6 s1.domA.tld. 900 IN A IP.ADRS_S-1_IPv4 s2.domA.tld. 900 IN A IP.ADRS_S-2_IPv4 im.domA.tld. 900 IN A IP.ADRS_S-IM-1_IPv4 im2.domA.tld. 900 IN A IP.ADRS_S-IM-2_IPv4 s1.domA.tld. 900 IN AAAA IP::ADRS_S-1_IPv6 s2.domA.tld. 900 IN AAAA IP::ADRS_S-2_IPv6 im.domA.tld. 900 IN AAAA IP::ADRS_S-IM-1_IPv6 im2.domA.tld. 900 IN AAAA IP::ADRS_S-IM-2_IPv6 www.domA.tld. 300 IN CNAME domA.tld. m.domA.tld. 300 IN CNAME domA.tld. _http._tcp.domA.tld. 3600 IN SRV 0 0 80 www.domA.tld. _https._tcp.domA.tld. 3600 IN SRV 0 0 443 www.domA.tld. _http._tcp.www.domA.tld. 3600 IN SRV 0 0 80 www.domA.tld. _https._tcp.www.domA.tld. 3600 IN SRV 0 0 443 www.domA.tld. _http._tcp.m.domA.tld. 3600 IN SRV 0 0 80 m.domA.tld. _https._tcp.m.domA.tld. 3600 IN SRV 0 0 443 m.domA.tld. domA.tld. 3600 IN MX 10 s1.domA.tld. domA.tld. 3600 IN MX 20 s2.domA.tld. _smtp._tcp.domA.tld. 3600 IN SRV 10 0 25 s1.domA.tld. _smtp._tcp.domA.tld. 3600 IN SRV 20 0 25 s2.domA.tld. _smtp._tcp.s1.domA.tld. 3600 IN SRV 10 0 25 s1.domA.tld. _smtp._tcp.s1.domA.tld. 3600 IN SRV 20 0 25 s2.domA.tld. _smtp._tcp.s2.domA.tld. 3600 IN SRV 10 0 25 s2.domA.tld. _smtp._tcp.s2.domA.tld. 3600 IN SRV 20 0 25 s1.domA.tld. _submission._tcp.domA.tld. 3600 IN SRV 10 0 587 s1.domA.tld. _submission._tcp.domA.tld. 3600 IN SRV 20 0 587 s2.domA.tld. _submission._tcp.s1.domA.tld. 3600 IN SRV 10 0 587 s1.domA.tld. _submission._tcp.s1.domA.tld. 3600 IN SRV 20 0 587 s2.domA.tld. _submission._tcp.s2.domA.tld. 3600 IN SRV 10 0 587 s2.domA.tld. _submission._tcp.s2.domA.tld. 3600 IN SRV 20 0 587 s1.domA.tld. _imaps._tcp.domA.tld. 1200 IN SRV 0 0 993 s1.domA.tld. _imaps._tcp.domA.tld. 1200 IN SRV 5 0 993 s2.domA.tld. _imaps._tcp.s1.domA.tld. 1200 IN SRV 0 0 993 s1.domA.tld. _imaps._tcp.s1.domA.tld. 1200 IN SRV 5 0 993 s2.domA.tld. _imaps._tcp.s2.domA.tld. 1200 IN SRV 0 0 993 s2.domA.tld. _imaps._tcp.s2.domA.tld. 1200 IN SRV 5 0 993 s1.domA.tld. _pops._tcp.domA.tld. 1200 IN SRV 0 0 995 s1.domA.tld. _pops._tcp.domA.tld. 1200 IN SRV 5 0 995 s2.domA.tld. _pops._tcp.s1.domA.tld. 1200 IN SRV 0 0 995 s1.domA.tld. _pops._tcp.s1.domA.tld. 1200 IN SRV 5 0 995 s2.domA.tld. _pops._tcp.s2.domA.tld. 1200 IN SRV 0 0 995 s2.domA.tld. _pops._tcp.s2.domA.tld. 1200 IN SRV 5 0 995 s1.domA.tld. ; Skipping SMTP (Port 26) based 3rd email-server. _xmpp-client._tcp.domA.tld. 900 IN SRV 0 0 5222 im.domA.tld. _xmpp-client._tcp.domA.tld. 900 IN SRV 1 0 5222 im2.domA.tld. _xmpp-client._tcp.domA.tld. 900 IN SRV 2 0 15222 im.domA.tld. _xmpp-client._tcp.domA.tld. 900 IN SRV 3 0 15222 im2.domA.tld. _xmpp-client._tcp.im.domA.tld. 900 IN SRV 0 0 5222 im.domA.tld. _xmpp-client._tcp.im.domA.tld. 900 IN SRV 1 0 15222 im.domA.tld. _xmpp-client._tcp.im.domA.tld. 900 IN SRV 2 0 5222 im2.domA.tld. _xmpp-client._tcp.im.domA.tld. 900 IN SRV 3 0 15222 im2.domA.tld. _xmpp-client._tcp.im2.domA.tld. 900 IN SRV 0 0 5222 im2.domA.tld. _xmpp-client._tcp.im2.domA.tld. 900 IN SRV 1 0 15222 im2.domA.tld. _xmpp-client._tcp.im2.domA.tld. 900 IN SRV 2 0 5222 im.domA.tld. _xmpp-client._tcp.im2.domA.tld. 900 IN SRV 3 0 15222 im.domA.tld. _xmpp-server._tcp.domA.tld. 1800 IN SRV 0 0 5269 im.domA.tld. _xmpp-server._tcp.domA.tld. 1800 IN SRV 1 0 5269 im2.domA.tld. _xmpp-server._tcp.domA.tld. 1800 IN SRV 2 0 15269 im.domA.tld. _xmpp-server._tcp.domA.tld. 1800 IN SRV 3 0 15269 im2.domA.tld. _xmpp-server._tcp.im.domA.tld. 1800 IN SRV 0 0 5269 im.domA.tld. _xmpp-server._tcp.im.domA.tld. 1800 IN SRV 1 0 15269 im.domA.tld. _xmpp-server._tcp.im.domA.tld. 1800 IN SRV 2 0 5269 im2.domA.tld. _xmpp-server._tcp.im.domA.tld. 1800 IN SRV 3 0 15269 im2.domA.tld. _xmpp-server._tcp.im2.domA.tld. 1800 IN SRV 0 0 5269 im2.domA.tld. _xmpp-server._tcp.im2.domA.tld. 1800 IN SRV 1 0 15269 im2.domA.tld. _xmpp-server._tcp.im2.domA.tld. 1800 IN SRV 2 0 5269 im.domA.tld. _xmpp-server._tcp.im2.domA.tld. 1800 IN SRV 3 0 15269 im.domA.tld. ; And multiple SIP services are configured ; similar to above XMPP services. _sip._tcp.domA.tld. 1200 IN SRV 0 0 5060 im.domA.tld. _sip._tcp.domA.tld. 1200 IN SRV 1 0 5060 im2.domA.tld. _sip._tcp.domA.tld. 1200 IN SRV 2 0 15060 im.domA.tld. _sip._tcp.domA.tld. 1200 IN SRV 3 0 15060 im2.domA.tld. _sips._tcp.domA.tld. 1200 IN SRV 0 0 5061 im.domA.tld. _sips._tcp.domA.tld. 1200 IN SRV 1 0 5061 im2.domA.tld. _sips._tcp.domA.tld. 1200 IN SRV 2 0 15061 im.domA.tld. _sips._tcp.domA.tld. 1200 IN SRV 3 0 15061 im2.domA.tld. ; Skipping rest of SIP related SRV declarations. _irc._tcp.domA.tld. 1800 IN SRV 0 0 6667 im.domA.tld. _irc._tcp.domA.tld. 3600 IN SRV 1 0 6667 im2.domA.tld. _irc._tcp.domA.tld. 3600 IN SRV 2 0 6669 im.domA.tld. _irc._tcp.domA.tld. 3600 IN SRV 3 0 6669 im2.domA.tld. _irc._tcp.im.domA.tld. 1800 IN SRV 0 0 6667 im.domA.tld. _irc._tcp.im.domA.tld. 3600 IN SRV 1 0 6669 im.domA.tld. _irc._tcp.im.domA.tld. 3600 IN SRV 2 0 6667 im2.domA.tld. _irc._tcp.im.domA.tld. 3600 IN SRV 3 0 6669 im2.domA.tld. _irc._tcp.im2.domA.tld. 1800 IN SRV 0 0 6667 im2.domA.tld. _irc._tcp.im2.domA.tld. 3600 IN SRV 1 0 6669 im2.domA.tld. _irc._tcp.im2.domA.tld. 3600 IN SRV 2 0 6667 im.domA.tld. _irc._tcp.im2.domA.tld. 3600 IN SRV 3 0 6669 im.domA.tld. ; Skipping rest of IRC related SRV declarations.; ; RRSIGs are not mentioned, but they exist when DNSSEC signed. Here, "im" & "im2" both host are running same software based services, on multiple ports, for slightly better traffic handling, for slightly better QoS, and for load-balancing, and to overcome few other software limitations. What is the secure port 5223's service name ? of _xmpp-client (Port 5222). What is the secure port 6697's service name ? of _irc (Port 6667). So, instead of specifying TLSA for same TA crt like this example, in a zone file: _443._tcp.www.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt _443._tcp.www.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_www_domA_srvr-crt _443._tcp.m.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt _443._tcp.m.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_m_domA_srvr-crt _25._tcp.s1.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt _25._tcp.s1.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_s1_domA_srvr-crt _25._tcp.s2.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt _25._tcp.s2.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_s2_domA_srvr-crt _587._tcp.s1.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt _587._tcp.s1.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_s1_domA_srvr-crt _587._tcp.s2.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt _587._tcp.s2.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_s2_domA_srvr-crt _993._tcp.s1.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt _993._tcp.s1.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_s1_domA_srvr-crt _993._tcp.s2.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt _993._tcp.s2.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_s2_domA_srvr-crt _5223._tcp.im.domA.tld. 900 IN TLSA 2 0 1 C_A_D_of_TA-crt _5223._tcp.im.domA.tld. 900 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt _15223._tcp.im.domA.tld. 900 IN TLSA 2 0 1 C_A_D_of_TA-crt _15223._tcp.im.domA.tld. 900 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt _5223._tcp.im2.domA.tld. 900 IN TLSA 2 0 1 C_A_D_of_TA-crt _5223._tcp.im2.domA.tld. 900 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt _15223._tcp.im2.domA.tld. 900 IN TLSA 2 0 1 C_A_D_of_TA-crt _15223._tcp.im2.domA.tld. 900 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt _5269._tcp.im.domA.tld. 900 IN TLSA 2 0 1 C_A_D_of_TA-crt _5269._tcp.im.domA.tld. 900 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt _15269._tcp.im.domA.tld. 900 IN TLSA 2 0 1 C_A_D_of_TA-crt _15269._tcp.im.domA.tld. 900 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt _5269._tcp.im2.domA.tld. 900 IN TLSA 2 0 1 C_A_D_of_TA-crt _5269._tcp.im2.domA.tld. 900 IN TLSA 1 0 0 C_A_D_of_im_domA_srvr-crt _15269._tcp.im2.domA.tld. 900 IN TLSA 2 0 1 C_A_D_of_TA-crt _15269._tcp.im2.domA.tld. 900 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt _5061._tcp.im.domA.tld. 900 IN TLSA 2 0 1 C_A_D_of_TA-crt _5061._tcp.im.domA.tld. 900 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt _15061._tcp.im.domA.tld. 900 IN TLSA 2 0 1 C_A_D_of_TA-crt _15061._tcp.im.domA.tld. 900 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt _5061._tcp.im2.domA.tld. 900 IN TLSA 2 0 1 C_A_D_of_TA-crt _5061._tcp.im2.domA.tld. 900 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt _15061._tcp.im2.domA.tld. 900 IN TLSA 2 0 1 C_A_D_of_TA-crt _15061._tcp.im2.domA.tld. 900 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt _6697._tcp.im.domA.tld. 900 IN TLSA 2 0 1 C_A_D_of_TA-crt _6697._tcp.im.domA.tld. 900 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt _6699._tcp.im.domA.tld. 900 IN TLSA 2 0 1 C_A_D_of_TA-crt _6699._tcp.im.domA.tld. 900 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt _6697._tcp.im2.domA.tld. 900 IN TLSA 2 0 1 C_A_D_of_TA-crt _6697._tcp.im2.domA.tld. 900 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt _6699._tcp.im2.domA.tld. 900 IN TLSA 2 0 1 C_A_D_of_TA-crt _6699._tcp.im2.domA.tld. 900 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt =3D 48 lines. (Practical/real servers, which uses service location dns SRV declarations, for running multiple services on same machine, or, pointing toward multiple services on different machines, have much more such service ports, and will result into declaring same C_A_D again and again). Can those be implemented in common location like this (alternative) example ? *._tcp.www.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt _443._tcp.www.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_www_domA_srvr-crt *._tcp.m.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt _443._tcp.m.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_m_domA_srvr-crt *._tcp.s1.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt _25._tcp.s1.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_mail_domA_srvr-crt _587._tcp.s1.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_mail_domA_srvr-crt _993._tcp.s1.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_mail_domA_srvr-crt *._tcp.s2.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt _25._tcp.s2.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_mail_domA_srvr-crt _587._tcp.s2.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_mail_domA_srvr-crt _993._tcp.s2.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_mail_domA_srvr-crt *._tcp.im.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt _6697._tcp.im.domA.tld. 360 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt _6699._tcp.im.domA.tld. 360 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt _5223._tcp.im.domA.tld. 360 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt _15223._tcp.im.domA.tld. 360 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt _5269._tcp.im.domA.tld. 360 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt _15269._tcp.im.domA.tld. 360 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt _5061._tcp.im.domA.tld. 360 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt _15061._tcp.im.domA.tld. 360 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt *._tcp.im2.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt _6697._tcp.im2.domA.tld. 360 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt _6699._tcp.im2.domA.tld. 360 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt _5223._tcp.im2.domA.tld. 360 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt _15223._tcp.im2.domA.tld. 360 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt _5269._tcp.im2.domA.tld. 360 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt _15269._tcp.im2.domA.tld. 360 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt _5061._tcp.im2.domA.tld. 360 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt _15061._tcp.im2.domA.tld. 360 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt =3D 30 lines. And here, "im" host is using only one EE/Server TLS/SSL cert for its all encrypted services, (and so is "im2", "s1", "s2", "www" hosts), so can we reduce TLSA DNS declarations even further, like this ? *._tcp.www.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt *._tcp.www.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_www_domA_srvr-crt *._tcp.m.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt *._tcp.m.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_m_domA_srvr-crt *._tcp.s1.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt *._tcp.s1.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_s1_domA_srvr-crt *._tcp.s2.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt *._tcp.s2.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_s2_domA_srvr-crt *._tcp.im.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt *._tcp.im.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_im_domA_srvr-crt *._tcp.im2.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt *._tcp.im2.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_im2_domA_srvr-crt =3D 12 lines. Here "TLSA 1 s m" EE is used (instead of "TLSA 3 s m" EE), to instruct/indicate client-side, that they must check full TLS/SSL chain for this EE/Server TLS/SSL cert, (if client's user also have similar preference settings). (Based on my own limited understanding in this/these case), One of the way to say it, or, domain-owner is trying to say in this case : Hey TLSA/DANE-aware clients, first get EE/server TLS-cert, for example, for port 5223, from "TLSA 1 s m" DNS record and also from server's TLS secured port 5223, if it is a EE/Servr cert under another Root-CA or Intermediate cert, then in second-step, check at-first, if the same port (5223) have a "TLSA 2 s m" TA RR or a "TLSA 0 s m" CA RR present or not ? If yes/present, check validity of "TLSA 1 s m" based EE/Servr TLS cert and its chain, But if same port (5223) does not have a "TLSA 2 s m" or "TLSA 0 s m", then check in-second, for a TLSA in common location like "*._tcp.host.domain.tld." or in "*._tcp.domain.tld.", if found, check validity of Root-CA/TA/IA TLS-cert, and the EE TLS cert under it nad also check validity of TLS cert chain. And then on success, finally use EE/Servr TLS cert for encrypted communication for port 5223 based XMPP service. So my understanding, it will work, or be effective, only when DANE/TLSA-aware clients supports such/similar logic based provisional checking (or wildcard based checking). Is wildcard TLSA yet supported by any client-side ? Do "Extended DNSSEC Validator" addon for Firefox, or, Bloodhound browser (based on Firefox) understands & uses it (wildcard TLSA) to create TLS/SSL encrypted communication ? or, can they even use wildcard TLSA and DANE-logics/protocols yet ? Or, should i add nameserver functionality in each server, like "im1" and "im2" as well ? (like "s1" & "s2") and then define only "im" or "im2" sub-domain zone file with related DNS RR set only ? then main zone file's DNS rr can be reduced. And if wanted, wilcard usage can be avoided. Or, what alternative solution exist ? Please point out mistakes, errors, and, specify what is correct. Thanks in advance. -- Bright Star. ------enig2MFSCPFERDLBDWBILXESF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJRybfCAAoJEID2ikYfWSP6pzUP/2ElrvlweBeRushnvg9FVa4g j3iNO1zay65hzWhe88V1zSjaNGGnafiXhJAPsnpLNaA+xR7IhLbAoAyVQvYSX8iL Tgst3xeZeZtv1YGRHCoUTF7f4MF4ZQCLXLWqETuDc5Cd5iBQna+31us9ChpEvL6T R5JdtSq76jQZisE9r23/iRseSYvfG9hWfoXy711v34F5S4zpbAe09VQTpf9Z4yjy TPrHZ6cDPvKga/1qDnW2CLfxLnSq6mL6XE5qxJ8PJXpCPHPLS9HVFH7bXq49J4Y2 n3d1zqa7y4ws5v3ot+/w7FDKXyIjb67Rk464ueVRGmeuTzRnINOFxIiwgaOF6VG1 WXCINoqdMEsh4nLZWcRs7b+XUwUmjzTUbV5BBZmg81/JGW1A6GEx+Ohzn3+4Qu4L QnYUuugZ95bYpTrJGpBlxkwrN+wVCnMhEbmi234fP0jJIASxkJ9ylwckevtNhiMq oH7YWrCWJ/uHvIKm639/6qNcrr5Y0hJgzMoPCUD+/WcXpNKYUeqFI5QWiHETfPRG 7RQrvXImPptxtbkvJGVOs5HFb9kOjJPAifWuXJJJqaRtlWJNkcK209ueFnzuZhGO m8tiLP79KK9Sz0KqbdR/zp7zwjIKm/Tcu4BVqaLNr+4VbKoKgDVIxrnsJw6eyzcP XWQ4ZibxxEeu33RDhQBU =QNKa -----END PGP SIGNATURE----- ------enig2MFSCPFERDLBDWBILXESF-- From viktor1dane@dukhovni.org Tue Jun 25 10:12: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 03BB121F9E98 for ; Tue, 25 Jun 2013 10:12:42 -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 XFdjX8f0zTIa for ; Tue, 25 Jun 2013 10:12:36 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 4694F11E810D for ; Tue, 25 Jun 2013 10:12:29 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id C242E2AAC76; Tue, 25 Jun 2013 17:12:24 +0000 (UTC) Date: Tue, 25 Jun 2013 17:12:24 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130625171224.GP29420@mournblade.imrryr.org> References: <51C9B7B8.1040403@inventati.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51C9B7B8.1040403@inventati.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] How to Reduce Multiple TA/CA "2 s m"/"0 s m" Or Same C_A_D TLSAs Using Wildcard TLSA 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, 25 Jun 2013 17:12:42 -0000 On Tue, Jun 25, 2013 at 08:31:04AM -0700, Bry8 Star wrote: > Then, if each service port has Two TLSAs, where, one "TLSA 2 s m" > (or one "TLSA 0 s m") RR is for declaring Root-CA or TA TLS/SSL > cert, and, another "TLSA 1 s m" (or one "TLSA 3 s m") is for > declaring EE/Server TLS/SSL cert. Pick one model. Either publish TA associations (0 or 2) or EE associations (1 or 3). It makes little sense to publish both for any given service end-point. When using the same TA for multiple services, or the same EE public key for multiple services, you can consolidate TLSA RRs via CNAMEs, for example (real life): _25._tcp.open.nlnetlabs.nl. IN CNAME 3.1.1._dane.nlnetlabs.nl. 3.1.1._dane.nlnetlabs.nl. IN TLSA 3 1 1 0D1FCBD71686199607A132744A4918FC209565C91FA8E9FFEEA0AAFD6B9305F6 > So, instead of specifying TLSA for same TA crt like this example, in > a zone file: > > _443._tcp.www.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt Remember to include the full trust anchor certificate in the server's chain file, since clients can't reconstruct the certificate from its digest. > _443._tcp.www.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_www_domA_srvr-crt DO NOT publish "0 0 0", "1 0 0", "2 0 0", or "3 0 0" full certificates in DNS. Such RRs cannot reliably be queried by clients. -- Viktor. From dane.list@iswho.me Tue Jun 25 10:34: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 2FEDC21F9C2C for ; Tue, 25 Jun 2013 10:34:16 -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 r3rGblTmE2kt for ; Tue, 25 Jun 2013 10:34:11 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by ietfa.amsl.com (Postfix) with ESMTP id 3DDD621F9CB2 for ; Tue, 25 Jun 2013 10:34:07 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id DD3BA20B10; Tue, 25 Jun 2013 13:34:06 -0400 (EDT) Received: from web6.nyi.mail.srv.osa ([10.202.2.216]) by compute6.internal (MEProxy); Tue, 25 Jun 2013 13:34:06 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=iswho.me; h= message-id:from:to:mime-version:content-transfer-encoding :content-type:subject:date:in-reply-to:references; s=mesmtp; bh= MXis3e2FrTZDvkRO0nxNy4KhB9Y=; b=WoSTi60PA/zgw5olUnr/jZPaSTw1s/CE j78d30a1PujQt9VMuNuSwbdpSLWPPOSdPuSixq8I6jfEhmZfsLrZ6T4WuRgHuUME 4u8cmvaicSjHuq2dr/ou9DliJXOWsXbKKQpfDtoglgvU0E+4TAXimN18kf5/6Pyj SDOi+rdS8fg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:subject:date:in-reply-to :references; s=smtpout; bh=MXis3e2FrTZDvkRO0nxNy4KhB9Y=; b=aQ1Qj hqm0uS+IKCGcpGlouZXwCdEMcuwmCtX9NYChwapDo2p+INrpdZehKfhCE3UcM+iB 2y+J4LYV76Mt1taz82ihU2nsbXFjtObKzXSx47Mh+s1ob9H+APjyVvw6dmYzNLtf PzGkJki9J7yBAKg/z+6QUIA2ac9/qwUOLrGfRw= Received: by web6.nyi.mail.srv.osa (Postfix, from userid 99) id BC08D298DF8; Tue, 25 Jun 2013 13:34:06 -0400 (EDT) Message-Id: <1372181646.21211.140661248357561.3D93BE64@webmail.messagingengine.com> X-Sasl-Enc: rdxhQnYZo64TuJtfbOBCLSrx7whDDkOKTZkpBFyO6PMw 1372181646 From: DANE To: Warren Kumari , dane@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - html Date: Tue, 25 Jun 2013 19:34:06 +0200 In-Reply-To: <779F96A3-D7CB-4067-9D20-143182CA4AFD@kumari.net> References: <51BB7629.4070708@inventati.org> <51BB8001.8050004@inventati.org> <51C84F93.2020104@inventati.org> <20130624142714.GF29420@mournblade.imrryr.org> <779F96A3-D7CB-4067-9D20-143182CA4AFD@kumari.net> Subject: Re: [dane] Pls Consider Supporting Intermediate TLS Certificate, TLSA Usage 4 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 17:34:16 -0000 On Mon, Jun 24, 2013, Warren Kumari wrote: ... > ... > I'd also like to point back at the pseudonym discussion. > Can you please explain what exactly you mean by that (if you're not just getting bonus points for trying) n> From ogud@ogud.com Wed Jun 26 05:47: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 CE85511E80AE for ; Wed, 26 Jun 2013 05:47:47 -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 s-Ow8lMSK++s for ; Wed, 26 Jun 2013 05:47:42 -0700 (PDT) Received: from smtp100.ord1c.emailsrvr.com (smtp100.ord1c.emailsrvr.com [108.166.43.100]) by ietfa.amsl.com (Postfix) with ESMTP id BC2BE21F9F84 for ; Wed, 26 Jun 2013 05:47:42 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp5.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 882761B00DC; Wed, 26 Jun 2013 08:47:41 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp5.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 532921B00C2; Wed, 26 Jun 2013 08:47:41 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Olafur Gudmundsson In-Reply-To: <51C9B7B8.1040403@inventati.org> Date: Wed, 26 Jun 2013 08:47:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51C9B7B8.1040403@inventati.org> To: bry8star@inventati.org X-Mailer: Apple Mail (2.1508) Cc: dane@ietf.org Subject: Re: [dane] How to Reduce Multiple TA/CA "2 s m"/"0 s m" Or Same C_A_D TLSAs Using Wildcard TLSA X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jun 2013 12:47:47 -0000 On Jun 25, 2013, at 11:31 AM, Bry8 Star wrote: > When specifying multiple DANE TLSA records for various TLS / SSL > supported encrypted communication: >=20 > Then, if each service port has Two TLSAs, where, one "TLSA 2 s m" > (or one "TLSA 0 s m") RR is for declaring Root-CA or TA TLS/SSL > cert, and, another "TLSA 1 s m" (or one "TLSA 3 s m") is for > declaring EE/Server TLS/SSL cert. >=20 > Then, it results into lot of same "TLSA 2 s m" (or "TLSA 0 s m") RR > for all those services/ports. >=20 > And, if only one TLSA is declared for each service/port, even then, > it results into lot of exact same C_A_D. >=20 > What can be done to reduce it ? As Victor notes CNAME is an obvious solution, and it should be the = recommended solution as it will decrease maintenance if done properly, as when the TLSA records = need to change that change is done in one place in one zone and all the other names inherit the change.=20 For each service there should be a SINGLE target that everyone points = to, i.e. keeping CNAME chains at length 1=20 as much as possible.=20 If multiple services "share" a crypto context that should be reflected = by having having the services "SINGLE" target point to the master context i.e. keeping the chains at length 2, what this = does is if at a later point the sharing is undone only the "SINGLE" target for the service needs to be updated.=20 The same can be done for SRV records instead of replicating them in all = the different locations have CNAME to a "master" location.=20 A more radical solution is to replace to place DNAME at _tcp when a name = like _tcp.www. has a subset of the names at _tcp.=20 Note you can not place DNAME at _nnn._tcp=85.. as the rewrite rule only = work at names below the DNAME.=20 Olafur From warren@kumari.net Wed Jun 26 10:48: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 7DAB821F9F94 for ; Wed, 26 Jun 2013 10:48:05 -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 ETIRNQXr0hmB for ; Wed, 26 Jun 2013 10:48:00 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2B621F9F84 for ; Wed, 26 Jun 2013 10:47:57 -0700 (PDT) Received: from [192.168.0.187] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 9C3081B40728; Wed, 26 Jun 2013 13:47:55 -0400 (EDT) From: Warren Kumari Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 26 Jun 2013 13:47:54 -0400 Message-Id: <253A5DB6-CA83-48E7-93EA-C81E12781105@kumari.net> To: "dane@ietf.org list" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [dane] Decreasing our meeting slot from 1.5h to 1h. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jun 2013 17:48:05 -0000 Hi there all, The Ops Ads sent mail saying that there is extreme demand for agenda = time for Berlin, and, if possible to compress things, consider donating = back time if you are not sure you will use it all, etc. We had originally asked for a 90 minute slot, but in light of the = request we will be offering to change to a 60 minute slot. On the agenda we currently have Wes Hardaker (channeling Viktor) = presenting: "DANE TLSA implementation and operational guidance" -- = https://datatracker.ietf.org/doc/draft-dukhovni-dane-ops/ "SMTP security via opportunistic DANE TLS" -- = http://datatracker.ietf.org/doc/draft-dukhovni-smtp-opportunistic-tls=20 and Olafur presenting: "Harmonizing how applications specify DANE-like usage" -- = http://datatracker.ietf.org/doc/draft-ogud-dane-vocabulary Paul Wouters may also be submitting a new draft or two before the -00 = cutoff (July 8th), and so we may try squeeze him in too. If anyone else would like agenda time, please let us know ASAP. We would like to make the best possible use of the meeting time -- this = means that familiarity with the drafts is expected. Thanks, W --=20 Never criticize a man till you've walked a mile in his shoes. Then if = he didn't like what you've said, he's a mile away and barefoot.=20 From ajs@anvilwalrusden.com Wed Jun 26 10:54: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 5976721F9F84 for ; Wed, 26 Jun 2013 10:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4WGOWU+njrx for ; Wed, 26 Jun 2013 10:54:41 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 9A11021F9113 for ; Wed, 26 Jun 2013 10:54:40 -0700 (PDT) Received: from mx1.yitter.info (nat-07-mht.dyndns.com [216.146.45.246]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id A91038A031 for ; Wed, 26 Jun 2013 17:54:39 +0000 (UTC) Date: Wed, 26 Jun 2013 13:54:38 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20130626175437.GF19676@mx1.yitter.info> References: <253A5DB6-CA83-48E7-93EA-C81E12781105@kumari.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <253A5DB6-CA83-48E7-93EA-C81E12781105@kumari.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Decreasing our meeting slot from 1.5h to 1h. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jun 2013 17:54:47 -0000 On Wed, Jun 26, 2013 at 01:47:54PM -0400, Warren Kumari wrote: > > We would like to make the best possible use of the meeting time -- this means that familiarity with the drafts is expected. I warmly applaud this note from the chairs, and would go so far as to ask the people presenting to send to the list some notes about particular things they'd like to resolve in the meeting so that people could come prepared to discuss. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From stpeter@stpeter.im Wed Jun 26 10:59: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 A619711E81C7 for ; Wed, 26 Jun 2013 10:59:20 -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 hML8zbTD2Yo6 for ; Wed, 26 Jun 2013 10:59:15 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8F33711E81CF for ; Wed, 26 Jun 2013 10:59:15 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7193B412FA; Wed, 26 Jun 2013 11:59:35 -0600 (MDT) Message-ID: <51CB2BF0.2040404@stpeter.im> Date: Wed, 26 Jun 2013 11:59:12 -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: Andrew Sullivan References: <253A5DB6-CA83-48E7-93EA-C81E12781105@kumari.net> <20130626175437.GF19676@mx1.yitter.info> In-Reply-To: <20130626175437.GF19676@mx1.yitter.info> 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] Decreasing our meeting slot from 1.5h to 1h. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jun 2013 17:59:20 -0000 On 6/26/13 11:54 AM, Andrew Sullivan wrote: > On Wed, Jun 26, 2013 at 01:47:54PM -0400, Warren Kumari wrote: >> >> We would like to make the best possible use of the meeting time -- this means that familiarity with the drafts is expected. > > I warmly applaud this note from the chairs, and would go so far as to > ask the people presenting to send to the list some notes about > particular things they'd like to resolve in the meeting so that people > could come prepared to discuss. Great idea, Andrew! Peter -- Peter Saint-Andre https://stpeter.im/ From bry8star@inventati.org Wed Jun 26 17:57: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 ED4B711E8181 for ; Wed, 26 Jun 2013 17:57: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 CO+IA72D6w56 for ; Wed, 26 Jun 2013 17:57:25 -0700 (PDT) Received: from latitanza.investici.org (latitanza.investici.org [IPv6:2002:525e:f9ea::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0316311E8175 for ; Wed, 26 Jun 2013 17:57:23 -0700 (PDT) Received: from [82.94.249.234] (latitanza [82.94.249.234]) (Authenticated sender: bry8star@inventati.org) by localhost (Postfix) with ESMTPSA id E3450980D4 for ; Thu, 27 Jun 2013 00:57:18 +0000 (UTC) X-DKIM: Sendmail DKIM Filter v2.8.2 latitanza.investici.org E3450980D4 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inventati.org; s=stigmate; t=1372294641; bh=gRcjQ1RM0MEII0zsTUQ0CvdYy1l2XZa6QfkoxnL4+hs=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject:References: In-Reply-To:Content-Type; b=QC9GigYrdprR7fgIcU3X/8zGAfCse5J5kuz18ZSi6I8Q1iK0R/7gH0SYuK0tPWYW2 1DkO5+5EUMeC+B9rnQuxBTjDeJxPGdrd4+csmxCKwLRluScwiSRk52n/QNgwN/jPyx l+fmP/HWTQjKZqPQ7AE7lD9RoXuJ3G73oQNxW7ek= Message-ID: <51CB8DCB.8010102@inventati.org> Date: Wed, 26 Jun 2013 17:56:43 -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: <51C9B7B8.1040403@inventati.org> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2EPLLKXBVGHLTDLNJAOHM" Subject: Re: [dane] How to Reduce Multiple TA/CA "2 s m"/"0 s m" Or Same C_A_D TLSAs Using Wildcard TLSA 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: Thu, 27 Jun 2013 00:57:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2EPLLKXBVGHLTDLNJAOHM Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Great, another possible solution could be using CNAMEs. More info on CNAME is here: RFC 6698 Section A.2.1.1. Provisioning TLSA Records with CNAME Records https://tools.ietf.org/html/rfc6698#appendix-A.2.1.1 More info on DNAME: https://tools.ietf.org/html/rfc6698#appendix-A.2.1.2 Thanks to both of you Viktor, and, Olafur, for all suggestions, improvements (related to this type of configuration). This configuration is intended to be used for a (very) "higher" security & encryption based service(s), where there is lesser or no confusion exist in TLSA/DANE and related DNS declarations/publication, etc. All necessary components are/will be clearly defined to eliminate (all/most) confusions. Very higher strength SSL/TLS certs are used in these services. Clients/users are shown & instructed to use slightly special configurations & client-software to connect with these services. But it is within what is publicly available normally in common and major web-browsers, client-softwares. Those who do not want to use such configuration, or, those who do not have various related capacity to process/handle more than one TLSA based secured & encrypted solution, then such clients/users/domain-owners/zone-operators may/should use one/single TLSA and may/should also choose to use shorter version of TLSAs like "TLSA u s 1" or "TLSA u s 2", instead of two or more full TLS/SSL cert based TLSA/DANE solution which are used & shown in these configurations, or choose what fits best for their implementation/objectives. In configuration, the choice of variations, permutations and combinations for TLSA related DNS records, which are allowed or optionally allowed by related RFCs, are upon domain-owner/zone-operator/DNS-operator. So, previously posted config can be like this ? Are these DNS/zone declarations correct ? (I've slightly modified & tried to correct per my own understanding. Changed "im" hostname into "im1", etc, forgot to show DNSKEY RRs, skipped DS RRs used for subs). A zone file: ; Lines that starts with ";" symbol are inactive. domA.tld. 3600 IN SOA s1.domA.tld. hostmaster.domA.tld. 2013052910 18000 3600 864000 3600 ; Below two lines are actually active in actual zone file. ;domA.tld. 3000 IN DNSKEY 256 3 8 HEX_CODE_KEY ;domA.tld. 3000 IN DNSKEY 257 3 8 HEX_CODE_KEY ; Since it is targetted for advanced & secured & ; encrypted usage/purpose, above will be changed, ; and higher strength encryption will be used. ; Skipping NSEC. domA.tld. 3000 IN NS s1.domA.tld. domA.tld. 3000 IN NS s2.domA.tld. domA.tld. 300 IN A IP.ADRS_S-1_IPv4 domA.tld. 300 IN A IP.ADRS_S-2_IPv4 domA.tld. 300 IN A IP.ADRS_S-IM-1_IPv4 domA.tld. 300 IN A IP.ADRS_S-IM-2_IPv4 domA.tld. 300 IN AAAA IP::ADRS_S-1_IPv6 domA.tld. 300 IN AAAA IP::ADRS_S-2_IPv6 domA.tld. 300 IN AAAA IP::ADRS_S-IM-1_IPv6 domA.tld. 300 IN AAAA IP::ADRS_S-IM-2_IPv6 s1.domA.tld. 900 IN A IP.ADRS_S-1_IPv4 s2.domA.tld. 900 IN A IP.ADRS_S-2_IPv4 im1.domA.tld. 900 IN A IP.ADRS_S-IM-1_IPv4 im2.domA.tld. 900 IN A IP.ADRS_S-IM-2_IPv4 s1.domA.tld. 900 IN AAAA IP::ADRS_S-1_IPv6 s2.domA.tld. 900 IN AAAA IP::ADRS_S-2_IPv6 im1.domA.tld. 900 IN AAAA IP::ADRS_S-IM-1_IPv6 im2.domA.tld. 900 IN AAAA IP::ADRS_S-IM-2_IPv6 www.domA.tld. 300 IN CNAME domA.tld. m.domA.tld. 300 IN CNAME domA.tld. _http._tcp.domA.tld. 3600 IN SRV 0 0 80 www.domA.tld. _https._tcp.domA.tld. 3600 IN SRV 0 0 443 www.domA.tld. _http._tcp.www.domA.tld. 3600 IN SRV 0 0 80 www.domA.tld. _https._tcp.www.domA.tld. 3600 IN SRV 0 0 443 www.domA.tld. _http._tcp.m.domA.tld. 3600 IN SRV 0 0 80 m.domA.tld. _https._tcp.m.domA.tld. 3600 IN SRV 0 0 443 m.domA.tld. domA.tld. 3600 IN MX 10 s1.domA.tld. domA.tld. 3600 IN MX 20 s2.domA.tld. _smtp._tcp.domA.tld. 3600 IN SRV 10 0 25 s1.domA.tld. _smtp._tcp.domA.tld. 3600 IN SRV 20 0 25 s2.domA.tld. _smtp._tcp.s1.domA.tld. 3600 IN SRV 10 0 25 s1.domA.tld. _smtp._tcp.s1.domA.tld. 3600 IN SRV 20 0 25 s2.domA.tld. _smtp._tcp.s2.domA.tld. 3600 IN SRV 10 0 25 s2.domA.tld. _smtp._tcp.s2.domA.tld. 3600 IN SRV 20 0 25 s1.domA.tld. _submission._tcp.domA.tld. 3600 IN SRV 10 0 587 s1.domA.tld. _submission._tcp.domA.tld. 3600 IN SRV 20 0 587 s2.domA.tld. _submission._tcp.s1.domA.tld. 3600 IN SRV 10 0 587 s1.domA.tld. _submission._tcp.s1.domA.tld. 3600 IN SRV 20 0 587 s2.domA.tld. _submission._tcp.s2.domA.tld. 3600 IN SRV 10 0 587 s2.domA.tld. _submission._tcp.s2.domA.tld. 3600 IN SRV 20 0 587 s1.domA.tld. _imaps._tcp.domA.tld. 1200 IN SRV 0 0 993 s1.domA.tld. _imaps._tcp.domA.tld. 1200 IN SRV 5 0 993 s2.domA.tld. _imaps._tcp.s1.domA.tld. 1200 IN SRV 0 0 993 s1.domA.tld. _imaps._tcp.s1.domA.tld. 1200 IN SRV 5 0 993 s2.domA.tld. _imaps._tcp.s2.domA.tld. 1200 IN SRV 0 0 993 s2.domA.tld. _imaps._tcp.s2.domA.tld. 1200 IN SRV 5 0 993 s1.domA.tld. _pops._tcp.domA.tld. 1200 IN SRV 0 0 995 s1.domA.tld. _pops._tcp.domA.tld. 1200 IN SRV 5 0 995 s2.domA.tld. _pops._tcp.s1.domA.tld. 1200 IN SRV 0 0 995 s1.domA.tld. _pops._tcp.s1.domA.tld. 1200 IN SRV 5 0 995 s2.domA.tld. _pops._tcp.s2.domA.tld. 1200 IN SRV 0 0 995 s2.domA.tld. _pops._tcp.s2.domA.tld. 1200 IN SRV 5 0 995 s1.domA.tld. ; Skipping SMTP (Port 26) based 3rd email-server. _sip._tcp.domA.tld. 1200 IN SRV 0 0 5060 im1.domA.tld. _sip._tcp.domA.tld. 1200 IN SRV 1 0 5060 im2.domA.tld. _sip._tcp.domA.tld. 1200 IN SRV 2 0 15060 im1.domA.tld. _sip._tcp.domA.tld. 1200 IN SRV 3 0 15060 im2.domA.tld. _sips._tcp.domA.tld. 1200 IN SRV 0 0 5061 im1.domA.tld. _sips._tcp.domA.tld. 1200 IN SRV 1 0 5061 im2.domA.tld. _sips._tcp.domA.tld. 1200 IN SRV 2 0 15061 im1.domA.tld. _sips._tcp.domA.tld. 1200 IN SRV 3 0 15061 im2.domA.tld. _sip._tcp.im1.domA.tld. 1200 IN SRV 0 0 5060 im1.domA.tld. _sip._tcp.im1.domA.tld. 1200 IN SRV 1 0 5060 im2.domA.tld. _sip._tcp.im1.domA.tld. 1200 IN SRV 2 0 15060 im1.domA.tld. _sip._tcp.im1.domA.tld. 1200 IN SRV 3 0 15060 im2.domA.tld. _sip._tcp.im2.domA.tld. 1200 IN SRV 0 0 5060 im2.domA.tld. _sip._tcp.im2.domA.tld. 1200 IN SRV 1 0 15060 im2.domA.tld. _sip._tcp.im2.domA.tld. 1200 IN SRV 2 0 5060 im1.domA.tld. _sip._tcp.im2.domA.tld. 1200 IN SRV 3 0 15060 im1.domA.tld. _sips._tcp.im1.domA.tld. 1200 IN SRV 0 0 5061 im1.domA.tld. _sips._tcp.im1.domA.tld. 1200 IN SRV 1 0 5061 im2.domA.tld. _sips._tcp.im1.domA.tld. 1200 IN SRV 2 0 15061 im1.domA.tld. _sips._tcp.im1.domA.tld. 1200 IN SRV 3 0 15061 im2.domA.tld. _sips._tcp.im2.domA.tld. 1200 IN SRV 0 0 5061 im2.domA.tld. _sips._tcp.im2.domA.tld. 1200 IN SRV 1 0 15061 im2.domA.tld. _sips._tcp.im2.domA.tld. 1200 IN SRV 2 0 5061 im1.domA.tld. _sips._tcp.im2.domA.tld. 1200 IN SRV 3 0 15061 im1.domA.tld. ; And multiple XMPP services are configured ; similar to above SIP services: _xmpp-client._tcp.domA.tld. 900 IN SRV 0 0 5222 im1.domA.tld. _xmpp-client._tcp.domA.tld. 900 IN SRV 1 0 5222 im2.domA.tld. _xmpp-client._tcp.domA.tld. 900 IN SRV 2 0 15222 im1.domA.tld. _xmpp-client._tcp.domA.tld. 900 IN SRV 3 0 15222 im2.domA.tld. _xmpp-client._tcp.im1.domA.tld. 900 IN SRV 0 0 5222 im1.domA.tld. _xmpp-client._tcp.im1.domA.tld. 900 IN SRV 1 0 15222 im1.domA.tld. _xmpp-client._tcp.im1.domA.tld. 900 IN SRV 2 0 5222 im2.domA.tld. _xmpp-client._tcp.im1.domA.tld. 900 IN SRV 3 0 15222 im2.domA.tld. _xmpp-client._tcp.im2.domA.tld. 900 IN SRV 0 0 5222 im2.domA.tld. _xmpp-client._tcp.im2.domA.tld. 900 IN SRV 1 0 15222 im2.domA.tld. _xmpp-client._tcp.im2.domA.tld. 900 IN SRV 2 0 5222 im1.domA.tld. _xmpp-client._tcp.im2.domA.tld. 900 IN SRV 3 0 15222 im1.domA.tld. _xmpp-server._tcp.domA.tld. 1800 IN SRV 0 0 5269 im1.domA.tld. _xmpp-server._tcp.domA.tld. 1800 IN SRV 1 0 5269 im2.domA.tld. _xmpp-server._tcp.domA.tld. 1800 IN SRV 2 0 15269 im1.domA.tld. _xmpp-server._tcp.domA.tld. 1800 IN SRV 3 0 15269 im2.domA.tld. _xmpp-server._tcp.im1.domA.tld. 1800 IN SRV 0 0 5269 im1.domA.tld. _xmpp-server._tcp.im1.domA.tld. 1800 IN SRV 1 0 15269 im1.domA.tld. _xmpp-server._tcp.im1.domA.tld. 1800 IN SRV 2 0 5269 im2.domA.tld. _xmpp-server._tcp.im1.domA.tld. 1800 IN SRV 3 0 15269 im2.domA.tld. _xmpp-server._tcp.im2.domA.tld. 1800 IN SRV 0 0 5269 im2.domA.tld. _xmpp-server._tcp.im2.domA.tld. 1800 IN SRV 1 0 15269 im2.domA.tld. _xmpp-server._tcp.im2.domA.tld. 1800 IN SRV 2 0 5269 im1.domA.tld. _xmpp-server._tcp.im2.domA.tld. 1800 IN SRV 3 0 15269 im1.domA.tld. ; Skipping rest of SIP related SRV declarations. ; And multiple IRC services are configured ; similar to above SIP/XMPP services. _irc._tcp.domA.tld. 1800 IN SRV 0 0 6667 im1.domA.tld. _irc._tcp.domA.tld. 3600 IN SRV 1 0 6667 im2.domA.tld. _irc._tcp.domA.tld. 3600 IN SRV 2 0 6669 im1.domA.tld. _irc._tcp.domA.tld. 3600 IN SRV 3 0 6669 im2.domA.tld. _irc._tcp.im1.domA.tld. 1800 IN SRV 0 0 6667 im1.domA.tld. _irc._tcp.im1.domA.tld. 3600 IN SRV 1 0 6669 im1.domA.tld. _irc._tcp.im1.domA.tld. 3600 IN SRV 2 0 6667 im2.domA.tld. _irc._tcp.im1.domA.tld. 3600 IN SRV 3 0 6669 im2.domA.tld. _irc._tcp.im2.domA.tld. 1800 IN SRV 0 0 6667 im2.domA.tld. _irc._tcp.im2.domA.tld. 3600 IN SRV 1 0 6669 im2.domA.tld. _irc._tcp.im2.domA.tld. 3600 IN SRV 2 0 6667 im1.domA.tld. _irc._tcp.im2.domA.tld. 3600 IN SRV 3 0 6669 im1.domA.tld. ; Skipping rest of IRC related SRV declarations. ; Skipped/omitted other DNS RRs. ; RRSIGs are not mentioned, but they exist when DNSSEC signed. Multiple SRV are for load-balancing, etc purpose. And used for forwarding client/traffic toward different/other server & service, when/if one of them is down or heavily loaded. And TLS / SSL cert full chain componenets: EE/Server {s1, s2, im1, im2, www, m} \ <-- IA {domA.tld} \ <-- CA/TA {Root-CA}. And here are TLSA related RRs, after incorporating CNAME logic: _443._tcp.www.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt _443._tcp.www.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_www-domA-crt _443._tcp.m.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt _443._tcp.m.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_m-domA-crt s1._s.domA.tld. 900 IN TLSA 2 0 1 C_A_D_of_TA-crt s1._s.domA.tld. 900 IN TLSA 1 0 0 C_A_D_of_s1-domA-crt s2._s.domA.tld. 900 IN TLSA 2 0 1 C_A_D_of_TA-crt s2._s.domA.tld. 900 IN TLSA 1 0 0 C_A_D_of_s2-domA-crt _25._tcp.s1.domA.tld. 360 IN CNAME s1._s.domA.tld. _25._tcp.s2.domA.tld. 360 IN CNAME s2._s.domA.tld. _587._tcp.s1.domA.tld. 360 IN CNAME s1._s.domA.tld. _587._tcp.s2.domA.tld. 360 IN CNAME s2._s.domA.tld. _993._tcp.s1.domA.tld. 360 IN CNAME s1._s.domA.tld. _993._tcp.s2.domA.tld. 360 IN CNAME s2._s.domA.tld. ; Skipping SMTP (Port 26) based 3rd email-server. im1._im.domA.tld. 900 IN TLSA 2 0 1 C_A_D_of_TA-crt im1._im.domA.tld. 900 IN TLSA 1 0 0 C_A_D_of_im1-domA-crt im2._im.domA.tld. 900 IN TLSA 2 0 1 C_A_D_of_TA-crt im2._im.domA.tld. 900 IN TLSA 1 0 0 C_A_D_of_im2-domA-crt _5061._tcp.im1.domA.tld. 900 IN CNAME im1._im.domA.tld. _15061._tcp.im1.domA.tld. 900 IN CNAME im1._im.domA.tld. _5061._tcp.im2.domA.tld. 900 IN CNAME im2._im.domA.tld. _15061._tcp.im2.domA.tld. 900 IN CNAME im2._im.domA.tld. _5223._tcp.im1.domA.tld. 900 IN CNAME im1._im.domA.tld. _15223._tcp.im1.domA.tld. 900 IN CNAME im1._im.domA.tld. _5223._tcp.im2.domA.tld. 900 IN CNAME im2._im.domA.tld. _15223._tcp.im2.domA.tld. 900 IN CNAME im2._im.domA.tld. _5269._tcp.im1.domA.tld. 900 IN CNAME im1._im.domA.tld. _15269._tcp.im1.domA.tld. 900 IN CNAME im1._im.domA.tld. _5269._tcp.im2.domA.tld. 900 IN CNAME im2._im.domA.tld. _15269._tcp.im2.domA.tld. 900 IN CNAME im2._im.domA.tld. _6697._tcp.im1.domA.tld. 900 IN CNAME im1._im.domA.tld. _6699._tcp.im1.domA.tld. 900 IN CNAME im1._im.domA.tld. _6697._tcp.im2.domA.tld. 900 IN CNAME im2._im.domA.tld. _6699._tcp.im2.domA.tld. 900 IN CNAME im2._im.domA.tld. =3D 12 TLSA lines/rr, and 22 related CNAME lines/rr. =3D 34 total TLSA related lines/rr. (previously, without using CNAME, this config used 48 TLSA lines/rr, where each line had TLSA RR). And if a ZO (zone-operator) or a domain-owner (D-O) wants to, then he/she/they can combine & reduce servers and services, by moving all "im1" services into "s1", and by moving all services from "im2" into "s2", then there will be even lesser amount of DNS records, but quality of services will be lower/slower, unless related hardware and configuration has enough capacity. A ZO or D-O can do opposite as well: start all on a single or two machines, and then, move services out to other server, when more resource assignment will be necessary. I could not find usefulness of DNAME or a way to use it for this specific configuration, without loosing current simple load-balancing features/advantages. But when ZO will add/use/link second domain-name "domB.tld." or other domain-name based services, on same set of machines, (or on different set of machines), then DNAME & CNAME could be very useful. Wanted to declare even Intermediate TLS/SSL certs ("TLSA u s 1"), to reduce (related/any-more/further) confusions, but there is now no way to clearly specify in TLSA which cert is after what in a TLS/SSL chain. Is it a right assessment, that, this type of CNAME or DNAME forwarding/replacing will need to be supported by DANE-aware client-software, and also supported by the Full DNSSEC based DNS-Resolver/DNS-Server which will be used by users in client-side, for these to work properly. Please correct the wrong DNS/zone declarations. Thanks in advance, -- Bright Star. Received from Olafur Gudmundsson, on 2013-06-26 5:47 AM: >=20 > On Jun 25, 2013, at 11:31 AM, Bry8 Star wrote:= >=20 >> When specifying multiple DANE TLSA records for various TLS / SSL >> supported encrypted communication: >> >> Then, if each service port has Two TLSAs, where, one "TLSA 2 s m" >> (or one "TLSA 0 s m") RR is for declaring Root-CA or TA TLS/SSL >> cert, and, another "TLSA 1 s m" (or one "TLSA 3 s m") is for >> declaring EE/Server TLS/SSL cert. >> >> Then, it results into lot of same "TLSA 2 s m" (or "TLSA 0 s m") RR >> for all those services/ports. >> >> And, if only one TLSA is declared for each service/port, even then, >> it results into lot of exact same C_A_D. >> >> What can be done to reduce it ? >=20 > As Victor notes CNAME is an obvious solution, and it should be the reco= mmended solution as > it will decrease maintenance if done properly, as when the TLSA records= need to change that change is done in one place in one zone and all > the other names inherit the change.=20 >=20 > For each service there should be a SINGLE target that everyone points = to, i.e. keeping CNAME chains at length 1=20 > as much as possible.=20 >=20 > If multiple services "share" a crypto context that should be reflected = by having having the services "SINGLE" target point > to the master context i.e. keeping the chains at length 2, what this do= es is if at a later point the sharing is undone only the > "SINGLE" target for the service needs to be updated.=20 >=20 > The same can be done for SRV records instead of replicating them in all= the different locations have CNAME to a "master" location.=20 >=20 > A more radical solution is to replace to place DNAME at _tcp when a nam= e like _tcp.www. has a subset of the > names at _tcp.=20 > Note you can not place DNAME at _nnn._tcp=85.. as the rewrite rule only= work at names below the DNAME.=20 >=20 > Olafur >=20 Received from Viktor Dukhovni, on 2013-06-25 10:12 AM: >=20 > On Tue, Jun 25, 2013 at 08:31:04AM -0700, Bry8 Star wrote: >=20 >> Then, if each service port has Two TLSAs, where, one "TLSA 2 s m" >> (or one "TLSA 0 s m") RR is for declaring Root-CA or TA TLS/SSL >> cert, and, another "TLSA 1 s m" (or one "TLSA 3 s m") is for >> declaring EE/Server TLS/SSL cert. >=20 >=20 > When using the same TA for multiple services, or the same EE public > key for multiple services, you can consolidate TLSA RRs via CNAMEs, > for example (real life): >=20 > _25._tcp.open.nlnetlabs.nl. IN CNAME 3.1.1._dane.nlnetlabs.nl. > 3.1.1._dane.nlnetlabs.nl. IN TLSA 3 1 1 0D1FCBD71686199607A132744A= 4918FC209565C91FA8E9FFEEA0AAFD6B9305F6 >=20 >> So, instead of specifying TLSA for same TA crt like this example, in >> a zone file: >> >> _443._tcp.www.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt >=20 > Remember to include the full trust anchor certificate in the server's > chain file, since clients can't reconstruct the certificate from > its digest. >=20 ------enig2EPLLKXBVGHLTDLNJAOHM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJRy43XAAoJEID2ikYfWSP65W4P/jEuBMt5G5CSnpWhmwwqT8MK e0q8B6VkxI3JrAX0lBm7rmXTwT5y4esdn51o7NH8hTCpmjuad2Bi+L4LLxmGTk1r //OQtmlCL5laEXQCTATQabkYt7le4Ovy7RmCxKzlNh7KVmAQAqsqMCQx2iO8NXID 82v9e+0pPZc1qpRKeZx1WTdh0ObpDDlYYHvLdGr8L4A1e/jzDNNQVynOZ1oh8A5p b2sX3snosYHsDqIpY8s3fop5XOJPLU3R0vqEQ0RZ60PqIpqAW9/AGKOBVWAwdsbi 7aS7kmJxepvGRvlZ3/jCY5io+Wo2LiXR+QzZLMu4ioqZDpua+gE+mWF7yQE3kEEE 7Swhv1CRqgyqu2PtSSc3M0M/MVYfDe1DbHZ804Zlizd5kNDqsTZwD9BBM+sC4PFY m6k5SIdI9bW70zHW/Dfp4CZchSM4A2UY4yPUFW4cRonijrXd92iL3qHV2S/zAno9 0a+rURcBLoDEXKuBEdequLkFpxR4J2e/8IKt5cFb+zaxQgNSMjXWyBkNnCz0NRMN aKfaKWFPTSID/ajpLpKfhhjRL0dPoPUbOXM6HApvWqeGY6PYnuPFSDkkBqyNKTRg TpGjvOwCUjvSzlqkAzGPqVcnAmxMf87ccBe88zWF3APhq4E28bm3hOKCYYvJENMo sCS+m4gQ1OWzxqW00fJV =o+za -----END PGP SIGNATURE----- ------enig2EPLLKXBVGHLTDLNJAOHM-- From wes@hardakers.net Thu Jun 27 07:13: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 20E6321F9CEF for ; Thu, 27 Jun 2013 07:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-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 5DqLDos-3W7B for ; Thu, 27 Jun 2013 07:13:26 -0700 (PDT) Received: from mail.hardakers.net (unknown [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D76021F9B60 for ; Thu, 27 Jun 2013 07:13:26 -0700 (PDT) Received: from localhost (unknown [IPv6:2001:470:1f00:187:ac26:8682:83cb:a5c6]) by mail.hardakers.net (Postfix) with ESMTPSA id 51DED240F4; Thu, 27 Jun 2013 07:13:24 -0700 (PDT) From: Wes Hardaker To: Warren Kumari References: <253A5DB6-CA83-48E7-93EA-C81E12781105@kumari.net> Date: Thu, 27 Jun 2013 07:13:24 -0700 In-Reply-To: <253A5DB6-CA83-48E7-93EA-C81E12781105@kumari.net> (Warren Kumari's message of "Wed, 26 Jun 2013 13:47:54 -0400") Message-ID: <0lbo6rvdyz.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 list" Subject: Re: [dane] Decreasing our meeting slot from 1.5h to 1h. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 27 Jun 2013 14:13:27 -0000 Warren Kumari writes: > We had originally asked for a 90 minute slot, but in light of the > request we will be offering to change to a 60 minute slot. > > On the agenda we currently have Wes Hardaker (channeling Viktor) > presenting: To fulfill this request, we should change this to "Wes Hardaker (who will be channeling "EKR" who will be channeling "Viktor"). -- Wes Hardaker My Pictures: http://capturedonearth.com/ My Thoughts: http://pontifications.hardakers.net/ From warren@kumari.net Thu Jun 27 07:36: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 52F4121F9AF9 for ; Thu, 27 Jun 2013 07:36: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 FLSrP4-Lvohb for ; Thu, 27 Jun 2013 07:36:32 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id D42A321F9AF8 for ; Thu, 27 Jun 2013 07:36:24 -0700 (PDT) Received: from [192.168.0.187] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id D36EA1B40599; Thu, 27 Jun 2013 10:36:22 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Warren Kumari In-Reply-To: <0lbo6rvdyz.fsf@wjh.hardakers.net> Date: Thu, 27 Jun 2013 10:36:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <06445344-CCEA-4284-85D4-771E63EA95FB@kumari.net> References: <253A5DB6-CA83-48E7-93EA-C81E12781105@kumari.net> <0lbo6rvdyz.fsf@wjh.hardakers.net> To: Wes Hardaker X-Mailer: Apple Mail (2.1508) Cc: "dane@ietf.org list" Subject: Re: [dane] Decreasing our meeting slot from 1.5h to 1h. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 27 Jun 2013 14:36:37 -0000 On Jun 27, 2013, at 10:13 AM, Wes Hardaker wrote: > Warren Kumari writes: >=20 >> We had originally asked for a 90 minute slot, but in light of the >> request we will be offering to change to a 60 minute slot. >>=20 >> On the agenda we currently have Wes Hardaker (channeling Viktor) >> presenting: >=20 > To fulfill this request, we should change this to "Wes Hardaker (who > will be channeling "EKR" who will be channeling "Viktor"). Wow, you *can* channel EKR? That's some serious talent. I'm guessing / hoping that they don't take us up on our limited time = offer, but if they do, we should still managed to fit everything in = without too much rushing -- we'll just make sure we start on time, and = keep the administrivia / faffing to the bare minimum=85. W > --=20 > Wes Hardaker =20 > My Pictures: http://capturedonearth.com/ > My Thoughts: http://pontifications.hardakers.net/ >=20 -- Credo quia absurdum est. From ogud@ogud.com Thu Jun 27 07:40:41 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 5C32421F9E67 for ; Thu, 27 Jun 2013 07:40:41 -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 ClQI-q-aqvsx for ; Thu, 27 Jun 2013 07:40:37 -0700 (PDT) Received: from smtp76.ord1c.emailsrvr.com (smtp76.ord1c.emailsrvr.com [108.166.43.76]) by ietfa.amsl.com (Postfix) with ESMTP id 3B45221F9E5F for ; Thu, 27 Jun 2013 07:40:37 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp2.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id E799C1E8145; Thu, 27 Jun 2013 10:40:34 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp2.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id A41471E809D; Thu, 27 Jun 2013 10:40:34 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Olafur Gudmundsson In-Reply-To: <253A5DB6-CA83-48E7-93EA-C81E12781105@kumari.net> Date: Thu, 27 Jun 2013 10:40:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <253A5DB6-CA83-48E7-93EA-C81E12781105@kumari.net> To: Warren Kumari X-Mailer: Apple Mail (2.1508) Cc: "dane@ietf.org list" Subject: Re: [dane] Decreasing our meeting slot from 1.5h to 1h. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 27 Jun 2013 14:40:41 -0000 On Jun 26, 2013, at 1:47 PM, Warren Kumari wrote: > Hi there all, >=20 > and Olafur presenting: > "Harmonizing how applications specify DANE-like usage" -- = http://datatracker.ietf.org/doc/draft-ogud-dane-vocabulary Please read the draft, it contains definitions of terms that are = important to DANE-like specifications,=20 the terms describe the components needed to create/use DANE-like = specification and the authentication rules for each component.=20 The goal of the draft is to reduce confusion and simply how a new = service/protocol is specified.=20 Olafur From bry8star@inventati.org Thu Jun 27 13:09: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 5CF9121F9E82 for ; Thu, 27 Jun 2013 13:09:42 -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 bVA2+-WdWH19 for ; Thu, 27 Jun 2013 13:09:40 -0700 (PDT) Received: from diserzione.investici.org (diserzione.investici.org [IPv6:2002:52dd:6399::1]) by ietfa.amsl.com (Postfix) with ESMTP id DC56021F9DE3 for ; Thu, 27 Jun 2013 13:09:39 -0700 (PDT) Received: from [82.221.99.153] (diserzione [82.221.99.153]) (Authenticated sender: bry8star@inventati.org) by localhost (Postfix) with ESMTPSA id DDF50180A71 for ; Thu, 27 Jun 2013 20:09:30 +0000 (UTC) X-DKIM: Sendmail DKIM Filter v2.8.2 diserzione.investici.org DDF50180A71 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inventati.org; s=stigmate; t=1372363776; bh=k+KcGY4k+1YEH0UD8WQsj6ai98UsEyEJqk73zhiAi6E=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject:References: In-Reply-To:Content-Type; b=B4hXDtKcFtLAMDpadR0oIPmGhZ78LNB4fUz4hGXJJ06P7FnPpsi5HN457FFssa+r9 v98kVdgO//4iv9lxSpMR6ATtofz/raYTHx/I7oCcEJaluETYBNLc3L6KSzbyUgQogK S3ysHn0QbnZr3EwBEeOpxaGpHN/QmjyWynMIAks0= Message-ID: <51CC9BD5.8090705@inventati.org> Date: Thu, 27 Jun 2013 13:08:53 -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: <51C9B7B8.1040403@inventati.org> <51CB8DCB.8010102@inventati.org> In-Reply-To: <51CB8DCB.8010102@inventati.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2MTTTPCDRSWCBNDNHUOOC" Subject: Re: [dane] How to Reduce Multiple TA/CA "2 s m"/"0 s m" Or Same C_A_D TLSAs Using Wildcard TLSA 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: Thu, 27 Jun 2013 20:09:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2MTTTPCDRSWCBNDNHUOOC Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable This solution is more TLSA standard friendly, than the previous one. (CNAME forwarding are used) _443._tcp.www.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt _443._tcp.www.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_www-domA-crt _443._tcp.m.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt _443._tcp.m.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_m-domA-crt ; Port 60 is Unassigned. Not used by any real service. _60._tcp.s1.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt _60._tcp.s1.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_s1-domA-crt _60._tcp.s2.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt _60._tcp.s2.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_s2-domA-crt _25._tcp.s1.domA.tld. 360 IN CNAME _60._tcp.s1.domA.tld. _25._tcp.s2.domA.tld. 360 IN CNAME _60._tcp.s2.domA.tld. _587._tcp.s1.domA.tld. 360 IN CNAME _60._tcp.s1.domA.tld. _587._tcp.s2.domA.tld. 360 IN CNAME _60._tcp.s2.domA.tld. _993._tcp.s1.domA.tld. 360 IN CNAME _60._tcp.s1.domA.tld. _993._tcp.s2.domA.tld. 360 IN CNAME _60._tcp.s2.domA.tld. ; Skipping SMTP (Port 26) based 3rd email-server. _60._tcp.im1.domA.tld. 900 IN TLSA 2 0 1 C_A_D_of_TA-crt _60._tcp.im1.domA.tld. 900 IN TLSA 1 0 0 C_A_D_of_im1-domA-crt _60._tcp.im2.domA.tld. 900 IN TLSA 2 0 1 C_A_D_of_TA-crt _60._tcp.im2.domA.tld. 900 IN TLSA 1 0 0 C_A_D_of_im2-domA-crt _5061._tcp.im1.domA.tld. 900 IN CNAME _60._tcp.im1.domA.tld. _15061._tcp.im1.domA.tld. 900 IN CNAME _60._tcp.im1.domA.tld. _5061._tcp.im2.domA.tld. 900 IN CNAME _60._tcp.im2.domA.tld. _15061._tcp.im2.domA.tld. 900 IN CNAME _60._tcp.im2.domA.tld. _5223._tcp.im1.domA.tld. 900 IN CNAME _60._tcp.im1.domA.tld. _15223._tcp.im1.domA.tld. 900 IN CNAME _60._tcp.im1.domA.tld. _5223._tcp.im2.domA.tld. 900 IN CNAME _60._tcp.im2.domA.tld. _15223._tcp.im2.domA.tld. 900 IN CNAME _60._tcp.im2.domA.tld. _5269._tcp.im1.domA.tld. 900 IN CNAME _60._tcp.im1.domA.tld. _15269._tcp.im1.domA.tld. 900 IN CNAME _60._tcp.im1.domA.tld. _5269._tcp.im2.domA.tld. 900 IN CNAME _60._tcp.im2.domA.tld. _15269._tcp.im2.domA.tld. 900 IN CNAME _60._tcp.im2.domA.tld. _6697._tcp.im1.domA.tld. 900 IN CNAME _60._tcp.im1.domA.tld. _6699._tcp.im1.domA.tld. 900 IN CNAME _60._tcp.im1.domA.tld. _6697._tcp.im2.domA.tld. 900 IN CNAME _60._tcp.im2.domA.tld. _6699._tcp.im2.domA.tld. 900 IN CNAME _60._tcp.im2.domA.tld. =3D 12 TLSA lines/rr, and 22 related CNAME lines/rr. =3D 34 total TLSA related lines/rr. Previously, without using CNAME, this config used 48 TLSA lines/rr, where each line had TLSA RR. Are these (showed in above) correct declarations ? Client-software which is trying to connect with server's secure port 5223, they should still be bale to obtain both TLSA: "TLSA 2 0 1" and "TLSA 1 0 0" and use it for TLS /SSL cert verification for port 5223, and on success, establish encrypted and authenticated communication, right ? Any other way to improve this configuration further ? How to make it more secured and encrypted ? How to add more declarations to clearly define all components that are used in the system. I skipped (did not show) : SSHFP, CERT PGP, etc DNS RRs, never the less they exists, and very essential to very clearly define & declare what is the ZO/D-O approved component(s), (public-side) GPG-KEY(s), which are valid for this system, as these Keys are used for signing files, software, etc, so that users can check their received/downloaded software/files are indeed authentic and unmodified in the middle of the way, or not. Need to understand more on NSEC. Thanks in advance, -- Bright Star. Received from Bry8 Star, on 2013-06-26 5:56 PM: > Great, another possible solution could be using CNAMEs. >=20 > More info on CNAME is here: > RFC 6698 Section > A.2.1.1. Provisioning TLSA Records with CNAME Records > https://tools.ietf.org/html/rfc6698#appendix-A.2.1.1 >=20 > More info on DNAME: > https://tools.ietf.org/html/rfc6698#appendix-A.2.1.2 >=20 > Thanks to both of you Viktor, and, Olafur, for all suggestions, > improvements (related to this type of configuration). >=20 > This configuration is intended to be used for a (very) "higher" > security & encryption based service(s), where there is lesser or no > confusion exist in TLSA/DANE and related DNS > declarations/publication, etc. All necessary components are/will be > clearly defined to eliminate (all/most) confusions. Very higher > strength SSL/TLS certs are used in these services. Clients/users > are shown & instructed to use slightly special configurations & > client-software to connect with these services. But it is within > what is publicly available normally in common and major > web-browsers, client-softwares. > Those who do not want to use such configuration, or, those who do > not have various related capacity to process/handle more than one > TLSA based secured & encrypted solution, then such > clients/users/domain-owners/zone-operators may/should use one/single > TLSA and may/should also choose to use shorter version of TLSAs like > "TLSA u s 1" or "TLSA u s 2", instead of two or more full TLS/SSL > cert based TLSA/DANE solution which are used & shown in these > configurations, or choose what fits best for their > implementation/objectives. > In configuration, the choice of variations, permutations and > combinations for TLSA related DNS records, which are allowed or > optionally allowed by related RFCs, are upon > domain-owner/zone-operator/DNS-operator. >=20 > So, previously posted config can be like this ? >=20 > Are these DNS/zone declarations correct ? >=20 > (I've slightly modified & tried to correct per my own understanding. > Changed "im" hostname into "im1", etc, forgot to show DNSKEY RRs, > skipped DS RRs used for subs). >=20 > A zone file: > ; Lines that starts with ";" symbol are inactive. > domA.tld. 3600 IN SOA s1.domA.tld. hostmaster.domA.tld. 2013052910 > 18000 3600 864000 3600 > ; Below two lines are actually active in actual zone file. > ;domA.tld. 3000 IN DNSKEY 256 3 8 HEX_CODE_KEY > ;domA.tld. 3000 IN DNSKEY 257 3 8 HEX_CODE_KEY > ; Since it is targetted for advanced & secured & > ; encrypted usage/purpose, above will be changed, > ; and higher strength encryption will be used. > ; Skipping NSEC. > domA.tld. 3000 IN NS s1.domA.tld. > domA.tld. 3000 IN NS s2.domA.tld. > domA.tld. 300 IN A IP.ADRS_S-1_IPv4 > domA.tld. 300 IN A IP.ADRS_S-2_IPv4 > domA.tld. 300 IN A IP.ADRS_S-IM-1_IPv4 > domA.tld. 300 IN A IP.ADRS_S-IM-2_IPv4 > domA.tld. 300 IN AAAA IP::ADRS_S-1_IPv6 > domA.tld. 300 IN AAAA IP::ADRS_S-2_IPv6 > domA.tld. 300 IN AAAA IP::ADRS_S-IM-1_IPv6 > domA.tld. 300 IN AAAA IP::ADRS_S-IM-2_IPv6 > s1.domA.tld. 900 IN A IP.ADRS_S-1_IPv4 > s2.domA.tld. 900 IN A IP.ADRS_S-2_IPv4 > im1.domA.tld. 900 IN A IP.ADRS_S-IM-1_IPv4 > im2.domA.tld. 900 IN A IP.ADRS_S-IM-2_IPv4 > s1.domA.tld. 900 IN AAAA IP::ADRS_S-1_IPv6 > s2.domA.tld. 900 IN AAAA IP::ADRS_S-2_IPv6 > im1.domA.tld. 900 IN AAAA IP::ADRS_S-IM-1_IPv6 > im2.domA.tld. 900 IN AAAA IP::ADRS_S-IM-2_IPv6 > www.domA.tld. 300 IN CNAME domA.tld. > m.domA.tld. 300 IN CNAME domA.tld. > _http._tcp.domA.tld. 3600 IN SRV 0 0 80 www.domA.tld. > _https._tcp.domA.tld. 3600 IN SRV 0 0 443 www.domA.tld. > _http._tcp.www.domA.tld. 3600 IN SRV 0 0 80 www.domA.tld. > _https._tcp.www.domA.tld. 3600 IN SRV 0 0 443 www.domA.tld. > _http._tcp.m.domA.tld. 3600 IN SRV 0 0 80 m.domA.tld. > _https._tcp.m.domA.tld. 3600 IN SRV 0 0 443 m.domA.tld. > domA.tld. 3600 IN MX 10 s1.domA.tld. > domA.tld. 3600 IN MX 20 s2.domA.tld. > _smtp._tcp.domA.tld. 3600 IN SRV 10 0 25 s1.domA.tld. > _smtp._tcp.domA.tld. 3600 IN SRV 20 0 25 s2.domA.tld. > _smtp._tcp.s1.domA.tld. 3600 IN SRV 10 0 25 s1.domA.tld. > _smtp._tcp.s1.domA.tld. 3600 IN SRV 20 0 25 s2.domA.tld. > _smtp._tcp.s2.domA.tld. 3600 IN SRV 10 0 25 s2.domA.tld. > _smtp._tcp.s2.domA.tld. 3600 IN SRV 20 0 25 s1.domA.tld. > _submission._tcp.domA.tld. 3600 IN SRV 10 0 587 s1.domA.tld. > _submission._tcp.domA.tld. 3600 IN SRV 20 0 587 s2.domA.tld. > _submission._tcp.s1.domA.tld. 3600 IN SRV 10 0 587 s1.domA.tld. > _submission._tcp.s1.domA.tld. 3600 IN SRV 20 0 587 s2.domA.tld. > _submission._tcp.s2.domA.tld. 3600 IN SRV 10 0 587 s2.domA.tld. > _submission._tcp.s2.domA.tld. 3600 IN SRV 20 0 587 s1.domA.tld. > _imaps._tcp.domA.tld. 1200 IN SRV 0 0 993 s1.domA.tld. > _imaps._tcp.domA.tld. 1200 IN SRV 5 0 993 s2.domA.tld. > _imaps._tcp.s1.domA.tld. 1200 IN SRV 0 0 993 s1.domA.tld. > _imaps._tcp.s1.domA.tld. 1200 IN SRV 5 0 993 s2.domA.tld. > _imaps._tcp.s2.domA.tld. 1200 IN SRV 0 0 993 s2.domA.tld. > _imaps._tcp.s2.domA.tld. 1200 IN SRV 5 0 993 s1.domA.tld. > _pops._tcp.domA.tld. 1200 IN SRV 0 0 995 s1.domA.tld. > _pops._tcp.domA.tld. 1200 IN SRV 5 0 995 s2.domA.tld. > _pops._tcp.s1.domA.tld. 1200 IN SRV 0 0 995 s1.domA.tld. > _pops._tcp.s1.domA.tld. 1200 IN SRV 5 0 995 s2.domA.tld. > _pops._tcp.s2.domA.tld. 1200 IN SRV 0 0 995 s2.domA.tld. > _pops._tcp.s2.domA.tld. 1200 IN SRV 5 0 995 s1.domA.tld. > ; Skipping SMTP (Port 26) based 3rd email-server. > _sip._tcp.domA.tld. 1200 IN SRV 0 0 5060 im1.domA.tld. > _sip._tcp.domA.tld. 1200 IN SRV 1 0 5060 im2.domA.tld. > _sip._tcp.domA.tld. 1200 IN SRV 2 0 15060 im1.domA.tld. > _sip._tcp.domA.tld. 1200 IN SRV 3 0 15060 im2.domA.tld. > _sips._tcp.domA.tld. 1200 IN SRV 0 0 5061 im1.domA.tld. > _sips._tcp.domA.tld. 1200 IN SRV 1 0 5061 im2.domA.tld. > _sips._tcp.domA.tld. 1200 IN SRV 2 0 15061 im1.domA.tld. > _sips._tcp.domA.tld. 1200 IN SRV 3 0 15061 im2.domA.tld. > _sip._tcp.im1.domA.tld. 1200 IN SRV 0 0 5060 im1.domA.tld. > _sip._tcp.im1.domA.tld. 1200 IN SRV 1 0 5060 im2.domA.tld. > _sip._tcp.im1.domA.tld. 1200 IN SRV 2 0 15060 im1.domA.tld. > _sip._tcp.im1.domA.tld. 1200 IN SRV 3 0 15060 im2.domA.tld. > _sip._tcp.im2.domA.tld. 1200 IN SRV 0 0 5060 im2.domA.tld. > _sip._tcp.im2.domA.tld. 1200 IN SRV 1 0 15060 im2.domA.tld. > _sip._tcp.im2.domA.tld. 1200 IN SRV 2 0 5060 im1.domA.tld. > _sip._tcp.im2.domA.tld. 1200 IN SRV 3 0 15060 im1.domA.tld. > _sips._tcp.im1.domA.tld. 1200 IN SRV 0 0 5061 im1.domA.tld. > _sips._tcp.im1.domA.tld. 1200 IN SRV 1 0 5061 im2.domA.tld. > _sips._tcp.im1.domA.tld. 1200 IN SRV 2 0 15061 im1.domA.tld. > _sips._tcp.im1.domA.tld. 1200 IN SRV 3 0 15061 im2.domA.tld. > _sips._tcp.im2.domA.tld. 1200 IN SRV 0 0 5061 im2.domA.tld. > _sips._tcp.im2.domA.tld. 1200 IN SRV 1 0 15061 im2.domA.tld. > _sips._tcp.im2.domA.tld. 1200 IN SRV 2 0 5061 im1.domA.tld. > _sips._tcp.im2.domA.tld. 1200 IN SRV 3 0 15061 im1.domA.tld. > ; And multiple XMPP services are configured > ; similar to above SIP services: > _xmpp-client._tcp.domA.tld. 900 IN SRV 0 0 5222 im1.domA.tld. > _xmpp-client._tcp.domA.tld. 900 IN SRV 1 0 5222 im2.domA.tld. > _xmpp-client._tcp.domA.tld. 900 IN SRV 2 0 15222 im1.domA.tld. > _xmpp-client._tcp.domA.tld. 900 IN SRV 3 0 15222 im2.domA.tld. > _xmpp-client._tcp.im1.domA.tld. 900 IN SRV 0 0 5222 im1.domA.tld. > _xmpp-client._tcp.im1.domA.tld. 900 IN SRV 1 0 15222 im1.domA.tld. > _xmpp-client._tcp.im1.domA.tld. 900 IN SRV 2 0 5222 im2.domA.tld. > _xmpp-client._tcp.im1.domA.tld. 900 IN SRV 3 0 15222 im2.domA.tld. > _xmpp-client._tcp.im2.domA.tld. 900 IN SRV 0 0 5222 im2.domA.tld. > _xmpp-client._tcp.im2.domA.tld. 900 IN SRV 1 0 15222 im2.domA.tld. > _xmpp-client._tcp.im2.domA.tld. 900 IN SRV 2 0 5222 im1.domA.tld. > _xmpp-client._tcp.im2.domA.tld. 900 IN SRV 3 0 15222 im1.domA.tld. > _xmpp-server._tcp.domA.tld. 1800 IN SRV 0 0 5269 im1.domA.tld. > _xmpp-server._tcp.domA.tld. 1800 IN SRV 1 0 5269 im2.domA.tld. > _xmpp-server._tcp.domA.tld. 1800 IN SRV 2 0 15269 im1.domA.tld. > _xmpp-server._tcp.domA.tld. 1800 IN SRV 3 0 15269 im2.domA.tld. > _xmpp-server._tcp.im1.domA.tld. 1800 IN SRV 0 0 5269 im1.domA.tld. > _xmpp-server._tcp.im1.domA.tld. 1800 IN SRV 1 0 15269 im1.domA.tld. > _xmpp-server._tcp.im1.domA.tld. 1800 IN SRV 2 0 5269 im2.domA.tld. > _xmpp-server._tcp.im1.domA.tld. 1800 IN SRV 3 0 15269 im2.domA.tld. > _xmpp-server._tcp.im2.domA.tld. 1800 IN SRV 0 0 5269 im2.domA.tld. > _xmpp-server._tcp.im2.domA.tld. 1800 IN SRV 1 0 15269 im2.domA.tld. > _xmpp-server._tcp.im2.domA.tld. 1800 IN SRV 2 0 5269 im1.domA.tld. > _xmpp-server._tcp.im2.domA.tld. 1800 IN SRV 3 0 15269 im1.domA.tld. > ; Skipping rest of SIP related SRV declarations. > ; And multiple IRC services are configured > ; similar to above SIP/XMPP services. > _irc._tcp.domA.tld. 1800 IN SRV 0 0 6667 im1.domA.tld. > _irc._tcp.domA.tld. 3600 IN SRV 1 0 6667 im2.domA.tld. > _irc._tcp.domA.tld. 3600 IN SRV 2 0 6669 im1.domA.tld. > _irc._tcp.domA.tld. 3600 IN SRV 3 0 6669 im2.domA.tld. > _irc._tcp.im1.domA.tld. 1800 IN SRV 0 0 6667 im1.domA.tld. > _irc._tcp.im1.domA.tld. 3600 IN SRV 1 0 6669 im1.domA.tld. > _irc._tcp.im1.domA.tld. 3600 IN SRV 2 0 6667 im2.domA.tld. > _irc._tcp.im1.domA.tld. 3600 IN SRV 3 0 6669 im2.domA.tld. > _irc._tcp.im2.domA.tld. 1800 IN SRV 0 0 6667 im2.domA.tld. > _irc._tcp.im2.domA.tld. 3600 IN SRV 1 0 6669 im2.domA.tld. > _irc._tcp.im2.domA.tld. 3600 IN SRV 2 0 6667 im1.domA.tld. > _irc._tcp.im2.domA.tld. 3600 IN SRV 3 0 6669 im1.domA.tld. > ; Skipping rest of IRC related SRV declarations. > ; Skipped/omitted other DNS RRs. > ; RRSIGs are not mentioned, but they exist when DNSSEC signed. >=20 > Multiple SRV are for load-balancing, etc purpose. And used for > forwarding client/traffic toward different/other server & service, > when/if one of them is down or heavily loaded. >=20 > And TLS / SSL cert full chain componenets: > EE/Server {s1, s2, im1, im2, www, m} > \ <-- IA {domA.tld} > \ <-- CA/TA {Root-CA}. >=20 > And here are TLSA related RRs, > after incorporating CNAME logic: >=20 > _443._tcp.www.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt > _443._tcp.www.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_www-domA-crt > _443._tcp.m.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt > _443._tcp.m.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_m-domA-crt > s1._s.domA.tld. 900 IN TLSA 2 0 1 C_A_D_of_TA-crt > s1._s.domA.tld. 900 IN TLSA 1 0 0 C_A_D_of_s1-domA-crt > s2._s.domA.tld. 900 IN TLSA 2 0 1 C_A_D_of_TA-crt > s2._s.domA.tld. 900 IN TLSA 1 0 0 C_A_D_of_s2-domA-crt > _25._tcp.s1.domA.tld. 360 IN CNAME s1._s.domA.tld. > _25._tcp.s2.domA.tld. 360 IN CNAME s2._s.domA.tld. > _587._tcp.s1.domA.tld. 360 IN CNAME s1._s.domA.tld. > _587._tcp.s2.domA.tld. 360 IN CNAME s2._s.domA.tld. > _993._tcp.s1.domA.tld. 360 IN CNAME s1._s.domA.tld. > _993._tcp.s2.domA.tld. 360 IN CNAME s2._s.domA.tld. > ; Skipping SMTP (Port 26) based 3rd email-server. > im1._im.domA.tld. 900 IN TLSA 2 0 1 C_A_D_of_TA-crt > im1._im.domA.tld. 900 IN TLSA 1 0 0 C_A_D_of_im1-domA-crt > im2._im.domA.tld. 900 IN TLSA 2 0 1 C_A_D_of_TA-crt > im2._im.domA.tld. 900 IN TLSA 1 0 0 C_A_D_of_im2-domA-crt > _5061._tcp.im1.domA.tld. 900 IN CNAME im1._im.domA.tld. > _15061._tcp.im1.domA.tld. 900 IN CNAME im1._im.domA.tld. > _5061._tcp.im2.domA.tld. 900 IN CNAME im2._im.domA.tld. > _15061._tcp.im2.domA.tld. 900 IN CNAME im2._im.domA.tld. > _5223._tcp.im1.domA.tld. 900 IN CNAME im1._im.domA.tld. > _15223._tcp.im1.domA.tld. 900 IN CNAME im1._im.domA.tld. > _5223._tcp.im2.domA.tld. 900 IN CNAME im2._im.domA.tld. > _15223._tcp.im2.domA.tld. 900 IN CNAME im2._im.domA.tld. > _5269._tcp.im1.domA.tld. 900 IN CNAME im1._im.domA.tld. > _15269._tcp.im1.domA.tld. 900 IN CNAME im1._im.domA.tld. > _5269._tcp.im2.domA.tld. 900 IN CNAME im2._im.domA.tld. > _15269._tcp.im2.domA.tld. 900 IN CNAME im2._im.domA.tld. > _6697._tcp.im1.domA.tld. 900 IN CNAME im1._im.domA.tld. > _6699._tcp.im1.domA.tld. 900 IN CNAME im1._im.domA.tld. > _6697._tcp.im2.domA.tld. 900 IN CNAME im2._im.domA.tld. > _6699._tcp.im2.domA.tld. 900 IN CNAME im2._im.domA.tld. >=20 > =3D 12 TLSA lines/rr, and 22 related CNAME lines/rr. > =3D 34 total TLSA related lines/rr. >=20 > (previously, without using CNAME, > this config used 48 TLSA lines/rr, > where each line had TLSA RR). >=20 > And if a ZO (zone-operator) or a domain-owner (D-O) wants to, then > he/she/they can combine & reduce servers and services, by moving all > "im1" services into "s1", and by moving all services from "im2" into > "s2", then there will be even lesser amount of DNS records, but > quality of services will be lower/slower, unless related hardware > and configuration has enough capacity. > A ZO or D-O can do opposite as well: start all on a single or two > machines, and then, move services out to other server, when more > resource assignment will be necessary. >=20 > I could not find usefulness of DNAME or a way to use it for this > specific configuration, without loosing current simple > load-balancing features/advantages. >=20 > But when ZO will add/use/link second domain-name "domB.tld." or > other domain-name based services, on same set of machines, (or on > different set of machines), then DNAME & CNAME could be very useful. >=20 > Wanted to declare even Intermediate TLS/SSL certs ("TLSA u s 1"), to > reduce (related/any-more/further) confusions, but there is now no > way to clearly specify in TLSA which cert is after what in a TLS/SSL > chain. >=20 > Is it a right assessment, that, this type of CNAME or DNAME > forwarding/replacing will need to be supported by DANE-aware > client-software, and also supported by the Full DNSSEC based > DNS-Resolver/DNS-Server which will be used by users in client-side, > for these to work properly. >=20 > Please correct the wrong DNS/zone declarations. >=20 > Thanks in advance, > -- Bright Star. >=20 >=20 >=20 >=20 > Received from Olafur Gudmundsson, on 2013-06-26 5:47 AM: >> >> On Jun 25, 2013, at 11:31 AM, Bry8 Star wrote= : >> >>> When specifying multiple DANE TLSA records for various TLS / SSL >>> supported encrypted communication: >>> >>> Then, if each service port has Two TLSAs, where, one "TLSA 2 s m" >>> (or one "TLSA 0 s m") RR is for declaring Root-CA or TA TLS/SSL >>> cert, and, another "TLSA 1 s m" (or one "TLSA 3 s m") is for >>> declaring EE/Server TLS/SSL cert. >>> >>> Then, it results into lot of same "TLSA 2 s m" (or "TLSA 0 s m") RR >>> for all those services/ports. >>> >>> And, if only one TLSA is declared for each service/port, even then, >>> it results into lot of exact same C_A_D. >>> >>> What can be done to reduce it ? >> >> As Victor notes CNAME is an obvious solution, and it should be the rec= ommended solution as >> it will decrease maintenance if done properly, as when the TLSA record= s need to change that change is done in one place in one zone and all >> the other names inherit the change.=20 >> >> For each service there should be a SINGLE target that everyone points= to, i.e. keeping CNAME chains at length 1=20 >> as much as possible.=20 >> >> If multiple services "share" a crypto context that should be reflected= by having having the services "SINGLE" target point >> to the master context i.e. keeping the chains at length 2, what this d= oes is if at a later point the sharing is undone only the >> "SINGLE" target for the service needs to be updated.=20 >> >> The same can be done for SRV records instead of replicating them in al= l the different locations have CNAME to a "master" location.=20 >> >> A more radical solution is to replace to place DNAME at _tcp when a na= me like _tcp.www. has a subset of the >> names at _tcp.=20 >> Note you can not place DNAME at _nnn._tcp=85.. as the rewrite rule onl= y work at names below the DNAME.=20 >> >> Olafur >> >=20 >=20 >=20 >=20 > Received from Viktor Dukhovni, on 2013-06-25 10:12 AM: >> >> On Tue, Jun 25, 2013 at 08:31:04AM -0700, Bry8 Star wrote: >> >>> Then, if each service port has Two TLSAs, where, one "TLSA 2 s m" >>> (or one "TLSA 0 s m") RR is for declaring Root-CA or TA TLS/SSL >>> cert, and, another "TLSA 1 s m" (or one "TLSA 3 s m") is for >>> declaring EE/Server TLS/SSL cert. >> >=20 > >=20 >> >> When using the same TA for multiple services, or the same EE public >> key for multiple services, you can consolidate TLSA RRs via CNAMEs, >> for example (real life): >> >> _25._tcp.open.nlnetlabs.nl. IN CNAME 3.1.1._dane.nlnetlabs.nl. >> 3.1.1._dane.nlnetlabs.nl. IN TLSA 3 1 1 0D1FCBD71686199607A132744= A4918FC209565C91FA8E9FFEEA0AAFD6B9305F6 >> >>> So, instead of specifying TLSA for same TA crt like this example, in >>> a zone file: >>> >>> _443._tcp.www.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt >> >> Remember to include the full trust anchor certificate in the server's >> chain file, since clients can't reconstruct the certificate from >> its digest. >> >=20 > >=20 >=20 >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 ------enig2MTTTPCDRSWCBNDNHUOOC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJRzJviAAoJEID2ikYfWSP6QjIQAIYWrMgXkn0FQlvhnor0KkP6 PlEPH41q1EoXUZoLudLWbFuq1AF3j7jWjaOzW68XTQCFKQG8dRcKJ3iM7Vku2in0 ORS3tZX8cqOlMS/aazWu4LJM/iI+rhI5L9SbOxcpl7PXRujRwJFCD0m0iMEnDOeZ qhLCBQQ7t0PJwYcW78A+jLukGruBLjPDuQ5iMW7/BY9D8wegsaTY8HUwqf4AIPdf BFIKMHO/xbwILgVn3YNxuR8syKcLua1x7tc/YRXWcH+2QAzTJvnK7a3llfXv5ijc /sA2FUCPmtXu151Qyl6isYvpzRN3SLNcL2oWq2oaS2I1AA0pEQt5RuAucDpnmN/j qoAKkt1lgk/WVQZgazChD/gxgIbOYrpX5zOvVrLhaJ7rRtsyC8P9eveegfpwP950 +94W0sV7xK4su8jMekNCHWlATQPJtb2bvGamcgDrYJOZoNPsnqGoMRanGkWxeThU 5g/h+lw5ldqlsToWSB86AfqmNIIcAeHbir+5RD6ajtUZdPawFE/gedQMDw8areMo B2AH+/+Hju3rM5w1Uoh2uLf5NM2h+SZ8VkAaxvmh6hOkU4W2/J+B+6SaF4k5QLB3 uUc63kvvnIFeUke1WwQZQR1Ynk0I/YZxqitIi0l/LP4b4WwMeqoBdrC2GPpObKMv 2n7JosXNAbhtrPMXYWv4 =Tsz0 -----END PGP SIGNATURE----- ------enig2MTTTPCDRSWCBNDNHUOOC-- From warren@kumari.net Thu Jun 27 14:29: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 283B021F994C for ; Thu, 27 Jun 2013 14:29: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, 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 7rhxRGEpH1Xo for ; Thu, 27 Jun 2013 14:29:23 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3BE521F9E02 for ; Thu, 27 Jun 2013 14:29:23 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.89]) by vimes.kumari.net (Postfix) with ESMTPSA id 01E1D1B407A9; Thu, 27 Jun 2013 17:29:21 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Warren Kumari In-Reply-To: <06445344-CCEA-4284-85D4-771E63EA95FB@kumari.net> Date: Thu, 27 Jun 2013 17:29:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5DC3EF28-1412-452E-AEC5-CA967A768217@kumari.net> References: <253A5DB6-CA83-48E7-93EA-C81E12781105@kumari.net> <0lbo6rvdyz.fsf@wjh.hardakers.net> <06445344-CCEA-4284-85D4-771E63EA95FB@kumari.net> To: Wes Hardaker X-Mailer: Apple Mail (2.1508) Cc: "dane@ietf.org list" Subject: Re: [dane] Decreasing our meeting slot from 1.5h to 1h. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 27 Jun 2013 21:29:28 -0000 On Jun 27, 2013, at 10:36 AM, Warren Kumari wrote: >=20 > On Jun 27, 2013, at 10:13 AM, Wes Hardaker wrote: >=20 >> Warren Kumari writes: >>=20 >>> We had originally asked for a 90 minute slot, but in light of the >>> request we will be offering to change to a 60 minute slot. >>>=20 >>> On the agenda we currently have Wes Hardaker (channeling Viktor) >>> presenting: >>=20 >> To fulfill this request, we should change this to "Wes Hardaker (who >> will be channeling "EKR" who will be channeling "Viktor"). >=20 > Wow, you *can* channel EKR? That's some serious talent. And, luckily, we won't need to see your EKR impersonation, they = (provisionally) scheduled it for 1.5h. W > I'm guessing / hoping that they don't take us up on our limited time = offer, but if they do, we should still managed to fit everything in = without too much rushing -- we'll just make sure we start on time, and = keep the administrivia / faffing to the bare minimum=85. >=20 > W >=20 >> --=20 >> Wes Hardaker =20 >> My Pictures: http://capturedonearth.com/ >> My Thoughts: http://pontifications.hardakers.net/ >>=20 >=20 > -- > Credo quia absurdum est. >=20 >=20 >=20 -- "Go on, prove me wrong. Destroy the fabric of the universe. See if I = care." -- Terry Prachett=20 From viktor1dane@dukhovni.org Thu Jun 27 15:14:50 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 4342111E80F2 for ; Thu, 27 Jun 2013 15:14:50 -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 KKG5u+tIlTE0 for ; Thu, 27 Jun 2013 15:14:45 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 1ABD511E80FA for ; Thu, 27 Jun 2013 15:14:45 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 4253F2AAC77; Thu, 27 Jun 2013 22:14:43 +0000 (UTC) Date: Thu, 27 Jun 2013 22:14:43 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130627221443.GG29420@mournblade.imrryr.org> References: <51C9B7B8.1040403@inventati.org> <51CB8DCB.8010102@inventati.org> <51CC9BD5.8090705@inventati.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51CC9BD5.8090705@inventati.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] How to Reduce Multiple TA/CA "2 s m"/"0 s m" Or Same C_A_D TLSAs Using Wildcard TLSA 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, 27 Jun 2013 22:14:50 -0000 On Thu, Jun 27, 2013 at 01:08:53PM -0700, Bry8 Star wrote: > ; Port 60 is Unassigned. Not used by any real service. > _60._tcp.s1.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt > _60._tcp.s1.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_s1-domA-crt > _60._tcp.s2.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt > _60._tcp.s2.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_s2-domA-crt Publishing "1 0 0" is unwise, full certificates are too big for publishing via DNS. Also publishing both a TA and and EE association is unwise. Pick one of "0 0 1", "1 0 1", "2 0 1" or "3 0 1": 2.0.1.tlsa.example.com. IN TLSA 2 0 1 A trust anchor can be shared across multiple hosts, and multiple services: _25._tcp.mx1.example.com. IN CNAME 2.0.1.tlsa.example.com. _25._tcp.mx2.example.com. IN CNAME 2.0.1.tlsa.example.com. _143._tcp.imap.example.com. IN CNAME 2.0.1.tlsa.example.com. > Client-software which is trying to connect with server's secure port > 5223, they should still be bale to obtain both TLSA: "TLSA 2 0 1" > and "TLSA 1 0 0" and use it for TLS /SSL cert verification for port > 5223, and on success, establish encrypted and authenticated > communication, right ? The "2 0 1" is enough, no need for "1 0 0". Each service chain file needs to also include the TA certificate and any intermediate certificates betweent the TA and the server leaf cert. > Any other way to improve this configuration further ? How to make > it more secured and encrypted? The data in DNS is public-key data. There is nothing to encrypt. > How to add more declarations to > clearly define all components that are used in the system. Add fewer declarations to publish just the current and (when rotating keys) upcoming certificate association for a single carefully chosen (usage, selector, matching-type), and generally use matching type 1, with selector 1 as most likely to be stable and compact. > Need to understand more on NSEC. You shouldn't need to, the NSEC or NSEC3 records are generated automatically by the software that signs your zone file. If NSEC3 support is not yet universal, you may need to tell this software to use NSEC in preference to NSEC3 until NSEC3 support is (effectively) universal. -- Viktor. From marka@isc.org Thu Jun 27 17:29:41 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 F014F21F8FDC for ; Thu, 27 Jun 2013 17:29:41 -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 KpMlJRjo3oE7 for ; Thu, 27 Jun 2013 17:29:37 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 1A29C21F9AC6 for ; Thu, 27 Jun 2013 17:29:37 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id C1238C94EF for ; Fri, 28 Jun 2013 00:29:27 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1372379375; bh=tDtNzbISE/SihD6UtkXjHLGF9cVWiF7PJCXZWhg6Ev0=; h=To:From:References:Subject:In-reply-to:Date; b=kbKGLNEKf+hFosBmPzuuZTCV1WZidF3tsMGqKtgxKE6LoIquMOlhddxO5b1rLkiWp MiV33yaiHJI8hAynfp17b2PrT5CmQFm3+xfElhthmtoO0+fbqD/RhsKZCugnEuVZ+D LXWd26M9Kb7PEbxRInbLLEu3M1WcinxXEv44Anew= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP for ; Fri, 28 Jun 2013 00:29:27 +0000 (UTC) (envelope-from marka@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 815341600A4 for ; Fri, 28 Jun 2013 00:30:46 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 0sX_ueC0Aa5W for ; Fri, 28 Jun 2013 00:30:46 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 272EB1600A3 for ; Fri, 28 Jun 2013 00:30:46 +0000 (UTC) X-Virus-Scanned: amavisd-new at zmx1.isc.org Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Gf2vLXGLRgXY for ; Fri, 28 Jun 2013 00:30:46 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) by zmx1.isc.org (Postfix) with ESMTPSA id CB46E16004A for ; Fri, 28 Jun 2013 00:30:45 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id AF24036620A3 for ; Fri, 28 Jun 2013 10:29:23 +1000 (EST) To: dane@ietf.org From: Mark Andrews References: <51C9B7B8.1040403@inventati.org> <51CB8DCB.8010102@inventati.org> <51CC9BD5.8090705@inventati.org> <20130627221443.GG29420@mournblade.imrryr.org> In-reply-to: Your message of "Thu, 27 Jun 2013 22:14:43 +0000." <20130627221443.GG29420@mournblade.imrryr.org> Date: Fri, 28 Jun 2013 10:29:23 +1000 Message-Id: <20130628002923.AF24036620A3@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Subject: Re: [dane] How to Reduce Multiple TA/CA "2 s m"/"0 s m" Or Same C_A_D TLSAs Using Wildcard TLSA X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 28 Jun 2013 00:29:42 -0000 In message <20130627221443.GG29420@mournblade.imrryr.org>, Viktor Dukhovni writ es: > On Thu, Jun 27, 2013 at 01:08:53PM -0700, Bry8 Star wrote: > > > ; Port 60 is Unassigned. Not used by any real service. > > _60._tcp.s1.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt > > _60._tcp.s1.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_s1-domA-crt > > _60._tcp.s2.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt > > _60._tcp.s2.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_s2-domA-crt > > Publishing "1 0 0" is unwise, full certificates are too big for > publishing via DNS. Also publishing both a TA and and EE association > is unwise. Pick one of "0 0 1", "1 0 1", "2 0 1" or "3 0 1": > > 2.0.1.tlsa.example.com. IN TLSA 2 0 1 > > A trust anchor can be shared across multiple hosts, and multiple services: > > _25._tcp.mx1.example.com. IN CNAME 2.0.1.tlsa.example.com. > _25._tcp.mx2.example.com. IN CNAME 2.0.1.tlsa.example.com. > _143._tcp.imap.example.com. IN CNAME 2.0.1.tlsa.example.com. > > > Client-software which is trying to connect with server's secure port > > 5223, they should still be bale to obtain both TLSA: "TLSA 2 0 1" > > and "TLSA 1 0 0" and use it for TLS /SSL cert verification for port > > 5223, and on success, establish encrypted and authenticated > > communication, right ? > > The "2 0 1" is enough, no need for "1 0 0". Each service chain file > needs to also include the TA certificate and any intermediate > certificates betweent the TA and the server leaf cert. > > > Any other way to improve this configuration further ? How to make > > it more secured and encrypted? > > The data in DNS is public-key data. There is nothing to encrypt. > > > > How to add more declarations to > > clearly define all components that are used in the system. > > Add fewer declarations to publish just the current and (when rotating > keys) upcoming certificate association for a single carefully chosen > (usage, selector, matching-type), and generally use matching type > 1, with selector 1 as most likely to be stable and compact. > > > Need to understand more on NSEC. > > You shouldn't need to, the NSEC or NSEC3 records are generated > automatically by the software that signs your zone file. > > If NSEC3 support is not yet universal, you may need to tell this > software to use NSEC in preference to NSEC3 until NSEC3 support is > (effectively) universal. Truly, one shouldn't use NSEC3 unless one has a need to use NSEC3. It is much more expensive on servers and clients. For most zones NSEC is all that is needed. For some zones NSEC is the only thing that will work. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From bry8star@inventati.org Fri Jun 28 07:34: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 89F0721F85B4 for ; Fri, 28 Jun 2013 07:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QBdOFLwwGOeC for ; Fri, 28 Jun 2013 07:34:47 -0700 (PDT) Received: from diserzione.investici.org (diserzione.investici.org [IPv6:2002:52dd:6399::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2BF21F85BB for ; Fri, 28 Jun 2013 07:33:20 -0700 (PDT) Received: from [82.221.99.153] (diserzione [82.221.99.153]) (Authenticated sender: bry8star@inventati.org) by localhost (Postfix) with ESMTPSA id C9CEC180907 for ; Fri, 28 Jun 2013 14:33:14 +0000 (UTC) X-DKIM: Sendmail DKIM Filter v2.8.2 diserzione.investici.org C9CEC180907 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inventati.org; s=stigmate; t=1372429998; bh=H5pLboRjJUT+dZA8Bc7aBKzMVNNDJnm/wXerGrIQieU=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject:References: In-Reply-To:Content-Type; b=T9zO+g27UcuMEhqEVK3atOdh1d1uANVcbqJVsPU/FyfIkC0GPWczNHDU3MCSALNc5 YI3JnBX0pKs2ZNvY+1D321+pG6nnG8dftQP+Iu2haTjKsAopwholPm+rKqEiyjg8S2 iEac8ILCVgcVEP4swyjLWqxUWz0iRpRfHCQ9/TAQ= Message-ID: <51CD9E8F.5060008@inventati.org> Date: Fri, 28 Jun 2013 07:32:47 -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: <51C9B7B8.1040403@inventati.org> <51CB8DCB.8010102@inventati.org> <51CC9BD5.8090705@inventati.org> <20130627221443.GG29420@mournblade.imrryr.org> <20130628002923.AF24036620A3@drugs.dv.isc.org> In-Reply-To: <20130628002923.AF24036620A3@drugs.dv.isc.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2BXORAWBDVDJTFDUCUGGE" Subject: Re: [dane] How to Reduce Multiple TA/CA "2 s m"/"0 s m" Or Same C_A_D TLSAs Using Wildcard TLSA 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: Fri, 28 Jun 2013 14:34:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2BXORAWBDVDJTFDUCUGGE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable THANKS for all the help as always, and for very very helpful suggestions toward improving this "specific" (not regular purpose) configuration. Reconfiguring based on Viktor's last post's suggestion (suggestion which are suitable and correct for this specific, (not a regular,) configuration, and suitable with its objectives), and also extending/improving my own previous configuration, and so, here is another reduced edition: This system now (still) using 4 servers: S-1, S-2, IM-1, IM-2. If anyone wants to, can transfer IM-1 server's all services inside S-1 server, and transfer IM-2 services inside S-2, if they have enough resources for providing all services. Then various DNS RRs can be reduced even further. A zone file: ; Lines that starts with ";" symbol are inactive. domA.tld. 3600 IN SOA s1.domA.tld. hostmaster.domA.tld. 2013052910 18000 3600 864000 3600 ; Below two lines are actually active in actual zone file. ;domA.tld. 3000 IN DNSKEY 256 3 8 HEX_CODE_KEY ;domA.tld. 3000 IN DNSKEY 257 3 8 HEX_CODE_KEY ; Since it is targeted+geared for "more secured" ; and "higher strength" encrypted services, above will ; be changed: dnskey's strength will be increased. ; Skipping NSEC3. As DNSSEC management software, ; can handle it automatically. domA.tld. 3000 IN NS s1.domA.tld. domA.tld. 3000 IN NS s2.domA.tld. domA.tld. 300 IN A IP.ADRS_S-1_IPv4 domA.tld. 300 IN A IP.ADRS_S-2_IPv4 domA.tld. 300 IN AAAA IP::ADRS_S-1_IPv6 domA.tld. 300 IN AAAA IP::ADRS_S-2_IPv6 ; IP-address of "s" will be "round-robin" based: s.domA.tld. 300 IN A IP.ADRS_S-1_IPv4 s.domA.tld. 300 IN A IP.ADRS_S-2_IPv4 s.domA.tld. 300 IN AAAA IP::ADRS_S-1_IPv6 s.domA.tld. 300 IN AAAA IP::ADRS_S-2_IPv6 s1.domA.tld. 900 IN A IP.ADRS_S-1_IPv4 s2.domA.tld. 900 IN A IP.ADRS_S-2_IPv4 s1.domA.tld. 900 IN AAAA IP::ADRS_S-1_IPv6 s2.domA.tld. 900 IN AAAA IP::ADRS_S-2_IPv6 ; IP-address of "im" will be "round-robin" based: im.domA.tld. 300 IN A IP.ADRS_S-IM-1_IPv4 im.domA.tld. 300 IN A IP.ADRS_S-IM-2_IPv4 im.domA.tld. 300 IN AAAA IP::ADRS_S-IM-1_IPv6 im.domA.tld. 300 IN AAAA IP::ADRS_S-IM-2_IPv6 im1.domA.tld. 900 IN A IP.ADRS_S-IM-1_IPv4 im2.domA.tld. 900 IN A IP.ADRS_S-IM-2_IPv4 im1.domA.tld. 900 IN AAAA IP::ADRS_S-IM-1_IPv6 im2.domA.tld. 900 IN AAAA IP::ADRS_S-IM-2_IPv6 ; IP-address of "s" will be "round-robin" based: www.domA.tld. 300 IN CNAME s.domA.tld. m.domA.tld. 300 IN CNAME s.domA.tld. _http._tcp.domA.tld. 300 IN SRV 0 0 80 www.domA.tld. _https._tcp.domA.tld. 300 IN SRV 0 0 443 www.domA.tld. _http._tcp.www.domA.tld. 300 IN SRV 0 0 80 www.domA.tld. _https._tcp.www.domA.tld. 300 IN SRV 0 0 443 www.domA.tld. _http._tcp.m.domA.tld. 300 IN SRV 0 0 80 m.domA.tld. _https._tcp.m.domA.tld. 300 IN SRV 0 0 443 m.domA.tld. domA.tld. 300 IN MX 10 s.domA.tld. domA.tld. 1800 IN MX 20 s1.domA.tld. domA.tld. 1800 IN MX 20 s2.domA.tld. _smtp._tcp.domA.tld. 300 IN SRV 10 0 25 s.domA.tld. _smtp._tcp.s.domA.tld. 300 IN SRV 10 0 25 s.domA.tld. _smtp._tcp.s.domA.tld. 1800 IN SRV 20 0 25 s1.domA.tld. _smtp._tcp.s.domA.tld. 1800 IN SRV 30 0 25 s2.domA.tld. _submission._tcp.domA.tld. 300 IN SRV 10 0 587 s.domA.tld. _submission._tcp.s.domA.tld. 1800 IN SRV 10 0 587 s.domA.tld. _submission._tcp.s.domA.tld. 1800 IN SRV 20 0 587 s1.domA.tld. _submission._tcp.s.domA.tld. 1800 IN SRV 30 0 587 s2.domA.tld. _imaps._tcp.domA.tld. 300 IN SRV 0 0 993 s.domA.tld. _imaps._tcp.s.domA.tld. 300 IN SRV 0 0 993 s.domA.tld. _imaps._tcp.s.domA.tld. 900 IN SRV 1 0 993 s1.domA.tld. _imaps._tcp.s.domA.tld. 900 IN SRV 2 0 993 s2.domA.tld. _pops._tcp.domA.tld. 300 IN SRV 0 0 995 s.domA.tld. _pops._tcp.s.domA.tld. 300 IN SRV 1 0 995 s.domA.tld. _pops._tcp.s.domA.tld. 900 IN SRV 2 0 995 s1.domA.tld. _pops._tcp.s.domA.tld. 900 IN SRV 3 0 995 s2.domA.tld. ; Skipping SMTP (Port 26) based 3rd email-server. _sip._tcp.domA.tld. 360 IN SRV 0 0 5060 im.domA.tld. _sip._tcp.domA.tld. 360 IN SRV 1 0 15060 im.domA.tld. _sip._tcp.im.domA.tld. 360 IN SRV 0 0 5060 im.domA.tld. _sip._tcp.im.domA.tld. 360 IN SRV 1 0 15060 im.domA.tld. ; Once encrypted Port (5061, 15061) SIP services are working ; completely, then non-encrypted ports will be removed. _sips._tcp.domA.tld. 360 IN SRV 0 0 5061 im.domA.tld. _sips._tcp.domA.tld. 360 IN SRV 1 0 15061 im.domA.tld. _sips._tcp.im.domA.tld. 360 IN SRV 0 0 5061 im.domA.tld. _sips._tcp.im.domA.tld. 360 IN SRV 1 0 15061 im.domA.tld. ; And multiple XMPP services are configured ; similar to above SIP services: _xmpp-client._tcp.domA.tld. 360 IN SRV 0 0 5222 im.domA.tld. _xmpp-client._tcp.domA.tld. 360 IN SRV 1 0 15222 im.domA.tld. _xmpp-client._tcp.im.domA.tld. 360 IN SRV 0 0 5222 im.domA.tld. _xmpp-client._tcp.im.domA.tld. 360 IN SRV 1 0 15222 im.domA.tld. ; Skipping 4 lines (secured sip client port 5223, 15223). ; Once encrypted Port (5223, 15223) XMPP services are working ; completely, then non-encrypted ports will be removed. _xmpp-server._tcp.domA.tld. 360 IN SRV 0 0 5269 im.domA.tld. _xmpp-server._tcp.domA.tld. 360 IN SRV 1 0 5269 im.domA.tld. _xmpp-server._tcp.im.domA.tld. 360 IN SRV 0 0 5269 im.domA.tld. _xmpp-server._tcp.im.domA.tld. 360 IN SRV 1 0 15269 im.domA.tld. ; Skipping rest of XMPP related SRV declarations. ; And multiple IRC services are configured ; similar to above SIP/XMPP services. _irc._tcp.domA.tld. 360 IN SRV 0 0 6667 im.domA.tld. _irc._tcp.domA.tld. 360 IN SRV 1 0 6669 im.domA.tld. _irc._tcp.im.domA.tld. 360 IN SRV 0 0 6667 im.domA.tld. _irc._tcp.im.domA.tld. 360 IN SRV 1 0 6669 im.domA.tld. ; Skipping 4 lines (secured IRC port 6697, 6699). ; Once encrypted Port (6697, 6699) IRC services are working ; completely, then non-encrypted ports will be removed. ; Skipped/omitted other DNS RRs. ; RRSIGs are not mentioned, but they exist when DNSSEC signed. =3D 70 lines of common DNS RRs. In previous config there were 113 lines of common DNS RRs. What is the common service name for the secure port (5223) of xmpp-client ? What is the common service name for the secure port of (6697) od IRC ? And TLS / SSL cert full chain components: EE/Server {s, im, www, m} \ <-- IA {domA.tld} \ <-- CA/TA {Root-CA}. Higher strength TLS/SSL cert. And here are TLSA/DANE related DNS RRs: _443._tcp.www.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt _443._tcp.www.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_www-domA-crt _443._tcp.m.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt _443._tcp.m.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_m-domA-crt ; Port 60 is Unassigned. Not used by any real service. ; And, using such form of TLSA makes more sense: ; _port._proto.zone. [TTL] IN TLSA u s m C_A_D _60._tcp.s.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt _60._tcp.s.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_s-domA-crt _25._tcp.s.domA.tld. 360 IN CNAME _60._tcp.s.domA.tld. _25._tcp.s1.domA.tld. 360 IN CNAME _60._tcp.s.domA.tld. _25._tcp.s2.domA.tld. 360 IN CNAME _60._tcp.s.domA.tld. _587._tcp.s.domA.tld. 360 IN CNAME _60._tcp.s.domA.tld. _587._tcp.s1.domA.tld. 360 IN CNAME _60._tcp.s.domA.tld. _587._tcp.s2.domA.tld. 360 IN CNAME _60._tcp.s.domA.tld. _993._tcp.s.domA.tld. 360 IN CNAME _60._tcp.s.domA.tld. _993._tcp.s1.domA.tld. 360 IN CNAME _60._tcp.s.domA.tld. _993._tcp.s2.domA.tld. 360 IN CNAME _60._tcp.s.domA.tld. ; Skipping SMTP (Port 26) based 3rd email-server. _60._tcp.im.domA.tld. 300 IN TLSA 2 0 1 C_A_D_of_TA-crt _60._tcp.im.domA.tld. 300 IN TLSA 1 0 0 C_A_D_of_im-domA-crt _5061._tcp.im.domA.tld. 300 IN CNAME _60._tcp.im.domA.tld. _15061._tcp.im.domA.tld. 300 IN CNAME _60._tcp.im.domA.tld. _5223._tcp.im.domA.tld. 300 IN CNAME _60._tcp.im.domA.tld. _15223._tcp.im.domA.tld. 300 IN CNAME _60._tcp.im.domA.tld. _5269._tcp.im.domA.tld. 300 IN CNAME _60._tcp.im.domA.tld. _15269._tcp.im.domA.tld. 300 IN CNAME _60._tcp.im.domA.tld. _6697._tcp.im.domA.tld. 300 IN CNAME _60._tcp.im.domA.tld. _6699._tcp.im.domA.tld. 300 IN CNAME _60._tcp.im.domA.tld. =3D 8 TLSA lines/rr, and 17 related CNAME lines/rr. =3D 25 total TLSA related lines/rr. In previous configuration, there were 12 TLSA lines/rr, and 22 related CNAME lines/rr, so in total 34 total TLSA related lines/rr. May be i should use "*" instead of "_60". Should carry more correct meaning & intention. C_A_D =3D Certificate Association Data. Now showing few other declared components: gpg --export GPG_KEY-ID_of_domA-signing@domA.tld > \ domA-signing_GPG_KEY-ID.pubkey.bin make-dns-cert -n domA-signing.domA.tld. \ -k domA-signing_GPG_KEY-ID.pubkey.bin > \ domA-signing_GPG_KEY-ID.pub.big.cert Then codes from "domA-signing_GPG_KEY-ID.pub.big.cert" file can be placed in zone file, such as below DNS RR, in place of . Publish/Declare public-side portion of GPG-KEY. Do not share private key side. Here "full_GPG-KEY" =3D "Entire GPG/PGP-KEY's binary code", used in zone file, with it's equivalent hexadecimal code form (RFC 3548). FPR =3D fpr =3D Fingerprint. When files, software are signed with GPG/PGP-KEY, which is associated with "domA-signing@domA.tld" and "file-signing@domA.tld" email-addresses, then, (based on RFC 4398) : domA-signing.domA.tld. 1800 IN CERT PGP 0 0 file-signing.domA.tld. 1800 IN CNAME domA-signing.domA.tld. HEX-CODE-of-FULL-GPG-KEY-FINGERPRINT 1800 IN CERT PGP 0 0 HEX-CODE-of-SHORT-GPG-KEY-FINGERPRINT 1800 IN CERT PGP 0 0 ; Declaring a developer's GPG-KEY: developer.name.domA.tld. 1800 IN CERT PGP 0 0 If GPG-KEY associated with this above "developer.name@domA.tld" email-adrs has this HEX-CODE-of-FULL-GPG-KEY-FINGERPRINT, then add another DNS RR: HEX-CODE-of-FULL-GPG-KEY-FINGERPRINT 1800 IN CERT PGP 0 0 Objective is to allow client-side users to get authentic & pre-declared (public-key portion of) signing GPG-KEY from DNSSEC based response, and verify downloaded files with it. Many websites still do not share their GPG-KEY in their DNS, and GPG-KEY text files are either on a non-encrypted HTTP (port 80) based web-page ! or, on an encrypted HTTPS (port 443) based webpage, but SSL cert is not declared in TLSA DNS RR ! Caution on CERT, TLSA and other DNS records which have slightly larger data : Each single active line in DNS, (or, The RDATA field in EACH dns RR (resource record) in DNS protocol) may hold upto 65535 octets (64kb) or less data/payload size. So do not exceed that, in any/one line. ; SSHFP: RFC 6594, 4255, 5656, 4716: ; do not use SHA-1 based SSH-keys: s1.domA.tld. 900 IN SSHFP 3 2 Hex_SHA-256_of_SSH-Key s2.domA.tld. 900 IN SSHFP 3 2 Hex_SHA-256_of_SSH-Key im1.domA.tld. 900 IN SSHFP 3 2 Hex_SHA-256_of_SSH-Key im2.domA.tld. 900 IN SSHFP 3 2 Hex_SHA-256_of_SSH-Key Received from Viktor Dukhovni, on 2013-06-27 3:14 PM:> On Thu, Jun 27, 2013 at 01:08:53PM -0700, Bry8 Star wrote: >=20 >> ; Port 60 is Unassigned. Not used by any real service. >> _60._tcp.s1.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt >> _60._tcp.s1.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_s1-domA-crt >> _60._tcp.s2.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt >> _60._tcp.s2.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_s2-domA-crt >=20 > Publishing "1 0 0" is unwise, full certificates are too big for > publishing via DNS. Also publishing both a TA and and EE association > is unwise. Pick one of "0 0 1", "1 0 1", "2 0 1" or "3 0 1": >=20 > 2.0.1.tlsa.example.com. IN TLSA 2 0 1 >=20 I think, What you are suggesting is not accurate for this specific configuration. In below is my "own" explanation of why: ZO =3D Zone Operator . D-O =3D Domain-Owner. A ZO/D-O type of users must choose what is right for their own configuration & system, not what i or someone else would suggest them suddenly without understanding the purpose/objectives & more details of a configuration and system. I think, for general configuration and when used for general purpose, then what you have suggested is best solution. I think, it will be correct for short time. When more software and devices will incorporate full DNSSEC and full DANE support, then combination of two or more TLSA RRs like, "TLSA 2 0 1" and "TLSA 1 0 0", most likely be one of the wise choice. Usage of multiple TLSAs, where EE TLSA clearly telling to look for a TA/CA TLSA, should have clearly indicated that sense to a ZO/D-O and to client(s) and to others. Data bandwidth rate will increase day by day, it will not go down day by day. Newer software and devices will incorporate/adopt the next version of DNS, which is DNSSEC, and will incorporate next version of TLS/SSL solution, which is DANE/CERT etc, all these entities have no choice, and no reason, for always and ONLY support only the old-DNS or only support the older SSL cert technologies, new features must be included and supported, or else they will be less useful and "old". A ZO/D-O type of user, for general case/purpose, can remove either all "TLSA 2 0 1" DNS RRs lines, or, remove all "TLSA 1 0 0" RRs or change them, and transform or adapt the configuration into what you are suggesting. I think, I've already mentioned this previously. And again now one more time here. And for this specific configuration/case, neither my server side, and nor my client-side have any such problem of pulling "big" data and using it. Is there a chart/list which shows different TLS cert key-sizes, and it's respective full TLSA actual binary bytes, that is used in wire ? But this configuration is (targeted / geared-toward / tuned / will-be-used) for such users who must use necessary high-quality and latest components which supports full DNSSEC and supports full DANE. Client-side's TLSA/DANE-preference or TLSA/DANE-settings will forcefully authenticate entire TLS/SSL cert chain's each component using multiple TLSAs from DNSSEC based response, for creating "higher" security. And that is why multiple TLSAs, SSHFP, CERT PGP, etc and finally, DNSSEC signed zone, are used. Or else, this configuration would have used mostly or just regular non-encrypted ports and may be some encrypted ports, and no DNSSEC, no DANE. If someone cannot do or have what is required to use these services (for "whatever" number of reasons and factors), then, i will not stop or down-grade services just for them ! If someone does not have a good router and fair amount of Internet bandwidth and a powerful enough computer, then encrypted IP-Phone service will not work properly, or not work at all, then go somewhere else. For email services, non-encrypted ports (_143, _110, etc) are not even used, and not mentioned in this specific configuration. Same will be done for other ports/services, once encrypted services are working completely, non-encrypted ports will be completely removed (unless an encrypted service requires it, and even then, any non-encrypted service will not be allowed to even initiated/started, as those can loose password and have other vulnerabilities or weaknesses, not welcome in this system). This specific configuration will be used for providing only encrypted connection based services. That is why the emphasis on using more and more TLSA/DANE, and DNSSEC, and other DNS & TLS related technologies. When a full TLS cert is pulled/received from TLS server, and a full TLSA (1 0 0) is pulled from DNS, and then comparing full TLS cert code against the full TLSA (1 0 0) C_A_D, is faster ? or slower ? than such : a TLS cert is pulled from TLS server, and SHA-256 hash checksum is calculated, and then TLSA (1 0 1) is pulled from DNS and checked against TLS cert's hash checksum. How many computational total steps are used in a 64-bits multi-core, multi-threaded computer for these two scenarios ? Most client-side have such, and, servers are usually much more powerful. Bandwidth is not a big factor for now, (for this configuration's system/server-side, and in its targeted client-side, both side have very high-speed and high-bandwidth connections). So PLEASE instruct and HELP to achieve that "higher" or "more secured" solution, (slightly slow or slow speed of operations will be tolerated and ok, but lower security will not be tolerated at-all), that is what i'm asking for, from the 1st post, so please help related to that, then that will be the CORRECT help for this specific configuration. Other suggestion not achieving goal, are not right suggestion for this specific configuration. Someone might say : i asked for a "more secured" solution where each component is DNSSEC and DANE authenticated, and using higher encryption strength TLS certs, then why are you even suggesting wrong things or which is going to create lower security level or will use un-authenticated or will use un-declared components ! >=20 > A trust anchor can be shared across multiple hosts, and multiple servic= es: >=20 > _25._tcp.mx1.example.com. IN CNAME 2.0.1.tlsa.example.com. > _25._tcp.mx2.example.com. IN CNAME 2.0.1.tlsa.example.com. > _143._tcp.imap.example.com. IN CNAME 2.0.1.tlsa.example.com. >=20 THANKS, i've now tried to use the idea from this very very helpful suggestion & help, in topside configuration. I can definitely apply the logic on correct ports for this specific configuration : like _993, _995, _5223 etc. I should've provided same/one type of service, from a same/common/shared one service name and provide from all servers, instead of what i was doing mostly : i used actual (two) server's hostnames, and used them in/for service hostname for different types of services. I was already doing it correctly, but for "www" & "m" services only, (i was using common service name "www" and a common TLSA for that, and provide service from both "s1" & "s2" servers using "round-robin"), and i should have done that for all other services as well. Thanks for pointing it out even those remaining mistakes. >=20 >> Client-software which is trying to connect with server's secure port >> 5223, they should still be bale to obtain both TLSA: "TLSA 2 0 1" >> and "TLSA 1 0 0" and use it for TLS /SSL cert verification for port >> 5223, and on success, establish encrypted and authenticated >> communication, right ? >=20 > The "2 0 1" is enough, no need for "1 0 0". Each service chain file > needs to also include the TA certificate and any intermediate > certificates betweent the TA and the server leaf cert. >=20 I think, your this response is also not accurate for this specific configuration, I'm Not going for and not targeting what is "enough", objective is/are to reach a more "higher" level of security or "much more than enough" level of security or close to 100% authentications. Client side is/will be configured and forced to check entire TLS/SSL cert chain's each component, (in regex term) greedily. That is why at-least two TLSA RRs are used. DANE-aware clients 1st pulls & checks Level-0 / EE / Server TLS/SSL cert, against the EE TLSA, and here EE TLSA (1 0 0) is clearly indicating to check EE TLS/SSL cert and it's full TLS/SSL chain (level after level), and so, eventually, TA TLSA (2 0 1) dns record will be pulled and checked against Root-CA SSL/TLS cert, and then on success, the EE SSL/TLS cert will be used for creating encrypted communication. IA =3D Intermediate Authority. One of the best solution would have been, to have all/100% component(s) of a TLS chain can be authenticated (for this specific configuration based solution, there are currently 3/three TLS components and they are defined or pre-declared in multiple (2 or more) TLSA RRs for each service/port : (1) "www.domA.tld.", "m.domA.tld.", "s.domA.tld.", "im.domA.tld." etc server SSL/TLS certs, checked against their respective EE TLSA ("TLSA 1 0 0") DNS RRs, (2) "domA.tld." IA SSL /TLS cert, checked against it's respective (1st) IA TLSA (either via "TLSA 4 64 1" or "TLSA 4 64 2") DNS RRs, (3) Root-CA SSL cert, checked against it's respective TA TLSA ("TLSA 2 0 1" or "TLSA 2 0 2") DNS RRs. But now shown & proposed IA type of TLSA usage is not supported, so now, cannot be defined, with its exact position, to indicate the IA cert's level position in a full TLS chain. And another better feature would have been, when, Server-side and client-side both could/will pull all/full Keys/Certs from various DNS records and after successful authentication, use EE cert for encrypted connection or communication. Only server-side will have a priv_key in their configuration. for any user, please avoid suggesting which will leave more components undeclared, or please avoid wrong suggestion for this specific configuration, where "more secured" level is expected. >=20 >> Any other way to improve this configuration further ? How to make >> it more secured and encrypted? >=20 > The data in DNS is public-key data. There is nothing to encrypt. >=20 I made one word mistake here, should have used "system" instead of "it". Sorry to create confusion and for using wrong word "it". I meant, system which will use this specific DNS/zone configuration, how can that system's each component be further more DNSSEC (and DANE, where applicable) authenticated/secured, and how to make or configure this system's connection & communication encryption more higher-strength. DNS/zone records are public and open and non-encrypted as always. Unless two zones are used, one for public/outside/external/dmz view, and one for inside/non-public/private view. For such "more secured" configuration & system, should i use all 8 kbits server TLS certs, instead of current 4 kbits server TLS certs, or, should i switch to ECDSA ? for SIP (audio-stream) what type of TLS cert would be better ? for xmpp, irc what type cert would better ? i think, various TLS cert need to be applied & load-tested to get a chart. I have some basic ideas on type of certs, what should be used in which cases, but may be a discussion or a new discussion can reveal further and better guidance for different cases/scenarios. >=20 >=20 >> How to add more declarations to >> clearly define all components that are used in the system. >=20 > Add fewer declarations to publish just the current and (when rotating > keys) upcoming certificate association for a single carefully chosen > (usage, selector, matching-type), and generally use matching type > 1, with selector 1 as most likely to be stable and compact. >=20 >> Need to understand more on NSEC. >=20 > You shouldn't need to, the NSEC or NSEC3 records are generated > automatically by the software that signs your zone file. >=20 > If NSEC3 support is not yet universal, you may need to tell this > software to use NSEC in preference to NSEC3 until NSEC3 support is > (effectively) universal. >=20 That is a big relief, THANKS. Yes, the NSEC3. My very limited understanding is NSEC is suffice, but it have some exploits, so NSEC3 is better. If name-servers have enough bandwidth & computation power, then client-side's full DNSSEC-Resolver will be burdened a lot when NSEC3 is used ? or NSEC is suffice ? Thanks for your help, -- Bright Star. Received from Mark Andrews, on 2013-06-27 5:29 PM: >=20 > In message <20130627221443.GG29420@mournblade.imrryr.org>, Viktor Dukho= vni writ > es: >> On Thu, Jun 27, 2013 at 01:08:53PM -0700, Bry8 Star wrote: >> >>> ; Port 60 is Unassigned. Not used by any real service. >>> _60._tcp.s1.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt >>> _60._tcp.s1.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_s1-domA-crt >>> _60._tcp.s2.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt >>> _60._tcp.s2.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_s2-domA-crt >> >> Publishing "1 0 0" is unwise, full certificates are too big for >> publishing via DNS. Also publishing both a TA and and EE association >> is unwise. Pick one of "0 0 1", "1 0 1", "2 0 1" or "3 0 1": >> >> 2.0.1.tlsa.example.com. IN TLSA 2 0 1 >> >> A trust anchor can be shared across multiple hosts, and multiple servi= ces: >> >> _25._tcp.mx1.example.com. IN CNAME 2.0.1.tlsa.example.com. >> _25._tcp.mx2.example.com. IN CNAME 2.0.1.tlsa.example.com. >> _143._tcp.imap.example.com. IN CNAME 2.0.1.tlsa.example.com. >> >>> Client-software which is trying to connect with server's secure port >>> 5223, they should still be bale to obtain both TLSA: "TLSA 2 0 1" >>> and "TLSA 1 0 0" and use it for TLS /SSL cert verification for port >>> 5223, and on success, establish encrypted and authenticated >>> communication, right ? >> >> The "2 0 1" is enough, no need for "1 0 0". Each service chain file >> needs to also include the TA certificate and any intermediate >> certificates betweent the TA and the server leaf cert. >> >>> Any other way to improve this configuration further ? How to make >>> it more secured and encrypted? >> >> The data in DNS is public-key data. There is nothing to encrypt. >> >> >>> How to add more declarations to >>> clearly define all components that are used in the system. >> >> Add fewer declarations to publish just the current and (when rotating >> keys) upcoming certificate association for a single carefully chosen >> (usage, selector, matching-type), and generally use matching type >> 1, with selector 1 as most likely to be stable and compact. >> >>> Need to understand more on NSEC. >> >> You shouldn't need to, the NSEC or NSEC3 records are generated >> automatically by the software that signs your zone file. >> >> If NSEC3 support is not yet universal, you may need to tell this >> software to use NSEC in preference to NSEC3 until NSEC3 support is >> (effectively) universal. >=20 > Truly, one shouldn't use NSEC3 unless one has a need to use NSEC3. > It is much more expensive on servers and clients. For most zones > NSEC is all that is needed. For some zones NSEC is the only thing > that will work. >=20 > Mark >=20 ------enig2BXORAWBDVDJTFDUCUGGE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJRzZ6bAAoJEID2ikYfWSP6PTsP/3fCdFD8SF8TJcEPPJi7jDGg Dzu09K4ZDGM+lLHN7YA90vV3NUhwoAdNFqkj8P5ivGX8w0oqmC9jUBjgLvs6Pj0b jwH6SoHQlWLfSJ78mOGMzI1QzwzF++aLq9EsGY5WYpBxL9OgxyqPwCjLDiZCxyKE WzBwEp0w9bsc29/VfWhy1Safg8L07wU2lpBbC/wQyOYemwEJYWlCtjk2huE5eQzP vlQ9zl+UifqrZY6pb5AcsemyfeEBe42dMvOol6TnaG2zRTWalqjZJrFoELMK1zuS S6u4Rx1vQDsp8qDCS3q7ijGSZtwRBaqdwMko0ZVB29OJgy+B9IDptihTSV99151z tGqnXzswEzzLUlKBXAJMua9LqPk01jyqjCOepmcdj1RUPlYVvRP+O2vfPdkQSx2V iPccp3g8kv5eFQOO3Av8BBsIoCY6mUvFQcRP4c6ZQIe77MMqfUZmP+T94dLd1Vr0 d2ULuuZqmEDZSMKBOR8uADIFjWGSibxX3BYSY+wrYIis3FAo2e2nYK4lFEcTUSyK erdzBtRk7zwpHw0u8fywK7HcGGd16CkQdpuUhce2nRjYlvsMOBHQFbnFzfdi7GHW U6EEKy6NTNTFqWTElDXRLlE/Cf0lfd/YEZcpVUVqD/lEQsO668zjsfa6W//sB/IP tCcZzHhEA4bv1nNMuCzd =gj71 -----END PGP SIGNATURE----- ------enig2BXORAWBDVDJTFDUCUGGE--