From nobody Tue Feb 2 15:58:04 2016 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 554DE1A910B for ; Tue, 2 Feb 2016 15:58:03 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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 ThOSi9ykt1nI for ; Tue, 2 Feb 2016 15:58:02 -0800 (PST) Received: from mail-qg0-x264.google.com (mail-qg0-x264.google.com [IPv6:2607:f8b0:400d:c04::264]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB86F1A9109 for ; Tue, 2 Feb 2016 15:58:00 -0800 (PST) Received: by mail-qg0-x264.google.com with SMTP id t74so634204qgt.2 for ; Tue, 02 Feb 2016 15:58:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verisign-com.20150623.gappssmtp.com; s=20150623; h=from:to:subject:thread-topic:thread-index:date:message-id :accept-language:content-language:user-agent:content-type :mime-version; bh=CbJhFolmY9xCW5Kw/v4UNqvoV2eom/WgJagGsyZBNQ4=; b=ypr9vIBGfzi58p4KXWVSm93DV7Ti7KIV/Rzxd+72Wu1Y6uwa2yoW2TJRzFVUebK/mR Qk93O6a3A71AiBcQaw2Ptz5f/QQGjA+1AH8p0Xa9Jkz4yJ3oach2oF7WehvqJc4EpeYj wwjCirI8zTBZDOm4wIuO5ufcjrI3d+zTRxCntso07tJQ+BnatfUuyHk5QNJH+9IWcheN TKwlZKsUoZTIVVICQzUfLGcmnTB+2BMAXxiqb2MvUBdf5BAUb/G0JPzqS1vHcqx9vFZb 4zFptgLvbX0tsQ/rXExl3GURtRZrF6pIVCNbWKy1qTyuP8wlLhQq71o5pqRdpaHo3oYK NBLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:accept-language:content-language:user-agent:content-type :mime-version; bh=CbJhFolmY9xCW5Kw/v4UNqvoV2eom/WgJagGsyZBNQ4=; b=esLuKq0L/BsyAlF3TYQoycvoZs2yR72isefnhDh3jRRF3KPk83IuUiVWZY4A6P9r+5 eoo8ZB11vB0AkwgfX4LJIxhSk9Y/TSJCFheCNhwHfEcNYPPMswNWyRQ1YKxYVU5gNUbE KUb0uJbIynZDXyrEl1bNnkTFzLy3MG5ecEU7TTycN+2iUGnMudxEaJj9Rw0iDponOW8T ZCQXOSRzukKb0T1RjjlgN/xdkrl0/FeekDFRghw7T8/I9QQAi3yRwDPcPlTeDkjG18wG UyfkueaLQxrE9Y00LGYHRWz456I6CUdUY4qHB5qMdO93g99iO+OwXelapnNPGIfu/h+D JnEQ== X-Gm-Message-State: AG10YOTO8WRhyPexfN7WoGik7XHhg11kGV3FYEE12VhAn9HDiDwYb/laKeW6yWjJx+NjzC6eYpsWUXqRTF3So41WJS9+2dIy X-Received: by 10.140.178.195 with SMTP id y186mr23124090qhy.100.1454457480095; Tue, 02 Feb 2016 15:58:00 -0800 (PST) Received: from brn1lxmailout01.verisign.com (brn1lxmailout01.verisign.com. [72.13.63.41]) by smtp-relay.gmail.com with ESMTPS id u191sm523382qka.2.2016.02.02.15.57.59 for (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 02 Feb 2016 15:58:00 -0800 (PST) X-Relaying-Domain: verisign.com Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01 [10.173.152.205]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id u12NvxBT014193 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 2 Feb 2016 18:57:59 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 2 Feb 2016 18:57:57 -0500 From: "Wiley, Glen" To: "dane@ietf.org" Thread-Topic: using DMARC to signal policy for email canonicalization, signing and encryption Thread-Index: AQHRXhWJTMInNB761k6xtmtGH06GmQ== Date: Tue, 2 Feb 2016 23:57:57 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [10.173.152.4] Content-Type: multipart/alternative; boundary="_000_D2D6ACC024CABgwileyverisigncom_" MIME-Version: 1.0 Archived-At: Subject: [dane] using DMARC to signal policy for email canonicalization, signing and encryption 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, 02 Feb 2016 23:58:03 -0000 --_000_D2D6ACC024CABgwileyverisigncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In light of all of the discussion about how the LHS of email addresses are = normalized and encoded/hashed in order to be used to publish certificates a= nd keys via DANE records like SMIMEA and OPENPGPKEY we have put together an= approach that lets a zone owner signal the policy that is used for their d= omain by adding a few keywords to the DMARC record. The draft is at: https://datatracker.ietf.org/doc/draft-osterweil-dmarc-dan= e-names/ We welcome discussion about this approach. -- Glen Wiley Principal Engineer Verisign, Inc. (571) 230-7917 A5E5 E373 3C75 5B3E 2E24 6A0F DC65 2354 9946 C63A --_000_D2D6ACC024CABgwileyverisigncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <1761EB4A5D70F1489C88A40CEFE01D84@verisign.com> Content-Transfer-Encoding: quoted-printable
In light of all of the discussion about how the LHS of email addresses= are normalized and encoded/hashed in order to be used to publish certifica= tes and keys via DANE records like SMIMEA and OPENPGPKEY we have put togeth= er an approach that lets a zone owner signal the policy that is used for their domain by adding a few keyw= ords to the DMARC record.


We welcome discussion about this approach.
-- 
Glen Wiley
Principal Engineer
Verisign, Inc.
(571) 230-7917

A5E5 E373 3C75 5B= 3E 2E24 &n= bsp;
6A0F DC65 2354 99= 46 C63A
--_000_D2D6ACC024CABgwileyverisigncom_-- From nobody Wed Feb 3 01:23:05 2016 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 9D2F01A874F for ; Wed, 3 Feb 2016 01:23:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.992 X-Spam-Level: * X-Spam-Status: No, score=1.992 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.001, 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 BZNGFmwVoeO1 for ; Wed, 3 Feb 2016 01:23:03 -0800 (PST) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E49A61A874E for ; Wed, 3 Feb 2016 01:23:02 -0800 (PST) Received: from titanium.fritz.box (HSI-KBW-134-3-117-69.hsi14.kabel-badenwuerttemberg.de [134.3.117.69]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 6162848E6; Wed, 3 Feb 2016 10:23:00 +0100 (CET) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none header.from=NLnetLabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1454491380; bh=IdryC8yYE/6F8ULvsrADhTMIx/0E1G3bQEEQpbHGR7Y=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=jXFwfU9ktk6fOW7KmDQhf2x7U3cxWZU+mvulTbq8/xNE0sMIBezeUwpnbJNrb2Z2h Z93CfUFkeB+o1EYwOirLGrNd3yQKEP1VD8kA04/KoD1eaf8eUR4QRYFXJnYOdAQfDY DLpuQC464DUGdkpQoHdgVeGawNrq00injRZyBi8U= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Benno Overeinder In-Reply-To: Date: Wed, 3 Feb 2016 10:22:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <436B616C-99D1-4863-8B16-F4B06C30101F@NLnetLabs.nl> References: <569FC8C7.40303@gmail.com> To: Olafur Gudmundsson X-Mailer: Apple Mail (2.3112) Archived-At: Cc: Shumon Huque , dane@ietf.org Subject: Re: [dane] Meeting plans for Buenos Aires? 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, 03 Feb 2016 09:23:04 -0000 Hi all, > On 21 Jan 2016, at 19:32, Olafur Gudmundsson wrote: >=20 > Everyone,=20 >=20 > The chairs and AD want to see discussion on the future of the working = group.=20 > Please bring to the table what you see the group can/should do.=20 > It is up to the participants to set the direction for the group.=20 > If the group continues we will recharter to reflect the direction.=20 >=20 > To facilitate f2f discussion on this topic, the chairs have requested = a 1 hour slot in BA, BUT PLEASE start the conversation here.=20 >=20 Besides all the potential work Shumon summarised, I do see a serious = interest and actual work starting off to use DANE TLSA & SMIMEA to = realise secure email services. Also the Electronic ID (EID) community = is interested to explore and actually use DANE as a building block for = EID services. With the uptake of DANE in applications, I guess there = will be relevant work to be done in extending DANE to fit new = requirements and use-cases. =E2=80=94 Benno --=20 Benno J. Overeinder NLnet Labs http://www.nlnetlabs.nl/ From nobody Thu Feb 4 08:06:43 2016 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 A419B1B3216 for ; Thu, 4 Feb 2016 08:06:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ngHRhHN_klRd for ; Thu, 4 Feb 2016 08:06:40 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1EDE1B2FAC for ; Thu, 4 Feb 2016 08:06:40 -0800 (PST) Received: from [192.168.1.87] (76-218-10-206.lightspeed.sntcca.sbcglobal.net [76.218.10.206]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id u14G6bPd017753 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 4 Feb 2016 08:06:37 -0800 To: Shumon Huque , Olafur Gudmundsson References: <569FC8C7.40303@gmail.com> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <56B3770C.8020505@dcrocker.net> Date: Thu, 4 Feb 2016 08:06:36 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 04 Feb 2016 08:06:39 -0800 (PST) Archived-At: Cc: "" Subject: Re: [dane] Meeting plans for Buenos Aires? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 16:06:41 -0000 On 1/21/2016 11:18 AM, Shumon Huque wrote: > Lastly, new protocols take a long time to get deployed. Look at IPv6 > - I'm speaking from experience, having first deployed it in > production in 2002. And it's still largely undeployed. Shutting down > the DANE working group while the protocol is still in its infancy, > and while there is still potential work in the queue, sends the wrong > message in my opinion. If there is work to do, then where is the draft charter text describing the problem and nature of work to be done, timeline for completion, indication of who is asking for the work, indication of who will do the work, and indication of who will adopt (use) the work? In terms of overseeing adoption of an IETF specification, that's not the job of the IETF. That's the job of whatever Internet constituency(ies) want to see the adoption. The IETF work is a segment of an industry process. Simplistically, it divides into : 1) formulate the needs, 2) design a solution, 3) deploy the solution. The IETF is (only) step #2. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Feb 4 08:38:57 2016 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 B66A31B32AF for ; Thu, 4 Feb 2016 08:38:55 -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 gGUdWxvrdhF5 for ; Thu, 4 Feb 2016 08:38:54 -0800 (PST) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FAFF1B32B5 for ; Thu, 4 Feb 2016 08:38:54 -0800 (PST) Received: by mail-qg0-x231.google.com with SMTP id b35so45889641qge.0 for ; Thu, 04 Feb 2016 08:38:54 -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=0ys1D+pSo2fZRbrG4aWvipwfsMEsdTlMvuwmejGM+A8=; b=XVGN8Sl/7h4jO8da16XIEBH0gB+CtH2KtLa2wJjfBDdojOqa6bw88uZLwTJQKiWX2N cOq98ReU88/O6cHr48B5c/snSvpj+PwMVUlYDWoDHRKGhjuQU3hOPap6+uo8TZ3KF1/v ROn/sVWAzL9cLRnn9y4iROEN1q5JSE5Z5LRzJKywVj3CP6HOvWpO1ZJMiAJpa7jmV8VE h1CUpYNkhinCKR7viQiVH7hvggWMQ0kU4iqSzJP+O//chUgt0hPTExF4Fuo3wQtgDdIS rKMKpeigmHWb3Zu9zFGYmldBqKJQvdZ/jfLCYP7VchNYYo0PGDkNRkIzMQB8ugYic5yj +o1w== 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=0ys1D+pSo2fZRbrG4aWvipwfsMEsdTlMvuwmejGM+A8=; b=Nuobs8Ub1stzkLtOBrylVsemLSXrbT0f8uvSijZx//5fp4dd6lHx40HALydIa+KXZf e/Pbwd3kpHI1d/TZnu6yFmPZvl15J3bAYJ8/bmsLHEiegqIAe5ZPN253Nb/wg+sfShSJ vgsHbPFiPRZdOPuiivarnp7qr+piPKkzqNOapeyTkyCalb6inLmXjeCpM/dRWq5K5exA QRAsg4Ui1BY+kaM/efvcTbBWVerWYrjZxjVEu+yYLZ0L5BNdRZiBtDg6uYtmtaPVA1+l Y0WsDfWmiqsZaE4N81uEk3qnza0w/5dUhzpNJveLt9Va6YCkYgoFRFmcCs2tNc5uZJe3 UlMA== X-Gm-Message-State: AG10YORpY6/6PwRoDY0fIacyU3g13WOyFyXxOVPU3XVfMZVi6Vh42JhGfuwQBwiYoqwgEbtYCsbz20tKc8wqZg== MIME-Version: 1.0 X-Received: by 10.140.237.74 with SMTP id i71mr10913353qhc.55.1454603933275; Thu, 04 Feb 2016 08:38:53 -0800 (PST) Received: by 10.140.102.9 with HTTP; Thu, 4 Feb 2016 08:38:53 -0800 (PST) In-Reply-To: <56B3770C.8020505@dcrocker.net> References: <569FC8C7.40303@gmail.com> <56B3770C.8020505@dcrocker.net> Date: Thu, 4 Feb 2016 11:38:53 -0500 Message-ID: From: Shumon Huque To: dcrocker@bbiw.net Content-Type: multipart/alternative; boundary=001a1135914cbb5b43052af45ecf Archived-At: Cc: "" Subject: Re: [dane] Meeting plans for Buenos Aires? 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, 04 Feb 2016 16:38:55 -0000 --001a1135914cbb5b43052af45ecf Content-Type: text/plain; charset=UTF-8 On Thu, Feb 4, 2016 at 11:06 AM, Dave Crocker wrote: > > > On 1/21/2016 11:18 AM, Shumon Huque wrote: > >> Lastly, new protocols take a long time to get deployed. Look at IPv6 >> - I'm speaking from experience, having first deployed it in >> production in 2002. And it's still largely undeployed. Shutting down >> the DANE working group while the protocol is still in its infancy, >> and while there is still potential work in the queue, sends the wrong >> message in my opinion. >> > > > If there is work to do, then where is the draft charter text describing > the problem and nature of work to be done, timeline for completion, > indication of who is asking for the work, indication of who will do the > work, and indication of who will adopt (use) the work? > I would be happy to send draft charter text for some of the work items I mentioned in my previous note. We're still in the discussion phase at the moment. I assume charter revision proposals will follow promptly if there is interest. Arguably some of the work like new uses of the existing TLSA server spec by other applications could be done in other IETF working groups. But the first item, augmenting the TLSA spec to support client authentication, feels like a core DANE working group item, so I would like that work at least to be done here. In terms of overseeing adoption of an IETF specification, that's not the > job of the IETF. That's the job of whatever Internet constituency(ies) > want to see the adoption. The IETF work is a segment of an industry > process. Simplistically, it divides into : 1) formulate the needs, 2) > design a solution, 3) deploy the solution. The IETF is (only) step #2. Sure - I wasn't suggesting IETF was the venue for deployment issues and advocacy. We should have a non IETF dane-ops list for that sort of thing. I was merely talking about the impression being sent by the shutdown. And there is a queue of plausible protocol development work. -- Shumon Huque --001a1135914cbb5b43052af45ecf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Feb 4, 2016 at 11:06 AM, Dave Crocker <dhc@dcrocker.net> = wrote:


On 1/21/2016 11:18 AM, Shumon Huque wrote:
Lastly, new protocols take a long time to get deployed. Look at IPv6
- I'm speaking from experience, having first deployed it in
production in 2002. And it's still largely undeployed. Shutting down the DANE working group while the protocol is still in its infancy,
and while there is still potential work in the queue, sends the wrong
message in my opinion.


 If there is work to do, then where is the draft charter text describing the= problem and nature of work to be done, timeline for completion, indication= of who is asking for the work, indication of who will do the work, and ind= ication of who will adopt (use) the work?

I would be happy to send draft charter text for some of the work items I= =C2=A0
mentioned in my previous note. We're still in the disc= ussion phase at the
moment. I assume charter revision proposals w= ill follow promptly if there
is interest.

Arguably some of the work like new uses of the existing TLSA server spec<= /div>
by other applications could be done in other IETF working groups.= But the first=C2=A0
item, augmenting the TLSA spec to support cl= ient authentication, feels like a=C2=A0
core DANE working group i= tem, so I would like that work at least to be done here.

In terms of overseeing adoption of an IETF specification, that's not th= e job of the IETF.=C2=A0 That's the job of whatever Internet constituen= cy(ies) want to see the adoption.=C2=A0 The IETF work is a segment of an in= dustry process.=C2=A0 Simplistically, it divides into :=C2=A0 1) formulate = the needs, 2) design a solution, 3) deploy the solution.=C2=A0 The IETF is = (only) step #2.

Sure - I wasn't suggest= ing IETF was the venue for deployment issues and
advocacy. We sho= uld have a non IETF dane-ops list for that sort of thing. I=C2=A0
was merely talking about the impression being sent by the shutdown. And=C2= =A0
there is a queue of plausible protocol development work.

--=C2=A0
Shumon Huque

