From marc.lampo.ietf@gmail.com Fri Feb 1 07:40: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 6C40121E805E for ; Fri, 1 Feb 2013 07:40:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUGU4XaziBlq for ; Fri, 1 Feb 2013 07:40:50 -0800 (PST) Received: from mail-vb0-f51.google.com (mail-vb0-f51.google.com [209.85.212.51]) by ietfa.amsl.com (Postfix) with ESMTP id C882B21E8030 for ; Fri, 1 Feb 2013 07:40:45 -0800 (PST) Received: by mail-vb0-f51.google.com with SMTP id fq11so2486802vbb.38 for ; Fri, 01 Feb 2013 07:40:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=B49i0gNYxFTGQEmV5jFwP6Lg54HACoK73Cc1Dru51js=; b=owbj+amSSoTMHcE0NE0ltsSi4kb0K7WthNsTW2EHUdDym+hnP6KX/yyJgtyxXDO+SY 1N/vuPoz3jS8qxNAmYqvfCL+lgKsKFKXn3+dW1EJZJo9skup1J40BOlE377PDgNO4tL6 5qcO9Ml3nhm4e1+gzUccyeBSqHPYwl8qafzzFw43Useo35qdceFZ6i8FyFp51H06Mndw /1n0ZBKMolqIZqaHPLFK8zOsNeAB+SCmd+GPevFdo5AlHn4DYqyudgshFXsdk0u3hxc6 aK4qZvL9cJKY/x0LyFO4WzHjbwLiNSGC/HI9r14hhS6Q2SpZJF7LA+lTcS2oXNVFMxSW iA0Q== MIME-Version: 1.0 X-Received: by 10.220.153.69 with SMTP id j5mr11441352vcw.35.1359733245287; Fri, 01 Feb 2013 07:40:45 -0800 (PST) Received: by 10.58.59.38 with HTTP; Fri, 1 Feb 2013 07:40:45 -0800 (PST) In-Reply-To: References: Date: Fri, 1 Feb 2013 16:40:45 +0100 Message-ID: From: Marc Lampo To: Paul Wouters Content-Type: text/plain; charset=ISO-8859-1 Cc: dane WG list Subject: Re: [dane] TLSA - Certificate Usage value 3 - produce one's own identity card ? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 01 Feb 2013 15:40:51 -0000 what I understand in this reply is the concern about the validity of SSL certificates handed out by CA's. I acknowledge that concern, that I share with you. I am however concerned with the suggestion to cover "it" with all DNS means ! Because I know for sure that registering a domain can be and is quite anonymous as well. For the registrars "selling names under a top-level-domain", this is only a low cost product, sometimes given away for free (in return for webhosting), with very little control of the identity of the registrant. And once there is delegation, the registrant could then generate self-signed ceriticates, publish TLSA record with type 3 : "this self-signed certicate is OK, don't alert the user". Hence the original subject : "produce one's own identity card". When I first read the draft, I though this was about "informing the user which CA was used for my official certificate". So, if a trusted CA is hacked and gives out an otherwise valid certifate for my domain, but to an organisation which is not "me", I can still inform my visitors which CA *I* chose for my real certicate. But that seems to be the CAA RR, recently published ... Kind regards, Marc (without trailing 'o' ;-) On Thu, Jan 31, 2013 at 8:13 PM, Paul Wouters wrote: > On Thu, 31 Jan 2013, Marc Lampo wrote: > >> how can the *parent* domain provide the identity ? > > > He who controls the spice, controls the universe! Oh wait, I mean to say > the parent can already take control of all of its children, so yes in > the DNS world, the "ID card" analogy does not quite work. (In the X509 > world, the ID card analogy compares perhaps to US drivers licenses, each > state looks different so no one can really verify the authenticity > anymore) > > So, parent DNS controls child DNS. Child DNS controls where it points > the webserver at. So no new "vulnerabilities" are introduced by putting > trust in selfsigned certs anchored to DNS. > > >> The TLSA record is content of the domain (not the parent) is it ? >> I know that, for DNSSEC, the parent signs the domains public key >> information (DS), >> but that is purely DNSSEC. >> It does not contribute to the identity of the domain holder. >> Or what am I missing ? > > > DNS does not provide "identity" information. But "Domain Validated" (DV) > certificates don't either. Anyone controlling example.com acn get a DV > cert issued by the CABforum members without any identity check. > > If you are talking about EVcerts, apparently CABforum people do more > checks before handing this out, allegedly doing identity validation, > so I would need to provide some Example Inc. paperwork before they > should give me an EV cert. This part cannot be replaced with TLSA > records, although TLSA records can contradict (rogue) EV certs. > > Paul From jakob@kirei.se Fri Feb 1 08:25: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 6546E21E8096 for ; Fri, 1 Feb 2013 08:25:51 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obnnDkdQMUjw for ; Fri, 1 Feb 2013 08:25:50 -0800 (PST) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id 3D11121E8030 for ; Fri, 1 Feb 2013 08:25:49 -0800 (PST) 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=sLdGs82emef7JDjl8cAgiw1yhJ94xaiN4AIRZ7qeqGw=; b=0ltstRGeX3yaxyZVj3Yd44j7IkaIjPn/2CFbdrboGYRcSr3PiFa3SfjvlSxmc2RaBuiyW2Giz+xpZ T89crabkA6jnRYJEuTxZ9/nylZRgsZ1U1UaJJ9+PYNZiVBulJ2W0QJMAbz9MAAneU4m/brA6LuSMks 1mmarRwg75ueT5qY= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Fri, 1 Feb 2013 17:25:46 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jakob Schlyter In-Reply-To: Date: Fri, 1 Feb 2013 08:25:39 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Marc Lampo X-Mailer: Apple Mail (2.1499) Cc: dane WG list Subject: Re: [dane] TLSA - Certificate Usage value 3 - produce one's own identity card ? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 01 Feb 2013 16:25:51 -0000 On 1 feb 2013, at 07:40, Marc Lampo wrote: > I can still inform my visitors which CA *I* chose for my real = certicate. > But that seems to be the CAA RR, recently published ... The primary purpose of the CAA RR is to allow for CAs "to implement = additional controls to reduce the risk of unintended certificate = mis-issue" (quote from RFC 6844). Although it may be used for = certificate evaluators (e.g. the browser) as well, that is not the = primary purpose. jakob From paul.hoffman@vpnc.org Fri Feb 1 08:35: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 A8F4E21E805F for ; Fri, 1 Feb 2013 08:35:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.349 X-Spam-Level: X-Spam-Status: No, score=-102.349 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, GB_ABOUTYOU=0.5, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJaJXiss+-06 for ; Fri, 1 Feb 2013 08:35:09 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3EDD721E8030 for ; Fri, 1 Feb 2013 08:34:55 -0800 (PST) Received: from [10.20.30.90] (50-1-98-243.dsl.dynamic.sonic.net [50.1.98.243]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r11GYqBx050873 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 1 Feb 2013 09:34:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: Date: Fri, 1 Feb 2013 08:34:52 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7408E891-EA21-4673-B42F-86A0B1027655@vpnc.org> References: To: Marc Lampo X-Mailer: Apple Mail (2.1499) Cc: dane WG list Subject: Re: [dane] TLSA - Certificate Usage value 3 - produce one's own identity card ? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 01 Feb 2013 16:35:11 -0000 On Feb 1, 2013, at 7:40 AM, Marc Lampo = wrote: > And once there is delegation, the registrant could then generate > self-signed ceriticates, > publish TLSA record with type 3 : "this self-signed certicate is OK, > don't alert the user". > Hence the original subject : "produce one's own identity card". Anyone, at any time, can produce an identity card for themselves. Kids = in the US who want to drink alcohol before they are 21 have known this = for decades. The trick is to get others to believe it. The current web PKI allows any of hundreds of CAs to act as the ultimate = authority for the ID. DANE allows a domain owner to use the DNSSEC trust = anchor as the ultimate authority for the ID. > When I first read the draft, I though this was about > "informing the user which CA was used for my official certificate". > So, if a trusted CA is hacked and gives out an otherwise valid > certifate for my domain, > but to an organisation which is not "me", > I can still inform my visitors which CA *I* chose for my real = certicate. > But that seems to be the CAA RR, recently published ... It would only seem that if you didn't read the RFC. CAA is not for = informing visitors about your CA, it is for informing diligent CAs about = your CA. --Paul Hoffman= From mrex@sap.com Fri Feb 1 08:36: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 3277621E805F for ; Fri, 1 Feb 2013 08:36:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.219 X-Spam-Level: X-Spam-Status: No, score=-10.219 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ahomTWn3M40r for ; Fri, 1 Feb 2013 08:36:50 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 6BDEC21E8030 for ; Fri, 1 Feb 2013 08:36:50 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r11GalW7027095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 1 Feb 2013 17:36:48 +0100 (MET) In-Reply-To: To: Jakob Schlyter Date: Fri, 1 Feb 2013 17:36:47 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20130201163647.E29F41A4F2@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: dane WG list Subject: Re: [dane] TLSA - Certificate Usage value 3 - produce one's own identity card ? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 16:36:51 -0000 Jakob Schlyter wrote: > > Marc Lampo wrote: > > > > I can still inform my visitors which CA *I* chose for my real certicate. > > But that seems to be the CAA RR, recently published ... > > The primary purpose of the CAA RR is to allow for CAs "to implement > additional controls to reduce the risk of unintended certificate > mis-issue" (quote from RFC 6844). Although it may be used for > certificate evaluators (e.g. the browser) as well, that is not the > primary purpose. TLS clients, including browsers, MUST NOT look at DNS CAA records!! Quoting from rfc6844: Relying Applications MUST NOT use CAA records as part of certificate validation. The content of the CAA is information directed to CAs about permissible issuers for _new_ certificates. They are not necessarily related to the issuer of any currently used certificates, any may differ, i.e. a Web Server might be currently using a certificate from an issuer for which no CAA record exists, and TLS clients (Relying Parties) MUST NOT check this during certificate path validation. -Martin From paul@cypherpunks.ca Fri Feb 1 09:41:57 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA00921E80D2 for ; Fri, 1 Feb 2013 09:41:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ot+J6e+X+7at for ; Fri, 1 Feb 2013 09:41:57 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 0C84021E8040 for ; Fri, 1 Feb 2013 09:41:56 -0800 (PST) Received: by bofh.nohats.ca (Postfix, from userid 500) id 7CAA180597; Fri, 1 Feb 2013 12:41:54 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 6FFD080591; Fri, 1 Feb 2013 12:41:54 -0500 (EST) Date: Fri, 1 Feb 2013 12:41:54 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Marc Lampo In-Reply-To: Message-ID: References: User-Agent: Alpine 2.03 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dane WG list Subject: Re: [dane] TLSA - Certificate Usage value 3 - produce one's own identity card ? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 01 Feb 2013 17:41:58 -0000 On Fri, 1 Feb 2013, Marc Lampo wrote: > I am however concerned with the suggestion to cover "it" with all DNS means ! > Because I know for sure that registering a domain can be and is quite > anonymous as well. and getting a DV cert issued from a random SSL provider from that point onwards is just as anonymous. It does not even require money if you just want it for a few months. So yes, the collective "we" have moved from "click the selfsigned cert warning away" to "be aware of frauds when the URL bar isn't green". Are you suggesting we bring the popups back for non-green URLs in browsers? If not, what _do_ you suggest we do? Paul From sm@resistor.net Sat Feb 2 00:11:45 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7307121F9111 for ; Sat, 2 Feb 2013 00:11:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFncso5kFf5r for ; Sat, 2 Feb 2013 00:11:44 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D39121F9106 for ; Sat, 2 Feb 2013 00:11:43 -0800 (PST) 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 r128BWAM027246; Sat, 2 Feb 2013 00:11:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1359792697; bh=/MORphr5S3STyvUaldIdEuMleF9Is+pmFw6P4o599Mo=; h=Date:To:From:Subject:Cc; b=4QRf5SEIyxR8CB7q0ep5+2Ef4Gkbc/UnGoZnjPdcmCC/bj8Hyd+6MmqiAqDTb1ccu dRRRvW8kWg1QePzIuz8wkcOwZ1pcGqS7OJNsAjGFEsy4T6Ug/0sBtvHUWRth7fm+iG tSfz02Hs72o0xJWPaAQWBdkjrw/0rHqQHEuFAYcE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1359792697; i=@resistor.net; bh=/MORphr5S3STyvUaldIdEuMleF9Is+pmFw6P4o599Mo=; h=Date:To:From:Subject:Cc; b=2aFcIukQPf7qcR0rxk03eNUBPzJlXQEBS61fgho7hRIH9vFR80jxagE1TH44U7syf LJne9QcjRjGZs9x6V9kGBhqU1KnxIeDxJhTslO4uc3te9ByzmZ1J+KGMAC0ycTgJOl gWYLbsaESX17ZmomHJKKF6G4/Ub3UMAUcgREPAfw= Message-Id: <6.2.5.6.2.20130201225257.09a5bb70@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 01 Feb 2013 23:54:26 -0800 To: Tony Finch From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: dane@ietf.org Subject: [dane] Comments on draft-ietf-dane-smtp-00 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 02 Feb 2013 08:11:45 -0000 Hi Tony, I have a few quick comments on draft-ietf-dane-smtp-00. In Section 1: "This memo does not cover message submission [RFC4409] [RFC5068] [RFC6186], nor does it cover LMTP [RFC2033], since they use the DNS in a different way than MTA-to-MTA SMTP." The reference to RFC 4409 should be updated to RFC 6409. In Section 1.1: "Is the Transmitted: header useful enough to include in this spec? Should it be dropped, or perhaps moved to another document?" I suggest sticking to a SMTP versus Message Format split and dropping the Transmitted: header field. In Section 2: "ADMD: An ADministrative Management Domain, as described in the Internet Mail Architecture [RFC5598]." The reference to RFC 5598 should be normative. In Section 3.1: "o A CNAME or DNAME pointing to a successful result." RFC 5321 does not say anything about DNAME. In Section 3.2: "It then proceeds with TLS negotiation [RFC5246]. If the client uses the Server Name Indication TLS extension ([RFC6066] section 3) it MUST use the SMTP server host name as the value for the ServerName field." I am not sure whether to hand-wave by not getting in RFC 6125 details (see Section 7.4 too). In Section 8: "If any of the DNS queries are for an internationalized domain name, then they need to use the A-label form [RFC5890]." I suggest using RFC 6531 as any future clarification for internationalized email (SMTP) would go in there. BTW, why go into intra-domain SMTP? The proposal could take a SMTP client to SMTP server approach and anything not using Section 5 of RFC 5321 is left unspecified (what Section 3.1 refers to as "insecure delivery"). Regards, -sm From fanf2@hermes.cam.ac.uk Sat Feb 2 13:28:15 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2DE721F8539 for ; Sat, 2 Feb 2013 13:28:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.21 X-Spam-Level: X-Spam-Status: No, score=-5.21 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n8IdXa6pDgmJ for ; Sat, 2 Feb 2013 13:28:14 -0800 (PST) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id 29D9E21F86FA for ; Sat, 2 Feb 2013 13:28:14 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:45307) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1U1kd7-0004FH-Yp (Exim 4.72) (return-path ); Sat, 02 Feb 2013 21:28:09 +0000 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1U1kd7-0004dH-Oj (Exim 4.72) (return-path ); Sat, 02 Feb 2013 21:28:09 +0000 Date: Sat, 2 Feb 2013 21:28:09 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: SM In-Reply-To: <6.2.5.6.2.20130201225257.09a5bb70@elandnews.com> Message-ID: References: <6.2.5.6.2.20130201225257.09a5bb70@elandnews.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dane@ietf.org Subject: Re: [dane] Comments on draft-ietf-dane-smtp-00 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 02 Feb 2013 21:28:15 -0000 SM wrote: > Thanks very much for your helpful comments! > The reference to RFC 4409 should be updated to RFC 6409. Thanks. > In Section 1.1: > > "Is the Transmitted: header useful enough to include in this spec? > Should it be dropped, or perhaps moved to another document?" > > I suggest sticking to a SMTP versus Message Format split and dropping the > Transmitted: header field. Note that the details of the Received: header are specified as part of SMTP - RFC 5321 section 4.4. So although I am inclined to agree with your conclusion, your reasoning is flawed :-) > In Section 2: > > "ADMD: An ADministrative Management Domain, as described in the > Internet Mail Architecture [RFC5598]." > > The reference to RFC 5598 should be normative. Wouldn't that be a downref (since RFC 5598 is informational) and therefore wrong? > In Section 3.1: > > "o A CNAME or DNAME pointing to a successful result." > > RFC 5321 does not say anything about DNAME. Would you be happier if I change this text to "A CNAME record (which might be synthesized from a DNAME record) pointing to a successful result"? In fact when I split this document into a generic DANE+SRV/MX document plus a DANE+SMTP document, I plan to describe alias handling better, so the above text will be revised more thoroughly than that. > In Section 3.2: > > "It then proceeds with TLS negotiation [RFC5246]. If the > client uses the Server Name Indication TLS extension ([RFC6066] > section 3) it MUST use the SMTP server host name as the value for the > ServerName field." > > I am not sure whether to hand-wave by not getting in RFC 6125 details (see > Section 7.4 too). No, I think it's really important to get this right and pin down the details, which is why section 7.4 exists. This is not such a problem for SMTP because its certificate name checking does not currently exist; but other SRV-based protocols (such as XMPP and RFC 6186 for MUAs) follow RFC 6125 rules where without DNSSEC they have to check the certificate subject name against the service domain. With DNSSEC they can instead check the certificate against the server host name, since DNSSEC has authenticated the link from service domain to server host name. This is desirable for multi-tenant services since it avoids the need for lots of certificates or large certificates, and it is important for applications like SMTP where a message can relate to multiple service domains. I covered the forwards / backwards compatibility aspects of this a bit better in draft-fanf-dane-mua and I'll fold the relevant parts into the generic DNAE+SRV draft. > In Section 8: > > "If any of the DNS queries are for an internationalized domain name, > then they need to use the A-label form [RFC5890]." > > I suggest using RFC 6531 as any future clarification for internationalized > email (SMTP) would go in there. I'm going to keep the protocol-independent version for the generic spec. I will have a look at RFC 6531 to see if the slimmed-down DANE+SMTP shim needs to say anything more. Thanks for the pointer. > BTW, why go into intra-domain SMTP? The proposal could take a SMTP client to > SMTP server approach and anything not using Section 5 of RFC 5321 is left > unspecified (what Section 3.1 refers to as "insecure delivery"). Because we need to make sure that cross-vendor interop works for private links as well as public ones. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From sm@resistor.net Sat Feb 2 23:14: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 1281521F86F4 for ; Sat, 2 Feb 2013 23:14:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.285 X-Spam-Level: X-Spam-Status: No, score=-102.285 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYESkqJ+kyjj for ; Sat, 2 Feb 2013 23:14:22 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EBCC21F86AC for ; Sat, 2 Feb 2013 23:14:21 -0800 (PST) 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 r137E7Ig011933; Sat, 2 Feb 2013 23:14:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1359875652; bh=yqhKS7qVUhDyHkmCta4hMUk/6/dn8xlC87xVHqgGeJs=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=j4Myjghh6UCJ8EMUs71K6C9dPRUsEOHEM9NyhQPuVTR4Pe8W0cVbzSJEEIWSNDDx/ zBr62sSNAELhYvctIebsvXoo1H1QCiIy1yt7kQ2MrkCV1Pu6S2RAqxjaFgLT/EAkYW aeN4N2eO+4cjcBnKVDx06ZXkRIlIXi5YIbciGs5w= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1359875652; i=@resistor.net; bh=yqhKS7qVUhDyHkmCta4hMUk/6/dn8xlC87xVHqgGeJs=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=kcFoLbpvP+1E28Vdd4C96V9Y/K3YxR5SrYeEaWwIIDmKtbj9uQLkAbA+p8koSv1dO YS6ZqggkwDeEOjLX3ruKMPmBLWdB9LNIPwMZMu7VEmus20YqD3Tk2X8QcXVDcYc3wz FXbRoawKiskVmhfpJc5ILGqucYPc+dvKWqUc8fxA= Message-Id: <6.2.5.6.2.20130202160359.0a017788@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 02 Feb 2013 22:56:43 -0800 To: Tony Finch From: SM In-Reply-To: References: <6.2.5.6.2.20130201225257.09a5bb70@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: dane@ietf.org Subject: Re: [dane] Comments on draft-ietf-dane-smtp-00 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 03 Feb 2013 07:14:24 -0000 Hi Tony, At 13:28 02-02-2013, Tony Finch wrote: >Note that the details of the Received: header are specified as part of >SMTP - RFC 5321 section 4.4. So although I am inclined to agree with your >conclusion, your reasoning is flawed :-) :-) >Wouldn't that be a downref (since RFC 5598 is informational) and therefore >wrong? Yes. It can be called out during the Last Call. RFC 5598 is already in the Downref registry. There shouldn't be any process issue if the reference is normative. >Would you be happier if I change this text to "A CNAME record (which might >be synthesized from a DNAME record) pointing to a successful result"? It's better to leave DNAME to 5321bis. The issue the draft tries to tackle is similar to what is in Section 3.7.2 of RFC 6531, i.e. in this case DNSSEC support. The text in Section 3.1 of the draft discussing about CNAME RRs can be interpreted in different ways. Although I read Section 5.1 of RFC 5321 again I cannot come up with suggested text for now. You already have the main idea in the draft. It's a matter of word-smithing it. Typo in Section 3.1: "successful". >In fact when I split this document into a generic DANE+SRV/MX document >plus a DANE+SMTP document, I plan to describe alias handling better, so >the above text will be revised more thoroughly than that. Alias handling was an issue for SMTP due to an incorrect interpretation of the specification. The discussion was previously controversial. >No, I think it's really important to get this right and pin down the >details, which is why section 7.4 exists. This is not such a problem for >SMTP because its certificate name checking does not currently exist; but >other SRV-based protocols (such as XMPP and RFC 6186 for MUAs) follow RFC >6125 rules where without DNSSEC they have to check the certificate subject >name against the service domain. With DNSSEC they can instead check the >certificate against the server host name, since DNSSEC has authenticated >the link from service domain to server host name. This is desirable for >multi-tenant services since it avoids the need for lots of certificates or >large certificates, and it is important for applications like SMTP where a >message can relate to multiple service domains. I covered the forwards / >backwards compatibility aspects of this a bit better in >draft-fanf-dane-mua and I'll fold the relevant parts into the generic >DNAE+SRV draft. It may end up being more work if the draft attempts to address all the details. Sorry for not being able to provide a clear answer. I will have to review some of the STARTTLS discussions and some other discussions before commenting further about the SMTP angle. I read draft-fanf-dane-mua previously. XMPP should be easier as there is draft-miller-xmpp-dnssec-prooftype-03. In Section 1: "We use DNSSEC to secure the association between a mail domain and its SMTP server host names, and between the host names and their certificates. Connections to servers are authenticated by their TLS certificates." Thinking about this, I would take a SMTP client to SMTP server approach instead of mail domain to SMTP server. The problem description is to secure the client to server connection. This means figuring out the secure delegation part (DNSSEC) and after that the TLS part. I can cover the Smarthost case by reusing some of the logic from secure delegation part. I better stop thinking. :-) Regards, -sm From matthew.kaufman@mi2.com Sun Feb 3 01:16:01 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5609B21F8528 for ; Sun, 3 Feb 2013 01:15:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.344 X-Spam-Level: X-Spam-Status: No, score=0.344 tagged_above=-999 required=5 tests=[AWL=-0.885, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, SARE_SUB_ENC_UTF8=0.152, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywZBNrqIvJ8z for ; Sun, 3 Feb 2013 01:15:51 -0800 (PST) Received: from p3plwbeout14-06.prod.phx3.secureserver.net (p3plsmtp14-06-2.prod.phx3.secureserver.net [173.201.192.192]) by ietfa.amsl.com (Postfix) with ESMTP id 9E37521F85DC for ; Sun, 3 Feb 2013 01:15:49 -0800 (PST) Received: from localhost ([10.6.247.10]) by p3plwbeout14-06.prod.phx3.secureserver.net with bizsmtp id vlFh1k0010EBgJJ01lFh4e; Sun, 03 Feb 2013 02:15:41 -0700 X-SID: vlFh1k0010EBgJJ01 Received: (qmail 18544 invoked by uid 99); 3 Feb 2013 09:15:41 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" X-Originating-IP: 68.80.104.228 User-Agent: Workspace Webmail 5.6.32 Message-Id: <20130203021540.5339fc2bd25bead7c8d75e9635a94f27.4ef81d89db.wbe@email14.secureserver.net> From: To: dane@ietfa.amsl.com Date: Sun, 03 Feb 2013 02:15:40 -0700 Mime-Version: 1.0 Subject: [dane] =?utf-8?q?Confirm=3A_dadane=40ietfa=2Eamsl=2Ecom=3A1WeeiyU?= =?utf-8?q?Q4fJA=3AVURdBx0NTB4o3nF0=5FWDZL5D=5FnkmAQCmXymoNkA?= X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 03 Feb 2013 09:16:01 -0000

From marc.lampo.ietf@gmail.com Mon Feb 4 11:43: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 DD06521F8A84 for ; Mon, 4 Feb 2013 11:43:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Znekf+a08lOU for ; Mon, 4 Feb 2013 11:43:06 -0800 (PST) Received: from mail-vc0-f181.google.com (mail-vc0-f181.google.com [209.85.220.181]) by ietfa.amsl.com (Postfix) with ESMTP id A060821F8A77 for ; Mon, 4 Feb 2013 11:43:05 -0800 (PST) Received: by mail-vc0-f181.google.com with SMTP id d16so4118824vcd.40 for ; Mon, 04 Feb 2013 11:43:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=OWT/pZ19W/H2LKjhhJYq1XLltwm8l5Fu6a2QlUZaJC0=; b=MfWsT426LWclZUNxrhE1lAsHwNelW3nXBO6b1atUynv+HHt2ljq8kX2IEeHzuUA9Hd JAXeOak9qFDojIB0E7X7KvqCeQbTQwD1KzlWUFLPu8qKB4MM0Ob6caJ4uXadH+y1fQRj obiQ4IgtPHiaIZQn9Hc263b2jvnK6kedLXYuY5NU1X/GS/wu6mM/Yt8X5IUwuBZ9pjXh fYEBr4NaTKqF6qGtNmVD4m8Ok62ysz88I2mPj1KzPwivG+q9Y+O2AV7ddyadsMoEJw6l 61+4IF5vI8JPcK6QuOLV8BR74IvkT5GkarsEFegF2W01zzWU8v06H3jtQ3TFrtzNfRA+ njBg== MIME-Version: 1.0 X-Received: by 10.58.132.170 with SMTP id ov10mr19883195veb.57.1360006979902; Mon, 04 Feb 2013 11:42:59 -0800 (PST) Received: by 10.58.59.38 with HTTP; Mon, 4 Feb 2013 11:42:59 -0800 (PST) In-Reply-To: References: Date: Mon, 4 Feb 2013 20:42:59 +0100 Message-ID: From: Marc Lampo To: dane WG list Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [dane] TLSA - Certificate Usage value 3 - produce one's own identity card ? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 04 Feb 2013 19:43:07 -0000 Indeed, thanks for pointing out, CAA is meant to be used at certificate issue time; an oversight of mine. For the TLSA record, upon rereading that RFC, I think the values 0 and 1 for the certificate usage field are OK. Together with an official CA, the domain administrator can, via another way (DNS-DNSSEC) inform the users of the CA that has been chosen for the domain. There are a number of cases were this does not contribute to security (malicious user who obtained a certificate and publishes corresponding TSLA RR); but good/genuine users can inform the users of the CA that has been chosen. If there is support at client side, they now have the capability to detect a "weird" certificate : apparently correct, by trusted CA, but not chosen by the domain (cfr Diginotar case) However values 2 and 3 introduce a way to use DNS only. The certificate is still used - because is is simply a built-in and widely supported way to encrypt - but the "who has created the certificate" is irrelevant, since, via the TLSA record with given valuers, the domain admin can simply OK whatever certificate generated locally. This shift (in who provides identity) from "only trusted CA" to "only via DNS info" is, in my opinion, a bad idea. Probably, as Paul Wouters contributed in this conversation, it is possible to obtain genuine certificates from not so good CA's, but a complete shift to DNS only is no improvement. As it is possible to register domain names with hardly any identity verification as well. Kind regards, Marc On Fri, Feb 1, 2013 at 6:41 PM, Paul Wouters wrote: > On Fri, 1 Feb 2013, Marc Lampo wrote: > >> I am however concerned with the suggestion to cover "it" with all DNS >> means ! >> Because I know for sure that registering a domain can be and is quite >> anonymous as well. > > > and getting a DV cert issued from a random SSL provider from that point > onwards is just as anonymous. It does not even require money if you just > want it for a few months. > > So yes, the collective "we" have moved from "click the selfsigned cert > warning away" to "be aware of frauds when the URL bar isn't green". > > Are you suggesting we bring the popups back for non-green URLs in > browsers? If not, what _do_ you suggest we do? > > Paul From kent@bbn.com Mon Feb 4 12:12: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 506DD21F8503 for ; Mon, 4 Feb 2013 12:12:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBcT8deAqZSS for ; Mon, 4 Feb 2013 12:12:17 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id A807B21F84FC for ; Mon, 4 Feb 2013 12:12:17 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:56858 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1U2SOk-000Kpw-4Y; Mon, 04 Feb 2013 15:12:14 -0500 Message-ID: <5110161D.1000109@bbn.com> Date: Mon, 04 Feb 2013 15:12:13 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Paul Wouters References: <510AD83D.6030307@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dane WG list Subject: Re: [dane] TLSA - Certificate Usage value 3 - produce one's own identity card ? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 04 Feb 2013 20:12:18 -0000 Paul, The assertion by the parent relates to the DNS name, nothing more. But, that name is under the control of the appropriate entity, in the DNS context. More importantly, that entity is limited in the range of DNS names for which it can create a signed assertion, unlike in the browser PKI context. So, I think that makes the DANE approach to binding a public key to a web site DNS name much more secure than the current browser PKI approach. Steve From paul.hoffman@vpnc.org Mon Feb 4 12:26: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 A1D7B21F8B0E for ; Mon, 4 Feb 2013 12:26:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4e8vreWGK7-H for ; Mon, 4 Feb 2013 12:26:30 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 448E421F8B0A for ; Mon, 4 Feb 2013 12:26:30 -0800 (PST) Received: from [10.20.30.90] (50-1-98-243.dsl.dynamic.sonic.net [50.1.98.243]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r14KQR55093000 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 4 Feb 2013 13:26:27 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: Date: Mon, 4 Feb 2013 12:26:26 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Marc Lampo X-Mailer: Apple Mail (2.1499) Cc: dane WG list Subject: Re: [dane] TLSA - Certificate Usage value 3 - produce one's own identity card ? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 04 Feb 2013 20:26:30 -0000 On Feb 4, 2013, at 11:42 AM, Marc Lampo = wrote: > For the TLSA record, upon rereading that RFC, I think the values 0 and = 1 for > the certificate usage field are OK. They are all "OK". If you don't like one of the usage types, don't use = it. --Paul Hoffman= From paul@cypherpunks.ca Mon Feb 4 21:18: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 1C09421F878F for ; Mon, 4 Feb 2013 21:18:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3v8r2t3m01K for ; Mon, 4 Feb 2013 21:18:04 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB2921F85D4 for ; Mon, 4 Feb 2013 21:18:03 -0800 (PST) Received: by bofh.nohats.ca (Postfix, from userid 500) id 69F2980597; Tue, 5 Feb 2013 00:18:01 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 533BD8050C; Tue, 5 Feb 2013 00:18:01 -0500 (EST) Date: Tue, 5 Feb 2013 00:18:01 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Marc Lampo In-Reply-To: Message-ID: References: User-Agent: Alpine 2.03 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: dane WG list Subject: Re: [dane] TLSA - Certificate Usage value 3 - produce one's own identity card ? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 05 Feb 2013 05:18:05 -0000 On Mon, 4 Feb 2013, Marc Lampo wrote: > This shift (in who provides identity) from "only trusted CA" to "only > via DNS info" There _is_ no shift. Whoever controls the DNS can do either things: - Create MX to receive email for the domain, and get a valid CA signed cert. - Create their own self signed cert, and put in a TLSA record. "Only trusted CA" is a lie. If I control your DNS, I can get a "trusted CA" certificate too. > it is possible to obtain genuine certificates from not so good CA's, > but a complete shift to DNS only is no improvement. This has nothing to do with "not so good CAs". If I control you DNS, I can get any "good CA" to issue a cert for me. And again, this _is_ different for EV certs but they are rare, expensive and per definition won't scale. Paul From wes@hardakers.net Tue Feb 5 08:15: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 683E021F893E for ; Tue, 5 Feb 2013 08:15:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6l0d0Flb6RSU for ; Tue, 5 Feb 2013 08:15:51 -0800 (PST) Received: from mail.hardakers.net (unknown [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id BC1AA21F88B0 for ; Tue, 5 Feb 2013 08:15:51 -0800 (PST) Received: from localhost (unknown [IPv6:2001:470:1f00:187:dd8:ca77:1cd8:c51b]) by mail.hardakers.net (Postfix) with ESMTPSA id EB8D89E; Tue, 5 Feb 2013 08:15:50 -0800 (PST) From: Wes Hardaker To: Marc Lampo References: Date: Tue, 05 Feb 2013 08:15:50 -0800 In-Reply-To: (Marc Lampo's message of "Mon, 4 Feb 2013 20:42:59 +0100") Message-ID: <0l622668jt.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: dane WG list Subject: Re: [dane] TLSA - Certificate Usage value 3 - produce one's own identity card ? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 05 Feb 2013 16:15:52 -0000 Marc Lampo writes: > There are a number of cases were this does not contribute to security > (malicious user who obtained a certificate and publishes > corresponding TSLA RR); It's worth noting that in order to do the above, you only had to trick a CA into issuing a cert *and* you must have control over the DNS for the domain, whereas before you had to only trick a CA into issuing a cert. So the bar has been raised for sites that have published a TLSA record. So it certainly does contribute to security as it increases the infrastructure that an attacker must target to succeed in a take-over. -- Wes Hardaker My Pictures: http://capturedonearth.com/ My Thoughts: http://pontifications.hardakers.net/ From cloos@jhcloos.com Tue Feb 12 13:07: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 2D54921F8C16 for ; Tue, 12 Feb 2013 13:07:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.612 X-Spam-Level: X-Spam-Status: No, score=0.612 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FAKE_REPLY_C=2.012, J_CHICKENPOX_33=0.6, J_CHICKENPOX_84=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MRPXP-JifW2S for ; Tue, 12 Feb 2013 13:07:42 -0800 (PST) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2604:8800:100:81ca::53]) by ietfa.amsl.com (Postfix) with ESMTP id 6039121F8BC9 for ; Tue, 12 Feb 2013 13:07:39 -0800 (PST) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 59813401C0; Tue, 12 Feb 2013 21:07:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1360703258; bh=+W00AQ2ZaPXuNjnCgcnd+VJZPkQUPd/QDNTQaUuW2Ec=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; b=Ulw1R+4C1A82DSHX3ltHmTIi6YuEIWS2lra4lVEUSIUEeB4pUMAiCoOm72f2nRsJQ 2onzvJ2cYD7KV/0RMwtaTNQMLf6ooK6Yccvxx0vD54dCs5DHdwSu5qKy+fjo/DICQg QXn50XAWpiTOpfmV6+5pD/PS8dfEBmaIQ8ktp7pI= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 2D4FD6007A; Tue, 12 Feb 2013 21:06:08 +0000 (UTC) From: James Cloos To: dane@ietf.org User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.3.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2013 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Tue, 12 Feb 2013 16:06:08 -0500 Message-ID: Lines: 49 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:130212:dane@ietf.org::oEJyJ1BxBFt693VE:000OLRCK Subject: Re: [dane] draft-fanf-dane-mua-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: Tue, 12 Feb 2013 21:07:49 -0000 I finally made time to read it through in one sitting. And it looks spot on. (Presuming I correctly grokked the intent. :) AIUI: When dnssec is bogus: die!die!die! ;^) In the case where dnssec is unavailable: if the server was specified by the user: that hostname:port is used for sni (and CN if the client lacks sni) or, if the server was specified via SRV: the email addr's right-hand-part is used for sni (and CN if the client lacks sni) When dnssec is available and verifies: whether the server was specified by the user or via SRV: that hostname:port is use for tlsa, sni (and CN if the client lacks sni) if tlsa rr exists: the server MUST support tls With, in the non-SRV cases, port defaulting to: tcp/143 for imap:// tcp/993 for imaps:// tcp/110 for pop:// tcp/995 for pops:// tcp/587 for submission:// Yes? That seems to meet all of the needs and current realities. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From fanf2@hermes.cam.ac.uk Wed Feb 13 03:50: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 8C5EC21F8800 for ; Wed, 13 Feb 2013 03:50:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.841 X-Spam-Level: X-Spam-Status: No, score=-5.841 tagged_above=-999 required=5 tests=[AWL=0.758, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7oMJ-vPNK8tF for ; Wed, 13 Feb 2013 03:50:51 -0800 (PST) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id C6D5C21F87FD for ; Wed, 13 Feb 2013 03:50:38 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:40249) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1U5arE-0007qC-Xy (Exim 4.72) (return-path ); Wed, 13 Feb 2013 11:50:36 +0000 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1U5arE-0006Aw-GE (Exim 4.72) (return-path ); Wed, 13 Feb 2013 11:50:36 +0000 Date: Wed, 13 Feb 2013 11:50:36 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: James Cloos In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dane@ietf.org Subject: Re: [dane] draft-fanf-dane-mua-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: Wed, 13 Feb 2013 11:50:52 -0000 James Cloos wrote: > > Yes? Yes! > That seems to meet all of the needs and current realities. Good :-) Thanks for the review. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From internet-drafts@ietf.org Mon Feb 18 15:59: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 A4F5C21E80A5; Mon, 18 Feb 2013 15:59:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ra65ivEJe1fk; Mon, 18 Feb 2013 15:59:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3A121E804C; Mon, 18 Feb 2013 15:59:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130218235905.31260.77742.idtracker@ietfa.amsl.com> Date: Mon, 18 Feb 2013 15:59:05 -0800 Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-srv-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, 18 Feb 2013 23:59:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DNS-based Authentication of Named Entitie= s Working Group of the IETF. Title : Using DNS-Based Authentication of Named Entities (DANE) = TLSA records with SRV and MX records. Author(s) : Tony Finch Filename : draft-ietf-dane-srv-00.txt Pages : 10 Date : 2013-02-18 Abstract: The DANE specification [RFC6698] describes how to use TLSA resource records in the DNS to associate a server's host name with its TLS certificate. The association is secured with DNSSEC. Some application protocols can use SRV records [RFC2782] to indirectly name the server hosts for a service domain. (SMTP uses MX records for the same purpose.) This specification gives generic instructions for how these application protocols locate and use TLSA records. Separate documents give the details that are specific to particular application protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-srv There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dane-srv-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From fanf2@hermes.cam.ac.uk Mon Feb 18 16:05: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 3E58321E80B3 for ; Mon, 18 Feb 2013 16:05:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.95 X-Spam-Level: X-Spam-Status: No, score=-5.95 tagged_above=-999 required=5 tests=[AWL=0.649, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id InSpuUk3HfZH for ; Mon, 18 Feb 2013 16:04:59 -0800 (PST) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by ietfa.amsl.com (Postfix) with ESMTP id 221D221E80A8 for ; Mon, 18 Feb 2013 16:04:58 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:45985) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1U7ahd-0001Lm-Rs (Exim 4.72) for dane@ietf.org (return-path ); Tue, 19 Feb 2013 00:04:57 +0000 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1U7ahd-0005Tv-Jt (Exim 4.72) for dane@ietf.org (return-path ); Tue, 19 Feb 2013 00:04:57 +0000 Date: Tue, 19 Feb 2013 00:04:57 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: dane@ietf.org In-Reply-To: <20130218235905.31260.46052.idtracker@ietfa.amsl.com> Message-ID: References: <20130218235905.31260.46052.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Subject: Re: [dane] New Version Notification for draft-ietf-dane-srv-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: Tue, 19 Feb 2013 00:05:00 -0000 This is to get my foot in the door before the -00 cutoff. It still has some text missing so there should be a more complete version before next week. internet-drafts@ietf.org wrote: > > A new version of I-D, draft-ietf-dane-srv-00.txt > has been successfully submitted by Tony Finch and posted to the > IETF repository. > > Filename: draft-ietf-dane-srv > Revision: 00 > Title: Using DNS-Based Authentication of Named Entities (DANE) TLSA records with SRV and MX records. > Creation date: 2013-02-18 > Group: dane > Number of pages: 10 > URL: http://www.ietf.org/internet-drafts/draft-ietf-dane-srv-00.txt > Status: http://datatracker.ietf.org/doc/draft-ietf-dane-srv > Htmlized: http://tools.ietf.org/html/draft-ietf-dane-srv-00 > > Abstract: > The DANE specification [RFC6698] describes how to use TLSA resource > records in the DNS to associate a server's host name with its TLS > certificate. The association is secured with DNSSEC. Some > application protocols can use SRV records [RFC2782] to indirectly > name the server hosts for a service domain. (SMTP uses MX records > for the same purpose.) This specification gives generic instructions > for how these application protocols locate and use TLSA records. > Separate documents give the details that are specific to particular > application protocols. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From internet-drafts@ietf.org Mon Feb 25 14:15:48 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B52E21E80FC; Mon, 25 Feb 2013 14:15:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e6iBtdPtwgUB; Mon, 25 Feb 2013 14:15:48 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6970421E8114; Mon, 25 Feb 2013 14:15:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130225221545.27248.62582.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 14:15:45 -0800 Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-srv-01.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, 25 Feb 2013 22:15:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DNS-based Authentication of Named Entitie= s Working Group of the IETF. Title : Using DNS-Based Authentication of Named Entities (DANE) = TLSA records with SRV and MX records. Author(s) : Tony Finch Filename : draft-ietf-dane-srv-01.txt Pages : 11 Date : 2013-02-25 Abstract: The DANE specification [RFC6698] describes how to use TLSA resource records in the DNS to associate a server's host name with its TLS certificate. The association is secured with DNSSEC. Some application protocols can use SRV records [RFC2782] to indirectly name the server hosts for a service domain. (SMTP uses MX records for the same purpose.) This specification gives generic instructions for how these application protocols locate and use TLSA records. Separate documents give the details that are specific to particular application protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-srv There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dane-srv-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dane-srv-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Feb 25 15:46: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 654AD21E8179; Mon, 25 Feb 2013 15:46:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CGK+2NwEQNSz; Mon, 25 Feb 2013 15:46:24 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A38B21E8198; Mon, 25 Feb 2013 15:46:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130225234623.16185.86947.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 15:46:23 -0800 Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-smtp-01.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, 25 Feb 2013 23:46:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DNS-based Authentication of Named Entitie= s Working Group of the IETF. Title : Secure SMTP using DNS-Based Authentication of Named Enti= ties (DANE) TLSA records. Author(s) : Tony Finch Filename : draft-ietf-dane-smtp-01.txt Pages : 9 Date : 2013-02-25 Abstract: SMTP has a STARTTLS extension, but (especially in the case of inter- domain mail transfer) it only provides very limited security because it does not specify how to authenticate the server's certificate. This memo specifies how TLSA records in the DNS can be used for proper SMTP server authentication. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-smtp There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dane-smtp-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dane-smtp-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Feb 25 15:46:43 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28B8F21E81A6; Mon, 25 Feb 2013 15:46:43 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29x4TRb9Ft1t; Mon, 25 Feb 2013 15:46:42 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 967D121E81A7; Mon, 25 Feb 2013 15:46:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130225234639.16195.57113.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 15:46:39 -0800 Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-srv-02.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, 25 Feb 2013 23:46:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DNS-based Authentication of Named Entitie= s Working Group of the IETF. Title : Using DNS-Based Authentication of Named Entities (DANE) = TLSA records with SRV and MX records. Author(s) : Tony Finch Filename : draft-ietf-dane-srv-02.txt Pages : 12 Date : 2013-02-25 Abstract: The DANE specification [RFC6698] describes how to use TLSA resource records in the DNS to associate a server's host name with its TLS certificate. The association is secured with DNSSEC. Some application protocols can use SRV records [RFC2782] to indirectly name the server hosts for a service domain. (SMTP uses MX records for the same purpose.) This specification gives generic instructions for how these application protocols locate and use TLSA records. Separate documents give the details that are specific to particular application protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-srv There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dane-srv-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dane-srv-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/