From nobody Sat Mar 1 00:42:57 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D51B1A0404 for ; Fri, 28 Feb 2014 17:52:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.59 X-Spam-Level: X-Spam-Status: No, score=-1.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KqNPBrGReNIP for ; Fri, 28 Feb 2014 17:52:55 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) by ietfa.amsl.com (Postfix) with ESMTP id 5A01F1A03A1 for ; Fri, 28 Feb 2014 17:52:55 -0800 (PST) Received: from sandelman.ca (CPE001b2128d533-CM185933f8bd5e.cpe.net.cable.rogers.com [99.240.158.182]) by relay.sandelman.ca (Postfix) with ESMTPS id DE8732207A; Fri, 28 Feb 2014 20:52:52 -0500 (EST) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id E6BAECA0D7; Fri, 28 Feb 2014 20:52:50 -0500 (EST) From: Michael Richardson To: Simo Sorce In-reply-to: <1393617370.22047.22.camel@willson.li.ssimo.org> References: <912.1393614300@sandelman.ca> <1393617370.22047.22.camel@willson.li.ssimo.org> Comments: In-reply-to Simo Sorce message dated "Fri, 28 Feb 2014 14:56:10 -0500." X-Mailer: MH-E 8.2; nmh 1.3; GNU Emacs 23.4.1 Date: Fri, 28 Feb 2014 20:52:50 -0500 Message-ID: <17001.1393638770@sandelman.ca> Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/dane/6Hg4Ge4cprdjX7TuyOO7uU7jnrU X-Mailman-Approved-At: Sat, 01 Mar 2014 00:42:56 -0800 Cc: dane WG list Subject: Re: [dane] An AD bit discussion X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2014 01:52:56 -0000 Simo Sorce wrote: >> For this reason, I think that applications should not set or depend >> upon the AD bit, even if the resolver is ::1. They either understand >> DNS(SEC), or they use an API call way more sophisticated than >> getaddrinfo() to do their connections. Java had the right idea, but >> the implementation and error reporting was very poor. > Nothing in this proposal prevents you from doing that for applications > you care about. OTOH forcing applications to a completely new API by > refusing this proposal on your grounds will guarantee less applications > will use DNSSEC. And DNSEC support will rapidly fragment making > system-wide management a lot more difficult. I think that prospect is a > much worse evil. If I understand what you are saying, you are worried that different applications will make up different DNSSEC APIs, and each application will have different controls. I am not opposed to centralized DNSSEC resolution (whether on the same host, or via a trusted channel). It's that I am dissastified with "SERVFAIL" as the only indication of a problem... -- Michael Richardson -on the road- From nobody Sat Mar 1 10:05:20 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE12B1A026A for ; Sat, 1 Mar 2014 10:05:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.55 X-Spam-Level: X-Spam-Status: No, score=-5.55 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vC9flUPvY9nz for ; Sat, 1 Mar 2014 10:05:13 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id D99491A0262 for ; Sat, 1 Mar 2014 10:05:11 -0800 (PST) Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s21I58er029012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 1 Mar 2014 13:05:08 -0500 Received: from [10.3.113.6] ([10.3.113.6]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s21I57SL000418; Sat, 1 Mar 2014 13:05:07 -0500 From: Simo Sorce To: Michael Richardson In-Reply-To: <17001.1393638770@sandelman.ca> References: <912.1393614300@sandelman.ca> <1393617370.22047.22.camel@willson.li.ssimo.org> <17001.1393638770@sandelman.ca> Content-Type: text/plain; charset="UTF-8" Organization: Red Hat, Inc. Date: Sat, 01 Mar 2014 13:05:07 -0500 Message-ID: <1393697107.22047.24.camel@willson.li.ssimo.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/9s8q5UXavPiQ1gM2rOD0La-dLuc Cc: dane WG list Subject: Re: [dane] An AD bit discussion X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2014 18:05:19 -0000 On Fri, 2014-02-28 at 20:52 -0500, Michael Richardson wrote: > Simo Sorce wrote: > >> For this reason, I think that applications should not set or depend > >> upon the AD bit, even if the resolver is ::1. They either understand > >> DNS(SEC), or they use an API call way more sophisticated than > >> getaddrinfo() to do their connections. Java had the right idea, but > >> the implementation and error reporting was very poor. > > > Nothing in this proposal prevents you from doing that for applications > > you care about. OTOH forcing applications to a completely new API by > > refusing this proposal on your grounds will guarantee less applications > > will use DNSSEC. And DNSEC support will rapidly fragment making > > system-wide management a lot more difficult. I think that prospect is a > > much worse evil. > > If I understand what you are saying, you are worried that different > applications will make up different DNSSEC APIs, and each application will > have different controls. Yes this is the worry, getting to an unmanageable situation that will discourage people from using DNSSEC. > I am not opposed to centralized DNSSEC resolution (whether on the same host, > or via a trusted channel). It's that I am dissastified with "SERVFAIL" > as the only indication of a problem... Understandable, but I have the impression this is a separate problem. Simo. -- Simo Sorce * Red Hat, Inc * New York From nobody Sat Mar 1 11:08:02 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E7E81A0A3E for ; Sat, 1 Mar 2014 11:07:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJtqftrB1Tmv for ; Sat, 1 Mar 2014 11:07:56 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3DB1A0A3D for ; Sat, 1 Mar 2014 11:07:56 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 602CB2AB24B; Sat, 1 Mar 2014 19:07:52 +0000 (UTC) Date: Sat, 1 Mar 2014 19:07:52 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140301190752.GL21390@mournblade.imrryr.org> References: <20140215164446.GN278@mournblade.imrryr.org> <20140217133057.2BDF41AC10@ld9781.wdf.sap.corp> <20140217181533.GG278@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140217181533.GG278@mournblade.imrryr.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/ziPlCpz2ZqrNFOyDw5pmy_RSgAA Subject: [dane] DANE-TA(3) and DANE-TA(2) certificate content semantics X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2014 19:07:59 -0000 On Mon, Feb 17, 2014 at 06:15:33PM +0000, Viktor Dukhovni wrote: So one of the important issues to be discussed in London (and of course on the list) is the question of DANE TLSA records pre-empting some or all of the content of the associated certificate: > So I can live with a weaker requirement, if that settles the issue. > With DANE-EE(3): > > - No PKIX signature verification. Covered by TLSA association > data field, and in any case we don't have a trusted issuer > whose signature can be checked. [ Obvious. ] > > - No name checks based on certificate content. Covered > by TLSA (service, protocol, base domain) triple. [ Already agreed. ] > > - No expiration checks based on certificate content. Covered > by TLSA RRset's RRSIG expiration time. [ Still under discussion. ] > > - No purpose checks based on extended key usage. Covered by > TLSA RRtype. [ Still under discussion. ] > > [ ... ] > > Of the two "Still under discussion" fields, the expiration is by > far the most important for the operational success of DANE. By > far the most common problem is expired certificates, and with > DANE-EE(3), we have an opportunity to eliminate this problem. > There is no more expiration, rather TLSA records are withdrawn from > DNS by the server operator once the certificate is no longer > appropriate (for whatever reason). So please think about this issue before the Thursday dane session, and/or indicate your views on the list. Related to this is the following observation: With "IN TLSA DANE-TA(2) SPKI(1) ..." records, the end entity server is free to modify any field in the TA certificate other than its subject name, its public key and fields constrained by the authority key identifier of the immediate child of the TA in the chain. Since the end entity is then free to modify the TA certificate (but anything below it), should/may the content of such a TA certificate be mostly ignored? In other words, should/may "IN TLSA 2 1 ?" be treated differently from "IN TLSA 2 0 ?" with respect to the handling of the TA certificate content, beyond the obvious difference of using either the public key only, or the whole certificate to match the TLSA record. For example, Postfix effectively ignores everything in the TA certificate other than the public key with "IN TLSA 2 1 1" (after all the TLSA record told us to trust the public key), but not with "IN TLSA 2 0 1". Since it looks like workable DANE support will be in OpenSSL 1.0.2 (in beta, to be released "soon"), now is a good time to settle these questions. There are two slides in the SMTP + OPS talk for London on DANE-EE(3) and DANE-TA(2) semantics. -- Viktor. From nobody Sat Mar 1 11:25:14 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB7571A0A5E for ; Sat, 1 Mar 2014 11:25:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9qTsS7RD1ax for ; Sat, 1 Mar 2014 11:25:06 -0800 (PST) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id AFCF91A013A for ; Sat, 1 Mar 2014 11:25:02 -0800 (PST) Received: by mail-pd0-f182.google.com with SMTP id g10so2114523pdj.13 for ; Sat, 01 Mar 2014 11:25:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=dp9VPv9Qc6zeH33jdHveGX8wA1dZEEnBf+CHHN66LSs=; b=w3EHDad+M/wUGKXd9bEsYVZF8P0vhtcdPQOR3ku4GUxQ+3V93EqMSBTlFTkcm+5QZj lch2sEqaNJEt092fnEV8UpQLizXkdtg/8wnk5+ES8qnu397zYMwE8Ti6Uz0UcDRj380r rY4DdckiO3cngZ5zbrjJTSRrSgls0OLmPC6kI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=dp9VPv9Qc6zeH33jdHveGX8wA1dZEEnBf+CHHN66LSs=; b=GCstNAfI/ytgMjSWX84Si/OqWcQIhRaFgiQwATCZ4IJ+cu79LqClM2l4zIandklrVj 9vcBFSO2cdmstjm7pw8qaibVuZWDEsQFlhO1rwZM/bHobfk7wWUNBWN+Pv74dK99ipVY 1TXyXCc/UuoeE1UrlOv8/vR644egEn/mVpDbd089Uqb9tRjmjJ+cDIN1wl4w/XV7kdJF QWbcCyBGsC937ZaH6zgkNJ4RvjGY3Nw9Tx6JkfzUVtj4i2sRYbVoZs6nmPAe90R1Ru5Z MHC84rCtqYTGZlcDQgFVFrG1ocNtqgp0qMI2TN9douwxCPYSNgE8k4B7CKIT7EJDoT4V V65Q== X-Gm-Message-State: ALoCoQm+6nmAB5pg6vDNJVPNpYPt+meILCTEkP5dfEmRYsxX5/iIeWSShlhC2BB4TW5J8HqaJQz2 X-Received: by 10.68.237.133 with SMTP id vc5mr10869546pbc.92.1393701899055; Sat, 01 Mar 2014 11:24:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.198.68 with HTTP; Sat, 1 Mar 2014 11:24:38 -0800 (PST) In-Reply-To: References: From: Tom Ritter Date: Sat, 1 Mar 2014 14:24:38 -0500 Message-ID: To: Warren Kumari Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/ha_ayOIuv-sx8pAA96NxY-_8CQo Cc: "" Subject: Re: [dane] Adopting draft-wouters-dane-openpgp and draft-wouters-dane-openpgpkey-usage X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2014 19:25:07 -0000 I won't be in London where this will be discussed more, but I support adopting these. I can at least provide editorial feedback. =) -tom On 18 February 2014 10:11, Warren Kumari wrote: > Dear DANE WG, > > This starts a Call for Adoption for draft-wouters-dane-openpgp and > draft-wouters-dane-openpgpkey-usage. > > These drafts are available here: > https://datatracker.ietf.org/doc/draft-wouters-dane-openpgp/ > and > https://datatracker.ietf.org/doc/draft-wouters-dane-openpgpkey-usage/ > > > Please review these two draft to see if you think if they are suitable > for adoption by the DANE WG. > > There has been some discussion on these (well, the doc that was split > to make these), and Paul Wouters will be discussing them in London. > > Please read the drafts and provide feedback onlist, supporting (or > objecting to) adoption. Please also indicate if you are willing to > contribute text, review, etc. > > We will discuss any large open questions in London, and so the call > for adoption will end shortly after the meeting. > Please make sure that you have actually read the drafts - this should > be questions / discussions, not "Please open your hymn books to the > Introduction and we'll all read along together". > > Please also note that Paul Hoffman will be leading a discussion at the > beginning of the meeting on the key acquisition vs service discovery > vs key usage assurance topic. > > This call for adoption ends Wed 12-Mar-2014. > > Thanks, > Warren Kumari > (as DANE WG co-chair) > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From nobody Sat Mar 1 13:05:06 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C039E1A0308 for ; Sat, 1 Mar 2014 13:05:03 -0800 (PST) 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=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T_jsdGju_0_L for ; Sat, 1 Mar 2014 13:05:00 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 969AC1A02CD for ; Sat, 1 Mar 2014 13:05:00 -0800 (PST) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B7FB340427; Sat, 1 Mar 2014 14:04:57 -0700 (MST) Message-ID: <53124B7C.4010504@stpeter.im> Date: Sat, 01 Mar 2014 14:05:00 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Warren Kumari , "" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/GhyjxbircaXgvew6xnZUr3_g4u4 Subject: Re: [dane] Adopting draft-wouters-dane-openpgp and draft-wouters-dane-openpgpkey-usage X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2014 21:05:05 -0000 On 2/18/14, 8:11 AM, Warren Kumari wrote: > Dear DANE WG, > > This starts a Call for Adoption for draft-wouters-dane-openpgp and > draft-wouters-dane-openpgpkey-usage. > > These drafts are available here: > https://datatracker.ietf.org/doc/draft-wouters-dane-openpgp/ > and > https://datatracker.ietf.org/doc/draft-wouters-dane-openpgpkey-usage/ > > > Please review these two draft to see if you think if they are suitable > for adoption by the DANE WG. I think they are suitable as starting points for work within the DANE working group. Peter From nobody Sun Mar 2 06:04:23 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEF941A06D1 for ; Sun, 2 Mar 2014 06:04:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.409 X-Spam-Level: ** X-Spam-Status: No, score=2.409 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CHxnNMv9GjjD for ; Sun, 2 Mar 2014 06:04:20 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id BF80D1A023D for ; Sun, 2 Mar 2014 06:04:20 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id D27292002F for ; Sun, 2 Mar 2014 10:22:40 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 21738647C9; Sun, 2 Mar 2014 09:04:17 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 15AE963AB2 for ; Sun, 2 Mar 2014 09:04:17 -0500 (EST) From: Michael Richardson To: dane WG list In-Reply-To: <1393697107.22047.24.camel@willson.li.ssimo.org> References: <912.1393614300@sandelman.ca> <1393617370.22047.22.camel@willson.li.ssimo.org> <17001.1393638770@sandelman.ca> <1393697107.22047.24.camel@willson.li.ssimo.org> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/dane/3j9Tx5McEEcXzPdEK9zjuax8NxQ Subject: Re: [dane] An AD bit discussion X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 14:04:22 -0000 Simo Sorce wrote: > On Fri, 2014-02-28 at 20:52 -0500, Michael Richardson wrote: >> Simo Sorce wrote: >> >> For this reason, I think that applications should not set or depend >> >> upon the AD bit, even if the resolver is ::1. They either understand >> >> DNS(SEC), or they use an API call way more sophisticated than >> >> getaddrinfo() to do their connections. Java had the right idea, but >> >> the implementation and error reporting was very poor. >> >> > Nothing in this proposal prevents you from doing that for applications >> > you care about. OTOH forcing applications to a completely new API by >> > refusing this proposal on your grounds will guarantee less applications >> > will use DNSSEC. And DNSEC support will rapidly fragment making >> > system-wide management a lot more difficult. I think that prospect is a >> > much worse evil. >> >> If I understand what you are saying, you are worried that different >> applications will make up different DNSSEC APIs, and each application will >> have different controls. > Yes this is the worry, getting to an unmanageable situation that will > discourage people from using DNSSEC. >> I am not opposed to centralized DNSSEC resolution (whether on the same >> host, >> or via a trusted channel). It's that I am dissastified with "SERVFAIL" >> as the only indication of a problem... > Understandable, but I have the impression this is a separate problem. The only *API* that we presently have is built on top of resolv.conf which makes use to *DNS*, and that API's only DNSSEC control is *AD*. So, it's not as yet, a separate problem. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From nobody Sun Mar 2 06:05:40 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0999C1A0721 for ; Sun, 2 Mar 2014 06:05:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.019 X-Spam-Level: * X-Spam-Status: No, score=1.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665, T_TVD_MIME_NO_HEADERS=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QMUh5TfoiXHC for ; Sun, 2 Mar 2014 06:05:39 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 189F91A06D1 for ; Sun, 2 Mar 2014 06:05:39 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 40EBB2002F for ; Sun, 2 Mar 2014 10:24:00 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 85BC1647C9; Sun, 2 Mar 2014 09:05:36 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 7629B63AB2 for ; Sun, 2 Mar 2014 09:05:36 -0500 (EST) From: Michael Richardson To: dane WG list In-Reply-To: <1393697107.22047.24.camel@willson.li.ssimo.org> References: <912.1393614300@sandelman.ca> <1393617370.22047.22.camel@willson.li.ssimo.org> <17001.1393638770@sandelman.ca> <1393697107.22047.24.camel@willson.li.ssimo.org> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/dane/6aVXZMubTBe0mqxbTj_uzmQNNRM Subject: Re: [dane] An AD bit discussion X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 14:05:40 -0000 --=-=-= Simo Sorce wrote: > On Fri, 2014-02-28 at 20:52 -0500, Michael Richardson wrote: >> Simo Sorce wrote: >> >> For this reason, I think that applications should not set or depend >> >> upon the AD bit, even if the resolver is ::1. They either understand >> >> DNS(SEC), or they use an API call way more sophisticated than >> >> getaddrinfo() to do their connections. Java had the right idea, but >> >> the implementation and error reporting was very poor. >> >> > Nothing in this proposal prevents you from doing that for applications >> > you care about. OTOH forcing applications to a completely new API by >> > refusing this proposal on your grounds will guarantee less applications >> > will use DNSSEC. And DNSEC support will rapidly fragment making >> > system-wide management a lot more difficult. I think that prospect is a >> > much worse evil. >> >> If I understand what you are saying, you are worried that different >> applications will make up different DNSSEC APIs, and each application will >> have different controls. > Yes this is the worry, getting to an unmanageable situation that will > discourage people from using DNSSEC. >> I am not opposed to centralized DNSSEC resolution (whether on the same >> host, >> or via a trusted channel). It's that I am dissastified with "SERVFAIL" >> as the only indication of a problem... > Understandable, but I have the impression this is a separate problem. The only *API* that we presently have is built on top of resolv.conf which makes use to *DNS*, and that API's only DNSSEC control is *AD*. So, it's not as yet, a separate problem. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting for hire =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUxM6rYqHRg3pndX9AQIdKQQAi2e1ZpZU5PQThoZuVRLDdZiB/WfZ1dbv fXzGulwgAs+XOWp3mDn+pw1W7gGkYcPyuE4o+05Eee4ZzU7wGMG7duF+NveOLbJy hvHgVx6n019ASYfwiLgnDNpLeMjSfk7xXqt35cb6D8beJjSXHa1Z9woxboCij86M NMHK72lCJKo= =lQUK -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Mar 2 11:35:08 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B22311A0A17 for ; Sun, 2 Mar 2014 11:35:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQY5CPn9G2iT for ; Sun, 2 Mar 2014 11:35:03 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id C9CC01A0A1B for ; Sun, 2 Mar 2014 11:35:02 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 104F72AAD0C; Sun, 2 Mar 2014 19:34:58 +0000 (UTC) Date: Sun, 2 Mar 2014 19:34:58 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140302193458.GP21390@mournblade.imrryr.org> References: <20140227054617.GP21390@mournblade.imrryr.org> <530F3A64.2000001@redhat.com> <20140227164014.GT21390@mournblade.imrryr.org> <20140227164201.GU21390@mournblade.imrryr.org> <530F9A3D.3070008@redhat.com> <20140227212614.GY21390@mournblade.imrryr.org> <20140227230922.GD21390@mournblade.imrryr.org> <53107D34.1030409@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53107D34.1030409@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/weDfb4xBxxs5icb4n3rdTCezsVQ Subject: Re: [dane] Proposal: AD bit handling in stub-resolvers (ACK/amend/NACK) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 19:35:06 -0000 On Fri, Feb 28, 2014 at 01:12:36PM +0100, Petr Spacek wrote: [ Not very comments by others addressing this I'm afraid. :-( ] > 1) Add a new boolean to /etc/resolv.conf: > options resolvers-trusted > - If present, this option states that "admin ensured that recursor > is trustworthy and the communication link between recursor and > stub-resolver is secure". > - If present, the AD bit will be passed from recursors to applications as-is. > - If not present, the AD bit sent to a applications will be always 0. > - E.g. the option will be present on a system with locally running Unbound. > - E.g. the option *will not* be present on thin client, compute node > in data centre, a random laptop installed today with default > configuration etc. > > Objections: > - There is a chance that dhcp client copies "options" from old > resolv.conf to new one. In that case simplest variant "options > resolvers-trusted" is insecure if one configured e.g. local trusted > recursor and DHCP client was started after that. If this concern is well founded, (i.e. there is evidence of at least one DHCP client implementation that does this), then indeed the boolean looks questionable, a white-list in a separate file is more robust. If so, and you want to protect naive applications from possibly insecure AD bits on systems that don't employ a local validating resolver, then the AD bit should be suppressed whenever a non-empty subset of the designated resolvers is not white-listed. It would be a mistake to suppress the AD bit selectively for just a subset of the resolvers based on where the answer came from. > 2) Add a function call for run-time check (for library users): > boolean dns_resolvers_trusted(resolver); Where "resolver" means the complete resolver context, i.e. all nameservers trusted, ... There would ideally (in each updated legacy implementation) be a new macro #defined that promises the existence of this function and the possibility of AD bit suppression. This could be a new option macro that enables applications to request bare AD bits without RRSIG records if both features are introduced together in implementations of the library on multiple platforms (i.e. ultimately by the upstream maintainer, rather than a downstream release-specific patch). -- Viktor. From nobody Mon Mar 3 01:10:42 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB8D1A064A for ; Mon, 3 Mar 2014 01:10:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHQGNK6uPMyD for ; Mon, 3 Mar 2014 01:10:38 -0800 (PST) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id D8B791A0349 for ; Mon, 3 Mar 2014 01:10:37 -0800 (PST) Received: by mail-ig0-f176.google.com with SMTP id uy17so7181869igb.3 for ; Mon, 03 Mar 2014 01:10:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=V5A1XDn2oangoYx9zJkGhzyCOuJHieJWZiJ8p7bRR3k=; b=scxBwr5Qhv6+a4Fxr91pf1z+mlL6TG2CPtuH0ghuSn2MjBKp0fVq/rOlTEP93NK34Z pNZ2bkcYUc065O8wTModg1C3drZzKyHkBMGzdiPdBrvym56eRYYRta5A/53HHKKVPJx2 1O4jfpOOABH01+MIuclyNnnKRJjny6BrlOQJrNLefrP1NeY/3HDmEu3T8X5i7+htLt3O GpEqwOekzkeqapM4ypWJy9BMTDBsbs/MV6jKzV6dKnWfDEOMofY0D1SgmNWcEelzESWx 6g7RRwGcrAgyqR+lujThTM3A0nEamBhTCzKLBy1myRws5Oli+jTLmL49EuEqIHeWgEi5 y7RA== MIME-Version: 1.0 X-Received: by 10.43.181.69 with SMTP id ph5mr18104icc.78.1393837834910; Mon, 03 Mar 2014 01:10:34 -0800 (PST) Received: by 10.50.138.166 with HTTP; Mon, 3 Mar 2014 01:10:34 -0800 (PST) In-Reply-To: References: Date: Mon, 3 Mar 2014 09:10:34 +0000 Message-ID: From: Scott Rose To: "" Content-Type: multipart/alternative; boundary=001a11c3b40c06436404f3b029b7 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/7IyWqhUiAeOyYf-MjUS2mejEDCY Subject: Re: [dane] Adopting draft-wouters-dane-openpgp and draft-wouters-dane-openpgpkey-usage X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: scott.rose@nist.gov List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 09:10:41 -0000 --001a11c3b40c06436404f3b029b7 Content-Type: text/plain; charset=ISO-8859-1 I support both of these drafts becoming WG drafts. Scott On Tue, Feb 18, 2014 at 3:11 PM, Warren Kumari wrote: > Dear DANE WG, > > This starts a Call for Adoption for draft-wouters-dane-openpgp and > draft-wouters-dane-openpgpkey-usage. > > These drafts are available here: > https://datatracker.ietf.org/doc/draft-wouters-dane-openpgp/ > and > https://datatracker.ietf.org/doc/draft-wouters-dane-openpgpkey-usage/ > > > Please review these two draft to see if you think if they are suitable > for adoption by the DANE WG. > > There has been some discussion on these (well, the doc that was split > to make these), and Paul Wouters will be discussing them in London. > > Please read the drafts and provide feedback onlist, supporting (or > objecting to) adoption. Please also indicate if you are willing to > contribute text, review, etc. > > We will discuss any large open questions in London, and so the call > for adoption will end shortly after the meeting. > Please make sure that you have actually read the drafts - this should > be questions / discussions, not "Please open your hymn books to the > Introduction and we'll all read along together". > > Please also note that Paul Hoffman will be leading a discussion at the > beginning of the meeting on the key acquisition vs service discovery > vs key usage assurance topic. > > This call for adoption ends Wed 12-Mar-2014. > > Thanks, > Warren Kumari > (as DANE WG co-chair) > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > --001a11c3b40c06436404f3b029b7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I support both of these drafts becoming WG drafts.=A0
=
Scott


On Tue, Feb 18, 2014 at 3:11 PM, Warren Kumari <warren@= kumari.net> wrote:
Dear DANE WG,

This starts a Call for Adoption for draft-wouters-dane-openpgp and
draft-wouters-dane-openpgpkey-usage.

These drafts are available here:
https://datatracker.ietf.org/doc/draft-wouters-dane-openpgp= /
and
https://datatracker.ietf.org/doc/draft-wouters-dan= e-openpgpkey-usage/


Please review these two draft to see if you think if they are suitable
for adoption by the DANE WG.

There has been some discussion on these (well, the doc that was split
to make these), and Paul Wouters will be discussing them in London.

Please read the drafts and provide feedback onlist, supporting (or
objecting to) adoption. Please also indicate if you are willing to
contribute text, review, etc.

We will discuss any large open questions in London, and so the call
for adoption will end shortly after the meeting.
Please make sure that you have actually read the drafts - this should
be questions / discussions, not "Please open your hymn books to the Introduction and we'll all read along together".

Please also note that Paul Hoffman will be leading a discussion at the
beginning of the meeting on the key acquisition vs service discovery
vs key usage assurance topic.

This call for adoption ends Wed 12-Mar-2014.

Thanks,
Warren Kumari
(as DANE WG co-chair)

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

--001a11c3b40c06436404f3b029b7-- From nobody Mon Mar 3 12:11:38 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5341D1A03A4 for ; Mon, 3 Mar 2014 12:11:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZeQVJE6z0hRm for ; Mon, 3 Mar 2014 12:11:34 -0800 (PST) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id 776DA1A031D for ; Mon, 3 Mar 2014 12:11:32 -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=HYV6cqTGZ1rDHMJ7dOiSQn3n+Gy6fBuVuT1kX8Ot5OM=; b=ASgNnOxRBYn7rSIcVs9vrPQvNZznazhUvU8ih3jHqiYCmuPrZGFmklgpCQZYJvxu88z+d1w/0uBfj 8CZDNUalhFZg8tdBvk+bSLgCsUi9ymljBlDIgXHSWWdOKpE01tXtrVye+8/VOFWg+24nGDi99Pd68t 64pEYTAPq1uHBvdU= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Mon, 3 Mar 2014 21:11:29 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Jakob Schlyter In-Reply-To: Date: Mon, 3 Mar 2014 21:11:26 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: To: Warren Kumari X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/mV3LhbSMemRuz4Solv08F0plq78 Cc: "" Subject: Re: [dane] Adopting draft-wouters-dane-openpgp and draft-wouters-dane-openpgpkey-usage X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 20:11:36 -0000 On 18 feb 2014, at 16:11, Warren Kumari wrote: > This starts a Call for Adoption for draft-wouters-dane-openpgp and > draft-wouters-dane-openpgpkey-usage. > > These drafts are available here: > https://datatracker.ietf.org/doc/draft-wouters-dane-openpgp/ > and > https://datatracker.ietf.org/doc/draft-wouters-dane-openpgpkey-usage/ > > > Please review these two draft to see if you think if they are suitable > for adoption by the DANE WG. Yes, please adopt. jakob From nobody Tue Mar 4 06:41:02 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD4E1A0152 for ; Tue, 4 Mar 2014 06:41:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.433 X-Spam-Level: * X-Spam-Status: No, score=1.433 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CttCd4gWxpAy for ; Tue, 4 Mar 2014 06:40:59 -0800 (PST) Received: from gateway08.websitewelcome.com (gateway08.websitewelcome.com [69.56.224.29]) by ietfa.amsl.com (Postfix) with ESMTP id ADD821A01AD for ; Tue, 4 Mar 2014 06:40:58 -0800 (PST) Received: by gateway08.websitewelcome.com (Postfix, from userid 5007) id 5F857BB6E2AB6; Tue, 4 Mar 2014 08:40:55 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway08.websitewelcome.com (Postfix) with ESMTP id 4908EBB6E2A8C for ; Tue, 4 Mar 2014 08:40:55 -0600 (CST) Received: from [31.133.172.94] (port=59302 helo=dhcp-ac5e.meeting.ietf.org) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1WKqWc-0001HX-Fp; Tue, 04 Mar 2014 08:40:54 -0600 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Sean Turner In-Reply-To: <7B475651-39DD-42E2-B17E-10076CEF368E@nic.cz> Date: Tue, 4 Mar 2014 14:40:50 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <48D7FD49-CA1E-4209-A258-80B59C2D61A7@ieca.com> References: <7B475651-39DD-42E2-B17E-10076CEF368E@nic.cz> To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= , Olafur Gudmundsson X-Mailer: Apple Mail (2.1874) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 31.133.172.94 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (dhcp-ac5e.meeting.ietf.org) [31.133.172.94]:59302 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/dane/eG1ba6s-pkFfprz_j9UUjSFXS_I Cc: "dane@ietf.org list" Subject: Re: [dane] Stepping down as the DANE co-chair... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 14:41:00 -0000 Ond=C5=99ej, Thanks for all of your efforts. I=E2=80=99ve always thought DANE was = going to be winner. =C3=93lafur, Thanks for stepping up to the plate! spt On Feb 24, 2014, at 10:25, Ond=C5=99ej Sur=C3=BD = wrote: > Dear WG members, >=20 > Due to various personal (a baby girl[1]) and work reasons I have = decided to step down as a co-chair of DANE WG. However I will stay in = the WG monitoring it's progress and contributing with draft reviews as = the time will allow. >=20 > =C3=93lafur Gu=C3=B0mundsson was so kind to accept to position of = co-chair this DANE beast with Warren Kumari. >=20 > Thanks to you all for your WG work, > Ond=C5=99ej >=20 > 1. Warren, has asked me to add a picture as a proof, so here it is: = https://dl.dropboxusercontent.com/u/3875106/Ester/IMGP1083.jpg > (The box is not a box, but crypto envelope :-D.) > -- > 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 > ------------------------------------------- >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From nobody Wed Mar 5 01:38:42 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C75F1A00F2 for ; Wed, 5 Mar 2014 01:38:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.447 X-Spam-Level: X-Spam-Status: No, score=-1.447 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ke3klCDH8Kd8 for ; Wed, 5 Mar 2014 01:38:39 -0800 (PST) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by ietfa.amsl.com (Postfix) with ESMTP id CCE271A000D for ; Wed, 5 Mar 2014 01:38:38 -0800 (PST) Received: from localhost (dhcp-a173.meeting.ietf.org [31.133.161.115]) by mail.hardakers.net (Postfix) with ESMTPSA id 59F8621ACD; Wed, 5 Mar 2014 01:38:31 -0800 (PST) From: Wes Hardaker To: =?utf-8?B?T25kxZllaiBTdXLDvQ==?= References: <7B475651-39DD-42E2-B17E-10076CEF368E@nic.cz> Date: Wed, 05 Mar 2014 01:38:29 -0800 In-Reply-To: <7B475651-39DD-42E2-B17E-10076CEF368E@nic.cz> (=?utf-8?Q?=22O?= =?utf-8?Q?nd=C5=99ej_Sur=C3=BD=22's?= message of "Mon, 24 Feb 2014 11:25:57 +0100") Message-ID: <0l8uspastm.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dane/9uk7ERU6geeEQn2rgaKTddOFxd0 Cc: "dane@ietf.org list" Subject: Re: [dane] Stepping down as the DANE co-chair... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 09:38:40 -0000 Ond=C5=99ej Sur=C3=BD writes: > Due to various personal (a baby girl[1]) and work reasons I have > decided to step down as a co-chair of DANE WG. Thanks very much for your past work, Ond=C5=99ej! We greatly appreciate yo= ur past time and effort. And thanks as well to =C3=93lafur for his new role1 --=20 Wes Hardaker Parsons From nobody Wed Mar 5 15:12:48 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22DCF1A005C for ; Wed, 5 Mar 2014 15:12:46 -0800 (PST) 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=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id reKJ1AxibNIc for ; Wed, 5 Mar 2014 15:12:43 -0800 (PST) Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) by ietfa.amsl.com (Postfix) with ESMTP id 693761A0305 for ; Wed, 5 Mar 2014 15:12:43 -0800 (PST) Received: by mail-wg0-f47.google.com with SMTP id x12so2126824wgg.18 for ; Wed, 05 Mar 2014 15:12:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=6SvJg9UMp/12tnmWNWrV7BojoAbQVteGToFixCw4Hrg=; b=CZPyCAX2upUx8oOMqmFJHukej/IG+Fzs2Z07Tj8p/Vl3mdon7njYjdB/hm48CGNYLO 1U5Bgy8Gdz1xLookvuzyfm0Dp2n2tmtLVaRqx+JfL7uARC1/6tUK0XkkdDEkvpw6e9ev 4oD7VXwhhNCVN4kaiGd9zw7N3NLm6Q+H9YHdiomgQmcdF42Hna/PLIxGarUeqYplFo9G Wxymej6cV69P9yhlkNyX+91zzbyMnzJmgFNAnkTIMWLxErpar3hVgrqcw5k+KAiyF1Ds g0LgTZ+vG9HUG9hOmsmabYCXRD68FaTQhQ3mXGA9fZLOgh9nrinnGVZZ6g9+8/yR+oUA DUoQ== X-Gm-Message-State: ALoCoQmvE3PSsqk94Gse6oJwIgo/qZUG8Jsbn3Cr2CTkaI8stlggIEp5nyn72SVxSSuNkBPSG6vH MIME-Version: 1.0 X-Received: by 10.194.86.130 with SMTP id p2mr4961256wjz.88.1394061159250; Wed, 05 Mar 2014 15:12:39 -0800 (PST) Received: by 10.194.54.167 with HTTP; Wed, 5 Mar 2014 15:12:39 -0800 (PST) X-Originating-IP: [130.129.154.181] In-Reply-To: References: Date: Wed, 5 Mar 2014 23:12:39 +0000 Message-ID: From: Warren Kumari To: Jakob Schlyter Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/vD8RhWbCvyi_0NzcGw9KOrwRTjM Cc: "" Subject: Re: [dane] Adopting draft-wouters-dane-openpgp and draft-wouters-dane-openpgpkey-usage X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 23:12:46 -0000 On Mon, Mar 3, 2014 at 8:11 PM, Jakob Schlyter wrote: > On 18 feb 2014, at 16:11, Warren Kumari wrote: > >> This starts a Call for Adoption for draft-wouters-dane-openpgp and >> draft-wouters-dane-openpgpkey-usage. >> >> These drafts are available here: >> https://datatracker.ietf.org/doc/draft-wouters-dane-openpgp/ >> and >> https://datatracker.ietf.org/doc/draft-wouters-dane-openpgpkey-usage/ >> >> >> Please review these two draft to see if you think if they are suitable >> for adoption by the DANE WG. > > Yes, please adopt. Great, thanks for all the feedback we have received so far. These will be (briefly) discussed tomorrow at the f2f meeting, but feel free to carry on providing feedback as well (those that haven't) W > > jakob > From nobody Thu Mar 6 01:23:37 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FADB1A0178; Thu, 6 Mar 2014 01:23:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iw7TOtBtsx-y; Thu, 6 Mar 2014 01:23:28 -0800 (PST) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 871231A0189; Thu, 6 Mar 2014 01:23:27 -0800 (PST) Received: by mail-la0-f48.google.com with SMTP id gf5so1549770lab.35 for ; Thu, 06 Mar 2014 01:23:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=jFbYMBmDPSk/cZ2XQuBNbkpCX4E57uDJDRQ0ZYPC88Q=; b=LjYHQAuhDtE88s5DeVyawSu4O25lb5me/WBHvSSw5FTT4YM7M6/9ATqWVs7tty5DnO EPcmFKzGcolFSH2OXNdHT/SnklAr+MQZYRt5Nlg6VzmCCcM3XnlxKZjEGSQIq7+upObo 0jI8LXkNC2HhJ/9+XgcZ+NGno7BMRT2O7rygNe3ZDPlP3zYkMwV9o5NB17aOOEXfYXzZ W6FuyNHdhqgVQk3f1iPd5yVv8ryVsXFDNyAVXjh/Y0l5DexTV1dxB27Fg8cc3o1vKKzZ 4nYeOOob9zJ8zJtihCky4S58uqItJWb8tA6eyMKYLio1N59WgP/sIM7hG5W6wxUJkDtb nWuA== MIME-Version: 1.0 X-Received: by 10.112.161.133 with SMTP id xs5mr723319lbb.51.1394097803060; Thu, 06 Mar 2014 01:23:23 -0800 (PST) Received: by 10.112.37.168 with HTTP; Thu, 6 Mar 2014 01:23:23 -0800 (PST) Date: Thu, 6 Mar 2014 09:23:23 +0000 Message-ID: From: Phillip Hallam-Baker To: "saag@ietf.org" , "dane@ietf.org" Content-Type: multipart/alternative; boundary=001a11c3c042556c1004f3ecb03d Archived-At: http://mailarchive.ietf.org/arch/msg/dane/wTsD-e1S-2-_ufP6NfNXyfj_rzk Subject: [dane] Need better opportunistic terminology X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 09:23:31 -0000 --001a11c3c042556c1004f3ecb03d Content-Type: text/plain; charset=ISO-8859-1 The term opportunistic has become the new synonym for 'Good' but it is being used for many different things. A) Unauthenticated key exchange B) Upgrade from plaintext to encrypted without controlling security policy requiring use of encryption. C) Silent-fail on bad credentials D) Silent-success on bad credentials There are arguments for all of these but I am just watching a presentation on 'opportunistic encryption' in DANE and I think the term is selling DANE short. DNS is an authoritative path for statements about DNS labels. Ergo authenticated DNS RRs are authenticated statements about them. DANE provides authenticated statements about security policy and keys. Ergo DANE cannot support opportunistic encryption because it is policy directed encryption (i.e. better). -- Website: http://hallambaker.com/ --001a11c3c042556c1004f3ecb03d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The term opportunistic has become the new synonym for '= ;Good' but it is being used for many different things.

A) Unauthenticated key exchange

B) Upgrade from= plaintext to encrypted without controlling security policy requiring use o= f encryption.

C) Silent-fail on bad credentials

<= div>D) Silent-success on bad credentials

There are= arguments for all of these but I am just watching a presentation on 'o= pportunistic encryption' in DANE and I think the term is selling DANE s= hort.

DNS is an authoritative path for statements about DNS l= abels. Ergo authenticated DNS RRs are authenticated statements about them. = DANE provides authenticated statements about security policy and keys. Ergo= DANE cannot support opportunistic encryption because it is policy directed= encryption (i.e. better).
--001a11c3c042556c1004f3ecb03d-- From nobody Thu Mar 6 03:45:40 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 531F51A023E for ; Thu, 6 Mar 2014 03:45:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgJovVUyBbsS for ; Thu, 6 Mar 2014 03:45:37 -0800 (PST) Received: from mail-pb0-x233.google.com (mail-pb0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 923D01A019C for ; Thu, 6 Mar 2014 03:45:37 -0800 (PST) Received: by mail-pb0-f51.google.com with SMTP id uo5so2494660pbc.24 for ; Thu, 06 Mar 2014 03:45:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Pf+SwIpIvCEmMBUR+r0FQt7JXA8/1vZeGNJXKl4uSQk=; b=Yi4byb77FWoGMcBfMbHBay4aHEq1D46bGNkCt8BibjBiHMSdfSln7cpueX7Lhi4QPm rLRfVeZFkNneRc6Tvs3NHRMIV5Kz4wMLi4QDkMKSVUlFz/mZBQzWaIgmuqRCGybDOQOQ 4r6qfVR6JC7H/KzR30vIAg+RF/kJPV6aG9eQdyrOdrN+bXew1T1M+otayxIoKj22W8/4 jX6D8HJQWCirnDBiSlFiESXRC4H/FdGE0x+3Ise5DJbeEwq2ydcFBEru9koHNICls6HF xKCj9T8e0JrTi7fSpx3QIv4FvRIrNP95PccNs7akffGneUnowhUa+EPsaWYmvCrHBK3B u0Ng== MIME-Version: 1.0 X-Received: by 10.66.136.131 with SMTP id qa3mr13519800pab.77.1394106333817; Thu, 06 Mar 2014 03:45:33 -0800 (PST) Received: by 10.66.220.102 with HTTP; Thu, 6 Mar 2014 03:45:33 -0800 (PST) In-Reply-To: References: Date: Thu, 6 Mar 2014 11:45:33 +0000 Message-ID: From: "Murray S. Kucherawy" To: Warren Kumari Content-Type: multipart/alternative; boundary=001a11337690ce70a004f3eeacf5 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/hHyKyCOrhshh35455ddXox1kAA4 Cc: "" Subject: Re: [dane] Adopting draft-wouters-dane-openpgp and draft-wouters-dane-openpgpkey-usage X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 11:45:39 -0000 --001a11337690ce70a004f3eeacf5 Content-Type: text/plain; charset=ISO-8859-1 This may be an ignorant question, but why would DANE handle these? They barely make reference to DANE at all, and certainly not in a normative sense. On Wed, Mar 5, 2014 at 11:12 PM, Warren Kumari wrote: > On Mon, Mar 3, 2014 at 8:11 PM, Jakob Schlyter wrote: > > On 18 feb 2014, at 16:11, Warren Kumari wrote: > > > >> This starts a Call for Adoption for draft-wouters-dane-openpgp and > >> draft-wouters-dane-openpgpkey-usage. > >> > >> These drafts are available here: > >> https://datatracker.ietf.org/doc/draft-wouters-dane-openpgp/ > >> and > >> https://datatracker.ietf.org/doc/draft-wouters-dane-openpgpkey-usage/ > >> > >> > >> Please review these two draft to see if you think if they are suitable > >> for adoption by the DANE WG. > > > > Yes, please adopt. > > Great, thanks for all the feedback we have received so far. These > will be (briefly) discussed tomorrow at the f2f meeting, but feel free > to carry on providing feedback as well (those that haven't) > > W > > > > > > jakob > > > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > --001a11337690ce70a004f3eeacf5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This may be an ignorant question, but why would DANE handl= e these?=A0 They barely make reference to DANE at all, and certainly not in= a normative sense.


On Wed, Mar 5, 2014 at 11:12 PM, Warren Kumari <warren@kumari.net><= /span> wrote:
On Mon, Mar 3, 2014 at 8:11 PM, Jakob Schlyter <jakob@kirei.se> wrote:
> On 18 feb 2014, at 16:11, Warren Kumari <warren@kumari.net> wrote:
>
>> This starts a Call for Adoption for draft-wouters-dane-openpgp and=
>> draft-wouters-dane-openpgpkey-usage.
>>
>> These drafts are available here:
>> https://datatracker.ietf.org/doc/draft-wouters-dan= e-openpgp/
>> and
>> https://datatracker.ietf.org/doc/draft-wo= uters-dane-openpgpkey-usage/
>>
>>
>> Please review these two draft to see if you think if they are suit= able
>> for adoption by the DANE WG.
>
> Yes, please adopt.

Great, =A0thanks for all the feedback we have received so far. These<= br> will be (briefly) discussed tomorrow at the f2f meeting, but feel free
to carry on providing feedback as well (those that haven't)

W


>
> =A0 =A0 =A0 =A0 jakob
>

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

--001a11337690ce70a004f3eeacf5-- From nobody Thu Mar 6 05:40:11 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78D9F1A0335 for ; Thu, 6 Mar 2014 05:40:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cF1RI_R4YptQ for ; Thu, 6 Mar 2014 05:40:07 -0800 (PST) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 117891A032A for ; Thu, 6 Mar 2014 05:40:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1394113201; d=isode.com; s=selector; i=@isode.com; bh=3jHfnL5sE0TRSDWgBrrp6osRmFIIV19Oq7mWaZf36Yo=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=aAwx76hf1EQvXb28atTuY2pvvIf2TtdhvkLM5lR8F2Br+C4GBEE6els0XqIulYY9aqXb/l Xky4kfaU3CPheG5OWVekLHdYbmNqIUCK4RfUR1Q/2fwQ4UwRvYsq3gv7ciYUy+zhPtTBqg JJMOuOQ62kN2Nsy/woDWm25oMBXl2F0=; Received: from [31.133.164.146] (dhcp-a492.meeting.ietf.org [31.133.164.146]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 6 Mar 2014 13:40:01 +0000 X-SMTP-Protocol-Errors: PIPELINING From: Alexey Melnikov Date: Thu, 6 Mar 2014 13:44:17 +0000 Message-Id: To: "dane@ietf.org" X-Mailer: iPad Mail (11B651) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=Apple-Mail-52AC0691-792B-4C33-BF29-93BA2AA5BC18 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/BXmjP0ftxpY1nAUAfI8L_FRKaUo Subject: [dane] Review of DANE SMTP draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 13:40:09 -0000 --Apple-Mail-52AC0691-792B-4C33-BF29-93BA2AA5BC18 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi, I have a possibly slightly cryptic review notes. Feel free to ask for clarif= ications. In the terminology section: what about no MX record case (A or AAAA only)? In 1.3.1: why mention SMTP URIs? How would introduction of such URIs help wi= th securing SMTP? I suggest you just mention that there is no signalling of "= secure" SMTP. In 2.2: Network address instead of MX hostname - I think this deserves an ex= ample. In 2.2.3 (page 17, 3rd from the last para): and possibly other places: TLS s= erver certificate matching rules should be fully specified. Use RFC 6125 (fo= r example look at draft-melnikov-email-tls-certs-01) or specify the rules di= rectly. Page 22, 3rd para: please add reference for the SNI TLS extension (a Normati= ve reference, because you use normative language when referencing the extens= ion) and various versions of TLS. In 2.3.3: it is not clear whether the client needs to check that for every r= ecord covered by the WORSE hash there is a corresponding record covered by t= he BETTER hash. In Section 3, last para: add "or bounced", as this can be more serious than j= ust being delayed. In 4.2, last para: did you mean "SHOULD"? I've heard Not checking expiration dates in certificate - I don't think this= was mentioned in the document. Best Regards, Alexey --Apple-Mail-52AC0691-792B-4C33-BF29-93BA2AA5BC18 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi,
I have a possibly slight= ly cryptic review notes. Feel free to ask for clarifications.

=
In the termi= nology section: what about no MX record case (A or AAAA only)?
<= div>
In 1.3.1: why mention SMTP URI= s? How would introduction of such URIs help with securing SMTP? I suggest yo= u just mention that there is no signalling of "secure" SMTP.

In 2.2: Net= work address instead of MX hostname - I think this deserves an example.

In 2.2.3 (page 17, 3r= d from the last para): and possibly other places: TLS server certificate mat= ching rules should be fully specified. Use RFC 6125 (for example look at&nbs= p;draft-melnikov-email-tls-certs-01) or specify the rules directly.

= Page 22, 3rd para: please ad= d reference for the SNI TLS extension (a Normative reference, because you us= e normative language when referencing the extension) and various versions of= TLS.

<= /span>
In 2.3.3: i= t is not clear whether the client needs to check that for every record cover= ed by the WORSE hash there is a corresponding record covered by the BETTER h= ash.

In Section 3= , last para: add "or bounced", as this can be more serious than just being d= elayed.
In 4.2, l= ast para: did you mean "SHOULD"?

I've heard Not checking expiration dates in certificate - I d= on't think this was mentioned in the document.

Best Regards,
Alexey


= --Apple-Mail-52AC0691-792B-4C33-BF29-93BA2AA5BC18-- From nobody Thu Mar 6 10:06:23 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9315B1A0083; Thu, 6 Mar 2014 09:05:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.745 X-Spam-Level: X-Spam-Status: No, score=-4.745 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9doIQzhl3oGy; Thu, 6 Mar 2014 09:05:21 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id E1D441A01FB; Thu, 6 Mar 2014 09:05:18 -0800 (PST) Received: from [192.168.1.97] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s26H3pcC028049 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 6 Mar 2014 09:04:01 -0800 (PST) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-198B2FEE-28D9-4138-AC58-E3CF0FC363E1 Message-Id: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> X-Mailer: iPhone Mail (11B651) From: Joe Touch Date: Thu, 6 Mar 2014 09:03:52 -0800 To: Phillip Hallam-Baker X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/dane/CFBUYbaMAmBAickRj17qPXG-HRg X-Mailman-Approved-At: Thu, 06 Mar 2014 10:06:20 -0800 Cc: "saag@ietf.org" , "dane@ietf.org" Subject: Re: [dane] [saag] Need better opportunistic terminology X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 17:05:23 -0000 --Apple-Mail-198B2FEE-28D9-4138-AC58-E3CF0FC363E1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On Mar 6, 2014, at 1:23 AM, Phillip Hallam-Baker wrote:= >=20 > The term opportunistic has become the new synonym for 'Good' but it is bei= ng used for many different things. >=20 > A) Unauthenticated key exchange Fwiw, this is IMO an error since I first introduced BTNS, and I had to clear= it up on Wikipedia multiple times. I see nothing opportunistic about this m= ode as a stand-alone concept.=20 I personally don't this the term applies to the modes listed below either.=20= One mode you didn't include - that I recall as one of tho first uses of the t= erm opportunistic, and remains the only one I associate with the term. - is t= he use of a key before either the key or encryption in general has been nego= tiated and is not the protocol default. (I.e., a little like B but more just= start using it then an 'upgrade'. ) Joe > B) Upgrade from plaintext to encrypted without controlling security policy= requiring use of encryption. >=20 > C) Silent-fail on bad credentials >=20 > D) Silent-success on bad credentials >=20 > There are arguments for all of these but I am just watching a presentation= on 'opportunistic encryption' in DANE and I think the term is selling DANE s= hort. >=20 > DNS is an authoritative path for statements about DNS labels. Ergo authent= icated DNS RRs are authenticated statements about them. DANE provides authen= ticated statements about security policy and keys. Ergo DANE cannot support o= pportunistic encryption because it is policy directed encryption (i.e. bette= r). >=20 >=20 >=20 > --=20 > Website: http://hallambaker.com/ > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --Apple-Mail-198B2FEE-28D9-4138-AC58-E3CF0FC363E1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


On Mar 6, 2014, at 1= :23 AM, Phillip Hallam-Baker <hallam@= gmail.com> wrote:

The term opportunistic has become the new synonym for 'Good' but i= t is being used for many different things.

A) Unauthentic= ated key exchange

Fwiw, th= is is IMO an error since I first introduced BTNS, and I had to clear it up o= n Wikipedia multiple times. I see nothing opportunistic about this mode as a= stand-alone concept. 

I personally don't this= the term applies to the modes listed below either. 

One mode you didn't include - that I recall as one of tho first uses o= f the term opportunistic, and remains the only one I associate with the term= . - is the use of a key before either the key or encryption in general has b= een negotiated and is not the protocol default. (I.e., a little like B but m= ore just start using it then an 'upgrade'. )

Joe

B) Up= grade from plaintext to encrypted without controlling security policy requir= ing use of encryption.

C) Silent-fail on bad credentials

D) Silent-success on bad credentials

There are a= rguments for all of these but I am just watching a presentation on 'opportun= istic encryption' in DANE and I think the term is selling DANE short.

DNS is an authoritative path for statements about DNS la= bels. Ergo authenticated DNS RRs are authenticated statements about them. DA= NE provides authenticated statements about security policy and keys. Ergo DA= NE cannot support opportunistic encryption because it is policy directed enc= ryption (i.e. better).
____________________= ___________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman= /listinfo/saag
= --Apple-Mail-198B2FEE-28D9-4138-AC58-E3CF0FC363E1-- From nobody Thu Mar 6 16:44:43 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28C2A1A014E; Thu, 6 Mar 2014 16:44:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tevUjjtw6wRg; Thu, 6 Mar 2014 16:44:38 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4F71A00CA; Thu, 6 Mar 2014 16:44:38 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 954212AB24D; Fri, 7 Mar 2014 00:44:32 +0000 (UTC) Date: Fri, 7 Mar 2014 00:44:32 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140307004432.GH21390@mournblade.imrryr.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/y1xNPGMRNWocdrbhZuuUgLbcLYU Cc: saag@ietf.org Subject: Re: [dane] Need better opportunistic terminology X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 00:44:41 -0000 On Thu, Mar 06, 2014 at 09:23:23AM +0000, Phillip Hallam-Baker wrote: > The term opportunistic has become the new synonym for 'Good' but it is > being used for many different things. Since I am the primary perpetrator of the thought crime in question, :-) I'd like to explain the term we used, and why, and solicit a better term if the IETF has a better way of expressing the underlying idea. Background: In the Postfix community, we've historically used the term "opportunistic TLS": http://www.postfix.org/TLS_README.html#client_tls_may to refer to a client that employs TLS encryption without any authentication when the server's EHLO response includes STARTTLS. In this case the client is willing to otherwise send in the clear, and, in fact, will fallback to cleartext when the TLS handshake fails. In the (new) DANE SMTP draft the terminology section reserves the term "(pre-DANE) opportunistic TLS" for the above client behaviour. http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-07#section-1.1 We introduce a new term (also listed in the terminology section) which is "opportunistic DANE TLS". The thought crime in question predates the last summer's pervasive monitoring disclosures. The work on the draft began in March 2013, and the new term was used (correctly or otherwise) from the outset. So you might ask what was the word "opportunistic" doing in our avant-garde use of the term "opportunistic DANE TLS"? The answer is that as with (pre-DANE) opportunistic TLS, the client is willing to send in the clear to any server for which no "secure" TLSA records are available. Thus, until the happy future when a significant fraction of domains are DNSSEC signed, and their MX hosts are accompanied by DNSSEC-validated "secure" TLSA records, in practice the protocol is essentially the same as with (pre-DANE) opportunistic TLS. The client employs the best security level available (including cleartext). What DANE does is raise the bar, so that for some destinations, the ones with secure TLSA records, the best available is authenticated TLS, and this status can be determined in a downgrade-resistant manner. I am open to any reasonable terminology that conveys to the user that the security policy is still "best effort", but when DANE is applicable we can do better than unauthenticated TLS with cleartext fallback. So Phillip is quite right that DANE gets us stronger semantics, but I would argue, that because the actual security posture is *conditional* on published receiving system capabilities, from the perspective of the sending system, this is just a "hardened" version of opportunistic TLS where, for just some destinations not known to the sender in advance, MITM attacks cannot trivially downgrade senders to plaintext or compromise transport integrity or confidentiality. So in Postfix documentation, we'll still describe the resulting security as a form of opportunistic TLS (this is how the email administrator should think about this "hardened" best-effort security). http://www.postfix.org/TLS_README.html#client_tls_dane In IETF documents, I'm open to anything that aligns reasonably well with other documents. We do not mean to cause any confusion. If there is a clear precedent or consensus for naming "opportunistic DANE TLS" in some other way, I for one have no objections. -- Viktor. From nobody Fri Mar 7 01:35:18 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CFE21A017B; Fri, 7 Mar 2014 01:35:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.019 X-Spam-Level: * X-Spam-Status: No, score=1.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665, T_TVD_MIME_NO_HEADERS=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rjx5X2yZdTNT; Fri, 7 Mar 2014 01:35:12 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 551F81A0159; Fri, 7 Mar 2014 01:35:12 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 048D12002B; Fri, 7 Mar 2014 05:53:47 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 4B7E1647C9; Fri, 7 Mar 2014 04:35:06 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 366F6647C8; Fri, 7 Mar 2014 04:35:06 -0500 (EST) From: Michael Richardson To: dane@ietf.org, saag@ietf.org In-Reply-To: <20140307004432.GH21390@mournblade.imrryr.org> References: <20140307004432.GH21390@mournblade.imrryr.org> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/dane/y3AiHzcyNbQRiN7cRVj2RA-YX5k Subject: Re: [dane] Need better opportunistic terminology X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 09:35:16 -0000 --=-=-= Viktor Dukhovni wrote: > So you might ask what was the word "opportunistic" doing in our > avant-garde use of the term "opportunistic DANE TLS"? The answer is > that as with (pre-DANE) opportunistic TLS, the client is willing to > send in the clear to any server for which no "secure" TLSA records are > available. > Thus, until the happy future when a significant fraction of domains are > DNSSEC signed, and their MX hosts are accompanied by DNSSEC-validated > "secure" TLSA records, in practice the protocol is essentially the same > as with (pre-DANE) opportunistic TLS. The client employs the best > security level available (including cleartext). And, in particular, I think that "opportunistics TLS" interoperates with "opportunistics DANE TLS". The two sides don't have to have to known each other's policies. > So Phillip is quite right that DANE gets us stronger semantics, but I > would argue, that because the actual security posture is *conditional* > on published receiving system capabilities, from the perspective of the > sending system, this is just a "hardened" version of opportunistic TLS > where, for just some destinations not known to the sender in advance, > MITM attacks cannot trivially downgrade senders to plaintext or > compromise transport integrity or confidentiality. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting for hire =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUxmSyoqHRg3pndX9AQKgpQQAgKbTzlCQ/FHl742S9UFn1kwhUb7zfTkQ JmQsKLY9sTgkbGu+/XaOsQe3B9/6OQdRwLNrOsBfWbo5kMR7iqql5inim93ODdmd eY5c2NAM5reg2pugCWGABZZz6tSqhw0uHwuffRojDFKlYZQa+7dSZ9omJ34e3A3b Lu1lFDlRwuM= =60eZ -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Mar 7 02:20:37 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4DF51A0159; Fri, 7 Mar 2014 02:20:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5PFCN6K_gDyQ; Fri, 7 Mar 2014 02:20:33 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id C00571A012B; Fri, 7 Mar 2014 02:20:32 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3E8D12AB24B; Fri, 7 Mar 2014 10:20:27 +0000 (UTC) Date: Fri, 7 Mar 2014 10:20:27 +0000 From: Viktor Dukhovni To: Michael Richardson Message-ID: <20140307102027.GJ21390@mournblade.imrryr.org> References: <20140307004432.GH21390@mournblade.imrryr.org> <13236.1394184906@sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <13236.1394184906@sandelman.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/6m6baSt_UJDldM7Jcp9ICmrjC_w Cc: saag@ietf.org, dane@ietf.org Subject: Re: [dane] Need better opportunistic terminology X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 10:20:36 -0000 On Fri, Mar 07, 2014 at 04:35:06AM -0500, Michael Richardson wrote: > > Thus, until the happy future when a significant fraction of domains are > > DNSSEC signed, and their MX hosts are accompanied by DNSSEC-validated > > "secure" TLSA records, in practice the protocol is essentially the same > > as with (pre-DANE) opportunistic TLS. The client employs the best > > security level available (including cleartext). > > And, in particular, I think that "opportunistics TLS" interoperates with > "opportunistics DANE TLS". The two sides don't have to have to known each > other's policies. Yes. This is quite common. Servers generally don't know how and whether clients perform TLS authentication. The best they can hope for is that clients find their certificates useful. I should however note that opportunistic DANE TLS sends SNI when the server has TLSA records. We don't yet know whether there are MTA implementations which would fail to complete the TLS handshake when they don't have a certificate with an exactly matching name. The draft requires servers to continue with a suitable default certificate if no SNI match is found. Since the draft precedes any significant deployment of SMTP servers with TLSA records, one can hope that server operators will not publish TLSA records if their server is "allergic" to "opportunistic" DANE TLSA clients (really SNI hints that turn out to not match any certificate configured on the server). Thus far no such servers have been observed, but the number of deployed clients and servers is still quite small. I am not aware of any MTAs that support server-side SNI, but this could be mere ignorance. If some do, those might be the ones that get unhappy with unexpected SNI signals from clients. Servers that have completely ignored SNI to date (e.g. Postfix) will continue to do so. Any suggestions for a better name for this mode of operation? -- Viktor. From nobody Sat Mar 8 09:06:04 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB371A02DB for ; Sat, 8 Mar 2014 09:06:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQHdw4Itqxfx for ; Sat, 8 Mar 2014 09:06:01 -0800 (PST) Received: from ka.mail.enyo.de (ka.mail.enyo.de [87.106.162.201]) by ietfa.amsl.com (Postfix) with ESMTP id 8AEA91A02B8 for ; Sat, 8 Mar 2014 09:06:01 -0800 (PST) Received: from [172.17.135.4] (helo=deneb.enyo.de) by ka.mail.enyo.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) id 1WMKh9-0001ZQ-IQ; Sat, 08 Mar 2014 18:05:55 +0100 Received: from fw by deneb.enyo.de with local (Exim 4.80) (envelope-from ) id 1WMKh9-0003nv-Dv; Sat, 08 Mar 2014 18:05:55 +0100 From: Florian Weimer To: Paul Wouters References: <20140226155752.GT21390@mournblade.imrryr.org> Date: Sat, 08 Mar 2014 18:05:55 +0100 In-Reply-To: (Paul Wouters's message of "Wed, 26 Feb 2014 11:16:36 -0500 (EST)") Message-ID: <87a9d0ei30.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/dane/VD41ZTzfuOnvpnHt8Ci_sVObSpg Cc: dane@ietf.org Subject: Re: [dane] An AD bit discussion X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 17:06:03 -0000 * Paul Wouters: > Sorry, I mistook the flags in the struct to be the DNS flags. Let me > rephrase it as "a DNS API call that returns the presence or lack of > AD bit" I think this focus on the AD bit is a grave mistake. There are other technologies for securing DNS data. At least one of them (installing an authenticated copy of the zone in the resolver) is superior to DNSSEC according to various criteria, but full implementation requires that the resolver clears the AD bit. From nobody Sun Mar 9 12:55:21 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ADB41A0375; Sun, 9 Mar 2014 12:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wYgnB2PcZO8t; Sun, 9 Mar 2014 12:55:18 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id BEEAB1A037E; Sun, 9 Mar 2014 12:55:18 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 1CD942AB250; Sun, 9 Mar 2014 19:55:12 +0000 (UTC) Date: Sun, 9 Mar 2014 19:55:12 +0000 From: Viktor Dukhovni To: Peter Saint-Andre Message-ID: <20140309195512.GQ21390@mournblade.imrryr.org> References: <20140307004432.GH21390@mournblade.imrryr.org> <531B6D43.7030806@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <531B6D43.7030806@stpeter.im> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/JmfkknsCISOjU18EpvBCceuT7LE Cc: saag@ietf.org, dane@ietf.org Subject: Re: [dane] Need better opportunistic terminology X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Mar 2014 19:55:20 -0000 On Sat, Mar 08, 2014 at 12:19:31PM -0700, Peter Saint-Andre wrote: > >I am open to any reasonable terminology that conveys to the user that the > >security policy is still "best effort", but when DANE is applicable we can > >do better than unauthenticated TLS with cleartext fallback. > > [...] > > So if regular folks have any mental association for the word > "opportunistic", it's something like "selfish and unscrupulous". Perhaps so, but the draft is written for potential implementors and to some extent administrators of SMTP TLS security, not so much "regular folks". By the target audience, "opportunistic TLS" is I think already understood in its proper context. > IMHO, it would be better to use terms like "best effort security" or > "optimistic security" (as in "we're hoping it's secure but we can't > make any promises"). The situation calls for a reasonably clear term for a mode of operation where DANE authenticated TLS is used whenever TLSA records are published via DNSSEC, with fallback to opportunistic TLS otherwise. The result is in a way doubly "opportunistic". Not only is DANE employed when possible (downgrade-resistant modulo DNSSEC compromise), but when DANE is not applicable, unauthenticated TLS is employed when possible (passive attack resistant, but vulnerable to MITM attacks). This said the intent is that the modifier "opportunistic" is to be understood to apply to "DANE". For example, Postfix also implements a "dane-only" security policy that can be used to insist on DANE security. This latter security policy is described as "mandatory" rather than "opportunistic". So while I am quite open to using better terminology, nothing obvious comes to mind. I don't think that "optimistic" is closer to the mark. The optimist might assume there are no attackers and always send in the clear. Doing best effort crypto to the extent of hardening STARTTLS against MITM attacks is, if anything, a somewhat pessimist/realist view of the security of the Internet. -- Viktor. From nobody Mon Mar 10 07:50:32 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9850F1A043E for ; Mon, 10 Mar 2014 07:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rd2AH6IJuB4b for ; Mon, 10 Mar 2014 07:50:28 -0700 (PDT) Received: from mail.zash.se (ip66.hethane.riksnet.nu [85.11.25.66]) by ietfa.amsl.com (Postfix) with ESMTP id B31D01A0434 for ; Mon, 10 Mar 2014 07:50:28 -0700 (PDT) Received: from [IPv6:2001:16d8:ffc6:0:b1f7:63b9:e8ad:8e70] (unknown [IPv6:2001:16d8:ffc6:0:b1f7:63b9:e8ad:8e70]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: zash) by mail.zash.se (Postfix) with ESMTPSA id C3A5560C58 for ; Mon, 10 Mar 2014 15:50:20 +0100 (CET) Message-ID: <531DD129.9020305@zash.se> Date: Mon, 10 Mar 2014 15:50:17 +0100 From: Kim Alvefur User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: DANE WG X-Enigmail-Version: 1.6 OpenPGP: id=B67AD329; url=http://zash.se/~zash/pubkey.asc Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="roirl2E1sq07wHlWaXKMdtXvuK34ditu3" Archived-At: http://mailarchive.ietf.org/arch/msg/dane/VKUt-9_4xERcMPd9P86tdALm-eE Subject: [dane] DANE XMPP s2s implementation X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 14:50:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --roirl2E1sq07wHlWaXKMdtXvuK34ditu3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Everyone back (and recovered) from IETF89? Much interesting, such people, very discussions, wow. So I have an experimental DANE implementation for server-to-server connections in the Prosody XMPP server. It's currently only doing DANE-EE and PKIX-EE. The TA variants are trickier, especially DANE-TA, so I have left them out for now. LuaSec, the OpenSSL to Lua binding we use, doesn't currently expose anything for validating some random chain. It also includes an attempt at doing something for authenticating the client certificate on incoming connections, by looking for a TLSA record at the same name as for SRV, eg _xmpp-server._tcp.example.com. Comments about this would be appreciated. Info: http://code.google.com/p/prosody-modules/wiki/mod_s2s_auth_dane Code: http://code.google.com/p/prosody-modules/source/browse/mod_s2s_auth_dane/= mod_s2s_auth_dane.lua -- Regards, Kim "Zash" Alvefur --roirl2E1sq07wHlWaXKMdtXvuK34ditu3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTHdEpAAoJEK3tmne2etMpnpQP/j8oRwpn+lumRIvmiLkD4xGP ksPjzru18hr5UKM7xV/ow7gO3ryHR5shVbKGnociH91D/gfA+S4tUECb0x8NT3aa GFso1Eq5uHeu4A/tUBsExCuKpmqocclFYoDdvxptkXKWB3tkq8g9z2fwV7KaySYH d6+ji3hH9icCbQjt4cQk8Adf3/aUMo7wKSUvhppDhjzhSr1iJjn8loHC6LmzWY2q mtRx6HgNvQkpJn1TQoU8eI099LtWLoJgsIWVQYtI9YxVzFnMW5urAi2ZnPns745/ dL/Alw0DnsSJInMzi4OSKMXmu0Lse2o9nUM4PWpr6rRSCDMKVs3OjtrcxLyuFHTF Txe1r9XGvpiTJwBA/wDMHR1idVIgVZ/AxP1F74hcu1fB8ouv6f2n0kvkHl8BCqIU xno4jok07baRddzbZplA0PFOx6h+0PmY+lC7i6pLVss3NWkSbeDqLEGmvT3nzfeT 0TdLFX9gEskt7s4mjcyoKalUaDTLJO96Di0yUoRCnHSrxeqF3mbi6KKZLVDDhwSe /8YPXZhcxcMqHDo6cS5J4S1Bf9+p9xgYfFMn4zRyLg7tpGjatWDzPxC0Ib5QQwRe EU6x4cLk0ZqMRXH9gneF8ADKUvvpiqupthGxqT+KZv+afJqygRS8C0KiIYT1uAUr sheJqJ1DVBEzMj45/Krd =KOtX -----END PGP SIGNATURE----- --roirl2E1sq07wHlWaXKMdtXvuK34ditu3-- From nobody Mon Mar 10 09:14:27 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 299B11A0535 for ; Mon, 10 Mar 2014 09:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NCorxV5C2WR6 for ; Mon, 10 Mar 2014 09:14:06 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 879BC1A04CD for ; Mon, 10 Mar 2014 09:13:58 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 006B32AAB42; Mon, 10 Mar 2014 16:13:50 +0000 (UTC) Date: Mon, 10 Mar 2014 16:13:50 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140310161350.GW21390@mournblade.imrryr.org> References: <531DD129.9020305@zash.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <531DD129.9020305@zash.se> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/ye9ALl6gCPkaEH5OAEWjO10z_c4 Subject: Re: [dane] DANE XMPP s2s implementation X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 16:14:21 -0000 On Mon, Mar 10, 2014 at 03:50:17PM +0100, Kim Alvefur wrote: > It's currently only doing DANE-EE and PKIX-EE. I would recommend that, as with the SMTP draft, the XMPP community choose a subset of the DANE usages to support. Either 0/1 or 2/3, but not both. By choosing both you get the weakest security, and the maximal deployment friction (everyone needs to deploy and trust the same set of CAs). So it makes more sense to implement just one of DANE-EE or PKIX-EE, with a plan to later add one of DANE-TA or PKIX-TA respectively. > The TA variants are > trickier, especially DANE-TA, so I have left them out for now. Indeed, especially for DANE-TA, it makes sense to wait until the underlying TLS toolkits: OpenSSL, NSS, GnuTLS, ... support DANE trust chain verification and name checks (integrated with trust validation because DANE-EE obviates name checks, while DANE-TA requires them). Though IIRC the XMPP draft currently just defers all the DANE language to the SRV draft, it may at some point make sense to be more explicit about XMPP-specific choices, unless the SRV draft is modified to define a set of profiles, one of which exactly matches the requirements of XMPP. > It also includes an attempt at doing something for authenticating the > client certificate on incoming connections, by looking for a TLSA record > at the same name as for SRV, eg _xmpp-server._tcp.example.com. Comments > about this would be appreciated. I encourage you to discuss this with the XMPP draft authors, I asked this very question informally and was told that client certificate verification was somehow accomplished via callbacks. If it is reasonable to require the outbound XMPP clients for a domain to possess the same private keys and certificates as the inbound servers, then your approach may reasonable. Though you likely end up taking the union of the TLSA records for all servers, rather than just the specific server you connect to when validating a connection to a server. I would suggest a less ad-hoc strategy for authenticating clients, perhaps a lookup key for TLSA records at: _xmpp-client.example.com IN TLSA ... if client certificates are to be used with XMPP to authenticate the client domain. (Neither _port nor _proto make much sense for clients, the client is not a fixed transport end-point). -- Viktor. From nobody Mon Mar 10 23:56:19 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B0C31A03AF for ; Mon, 10 Mar 2014 23:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wnA8c046eR-o for ; Mon, 10 Mar 2014 23:56:15 -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 D61CA1A039D for ; Mon, 10 Mar 2014 23:56:15 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id BEF9EC947E; Tue, 11 Mar 2014 06:55:57 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1394520970; bh=8VVeZUBZ0qRh1phefzHnQii5m1xkLb6YPbimFN9w1W4=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=AcWZNhksbc1/dGQidJsym1LEecEbHBrZqe78Lg7oVn78847qE5epgBc7D7qbu990/ L+2PZkHxjEAEQi0YPD/Hpe2JDZduFzaCKH4xHyBkhEJQOG3CDe7XfPT7yz+Kvg+/FD +H+UeMDtR3OX+syP2CoaAeGSipDlMuj6VrRhZOBM= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Tue, 11 Mar 2014 06:55:57 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 9FF7F16005D; Tue, 11 Mar 2014 06:56:57 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 10ED1160055; Tue, 11 Mar 2014 06:56:42 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id C613F10E0717; Tue, 11 Mar 2014 17:46:39 +1100 (EST) To: Florian Weimer From: Mark Andrews References: <20140226155752.GT21390@mournblade.imrryr.org> <87a9d0ei30.fsf@mid.deneb.enyo.de> In-reply-to: Your message of "Sat, 08 Mar 2014 18:05:55 +0100." <87a9d0ei30.fsf@mid.deneb.enyo.de> Date: Tue, 11 Mar 2014 17:46:39 +1100 Message-Id: <20140311064639.C613F10E0717@rock.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Archived-At: http://mailarchive.ietf.org/arch/msg/dane/2Gs3L4we6RfYGu2_4FAy-wypmJM Cc: Paul Wouters , dane@ietf.org Subject: Re: [dane] An AD bit discussion X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 06:56:17 -0000 In message <87a9d0ei30.fsf@mid.deneb.enyo.de>, Florian Weimer writes: > * Paul Wouters: > > > Sorry, I mistook the flags in the struct to be the DNS flags. Let me > > rephrase it as "a DNS API call that returns the presence or lack of > > AD bit" > > I think this focus on the AD bit is a grave mistake. There are other > technologies for securing DNS data. At least one of them (installing > an authenticated copy of the zone in the resolver) is superior to > DNSSEC according to various criteria, but full implementation requires > that the resolver clears the AD bit. You can set AD=1 with a local copy of the zone. I actually run named locally like this with full dnssec validation of results returned from the local zone. You can also just assert AD=1 without doing validation if that is what your local policy states on secure transfer. > _______________________________________________ > 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 nobody Tue Mar 11 00:32:50 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40F1A1A027F for ; Tue, 11 Mar 2014 00:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDWhnTGhEHBQ for ; Tue, 11 Mar 2014 00:32:47 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 669BE1A0278 for ; Tue, 11 Mar 2014 00:32:47 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s2B7Wbpm015013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 11 Mar 2014 03:32:37 -0400 Received: from pspacek.brq.redhat.com (vpn1-7-23.ams2.redhat.com [10.36.7.23]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s2B7WZbq001296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 11 Mar 2014 03:32:37 -0400 Message-ID: <531EBC13.1060007@redhat.com> Date: Tue, 11 Mar 2014 08:32:35 +0100 From: Petr Spacek Organization: Red Hat User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: dane@ietf.org References: <20140226155752.GT21390@mournblade.imrryr.org> <87a9d0ei30.fsf@mid.deneb.enyo.de> <20140311064639.C613F10E0717@rock.dv.isc.org> In-Reply-To: <20140311064639.C613F10E0717@rock.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/B6PGvjXgF5i9oDJ3bf3-W78-E2o Subject: Re: [dane] An AD bit discussion X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 07:32:49 -0000 On 11.3.2014 07:46, Mark Andrews wrote: > > In message <87a9d0ei30.fsf@mid.deneb.enyo.de>, Florian Weimer writes: >> * Paul Wouters: >> >>> Sorry, I mistook the flags in the struct to be the DNS flags. Let me >>> rephrase it as "a DNS API call that returns the presence or lack of >>> AD bit" >> >> I think this focus on the AD bit is a grave mistake. There are other >> technologies for securing DNS data. At least one of them (installing >> an authenticated copy of the zone in the resolver) is superior to >> DNSSEC according to various criteria, but full implementation requires >> that the resolver clears the AD bit. > > You can set AD=1 with a local copy of the zone. I actually run > named locally like this with full dnssec validation of results > returned from the local zone. You can also just assert AD=1 without > doing validation if that is what your local policy states on secure > transfer. Maybe it is not a problem but I have to ask: What if DS records in parent zone are somehow broken? Validating resolvers will see the child zone as bogus but authoritative server for such zone will happily set AD=1. I'm curious if this conflicts with AD bit definition in RFCs or not. -- Petr^2 Spacek From nobody Tue Mar 11 01:09:13 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 293A61A03F2 for ; Tue, 11 Mar 2014 01:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.448 X-Spam-Level: X-Spam-Status: No, score=-7.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fvgJLhZqICsl for ; Tue, 11 Mar 2014 01:09:09 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) by ietfa.amsl.com (Postfix) with ESMTP id 9889C1A03E0 for ; Tue, 11 Mar 2014 01:09:08 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 819172383DF; Tue, 11 Mar 2014 08:08:51 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id E99AE16005D; Tue, 11 Mar 2014 08:09:50 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id B4F94160055; Tue, 11 Mar 2014 08:09:50 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 2AF5B10E2EE8; Tue, 11 Mar 2014 19:09:01 +1100 (EST) To: Petr Spacek From: Mark Andrews References: <20140226155752.GT21390@mournblade.imrryr.org> <87a9d0ei30.fsf@mid.deneb.enyo.de> <20140311064639.C613F10E0717@rock.dv.isc.org> <531EBC13.1060007@redhat.com> In-reply-to: Your message of "Tue, 11 Mar 2014 08:32:35 +0100." <531EBC13.1060007@redhat.com> Date: Tue, 11 Mar 2014 19:09:01 +1100 Message-Id: <20140311080901.2AF5B10E2EE8@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/dane/y1UcwtQ6WriNnYrPPFXKpbPI7Pc Cc: dane@ietf.org Subject: Re: [dane] An AD bit discussion X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 08:09:11 -0000 In message <531EBC13.1060007@redhat.com>, Petr Spacek writes: > On 11.3.2014 07:46, Mark Andrews wrote: > > > > In message <87a9d0ei30.fsf@mid.deneb.enyo.de>, Florian Weimer writes: > >> * Paul Wouters: > >> > >>> Sorry, I mistook the flags in the struct to be the DNS flags. Let me > >>> rephrase it as "a DNS API call that returns the presence or lack of > >>> AD bit" > >> > >> I think this focus on the AD bit is a grave mistake. There are other > >> technologies for securing DNS data. At least one of them (installing > >> an authenticated copy of the zone in the resolver) is superior to > >> DNSSEC according to various criteria, but full implementation requires > >> that the resolver clears the AD bit. > > > > You can set AD=1 with a local copy of the zone. I actually run > > named locally like this with full dnssec validation of results > > returned from the local zone. You can also just assert AD=1 without > > doing validation if that is what your local policy states on secure > > transfer. > > Maybe it is not a problem but I have to ask: > > What if DS records in parent zone are somehow broken? Validating resolvers > will see the child zone as bogus but authoritative server for such zone will > happily set AD=1. Yes. > I'm curious if this conflicts with AD bit definition in RFCs or not. It is permitted. > -- > Petr^2 Spacek > > _______________________________________________ > 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 nobody Tue Mar 11 14:53:43 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 842BD1A063F; Tue, 11 Mar 2014 14:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gdfsCku1caT; Tue, 11 Mar 2014 14:53:33 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 77AC21A081F; Tue, 11 Mar 2014 14:53:31 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:49887) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WNUc7-0007aT-Vo; Tue, 11 Mar 2014 17:53:32 -0400 Message-ID: <531F85D5.2070209@bbn.com> Date: Tue, 11 Mar 2014 17:53:25 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: dane@ietf.org, saag References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> In-Reply-To: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> Content-Type: multipart/alternative; boundary="------------070101090705030407040800" Archived-At: http://mailarchive.ietf.org/arch/msg/dane/D800tEsz9iZUleu7C4KeL8G_H9E Subject: Re: [dane] [saag] Need better opportunistic terminology X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 21:53:39 -0000 This is a multi-part message in MIME format. --------------070101090705030407040800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Joe, > On Mar 6, 2014, at 1:23 AM, Phillip Hallam-Baker > wrote: > >> The term opportunistic has become the new synonym for 'Good' but it >> is being used for many different things. >> >> A) Unauthenticated key exchange > > Fwiw, this is IMO an error since I first introduced BTNS, and I had to > clear it up on Wikipedia multiple times. I see nothing opportunistic > about this mode as a stand-alone concept. The original use of the term appears to be from RFC 4322, Micheal Richardson's document. He describes how to use keys retrieved from the DNS with IPsec/IKE, without prior, bilateral arrangements for access control, via the SPD. He defined OE that way, and noted that it was not an unauthenticated mode of IPsec. I prefer that we stick with that definition of the term, which is IPsec-specific. I have suggested "opportunistic keying" as a preferred term, since its the key management, not the encryption per se, that distinguishes other proposed modes of operation for IPsec, TLS, etc. The breakout group at the STRINT workshop that discussed terminology suggested using the term noted above. Steve --------------070101090705030407040800 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Joe,

On Mar 6, 2014, at 1:23 AM, Phillip Hallam-Baker <hallam@gmail.com> wrote:

The term opportunistic has become the new synonym for 'Good' but it is being used for many different things.

A) Unauthenticated key exchange

Fwiw, this is IMO an error since I first introduced BTNS, and I had to clear it up on Wikipedia multiple times. I see nothing opportunistic about this mode as a stand-alone concept.
The original use of the term appears to be from RFC 4322, Micheal Richardson's document.
He describes how to use keys retrieved from the DNS with IPsec/IKE, without prior, bilateral
arrangements for access control, via the SPD. He defined OE that way, and noted that it was
not an unauthenticated mode of IPsec. I prefer that we stick with that definition of the term,
which is IPsec-specific. I have suggested "opportunistic keying" as a preferred term, since
its the key management, not the encryption per se, that distinguishes other proposed modes of
operation for IPsec, TLS, etc. The breakout group at the STRINT workshop that discussed terminology
suggested using the term noted above.

Steve


--------------070101090705030407040800-- From nobody Tue Mar 11 15:13:05 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8675F1A0823; Tue, 11 Mar 2014 15:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UaItCGUI0cLa; Tue, 11 Mar 2014 15:12:55 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7CA1A063F; Tue, 11 Mar 2014 15:12:55 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s2BMCZWQ019124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 11 Mar 2014 15:12:35 -0700 (PDT) Message-ID: <531F8A53.1040103@isi.edu> Date: Tue, 11 Mar 2014 15:12:35 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Stephen Kent , dane@ietf.org, saag References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> In-Reply-To: <531F85D5.2070209@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/dane/IaoPSi0XcjRPNxJKlQvlSVneDWg Subject: Re: [dane] [saag] Need better opportunistic terminology X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 22:12:57 -0000 Hi, Steve, On 3/11/2014 2:53 PM, Stephen Kent wrote: > Joe, > >> On Mar 6, 2014, at 1:23 AM, Phillip Hallam-Baker > > wrote: >> >>> The term opportunistic has become the new synonym for 'Good' but it >>> is being used for many different things. >>> >>> A) Unauthenticated key exchange >> >> Fwiw, this is IMO an error since I first introduced BTNS, and I had to >> clear it up on Wikipedia multiple times. I see nothing opportunistic >> about this mode as a stand-alone concept. > > The original use of the termappears to be from RFC 4322, Micheal > Richardson's document. He describes how to use keys retrieved from > the DNS with IPsec/IKE, without prior, bilateral arrangements for > access control, via the SPD. He defined OE that way, and noted that > it was not an unauthenticated mode of IPsec. RFC4322 defines OE. Section 1.2 describes "anonymous encryption" which is basically unauthenticated key exchange. From later in that section: Although it is a useful mode, anonymous encryption is not the goal of this project. Michael and I discussed the difference between the two (OE and anonymous encryption) on many occasions, and I don't think either of us ever confused the two (though someone who edited Wikipedia did once). The sentence above confirms that, AFAICT. > I prefer that we stick > with that definition of the term, which is IPsec-specific. I'm not quite sure what term or what definition you're referring to: OE, anonymous encryption, or unauthenticated key exchange. Can you clarify? > I have > suggested "opportunistic keying" as a preferred term, since its the > key management, not the encryption per se, that distinguishes other > proposed modes of operation for IPsec, TLS, etc. I agree if you're replacing OE with OK ;-) > The breakout group at the STRINT workshop that discussed terminology > suggested using the term noted above. Sorry, but to clarify, which term? Joe From nobody Tue Mar 11 15:30:22 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 744A81A066A; Tue, 11 Mar 2014 15:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5iyaMw7ZLOl; Tue, 11 Mar 2014 15:30:15 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 13E7C1A0834; Tue, 11 Mar 2014 15:30:15 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s2BMTp7Y024410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 11 Mar 2014 15:29:52 -0700 (PDT) Message-ID: <531F8E5F.8030705@isi.edu> Date: Tue, 11 Mar 2014 15:29:51 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Stephen Kent , dane@ietf.org, saag References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> In-Reply-To: <531F8A53.1040103@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/dane/nEH4-pO15ZRFYF5hnUIOni2MYBs Subject: Re: [dane] [saag] Need better opportunistic terminology X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 22:30:16 -0000 On 3/11/2014 3:12 PM, Joe Touch wrote: > Hi, Steve, .... >> I have >> suggested "opportunistic keying" as a preferred term, since its the >> key management, not the encryption per se, that distinguishes other >> proposed modes of operation for IPsec, TLS, etc. > > I agree if you're replacing OE with OK ;-) One clarification: I don't see the use of unauthenticated keying as opportunistic in any sense of the word. Opportunistic would mean making an assumption that might be wrong, but when it's right it saves time/effort. There's no savings here; by using unauthenticated key exchange, you're really just lowering the bar. That said, I don't like the term "anonymous encryption" because it implies identity hiding, which isn't the purpose either. Why not just use the term "unauthenticated encryption", when that's exactly what's happening? Joe From nobody Tue Mar 11 17:21:10 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF38D1A08A1; Tue, 11 Mar 2014 17:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.019 X-Spam-Level: * X-Spam-Status: No, score=1.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665, T_TVD_MIME_NO_HEADERS=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gc9eI9wDqxoz; Tue, 11 Mar 2014 17:21:04 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 222151A08A0; Tue, 11 Mar 2014 17:21:04 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E0D6D20034; Tue, 11 Mar 2014 21:39:54 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 06C65647C9; Tue, 11 Mar 2014 20:20:57 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id E8F66647C8; Tue, 11 Mar 2014 20:20:57 -0400 (EDT) From: Michael Richardson To: Viktor Dukhovni In-Reply-To: <20140307004432.GH21390@mournblade.imrryr.org> References: <20140307004432.GH21390@mournblade.imrryr.org> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/dane/g2lUKCbeOE-6Gq5stqPFuIX4Q7w Cc: saag@ietf.org, dane@ietf.org Subject: Re: [dane] [saag] Need better opportunistic terminology X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 00:21:05 -0000 --=-=-= Viktor Dukhovni wrote: >> The term opportunistic has become the new synonym for 'Good' but it is >> being used for many different things. > Since I am the primary perpetrator of the thought crime in question, :-) > I'd like to explain the term we used, and why, and solicit a better > term if the IETF has a better way of expressing the underlying idea. > Background: > In the Postfix community, we've historically used the term > "opportunistic TLS": > http://www.postfix.org/TLS_README.html#client_tls_may > to refer to a client that employs TLS encryption without any > authentication when the server's EHLO response includes STARTTLS. > In this case the client is willing to otherwise send in the clear, > and, in fact, will fallback to cleartext when the TLS handshake fails. I think that this term is consistent with rfc4322's use of opportunistic (IPsec) encryption. (I clipped the rest, because I have nothing to add) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting for hire =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUx+oaYqHRg3pndX9AQIJRQQAo18rW9LAHYjZhHuFdYO4m9bKzgadod0P 3Qy4ReuUlUzqRVP/U/F6RRE7+uN83ptyAXiiHM1rUWLcXNeP0Y9uNur6vQd91GTe YKha7NDeIzJNuFZ6Y9yrov90PkjTeeE38UZEUoZk3rjX18NctcIR1UaOxOLmg1rF 779+GJUpblk= =Jr4V -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Mar 11 23:28:07 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91EDE1A08F1; Tue, 11 Mar 2014 23:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.031 X-Spam-Level: X-Spam-Status: No, score=-3.031 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MtbIxutUTZ2Q; Tue, 11 Mar 2014 23:28:03 -0700 (PDT) Received: from anguilla.debian.or.at (anguilla.debian.or.at [86.59.21.37]) by ietfa.amsl.com (Postfix) with ESMTP id 68EB51A08E8; Tue, 11 Mar 2014 23:28:03 -0700 (PDT) Received: by anguilla.debian.or.at (Postfix, from userid 1002) id 9449C10E7C6; Wed, 12 Mar 2014 07:27:56 +0100 (CET) Date: Wed, 12 Mar 2014 07:27:56 +0100 From: Peter Palfrader To: Stephen Kent , dane@ietf.org, saag Message-ID: <20140312062756.GN11878@anguilla.noreply.org> References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <531F8E5F.8030705@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <531F8E5F.8030705@isi.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/bkwObLXXyzMWMrTdYBP1l0BFMhY Subject: Re: [dane] [saag] Need better opportunistic terminology X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 06:28:06 -0000 On Tue, 11 Mar 2014, Joe Touch wrote: > Why not just use the term "unauthenticated encryption", when that's > exactly what's happening? There is such a thing as authenticated encryption[1], as in AES GCM for instance, and what we're doing here is not its opposite. Thus, I think calling this "unauthenticated encryption" would be a bad idea. Cheers, 1: https://en.wikipedia.org/wiki/Authenticated_encryption -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `- http://www.debian.org/ From nobody Wed Mar 12 04:37:33 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 852451A094C; Wed, 12 Mar 2014 04:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2AvFBCeNYdfp; Wed, 12 Mar 2014 04:37:25 -0700 (PDT) Received: from ppsw-40.csi.cam.ac.uk (ppsw-40-v6.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f40]) by ietfa.amsl.com (Postfix) with ESMTP id C67901A0969; Wed, 12 Mar 2014 04:37:25 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:58719) by ppsw-40.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1WNhTJ-00089N-kE (Exim 4.82_3-c0e5623) (return-path ); Wed, 12 Mar 2014 11:37:17 +0000 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1WNhTJ-0008Q1-8H (Exim 4.72) (return-path ); Wed, 12 Mar 2014 11:37:17 +0000 Date: Wed, 12 Mar 2014 11:37:17 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Viktor Dukhovni In-Reply-To: <20140307004432.GH21390@mournblade.imrryr.org> Message-ID: References: <20140307004432.GH21390@mournblade.imrryr.org> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Archived-At: http://mailarchive.ietf.org/arch/msg/dane/cc2_yDD2PKht-3WanuwEy1Lt9ZA Cc: saag@ietf.org, dane@ietf.org Subject: Re: [dane] [saag] Need better opportunistic terminology X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 11:37:28 -0000 I am inclined to avoid the word "opportunistic". Judging by the confusion over the meaning of the word, and the several possible meanings that people gave at the meeting last week, I don't think its jargon usage is precise enough to be helpful. And its dictionary meaning has some slightly unpleasant overtones. How about the straightforwardly descriptive terms "unauthenticated STARTTLS" and "DANE STARTTLS"? STARTTLS implies this is an upgrade from cleartext, which I think you said last week was one of the concepts you wanted to capture in the phrase. And unauthenticated vs DANE should suggest the key security difference. Tony. -- f.anthony.n.finch http://dotat.at/ German Bight: Variable 3 or 4. Smooth or slight. Fair. Good, occasionally poor later in south. From nobody Wed Mar 12 05:46:24 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D111C1A0851; Tue, 11 Mar 2014 15:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhgV4EP3-a0W; Tue, 11 Mar 2014 15:14:01 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id D832D1A0843; Tue, 11 Mar 2014 15:13:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 447F2BE4D; Tue, 11 Mar 2014 22:13:51 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTuJkgCtOkcp; Tue, 11 Mar 2014 22:13:50 +0000 (GMT) Received: from [10.87.48.8] (unknown [86.46.16.238]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 35616BE3F; Tue, 11 Mar 2014 22:13:50 +0000 (GMT) Message-ID: <531F8A9D.2060407@cs.tcd.ie> Date: Tue, 11 Mar 2014 22:13:49 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Stephen Kent , uta@ietf.org References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> In-Reply-To: <531F85D5.2070209@bbn.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/VGEkahMv_S_vgrJi_bVYqUyZ3Kk X-Mailman-Approved-At: Wed, 12 Mar 2014 05:46:19 -0700 Subject: Re: [dane] [saag] Need better opportunistic terminology X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 22:14:05 -0000 Hiya, (Bcc'ing dane and saag for reasons that'll become obvious:-) On 03/11/2014 09:53 PM, Stephen Kent wrote: > I prefer that we stick with that definition of the term, > which is IPsec-specific. I don't think we need to face any such constraint at all. We might choose to, but there's no reason our definitions need to honor previous ones since any use of the OE term will conflict with someone's understanding. I also don't want us to end up with IPsec (or TLS) specific terminology. > I have suggested "opportunistic keying" as a > preferred term, since > its the key management, not the encryption per se, that distinguishes > other proposed modes of > operation for IPsec, TLS, etc. The breakout group at the STRINT workshop > that discussed terminology > suggested using the term noted above. I agree the OK term is better for the reasons you state. (And Pete Resnick likes the idea of OK protocols:-) If/when we re-do the MPLS thing we'll move to use that and I think it'll be useful if other folks do too. And speaking of terminology, I canvassed a few folks last week and there was reasonable support for doing the draft that defines these terms within the UTA WG. So I'd suggest we move the discussion there if that's ok just to try get it in one place. S. From nobody Wed Mar 12 05:46:26 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE891A08A6; Tue, 11 Mar 2014 17:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JouO2-OaYlC4; Tue, 11 Mar 2014 17:28:03 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1C01A08A7; Tue, 11 Mar 2014 17:28:03 -0700 (PDT) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s2C0QOp6025498; Tue, 11 Mar 2014 17:27:54 -0700 Received: from sc-owa03.marvell.com ([199.233.58.149]) by mx0b-0016f401.pphosted.com with ESMTP id 1jh9xj8gvp-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 11 Mar 2014 17:27:54 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA03.marvell.com ([fe80::4561:8e1c:d59b:f770%17]) with mapi; Tue, 11 Mar 2014 17:27:53 -0700 From: Paul Lambert To: Joe Touch , Stephen Kent , "dane@ietf.org" , saag Date: Tue, 11 Mar 2014 17:27:52 -0700 Thread-Topic: [saag] [dane] Need better opportunistic terminology Thread-Index: Ac89eXqdh5qFJQD5Q724mDexPHA3zQAB5Ikg Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D018B8660CCD@SC-VEXCH2.marvell.com> References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <531F8E5F.8030705@isi.edu> In-Reply-To: <531F8E5F.8030705@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-03-11_07:2014-03-11,2014-03-11,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1403110159 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/wBMHuYULWPdKDynQGdlroasd6zc X-Mailman-Approved-At: Wed, 12 Mar 2014 05:46:19 -0700 Subject: Re: [dane] [saag] Need better opportunistic terminology X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 00:28:05 -0000 ]On 3/11/2014 3:12 PM, Joe Touch wrote: ]> Hi, Steve, ].... ]>> I have ]>> suggested "opportunistic keying" as a preferred term, since its the ]>> key management, not the encryption per se, that distinguishes other ]>> proposed modes of operation for IPsec, TLS, etc. ]> ]> I agree if you're replacing OE with OK ;-) ] ]One clarification: I don't see the use of unauthenticated keying as ]opportunistic in any sense of the word. ] ]Opportunistic would mean making an assumption that might be wrong, but ]when it's right it saves time/effort. Opportunistic keying does provide authentication, it's just that=20 the authentication is only to the public key and is not tightly bound to any other type of identification (address, name, etc.) The binding of the key to other information useful for access control decisions is deferred. Other mechanisms are used to associate=20 the key with an appropriate access policy. At this point is where it seems to get a little trickier to describe a generic model for multiple protocols. Different applications have different=20 identifiers and binding requirements. I'm assuming the intent generally that the first key discovered=20 for a specific context would be bound to that specific usage. Without some type of pinning of the key to a context we end up with unauthenticated encryption. This implies that we will be creating more applications that display public keys or hashes of public keys. Human validation of key ownership is always a good security check (although not always the best user experience). The definition should be clear on the necessity of the additional binding and possible check of the key ownership. One idea for formalization of such opportunistic mechanisms would be to clearly define the state of the key binding to it's use in a particular context. A key newly discovered and being used for a particular dns address could be in an invalidated state, while one that was explicitly=20 checked in some manner would be in a validated state. Note - I'm working on protocols for bootstrapping P2P security that are very close to these discusions.=20 Basic design is that all devices have a public=20 Key and they are introduced for a particular=20 set of communications (service). In this application out-of-band channels can be used to support the introduction (e.g. NFC, QR Code, label on device, dynamic label on display). I've been calling aspects of this bootstrap process 'key centric' versus opportunistic since we are trying to always have a means to securely bind the key to the specific usage. Keys are the identity and are maintained in ACLs and groups for access control. Usability concerns in products will introduce=20 implementations that are more promiscuous and=20 connect opportunistically with minimal human interaction. The different types of security policies that this creates is a problem in that it lacks clear user oriented definitions. Right now, in the Wi-Fi industry the terminology is=20 either 'open' or 'encrypted' (aka WPA2). Now there will be new modes like: encrypted but=20 anyone can connect (e.g. open printer kiosk). I suspect that that this differentiation in policies will also occur in other uses of opportunistic encryption. Paul ] ]There's no savings here; by using unauthenticated key exchange, you're ]really just lowering the bar. ] ]That said, I don't like the term "anonymous encryption" because it ]implies identity hiding, which isn't the purpose either. ] ]Why not just use the term "unauthenticated encryption", when that's ]exactly what's happening? =09 ] ]Joe ] ]_______________________________________________ ]saag mailing list ]saag@ietf.org ]https://www.ietf.org/mailman/listinfo/saag From nobody Wed Mar 12 06:35:28 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7E131A0998; Wed, 12 Mar 2014 06:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IkgBGc89cOA8; Wed, 12 Mar 2014 06:35:24 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id D8D621A096E; Wed, 12 Mar 2014 06:35:23 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:39532 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WNjJT-0008KP-PQ; Wed, 12 Mar 2014 09:35:15 -0400 Message-ID: <53206293.8020907@bbn.com> Date: Wed, 12 Mar 2014 09:35:15 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Joe Touch , dane@ietf.org, saag References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> In-Reply-To: <531F8A53.1040103@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/sf4nVTA9XFrtEkyj3DvwlP0cpqc Subject: Re: [dane] [saag] Need better opportunistic terminology X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 13:35:26 -0000 Joe, > ... >> with that definition of the term, which is IPsec-specific. > > I'm not quite sure what term or what definition you're referring to: > OE, anonymous encryption, or unauthenticated key exchange. Can you > clarify? OE. I argue that OE is defined only for IPsec, because the definition focuses on how to avoid the need to coordinate SPD entries at each end. > >> I have >> suggested "opportunistic keying" as a preferred term, since its the >> key management, not the encryption per se, that distinguishes other >> proposed modes of operation for IPsec, TLS, etc. > > I agree if you're replacing OE with OK ;-) yeah, I like OK (and I like IKE too, for those of us old enough to appreciate that election slogan) > >> The breakout group at the STRINT workshop that discussed terminology >> suggested using the term noted above. > > Sorry, but to clarify, which term? OK vs. OE. Steve From nobody Wed Mar 12 06:44:28 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4189C1A0722; Wed, 12 Mar 2014 06:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wynhn76LWT82; Wed, 12 Mar 2014 06:44:24 -0700 (PDT) Received: from ppsw-40.csi.cam.ac.uk (ppsw-40-v6.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f40]) by ietfa.amsl.com (Postfix) with ESMTP id 8881E1A0715; Wed, 12 Mar 2014 06:44:24 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:35693) by ppsw-40.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1WNjSB-0002RZ-kK (Exim 4.82_3-c0e5623) (return-path ); Wed, 12 Mar 2014 13:44:15 +0000 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1WNjSB-00045M-91 (Exim 4.72) (return-path ); Wed, 12 Mar 2014 13:44:15 +0000 Date: Wed, 12 Mar 2014 13:44:15 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Viktor Dukhovni In-Reply-To: <20140309195512.GQ21390@mournblade.imrryr.org> Message-ID: References: <20140307004432.GH21390@mournblade.imrryr.org> <531B6D43.7030806@stpeter.im> <20140309195512.GQ21390@mournblade.imrryr.org> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Archived-At: http://mailarchive.ietf.org/arch/msg/dane/WPIUXRVgP_3vfG6zxn478_HNj7Q Cc: saag@ietf.org, dane@ietf.org Subject: Re: [dane] Need better opportunistic terminology X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 13:44:26 -0000 Viktor Dukhovni wrote: > > The result is in a way doubly "opportunistic". Not only is DANE > employed when possible (downgrade-resistant modulo DNSSEC compromise), > but when DANE is not applicable, unauthenticated TLS is employed > when possible (passive attack resistant, but vulnerable to MITM > attacks). I think what you are describing is just protocol feature negotiation and so it does not need a special term. We don't talk about opportunistic cipher suites, for example. Tony. -- f.anthony.n.finch http://dotat.at/ Fair Isle: Southwesterly veering westerly 5 to 7, but 4 at first in southeast, perhaps gale 8 later in west. Moderate or rough, occasionally very rough in northwest. Rain later. Moderate or good. From nobody Wed Mar 12 09:50:47 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 921031A0745; Wed, 12 Mar 2014 09:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2NxeLdIbM9Oo; Wed, 12 Mar 2014 09:50:40 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 339ED1A0829; Wed, 12 Mar 2014 09:50:18 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s2CGnGDf017693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 12 Mar 2014 09:49:18 -0700 (PDT) Message-ID: <5320900C.2030007@isi.edu> Date: Wed, 12 Mar 2014 09:49:16 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Stephen Kent , dane@ietf.org, saag References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <53206293.8020907@bbn.com> In-Reply-To: <53206293.8020907@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/dane/ek3TiH8G3O9956lrQoyztQdB6CY Subject: Re: [dane] [saag] Need better opportunistic terminology X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 16:50:45 -0000 Steve (et al.), On 3/12/2014 6:35 AM, Stephen Kent wrote: > Joe, > >> ... >>> with that definition of the term, which is IPsec-specific. >> >> I'm not quite sure what term or what definition you're referring to: >> OE, anonymous encryption, or unauthenticated key exchange. Can you >> clarify? > > OE. I argue that OE is defined only for IPsec, because the definition > focuses on how to > avoid the need to coordinate SPD entries at each end. Agreed. >>> I have >>> suggested "opportunistic keying" as a preferred term, since its the >>> key management, not the encryption per se, that distinguishes other >>> proposed modes of operation for IPsec, TLS, etc. >> >> I agree if you're replacing OE with OK ;-) > > yeah, I like OK (and I like IKE too, for those of us old enough to > appreciate that election slogan) I'm still a little hesitant, thinking on it further, about the term "opportunistic" in this sense at all. BTNS uses unsigned key exchanged, and there's nothing "opportunistic" about it. Unsigned authentication is the goal from the start. OE as defined in RFC 4322 isn't about using unsigned key exchange; the "opportunistic" sense is derived from using keys retrieved from DNS without prior agreement. That's not what happens in BTNS. Paul just noted: "Opportunistic keying does provide authentication, it's just that the authentication is only to the public key and is not tightly bound to any other type of identification (address, name, etc.)" I.e., fundamentally, opportunistic approaches are completely different from those that don't ever bother to authenticate. I don't think it's useful (and could be confusing) to confuse the two by overlapping terminology. I don't like the term "optimistic" either; it too implies something that you "hope works". There's no "hope" associated with unsigned key exchange; you do it (IMO) because you know what it is and you know its impact (e.g., raising the bar of an attacker to performing a full key exchange, vs. just tossing single packets like RSTs around). Is there a reason not to just call unauthenticated key exchange what it is - unauthenticated key exchange? If you want something pithy, maybe "Zero-ID security"? >> The breakout group at the STRINT workshop that discussed terminology >>> suggested using the term noted above. >> >> Sorry, but to clarify, which term? > > OK vs. OE. Thanks for the clarification. Joe From nobody Wed Mar 12 10:04:16 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D2081A048A; Wed, 12 Mar 2014 10:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VDkYb5asc69J; Wed, 12 Mar 2014 10:04:07 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7B81A0381; Wed, 12 Mar 2014 10:04:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 05402BE54; Wed, 12 Mar 2014 17:04:01 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7kz4QkdFcQMq; Wed, 12 Mar 2014 17:04:00 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id CF68BBE56; Wed, 12 Mar 2014 17:04:00 +0000 (GMT) Message-ID: <53209382.3070809@cs.tcd.ie> Date: Wed, 12 Mar 2014 17:04:02 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Joe Touch , Stephen Kent , dane@ietf.org, saag References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <53206293.8020907@bbn.com> <5320900C.2030007@isi.edu> In-Reply-To: <5320900C.2030007@isi.edu> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/pSd7zkKDeaBU-OKr-mxl-kP99BQ Subject: Re: [dane] [saag] Need better opportunistic terminology X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 17:04:15 -0000 (again, I'd suggest one list for this if we can and the UTA wg list, but hopefully that'll settle down when there's an I-D, and since I'm not the boss of us anyway...:-) On 03/12/2014 04:49 PM, Joe Touch wrote: > Steve (et al.), > > On 3/12/2014 6:35 AM, Stephen Kent wrote: >> Joe, >> >>> ... >>>> with that definition of the term, which is IPsec-specific. >>> >>> I'm not quite sure what term or what definition you're referring to: >>> OE, anonymous encryption, or unauthenticated key exchange. Can you >>> clarify? >> >> OE. I argue that OE is defined only for IPsec, because the definition >> focuses on how to >> avoid the need to coordinate SPD entries at each end. > > Agreed. > >>>> I have >>>> suggested "opportunistic keying" as a preferred term, since its the >>>> key management, not the encryption per se, that distinguishes other >>>> proposed modes of operation for IPsec, TLS, etc. >>> >>> I agree if you're replacing OE with OK ;-) >> >> yeah, I like OK (and I like IKE too, for those of us old enough to >> appreciate that election slogan) > > I'm still a little hesitant, thinking on it further, about the term > "opportunistic" in this sense at all. I do think we want to define that term even if we do not want to encourage its use. It is being used and with subtly different meanings by different folks. > > BTNS uses unsigned key exchanged, and there's nothing "opportunistic" > about it. Unsigned authentication is the goal from the start. > > OE as defined in RFC 4322 isn't about using unsigned key exchange; the > "opportunistic" sense is derived from using keys retrieved from DNS > without prior agreement. That's not what happens in BTNS. > > Paul just noted: > "Opportunistic keying does provide authentication, it's just that > the authentication is only to the public key and is not > tightly bound to any other type of identification (address, name, etc.)" > > I.e., fundamentally, opportunistic approaches are completely different > from those that don't ever bother to authenticate. I don't think it's > useful (and could be confusing) to confuse the two by overlapping > terminology. > > I don't like the term "optimistic" either; it too implies something that > you "hope works". There's no "hope" associated with unsigned key > exchange; you do it (IMO) because you know what it is and you know its > impact (e.g., raising the bar of an attacker to performing a full key > exchange, vs. just tossing single packets like RSTs around). > > Is there a reason not to just call unauthenticated key exchange what it > is - unauthenticated key exchange? Yes. "authenticated encryption" is a term of art (AEAD etc) and this would be confusingly close - it'd be inevitable that some would end up saying unauthenticated encryption and thereby would confuse the real crypto folks. I like the OK term myself and would be happy if we landed on encouraging its use, based on a good definition. But I'm fine if we end up calling it squiggle, so long as we all end up calling the same "it" that. > > If you want something pithy, maybe "Zero-ID security"? Too close to zero-touch (which is not ad-hominem, but is a term being used in netconf - Joe you just *have* to get involved in that:-) S. > >>> The breakout group at the STRINT workshop that discussed terminology >>>> suggested using the term noted above. >>> >>> Sorry, but to clarify, which term? >> >> OK vs. OE. > > Thanks for the clarification. > > Joe > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > From nobody Wed Mar 12 10:22:04 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF6521A04B8; Wed, 12 Mar 2014 10:06:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kj3WnwFjT4ZN; Wed, 12 Mar 2014 10:06:11 -0700 (PDT) Received: from homiemail-a106.g.dreamhost.com (agjbgdcfdbed.dreamhost.com [69.163.253.143]) by ietfa.amsl.com (Postfix) with ESMTP id 3D9E91A04C2; Wed, 12 Mar 2014 10:06:10 -0700 (PDT) Received: from homiemail-a106.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTP id 4A58B2005D102; Wed, 12 Mar 2014 10:06:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=5oMYqLH9wy6D+fktRX0k rWOyZ6c=; b=SrC99ml8mRdpeNOkNCUcSlg5PhmpPiwPCa1jorcYms6wWMUDWtXF KFbRR6jSCBYsQUu8ZL5TnoT21ol5nK38H9zi0tOBL9rmbVinIsxNIJK+GJP7nr4U z64lLIbUMaKwvAzIK98T1vnyLqPGFBC8E5s2BSSVzTCjTAS2FFLWnwM= Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTPSA id C9ADF2005D108; Wed, 12 Mar 2014 10:06:03 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id k14so9151123wgh.34 for ; Wed, 12 Mar 2014 10:06:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=s8I3t4SOI2QY6L/4Y3JzvRKhSwgBOqh01jJu4T85tgs=; b=mG1cjGPdfj8cafWOZvOxNcYRe1aSbYSlCaaJT9HJO0eB21p73e18yntW1/61NHeYc3 tnCqq0p670whbkikhRWd0l/jSxYNRsn/gqr7T8NHWJ092ez4Yc1BCG/LSN8i5tPUi8c1 GyouKA86OLgFBRz9MAlzzcty+FxmX4Ndt5OdTiPm7hLXLcdNN/sabVYECZNsxypIramT Q8q1UG0EXoOCOasEudvh2GJheFp5TFDakzjvpetuYlp8PmDxj1AVpp8EcbNJhYYxrJsS gdrzE0gnV/zFp3pPqhKvrMaDeINc2iKH8d3nkK0Eq+c0rpfD7kXeDMoehiFp2+4+05pU vvcA== MIME-Version: 1.0 X-Received: by 10.180.163.206 with SMTP id yk14mr8572892wib.5.1394643961958; Wed, 12 Mar 2014 10:06:01 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Wed, 12 Mar 2014 10:06:01 -0700 (PDT) In-Reply-To: <5320900C.2030007@isi.edu> References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <53206293.8020907@bbn.com> <5320900C.2030007@isi.edu> Date: Wed, 12 Mar 2014 12:06:01 -0500 Message-ID: From: Nico Williams To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/eDM3EfEWFm2qiuTxqTkBRdALVQQ X-Mailman-Approved-At: Wed, 12 Mar 2014 10:21:49 -0700 Cc: saag , dane@ietf.org Subject: Re: [dane] [saag] Need better opportunistic terminology X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 17:06:16 -0000 On Wed, Mar 12, 2014 at 11:49 AM, Joe Touch wrote: > On 3/12/2014 6:35 AM, Stephen Kent wrote: >>>> I have >>>> suggested "opportunistic keying" as a preferred term, since its the >>>> key management, not the encryption per se, that distinguishes other >>>> proposed modes of operation for IPsec, TLS, etc. >>> >>> I agree if you're replacing OE with OK ;-) >> >> yeah, I like OK (and I like IKE too, for those of us old enough to >> appreciate that election slogan) OK will present difficulties as an acronym... Otherwise I like "opportunistic keying", but it could cover a large range of behaviors (e.g., TOFU). > I'm still a little hesitant, thinking on it further, about the term > "opportunistic" in this sense at all. > > BTNS uses unsigned key exchanged, and there's nothing "opportunistic" about > it. Unsigned authentication is the goal from the start. For me the goal was to use channel binding at the application layer. But we never got there: no one seems to care much about end-to-end IPsec, sadly. (Well, it's not that no one cares, but that it's too late now; TLS is king.) > OE as defined in RFC 4322 isn't about using unsigned key exchange; the > "opportunistic" sense is derived from using keys retrieved from DNS without > prior agreement. That's not what happens in BTNS. Stephen has it right: OE in the RFC4322 sense is about applying protection even when SPDs don't agree on this, but it still requires a keying infrastructure (i.e., trust paths). Nico -- From nobody Wed Mar 12 10:31:33 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ABF01A0552; Wed, 12 Mar 2014 10:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DwC5JYu8BVxv; Wed, 12 Mar 2014 10:31:25 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id A717B1A0381; Wed, 12 Mar 2014 10:31:25 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s2CHUnnG001614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 12 Mar 2014 10:30:50 -0700 (PDT) Message-ID: <532099C9.6060405@isi.edu> Date: Wed, 12 Mar 2014 10:30:49 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Nico Williams References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <53206293.8020907@bbn.com> <5320900C.2030007@isi.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/dane/2qhLzTv_nqo4bU5ha0InKahyURM Cc: saag , dane@ietf.org Subject: Re: [dane] [saag] Need better opportunistic terminology X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 17:31:31 -0000 On 3/12/2014 10:06 AM, Nico Williams wrote: > On Wed, Mar 12, 2014 at 11:49 AM, Joe Touch wrote: ... >> BTNS uses unsigned key exchanged, and there's nothing "opportunistic" about >> it. Unsigned authentication is the goal from the start. > > For me the goal was to use channel binding at the application layer. Having unsigned key exchange has two ultimate uses: - raising the bar for attacks above 'send a RST' but below MITM - providing a network-level mechanism that can be linked to security at higher layers App-layer channel binding could be useful for BTNS, or for other approaches too (e.g., where a single key protects a set of ports). > But we never got there: no one seems to care much about end-to-end > IPsec, sadly. (Well, it's not that no one cares, but that it's too > late now; TLS is king.) TLS still doesn't protect the transport or network layers. >> OE as defined in RFC 4322 isn't about using unsigned key exchange; the >> "opportunistic" sense is derived from using keys retrieved from DNS without >> prior agreement. That's not what happens in BTNS. > > Stephen has it right: OE in the RFC4322 sense is about applying > protection even when SPDs don't agree on this, but it still requires a > keying infrastructure (i.e., trust paths). Right, but then "O" isn't quite the right term for security that avoids the need for keying infrastructure altogether. Joe From nobody Wed Mar 12 13:31:09 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 640D91A068F; Wed, 12 Mar 2014 13:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7H4q69MkluDc; Wed, 12 Mar 2014 13:31:05 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id AD3771A0496; Wed, 12 Mar 2014 13:31:05 -0700 (PDT) Received: from [128.9.184.173] ([128.9.184.173]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s2CKSdhm009134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 12 Mar 2014 13:28:39 -0700 (PDT) Message-ID: <5320C37A.1000903@isi.edu> Date: Wed, 12 Mar 2014 13:28:42 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Derek Atkins References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <531F8E5F.8030705@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/dane/itGjbQVWAvZ5rxEApeeIyTF0lX8 Cc: saag , dane@ietf.org Subject: Re: [dane] [saag] Need better opportunistic terminology X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 20:31:07 -0000 On 3/12/2014 1:02 PM, Derek Atkins wrote: > Joe Touch writes: > >> Why not just use the term "unauthenticated encryption", when that's >> exactly what's happening? > > Well, it's not necessarily what's happening. The data itself might > still have "integrity protection" (which is a form of authentication. Yes, and might be inaccessible to anyone except the endpoints that negotiated the key too. So you have a protected exchange both in privacy and integrity, but you don't know with whom. > You're just not authenticating the endpoint, which means you could be > subject to a MitM attack. Alternate terms could be "Unauthenticated > Keying" or "Unauthenticated Key Exchange" which are closer (IMHO) to > what's going on. Sure - yes, but neither acronym is desirable, unfortunately. Unidentified Security? Joe From nobody Wed Mar 12 13:47:31 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39FCE1A074E; Wed, 12 Mar 2014 13:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.019 X-Spam-Level: * X-Spam-Status: No, score=1.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665, T_TVD_MIME_NO_HEADERS=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M6563Sq_s64f; Wed, 12 Mar 2014 13:47:25 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id A8EBD1A074A; Wed, 12 Mar 2014 13:47:25 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8FA712002F; Wed, 12 Mar 2014 18:06:17 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id A4088647C9; Wed, 12 Mar 2014 16:47:17 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 893F3647C8; Wed, 12 Mar 2014 16:47:17 -0400 (EDT) From: Michael Richardson To: Peter Palfrader In-Reply-To: <20140312062756.GN11878@anguilla.noreply.org> References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <531F8E5F.8030705@isi.edu> <20140312062756.GN11878@anguilla.noreply.org> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/dane/Xdxxz_6_aHZSLiSkD21ynr3OrBc Cc: saag , dane@ietf.org Subject: Re: [dane] [saag] Need better opportunistic terminology X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 20:47:27 -0000 --=-=-= Peter Palfrader wrote: >> Why not just use the term "unauthenticated encryption", when that's >> exactly what's happening? > There is such a thing as authenticated encryption[1], as in AES GCM for > instance, and what we're doing here is not its opposite. Thus, I think > calling this "unauthenticated encryption" would be a bad idea. +1 and, the privacy that results from the encryption, while the primary carrot, is simply the result of finding a way to do a DH operation. The part that we are all discussing is determining how (much) to trust the DH results. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting for hire =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUyDH1YqHRg3pndX9AQKMlQQA3HKcDhKnxTg4goYXmR1EdgEoBEMHm9jK Xvyi2ofWmC0eZyS4Uy1s5GMaMkS3EJ+A46eQIJjlL+Ds/jGQaHuS6V1MEMfrwzR1 8S5QWKIbTC3kpXRiVaScYN4SyXsM9SPZiqV6ZHDTTOnGZNm9p7HT2F2TRknKoERP 3MjeGWb6B8U= =665o -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Mar 12 13:53:22 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE2A1A0784; Wed, 12 Mar 2014 13:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xzj3nxUE9o-z; Wed, 12 Mar 2014 13:53:18 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 674621A0664; Wed, 12 Mar 2014 13:53:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9DFB2BE51; Wed, 12 Mar 2014 20:53:08 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUAhZU6HlWF7; Wed, 12 Mar 2014 20:53:07 +0000 (GMT) Received: from [10.87.48.8] (unknown [86.46.16.238]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7C87DBE33; Wed, 12 Mar 2014 20:53:07 +0000 (GMT) Message-ID: <5320C932.3010107@cs.tcd.ie> Date: Wed, 12 Mar 2014 20:53:06 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Michael Richardson , Peter Palfrader References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <531F8E5F.8030705@isi.edu> <20140312062756.GN11878@anguilla.noreply.org> <3454.1394657237@sandelman.ca> In-Reply-To: <3454.1394657237@sandelman.ca> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/w0KT_kSyoFF8L_Ku-tO9dfQ-pmo Cc: saag , dane@ietf.org Subject: Re: [dane] [saag] Need better opportunistic terminology X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 20:53:20 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Michael, On 03/12/2014 08:47 PM, Michael Richardson wrote: > The part that we are all discussing is determining how (much) to > trust the DH results. I don't think that's a very accurate characterisation to be honest. I think the most relevant (but intertwined) factors are: - - trading off ease of deployment vs. endpoint authentication - - trading off protection against passive vs active attack - - better separating key exchange from endpoint authentication so that traditional authentication or TOFU or whatever can be used before during or after key exchange S. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQEcBAEBAgAGBQJTIMkuAAoJEC88hzaAX42iNbgH/2zx/K+XLC1j17iDnCmK4Kn6 mZGTrtpYf2EiAquYoS0fb2iZ8Ni7G3SV/HeUvohdT2SdhzzJ1nfxX93FHdQi0TV5 /slo1yikxtalAmxOJJQutxeXqQFd8J50uoDHfFt0qa25ph6PU5Nb7ICpONQzbfCM i6oOuh8/qY7746S51DC1a8A0FsqdhWktcEwa+sxmh9aLImmCTrSfx4lHoCMFxowO vE7tYngzifAKV5KWdC6n7UJFgXTniVGgcEpLSplN4oXMJz2Mh8dHg+Yk8aORPCq9 lBE4j3b5BWWi7U1wTcYmPQHy9GwTg2ApzhBoHCKycfmoXVIHvR1EunAo3JrATmk= =Tvs/ -----END PGP SIGNATURE----- From nobody Wed Mar 12 13:59:04 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E13641A076A for ; Wed, 12 Mar 2014 13:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mH4Jg7kCj093 for ; Wed, 12 Mar 2014 13:59:00 -0700 (PDT) Received: from smtp108.ord1c.emailsrvr.com (smtp108.ord1c.emailsrvr.com [108.166.43.108]) by ietfa.amsl.com (Postfix) with ESMTP id 02F701A074C for ; Wed, 12 Mar 2014 13:58:59 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp6.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id C00F6988DF for ; Wed, 12 Mar 2014 16:58:53 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp6.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 5F927990B8 for ; Wed, 12 Mar 2014 16:58:53 -0400 (EDT) From: Olafur Gudmundsson Content-Type: multipart/alternative; boundary="Apple-Mail=_F319A7B4-C784-4CE1-B909-D0923C47FD8D" Message-Id: <3D074047-A9FC-4C90-A819-76552A99EE27@ogud.com> Date: Wed, 12 Mar 2014 16:58:54 -0400 To: dane WG list Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/kGG0nUYw-BZcl3cGJn-edqZD1cU Subject: [dane] IETF-89 draft minutes X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 20:59:03 -0000 --Apple-Mail=_F319A7B4-C784-4CE1-B909-D0923C47FD8D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Unless we hear otherwise in the by March 24'th these will become the = official minutes. Thanks to Stephane, Olle and Dan for their notes.=20 Olafur & Warren=20 IETF 89, DANE Working Group meeting 2014-03-06=20 Chairs: Warren Kumari, Olafur Gudmundsson Scribe: Stephane Bortzmeyer Jabber Scribe: Olle Johansson=20 Tweeter: Dan York=20 Agenda in With links to the slides at 0) Administrivia The room is more than completely packed and many people are standing (or waiting outside). Next time, a bigger room is needed. 1) DANE status, Managment changes, future direction Co-chair Olafur Gudmundsson replaces Ondrej Sury. The draft "registry acronyms" draft-ietf-dane-registry-acronyms is in the RFC editor queue. Four other drafts are active. The plans are: 1.1) SMTP draft-ietf-dane-smtp-with-dane in WGLC. SRV = draft-ietf-dane-srv soon (15 april) in WGLC 1.2) SMIME draft-ietf-dane-smime + OpenPGP draft-wouters-dane-openpgp (if adopted by the WG) : in WGLC on 15 may 1.3) DANE operations draft-ietf-dane-ops : decision in june? 1.4) IPsec draft-osterweil-dane-ipsec (if adopted) after What after that? Shutdown? Many changes are expected before june, so it is too early to decide. Paul Hoffman : lots of interest in other WGs so, it would be unwise to shutdown. Discussion taken to the mailing list (but nobody argued for a shutdown). 2) Working group Lookup documents 2.1) DANE SMTP by Viktor Dukhovni (Postfix) http://www.ietf.org/proceedings/89/slides/slides-89-dane-1.pdf Viktor reported a *lot* of open issues, discovered by the development of DANE-for-SMTP but often not-SMTP specifics. Some examples: if DANE publishes a full certificate, should we use only the public key in it or also check the other fields of the certificate? Many combination of options in DANE are strange and may be useless and require explanations anyway. What if some keys are published with a different set of digests? Big CNAME issue: search the TLSA record in the expanded name (after following the CNAME chain) or not? And what if expansion is insecure (not signed with DNSSEC)? Some details when implementing DANE on Postfix: don't do TLSA when the base domain is insecure even if, in theory, the DANE domain name may be secure, for instance with DLV). When Postfix receives a raw public key, it builds a dummy certificate around it, to make its TLS library happy. (See the draft on raw keys draft-ietf-tls-oob-pubkey, in RFC editor queue) Philip Hallam-Baker mentioned Certificate Transparency but it did not seem to raise interest. Crocker asked for a way for the client to signal the server which algorithms it knows, so the server can know when to drop an algorithm. Dukhovni disagreed, saying that DANE is complicated enough. After a few certificate questions, the DNS ones : the main discussion was (Peter Koch) about "fallback" to the first item in a CNAME chain when it is insecure. Fallbacks are brittle and can be dangerous. (It is the opinion of the minute taker that "fallback" is not the best word to describe the algorithm proposed in the current draft.) 2.2) Using DNS-Based Authentication of Named Entities (DANE) TLSA records with SRV and MX records. Matt Miller=20 http://www.ietf.org/proceedings/89/slides/slides-89-dane-0.pdf Olle Johansson suggested that SIP has similar issues and that DANE people should harmonize with SIP. Someone suggested (jokingly, presumes the minute taker) to write a NAPTR document for DANE... A list of XMPP servers using DANE = 2.3) Harmonizing how applications specify DANE-like usage (DANE vocabulary) Olafur Gudmunsson https://tools.ietf.org/agenda/89/slides/slides-89-dane-4.pdf Having a separate document, only with DNS vocabulary since it seems under-specified, and varies wildly? This would introduce a delay. OK for Paul Hoffman: I have issues such as changing DNSSEC vocabulary. We should slow down the drafts, so we can fix the vocabulary. Disagreement for Viktor Dukhovni : no delay is wished for, the specification is ready. Paul Hoffman suggested to public the current drafts, then write the = vocabulary document, then produce a -bis of the other documents. Taken to the mailing list. 2.4) The DANE world model DANE - key acquisition, service discovery or usage assurance? Paul Hoffman (No slides) This was a more philosophical discussion (do note the W3C has an explicit Philosophy Working Group ). Now that DANE is used for other things than the Web, we have many questions. Biggest one in the discussion, "DNS : delivery or discovery?" It seems there is no consensus, one of the reasons being that there is no clear definition of either. Many people do not see the difference (Dave Crocker: no difference. A lookup with A is the same as a lookup with SRV). Some people says there is one and that discovery is bad, is not "proper use of the DNS". For instance, on XMPP, Andrew Sullivan said "there's an ambiguity in 'discovery'. Some of it is 'discover service at this owner name' and some of it is 'find the right owner name for this service'. Most of the DNS anger is directed at (2) because it requires tree-climbing." It is not only philosophical, it may have security consequence if the data in the DNS and in TLS disagree. Also, does it mean we can use DANE to find out if we are supposed to connect to the peer with TLS? Tony Finch: a TLSA record also means you expect people to use TLS (no consensus on that). Peter Koch said it is neither delivery or discovery, DNS is lookup, you need a fixed identifier to starts with. He pointed out another ambiguity: domain can mean a subtree or a domain name (a node). Andrew Sullivan suggested also to start on a new work item: "Semiotics of DNS names from an architechtonic lead user's, pan-applicationist, IntraSuperSemioNet, post-modernist perspective" :-) For this issue, there was one question by the chairs: do we need to document this? The hmmmm clearly says yes and there was four-five volunteers to work on it. 2.5) Using DANE to Associate OpenPGP public keys with email addresses Paul Wouters https://tools.ietf.org/agenda/89/slides/slides-89-dane-2.pdf There is running code on (and Github ) + a milter for Sendmail and Postfix. Biggest issue in the discussion: the TLSA record is found at a domain name which is the user's email address (actually, a hash of it). Since the left part of an email address is case-sensitive (in theory: Paul Wouters asked if there really was SMTP servers which care about case and got not reply), matching is less trivial thaan it seems ('echo -n "jAkOb" | openssl sha -sha224' ?) Mark Andrews claimed we should define canonicalization rules. Not doing so is "lazyness". Paul Hoffman disagrees, canonicalization is not easy (internationalized left parts) Taken to the mailing list. The two OpenPGP documents are asking for adoption. draft-wouters-dane-openpgp and draft-wouters-dane-openpgpkey-usage both got a strong hmmmmmmmmmmm. 2.6) IPSECKEY / Auth_none Paul Wouters http://www.ietf.org/proceedings/89/slides/slides-89-dane-3.pdf Just information, no decision 2.7) IPSECA Eric Osterweill (slides not available) draft-osterweil-dane-ipsec One of the goals is harmonize IPsec key learning with DANE. For instance, IPsec keys are currently host-specific while DANE keys are port-specific. Not many reactions= --Apple-Mail=_F319A7B4-C784-4CE1-B909-D0923C47FD8D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Olafur & = Warren 


IETF 89, DANE Working = Group meeting
2014-03-06 
Chairs: Warren Kumari, Olafur = Gudmundsson
Scribe: Stephane Bortzmeyer
Jabber = Scribe: Olle Johansson 
Tweeter: Dan = York 

Agenda in <https://data= tracker.ietf.org/meeting/89/agenda/dane/>
With links to the = slides at <https://tools.ietf.org/wg/d= ane/agenda>

0) Administrivia

The room is more than = completely packed and many people are standing
(or waiting outside). = Next time, a bigger room is needed.

1) DANE status, Managment = changes, future direction

Co-chair Olafur Gudmundsson replaces = Ondrej Sury.

The draft "registry acronyms" = draft-ietf-dane-registry-acronyms is in
the RFC editor = queue.

Four other drafts are active. The plans are:
1.1) SMTP = draft-ietf-dane-smtp-with-dane in WGLC.  SRV = draft-ietf-dane-srv
soon (15 april) in WGLC
1.2) SMIME = draft-ietf-dane-smime + OpenPGP draft-wouters-dane-openpgp
(if = adopted by the WG) : in WGLC on 15 may
1.3) DANE operations = draft-ietf-dane-ops : decision in june?
1.4) IPsec = draft-osterweil-dane-ipsec (if adopted) after

What after that? = Shutdown? Many changes are expected before
june, so it is too early = to decide. Paul Hoffman : lots of interest in
other WGs so, it would = be unwise to shutdown. Discussion taken to the
mailing list (but = nobody argued for a shutdown).

2) Working group Lookup = documents

2.1) DANE SMTP by Viktor Dukhovni (Postfix)
ht= tp://www.ietf.org/proceedings/89/slides/slides-89-dane-1.pdf

Vi= ktor reported a *lot* of open issues, discovered by the = development
of DANE-for-SMTP but often not-SMTP specifics. Some = examples: if DANE
publishes a full certificate, should we use only = the public key in it
or also check the other fields of the = certificate? Many combination of
options in DANE are strange and may = be useless and require
explanations anyway. What if some keys are = published with a different
set of digests?  Big CNAME issue: = search the TLSA record in the
expanded name (after following the = CNAME chain) or not? And what if
expansion is insecure (not signed = with DNSSEC)?

Some details when implementing DANE on Postfix: = don't do TLSA when the
base domain is insecure even if, in theory, = the DANE domain name may
be secure, for instance with DLV). When = Postfix receives a raw public
key, it builds a dummy certificate = around it, to make its TLS library
happy. (See the draft on raw keys = draft-ietf-tls-oob-pubkey, in RFC
editor queue)

Philip = Hallam-Baker mentioned Certificate Transparency but it did not
seem = to raise interest.

Crocker asked for a way for the client to = signal the server which
algorithms it knows, so the server can know = when to drop an algorithm.
Dukhovni disagreed, saying that DANE is = complicated enough.

After a few certificate questions, the DNS = ones : the main discussion
was (Peter Koch) about "fallback" to the = first item in a CNAME chain
when it is insecure. Fallbacks are = brittle and can be dangerous. (It
is the opinion of the minute taker = that "fallback" is not the best
word to describe the algorithm = proposed in the current draft.)

2.2) Using DNS-Based = Authentication of Named Entities (DANE) TLSA
records with SRV and MX = records.
Matt Miller 
ht= tp://www.ietf.org/proceedings/89/slides/slides-89-dane-0.pdf

Ol= le Johansson suggested that SIP has similar issues and that = DANE
people should harmonize with SIP.

Someone suggested = (jokingly, presumes the minute taker) to write a
NAPTR document for = DANE...

A list of XMPP servers using DANE <https://xmpp.net/reports.= php#dnssecdane>

2.3) Harmonizing how applications specify = DANE-like usage
(DANE vocabulary)
Olafur Gudmunsson
http= s://tools.ietf.org/agenda/89/slides/slides-89-dane-4.pdf

Having= a separate document, only with DNS vocabulary since it = seems
under-specified, and varies wildly? This would introduce a = delay. OK
for Paul Hoffman: I have issues such as changing DNSSEC = vocabulary. We
should slow down the drafts, so we can fix = the
vocabulary. Disagreement for Viktor Dukhovni : no delay is wished = for,
the specification is ready.

Paul Hoffman suggested to = public the current drafts, then write the vocabulary
document, then = produce a -bis of the other documents. Taken to the
mailing = list.

2.4) The DANE world model
DANE - key acquisition, = service discovery or usage assurance?
Paul Hoffman
(No = slides)

This was a more philosophical discussion (do note the W3C = has an
explicit Philosophy Working Group
<http://www.w3.org/community= /philoweb/>). Now that DANE is used for
other things than the = Web, we have many questions. Biggest one in the
discussion, "DNS : = delivery or discovery?" It seems there is no
consensus, one of the = reasons being that there is no clear definition
of either.  Many = people do not see the difference (Dave Crocker: no
difference. A = lookup with A is the same as a lookup with SRV).  Some
people = says there is one and that discovery is bad, is not "proper use
of = the DNS". For instance, on XMPP, Andrew Sullivan said "there's = an
ambiguity in 'discovery'.  Some of it is 'discover service at = this
owner name' and some of it is 'find the right owner name for = this
service'.  Most of the DNS anger is directed at (2) because = it
requires tree-climbing."

It is not only philosophical, it = may have security consequence if the
data in the DNS and in TLS = disagree. Also, does it mean we can use
DANE to find out if we are = supposed to connect to the peer with TLS?
Tony Finch: a TLSA record = also means you expect people to use TLS (no
consensus on = that).

Peter Koch said it is neither delivery or discovery, DNS = is lookup,
you need a fixed identifier to starts with. He pointed out = another
ambiguity: domain can mean a subtree or a domain name (a = node).

Andrew Sullivan suggested also to start on a new work = item: "Semiotics
of DNS names from an architechtonic lead user's, = pan-applicationist,
IntraSuperSemioNet, post-modernist perspective" = :-)

For this issue, there was one question by the chairs: do we = need to
document this? The hmmmm clearly says yes and there was = four-five
volunteers to work on it.

2.5) Using DANE to = Associate OpenPGP public keys with email addresses
Paul Wouters
http= s://tools.ietf.org/agenda/89/slides/slides-89-dane-2.pdf

There = is running code on
<http://people.red= hat.com/pwouters/hash-slinger/> (and Github
<https://github.com/letoam= s/hash-slinger>) + a milter for Sendmail = and
Postfix.

Biggest issue in the discussion: the TLSA record = is found at a domain
name which is the user's email address = (actually, a hash of it). Since
the left part of an email address is = case-sensitive (in theory: Paul
Wouters asked if there really was = SMTP servers which care about case
and got not reply), matching is = less trivial thaan it seems ('echo -n
"jAkOb" | openssl sha -sha224' = ?)

Mark Andrews claimed we should define canonicalization rules. = Not
doing so is "lazyness". Paul Hoffman disagrees, canonicalization = is
not easy (internationalized left parts) Taken to the mailing = list.

The two OpenPGP documents are asking for = adoption.
draft-wouters-dane-openpgp and = draft-wouters-dane-openpgpkey-usage
both got a strong = hmmmmmmmmmmm.

2.6) IPSECKEY / Auth_none
Paul Wouters
ht= tp://www.ietf.org/proceedings/89/slides/slides-89-dane-3.pdf

Ju= st information, no decision

2.7) IPSECA
Eric = Osterweill
(slides not = available)

draft-osterweil-dane-ipsec

One of the goals is = harmonize IPsec key learning with DANE. For
instance, IPsec keys are = currently host-specific while DANE keys are
port-specific. Not many = reactions
= --Apple-Mail=_F319A7B4-C784-4CE1-B909-D0923C47FD8D-- From nobody Wed Mar 12 14:13:57 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C17D81A074A; Wed, 12 Mar 2014 14:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.019 X-Spam-Level: * X-Spam-Status: No, score=1.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665, T_TVD_MIME_NO_HEADERS=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPZLHmmq7GAv; Wed, 12 Mar 2014 14:13:49 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 9C75B1A0644; Wed, 12 Mar 2014 14:13:44 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 552012002F; Wed, 12 Mar 2014 18:32:38 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 67DFF647C9; Wed, 12 Mar 2014 17:13:38 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 5585C647C8; Wed, 12 Mar 2014 17:13:38 -0400 (EDT) From: Michael Richardson To: Stephen Farrell In-Reply-To: <5320C932.3010107@cs.tcd.ie> References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <531F8E5F.8030705@isi.edu> <20140312062756.GN11878@anguilla.noreply.org> <3454.1394657237@sandelman.ca> <5320C932.3010107@cs.tcd.ie> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/dane/XDJE4Qru7X36QbR01haZG5M2Qdg Cc: Peter Palfrader , saag , dane@ietf.org Subject: Re: [dane] [saag] Need better opportunistic terminology X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 21:13:50 -0000 --=-=-= Stephen Farrell wrote: > On 03/12/2014 08:47 PM, Michael Richardson wrote: >> The part that we are all discussing is determining how (much) to >> trust the DH results. > I don't think that's a very accurate characterisation > to be honest. > I think the most relevant (but intertwined) factors are: > - trading off ease of deployment vs. endpoint authentication > - trading off protection against passive vs active attack > - better separating key exchange from endpoint authentication > so that traditional authentication or TOFU or whatever can > be used before during or after key exchange But, you made my point. While the end user sees the overall benefit is: my traffic can not seen The problems and challenges that we have are not in how or even when to apply AES, it's how/when to do the DH. To the end user, having the word "encryption" in the terminology is useful because it tells them why they should pay attention to it. To us, it's a red-herring, because it's not where the issue is. You listed the issues. (BTW: my TLA cache is failing on "TOFU") -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting for hire =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCUAwUBUyDOAoqHRg3pndX9AQKH+gP4kbSFq2q+jiLQrr1MMpUul4TI4ZV9GXvl 9FJYBa9k5Ed6VH5QY4iTyRaNQEZU+clr1Hbwrx+BA/4b1aGCgVoe4ktxwytWY2s5 KazF5oqtE39pY4IMaSs5E2ZAbRhF3tpod8mFIxdlC28JpbK2P1tDPlQBvDONcmX+ puX85oH3aQ== =NCbi -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Mar 12 14:47:02 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5491A0685; Wed, 12 Mar 2014 14:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMnFudP965WB; Wed, 12 Mar 2014 14:46:56 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2381A0733; Wed, 12 Mar 2014 14:46:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B4F37BE51; Wed, 12 Mar 2014 21:46:49 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ESecBKXOHD61; Wed, 12 Mar 2014 21:46:48 +0000 (GMT) Received: from [10.87.48.8] (unknown [86.46.16.238]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3BFE6BE29; Wed, 12 Mar 2014 21:46:48 +0000 (GMT) Message-ID: <5320D5C8.8030509@cs.tcd.ie> Date: Wed, 12 Mar 2014 21:46:48 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Michael Richardson References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <531F8E5F.8030705@isi.edu> <20140312062756.GN11878@anguilla.noreply.org> <3454.1394657237@sandelman.ca> <5320C932.3010107@cs.tcd.ie> <10021.1394658818@sandelman.ca> In-Reply-To: <10021.1394658818@sandelman.ca> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/3R0MtNriUUoUKPDyxufRk7xgxM8 Cc: Peter Palfrader , saag , dane@ietf.org Subject: Re: [dane] [saag] Need better opportunistic terminology X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 21:46:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hiya, On 03/12/2014 09:13 PM, Michael Richardson wrote: > > Stephen Farrell wrote: >> On 03/12/2014 08:47 PM, Michael Richardson wrote: >>> The part that we are all discussing is determining how (much) >>> to trust the DH results. > >> I don't think that's a very accurate characterisation to be >> honest. > >> I think the most relevant (but intertwined) factors are: > >> - trading off ease of deployment vs. endpoint authentication - >> trading off protection against passive vs active attack - better >> separating key exchange from endpoint authentication so that >> traditional authentication or TOFU or whatever can be used before >> during or after key exchange > > But, you made my point. Well yes and no, we're agreeing and almost but not quite discussing the same things I figure, let's see if that continues... :-) > While the end user sees the overall benefit is: my traffic can not > seen > > The problems and challenges that we have are not in how or even > when to apply AES, Agreed. > it's how/when to do the DH. "How" to do DH is pretty much the same everywhere or at least the diffs are not relevant for a generic terminology draft. "When" is I think as-soon-as-you-can (modulo amortizing DH over multiple "sessions" or similar). I think our challenges are not in when to do DH but in how that relates to when we might do what forms of endpoint authentication (or none) and the consequences of each of those options. That's why I think a generic terminology draft will be useful, as there are lots of potential combinations. Naming each (or whatever) will make it easier for protocol developers to argue about what's suitable for their particular environments. For example, in the limit, I think it'd be worth thinking about whether a post-facto MITM detection protocol perhaps run a day or two later might have value. That'd be more of a research topic really, but could still represent a form of useful endpoint authentication even if it only detected a MITM with say a 1% probability. Think of Alice and Bob depositing a witness pair derived from the DH secret and some HASH(shared-info + application traffic) some place(s) so someone (else) could detect if there was a Charlie in the middle. (BTW: I'm not sure such a useful generic protocol exists, but it'd be fun to work it out.) > To the end user, having the word "encryption" in the terminology is > useful because it tells them why they should pay attention to it. Good point. Maybe that's why folks keep coming back to OE as a term. > > To us, it's a red-herring, because it's not where the issue is. Also true. Cheers, S. > You listed the issues. > > (BTW: my TLA cache is failing on "TOFU") > > -- Michael Richardson , Sandelman Software > Works -= IPv6 IoT consulting for hire =- > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQEcBAEBAgAGBQJTINXHAAoJEC88hzaAX42iuwsH/jG+Iny/Ae5cEJblR09CD9CE oPhLIMQM6eFBHiFFkz185XilNgyCUuWlAsGSEAMxNybKwZmpChf52ljhEXgE7Vx8 ULDHW8NadWp6O6V2CXie4vQM3ZAW58sgGRCqtejja3R2+DrKxgqi5gnWNxOYLt45 fzXjZYwZ1njlKPV1iLkAwrhLMj8HYOd005CNwW4owL746SV95AroZU316VfVVvB/ ehoLCHINcFJ32mFoPynPQwY/oSL89UWhSzswnkNljSC1R9dYs+eX/mEkBgFC/0Am EptcQZ0IwS5nBf4IwWi9V2wD+phS9zMAcOhpT7oJPzguZhChF/ziVH0NwYGsibg= =32vZ -----END PGP SIGNATURE----- From nobody Wed Mar 12 14:47:22 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E96B1A0772; Wed, 12 Mar 2014 14:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgEEKg7o1l0g; Wed, 12 Mar 2014 14:47:16 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2855C1A0479; Wed, 12 Mar 2014 14:47:16 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:49606 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WNqzV-000IhX-HF; Wed, 12 Mar 2014 17:47:09 -0400 Message-ID: <5320D5DD.8060204@bbn.com> Date: Wed, 12 Mar 2014 17:47:09 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Joe Touch , dane@ietf.org, saag References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <53206293.8020907@bbn.com> <5320900C.2030007@isi.edu> In-Reply-To: <5320900C.2030007@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/ytb5-MW_oJ9NSrTOBQiXUC9SeOs Subject: Re: [dane] [saag] Need better opportunistic terminology X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 21:47:19 -0000 Joe, > >> yeah, I like OK (and I like IKE too, for those of us old enough to >> appreciate that election slogan) > > I'm still a little hesitant, thinking on it further, about the term > "opportunistic" in this sense at all. > > BTNS uses unsigned key exchanged, and there's nothing "opportunistic" > about it. Unsigned authentication is the goal from the start. > > OE as defined in RFC 4322 isn't about using unsigned key exchange; the > "opportunistic" sense is derived from using keys retrieved from DNS > without prior agreement. That's not what happens in BTNS. agreed. > Paul just noted: > "Opportunistic keying does provide authentication, it's just that > the authentication is only to the public key and is not > tightly bound to any other type of identification (address, name, etc.)" Public keys are not principles. We went through that long and painful discussion during the SPKI days. So, saying that OE provide authentication of a key seems meaningless to me, especially if the key is ephemeral. > I.e., fundamentally, opportunistic approaches are completely different > from those that don't ever bother to authenticate. I don't think it's > useful (and could be confusing) to confuse the two by overlapping > terminology. We'll, we don't have an agreed upon definition for O* yet. My view is that the primary goal of this effort is to remove barriers to using encryption. Since authenticating the identity or a peer or server has tended to be a barrier, we seem willing to make that form of authentication optional. But, we still prefer authentication, because we'd like to avoid MiTM attacks. That suggests that O* refers to techniques that emphasize encryption, prefer that it be authenticated, but are willing to fall back to un-autnenticated encryption if that's thbe best we can do. (And to fall back to plaintext if the peer/server is not capable of our new-fangled O*) > I don't like the term "optimistic" either; it too implies something > that you "hope works". There's no "hope" associated with unsigned key > exchange; you do it (IMO) because you know what it is and you know its > impact (e.g., raising the bar of an attacker to performing a full key > exchange, vs. just tossing single packets like RSTs around). I'm not wedded top either term, but I'd like to emphasize that the encryption process is the same in all cases; it's the key management that's different. > > Is there a reason not to just call unauthenticated key exchange what > it is - unauthenticated key exchange? I think we want more than that, as I described above, hence the desire to coin a new term. Steve From nobody Wed Mar 12 14:56:29 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 836571A074C; Wed, 12 Mar 2014 14:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HeLSBhujBNh0; Wed, 12 Mar 2014 14:56:25 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 090471A0744; Wed, 12 Mar 2014 14:56:25 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:49659 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WNr8D-000Ir4-CA; Wed, 12 Mar 2014 17:56:09 -0400 Message-ID: <5320D7F9.6090504@bbn.com> Date: Wed, 12 Mar 2014 17:56:09 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Stephen Farrell , Joe Touch , dane@ietf.org, saag References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <53206293.8020907@bbn.com> <5320900C.2030007@isi.edu> <53209382.3070809@cs.tcd.ie> In-Reply-To: <53209382.3070809@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/2baJqq-5tS-BC_YiK6bsg3Cgre8 Subject: Re: [dane] [saag] Need better opportunistic terminology X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 21:56:26 -0000 Stephen, > (again, I'd suggest one list for this if we can and the > UTA wg list, but hopefully that'll settle down when there's > an I-D, and since I'm not the boss of us anyway...:-) > This is a broader topic than TLS, as later messages from Joe indicated, so I don't think UTA is the right place for this discussion. Steve From nobody Wed Mar 12 15:00:15 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E957F1A074C; Wed, 12 Mar 2014 15:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHmrHYk6FG25; Wed, 12 Mar 2014 15:00:11 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 74E531A0795; Wed, 12 Mar 2014 15:00:11 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s2CLxYS9009943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 12 Mar 2014 14:59:37 -0700 (PDT) Message-ID: <5320D8C6.5070609@isi.edu> Date: Wed, 12 Mar 2014 14:59:34 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Stephen Kent , dane@ietf.org, saag References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <53206293.8020907@bbn.com> <5320900C.2030007@isi.edu> <5320D5DD.8060204@bbn.com> In-Reply-To: <5320D5DD.8060204@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/dane/7RiK4oIMKnvGUWDfKBnPTdQkOKs Subject: Re: [dane] [saag] Need better opportunistic terminology X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 22:00:14 -0000 Steve (et al.), On 3/12/2014 2:47 PM, Stephen Kent wrote: ... >> Is there a reason not to just call unauthenticated key exchange what >> it is - unauthenticated key exchange? > I think we want more than that, as I described above, hence the desire > to coin a new term. No disagreement; there seems to be a need then for two terms: 1. unauthenticated key exchange/use 2. security that uses authentication when available, but allows unauthenticated methods as a backup Personally, I'd call the first "zero-ID" (yes, FWIW, the similarity to 'zero-touch' was intentional), and the second "zero-ID fallback". I'm not wed to either term, but "opportunistic" doesn't seem useful because OE seems to me a lot more like "use this key and hope it works", which isn't part of either case above. Joe From nobody Wed Mar 12 17:38:05 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B1541A07C6; Wed, 12 Mar 2014 17:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FwiQ3XW3pyFr; Wed, 12 Mar 2014 17:37:59 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id C69511A07A6; Wed, 12 Mar 2014 17:37:58 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 470C92AADF5; Thu, 13 Mar 2014 00:37:52 +0000 (UTC) Date: Thu, 13 Mar 2014 00:37:52 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140313003752.GF21390@mournblade.imrryr.org> References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <53206293.8020907@bbn.com> <5320900C.2030007@isi.edu> <5320D5DD.8060204@bbn.com> <5320D8C6.5070609@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5320D8C6.5070609@isi.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/Vrj7CixTkgJb4PGVd64laahDOeM Cc: saag@ietf.org Subject: Re: [dane] [saag] Need better opportunistic terminology X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 00:38:02 -0000 On Wed, Mar 12, 2014 at 02:59:34PM -0700, Joe Touch wrote: [ It seems the discussion has moved on beyond the specifics of the title of the SMTP with DANE draft: "SMTP security via opportunistic DANE TLS". So if anyone has a considered proposal for a better name, please start a new thread on the DANE list only, or just send me your suggestions off-list. ] > No disagreement; there seems to be a need then for two terms: > > 1. unauthenticated key exchange/use > > 2. security that uses authentication when available, > but allows unauthenticated methods as a backup Moving beyond the SMTP with DANE use-case, the space for SMTP alone is definitely larger than just two cases. For example, with email, we have: 0. Opportunistic TLS. http://www.postfix.org/TLS_README.html#client_tls_may What's opportunistic here is not the key management (long-term keys are not used or ignored), but the *use* of TLS. If the server EHLO response includes STARTTLS, TLS is attempted, otherwise not. 1. Mandatory unauthenticated TLS (similar to 1. above). http://www.postfix.org/TLS_README.html#client_tls_encrypt Use of TLS is not opportunistic, the transmission channel is always encrypted. However as with "0." there is no authentication. 2. Opportunistic use of authenticated TLS (e.g. via DANE) with fallback to "0." when the destination authentication policy is not available. http://www.postfix.org/TLS_README.html#client_tls_dane (with the "dane" security level) Here when "usable" secure TLSA records are published, the server is always authenticated. But otherwise, we do our best to at least not send in the clear. 3. Mandatory authentication: http://www.postfix.org/TLS_README.html#client_tls_fprint http://www.postfix.org/TLS_README.html#client_tls_secure http://www.postfix.org/TLS_README.html#client_tls_dane (with the "dane-only" security level) Similar to HTTPS, but no user to click OK, so deployment is limited to small set of administrator designated destinations. 4. Audit-only authentication (on the drawing board for Postfix): An attempt is made to authenticate the peer with the administrator selected policy (2 when destination policy is known or one of static policies in 3). Authentication results are logged, but mail delivery proceeds even when authentication fails. The failure mode can be configured to either "0." or "1." There are of course additional models (TOFU, Tack, ...) So perhaps a small list of terms (nouns or noun-phrases) will not cover all the models in a generic way. We can however provide some guidance on the appropriate use of some popular "adjectives", to encourage people to use them in a more appropriate, consistent fashion. My contention is, for example, that the use of "opportunistic" in "opportunistic TLS" to describe TLS in case "0" is a proper use of that adjective. Similarly "opportunistic DANE TLS" for case "2" is also reasonable. By way of contrast one might speak of "mandatory TLS", "mandatory DANE TLS", ... Finally, the terminology is the least of our worries, lets get more of the security protocols deployed! -- Viktor. From nobody Wed Mar 12 19:27:59 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A962F1A0882; Wed, 12 Mar 2014 19:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FTpLbpb_UiNb; Wed, 12 Mar 2014 19:27:56 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 9E75D1A0877; Wed, 12 Mar 2014 19:27:53 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id hr17so242542lab.5 for ; Wed, 12 Mar 2014 19:27:46 -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=pWSJJjYuWwwJX8IfEfzo1Cgx/nTk/z7byCap2ZmkXGQ=; b=bQXCbul620IGbGdw7DzKk3mJhli4/hX73QTbLcdSgRYVCH3skBuI13p+Ath0/HmYLW 5QfJm9E8J27yo8i7+Wt4Oa6nV556f/c4F20tXHLXKFCgRVI4614EXdvo+OjFEp7sSTxp a0dxoVwm81vigRQifpFdTiU9Y59FeFKwIbEqR/6fiAn18//Zn6+WweabOBv0uwd0XDMG NS388I6iWhOE9t9daVZ9eaonZJmfBTKMUBr/zS2efeILP66okY3ap2laM97GDsWgq53S wXRqoqF4EJzjo985gTelxxErYYT/WfqxDv4hGq2YTBiHSRaGzwkNOS6sxMe8yCXHsZnm ddRA== MIME-Version: 1.0 X-Received: by 10.112.129.168 with SMTP id nx8mr43388lbb.37.1394677666493; Wed, 12 Mar 2014 19:27:46 -0700 (PDT) Received: by 10.112.234.229 with HTTP; Wed, 12 Mar 2014 19:27:46 -0700 (PDT) In-Reply-To: <5320D5C8.8030509@cs.tcd.ie> References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <531F8E5F.8030705@isi.edu> <20140312062756.GN11878@anguilla.noreply.org> <3454.1394657237@sandelman.ca> <5320C932.3010107@cs.tcd.ie> <10021.1394658818@sandelman.ca> <5320D5C8.8030509@cs.tcd.ie> Date: Wed, 12 Mar 2014 22:27:46 -0400 Message-ID: From: Phillip Hallam-Baker To: Stephen Farrell Content-Type: multipart/alternative; boundary=047d7b343d68e33ab304f473b2e0 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/BJmmbfINBlzn8XjVQBJeJGrTlDc Cc: Peter Palfrader , Michael Richardson , saag , "dane@ietf.org" Subject: Re: [dane] [saag] Need better opportunistic terminology X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 02:27:57 -0000 --047d7b343d68e33ab304f473b2e0 Content-Type: text/plain; charset=ISO-8859-1 I don't particularly mind what the definition is, provided I can know what the speaker means by it. Which right now I don't. I am quite happy if we defer the definition of what OE is until we have decided what to do and then decide that that is OE by definition. Some terms that come to mind for encryption using credentials that are not authenticated: Faith-Based Encryption Passive Protection Junk Encryption (cf Junk bonds which are worth a lot more than zero but a lot less than par) --047d7b343d68e33ab304f473b2e0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I don't particularly mind w= hat the definition is, provided I can know what the speaker means by it. Wh= ich right now I don't. I am quite happy if we defer the definition of w= hat OE is until we have decided what to do and then decide that that is OE = by definition.


<= /div>
Some terms that come to mind for encryption= using credentials that are not authenticated:

Faith-Based Encryption
Passive Protection
Junk En= cryption (cf Junk bonds which are worth a lot more than zero but a lot less= than par)


<= div class=3D"gmail_extra">
--047d7b343d68e33ab304f473b2e0-- From nobody Wed Mar 12 19:33:07 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF7381A04D2; Wed, 12 Mar 2014 13:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.289 X-Spam-Level: X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w_FwRX4bBfvu; Wed, 12 Mar 2014 13:02:39 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by ietfa.amsl.com (Postfix) with ESMTP id BCCFC1A0473; Wed, 12 Mar 2014 13:02:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 19575E2034; Wed, 12 Mar 2014 16:02:33 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 06205-01; Wed, 12 Mar 2014 16:02:31 -0400 (EDT) Received: from mocana.ihtfp.org (unknown [IPv6:fe80::224:d7ff:fee7:8924]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 76518E2033; Wed, 12 Mar 2014 16:02:31 -0400 (EDT) Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.7/8.14.7/Submit) id s2CK2UYt016022; Wed, 12 Mar 2014 16:02:30 -0400 From: Derek Atkins To: Joe Touch References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <531F8E5F.8030705@isi.edu> Date: Wed, 12 Mar 2014 16:02:29 -0400 In-Reply-To: <531F8E5F.8030705@isi.edu> (Joe Touch's message of "Tue, 11 Mar 2014 15:29:51 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: http://mailarchive.ietf.org/arch/msg/dane/xVCja2uOUjX06jqzPnPOWgZ-iyc X-Mailman-Approved-At: Wed, 12 Mar 2014 19:33:00 -0700 Cc: saag , dane@ietf.org Subject: Re: [dane] [saag] Need better opportunistic terminology X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 20:02:41 -0000 Joe Touch writes: > Why not just use the term "unauthenticated encryption", when that's > exactly what's happening? Well, it's not necessarily what's happening. The data itself might still have "integrity protection" (which is a form of authentication. You're just not authenticating the endpoint, which means you could be subject to a MitM attack. Alternate terms could be "Unauthenticated Keying" or "Unauthenticated Key Exchange" which are closer (IMHO) to what's going on. > Joe -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Wed Mar 12 19:33:10 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A94D1A07F5; Wed, 12 Mar 2014 18:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxR7M-y79DxS; Wed, 12 Mar 2014 18:14:31 -0700 (PDT) Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) by ietfa.amsl.com (Postfix) with ESMTP id A82C01A07F2; Wed, 12 Mar 2014 18:14:31 -0700 (PDT) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s2D1EMQb027375; Wed, 12 Mar 2014 18:14:22 -0700 Received: from sc-owa03.marvell.com ([199.233.58.149]) by mx0a-0016f401.pphosted.com with ESMTP id 1jhd2xw6h8-5 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 12 Mar 2014 18:14:22 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA03.marvell.com ([fe80::4561:8e1c:d59b:f770%17]) with mapi; Wed, 12 Mar 2014 18:14:20 -0700 From: Paul Lambert To: Stephen Kent , Joe Touch , "dane@ietf.org" , saag Date: Wed, 12 Mar 2014 18:14:18 -0700 Thread-Topic: [saag] [dane] Need better opportunistic terminology Thread-Index: Ac8+WY/O2vqrqseDQwKUvwYbLOprFQ== Message-ID: References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <53206293.8020907@bbn.com> <5320900C.2030007@isi.edu> <5320D5DD.8060204@bbn.com> In-Reply-To: <5320D5DD.8060204@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-03-12_08:2014-03-12,2014-03-12,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1403120167 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/BsTU2eue5niJv3KpZSFrIN-flro X-Mailman-Approved-At: Wed, 12 Mar 2014 19:32:59 -0700 Subject: Re: [dane] [saag] Need better opportunistic terminology X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 01:14:33 -0000 On 3/12/14, 2:47 PM, "Stephen Kent" wrote: >Joe, > > >>> yeah, I like OK (and I like IKE too, for those of us old enough to >>> appreciate that election slogan) >> >> I'm still a little hesitant, thinking on it further, about the term >> "opportunistic" in this sense at all. >> >> BTNS uses unsigned key exchanged, and there's nothing "opportunistic" >> about it. Unsigned authentication is the goal from the start. >> >> OE as defined in RFC 4322 isn't about using unsigned key exchange; the >> "opportunistic" sense is derived from using keys retrieved from DNS >> without prior agreement. That's not what happens in BTNS. >agreed. >> Paul just noted: >> "Opportunistic keying does provide authentication, it's just that >> the authentication is only to the public key and is not >> tightly bound to any other type of identification (address, name, etc.)" >Public keys are not principles. We went through that long and painful >discussion >during the SPKI days. >=20 Your level of pain in a discussion is not a measure of a concepts validity :-)=20 Public keys and the hashes of public keys are the fundamental identifier of a =8Cprincipal=B9 when we are using public key based authentication. The principal is the end user or computer that controls the use of the public key. The public key is authenticated in a key exchange or signature validation process and is the primary connection in the process to the key holder (principal). Other information may be associated with the key locally or through a trusted path (out-of-band, signed, etc.) that can be used for authorization decisions. The other information may even include information associated with the key in a X.509 or other form of certificate. The public key and associated key hash for a principal may change. Changing keys could be viewed as either a new identifier for the same principal or a new principal with the same associated attributes as a previous principal. Either way, the public key (or hash) is a unique identifier of a principal which can then be usefully processed in a security policy. =20 There are several usages of =B3opportunistic=B2 in this thread. Clearly ne= w terms are needed. I=B9m primarily interested in =8Ckeys as identifiers=B9 = where longer term keys are used to identify principals. Security policies are built on hashes of keys and optionally other associated information that may include names, labels, group membership, etc. This may be getting a little far afield of the TLS-DANE or IPsec opportunistic specific usage. Still, the deferred binding and the TOFU model are compatible with a perspective of keys as identifiers of principals. >So, saying that OE provide authentication of a key >seems >meaningless to me, especially if the key is ephemeral. Yes, ephemeral keys do not provide any long term identity. This can also be a feature. A =8Cprincipal identifier=B9 with no associated information would only be authorized for actions that have no restrictions on specific principals. =20 Paul >> I.e., fundamentally, opportunistic approaches are completely different >> from those that don't ever bother to authenticate. I don't think it's >> useful (and could be confusing) to confuse the two by overlapping >> terminology. >We'll, we don't have an agreed upon definition for O* yet. My view is >that the primary goal of >this effort is to remove barriers to using encryption. Since >authenticating the identity or a >peer or server has tended to be a barrier, we seem willing to make that >form of authentication >optional. But, we still prefer authentication, because we'd like to >avoid MiTM attacks. That suggests >that O* refers to techniques that emphasize encryption, prefer that it >be authenticated, but are >willing to fall back to un-autnenticated encryption if that's thbe best >we can do. (And to fall back >to plaintext if the peer/server is not capable of our new-fangled O*) >> I don't like the term "optimistic" either; it too implies something >> that you "hope works". There's no "hope" associated with unsigned key >> exchange; you do it (IMO) because you know what it is and you know its >> impact (e.g., raising the bar of an attacker to performing a full key >> exchange, vs. just tossing single packets like RSTs around). >I'm not wedded top either term, but I'd like to emphasize that the >encryption process is >the same in all cases; it's the key management that's different. >> >> Is there a reason not to just call unauthenticated key exchange what >> it is - unauthenticated key exchange? >I think we want more than that, as I described above, hence the desire >to coin a new term. > >Steve > >_______________________________________________ >saag mailing list >saag@ietf.org >https://www.ietf.org/mailman/listinfo/saag From nobody Wed Mar 12 19:33:12 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2BF31A074A; Wed, 12 Mar 2014 14:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7nmtQdRzngcq; Wed, 12 Mar 2014 14:28:58 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8621A073B; Wed, 12 Mar 2014 14:28:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 388DDE2033; Wed, 12 Mar 2014 17:28:51 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 06529-05; Wed, 12 Mar 2014 17:28:49 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id 1200DE2038; Wed, 12 Mar 2014 17:28:48 -0400 (EDT) Received: from 192.168.248.230 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Wed, 12 Mar 2014 17:28:48 -0400 Message-ID: <2b9139a5b1fe14a683ba11c63830bfdb.squirrel@mail2.ihtfp.org> In-Reply-To: <10021.1394658818@sandelman.ca> References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <531F8E5F.8030705@isi.edu> <20140312062756.GN11878@anguilla.noreply.org> <3454.1394657237@sandelman.ca> <5320C932.3010107@cs.tcd.ie> <10021.1394658818@sandelman.ca> Date: Wed, 12 Mar 2014 17:28:48 -0400 From: "Derek Atkins" To: "Michael Richardson" User-Agent: SquirrelMail/1.4.22-13.fc20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: http://mailarchive.ietf.org/arch/msg/dane/h5QxaTRTLvTqqkemMagQySmQSXY X-Mailman-Approved-At: Wed, 12 Mar 2014 19:33:00 -0700 Cc: Peter Palfrader , dane@ietf.org, saag Subject: Re: [dane] [saag] Need better opportunistic terminology X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 21:29:00 -0000 On Wed, March 12, 2014 5:13 pm, Michael Richardson wrote: > > (BTW: my TLA cache is failing on "TOFU") Trust on First Use (aka the SSH Model). A step up from completely unchecked DH, but a step below DANE or Certificate Validation. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Wed Mar 12 19:33:14 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2C51A0764; Wed, 12 Mar 2014 14:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzjoB-ArRdX4; Wed, 12 Mar 2014 14:59:08 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 54F311A0758; Wed, 12 Mar 2014 14:59:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A84F4BE4D; Wed, 12 Mar 2014 21:59:01 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zG1eRjoJ2xhr; Wed, 12 Mar 2014 21:59:00 +0000 (GMT) Received: from [10.87.48.8] (unknown [86.46.16.238]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7CF43BE29; Wed, 12 Mar 2014 21:59:00 +0000 (GMT) Message-ID: <5320D8A4.1000709@cs.tcd.ie> Date: Wed, 12 Mar 2014 21:59:00 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Stephen Kent , Joe Touch , saag References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <53206293.8020907@bbn.com> <5320900C.2030007@isi.edu> <53209382.3070809@cs.tcd.ie> <5320D7F9.6090504@bbn.com> In-Reply-To: <5320D7F9.6090504@bbn.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/YwNe4ibYBFhKRGZgdQgg-pGbK3s X-Mailman-Approved-At: Wed, 12 Mar 2014 19:33:01 -0700 Subject: Re: [dane] [saag] Need better opportunistic terminology X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 21:59:09 -0000 Sure, that's arguable. My main reason for suggesting UTA is that I figure its drafts will have more/soonest dependencies on the terminology draft. However, if folk prefer saag, for now at least that's fine. But let's drop the cross-posting to dane then please? (Which I bcc'd) S. On 03/12/2014 09:56 PM, Stephen Kent wrote: > Stephen, > >> (again, I'd suggest one list for this if we can and the >> UTA wg list, but hopefully that'll settle down when there's >> an I-D, and since I'm not the boss of us anyway...:-) >> > This is a broader topic than TLS, as later messages from Joe indicated, so > I don't think UTA is the right place for this discussion. > > Steve > > From nobody Wed Mar 12 19:33:17 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4B331A07D8; Wed, 12 Mar 2014 17:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id av7fcrBUH3nu; Wed, 12 Mar 2014 17:48:57 -0700 (PDT) Received: from hapkido.dreamhost.com (hapkido.dreamhost.com [66.33.216.122]) by ietfa.amsl.com (Postfix) with ESMTP id 558251A07CC; Wed, 12 Mar 2014 17:48:57 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (unknown [69.163.253.160]) by hapkido.dreamhost.com (Postfix) with ESMTP id 42871388DD; Wed, 12 Mar 2014 17:48:51 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id F2F1521DE71; Wed, 12 Mar 2014 17:48:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=07a0pJsed6fh5W2x33GT Iza+PWM=; b=gVlFYG5f/bOXn9SGWIU9lRWhvNm5iqQoS88ONsMrtJJKuZFfkpb/ 7kkrHPPW4d1dqsuJuJ1hGJKfIMDERIWHVPkVDDDUk91DPROFilJ1i+JeQqDd97Uc EDPdFNJhW5BN0PCuatTM0Y8oP8B3usH0WzWIFsT1Knx/73P+06aQfjo= Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPSA id 744BA21DE57; Wed, 12 Mar 2014 17:48:50 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id a1so235336wgh.8 for ; Wed, 12 Mar 2014 17:48:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CZN60Buzgeu0LyEe2I2tfbVpeqH8o/IhSLFM7WGoE/k=; b=BNFm4Ec5/beZqHkzTHDeLMovNK/qCV4qXBBPvbUwx+Lc30/eVvWDlmu2xlWzbv4K4I 2mX2NlbU3XmHE4gPt0NIIXDWU3E41GbGme/T/4XqtdzlSWmxTjV30SgIjPi0qHq1YRhs PUciWOlqi5PwN1S+PQQqD6g/xish7EPRFLvTUDlulbTLJToOQMR1ACO5kD4GKwXrVuf7 HS3uTIBKFz7Jz9b/KwZONFxRZO4olDAegVLp5BdY3ws5iw4D5GBZ/4xP3lFX0awMqiud XbJtEgGP2bFoI51Q9pakHkK98vvxvkcR+Qp0Qm7CU3MN0FMQJiFw8ItHBsw5teDIBNS2 /ndA== MIME-Version: 1.0 X-Received: by 10.180.36.8 with SMTP id m8mr856967wij.42.1394671726700; Wed, 12 Mar 2014 17:48:46 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Wed, 12 Mar 2014 17:48:46 -0700 (PDT) In-Reply-To: <20140313003752.GF21390@mournblade.imrryr.org> References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <53206293.8020907@bbn.com> <5320900C.2030007@isi.edu> <5320D5DD.8060204@bbn.com> <5320D8C6.5070609@isi.edu> <20140313003752.GF21390@mournblade.imrryr.org> Date: Wed, 12 Mar 2014 19:48:46 -0500 Message-ID: From: Nico Williams To: dane@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/xbxep8KvB7y72ifJQ4KNmoPcuu4 X-Mailman-Approved-At: Wed, 12 Mar 2014 19:32:59 -0700 Cc: "saag@ietf.org" Subject: Re: [dane] [saag] Need better opportunistic terminology X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 00:48:58 -0000 On Wed, Mar 12, 2014 at 7:37 PM, Viktor Dukhovni wrote: > On Wed, Mar 12, 2014 at 02:59:34PM -0700, Joe Touch wrote: > > [ It seems the discussion has moved on beyond the specifics of the title of > the SMTP with DANE draft: "SMTP security via opportunistic DANE TLS". So > if anyone has a considered proposal for a better name, please start a new > thread on the DANE list only, or just send me your suggestions off-list. ] It has moved beyond SMTP w/ DANE because we actually need general terminology for some of these behaviors. > 2. Opportunistic use of authenticated TLS (e.g. via DANE) with > fallback to "0." when the destination authentication policy > is not available. > > http://www.postfix.org/TLS_README.html#client_tls_dane > (with the "dane" security level) > > Here when "usable" secure TLSA records are published, > the server is always authenticated. But otherwise, we > do our best to at least not send in the clear. Right, we should distinguish "authenticate with TLS server PKI" from authenticate via DANE". > So perhaps a small list of terms (nouns or noun-phrases) will not > cover all the models in a generic way. We can however provide some > guidance on the appropriate use of some popular "adjectives", to > encourage people to use them in a more appropriate, consistent > fashion. > > My contention is, for example, that the use of "opportunistic" in > "opportunistic TLS" to describe TLS in case "0" is a proper use of > that adjective. Similarly "opportunistic DANE TLS" for case "2" > is also reasonable. By way of contrast one might speak of "mandatory > TLS", "mandatory DANE TLS", ... No argument from me. You're right too that we're going to compose two or more words. > Finally, the terminology is the least of our worries, lets get more > of the security protocols deployed! Well, you'd be surprised. Terminology makes a huge difference 'round these here parts. In this particular space we have a chance to define generic terms because a lot of the behaviors in question are new(ish). Sounds like a huge win to me! Nico -- From nobody Thu Mar 13 00:59:26 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 353321A094F; Thu, 13 Mar 2014 00:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHR9EsNpaNBL; Thu, 13 Mar 2014 00:59:22 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id C6F4B1A094E; Thu, 13 Mar 2014 00:59:21 -0700 (PDT) Received: from [192.168.40.13] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 6195793C2A2; Thu, 13 Mar 2014 07:59:13 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: "Olle E. Johansson" In-Reply-To: Date: Thu, 13 Mar 2014 08:59:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <531F8E5F.8030705@isi.edu> To: Derek Atkins X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/H6SoTuEIwEAE-py9Cr7R47Qv900 Cc: dane@ietf.org, saag , Joe Touch Subject: Re: [dane] [saag] Need better opportunistic terminology X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 07:59:24 -0000 On 12 Mar 2014, at 21:02, Derek Atkins wrote: > Joe Touch writes: >=20 >> Why not just use the term "unauthenticated encryption", when that's >> exactly what's happening? >=20 > Well, it's not necessarily what's happening. The data itself might > still have "integrity protection" (which is a form of authentication. > You're just not authenticating the endpoint, which means you could be > subject to a MitM attack. Alternate terms could be "Unauthenticated > Keying" or "Unauthenticated Key Exchange" which are closer (IMHO) to > what's going on. To get any movement in this area among developers and sysadmins,=20 we need a language that any sysadmin or developer understands.=20 I believe we can easily get them to understand "Opportunistic = encryption" but if we go into explaining "keying" or "key exchange" they will be = lost in=20 the OpenSSL documentation maze again. We might have to separate a "marketing name" of the overall concept from a set of technical definitions we can refer to when explaining this = in RFCs. For me, I can happily accept using OE as the unclear marketing bullshit term for a set of solutions that set up an encrypted = communication channel - regardless of URI or configuration, without any indication to the user in the phone UI or browser UI - no locks! I can understand that this may be hard to accept in a technical = community, but we have a huge educational effort ahead of us in order to get this done. The general concept has to be easy to explain. In summary, I propose that we keep OE as the overall term and define a set of more precise terminology to explain what goes on in the = background. As Victor pointed out, there may be different solutions in different protocols. As a side note: https://tools.ietf.org/html/rfc5630 Use the term "best-effort TLS" to describe that a SIP ua is perfectly allowed to set up a TLS session based on policy regardless if there is a "sips:" URI. I don't know where that terminalogy came from. It's always used with quotation marks in the RFC. This "best-effort TLS" still requires verification of the certificate though. Cheers /O From nobody Thu Mar 13 05:49:00 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDB501A081D; Thu, 13 Mar 2014 05:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hs9WN0-K1-ZU; Thu, 13 Mar 2014 05:48:53 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51-v6.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f51]) by ietfa.amsl.com (Postfix) with ESMTP id DD0321A0848; Thu, 13 Mar 2014 05:48:52 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:42109) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1WO541-0005mr-WU (Exim 4.82_3-c0e5623) (return-path ); Thu, 13 Mar 2014 12:48:45 +0000 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1WO541-0007cE-0E (Exim 4.72) (return-path ); Thu, 13 Mar 2014 12:48:45 +0000 Date: Thu, 13 Mar 2014 12:48:45 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: dane@ietf.org In-Reply-To: <20140313003752.GF21390@mournblade.imrryr.org> Message-ID: References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <53206293.8020907@bbn.com> <5320900C.2030007@isi.edu> <5320D5DD.8060204@bbn.com> <5320D8C6.5070609@isi.edu> <20140313003752.GF21390@mournblade.imrryr.org> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Archived-At: http://mailarchive.ietf.org/arch/msg/dane/0d7vrygC_jbhit8NvTdGq33hhpg Cc: saag@ietf.org Subject: Re: [dane] [saag] Need better opportunistic terminology X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 12:48:56 -0000 Viktor Dukhovni wrote: > > My contention is, for example, that the use of "opportunistic" in > "opportunistic TLS" to describe TLS in case "0" is a proper use of > that adjective. I think a better phrase would be "negotiated unauthenticated TLS". (Or "unauthenticated STARTTLS" since STARTTLS implies negotiated TLS). "Opportunistic" implies that someone is taking advantage of someone else to their detriment, whereas SMTP TLS is by mutual agreement. > Similarly "opportunistic DANE TLS" for case "2" is also reasonable. By > way of contrast one might speak of "mandatory TLS", "mandatory DANE > TLS", ... The mandatory cases are where the postmaster has overridden normal protocol negotiation, which implies that they should get a weirder name than the normal negotiated cases. Postfix's use of "opportunistic" is a bit weird. Sendmail and Exim do not use the term, though Microsoft Exchange does. Tony. -- f.anthony.n.finch http://dotat.at/ Shannon: South or southeast 3 or 4, veering southwest 4 or 5 later. Moderate or rough. Fair. Moderate or good. From nobody Thu Mar 13 08:11:19 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D02C1A0A14; Thu, 13 Mar 2014 08:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zH1uCCFszHnX; Thu, 13 Mar 2014 08:11:08 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 521261A0A13; Thu, 13 Mar 2014 08:11:07 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s2DF8PQN028390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 13 Mar 2014 08:08:35 -0700 (PDT) Message-ID: <5321C9EC.8010403@isi.edu> Date: Thu, 13 Mar 2014 08:08:28 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Olle E. Johansson" , Derek Atkins References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <531F8E5F.8030705@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/dane/Tup3tMVq9PkIkH7rDLKkwuySjAM Cc: saag , dane@ietf.org Subject: Re: [dane] [saag] Need better opportunistic terminology X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 15:11:10 -0000 On 3/13/2014 12:59 AM, Olle E. Johansson wrote: > > On 12 Mar 2014, at 21:02, Derek Atkins wrote: > >> Joe Touch writes: >> >>> Why not just use the term "unauthenticated encryption", when that's >>> exactly what's happening? >> >> Well, it's not necessarily what's happening. The data itself might >> still have "integrity protection" (which is a form of authentication. >> You're just not authenticating the endpoint, which means you could be >> subject to a MitM attack. Alternate terms could be "Unauthenticated >> Keying" or "Unauthenticated Key Exchange" which are closer (IMHO) to >> what's going on. > > To get any movement in this area among developers and sysadmins, > we need a language that any sysadmin or developer understands. > I believe we can easily get them to understand "Opportunistic encryption" > but if we go into explaining "keying" or "key exchange" they will be lost in > the OpenSSL documentation maze again. The problem is that OE isn't what's going on when you simply choose not to authenticate keys. Yes, it's a simple term, but it's also an incorrect one. I appreciate the desire to find a cute marketing term, which is why I offered "zero-ID" - which is more accurate and easier to explain to developers and sysadmins (what do you *do* to make OE? it's easy to make zero-ID - you stop using IDs). I'm not wed to that term, but market-speak is your metric, OE fails on multiple counts. > As a side note: > > https://tools.ietf.org/html/rfc5630 > > Use the term "best-effort TLS" to describe that a SIP ua is perfectly > allowed to set up a TLS session based on policy regardless if there > is a "sips:" URI. I don't know where that terminalogy came from. It's > always used with quotation marks in the RFC. This "best-effort TLS" > still requires verification of the certificate though. That's similar reasoning as to why I don't like OE. Joe From nobody Thu Mar 13 19:02:48 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 790061A081E for ; Thu, 13 Mar 2014 19:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XL6CHxjk7Qvt for ; Thu, 13 Mar 2014 19:02:45 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3D51A0813 for ; Thu, 13 Mar 2014 19:02:44 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 9BEC82AB13B; Fri, 14 Mar 2014 02:02:36 +0000 (UTC) Date: Fri, 14 Mar 2014 02:02:36 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140314020236.GP21390@mournblade.imrryr.org> References: <3D074047-A9FC-4C90-A819-76552A99EE27@ogud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D074047-A9FC-4C90-A819-76552A99EE27@ogud.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/G24aRGlxzwbpHoowM34LA1Tfw30 Subject: Re: [dane] IETF-89 draft minutes X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 02:02:47 -0000 On Wed, Mar 12, 2014 at 04:58:54PM -0400, Olafur Gudmundsson wrote: [ Comments clarifying the minutes, I'll open separate threads to discuss each issue. ] > 2.1) DANE SMTP by Viktor Dukhovni (Postfix) And Wes Hardaker, though I got to present this time, the drafts (and slides) are joint work. > Viktor reported a *lot* of open issues, discovered by the development > of DANE-for-SMTP but often not-SMTP specifics. Some examples: if DANE > publishes a full certificate, should we use only the public key in it > or also check the other fields of the certificate? The phrasing above is a bit misleading. More accurate: * With DANE-TA(2) and DANE-EE(3), should the content of the matching trust anchor or end-entity certificate be used in validating the server chain, beyond the extent necessary to match it with the TLSA record (either exact comparison of DER encoding with matching type 0, or comparison of the digest of the certificate or SPKI. - Does this depend on whether the selector is Cert(0) or SPKI(1)? * With DANE-EE(3), whether we ignore the rest of the certificate or not, at the very least the client MUST NOT enforce name checks or expiration, which are handled via DNSSEC. > Many combination of options in DANE are strange and may be useless > and require explanations anyway. I think what I actually said that is vaguely along these lines is: * What does "IN TLSA DANE-TA(2) SPKI(1) Full(0)" mean? Are clients expected to be able to perform validation with "bare" keys (when the TLS server's chain does not contain a matching certificate, but rather contains only a certificate signed with said key). * Later I suggested that applications should typically support only one of the pairs of the usage pairs: {(DANE-TA, DANE-EE), (PKIX-TA, PKIX-EE)}. Supporting both gives you the intersection of the security properties and the union of the interoperability issues (i.e. generally a bad idea). > What if some keys are published with a different > set of digests? * There has been little discussion of digest algorithm agility. Given the new BCP for protocol authors, it is clear a spec is needed. * The approach proposed requires server operators to publish TLSA records (when more than one digest algorithm is employed) in a compatible manner. The question was "what to do if they don't"? (Discussion in separate thread). > Big CNAME issue: search the TLSA record in the > expanded name (after following the CNAME chain) or not? And what if > expansion is insecure (not signed with DNSSEC)? The CNAME issue is I think no longer particularly controversial, but people need to read the SMTP and OPS drafts and make sure we're not missing anything. What happens (proposed) when the CNAME chain is insecure is that the origin is the candidate TLSA base domain. Ditto when the chain is secure, but no TLSA records are present there. > Some details when implementing DANE on Postfix: don't do TLSA when the > base domain is insecure even if, in theory, the DANE domain name may > be secure, for instance with DLV). This needs to be done in all protocols where DANE is not mandatory. Otherwise, DNS lookup failure with TLSA RRs will be observed with bare-bones nameservers in dns load balancer and related kit that cuts corners on DNS code. > When Postfix receives a raw public key, it builds a dummy certificate > around it, to make its TLS library happy. (See the draft on raw keys > draft-ietf-tls-oob-pubkey, in RFC editor queue) Right, this is "2 1 0" support, when the peer's chain has no matching cert, just things signed under the key (see above). The group has to decide whether clients are expected to go the extra mile to support this (like in Postfix). > Philip Hallam-Baker mentioned Certificate Transparency but it did not > seem to raise interest. To be fair, I mentioned that CT is specified out of scope for DANE-TA(2) and DANE-EE(3) in the ops draft. Phillip believes that it is possible (and therefore desirable) to support CT in these cases. I contend that it is not possible to apply CT to private CAs and private leaf certs. > Crocker asked for a way for the client to signal the server which > algorithms it knows, so the server can know when to drop an algorithm. > Dukhovni disagreed, saying that DANE is complicated enough. This would have to be done in band in either the application or TLS protocols, even though DANE is an out-of-band DNS policy mechanism. So this would be a DANE-specific TLS extension, that servers would have the option to log in some manner for later analysis. Now in TLSv1.2 clients already send digest names, but they are TLS digests, and need not be the set of digests supported for DANE matching types. I don't see this working cleanly... However such signalling can be specified later, we can hope SHA2-256 will last long enough for most clients to upgrade to the protocol versions in which such signalling is supported. > After a few certificate questions, the DNS ones : the main discussion > was (Peter Koch) about "fallback" to the first item in a CNAME chain > when it is insecure. Fallbacks are brittle and can be dangerous. (It > is the opinion of the minute taker that "fallback" is not the best > word to describe the algorithm proposed in the current draft.) Right, this is not exactly fallback to lower security, rather this is a search for applicable TLSA records in multiple (either one or two) candidate locations. -- Viktor. From nobody Thu Mar 13 22:23:58 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7CE51A0035 for ; Thu, 13 Mar 2014 22:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.871 X-Spam-Level: ** X-Spam-Status: No, score=2.871 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPOOF_COM2COM=2.048, SPOOF_COM2OTH=2.723] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bn9J88Tvnl_Q for ; Thu, 13 Mar 2014 22:23:50 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 90F0C1A002F for ; Thu, 13 Mar 2014 22:23:50 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3EB072AADF5; Fri, 14 Mar 2014 05:23:42 +0000 (UTC) Date: Fri, 14 Mar 2014 05:23:42 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140314052342.GQ21390@mournblade.imrryr.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/B20JRnO1KaEGMvxAt3KxH7Bud9M Subject: Re: [dane] Review of DANE SMTP draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 05:23:53 -0000 On Thu, Mar 06, 2014 at 01:44:17PM +0000, Alexey Melnikov wrote: > In the terminology section: what about no MX record case (A or AAAA only)? Thanks. This was a global replace error. The term used to define "MX Host". All of its occurrences got replaced with "SMTP server", no longer specific to MX hosts of domains, but the terminology is now wrong. I am going to just delete this dangling definition. > In 1.3.1: why mention SMTP URIs? How would introduction of such > URIs help with securing SMTP? I suggest you just mention that there > is no signalling of "secure" SMTP. There are no URIs and none are desired. This is an attempt at a contrast with HTTP, and yes the point is that there is no signalling of HOP by hop security policy in the envelope address (which is more of a feature than a bug). I'm tweaking the text to talk about signalling more explicitly, rather than a hypothetical URI scheme. > In 2.2: Network address instead of MX hostname - I think this > deserves an example. [ Second-last paragraph of 2.2 ] Is it not obvious that this means the misguided: example.com. IN MX 0 192.0.2.1. I am not adding this yet, do others feel this really warrants more text? > In 2.2.3 (page 17, 3rd from the last para): and possibly other places: > TLS server certificate matching rules should be fully specified. Use RFC > 6125 (for example look at draft-melnikov-email-tls-certs-01) or specify > the rules directly. In 6125 (where the exceptions dominate the rules) there are no provisions for matching one of a set of candidate names. So, I guess, we should be more explicit about the wildcard matching (perhaps generically in the SRV draft) and otherwise defer to 6125 for international domain names, Subject commonName vs. subjectAltName:DNS, etc. FWIW Postfix by default (Postini work-around) supports wildcard certificates that match multiple DNS labels: http://www.postfix.org/postconf.5.html#tls_wildcard_matches_multiple_labels The folks at Postini have a wildcard cert for "*.psmtp.com" and clients publish MX records of the form: verisign.com. IN MX 100 verisign.com.s6a1.psmtp.com. verisign.com. IN MX 200 verisign.com.s6a2.psmtp.com. verisign.com. IN MX 300 verisign.com.s6b1.psmtp.com. verisign.com. IN MX 400 verisign.com.s6b2.psmtp.com. I have not given much thought to writing DANE-specific rules for SMTP TLS with respect to the mechanics of matching of any particular candidate name against the certificate. (To be honest, I did not need to write any new code for this, since name matching is handled in Postfix TLS policy generically for DANE and PKIX. The existing PKIX code was already flexible enough to do all the work, so this did not cross my radar). In https://tools.ietf.org/html/rfc6125#appendix-B.4 we have matching with just "*" as a wildcard (no "foo*.example.com" or "*foo.example.com") and only for a single label. While SMTP-AUTH forbids chasing CNAMEs insecurely, it only works well for MSA hosts, not MX hosts which already lose after insecure MX delegation. With DANE we have a secure TLSA base domain, so this does not apply. I don't know whether the Postfix (on by default) Postini work-around deserves IETF blessing. Perhaps it would be better for Postini to fix their certificates, or if they ever deploy DANE to publish only DANE-EE(3) certs, which make the question moot. I don't know whether any other sites are attempting to use SMTP with wildcard certs for multi-label sub-domains. There is not enough authenticated TLS happening for SMTP today to know what's out there in the wild. > Page 22, 3rd para: please add reference for the SNI TLS extension (a > Normative reference, because you use normative language when referencing > the extension) and various versions of TLS. RFC 6066 is referenced on page 6 (second last paragraph) and appears in the References section. Should the reference be repeated on page 22? > In 2.3.3: it is not clear whether the client needs to check that for every > record covered by the WORSE hash there is a corresponding record covered > by the BETTER hash. This is not possible. The records don't carry separate "instance" identifiers that allow one to identify all the TLSA records of a single certificate or public key. The various digest algorithms are not invertible! All that the client can check is that the number of records for the best algorithm is the same as that for all other algorithms within each combination of usage and selector. We may need a separate thread on pinning down algorithm agility (unless it is good enough as-is, perhaps with clarifications if the intent is not completely clear). > In Section 3, last para: add "or bounced", as this can be more serious > than just being delayed. Fine. > In 4.2, last para: did you mean "SHOULD"? Perhaps so, though this may hold up publication of the SMTP draft until the "ops" draft is also done. We could cut/paste the relevant text, or move it to the more generic SRV draft. Ultimately, there is a real need for DANEbis, but it looks like it won't move forward until there are more published and deployed protocols, so we'll all be parroting the "missing" text in multiple drafts, or perhaps the normative text from "ops" can be published as a standards track "clarifications" to 6698? Any suggestions from the chairs? > I've heard Not checking expiration dates in certificate - I don't think > this was mentioned in the document. This is in the "ops" draft, but I'll add it to the description in the SMTP draft, after we figure out exactly what should be ignored in DANE-EE(3) certs (and possibly DANE-TA(2) SPKI(1) trust anchor certs). (Separate thread on this soon). -- Viktor. From nobody Fri Mar 14 10:15:00 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A0521A018B for ; Fri, 14 Mar 2014 10:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.223 X-Spam-Level: ** X-Spam-Status: No, score=2.223 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, SPOOF_COM2COM=2.048, SPOOF_COM2OTH=2.723] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCF_CTAYUp-8 for ; Fri, 14 Mar 2014 10:14:55 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id C57291A0170 for ; Fri, 14 Mar 2014 10:14:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1394817286; d=isode.com; s=selector; i=@isode.com; bh=dq0EL4D3aKX+mpI8C05R6yOI3vDvJalTPwpyrVlJ/VE=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=L6ElVdOqWUC8qozlXb4En7jqqKrZPTQv1gsZp7BamSr6qc461Gm/JE0NpS17XzGcQkp1vI TYhNgzBGKGtOIkH9iSqb04zJSJdusXaIACtT0uum2Iggm9MrHY+5zR0Hh7vaLDmuusHDOa MF7DRix/AWMAtx93pYPjDPSAbJikGEE=; Received: from [172.16.1.29] (richard.isode.com [62.3.217.249]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 14 Mar 2014 17:14:46 +0000 Message-ID: <53233939.9020703@isode.com> Date: Fri, 14 Mar 2014 17:15:37 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 To: dane@ietf.org References: <20140314052342.GQ21390@mournblade.imrryr.org> In-Reply-To: <20140314052342.GQ21390@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/xOP-2HbRcZmPWSW6RzFRKXlI63Y Subject: Re: [dane] Review of DANE SMTP draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 17:14:57 -0000 On 14/03/2014 05:23, Viktor Dukhovni wrote: > On Thu, Mar 06, 2014 at 01:44:17PM +0000, Alexey Melnikov wrote: > >> In the terminology section: what about no MX record case (A or AAAA only)? > Thanks. This was a global replace error. The term used to define > "MX Host". All of its occurrences got replaced with "SMTP server", > no longer specific to MX hosts of domains, but the terminology is > now wrong. I am going to just delete this dangling definition. Ok. >> In 1.3.1: why mention SMTP URIs? How would introduction of such >> URIs help with securing SMTP? I suggest you just mention that there >> is no signalling of "secure" SMTP. > There are no URIs and none are desired. This is an attempt at a > contrast with HTTP, and yes the point is that there is no signalling > of HOP by hop security policy in the envelope address (which is > more of a feature than a bug). I'm tweaking the text to talk about > signalling more explicitly, rather than a hypothetical URI scheme. Ok. >> In 2.2: Network address instead of MX hostname - I think this >> deserves an example. > [ Second-last paragraph of 2.2 ] > > Is it not obvious that this means the misguided: > > example.com. IN MX 0 192.0.2.1. No, it is not obvious, otherwise I wouldn't have asked. > I am not adding this yet, do others feel this really warrants more > text? > >> In 2.2.3 (page 17, 3rd from the last para): and possibly other places: >> TLS server certificate matching rules should be fully specified. Use RFC >> 6125 (for example look at draft-melnikov-email-tls-certs-01) or specify >> the rules directly. > In 6125 (where the exceptions dominate the rules) there are no > provisions for matching one of a set of candidate names. I am not sure I understand. If there are multiple subjectAltName values of the same type, any match works. Unless you mean something else. > So, I > guess, we should be more explicit about the wildcard matching > (perhaps generically in the SRV draft) and otherwise defer to > 6125 for international domain names, Subject commonName vs. > subjectAltName:DNS, etc. > > FWIW Postfix by default (Postini work-around) supports wildcard certificates > that match multiple DNS labels: > > http://www.postfix.org/postconf.5.html#tls_wildcard_matches_multiple_labels > > The folks at Postini have a wildcard cert for "*.psmtp.com" and clients > publish MX records of the form: > > verisign.com. IN MX 100 verisign.com.s6a1.psmtp.com. > verisign.com. IN MX 200 verisign.com.s6a2.psmtp.com. > verisign.com. IN MX 300 verisign.com.s6b1.psmtp.com. > verisign.com. IN MX 400 verisign.com.s6b2.psmtp.com. > > I have not given much thought to writing DANE-specific rules for > SMTP TLS with respect to the mechanics of matching of any particular > candidate name against the certificate. (To be honest, I did not > need to write any new code for this, since name matching is handled > in Postfix TLS policy generically for DANE and PKIX. The existing > PKIX code was already flexible enough to do all the work, so this > did not cross my radar). In > > https://tools.ietf.org/html/rfc6125#appendix-B.4 > > we have matching with just "*" as a wildcard (no "foo*.example.com" > or "*foo.example.com") and only for a single label. While SMTP-AUTH > forbids chasing CNAMEs insecurely, it only works well for MSA hosts, > not MX hosts which already lose after insecure MX delegation. With > DANE we have a secure TLSA base domain, so this does not apply. > > I don't know whether the Postfix (on by default) Postini work-around > deserves IETF blessing. Perhaps it would be better for Postini to > fix their certificates, I think so, yes. > or if they ever deploy DANE to publish only > DANE-EE(3) certs, which make the question moot. I don't know > whether any other sites are attempting to use SMTP with wildcard > certs for multi-label sub-domains. There is not enough authenticated > TLS happening for SMTP today to know what's out there in the wild. > >> Page 22, 3rd para: please add reference for the SNI TLS extension (a >> Normative reference, because you use normative language when referencing >> the extension) and various versions of TLS. > RFC 6066 is referenced on page 6 (second last paragraph) and appears > in the References section. Should the reference be repeated on > page 22? In general, I prefer when references are repeated. >> In 2.3.3: it is not clear whether the client needs to check that for every >> record covered by the WORSE hash there is a corresponding record covered >> by the BETTER hash. > This is not possible. The records don't carry separate "instance" > identifiers that allow one to identify all the TLSA records of a > single certificate or public key. The various digest algorithms > are not invertible! All that the client can check is that the > number of records for the best algorithm is the same as that for > all other algorithms within each combination of usage and selector. I think your current text can be misinterpreted that such validation is allowed. Use of normative language didn't help. I think I interpreted some of the requirements as applying to SMTP clients, where they applied to ISPs. > We may need a separate thread on pinning down algorithm agility > (unless it is good enough as-is, perhaps with clarifications if > the intent is not completely clear). > >> In Section 3, last para: add "or bounced", as this can be more serious >> than just being delayed. > Fine. Thank you. >> In 4.2, last para: did you mean "SHOULD"? > Perhaps so, though this may hold up publication of the SMTP draft > until the "ops" draft is also done. We could cut/paste the relevant > text, or move it to the more generic SRV draft. > > Ultimately, there is a real need for DANEbis, but it looks like it > won't move forward until there are more published and deployed > protocols, so we'll all be parroting the "missing" text in multiple > drafts, or perhaps the normative text from "ops" can be published as > a standards track "clarifications" to 6698? Any suggestions from > the chairs? > >> I've heard Not checking expiration dates in certificate - I don't think >> this was mentioned in the document. > This is in the "ops" draft, but I'll add it to the description in > the SMTP draft, after we figure out exactly what should be ignored > in DANE-EE(3) certs (and possibly DANE-TA(2) SPKI(1) trust anchor > certs). (Separate thread on this soon). Ok. If you are departing from RFC 5280, they you should state all new requirements. From nobody Fri Mar 14 10:41:16 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD5A21A0170 for ; Fri, 14 Mar 2014 10:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGgDejPr-SFb for ; Fri, 14 Mar 2014 10:41:11 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 754781A017C for ; Fri, 14 Mar 2014 10:41:10 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 19CB72AB13B; Fri, 14 Mar 2014 17:41:02 +0000 (UTC) Date: Fri, 14 Mar 2014 17:41:02 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140314174101.GU21390@mournblade.imrryr.org> References: <20140314052342.GQ21390@mournblade.imrryr.org> <53233939.9020703@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53233939.9020703@isode.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/re430AJNN3wUk8ZTEyorCsCJ7k4 Subject: Re: [dane] Review of DANE SMTP draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 17:41:14 -0000 On Fri, Mar 14, 2014 at 05:15:37PM +0000, Alexey Melnikov wrote: > >[ Second-last paragraph of 2.2 ] > > > >Is it not obvious that this means the misguided: > > > > example.com. IN MX 0 192.0.2.1. > > No, it is not obvious, otherwise I wouldn't have asked. The original sentence reads: Similarly, when an MX RRset incorrectly lists a network address in lieu of an MX hostname, if the MTA chooses to connect to the network address, DANE TLSA does not apply for such a connection. Anyone else feel this deserves an example? There are some poor sods who attempt to stuff IPv4 addresses into MX hostname RRDATA, and some MTAs may do them a favour and handle this broken syntax. In that case DANE is clearly out of scope. > >In 6125 (where the exceptions dominate the rules) there are no > >provisions for matching one of a set of candidate names. > > I am not sure I understand. If there are multiple subjectAltName > values of the same type, any match works. Unless you mean something > else. No, the SMTP and SRV drafts specify that the client has multiple names it is willing to accept, any one of which may match one of the many SAN names in the peer certificate. There can be up to three names. The original name before redirection by MX or SRV, the securely CNAME expanded version of that if different, and finally the TLSA base domain of the server. > >I don't know whether the Postfix (on by default) Postini work-around > >deserves IETF blessing. Perhaps it would be better for Postini to > >fix their certificates, > > I think so, yes. That is Postini fix their mess? Or SMTP support multi-label wildcards? > >RFC 6066 is referenced on page 6 (second last paragraph) and appears > >in the References section. Should the reference be repeated on > >page 22? > > In general, I prefer when references are repeated. We can do that. There is clearly sufficient distance between page 6, and page 22, for the reference not to appear repetitive. > >>In 2.3.3: it is not clear whether the client needs to check that for every > >>record covered by the WORSE hash there is a corresponding record covered > >>by the BETTER hash. > > > >This is not possible. The records don't carry separate "instance" > >identifiers that allow one to identify all the TLSA records of a > >single certificate or public key. The various digest algorithms > >are not invertible! All that the client can check is that the > >number of records for the best algorithm is the same as that for > >all other algorithms within each combination of usage and selector. > > I think your current text can be misinterpreted that such validation > is allowed. Use of normative language didn't help. I think I > interpreted some of the requirements as applying to SMTP clients, > where they applied to ISPs. What do you mean by "such validation is allowed"? Would you mind starting a new thread with questions specifically about the digest agility part of the SMTP draft? This mechanism is not intended to be SMTP-specific, and should some day make it into DANEbis via the SRV draft as a first hop perhaps (unless it should be its own stand-alone draft on just digest agility for DANE). > >>I've heard Not checking expiration dates in certificate - I don't think > >>this was mentioned in the document. > >> > >This is in the "ops" draft, but I'll add it to the description in > >the SMTP draft, after we figure out exactly what should be ignored > >in DANE-EE(3) certs (and possibly DANE-TA(2) SPKI(1) trust anchor > >certs). (Separate thread on this soon). > > Ok. If you are departing from RFC 5280, they you should state all > new requirements. Yes. -- Viktor. From nobody Fri Mar 14 12:34:55 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2A4C1A00A9 for ; Fri, 14 Mar 2014 12:34:54 -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=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kM7s4D5_hai5 for ; Fri, 14 Mar 2014 12:34:52 -0700 (PDT) Received: from insensate.co.uk (norman.insensate.co.uk [81.174.156.22]) by ietfa.amsl.com (Postfix) with ESMTP id CFAB21A0092 for ; Fri, 14 Mar 2014 12:34:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 12D3A143C8B9 for ; Fri, 14 Mar 2014 19:34:44 +0000 (GMT) Received: from insensate.co.uk ([127.0.0.1]) by localhost (psyche.insensate.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rys0LQC-3mrC for ; Fri, 14 Mar 2014 19:34:43 +0000 (GMT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTPSA id 16DE6143C8AE for ; Fri, 14 Mar 2014 19:34:43 +0000 (GMT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) From: Lawrence Conroy In-Reply-To: <20140314174101.GU21390@mournblade.imrryr.org> Date: Fri, 14 Mar 2014 19:34:42 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140314052342.GQ21390@mournblade.imrryr.org> <53233939.9020703@isode.com> <20140314174101.GU21390@mournblade.imrryr.org> To: dane@ietf.org X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/AA67TVZmrGwX5JuKdodEQnLrLDs Subject: Re: [dane] Review of DANE SMTP draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 19:34:54 -0000 Hi Viktor, Alexey, folks, Please, please, please do NOT give invalid/incorrect examples (even as = examples of what NOT to do). Viktor: The text you have seems pretty obvious to me on reading. To nail it in with a hammer, maybe c/when an MX RRset incorrectly lists = a network address in lieu of an MX hostname, if the MTA chooses/Even = though this form is invalid, some MX RRsets may be encountered that list = a network address in lieu of an MX hostname. If the MTA nevertheless = chooses/ (but that really is smashing the point home). Now back to lurking. all the best, Lawrence On 14 Mar 2014, at 17:41, Viktor Dukhovni wrote: > On Fri, Mar 14, 2014 at 05:15:37PM +0000, Alexey Melnikov wrote: >>> [ Second-last paragraph of 2.2 ] >>>=20 >>> Is it not obvious that this means the misguided: >>>=20 >>> example.com. IN MX 0 192.0.2.1. >>=20 >> No, it is not obvious, otherwise I wouldn't have asked. >=20 > The original sentence reads: >=20 > Similarly, when an MX RRset incorrectly lists a network address in > lieu of an MX hostname, if the MTA chooses to connect to the = network > address, DANE TLSA does not apply for such a connection. >=20 > Anyone else feel this deserves an example? There are some poor > sods who attempt to stuff IPv4 addresses into MX hostname RRDATA, > and some MTAs may do them a favour and handle this broken syntax. > In that case DANE is clearly out of scope. >=20 >>> In 6125 (where the exceptions dominate the rules) there are no >>> provisions for matching one of a set of candidate names. >>=20 >> I am not sure I understand. If there are multiple subjectAltName >> values of the same type, any match works. Unless you mean something >> else. >=20 > No, the SMTP and SRV drafts specify that the client has multiple > names it is willing to accept, any one of which may match one of > the many SAN names in the peer certificate. There can be up to > three names. The original name before redirection by MX or SRV, > the securely CNAME expanded version of that if different, and > finally the TLSA base domain of the server. >=20 >>> I don't know whether the Postfix (on by default) Postini work-around >>> deserves IETF blessing. Perhaps it would be better for Postini to >>> fix their certificates, >>=20 >> I think so, yes. >=20 > That is Postini fix their mess? Or SMTP support multi-label > wildcards? >=20 >>> RFC 6066 is referenced on page 6 (second last paragraph) and appears >>> in the References section. Should the reference be repeated on >>> page 22? >>=20 >> In general, I prefer when references are repeated. >=20 > We can do that. There is clearly sufficient distance between page > 6, and page 22, for the reference not to appear repetitive. >=20 >>>> In 2.3.3: it is not clear whether the client needs to check that = for every >>>> record covered by the WORSE hash there is a corresponding record = covered >>>> by the BETTER hash. >>>=20 >>> This is not possible. The records don't carry separate "instance" >>> identifiers that allow one to identify all the TLSA records of a >>> single certificate or public key. The various digest algorithms >>> are not invertible! All that the client can check is that the >>> number of records for the best algorithm is the same as that for >>> all other algorithms within each combination of usage and selector. >>=20 >> I think your current text can be misinterpreted that such validation >> is allowed. Use of normative language didn't help. I think I >> interpreted some of the requirements as applying to SMTP clients, >> where they applied to ISPs. >=20 > What do you mean by "such validation is allowed"? Would you mind > starting a new thread with questions specifically about the digest > agility part of the SMTP draft? This mechanism is not intended to > be SMTP-specific, and should some day make it into DANEbis via the > SRV draft as a first hop perhaps (unless it should be its own > stand-alone draft on just digest agility for DANE). >=20 >>>> I've heard Not checking expiration dates in certificate - I don't = think >>>> this was mentioned in the document. >>>>=20 >>> This is in the "ops" draft, but I'll add it to the description in >>> the SMTP draft, after we figure out exactly what should be ignored >>> in DANE-EE(3) certs (and possibly DANE-TA(2) SPKI(1) trust anchor >>> certs). (Separate thread on this soon). >>=20 >> Ok. If you are departing from RFC 5280, they you should state all >> new requirements. >=20 > Yes. >=20 > --=20 > Viktor. >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From nobody Fri Mar 14 14:42:26 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 225D61A01F4 for ; Fri, 14 Mar 2014 14:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNU_TcNMrH1l for ; Fri, 14 Mar 2014 14:42:22 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id EE47B1A01F1 for ; Fri, 14 Mar 2014 14:42:21 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 8BB6B2AADF5; Fri, 14 Mar 2014 21:42:12 +0000 (UTC) Date: Fri, 14 Mar 2014 21:42:12 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140314214212.GV21390@mournblade.imrryr.org> References: <20140314052342.GQ21390@mournblade.imrryr.org> <53233939.9020703@isode.com> <20140314174101.GU21390@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) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/1kfuzI230g3I8iXhdsZU-0KDw-U Subject: Re: [dane] Review of DANE SMTP draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 21:42:24 -0000 On Fri, Mar 14, 2014 at 07:34:42PM +0000, Lawrence Conroy wrote: > Hi Viktor, Alexey, folks, > > Please, please, please do NOT give invalid/incorrect examples (even as > examples of what NOT to do). No worries, I did not want to spend too much ink on this case. It was just a "throw-away" comment, while specifying that DANE is not applicable to address literal destinations when sending email to legal, but rare, constructs such as postmaster@[192.0.2.1] (also no example). -- Viktor. From nobody Fri Mar 14 18:08:44 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 958951A0221 for ; Fri, 14 Mar 2014 18:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.223 X-Spam-Level: ** X-Spam-Status: No, score=2.223 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, SPOOF_COM2COM=2.048, SPOOF_COM2OTH=2.723] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id my0dqXWqYHli for ; Fri, 14 Mar 2014 18:08:39 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.23.85]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8741A0121 for ; Fri, 14 Mar 2014 18:08:39 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 319CD1DF6E; Sat, 15 Mar 2014 01:08:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore13; t=1394845711; bh=JtslSK9xz2BgL4FP6FgbtqtUIfMmQP6JEETjHL4YpTI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=SEJsGST6GKDndTHw6ObJjEFpdyNWYrSfPtbOJRjs6K8WZy4wEU8bd3dzO/9fHq98O 7r67naoe1Au1uuSjasLI2ZRYgqp/8obK7ZjUjrJBTxO0Iu6zS3gpxbxuHU8xv4/ooq fjNb4obHFnNQ5FmqfU6WUdeoZBfsOxxgXbmBCJDv7pA== Received: by carbon.jhcloos.org (Postfix, from userid 500) id D45E560021; Sat, 15 Mar 2014 01:01:48 +0000 (UTC) From: James Cloos To: Viktor Dukhovni In-Reply-To: <20140314052342.GQ21390@mournblade.imrryr.org> (Viktor Dukhovni's message of "Fri, 14 Mar 2014 05:23:42 +0000") References: <20140314052342.GQ21390@mournblade.imrryr.org> User-Agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.3.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Fri, 14 Mar 2014 21:01:48 -0400 Message-ID: Lines: 23 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:140315:viktor1dane@dukhovni.org::gi06C3ZRavFNOyur:000000000000000000000000000000000000N4rD5 X-Hashcash: 1:30:140315:dane@ietf.org::UvCURVis2Yh8IIhK:000WNcxE Archived-At: http://mailarchive.ietf.org/arch/msg/dane/UEnR6jZLREb6hjSHP9XfvLqwDY4 Cc: dane@ietf.org Subject: Re: [dane] Review of DANE SMTP draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 01:08:40 -0000 >>>>> "VD" == Viktor Dukhovni writes: VD> FWIW Postfix by default (Postini work-around) supports wildcard VD> certificates that match multiple DNS labels: VD> http://www.postfix.org/postconf.5.html#tls_wildcard_matches_multiple_labels VD> The folks at Postini have a wildcard cert for "*.psmtp.com" and VD> clients publish MX records of the form: VD> verisign.com. IN MX 100 verisign.com.s6a1.psmtp.com. VD> verisign.com. IN MX 200 verisign.com.s6a2.psmtp.com. VD> verisign.com. IN MX 300 verisign.com.s6b1.psmtp.com. VD> verisign.com. IN MX 400 verisign.com.s6b2.psmtp.com. For some historical context, mozilla's original wildcarded ssl implement- ation also allowed an *. to match any number of labels. Several sites were broken by the change to limit a wildcard to a single label. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From nobody Fri Mar 14 19:42:15 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BADE1A026B for ; Fri, 14 Mar 2014 19:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.871 X-Spam-Level: ** X-Spam-Status: No, score=2.871 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPOOF_COM2COM=2.048, SPOOF_COM2OTH=2.723] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqVz9mlt3zIM for ; Fri, 14 Mar 2014 19:42:11 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id E47551A0230 for ; Fri, 14 Mar 2014 19:42:10 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id A553F2AB259; Sat, 15 Mar 2014 02:42:03 +0000 (UTC) Date: Sat, 15 Mar 2014 02:42:03 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140315024203.GW21390@mournblade.imrryr.org> References: <20140314052342.GQ21390@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) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/3OvHRq3Pz6xpP8Wu3sT5Swub1P8 Subject: Re: [dane] Review of DANE SMTP draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 02:42:12 -0000 On Fri, Mar 14, 2014 at 09:01:48PM -0400, James Cloos wrote: > > The folks at Postini have a wildcard cert for "*.psmtp.com" and > > clients publish MX records of the form: > > > > verisign.com. IN MX 100 verisign.com.s6a1.psmtp.com. > > verisign.com. IN MX 200 verisign.com.s6a2.psmtp.com. > > verisign.com. IN MX 300 verisign.com.s6b1.psmtp.com. > > verisign.com. IN MX 400 verisign.com.s6b2.psmtp.com. > > For some historical context, mozilla's original wildcarded ssl implement- > ation also allowed an *. to match any number of labels. > > Several sites were broken by the change to limit a wildcard to a single label. I take it you're suggesting to not perpetuate Postini's abuse of wildcard certs? Implementations might choose to be more liberal, but servers can't expect multi-label wildcard support. Right? -- Viktor. From nobody Fri Mar 14 22:17:18 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC451A000E for ; Fri, 14 Mar 2014 22:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q_oVoH0GfRIv for ; Fri, 14 Mar 2014 22:17:14 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 2C9401A0002 for ; Fri, 14 Mar 2014 22:17:13 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id E08342AB22D; Sat, 15 Mar 2014 05:17:04 +0000 (UTC) Date: Sat, 15 Mar 2014 05:17:04 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140315051704.GY21390@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) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/tTK1wXXuvGJH8plYbuOupl7_7_0 Subject: [dane] Digest Algorithm Agility discussion X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 05:17:16 -0000 The SMTP draft specifies a digest algorithm agility protocol for DANE. In this thread it would be helpful to arrive at consensus around the proposal, or a modified proposal if a better approach is suggested. Once that's settled, we can briefly touch on which document is the right home for this protocol. Goal: * It should be possible for servers to publish TLSA records employing multiple digest algorithms allowing clients to choose the best mutually supported digest. Important barrier: * When two or more distinct objects (multiple certificates or multiple public keys) are published in TLSA records with multiple digest algorithms, it is not possible based on the TLSA records alone to partition the records by object instance, combining related records that are merely different digests of the same underlying object. * What this means is that clients can't tell whether ignoring all the records for a given weaker digest does not result in leaving out some objects which are only present with that digest. Design: * The burden of making it safe to disregard records with deprecated or in any case less preferred digest algorithms is placed on the TLSA record publisher. * If for each given usage and selector, each published object that appears with a non-zero (i.e. a digest) matching type appears with the *same set* of digests as all other objects with that usage and selector, then it is definitely safe for clients to disregard all records except those with strongest (per client configuration) algorithm. * The server MUST employ this approach to publishing its records. * The client SHOULD employ digest algorithm agility by ignoring all but the strongest non-zero digest for each usage/selector combination. Note, records with matching type zero play no role in digest algorithm agility. Open issue: * Suppose the server records are clearly in violation of the requirement, because the number of records for one of the digest algorithms is strictly greater than the (non-zero) number of records for some other algorithm. Should the client apply the agility algorithm anyway (server is to blame if this is not safe)? Or should it avoid using digest agility in this case? Note, avoiding the algorithm does not solve all possible problems. The digest values could be mistranscribed, or even though the counts are the same, the sets of underlying objects for some pair of algorithms might still not be identical. Larger question: * Is this the right agility protocol? It seems to me to be roughly the best we can do given the structure of TLSA records. -- Viktor. From nobody Sat Mar 15 11:02:09 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 166631A017B for ; Sat, 15 Mar 2014 11:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHof9TMErkwH for ; Sat, 15 Mar 2014 11:02:05 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.23.85]) by ietfa.amsl.com (Postfix) with ESMTP id 45DCE1A017D for ; Sat, 15 Mar 2014 11:02:05 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 7A3BA1DD11; Sat, 15 Mar 2014 18:01:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore13; t=1394906517; bh=gdF1mMAv33A0fludJAC3hTJKvl4U4p5MJYOVBTmTWSQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=DFeLY7SL90Qjkv0Zf2pHdgGRPqQIW3FPw7T4pqfAzkHcNyBbUymWhjGqtQPB93jHP BdGDj3LktUhdaG5WPO/nAtIWArEouoOiywtk7sF+b2HC0sG42exh3l0GsTmvWzaxs/ nsDEcCE4wCkfMSO1epZL9f3tJXVhwGiFYTHn/uq/ueg== Received: by carbon.jhcloos.org (Postfix, from userid 500) id B1E0E60021; Sat, 15 Mar 2014 17:59:43 +0000 (UTC) From: James Cloos To: Viktor Dukhovni In-Reply-To: <20140315024203.GW21390@mournblade.imrryr.org> (Viktor Dukhovni's message of "Sat, 15 Mar 2014 02:42:03 +0000") References: <20140314052342.GQ21390@mournblade.imrryr.org> <20140315024203.GW21390@mournblade.imrryr.org> User-Agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.3.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 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: Sat, 15 Mar 2014 13:59:43 -0400 Message-ID: Lines: 16 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:140315:viktor1dane@dukhovni.org::2TqHpLh+DfCL6y4S:0000000000000000000000000000000000005VSoq X-Hashcash: 1:30:140315:dane@ietf.org::MrHj1+F22evGIw3r:000NfCLx Archived-At: http://mailarchive.ietf.org/arch/msg/dane/OUSDo71cmbtRWzNO8bG9C3rfGtI Cc: dane@ietf.org Subject: Re: [dane] Review of DANE SMTP draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 18:02:07 -0000 >>>>> "VD" == Viktor Dukhovni writes: VD> I take it you're suggesting to not perpetuate Postini's abuse of VD> wildcard certs? Not really; I'm ambivalent. And most tls usage lacks uri bars, so it is less of an issue than it might be for browsers. VD> Implementations might choose to be more liberal, VD> but servers can't expect multi-label wildcard support. Right? True. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From nobody Sun Mar 16 13:54:42 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED7F01A01F9 for ; Sun, 16 Mar 2014 13:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RU44-qAJ2GpD for ; Sun, 16 Mar 2014 13:54:37 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id C53911A01E4 for ; Sun, 16 Mar 2014 13:54:36 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 827372AADF5; Sun, 16 Mar 2014 20:54:28 +0000 (UTC) Date: Sun, 16 Mar 2014 20:54:28 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140316205428.GG24183@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/8EfkLUuC6E2qp7NmMuCuVyTWs2E Subject: [dane] DANE-EE(3) certificate matching rules? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Mar 2014 20:54:40 -0000 We've previously agreed on cu=DANE-EE(3) obviating name checks, since the TLSA base domain with port and protocol prefix is in fact a more specific binding of the service end-point and public key than any name in the certificate, and (perhaps more so) because this dramatically simplifies virtual hosting. In the OPs draft I went further and stated that verification of the DANE-EE(3) end-entity certificate stops at matching it against the TLSA record, and its content MUST otherwise be ignored. This subsumes at least checks of the expiration date and also the EKU, both of which are essentially superseded by the TLSA RR. I may have gone a bit further than necessary. The main goal is to make DANE authentication usable in protocols with no user to "click OK". To this end I want to avoid the most common operational failures with PKIX. Therefore I propose that: - In addition to name checks, expiration checks also be performed via the TLSA RR signature lifetime, rather than the certificate expiration date. The TLSA record is updated frequently as the DNSSEC zone is periodically re-signed. This ensures that there are no surprise expirations. Certificates can be replaced at the operator's convenience. - Though the EKU is technically superseded by the TLSA RR type, which implies a TLSA usage, getting this wrong would be discovered immediately by the server operator, and quickly fixed. There is no need to complicate implementations by special-casing DANE EKU processing. Similarly with the key usage, and other fields. Therefore, the final proposal for DANE-EE(3) is that only name checks and expiration checks are out of scope. This applies whether the selector is Cert(0) or SPKI(1). However, when *all* TLSA records are "IN TLSA DANE-EE(3) SPKI(1) ?", implementations that support the proposed bare public key TLS extension, may signal that extension, in which case if the server cooperates, in effect the rest of the certificate is ignored (in fact never transmitted). Any comments? Can the above be the final consensus on this topic? -- Viktor. From nobody Sun Mar 16 15:47:38 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFEEA1A01E8 for ; Sun, 16 Mar 2014 15:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LmMkkh2ZnHuN for ; Sun, 16 Mar 2014 15:47:33 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.23.85]) by ietfa.amsl.com (Postfix) with ESMTP id BB47D1A030D for ; Sun, 16 Mar 2014 15:47:33 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 050FA1EBF2; Sun, 16 Mar 2014 22:47:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore13; t=1395010043; bh=p9srwYvNElgxoLVxA9BkDommwtYQ1tlHChfYGBBiPoY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=mQsiaFtulIIlWCcmk5sQqkFLrIeIgm20UfKKYIdk238wapbVBguigwv1aK3GvwO+3 ugvhAlLF9CrSBymZFitSqhw2NdGh6cdNTRoad/jOVQU4ucZ2DmAn8QrdD5NQnHRc2T c4KVXMzJttu6HIugTN59A72U9ScQxlQkmBiSN0oWFSw== Received: by carbon.jhcloos.org (Postfix, from userid 500) id 7B94660021; Sun, 16 Mar 2014 22:45:20 +0000 (UTC) From: James Cloos To: dane@ietf.org In-Reply-To: <20140316205428.GG24183@mournblade.imrryr.org> (Viktor Dukhovni's message of "Sun, 16 Mar 2014 20:54:28 +0000") References: <20140316205428.GG24183@mournblade.imrryr.org> User-Agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.3.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 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: Sun, 16 Mar 2014 18:45:20 -0400 Message-ID: Lines: 22 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:140316:dane@ietf.org::ECdOKqb56rglZwh6:000Oea88 X-Hashcash: 1:30:140316:viktor1dane@dukhovni.org::5qKqrSTJnFAybzp1:0000000000000000000000000000000000002urbx Archived-At: http://mailarchive.ietf.org/arch/msg/dane/aRJ8mP_hAeksynNnDleUP4FnGgc Subject: Re: [dane] DANE-EE(3) certificate matching rules? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Mar 2014 22:47:36 -0000 >>>>> "VD" == Viktor Dukhovni writes: VD> Therefore, the final proposal for DANE-EE(3) is that only name VD> checks and expiration checks are out of scope. This applies whether VD> the selector is Cert(0) or SPKI(1). However, when *all* TLSA records VD> are "IN TLSA DANE-EE(3) SPKI(1) ?", implementations that support the VD> proposed bare public key TLS extension, may signal that extension, VD> in which case if the server cooperates, in effect the rest of the VD> certificate is ignored (in fact never transmitted). VD> Any comments? Can the above be the final consensus on this topic? That seems reasonable. Some software stacks may make that difficult easily to accomplish. At least in the short term. But such libraries can be fixed. So, +1. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From nobody Mon Mar 17 08:27:15 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7F71A0409 for ; Mon, 17 Mar 2014 08:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6qthlOuFU-9 for ; Mon, 17 Mar 2014 08:27:10 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 481CE1A040E for ; Mon, 17 Mar 2014 08:27:08 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 56BC5800AA for ; Mon, 17 Mar 2014 11:26:59 -0400 (EDT) Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s2HFQw9b002046 for ; Mon, 17 Mar 2014 11:26:59 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 17 Mar 2014 11:26:58 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: dane WG list In-Reply-To: <20140315051704.GY21390@mournblade.imrryr.org> Message-ID: References: <20140315051704.GY21390@mournblade.imrryr.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/dane/Dsgcv2lCCuAxnShW3omOT3AmBEc Subject: Re: [dane] Digest Algorithm Agility discussion X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 15:27:13 -0000 On Sat, 15 Mar 2014, Viktor Dukhovni wrote: > Goal: > > * It should be possible for servers to publish TLSA records > employing multiple digest algorithms allowing clients to > choose the best mutually supported digest. Isn't that already possible? > * The client SHOULD employ digest algorithm agility by ignoring > all but the strongest non-zero digest for each usage/selector > combination. Note, records with matching type zero play no > role in digest algorithm agility. I don't think that is a proper assumption. For example, a zone might need to publish a GOST based digest for legal reasons (eg not trusting US based digests) but might publish a FIPS approved digest for other people. The client has a more complicated reduction scheme going on for their local policy than "strongest". Traditionally, for instance with the DS record, we allow publishing multiple digests, and the client's task is just to find one which is "acceptable". It would be nice if it starts with what it believes is the "strongest". If a certain digest is so weak it is basically broken, it should not be left in a published TLSA record. If the most prefered TLSA record fails validation, the client should try another TLSA record. The order in which is does so could be written down in the RFC if we think there is one true way of doing so. Otherwise, it should just be referenced in the RFC as "according to local policy". This also gives the server admin some more protection. If they publish digests using SHA2-256 and SHA1, and it turns out their tool generates bad SHA2-256, than the clients still have a valid SHA1 to fall back to. Perhaps there is text in the DS record RFC to look at that describes this better than I just did. Paul From nobody Mon Mar 17 08:51:03 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4AA51A01ED for ; Mon, 17 Mar 2014 08:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27Hro6hUFEuk for ; Mon, 17 Mar 2014 08:50:58 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0861A01BE for ; Mon, 17 Mar 2014 08:50:58 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 0C4CB2AADF5; Mon, 17 Mar 2014 15:50:50 +0000 (UTC) Date: Mon, 17 Mar 2014 15:50:49 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140317155049.GB24183@mournblade.imrryr.org> References: <20140315051704.GY21390@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.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/fBhmhVFaykWViLK9FbzNoymKcWc Subject: Re: [dane] Digest Algorithm Agility discussion X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 15:51:01 -0000 On Mon, Mar 17, 2014 at 11:26:58AM -0400, Paul Wouters wrote: > On Sat, 15 Mar 2014, Viktor Dukhovni wrote: > > >Goal: > > > > * It should be possible for servers to publish TLSA records > > employing multiple digest algorithms allowing clients to > > choose the best mutually supported digest. > > Isn't that already possible? Not based on RFC 6698 alone. With RFC 6698 the client trusts all TLSA records whether "weak" and "strong". > > * The client SHOULD employ digest algorithm agility by ignoring > > all but the strongest non-zero digest for each usage/selector > > combination. Note, records with matching type zero play no > > role in digest algorithm agility. > > I don't think that is a proper assumption. For example, a zone might > need to publish a GOST based digest for legal reasons (eg not trusting > US based digests) but might publish a FIPS approved digest for other > people. The client has a more complicated reduction scheme going on > for their local policy than "strongest". I am not *assuming* anything. We defined required client and server behaviour which, if consistently applied by all parties, makes algorithm agility possible. The client decides which digest to use. So long as the server publishes each object (certificate or public key) with the same set of digests as all other objects (i.e. the TLSA RRset is a "cross product" of the desired objects and digest algorithms) no information is lost when the client chooses just a single digest and ignores the rest. > Traditionally, for instance with the DS record, we allow publishing > multiple digests, and the client's task is just to find one which is > "acceptable". It would be nice if it starts with what it believes is > the "strongest". My proposal is essentially the same. The client uses the strongest acceptable digest algorithm. The *client* decides what "strongest" means. It never chooses an unsupported algorithm. > If a certain digest is so weak it is basically broken, it should not be > left in a published TLSA record. Weak digests (say SHA2-256 if/when broken) cannot be easily removed from RRsets until all clients support stronger ones. The idea is to publish stronger digests and deploy stronger clients, then remove weak digests later. Stronger clients will never use the published weak records. Otherwise there's an Internet-wide flag-day. > If the most prefered TLSA record fails validation, the client should try > another TLSA record. This works poorly. While the weak algorithm is being phased out (years) even clients that support stronger algorithms are at risk. > The order in which is does so could be written down > in the RFC if we think there is one true way of doing so. The order is irrelevant. Eventually some record matches. It is immaterial whether it is "first" or "last". > This also gives the server admin some more protection. If they publish > digests using SHA2-256 and SHA1, and it turns out their tool generates > bad SHA2-256, than the clients still have a valid SHA1 to fall back to. They could also publish a bogus CU or selector, or mess up in many other ways. I don't think that the intent of multiple algorithms in 6698 is to mask bogus data. > Perhaps there is text in the DS record RFC to look at that describes > this better than I just did. Perhaps Wes can chime in. His comment to me was that the proposed DAA (digest algorithm agility) is essentially the only possible and largely analogous to the DNSSEC approach. -- Viktor. From nobody Mon Mar 17 09:48:02 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FFFC1A0427 for ; Mon, 17 Mar 2014 09:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6IvExfgt14VN for ; Mon, 17 Mar 2014 09:47:58 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 80BCD1A006F for ; Mon, 17 Mar 2014 09:47:58 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s2HGlllE029644 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 17 Mar 2014 09:47:49 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: <20140317155049.GB24183@mournblade.imrryr.org> Date: Mon, 17 Mar 2014 09:47:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140315051704.GY21390@mournblade.imrryr.org> <20140317155049.GB24183@mournblade.imrryr.org> To: dane@ietf.org X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/tehhNTQq7NcwRw7q_dk4DcqLoiI Subject: Re: [dane] Digest Algorithm Agility discussion X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 16:48:00 -0000 This discussion comes up in every security WG. The proposal tries to = help a client who wants to always use the strongest algorithm without = actually having to understand why a different algorithm is weaker. This = makes the semantics pretty intractable. On Mar 17, 2014, at 8:50 AM, Viktor Dukhovni = wrote: > On Mon, Mar 17, 2014 at 11:26:58AM -0400, Paul Wouters wrote: >=20 >> On Sat, 15 Mar 2014, Viktor Dukhovni wrote: >>=20 >>> Goal: >>>=20 >>> * It should be possible for servers to publish TLSA records >>> employing multiple digest algorithms allowing clients to >>> choose the best mutually supported digest. >>=20 >> Isn't that already possible? >=20 > Not based on RFC 6698 alone. With RFC 6698 the client trusts all > TLSA records whether "weak" and "strong". Can you point to the specific text for that? It was not my intention, = and I doubt it was the intention of the WG. > My proposal is essentially the same. The client uses the strongest > acceptable digest algorithm. The *client* decides what "strongest" > means. It never chooses an unsupported algorithm. Again, that was at least my intention for 6698. If we need to clarify = that, that would be much better than adding another layer of protocol = grease. >> If a certain digest is so weak it is basically broken, it should not = be >> left in a published TLSA record. >=20 > Weak digests (say SHA2-256 if/when broken) cannot be easily removed > from RRsets until all clients support stronger ones. The idea is > to publish stronger digests and deploy stronger clients, then remove > weak digests later. =20 Yes. > Stronger clients will never use the published > weak records. =20 I strongly doubt that is the desired outcome. If so, lots of zones will = go invisible when the "later" in "remove weak digests later" stretches = to a decade. Instead, a stronger client can have a setting that says "I'm going to = abort when seeing a weaker digest, and I will alert you". The latter = part is important. > Otherwise there's an Internet-wide flag-day. Which will never happen, so bringing it up is just hyperbole. >> If the most prefered TLSA record fails validation, the client should = try >> another TLSA record. >=20 > This works poorly. While the weak algorithm is being phased out > (years) even clients that support stronger algorithms are at risk. At risk of what? Seriously: DANE is additional security over non-TLS, so = a "weak" algorithm is still better than "no TLS". Reduction to absurdity = is not helpful here. >> Perhaps there is text in the DS record RFC to look at that describes >> this better than I just did. >=20 > Perhaps Wes can chime in. His comment to me was that the proposed > DAA (digest algorithm agility) is essentially the only possible > and largely analogous to the DNSSEC approach. I believe he is talking about RFC 6975. I do not believe that it = attracted any significant interest. --Paul Hoffman= From nobody Mon Mar 17 09:58:08 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C79AA1A01ED for ; Mon, 17 Mar 2014 09:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qIQYnJ-KmuWu for ; Mon, 17 Mar 2014 09:58:04 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id E664A1A0436 for ; Mon, 17 Mar 2014 09:58:03 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 48BDF800AA for ; Mon, 17 Mar 2014 12:57:55 -0400 (EDT) Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s2HGvsCM008140 for ; Mon, 17 Mar 2014 12:57:55 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 17 Mar 2014 12:57:54 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: dane WG list In-Reply-To: <20140317155049.GB24183@mournblade.imrryr.org> Message-ID: References: <20140315051704.GY21390@mournblade.imrryr.org> <20140317155049.GB24183@mournblade.imrryr.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dane/9aULsaRq_gkNcIho1WdarErMlvY Subject: Re: [dane] Digest Algorithm Agility discussion X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 16:58:06 -0000 On Mon, 17 Mar 2014, Viktor Dukhovni wrote: >>> * It should be possible for servers to publish TLSA records >>> employing multiple digest algorithms allowing clients to >>> choose the best mutually supported digest. >> >> Isn't that already possible? > > Not based on RFC 6698 alone. With RFC 6698 the client trusts all > TLSA records whether "weak" and "strong". 4.1 states: A TLSA RRSet whose DNSSEC validation state is secure MUST be used as a certificate association for TLS unless a local policy would prohibit the use of the specific certificate association in the secure TLSA RRSet. Can that not be used to reject a weak digest? > My proposal is essentially the same. The client uses the strongest > acceptable digest algorithm. The *client* decides what "strongest" > means. It never chooses an unsupported algorithm. but you want to fail if that one selected one fails. I don't think that is the right decision. >> If a certain digest is so weak it is basically broken, it should not be >> left in a published TLSA record. > > Weak digests (say SHA2-256 if/when broken) cannot be easily removed > from RRsets until all clients support stronger ones. The idea is > to publish stronger digests and deploy stronger clients, then remove > weak digests later. Stronger clients will never use the published > weak records. Otherwise there's an Internet-wide flag-day. I don't think we disagree. the server publishes a new strong digest, and clients that support that and consider sha2-256 weak will not use sha2-256. If the admin messes up the new strong digest, than new clients will fail to get a TLSA record, and old clients will use an unsafe one. >> If the most prefered TLSA record fails validation, the client should try >> another TLSA record. > > This works poorly. While the weak algorithm is being phased out > (years) even clients that support stronger algorithms are at risk. New clients can have a local policy that states never to accept weak digests. I don't see a problem with agility. The weak TLSA records are only left in for clients that support nothing stronger. >> This also gives the server admin some more protection. If they publish >> digests using SHA2-256 and SHA1, and it turns out their tool generates >> bad SHA2-256, than the clients still have a valid SHA1 to fall back to. > > They could also publish a bogus CU or selector, or mess up in many other > ways. I don't think that the intent of multiple algorithms in 6698 is > to mask bogus data. Maybe I don't understand what you think the problem is? >> Perhaps there is text in the DS record RFC to look at that describes >> this better than I just did. > > Perhaps Wes can chime in. His comment to me was that the proposed > DAA (digest algorithm agility) is essentially the only possible > and largely analogous to the DNSSEC approach. So aren't we all agreeing? Paul From nobody Mon Mar 17 10:35:19 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5A131A0442 for ; Mon, 17 Mar 2014 10:35:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f53wmSISQN2V for ; Mon, 17 Mar 2014 10:35:14 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 803E91A02AD for ; Mon, 17 Mar 2014 10:35:14 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 1E54C2AB19D; Mon, 17 Mar 2014 17:35:06 +0000 (UTC) Date: Mon, 17 Mar 2014 17:35:06 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140317173506.GD24183@mournblade.imrryr.org> References: <20140315051704.GY21390@mournblade.imrryr.org> <20140317155049.GB24183@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.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/KjE11hywm1ZmvmHG9iMZ2lK_8TQ Subject: Re: [dane] Digest Algorithm Agility discussion X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 17:35:17 -0000 On Mon, Mar 17, 2014 at 12:57:54PM -0400, Paul Wouters wrote: > On Mon, 17 Mar 2014, Viktor Dukhovni wrote: > > >>> * It should be possible for servers to publish TLSA records > >>> employing multiple digest algorithms allowing clients to > >>> choose the best mutually supported digest. > >> > >>Isn't that already possible? > > > >Not based on RFC 6698 alone. With RFC 6698 the client trusts all > >TLSA records whether "weak" and "strong". > > 4.1 states: > > A TLSA RRSet whose DNSSEC validation state is secure MUST be used > as a certificate association for TLS unless a local policy would > prohibit the use of the specific certificate association in the > secure TLSA RRSet. > > Can that not be used to reject a weak digest? The above proposal is for clients to black-list designated weak digests, rather than select the strongest available digest. If a digest is not yet ready to be black-listed, but is no longer recommended (as lets say SHA1 is now) we'd still have clients using it even when stronger digests are published along-side. I am proposing clients using *only* the strongest digest (as determined by their configuration) and ignoring the rest. This results in a much clear phase-out process. The weak digests are only used when one of the sides only supports that digest. It all boils down to how one might attempt to phase out a weak digest. If there is no "negotiation" (choice of strongest mutually available option) transitions are much harder, because the weak options are used until suddenly dropped, rather than gradually becoming less common, until it is easy to phase them out because almost nobody uses them. > >My proposal is essentially the same. The client uses the strongest > >acceptable digest algorithm. The *client* decides what "strongest" > >means. It never chooses an unsupported algorithm. > > but you want to fail if that one selected one fails. I don't think that > is the right decision. There is no "right" or "wrong", only trade-offs. > I don't think we disagree. the server publishes a new strong digest, and > clients that support that and consider sha2-256 weak will not use > sha2-256. The difference is that clients don't consider SHA2-256 (say) weak right away, they initially get to prefer to not use it, whenever (say) SHA2-512 is also published. > If the admin messes up the new strong digest, than new clients > will fail to get a TLSA record, and old clients will use an unsafe one. The admin messing up is a red-herring. Nobody will publish two digests just in case one is "messed-up". They will publish multiple digests to allow clients to choose the strongest one. > >>If the most prefered TLSA record fails validation, the client should try > >>another TLSA record. > > > >This works poorly. While the weak algorithm is being phased out > >(years) even clients that support stronger algorithms are at risk. > > New clients can have a local policy that states never to accept weak > digests. I don't see a problem with agility. The weak TLSA records > are only left in for clients that support nothing stronger. Such policy is difficult to enable, it applies even to servers that only publish the weak digest. My proposal incrementally phases out the weak digest as servers publish the stronger version. > Maybe I don't understand what you think the problem is? Incremental transition from weak to strong algorithms with no flag day (clients having to completely disable an algorithm to avoid exposure to it even with servers that support a stronger one). With TLS for example, clients don't have to disable all weaker block ciphers, because the client and server will agree on the strongest mutually available (based on either the client's or server's preference list). Once the mutually strongest option is selected, the others are irrelevant. The idea here is the same. > >Perhaps Wes can chime in. His comment to me was that the proposed > >DAA (digest algorithm agility) is essentially the only possible > >and largely analogous to the DNSSEC approach. > > So aren't we all agreeing? Not yet. To be specific suppose a server publishes: IN TLSA 3 1 2 {blob2} IN TLSA 3 1 1 {blob1} and a client supports SHA2-512 (believed strong) and SHA2-256 (hypothetically tarnished, but not yet known broken). In my proposal the client completely ignores {blob1} *even if* {blob2} does not match! The client and server first agree on the strongest digest (analogy with TLS cipher-suite negotiation) and then only that digest is used. The same client authenticating a second server: IN TLSA 3 1 1 {blob3} will use {blob3}. -- Viktor. From nobody Mon Mar 17 10:44:35 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 814F41A045E for ; Mon, 17 Mar 2014 10:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XYjsQ0vpdYd0 for ; Mon, 17 Mar 2014 10:44:31 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 7704E1A045D for ; Mon, 17 Mar 2014 10:44:31 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 26E442AB274; Mon, 17 Mar 2014 17:44:23 +0000 (UTC) Date: Mon, 17 Mar 2014 17:44:23 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140317174423.GE24183@mournblade.imrryr.org> References: <20140315051704.GY21390@mournblade.imrryr.org> <20140317155049.GB24183@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.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/RV0iTkuZ_hAEn8jvbVL_M3ZlUBI Subject: Re: [dane] Digest Algorithm Agility discussion X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 17:44:33 -0000 On Mon, Mar 17, 2014 at 09:47:46AM -0700, Paul Hoffman wrote: > >>> * It should be possible for servers to publish TLSA records > >>> employing multiple digest algorithms allowing clients to > >>> choose the best mutually supported digest. > >> > >> Isn't that already possible? > > > > Not based on RFC 6698 alone. With RFC 6698 the client trusts all > > TLSA records whether "weak" and "strong". > > Can you point to the specific text for that? It was not my > intention, and I doubt it was the intention of the WG. Per RFC 6698, the client evaluats all "usable" TLSA records until one matches, regardless of digest algorithm strength. > > My proposal is essentially the same. The client uses the strongest > > acceptable digest algorithm. The *client* decides what "strongest" > > means. It never chooses an unsupported algorithm. > > Again, that was at least my intention for 6698. If we need to > clarify that, that would be much better than adding another layer > of protocol grease. There is no text in 6698 that even approximately suggests that clients get to use only the records with the strongest (local criteria) digest. > > Stronger clients will never use the published weak records. > > I strongly doubt that is the desired outcome. If so, lots of > zones will go invisible when the "later" in "remove weak digests > later" stretches to a decade. One can audit for weak TLSA RRsets on peer systems before deciding to disable a weak algorithm. My proposal makes it possible to ramp security before completely disabling an algorithm. Not doing the proposed agility algorithm makes the problem worse. > > This works poorly. While the weak algorithm is being phased out > > (years) even clients that support stronger algorithms are at risk. > > At risk of what? Seriously: DANE is additional security over > non-TLS, so a "weak" algorithm is still better than "no TLS". > Reduction to absurdity is not helpful here. Of all people, I am quite surprised to see you say that. DANE IS NOT additional security over non-TLS. DANE is a specification for publishing public keys in DNS. It can be used for both opportunistic and non-opportunistic use-cases. Postfix supports DANE in both opportunistic and mandatory modes. Please see also my reply to Paul W. -- Viktor. From nobody Mon Mar 17 11:14:49 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD6A1A0488 for ; Mon, 17 Mar 2014 11:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TV8n2FiZXXSU for ; Mon, 17 Mar 2014 11:14:44 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id A33161A048D for ; Mon, 17 Mar 2014 11:14:44 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s2HIEYDK032984 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 17 Mar 2014 11:14:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: <20140317174423.GE24183@mournblade.imrryr.org> Date: Mon, 17 Mar 2014 11:14:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <040FB71F-BD97-44A2-A600-B6E69FBD1EE5@vpnc.org> References: <20140315051704.GY21390@mournblade.imrryr.org> <20140317155049.GB24183@mournblade.imrryr.org> <20140317174423.GE24183@mournblade.imrryr.org> To: dane@ietf.org X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/TQ-cJxId3Fa2rglzeRnru5mYWe4 Subject: Re: [dane] Digest Algorithm Agility discussion X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 18:14:46 -0000 On Mar 17, 2014, at 10:44 AM, Viktor Dukhovni = wrote: > On Mon, Mar 17, 2014 at 09:47:46AM -0700, Paul Hoffman wrote: >=20 >>>>> * It should be possible for servers to publish TLSA records >>>>> employing multiple digest algorithms allowing clients to >>>>> choose the best mutually supported digest. >>>>=20 >>>> Isn't that already possible? >>>=20 >>> Not based on RFC 6698 alone. With RFC 6698 the client trusts all >>> TLSA records whether "weak" and "strong". >>=20 >> Can you point to the specific text for that? It was not my >> intention, and I doubt it was the intention of the WG. >=20 > Per RFC 6698, the client evaluats all "usable" TLSA records until > one matches, regardless of digest algorithm strength. Umm, I asked for specific text. :-) If it is in Section 4.1 (which is = where it should be), I'm not seeing it. >>> My proposal is essentially the same. The client uses the strongest >>> acceptable digest algorithm. The *client* decides what "strongest" >>> means. It never chooses an unsupported algorithm. >>=20 >> Again, that was at least my intention for 6698. If we need to >> clarify that, that would be much better than adding another layer >> of protocol grease. >=20 > There is no text in 6698 that even approximately suggests that clients > get to use only the records with the strongest (local criteria) = digest. In Section 4.1: o A TLSA RRSet whose DNSSEC validation state is secure MUST be used as a certificate association for TLS unless a local policy would prohibit the use of the specific certificate association in the secure TLSA RRSet. And at the end of Section 8: Generators of TLSA records should be aware that the client's full trust of a certificate association retrieved from a TLSA record may be a matter of local policy. While such trust is limited to the specific domain name, protocol, and port for which the TLSA query was made, local policy may decline to accept the certificate (for reasons such as weak cryptography), as is also the case with PKIX trust anchors. Crypto choice is definitely a local policy. --Paul Hoffman= From nobody Mon Mar 17 11:22:31 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E33581A0449 for ; Mon, 17 Mar 2014 11:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3YHOedZso5lG for ; Mon, 17 Mar 2014 11:22:28 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0B41A042D for ; Mon, 17 Mar 2014 11:22:28 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 18A9D2AB19D; Mon, 17 Mar 2014 18:22:19 +0000 (UTC) Date: Mon, 17 Mar 2014 18:22:19 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140317182219.GF24183@mournblade.imrryr.org> References: <20140315051704.GY21390@mournblade.imrryr.org> <20140317155049.GB24183@mournblade.imrryr.org> <20140317174423.GE24183@mournblade.imrryr.org> <040FB71F-BD97-44A2-A600-B6E69FBD1EE5@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <040FB71F-BD97-44A2-A600-B6E69FBD1EE5@vpnc.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/_HJtQJqBX_-vcNGr5O3YeXpS3_Y Subject: Re: [dane] Digest Algorithm Agility discussion X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 18:22:31 -0000 On Mon, Mar 17, 2014 at 11:14:32AM -0700, Paul Hoffman wrote: > > There is no text in 6698 that even approximately suggests that clients > > get to use only the records with the strongest (local criteria) digest. > > In Section 4.1: > o A TLSA RRSet whose DNSSEC validation state is secure MUST be used > as a certificate association for TLS unless a local policy would > prohibit the use of the specific certificate association in the > secure TLSA RRSet. This is not "use strongest". This is the opposite. It forces the use of tarnished, but still acceptable digests even when untarnished digests are present. The new proposal is to ignore all but the strongest, even when the remainder would be usable. Also the pseudo-code in the appendices loops over *all* "usable" TLSA RRs (those not banned by 4.1). My proposal modifies the pseudo-code to loop over only those records (for each usage/selector) with the strongest digest plus any records with matching type 0. The key difference is the lifecycle of a tarnished digest. With 6698, it is trusted until the moment it is dropped. With the new proposal it gradually fades out. I think the fading out part is an important feature. It makes it possible to be secure with servers that publish strong RRs even while accepting weak digests from servers that don't. -- Viktor. From nobody Mon Mar 17 11:46:55 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 827B11A0455 for ; Mon, 17 Mar 2014 11:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFkQZy2QDzyr for ; Mon, 17 Mar 2014 11:46:51 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id EDAC61A042F for ; Mon, 17 Mar 2014 11:46:50 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 40A57800AA for ; Mon, 17 Mar 2014 14:46:42 -0400 (EDT) Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s2HIkfsj014502 for ; Mon, 17 Mar 2014 14:46:42 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 17 Mar 2014 14:46:41 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: dane WG list In-Reply-To: <20140317182219.GF24183@mournblade.imrryr.org> Message-ID: References: <20140315051704.GY21390@mournblade.imrryr.org> <20140317155049.GB24183@mournblade.imrryr.org> <20140317174423.GE24183@mournblade.imrryr.org> <040FB71F-BD97-44A2-A600-B6E69FBD1EE5@vpnc.org> <20140317182219.GF24183@mournblade.imrryr.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/dane/JhZ-jFLJ6dulWLD4wIaG9FsSRwg Subject: Re: [dane] Digest Algorithm Agility discussion X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 18:46:53 -0000 On Mon, 17 Mar 2014, Viktor Dukhovni wrote: > This is not "use strongest". This is the opposite. It forces the > use of tarnished, but still acceptable digests even when untarnished > digests are present. The new proposal is to ignore all but the > strongest, even when the remainder would be usable. > > Also the pseudo-code in the appendices loops over *all* "usable" TLSA > RRs (those not banned by 4.1). Okay, I understand your point now. The text in 6698 is indeed doing some half weird local policy client dictation that it should not have done. > My proposal modifies the pseudo-code > to loop over only those records (for each usage/selector) with the > strongest digest plus any records with matching type 0. So I agree with you that is the right approach. I am not sure if I agree that we should try and write that into an RFC other than "according to local policy". but the text should clearly not be like 6698, that would technically violate the RFC if your method of local policy is implemented. Paul From nobody Mon Mar 17 12:00:44 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B4C11A04F1 for ; Mon, 17 Mar 2014 12:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-FiXjEH46mO for ; Mon, 17 Mar 2014 12:00:39 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF491A04C1 for ; Mon, 17 Mar 2014 12:00:37 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 4F7B62AADF5; Mon, 17 Mar 2014 19:00:28 +0000 (UTC) Date: Mon, 17 Mar 2014 19:00:28 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140317190028.GG24183@mournblade.imrryr.org> References: <20140315051704.GY21390@mournblade.imrryr.org> <20140317155049.GB24183@mournblade.imrryr.org> <20140317174423.GE24183@mournblade.imrryr.org> <040FB71F-BD97-44A2-A600-B6E69FBD1EE5@vpnc.org> <20140317182219.GF24183@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.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/LUfvnQjr6oA9yXSjhbhaDJiofVg Subject: Re: [dane] Digest Algorithm Agility discussion X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 19:00:41 -0000 On Mon, Mar 17, 2014 at 02:46:41PM -0400, Paul Wouters wrote: > >My proposal modifies the pseudo-code > >to loop over only those records (for each usage/selector) with the > >strongest digest plus any records with matching type 0. > > So I agree with you that is the right approach. I am not sure if I > agree that we should try and write that into an RFC other than > "according to local policy". > > but the text should clearly not be like 6698, that would technically > violate the RFC if your method of local policy is implemented. The motivation to publish the proposed digest algorithm agility algorithm is to encourage (coerce) server operators to make sure that they always use "cross product" TLSA RRsets: for each usage for each selector(for that usage) for each supported digest for each object (of given usage and selector) publish usage selector mtype(digest) {digest(object)} since the set of digests is the same for every object, it is safe to ignore any subset of the non-zero mtypes. Now this is in some sense already implied by 6698 since the server operator does not know which digests might be excluded by a 6698 4.1 local policy. The goal is to both highlight this requirement, and to encourage (require) clients to implement agility rather than leave it to implementor's imagination. In Postfix, users get to configure which digests are acceptable and their priority. The default is to support both SHA2-256 and SHA2-512 and to prefer the latter. -- Viktor. From nobody Mon Mar 17 12:23:51 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FFAA1A0492 for ; Mon, 17 Mar 2014 12:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbeXdXVYs41P for ; Mon, 17 Mar 2014 12:23:47 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id D58261A0488 for ; Mon, 17 Mar 2014 12:23:47 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s2HJNbtu035483 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 17 Mar 2014 12:23:38 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: <20140317182219.GF24183@mournblade.imrryr.org> Date: Mon, 17 Mar 2014 12:23:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <11F238D2-1CF8-4413-AA88-50B10C9982C5@vpnc.org> References: <20140315051704.GY21390@mournblade.imrryr.org> <20140317155049.GB24183@mournblade.imrryr.org> <20140317174423.GE24183@mournblade.imrryr.org> <040FB71F-BD97-44A2-A600-B6E69FBD1EE5@vpnc.org> <20140317182219.GF24183@mournblade.imrryr.org> To: dane@ietf.org X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/5PoqSDEtqL3W-nWEy7TGMd2bD74 Subject: Re: [dane] Digest Algorithm Agility discussion X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 19:23:49 -0000 On Mar 17, 2014, at 11:22 AM, Viktor Dukhovni = wrote: > On Mon, Mar 17, 2014 at 11:14:32AM -0700, Paul Hoffman wrote: >=20 >>> There is no text in 6698 that even approximately suggests that = clients >>> get to use only the records with the strongest (local criteria) = digest. >>=20 >> In Section 4.1: >> o A TLSA RRSet whose DNSSEC validation state is secure MUST be = used >> as a certificate association for TLS unless a local policy would >> prohibit the use of the specific certificate association in the >> secure TLSA RRSet. >=20 > This is not "use strongest". =20 Correct. > This is the opposite. Not correct. It allows local policy of any sort. Some local policies = will be "do not use X because it is weak". > It forces the > use of tarnished, but still acceptable digests even when untarnished > digests are present. =20 It does not because that choice is local policy. > The new proposal is to ignore all but the > strongest, even when the remainder would be usable. That new proposal mandates a view of "strongest". Local policy should = still trump that mandate. > Also the pseudo-code in the appendices loops over *all* "usable" TLSA > RRs (those not banned by 4.1). =20 Correct. And RRs that are prohibited by local policy have already been = removed: for each R in TLSArecords { // unusable records include unknown certUsage, unknown // selectorType, unknown matchingType, erroneous RDATA, and // prohibited by local policy if (R is unusable) { remove R from TLSArecords } } > My proposal modifies the pseudo-code > to loop over only those records (for each usage/selector) with the > strongest digest plus any records with matching type 0. Over-riding local policy is a non-starter, at least in my opinion. Also: your focus on digests is possibly misplaced; why do you believe = that a digest is more likely to be tarnished than a signature algorithm = itself? --Paul Hoffman From nobody Mon Mar 17 13:25:43 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF8641A0223 for ; Mon, 17 Mar 2014 13:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qa0anKg4GmdI for ; Mon, 17 Mar 2014 13:25:39 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 769A51A0200 for ; Mon, 17 Mar 2014 13:25:39 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 145882AB275; Mon, 17 Mar 2014 20:25:31 +0000 (UTC) Date: Mon, 17 Mar 2014 20:25:31 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140317202531.GH24183@mournblade.imrryr.org> References: <20140315051704.GY21390@mournblade.imrryr.org> <20140317155049.GB24183@mournblade.imrryr.org> <20140317174423.GE24183@mournblade.imrryr.org> <040FB71F-BD97-44A2-A600-B6E69FBD1EE5@vpnc.org> <20140317182219.GF24183@mournblade.imrryr.org> <11F238D2-1CF8-4413-AA88-50B10C9982C5@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <11F238D2-1CF8-4413-AA88-50B10C9982C5@vpnc.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/3W-sojbbxvu2clo9OM3idlPS73U Subject: Re: [dane] Digest Algorithm Agility discussion X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 20:25:42 -0000 On Mon, Mar 17, 2014 at 12:23:34PM -0700, Paul Hoffman wrote: > Not correct. It allows local policy of any sort. Some local > policies will be "do not use X because it is weak". The language seems to suggest that refusing a digest by local policy does not depend on the set of digests present in the server's TLSA RRset. If we are to fit my proposal into this "local policy" framework, it would be to block all digests except the strongest found for each usage/selector (thus depended on the RRset content). Is such a local policy acceptable within the context of 6698. Note that in Postfix in addition to ignoring all but the "strongest", administrators get to simply ban some digests (which is how I read 6698) "local policy". So my proposal does not contradict 6698 use of local policy to ban digests, but it lifts the mandate to honour all the rest, and replaces with a mandate to honour only the strongest remaining digest from each (usage, selector) pair. > > use of tarnished, but still acceptable digests even when untarnished > > digests are present. > > It does not because that choice is local policy. This boils down to how we define 6698 local policy. My reading was that one may decide to not support some digests, but nothing quite as subtle as pruning the digests dynamically to just the strongest presented by the server. > > The new proposal is to ignore all but the > > strongest, even when the remainder would be usable. > > That new proposal mandates a view of "strongest". Local policy > should still trump that mandate. It does not specify which is strongest, that is deliberately local policy. It is also local policy which digests to not support even when the server supports nothing better. All it does is refine the 6698 loop to consider at most one (selected by the client using whatever policy it likes) digest algorithm per (usage, selector) combination. > > Also the pseudo-code in the appendices loops over *all* "usable" TLSA > > RRs (those not banned by 4.1). > > Correct. And RRs that are prohibited by local policy have already > been removed: Is it legal per 6698 to make the set of local policy removed RRs depend on the set of RRs presented by the server? If so, I am specifying a partial local policy, in which: - The set of outright banned digests is not fixed. - The preferences of the remaining digests are not fixed. - Once the client decides what to ban and the order of preferences, it bans all but the strongest TLSA RRs from the server. > > My proposal modifies the pseudo-code > > to loop over only those records (for each usage/selector) with the > > strongest digest plus any records with matching type 0. > > Over-riding local policy is a non-starter, at least in my opinion. I don't see this as overriding local policy. There is enough rope in the choice of digests to ban and in the preference order of the rest. Those are my definitions of local policy. Local policy can't for example change the structure of the TLSA record, or the meaning of SHA2-256, ... If we fix a more precise algorithm agility protocol, that fixed part ceases to be local policy, but that's OK, there is still local policy for what is not fixed and it is quite sufficient for being able to reject some algorithms and express preferences among the remainder. > Also: your focus on digests is possibly misplaced; why do you > believe that a digest is more likely to be tarnished than a > signature algorithm itself? I don't. The TLSA record in 6698 employs multiple digest algorithms, I'm specifying an agility protocol for TLSA digest algorithms. Had 6698 specified multiple signature algorithms we'd be talking about those. -- Viktor. From nobody Mon Mar 17 15:23:41 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0A31A0642 for ; Mon, 17 Mar 2014 15:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wt32XKHDXIMl for ; Mon, 17 Mar 2014 15:23:39 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id A46571A063A for ; Mon, 17 Mar 2014 15:23:38 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s2HMNKgf018594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 17 Mar 2014 23:23:20 +0100 (MET) In-Reply-To: To: Paul Wouters Date: Mon, 17 Mar 2014 23:23:20 +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: <20140317222320.443521AC59@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/dane/zjJEs3VJxX_TrzS113KhzLdPNhM Cc: dane WG list Subject: Re: [dane] Digest Algorithm Agility discussion X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 22:23:40 -0000 Paul Wouters wrote: > On Mon, 17 Mar 2014, Viktor Dukhovni wrote: >> >> This is not "use strongest". This is the opposite. It forces the >> use of tarnished, but still acceptable digests even when untarnished >> digests are present. The new proposal is to ignore all but the >> strongest, even when the remainder would be usable. >> >> Also the pseudo-code in the appendices loops over *all* "usable" TLSA >> RRs (those not banned by 4.1). > > Okay, I understand your point now. The text in 6698 is indeed doing some > half weird local policy client dictation that it should not have done. DANE does not have any "tarnished" hash algorithms. DANE does not allow SHA1 at all and needs SHA-256 as a minimum. The weakest "link" is therefore the hash that is used by DNSSEC for the digital signature of the RRSET, which currently is SHA-1. As long as DNSSEC does not require "stronger than SHA-256", it will be pure bike-shedding to prefer a SHA-512 TLSA record over a SHA-256 one. And you probably do not want to hold your breath until DNSSEC has overcome SHA-1 based signatures. The notion that hashes allowed by DANE can be ordered by strength/weakness is also wrong. In the future, hashes with the same output size might get a codepoint assigned and used, and some of them might not be implemented by all DANE clients. Think of hashes from the russian GOST family of algorithms. Usage of SHA-512/256 over SHA-256 is not motivated by algorithm strength concerns, but rather by raw hash throughput considerations on 64-bit platforms. -Martin From nobody Mon Mar 17 15:34:18 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 027F11A032C for ; Mon, 17 Mar 2014 15:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.781 X-Spam-Level: X-Spam-Status: No, score=-1.781 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, SPOOF_COM2COM=2.048, SPOOF_COM2OTH=2.723] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O4RZ2d5AswbQ for ; Mon, 17 Mar 2014 15:34:16 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id F2C461A0322 for ; Mon, 17 Mar 2014 15:34:15 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s2HMY7iu020059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 17 Mar 2014 23:34:07 +0100 (MET) In-Reply-To: <20140315024203.GW21390@mournblade.imrryr.org> To: dane@ietf.org Date: Mon, 17 Mar 2014 23:34:07 +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: <20140317223407.679571AC59@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/dane/QX-ZVojLlVQz4q6fBpP4nTo_uj0 Subject: Re: [dane] Review of DANE SMTP draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 22:34:18 -0000 Viktor Dukhovni wrote: > On Fri, Mar 14, 2014 at 09:01:48PM -0400, James Cloos wrote: > >>> The folks at Postini have a wildcard cert for "*.psmtp.com" and >>> clients publish MX records of the form: >>> >>> verisign.com. IN MX 100 verisign.com.s6a1.psmtp.com. >>> verisign.com. IN MX 200 verisign.com.s6a2.psmtp.com. >>> verisign.com. IN MX 300 verisign.com.s6b1.psmtp.com. >>> verisign.com. IN MX 400 verisign.com.s6b2.psmtp.com. >> >> For some historical context, mozilla's original wildcarded ssl implement- >> ation also allowed an *. to match any number of labels. >> >> Several sites were broken by the change to limit a wildcard to a single label. > > I take it you're suggesting to not perpetuate Postini's abuse of > wildcard certs? Implementations might choose to be more liberal, > but servers can't expect multi-label wildcard support. Right? See: http://tools.ietf.org/html/rfc6125#section-6.4.3 6.4.3. Checking of Wildcard Certificates A client employing this specification's rules MAY match the reference identifier against a presented identifier whose DNS domain name portion contains the wildcard character '*' as part or all of a label (following the description of labels and domain names in [DNS-CONCEPTS]). For information regarding the security characteristics of wildcard certificates, see Section 7.2. If a client matches the reference identifier against a presented identifier whose DNS domain name portion contains the wildcard character '*', the following rules apply: 1. The client SHOULD NOT attempt to match a presented identifier in which the wildcard character comprises a label other than the left-most label (e.g., do not match bar.*.example.net). 2. If the wildcard character is the only character of the left-most label in the presented identifier, the client SHOULD NOT compare against anything but the left-most label of the reference identifier (e.g., *.example.com would match foo.example.com but not bar.foo.example.com or example.com). 3. The client MAY match a presented identifier in which the wildcard character is not the only character of the label (e.g., baz*.example.net and *baz.example.net and b*z.example.net would be taken to match baz1.example.net and foobaz.example.net and buzz.example.net, respectively). However, the client SHOULD NOT attempt to match a presented identifier where the wildcard character is embedded within an A-label or U-label [IDNA-DEFS] of an internationalized domain name [IDNA-PROTO]. -Martin From nobody Mon Mar 17 15:53:42 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3C41A0646 for ; Mon, 17 Mar 2014 15:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-nHo1e4jwLO for ; Mon, 17 Mar 2014 15:53:38 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 068091A01D7 for ; Mon, 17 Mar 2014 15:53:37 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3894C2AB275; Mon, 17 Mar 2014 22:53:29 +0000 (UTC) Date: Mon, 17 Mar 2014 22:53:29 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140317225329.GK24183@mournblade.imrryr.org> References: <20140317222320.443521AC59@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140317222320.443521AC59@ld9781.wdf.sap.corp> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/DxtzqXf1aB97xvHqzW6tddcB2c8 Subject: Re: [dane] Digest Algorithm Agility discussion X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 22:53:40 -0000 On Mon, Mar 17, 2014 at 11:23:20PM +0100, Martin Rex wrote: > DANE does not have any "tarnished" hash algorithms. Not yet. The point of algorithm agility is to plan for the future. Yes, it is currently difficult to imagine practical weaknesses in SHA2-256, but time marches on. > DANE does not allow SHA1 at all and needs SHA-256 as a minimum. Yes. > The weakest "link" is therefore the hash that is used by DNSSEC > for the digital signature of the RRSET, which currently is SHA-1. My zones are signed, or are about to be signed with algorithm 8, RSASHA256. > As long as DNSSEC does not require "stronger than SHA-256", it will > be pure bike-shedding to prefer a SHA-512 TLSA record over a SHA-256 one. We're specifying an agility algorithm. Nobody has to publish SHA2-512 digests. Only SHA2-256 is mandatory at this time. When SHA2-512 is published, it may as well be used in preference to SHA2-256. Getting the specification right from the start avoids problems later. > And you probably do not want to hold your breath until DNSSEC has > overcome SHA-1 based signatures. There are existing zones that are signed with RSA, NSEC3, SHA256. > The notion that hashes allowed by DANE can be ordered by strength/weakness > is also wrong. Nobody is suggesting ordering by the 8-bit mtype ordinal or mere hash length. The ordering is to be based on client-defined preference for the underlying digest algorithms. > In the future, hashes with the same output size might get a codepoint > assigned and used, and some of them might not be implemented by all DANE > clients. That's fine. Servers can publish all mandatory to implement algorithms, plus any others of their choice. > Usage of SHA-512/256 over SHA-256 is not motivated by algorithm strength > concerns, but rather by raw hash throughput considerations on 64-bit > platforms. And yet SHA2-512 likely has (absurdly) greater collision resistance than SHA2-256. Right now both are far out of reach of practical attacks. This may not always be the case, and, especially when servers introduce various other hashes, clients may want to use preferred digests. I am not proposing anything particularly radical. It is a fairly obvious and conservative proposal. "Negotiate" (pick from server's menu of choices) an optimal digest algorithm and use only that one and not the rest. The objections are a bit surprising. (I too would like to believe that SHA2-256 will never be compromised, but it seems prudent to plan for the worst). To turn this around, why should clients run through all of the server's published digests by default, when any one should be enough? Since servers don't know which algorithms clients disable by local policy, it is a mistake to publish an object's digest with only a subset of the algorithms used to publish other objects. -- Viktor. From nobody Mon Mar 17 16:07:01 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DFA31A0649 for ; Mon, 17 Mar 2014 16:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLgRhOnXPZAu for ; Mon, 17 Mar 2014 16:06:56 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 33B0D1A063B for ; Mon, 17 Mar 2014 16:06:56 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id A3BAD2AB274; Mon, 17 Mar 2014 23:06:46 +0000 (UTC) Date: Mon, 17 Mar 2014 23:06:46 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140317230646.GL24183@mournblade.imrryr.org> References: <20140315024203.GW21390@mournblade.imrryr.org> <20140317223407.679571AC59@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140317223407.679571AC59@ld9781.wdf.sap.corp> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/oRMof8fpvucQogJjAgzT5G_bpCc Subject: Re: [dane] Review of DANE SMTP draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 23:06:58 -0000 On Mon, Mar 17, 2014 at 11:34:07PM +0100, Martin Rex wrote: > 2. If the wildcard character is the only character of the left-most > label in the presented identifier, the client SHOULD NOT compare > against anything but the left-most label of the reference > identifier (e.g., *.example.com would match foo.example.com but > not bar.foo.example.com or example.com). I am aware of this SHOULD NOT. The question is whether this is the right behaviour for opportunistic DANE TLS. There is no user to "click OK", and if Postini-style wildcard certs are likely to be employed or need to be employed, then perhaps the right choice for SMTP is to tolerate multi-label wildcards. I am not insisting one way or the other, just wondering whether there is consensus. Fortunately, there is a UTA draft on name checks for SMTP, and its authors have invited me to pitch in. Their draft defines wildcards to match a single label, and this question is perhaps best dealt with on the UTA list (where I may again run into Martin and the rest of our fine DANE crew, but it seems to be a more natural forum for what is I think more of an application question). So most likely SMTP name checks will not specifically endorse multi-label wildcards, but if it is OK with this group, I'd like to move this specific issue to that forum. -- Viktor. From nobody Mon Mar 17 16:33:39 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3939A1A064C for ; Mon, 17 Mar 2014 16:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qdYQmN5eQF_7 for ; Mon, 17 Mar 2014 16:33:35 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 96AC91A064B for ; Mon, 17 Mar 2014 16:33:35 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s2HNXPmH003433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 18 Mar 2014 00:33:25 +0100 (MET) In-Reply-To: <20140316205428.GG24183@mournblade.imrryr.org> To: dane@ietf.org Date: Tue, 18 Mar 2014 00:33:25 +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: <20140317233325.601E81AC59@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/dane/FQyCUeHAX3H43TClqymhRy5GDsE Subject: Re: [dane] DANE-EE(3) certificate matching rules? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 23:33:37 -0000 Viktor Dukhovni wrote: > > I may have gone a bit further than necessary. The main goal is to > make DANE authentication usable in protocols with no user to "click > OK". To this end I want to avoid the most common operational > failures with PKIX. Therefore I propose that: > > - In addition to name checks, expiration checks also be > performed via the TLSA RR signature lifetime, rather than > the certificate expiration date. The TLSA record is updated > frequently as the DNSSEC zone is periodically re-signed. This > ensures that there are no surprise expirations. Certificates > can be replaced at the operator's convenience. > > Any comments? Can the above be the final consensus on this topic? I strongly dislike this idea, and would really appreciate instead a requirement that any X.509 certificates that are generated for use with DANE-EE(3) *MUST* be generated with a sufficiently liberal validity period that interop is not going to break if a DANE client enforces the X.509 asserted validity period. -Martin From nobody Mon Mar 17 16:54:26 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75D701A01E1 for ; Mon, 17 Mar 2014 16:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QwCvrbA29J-8 for ; Mon, 17 Mar 2014 16:54:22 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id C45551A0325 for ; Mon, 17 Mar 2014 16:54:22 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 510D22AB274; Mon, 17 Mar 2014 23:54:13 +0000 (UTC) Date: Mon, 17 Mar 2014 23:54:13 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140317235413.GN24183@mournblade.imrryr.org> References: <20140316205428.GG24183@mournblade.imrryr.org> <20140317233325.601E81AC59@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140317233325.601E81AC59@ld9781.wdf.sap.corp> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/wki5r-PyXRDcoutrJ9gWCIhdPc0 Subject: Re: [dane] DANE-EE(3) certificate matching rules? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 23:54:25 -0000 On Tue, Mar 18, 2014 at 12:33:25AM +0100, Martin Rex wrote: > > I may have gone a bit further than necessary. The main goal is to > > make DANE authentication usable in protocols with no user to "click > > OK". To this end I want to avoid the most common operational > > failures with PKIX. Therefore I propose that: > > > > - In addition to name checks, expiration checks also be > > performed via the TLSA RR signature lifetime, rather than > > the certificate expiration date. The TLSA record is updated > > frequently as the DNSSEC zone is periodically re-signed. This > > ensures that there are no surprise expirations. Certificates > > can be replaced at the operator's convenience. > > > > Any comments? Can the above be the final consensus on this topic? > > I strongly dislike this idea, and would really appreciate instead > a requirement that any X.509 certificates that are generated for use > with DANE-EE(3) *MUST* be generated with a sufficiently liberal > validity period that interop is not going to break if a DANE client > enforces the X.509 asserted validity period. I sympathize with the instinct. The problem is that the longer that interval is, the greater the surprise that the (long forgotten) certificate has expired. At least with my proposal the expiration can be used as a kinder-gentler reminder to the server operator that it might be a good time to replace the cert (often what happens with many PKIX certs that get replaced in a hurry shortly *after* expiring). With DANE-EE(3), the server operator can audit his systems and note that some certs are overdue for replacement. Using the continued publication of the TLSA record in DNS as continued validity of the certificate is much simpler, and avoids operational difficulties that might otherwise derail adoption of the protocol. Having a protocol that is actually used is I think the primary goal. At the moment MTA SMTP clients ignore TLS certs, names, expiration dates and all (and often use anon cipher-suites). Decoupling the expiration from the certificate, makes operational errors less likely. Note that with "3 1 1" and "3 1 2" (which are likely to be the most widely used), the expiration is not even covered by the TLSA digest, and the certificate expiration can be freely modified by anyone, without any objection from the verifier. In other words, with "IN TLSA 3 1 ?", the expiration field is provably superfluous. With "IN TLSA 3 0 1" it arguably represents the original intent of the publisher (long forgotten by the time expiration rolls around). Our new security protocols will cut some corners and break with the past, where necessary, to enable broad adoption. A protocol that is too fragile won't get adopted. The proverbial "perfect" as the enemy of the "good". -- Viktor. From nobody Tue Mar 18 04:27:11 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2EF51A03C9 for ; Tue, 18 Mar 2014 04:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qlEKiB1WWri4 for ; Tue, 18 Mar 2014 04:27:08 -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 8568B1A03C7 for ; Tue, 18 Mar 2014 04:27:08 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 482ECC941E for ; Tue, 18 Mar 2014 11:26:47 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1395142020; bh=CSzECV/aKXQ5oI5wmtpo6xoh5I1Nh9uTcUvDl/dJ6RQ=; h=To:From:References:Subject:In-reply-to:Date; b=IdLhWHMpugTL0uAAwX+dv7PFYQzRrUnqmWQcoaZOD5gBg3c6ED2PwVDisICXaTt5m jgDDOyn3dVf+/EG4ncL8lYxeuOK8YCz0J7Ke7mtgoMjZOLlnlradpc4PjhZXnS2AwV Y1nogbXD8A9JYECkCOB+zy8tf5c+bIiqncTHcNRw= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP for ; Tue, 18 Mar 2014 11:26:47 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id AC4AB160060 for ; Tue, 18 Mar 2014 11:27:51 +0000 (UTC) Received: from rock.dv.isc.org (dsl092-002-166.sfo1.dsl.speakeasy.net [66.92.2.166]) by zmx1.isc.org (Postfix) with ESMTPSA id A121E16004B for ; Tue, 18 Mar 2014 11:27:51 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 885B21190C03 for ; Tue, 18 Mar 2014 22:26:47 +1100 (EST) To: dane@ietf.org From: Mark Andrews References: <20140317222320.443521AC59@ld9781.wdf.sap.corp> <20140317225329.GK24183@mournblade.imrryr.org> In-reply-to: Your message of "Mon, 17 Mar 2014 22:53:29 -0000." <20140317225329.GK24183@mournblade.imrryr.org> Date: Tue, 18 Mar 2014 22:26:47 +1100 Message-Id: <20140318112647.885B21190C03@rock.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Archived-At: http://mailarchive.ietf.org/arch/msg/dane/EGdd7bs5MccmFTNVm177zvcWZ2Q Subject: Re: [dane] Digest Algorithm Agility discussion X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 11:27:09 -0000 This whole argument of weakest vs strongest was had years ago in DNSSEC and quite frankly is a waste of time trying to pick the strongest as you are often comparing apples and oranges. DNSSEC validators just have a way to say "we no longer trust this algorithm" and once that is set all records with that algorithm are ignored when doing validation regardless of whether there is code to support that algorithm or not. DANE implementations need a way to do the same for matching type. Stop trying to over engineer this. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Mar 18 07:14:12 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8B271A037C for ; Tue, 18 Mar 2014 07:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oyGoBRFLQICA for ; Tue, 18 Mar 2014 07:14:07 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id A65261A012F for ; Tue, 18 Mar 2014 07:14:06 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 494E82AB22D; Tue, 18 Mar 2014 14:13:56 +0000 (UTC) Date: Tue, 18 Mar 2014 14:13:56 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140318141356.GO24183@mournblade.imrryr.org> References: <20140317222320.443521AC59@ld9781.wdf.sap.corp> <20140317225329.GK24183@mournblade.imrryr.org> <20140318112647.885B21190C03@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140318112647.885B21190C03@rock.dv.isc.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/UtgIpagR4vgH8mA_fQHac19C2Zc Subject: Re: [dane] Digest Algorithm Agility discussion X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 14:14:10 -0000 On Tue, Mar 18, 2014 at 10:26:47PM +1100, Mark Andrews wrote: > This whole argument of weakest vs strongest was had years ago in > DNSSEC and quite frankly is a waste of time trying to pick the > strongest as you are often comparing apples and oranges. The client ranks the algorithms by preference, in much the same way that TLS ranks cipher-suites by preference and in TLSv1.2 even signature algorithms by preference. It does not matter whether the rankings are objectively justified. The client uses its most preferred digest (perhaps it has hardware support for it). > DNSSEC validators just have a way to say "we no longer trust this > algorithm" and once that is set all records with that algorithm are > ignored when doing validation regardless of whether there is code > to support that algorithm or not. If things are as you describe, this works poorly, since clients continue to accept weak signatures on zones that have both strong and weak signatures (RSA/SHA1 and RSA/SHA256) if the strong signature fails to match the client trusts the weak, right? It becomes difficult to phase out a weak algorithm because the incentive to publish the strong along with the weak is reduced as the benefit from doing so is delayed until clients actually discontinue the weak algorithm. -- Viktor. From nobody Tue Mar 18 07:38:11 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17B221A04BC for ; Tue, 18 Mar 2014 07:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mzrlrw3Qk67R for ; Tue, 18 Mar 2014 07:38:08 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 1516D1A04CD for ; Tue, 18 Mar 2014 07:38:08 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 70CB82AB22D; Tue, 18 Mar 2014 14:37:59 +0000 (UTC) Date: Tue, 18 Mar 2014 14:37:59 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140318143759.GP24183@mournblade.imrryr.org> References: <20140317222320.443521AC59@ld9781.wdf.sap.corp> <20140317225329.GK24183@mournblade.imrryr.org> <20140318112647.885B21190C03@rock.dv.isc.org> <20140318141356.GO24183@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140318141356.GO24183@mournblade.imrryr.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/llkWNPAOZTpE-2SjBybOdT_ACoQ Subject: Re: [dane] Digest Algorithm Agility discussion (checkpoint) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 14:38:10 -0000 Thanks to everyone who contributed to this point. My conclusions so far: - Since "local policy" may exclude an arbitrary subset of the digest algorithms from consideration, whether the digest algorithm employed by clients is as I suggest, or not, server operators MUST apply the SAME set of digests to all objects published in a TLSA RRset, since otherwise the "visibility" of objects in the RRset will be client dependent. - Given the above clients either MAY or SHOULD apply the algorithm I propose, it provides incremental benefit before weaker algorithms are dropped, and reduces risks to servers that publish weaker algorithms. For example, with opportunistic TLS, client and server implementations can safely leave weaker cipher-suites at a low priority on their cipher-lists, because these will not be chosen when stronger options are available. When nothing better is available, these are at least better than cleartext. If "local policy" per 6698, includes the possibility of "adaptive local policy" that depends on the server's TLSA RRset content, then my proposal is already an implicit MAY per 6698. I'd like to propose to elevate it to a SHOULD, while emphasizing the MUST for the server to publish cross-product TLSA RRsets when employing multiple digests. Reminder: the proposal is that clients SHOULD apply some local ranking to the digest algorithms, and only use those records for each (usage, selector) combination that either have a matching type of Full(0) or have the best ranking among all digests used with that (usage, selector). Clients SHOULD have a way to completely disable algorithms. -- Viktor. From nobody Tue Mar 18 09:21:23 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32D431A06E1 for ; Tue, 18 Mar 2014 09:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJopHj9SI8ho for ; Tue, 18 Mar 2014 09:21:20 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id BDF3A1A0476 for ; Tue, 18 Mar 2014 09:21:20 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id A6144800AF; Tue, 18 Mar 2014 12:21:11 -0400 (EDT) Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s2IGLAP7027765; Tue, 18 Mar 2014 12:21:11 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 18 Mar 2014 12:21:10 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Martin Rex In-Reply-To: <20140317233325.601E81AC59@ld9781.wdf.sap.corp> Message-ID: References: <20140317233325.601E81AC59@ld9781.wdf.sap.corp> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/dane/dGtzzjqLNQIzJTLug1hamBuAyM0 Cc: dane WG list Subject: Re: [dane] DANE-EE(3) certificate matching rules? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 16:21:22 -0000 On Tue, 18 Mar 2014, Martin Rex wrote: > I strongly dislike this idea, and would really appreciate instead > a requirement that any X.509 certificates that are generated for use > with DANE-EE(3) *MUST* be generated with a sufficiently liberal > validity period that interop is not going to break if a DANE client > enforces the X.509 asserted validity period. You can't because we now have EE certs that could only contain SBKI and no other x.509 legacy. Paul From nobody Tue Mar 18 10:40:21 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 294741A0418 for ; Tue, 18 Mar 2014 10:40:20 -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=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gRxcDvV8Cs1G for ; Tue, 18 Mar 2014 10:40:18 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id CAE5F1A0296 for ; Tue, 18 Mar 2014 10:40:18 -0700 (PDT) Received: from Philemon (68-116-62-210.static.mdfd.or.charter.com [68.116.62.210]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 6A19C38F07; Tue, 18 Mar 2014 10:40:10 -0700 (PDT) From: "Jim Schaad" To: "'Mark Andrews'" , References: <20140317222320.443521AC59@ld9781.wdf.sap.corp> <20140317225329.GK24183@mournblade.imrryr.org> <20140318112647.885B21190C03@rock.dv.isc.org> In-Reply-To: <20140318112647.885B21190C03@rock.dv.isc.org> Date: Tue, 18 Mar 2014 10:38:22 -0700 Message-ID: <034101cf42d0$dbf12b00$93d38100$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGxy6ebEn9/u3emUDYYLc73IoNHVwLXWW52AyQUopwBfvaxT5rmNyMA Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/dane/oAyFNr1wJzYaOZoTu966ImXAXE4 Subject: Re: [dane] Digest Algorithm Agility discussion X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 17:40:20 -0000 > -----Original Message----- > From: dane [mailto:dane-bounces@ietf.org] On Behalf Of Mark Andrews > Sent: Tuesday, March 18, 2014 4:27 AM > To: dane@ietf.org > Subject: Re: [dane] Digest Algorithm Agility discussion > > > This whole argument of weakest vs strongest was had years ago in DNSSEC and > quite frankly is a waste of time trying to pick the strongest as you are often > comparing apples and oranges. > > DNSSEC validators just have a way to say "we no longer trust this algorithm" > and once that is set all records with that algorithm are ignored when doing > validation regardless of whether there is code to support that algorithm or > not. > > DANE implementations need a way to do the same for matching type. > > Stop trying to over engineer this. +1 - At any given time this is a binary choice. The hash algorithm either is or is not acceptable. Jim > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From nobody Tue Mar 18 11:14:21 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA821A0768 for ; Tue, 18 Mar 2014 11:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jw105Xtn5wBo for ; Tue, 18 Mar 2014 11:14:05 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 62F7F1A0769 for ; Tue, 18 Mar 2014 11:09:45 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s2II9ZtY087328 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 18 Mar 2014 11:09:36 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: <20140318143759.GP24183@mournblade.imrryr.org> Date: Tue, 18 Mar 2014 11:09:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <48DE266C-3800-4428-A9E5-F0A732D35D9D@vpnc.org> References: <20140317222320.443521AC59@ld9781.wdf.sap.corp> <20140317225329.GK24183@mournblade.imrryr.org> <20140318112647.885B21190C03@rock.dv.isc.org> <20140318141356.GO24183@mournblade.imrryr.org> <20140318143759.GP24183@mournblade.imrryr.org> To: dane@ietf.org X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/gbjlNGeHoYgFfWAOjTliohUyTho Subject: Re: [dane] Digest Algorithm Agility discussion (checkpoint) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 18:14:11 -0000 On Mar 18, 2014, at 7:37 AM, Viktor Dukhovni = wrote: >=20 > Thanks to everyone who contributed to this point. My conclusions > so far: >=20 > - Since "local policy" may exclude an arbitrary subset of the > digest algorithms from consideration, whether the digest > algorithm employed by clients is as I suggest, or not, server > operators MUST apply the SAME set of digests to all objects > published in a TLSA RRset, since otherwise the "visibility" > of objects in the RRset will be client dependent. This discussion keeps getting into the "we're the Internet Police" = realm. First it is "we know which hash algorithms are too weak", and now = it is "operators must do this action or else different clients will = behave differently". If an operator wants to use a particular hash algorithm *for any = reason*, we should not stop them. > - Given the above clients either MAY or SHOULD apply the > algorithm I propose, it provides incremental benefit before > weaker algorithms are dropped, and reduces risks to servers > that publish weaker algorithms. >=20 > For example, with opportunistic TLS, client and server > implementations can safely leave weaker cipher-suites at a > low priority on their cipher-lists, because these will not be > chosen when stronger options are available. When nothing > better is available, these are at least better than cleartext. It would only have that benefit if there was agreement from above on = what "weaker" was and whether we should force people to limit themselves = to our algorithms. > If "local policy" per 6698, includes the possibility of "adaptive > local policy" that depends on the server's TLSA RRset content, then > my proposal is already an implicit MAY per 6698. =20 Exactly right. > I'd like to propose > to elevate it to a SHOULD, while emphasizing the MUST for the server > to publish cross-product TLSA RRsets when employing multiple digests. This is insane. You are creating operational failure cases for servers = for no benefit until one of the hash algorithms has a significant = weakness. Even then, the damage you are proposing quite outweighs the = chance of any real damage from the use of a weakened hash. Hashes weaken = very slowly, and there is plenty of time to alert people to use stronger = hashes. > Reminder: the proposal is that clients SHOULD apply some local > ranking to the digest algorithms, and only use those records for > each (usage, selector) combination that either have a matching type > of Full(0) or have the best ranking among all digests used with > that (usage, selector). Clients SHOULD have a way to completely > disable algorithms. They do: it's called local policy. --Paul Hoffman= From nobody Tue Mar 18 12:20:25 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 868B51A0655 for ; Tue, 18 Mar 2014 12:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTnDiXMt-WT3 for ; Tue, 18 Mar 2014 12:20:21 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id A21E81A0455 for ; Tue, 18 Mar 2014 12:20:21 -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 05AB88A031 for ; Tue, 18 Mar 2014 19:20:12 +0000 (UTC) Date: Tue, 18 Mar 2014 15:20:07 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20140318192007.GA28214@mx1.yitter.info> References: <20140317222320.443521AC59@ld9781.wdf.sap.corp> <20140317225329.GK24183@mournblade.imrryr.org> <20140318112647.885B21190C03@rock.dv.isc.org> <20140318141356.GO24183@mournblade.imrryr.org> <20140318143759.GP24183@mournblade.imrryr.org> <48DE266C-3800-4428-A9E5-F0A732D35D9D@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48DE266C-3800-4428-A9E5-F0A732D35D9D@vpnc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/_VQWgGVN0XdpaiuPOSjX7Mq3Aro Subject: Re: [dane] Digest Algorithm Agility discussion (checkpoint) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 19:20:23 -0000 On Tue, Mar 18, 2014 at 11:09:31AM -0700, Paul Hoffman wrote: > > If an operator wants to use a particular hash algorithm *for any reason*, we should not stop them. > I would say this instead as, "We will not be able to stop them anyway, so we should focus on interoperability and maybe some sound advice," but I know lots of people will disagree. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Tue Mar 18 13:00:18 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 166BB1A02FB for ; Tue, 18 Mar 2014 13:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.414 X-Spam-Level: X-Spam-Status: No, score=-0.414 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5Qp92E_PGvf for ; Tue, 18 Mar 2014 13:00:16 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 398C91A0296 for ; Tue, 18 Mar 2014 13:00:16 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D22ED2AAD62; Tue, 18 Mar 2014 20:00:04 +0000 (UTC) Date: Tue, 18 Mar 2014 20:00:04 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140318200004.GU24183@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <034101cf42d0$dbf12b00$93d38100$@augustcellars.com> <48DE266C-3800-4428-A9E5-F0A732D35D9D@vpnc.org> <20140318192007.GA28214@mx1.yitter.info> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/4cG-QECJk7PBYHsAc5t6okgePm4 Subject: Re: [dane] Digest Algorithm Agility discussion (checkpoint) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 20:00:18 -0000 On Tue, Mar 18, 2014 at 03:20:07PM -0400, Andrew Sullivan wrote: > I would say this instead as, "We will not be able to stop them anyway, > so we should focus on interoperability and maybe some sound advice," > but I know lots of people will disagree. On Tue, Mar 18, 2014 at 11:09:31AM -0700, Paul Hoffman wrote: > [ Lots of misinterpretation and inaccuracies about the proposed mechanism. ] > > This is insane. You are creating operational failure cases for servers > for no benefit until one of the hash algorithms has a significant weakness. > Even then, the damage you are proposing quite outweighs the chance of any > real damage from the use of a weakened hash. Hashes weaken very slowly, > and there is plenty of time to alert people to use stronger hashes. On Tue, Mar 18, 2014 at 10:38:22AM -0700, Jim Schaad wrote: > > Stop trying to over engineer this. > > +1 - At any given time this is a binary choice. The hash algorithm either > is or is not acceptable. I don't think I to need to restate the merits of the incremental security as stronger digests are added before weaker ones are disabled. My sense is that regardless, there is not much enthusias for negotiating a single digest based on what digests the server offers, with the client choosing its most preferred one. Is this an accurate summary of the group's consensus view? Does anyone want to defend the view of TLSA digests as a menu of options from which the client can choose one? If not, I will drop the digest agility portion of the SMTP draft. In the OPs draft we can encourage server operators (SHOULD) to apply all digests equally to all objects, because that's more robust in the face of local policy, and results when this is not done may not be what the operator wanted. Anyone else? -- Viktor. From nobody Tue Mar 18 14:09:37 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAFF81A0417 for ; Tue, 18 Mar 2014 14:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ln8FhQ64TR_v for ; Tue, 18 Mar 2014 14:09:25 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id B4A971A0421 for ; Tue, 18 Mar 2014 14:09:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1395176956; d=isode.com; s=selector; i=@isode.com; bh=xPfVzLJbenTJxT0Ih65AuiFkYJ4RLQ4yn8/fJaZSc7k=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=Kz0HzWM8jV0AYSYHV5df6etxMLpaZZPP9o4iceUgX6sRFaJp6vz9yoUjr91e29IwgLJ/L+ 7Zq2RNeI+LMFAjtD6YAXFCL7oT4spqrJFPrwqmohM+0fqYAisNgUUoyFgizBPgqmH+vp5l 7+ycFYKp0vIXc61R1RZfjASzA1WJS2Q=; Received: from [192.168.0.12] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 18 Mar 2014 21:09:16 +0000 X-SMTP-Protocol-Errors: PIPELINING From: Alexey Melnikov X-Mailer: iPad Mail (11B651) In-Reply-To: <20140314174101.GU21390@mournblade.imrryr.org> Date: Tue, 18 Mar 2014 21:13:59 +0000 Cc: "dane@ietf.org" Message-Id: References: <20140314052342.GQ21390@mournblade.imrryr.org> <53233939.9020703@isode.com> <20140314174101.GU21390@mournblade.imrryr.org> To: "dane@ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dane/qNrBEyVmNXIPog_fCYUFOKHCpeU Subject: Re: [dane] Review of DANE SMTP draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 21:09:32 -0000 Hi Victor, > On 14 Mar 2014, at 17:41, Viktor Dukhovni wrote= : >=20 > On Fri, Mar 14, 2014 at 05:15:37PM +0000, Alexey Melnikov wrote: >=20 >>> [ Second-last paragraph of 2.2 ] >>>=20 >>> Is it not obvious that this means the misguided: >>>=20 >>> example.com. IN MX 0 192.0.2.1. >>=20 >> No, it is not obvious, otherwise I wouldn't have asked. >=20 > The original sentence reads: >=20 > Similarly, when an MX RRset incorrectly lists a network address in > lieu of an MX hostname, if the MTA chooses to connect to the network > address, DANE TLSA does not apply for such a connection. >=20 > Anyone else feel this deserves an example? There are some poor > sods who attempt to stuff IPv4 addresses into MX hostname RRDATA, > and some MTAs may do them a favour and handle this broken syntax. > In that case DANE is clearly out of scope. Ok, after thinking more about this, your current text looks Ok as is. >=20 >>> In 6125 (where the exceptions dominate the rules) there are no >>> provisions for matching one of a set of candidate names. >>=20 >> I am not sure I understand. If there are multiple subjectAltName >> values of the same type, any match works. Unless you mean something >> else. >=20 > No, the SMTP and SRV drafts specify that the client has multiple > names it is willing to accept, any one of which may match one of > the many SAN names in the peer certificate. There can be up to > three names. The original name before redirection by MX or SRV, > the securely CNAME expanded version of that if different, and > finally the TLSA base domain of the server. RFC 6125 allows for that, so I see no conflict. >=20 >>> I don't know whether the Postfix (on by default) Postini work-around >>> deserves IETF blessing. Perhaps it would be better for Postini to >>> fix their certificates, >>=20 >> I think so, yes. >=20 > That is Postini fix their mess? Yes. > Or SMTP support multi-label wildcards? I suppose this might be another reasonable outcome, if we can get IETF conse= nsus on this. From nobody Wed Mar 19 03:28:57 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD341A06AF for ; Wed, 19 Mar 2014 03:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZ3aRt12n6DT for ; Wed, 19 Mar 2014 03:28:48 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id AA3091A071B for ; Wed, 19 Mar 2014 03:28:48 -0700 (PDT) Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s2JASeTd014601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 19 Mar 2014 06:28:40 -0400 Received: from pspacek.brq.redhat.com (vpn1-4-232.ams2.redhat.com [10.36.4.232]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s2JAScZZ016298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 19 Mar 2014 06:28:39 -0400 Message-ID: <53297155.8070201@redhat.com> Date: Wed, 19 Mar 2014 11:28:37 +0100 From: Petr Spacek Organization: Red Hat User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: dane@ietf.org References: <20140226173630.GZ21390@mournblade.imrryr.org> <20140226182432.GB21390@mournblade.imrryr.org> <20140226191144.GC21390@mournblade.imrryr.org> In-Reply-To: <20140226191144.GC21390@mournblade.imrryr.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/WEtgw2DWkGueNmH5uSiizEuXJtw Subject: Re: [dane] An AD bit discussion X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 10:28:55 -0000 Hello list, On 26.2.2014 20:11, Viktor Dukhovni wrote: > On Wed, Feb 26, 2014 at 07:02:45PM +0000, Tony Finch wrote: > >> Viktor Dukhovni wrote: >> >>> I think it requires EDNS0, >> >> The AD bit is in the message header not the OPT pseudo-RR, so >> syntactically it doesn't require EDNS0. BIND works OK (try >> dig +qr +noedns). However the spec is silent on this matter. >> http://tools.ietf.org/html/rfc6840#page-10 >> Also I think it is arguable that RFC 4035 says servers should set the >> AD flag in the response regardless of whether the client indicates >> it is security-aware. But implementations do not do that. > > You're right about the AD bit of course, I was thinking of "DO". > Below setting either "AD=1" or "DO=1" elicits a validated response > from unbound, but with "DO=1" additional RRSIG records are returned. > The libresolv API does not currently expose a portable mechanism > for setting AD=1 in requests. I have heard that there was a discussion about AD bit handling at IETF 89. Could somebody summarize it, please? I understand that everybody is more interested in DANE and DNS-privacy but I would like to finish this discussion and either drop the AD-bit special handling altogether or move to implementation phase :-) Thank you very much for your time! -- Petr^2 Spacek From nobody Wed Mar 19 07:08:56 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF1101A0767 for ; Wed, 19 Mar 2014 07:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPE9q3QgnCd0 for ; Wed, 19 Mar 2014 07:08:52 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 616271A076A for ; Wed, 19 Mar 2014 07:08:52 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.174.1; Wed, 19 Mar 2014 10:08:02 -0400 Received: from postmark.nist.gov (129.6.16.94) by WSXGHUB1.xchange.nist.gov (129.6.18.96) with Microsoft SMTP Server (TLS) id 8.3.327.1; Wed, 19 Mar 2014 10:08:41 -0400 Received: from 6-140.antd.nist.gov (6-140.antd.nist.gov [129.6.140.6]) by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id s2JE8aL7003625 for ; Wed, 19 Mar 2014 10:08:36 -0400 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Scott Rose In-Reply-To: <20140318200004.GU24183@mournblade.imrryr.org> Date: Wed, 19 Mar 2014 10:08:38 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <2D59247F-0B0F-4CE7-A4D2-F57EE4167099@gmail.com> References: <20140318200004.GU24183@mournblade.imrryr.org> To: X-Mailer: Apple Mail (2.1874) X-NIST-MailScanner-Information: Archived-At: http://mailarchive.ietf.org/arch/msg/dane/XDpm8AOOwtsB4sF9tr7cY9UCSA8 Subject: Re: [dane] Digest Algorithm Agility discussion (checkpoint) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 14:08:55 -0000 On Mar 18, 2014, at 4:00 PM, Viktor Dukhovni = wrote: >=20 > My sense is that regardless, there is not much enthusias for > negotiating a single digest based on what digests the server offers, > with the client choosing its most preferred one. >=20 > Is this an accurate summary of the group's consensus view? Does > anyone want to defend the view of TLSA digests as a menu of options > from which the client can choose one? >=20 Don't know about the rest of the WG, but it's mine. Some communities = have a larger local policy that they want to enforce, and the client = will prefer that primarily, with potential fallbacks.=20 > If not, I will drop the digest agility portion of the SMTP draft. > In the OPs draft we can encourage server operators (SHOULD) to > apply all digests equally to all objects, because that's more robust > in the face of local policy, and results when this is not done may > not be what the operator wanted. >=20 Still need to see the final text, but looks like it is the right = direction. Scott > Anyone else? >=20 > --=20 > Viktor. >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From nobody Wed Mar 19 07:35:42 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B92641A0756 for ; Wed, 19 Mar 2014 07:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rIXY3LaHT9fi for ; Wed, 19 Mar 2014 07:35:36 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6521A0415 for ; Wed, 19 Mar 2014 07:35:36 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 549922AB26D; Wed, 19 Mar 2014 14:35:27 +0000 (UTC) Date: Wed, 19 Mar 2014 14:35:27 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140319143527.GX24183@mournblade.imrryr.org> References: <20140318200004.GU24183@mournblade.imrryr.org> <2D59247F-0B0F-4CE7-A4D2-F57EE4167099@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2D59247F-0B0F-4CE7-A4D2-F57EE4167099@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/51qE3VkMosBEGh3VMBbebs_UR7A Subject: Re: [dane] Digest Algorithm Agility discussion (checkpoint) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 14:35:38 -0000 On Wed, Mar 19, 2014 at 10:08:38AM -0400, Scott Rose wrote: > On Mar 18, 2014, at 4:00 PM, Viktor Dukhovni wrote: > > > My sense is that regardless, there is not much enthusias for > > negotiating a single digest based on what digests the server offers, > > with the client choosing its most preferred one. > > > > Is this an accurate summary of the group's consensus view? Does > > anyone want to defend the view of TLSA digests as a menu of options > > from which the client can choose one? > > Don't know about the rest of the WG, but it's mine. Some communities have > a larger local policy that they want to enforce, and the client will prefer > that primarily, with potential fallbacks. Sorry, could you confirm the meaning of the above sentence? Probably my fault, but I am not 100% sure whether you're saying that clients: - should (proposed agility protocol) - may (employ adaptive local policy that amounts to the above), or - must not ignore lesser ranked (by the client's local policy) digest matching types in the server's TLSA RRset. > > If not, I will drop the digest agility portion of the SMTP draft. > > In the OPs draft we can encourage server operators (SHOULD) to > > apply all digests equally to all objects, because that's more robust > > in the face of local policy, and results when this is not done may > > not be what the operator wanted. > > Still need to see the final text, but looks like it is the right direction. This seems to suggest a vote for either "may" or "must not" above... -- Viktor. From nobody Wed Mar 19 07:52:06 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB7C01A0764 for ; Wed, 19 Mar 2014 07:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f16_aaXiOrEs for ; Wed, 19 Mar 2014 07:52:01 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id CA0C61A045A for ; Wed, 19 Mar 2014 07:52:00 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.174.1; Wed, 19 Mar 2014 10:51:12 -0400 Received: from postmark.nist.gov (129.6.16.94) by WSXGHUB1.xchange.nist.gov (129.6.18.96) with Microsoft SMTP Server (TLS) id 8.3.327.1; Wed, 19 Mar 2014 10:51:51 -0400 Received: from 6-140.antd.nist.gov (6-140.antd.nist.gov [129.6.140.6]) by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id s2JEpcf7006528 for ; Wed, 19 Mar 2014 10:51:38 -0400 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Scott Rose In-Reply-To: <20140319143527.GX24183@mournblade.imrryr.org> Date: Wed, 19 Mar 2014 10:51:39 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20140318200004.GU24183@mournblade.imrryr.org> <2D59247F-0B0F-4CE7-A4D2-F57EE4167099@gmail.com> <20140319143527.GX24183@mournblade.imrryr.org> To: X-Mailer: Apple Mail (2.1874) X-NIST-MailScanner-Information: Archived-At: http://mailarchive.ietf.org/arch/msg/dane/9rlPHM3BBsRnT8UhZxnbpmmz4sw Subject: Re: [dane] Digest Algorithm Agility discussion (checkpoint) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 14:52:05 -0000 On Mar 19, 2014, at 10:35 AM, Viktor Dukhovni = wrote: > On Wed, Mar 19, 2014 at 10:08:38AM -0400, Scott Rose wrote: >=20 >> On Mar 18, 2014, at 4:00 PM, Viktor Dukhovni = wrote: >>=20 >>> My sense is that regardless, there is not much enthusias for >>> negotiating a single digest based on what digests the server offers, >>> with the client choosing its most preferred one. >>>=20 >>> Is this an accurate summary of the group's consensus view? Does >>> anyone want to defend the view of TLSA digests as a menu of options >>> from which the client can choose one? >>=20 >> Don't know about the rest of the WG, but it's mine. Some communities = have >> a larger local policy that they want to enforce, and the client will = prefer >> that primarily, with potential fallbacks. >=20 > Sorry, could you confirm the meaning of the above sentence? Probably > my fault, but I am not 100% sure whether you're saying that clients: >=20 > - should (proposed agility protocol) > - may (employ adaptive local policy that amounts to the above), or > - must not >=20 The document should drop the algorithm agility text. RFC 6698 is enough = IMHO. =20 Scott >=20 > --=20 > Viktor. >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From nobody Thu Mar 20 14:05:09 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC5D21A0753 for ; Thu, 20 Mar 2014 14:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.818 X-Spam-Level: * X-Spam-Status: No, score=1.818 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DEAR_SOMETHING=1.973, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URI_HEX=1.122] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bElq_vfrGO29 for ; Thu, 20 Mar 2014 14:04:49 -0700 (PDT) Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id BF3DA1A042C for ; Thu, 20 Mar 2014 14:04:49 -0700 (PDT) Received: by mail-oa0-f50.google.com with SMTP id i7so1613262oag.9 for ; Thu, 20 Mar 2014 14:04:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=+OkFi3d0CEOd8xO5Gqpvd28Z23AXYeRLaCTsLXo2jXc=; b=tLXRJJOVBkfR/K2zhGnT9y4gqnlG2boCCMtJy6VRBb7rXYY4+0odHAOD8ls+Rg8f7x sUx55XrSmWilTSxzUEEpzKkPVZ3mZKhzR39IKNGFFCSHuwwVqgGlXZBZHI/GbUbDYRTN atsnX0ZP5CdQ4T2HJShk4+5eb79D4JJAXNL7m9mHjJgbkFbQyySGCdgPbd9pJADH95ee Xy7WfooZO6grNKxPuiYuEhNz40Fehf311lUcTpQHOM38AWvxz/lLtrNRmAP4i1IWJ2d9 r2O0R3iEt3357uhsbOf52P/VXBTVWx0+pnZyYSHH8Sd4pVk5wLZjSMr2G8E8dO14RpD/ DXpw== X-Received: by 10.60.98.139 with SMTP id ei11mr444358oeb.43.1395349480483; Thu, 20 Mar 2014 14:04:40 -0700 (PDT) MIME-Version: 1.0 Sender: sirach.vassallo@gmail.com Received: by 10.76.151.202 with HTTP; Thu, 20 Mar 2014 14:04:00 -0700 (PDT) From: Sirach Vassallo Date: Thu, 20 Mar 2014 22:04:00 +0100 X-Google-Sender-Auth: KJikDYRm8pLNRSqknwmzijXPBDw Message-ID: To: dane@ietf.org Content-Type: multipart/mixed; boundary=089e0122991c1f9a1a04f5101e94 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/O_WhcCobIvNrJegrQUailblvWdo Subject: [dane] Implementing DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 21:04:52 -0000 --089e0122991c1f9a1a04f5101e94 Content-Type: multipart/alternative; boundary=089e0122991c1f9a1504f5101e92 --089e0122991c1f9a1504f5101e92 Content-Type: text/plain; charset=ISO-8859-1 Dear Sir/madam, My name is Sirach Vassallo and I am reading a B.Sc. Degree in Computer Networks. As for my thesis, I am researching the DANE protocol. My research includes the Limitations of PKI, DNSSEC and DANE as an alternative to PKI. Part of my thesis includes the implementation of such protocol. However, I am having a problem when it comes to TLSA validation by clients. Please, I would like to ask some questions so that I may continue with my research. I would really appreciate someone's help! I have implemented DNSSEC for my domain: danetest.com. I am using BIND 9.9.5 on Ubuntu Desktop 12.04 LTS. I am using zonesigner from the DNSSEC-Tools to sign my zone. I have one primary DNS server and one Slave - both Ubuntu 12.04. I also have another server (Windows Server 2012) running IIS 8 with 2 websites verified.danetest.com and broken.danetest.com. I created self-signed certificates for each of these websites and I am making use of SNI for mapping these certificates to the correct hostname. As for the client, I am using the DNSSEC/TLSA Validator extension on Firefox (https://www.dnssec-validator.cz/) on Mac OS X 10.9.2. I am attaching with this email the *db.danetest.com * and* db.danetest.com.signed* configuration files. This is my TLSA record for verified.danetest.com _443._tcp.verified.danetest.com. IN TLSA 3 0 1 ( baf3515d2695e25a2e4e850d909b4a446cdb7de3df2dfc116d36bb4afd94f99c ) I am generating the TLSA record by using this online tool: https://www.huque.com/bin/gen_tlsa. As the online tool requires a PEM format of the certificate, I am converting the .pfx (created from IIs) to .pem using openSSL. My question is, am I implementing the TLSA RR correctly? Since the client extension is saying that the name verification is failing. Should the Usage, Selector and Matching type fields be in number bits or words as listed in the draft: draft-ietf-dane-ops-03 ? Also, does the TLSA record needs to be inserted into the signed zone file? or the normal unsigned conf file? I tried both, however, when using the IN TLSA DANE-TA Cert SHA2-256 format instead of numbers, the zonesigner daemon gave me an error saying that the format is not supported. I would really appreciate your help. Thank you in advance, and hope to hear from you soon. Regards, Sirach Vassallo m. 00 356 99491210 e. sirach@vassallos.com --089e0122991c1f9a1504f5101e92 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear Sir/madam,

My name is Sirach Vassallo and I am reading a B.Sc. Degree in= Computer Networks. As for my thesis, I am researching the DANE protocol. M= y research includes the Limitations of PKI, DNSSEC and DANE as an alternati= ve to PKI.

Part of my thesis includes the implementation of such protocol. However, I = am having a problem when it comes to TLSA validation by clients. Please, I = would like to ask some questions so that I may continue with my research. I= would really appreciate someone's help!


I have implemented DNSSEC for my domain:= danetest.com. I am using BIND 9.9.5 on= Ubuntu Desktop 12.04 LTS. I am using zonesigner from the DNSSEC-Tools to s= ign my zone.

I = have one primary DNS server and one Slave - both Ubuntu 12.04. I also have = another server (Windows Server 2012) running IIS 8 with 2 websites verified.danetest.com and broken.danetest.com. I created self-signed = certificates for each of these websites and I am making use of SNI for mapp= ing these certificates to the correct hostname.

As= for the client, I am using the DNSSEC/TLSA Validator extension on Firefox = (https://www.dnssec-validator.= cz/) on Mac OS X 10.9.2.

I = am attaching with this email the db.d= anetest.com and db.danetest.com.signed configuration files.<= br>
=
This is my TLSA record for verified.danetest.com

_443._tcp.verified.danetest.com. IN TLS= A 3 0 1 ( baf3515d2695e25a2e4e850d909b4a446cdb7de3df2dfc116d36bb4afd94f99c = )

I am generating th= e TLSA record by using this online tool:=A0https://www.huque.com/bin/gen_tlsa.
As the online tool requires a PEM format of the certificate= , I am converting the .pfx (created from IIs) to .pem using openSSL.=A0
=
My question is, am I implementing the TLSA RR correctly? Since the clie= nt extension is saying that the name verification is failing.
=
Sh= ould the Usage, Selector and Matching type fields be in number bits or word= s as listed in the draft: draft-ietf-dane-ops-03 ?

<= /div>
Also, d= oes the TLSA record needs to be inserted into the signed zone file? or the = normal unsigned conf file? I tried both, however, when using the=A0<= span style=3D"color:rgb(0,0,0);font-size:13px;line-height:1.2em">IN TLSA DANE-TA Cert SHA2-256 format ins= tead of numbers, the zonesigner daemon gave me an error saying that the for= mat is not supported.

<= /div>
I would= really appreciate your help. Thank you in advance, and hope to hear from you soon.

<= /div>
Regards,

<= div>
Sirach Vassallo
<= /font>=A0
m.=A000=A0356 99491210<= /font>
--089e0122991c1f9a1504f5101e92-- --089e0122991c1f9a1a04f5101e94 Content-Type: text/plain; charset=US-ASCII; name="db.danetest.com.signed.txt" Content-Disposition: attachment; filename="db.danetest.com.signed.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ht0izjee0 OyBGaWxlIHdyaXR0ZW4gb24gV2VkIE1hciAxOSAyMzo1NTo1MyAyMDE0DQo7IGRuc3NlY19zaWdu em9uZSB2ZXJzaW9uIDkuOS41LTItVWJ1bnR1DQpkYW5ldGVzdC5jb20uCQk2MDQ4MDAJSU4gU09B CW5zMS5kYW5ldGVzdC5jb20uIG1haWwuZGFuZXRlc3QuY29tLiAoDQoJCQkJCTIwMTQwMzE5MDIg OyBzZXJpYWwNCgkJCQkJNjA0ODAwICAgICA7IHJlZnJlc2ggKDEgd2VlaykNCgkJCQkJODY0MDAg ICAgICA7IHJldHJ5ICgxIGRheSkNCgkJCQkJMjE0OTIwMCAgICA7IGV4cGlyZSAoMyB3ZWVrcyAz IGRheXMgMjEgaG91cnMpDQoJCQkJCTYwNDgwMCAgICAgOyBtaW5pbXVtICgxIHdlZWspDQoJCQkJ CSkNCgkJCTYwNDgwMAlSUlNJRwlTT0EgOCAyIDYwNDgwMCAoDQoJCQkJCTIwMTQwNDE4MjE1NTUz IDIwMTQwMzE5MjE1NTUzIDQ2Nzk0IGRhbmV0ZXN0LmNvbS4NCgkJCQkJSkNYMDdwaEhNT08waldI bWhiMzdFM0ZnYllDVWhnc2FjM0taDQoJCQkJCWZya3krV214cXVNdXJZemgyaHA1NDRyZGFOSVhL ZWtlMUN6Lw0KCQkJCQlqc0tvNHNlam5lWXdsQk0vQkZXYnUrSDlYSDZEWiszcnF4NXkNCgkJCQkJ MzR4WmhjL1lwNkNpb3RiRVJYU2hQaXhiK0o1T21sWGZNUldGDQoJCQkJCWZDN3E0L0FaOGE0NDZo ekJYUEFkWldkVXJhOD0gKQ0KCQkJNjA0ODAwCU5TCW5zMS5kYW5ldGVzdC5jb20uDQoJCQk2MDQ4 MDAJTlMJbnMyLmRhbmV0ZXN0LmNvbS4NCgkJCTYwNDgwMAlSUlNJRwlOUyA4IDIgNjA0ODAwICgN CgkJCQkJMjAxNDA0MTgyMTU1NTMgMjAxNDAzMTkyMTU1NTMgNDY3OTQgZGFuZXRlc3QuY29tLg0K CQkJCQlPOW5WVFJ6ZEgvVmxBOFJrams5dTBjckZrTW9hUXVWbHV5VnUNCgkJCQkJVmFlb1VjMEp5 N3JpNDdtZ2UremJNaHpOSjNpalBkVU5GM05YDQoJCQkJCWlQWXBFV3V6SzlpMWNVT3o4cmZIZ09t VUJFVnp6dGUxMGxKeg0KCQkJCQlvRWFmcmx3VFBSWlVqQ0hhQzV1TTNSZURzZjVnYkdKN2ZsSVIN CgkJCQkJS01CMzlLWVhCSGZuOUhhTGRzb0JQNVhZWW80PSApDQoJCQk2MDQ4MDAJQQkxOTUuMTU4 LjEwNi4xMA0KCQkJNjA0ODAwCVJSU0lHCUEgOCAyIDYwNDgwMCAoDQoJCQkJCTIwMTQwNDE4MjE1 NTUzIDIwMTQwMzE5MjE1NTUzIDQ2Nzk0IGRhbmV0ZXN0LmNvbS4NCgkJCQkJaDEySjZmZ2ducEIw UVpLeE9YWGloRGFVQnNBWkNqdzhEVFpzDQoJCQkJCVg1MWlsL2NSbEdPQlRBZFFVbE1qNFVwckpG YW5XWE8yR2c0bg0KCQkJCQlScGx5WGx1ODV5OFhiNmdPVmQ3Q1hWK0svUDFvMjdmTjRKcHUNCgkJ CQkJNnY2SVExdDJUeUs0am1kbUdKNDBPZi9HOXhrWHB0STNtZjRPDQoJCQkJCUhwU2xGbzViamlk cDBTc0diUHIya0F2eTUyVT0gKQ0KCQkJMzYwMAlNWAkxMCBmODQwNzYxZjA3MDc3ZTQzODQ5Njcw ODc3ZjhiZTkucGFteDEuaG90bWFpbC5jb20uDQoJCQkzNjAwCVJSU0lHCU1YIDggMiAzNjAwICgN CgkJCQkJMjAxNDA0MTgyMTU1NTMgMjAxNDAzMTkyMTU1NTMgNDY3OTQgZGFuZXRlc3QuY29tLg0K CQkJCQl0eEFmV0lTZFV2bkdHV0wwbXBIcHhhQlRUaS94SGlwdWlRaTANCgkJCQkJRk9Qd25aVEdF ZFptMzlvaXk1LzdoaER0cyt5YU5wTVBnV0VUDQoJCQkJCXI5cG11aHN1ZTJZR0xGYk1ZYVA4SHZE bmpGRUs3WElGS3o3Vw0KCQkJCQlyRHhNRk9OamlpSFV3UlRnZ3ZFY0ZGSXBIUVFzWFNHakVEdzgN CgkJCQkJaE8vSmJvcWJscmN6eFBpRlAvUzBKQ0VUQjBBPSApDQoJCQk2MDQ4MDAJTlNFQwlicm9r ZW4uZGFuZXRlc3QuY29tLiBBIE5TIFNPQSBNWCBSUlNJRyBOU0VDIEROU0tFWQ0KCQkJNjA0ODAw CVJSU0lHCU5TRUMgOCAyIDYwNDgwMCAoDQoJCQkJCTIwMTQwNDE4MjE1NTUzIDIwMTQwMzE5MjE1 NTUzIDQ2Nzk0IGRhbmV0ZXN0LmNvbS4NCgkJCQkJQXFIQ3NDT2ZqTUF0SlZrOVRGZCtMZ0x3SlUy algyckxkTlpSDQoJCQkJCTcwNThuMDZOSE5maFdMcHZPMHlyR2dqcSsyM0RabHFXL3VSaw0KCQkJ CQlXYzM2NXJTQmd2SFRDeXQyWS82aWc5VWZvTkdQZUwwV3UzVkcNCgkJCQkJVitwU0lzWDAxVzlz bmN3dlR1WUVHWW9hTmp3blBMTGF0VXdNDQoJCQkJCXN5ZTAxdmU1T0ZDbVplZ2dpZWlpeUhTbUZj UT0gKQ0KCQkJNjA0ODAwCUROU0tFWQkyNTYgMyA4ICgNCgkJCQkJQXdFQUFhSlNqUHllc2VaZ0lm dVEzazZaamxHODh6eEQ2SUVaDQoJCQkJCWtHVk9hZFJheEU0YVNORnUyQk9iTjlORWp0QUw3M1dN cENDdA0KCQkJCQlVNTBzNHN6U2lJSEFSWlZSSmQycDZKTSs4T1k4bGRkTkM3engNCgkJCQkJNVNh bE5PT05DbXU4aGt0SkZMVGdGQzlHQUFPbTB2RThLUWdNDQoJCQkJCS9UQzJwOEVXeEdRQ3d5UG1i V0I0T1docnlvb1RFNDdUDQoJCQkJCSkgOyBaU0s7IGFsZyA9IFJTQVNIQTI1Njsga2V5IGlkID0g Mjc2MDANCgkJCTYwNDgwMAlETlNLRVkJMjU2IDMgOCAoDQoJCQkJCUF3RUFBZVljUnc4Z3IzNlZy Wmc1bnVJeW5ERXQyNnk1OGRFag0KCQkJCQlRck1vcTJoSE1VdS9ESlpYNi9qUThRNkpNVVJrQzlk V3dab1INCgkJCQkJL1pha0tSZExrUWg4Z1QvUXlZR294c2oxbjBpREpZclJrZFdPDQoJCQkJCTB2 MmZrWm1aVU81UEZ3ZWttSEprbGplbVhEZnk1V3VYVHRSRg0KCQkJCQlHZWhZTDRia0xaWUQ5VHQ1 a3BTNkdIUG5GOWFrOElhYg0KCQkJCQkpIDsgWlNLOyBhbGcgPSBSU0FTSEEyNTY7IGtleSBpZCA9 IDQ2Nzk0DQoJCQk2MDQ4MDAJRE5TS0VZCTI1NyAzIDggKA0KCQkJCQlBd0VBQWN1eUZoVHB6amxZ N1RVeFYvM2Y0M2xlQ0ZHRnNneDENCgkJCQkJcUpYWkNyYUlyOHBhODB2ejBncXZmUXNtV1NNbzVL dWRGMjdSDQoJCQkJCXNjNW1pOU5JTWRucFV5NzVRWTY5UkhSNHlUeTA5QU51L1RWZw0KCQkJCQlQ TStPaHgvdkh6bFhaRnY4Yzl6enh2MVRVUkhLUTM1SEwwL1YNCgkJCQkJMVNLejZqV0NJeExNdThw bDRRcytBZXVIYi91Y2Z5WmswelZODQoJCQkJCWg4eWxtR0FoZUdIT2VwWlg0Qm5SQ3AvRjRIeUpp Uzc2SENCMA0KCQkJCQlOTndVY0txVnpsSjM3eDJhYS82QTU2TXNIWEd2cHNxcy9BWloNCgkJCQkJ cVE1L203OEViNmZkRmdpN2hOWG52eUhVUHRYbjlURHZnWkRyDQoJCQkJCVVTd1B6b0JHaHBDdlJz THA3NDRGUDBSU3FGVCtMUDB4WmJNbw0KCQkJCQliUVZSbk1ycHVKZ1JpUi9iZXpHMG5scz0NCgkJ CQkJKSA7IEtTSzsgYWxnID0gUlNBU0hBMjU2OyBrZXkgaWQgPSA0Njk0Mg0KCQkJNjA0ODAwCVJS U0lHCUROU0tFWSA4IDIgNjA0ODAwICgNCgkJCQkJMjAxNDA0MTgyMTU1NTMgMjAxNDAzMTkyMTU1 NTMgNDY3OTQgZGFuZXRlc3QuY29tLg0KCQkJCQlJajdnall0YzBRQVZPNURNeEdIbEJVUkFRd29i b1NxTFBZQmYNCgkJCQkJWThQc2hwdU4zVXJ1VmlGVktibCtHenNCTGhEOTVUblhJcnc3DQoJCQkJ CVdwTHhpNmVOZGFrSVROREhNbW5OckpjU2NqaUtMRVdyUWdnMQ0KCQkJCQl2anZzTkFxUy9DTTlS ek5PbGFCOC9leUo2MXNBZHBwNDZacUcNCgkJCQkJVGl0aG5oYTdMUFAwblk4bHVyd0J5UUlZalIw PSApDQoJCQk2MDQ4MDAJUlJTSUcJRE5TS0VZIDggMiA2MDQ4MDAgKA0KCQkJCQkyMDE0MDQxODIx NTU1MyAyMDE0MDMxOTIxNTU1MyA0Njk0MiBkYW5ldGVzdC5jb20uDQoJCQkJCVR0MFBBcVlvaS9Z bnNhczFQNU5vbXhFMXdmRHZabC81bUxvNQ0KCQkJCQlsZnh3SjJaT1J5dkpYenRzU0Y1T01tWnJS Y2Z1YVJCYjEyTk0NCgkJCQkJRGw3M1dlbTNEanFKbzNYYStYK1Q5TzV5SnZseFVuK1N3R0JXDQoJ CQkJCUFIbENKdWtaLzlCa3FRaGFVKzIxVUlzNGg1VXpZWkVtbE55Ng0KCQkJCQllSFhla0FmeE1W ZXI4dHptWWRqRitpY3dCQ1pTa3Y0SlFrdk8NCgkJCQkJWjd2NzFVMXFDbHBEaWZxNm5zM0ZwME5r dlorWm1wdW41ZlFHDQoJCQkJCWYydGtLaTUwMGdmTHp5aVhPMS9WNG8rNkNPVm16VjQxVm4zbw0K CQkJCQlxeURUdnhBK2tsY0lxSWVpU1N2RTYwaVdlUUNTVU1ERjhNVDkNCgkJCQkJTktXSFZ1cDhu RUFyUnZHMDFSd3Y2Vmx4ZkpzNnBhdDlRUjQyDQoJCQkJCVlkK29CcEFCUzJPRmYveTVYUT09ICkN CmJyb2tlbi5kYW5ldGVzdC5jb20uCTYwNDgwMAlJTiBBCTE5NS4xNTguMTA2LjEwDQoJCQk2MDQ4 MDAJUlJTSUcJQSA4IDMgNjA0ODAwICgNCgkJCQkJMjAxNDA0MTgyMTU1NTMgMjAxNDAzMTkyMTU1 NTMgNDY3OTQgZGFuZXRlc3QuY29tLg0KCQkJCQloVHZDbFJ4K0ZsOEVCRVlLYXY3VHF0ZFZ4Sk80 R1VNbE5qUVcNCgkJCQkJN0hkSU92R09kUVUyeEg2RlNodm9oRlVqMWVhLzBhL2JHSEtRDQoJCQkJ CTJxVmNna1NiYm9JUkZickxqL1hSZjU1d1pNR0MvODFkaUNsTg0KCQkJCQk0TFQzMjNpdWxVQ2pa WWU5UmNsaTVlV044RTdVS0I5bGsyVHYNCgkJCQkJZ1I1SUpyTVlhRGMvdHlWNldYVE5PZXZIc3hZ PSApDQoJCQk2MDQ4MDAJTlNFQwltYWlsLmRhbmV0ZXN0LmNvbS4gQSBSUlNJRyBOU0VDDQoJCQk2 MDQ4MDAJUlJTSUcJTlNFQyA4IDMgNjA0ODAwICgNCgkJCQkJMjAxNDA0MTgyMTU1NTMgMjAxNDAz MTkyMTU1NTMgNDY3OTQgZGFuZXRlc3QuY29tLg0KCQkJCQltVEQ5ZWRkUWNhZDRWV3VZOW1HQml2 Ryt5UkFrSW95bkVvYkoNCgkJCQkJMVVQY1grRVBWR256RlY4V2VWNmNaN0h3aExaVXEzamoya1Vm DQoJCQkJCUtPb1RjYVhyQ214cm1XcktKNXBhNUV0SlU0QTdPakpKVUpPRg0KCQkJCQlmUTdTTE01 QnFsU1Q3eHBmTUdZbERaMlQ4bUVtd1hZaExXOEMNCgkJCQkJdnhFSThzQ3BOcUtpSzFnK3hCSWdH SzdqeXBBPSApDQptYWlsLmRhbmV0ZXN0LmNvbS4JNjA0ODAwCUlOIENOQU1FIGdvLmRvbWFpbnMu bGl2ZS5jb20uDQoJCQk2MDQ4MDAJUlJTSUcJQ05BTUUgOCAzIDYwNDgwMCAoDQoJCQkJCTIwMTQw NDE4MjE1NTUzIDIwMTQwMzE5MjE1NTUzIDQ2Nzk0IGRhbmV0ZXN0LmNvbS4NCgkJCQkJQ3VRdVRZ RFc3aWc5eUowdU5abWR0cWNwOEZFTVVZYWtDbTZQDQoJCQkJCWFmREF5WElFVFN2Ky9Cd3BnTXN2 czFHck8rWDY0UHJNZU5EbQ0KCQkJCQk0TWpncTNhV0VUQnJyckVPdEh4TE83RE8vRVpneWp6azBy VDYNCgkJCQkJSmIxMEZqc2N3L3p5dlY5VVF1QkJPZ2RCMkZmTHhyM2FmUnFPDQoJCQkJCVc3OVRO VDFmRzV1TkdDQmFxVDFhbGx0QUo4bz0gKQ0KCQkJNjA0ODAwCU5TRUMJbnMxLmRhbmV0ZXN0LmNv bS4gQ05BTUUgUlJTSUcgTlNFQw0KCQkJNjA0ODAwCVJSU0lHCU5TRUMgOCAzIDYwNDgwMCAoDQoJ CQkJCTIwMTQwNDE4MjE1NTUzIDIwMTQwMzE5MjE1NTUzIDQ2Nzk0IGRhbmV0ZXN0LmNvbS4NCgkJ CQkJb0YzZVF4Z0x6NzVkUzZIYTV5TzNEbnRPTnF5R2xudU5LZTEzDQoJCQkJCSs5bW5mMXA2UGdm TUVZVkhMdEtKcG55eEZwaHd5RkxJbUNQUQ0KCQkJCQltOFR3QUMxcytmazMxbHpoL21xU1F6TGJx YndES3VoTS9IS2kNCgkJCQkJemJ1emhoZ2NDTXNXTFNZeFFhV2xnbGZXRkNwbUYyUFFlSE9KDQoJ CQkJCWR1OEZMNGZ3NENtVlNjZGJTRy9JUlJhTkNIaz0gKQ0KbnMxLmRhbmV0ZXN0LmNvbS4JNjA0 ODAwCUlOIEEJMTk1LjE1OC4xMDYuMTANCgkJCTYwNDgwMAlSUlNJRwlBIDggMyA2MDQ4MDAgKA0K CQkJCQkyMDE0MDQxODIxNTU1MyAyMDE0MDMxOTIxNTU1MyA0Njc5NCBkYW5ldGVzdC5jb20uDQoJ CQkJCWx4NWlIa3VWSzd2dlhqRkk4bU01aEpZQXhRdU1tamhDUVNrTg0KCQkJCQlmR2ZPYS8wNWNm NG9id3RHTkZiNnBKVjd5Q0ViRTM4dkthem8NCgkJCQkJU1N6eTRYN0xidjZqSTliRnBmSlE3OUx3 TmkvZzRSbCtXYnV4DQoJCQkJCS9SdVlzeStoQzZzSEFhTWMrWllVSVBqeC9wUlZVWk9zYWNEZA0K CQkJCQlQcGJsNnlIWlJ1ckRCb2ZkTGs4Mkg4NzY0NWc9ICkNCgkJCTYwNDgwMAlOU0VDCW5zMi5k YW5ldGVzdC5jb20uIEEgUlJTSUcgTlNFQw0KCQkJNjA0ODAwCVJSU0lHCU5TRUMgOCAzIDYwNDgw MCAoDQoJCQkJCTIwMTQwNDE4MjE1NTUzIDIwMTQwMzE5MjE1NTUzIDQ2Nzk0IGRhbmV0ZXN0LmNv bS4NCgkJCQkJWHY1RTlpME1EU1I2eEcza0lmRnZUU3BFS0FzbXJXTTg3UEltDQoJCQkJCXJmcmZL d2F5OHNqY0dlODlyR0NLVjArbGxQS240eHNCY0dLMw0KCQkJCQlNY3JNQVdoTXRnY3MxS2xEclg4 ZzFDd0FiV0xlTWgxam1vL0kNCgkJCQkJakZ6bFdwck9vWXZ4cFUzdXplejROTktLRzJRK3ZSU1Y5 QlBoDQoJCQkJCXd1Sk1GanBEUm82T29nRGhZdWxYem5zY000WT0gKQ0KXzQ0My5fdGNwLnZlcmlm aWVkLmRhbmV0ZXN0LmNvbS4gSU4gVExTQSAzIDAgMSAoIGJhZjM1MTVkMjY5NWUyNWEyZTRlODUw ZDkwOWI0YTQ0NmNkYjdkZTNkZjJkZmMxMTZkMzZiYjRhZmQ5NGY5OWMgKQ0KdmVyaWZpZWQuZGFu ZXRlc3QuY29tLgk2MDQ4MDAJSU4gQQkxOTUuMTU4LjEwNi4xMA0KCQkJNjA0ODAwCVJSU0lHCUEg OCAzIDYwNDgwMCAoDQoJCQkJCTIwMTQwNDE4MjE1NTUzIDIwMTQwMzE5MjE1NTUzIDQ2Nzk0IGRh bmV0ZXN0LmNvbS4NCgkJCQkJZk9JWHkyc3gzZklSMmxEUis0QTlaRGdFK25PaGtLU2JsTTBsDQoJ CQkJCWpqVW1FNnJpUGRrZENyRU5BZ2xMMTAxSlA5aURhdlFUNzcyeg0KCQkJCQkxelpyVFdadi8z NGJ5cW1ZVnZqbHBRUkU1bllNWXhWOWpWNHYNCgkJCQkJcmtENXVqdG9JLzB1UjlFR2ptRG9IczRv Y3NjWGEyU2RzLzdkDQoJCQkJCWN0aVNLK2pKNnpXaUJIaDNzTDczUWZmckRYaz0gKQ0KCQkJNjA0 ODAwCU5TRUMJZGFuZXRlc3QuY29tLiBBIFJSU0lHIE5TRUMNCgkJCTYwNDgwMAlSUlNJRwlOU0VD IDggMyA2MDQ4MDAgKA0KCQkJCQkyMDE0MDQxODIxNTU1MyAyMDE0MDMxOTIxNTU1MyA0Njc5NCBk YW5ldGVzdC5jb20uDQoJCQkJCXcxSTluZjArS253dVVMcTFHVUVNZ2FjWmk1STF2R2JvRzh2bg0K CQkJCQlLSXBBUlZaR3lwZjhVRkUwc0FLWDlmQytYNWxhQS9kZHYzUTcNCgkJCQkJYWVhRjZBYkI2 Y2I4cGw2Q1VSWmJTNThxWXhvclZoOXA5d0dmDQoJCQkJCUppZHYwdnpPWGw0NUFKczBKMWJGS1h0 V3BlSnpKdjFHaE9pSg0KCQkJCQlsbzFSTXB6Mnk4RUlUdlpnUmUxTkJJZ2ozMWc9ICkNCm5zMi5k YW5ldGVzdC5jb20uCTYwNDgwMAlJTiBBCTE5NS4xNTguOTQuMjcNCgkJCTYwNDgwMAlSUlNJRwlB IDggMyA2MDQ4MDAgKA0KCQkJCQkyMDE0MDQxODIxNTU1MyAyMDE0MDMxOTIxNTU1MyA0Njc5NCBk YW5ldGVzdC5jb20uDQoJCQkJCU13OW5tWXdMcEx1MEd0ZTFaM3FOdUx1U3M2T3ZHUyt5cndXSg0K CQkJCQlQTEM5VWo1Mmw3SmhOZnFpQzYrd2dOZGZvelBzd2lvVHYvU0sNCgkJCQkJcUFzRUlEdEpC MXJGZ2JEa1pyZkpqT0dMdVFsbXhSWGNQcFFQDQoJCQkJCXp3Z25xUGxlNFJHMEN2UUJTNlBRUzZY dVNhYnpIVEkxUVJKVw0KCQkJCQlzNEE4Nldxb0IrSnpUbGdKK093NFVieFRsMEE9ICkNCgkJCTYw NDgwMAlOU0VDCXZlcmlmaWVkLmRhbmV0ZXN0LmNvbS4gQSBSUlNJRyBOU0VDDQoJCQk2MDQ4MDAJ UlJTSUcJTlNFQyA4IDMgNjA0ODAwICgNCgkJCQkJMjAxNDA0MTgyMTU1NTMgMjAxNDAzMTkyMTU1 NTMgNDY3OTQgZGFuZXRlc3QuY29tLg0KCQkJCQlFSUxaV1gzTVVEL2l2L28wd0FUVTg2VXpNRVB6 eVJPdnV2SVgNCgkJCQkJQVVoTDBqNlpLaGhCK01OamlCNTlSNWNHQXhUYUZkamVYcFhYDQoJCQkJ CURGN3pMc25EMlhGSHN1Mjd5c25GeVlaUURjLzgxTzlDZk5idA0KCQkJCQlINFI5S0RCSGtueWUy UzJIWGRYU2RFei9SWGVRaFRYN3hNTVgNCgkJCQkJME9YTDJsdzR2VjNtdDBjaWhjU012RGJXWFNR PSAp --089e0122991c1f9a1a04f5101e94 Content-Type: text/plain; charset=US-ASCII; name="db.danetest.com.txt" Content-Disposition: attachment; filename="db.danetest.com.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ht0izjf71 JFRUTCA2MDQ4MDANCiRPUklHSU4gZGFuZXRlc3QuY29tLg0KQAlJTglTT0EJbnMxLmRhbmV0ZXN0 LmNvbS4gbWFpbC5kYW5ldGVzdC5jb20uICgNCgkJCTIwMTQwMzE5MDIJOyBTZXJpYWwNCgkJCTYw NDgwMAkJOyBSZWZyZXNoDQoJCQk4NjQwMAkJOyBSZXRyeQ0KCQkJMjE0OTIwMAkJOyBFeHBpcmUN CgkJCTYwNDgwMCApCTsgTmVnYXRpdmUgQ2FjaGUgVFRMDQo7DQpACQkJSU4JTlMJbnMxLmRhbmV0 ZXN0LmNvbS4NCkAJCQlJTglOUwluczIuZGFuZXRlc3QuY29tLg0KQAkJMzYwMAlJTglNWCAgMTAg IGY4NDA3NjFmMDcwNzdlNDM4NDk2NzA4NzdmOGJlOS5wYW14MS5ob3RtYWlsLmNvbS4NCkAJCQlJ TglBCTE5NS4xNTguMTA2LjEwDQpuczEJCQlJTglBCTE5NS4xNTguMTA2LjEwDQpuczIJCQlJTglB CTE5NS4xNTguOTQuMjcNCnZlcmlmaWVkCQlJTglBCTE5NS4xNTguMTA2LjEwDQpicm9rZW4JCQlJ TglBCTE5NS4xNTguMTA2LjEwDQptYWlsCQkJSU4JQ05BTUUJZ28uZG9tYWlucy5saXZlLmNvbS4N Cg== --089e0122991c1f9a1a04f5101e94-- From nobody Thu Mar 20 15:12:44 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4BAB1A091D for ; Thu, 20 Mar 2014 15:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rlcrf06TH0MH for ; Thu, 20 Mar 2014 15:12:40 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by ietfa.amsl.com (Postfix) with ESMTP id 9CCC01A08E0 for ; Thu, 20 Mar 2014 15:12:39 -0700 (PDT) Received: from localhost (50-1-19-226.dsl.dynamic.sonic.net [50.1.19.226]) by mail.hardakers.net (Postfix) with ESMTPSA id D201D27168; Thu, 20 Mar 2014 15:12:25 -0700 (PDT) From: Wes Hardaker To: Viktor Dukhovni References: <20140315051704.GY21390@mournblade.imrryr.org> Date: Thu, 20 Mar 2014 15:12:23 -0700 In-Reply-To: <20140315051704.GY21390@mournblade.imrryr.org> (Viktor Dukhovni's message of "Sat, 15 Mar 2014 05:17:04 +0000") Message-ID: <0l4n2sa5a0.fsf@wjh.hardakers.net> User-Agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/dane/NjsiKjQ-btjyDyz-3uKdKo5urC4 Cc: dane@ietf.org Subject: Re: [dane] Digest Algorithm Agility discussion X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 22:12:42 -0000 Viktor Dukhovni writes: > The SMTP draft specifies a digest algorithm agility protocol for DANE. So, trying to review this thread for where things stood and a number of things jumped out at me. Specifically, there is a lot of violent agreement on some things. So let me get the most important out of the way that I'm firmly convinced everyone agrees on: local policy always trumps everything. EG this is perfectly acceptable: if moon == full: acceptable_alg_list = [GOST] else if elvis == reborn or the_beetles == on_tour: acceptable_alg_list = [MD5, SHA51] prefer = any_match else acceptable_alg_list = [SHA512, SHA256] prefer = first_existing_alg_published_from_list And that (wacky) policy would always trump any other decision tree in the code base. Where things have been falling apart are o o What is the default for "prefer", any_match [most people's opinion] or first_existing_alg_published_from_list [Viktor's opinion]? To really consider this, we have to take a few things into account: o The server is unable to publish, for their clients, their preference order. There is no way to make the statement "please authenticate my certificate using SHA256. Unless you don't understand it, in which case just use SHA1". The *only* thing it can do is publish things it trusts and hope the client uses the best one available, for which it has no say. o The client gets to pick what it's willing to accept and what it's not. o But, there are two sides to DANE. 1. DANE is augmented security to the base infrastructure. Rather than allowing 1300+ X.509 CAs, it restricts the connection to a single, linear X.509 path (tied to a single, linear DNSSEC path). This is certainly the case for the HTTP case. Even a MD5 hash to double check the CA path is likely an improvement to the non-DANE case. It's an *added* check to the existing infrastructure. So clients are more likely to be willing to accept nearly anything "not broken". 2. DANE is *the* security mechanism, and without it you simply can't do some aspect of security. In the SMTP case, it is impossible to do authentication without a DNSSEC/DANE solution. 6698 was not originally written to cover this case (and, as discussed recently, this all hinges on "discovery" and that was deliberately left out of past solutions). In this case, it's much more likely someone may want a policy of "if they indicated they can do my most preferred algorithm, then don't transmit the message if that algorithm is failing. I don't care if there is another match to a less preferred one. o Now for case #2, it'd be easy to simply thing "look, just don't specify MD5 if you don't trust it". But that's not so simple when it comes to connecting to random machines in the world. It'd be great to have a policy of "Only accept SHA256 from example.com, but accept either SHA256 or SHA512 from example.org if either works". That that's not a manageable policy to maintain for the internet at large. So where does that leave us? With a choice. What do we want as a policy knob. The choice: Do you, Mr. System Administrator defining the local policy for the *client*, want: A) Accept any published hashing algorithm out of my "unordered set" to validate the remotely presented certificate. [Ordering it doesn't buy you anything since you'll simply accept a match and it doesn't matter which you try first, since any success in any algorithm will equally indicate "ok"; in fact in an implementation aiming for speed, it might be best to choose the order based on how fast you can execute the algorithm]. If the server fails to publish a perfect record set, as long as one matches I'm ok with that. B) Believe that the server will always publish perfect records, and if my "ordered set" of algorithms is [SHA512, SHA256] and they publish SHA512, then I never want to accept SHA256 because I fear an attack more than I fear a server administrator blowing their configuration. So to recap, first: either of those is fine in local policy knob setting scheme. Implementations can let administrators of clients configure sane or insane policies they want. But the real question, is what is the *default* that we should suggest an implementation do? RFC6698 indicates choice A ("accept anything that matches in my unordered set"). But, what about other specific protocols? I) what should we do generically? RFC6698 already laid this out as A in absence of local policy. II) what should we do in SMTP? This is where Viktor, considering case #2 above, is wanting to do B ("accept just the 'best' in an ordered set of algorithms) instead of A. The arguments, though, from both sides are probably talking about different cases (generic vs SMTP) and I think that is ending up with some of the confusion. Here's the multiple choice quiz to cap all this off: 1. For generic DANE, is the right *default* choice: A) Accept any successful matching hash, regardless of "strength". (This is what 6698 says to do today) B) Accept only the strongest hash, from an ordered list, that the server has published (and DNSSEC has validated the RRSET for). 2. For SMTP, is the right (SMTP-application-specific) *default* choice: A) Accept any successful matching hash, regardless of "strength". (This is what 6698 says to do today) B) Accept only the strongest hash, from an ordered list, that the server has published (and DNSSEC has validated the RRSET for). 3. For XMPP: A) Accept any successful matching hash, regardless of "strength". (This is what 6698 says to do today) B) Accept only the strongest hash, from an ordered list, that the server has published (and DNSSEC has validated the RRSET for). 4. For HTTP: A) Accept any successful matching hash, regardless of "strength". (This is what 6698 says to do today) B) Accept only the strongest hash, from an ordered list, that the server has published (and DNSSEC has validated the RRSET for). 5. For IMAP: .... -- Wes Hardaker Parsons From nobody Thu Mar 20 16:08:58 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0919F1A0924 for ; Thu, 20 Mar 2014 16:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7u_Gn8gLQrcT for ; Thu, 20 Mar 2014 16:08:53 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id EE0961A0914 for ; Thu, 20 Mar 2014 16:08:52 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B2C3B800AA; Thu, 20 Mar 2014 19:08:42 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1395356922; bh=8vodFbM1qRYcbcB5j86/08CczxkYvH+Lh1hS2ahg6VA=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=GaR2GFESs2lSfBHHFzGxTtvgMahvOqCWO46S6/1QKC6jwWuXHLwOzYNgI++aXZOBO bjo5AlmKUTP0+wz2GjmwfGm6Qj6bA9DLCJCGk0yI4n5F9WVYq+k5SVk6KQc91bZ79H gqw6H3hppTfLWZOr7wefOyqTMTwDqO4YFqjmY2JU= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s2KN8gCf031278; Thu, 20 Mar 2014 19:08:42 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Thu, 20 Mar 2014 19:08:42 -0400 (EDT) From: Paul Wouters To: Sirach Vassallo In-Reply-To: Message-ID: References: User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dane/LrzlqGlodrvuvMsCmyLyD0xU9Ys Cc: dane@ietf.org Subject: Re: [dane] Implementing DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 23:08:56 -0000 On Thu, 20 Mar 2014, Sirach Vassallo wrote: > This is my TLSA record for verified.danetest.com That SSL server is not properly configured and goes into a reloading loop. So the SSL certificate cannot be obtained to be checked against the TLSA record. First ensure https://verified.danetest.com/ actually works, then re-test. Paul From nobody Thu Mar 20 18:08:13 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE5EC1A084F for ; Thu, 20 Mar 2014 18:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WWQvPzaHNwi4 for ; Thu, 20 Mar 2014 18:08:06 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 827B71A0830 for ; Thu, 20 Mar 2014 18:08:06 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 37BD42AB22D; Fri, 21 Mar 2014 01:07:56 +0000 (UTC) Date: Fri, 21 Mar 2014 01:07:56 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140321010756.GR24183@mournblade.imrryr.org> References: <20140315051704.GY21390@mournblade.imrryr.org> <0l4n2sa5a0.fsf@wjh.hardakers.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0l4n2sa5a0.fsf@wjh.hardakers.net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/hexqCnBPRT63QjYMMMwRu_7g_fw Subject: Re: [dane] Digest Algorithm Agility discussion X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 01:08:11 -0000 [ Forwarded on behalf of: Phil Pennock ] On 2014-03-20 at 15:12 -0700, Wes Hardaker wrote: > way that I'm firmly convinced everyone agrees on: local policy always > trumps everything. EG this is perfectly acceptable: [...] > And that (wacky) policy would always trump any other decision tree in > the code base. Yes. (I apologise in advance for how long some of what follows is.) > o What is the default for "prefer", any_match [most people's opinion] or > first_existing_alg_published_from_list [Viktor's opinion]? It's also my opinion [see next paragraph], speaking with my Exim Developer hat on; alas, ietf.org tends to blackhole my mails, making it rather hard for me to participate. I'd rather not start using a Gmail account just to be able to participate in an IETF discussion, but currently I've left the impression that Viktor is rather alone in his current stance, which is deeply unfortunate. (If this mail doesn't make it through, perhaps a named recipient can forward it on again?) [ done: Viktor. ] I think Viktor's opinion is more accurately stated as "first_existing_alg_published_by_remote_found_in_local_list"; a distinction which emphasizes that it's not central control of algorithms but is instead local control. The issues are around ensuring that default policies are not wacky and SMTP interop can avoid breakage and flag-days. The problem that I see is that the history of SMTP shows that if we leave a lot of ambiguity, people will do some very strange things, even in areas which aren't so security sensitive; further, strange things now have the ability to hinder algorithm agility in the future. So this is not bike-shedding, but is instead trying to provide solid guidance to implementers about what is most likely to provide a solid interoperable solution which doesn't leave us with a lot of unable-to-migrate systems come the day that a practical second pre-image attack is announced against something in the SHA2 family. And please let's not descend into debate about how likely that might be -- the point is to help ensure that security features added now don't needlessly repeat the mistakes of the past. So, whichever path is chosen, "any match" or "first match from your local policy of whichever algs you trust", the spec needs to provide clear guidance so that most MTAs implementing DANE will end up using similar logic. > The choice: > > Do you, Mr. System Administrator defining the local policy for the > *client*, want: > > A) Accept any published hashing algorithm out of my "unordered set" > to validate the remotely presented certificate. [Ordering it > doesn't buy you anything since you'll simply accept a match and it > doesn't matter which you try first, since any success in any > algorithm will equally indicate "ok"; in fact in an implementation > aiming for speed, it might be best to choose the order based on > how fast you can execute the algorithm]. If the server fails to > publish a perfect record set, as long as one matches I'm ok with that. > > B) Believe that the server will always publish perfect records, and > if my "ordered set" of algorithms is [SHA512, SHA256] and they > publish SHA512, then I never want to accept SHA256 because I fear > an attack more than I fear a server administrator blowing their > configuration. The issue is around the time period where there is a widely accepted but then-known-to-be-broken hash algorithm (with a hope that it will become less widely accepted) and another algorithm, at that point in the future then-currently believed to be safe, and what are the effects which will speed or hinder a safe orderly transition to the use of the second algorithm. A separate issue (which doesn't need to hold up this specification) is letting the recipient system know what the impact would be of dropping the old algorithm from the published set. Tony Finch's "Transmitted:" trace header from the draft-fanf-dane-smtp series would help here and it's easy to see how this can build on top of the current work (and does not need to be part of the current work). I'll assume Transmitted: below as shorthand for "or anything equivalent" (eg, RCPT parameter stating for each recipient how the client decided this was the correct server, etc etc). If there is a clearly defined "you should prefer the algorithm which you trust the most, when selecting a TLSA anchor from the set I publish", and later an ability for a server operator to get stats on which anchor the client used, then the server operator can get metrics on which keys are actually used and what the impact of withdrawing the publishing of the old key would be. With the "accept any" approach, the only solution is to stop publishing one day, 15 years after the point when anyone sane would have switched, and discover from the howls of protest the few organisations who are horribly broken. I'd much rather see a designed in decay-curve in the use of the known-broken algorithm, an ability for a future Transmitted: header to be meaningful, a rational basis for recipient postmasters to be able to say "If you cared, you should have told us which was in use with the Transmitted: header. You didn't tell us, and everyone else stopped using it, so we stopped publishing the data which ~everyone thinks is worthless and dangerous if relied upon." > So to recap, first: either of those is fine in local policy knob setting > scheme. Implementations can let administrators of clients configure > sane or insane policies they want. The client side can do whatever it wants, but if it expects to be able to _stay_ secure in the face of ongoing crypto research and not cause every postmaster to curse the idiot vendor, it should use the "have a preferred list and find the first in our list which the remote site published" approach as the default (absent prior site-specific negotiation). > I) what should we do generically? RFC6698 already laid this out as A in > absence of local policy. That's effectively a punt on algorithm agility and disappointing. > II) what should we do in SMTP? This is where Viktor, considering case > #2 above, is wanting to do B ("accept just the 'best' in an ordered set > of algorithms) instead of A. The arguments, though, from both sides > are probably talking about different cases (generic vs SMTP) and I > think that is ending up with some of the confusion. So Viktor and I, representing Postfix and Exim, both want this. > Here's the multiple choice quiz to cap all this off: > > 1. For generic DANE, is the right *default* choice: > > A) Accept any successful matching hash, regardless of "strength". > (This is what 6698 says to do today) > > B) Accept only the strongest hash, from an ordered list, that the > server has published (and DNSSEC has validated the RRSET for). C) Accept the strongest hash, from an ordered list maintained by the client, of those hashes published by the server (as confirmed by DNSSEC yada yada). (This might be B, but your B is still not unambiguously worded, sorry.) I'm only going to push back on those app-specific protocols where I'm an implementer and my code talks, since otherwise I'm making mandates of other people. > 2. For SMTP, is the right (SMTP-application-specific) *default* choice: > > A) Accept any successful matching hash, regardless of "strength". > (This is what 6698 says to do today) > > B) Accept only the strongest hash, from an ordered list, that the > server has published (and DNSSEC has validated the RRSET for). C above. A perhaps implemented but needing explicit action to activate, as a "bug compatibility workaround" for remote sites. > 3. For XMPP: > 4. For HTTP: > 5. For IMAP: No voice, am not an implementer, but I'll cough "C" if people are willing to listen. More generally: approach A can't distinguish between "successful attack on hash" and "remote site bungled". In the event of a mishap, mail queues and postmasters investigate, nothing is lost. This sort of thing happens routinely today (see, eg, mailops mailing list, whenever some big site suddenly starts deferring a lot of mail). People notice. Out-of-band mechanisms are found. Codifying a solution of "thou shalt be vulnerable to the worst hash algorithm you publish, because the clients should accept it as sufficient" is cause for those who care about privacy of incoming mail to stop publishing the hash fast, which breaks verification if clients don't have an alternative. Instead we want a model where operators can allow for migration which always has a trust path, knowing that continuing to publish known-broken only affects integrity of the path for those senders who either only support, or prefer, the known-broken hash algorithm and that everyone _else_ immediately gets the benefit of other published hash algorithms. So, since we're still at the stage where we can avoid going wrong instead of having to try to figure out compatible ways to recover later, can we *please* codify that the default approach should support algorithm agility instead of vulnerability-to-worst-published? Queuing happens, mistakes will get caught with no worst problem than some delayed email, which I argue is far more in keeping with common expectation than "your mail will go through quickly, but we might have sent it onto some attackers, we don't know". -Phil, pdp@exim.org From nobody Fri Mar 21 11:50:10 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 110961A0A42 for ; Fri, 21 Mar 2014 11:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KR2wUEyAZmlT for ; Fri, 21 Mar 2014 11:50:07 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF4B1A0A39 for ; Fri, 21 Mar 2014 11:50:07 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3C2C82AB250; Fri, 21 Mar 2014 18:49:57 +0000 (UTC) Date: Fri, 21 Mar 2014 18:49:57 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140321184957.GA24183@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/6O4EbpMYG8pruHD3Mle0iq4yN3U Subject: [dane] "DANE-TA(2) ? Full(0)" certificate chain matching? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 18:50:09 -0000 [ I am hoping everyone is taking a bit of time to think through the agility issue. We do however need to get it resolved one way or other, so if possible please post concluding comments today or early next week. ] I believe we have reached consensus on DANE-EE(3) end-entity X.509 cert verification: - No name checks based on certificate content (TLSA base domain sufficient) - No expiration checks based on certificate content (DNSSEC sufficient) It is time to consider the issues for DANE-TA(2). The first issue is: With records of the form: _25.mx.example.com. TLSA DANE-TA(2) {blob} where the matching type is really a digest, not Full(0), we've observed that the server operator had better include the matching certificate in his TLS handshake certificate (chain) message, because the verifying client can't match a digest against a certificate it does not have. What do we want to say about: _25.mx.example.com. TLSA DANE-TA(2) SPKI(1) Full(0) {DER-encoded key} In this case the client still typically has no corresponding certificate in hand, and so, if the server does not provide a matching certificate in the TLS handshake, the client cannot "compare" the TLSA record with the server's chain. However, if the server's chain starts with a certificate signed with the trust anchor key in question (obtained from the TLSA record), the client can in principle verify the chain. The Postfix SMTP client in fact does exactly this, uses any "IN TLSA 2 1 0" trust anchor keys to verify "signed-by" even when the server does not present a corresponding TA issuing certificate in his chain. So the question is: - Are clients expected to do this? In other words can servers expect to be able to elide TA certs from their chains when the TA key is in a "2 1 0" TLSA record? - If clients are not expected to do this, there is little point in "IN TLSA 2 1 0", with the key also inside a certificate in the server's chain, it makes a lot more sense to publish "IN TLSA 2 1 X" for some suitable set of digests X. A related question is whether with "DANE-TA(2) Cert(0) Full(0)", there is again a practical need to duplicate the certificate in the server's chain "for matching", or whether this time the server really can avoid duplication, because the client has the cert in hand. Note: The OPS draft discourages "Full(0)" due to potential issues with DNS payload bloat, but these are nevertheless valid, and it would be good to settle on the semantics. -- Viktor. From nobody Sat Mar 22 00:47:54 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAA2D1A0584 for ; Sat, 22 Mar 2014 00:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.731 X-Spam-Level: X-Spam-Status: No, score=-0.731 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Ob-Iw7WAUnZ for ; Sat, 22 Mar 2014 00:47:50 -0700 (PDT) Received: from anguilla.debian.or.at (anguilla.debian.or.at [IPv6:2001:858:10f:6::2]) by ietfa.amsl.com (Postfix) with ESMTP id 91C291A04C5 for ; Sat, 22 Mar 2014 00:47:50 -0700 (PDT) Received: by anguilla.debian.or.at (Postfix, from userid 1002) id 877EA10E7B6; Sat, 22 Mar 2014 08:47:37 +0100 (CET) Date: Sat, 22 Mar 2014 08:47:37 +0100 From: Peter Palfrader To: dane@ietf.org Message-ID: <20140322074737.GA5739@anguilla.noreply.org> References: <20140315051704.GY21390@mournblade.imrryr.org> <0l4n2sa5a0.fsf@wjh.hardakers.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0l4n2sa5a0.fsf@wjh.hardakers.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/rlKWeGjPcYfktNB1uGZ-XnVtWSw Subject: Re: [dane] Digest Algorithm Agility discussion X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Mar 2014 07:47:52 -0000 On Thu, 20 Mar 2014, Wes Hardaker wrote: > Do you, Mr. System Administrator defining the local policy for the > *client*, want: > > A) Accept any published hashing algorithm out of my "unordered set" > to validate the remotely presented certificate. [Ordering it > doesn't buy you anything since you'll simply accept a match and it > doesn't matter which you try first, since any success in any > algorithm will equally indicate "ok"; in fact in an implementation > aiming for speed, it might be best to choose the order based on > how fast you can execute the algorithm]. If the server fails to > publish a perfect record set, as long as one matches I'm ok with that. > > B) Believe that the server will always publish perfect records, and > if my "ordered set" of algorithms is [SHA512, SHA256] and they > publish SHA512, then I never want to accept SHA256 because I fear > an attack more than I fear a server administrator blowing their > configuration. > But the real question, is what is the *default* that we should suggest > an implementation do? > II) what should we do in SMTP? This is where Viktor, considering case > #2 above, is wanting to do B ("accept just the 'best' in an ordered set > of algorithms) instead of A. The arguments, though, from both sides > are probably talking about different cases (generic vs SMTP) and I > think that is ending up with some of the confusion. I'd like to see the SMTP draft suggest B. (All the others should do B too, but that's a different story). Aloha, -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `- http://www.debian.org/ From nobody Sun Mar 23 10:42:51 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 780391A6FF4 for ; Sun, 23 Mar 2014 10:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2JbiMDR_SC2J for ; Sun, 23 Mar 2014 10:42:46 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 1E5E61A0791 for ; Sun, 23 Mar 2014 10:42:46 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 015852383C9; Sun, 23 Mar 2014 17:42:32 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 2056E160060; Sun, 23 Mar 2014 17:43:39 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 1B6E2160047; Sun, 23 Mar 2014 17:43:15 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 63C6111B2111; Mon, 24 Mar 2014 04:42:05 +1100 (EST) To: Peter Palfrader From: Mark Andrews References: <20140315051704.GY21390@mournblade.imrryr.org> <0l4n2sa5a0.fsf@wjh.hardakers.net> <20140322074737.GA5739@anguilla.noreply.org> In-reply-to: Your message of "Sat, 22 Mar 2014 08:47:37 +0100." <20140322074737.GA5739@anguilla.noreply.org> Date: Mon, 24 Mar 2014 04:42:05 +1100 Message-Id: <20140323174205.63C6111B2111@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/dane/v4dfCZa0R2p3d6fbJfiEZGpledM Cc: dane@ietf.org Subject: Re: [dane] Digest Algorithm Agility discussion X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 17:42:48 -0000 In message <20140322074737.GA5739@anguilla.noreply.org>, Peter Palfrader writes: > On Thu, 20 Mar 2014, Wes Hardaker wrote: > > > Do you, Mr. System Administrator defining the local policy for the > > *client*, want: > > > > A) Accept any published hashing algorithm out of my "unordered set" > > to validate the remotely presented certificate. [Ordering it > > doesn't buy you anything since you'll simply accept a match and it > > doesn't matter which you try first, since any success in any > > algorithm will equally indicate "ok"; in fact in an implementation > > aiming for speed, it might be best to choose the order based on > > how fast you can execute the algorithm]. If the server fails to > > publish a perfect record set, as long as one matches I'm ok with that. > > > > B) Believe that the server will always publish perfect records, and > > if my "ordered set" of algorithms is [SHA512, SHA256] and they > > publish SHA512, then I never want to accept SHA256 because I fear > > an attack more than I fear a server administrator blowing their > > configuration. > > > But the real question, is what is the *default* that we should suggest > > an implementation do? > > > II) what should we do in SMTP? This is where Viktor, considering case > > #2 above, is wanting to do B ("accept just the 'best' in an ordered set > > of algorithms) instead of A. The arguments, though, from both sides > > are probably talking about different cases (generic vs SMTP) and I > > think that is ending up with some of the confusion. > > I'd like to see the SMTP draft suggest B. (All the others should do B > too, but that's a different story). > > Aloha, > -- > | .''`. ** Debian ** > Peter Palfrader | : :' : The universal > http://www.palfrader.org/ | `. `' Operating System > | `- http://www.debian.org/ > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane Truly, we do not know which of SHA256 and SHA512 will be broken first. Both are more than strong enough for this job at this point in time. When one is broken it will no longer be strong enough. Neither will be broken by brute force. They will be broken by discoveries of flaws in the algorithms. We support multiple algorithms so that when/if one is broken we do not end up in a situation of having no trusted algorithms supported. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Sun Mar 23 11:21:13 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 835371A6FF9 for ; Sun, 23 Mar 2014 11:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n0gWaz2rr5eP for ; Sun, 23 Mar 2014 11:21:09 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id E93A71A6FF8 for ; Sun, 23 Mar 2014 11:21:08 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 390CE2AB250; Sun, 23 Mar 2014 18:21:07 +0000 (UTC) Date: Sun, 23 Mar 2014 18:21:07 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140323182106.GX24183@mournblade.imrryr.org> References: <20140315051704.GY21390@mournblade.imrryr.org> <0l4n2sa5a0.fsf@wjh.hardakers.net> <20140322074737.GA5739@anguilla.noreply.org> <20140323174205.63C6111B2111@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140323174205.63C6111B2111@rock.dv.isc.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/oo2pyGZswQunR7QgxFtigs_fdPA Subject: Re: [dane] Digest Algorithm Agility discussion X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 18:21:11 -0000 On Mon, Mar 24, 2014 at 04:42:05AM +1100, Mark Andrews wrote: > Truly, we do not know which of SHA256 and SHA512 will be broken > first. Both are more than strong enough for this job at this point > in time. Agree with this 100%. > When one is broken it will no longer be strong enough. > Neither will be broken by brute force. They will be broken by > discoveries of flaws in the algorithms. We support multiple > algorithms so that when/if one is broken we do not end up in a > situation of having no trusted algorithms supported. I assume that once the SHA3 (aka Keccac) specification is finally published by NIST, there will be a DANE-related draft registering at least two new matching type algorithms for TLSA records: 3 SHA3-256 4 SHA3-512 At that point, a client evaluating a TLSA RRset will have a real choice, for example: SHA2-256 vs. SHA3-256. The reason the SHA3 competition was held and the Keccac sponge construction was selected, is that with MD5 and SHA1 looking broken and vulnerable respectively, there was a desire to find new hash primitives that are based on new ideas. So SHA3 is essentially our insurance policy on further progress against the similar SHA1 and SHA2 designs. While for now progress along these lines appears to be stalled, it is not unreasonable to admit the *possibility* that it might resume again. Initially, clients may be configured to prefer SHA2-256 (which is both mandatory to implement and has stood the test of time). However, later if there is any trouble on the SHA2 front, the client can be updated to prefer SHA3 (when published by the server) to SHA2. The proposed specification provides a transition mechanism with no flag day, algorithms can be deprecated (relative to more preferred algorithms) without being disabled. If a server publishes: SHA2-256 SHA2-512 SHA3-256 And the client's preference order is (best to worst): SHA3-256, SHA2-512, SHA2-256, then the client will only evaluate the TLSA records with SHA3-256 digests and if none match, authentication fails. Today the client can prefer: SHA2-256, SHA2-512 And, since both are currently believed well out of reach of even state-funded adversaries, save itself the wasted cycles of computing SHA2-512 when both are published. The point of Wes's choice "B" is that clients don't have to impose a flag on themselves and drop weakened algorithms entirely, given that many servers may not be publishing anything stronger. Instead with "B", the client uses the strongest mutually available option. -- Viktor. From nobody Sun Mar 23 11:57:39 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 820391A09AE for ; Sun, 23 Mar 2014 11:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oW4eb0aQgTYe for ; Sun, 23 Mar 2014 11:57:35 -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 AAD0E1A09A9 for ; Sun, 23 Mar 2014 11:57:35 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 1B6C2C9468 for ; Sun, 23 Mar 2014 18:57:22 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1395601055; bh=NfVtIF26XSyZn30oVNgUxeWM5jGw2m7Gc2n5HiK0GIs=; h=To:From:References:Subject:In-reply-to:Date; b=iYEfs77uaM8/ShzfnE7P3V6aZb7TB3nhBtz9gqwnRag63VYOE84ZuASQstbA31Ocj IvZ+kNaCM+dCX/Iumzeh8fOd+/ebxaEQIKPQ4+wv4V2Nxp5V87buKggAAsbS4weEO+ 4AsciPLNvC4zmVQYCZuOKvl7I0Bowshxjpiqh7wA= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP for ; Sun, 23 Mar 2014 18:57:22 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id C7C73160060 for ; Sun, 23 Mar 2014 18:58:29 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 1B7BD160047 for ; Sun, 23 Mar 2014 18:58:28 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 7A84711B2CB8 for ; Mon, 24 Mar 2014 05:57:18 +1100 (EST) To: dane@ietf.org From: Mark Andrews References: <20140315051704.GY21390@mournblade.imrryr.org> <0l4n2sa5a0.fsf@wjh.hardakers.net> <20140322074737.GA5739@anguilla.noreply.org> <20140323174205.63C6111B2111@rock.dv.isc.org> <20140323182106.GX24183@mournblade.imrryr.org> In-reply-to: Your message of "Sun, 23 Mar 2014 18:21:07 -0000." <20140323182106.GX24183@mournblade.imrryr.org> Date: Mon, 24 Mar 2014 05:57:18 +1100 Message-Id: <20140323185718.7A84711B2CB8@rock.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Archived-At: http://mailarchive.ietf.org/arch/msg/dane/-sWcg2LuKVxnSRENwTHH0UYmErY Subject: Re: [dane] Digest Algorithm Agility discussion X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 18:57:37 -0000 In message <20140323182106.GX24183@mournblade.imrryr.org>, Viktor Dukhovni writ es: > On Mon, Mar 24, 2014 at 04:42:05AM +1100, Mark Andrews wrote: > > > Truly, we do not know which of SHA256 and SHA512 will be broken > > first. Both are more than strong enough for this job at this point > > in time. > > Agree with this 100%. > > > When one is broken it will no longer be strong enough. > > Neither will be broken by brute force. They will be broken by > > discoveries of flaws in the algorithms. We support multiple > > algorithms so that when/if one is broken we do not end up in a > > situation of having no trusted algorithms supported. > > I assume that once the SHA3 (aka Keccac) specification is finally > published by NIST, there will be a DANE-related draft registering > at least two new matching type algorithms for TLSA records: > > 3 SHA3-256 > 4 SHA3-512 > > At that point, a client evaluating a TLSA RRset will have a real > choice, for example: SHA2-256 vs. SHA3-256. > > The reason the SHA3 competition was held and the Keccac sponge > construction was selected, is that with MD5 and SHA1 looking broken > and vulnerable respectively, there was a desire to find new hash > primitives that are based on new ideas. > > So SHA3 is essentially our insurance policy on further progress > against the similar SHA1 and SHA2 designs. While for now progress > along these lines appears to be stalled, it is not unreasonable to > admit the *possibility* that it might resume again. > > Initially, clients may be configured to prefer SHA2-256 (which is > both mandatory to implement and has stood the test of time). However, > later if there is any trouble on the SHA2 front, the client can be > updated to prefer SHA3 (when published by the server) to SHA2. > > The proposed specification provides a transition mechanism with no > flag day, algorithms can be deprecated (relative to more preferred > algorithms) without being disabled. > > If a server publishes: > > SHA2-256 > SHA2-512 > SHA3-256 > > And the client's preference order is (best to worst): > > SHA3-256, > SHA2-512, > SHA2-256, > > then the client will only evaluate the TLSA records with SHA3-256 digests > and if none match, authentication fails. Today the client can prefer: > > SHA2-256, > SHA2-512 > > And, since both are currently believed well out of reach of even > state-funded adversaries, save itself the wasted cycles of computing > SHA2-512 when both are published. > > The point of Wes's choice "B" is that clients don't have to impose > a flag on themselves and drop weakened algorithms entirely, given > that many servers may not be publishing anything stronger. Instead > with "B", the client uses the strongest mutually available option. If you don't trust a algorithm you should not be using it. Period. This fall back to this untrusted/broken algorithm is bad engingeering and bad security practice. If the site you want to email only has broken TLSA records, get them on the phone to fix the problem. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Sun Mar 23 12:10:43 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 903591A09BA for ; Sun, 23 Mar 2014 12:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.031 X-Spam-Level: X-Spam-Status: No, score=-3.031 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f9hWVlMhCYxZ for ; Sun, 23 Mar 2014 12:10:39 -0700 (PDT) Received: from anguilla.debian.or.at (anguilla.debian.or.at [86.59.21.37]) by ietfa.amsl.com (Postfix) with ESMTP id 232DE1A09A9 for ; Sun, 23 Mar 2014 12:10:38 -0700 (PDT) Received: by anguilla.debian.or.at (Postfix, from userid 1002) id DFD6310E7AC; Sun, 23 Mar 2014 20:10:37 +0100 (CET) Date: Sun, 23 Mar 2014 20:10:37 +0100 From: Peter Palfrader To: dane@ietf.org Message-ID: <20140323191037.GA1469@anguilla.noreply.org> References: <20140315051704.GY21390@mournblade.imrryr.org> <0l4n2sa5a0.fsf@wjh.hardakers.net> <20140322074737.GA5739@anguilla.noreply.org> <20140323174205.63C6111B2111@rock.dv.isc.org> <20140323182106.GX24183@mournblade.imrryr.org> <20140323185718.7A84711B2CB8@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140323185718.7A84711B2CB8@rock.dv.isc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/FWI1rtDV8vGwU4VdOmqfzHFsXyM Subject: Re: [dane] Digest Algorithm Agility discussion X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 19:10:41 -0000 On Mon, 24 Mar 2014, Mark Andrews wrote: > If you don't trust a algorithm you should not be using it. Period. > This fall back to this untrusted/broken algorithm is bad engingeering > and bad security practice. > > If the site you want to email only has broken TLSA records, get > them on the phone to fix the problem. Assume we may have reason to believe that SHA1 is within reach of well funded adversaries, and assume it had a code-point in DANE. Site A only publishes SHA1 entries. Would rather do unauthenticated TLS than trust SHA1? Site B publishes both SHA2-512 and SHA1 entries. Would you still want to trust SHA1? -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `- http://www.debian.org/ From nobody Sun Mar 23 12:26:16 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24D491A09BA for ; Sun, 23 Mar 2014 12:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hxPTrUrI9lx for ; Sun, 23 Mar 2014 12:26:14 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id CCBD51A09AE for ; Sun, 23 Mar 2014 12:26:13 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 308632383E9; Sun, 23 Mar 2014 19:26:01 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 5BADE160060; Sun, 23 Mar 2014 19:27:08 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 2E395160047; Sun, 23 Mar 2014 19:27:08 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 7716111B342A; Mon, 24 Mar 2014 06:25:57 +1100 (EST) To: Peter Palfrader From: Mark Andrews References: <20140315051704.GY21390@mournblade.imrryr.org> <0l4n2sa5a0.fsf@wjh.hardakers.net> <20140322074737.GA5739@anguilla.noreply.org> <20140323174205.63C6111B2111@rock.dv.isc.org> <20140323182106.GX24183@mournblade.imrryr.org> <20140323185718.7A84711B2CB8@rock.dv.isc.org> <20140323191037.GA1469@anguilla.noreply.org> In-reply-to: Your message of "Sun, 23 Mar 2014 20:10:37 +0100." <20140323191037.GA1469@anguilla.noreply.org> Date: Mon, 24 Mar 2014 06:25:57 +1100 Message-Id: <20140323192557.7716111B342A@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/dane/XH-pGgrGvUy2uy0Tju_Cez1GZRw Cc: dane@ietf.org Subject: Re: [dane] Digest Algorithm Agility discussion X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 19:26:15 -0000 In message <20140323191037.GA1469@anguilla.noreply.org>, Peter Palfrader writes : > On Mon, 24 Mar 2014, Mark Andrews wrote: > > > If you don't trust a algorithm you should not be using it. Period. > > This fall back to this untrusted/broken algorithm is bad engingeering > > and bad security practice. > > > > If the site you want to email only has broken TLSA records, get > > them on the phone to fix the problem. > > Assume we may have reason to believe that SHA1 is within reach of well > funded adversaries, and assume it had a code-point in DANE. > > Site A only publishes SHA1 entries. Would rather do unauthenticated TLS > than trust SHA1? You left out - report and refuse to send until fixed. > Site B publishes both SHA2-512 and SHA1 entries. Would you still want > to trust SHA1? Once you decide SHA1 is not acceptable you ignore the records with SHA1 hashes. Publishing new hashes is trivial and will remain trivial. Once a algorithm has reached the state where you don't trust it for a purpose you don't use it for thar purpose. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Sun Mar 23 12:57:23 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 780531A09BF for ; Sun, 23 Mar 2014 12:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vlGijyk7Hh2j for ; Sun, 23 Mar 2014 12:57:19 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 47FCE1A09AE for ; Sun, 23 Mar 2014 12:57:18 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 787442AB137; Sun, 23 Mar 2014 19:57:17 +0000 (UTC) Date: Sun, 23 Mar 2014 19:57:17 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140323195717.GA13649@mournblade.imrryr.org> References: <20140315051704.GY21390@mournblade.imrryr.org> <0l4n2sa5a0.fsf@wjh.hardakers.net> <20140322074737.GA5739@anguilla.noreply.org> <20140323174205.63C6111B2111@rock.dv.isc.org> <20140323182106.GX24183@mournblade.imrryr.org> <20140323185718.7A84711B2CB8@rock.dv.isc.org> <20140323191037.GA1469@anguilla.noreply.org> <20140323192557.7716111B342A@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140323192557.7716111B342A@rock.dv.isc.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/nWL06ulZHnj6HHF3uG1mNLm9AFs Subject: Re: [dane] Digest Algorithm Agility discussion X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 19:57:21 -0000 On Mon, Mar 24, 2014 at 06:25:57AM +1100, Mark Andrews wrote: > > Site A only publishes SHA1 entries. Would rather do unauthenticated TLS > > than trust SHA1? > > You left out - report and refuse to send until fixed. Broken is not a binary state. Before previously reasonably sound algorithms are fully broken, they are first tarnished, and our confidence in their strength begins to fray. Refuse to send is a strong reaction, when an algorithm is only tarnished, with no known practical attacks, but known signs of weakness. Have you disabled RC4 in your browser yet? If not, your rather principled stand is "do as I say, not do I as do". > > Site B publishes both SHA2-512 and SHA1 entries. Would you still want > > to trust SHA1? > > Once you decide SHA1 is not acceptable you ignore the records with SHA1 > hashes. A flag day, one can sensibly avoid, by incrementally phasing out (hypothetically) SHA1 as server publish stronger records that include (hypothetically) SHA1 to accommodate weaker clients in addition to stronger digests. > Publishing new hashes is trivial and will remain trivial. Flag days remain a major deployment problem. > Once a algorithm has reached the state where you don't trust it for a > purpose you don't use it for that purpose. That's fine, except at Internet scale. Windows 2003 servers still top out at RC4-SHA1, and at least Exchange 2003 has a broken 3DES implementation. Many server operators only enable RC4 for performance reasons. When exactly should you or I disable RC4-SHA1 support? Fortunately in TLS cipher suites are negotiated. I am trying to do the same for DANE. -- Viktor. From nobody Sun Mar 23 13:00:14 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E55021A09BF for ; Sun, 23 Mar 2014 13:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.731 X-Spam-Level: X-Spam-Status: No, score=-0.731 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAEKFQPyIeFq for ; Sun, 23 Mar 2014 13:00:12 -0700 (PDT) Received: from anguilla.debian.or.at (anguilla.debian.or.at [IPv6:2001:858:10f:6::2]) by ietfa.amsl.com (Postfix) with ESMTP id EA1C51A09AE for ; Sun, 23 Mar 2014 13:00:11 -0700 (PDT) Received: by anguilla.debian.or.at (Postfix, from userid 1002) id 6547310E7AC; Sun, 23 Mar 2014 21:00:08 +0100 (CET) Date: Sun, 23 Mar 2014 21:00:08 +0100 From: Peter Palfrader To: dane@ietf.org Message-ID: <20140323200008.GB1469@anguilla.noreply.org> References: <20140315051704.GY21390@mournblade.imrryr.org> <0l4n2sa5a0.fsf@wjh.hardakers.net> <20140322074737.GA5739@anguilla.noreply.org> <20140323174205.63C6111B2111@rock.dv.isc.org> <20140323182106.GX24183@mournblade.imrryr.org> <20140323185718.7A84711B2CB8@rock.dv.isc.org> <20140323191037.GA1469@anguilla.noreply.org> <20140323192557.7716111B342A@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140323192557.7716111B342A@rock.dv.isc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/Gs0D1NjJAtxFFF0wqWWKSXU3oeg Subject: Re: [dane] Digest Algorithm Agility discussion X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 20:00:13 -0000 On Mon, 24 Mar 2014, Mark Andrews wrote: > > Site A only publishes SHA1 entries. Would rather do unauthenticated TLS > > than trust SHA1? > > You left out - report and refuse to send until fixed. No, that's not what the SMTP draft suggests. When DANE is not there, then servers just fall back to not authenticating a peer's cert, as they do nowadays. -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `- http://www.debian.org/ From nobody Sun Mar 23 13:28:37 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 364011A09E1 for ; Sun, 23 Mar 2014 13:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, J_CHICKENPOX_12=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8AQob5LV_pH for ; Sun, 23 Mar 2014 13:28:33 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 748AC1A09D2 for ; Sun, 23 Mar 2014 13:28:33 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id DF9002AB137; Sun, 23 Mar 2014 20:28:31 +0000 (UTC) Date: Sun, 23 Mar 2014 20:28:31 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140323202831.GB13649@mournblade.imrryr.org> References: <20140315051704.GY21390@mournblade.imrryr.org> <0l4n2sa5a0.fsf@wjh.hardakers.net> <20140322074737.GA5739@anguilla.noreply.org> <20140323174205.63C6111B2111@rock.dv.isc.org> <20140323182106.GX24183@mournblade.imrryr.org> <20140323185718.7A84711B2CB8@rock.dv.isc.org> <20140323191037.GA1469@anguilla.noreply.org> <20140323192557.7716111B342A@rock.dv.isc.org> <20140323200008.GB1469@anguilla.noreply.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140323200008.GB1469@anguilla.noreply.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/9wP2ju05YyNBb4WZYlhTmh1XQz8 Subject: Re: [dane] Digest Algorithm Agility discussion X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 20:28:36 -0000 On Sun, Mar 23, 2014 at 09:00:08PM +0100, Peter Palfrader wrote: > On Mon, 24 Mar 2014, Mark Andrews wrote: > > > > Site A only publishes SHA1 entries. Would rather do unauthenticated TLS > > > than trust SHA1? > > > > You left out - report and refuse to send until fixed. > > No, that's not what the SMTP draft suggests. When DANE is not there, > then servers just fall back to not authenticating a peer's cert, as they > do nowadays. Indeed if one simply considers (again hypothetically) SHA1 to be "unusable", then with no "usable" TLSA records, the connection would fall back to unauthenticated TLS. To do what Mark suggests, we'd have to treat SHA1 as usable, but always fails. That is new code to make SHA1 never match. And still I don't see anyone shooting themselves in the foot with self-imposed flag days for a long time after an algorithm becomes suspect. I sees that, the unstated objection must be a belief that SHA2-256 will never fail, and thus we're wasting time designing solutions to a non-problem. While I don't believe in eternal unbounded progress, and (barring a P=NP revolution) it is likely that at some point we'll have algorithms that never need replacement, it is perhaps premature to declare mission-complete with SHA2. For if we are to take the threat of gradual degradation of our confidence in SHA2 seriously, we need usable approaches for phasing it out. Flag days don't look like usable approaches to me. -- Viktor. From nobody Sun Mar 23 13:51:59 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D90961A07B7 for ; Sun, 23 Mar 2014 13:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zTccpw-Kn4Gp for ; Sun, 23 Mar 2014 13:51:55 -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 CD9901A099B for ; Sun, 23 Mar 2014 13:51:55 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 6E5F6C94B6 for ; Sun, 23 Mar 2014 20:51:41 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1395607915; bh=ljzqxmzJkLFUszlq95dC8jviYTO1hAFavBDRVGmQiGI=; h=To:From:References:Subject:In-reply-to:Date; b=grEUhbBGCNK9gvZA28IWxdBXRWcKo8M4LVszjY09jr8ufYqBN6c+srG8LifVPVud2 h4y5nSDh+zA6vdH2ys+GOCpKkz9+CmuP0kpn6lVjrvVyHtPmYoCpXXoJjGKgF9sWk2 BQ+dY4GQ9RD8G/B8JwHWhzGPsQZj0wfCFzmXeLG8= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP for ; Sun, 23 Mar 2014 20:51:41 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 327CC160060 for ; Sun, 23 Mar 2014 20:52:49 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 0FB3D160047 for ; Sun, 23 Mar 2014 20:52:48 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id D9ACE11B3EAD for ; Mon, 24 Mar 2014 07:51:38 +1100 (EST) To: dane@ietf.org From: Mark Andrews References: <20140315051704.GY21390@mournblade.imrryr.org> <0l4n2sa5a0.fsf@wjh.hardakers.net> <20140322074737.GA5739@anguilla.noreply.org> <20140323174205.63C6111B2111@rock.dv.isc.org> <20140323182106.GX24183@mournblade.imrryr.org> <20140323185718.7A84711B2CB8@rock.dv.isc.org> <20140323191037.GA1469@anguilla.noreply.org> <20140323192557.7716111B342A@rock.dv.isc.org> <20140323195717.GA13649@mournblade.imrryr.org> In-reply-to: Your message of "Sun, 23 Mar 2014 19:57:17 -0000." <20140323195717.GA13649@mournblade.imrryr.org> Date: Mon, 24 Mar 2014 07:51:38 +1100 Message-Id: <20140323205138.D9ACE11B3EAD@rock.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Archived-At: http://mailarchive.ietf.org/arch/msg/dane/TkE_yZl2zU9sZ6HDmPRLwqeLDNs Subject: Re: [dane] Digest Algorithm Agility discussion X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 20:51:58 -0000 In message <20140323195717.GA13649@mournblade.imrryr.org>, Viktor Dukhovni writ es: > On Mon, Mar 24, 2014 at 06:25:57AM +1100, Mark Andrews wrote: > > > > Site A only publishes SHA1 entries. Would rather do unauthenticated TLS > > > than trust SHA1? > > > > You left out - report and refuse to send until fixed. > > Broken is not a binary state. Before previously reasonably sound > algorithms are fully broken, they are first tarnished, and our > confidence in their strength begins to fray. > > Refuse to send is a strong reaction, when an algorithm is only > tarnished, with no known practical attacks, but known signs of > weakness. Have you disabled RC4 in your browser yet? If not, your > rather principled stand is "do as I say, not do I as do". > > > > Site B publishes both SHA2-512 and SHA1 entries. Would you still want > > > to trust SHA1? > > > > Once you decide SHA1 is not acceptable you ignore the records with SHA1 > > hashes. > > A flag day, one can sensibly avoid, by incrementally phasing out > (hypothetically) SHA1 as server publish stronger records that include > (hypothetically) SHA1 to accommodate weaker clients in addition to stronger > digests. > > > Publishing new hashes is trivial and will remain trivial. > > Flag days remain a major deployment problem. > > > Once a algorithm has reached the state where you don't trust it for a > > purpose you don't use it for that purpose. > > That's fine, except at Internet scale. Windows 2003 servers still > top out at RC4-SHA1, and at least Exchange 2003 has a broken 3DES > implementation. Many server operators only enable RC4 for > performance reasons. And the reason for that is that is that Microsoft has no presure on it to release service packs with newer algorithms as clients fall back to the known too weak algorithms. The clients are not getting the security they think they are. What Microsoft should do is release updated clients that do not support RC4 and also release server packs which support newer algorithms. > When exactly should you or I disable RC4-SHA1 support? Fortunately > in TLS cipher suites are negotiated. I am trying to do the same > for DANE. There is NOTHING preventing implementations from ranking hash algorithms. There is NOTHING preventing implementations from having a accept/reject. There is no reason to REQUIRE implementations to ranking hash algorithms. Supporting out of date clients does a disservice to both yourself and them. > -- > 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 nobody Sun Mar 23 16:01:50 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3331A6F7E for ; Sun, 23 Mar 2014 16:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.411 X-Spam-Level: X-Spam-Status: No, score=-1.411 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_12=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rbRb9f4bhXqJ for ; Sun, 23 Mar 2014 16:01:46 -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 AE38D1A07F9 for ; Sun, 23 Mar 2014 16:01:46 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 5DE80C94B6 for ; Sun, 23 Mar 2014 23:01:33 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1395615706; bh=gA1opKnV/ehNPE5aR53HjvgGlQycyFGHRp5SElNHKoE=; h=To:From:References:Subject:In-reply-to:Date; b=uzXiu1xcG8kh3rarFedC+XzkPVhxzlP7hDR4Rhuw2gHLIYzcjJnq98VTEVJM77J3q 7QHIcK6B4790tH26fv31dri3Osg/WV8YI0zq4cK2D2GDEfN6ueeMUAss9T/GWEY+on QSl7ib4Whd19fZXPXLAETwMAxLoM2u5VqZFsRvjQ= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP for ; Sun, 23 Mar 2014 23:01:33 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 2CDF6160060 for ; Sun, 23 Mar 2014 23:02:41 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 55881160047 for ; Sun, 23 Mar 2014 23:02:40 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id EF23411B4816 for ; Mon, 24 Mar 2014 10:01:25 +1100 (EST) To: dane@ietf.org From: Mark Andrews References: <20140315051704.GY21390@mournblade.imrryr.org> <0l4n2sa5a0.fsf@wjh.hardakers.net> <20140322074737.GA5739@anguilla.noreply.org> <20140323174205.63C6111B2111@rock.dv.isc.org> <20140323182106.GX24183@mournblade.imrryr.org> <20140323185718.7A84711B2CB8@rock.dv.isc.org> <20140323191037.GA1469@anguilla.noreply.org> <20140323192557.7716111B342A@rock.dv.isc.org> <20140323200008.GB1469@anguilla.noreply.org> <20140323202831.GB13649@mournblade.imrryr.org> In-reply-to: Your message of "Sun, 23 Mar 2014 20:28:31 -0000." <20140323202831.GB13649@mournblade.imrryr.org> Date: Mon, 24 Mar 2014 10:01:25 +1100 Message-Id: <20140323230125.EF23411B4816@rock.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Archived-At: http://mailarchive.ietf.org/arch/msg/dane/NVnrtFrUA7Ec6syWzZ5DL7RefQE Subject: Re: [dane] Digest Algorithm Agility discussion X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 23:01:48 -0000 In message <20140323202831.GB13649@mournblade.imrryr.org>, Viktor Dukhovni writ es: > On Sun, Mar 23, 2014 at 09:00:08PM +0100, Peter Palfrader wrote: > > > On Mon, 24 Mar 2014, Mark Andrews wrote: > > > > > > Site A only publishes SHA1 entries. Would rather do unauthenticated TL > S > > > > than trust SHA1? > > > > > > You left out - report and refuse to send until fixed. > > > > No, that's not what the SMTP draft suggests. When DANE is not there, > > then servers just fall back to not authenticating a peer's cert, as they > > do nowadays. The SMTP draft says how to securely go from a email domain to a CERT using DNSSEC and TLSA. It does not say whether one should use a non secure connection or not. That is seperate policy. > Indeed if one simply considers (again hypothetically) SHA1 to be > "unusable", then with no "usable" TLSA records, the connection > would fall back to unauthenticated TLS. It might or it might not. That is a seperate policy decision. > To do what Mark suggests, we'd have to treat SHA1 as usable, but > always fails. That is new code to make SHA1 never match. One will have something like if (!supported(match)) skip record; > And > still I don't see anyone shooting themselves in the foot with > self-imposed flag days for a long time after an algorithm becomes > suspect. > > I sees that, the unstated objection must be a belief that SHA2-256 > will never fail, and thus we're wasting time designing solutions > to a non-problem. While I don't believe in eternal unbounded > progress, and (barring a P=NP revolution) it is likely that at some > point we'll have algorithms that never need replacement, it is > perhaps premature to declare mission-complete with SHA2. I don't assume that it will never be broken. I also don't think we need to "if has_alg(a) then {} else {}". > For if we are to take the threat of gradual degradation of our > confidence in SHA2 seriously, we need usable approaches for phasing > it out. Flag days don't look like usable approaches to me. > > -- > 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 nobody Sun Mar 23 16:57:33 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0794B1A0055 for ; Sun, 23 Mar 2014 16:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, J_CHICKENPOX_12=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYFxLiXoATp7 for ; Sun, 23 Mar 2014 16:57:29 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 760861A0054 for ; Sun, 23 Mar 2014 16:57:29 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 73DCF2AB137; Sun, 23 Mar 2014 23:57:27 +0000 (UTC) Date: Sun, 23 Mar 2014 23:57:27 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140323235727.GC13649@mournblade.imrryr.org> References: <0l4n2sa5a0.fsf@wjh.hardakers.net> <20140322074737.GA5739@anguilla.noreply.org> <20140323174205.63C6111B2111@rock.dv.isc.org> <20140323182106.GX24183@mournblade.imrryr.org> <20140323185718.7A84711B2CB8@rock.dv.isc.org> <20140323191037.GA1469@anguilla.noreply.org> <20140323192557.7716111B342A@rock.dv.isc.org> <20140323200008.GB1469@anguilla.noreply.org> <20140323202831.GB13649@mournblade.imrryr.org> <20140323230125.EF23411B4816@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140323230125.EF23411B4816@rock.dv.isc.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/tfYgdSFuXP8PXVAnIV5BfNQaCcU Subject: Re: [dane] Digest Algorithm Agility discussion X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 23:57:31 -0000 On Mon, Mar 24, 2014 at 10:01:25AM +1100, Mark Andrews wrote: > > > No, that's not what the SMTP draft suggests. When DANE is not there, > > > then servers just fall back to not authenticating a peer's cert, as they > > > do nowadays. > > The SMTP draft says how to securely go from a email domain to a > CERT using DNSSEC and TLSA. It does not say whether one should use > a non secure connection or not. That is separate policy. Section 2.2: A Secure non-empty TLSA RRset where all the records are unusable: A connection to the MTA MUST be made via TLS, but authentication is not required. Failure to establish an encrypted TLS connection MUST result in falling back to the next SMTP server or delayed delivery. No, it is primarily a draft for opportunistic SMTP TLS at Internet scale, where per-destination policy does not scale. The default policy for the Internet as a whole, for reasons explained in the introduction, cannot be PKIX authenticated TLS. Therefore, when the TLSA records are entirely unusable, and in keeping with Tony's original work on the SRV draft, the client reverts to legacy mandatory (practically always unauthenticated) TLS. > > Indeed if one simply considers (again hypothetically) SHA1 to be > > "unusable", then with no "usable" TLSA records, the connection > > would fall back to unauthenticated TLS. > > It might or it might not. That is a separate policy decision. Policy can't revoke reality. Without usable TLSA records SMTP TLS cannot be authenticated at scale. There can be pockets of authenticated SMTP between some clusters of domains, but the scope of the draft is the vast majority of MTA to MTA connections not covered by explicit per-destination local policy. > > To do what Mark suggests, we'd have to treat SHA1 as usable, but > > always fails. That is new code to make SHA1 never match. > > One will have something like > > if (!supported(match)) > skip record; Which needs to be different from considering the record "unusable", because the matching type is unknown to the client. The record is retained for purposes of determining whether any "usable" records are found, but skipped without being used. And still an unnecessary flag day. > > It seems that, the unstated objection must be a belief that SHA2-256 > > will never fail, and thus we're wasting time designing solutions > > to a non-problem. While I don't believe in eternal unbounded > > progress, and (barring a P=NP revolution) it is likely that at some > > point we'll have algorithms that never need replacement, it is > > perhaps premature to declare mission-complete with SHA2. > > I don't assume that it will never be broken. I also don't think we > need to "if has_alg(a) then {} else {}". And yet you object to specifying a mechanism for non-disruptive transition to better digests should one of the previously trusted digests become tarnished. Is the objection to the agility mechanism per-se, or to saying that clients SHOULD employ it? I seem to recall you saying that clients already *may* employ the proposed mechanism. If so server operators need to know that their TLSA records SHOULD be structured to interoperate with policies that ignore some subset of the published digests, so that part goes into at least the operational considerations section, and likely into the OPS draft. Is it your view point then that the proposed mechanism should be a BCP, and not a requirement? Why? What's the value of having a free-for-all on how digests are phased out? When servers don't know that clients ignore weaker digests, they are more likely to remove these from their TLSA records early, resulting in lower security with clients that only support the weaker (but not necessarily easily broken) digests. -- Viktor. From nobody Mon Mar 24 07:54:48 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45BEE1A0243 for ; Mon, 24 Mar 2014 07:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.69 X-Spam-Level: X-Spam-Status: No, score=0.69 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vaJvB2z6PyPY for ; Mon, 24 Mar 2014 07:54:40 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 00D3D1A0220 for ; Mon, 24 Mar 2014 07:54:38 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 122F4800AA for ; Mon, 24 Mar 2014 10:54:36 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1395672876; bh=60aIxl25Kj10tttV+RG5I6LhDppQtVZ6brI1YIW5Q98=; h=Date:From:To:Subject:In-Reply-To:References; b=shTMd/fUfnQcnLi1Wa8bpwiHWzNvelkqR2WgdTgefXs7oJvyyLMxPuT1VB0tsq25g dVHBrrzE6H07MG3a91+quS/1dY8MC4UOVwhru6HTbvN+09fF1I7FqJYFjdnejKUAd/ TyRJsA0sJ6lmDSkxoki9gxLxHM2Zx8uF72w/qDkY= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s2OEsZaf025250 for ; Mon, 24 Mar 2014 10:54:35 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 24 Mar 2014 10:54:35 -0400 (EDT) From: Paul Wouters To: dane@ietf.org In-Reply-To: <20140323235727.GC13649@mournblade.imrryr.org> Message-ID: References: <0l4n2sa5a0.fsf@wjh.hardakers.net> <20140322074737.GA5739@anguilla.noreply.org> <20140323174205.63C6111B2111@rock.dv.isc.org> <20140323182106.GX24183@mournblade.imrryr.org> <20140323185718.7A84711B2CB8@rock.dv.isc.org> <20140323191037.GA1469@anguilla.noreply.org> <20140323192557.7716111B342A@rock.dv.isc.org> <20140323200008.GB1469@anguilla.noreply.org> <20140323202831.GB13649@mournblade.imrryr.org> <20140323230125.EF23411B4816@rock.dv.isc.org> <20140323235727.GC13649@mournblade.imrryr.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dane/4n0AsL1BDli7IkuPXj-Hqctkz1g Subject: Re: [dane] Digest Algorithm Agility discussion X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 14:54:44 -0000 On Sun, 23 Mar 2014, Viktor Dukhovni wrote: > when the TLSA records are entirely unusable, and in keeping with Tony's > original work on the SRV draft, the client reverts to legacy > mandatory (practically always unauthenticated) TLS. That's unfortunate. Perhaps it depends on the definition of "unusable", but if all TLSA records for instance fail the RRSIG validation, I would hope that postfix would abort delivery attempts and definately _not_ fallback to unauthenticated TLS. Paul From nobody Mon Mar 24 08:33:52 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94DD71A01C6 for ; Mon, 24 Mar 2014 08:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBYbifsKwTAv for ; Mon, 24 Mar 2014 08:33:48 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 416E21A01B9 for ; Mon, 24 Mar 2014 08:33:48 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 110BD2AB250; Mon, 24 Mar 2014 15:33:46 +0000 (UTC) Date: Mon, 24 Mar 2014 15:33:46 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140324153345.GF13649@mournblade.imrryr.org> References: <20140323174205.63C6111B2111@rock.dv.isc.org> <20140323182106.GX24183@mournblade.imrryr.org> <20140323185718.7A84711B2CB8@rock.dv.isc.org> <20140323191037.GA1469@anguilla.noreply.org> <20140323192557.7716111B342A@rock.dv.isc.org> <20140323200008.GB1469@anguilla.noreply.org> <20140323202831.GB13649@mournblade.imrryr.org> <20140323230125.EF23411B4816@rock.dv.isc.org> <20140323235727.GC13649@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.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/H8zy4padM1fCV9IwNstrFkC_m2c Subject: Re: [dane] Digest Algorithm Agility discussion X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 15:33:50 -0000 On Mon, Mar 24, 2014 at 10:54:35AM -0400, Paul Wouters wrote: > On Sun, 23 Mar 2014, Viktor Dukhovni wrote: > > >when the TLSA records are entirely unusable, and in keeping with Tony's > >original work on the SRV draft, the client reverts to legacy > >mandatory (practically always unauthenticated) TLS. > > That's unfortunate. Perhaps it depends on the definition of "unusable", > but if all TLSA records for instance fail the RRSIG validation, I would > hope that Postfix would abort delivery attempts and definitely _not_ > fall back to unauthenticated TLS. Unusable is quite different from "fails validation". When "usable" records are found, but none match (all fail validation), delivery is aborted. The "unusable" case is when at least one of the TLSA *parameters* is unsupported, the digest value has an impossible length, or a full value is malformed: example.com. IN TLSA ???(50) SPKI(1) SHA2-512(2) {hex for 64-byte blob} example.com. IN TLSA DANE-EE(3) ???(2) SHA2-512(2) {hex for 64-byte blob} example.com. IN TLSA DANE-EE(3) SPKI(1) ???(3) {hex for 64-byte blob} example.com. IN TLSA DANE-EE(3) SPKI(1) SHA2-512(2) {hex for 32-byte blob} example.com. IN TLSA DANE-EE(3) SPKI(1) Full(0) {not ASN.1 of SPKI} example.com. IN TLSA DANE-EE(3) Cert(0) Full(0) {not ASN.1 of X.509 cert} If all records are "unusable", Postfix falls back to unauthenticated TLS. The administrator may be in a position to configure Postfix to "test-drive" "DANE TLS" in a mode where validation failures are tolerated and logged (DANE audit rather than enforcement), but that's quite different from ignoring validation failures. The default (when DANE TLS is enabled) is "enforce". Support for "audit" mode is under development, and is not DANE TLS specific. It supports audited fallback from all verified (authenticated) TLS policies to either enforced unauthenticated TLS, or even just plain opportunistic TLS (with cleartext fallback). In all cases failure to arrive at the desired security state is logged. -- Viktor. From nobody Mon Mar 24 08:34:11 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C678D1A0236 for ; Mon, 24 Mar 2014 08:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.731 X-Spam-Level: X-Spam-Status: No, score=-0.731 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1DQ4mKhBBDNI for ; Mon, 24 Mar 2014 08:34:00 -0700 (PDT) Received: from anguilla.debian.or.at (anguilla.debian.or.at [IPv6:2001:858:10f:6::2]) by ietfa.amsl.com (Postfix) with ESMTP id E923A1A0188 for ; Mon, 24 Mar 2014 08:33:59 -0700 (PDT) Received: by anguilla.debian.or.at (Postfix, from userid 1002) id 6E8D010E7AC; Mon, 24 Mar 2014 16:33:58 +0100 (CET) Date: Mon, 24 Mar 2014 16:33:58 +0100 From: Peter Palfrader To: Paul Wouters Message-ID: <20140324153358.GO1469@anguilla.noreply.org> References: <20140323174205.63C6111B2111@rock.dv.isc.org> <20140323182106.GX24183@mournblade.imrryr.org> <20140323185718.7A84711B2CB8@rock.dv.isc.org> <20140323191037.GA1469@anguilla.noreply.org> <20140323192557.7716111B342A@rock.dv.isc.org> <20140323200008.GB1469@anguilla.noreply.org> <20140323202831.GB13649@mournblade.imrryr.org> <20140323230125.EF23411B4816@rock.dv.isc.org> <20140323235727.GC13649@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) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/0QoSr8uPRb1eWO3j_Hg7SNXkjGY Cc: dane@ietf.org Subject: Re: [dane] Digest Algorithm Agility discussion X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 15:34:02 -0000 On Mon, 24 Mar 2014, Paul Wouters wrote: > On Sun, 23 Mar 2014, Viktor Dukhovni wrote: > > >when the TLSA records are entirely unusable, and in keeping with Tony's > >original work on the SRV draft, the client reverts to legacy > >mandatory (practically always unauthenticated) TLS. > > That's unfortunate. Perhaps it depends on the definition of "unusable", > but if all TLSA records for instance fail the RRSIG validation, I would > hope that postfix would abort delivery attempts and definately _not_ > fallback to unauthenticated TLS. 2.1. of draft-ietf-dane-smtp-with-dane-07: } When a DNS lookup failure (error or "bogus" or "indeterminate" as } defined above) prevents an SMTP client from determining which SMTP } server or servers it should connect to, message delivery MUST be } delayed. Unusable thus would mean we don't know or like the digest type, or usage, selector, or matching type. The 07 dane smtp draft further says: } A Secure non-empty TLSA RRset where all the records are unusable: A } connection to the MTA MUST be made via TLS, but authentication is } not required. Failure to establish an encrypted TLS connection } MUST result in falling back to the next SMTP server or delayed } delivery. Cheers, -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `- http://www.debian.org/ From nobody Mon Mar 24 08:37:12 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D37C71A0238 for ; Mon, 24 Mar 2014 08:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.355 X-Spam-Level: ** X-Spam-Status: No, score=2.355 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.793] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tds5Zqso7abz for ; Mon, 24 Mar 2014 08:37:09 -0700 (PDT) Received: from mail.hardakers.net (unknown [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id B1ED41A023C for ; Mon, 24 Mar 2014 08:37:09 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id A6923257FA; Mon, 24 Mar 2014 08:37:08 -0700 (PDT) From: Wes Hardaker To: Paul Wouters References: <0l4n2sa5a0.fsf@wjh.hardakers.net> <20140322074737.GA5739@anguilla.noreply.org> <20140323174205.63C6111B2111@rock.dv.isc.org> <20140323182106.GX24183@mournblade.imrryr.org> <20140323185718.7A84711B2CB8@rock.dv.isc.org> <20140323191037.GA1469@anguilla.noreply.org> <20140323192557.7716111B342A@rock.dv.isc.org> <20140323200008.GB1469@anguilla.noreply.org> <20140323202831.GB13649@mournblade.imrryr.org> <20140323230125.EF23411B4816@rock.dv.isc.org> <20140323235727.GC13649@mournblade.imrryr.org> Date: Mon, 24 Mar 2014 08:37:08 -0700 In-Reply-To: (Paul Wouters's message of "Mon, 24 Mar 2014 10:54:35 -0400 (EDT)") Message-ID: <0l4n2nbobf.fsf@wjh.hardakers.net> User-Agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/dane/-p3L6caj914i1ekVIEszG022Ql8 Cc: dane@ietf.org Subject: Re: [dane] Digest Algorithm Agility discussion X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 15:37:11 -0000 Paul Wouters writes: > On Sun, 23 Mar 2014, Viktor Dukhovni wrote: > >> when the TLSA records are entirely unusable, and in keeping with Tony's >> original work on the SRV draft, the client reverts to legacy >> mandatory (practically always unauthenticated) TLS. > > That's unfortunate. Perhaps it depends on the definition of "unusable", > but if all TLSA records for instance fail the RRSIG validation, I would > hope that postfix would abort delivery attempts and definately _not_ > fallback to unauthenticated TLS. Yes, this is the case Paul (no need to worry). >From 6698: // unusable records include unknown certUsage, unknown // selectorType, unknown matchingType, erroneous RDATA, and // prohibited by local policy Within the SMTP draft, DNSSEC and, for that matter, any DNS error indicates a full stop with that MX host. It'll try other hosts, and if they're broken too then delay. The unusable indicates "I can't understand the TLSA record for some reason", not "the hash didn't match" or "was not validated". -- Wes Hardaker Parsons From nobody Mon Mar 24 09:02:53 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FEDA1A0239 for ; Mon, 24 Mar 2014 09:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6QTTrICAyzHH for ; Mon, 24 Mar 2014 09:02:50 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by ietfa.amsl.com (Postfix) with ESMTP id CDA8F1A01B9 for ; Mon, 24 Mar 2014 09:02:49 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 052582E969; Mon, 24 Mar 2014 09:02:49 -0700 (PDT) From: Wes Hardaker To: Mark Andrews References: <20140315051704.GY21390@mournblade.imrryr.org> <0l4n2sa5a0.fsf@wjh.hardakers.net> <20140322074737.GA5739@anguilla.noreply.org> <20140323174205.63C6111B2111@rock.dv.isc.org> <20140323182106.GX24183@mournblade.imrryr.org> <20140323185718.7A84711B2CB8@rock.dv.isc.org> Date: Mon, 24 Mar 2014 09:02:48 -0700 In-Reply-To: <20140323185718.7A84711B2CB8@rock.dv.isc.org> (Mark Andrews's message of "Mon, 24 Mar 2014 05:57:18 +1100") Message-ID: <0ld2hba8k7.fsf@wjh.hardakers.net> User-Agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/dane/gU5FqwbObxZjNwh7CkfO2tZsvVc Cc: dane@ietf.org Subject: Re: [dane] Digest Algorithm Agility discussion X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 16:02:51 -0000 Mark Andrews writes: > If the site you want to email only has broken TLSA records, get > them on the phone to fix the problem. I agree with you, that's the ideal right solution! However, the world is a bit bigger than you can safely war-dial with a problem. This has been proven time and time again by the slow role out of every protocol on the planet. EG, apparently not enough phone calls have been made to the recursive resolvers of every ISP that fail to turn on DNSSEC validation. It's simply not scalable to fall back to a phone call, or even automated email. If we could, indeed, convince the world to upgrade quickly just by contacting them, we wouldn't have a BCP38 problems, spam problems, IPv4 address space problems, and insecure algorithms in use problems. But we very very much do. Otherwise, shouldn't we also call every SMTP service provider for every zone and tell them to turn on TLS? We haven't done that either (nor will anyone). So, the alternative is to have a sliding roll-out that can support the case where 50% of the world is in a new state and 50% is in the old state. Opportunistic turning-on of anything results in "when both parties support it, it magically happens". That includes both the DANE/SMTP protocol itself, as well as the algorithm selection by preferring a stronger one over a weaker one, but not stopping delivery to the 50% of the world that hasn't switched yet. The world has yet to succeed in a single flag day for any protocol. Not one. -- Wes Hardaker Parsons From nobody Wed Mar 26 15:25:20 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2381A03DB for ; Wed, 26 Mar 2014 15:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxDka3E-bLPm for ; Wed, 26 Mar 2014 15:25:14 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 257F01A0274 for ; Wed, 26 Mar 2014 15:25:13 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id DC63D2AAC73; Wed, 26 Mar 2014 22:25:11 +0000 (UTC) Date: Wed, 26 Mar 2014 22:25:11 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140326222511.GE13649@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/zk4Grky4ivfiVMDa-0Un1bdbuJM Subject: [dane] Repost: "DANE-TA(2) ? Full(0)" certificate chain matching? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 22:25:17 -0000 [ Repost, no feedback received. Question summary: * Are clients supposed to check "signed-by" via bare TA keys (2 1 0) that have no matching certificate in the server's chain (say root TA left out of chain per normal PKIX practice)? * Are clients supposed to be able to augment the server chain with any (2 0 0) DANE-TA certificate obtained from DNS, if that certificate is missing from the server's chain? ] I believe we have reached consensus on DANE-EE(3) end-entity X.509 cert verification: - No name checks based on certificate content (TLSA base domain sufficient) - No expiration checks based on certificate content (DNSSEC sufficient) It is time to consider the issues for DANE-TA(2). The first issue is: With records of the form: _25.mx.example.com. TLSA DANE-TA(2) {blob} where the matching type is really a digest, not Full(0), we've observed that the server operator had better include the matching certificate in his TLS handshake certificate (chain) message, because the verifying client can't match a digest against a certificate it does not have. What do we want to say about: _25.mx.example.com. TLSA DANE-TA(2) SPKI(1) Full(0) {DER-encoded key} In this case the client still typically has no corresponding certificate in hand, and so, if the server does not provide a matching certificate in the TLS handshake, the client cannot "compare" the TLSA record with the server's chain. However, if the server's chain starts with a certificate signed with the trust anchor key in question (obtained from the TLSA record), the client can in principle verify the chain. The Postfix SMTP client in fact does exactly this, uses any "IN TLSA 2 1 0" trust anchor keys to verify "signed-by" even when the server does not present a corresponding TA issuing certificate in his chain. So the question is: - Are clients expected to do this? In other words can servers expect to be able to elide TA certs from their chains when the TA key is in a "2 1 0" TLSA record? - If clients are not expected to do this, there is little point in "IN TLSA 2 1 0", with the key also inside a certificate in the server's chain, it makes a lot more sense to publish "IN TLSA 2 1 X" for some suitable set of digests X. A related question is whether with "DANE-TA(2) Cert(0) Full(0)", there is again a practical need to duplicate the certificate in the server's chain "for matching", or whether this time the server really can avoid duplication, because the client has the cert in hand. Note: The OPS draft discourages "Full(0)" due to potential issues with DNS payload bloat, but these are nevertheless valid, and it would be good to settle on the semantics. -- Viktor.