--001a1135914cbb5b43052af45ecf-- From nobody Thu Feb 4 08:55:52 2016 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 140101B32DD for ; Thu, 4 Feb 2016 08:55:49 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 CKE3h0fj-tFI for ; Thu, 4 Feb 2016 08:55:46 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0086.outbound.protection.outlook.com [65.55.169.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F2E71B32CF for ; Thu, 4 Feb 2016 08:55:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.onmicrosoft.com; s=selector1-isoc-org; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/yKy7MvEzOXxNjxH2yGReh0+pOjL5t7e9N9lSILuagQ=; b=gwZOC2SpqzqC1IyFAO5Ld1wqiNGpABzGjPN5iVd9ln0jdl9sEq0X/kscgj2BU5rY4VKYg17X9Of7/ycHjT4NLlyAkmBHSyzYgqLkhcQ0f6rrS7LjtjQFaWsYzSSRhrE5h7FhFclcY2BhICYRVh1x4aK2w53kD++z4raB4gDqVxw= Received: from CY1PR0601MB1657.namprd06.prod.outlook.com (10.163.232.19) by CY1PR0601MB1657.namprd06.prod.outlook.com (10.163.232.19) with Microsoft SMTP Server (TLS) id 15.1.396.15; Thu, 4 Feb 2016 16:55:43 +0000 Received: from CY1PR0601MB1657.namprd06.prod.outlook.com ([10.163.232.19]) by CY1PR0601MB1657.namprd06.prod.outlook.com ([10.163.232.19]) with mapi id 15.01.0396.020; Thu, 4 Feb 2016 16:55:43 +0000 From: Dan York To: Dave Crocker Thread-Topic: [dane] Meeting plans for Buenos Aires? Thread-Index: AQHRU5E+IYqeUCUWr0ma1uZZ+hMJA58EhVcAgAApfICAAZ4eAIAADQuAgBXK7QCAAA24AA== Date: Thu, 4 Feb 2016 16:55:43 +0000 Message-ID: References: <569FC8C7.40303@gmail.com> <56B3770C.8020505@dcrocker.net> In-Reply-To: <56B3770C.8020505@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: bbiw.net; dkim=none (message not signed) header.d=none;bbiw.net; dmarc=none action=none header.from=isoc.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [74.69.229.215] x-microsoft-exchange-diagnostics: 1; CY1PR0601MB1657; 5:x3deW7ohwYqB0wwRyBtbfwtTjgwzwztGjVMwwe5DKpzQbPJNPBTzDX3xO3DbDgG13oQ+vpHfM45PpmuwgMjwNnExLfeaE+D/ptxslUhQ/ParnJW5k9BRwV96hXF6QUu9R+Od+i2Tdg+VBHVtAoNFYQ==; 24:NWr++MbqGt9jELW0rVLezvTcOQ8gkQIjsTPzDufr7YFpRpvInOvA4l/IBMXWN0fHSvTE4p6N1yG90DlkjeiEJzUrn+r1H8wp0t+BdLEN/nA= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0601MB1657; x-ms-office365-filtering-correlation-id: 29b431d7-2ef6-41c3-3e22-08d32d840526 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:CY1PR0601MB1657; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0601MB1657; x-forefront-prvs: 084285FC5C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(24454002)(377454003)(479174004)(5001960100002)(6116002)(92566002)(83716003)(2906002)(102836003)(5008740100001)(10400500002)(99286002)(93886004)(76176999)(4326007)(189998001)(110136002)(86362001)(15975445007)(3846002)(87936001)(1220700001)(106116001)(1096002)(2900100001)(19580395003)(19580405001)(3660700001)(50986999)(5004730100002)(15395725005)(82746002)(19617315012)(3280700002)(54356999)(16236675004)(66066001)(36756003)(2950100001)(77096005)(33656002)(122556002)(5002640100001)(11100500001)(40100003)(586003)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0601MB1657; H:CY1PR0601MB1657.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_B01E493727F14624BA0B8C6069894CF0isocorg_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Feb 2016 16:55:43.0478 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0601MB1657 Archived-At: Cc: IETF DANE Mailinglist Subject: Re: [dane] Meeting plans for Buenos Aires? 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, 04 Feb 2016 16:55:49 -0000 --_000_B01E493727F14624BA0B8C6069894CF0isocorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On 1/21/2016 11:18 AM, Shumon Huque wrote: Lastly, new protocols take a long time to get deployed. Look at IPv6 - I'm speaking from experience, having first deployed it in production in 2002. And it's still largely undeployed. Shutting down the DANE working group while the protocol is still in its infancy, and while there is still potential work in the queue, sends the wrong message in my opinion. First... +100 to what Shumon said! We are at the stage of DANE deployment = where, while the protocol may be well-developed, the deployment is only now= beginning... and I think it would send a wrong message to kill of the grou= p now. But to answer Dave... On Feb 4, 2016, at 11:06 AM, Dave Crocker > wrote: If there is work to do, then where is the draft charter text describing the= problem and nature of work to be done, timeline for completion, indication= of who is asking for the work, indication of who will do the work, and ind= ication of who will adopt (use) the work? Good point. Perhaps the action here is to update the DANE WG Charter with = the deliverables such as the ones Shumon indicates. All of the milestones= on the existing charter ( https://datatracker.ietf.org/wg/dane/charter/ ) = have been completed and so by the process it would make sense to declare vi= ctory and shut the group down. In terms of overseeing adoption of an IETF specification, that's not the jo= b of the IETF. That's the job of whatever Internet constituency(ies) want = to see the adoption. The IETF work is a segment of an industry process. S= implistically, it divides into : 1) formulate the needs, 2) design a solut= ion, 3) deploy the solution. The IETF is (only) step #2. Yes, BUT... the reality is that during the deployment (step 3) of the solu= tion there are very frequently issues discovered that were not anticipated = in the original development of the protocol. Changes that need to be made = to the protocol are identified. Additional uses cases are often found. Wa= ys to extend a protocol are discovered. New guidance is developed. All of = those are pieces of information that can be fed back into the IETF process = to wind up with a better solution (step #2). We've in fact *already* seen this within DANE with some of the work that Vi= ktor and Wes have fed back into the group based on their work with DANE in = SMTP. The question is - if the DANE working group shuts down, where does that fee= dback go so that DANE could be improved? Right now, I'm seeing a good bit of interest in DANE out in the wider indus= try. I'd like to make the process for incorporating that feedback during d= eployment as efficient and fast as possible. To me, keeping the DANE WG ar= ound for a bit more would be one way to make sure that the feedback loop is= out there. Alternatively, for IPv6, there is the V6OPS WG where these kind of operatio= ns/deployment issues can be brought. For "DNS" in general there is DNSOP. = Could DANE issues be brought there? I guess so if the charter were update= d... but that then throws even more into an already packed WG. Or... we could close the DANE WG and wait around until there were enough is= sues to merit opening up a new DANE-related WG (similar to how EPPEXT was e= ventually formed after PROVREG shut down). I agree that "waiting for feedback from deployment" is NOT a reason to keep= a WG on the books ALONE, but given points by Shumon and others I *do* thin= k there is enough DANE-related work to keep the WG going... which then also= can be that potential feedback mechanism. My 2 cents, Dan -- Dan York Senior Content Strategist, Internet Society york@isoc.org +1-802-735-1624 Jabber: york@jabber.isoc.org Skype: danyork http://twitter.com/danyork http://www.internetsociety.org/ --_000_B01E493727F14624BA0B8C6069894CF0isocorg_ Content-Type: text/html; charset="us-ascii" Content-ID: <6098E5A40179BA439C35595085095B00@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable

On 1/21/2016 11:18 AM, Shumon Huque wrote:
Lastly, new protocols take a long time= to get deployed. Look at IPv6
- I'm speaking from experience, having first deployed it in
production in 2002. And it's still largely undeployed. Shutting down
the DANE working group while the protocol is still in its infancy,
and while there is still potential work in the queue, sends the wrong
message in my opinion.

First... +100 to what Shumon said!  We are at the stage of DANE de= ployment where, while the protocol may be well-developed, the deployment is= only now beginning... and I think it would send a wrong message to kill of= the group now.

But to answer Dave...

On Feb 4, 2016, at 11:06 AM, Dave Crocker <dhc@dcrocker.net> wrote:

If there is work to do, then where is the draft charter tex= t describing the problem and nature of work to be done, timeline for comple= tion, indication of who is asking for the work, indication of who will do t= he work, and indication of who will adopt (use) the work?

Good point.  Perhaps the action here is to update the DANE WG Charter = with the deliverables such as the ones Shumon indicates.   All of the = milestones on the existing charter ( https://datatracker.ietf.org/wg/dane/ch= arter/ ) have been completed and so by the process it would make sense to declare v= ictory and shut the group down.

In terms of overseeing adoption of an IETF specification, t= hat's not the job of the IETF.  That's the job of whatever Internet co= nstituency(ies) want to see the adoption.  The IETF work is a segment = of an industry process.  Simplistically, it divides into :  1) formulate the needs, 2) design a solution, 3) depl= oy the solution.  The IETF is (only) step #2.

Yes, BUT...  the reality is that during the deployment (step 3) of the= solution there are very frequently issues discovered that were not anticip= ated in the original development of the protocol.  Changes that need t= o be made to the protocol are identified.  Additional uses cases are often found.  Ways to extend a protoc= ol are discovered. New guidance is developed.  All of those are pieces= of information that can be fed back into the IETF process to wind up with = a better solution (step #2).

We've in fact *already* seen this within DANE with some of = the work that Viktor and Wes have fed back into the group based on their wo= rk with DANE in SMTP.

The question is - if the DANE working group shuts down, whe= re does that feedback go so that DANE could be improved?

Right now, I'm seeing a good bit of interest in DANE out in= the wider industry.  I'd like to make the process for incorporating t= hat feedback during deployment as efficient and fast as possible.  To = me, keeping the DANE WG around for a bit more would be one way to make sure that the feedback loop is out there.

Alternatively, for IPv6, there is the V6OPS WG where these = kind of operations/deployment issues can be brought.  For "DNS&qu= ot; in general there is DNSOP.  Could DANE issues be brought there? &n= bsp;I guess so if the charter were updated... but that then throws even more into an already packed WG.

Or... we could close the DANE WG and wait around until ther= e were enough issues to merit opening up a new DANE-related WG (similar to = how EPPEXT was eventually formed after PROVREG shut down).

I agree that "waiting for feedback from deployment&quo= t; is NOT a reason to keep a WG on the books ALONE, but given points by Shu= mon and others I *do* think there is enough DANE-related work to keep the W= G going... which then also can be that potential feedback mechanism.

My 2 cents,
Dan
--
Dan York
Senior Content Strategist, Int= ernet Society
york@isoc.org   +1-802-735-1624
Jabber: york@jabber.isoc.org 
Skype: danyork   http://twitter.com/danyork

http://www.internets= ociety.org/




--_000_B01E493727F14624BA0B8C6069894CF0isocorg_-- From nobody Thu Feb 4 15:07:06 2016 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 400691B33A1 for ; Thu, 4 Feb 2016 15:07:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.664 X-Spam-Level: * X-Spam-Status: No, score=1.664 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, KHOP_DYNAMIC=0.001, 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 0IxzhGD8UNp8 for ; Thu, 4 Feb 2016 15:07:04 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17D301B33A0 for ; Thu, 4 Feb 2016 15:07:03 -0800 (PST) Received: (qmail 45943 invoked from network); 4 Feb 2016 23:07:02 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 4 Feb 2016 23:07:02 -0000 Date: 4 Feb 2016 23:06:40 -0000 Message-ID: <20160204230640.69198.qmail@ary.lan> From: "John Levine" To: dane@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dane] Meeting plans for Buenos Aires? 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, 04 Feb 2016 23:07:05 -0000 >First... +100 to what Shumon said! We are at the stage of DANE deployment where, while the protocol may be >well-developed, the deployment is only now beginning... and I think it would send a wrong message to kill >of the group now. I'm sorry, but this shows a complete misunderstanding of what a working group is and how the IETF works. WGs exist to develop standards, following their charters. The whole reason that WGs have charters is so they don't just drift on forever. If, as it appears, DANE has finished the work in its charter, it's time to shut it down. In the past, some WG's mailing lists have stayed open for discussions of topics related to the former WG's work. It looks line DANE could be a candidate for that. R's, John From nobody Thu Feb 4 16:43:22 2016 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 468311B2AE9 for ; Thu, 4 Feb 2016 16:43:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.503 X-Spam-Level: X-Spam-Status: No, score=-0.503 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.001, 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 XIlasq_gdekW for ; Thu, 4 Feb 2016 16:43:19 -0800 (PST) Received: from insensate.co.uk (norman.insensate.co.uk [81.174.156.22]) by ietfa.amsl.com (Postfix) with ESMTP id 5ABC61B2AED for ; Thu, 4 Feb 2016 16:43:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id A4D7C658755; Fri, 5 Feb 2016 00:43:18 +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 KVWDS9Bl52ZL; Fri, 5 Feb 2016 00:43:18 +0000 (GMT) Received: from sun.insensate.co.uk (norman.insensate.co.uk [81.174.156.22]) by insensate.co.uk (Postfix) with ESMTPSA id 13E0965874A; Fri, 5 Feb 2016 00:43:18 +0000 (GMT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Lawrence Conroy In-Reply-To: <20160204230640.69198.qmail@ary.lan> Date: Fri, 5 Feb 2016 00:43:17 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160204230640.69198.qmail@ary.lan> To: John Levine X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Meeting plans for Buenos Aires? 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, 05 Feb 2016 00:43:21 -0000 Hi folks, so ... ogud + friendly AD: There seems some serious reluctance to re-charter DANE to do more work = (for reasons I'd love to see spelt out). The question's been asked, but I haven't seen a detailed answer. Shumon/Bello/Melinda/...: Given that reluctance, if you want to do some work, develop a charter = though the BOF process (same as keyassure/DANE did), convince the ADs, and get a = ->new<- WG for this new work. [maybe called SWEDE?] John: As for the use of keeping the ML open after the WG has died: remind me = again how successful that has been in the IETF. all the best, Lawrence On 4 Feb 2016, at 23:06, John Levine wrote: >> First... +100 to what Shumon said! We are at the stage of DANE = deployment where, while the protocol may be >> well-developed, the deployment is only now beginning... and I think = it would send a wrong message to kill >> of the group now. >=20 > I'm sorry, but this shows a complete misunderstanding of what a > working group is and how the IETF works. WGs exist to develop > standards, following their charters. The whole reason that WGs have > charters is so they don't just drift on forever. >=20 > If, as it appears, DANE has finished the work in its charter, it's > time to shut it down. In the past, some WG's mailing lists have > stayed open for discussions of topics related to the former WG's work. > It looks line DANE could be a candidate for that. >=20 > R's, > John >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From nobody Thu Feb 4 17:14:54 2016 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 07D9D1B2BCC for ; Thu, 4 Feb 2016 17:14:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.136 X-Spam-Level: X-Spam-Status: No, score=-1.136 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, KHOP_DYNAMIC=0.001, 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 TFCPg7gjnLBa for ; Thu, 4 Feb 2016 17:14:52 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE97A1B2BCB for ; Thu, 4 Feb 2016 17:14:51 -0800 (PST) Received: (qmail 60570 invoked from network); 5 Feb 2016 01:14:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=ec99.56b3f78a.k1602; bh=wvNHxKNBE+zIyrBTm+IO8zXWPg945Iy3xMZ/3RNfEUA=; b=myHi2qLMvnRJaCCEUsYDtSubj+RAwI+wjGeDwV8v/1Kd30W6Au3/oqCGxAuupWT2OcJ2DBd07uxO89/mGQbehM9tooVG+tL3S+R70q/RqCCVAPMgVa1v43KkXyMCrFdC+/z1d1ZlWW/oSy23Q5HlR433NsX0QPK6CakNHDvOAtOydk+1E79u7b6gy1490TZ/mjgdKkq3IpO+zWyO05T9xi8K/OoUyhyaS1p95dx35Sk98gunELY7MM0RxVYIjbDX DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=ec99.56b3f78a.k1602; bh=wvNHxKNBE+zIyrBTm+IO8zXWPg945Iy3xMZ/3RNfEUA=; b=NE64XZjeTP2NMLlwAeWtxPyVNkeV+82H61uRnwtzAUF6sPciuKyZy16RyNqSG6WcA82oEAHJEEo1PZ/baowA/fnlw2QwLdHeJp/vi2KaFiDkNXrKsaZfhtSPXiWCyiUCt8o0LFFzGYu2mrU9LyCe+Pnf7VkNcdvIwkK+SfVq4bbrjnfDYWePurqR3cRFMC11Xkztxhxxj8H9tUYmvfDsvcEl3DJRyyrpK/mYAJF7OUh/G8N5tgxP0u+DE+yW2WZR Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 05 Feb 2016 01:14:50 -0000 Date: 4 Feb 2016 20:14:49 -0500 Message-ID: From: "John R Levine" To: "Lawrence Conroy" In-Reply-To: References: <20160204230640.69198.qmail@ary.lan> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Cc: dane@ietf.org Subject: Re: [dane] lists and Meeting plans for Buenos Aires? 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, 05 Feb 2016 01:14:53 -0000 > As for the use of keeping the ML open after the WG has died: remind me again how successful that has been in the IETF. It varies. Of the ones I can think of, the ietf-smtp list is useful as a place to kick around proposed SMTP changes, such as a current discussion about whether a compressed data extension would be a good idea and if so how to do it. There are certainly plenty that either have no traffic, or the messages aren't interesting. It doesn't make any difference to me whether the dane list stays open, but if there is more left to say about publishing stuff in the DNS secured by DNSSEC, it'd be as good a place as any. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Thu Feb 4 17:28:04 2016 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 A5FE81B2BEB for ; Thu, 4 Feb 2016 17:28:03 -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, 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 2tgVkFwIt_VR for ; Thu, 4 Feb 2016 17:28:01 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A277E1B2B9C for ; Thu, 4 Feb 2016 17:28:01 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id AA4AA284CDB; Fri, 5 Feb 2016 01:28:00 +0000 (UTC) Date: Fri, 5 Feb 2016 01:28:00 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20160205012800.GR19242@mournblade.imrryr.org> References: <20160204230640.69198.qmail@ary.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [dane] lists and Meeting plans for Buenos Aires? 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, 05 Feb 2016 01:28:03 -0000 On Thu, Feb 04, 2016 at 08:14:49PM -0500, John R Levine wrote: > >As for the use of keeping the ML open after the WG has died: remind me again how successful that has been in the IETF. > > It varies. Of the ones I can think of, the ietf-smtp list is useful as a > place to kick around proposed SMTP changes, such as a current discussion > about whether a compressed data extension would be a good idea and if so how > to do it. There are certainly plenty that either have no traffic, or the > messages aren't interesting. > > It doesn't make any difference to me whether the dane list stays open, but > if there is more left to say about publishing stuff in the DNS secured by > DNSSEC, it'd be as good a place as any. We still have client DANE auth on the charter and Shumon's draft (I'm taking a back seat this time) is in early stages of development. And the TLS working group might soon be looking at the DANE stapling extension, it may useful to have some veterans here to provide feedback to the TLS WG. So some work still remains, even though things are quite slow just now. At this time most of my energy is on the deployment side, in particular at present on getting OpenSSL 1.1.0 out the door. It seems that Claus Assmann has started looking at the DANE support in 1.1.0, if anyone else has started testing it and has feedback, feel free to share. The alpha3 release scheduled for next week might be a good time to get your feet wet. Note, OpenSSL 1.1.0 provides peer chain verification via application provided TLSA records, obtaining and (DNSSEC) validating those TLSA records is up to the application. There are opportunities here for more "feature-complete" libraries that provide the "missing" glue and provide a more integrated interface that does that does the TLSA lookup with either in-application DNSSEC validation or AD-bit trust from a local resolver, and then uses OpenSSL to do the DANE TLS bits. -- Viktor. From nobody Thu Feb 4 17:37:29 2016 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 8137F1B2C3A for ; Thu, 4 Feb 2016 17:37:27 -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 uzMnlkk3p22K for ; Thu, 4 Feb 2016 17:37:26 -0800 (PST) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 154691B2C37 for ; Thu, 4 Feb 2016 17:37:26 -0800 (PST) Received: by mail-qg0-x229.google.com with SMTP id b35so57167769qge.0 for ; Thu, 04 Feb 2016 17:37:26 -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=kdsMhIgCoONmr9jtNdj5T7gUPXgqU9YemVi9UImQ5uc=; b=dI5kDi7VFFjW4QORBfl8GGLFWwZvJedDeODHUyO8Snbgiz7hFExXpQt5t077Xbpwj8 lqlhXzwYHbNxaeLfXiWDbBAIIlfn5oafaumKhEY1VOse39NdqaICSLVZIIXvmTixly5M qoBDKVrqvZTlc7LLm9M06WbA+EVYTefEYbdKfQtBXU6jfzZMrTCJ9q8Iovfc1Ebj5EAn X5POA9unnRmpTZqvyodkl4TNFjwMtSBebJDCLMuez/jdBAE4g3YuGGmkl9otcAGvqdqP WOxlfS6qvBbIJX3wyapo+wZf/YS3sRoJ1stzcjsoLuIqAsKkRshIRu2JPYaYfBB6jeBM KDWg== 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=kdsMhIgCoONmr9jtNdj5T7gUPXgqU9YemVi9UImQ5uc=; b=jwqAonZXQb8lO2hJq/BJLeaIQWEY5j28+BeuiJpyZ6njwDryDjgh80E9vDi2NJJ5c9 ZbdOc5Yr4R3Fi2qGTRtvLxvctallSoIO7W3MNJz1JCFxuYsG2n2qg2UwXAdeERvHgdNC msyGGDSXG+15+H8fyPYwbDfzj76mG8hwaKUzQYsN7RXWtEW9Ji8eVsXXsIirK94QEst6 09k+FfwF2rQTFxNJUBlyAXqgVYb1HKpidpVzSDTRQm+vo8vAI9Dz3giF3dHCJU7x31Ca uZCpDZbqX/0xZLFBw14rCORqGJMAZL+A1Fsbl1kEeia5y2NjrBYnDXWaREfqBHAAJ6gZ pAxw== X-Gm-Message-State: AG10YOToGbfDwft6Vf83pu93Reo9Gz79FO5j139ZsGV5/kktQLHeWfeoJqZKsPL82jHlI4T9AZlsJzRKuX1Z/Q== MIME-Version: 1.0 X-Received: by 10.140.175.7 with SMTP id v7mr14080034qhv.103.1454636245242; Thu, 04 Feb 2016 17:37:25 -0800 (PST) Received: by 10.140.102.9 with HTTP; Thu, 4 Feb 2016 17:37:25 -0800 (PST) In-Reply-To: References: <20160204230640.69198.qmail@ary.lan> Date: Thu, 4 Feb 2016 20:37:25 -0500 Message-ID: From: Shumon Huque To: Lawrence Conroy Content-Type: multipart/alternative; boundary=001a113a29eaacda5b052afbe43b Archived-At: Cc: "" Subject: Re: [dane] Meeting plans for Buenos Aires? 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, 05 Feb 2016 01:37:27 -0000 --001a113a29eaacda5b052afbe43b Content-Type: text/plain; charset=UTF-8 On Thu, Feb 4, 2016 at 7:43 PM, Lawrence Conroy wrote: > Hi folks, > so ... > ogud + friendly AD: > There seems some serious reluctance to re-charter DANE to do more work > (for reasons I'd love to see spelt out). > The question's been asked, but I haven't seen a detailed answer. > > Shumon/Bello/Melinda/...: > Given that reluctance, if you want to do some work, develop a charter > though the BOF > process (same as keyassure/DANE did), convince the ADs, and get a ->new<- > WG for this new work. > [maybe called SWEDE?] > Thanks for the suggestion! I'd prefer to try to recharter the current group with any new work items first, before this more drastic option. But glancing at the current charter just now, it might already cover some of the work that I outlined earlier. -- Shumon Huque. --001a113a29eaacda5b052afbe43b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Feb 4, 2016 at 7:43 PM, Lawrence Conroy <lconroy@insensate.co.= uk> wrote:
Hi folks,
=C2=A0so ...
ogud + friendly AD:
There seems some serious reluctance to re-charter DANE to do more work (for= reasons I'd love to see spelt out).
The question's been asked, but I haven't seen a detailed answer.
Shumon/Bello/Melinda/...:
Given that reluctance, if you want to do some work, develop a charter thoug= h the BOF
process (same as keyassure/DANE did), convince the ADs, and get a ->new&= lt;- WG for this new work.
[maybe called SWEDE?]

Thanks for the su= ggestion! I'd prefer to try to recharter the current group
wi= th any new work items first, before this more drastic option. But glancing<= /div>
at the current charter just now, it might already cover some of t= he work
that I outlined earlier.

--=C2= =A0
Shumon Huque.

--001a113a29eaacda5b052afbe43b-- From nobody Thu Feb 4 17:48:48 2016 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 006811B2C73 for ; Thu, 4 Feb 2016 17:48:47 -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 gS-bYprGtDW9 for ; Thu, 4 Feb 2016 17:48:45 -0800 (PST) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5A4E1B2C71 for ; Thu, 4 Feb 2016 17:48:44 -0800 (PST) Received: by mail-qg0-x22d.google.com with SMTP id u30so57488072qge.1 for ; Thu, 04 Feb 2016 17:48:44 -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 :content-type; bh=zxanhj7B6mH3fj5BZQpGqFQzzh90OyyF61FoO9vGqU8=; b=JxnDEJNdcdUmUjBmFtZCuoYaQ74zjmdtYzc1n67z7bsY2Ttl+BL+4zXxWuWK1IwFH5 qzHX/R0aSyHxNnOgn4hI0Hfbz/nkuNWZvHbcH1U6FK3Y837Qdbi9RQjiUDFFK4RF73nF J4lnHMl7+TcZ50AJiEq4isED4os0QGOEBeFl/qUCWK6GRRrNZZIVe9iq/AUvOgzPjkPR RtlGOH6AHmYlj/ABRGQ4Chms+Pim4G1iKx+4Ul7VF4V9s3+ch52otOdowUfUTUULOrk4 PtDChoJQmP1L6aUlmUQWH3X6eRoRRiTH+jDN70Nn8Q4kl0m1j80T88YQzEysrvEZ7iKV GF9w== 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:content-type; bh=zxanhj7B6mH3fj5BZQpGqFQzzh90OyyF61FoO9vGqU8=; b=gVvm/mQ4+POcRc89dF7H4TpEG72N1DCIqAUYTh47c6jUpzezOiePd9A5quoTKU91e5 Di2IiKpu7KzEiCpXBThocs8UUUF4RmDpT+iSj14A0ZEMTBbcbfK4MJQI4hxfxUiY0Z2s pFgQIyCquB143z9n0A5cC499GbKlx4PUNStD6VfBpxmhXvOcIJOGgZg3mAShcINT0Ulw R+UVN8wRFha/FcE1JTeM8M0Fx1dWxRW1/XGXfIaIeHttqNtHbyn7CLXM9+Ham+ul7N6p J5RGuy2SgPGQUNLy2JAe33daXwz33bK8yhfxpRd77jEhx56jAyA31l3ed2z/gtt5kdhz CgGQ== X-Gm-Message-State: AG10YOQV5XrajTYzBCARKse6GS3tiIwQ9d4MtihgO/4X7TzPZkuEq8yIAaUPhgARlHluEhXTV1XQmcb0Cn92sw== MIME-Version: 1.0 X-Received: by 10.140.168.85 with SMTP id o82mr14133760qho.10.1454636924022; Thu, 04 Feb 2016 17:48:44 -0800 (PST) Received: by 10.140.102.9 with HTTP; Thu, 4 Feb 2016 17:48:43 -0800 (PST) In-Reply-To: <20160205012800.GR19242@mournblade.imrryr.org> References: <20160204230640.69198.qmail@ary.lan> <20160205012800.GR19242@mournblade.imrryr.org> Date: Thu, 4 Feb 2016 20:48:43 -0500 Message-ID: From: Shumon Huque To: "" Content-Type: multipart/alternative; boundary=001a113ab5d222384c052afc0dc5 Archived-At: Subject: Re: [dane] lists and Meeting plans for Buenos Aires? 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, 05 Feb 2016 01:48:47 -0000 --001a113ab5d222384c052afc0dc5 Content-Type: text/plain; charset=UTF-8 On Thu, Feb 4, 2016 at 8:28 PM, Viktor Dukhovni wrote: > On Thu, Feb 04, 2016 at 08:14:49PM -0500, John R Levine wrote: > > > >As for the use of keeping the ML open after the WG has died: remind me > again how successful that has been in the IETF. > > > > It varies. Of the ones I can think of, the ietf-smtp list is useful as a > > place to kick around proposed SMTP changes, such as a current discussion > > about whether a compressed data extension would be a good idea and if so > how > > to do it. There are certainly plenty that either have no traffic, or the > > messages aren't interesting. > > > > It doesn't make any difference to me whether the dane list stays open, > but > > if there is more left to say about publishing stuff in the DNS secured by > > DNSSEC, it'd be as good a place as any. > > We still have client DANE auth on the charter and Shumon's draft > (I'm taking a back seat this time) is in early stages of development. > And the TLS working group might soon be looking at the DANE stapling > extension, it may useful to have some veterans here to provide > feedback to the TLS WG. > Hmm, I hadn't noticed until you mentioned it, that client DANE records are already in the current charter, so this piece is already covered. I hope to request a call for working group adoption of our draft on this topic in the near future. > So some work still remains, even though things are quite slow just > now. > > At this time most of my energy is on the deployment side, in > particular at present on getting OpenSSL 1.1.0 out the door. > > It seems that Claus Assmann has started looking at the DANE support > in 1.1.0, if anyone else has started testing it and has feedback, > feel free to share. The alpha3 release scheduled for next week > might be a good time to get your feet wet. > > Note, OpenSSL 1.1.0 provides peer chain verification via application > provided TLSA records, obtaining and (DNSSEC) validating those TLSA > records is up to the application. There are opportunities here > for more "feature-complete" libraries that provide the "missing" > glue and provide a more integrated interface that does that does > the TLSA lookup with either in-application DNSSEC validation or > AD-bit trust from a local resolver, and then uses OpenSSL to do > the DANE TLS bits. > I've written some code using the new OpenSSL 1.1.0 DANE APIs that already does this (both the application validation version using getdns and one that inspects AD bit from a trusted resolver using ldns). I'll send you a separate note off list about this with some feedback. Also the getdns library will likely develop an integrated DANE TLS connection function that will do this. -- Shumon Huque --001a113ab5d222384c052afc0dc5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Feb 4, 2016 at 8:28 PM, Viktor Dukhovni <ietf-dane@dukhovni.org= > wrote:
O= n Thu, Feb 04, 2016 at 08:14:49PM -0500, John R Levine wrote:

> >As for the use of keeping the ML open after the WG has died: remin= d me again how successful that has been in the IETF.
>
> It varies.=C2=A0 Of the ones I can think of, the ietf-smtp list is use= ful as a
> place to kick around proposed SMTP changes, such as a current discussi= on
> about whether a compressed data extension would be a good idea and if = so how
> to do it.=C2=A0 There are certainly plenty that either have no traffic= , or the
> messages aren't interesting.
>
> It doesn't make any difference to me whether the dane list stays o= pen, but
> if there is more left to say about publishing stuff in the DNS secured= by
> DNSSEC, it'd be as good a place as any.

We still have client DANE auth on the charter and Shumon's draft=
(I'm taking a back seat this time) is in early stages of development. And the TLS working group might soon be looking at the DANE stapling
extension, it may useful to have some veterans here to provide
feedback to the TLS WG.

Hmm, I hadn'= ;t noticed until you mentioned it, that client DANE records
are a= lready in the current charter, so this piece is already covered. I hope
to request a call for working group adoption of our draft on this to= pic in=C2=A0
the near future.
=C2=A0
So some work still remains, even though things are quite slow just
now.

At this time most of my energy is on the deployment side, in
particular at present on getting OpenSSL 1.1.0 out the door.

It seems that Claus Assmann has started looking at the DANE support
in 1.1.0, if anyone else has started testing it and has feedback,
feel free to share.=C2=A0 The alpha3 release scheduled for next week
might be a good time to get your feet wet.

Note, OpenSSL 1.1.0 provides peer chain verification via application
provided TLSA records, obtaining and (DNSSEC) validating those TLSA
records is up to the application.=C2=A0 There are opportunities here
for more "feature-complete" libraries that provide the "miss= ing"
glue and provide a more integrated interface that does that does
the TLSA lookup with either in-application DNSSEC validation or
AD-bit trust from a local resolver, and then uses OpenSSL to do
the DANE TLS bits.

I've written som= e code using the new OpenSSL 1.1.0 DANE APIs
that already does th= is (both the application validation version using
getdns and one = that inspects AD bit from a trusted resolver using ldns).=C2=A0
I= 'll send you a separate note off list about this with some feedback.

Also the getdns library will likely develop an integ= rated DANE TLS=C2=A0
connection function that will do this.
=

--=C2=A0
Shumon Huque

--001a113ab5d222384c052afc0dc5-- From nobody Thu Feb 4 17:53:15 2016 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 99F4B1B2C79 for ; Thu, 4 Feb 2016 17:53:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.136 X-Spam-Level: X-Spam-Status: No, score=-1.136 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, KHOP_DYNAMIC=0.001, 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 eP0vAvtQ3YhV for ; Thu, 4 Feb 2016 17:53:12 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 823A41B2C7C for ; Thu, 4 Feb 2016 17:53:12 -0800 (PST) Received: (qmail 64992 invoked from network); 5 Feb 2016 01:53:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=fdde.56b40087.k1602; bh=nv6TVwtub1zgYbLTdgQJoj5xegMd3KJojmtA9F38R3M=; b=EF7zfnkVIyJMf2GVQ2i4fa/lM7gaqZsxKs8/PvTycotqlNwnhDrEfJLUoceWKzN1wXEdbbnQgxkCIVJYsyXwM4zzPGqKz2Tg6pUqhBQHT46YRNFWF6fbLecPacMTgB7YH8Hk+eA1m7OmFcOMZLuYjDwiSpRY2vr6ml6PjnV+bg68lvFT+fVLI+BLygIGi7l5S2twhyRwjAg/dGXUgJFvxbUMB28Pv8aYb5Jy6cQ5Diw2VsxUuLpmGN/r4TYkNymn DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=fdde.56b40087.k1602; bh=nv6TVwtub1zgYbLTdgQJoj5xegMd3KJojmtA9F38R3M=; b=FJZJckYkP8/TrM5AIrlzL+eLhasdaYDOrDG2lj0QC2MgakODk+a0dIzzg1eooViP+6vbHExcf5PlWiPKYGte+82Yzy7IEDQo5nPnTUS4Zs3xx+/jydO/gDkWKY0+VZhK50pepBKnyAsqvtmP/vJ72lM+mQuPkCWys7lBkNnoa4cLh6O0e1A0TrLK/cZXJBT8j1T352tIjwXVhCzVcEW5DUUHa6fHdKZT4VmcO0SjuIhp4dVyKGEDGwKteuLAlDpT Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 05 Feb 2016 01:53:11 -0000 Date: 4 Feb 2016 20:53:10 -0500 Message-ID: From: "John R Levine" To: "Shumon Huque" In-Reply-To: References: <20160204230640.69198.qmail@ary.lan> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "" Subject: Re: [dane] Meeting plans for Buenos Aires? 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, 05 Feb 2016 01:53:13 -0000 > Thanks for the suggestion! I'd prefer to try to recharter the current group > with any new work items first, before this more drastic option. But glancing > at the current charter just now, it might already cover some of the work > that I outlined earlier. If you have a clear, well focused list of things to do, you'll probably find that setting up a new WG is easier than rechartering. It certainly comes with less baggage. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Thu Feb 4 18:26:05 2016 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 EE6FC1B2D10 for ; Thu, 4 Feb 2016 18:26:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 i__i66iL7NQ9 for ; Thu, 4 Feb 2016 18:26:03 -0800 (PST) Received: from insensate.co.uk (norman.insensate.co.uk [81.174.156.22]) by ietfa.amsl.com (Postfix) with ESMTP id 4BBC81B2D0E for ; Thu, 4 Feb 2016 18:26:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 8845E658A8E for ; Fri, 5 Feb 2016 02:26:02 +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 z4dZ0c60WqxZ for ; Fri, 5 Feb 2016 02:26:02 +0000 (GMT) Received: from sun.insensate.co.uk (norman.insensate.co.uk [81.174.156.22]) by insensate.co.uk (Postfix) with ESMTPSA id 04038658A85 for ; Fri, 5 Feb 2016 02:26:02 +0000 (GMT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Lawrence Conroy In-Reply-To: Date: Fri, 5 Feb 2016 02:26:00 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <138B4D21-80D7-4FD1-BDAD-FDCBBBEF1020@insensate.co.uk> References: <20160204230640.69198.qmail@ary.lan> To: "" X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [dane] Meeting plans for Buenos Aires? 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, 05 Feb 2016 02:26:05 -0000 Hi again, really -- does re-chartering have a higher bar now? I would have thought, if some items are already in/alluded to in the = existing charter, then extending it for focussed extensions that are = close-coupled to the current text could be a quicker approach. That's = certainly been my experience in the past. Either way, a new charter (or extension to the current one) requires = enthusiasts to spell out exactly what the tasks will be, when they are = needed/aim to be completed, and get people willing to do the work. That = means charter text. Your esteemed co-chair did ask for this, so over to you folks -- if you = want it, make it happen. (I'm sure there's an apposite Mel Brooks quote here). all the best, Lawrence On 5 Feb 2016, at 01:53, John R Levine wrote: >> Thanks for the suggestion! I'd prefer to try to recharter the current = group >> with any new work items first, before this more drastic option. But = glancing >> at the current charter just now, it might already cover some of the = work >> that I outlined earlier. >=20 > If you have a clear, well focused list of things to do, you'll = probably find that setting up a new WG is easier than rechartering. It = certainly comes with less baggage. >=20 > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. From nobody Fri Feb 5 02:03:08 2016 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 DA2841B2BF7 for ; Fri, 5 Feb 2016 02:03:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.247 X-Spam-Level: ** X-Spam-Status: No, score=2.247 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_BRBL_LASTEXT=1.449, RP_MATCHES_RCVD=-0.001, 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 xhCwpILEy2YK for ; Fri, 5 Feb 2016 02:03:05 -0800 (PST) Received: from new.toad.com (new.toad.com [209.237.225.253]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (112/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 342071A21A0 for ; Fri, 5 Feb 2016 02:03:04 -0800 (PST) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id u15A2q0P017177; Fri, 5 Feb 2016 02:02:53 -0800 Message-Id: <201602051002.u15A2q0P017177@new.toad.com> To: dcrocker@bbiw.net In-reply-to: <56B3770C.8020505@dcrocker.net> References: <569FC8C7.40303@gmail.com> <56B3770C.8020505@dcrocker.net> Comments: In-reply-to Dave Crocker message dated "Thu, 04 Feb 2016 08:06:36 -0800." Date: Fri, 05 Feb 2016 02:02:52 -0800 From: John Gilmore Archived-At: Cc: "" Subject: [dane] Why shut down the DANE group? 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, 05 Feb 2016 10:03:06 -0000 > design a solution, 3) deploy the solution. The IETF is (only) step #2. Yeah, let's not have the designers talking with the deployers. That can lead to interoperability and harmony, which IETF is dead set against. I suggest that any dane member who doesn't want to continue, should quit the group and resign from the mailing list. Then from your point of view, the group will already be "shut down". Yet those who wish to continue will still be able to continue. >From whence is the pressure coming to "shut down the group entirely"? Perhaps NSA is concerned that DANE might actually provide a usable public key infrastructure for mass authentication and encryption? Better shut that puppy right down, then, before it's too late. John (irony trigger warning) From nobody Fri Feb 5 02:50:05 2016 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 86E341A1AB9 for ; Fri, 5 Feb 2016 02:50:03 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 dfK0F6rRf4QT for ; Fri, 5 Feb 2016 02:50:01 -0800 (PST) Received: from smtp68.iad3a.emailsrvr.com (smtp68.iad3a.emailsrvr.com [173.203.187.68]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 815611A1AB3 for ; Fri, 5 Feb 2016 02:50:01 -0800 (PST) Received: from smtp25.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp25.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 6DFC4180080; Fri, 5 Feb 2016 05:50:00 -0500 (EST) Received: from app8.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp25.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 5E8C418013B; Fri, 5 Feb 2016 05:50:00 -0500 (EST) X-Sender-Id: ogud@ogud.com Received: from app8.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.5.4); Fri, 05 Feb 2016 05:50:00 -0500 Received: from ogud.com (localhost.localdomain [127.0.0.1]) by app8.wa-webapps.iad3a (Postfix) with ESMTP id 46FD528005A; Fri, 5 Feb 2016 05:50:00 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: ogud@ogud.com, from: ogud@ogud.com) with HTTP; Fri, 5 Feb 2016 05:50:00 -0500 (EST) Date: Fri, 5 Feb 2016 05:50:00 -0500 (EST) From: "Olafur Gudmundsson" To: "Shumon Huque" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20160205055000000000_87263" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: References: <20160204230640.69198.qmail@ary.lan> X-Auth-ID: ogud@ogud.com Message-ID: <1454669400.288623764@apps.rackspace.com> X-Mailer: webmail/12.0.0-RC Archived-At: Cc: "=?utf-8?Q?=3Cdane=40ietf.org=3E?=" Subject: Re: [dane] =?utf-8?q?Meeting_plans_for_Buenos_Aires=3F?= 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, 05 Feb 2016 10:50:03 -0000 ------=_20160205055000000000_87263 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0A =0AFor the record: =0AIF there is identified work to do= rechartering is an easy step.=0ALets identify what remains from existing c= harter that is still relevant.=0AAdd any new work proposed and there is int= erest in pursuing by more people than just the editors. =0A =0AOlafur=0APs:= the best way to figure out if a WG is done is to threaten to shut it down = =0A =0A =0A =0AOn Thursday, 4 February, 2016 20:37, "Shumon Huque" said:=0A=0A=0A=0A=0A=0AOn Thu, Feb 4, 2016 at 7:43 PM, Lawrence = Conroy <[ lconroy@insensate.co.uk ]( mailto:lconroy@insensate.co.uk )> wrot= e:=0AHi folks,=0A so ...=0A ogud + friendly AD:=0A There seems some seriou= s reluctance to re-charter DANE to do more work (for reasons I'd love to se= e spelt out).=0A The question's been asked, but I haven't seen a detailed a= nswer.=0A=0A Shumon/Bello/Melinda/...:=0A Given that reluctance, if you wan= t to do some work, develop a charter though the BOF=0A process (same as key= assure/DANE did), convince the ADs, and get a ->new<- WG for this new work.= =0A [maybe called SWEDE?]=0AThanks for the suggestion! I'd prefer to try to= recharter the current group=0Awith any new work items first, before this m= ore drastic option. But glancing=0Aat the current charter just now, it migh= t already cover some of the work=0Athat I outlined earlier.=0A-- =0AShumon = Huque. ------=_20160205055000000000_87263 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

<chair-hat=3Don>&nbs= p;

=0A

For the record: 

=0A

IF t= here is identified work to do rechartering is an easy step.

=0A

Lets identify what remains from existing charter that is still rel= evant.

=0A

Add any new work proposed and there is intere= st in pursuing by more people than just the editors. 

=0A

 

=0A

Olafur

=0A

Ps: th= e best way to figure out if a WG is done is to threaten to shut it down&nbs= p;

=0A

 

=0A

 

=0A

 

=0A

On Thursday, 4 February, 2016 20:3= 7, "Shumon Huque" <shuque@gmail.com> said:

=0A
=0A
=0A
=0A
On Thu, Feb 4, 2016 at 7:43 PM, Lawrence Con= roy <lconroy@insensate.co.uk> wrote:
=0AHi folks,
 so ...
ogud + frien= dly AD:
There seems some serious reluctance to re-charter DANE to do = more work (for reasons I'd love to see spelt out).
The question's bee= n asked, but I haven't seen a detailed answer.

Shumon/Bello/Mel= inda/...:
Given that reluctance, if you want to do some work, develop= a charter though the BOF
process (same as keyassure/DANE did), convi= nce the ADs, and get a ->new<- WG for this new work.
[maybe cal= led SWEDE?]=0A
Thanks for the suggestion! I'd prefer to tr= y to recharter the current group
=0A
with any new work items first= , before this more drastic option. But glancing
=0A
at the current= charter just now, it might already cover some of the work
=0A
tha= t I outlined earlier.
=0A
-- 
=0A
Shumon Huque.=0A
=0A
=0A
=0A
 ------=_20160205055000000000_87263-- From nobody Fri Feb 5 18:07:33 2016 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 3BCC91A0047 for ; Fri, 5 Feb 2016 18:07:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 wnBnuXjlJRPg for ; Fri, 5 Feb 2016 18:07:30 -0800 (PST) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 118DD1A005A for ; Fri, 5 Feb 2016 18:07:30 -0800 (PST) Received: by mail-pa0-x22b.google.com with SMTP id yy13so42975823pab.3 for ; Fri, 05 Feb 2016 18:07:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=2zFPsdXtXVrlhNyinejhoDCrIXauFvMcmkPI93BIGd4=; b=y8bSZNvhPpzV6Wm45W7prv0jh4yVioc/yR2esUyyYilx2aSsGtt60tQvdwbtJBjSfX IZu4zq0Skfh36IHvHSvJBti1+3EY9kYXum20vtFja8jJXh+2l5o796dFygN2j/0Iuvub f52gNn5EENrA4hS+ZoW06lW9nLs6BihFR2S5EBQeDUCKizUZw3ZPraU0xuaiuZy65rSe frUtQl65XIkiloj9OITAXDrcSEJaWYtPsuIqJvaxUoDU6DqgjYuxwQ2sr2ljInoluFby IpNjwtoCvEIurTirJaETP1+HyaiaI6NGkXwTz/hWyXrGTfeKb2ij1JTfirITHdm4K4XV uOCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=2zFPsdXtXVrlhNyinejhoDCrIXauFvMcmkPI93BIGd4=; b=k89DLKYPsTLwiIph8RAAaBWaQTtdj6X7bF7nw/z7HQKZ46yPfnBrApxhEEDY/UpCvP KbqocxDl+Q0Su64rlAbAe9TKCSSiJmhfJfIY+yHABH57KYl0TlclI5DIdscfSPB2gytd vFVnDVL/9AGs30iD+ElSksmIPH3vM1Jsy2M3lC+RX8MJ8bFzrZMyvrsMkbNY3BwPWuuj qN51hq8dxHqeRE7hV8tzgWdxPjVDS5S5b4t5rmVPic1y3Uyv8/P3HcuA3u6ltp60xb1f 35Zxj9GGeh0w99qa1736eyT5iQmKHfaue1697kvDkMk7JzmYN/deb6+GaCrmPVRzGEFu Crqw== X-Gm-Message-State: AG10YORelG0r1Az88RWADYDWnDKkc4apk3pWTSom33P4dNlYS0t/Rlbolbgfh5jddF4Bcg== X-Received: by 10.66.187.77 with SMTP id fq13mr7175491pac.25.1454724449705; Fri, 05 Feb 2016 18:07:29 -0800 (PST) Received: from Melindas-MacBook-Pro.local (216-67-62-89-radius.dynamic.acsalaska.net. [216.67.62.89]) by smtp.googlemail.com with ESMTPSA id r87sm27190750pfa.61.2016.02.05.18.07.28 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Feb 2016 18:07:28 -0800 (PST) To: dane@ietf.org References: <569FC8C7.40303@gmail.com> <56B3770C.8020505@dcrocker.net> <201602051002.u15A2q0P017177@new.toad.com> From: Melinda Shore Message-ID: <56B5555C.70604@gmail.com> Date: Fri, 5 Feb 2016 17:07:24 -0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <201602051002.u15A2q0P017177@new.toad.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dane] Why shut down the DANE group? 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, 06 Feb 2016 02:07:31 -0000 On 2/5/16 1:02 AM, John Gilmore wrote: > Yeah, let's not have the designers talking with the deployers. That can > lead to interoperability and harmony, which IETF is dead set against. Well, no. This is an artifact of how the IETF works. I think on balance the decision to terminate working groups as soon as they complete their charter work has led to exactly the problems you describe, but it's really bureaucratic rather than malicious. It may be time to start making wider use of maintenance and extensions working groups, although that's a wider discussion for the entire IETF. In any event working groups are typically not chartered on the basis of some of the arguments being made here and the discussion really needs to focus on things that need to be specified. But, if someone wants to take the discussion of M&E working groups to the broader list, I think I'd support that. Melinda From nobody Sat Feb 6 14:55:57 2016 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 AE7651A0404 for ; Sat, 6 Feb 2016 14:55:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.146 X-Spam-Level: **** X-Spam-Status: No, score=4.146 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_BRBL_LASTEXT=1.449, RCVD_IN_PSBL=2.7, RP_MATCHES_RCVD=-0.001, 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 mwY3947aCtPc for ; Sat, 6 Feb 2016 14:55:55 -0800 (PST) Received: from new.toad.com (new.toad.com [209.237.225.253]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (112/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 448311A03F9 for ; Sat, 6 Feb 2016 14:55:55 -0800 (PST) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id u16Mtnwt023961; Sat, 6 Feb 2016 14:55:49 -0800 Message-Id: <201602062255.u16Mtnwt023961@new.toad.com> To: Melinda Shore In-reply-to: <56B5555C.70604@gmail.com> References: <569FC8C7.40303@gmail.com> <56B3770C.8020505@dcrocker.net> <201602051002.u15A2q0P017177@new.toad.com> <56B5555C.70604@gmail.com> Comments: In-reply-to Melinda Shore message dated "Fri, 05 Feb 2016 17:07:24 -0900." Date: Sat, 06 Feb 2016 14:55:49 -0800 From: John Gilmore Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Why shut down the DANE group? 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, 06 Feb 2016 22:55:56 -0000 > > Yeah, let's not have the designers talking with the deployers. That can > > lead to interoperability and harmony, which IETF is dead set against. > > Well, no. This is an artifact of how the IETF works. You mean, how the IETF fails. > I think on balance the decision to terminate working groups > as soon as they complete their charter work has led to > exactly the problems you describe, but it's really > bureaucratic rather than malicious. If it's a pervasive, bureaucratic issue, then it should be fixed even more than if it was just based on one person's malice. The bizarre part for me is that it's easier just to let it continue. So why does the bureacracy do actual work to shut it down? John From nobody Sat Feb 6 15:06:52 2016 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 B4CCC1A6F7B for ; Sat, 6 Feb 2016 15:06:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 jku1J5MpVxA2 for ; Sat, 6 Feb 2016 15:06:48 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D8221A6F7F for ; Sat, 6 Feb 2016 15:06:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 51ABCBE5D; Sat, 6 Feb 2016 23:06:39 +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 MX69bW4XUl1r; Sat, 6 Feb 2016 23:06:38 +0000 (GMT) Received: from [10.87.48.75] (unknown [86.42.26.249]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 86A18BE58; Sat, 6 Feb 2016 23:06:37 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1454799997; bh=S/IehQNw8zTEn2Z1GlhxX9iac5fSb51DHtextSjYy/0=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=Gk7LcUlUm+za0OlIXOR0go7Ag/OP3h9LsQdl75BtFE+Qgjlq88ec0Dus07cZdUT/p 7G++/ljP5MdRg5OyypnKQfweywDKIzhTrIvCSjSBA1NpSGHZ/SEfMSgsiATEcmDg29 P8xV0TMxmVcQXllfJQCUMcNUW7TnxNToVw70zR4Y= To: John Gilmore , Melinda Shore References: <569FC8C7.40303@gmail.com> <56B3770C.8020505@dcrocker.net> <201602051002.u15A2q0P017177@new.toad.com> <56B5555C.70604@gmail.com> <201602062255.u16Mtnwt023961@new.toad.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56B67C7C.2020109@cs.tcd.ie> Date: Sat, 6 Feb 2016 23:06:36 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <201602062255.u16Mtnwt023961@new.toad.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Why shut down the DANE group? 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, 06 Feb 2016 23:06:50 -0000 Folks, I think the chairs already said that if there's work to be done they're up for this wg continuing. I think that is entirely the right position to take. The chairs had earlier said that if the chartered work items were completed then shutting down would be the plan. And that is a good plan in general, though there's of course room for what can be quite subtle differences in reasonable opinions. And if more credible work turns up with more credible folks willing to do that, then continuing is the clear thing to do, with re-chartering as needed. (And re-chartering is not at all a hard thing, whoever said it is hard... is plain wrong.) What I don't myself see any room for, or have any time for, is the kind of hyperbole below - a phrase like "pervasive bureaucracy" is IMO an entirely undeserved and unjustified slur presumably aimed at the WG chairs and is no form of rational or informed criticism. And with that, I hope participants here move their attention back to improving how public keys get distributed. Thanks, S. On 06/02/16 22:55, John Gilmore wrote: >>> Yeah, let's not have the designers talking with the deployers. That can >>> lead to interoperability and harmony, which IETF is dead set against. >> >> Well, no. This is an artifact of how the IETF works. > > You mean, how the IETF fails. > >> I think on balance the decision to terminate working groups >> as soon as they complete their charter work has led to >> exactly the problems you describe, but it's really >> bureaucratic rather than malicious. > > If it's a pervasive, bureaucratic issue, then it should be fixed even > more than if it was just based on one person's malice. > > The bizarre part for me is that it's easier just to let it continue. > So why does the bureacracy do actual work to shut it down? > > John > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > From nobody Mon Feb 8 08:53:33 2016 Return-Path: X-Original-To: dane@ietf.org Delivered-To: dane@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C04831B2C97; Mon, 8 Feb 2016 08:53:30 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.14.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160208165330.16376.99994.idtracker@ietfa.amsl.com> Date: Mon, 08 Feb 2016 08:53:30 -0800 Archived-At: Cc: draft-ietf-dane-openpgpkey@ietf.org, dane-chairs@ietf.org, dane@ietf.org Subject: [dane] Last Call: (Using DANE to Associate OpenPGP public keys with email addresses) to Experimental RFC X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@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, 08 Feb 2016 16:53:30 -0000 The IESG has received a request from the DNS-based Authentication of Named Entities WG (dane) to consider the following document: - 'Using DANE to Associate OpenPGP public keys with email addresses' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-02-22. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract OpenPGP is a message format for email (and file) encryption that lacks a standardized lookup mechanism to securely obtain OpenPGP public keys. DNS-Based Authentication of Named Entities ("DANE") is a method for publishing public keys in DNS. This document specifies a DANE method for publishing and locating OpenPGP public keys in DNS for a specific email address using a new OPENPGPKEY DNS Resource Record. Security is provided via Secure DNS, however the OPENPGPKEY record is not a replacement for verification of authenticity via the "Web of Trust" or manual verification. The OPENPGPKEY record can be used to encrypt an email that would otherwise have to be send unencrypted. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/ballot/ No IPR declarations have been submitted directly on this I-D. This is a second IETF last call - the diff from version -05 which was the subject of the previous IETF last call is at [1]. [1] https://www.ietf.org/rfcdiff?url1=draft-ietf-dane-openpgpkey-05&url2=draft-ietf-dane-openpgpkey-07 From nobody Fri Feb 12 04:51:26 2016 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 03E4A1B44FB for ; Fri, 12 Feb 2016 04:51:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.122 X-Spam-Level: X-Spam-Status: No, score=0.122 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, 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 YDej6yt8_Z5X for ; Fri, 12 Feb 2016 04:51:23 -0800 (PST) Received: from mail-lf0-x241.google.com (mail-lf0-x241.google.com [IPv6:2a00:1450:4010:c07::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0834C1B44F8 for ; Fri, 12 Feb 2016 04:51:23 -0800 (PST) Received: by mail-lf0-x241.google.com with SMTP id e36so4098385lfi.0 for ; Fri, 12 Feb 2016 04:51:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=e/abLW2WMMrdyflkEq1qBabtFL4kmGPl6if0VHAKKcE=; b=gQRvBH8B6iydoasQmXb0gDyBRIEtXcadTTFZpGq4V1K0uztWi/tQ74H95Q5Y02u9oO dULKmRcTGTse34Zo0VSYH43g6wzFxxvtFcntXOjrFe0HasvDhIHOf1FU+beW66QTyrh1 y88qj3Z8/RrWOkHKEhHV/Jg5o0Ytxy6ox9YGXi3vHaqM+OkaxSg3KuunaCEg64Wr2iL1 H3YI8d2MbLBUieTZNTU9MDE7AEcb2vrpQ8TyZBHG4YNJEzSvCzcKkUZYX4escOiEATQu cUm4wZSRyldcb/pkiYMdMTif8t+mroK+4zQ7Bj4m23OWF3U+modrlMLqzfAszZ9ztMJ5 Tx5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=e/abLW2WMMrdyflkEq1qBabtFL4kmGPl6if0VHAKKcE=; b=VfDW69rN1/2TKdkonQwcK9hQvwgRyrSDdAL0G0QCY3DOGMiaS7EbEMarOLqYy/xRTc Uj4xkecF1Fq8tMZJYW6diah7/s5SZNYpR8hR+ilLL+Hx8H3LGVFQbQub8n9KKM692KdW Vmo33AH9yoBhh7RQRBDRRgUGJk9CxI87ZhUqzJyV32trfRTw50sJdV69oKfXhOA3RGNr Eh0X4SNmsQ1TJ2ZfB1+hYYXg6DcXVPhcUHCwdBVK/Lw/qxf7nmuA8XSz0T2g1bM46+Eg FhH2vmbI6wxEnvmkk2BRCJu1wq4rexfMx+YJj0wO4YMKmPOqa8p54hZMTYtroCDq3ER7 fQkw== X-Gm-Message-State: AG10YOSa9djiVqB0Exj2lTyV8OCibnhK4WZ5RquFnwJjmUQqc7JP8DwAZyt5ZU5ov63ZweHIbJxZemWYUTdVhg== MIME-Version: 1.0 X-Received: by 10.25.163.76 with SMTP id m73mr482155lfe.39.1455281481321; Fri, 12 Feb 2016 04:51:21 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.49.80 with HTTP; Fri, 12 Feb 2016 04:51:21 -0800 (PST) In-Reply-To: <201602051002.u15A2q0P017177@new.toad.com> References: <569FC8C7.40303@gmail.com> <56B3770C.8020505@dcrocker.net> <201602051002.u15A2q0P017177@new.toad.com> Date: Fri, 12 Feb 2016 07:51:21 -0500 X-Google-Sender-Auth: ee8UizHIbIOPWLouVib_Ft-2O1U Message-ID: From: Phillip Hallam-Baker To: John Gilmore Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Dave Crocker , "" Subject: Re: [dane] Why shut down the DANE group? 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, 12 Feb 2016 12:51:25 -0000 On Fri, Feb 5, 2016 at 5:02 AM, John Gilmore wrote: >> design a solution, 3) deploy the solution. The IETF is (only) step #2. > > Yeah, let's not have the designers talking with the deployers. That can > lead to interoperability and harmony, which IETF is dead set against. If you want deployment, then you had better talk to the developers in step 0, not after the finished product is published. This working group made sure that the developer community was alienated at an early stage. Their input was ignored and some of the participants made sure that they insulted a couple of key people in the browser world whose support was essential. The industry now has or at least it thinks it has two answers to the problems DANE addresses. They are using HTTP key pinning as their security policy layer and are looking at Lets Encrypt for free certs. If you want to achieve the original objectives of this working group and get them deployed, then work within the framework that the parties whose buy-in you need for deployment have already established. HTTP key pinning does provide some security but it is in band to HTTP which means it can only provide security after first use and there is a big potential for 'shooting yourself in the foot'. The DNS based answer to those problems that is deployable is to take the HTTP key pinning record that they have already defined and support in the browser code and publish that exact text string as a DNS Resource Record. From nobody Fri Feb 12 05:26:25 2016 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 5BFD01A00B2 for ; Fri, 12 Feb 2016 05:26:17 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 z5k84XGV5KZC for ; Fri, 12 Feb 2016 05:26:11 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0093.outbound.protection.outlook.com [65.55.169.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D31FA1A00B9 for ; Fri, 12 Feb 2016 05:26:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.onmicrosoft.com; s=selector1-isoc-org; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=M0jlRdgj9rcY6+QQfUck98Rdd/Zi7CkTGW+RBhxzFas=; b=tu26VxIAsD2SU4Kfltq5y26Dyu9UVATwjjLvBXTiRsv7OCLa99CXa9l786lmrtAXnCRnGvcekuxqJf7+yP5+2q1chmDgDpU0Yr2bZVxbNcbWnzDjSts6g+AAyZhELeaAYl8gvEIA0dBmGGoS6YRw3e4HvQF3hBM9eOYQR9/l4rg= Received: from CY1PR0601MB1657.namprd06.prod.outlook.com (10.163.232.19) by CY1PR0601MB1657.namprd06.prod.outlook.com (10.163.232.19) with Microsoft SMTP Server (TLS) id 15.1.403.16; Fri, 12 Feb 2016 13:26:08 +0000 Received: from CY1PR0601MB1657.namprd06.prod.outlook.com ([10.163.232.19]) by CY1PR0601MB1657.namprd06.prod.outlook.com ([10.163.232.19]) with mapi id 15.01.0403.017; Fri, 12 Feb 2016 13:26:08 +0000 From: Dan York To: Phillip Hallam-Baker Thread-Topic: Putting HPKP header into DNS - Re: [dane] Why shut down the DANE group? Thread-Index: AQHRZZQbx7hm6P1tyE2si+2iiadFPJ8oZrIA Date: Fri, 12 Feb 2016 13:26:07 +0000 Message-ID: <23033B83-5182-4F6C-BCA7-E9A51A1A0D64@isoc.org> References: <569FC8C7.40303@gmail.com> <56B3770C.8020505@dcrocker.net> <201602051002.u15A2q0P017177@new.toad.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: hallambaker.com; dkim=none (message not signed) header.d=none;hallambaker.com; dmarc=none action=none header.from=isoc.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [74.69.229.215] x-microsoft-exchange-diagnostics: 1; CY1PR0601MB1657; 5:IULAl9rfMdyQgObpaqbyx2hPx9vXJExiJIUsCuE1UuJByDO+48ZbQ5PvgWcQgZVePVHeVwSBCIl6lx6C8mZjRrzvLvn2QY5qkCC60kEyzD112k3YffaB2D4ChwylTWhEDvoqfRplJKgQhVKCetBmYg==; 24:3YxuV0t3OCMhiB1xe+ij7Xo93A8mzYJGGRMvMfVVgjRAGxdyj65e8uh9ylVn9pe+F9g3axfUUykiHH2hl4uwEgWwJRIWrKkox5b2iUCZWYU= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0601MB1657; x-ms-office365-filtering-correlation-id: cd6434d8-5bbd-4574-dae0-08d333b010f5 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:CY1PR0601MB1657; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0601MB1657; x-forefront-prvs: 0850800A29 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(377454003)(24454002)(5004730100002)(87936001)(122556002)(5008740100001)(19580395003)(82746002)(19617315012)(19580405001)(10400500002)(5001960100002)(229853001)(86362001)(6116002)(76176999)(66066001)(50986999)(3846002)(586003)(54356999)(16236675004)(93886004)(102836003)(99286002)(110136002)(92566002)(2906002)(1096002)(33656002)(15395725005)(1220700001)(106116001)(11100500001)(40100003)(5002640100001)(77096005)(36756003)(3280700002)(15975445007)(3660700001)(189998001)(4326007)(83716003)(2900100001)(2950100001); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0601MB1657; H:CY1PR0601MB1657.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_23033B8351824F6CBCA7E9A51A1A0D64isocorg_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Feb 2016 13:26:07.8680 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0601MB1657 Archived-At: Cc: IETF DANE Mailinglist , Dave Crocker Subject: [dane] Putting HPKP header into DNS - Re: Why shut down the DANE group? 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, 12 Feb 2016 13:26:17 -0000 --_000_23033B8351824F6CBCA7E9A51A1A0D64isocorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Phillip, On Feb 12, 2016, at 7:51 AM, Phillip Hallam-Baker > wrote: HTTP key pinning does provide some security but it is in band to HTTP which means it can only provide security after first use and there is a big potential for 'shooting yourself in the foot'. A couple of weeks ago I was having this kind of discussion with someone abo= ut how cert pinning was Trust-On-First-Use and how DNSSEC/DANE could be use= d *with* cert pinning to get around the TOFU problem. My suggestion was th= at the app in question could also do a lookup on the DANE TLSA record and c= ompare that with what they were getting for the cert to pin, but... The DNS based answer to those problems that is deployable is to take the HTTP key pinning record that they have already defined and support in the browser code and publish that exact text string as a DNS Resource Record. ... that is certainly another answer and perhaps much simpler and easier. = Put the exact RFC 7469 HPKP header ( https://tools.ietf.org/html/rfc7469 )= in DNS as a resource record and then sign that with DNSSEC. Has anyone ever taken a look at whether that (putting the HPKP header into = DNS) would be something reasonable to do? Given that this would not be with the TLSA record, I realize this work migh= t be outside of the scope of the *current* charter of the DANE WG ( https:/= /datatracker.ietf.org/wg/dane/charter/ ), although it does say "The DANE WG= will specify how to incorporate DANE and DANE-like functionality into prot= ocols." But if this is something worth pursuing it could be something don= e here (with a recharter) or something done in another WG (or a new short-t= erm WG could be spun up). Anyway... an interesting idea, Phillip! Dan -- Dan York Senior Content Strategist, Internet Society york@isoc.org +1-802-735-1624 Jabber: york@jabber.isoc.org Skype: danyork http://twitter.com/danyork http://www.internetsociety.org/ --_000_23033B8351824F6CBCA7E9A51A1A0D64isocorg_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Phillip,

On Feb 12, 2016, at 7:51 AM, Phillip Hallam-Baker <phill@hallambaker.com>= ; wrote:

HTTP key pinning does provide some security but it is in band to HTTP
which means it can only provide security after first use and there is
a big potential for 'shooting yourself in the foot'.

A couple of weeks ago I was having this kind of discussion with someon= e about how cert pinning was Trust-On-First-Use and how DNSSEC/DANE could b= e used *with* cert pinning to get around the TOFU problem.  My suggest= ion was that the app in question could also do a lookup on the DANE TLSA record and compare that with what they w= ere getting for the cert to pin, but...

The DNS based
answer to those problems that is deployable is to take the HTTP key
pinning record that they have already defined and support in the
browser code and publish that exact text string as a DNS Resource
Record.

... that is certainly another answer and perhaps much simpler and easier. &= nbsp; Put the exact RFC 7469 HPKP header ( https://tools.ietf.org/html/rfc7469&nbs= p;) in DNS as a resource record and then sign that with DNSSEC.

Has anyone ever taken a look at whether that (putting the HPKP header = into DNS) would be something reasonable to do?

Given that this would not be with the TLSA record, I realize this work= might be outside of the scope of the *current* charter of the DANE WG (&nb= sp;htt= ps://datatracker.ietf.org/wg/dane/charter/ ), although it does say "The DANE WG will specify how to incorporate DAN= E and DANE-like functionality into protocols."   But if this is s= omething worth pursuing it could be something done here (with a recharter) = or something done in another WG (or a new short-term WG could be spun up).

Anyway... an interesting idea, Phillip!

Dan

--
Dan York
Senior Content Strategist, Int= ernet Society
york@isoc.org   +1-802-735-1624
Jabber: york@jabber.isoc.org 
Skype: danyork   http://twitter.com/danyork

http://www.internets= ociety.org/




--_000_23033B8351824F6CBCA7E9A51A1A0D64isocorg_-- From nobody Fri Feb 12 06:46:03 2016 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 3168A1A0430 for ; Fri, 12 Feb 2016 06:46:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 SkS7W-TtCV_G for ; Fri, 12 Feb 2016 06:46:01 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A2C71A0423 for ; Fri, 12 Feb 2016 06:46:01 -0800 (PST) Received: from [192.168.1.87] (76-218-10-206.lightspeed.sntcca.sbcglobal.net [76.218.10.206]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id u1CEk02f024790 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT) for ; Fri, 12 Feb 2016 06:46:00 -0800 References: <569FC8C7.40303@gmail.com> <56B3770C.8020505@dcrocker.net> <201602051002.u15A2q0P017177@new.toad.com> From: Dave Crocker Organization: Brandenburg InternetWorking To: "" Message-ID: <56BDF027.9010609@dcrocker.net> Date: Fri, 12 Feb 2016 06:45:59 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <201602051002.u15A2q0P017177@new.toad.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 12 Feb 2016 06:46:00 -0800 (PST) Archived-At: Subject: Re: [dane] Why shut down the DANE group? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 14:46:02 -0000 On 2/5/2016 2:02 AM, John Gilmore wrote: >> design a solution, 3) deploy the solution. The IETF is (only) step #2. > > Yeah, let's not have the designers talking with the deployers. That can > lead to interoperability and harmony, which IETF is dead set against. It important that the IETF not be the only place such folk can interact. Successful protocols have active involvement of developers and deployers from before the standards process, and long after. There needs to be an /independent/ community establishing the needs and exploiting the new capabilities. Again: the IETF is a way-station in the life-cycle. It supplies some resources and process for a step along the way, but it is not the anchor holding the community together. Keeping the IETF mailing list active is often helpful, but that's different from maintain a working group. For that independent community, outside of the IETF it is common to have multiple, related mailing lists, such as foo-interest, for general discussion, and foo-dev, for discussion of the technical details and possible revisions, and foo-ops, for deployment discussion. As for the concern expressed in the thread for garnering feedback about a new specification and then incorporating changes, that forms input to a fresh effort to form a new working group, to do the next version of the specification. In fact there often is a a counter-productive effect of keeping a working group actively seeking input to revisions: It communicates to the industry that the specification remains unstable. Operators do not like deploying unstable specifications; so they defer adoption. d/ From nobody Fri Feb 12 14:28:08 2016 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 36B481A9133 for ; Fri, 12 Feb 2016 14:28:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-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 JOwSqASz8vzF for ; Fri, 12 Feb 2016 14:28:04 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73E1C1A9134 for ; Fri, 12 Feb 2016 14:28:04 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3q28bj5WwMzGVs; Fri, 12 Feb 2016 23:28:01 +0100 (CET) X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 1ZPbQTSusuMe; Fri, 12 Feb 2016 23:28:00 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 12 Feb 2016 23:28:00 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 56A82600B883; Fri, 12 Feb 2016 17:27:59 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 56A82600B883 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 52DD61013; Fri, 12 Feb 2016 17:27:59 -0500 (EST) Date: Fri, 12 Feb 2016 17:27:59 -0500 (EST) From: Paul Wouters To: Dan York In-Reply-To: <23033B83-5182-4F6C-BCA7-E9A51A1A0D64@isoc.org> Message-ID: References: <569FC8C7.40303@gmail.com> <56B3770C.8020505@dcrocker.net> <201602051002.u15A2q0P017177@new.toad.com> <23033B83-5182-4F6C-BCA7-E9A51A1A0D64@isoc.org> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: IETF DANE Mailinglist Subject: Re: [dane] Putting HPKP header into DNS - Re: Why shut down the DANE group? 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, 12 Feb 2016 22:28:06 -0000 On Fri, 12 Feb 2016, Dan York wrote: > ... that is certainly another answer and perhaps much simpler and easier.   Put the exact RFC 7469 HPKP header ( https://tools.ietf.org/html/rfc7469 ) in DNS as a resource record and > then sign that with DNSSEC. > > Has anyone ever taken a look at whether that (putting the HPKP header into DNS) would be something reasonable to do? If you are using the http server to send the key info, why not just send the TLSA RRset as an option? We already have a draft for that: https://tools.ietf.org/html/draft-shore-tls-dnssec-chain-extension-02 > Given that this would not be with the TLSA record I don't see why not to use the TLSA record. Its existence basically means "MUST do TLS with this key, hard fail otherwise". Paul From nobody Fri Feb 12 15:02:26 2016 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 AB2E01AC3B5 for ; Fri, 12 Feb 2016 15:02:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 V18oO7UiumPk for ; Fri, 12 Feb 2016 15:02:23 -0800 (PST) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E4001ABD35 for ; Fri, 12 Feb 2016 15:02:23 -0800 (PST) Received: by mail-yw0-x234.google.com with SMTP id h129so76760212ywb.1 for ; Fri, 12 Feb 2016 15:02:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:content-type; bh=vBnwIcAIoYBkTU+l2OT98yJukNbtIMTsID4ojCE1y9o=; b=mnWKWST+M2TIxnKzri2sYv/v+cgBSyyaxv1zwWP6biMqATu/qoaBYLLC9XfjcgI3Un O/norjPGd1hadvu8CHoYgVa6QO5+sh4NlFQBxy0OYXW2dv7rIhGt2rdO16pvC/+ZIo4m Hz+RDWA39lWjjhifn0zfoecD2tO/R0slR0vZneflBEWK9admYokSvzfev4eXKhG3jd4Y DPUElZCsVdn+/z7MCWqfpPMfL3TyGjoVo9Mq6S3fiC87VNjbAnx1XqoZePGVF4sBkRB8 sZsaaol7BzWkWUVHZnzGvWxoyUrrmQgG1RADII1ii7ace4wif5KUT2SB3lGN9Ino5qCV lC7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=vBnwIcAIoYBkTU+l2OT98yJukNbtIMTsID4ojCE1y9o=; b=In+Iml0/zE5nKhDkfeoyUNi3DX5Z1HyKtG/XznZGxCFnxSxat95mwaoB5/9UqOeWMf irB0gjQdPpLd8oLe28UzPJTpq7o4CvAzvKFaltgP8fpwNE1kx0t1xWe8l4C+YT1yZZAz jOxRe0tFLTcIHDwgP2iCUUvZLB9Vld31eFH5QV4Ai5n/XVtSqbMWKxjPGbh8BqW2C88V y04yMAaX2lQoM1CGHM3R1eCgjMzH3g79x1eHVYDrmkGcO3UpGszSRRQXGHsqzQO0vR9Y hP/dM0Rj1tDlXcV1eltygXgg6WQJ6zRFOL6cgnF1dU0N3GvPCpb8BJ3Tk4+4yguviH+1 EYGw== X-Gm-Message-State: AG10YORj6qTBzQhJ0quPQfjLaJxgjpOAYlwquqUZdvooMSSPM6GPK1odM+z9BX2L9Srg4l2KaQmFdWncXmqz7JqA X-Received: by 10.129.119.10 with SMTP id s10mr2834443ywc.127.1455318142927; Fri, 12 Feb 2016 15:02:22 -0800 (PST) MIME-Version: 1.0 From: Warren Kumari Date: Fri, 12 Feb 2016 23:02:12 +0000 Message-ID: To: "" Content-Type: multipart/alternative; boundary=001a1141c836f1fb2f052b9aa8b6 Archived-At: Subject: [dane] DANE meeting at IETF95 in BA 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, 12 Feb 2016 23:02:24 -0000 --001a1141c836f1fb2f052b9aa8b6 Content-Type: text/plain; charset=UTF-8 Hi all, We are glad to see all of the enthusiasm and desire to get more work done[0] in response to our "Are we done here?" email. We've requested a meeting slow in Buenos Aires, and would like to have a productive meeting - as always we will be giving meeting time to documents which have open issues which are best discussed in person, then to documents which have had lots of discussion. Because we are also discussing new work we may also give time to new documents / ideas. So, if you would like some agenda time, please send mail to dane-chairs. Thank you, Olafur and Warren [0]: Huh, almost like we planned that.... ;-P --001a1141c836f1fb2f052b9aa8b6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

We are glad to see all of the enthus= iasm and desire to get more work done[0] in response to our "Are we do= ne here?" email.

We've reque= sted a meeting slow in Buenos Aires, and would like to have a productive me= eting - as always we will be giving meeting time to documents which have op= en issues which are best discussed in person, then to documents which have = had lots of discussion. Because we are also discussing new work we may also= give time to new documents / ideas.

= So, if you would like some agenda time, please send mail to dane-chairs.


Thank you,
Olafur and Warren

[0]: Huh,= almost like we planned that.... ;-P
--001a1141c836f1fb2f052b9aa8b6-- From nobody Fri Feb 12 17:42:30 2016 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 8DF731B29B4 for ; Fri, 12 Feb 2016 17:42:29 -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, 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 LrrHrEhMSULW for ; Fri, 12 Feb 2016 17:42:28 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1631D1B29B3 for ; Fri, 12 Feb 2016 17:42:27 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id A8344284CDB; Sat, 13 Feb 2016 01:42:26 +0000 (UTC) Date: Sat, 13 Feb 2016 01:42:26 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20160213014226.GP19242@mournblade.imrryr.org> References: <569FC8C7.40303@gmail.com> <56B3770C.8020505@dcrocker.net> <201602051002.u15A2q0P017177@new.toad.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [dane] Why shut down the DANE group? 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, 13 Feb 2016 01:42:29 -0000 On Fri, Feb 12, 2016 at 07:51:21AM -0500, Phillip Hallam-Baker wrote: > The industry now has or at least it thinks it has two answers to the > problems DANE addresses. They are using HTTP key pinning as their > security policy layer and are looking at Lets Encrypt for free certs. > > If you want to achieve the original objectives of this working group > and get them deployed, then work within the framework that the parties > whose buy-in you need for deployment have already established. It seems to me that the most significant obstacle to using DNSSEC-assisted key pinning in browsers is not the RRdata format (TLSA or HPKP text), but rather the DNSSEC last-mile problem, which means browsers often can't get DNSSEC validated records of any kind. Hence revived efforts to transport DNS data inside the TLS handshake between HTTP server and client. Given that the DNSSEC approach has more solid mechanisms for ensuring freshness, and that DANE also supports pinning of trust-anchors, not just EE keys, there is little to recommend HPKP once DNSSEC is available. -- Viktor. From nobody Fri Feb 12 20:13:39 2016 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 3350B1B2B96 for ; Fri, 12 Feb 2016 20:13:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, 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 FC-eQEIiyiUz for ; Fri, 12 Feb 2016 20:13:36 -0800 (PST) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 350521B2B91 for ; Fri, 12 Feb 2016 20:13:36 -0800 (PST) Received: by mail-lf0-x232.google.com with SMTP id l143so62792706lfe.2 for ; Fri, 12 Feb 2016 20:13:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=5ePcZoLXo/Uu0uipVv/u8Y52ImqudLg7W/UHj29Tfxs=; b=K6BLHyyJyVqfUcpj5ZyGRcZ8cjeHFxScokzuXrDR3r/66JDHxJPGm4SnxTMgl51QCw FfwPtAF4+tYEkY3mjOcwd0klLgqH9SLn3ql7DQujvhZ27C5P9tM88KcU1fbJ8edJ4EBF MTQmuWiJ1QH6AfbCSfuy8KC+qByn/5sAIHu16i8YYeiw4PMvVYNZp/T7O/8OClRNo9iq v19xj9RDsdUW+3OCELYOunl/suNfrCxiJqe0Lu9LPozmqkuATcf+L4dfiUbH5a5u6dCc ZLw4IfPHFPvif4lOlzE99VXYPtRugyXY1MV0Jd9hcfBFL6ClUtYfEcbQeB8Df/2UNgDf 0wmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=5ePcZoLXo/Uu0uipVv/u8Y52ImqudLg7W/UHj29Tfxs=; b=a//6CJEaiEfswXPlI9UKmdrSCHzrerDit0rncbDKmbLhWerVi6cTKKBKLPboPWef8j K+6ogWHzk7WwohHOOfBQIpnMPuw7xpeoBFj2IXcxzGP5dopr2KD6agCMZ/d/rnCNKJxm 6/hPtvLWSn5fZ8X6KfHmE/+K820YiMIXAt7IG5tpWrRUDYbH7j6f7aW69itt55gjqXbc I/iIj1pXABBaRPEbdMSMQ68HtwGvNk/38kv4W2O4CpuIMg2SG7d9VQdOpmPi1F2kb9/1 KkgidHCAiE9Ey26f5Re2wOU1Wgjp/pMsq4kY7nPdV/w0Cr2k0x4h+s4FQWMcgkY2qNGp 6pZg== X-Gm-Message-State: AG10YOTwETcUszDYfLN1o2ohD+ufQt4gItaKEGvqCoUnLAB6HqutJiKD8T2+lm2b/dwJK5MaL6SAimDZMFd4Vw== MIME-Version: 1.0 X-Received: by 10.25.163.76 with SMTP id m73mr1831655lfe.39.1455336814370; Fri, 12 Feb 2016 20:13:34 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.49.80 with HTTP; Fri, 12 Feb 2016 20:13:34 -0800 (PST) In-Reply-To: <20160213014226.GP19242@mournblade.imrryr.org> References: <569FC8C7.40303@gmail.com> <56B3770C.8020505@dcrocker.net> <201602051002.u15A2q0P017177@new.toad.com> <20160213014226.GP19242@mournblade.imrryr.org> Date: Fri, 12 Feb 2016 23:13:34 -0500 X-Google-Sender-Auth: a1HCc9ba6JZd3xOSNciIIIrtfaw Message-ID: From: Phillip Hallam-Baker To: "dane@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [dane] Why shut down the DANE group? 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, 13 Feb 2016 04:13:38 -0000 On Fri, Feb 12, 2016 at 8:42 PM, Viktor Dukhovni wrote: > On Fri, Feb 12, 2016 at 07:51:21AM -0500, Phillip Hallam-Baker wrote: > >> The industry now has or at least it thinks it has two answers to the >> problems DANE addresses. They are using HTTP key pinning as their >> security policy layer and are looking at Lets Encrypt for free certs. >> >> If you want to achieve the original objectives of this working group >> and get them deployed, then work within the framework that the parties >> whose buy-in you need for deployment have already established. > > It seems to me that the most significant obstacle to using > DNSSEC-assisted key pinning in browsers is not the RRdata format > (TLSA or HPKP text), but rather the DNSSEC last-mile problem, which > means browsers often can't get DNSSEC validated records of any > kind. Yes, hence I submitted a proposal to address that issue before DANE chartered. The other problem is that in DANE DNSSEC is a MUST. Which was a problem when every single one of my browser contacts refused to consider at present. My goal was to upsell my DV customers to DNSSEC. That can't happen if it is a MUST. > Hence revived efforts to transport DNS data inside the TLS handshake > between HTTP server and client. But the folk pursuing that effort refuse to consider the fact that the browser engineers are pushed to minimize latency as first priority. So now deployment of DPRIV is effectively gated on TCP Fast start. > Given that the DNSSEC approach has more solid mechanisms for ensuring > freshness, and that DANE also supports pinning of trust-anchors, > not just EE keys, there is little to recommend HPKP once DNSSEC is > available. Except for the fact that it is already deployed and has a comprehensive support base. HPKP in a DNS RR offers exactly the same functionality without the deployment hassles. Why do you expect the internet to bend to the will of a dozen people who don't listen? From nobody Fri Feb 12 20:35:19 2016 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 1AAB81B2BD6 for ; Fri, 12 Feb 2016 20:35:19 -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, 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 ExA3OcpuYxsP for ; Fri, 12 Feb 2016 20:35:17 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9626D1B2BD4 for ; Fri, 12 Feb 2016 20:35:17 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 7525D282FB3; Sat, 13 Feb 2016 04:35:16 +0000 (UTC) Date: Sat, 13 Feb 2016 04:35:16 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20160213043516.GQ19242@mournblade.imrryr.org> References: <569FC8C7.40303@gmail.com> <56B3770C.8020505@dcrocker.net> <201602051002.u15A2q0P017177@new.toad.com> <20160213014226.GP19242@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.24 (2015-08-30) Archived-At: Subject: Re: [dane] Why shut down the DANE group? 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, 13 Feb 2016 04:35:19 -0000 On Fri, Feb 12, 2016 at 11:13:34PM -0500, Phillip Hallam-Baker wrote: > HPKP in a DNS RR offers exactly the same functionality without the > deployment hassles. Why do you expect the internet to bend to the will > of a dozen people who don't listen? Again this is quite orthogonal to the payload format, you're arguing for using DNS key pinning without DNSSEC (similar to DKIM). That makes the lookup vulnerable to active attacks, so we're back to TOFU and cache lifetimes longer than the DNS TTL, ... There a lot less reason left to using DNS by the time that happens, except for the hope of the upselling you mention, where perhaps some folks start publishing the same records in signed zones, and clients start checking the signatures. Yes, I understand that DNSSEC is at present and may indefinitely remain too high a bar. In which case DANE fails. However key pinning via insecure DNS is not really DANE, it is just an alternate transport for some application data via a typically untrusted cache. It may be more efficient than a roundrip to the HTTP server, but that's all. So I don't think there was is any need for a DANE working-group to propose and standardize such things. The DANE working-group is trying something more ambitious, that may fail, but is likely worth a try. -- Viktor. From nobody Sat Feb 13 02:52:11 2016 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 963231B30AB for ; Sat, 13 Feb 2016 02:52:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.643 X-Spam-Level: X-Spam-Status: No, score=0.643 tagged_above=-999 required=5 tests=[HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.006, 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 MXPwlzZL2WsE for ; Sat, 13 Feb 2016 02:52:08 -0800 (PST) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67B8F1B30AA for ; Sat, 13 Feb 2016 02:52:08 -0800 (PST) Received: from [192.168.1.122] (frobbit.cust.teleservice.net [85.30.128.225]) by mail.frobbit.se (Postfix) with ESMTPSA id C7C661FD35 for ; Sat, 13 Feb 2016 11:42:44 +0100 (CET) From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" To: dane@ietf.org Date: Sat, 13 Feb 2016 11:42:48 +0100 Message-ID: <91AC572E-B942-448F-BB17-BB31C5D13C89@frobbit.se> In-Reply-To: <20160213043516.GQ19242@mournblade.imrryr.org> References: <569FC8C7.40303@gmail.com> <56B3770C.8020505@dcrocker.net> <201602051002.u15A2q0P017177@new.toad.com> <20160213014226.GP19242@mournblade.imrryr.org> <20160213043516.GQ19242@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_4DE52D1B-970C-4D18-A19C-C52D463165EE_="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Mailer: MailMate (1.9.4r5220) Archived-At: Subject: Re: [dane] Why shut down the DANE group? 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, 13 Feb 2016 10:52:09 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_4DE52D1B-970C-4D18-A19C-C52D463165EE_= Content-Type: text/plain On 13 Feb 2016, at 5:35, Viktor Dukhovni wrote: > Yes, I understand that DNSSEC is at present and may indefinitely remain too high a bar. It is too high a bar just because this is repeated over and over again. Not because it really is. Patrik --=_MailMate_4DE52D1B-970C-4D18-A19C-C52D463165EE_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAla/CKgACgkQrMabGguI180VyACgjl5Oul8Yet8QW4iE31W9Sg/Y NOwAniKwVyxtVxXhJOtIR82MOHOOsUV+ =r20K -----END PGP SIGNATURE----- --=_MailMate_4DE52D1B-970C-4D18-A19C-C52D463165EE_=-- From nobody Sat Feb 13 10:40:53 2016 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 913891A1A82 for ; Sat, 13 Feb 2016 10:40:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 UOLu8IFFX1FG for ; Sat, 13 Feb 2016 10:40:51 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 952631A1A7F for ; Sat, 13 Feb 2016 10:40:51 -0800 (PST) Received: from [192.168.1.87] (76-218-10-206.lightspeed.sntcca.sbcglobal.net [76.218.10.206]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id u1DIekOS030450 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Sat, 13 Feb 2016 10:40:46 -0800 To: =?UTF-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= , dane@ietf.org References: <569FC8C7.40303@gmail.com> <56B3770C.8020505@dcrocker.net> <201602051002.u15A2q0P017177@new.toad.com> <20160213014226.GP19242@mournblade.imrryr.org> <20160213043516.GQ19242@mournblade.imrryr.org> <91AC572E-B942-448F-BB17-BB31C5D13C89@frobbit.se> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <56BF78AC.2080803@dcrocker.net> Date: Sat, 13 Feb 2016 10:40:44 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <91AC572E-B942-448F-BB17-BB31C5D13C89@frobbit.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sat, 13 Feb 2016 10:40:47 -0800 (PST) Archived-At: Subject: Re: [dane] Why shut down the DANE group? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2016 18:40:52 -0000 On 2/13/2016 2:42 AM, Patrik Fältström wrote: > On 13 Feb 2016, at 5:35, Viktor Dukhovni wrote: > >> Yes, I understand that DNSSEC is at present and may indefinitely remain too high a bar. > > It is too high a bar just because this is repeated over and over again. Not because it really is. Please explain. The continuing lack of widespread adoption is only due to what? The fact that people keep saying it's too hard? It would be easy if only they would realize it? When a market is glacially slow to adopt something, it does not help much to blame the market. d/ From nobody Sat Feb 13 11:15:20 2016 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 883EF1A1BE9 for ; Sat, 13 Feb 2016 11:15:19 -0800 (PST) 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, 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 2XZHf5aAO35N for ; Sat, 13 Feb 2016 11:15:17 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C97971A1BE5 for ; Sat, 13 Feb 2016 11:15:17 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 7CA16282FB3; Sat, 13 Feb 2016 19:15:16 +0000 (UTC) Date: Sat, 13 Feb 2016 19:15:16 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20160213191516.GR19242@mournblade.imrryr.org> References: <56B3770C.8020505@dcrocker.net> <201602051002.u15A2q0P017177@new.toad.com> <20160213014226.GP19242@mournblade.imrryr.org> <20160213043516.GQ19242@mournblade.imrryr.org> <91AC572E-B942-448F-BB17-BB31C5D13C89@frobbit.se> <56BF78AC.2080803@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <56BF78AC.2080803@dcrocker.net> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [dane] Why shut down the DANE group? 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, 13 Feb 2016 19:15:19 -0000 On Sat, Feb 13, 2016 at 10:40:44AM -0800, Dave Crocker wrote: > On 2/13/2016 2:42 AM, Patrik Fältström wrote: > >On 13 Feb 2016, at 5:35, Viktor Dukhovni wrote: > > > >>Yes, I understand that DNSSEC is at present and may indefinitely remain too high a bar. > > > >It is too high a bar just because this is repeated over and over again. Not because it really is. > > > Please explain. The continuing lack of widespread adoption is only due to > what? The fact that people keep saying it's too hard? It would be easy if > only they would realize it? > > When a market is glacially slow to adopt something, it does not help much to > blame the market. Indeed, the incentives have not yet been sufficient, and might never become sufficiently compelling. There needs to be more value and fewer disincentives. I'm working on the value part by adding DANE support to Postfix and OpenSSL, and contributing to DANE support in Exim. At some point I'll look at additional open-source TLS toolkits beyond OpenSSL. I've also worked with a number of DNS providers to fix their stacks, so that TLSA record lookups don't routinely fail. The impedance is much lower now than it was in 2014. The only remaining significant clusters of problems are at mail.mil and isphuset.no. I have tickets open with both, but progress if any is glacial. Adoption of DANE TLSA for email is still low, but growing. At the MAAWG conference in October I could report ~6k domains with 24 "large enough" to also be listed in Google's email transparency report. Today it is ~11k domains, with 32 listed in Google's email transparency report. The DANE specs were released with no meaningful running code in sight, and the browsers as the aspirational initial target market. For various reasons the browsers did not turn out turn out to be a good fit at the time. So what we're seeing is a much slower ramp-up in more niche technology segments, with the protocol not yet widely supported in toolkits. So it is too early to expect broad adoption. As for DNSSEC, I've surveyed around 4.6 million (zone-apex) domains, of these, 110k have DNSSEC for both the domain and at least one best preference MX host. So it looks like: domains : dnsssec : dane ~ 400 : 10 : 1 Another data-point is that among the "large enough" domains (listed in Google's email transparency report at some point in the last couple of years) I have: domains : dnssec : dane ~ 70000 : 700 : 32 so here DNSSSEC adoption is ~1% rather than ~2.5%, and dane adoption among DANE-capable domains is 1:20 rather than 1:10. If this were steady-state, we should give up. For now, there's some room for optimism. And yes, I agree with you about not blaming the market. If we want a different result, work is required to change the incentives. -- Viktor. From nobody Sat Feb 13 16:40:15 2016 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 6B4081B35A7 for ; Sat, 13 Feb 2016 16:40:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.621 X-Spam-Level: X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, 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 zKrDmp4wedqw for ; Sat, 13 Feb 2016 16:40:13 -0800 (PST) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E5E31B35A6 for ; Sat, 13 Feb 2016 16:40:13 -0800 (PST) Received: by mail-lf0-x22a.google.com with SMTP id m1so71318576lfg.0 for ; Sat, 13 Feb 2016 16:40:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=N6nmk67kyTuB+zhAmLze3zQg+Ea1MuH4ZFYpuxFdVXM=; b=j4/79JyokbfdHT5RYTSwE95mbnmSGY4Fmf57q1eV0pSX+/NupvG2xQt/qPO/wPSIXY czgAeESaRudYHmsod6Qujfk9h7aAUKk0GgxkvUv3P+0Bi0hWZ8z3UA4336xWEIWR4Bx9 1fBodNnYIO8dn/jwQTbLAcCZIi6+8P7kRPkKt0G3ZRkzgcH2OaYfKXmDiETbfJQTN/wS WTIcT3HE5HOr29okt2orF4F5Dr+842UeptCI73Xmzk/ugDshb8nd30QyB1G30tMrrTJz R2q3x0VPaf3HXQ3pWnX0E5rjWB24/tvDvxdJdhN3SXfnq2Y+JpZ94Jfdlg5MgxkFGrjf CZJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=N6nmk67kyTuB+zhAmLze3zQg+Ea1MuH4ZFYpuxFdVXM=; b=Kd8NKfwKQxk1/ZCDNPwE6ijP2VGIUzP08zYsekSMv/r9G4Rpp6tM9y5lhp1i8tn9/V YhRZaCWah+7bkqaA4CzEhVJg7PTbBcBvPZP+0Sehjvmj4nxBTx2gXeAzaDYGK9SWZstF aYCgwjKKSoL5WrXdmZwOpQ8UEW8DHDdG9y8S1wwhNw5mc4imNA8Cpjf9Q1buEbKPwsPS QrtpwT/cP/1MTkdffL2OmJfJn0tSE/luri+Pmw0eFZAbelKjDA9ziJlX/CuPTN7ficYo Yiw12bpa7zx3Sv/dY0F+cPhp0M8UUyzztqBmDEedTpsqLNkTnpgchD6X1JwFy8c/wCoe qM1w== X-Gm-Message-State: AG10YOTQYmQO7l+ay+UJcy3PDtuje0khQGoCN/8RM0HpLddIneHRb0GSkGX2133uX+bRkomN8G0BFIPbCqQT6w== MIME-Version: 1.0 X-Received: by 10.25.205.7 with SMTP id d7mr3822939lfg.70.1455410411335; Sat, 13 Feb 2016 16:40:11 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.49.80 with HTTP; Sat, 13 Feb 2016 16:40:11 -0800 (PST) In-Reply-To: <23033B83-5182-4F6C-BCA7-E9A51A1A0D64@isoc.org> References: <569FC8C7.40303@gmail.com> <56B3770C.8020505@dcrocker.net> <201602051002.u15A2q0P017177@new.toad.com> <23033B83-5182-4F6C-BCA7-E9A51A1A0D64@isoc.org> Date: Sat, 13 Feb 2016 19:40:11 -0500 X-Google-Sender-Auth: qHNTK6S77n87BjbFRsQ-GrLyGX0 Message-ID: From: Phillip Hallam-Baker To: Dan York Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Dave Crocker , IETF DANE Mailinglist Subject: Re: [dane] Putting HPKP header into DNS - Re: Why shut down the DANE group? 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, 14 Feb 2016 00:40:14 -0000 My problem with DANE is that since it allows for Cert Validation, DNSSEC must be a MUST. Of course if you are doing HPKP in DNS, doing DNNSEC is a no brainer for the site. But from a game theory point of view, there is a big difference between 'strongly encouraged' and 'MUST'. Making the requirement for DNSSEC a 'MUST' means that DNSSEC support in the browser is a MUST. And so any attempt to use TLSA is dependent on DNSSEC deployment having been achieved. HPKP in DNS can be rolled out today. Rolling out HPKP highlights the failure of the browser providers to fully lock the system down with DNSSEC. The objective here is to get the camel's nose inside the tent. From nobody Sun Feb 14 03:32:35 2016 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 25E301B3D52 for ; Sun, 14 Feb 2016 03:32:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.108 X-Spam-Level: X-Spam-Status: No, score=-0.108 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.006, 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 2F4fcaeAcBep for ; Sun, 14 Feb 2016 03:32:33 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 1C49C1B3D54 for ; Sun, 14 Feb 2016 03:32:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1455449552; d=isode.com; s=selector; i=@isode.com; bh=avLiMeCW9YZFEk/BiB79MtjN1u8jTlhlPeUcFoHrsn4=; 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=ubMmmLY1NJt7KbLSBElWjSy/mF7DWxjV6reGL3nHyk70no/fXN/mZMoZPZ+2pqmHuWxkDC im5ueyUtguzmhaCOGXEEAorHzBiOW8A1Ds1BtWfJgx9tR7WtCUzbNX9q3Glajy6RnAfEgW Hhcbfx8e4RMeHb57jMtQy0FglFl6yEk=; Received: from [192.168.0.6] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Sun, 14 Feb 2016 11:32:32 +0000 X-SMTP-Protocol-Errors: PIPELINING From: Alexey Melnikov X-Mailer: iPad Mail (13D15) In-Reply-To: Date: Sun, 14 Feb 2016 11:37:12 +0000 Message-Id: <5A970808-A162-43D1-B1E4-54BB9EE8B1A5@isode.com> References: <20160204230640.69198.qmail@ary.lan> To: John R Levine MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "" Subject: Re: [dane] Meeting plans for Buenos Aires? 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, 14 Feb 2016 11:32:34 -0000 On 5 Feb 2016, at 01:53, John R Levine wrote: >> Thanks for the suggestion! I'd prefer to try to recharter the current gro= up >> with any new work items first, before this more drastic option. But glanc= ing >> at the current charter just now, it might already cover some of the work >> that I outlined earlier. >=20 > If you have a clear, well focused list of things to do, you'll probably fi= nd that setting up a new WG is easier than rechartering. In my experince: It depends. Either they are about the same amount of work o= r rechartering is slightly easier, unless ADs have a desire to shutdown the W= G. > It certainly comes with less baggage. True. From nobody Sun Feb 14 17:56:30 2016 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 C38B41A1A10 for ; Sun, 14 Feb 2016 17:56:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 XrTPscPMY50P for ; Sun, 14 Feb 2016 17:56:27 -0800 (PST) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09D6E1A21B4 for ; Sun, 14 Feb 2016 17:56:27 -0800 (PST) Received: by mail-ig0-x234.google.com with SMTP id xg9so43035075igb.1 for ; Sun, 14 Feb 2016 17:56:27 -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=Ez3ftLBKnRp8WP7Vs1QopMRXjR97DITDYXz0PfzRKJE=; b=Q7UwEZadmZB139z4mV/lfVt5aSZDIID3DzXN+ouBBiTMET0XmzPJZoRr/Ow0aeump3 y0bJvPNnkU6LT7ihp/hPc2A35Rf4KGxXRFCbkOAMTqCsL/1o3IXiNL4gOwV/xPV5xVu8 HLfn0v35SRYJsby3YdQO5RcOTuYF9hkPm+MA7/K93rndtUB7VRP9qR6VhWqyvG6Y3l92 ER+wcDhpi2JoaPbWBzs+crf3c2jhJqfoOKXEhjkIdYHQMK/KNaBtCO1B3/VGCQ4xXumn g3t5vZ6/CV9iEvzpxn9veXNmc79g7ai3Pi8oQBhFFlNHGsHc3hmUaK1r7Gkzm6YG407V ds6g== 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=Ez3ftLBKnRp8WP7Vs1QopMRXjR97DITDYXz0PfzRKJE=; b=lMBCxWgZP1AQWb0XUqPFU7d9b0v2g8uxxeVeuo/DTiCd8wfFiDLNpBqaQQbm9xEr6E Je5wF82UGTwQPp5mh2UJjkAequLEilbffqie+uc/1kV4cYfNPTzublM08SJCFictkSF2 IVYQ0dbvDJxZx+kX0APu+nzI4UNsBE8Q6wygQuGWVRzQaPFNHJbOjPfH17rYHcrg8GU1 dHqXwvl8WMpzBN4fw8nb2kdnJyILVCa0ssBuiGyQQAWtFadiF8BgcYX2tffA/JwLaM4h aH5jQB2rWbpfIeQYd8o3clyfjoiosaWyrvdyvBz4NLHySTbkrSCIiNhlGOqGALxP0jsy WaaA== X-Gm-Message-State: AG10YOSErL9M5C3oyWnz4Kt5W0rYnt/t6GQETpi8jYiKiqlz5xlPgEDRtwZ7NOkRK8AHqe4hRWhfY2Fl4YcJoQ== MIME-Version: 1.0 X-Received: by 10.50.20.73 with SMTP id l9mr10189061ige.58.1455501386358; Sun, 14 Feb 2016 17:56:26 -0800 (PST) Received: by 10.36.53.79 with HTTP; Sun, 14 Feb 2016 17:56:26 -0800 (PST) In-Reply-To: References: <569FC8C7.40303@gmail.com> <56B3770C.8020505@dcrocker.net> <201602051002.u15A2q0P017177@new.toad.com> <23033B83-5182-4F6C-BCA7-E9A51A1A0D64@isoc.org> Date: Mon, 15 Feb 2016 12:56:26 +1100 Message-ID: From: Martin Thomson To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Dave Crocker , IETF DANE Mailinglist Subject: Re: [dane] Putting HPKP header into DNS - Re: Why shut down the DANE group? 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, 15 Feb 2016 01:56:28 -0000 On 14 February 2016 at 11:40, Phillip Hallam-Baker wrote: > HPKP in DNS can be rolled out today. Maybe I'm just dim today, but doesn't that suffer from the same problem as TLSA? HPKP in HTTPS relies on HTTPS providing integrity. Don't you need DNSSEC to get the same result for DNS? From nobody Mon Feb 15 05:40:41 2016 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 1B3B71B33A6 for ; Mon, 15 Feb 2016 05:40:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, 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 LfQNXaJoQg0x for ; Mon, 15 Feb 2016 05:40:38 -0800 (PST) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 755181B33A4 for ; Mon, 15 Feb 2016 05:40:38 -0800 (PST) Received: by mail-lb0-x235.google.com with SMTP id ut4so2552030lbc.1 for ; Mon, 15 Feb 2016 05:40:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=4PsMNDguN6x568HO2sdu3e8pbmRCYEw+TVnW0/dzdT8=; b=Ce2jV4BO4V9R75ogyyb7vqO44eXaeCJiduoUAfKkCoBjnYg9sgzp3L0MpMnvoHGFBy YbNndSC5U4R63LuuhatE0dunOuu5gSYGti5Bjg8IjxH2u5mGI7CklH8pfXErUZDzFqXs lt+vBO1euMc1XmXYphb5m6pZJ52K0R/ZX41lINsXjLzrroc90PqaVYLnAYclCnJ4ylYR 81BSU6efH7P3xsA4/XDHNI+pTQkHn9aTOJYl/86w2EIQdOuD2LDBvld7GyaT7N1qAhPq Ltz/qzjglZ77ElnpfmmRMkOwcu0Jf7NMIvIQ6BIsmutrkFBNW51CXN1PBw9/SgyZkfHc V/OQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4PsMNDguN6x568HO2sdu3e8pbmRCYEw+TVnW0/dzdT8=; b=SfysXJ3jtQiU21BwXZ7bn3x57upA3UGg+xC3/jcKwKlktrhGkoXvrDGJGW2Aso1Dtg ngXlXTXpuu6ynvdAeQ0Uw5hr4uhicw4vTkEYKZ3uCUSYBSEQYfGLCZGWavjFm2CePjb0 7alIEcgO6rUk8H6MFb9OTTH6mlZ7EajYtLs4XCM9Kyc4vDrC0NS6z4VkX1IWtkENjlES cIh3iDZ4wazv7OFOoffR0JOG1RnKFFssab8o88aIzuQAYMAf9bzCYlv00f5MJanQznRJ 0ceNkFRuZLLOlpxgZ1bxorPipF27HvG6sX3xgMwJgYJN6jpTAOyOsEM9Vj1q9+ZXcbo5 Wj+Q== X-Gm-Message-State: AG10YOQPnmgxr7+LmEGj2dFFRyIEB7YltG33bSm9h0KNVnU0HvYyraHB3M622Ma8KalIdDLmCESuSA3GLJgjTg== MIME-Version: 1.0 X-Received: by 10.112.91.202 with SMTP id cg10mr6814574lbb.142.1455543636731; Mon, 15 Feb 2016 05:40:36 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.49.80 with HTTP; Mon, 15 Feb 2016 05:40:36 -0800 (PST) In-Reply-To: References: <569FC8C7.40303@gmail.com> <56B3770C.8020505@dcrocker.net> <201602051002.u15A2q0P017177@new.toad.com> <23033B83-5182-4F6C-BCA7-E9A51A1A0D64@isoc.org> Date: Mon, 15 Feb 2016 08:40:36 -0500 X-Google-Sender-Auth: djw8gbTxafYMg7363AkywoJXYD0 Message-ID: From: Phillip Hallam-Baker To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Dave Crocker , IETF DANE Mailinglist Subject: Re: [dane] Putting HPKP header into DNS - Re: Why shut down the DANE group? 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, 15 Feb 2016 13:40:40 -0000 On Sun, Feb 14, 2016 at 8:56 PM, Martin Thomson wrote: > On 14 February 2016 at 11:40, Phillip Hallam-Baker > wrote: >> HPKP in DNS can be rolled out today. > > > Maybe I'm just dim today, but doesn't that suffer from the same > problem as TLSA? HPKP in HTTPS relies on HTTPS providing integrity. > Don't you need DNSSEC to get the same result for DNS? You only need authentication if you are going to store the information for longer than the DNS TTL or use it in place of an authenticated key pin. Otherwise, a false D-HPKP signal is just a Denial of Service vector which is already trivial for someone who controls DNS. Obviously there is an advantage to deployment of DNSSEC, as follows: 1) For browser providers as a means of improving D-HPKP security policy once there is an established base for D-HPKP. 2) Once there is a deployment of DNSSEC in a browser, there is an incentive for sites with D-HPKP to deploy DNSSEC. DANE requires both sides to anticipate support by the other. It is a deployment deadlock. There is no advantage to deployment by sites without support in the browser. The browser providers have stated they don't see the point of DNSSEC to secure A/AAAA records (and they are right). TLSA deployment is negligible, less than 1000 domains and 7-13% of those are wrong. https://www.isi.edu/~johnh/PAPERS/Zhu15a.pdf The other deployment pathology that DANE suffers from is that the companies that help most enterprises manage their DNS records are DNS registrars. These companies typically have a business model of selling the DNS record at or below cost and making the difference up with value added services, chiefly SSL certificates. Now without laboring the point, just how did you expect to deploy a new protocol when you were openly boasting about how it was going to eliminate the principal source of revenue for the party you need support from? This was an experiment. It has failed. Now if you really want to solve the problem, how about people let me have a go at doing it the way I suggested in the first place. From nobody Mon Feb 15 10:30:35 2016 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 31E961ACD84 for ; Mon, 15 Feb 2016 10:30:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 1P2cnKGT4WwX for ; Mon, 15 Feb 2016 10:30:29 -0800 (PST) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60E141ACD83 for ; Mon, 15 Feb 2016 10:30:29 -0800 (PST) Received: by mail-yw0-x22b.google.com with SMTP id e63so26019501ywc.3 for ; Mon, 15 Feb 2016 10:30:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=M3j2B9ZEeOSjbYvbCfJjJ41sxQHfcP31uVAaFj0fPUs=; b=pBP1oxnNUPe03OYkjrXcmzGFwhQFsQHi54Hi5uysOt8yeLvMZeG0aTZWm96xPlUKcI p0+1/l7fIkEkuWFO0nUI8bmWovdCZ1hvhEQrKyJJzBLbXZ/B5NV8CD6TJhBe5z3E/K4w ez9+3t9xF0aXUtrfVB/6c28gAKqJ4MMUZf9x/YQmQW1M8eLyE54i9+aZgzz4BJe5Q6x9 eh5vU7FsLNfP5QH7iWhRF/9BXlt1weIANZrWMejr5r6loDEgP1W12uWZ5vNr+Gje25Ts L6so7SmzsWn1Mj2Lz4y3+VLLkKW1lXYqO1LmDdNyv7FJcIgaCW14/pxigbRJtk/GTVhE Hrow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=M3j2B9ZEeOSjbYvbCfJjJ41sxQHfcP31uVAaFj0fPUs=; b=HlctB+ROYV4AjHIz6gBA8xgRbMFpWqGDkPeQkibBPdM+FD5KV5atGC3K7FpnDz70+6 X/yQ95iMAsNjMHBqWxgF+cwwpAGqRJBTeU2QfZNAk8RK4znwRzpGI+uzXpoqpzyIHuWN 3JUJW3uraJ2Y5kIG6nF3sxoci2jZYgF66YESf+3gjq12WnC2BXizJYJvUMLmz+hmlumh i1jiRrGB2pDzVQR2Anrao2HCtprmMyuHGWPCni7MRg2LBn5roSxI8jFHtniWtxVDpxaK x4jGfVJbr1DbF1d+R1c/t4KnDc2heHSt6PkAUobcl3a5vf7LyLFruLYf6USUbW8yDNrP PPGw== X-Gm-Message-State: AG10YORInxzZ6U7r9bYXikVknvrJ0XzBOM34O4BvJrGbGNTb6+yNWFkkGZRoAiCEe3RTVHKMxYy4e0MQPouX/QQ1 X-Received: by 10.129.119.10 with SMTP id s10mr10773133ywc.127.1455561028672; Mon, 15 Feb 2016 10:30:28 -0800 (PST) MIME-Version: 1.0 References: <20160204230640.69198.qmail@ary.lan> <5A970808-A162-43D1-B1E4-54BB9EE8B1A5@isode.com> In-Reply-To: <5A970808-A162-43D1-B1E4-54BB9EE8B1A5@isode.com> From: Warren Kumari Date: Mon, 15 Feb 2016 18:30:19 +0000 Message-ID: To: Alexey Melnikov , John R Levine Content-Type: multipart/alternative; boundary=001a1141c836104ec5052bd336b3 Archived-At: Cc: "" Subject: Re: [dane] Meeting plans for Buenos Aires? 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, 15 Feb 2016 18:30:31 -0000 --001a1141c836104ec5052bd336b3 Content-Type: text/plain; charset=UTF-8 On Sun, Feb 14, 2016 at 6:32 AM Alexey Melnikov wrote: > > On 5 Feb 2016, at 01:53, John R Levine wrote: > > >> Thanks for the suggestion! I'd prefer to try to recharter the current > group > >> with any new work items first, before this more drastic option. But > glancing > >> at the current charter just now, it might already cover some of the work > >> that I outlined earlier. > > > > If you have a clear, well focused list of things to do, you'll probably > find that setting up a new WG is easier than rechartering. > > In my experince: It depends. Either they are about the same amount of work > or rechartering is slightly easier, unless ADs have a desire to shutdown > the WG. > Yes, it depends -- on many things. These include how large of a change to the charter is proposed, how similar a new WG would be, what the WG wants to do, how the WG has been performing until this point, how receptive the ADs are, recent history and the phase of the moon. Without seeing specific documents / proposed charter text it is really hard to know if it is something that this WG should do. We (Ondrej and I) specifically added: "When work on currently chartered documents is complete the WG may re-charter if sufficiently pressing new work is identified. DANE is not intended to be a long-lived catch-all WG for all public key distribution in DNS issues and so will generally not adopt new work items without re-chartering." because we didn't want to just limp along, staying alive just to stay alive. Olafur and I proposed wrapping things up largely because we hadn't seen a large amount of concrete proposed work, and reviews on existing work were getting harder / it was the same set of voices[0]. Again, we are happy that people want to get work done, and we are happy to adopt new work, recharter if needed, whatever -- but this requires everyone (yes, including the chairs!) doing their bit -- for example, there has been very little discussion on draft-huque-dane-client-cert, and much of what discussion there has been is on the prefix / label. Please, can folk review the content of the document for other issues? Also, we have heard that people would like to get new work going - it is getting close to BA, so if you have work, we'd like to see some documents so that we can discuss them, please request meeting time, etc. > > It certainly comes with less baggage. > > True. > > Indeed. W > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > --001a1141c836104ec5052bd336b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Feb 14= , 2016 at 6:32 AM Alexey Melnikov <alexey.melnikov@isode.com> wrote:

On 5 Feb 2016, at 01:53, John R Levine <johnl@taugh.com> wrote:

>> Thanks for the suggestion! I'd prefer to try to recharter the = current group
>> with any new work items first, before this more drastic option. Bu= t glancing
>> at the current charter just now, it might already cover some of th= e work
>> that I outlined earlier.
>
> If you have a clear, well focused list of things to do, you'll pro= bably find that setting up a new WG is easier than rechartering.

In my experince: It depends. Either they are about the same amount of work = or rechartering is slightly easier, unless ADs have a desire to shutdown th= e WG.

Yes, =C2=A0it depends -- on many things. = These include how large of a change to the charter is proposed, how similar= a new WG would be, what the WG wants to do, how the WG has been performing= until this point, how receptive the ADs are, recent history and the phase = of the moon.
=C2=A0
Without seeing specific documents /= proposed charter text it is really hard to know if it is something that th= is WG should do.
We (Ondrej and I) specifically added:
=
"When work on currently chartered documents is complete the WG
may re-charter if sufficiently pressing new work is identified.

DANE is not intended to be a long-lived catch-all WG = for all
public key distribution in DNS issues and so will general= ly not
adopt new work items without re-chartering." because = we didn't want to just limp along, staying alive just to stay alive.
Olafur and I proposed wrapping things up largely because we hadn= 9;t seen a large amount of concrete proposed work, and reviews on existing = work were getting harder / it was the same set of voices[0]. Again, we are = happy that people want to get work done, and we are happy to adopt new work= , recharter if needed, whatever -- but this requires everyone (yes, includi= ng the chairs!) doing their bit -- for example, there has been very little = discussion on=C2=A0draft-huque-dane-client-cert, and much of what discussio= n there has been is on the prefix / label. Please, can folk review the cont= ent of the document for other issues?
Also, we have heard t= hat people would like to get new work going - it is getting close to BA, so= if you have work, we'd like to see some documents so that we can discu= ss them, please request meeting time, etc.


> It certainly comes with less baggage.

True.


Indeed.

W
=C2=A0

_______________________________________________
dane mailing list
dane@ietf.org
https://www.ietf.org/mailman/listinfo/dane
--001a1141c836104ec5052bd336b3-- From nobody Mon Feb 15 12:15:18 2016 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 6B45F1AD259 for ; Mon, 15 Feb 2016 12:15:16 -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, 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 F7T27GfviWSH for ; Mon, 15 Feb 2016 12:15:15 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BF751AD255 for ; Mon, 15 Feb 2016 12:15:14 -0800 (PST) Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id A74D4282F4E for ; Mon, 15 Feb 2016 20:15:13 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Viktor Dukhovni In-Reply-To: Date: Mon, 15 Feb 2016 15:15:13 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <43F54AEB-8574-4972-A849-AB533348E6C3@dukhovni.org> References: <569FC8C7.40303@gmail.com> <56B3770C.8020505@dcrocker.net> <201602051002.u15A2q0P017177@new.toad.com> <23033B83-5182-4F6C-BCA7-E9A51A1A0D64@isoc.org> To: dane@ietf.org X-Mailer: Apple Mail (2.3112) Archived-At: Subject: Re: [dane] Putting HPKP header into DNS - Re: Why shut down the DANE group? 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, 15 Feb 2016 20:15:16 -0000 > On Feb 15, 2016, at 8:40 AM, Phillip Hallam-Baker = wrote: >=20 > TLSA deployment is negligible, less than 1000 domains and > 7-13% of those are wrong. Not surprising. For HTTPS, if nobody is checking, why should they be = right! With SMTP, out of 11k tested domains ~30 (0.3%) are wrong. TLSA records = are only kept right if there's an operational impact when they're wrong. The error rate for SMTP will drop as more sending systems enable = outbound checks. --=20 Viktor. From nobody Mon Feb 15 13:41:48 2016 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 68B001A9087 for ; Mon, 15 Feb 2016 13:41:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, 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 aCMVJSQIQkSC for ; Mon, 15 Feb 2016 13:41:46 -0800 (PST) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FC2A1A1B81 for ; Mon, 15 Feb 2016 13:41:46 -0800 (PST) Received: by mail-lb0-x234.google.com with SMTP id ut4so9262664lbc.1 for ; Mon, 15 Feb 2016 13:41:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=W+CwNENklZM8k/J6BFdBG72VKN+LELoETb9KCOi4AGU=; b=m6wlDsfOko/BsWEb+2jU2tSJ9fL1g9fxE9KI6u9zXApsBCRv7h7oDFpjerypQCnQ4k SSIqaXMdrnHM7IYXXOlVtqB0Q2Szjt81D1uaoi9eFuBMjUOf6heCufu2UwEMPRcCTMns d7T15MWyUw4kAb1fL4UBZssAopF0+4cZDvTE5g1CXqk0Rz7rwCQ7LdCaiTlI+wauAQQG GfZ0Bq/XDRRy0oKWb1KGGr2UPYMB4M1tMPhIFiA+R1ZDP5jCtF6XXPaylYGvIuCY6tzK HSoyLwUFRNDrOXbOgoifBgfPZuITJlF/OakNUVzEDzi++0HLleKxNSuoT29BgyOGLXAr 3Bxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=W+CwNENklZM8k/J6BFdBG72VKN+LELoETb9KCOi4AGU=; b=hHzYC05DVBVqBTqoe2qyw1u5yPY1etNEBSwhhV8jc66yie9709ip2KoEPfEw+A3Rep w/yJpnbr4CiJbhlcg/qQdkrkty16zjirWn2MixNrlvuElT4WDlIhJNodRjVQ8EFLqI5D Zh5gUNAgWi6i4UZJqsJFrUPG2nftxPnxw4KlGomLcqdoA+B/y8fCj9uupRHvRpyZYtyZ COCIUSQrobDlaQ10pJ933ZlPZ0TcljvXEyh5mKV58ZQKlvQSAJVkCWVkzBXc+bfDju9a VlZEBWKIeB3m03IXLLkzpdZf5lGrr4fA+zUB5YdJlUlNdBAf1mtXH17nVThIdxvUzR1s aLkw== X-Gm-Message-State: AG10YOSnNtBH5nrIGUSigQVec5s/LlcQRrrfRfOq15HO4DoJeP9j4BiledFse/lZVwmowoV3VP8Wb1UiuXMNag== MIME-Version: 1.0 X-Received: by 10.112.199.197 with SMTP id jm5mr6359682lbc.109.1455572504224; Mon, 15 Feb 2016 13:41:44 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.49.80 with HTTP; Mon, 15 Feb 2016 13:41:44 -0800 (PST) In-Reply-To: <43F54AEB-8574-4972-A849-AB533348E6C3@dukhovni.org> References: <569FC8C7.40303@gmail.com> <56B3770C.8020505@dcrocker.net> <201602051002.u15A2q0P017177@new.toad.com> <23033B83-5182-4F6C-BCA7-E9A51A1A0D64@isoc.org> <43F54AEB-8574-4972-A849-AB533348E6C3@dukhovni.org> Date: Mon, 15 Feb 2016 16:41:44 -0500 X-Google-Sender-Auth: 8W9Dn_gJZN2YNdeGfld2DKrULHI Message-ID: From: Phillip Hallam-Baker To: "dane@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [dane] Putting HPKP header into DNS - Re: Why shut down the DANE group? 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, 15 Feb 2016 21:41:47 -0000 On Mon, Feb 15, 2016 at 3:15 PM, Viktor Dukhovni wrote: > >> On Feb 15, 2016, at 8:40 AM, Phillip Hallam-Baker wrote: >> >> TLSA deployment is negligible, less than 1000 domains and >> 7-13% of those are wrong. > > Not surprising. For HTTPS, if nobody is checking, why should they be right! > > With SMTP, out of 11k tested domains ~30 (0.3%) are wrong. TLSA records are only > kept right if there's an operational impact when they're wrong. > > The error rate for SMTP will drop as more sending systems enable outbound checks. That is a predictable consequence from combining the key publication mechanism and the security policy mechanism. People create keys in advance of actually using them. This is why I proposed separating the two systems. To validate a cert one would use .example.com TLSB Perhaps if some people had been less willing to dismiss any contribution from people in the PKI industry as antithetical to the purposes of the WG, this situation might have been avoided. That is all water under the bridge now of course. I will write a draft proposing my way to do it. Perhaps people could do me the favor of thinking twice before complaining that it treads on DANE scope. From nobody Wed Feb 24 12:15:20 2016 Return-Path: X-Original-To: dane@ietf.org Delivered-To: dane@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D26331B3369; Wed, 24 Feb 2016 12:15:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160224201516.10813.94385.idtracker@ietfa.amsl.com> Date: Wed, 24 Feb 2016 12:15:16 -0800 Archived-At: Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-smime-10.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 20:15:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS-based Authentication of Named Entities of the IETF. Title : Using Secure DNS to Associate Certificates with Domain Names For S/MIME Authors : Paul Hoffman Jakob Schlyter Filename : draft-ietf-dane-smime-10.txt Pages : 6 Date : 2016-02-24 Abstract: This document describes how to use secure DNS to associate an S/MIME user's certificate with the intended domain name, similar to the way that DANE (RFC 6698) does for TLS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-smime/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dane-smime-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dane-smime-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Feb 28 16:31:13 2016 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 207F71ACEBD for ; Sun, 28 Feb 2016 16:31:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.423 X-Spam-Level: * X-Spam-Status: No, score=1.423 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 ySvfgLkC7-NR for ; Sun, 28 Feb 2016 16:31:11 -0800 (PST) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3EAB1ACEBB for ; Sun, 28 Feb 2016 16:31:10 -0800 (PST) Received: by mail-yk0-x232.google.com with SMTP id r207so57076155ykd.2 for ; Sun, 28 Feb 2016 16:31:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=ot5oLUcY2rwuuoaocQTe2Oz03TOG4wNPNhO1+PcpvcU=; b=eNvRaa19Cbw9coaNOthrL36OQHyROoujNDAaw6K/pM2V8lj/4ukAAl6uhZMMsA87Pc Ep/8iZ4SrYBDpHo3HXmQJEZ+LAYX6o9hRvBtr5vQtyF70vKQVJUMSkVzkEDiaUnGWdcY /8peZtJyWoy0JsCp91wPD7wLryImw18pdvMAIuKcJyCUCgdpNP8V2Gd7G8enmx7F5QXF RoYsyUigGUSFfjrg8c6UpHUq5THg+539RivHgiMGXU+33/tMs1zvBbjIgBVa67xp9lVq CH4Wj3bzDnIGK+QSUo2utYuto3eakxS+XNzkR1cSEg4kccwJIvJXSrDGwbcQTT3s4PzD KGiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=ot5oLUcY2rwuuoaocQTe2Oz03TOG4wNPNhO1+PcpvcU=; b=PqURB0t3oPIS/0eBabaKtTa5fYOKnVg7hmvsUFp36Kj8sSZyzQSDo6covTUI1UN5js 6AFaNROveEN0TOZf88oi6VPb+zslG7CtvGEryE0z5W93Yt+yraArtILcdxlfhbCwf380 XjkmdLjJg9KHgcoE2yK8NY0EN5GT0KnmcgHcXWlXsYWH5hWsa66rk8kmucwdjF+ZykA0 vYf7RtXRm9D519+4KS1qBuz9VrK/fA9QwNfzuEQxOeRYVt6CFlfibWJujcDEyho4yC0X s1B4axXN0yLJWSDqNEX3Swem0ZJZe7ls48D7NiWslbzkCoqg6GTKxJW/1VM6R4kKn8ZG 6e0w== X-Gm-Message-State: AD7BkJLX1B+CZRnMDt2b7b4wpYTTsyIkm4pIG5ZOyFhhbvjA3CVgbRJ2FiSfmL747lOEMAYd/oTV5rZ3GBCfQPvI X-Received: by 10.37.56.85 with SMTP id f82mr2380753yba.77.1456705870182; Sun, 28 Feb 2016 16:31:10 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Warren Kumari Date: Mon, 29 Feb 2016 00:31:00 +0000 Message-ID: To: "" Content-Type: multipart/alternative; boundary=94eb2c09e1f6ef6be2052cddc312 Archived-At: Subject: Re: [dane] DANE meeting at IETF95 in BA 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, 29 Feb 2016 00:31:12 -0000 --94eb2c09e1f6ef6be2052cddc312 Content-Type: text/plain; charset=UTF-8 A reminder - y'all told us that you want DANE to meet in BA, and that there is still much work to be done (yay!), but we have not seen any requests, or recent, promised documents / updates (boo!) W On Fri, Feb 12, 2016 at 6:02 PM Warren Kumari wrote: > Hi all, > > We are glad to see all of the enthusiasm and desire to get more work > done[0] in response to our "Are we done here?" email. > > We've requested a meeting slow in Buenos Aires, and would like to have a > productive meeting - as always we will be giving meeting time to documents > which have open issues which are best discussed in person, then to > documents which have had lots of discussion. Because we are also discussing > new work we may also give time to new documents / ideas. > > So, if you would like some agenda time, please send mail to dane-chairs. > > > Thank you, > Olafur and Warren > > [0]: Huh, almost like we planned that.... ;-P > --94eb2c09e1f6ef6be2052cddc312 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
A reminder - y'all told us that you want DANE to meet = in BA, and that there is still much work to be done (yay!), but we have not= seen any requests, or recent, promised documents / updates (boo!)

=
W

On Fri, Feb= 12, 2016 at 6:02 PM Warren Kumari <warren@kumari.net> wrote:
<= div dir=3D"ltr">
Hi all,

We are glad to see all of the enthusias= m and desire to get more work done[0] in response to our "Are we done = here?" email.
We've requeste= d a meeting slow in Buenos Aires, and would like to have a productive meeti= ng - as always we will be giving meeting time to documents which have open = issues which are best discussed in person, then to documents which have had= lots of discussion. Because we are also discussing new work we may also gi= ve time to new documents / ideas.

So,= if you would like some agenda time, please send mail to dane-chairs.
=


Thank you,
Olafur and Warren

[0]: Huh, al= most like we planned that.... ;-P
--94eb2c09e1f6ef6be2052cddc312--