Newsletter

Once I started to look at security policy publication, = I realized that the discovery signaling problem is solved almost for free.<= /div>

So the starting point is the need t= o express policy of the form 'always use TLS' in the DNS. Which is = what I propose with ESRV:

_imap._tcp.example.com =A0 ESRV "tls=3Drequired"

_http._= tcp.example.com =A0 ESRV "tls= =3Drequired"

[From this starting point we could easil= y elaborate the scheme to require specific trust roots for use of TLS or IP= SEC or whatever. But that is actually a somewhat subtle and involved proble= m I would like to defer for now.]

Now due to the problem with CNAME, it is highly desirab= le that the resolution process for ERSV (or any other policy record) is inc= remental and starts at the unprefixed zone. So the first lookup would be fo= r an ESRV record for unprefixed example.com<= /a>:

example.com =A0ESRV = "tls=3Drequired match=3D_http._tcp, _imap._tcp"

www.example.com CNAME example.com

Which should deliver the relevant policy records in a s= ingle lookup for either example.com or w= ww. example.com.=A0

What does become rather clear is that the original attempt t= o avoid the need for an SRV registry by re-using the protocol names registr= y in a horrible kludged fashion was a big mistake. I think we should seriou= sly consider starting the use of prefixes from scratch and abandon the tcp/= udp layer.

Now once you have a lookup that is allow= ing security policy to be distributed, it can be used to publish other info= rmation. For example it could tell the client that it can use SRV or NAPTR = or URI for enhanced discovery.

example.com =A0ESRV = "prefix=3D_http._tcp,_imap._tcp"

_http._tcp.example.com ESRV "tls=3Drequired disc=3Dsr= v"

_http._tcp.example.com SRV 1 1 = 80 site1.example.com

_ht= tp._tcp.example.com SRV 1 1 80 site2.example.com

I have an initial draft out, but I am still working on = the details. The practical significance of this is that it is not necessary= for the use of the URI scheme to be hardwired into the application protoco= l as Patrik states.=A0

I think that it is in fact practical to use a mechanism= such as ESRV to retrofit a new discovery mechanism to existing protocols.<= /div>

One real concrete benefit of this i= s that we establish a space in which we can develop rather more interesting= discovery mechanisms that make use of geographic location or account data = to optimize discovery.=A0

At the moment when I connect to gmail via POP3, I guess= my client must be connecting me to a tier 1 server whose only reason for e= xistence is the need to route my request to the place where the data is act= ually stored. Wouldn't it be nice if we could possibly eliminate that t= ier at a future date? Think of the carbon emissions we could save.=A0

Sure there are performance issues to cle= ar. But I think those can be managed. The important thing here is to get th= e architecture right so that applications have the right information to wor= k with and get the most efficient transport layer possible. We can work out= how to save DNS round trips as a lower priority.

2010/10/11 Patrik F=E4lt= str=F6m <paf@cisco.co= m>

On 27 jul 2010, at 20.48, Ted Hardie wrote:

> At the moment, the draft

> describes a mechanism that
> relies on two associated things: =A0a composed service name and an RR = with format:
>
> Ownername TTL Class URI Priority Weight Target
>
> One composed service name example you give is
>
> $ORIGIN example.com.
> =A0 _http._web =A0 =A0IN URI 10 1 "http://www.example.com/"
>
> That is, someone looks up _http._web.example.com and discovers
> this URI there. =A0The first issue is the one draft notes, that you > must know in advance to check for this in order to populate
> the fields correctly.

Correct.

> For your "two domains, one homepage"
> example, the querier must know in advance, in other words,
> to check for the _http._web.example.net in order to
> discover that there is another domain. =A0That's not going
> to happen as an adjunct for standard web queries without
> a lot of other work, so it really relies on some application
> that wants that bit of data (as opposed to just wanting
> the home page).

That is correct. The use of the URI RR Type will only happen in new p= rotocols, or new use. I do not think it will be used for existing protocols= , like HTTP, or other protocols where you have inbound "redirect"= functionality.

> It's okay that it is only useful to applications that
> already know they want it, but, unfortunately,
> it's also not really enough. =A0_http._web is a very general
> service name, and there is no way with that level of
> granularity to know whether the URI you're getting
> is meant to be an equivalent, an alternate, or to
> stand in some other relationship (e.g. hold meta data).

Correct, and that is why the actual service type registrations must b= e more precise. What I have in the draft (draft-faltstrom-uri-05) is the fo= llowing:

> =A0 =A0Valid service
> =A0 =A0parameters used are those used for SRV resource records, or
> =A0 =A0registered by IANA for Enumservice Registrations.

What you say, which I agree with, is that "just" use of some pref= ixes without having them defined is dangerous. And this is why I am leaning= towards either the Enumservice Registrations (where you have this issue) o= r the SRV resource records that according to the SRV spec is requiring furt= her specification in its applicability statement:

> =A0 =A0In general, it is expected that SRV records will be used by cli= ents
> =A0 =A0for applications where the relevant protocol specification indi= cates
> =A0 =A0that clients should use the SRV record. Such specification MUST=
> =A0 =A0define the symbolic name to be used in the Service field of the= SRV
> =A0 =A0record as described below. It also MUST include security
> =A0 =A0considerations. Service SRV records SHOULD NOT be used in the a= bsence
> =A0 =A0of such specification.

Now, I do not see as much of a problem as you do, as whoever that is using = the URI know already what it is after. It can either (as today) use a URI d= irectly for the communication, or start by using a hostname, look up a URI = RR and get back the URI to use.

What I think you are after is in the case we have the following scenario:
1. The owner of a domain is publishing a URI RR for a specific service name= d foo, so the URI RR _foo._tcp.example. is provisioned.
2. The service name is overloaded, for not only what the owner of the name = was thinking of, but also bar.
3. Someone that want to use the service bar, for the domain name example is= also looking up _foo._tcp.example, get back the URI that was to be used fo= r the foo service, and the application is at best "surprised".
Here "foo" can be for example "web surfing" while "= ;bar" can be for example calendaring that also uses the HTTP protocol.=

In this case, the service "bar" should use a specific scheme, for= example _bar._tcp.example.

And we once again hit a problem I do not think is "my" fault, but= rather that we do not have a proper registry for service types. As you can= see already there in the SRV spec.

Yes, I was Area Director for apps area then, and did rise exactly this issu= e ;-)

> Each pairing of composed service name and URI
> has to have some semantic that tells you what the
> URI has to do with the related service name.

Agree, and my view is that that should be made in the service name (i= .e. in the owner of the RR) and not anywhere in the resulting URI.

Note that the service in the owner is not an encoding of the uri scheme. It= is really a service definition/name. Many different such names can result = in a URI using the HTTP scheme.

> If I create a URI record at =A0_dns._udp.example.net
> with a target of dns:example.org.?clAsS=3DIN;tYpE=3DCNAME
> am I reporting the CNAMES which point to example.net?
> Or am I telling you that example.net is authoritative for
> the domain name that is the result of that query?
> The service name and URI pointer aren't really enough
> to know.

I do not know what the spec of the dns service type says. Does one ex= ist? I know there is a dns URI scheme.

As you can see in RFC 4501 (from which I see you have grabbed this example = ;-) ), the URI is for a resource record with the absolute name example.org, class IN and type CNA= ME. So a spec of the dns service must tell how to handle this case. I think= your example is one where there must be subtypes. For example:

_cname._in._dns._udp.e= xample.net. IN URI 10 10 "dns:example.org.?clAsS=3DIN;tYpE=3DCNAME= "

> You touch on this in the draft by noting that the service
> name usage may be subtly different for each RR that uses,
> but I think the situation is far more complicated than that.
> URIs are inherently sub-typable (by scheme, query, etc.),
> and that means that the semantics here seem to me to
> need a much richer description capability than the draft
> assumes.

Hmm...I think a lot of work is needed for each service type.

> I'm not sure that this explanation is all that much better,
> so feel free to batter away at the results.

I think you talk about more how the registration and spec of each ser= vice type is done, and not this spec. But maybe you want more stuff in this= document? I have added some text about it.

=A0 Patrik

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

--0016364d31b72c1d8d0492708342-- From namedroppers-bounces@ietf.org Wed Oct 13 09:17:08 2010 Return-Path: X-Original-To: dnsext-archive@lists.ietf.org Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D0C03A6BD0 for ; Wed, 13 Oct 2010 09:17:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Welcome to the "namedroppers" mailing list From: namedroppers-request@ietf.org To: dnsext-archive@lists.ietf.org X-No-Archive: yes Message-ID: Date: Wed, 13 Oct 2010 09:16:59 -0700 Precedence: bulk X-BeenThere: namedroppers@ietf.org X-Mailman-Version: 2.1.9 List-Id: DNS Extensions working group discussion list X-List-Administrivia: yes Sender: namedroppers-bounces@ietf.org Errors-To: namedroppers-bounces@ietf.org You have been subscribed to this list because you are currently a subscriber to the namedroppers@ops.ietf.org list. We're moving that list. If you want to remove your subscription, you may. This is a one-time event: we won't re-sync the list subscribers again. Thanks, Andrew and Olafur (your list admins)Welcome to the namedroppers@ietf.org mailing list! Welcome to the DNS Extensions working group list. Anything listed in the charter for the working group (http://datatracker.ietf.org/wg/dnsext/charter/) is on-topic on this list. Please keep your postings relevant to the list's purpose. The list is an IETF activity in the meaning of RFC 5378, so messages addressed to the list are IETF contributions. Note Well Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: - the IETF plenary session, - any IETF working group or portion thereof, - the IESG or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 5378 and RFC 3979 (updated by RFC 4879). Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 5378 and RFC 3979 for details. A participant in any IETF activity is deemed to accept all IETF rules of process, as documented in Best Current Practices RFCs and IESG Statements. A participant in any IETF activity acknowledges that written, audio and video records of meetings may be made and may be available to the public. To post to this list, send your email to: namedroppers@ietf.org General information about the mailing list is at: https://www.ietf.org/mailman/listinfo/namedroppers If you ever want to unsubscribe or change your options (eg, switch to or from digest mode, change your password, etc.), visit your subscription page at: https://www.ietf.org/mailman/options/namedroppers/dnsext-archive%40lists.ietf.org You can also make such adjustments via email by sending a message to: namedroppers-request@ietf.org with the word `help' in the subject or body (don't include the quotes), and you will get back a message with instructions. You must know your password to change your options (including changing the password, itself) or to unsubscribe. It is: YjMHLMe7 Normally, Mailman will remind you of your ietf.org mailing list passwords once every month, although you can disable this if you prefer. This reminder will also include instructions on how to unsubscribe or change your account options. There is also a button on your options page that will email your current password to you. From namedroppers-bounces@ietf.org Wed Oct 13 09:39:49 2010 Return-Path: X-Original-To: dnsext-archive@lists.ietf.org Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84F1B3A6943; Wed, 13 Oct 2010 09:39:49 -0700 (PDT) X-Original-To: namedroppers@core3.amsl.com Delivered-To: namedroppers@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAC7C3A68C0 for ; Wed, 13 Oct 2010 09:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.038 X-Spam-Level: X-Spam-Status: No, score=-102.038 tagged_above=-999 required=5 tests=[AWL=0.561, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eusvtixdaRot for ; Wed, 13 Oct 2010 09:39:38 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id DC7963A682A for ; Wed, 13 Oct 2010 09:39:34 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 5CC921ECB408 for ; Wed, 13 Oct 2010 16:40:50 +0000 (UTC) Date: Wed, 13 Oct 2010 12:40:48 -0400 From: Andrew Sullivan To: namedroppers@ietf.org Message-ID: <20101013164048.GI51385@shinkuro.com> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) X-Mailman-Approved-At: Wed, 13 Oct 2010 09:39:48 -0700 Subject: [namedroppers] List-meta: this new list is not in service yet X-BeenThere: namedroppers@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: namedroppers-bounces@ietf.org Errors-To: namedroppers-bounces@ietf.org Dear colleagues, While we have subscribed everyone to the namedroppers@ietf.org list who was a subscriber to namedroppers@ops.ietf.org, the new list isn't in operation yet. I've enabled the emergency moderation, and so postings to this list will not go through for the time being. I'll post an update when the list is open & ready to go. Best regards, Andrew -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. _______________________________________________ namedroppers mailing list namedroppers@ietf.org https://www.ietf.org/mailman/listinfo/namedroppers From owner-namedroppers@ops.ietf.org Wed Oct 13 09:52:25 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 006953A6834; Wed, 13 Oct 2010 09:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.041 X-Spam-Level: X-Spam-Status: No, score=-102.041 tagged_above=-999 required=5 tests=[AWL=0.558, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWBT7qR-UkDD; Wed, 13 Oct 2010 09:52:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 149103A68D5; Wed, 13 Oct 2010 09:52:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P64UI-0005nC-MB for namedroppers-data0@psg.com; Wed, 13 Oct 2010 16:47:34 +0000 Received: from mail.yitter.info ([208.86.224.201]) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P64UG-0005mp-3f for namedroppers@ops.ietf.org; Wed, 13 Oct 2010 16:47:32 +0000 Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id EDCF91ECB408 for ; Wed, 13 Oct 2010 16:47:26 +0000 (UTC) Date: Wed, 13 Oct 2010 12:47:25 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: [dnsext] List migration update Message-ID: <20101013164724.GJ51385@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Dear colleagues, If you are on the namedroppers@ops.ietf.org list, you should have recently received (or should receive presently) a notice of your subscription to the namedroppers@ietf.org list. This is part of moving the list. The new list is not yet open, and all messages will currently be discarded (the moderation bit is on, but I'll delete any messages that go there). While there were some people who argued in favour of the dnsext@ietf.org name for the list (and while I tended to agree with those arguments), several people seemed to feel very strongly that we should keep the namedroppers list name. So that's what we've done. My current plan is to cut over on 2010-10-21, which is one week from tomorrow. Please plan to update your mail filters, if you have not already done so. Currently, there is not an alias from dnsext@ietf.org to namedroppers@ietf.org. I hope to fix that. We have not yet moved the namedroppers archive. If you have any questions or concerns, please don't hesitate to raise them. Best regards, Andrew -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Wed Oct 13 11:06:14 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 046B03A69F5; Wed, 13 Oct 2010 11:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.272 X-Spam-Level: X-Spam-Status: No, score=-2.272 tagged_above=-999 required=5 tests=[AWL=0.326, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 446viumJ7F+l; Wed, 13 Oct 2010 11:06:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E12683A69CD; Wed, 13 Oct 2010 11:06:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P65ch-000CvF-Lh for namedroppers-data0@psg.com; Wed, 13 Oct 2010 18:00:23 +0000 Received: from mail-fx0-f52.google.com ([209.85.161.52]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P65cT-000CuU-QN for namedroppers@ops.ietf.org; Wed, 13 Oct 2010 18:00:09 +0000 Received: by fxm16 with SMTP id 16so2974167fxm.11 for ; Wed, 13 Oct 2010 11:00:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=fWVUC4hJD0zyMK1RUSN7LQuo/lfXU+DQWz2Xy9pajgw=; b=TLyY7WvFL7NWmNRmwfCjHuRXnLgaELyV+A9IC0ZiLzlAG1u3OmiHmvVBn+Gb7KSsXJ g1alAG4P89uVJdSVfE8ga+B7l0chIm8QE4xpzuBZ64FfltVbGusDTwsVYn8C7nnHrg9B nTCdaKGFYdQfEHWPoEYzk4D+OfgBMD8E8sv2M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=cMBZb1at/feC2jmX/BeVGhljHeDKamZi4DgxoN6CYV3iQknKFnWw3l+Ba91Qy1j0cZ q5HTH9pO+hbVJPSrjnFsRVotFhXG9z6n/4tNaGpsx8xWsL4FlidzEqouT3E1q/i/GaQa cKy/ieNxzuwbCmx+8p2ynJHkLf3GG/Y4Q16cw= MIME-Version: 1.0 Received: by 10.239.180.140 with SMTP id i12mr611127hbg.140.1286992804005; Wed, 13 Oct 2010 11:00:04 -0700 (PDT) Received: by 10.239.156.141 with HTTP; Wed, 13 Oct 2010 11:00:03 -0700 (PDT) In-Reply-To: References: <20100725184119.GA42253@registro.br> <8E0002DF-09C9-46CD-AB1B-6DE946E3D0DC@cisco.com>

<0058A35A-86AB-4BC8-A9C0-2DD92CA04265@cisco.com>

Date: Wed, 13 Oct 2010 14:00:03 -0400 Message-ID: Subject: Re: [dnsext] URI RRTYPE review - Comments period end Aug 15th From: Phillip Hallam-Baker To: "Patrik Faltstrom (pfaltstr)" Cc: Ted Hardie , Frederico A C Neves , namedroppers@ops.ietf.org Content-Type: multipart/alternative; boundary=001485f2c18ce9490e0492835cb3 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --001485f2c18ce9490e0492835cb3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable DDDS is a feature that can only be realistically added to a specification a= t the time that the protocol is first defined. It is the same problem with SR= V and pretty much every other expanded discovery mechanism. The point I am making about security policy is that security policy is a feature that we can realistically retro-fit to existing protocols. We have already applied security policy to SMTP via DKIM. We can usefully apply security policy in many other contexts. Since the additional functionality NAPTR provides over SRV is very similar to the functionality that can be usefully added to a security policy mechanism, there is probably not a great deal of milage in having a securit= y policy record that contains a flag saying 'you can get there better using NAPTR'. But there is certainly a lot of value in a flag that says 'you can get there better using SRV or URI'. The way I think this would be presented to an application programmer would be a replacement for gethostbyname where the caller specifies a DNS name, a DNS protocol prefix, a default port number (optional) and a minimum set of security criteria (optional) and the routine then returns the best connection possible to a host providing the service. So in this model the application programmer's mental model would not change very much from gethostbyname. If we later define new discovery mechanisms they can be used by any client that has the appropriate library support. On Wed, Oct 13, 2010 at 10:51 AM, Patrik Faltstrom (pfaltstr) < pfaltstr@cisco.com> wrote: > On 13 okt 2010, at 15:13, "Phillip Hallam-Baker" wrote= : > > Unfortunately, NAPTR does not have the ability to specify security policy > information so the deployment incentives don't work the same. > > > NAPTR only exists within a DDDS context, so that is up to your definition > of the algorithm that uses the NAPTR. > > So I do not understand the above. Please expand. > > Patrik > > SRV has existed for a decade now, yet we still cant get applications to > bother to check it for no-brainer applications such as imap. > > > If people care about security (an unproven hypothesis unfortunately) and > are thus willing to check a DNSSEC signature chain, then I have to hope t= hat > they are willing to do an extra lookup to actually give that DNSSEC looku= p a > point. > > The biggest security hole in the Internet at the moment is the fact that > security is an optional afterthought. So sites have to rely on people > noticing the dorky padlock icon which means only that the communication w= as > encrypted. > > > DNSSEC deployment might not require an out of pocket cost, but that does > not mean that the cost of deployment is 'free'. Just the fact that DNSSEC > means that DNS deployment has to be done right means several hours extra > work a year and that translates into higher administration costs. > > There has to be a compelling value provided by DNSSEC and merely defeatin= g > the Kaminsky attack on its own isn't enough. > > Provide protection against the downgrade attack however and suddenly you > have a very compelling value with an immediate value to the client that > cannot be realized any other way. > > > An e-commerce site does not need to be very large for the value of a > security policy record to be in the hundreds of dollars. For the major > phishing targets it is in the hundred of thousands or millions. > > Making a case for better discovery techniques on their own is much harder > since the cost of bandwidth continues to fall and the application provide= rs > have not seen a benefit to date. > > > Which is why I think that a flag in the security policy record that says > 'hey there is also a better discovery mechanism' is more powerful as a > deployment strategy than a flag in the discovery record saying to use htt= ps. > > > 2010/10/12 Patrik F=E4ltstr=F6m < paf@cisco.com> > >> On 12 okt 2010, at 21.30, Phillip Hallam-Baker wrote: >> >> > For example it >> > could tell the client that it can use SRV or NAPTR or URI for enhanced >> > discovery. >> > >> > example.com ESRV "prefix=3D_http._tcp,_imap._tcp" >> > _http._ tcp.example.com ESRV "tls=3Drequired >> disc=3Dsrv" >> > _http._ tcp.example.com SRV 1 1 80 >> site1.example.com >> > _http._ tcp.example.com SRV 1 1 80 >> site2.example.com >> >> For me this is what NAPTR does... >> >> example.com. NAPTR 20 0 "s" "http" "" _http._ >> tcp.frobbit.se. >> example.com. NAPTR 20 0 "s" "imap" "" _imap._ >> tcp.frobbit.se. >> _http._ tcp.example.com. SRV 1 1 80 >> site1.example.com. >> _http._ tcp.example.com. SRV 1 1 80 >> site2.example.com. >> >> Patrik >> >> > > > -- > Website: http://hallambaker.com/ > > --=20 Website: http://hallambaker.com/ --001485f2c18ce9490e0492835cb3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable DDDS is a feature that can only be realistically added to a specification a= t the time that the protocol is first defined. It is the same problem with = SRV and pretty much every other expanded discovery mechanism.

The point I am making about security policy is that security policy is= a feature that we can realistically retro-fit to existing protocols. We ha= ve already applied security policy to SMTP via DKIM. We can usefully apply = security policy in many other contexts.

Since the additional functionality NAPTR= provides over SRV is very similar to the functionality that can be usefull= y added to a security policy mechanism, there is probably not a great deal = of milage in having a security policy record that contains a flag saying &#= 39;you can get there better using NAPTR'. But there is certainly a lot = of value in a flag that says 'you can get there better using SRV or URI= '.

The way I think this would be presented to an applicati= on programmer would be a replacement for gethostbyname where the caller spe= cifies a DNS name, a DNS protocol prefix, a default port number (optional) = and a minimum set of security criteria (optional) and the routine then retu= rns the best connection possible to a host providing the service.

So in this model the application programmer's menta= l model would not change very much from gethostbyname.

If we later define new discovery mechanisms they can be used by any cl= ient that has the appropriate library support.

On Wed, Oct 13, 2010= at 10:51 AM, Patrik Faltstrom (pfaltstr) <pfaltstr@cisco.com> wrote:

On 13 okt 2010, at 15= :13, "Phillip Hallam-Baker" <hallam@gmail.com> wrote:

<= br>

Unfortunately, NAPTR does not hav= e the ability to specify security policy information so the deployment ince= ntives don't work the same.

NAPT= R only exists within a DDDS context, so that is up to your definition of th= e algorithm that uses the NAPTR.

So I do not understand the above. Please expand.

<= br>

=A0=A0 Patrik

<= /div>

S= RV has existed for a decade now, yet we still cant get applications to both= er to check it for no-brainer applications such as imap.

If people care about security (an unprov= en hypothesis unfortunately) and are thus willing to check a DNSSEC signatu= re chain, then I have to hope that they are willing to do an extra lookup t= o actually give that DNSSEC lookup a point.

The biggest security hole in the Internet at the moment= is the fact that security is an optional afterthought. So sites have to re= ly on people noticing the dorky padlock icon which means only that the comm= unication was encrypted.

DNSSEC deployment might not require an o= ut of pocket cost, but that does not mean that the cost of deployment is &#= 39;free'. Just the fact that DNSSEC means that DNS deployment has to be= done right means several hours extra work a year and that translates into = higher administration costs.

There has to be a compelling value provided by DNSSEC a= nd merely defeating the Kaminsky attack on its own isn't enough.
<= div>
Provide protection against the downgrade attack however = and suddenly you have a very compelling value with an immediate value to th= e client that cannot be realized any other way.

An e-commerce site does not need to be v= ery large for the value of a security policy record to be in the hundreds o= f dollars. For the major phishing targets it is in the hundred of thousands= or millions.

Making a case for better discovery techniques on their o= wn is much harder since the cost of bandwidth continues to fall and the app= lication providers have not seen a benefit to date.

Which is why I think that a flag in the security policy= record that says 'hey there is also a better discovery mechanism' = is more powerful as a deployment strategy than a flag in the discovery reco= rd saying to use https.

2010/10/12 Patrik F=E4lt= str=F6m <paf@cisco.com<= /a>>

On 12 okt 2010, at 21.30, Phillip Hallam-Baker wrote:

> For example it
> could tell the client that it can use SRV or NAPTR or URI for enhanced=
> discovery.
>
> example.com =A0ESRV "prefix=3D_htt= p._tcp,_imap._tcp"
> _http._tcp.example.com ESRV &qu= ot;tls=3Drequired disc=3Dsrv"
> _http._tcp.example.com SRV 1 1 = 80 site1.example.com
> _http._tcp.example.com SRV 1 1 = 80 site2.example.com

For me this is what NAPTR does...

example.com. NAPTR 20 0 "s" "= http" "" _http._tcp.frobbit= .se.
example.com. NAPTR 20 0 "s" "= imap" "" _imap._tcp.frobbit= .se.

_http._tcp.example.com. SRV 1 1= 80 site1.example.com.

_http._tcp.example.com. SRV 1 = 1 80 site2.example.com.

=A0 Patrik

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

--
Website: http://hal= lambaker.com/

--001485f2c18ce9490e0492835cb3-- From owner-namedroppers@ops.ietf.org Wed Oct 13 14:20:27 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56A513A6A2C; Wed, 13 Oct 2010 14:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.052 X-Spam-Level: X-Spam-Status: No, score=-102.052 tagged_above=-999 required=5 tests=[AWL=0.547, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yfx9+CgapXcC; Wed, 13 Oct 2010 14:20:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5509F3A6A2B; Wed, 13 Oct 2010 14:20:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P68fY-0002yb-D9 for namedroppers-data0@psg.com; Wed, 13 Oct 2010 21:15:28 +0000 Received: from mail.yitter.info ([208.86.224.201]) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P68fV-0002yE-Jn for namedroppers@ops.ietf.org; Wed, 13 Oct 2010 21:15:25 +0000 Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id C0BE41ECB422 for ; Wed, 13 Oct 2010 21:15:21 +0000 (UTC) Date: Wed, 13 Oct 2010 17:15:20 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: [dnsext] Meeting in Beijing Message-ID: <20101013211518.GD773@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Dear colleagues, At the moment, we have a very light agenda for the Beijing meeting. These are the items for which we've received requests: 1. A brief presentation on a DNSSEC history wiki (with a solitication for participation). 2. A discussion of draft-vixie-dnsext-resimprove-00. 3. A discussion of draft-yao-dnsext-identical-resolution-0[1|2]. We'd like people to treat (3) as though it's a WG draft. Assuming the charter we sent to the IESG gets approved, that document will automatically become a WG document by virtue of the charter adoption. We're being careful not to step out of process, however, and as of right now, the document isn't strictly speaking on charter. Our feeling is that a meeting of this sort can be completed within an hour or so. However, we find ourselves at the moment with a much longer slot (currently, Wed. morning, for 2 1/2 hours. We didn't ask for that much; it is apparently mostly to deal with scheduling difficulties). I note, however, that we have a number of drafts that have been lingering for some time. This is mostly due to inertia. Olafur and I therefore propose to use the extra time as a breakout session to nail down whatever changes are still needed in those lingering drafts. If we can get five committed reviewers for each document in the room, and get the necessary text compromises settled, we can then immediately send them through WGLC, and we would clear our docket. We think this would be a productive use of the time. If you have objections to this plan, please let us know. If you do not so object, we'll take that as an indication that the plan sounds sensible. Best regards, Andrew and Olafur. -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Wed Oct 13 14:36:22 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4767A3A69FF; Wed, 13 Oct 2010 14:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.715 X-Spam-Level: X-Spam-Status: No, score=-1.715 tagged_above=-999 required=5 tests=[AWL=0.884, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nmYSTKa8bfqW; Wed, 13 Oct 2010 14:36:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7BCF73A69DF; Wed, 13 Oct 2010 14:36:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P68w2-00047Y-VN for namedroppers-data0@psg.com; Wed, 13 Oct 2010 21:32:30 +0000 Received: from elasmtp-junco.atl.sa.earthlink.net ([209.86.89.63]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P68w0-00046T-3p for namedroppers@ops.ietf.org; Wed, 13 Oct 2010 21:32:28 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=tSRftmqyVPuA0chpe84P8FXdnAlDOUJAOGfkPB9mId9LJNyQs6BMcOM0f9j2q4OH; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.36] (helo=elwamui-hybrid.atl.sa.earthlink.net) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1P68vh-0001qx-BY for namedroppers@ops.ietf.org; Wed, 13 Oct 2010 17:32:09 -0400 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Wed, 13 Oct 2010 17:32:09 -0400 Message-ID: <31932914.1287005529271.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> Date: Wed, 13 Oct 2010 16:32:09 -0500 (GMT-05:00) From: "Jeffrey A. Williams" Reply-To: "Jeffrey A. Williams" To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Meeting in Beijing Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688f24b3d0d18d2a8d493695a413212d92c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.36 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Andrew and all, I noticed that Phillips proposal is not on the list. Was there some reason as to why not? -----Original Message----- >From: Andrew Sullivan >Sent: Oct 13, 2010 4:15 PM >To: namedroppers@ops.ietf.org >Subject: [dnsext] Meeting in Beijing > >Dear colleagues, > >At the moment, we have a very light agenda for the Beijing meeting. >These are the items for which we've received requests: > >1. A brief presentation on a DNSSEC history wiki (with a solitication >for participation). > >2. A discussion of draft-vixie-dnsext-resimprove-00. > >3. A discussion of draft-yao-dnsext-identical-resolution-0[1|2]. > >We'd like people to treat (3) as though it's a WG draft. Assuming the >charter we sent to the IESG gets approved, that document will >automatically become a WG document by virtue of the charter adoption. >We're being careful not to step out of process, however, and as of >right now, the document isn't strictly speaking on charter. > >Our feeling is that a meeting of this sort can be completed within an >hour or so. However, we find ourselves at the moment with a much >longer slot (currently, Wed. morning, for 2 1/2 hours. We didn't ask >for that much; it is apparently mostly to deal with scheduling >difficulties). > >I note, however, that we have a number of drafts that have been >lingering for some time. This is mostly due to inertia. Olafur and I >therefore propose to use the extra time as a breakout session to nail >down whatever changes are still needed in those lingering drafts. If >we can get five committed reviewers for each document in the room, and >get the necessary text compromises settled, we can then immediately >send them through WGLC, and we would clear our docket. We think this >would be a productive use of the time. > >If you have objections to this plan, please let us know. If you do >not so object, we'll take that as an indication that the plan sounds >sensible. > >Best regards, > >Andrew and Olafur. > >-- >Andrew Sullivan >ajs@shinkuro.com >Shinkuro, Inc. > Regards, Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com Phone: 214-244-4827 From owner-namedroppers@ops.ietf.org Wed Oct 13 14:42:33 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9810D3A6A77; Wed, 13 Oct 2010 14:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WziFgdZY8rmh; Wed, 13 Oct 2010 14:42:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 987023A6A1D; Wed, 13 Oct 2010 14:42:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P6949-0004iN-JX for namedroppers-data0@psg.com; Wed, 13 Oct 2010 21:40:53 +0000 Received: from [2001:4900:1:392:213:20ff:fe1b:3bfe] (helo=monster.hopcount.ca) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P6947-0004hg-A4 for namedroppers@ops.ietf.org; Wed, 13 Oct 2010 21:40:51 +0000 Received: from [199.212.90.23] (helo=dh23.r2.owls.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1P6941-0003ev-SH; Wed, 13 Oct 2010 21:40:47 +0000 Subject: Re: [dnsext] Meeting in Beijing Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Joe Abley In-Reply-To: <20101013211518.GD773@shinkuro.com> Date: Wed, 13 Oct 2010 17:40:44 -0400 Cc: namedroppers@ops.ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20101013211518.GD773@shinkuro.com> To: Andrew Sullivan X-Mailer: Apple Mail (2.1081) X-SA-Exim-Connect-IP: 199.212.90.23 X-SA-Exim-Mail-From: jabley@hopcount.ca X-SA-Exim-Scanned: No (on monster.hopcount.ca); SAEximRunCond expanded to false Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 2010-10-13, at 17:15, Andrew Sullivan wrote: > I note, however, that we have a number of drafts that have been > lingering for some time. This is mostly due to inertia. Olafur and I > therefore propose to use the extra time as a breakout session to nail > down whatever changes are still needed in those lingering drafts. If > we can get five committed reviewers for each document in the room, and > get the necessary text compromises settled, we can then immediately > send them through WGLC, and we would clear our docket. We think this > would be a productive use of the time. has the following which are not = stuck upstream of the working group: draft-ietf-dnsext-dnssec-registry-fixes-06 draft-ietf-dnsext-rfc2672bis-dname-19 Did you mean just those two, or also others? Joe= From owner-namedroppers@ops.ietf.org Wed Oct 13 14:53:28 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DD503A69DF; Wed, 13 Oct 2010 14:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[AWL=0.449, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eOyWUjVSqTOF; Wed, 13 Oct 2010 14:53:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 11AFA3A69CE; Wed, 13 Oct 2010 14:53:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P69Do-0005WR-UN for namedroppers-data0@psg.com; Wed, 13 Oct 2010 21:50:52 +0000 Received: from mail-qy0-f180.google.com ([209.85.216.180]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P69Dl-0005W6-Py for namedroppers@ops.ietf.org; Wed, 13 Oct 2010 21:50:50 +0000 Received: by qyk1 with SMTP id 1so7649810qyk.11 for ; Wed, 13 Oct 2010 14:50:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ZvIh2LLQAMTgbuFRW2IbW4ly8vHTWhKMmNXXr8X5MZY=; b=gtdJwQhwXJFp63sLd5MCZqCymzSM+E01xuIpWAnwYA+fH4m8U+CHlfrm7UC5eLgvH1 2r/2L/HlAT3mkZJgV6MOdxc2tpbkcqZtH5hh0mwbcG0f31xec4OesWiTJlyNWibS6ZFH X+TihMYNXmd3QIRhAP6xihZYfyqZzesItXI1U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=RtzfsP6xMfnQx6x+6AufkLjkPwlbAliShoC3TXJe9rFHU/Szvg9TJ49Ljksf59NfLT uD1nnHQX2onnMpEBTu9NIpxBhbjFgm2iIlDl1KDp/63gC5rfRF3SQVbQKArKmZDQ2B7f dRQiutt024A+Qly45tf+jMPqWOTCtpXyVin6c= MIME-Version: 1.0 Received: by 10.229.216.16 with SMTP id hg16mr8061031qcb.55.1287006042183; Wed, 13 Oct 2010 14:40:42 -0700 (PDT) Received: by 10.229.213.69 with HTTP; Wed, 13 Oct 2010 14:40:42 -0700 (PDT) In-Reply-To: <20101013211518.GD773@shinkuro.com> References: <20101013211518.GD773@shinkuro.com> Date: Wed, 13 Oct 2010 14:40:42 -0700 Message-ID: Subject: Re: [dnsext] Meeting in Beijing From: Ted Hardie To: Andrew Sullivan Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: I would like to see time for discussion of paf's recent draft. There has been reasonable list traffic to support having a face-to-face meeting discussion, but I don't think it falls into your "5 reviewers and WGLC" bucket, because at least one counter proposal has come in. For what it's worth, I'm still chewing over his responses to the issues I raised. I feel like the basic approach, "some firm description of the service is needed" is a point at which we agree. But the registration methodology has its limits, as we have seen in many other URI-related registries. They are so easy to mint that it is hard to capture the ones in use, much less advise on their creation. My tea leaves say the same problem will happen here if this method gets any popularity at all I'm not sure yet what to suggest, but if we have extra time in the meeting schedule, I'm sure I would benefit from hearing others' thoughts on the problem space. regards, Ted On Wed, Oct 13, 2010 at 2:15 PM, Andrew Sullivan wrote: > Dear colleagues, > > At the moment, we have a very light agenda for the Beijing meeting. > These are the items for which we've received requests: > > 1. =A0A brief presentation on a DNSSEC history wiki (with a solitication > for participation). > > 2. =A0A discussion of draft-vixie-dnsext-resimprove-00. > > 3. =A0A discussion of draft-yao-dnsext-identical-resolution-0[1|2]. > > We'd like people to treat (3) as though it's a WG draft. =A0Assuming the > charter we sent to the IESG gets approved, that document will > automatically become a WG document by virtue of the charter adoption. > We're being careful not to step out of process, however, and as of > right now, the document isn't strictly speaking on charter. > > Our feeling is that a meeting of this sort can be completed within an > hour or so. =A0However, we find ourselves at the moment with a much > longer slot (currently, Wed. morning, for 2 1/2 hours. =A0We didn't ask > for that much; it is apparently mostly to deal with scheduling > difficulties). > > I note, however, that we have a number of drafts that have been > lingering for some time. =A0This is mostly due to inertia. =A0Olafur and = I > therefore propose to use the extra time as a breakout session to nail > down whatever changes are still needed in those lingering drafts. =A0If > we can get five committed reviewers for each document in the room, and > get the necessary text compromises settled, we can then immediately > send them through WGLC, and we would clear our docket. =A0We think this > would be a productive use of the time. > > If you have objections to this plan, please let us know. =A0If you do > not so object, we'll take that as an indication that the plan sounds > sensible. > > Best regards, > > Andrew and Olafur. > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > > From owner-namedroppers@ops.ietf.org Wed Oct 13 16:58:53 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AA823A6A73; Wed, 13 Oct 2010 16:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.358 X-Spam-Level: X-Spam-Status: No, score=-101.358 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wFTMrecDHCjt; Wed, 13 Oct 2010 16:58:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3729F3A69EF; Wed, 13 Oct 2010 16:58:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P6B8e-000CZY-LR for namedroppers-data0@psg.com; Wed, 13 Oct 2010 23:53:40 +0000 Received: from mail.yitter.info ([208.86.224.201]) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P6B8a-000CZF-Oq for namedroppers@ops.ietf.org; Wed, 13 Oct 2010 23:53:37 +0000 Received: from [172.16.33.104] (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 7318D1ECB408; Wed, 13 Oct 2010 23:53:34 +0000 (UTC) References: <31932914.1287005529271.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> In-Reply-To: <31932914.1287005529271.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> Mime-Version: 1.0 (iPhone Mail 8B117) Content-Type: text/plain; charset=us-ascii Message-Id: <37E7640E-6F0F-4C5D-BAE6-A38742D63757@shinkuro.com> Content-Transfer-Encoding: quoted-printable Cc: "namedroppers@ops.ietf.org" X-Mailer: iPhone Mail (8B117) From: Andrew Sullivan Subject: Re: [dnsext] Meeting in Beijing Date: Wed, 13 Oct 2010 19:53:06 -0400 To: "Jeffrey A. Williams" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Unless I completely overlooked it, he didn't request a slot in the meeting.=20= --=20 Andrew Sullivan On 2010-10-13, at 17:32, "Jeffrey A. Williams" wrot= e: > Andrew and all, >=20 > I noticed that Phillips proposal is not on the list. > Was there some reason as to why not? >=20 >=20 > -----Original Message----- >> From: Andrew Sullivan >> Sent: Oct 13, 2010 4:15 PM >> To: namedroppers@ops.ietf.org >> Subject: [dnsext] Meeting in Beijing >>=20 >> Dear colleagues, >>=20 >> At the moment, we have a very light agenda for the Beijing meeting. >> These are the items for which we've received requests: >>=20 >> 1. A brief presentation on a DNSSEC history wiki (with a solitication >> for participation). >>=20 >> 2. A discussion of draft-vixie-dnsext-resimprove-00. >>=20 >> 3. A discussion of draft-yao-dnsext-identical-resolution-0[1|2]. >>=20 >> We'd like people to treat (3) as though it's a WG draft. Assuming the >> charter we sent to the IESG gets approved, that document will >> automatically become a WG document by virtue of the charter adoption. >> We're being careful not to step out of process, however, and as of >> right now, the document isn't strictly speaking on charter. >>=20 >> Our feeling is that a meeting of this sort can be completed within an >> hour or so. However, we find ourselves at the moment with a much >> longer slot (currently, Wed. morning, for 2 1/2 hours. We didn't ask >> for that much; it is apparently mostly to deal with scheduling >> difficulties). >>=20 >> I note, however, that we have a number of drafts that have been >> lingering for some time. This is mostly due to inertia. Olafur and I >> therefore propose to use the extra time as a breakout session to nail >> down whatever changes are still needed in those lingering drafts. If >> we can get five committed reviewers for each document in the room, and >> get the necessary text compromises settled, we can then immediately >> send them through WGLC, and we would clear our docket. We think this >> would be a productive use of the time. >>=20 >> If you have objections to this plan, please let us know. If you do >> not so object, we'll take that as an indication that the plan sounds >> sensible. >>=20 >> Best regards, >>=20 >> Andrew and Olafur. >>=20 >> --=20 >> Andrew Sullivan >> ajs@shinkuro.com >> Shinkuro, Inc. >>=20 >=20 > Regards, > Jeffrey A. Williams > Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing,= strong!) > "Obedience of the law is the greatest freedom" - > Abraham Lincoln >=20 > "Credit should go with the performance of duty and not with what is very > often the accident of glory" - Theodore Roosevelt >=20 > "If the probability be called P; the injury, L; and the burden, B; liabili= ty > depends upon whether B is less than L multiplied by > P: i.e., whether B is less than PL." > United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Updated 1/26/04 > CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. o= f > Information Network Eng. INEG. INC. > ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.c= om > Phone: 214-244-4827 >=20 >=20 >=20 From owner-namedroppers@ops.ietf.org Wed Oct 13 19:52:08 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1999A3A685B; Wed, 13 Oct 2010 19:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.897 X-Spam-Level: X-Spam-Status: No, score=-6.897 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1cQyLvAbtMw4; Wed, 13 Oct 2010 19:52:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AC0203A6832; Wed, 13 Oct 2010 19:52:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P6Dr4-000LzY-VP for namedroppers-data0@psg.com; Thu, 14 Oct 2010 02:47:42 +0000 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P6Dr1-000LzH-V8 for namedroppers@ops.ietf.org; Thu, 14 Oct 2010 02:47:40 +0000 Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlEFAIYMtkyrRN+J/2dsb2JhbACgVUwCcaEQnF+FSASKQYMJgmCBfg X-IronPort-AV: E=Sophos;i="4.57,328,1283731200"; d="scan'208";a="200443612" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 14 Oct 2010 02:47:38 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o9E2lcPS017606; Thu, 14 Oct 2010 02:47:38 GMT Received: from xmb-ams-106.cisco.com ([144.254.74.81]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Oct 2010 04:47:37 +0200 Received: from 128.107.191.32 ([128.107.191.32]) by XMB-AMS-106.cisco.com ([144.254.74.81]) with Microsoft Exchange Server HTTP-DAV ; Thu, 14 Oct 2010 02:47:36 +0000 Subject: Re: [dnsext] Meeting in Beijing References: <20101013211518.GD773@shinkuro.com> Content-Transfer-Encoding: quoted-printable From: "Patrik Faltstrom (pfaltstr)" Content-Type: text/plain; charset="us-ascii" Thread-Topic: [dnsext] Meeting in Beijing Thread-Index: ActrSihnMW0dTg9FSjaIXe4707KdXw== In-Reply-To: Message-ID: <1CA5D684-18BB-4C3A-908C-C9A8949CA0AC@cisco.com> Date: Thu, 14 Oct 2010 04:48:11 +0200 To: "Ted Hardie" Cc: "Andrew Sullivan" , MIME-Version: 1.0 (iPhone Mail 8B117) X-OriginalArrivalTime: 14 Oct 2010 02:47:37.0891 (UTC) FILETIME=[298ADF30:01CB6B4A] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 13 okt 2010, at 23:52, "Ted Hardie" wrote: > I would like to see time for discussion of paf's recent draft. I think a discussion would be healthy. I will though not be in Beijing but w= ill participate remotely. Patrik > There has been reasonable list traffic to support having > a face-to-face meeting discussion, but I don't think it > falls into your "5 reviewers and WGLC" bucket, because > at least one counter proposal has come in. >=20 > For what it's worth, I'm still chewing over his responses to > the issues I raised. I feel like the basic approach, "some firm > description of the service is needed" is a point at which we > agree. But the registration methodology has its limits, > as we have seen in many other URI-related registries. > They are so easy to mint that it is hard to capture the ones in use, > much less advise on their creation. My tea leaves say the > same problem will happen here if this method gets any popularity at > all >=20 > I'm not sure yet what to suggest, but if we have extra time in the > meeting schedule, I'm sure I would benefit from hearing others' thoughts > on the problem space. >=20 > regards, >=20 > Ted >=20 >=20 > On Wed, Oct 13, 2010 at 2:15 PM, Andrew Sullivan wrote:= >> Dear colleagues, >>=20 >> At the moment, we have a very light agenda for the Beijing meeting. >> These are the items for which we've received requests: >>=20 >> 1. A brief presentation on a DNSSEC history wiki (with a solitication >> for participation). >>=20 >> 2. A discussion of draft-vixie-dnsext-resimprove-00. >>=20 >> 3. A discussion of draft-yao-dnsext-identical-resolution-0[1|2]. >>=20 >> We'd like people to treat (3) as though it's a WG draft. Assuming the >> charter we sent to the IESG gets approved, that document will >> automatically become a WG document by virtue of the charter adoption. >> We're being careful not to step out of process, however, and as of >> right now, the document isn't strictly speaking on charter. >>=20 >> Our feeling is that a meeting of this sort can be completed within an >> hour or so. However, we find ourselves at the moment with a much >> longer slot (currently, Wed. morning, for 2 1/2 hours. We didn't ask >> for that much; it is apparently mostly to deal with scheduling >> difficulties). >>=20 >> I note, however, that we have a number of drafts that have been >> lingering for some time. This is mostly due to inertia. Olafur and I >> therefore propose to use the extra time as a breakout session to nail >> down whatever changes are still needed in those lingering drafts. If >> we can get five committed reviewers for each document in the room, and >> get the necessary text compromises settled, we can then immediately >> send them through WGLC, and we would clear our docket. We think this >> would be a productive use of the time. >>=20 >> If you have objections to this plan, please let us know. If you do >> not so object, we'll take that as an indication that the plan sounds >> sensible. >>=20 >> Best regards, >>=20 >> Andrew and Olafur. >>=20 >> -- >> Andrew Sullivan >> ajs@shinkuro.com >> Shinkuro, Inc. >>=20 >>=20 >=20 From owner-namedroppers@ops.ietf.org Wed Oct 13 21:55:33 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B0A83A69EC; Wed, 13 Oct 2010 21:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.656 X-Spam-Level: X-Spam-Status: No, score=-1.656 tagged_above=-999 required=5 tests=[AWL=-0.298, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJ8WxhUK-vwu; Wed, 13 Oct 2010 21:55:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5AEA73A67D1; Wed, 13 Oct 2010 21:55:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P6FkF-00035t-NK for namedroppers-data0@psg.com; Thu, 14 Oct 2010 04:48:47 +0000 Received: from mail-fx0-f52.google.com ([209.85.161.52]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P6FkA-00035i-FV for namedroppers@ops.ietf.org; Thu, 14 Oct 2010 04:48:42 +0000 Received: by fxm16 with SMTP id 16so3451689fxm.11 for ; Wed, 13 Oct 2010 21:48:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=Vb0671eEem9UJezbgPuFicGh3Fxida8RtFoPGG6VEHw=; b=LObLZH8CFqUI0Y/S20xSgRMo6DIAvyAN83/HZJf3RW3y/KxILs5YV9vyN5xvt0ooNt chbEuYPRUM+TFbviDHXFhExq7nM62RQrX5HNAsClcEwFF+VCgKVhXglHSzcd98YJzLEh xd4B9/ETPCiqh1PJY7iGJDhUe4uJ88miozX/g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=JGosh6pN1oHYYRtZ5PSfOaYQTjkPZwtq8YWYrMdbltY9dO1kRkgu3FGcXwhp1sDshP WhDJ/o/CU5iWqgHjArVEHiBqAxZFa2dtV3QT+HaX1Q7sFBSlGKuPk47jRjfJM/sx4Y64 TW/arFfYNBItTGKYbcoKgCX3LSYfstajki4pc= MIME-Version: 1.0 Received: by 10.239.172.69 with SMTP id z5mr601681hbe.170.1287031720994; Wed, 13 Oct 2010 21:48:40 -0700 (PDT) Received: by 10.239.156.141 with HTTP; Wed, 13 Oct 2010 21:48:40 -0700 (PDT) In-Reply-To: <37E7640E-6F0F-4C5D-BAE6-A38742D63757@shinkuro.com> References: <31932914.1287005529271.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> <37E7640E-6F0F-4C5D-BAE6-A38742D63757@shinkuro.com> Date: Thu, 14 Oct 2010 00:48:40 -0400 Message-ID: Subject: Re: [dnsext] Meeting in Beijing From: Phillip Hallam-Baker To: Andrew Sullivan Cc: "Jeffrey A. Williams" , "namedroppers@ops.ietf.org" Content-Type: multipart/alternative; boundary=001485f03cac8b684a04928c6c48 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --001485f03cac8b684a04928c6c48 Content-Type: text/plain; charset=ISO-8859-1 Unfortunately I will not be in Beijing. But I am planning to attend Prague and I think my proposal will be rather better to understand once I have the whole scheme developed. My overarching concept is that Security Policy is the way to create a compelling value proposition for DNSSEC. One approach would be to specify each chunk piecemeal so that the larger scheme only becomes gradually apparent. I don't think that is an honest approach, but it is an approach that is often encouraged in the interests of 'focus'. I would prefer to present a sketch of the overarching scheme and the initial starting points at the same time so that people can see that the initial work items are practical but do not lead to a dead end. For example, any scheme that requires additional DNS lookups on every http transaction is going to look unattractive in the short term when deployment is limited. In the larger scheme that overhead is factored out of the critical response loop entirely. On Wed, Oct 13, 2010 at 7:53 PM, Andrew Sullivan wrote: > Unless I completely overlooked it, he didn't request a slot in the meeting. > > -- > Andrew Sullivan > > > On 2010-10-13, at 17:32, "Jeffrey A. Williams" > wrote: > > > Andrew and all, > > > > I noticed that Phillips proposal is not on the list. > > Was there some reason as to why not? > > > > > > -----Original Message----- > >> From: Andrew Sullivan > >> Sent: Oct 13, 2010 4:15 PM > >> To: namedroppers@ops.ietf.org > >> Subject: [dnsext] Meeting in Beijing > >> > >> Dear colleagues, > >> > >> At the moment, we have a very light agenda for the Beijing meeting. > >> These are the items for which we've received requests: > >> > >> 1. A brief presentation on a DNSSEC history wiki (with a solitication > >> for participation). > >> > >> 2. A discussion of draft-vixie-dnsext-resimprove-00. > >> > >> 3. A discussion of draft-yao-dnsext-identical-resolution-0[1|2]. > >> > >> We'd like people to treat (3) as though it's a WG draft. Assuming the > >> charter we sent to the IESG gets approved, that document will > >> automatically become a WG document by virtue of the charter adoption. > >> We're being careful not to step out of process, however, and as of > >> right now, the document isn't strictly speaking on charter. > >> > >> Our feeling is that a meeting of this sort can be completed within an > >> hour or so. However, we find ourselves at the moment with a much > >> longer slot (currently, Wed. morning, for 2 1/2 hours. We didn't ask > >> for that much; it is apparently mostly to deal with scheduling > >> difficulties). > >> > >> I note, however, that we have a number of drafts that have been > >> lingering for some time. This is mostly due to inertia. Olafur and I > >> therefore propose to use the extra time as a breakout session to nail > >> down whatever changes are still needed in those lingering drafts. If > >> we can get five committed reviewers for each document in the room, and > >> get the necessary text compromises settled, we can then immediately > >> send them through WGLC, and we would clear our docket. We think this > >> would be a productive use of the time. > >> > >> If you have objections to this plan, please let us know. If you do > >> not so object, we'll take that as an indication that the plan sounds > >> sensible. > >> > >> Best regards, > >> > >> Andrew and Olafur. > >> > >> -- > >> Andrew Sullivan > >> ajs@shinkuro.com > >> Shinkuro, Inc. > >> > > > > Regards, > > Jeffrey A. Williams > > Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and > growing, strong!) > > "Obedience of the law is the greatest freedom" - > > Abraham Lincoln > > > > "Credit should go with the performance of duty and not with what is very > > often the accident of glory" - Theodore Roosevelt > > > > "If the probability be called P; the injury, L; and the burden, B; > liability > > depends upon whether B is less than L multiplied by > > P: i.e., whether B is less than PL." > > United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] > > =============================================================== > > Updated 1/26/04 > > CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. > of > > Information Network Eng. INEG. INC. > > ABA member in good standing member ID 01257402 E-Mail > jwkckid1@ix.netcom.com > > Phone: 214-244-4827 > > > > > > > > -- Website: http://hallambaker.com/ --001485f03cac8b684a04928c6c48 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Unfortunately I will not be in Beijing. But I am planning to attend Prague = and I think my proposal will be rather better to understand once I have the= whole scheme developed.

My overarching concept is that = Security Policy is the way to create a compelling value proposition for DNS= SEC.

One approach would be to specify each chunk piecemeal s= o that the larger scheme only becomes gradually apparent. I don't think= that is an honest approach, but it is an approach that is often encouraged= in the interests of 'focus'.

I would prefer to present a sketch of the overarching s= cheme and the initial starting points at the same time so that people can s= ee that the initial work items are practical but do not lead to a dead end.=

For example, any scheme that requires additional DNS lo= okups on every http transaction is going to look unattractive in the short = term when deployment is limited. In the larger scheme that overhead is fact= ored out of the critical response loop entirely.

On Wed, Oct 13, 2010 at 7= :53 PM, Andrew Sullivan <ajs@shinkuro.com> wrote:

Unless I completely overlooked it, he didn't request a slot in the meet= ing.

--

Andrew Sullivan
<ajs@shinkuro.com>

On 2010-10-13, at 17:32, "Jeff= rey A. Williams" <jwkckid= 1@ix.netcom.com> wrote:

> Andrew and all,
>
> =A0I noticed that Phillips proposal is not on the list.
> Was there some reason as to why not?
>
>
> -----Original Message-----
>> From: Andrew Sullivan <ajs@= shinkuro.com>
>> Sent: Oct 13, 2010 4:15 PM
>> To: namedroppers@ops.= ietf.org
>> Subject: [dnsext] Meeting in Beijing
>>
>> Dear colleagues,
>>
>> At the moment, we have a very light agenda for the Beijing meeting= .
>> These are the items for which we've received requests:
>>
>> 1. =A0A brief presentation on a DNSSEC history wiki (with a soliti= cation
>> for participation).
>>
>> 2. =A0A discussion of draft-vixie-dnsext-resimprove-00.
>>
>> 3. =A0A discussion of draft-yao-dnsext-identical-resolution-0[1|2]= .
>>
>> We'd like people to treat (3) as though it's a WG draft. = =A0Assuming the
>> charter we sent to the IESG gets approved, that document will
>> automatically become a WG document by virtue of the charter adopti= on.
>> We're being careful not to step out of process, however, and a= s of
>> right now, the document isn't strictly speaking on charter. >>
>> Our feeling is that a meeting of this sort can be completed within= an
>> hour or so. =A0However, we find ourselves at the moment with a muc= h
>> longer slot (currently, Wed. morning, for 2 1/2 hours. =A0We didn&= #39;t ask
>> for that much; it is apparently mostly to deal with scheduling
>> difficulties).
>>
>> I note, however, that we have a number of drafts that have been >> lingering for some time. =A0This is mostly due to inertia. =A0Olaf= ur and I
>> therefore propose to use the extra time as a breakout session to n= ail
>> down whatever changes are still needed in those lingering drafts. = =A0If
>> we can get five committed reviewers for each document in the room,= and
>> get the necessary text compromises settled, we can then immediatel= y
>> send them through WGLC, and we would clear our docket. =A0We think= this
>> would be a productive use of the time.
>>
>> If you have objections to this plan, please let us know. =A0If you= do
>> not so object, we'll take that as an indication that the plan = sounds
>> sensible.
>>
>> Best regards,
>>
>> Andrew and Olafur.
>>
>> --
>> Andrew Sullivan
>> ajs@shinkuro.com
>> Shinkuro, Inc.
>>
>
> Regards,
> Jeffrey A. Williams
> Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and grow= ing, strong!)
> "Obedience of the law is the greatest freedom" -
> =A0 Abraham Lincoln
>
> "Credit should go with the performance of duty and not with what = is very
> often the accident of glory" - Theodore Roosevelt
>
> "If the probability be called P; the injury, L; and the burden, B= ; liability
> depends upon whether B is less than L multiplied by
> P: i.e., whether B is less than PL."
> United States v. Carroll Towing =A0(159 F.2d 169 [2d Cir. 1947]
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Updated 1/26/04
> CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. di= v. of
> Information Network Eng. =A0INEG. INC.
> ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com
> Phone: 214-244-4827
>
>
>

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

--001485f03cac8b684a04928c6c48-- From owner-namedroppers@ops.ietf.org Thu Oct 14 04:43:10 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 232B83A68F8; Thu, 14 Oct 2010 04:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.877 X-Spam-Level: X-Spam-Status: No, score=-5.877 tagged_above=-999 required=5 tests=[AWL=0.722, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gx637Jfw9-Tg; Thu, 14 Oct 2010 04:43:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 38D6A3A679C; Thu, 14 Oct 2010 04:43:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P6M5w-000893-BX for namedroppers-data0@psg.com; Thu, 14 Oct 2010 11:35:36 +0000 Received: from rimp2.nist.gov ([129.6.16.227] helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P6M5s-00088j-ME for namedroppers@ops.ietf.org; Thu, 14 Oct 2010 11:35:32 +0000 Received: from WSXGHUB2.xchange.nist.gov (WSXGHUB2.xchange.nist.gov [129.6.18.19]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id o9EBZLb7005982 for ; Thu, 14 Oct 2010 07:35:22 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::41df:f63f:c718:e08]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Thu, 14 Oct 2010 07:34:50 -0400 From: "Rose, Scott W." To: Namedroppers WG Date: Thu, 14 Oct 2010 07:35:20 -0400 Subject: Re: [dnsext] Meeting in Beijing Thread-Topic: [dnsext] Meeting in Beijing Thread-Index: Actrk8/8JnWDnj76QGyxCa9I/reOyg== Message-ID: <2327B25E-584F-44EE-97BE-168F70C4A109@nist.gov> References: <20101013211518.GD773@shinkuro.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scott.rose@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Oct 13, 2010, at 5:40 PM, Joe Abley wrote: > > On 2010-10-13, at 17:15, Andrew Sullivan wrote: > >> I note, however, that we have a number of drafts that have been >> lingering for some time. This is mostly due to inertia. Olafur and I >> therefore propose to use the extra time as a breakout session to nail >> down whatever changes are still needed in those lingering drafts. If >> we can get five committed reviewers for each document in the room, and >> get the necessary text compromises settled, we can then immediately >> send them through WGLC, and we would clear our docket. We think this >> would be a productive use of the time. > > has the following which are not stuck upstream of the working group: > > draft-ietf-dnsext-dnssec-registry-fixes-06 Kind of waiting for draft-ietf-dnsext-dnssec-alg-allocation-03 to advance since it is an ref to draft-registry fixes (and one of the reasons registry-fixes was written). Don't know if I need a slot to say "waiting for ref to be published". There was no other discussion on the mailing list that I recall, but correct me if I'm wrong. > draft-ietf-dnsext-rfc2672bis-dname-19 Wouter and I need to rev this (if only to keep it alive). I think we're still hung up on the whole "What to return when the target name of a DNAME doesn't exist" question (the long thread). From my reading (as much as I could follow), that was never resolved but spun into larger questions about redirection. I won't be in Beijing in person, but may participate remotely if possible. Scott > > Did you mean just those two, or also others? > > > Joe =================================== Scott Rose NIST scottr@nist.gov +1 301-975-8439 Google Voice: +1 571-249-3671 http://www.dnsops.gov/ =================================== From owner-namedroppers@ops.ietf.org Thu Oct 14 05:17:59 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E89C3A6AF4; Thu, 14 Oct 2010 05:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.869 X-Spam-Level: X-Spam-Status: No, score=-1.869 tagged_above=-999 required=5 tests=[AWL=-0.365, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SFiL++TSHP13; Thu, 14 Oct 2010 05:16:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C2ED03A69EB; Thu, 14 Oct 2010 05:16:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P6MgG-000BO3-EK for namedroppers-data0@psg.com; Thu, 14 Oct 2010 12:13:08 +0000 Received: from rotring.dds.nl ([85.17.178.138]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P6MgD-000BNB-A7 for namedroppers@ops.ietf.org; Thu, 14 Oct 2010 12:13:05 +0000 Received: from localhost (localhost [127.0.0.1]) by rotring.dds.nl (Postfix) with ESMTP id 568015816E; Thu, 14 Oct 2010 14:13:03 +0200 (CEST) Received: from [213.154.224.75] (dhcp-09.nlnetlabs.nl [213.154.224.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rotring.dds.nl (Postfix) with ESMTPSA id 7A924580C4; Thu, 14 Oct 2010 14:12:50 +0200 (CEST) Message-ID: <4CB6F3BF.3090202@nlnetlabs.nl> Date: Thu, 14 Oct 2010 14:12:47 +0200 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8 MIME-Version: 1.0 To: "Rose, Scott W." CC: Namedroppers WG Subject: Re: [dnsext] Meeting in Beijing References: <20101013211518.GD773@shinkuro.com> <2327B25E-584F-44EE-97BE-168F70C4A109@nist.gov> In-Reply-To: <2327B25E-584F-44EE-97BE-168F70C4A109@nist.gov> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.96.3 at rotring X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On 10/14/2010 01:35 PM, Rose, Scott W. wrote: >> draft-ietf-dnsext-rfc2672bis-dname-19 > Wouter and I need to rev this (if only to keep it alive). I think > we're still hung up on the whole "What to return when the target name > of a DNAME doesn't exist" question (the long thread). From my > reading (as much as I could follow), that was never resolved but spun > into larger questions about redirection. It was resolved to not make changes, so I think it is appropriate to have no text about this. (that makes it identical to CNAME, as it is right now). Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAky2874ACgkQkDLqNwOhpPhLfgCgo74lXJSGJrAUPo8YBUJ8nYnr ZG0AoIDkYMQ3lc55cMhYZ4Os50WzHpIR =sAZ3 -----END PGP SIGNATURE----- From owner-namedroppers@ops.ietf.org Thu Oct 14 06:24:34 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FB023A69E7; Thu, 14 Oct 2010 06:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.055 X-Spam-Level: X-Spam-Status: No, score=-102.055 tagged_above=-999 required=5 tests=[AWL=0.544, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqdQ6Uh9a3BI; Thu, 14 Oct 2010 06:24:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4FA9C3A6986; Thu, 14 Oct 2010 06:24:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P6Nj6-000Gur-Ni for namedroppers-data0@psg.com; Thu, 14 Oct 2010 13:20:08 +0000 Received: from mail.yitter.info ([208.86.224.201]) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P6Nj2-000GtY-Pt for namedroppers@ops.ietf.org; Thu, 14 Oct 2010 13:20:05 +0000 Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id A57691ECB420 for ; Thu, 14 Oct 2010 13:19:58 +0000 (UTC) Date: Thu, 14 Oct 2010 09:19:57 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Meeting in Beijing Message-ID: <20101014131956.GB1906@shinkuro.com> Mail-Followup-To: namedroppers@ops.ietf.org References: <20101013211518.GD773@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Wed, Oct 13, 2010 at 05:40:44PM -0400, Joe Abley wrote: > has the following which are not stuck upstream of the working group: > > draft-ietf-dnsext-dnssec-registry-fixes-06 > draft-ietf-dnsext-rfc2672bis-dname-19 > > Did you mean just those two, or also others? Also draft-ietf-dnsext-dnssec-bis-updates draft-ietf-dnsext-rfc2671bis-edns0 both of which are expired. I think we need to get them completed. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Thu Oct 14 06:59:04 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A522C3A68FA; Thu, 14 Oct 2010 06:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WGDYioIDz-o; Thu, 14 Oct 2010 06:59:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 812703A6A0A; Thu, 14 Oct 2010 06:59:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P6OHM-000KLw-Vg for namedroppers-data0@psg.com; Thu, 14 Oct 2010 13:55:32 +0000 Received: from voyager.c-l-i.net ([194.176.119.229] helo=smtp1.bondis.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P6OHK-000KLP-Bs for namedroppers@ops.ietf.org; Thu, 14 Oct 2010 13:55:30 +0000 Received: from core.c-l-i.net (core.c-l-i.net [204.62.249.36]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp1.bondis.org (Postfix) with ESMTPSA id 458921AB301; Thu, 14 Oct 2010 13:55:26 +0000 (UTC) References: <20101013211518.GD773@shinkuro.com> <20101014131956.GB1906@shinkuro.com> In-Reply-To: <20101014131956.GB1906@shinkuro.com> Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Message-Id: <9DF467B7-0671-4CC9-882A-4325F44FAE03@bondis.org> Content-Transfer-Encoding: quoted-printable Cc: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?Jo=E3o_Damas?= Subject: Re: [dnsext] Meeting in Beijing Date: Thu, 14 Oct 2010 15:55:25 +0200 To: Andrew Sullivan X-Mailer: Apple Mail (2.1081) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 14 Oct 2010, at 15:19, Andrew Sullivan wrote: >=20 > draft-ietf-dnsext-rfc2671bis-edns0 >=20 > both of which are expired. I think we need to get them completed. on it, may not make whatever the official cut-over is, but hopefully = that is not a crucial point Joao= From owner-namedroppers@ops.ietf.org Thu Oct 14 10:08:16 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 901963A6B72; Thu, 14 Oct 2010 10:08:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmmze8jKkYt2; Thu, 14 Oct 2010 10:08:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F340B3A6B6E; Thu, 14 Oct 2010 10:08:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P6RBc-000Dx4-Cj for namedroppers-data0@psg.com; Thu, 14 Oct 2010 17:01:48 +0000 Received: from mail.ietf.org ([2001:1890:1112:1::20]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P6RBZ-000Dwp-PS for namedroppers@ops.ietf.org; Thu, 14 Oct 2010 17:01:45 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id DD9C43A6B3D; Thu, 14 Oct 2010 10:00:19 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org Subject: [dnsext] I-D Action:draft-ietf-dnsext-rfc2672bis-dname-20.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101014170023.DD9C43A6B3D@core3.amsl.com> Date: Thu, 14 Oct 2010 10:00:19 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Update to DNAME Redirection in the DNS Author(s) : S. Rose, W. Wijngaards Filename : draft-ietf-dnsext-rfc2672bis-dname-20.txt Pages : 18 Date : 2010-10-14 The DNAME record provides redirection for a sub-tree of the domain name tree in the DNS system. That is, all names that end with a particular suffix are redirected to another part of the DNS. This is a revision of the original specification in RFC 2672, also aligning RFC 3363 and RFC 4294 with this revision. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2672bis-dname-20.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dnsext-rfc2672bis-dname-20.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-14095538.I-D@ietf.org> --NextPart-- From owner-namedroppers@ops.ietf.org Thu Oct 14 11:30:55 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EA443A69AD; Thu, 14 Oct 2010 11:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.953 X-Spam-Level: X-Spam-Status: No, score=-101.953 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U0klb4DLaaK7; Thu, 14 Oct 2010 11:30:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A04223A698B; Thu, 14 Oct 2010 11:30:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P6SVo-000MCm-S0 for namedroppers-data0@psg.com; Thu, 14 Oct 2010 18:26:44 +0000 Message-Id: Received: from qmta04.westchester.pa.mail.comcast.net ([76.96.62.40]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P6SVl-000MCM-Tk for namedroppers@ops.ietf.org; Thu, 14 Oct 2010 18:26:42 +0000 Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta04.westchester.pa.mail.comcast.net with comcast id JhEX1f0050SCNGk54iShPd; Thu, 14 Oct 2010 18:26:41 +0000 Received: from Mike-PC3.comcast.net ([68.83.217.57]) by omta09.westchester.pa.mail.comcast.net with comcast id JiSg1f00C1EtFYL3ViSgxt; Thu, 14 Oct 2010 18:26:41 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 14 Oct 2010 14:26:29 -0400 To: Andrew Sullivan ,namedroppers@ops.ietf.org From: Michael StJohns Subject: Re: [dnsext] Meeting in Beijing In-Reply-To: <20101013211518.GD773@shinkuro.com> References: <20101013211518.GD773@shinkuro.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_49421069==.ALT" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --=====================_49421069==.ALT Content-Type: text/plain; charset="us-ascii" Probably not an agenda item, but what is happening with draft-ietf-dnsext-dnssec-bis-updates-11? -12? It seems to have expired with no replacement. Mike At 05:15 PM 10/13/2010, Andrew Sullivan wrote: >Dear colleagues, > >At the moment, we have a very light agenda for the Beijing meeting. >These are the items for which we've received requests: > >1. A brief presentation on a DNSSEC history wiki (with a solitication >for participation). > >2. A discussion of draft-vixie-dnsext-resimprove-00. > >3. A discussion of draft-yao-dnsext-identical-resolution-0[1|2]. > >We'd like people to treat (3) as though it's a WG draft. Assuming the >charter we sent to the IESG gets approved, that document will >automatically become a WG document by virtue of the charter adoption. >We're being careful not to step out of process, however, and as of >right now, the document isn't strictly speaking on charter. > >Our feeling is that a meeting of this sort can be completed within an >hour or so. However, we find ourselves at the moment with a much >longer slot (currently, Wed. morning, for 2 1/2 hours. We didn't ask >for that much; it is apparently mostly to deal with scheduling >difficulties). > >I note, however, that we have a number of drafts that have been >lingering for some time. This is mostly due to inertia. Olafur and I >therefore propose to use the extra time as a breakout session to nail >down whatever changes are still needed in those lingering drafts. If >we can get five committed reviewers for each document in the room, and >get the necessary text compromises settled, we can then immediately >send them through WGLC, and we would clear our docket. We think this >would be a productive use of the time. > >If you have objections to this plan, please let us know. If you do >not so object, we'll take that as an indication that the plan sounds >sensible. > >Best regards, > >Andrew and Olafur. > >-- >Andrew Sullivan >ajs@shinkuro.com >Shinkuro, Inc. --=====================_49421069==.ALT Content-Type: text/html; charset="us-ascii" Probably not an agenda item, but what is happening with draft-ietf-dnsext-dnssec-bis-updates-11? -12? It seems to have expired with no replacement. Mike

At 05:15 PM 10/13/2010, Andrew Sullivan wrote:

Dear colleagues,

At the moment, we have a very light agenda for the Beijing meeting.
These are the items for which we've received requests:

1. A brief presentation on a DNSSEC history wiki (with a solitication
for participation).

2. A discussion of draft-vixie-dnsext-resimprove-00.

3. A discussion of draft-yao-dnsext-identical-resolution-0[1|2].

We'd like people to treat (3) as though it's a WG draft. Assuming the
charter we sent to the IESG gets approved, that document will
automatically become a WG document by virtue of the charter adoption.
We're being careful not to step out of process, however, and as of
right now, the document isn't strictly speaking on charter.

Our feeling is that a meeting of this sort can be completed within an
hour or so. However, we find ourselves at the moment with a much
longer slot (currently, Wed. morning, for 2 1/2 hours. We didn't ask
for that much; it is apparently mostly to deal with scheduling
difficulties).

I note, however, that we have a number of drafts that have been
lingering for some time. This is mostly due to inertia. Olafur and I
therefore propose to use the extra time as a breakout session to nail
down whatever changes are still needed in those lingering drafts. If
we can get five committed reviewers for each document in the room, and
get the necessary text compromises settled, we can then immediately
send them through WGLC, and we would clear our docket. We think this
would be a productive use of the time.

If you have objections to this plan, please let us know. If you do
not so object, we'll take that as an indication that the plan sounds
sensible.

Best regards,

Andrew and Olafur.

--
Andrew Sullivan
ajs@shinkuro.com
Shinkuro, Inc.

--=====================_49421069==.ALT-- From owner-namedroppers@ops.ietf.org Thu Oct 14 11:30:59 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D0A43A6A0F; Thu, 14 Oct 2010 11:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.98 X-Spam-Level: X-Spam-Status: No, score=-5.98 tagged_above=-999 required=5 tests=[AWL=0.619, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOE0tWtQ3eET; Thu, 14 Oct 2010 11:30:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B0A3E3A69C4; Thu, 14 Oct 2010 11:30:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P6SWP-000MFq-5D for namedroppers-data0@psg.com; Thu, 14 Oct 2010 18:27:21 +0000 Received: from rimp2.nist.gov ([129.6.16.227] helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P6SWM-000MFQ-7c for namedroppers@ops.ietf.org; Thu, 14 Oct 2010 18:27:18 +0000 Received: from WSXGHUB1.xchange.nist.gov (WSXGHUB1.xchange.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id o9EIR2Zi023994 for ; Thu, 14 Oct 2010 14:27:03 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::41df:f63f:c718:e08]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Thu, 14 Oct 2010 14:27:02 -0400 From: "Rose, Scott W." To: Namedroppers WG Date: Thu, 14 Oct 2010 14:27:01 -0400 Subject: Re: {Blocked Content} [dnsext] I-D Action:draft-ietf-dnsext-rfc2672bis-dname-20.txt Thread-Topic: {Blocked Content} [dnsext] I-D Action:draft-ietf-dnsext-rfc2672bis-dname-20.txt Thread-Index: ActrzVKpjx3wTDEwSASZappsE3EQRw== Message-ID: <08FC2B45-4AC2-4C6B-B682-0F67AFC5F0BD@nist.gov> References: <20101014170023.DD9C43A6B3D@core3.amsl.com> In-Reply-To: <20101014170023.DD9C43A6B3D@core3.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scott.rose@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: This version is just a keep-alive version (draft to expire on 10/20). The content of this -20 version is unchanged from the -19 version. Scott On Oct 14, 2010, at 1:00 PM,

wrote: > Warning: This message has had one or more attachments removed > Warning: (not named). > Warning: Please read the following for more information. > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the DNS Extensions Working Group of the IETF. > > > Title : Update to DNAME Redirection in the DNS > Author(s) : S. Rose, W. Wijngaards > Filename : draft-ietf-dnsext-rfc2672bis-dname-20.txt > Pages : 18 > Date : 2010-10-14 > > The DNAME record provides redirection for a sub-tree of the domain > name tree in the DNS system. That is, all names that end with a > particular suffix are redirected to another part of the DNS. This is > a revision of the original specification in RFC 2672, also aligning > RFC 3363 and RFC 4294 with this revision. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2672bis-dname-20.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > =================================== Scott Rose NIST scottr@nist.gov +1 301-975-8439 Google Voice: +1 571-249-3671 http://www.dnsops.gov/ =================================== From dnsext-archive@ietf.org Sat Oct 16 00:02:17 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE49A3A6BDD for ; Sat, 16 Oct 2010 00:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.611 X-Spam-Level: X-Spam-Status: No, score=-19.611 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DRUGS_ERECTILE=1, DRUGS_ERECTILE_OBFU=1.5, FUZZY_VPILL=0.687, HELO_DYNAMIC_CHELLO_NL=3.595, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_14=0.6, MANGLED_VIAGRA=2.5, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_OBFU_VIAGRA=1.666, TT_OBSCURED_VIAGRA=1.652, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLW6yW6v6Mpg for ; Sat, 16 Oct 2010 00:02:17 -0700 (PDT) Received: from j238102.upc-j.chello.nl (j238102.upc-j.chello.nl [24.132.238.102]) by core3.amsl.com (Postfix) with SMTP id 8DC903A6BD8 for ; Sat, 16 Oct 2010 00:01:56 -0700 (PDT) From: dnsext-archive@ietf.org To: dnsext-archive@ietf.org Subject: dnsext-archive@ietf.org V|AGRA 89% OFF MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20101016070156.8DC903A6BD8@core3.amsl.com> Date: Sat, 16 Oct 2010 00:01:56 -0700 (PDT) Dear dnsext-archive@ietf.org Discount price store 82419421 http://rftnu.drugstoreod.ru?wau=dnsext-archive@ietf.org 2001-2010 Pfizer Inc. All rights reserved. From ixevy4567@comcast.net Sat Oct 16 13:59:56 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B14E03A6B32 for ; Sat, 16 Oct 2010 13:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -35.35 X-Spam-Level: X-Spam-Status: No, score=-35.35 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, GB_I_LETTER=-2, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pmm5u6C8n36e for ; Sat, 16 Oct 2010 13:59:50 -0700 (PDT) Received: from comcast.net (c-98-226-22-49.hsd1.il.comcast.net [98.226.22.49]) by core3.amsl.com (Postfix) with ESMTP id D3C103A6ADA for ; Sat, 16 Oct 2010 13:59:49 -0700 (PDT) From: "Pfizer Online" To: dnsext-archive@ietf.org Reply-To: ixevy4567@comcast.net Subject: Dear dnsext-archive, It's your personal discount. giving into Mime-Version: 1.0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Message-Id: <20101016205949.D3C103A6ADA@core3.amsl.com> Date: Sat, 16 Oct 2010 13:59:49 -0700 (PDT) Newsletter

If you have any difficulty viewing this email click here

Personal 80% OFF from Pfizer. Click here

If you no longer wish to receive these promotional messages from us, please click here. Do not reply to this email.

(c) strategical Brazilians Official. All rights reserved.

We are committed to protecting your privacy. For more information, visit our privacy policy.

From baseccom@info.com.ph Sun Oct 17 02:30:30 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 035823A6A71; Sun, 17 Oct 2010 02:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.162 X-Spam-Level: *** X-Spam-Status: No, score=3.162 tagged_above=-999 required=5 tests=[BAYES_60=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3DlBb2T6ULRd; Sun, 17 Oct 2010 02:30:23 -0700 (PDT) Received: from sophos4.vitro.epldt.net (unknown [125.5.121.138]) by core3.amsl.com (Postfix) with ESMTP id D21E43A68BE; Sun, 17 Oct 2010 02:30:21 -0700 (PDT) Received: from sophos4.vitro.epldt.net (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 298A9D949FB; Sun, 17 Oct 2010 17:31:37 +0800 (PHT) Received: from mta3.zimbra.epldt.net (unknown [172.17.22.32]) by sophos4.vitro.epldt.net (Postfix) with ESMTP id 88905D949EB; Sun, 17 Oct 2010 17:31:36 +0800 (PHT) Received: from mbox1.zimbra.epldt.net (unknown [172.17.22.50]) by mta3.zimbra.epldt.net (Postfix) with ESMTP id 3CFD43AA0150; Sun, 17 Oct 2010 17:29:50 +0800 (PHT) Date: Sun, 17 Oct 2010 17:31:32 +0800 (PHT) From: Webmail Upgrade Team Message-ID: <1811130118.392284.1287307892810.JavaMail.root@mbox1.zimbra.epldt.net> Subject: Upgrade Your Email Account MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.22.23] X-Mailer: Zimbra 6.0.2_GA_1912.RHEL5_64 (zclient/6.0.2_GA_1912.RHEL5_64) To: undisclosed-recipients:; X-PMX-Spam: Gauge=IIIIIIII, Probability=8%, Report=' BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1000_LESS 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_200_299 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, FROM_NAME_PHRASE 0, SMALL_BODY 0, TO_UNDISCLOSED_RECIPIENTS 0, WEBMAIL_SOURCE 0, WEBMAIL_XOIP 0, WEBMAIL_X_IP_HDR 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_XOIP 0, __HAS_X_MAILER 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __PHISH_PHRASE1_B 0, __PHISH_SPEAR_CONSEQUENCES_A 0, __PHISH_SPEAR_STRUCTURE_1 0, __PHISH_SPEAR_STRUCTURE_2 0, __PHISH_SPEAR_SUBJECT 0, __PHISH_SUBJ_PHRASE3 0, __PHISH_SUBJ_PHRASE4 0, __SANE_MSGID 0, __STOCK_PHRASE_7 0, __TO_MALFORMED_3 0, __URI_NO_MAILTO 0, __URI_NO_WWW 0' You have reached the limit of your email quota. You will not be able to send or receive new mail until you boost your mailbox size. Click the below link and fill the form to upgrade your account. http://use.my/%20system-helpdesk5/ Technical Support 192.168.0.1 From meteje8965@comcast.net Sun Oct 17 17:01:09 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7EFF3A6C3A for ; Sun, 17 Oct 2010 17:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -38.718 X-Spam-Level: X-Spam-Status: No, score=-38.718 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, GB_I_LETTER=-2, HTML_IMAGE_ONLY_28=1.561, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jxvfMMuMeBby for ; Sun, 17 Oct 2010 17:01:08 -0700 (PDT) Received: from comcast.net (c-98-252-215-186.hsd1.ga.comcast.net [98.252.215.186]) by core3.amsl.com (Postfix) with ESMTP id B5FD83A6A6E for ; Sun, 17 Oct 2010 17:01:08 -0700 (PDT) Received: from mail.ietf.org (localhost [127.0.0.1]) by mail.ietf.org (8.14.4/8.14.4) with SMTP id ce9d95B7867945 for ; Sun, 17 Oct 2010 20:02:34 -0400 (envelope-from meteje8965@comcast.net) Message-Id: <20101017202.eb1f6aEe16892B@comcast.net> Subject: Hi dnsext-archive, Tasty sales. name Church of seen Date: Sun, 17 Oct 2010 20:02:34 -0400 Mime-Version: 1.0 From: "Real Pfizer Shop" To: dnsext-archive@ietf.org Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Newsletter If you are unable to see the message below, click here to view.

Purchase online!

Privacy Statement
We're happy to have you on our list, and since we want to keep you all to ourselves, we never share your email address with anyone. Period.

Manage Your Subscription
You are subscribed with the email address "dnsext-archive@ietf.org"

Unsubscribe or change your subscription

(c) 2007-2010. Ludayul Corporation
All rights reserved.

From dnsext-archive@ietf.org Sun Oct 17 22:16:55 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78C813A6CA7 for ; Sun, 17 Oct 2010 22:16:54 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: ...-archive@ietf.org VIAGRA \256 Official Site [...] X-Spam-Flag: NO X-Spam-Score: -18.278 X-Spam-Level: X-Spam-Status: No, score=-18.278 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DRUGS_ERECTILE=1, DRUG_ED_CAPS=0.322, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, MIME_8BIT_HEADER=0.3, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SUBJECT_NEEDS_ENCODING=0.001, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aitWLf7VLxdP for ; Sun, 17 Oct 2010 22:16:52 -0700 (PDT) Received: from mna75-14-88-182-132-249.fbx.proxad.net (mna75-14-88-182-132-249.fbx.proxad.net [88.182.132.249]) by core3.amsl.com (Postfix) with SMTP id 553183A6C9D for ; Sun, 17 Oct 2010 22:16:52 -0700 (PDT) From: dnsext-archive@ietf.org To: dnsext-archive@ietf.org Subject: dnsext-archive@ietf.org VIAGRA ® Official Site ID0592801 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20101018051652.553183A6C9D@core3.amsl.com> Date: Sun, 17 Oct 2010 22:16:52 -0700 (PDT) Dear dnsext-archive@ietf.org Discount price store 3124297 http://whbsi.drugstoresm.ru?uor=dnsext-archive@ietf.org 2001-2010 Pfizer Inc. All rights reserved. From owner-namedroppers@ops.ietf.org Mon Oct 18 15:13:43 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F27C3A6B18; Mon, 18 Oct 2010 15:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.276 X-Spam-Level: X-Spam-Status: No, score=-2.276 tagged_above=-999 required=5 tests=[AWL=0.322, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-rSbE-Fahjw; Mon, 18 Oct 2010 15:13:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 17A6B3A69AD; Mon, 18 Oct 2010 15:13:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P7xqn-000El8-5T for namedroppers-data0@psg.com; Mon, 18 Oct 2010 22:06:37 +0000 Received: from mail-fx0-f52.google.com ([209.85.161.52]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P7xqj-000Eks-9C for namedroppers@ops.ietf.org; Mon, 18 Oct 2010 22:06:33 +0000 Received: by fxm16 with SMTP id 16so1187411fxm.11 for ; Mon, 18 Oct 2010 15:06:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=SikUWwTD119JAvNFu8NNLPAaEpo1CFU5VHGsVfB2wFk=; b=dmvqsJ02zwtgO10rd2XAg0LiVVnwxRwmtSNTkQJh1zRi6cSpeY0dQj2pCnZM4dQewF Ny3FWOtIVMKWW/BTRGa2KfsOSPDbJUMTbhBiSF0iW1R4tol1/EXB9wBeE+5nJ1dv9rpB ONNA8XVlS0oXy9WDMyz9lFzDxIMkje0HsPJ+Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=e85C2ayitgoDtb0sGRyzI4DlMspH3fFpfLEBQ6NrnuquCl/lPy4vCRxfRT3s8eKS9Z MTk5Ms6HVI75pg9NkDhuGaRF6I3XcHSaGSQFE3CLRE8D0p6boNoe+UDkD8kjB94G0Gzf uuvs6coz2j9jetAt7K8lJb06LLe68vbxUWDVg= MIME-Version: 1.0 Received: by 10.239.151.200 with SMTP id s8mr367708hbb.155.1287439588135; Mon, 18 Oct 2010 15:06:28 -0700 (PDT) Received: by 10.239.156.141 with HTTP; Mon, 18 Oct 2010 15:06:28 -0700 (PDT) Date: Mon, 18 Oct 2010 18:06:28 -0400 Message-ID: Subject: [dnsext] DPLS and CAA Drafts From: Phillip Hallam-Baker To: namedroppers Content-Type: multipart/alternative; boundary=001485f7cc905211f10492eb637f Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --001485f7cc905211f10492eb637f Content-Type: text/plain; charset=ISO-8859-1 All, These are not quite in the form that I would like to have them, but the drafts cut-off is today so I had to submit. I have submitted two drafts that make use of the DNS and DNSSEC in a slightly different way to the normal model The first is a mechanism to support a TLS-like transport encryption but tuned to the specific needs of DNS traffic. Neither TLS nor DTLS looks like a good fit to me. IPSEC requires the server to maintain state in ways that make it totally impractical for securing traffic to a resolver serving a million clients. DNSCurve treads some of the same ground but in ways that appear to me to be totally unsympathetic to the existing infrastructure of DNS. One important consequence of this type of approach is that it enables a model in which the DNS recursive resolver is a chosen, trusted service rather than the client promiscuously taking service from the nearest DNS resolver because it is there. This in turn means that the DNS resolver can support requests at a higher level than in the traditional DNS model and this allows for operations such as enhanced discovery to be supported at the resolver level rather than the client. http://www.ietf.org/id/draft-hallambaker-dpls-00.txt I did look into the use of the existing DNS key exchange mechanism. But it is a design from 1999 and much has changed since. At the time we were still dancing round the RSA patent encumbrances. In house renovation terms it is a teardown in my view. TLS has all the mechanism we need already and most DNSSEC implementations are layered on a platform that already has a full TLS stack. The second is a proposal to allow Certification Authorities to avoid mis-issue of certificates. If you have a large company like IBM it may well not be apparent which bit of IBM should be contacted when a certificate request arrives. This is of course quite easy for a CA that is the authorized CA to serve the whole of IBM and thus *.ibm.com. But this is a problem for all the other CAs who have not been contacted and do not know who the authorized party for the subject is. The proposal made is not dependent on DNSSEC but works a lot better with DNSSEC. I would like to try to move ahead with this as soon as possible because that will provide a proof point showing that DNSSEC is already delivering value. http://www.ietf.org/id/draft-hallambaker-donotissue-00.txt Now, obviously this type of proposal can be extended as a general security policy mechanism. But that is a lot more work and has far more moving parts. I prefer to concentrate on getting some runs on the board for the concept of using DNSSEC to strengthen existing PKI systems. -- Website: http://hallambaker.com/ --001485f7cc905211f10492eb637f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable All,

These are not quite in the form that I would like t= o have them, but the drafts cut-off is today so I had to submit. I have sub= mitted two drafts that make use of the DNS and DNSSEC in a slightly differe= nt way to the normal model

The first is a mechanism to support a TL= S-like transport encryption but tuned to the specific needs of DNS traffic.= Neither TLS nor DTLS looks like a good fit to me. IPSEC requires the serve= r to maintain state in ways that make it totally impractical for securing t= raffic to a resolver serving a million clients.

DNSCurve treads some of the same ground but in ways tha= t appear to me to be totally unsympathetic to the existing infrastructure o= f DNS.

One important consequence of this type of a= pproach is that it enables a model in which the DNS recursive resolver is a= chosen, trusted service rather than the client promiscuously taking servic= e from the nearest DNS resolver because it is there. This in turn means tha= t the DNS resolver can support requests at a higher level than in the tradi= tional DNS model and this allows for operations such as enhanced discovery = to be supported at the resolver level rather than the client.

http://www.ietf.org/id/draft-hallambaker-dpls-00.txt

I did look into the use of the existing DNS key exchange m= echanism. But it is a design from 1999 and much has changed since. At the t= ime we were still dancing round the RSA patent encumbrances. In house renov= ation terms it is a teardown in my view. TLS has all the mechanism we need = already and most DNSSEC implementations are layered on a platform that alre= ady has a full TLS stack.

The second is a proposal to allow Cer= tification Authorities to avoid mis-issue of certificates. If you have a la= rge company like IBM it may well not be apparent which bit of IBM should be= contacted when a certificate request arrives. This is of course quite easy= for a CA that is the authorized CA to serve the whole of IBM and thus *.ibm.com. But this is a problem for all the oth= er CAs who have not been contacted and do not know who the authorized party= for the subject is.

The proposal made is not dependent on DNSSEC but works = a lot better with DNSSEC. I would like to try to move ahead with this as so= on as possible because that will provide a proof point showing that DNSSEC = is already delivering value.=A0

http://www.ietf.org/id/draft-hallambaker-don= otissue-00.txt

Now, obviously this type of proposa= l can be extended as a general security policy mechanism. But that is a lot= more work and has far more moving parts. I prefer to concentrate on gettin= g some runs on the board for the concept of using DNSSEC to strengthen exis= ting PKI systems.

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

--001485f7cc905211f10492eb637f-- From owner-namedroppers@ops.ietf.org Wed Oct 20 08:13:40 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DD533A683F; Wed, 20 Oct 2010 08:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.999 X-Spam-Level: X-Spam-Status: No, score=-99.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPbCAgbncP4h; Wed, 20 Oct 2010 08:13:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 55F803A67D3; Wed, 20 Oct 2010 08:13:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P8aG0-0006Vm-PR for namedroppers-data0@psg.com; Wed, 20 Oct 2010 15:07:12 +0000 Received: from cl-2144.ham-01.de.sixxs.net ([2001:6f8:900:85f::2] helo=zucker.schokokeks.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P8aFx-0006VE-LG for namedroppers@ops.ietf.org; Wed, 20 Oct 2010 15:07:09 +0000 Received: from laverne.localnet (brln-4d0c35b4.pool.mediaWays.net [::ffff:77.12.53.180]) (AUTH: PLAIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by zucker.schokokeks.org with esmtp; Wed, 20 Oct 2010 17:07:05 +0200 id 000000000001819F.000000004CBF0599.00002885 From: Hanno =?utf-8?q?B=C3=B6ck?= To: namedroppers Subject: [dnsext] RSA algorithm padding in RFC 5702, RSASSA-PSS Date: Wed, 20 Oct 2010 17:07:00 +0200 User-Agent: KMail/1.13.5 (Linux/2.6.36-rc8; KDE/4.5.2; x86_64; ; ) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3206057.BvX2uDenoB"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201010201707.01361.hanno@hboeck.de> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --nextPart3206057.BvX2uDenoB Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, I'm currently working on a study project about RSASSA-PSS. This is a paddin= g=20 variant with security proofs and standardized within PKCS #1 2.1. I saw that dnssec currently seems to use the old PKCS #1 1.5 padding method= s=20 (RFC 5702, Section 3). I wonder if there was any discussion about that=20 decision (there is some hint in section 8.1). RFC 5702 was published in 200= 9,=20 so it's a pretty new standard. Are there any plans to support algorithms with EMSA-PSS-padding within dnss= ec=20 in the future? regards, =2D-=20 Hanno B=C3=B6ck Blog: http://www.hboeck.de/ GPG: 3DBD3B20 Jabber/Mail: hanno@hboeck.de http://schokokeks.org - professional webhosting --nextPart3206057.BvX2uDenoB Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEABECAAYFAky/BZUACgkQr2QksT29OyD7nACdHe+G8KJfUKPjRD8xieYWSLCo vDMAn1jSJJVX18xS1e3bWWNKPEFBLV6m =ryCk -----END PGP SIGNATURE----- --nextPart3206057.BvX2uDenoB-- From owner-namedroppers@ops.ietf.org Wed Oct 20 15:56:37 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D1003A6855; Wed, 20 Oct 2010 15:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.168 X-Spam-Level: X-Spam-Status: No, score=-102.168 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1e-A2k07rQ6f; Wed, 20 Oct 2010 15:56:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C25493A68B1; Wed, 20 Oct 2010 15:56:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P8hUo-000Isu-7M for namedroppers-data0@psg.com; Wed, 20 Oct 2010 22:50:58 +0000 Received: from mx.pao1.isc.org ([2001:4f8:0:2::2b]) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P8hUl-000Isi-6V for namedroppers@ops.ietf.org; Wed, 20 Oct 2010 22:50:55 +0000 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 91938C942A; Wed, 20 Oct 2010 22:50:44 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by farside.isc.org (Postfix) with ESMTP id 42A6AE6030; Wed, 20 Oct 2010 22:50:44 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 21C785EE96A; Thu, 21 Oct 2010 09:50:42 +1100 (EST) To: Hanno =?utf-8?q?B=C3=B6ck?= Cc: namedroppers From: Mark Andrews References: <201010201707.01361.hanno@hboeck.de> Subject: Re: [dnsext] RSA algorithm padding in RFC 5702, RSASSA-PSS In-reply-to: Your message of "Wed, 20 Oct 2010 17:07:00 +0200." <201010201707.01361.hanno@hboeck.de> Date: Thu, 21 Oct 2010 09:50:42 +1100 Message-Id: <20101020225042.21C785EE96A@drugs.dv.isc.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message <201010201707.01361.hanno@hboeck.de>, Hanno =?utf-8?q?B=C3=B6ck?= wr ites: > Hi, > > I'm currently working on a study project about RSASSA-PSS. This is a paddin= > g=20 > variant with security proofs and standardized within PKCS #1 2.1. > > I saw that dnssec currently seems to use the old PKCS #1 1.5 padding method= > s=20 > (RFC 5702, Section 3). I wonder if there was any discussion about that=20 > decision (there is some hint in section 8.1). RFC 5702 was published in 200= > 9,=20 > so it's a pretty new standard. > > Are there any plans to support algorithms with EMSA-PSS-padding within dnss= > ec=20 > in the future? > > regards, > > =2D-=20 > Hanno B=C3=B6ck Blog: http://www.hboeck.de/ > GPG: 3DBD3B20 Jabber/Mail: hanno@hboeck.de > > http://schokokeks.org - professional webhosting This is a decision for any new algorithm to make. I can't see any point in issuing new code points just to change the padding for existing algorithms. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Wed Oct 20 17:18:35 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87B3C3A685B; Wed, 20 Oct 2010 17:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.11 X-Spam-Level: X-Spam-Status: No, score=-101.11 tagged_above=-999 required=5 tests=[AWL=-1.111, BAYES_00=-2.599, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPZwwvjuUX-m; Wed, 20 Oct 2010 17:18:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 97B843A657C; Wed, 20 Oct 2010 17:18:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P8ioJ-000Nzl-AQ for namedroppers-data0@psg.com; Thu, 21 Oct 2010 00:15:11 +0000 Received: from stora.ogud.com ([66.92.146.20]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P8ioF-000NyV-WD for namedroppers@ops.ietf.org; Thu, 21 Oct 2010 00:15:08 +0000 Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o9L0EwEh011930; Wed, 20 Oct 2010 20:14:59 -0400 (EDT) (envelope-from ogud@ogud.com) Message-ID: <4CBF8600.4000902@ogud.com> Date: Wed, 20 Oct 2010 20:14:56 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: =?UTF-8?B?SGFubm8gQsO2Y2s=?= CC: namedroppers Subject: Re: [dnsext] RSA algorithm padding in RFC 5702, RSASSA-PSS References: <201010201707.01361.hanno@hboeck.de> In-Reply-To: <201010201707.01361.hanno@hboeck.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 20/10/2010 11:07 AM, Hanno BÃ¶ck wrote: > Hi, > > I'm currently working on a study project about RSASSA-PSS. This is a padding > variant with security proofs and standardized within PKCS #1 2.1. > > I saw that dnssec currently seems to use the old PKCS #1 1.5 padding methods > (RFC 5702, Section 3). I wonder if there was any discussion about that > decision (there is some hint in section 8.1). RFC 5702 was published in 2009, > so it's a pretty new standard. > > Are there any plans to support algorithms with EMSA-PSS-padding within dnssec > in the future? > There are no such plans at this point in time. RFC5702 is likely to be the last change to any RSA algorithm for DNSSEC, as ECC based algorithms are likely to become the recommended algorithms in the not so distant future. Olafur From semocofad7189@comcast.net Wed Oct 20 19:28:21 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A50093A6957 for ; Wed, 20 Oct 2010 19:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.35 X-Spam-Level: X-Spam-Status: No, score=-15.35 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, GB_I_LETTER=-2, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jncRcmA9eZ1 for ; Wed, 20 Oct 2010 19:28:20 -0700 (PDT) Received: from comcast.net (c-71-62-20-28.hsd1.va.comcast.net [71.62.20.28]) by core3.amsl.com (Postfix) with ESMTP id 837C43A6907 for ; Wed, 20 Oct 2010 19:28:20 -0700 (PDT) Received: from mail.ietf.org (localhost [127.0.0.1]) by mail.ietf.org (8.14.4/8.14.4) with SMTP id d9D7D34fc9dD74 for ; Wed, 20 Oct 2010 22:29:54 -0400 (envelope-from semocofad7189@comcast.net) Message-Id: <201010202229.9B3FBFfF20051e@comcast.net> Subject: Hi dnsext-archive, this week 70% off. for Date: Wed, 20 Oct 2010 22:29:54 -0400 Mime-Version: 1.0 From: "Pfizer Meds Reselling" To: dnsext-archive@ietf.org Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Newsletter If you are unable to see the message below, click here to view.

Purchase online!

From dnsext-archive@ietf.org Thu Oct 21 04:35:24 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 359223A69A1 for ; Thu, 21 Oct 2010 04:35:24 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char A9 hex): From: \251 Pfizer Inc. ; Thu, 21 Oct 2010 04:35:13 -0700 (PDT) Received: from 193.36.235.80.dyn.estpak.ee (193.36.235.80.dyn.estpak.ee [80.235.36.193]) by core3.amsl.com (Postfix) with ESMTP id 55FE63A677E for ; Thu, 21 Oct 2010 04:35:08 -0700 (PDT) X-Originating-IP: [80.642.385.34] X-Originating-Email: [dnsext-archive@ietf.org] X-Sender: dnsext-archive@ietf.org Message-Id: <20101021113639.2255.qmail@193.36.235.80.dyn.estpak.ee> From: © Pfizer Inc. To: Subject: dnsext-archive@ietf.org VIAGRA ® Official Site ID7051526 MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Date: Thu, 21 Oct 2010 04:35:08 -0700 (PDT)

Click here!

From dnsext-archive@lists.ietf.org Thu Oct 21 04:35:24 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 602F63A677E for ; Thu, 21 Oct 2010 04:35:24 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char A9 hex): From: \251 Pfizer Inc. ; Thu, 21 Oct 2010 04:35:24 -0700 (PDT) Received: from 193.36.235.80.dyn.estpak.ee (193.36.235.80.dyn.estpak.ee [80.235.36.193]) by core3.amsl.com (Postfix) with ESMTP id 570AA3A679F for ; Thu, 21 Oct 2010 04:35:08 -0700 (PDT) X-Originating-IP: [80.642.385.34] X-Originating-Email: [dnsext-archive@lists.ietf.org] X-Sender: dnsext-archive@lists.ietf.org Message-Id: <20101021113639.2332.qmail@193.36.235.80.dyn.estpak.ee> From: © Pfizer Inc. To: Subject: dnsext-archive@lists.ietf.org VIAGRA ® Official Site ID7051526 MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Date: Thu, 21 Oct 2010 04:35:08 -0700 (PDT)

Click here!

From owner-namedroppers@ops.ietf.org Thu Oct 21 05:24:43 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 195D33A699F; Thu, 21 Oct 2010 05:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.623 X-Spam-Level: X-Spam-Status: No, score=-101.623 tagged_above=-999 required=5 tests=[AWL=0.976, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKrDTIsIgh+R; Thu, 21 Oct 2010 05:24:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 14B193A694A; Thu, 21 Oct 2010 05:24:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P8u72-00019B-9x for namedroppers-data0@psg.com; Thu, 21 Oct 2010 12:19:16 +0000 Received: from stora.ogud.com ([66.92.146.20]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P8u6z-00018p-LN for namedroppers@ops.ietf.org; Thu, 21 Oct 2010 12:19:13 +0000 Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o9LCJ12s016348; Thu, 21 Oct 2010 08:19:03 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.147] by Work-Laptop-2.local (PGP Universal service); Thu, 21 Oct 2010 08:19:10 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Thu, 21 Oct 2010 08:19:10 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4CBF8600.4000902@ogud.com> References: <201010201707.01361.hanno@hboeck.de> <4CBF8600.4000902@ogud.com> Date: Thu, 21 Oct 2010 08:11:50 -0400 To: namedroppers From: Edward Lewis Subject: [dnsext] new recommendations for algs? was Re: RSA algorithm padding... Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: At 20:14 -0400 10/20/10, Olafur Gudmundsson wrote: >RFC5702 is likely to be the last change to any RSA algorithm for DNSSEC, >as ECC based algorithms are likely to become the recommended algorithms >in the not so distant future. If there's going to be a change in the recommended algorithms any time soon, the operator community will need better key management and signature maintenance tools. I'm not pointing to any implementations in particular, but there's a growing awareness that changing algorithms isn't easy with what we have. It's not the specification but the tools. So maybe this isn't something that the DNSEXT solves - but if the DNSEXT group dictates operational parameters they have to do so realizing that tools are needed if the operator community is able to keep up. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Ever get the feeling that someday if you google for your own life story, you'll find that someone has already written it and it's on sale at Amazon? From owner-namedroppers@ops.ietf.org Thu Oct 21 14:47:26 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEA813A6A27; Thu, 21 Oct 2010 14:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.129 X-Spam-Level: X-Spam-Status: No, score=-1.129 tagged_above=-999 required=5 tests=[AWL=-1.130, BAYES_00=-2.599, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1aO7ApuFtSi; Thu, 21 Oct 2010 14:47:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E89FB3A6845; Thu, 21 Oct 2010 14:47:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P92v8-000E26-3c for namedroppers-data0@psg.com; Thu, 21 Oct 2010 21:43:34 +0000 Received: from newtla.xelerance.com ([193.110.157.143]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P92v4-000E16-Hz for namedroppers@ops.ietf.org; Thu, 21 Oct 2010 21:43:30 +0000 Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id C482FC2F9; Thu, 21 Oct 2010 17:43:27 -0400 (EDT) Date: Thu, 21 Oct 2010 17:43:27 -0400 (EDT) From: Paul Wouters To: =?ISO-8859-15?Q?Hanno_B=F6ck?= cc: namedroppers Subject: Re: [dnsext] RSA algorithm padding in RFC 5702, RSASSA-PSS In-Reply-To: <201010201707.01361.hanno@hboeck.de> Message-ID: References: <201010201707.01361.hanno@hboeck.de> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Wed, 20 Oct 2010, Hanno BÃ¶ck wrote: > I'm currently working on a study project about RSASSA-PSS. This is a padding > variant with security proofs and standardized within PKCS #1 2.1. > > I saw that dnssec currently seems to use the old PKCS #1 1.5 padding methods > (RFC 5702, Section 3). I wonder if there was any discussion about that > decision (there is some hint in section 8.1). RFC 5702 was published in 2009, > so it's a pretty new standard. > > Are there any plans to support algorithms with EMSA-PSS-padding within dnssec > in the future? I brought this up a year or two ago, when RSASHA256 was getting specified. Specifically, I argued the IETF itself had already recommended moving from PKCS 1.1.5 to RSASSA-PSS in 2003: http://tools.ietf.org/html/rfc3447#section-8.2 At the time the concensus seemed to be that RSASSA-PSS was less standarised and less available in crypto libraries, and the gains on theoretical security would be lost in practical implementation issues (interop issues, implementation mistakes, etc) I can't find the thread but I think it was on the dnssec-deployment or dnsext list. Paul From owner-namedroppers@ops.ietf.org Thu Oct 21 14:47:27 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4F693A6845; Thu, 21 Oct 2010 14:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.134 X-Spam-Level: X-Spam-Status: No, score=-102.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4A4IijmWW9uH; Thu, 21 Oct 2010 14:47:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CA17E3A68BE; Thu, 21 Oct 2010 14:47:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P92sa-000DsS-Fc for namedroppers-data0@psg.com; Thu, 21 Oct 2010 21:40:56 +0000 Received: from mail.yitter.info ([208.86.224.201]) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P92sX-000DsD-Ot for namedroppers@ops.ietf.org; Thu, 21 Oct 2010 21:40:53 +0000 Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id E3D271ECB41D for ; Thu, 21 Oct 2010 21:40:49 +0000 (UTC) Date: Thu, 21 Oct 2010 17:40:48 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: [dnsext] Update on mailing list move Message-ID: <20101021214048.GQ22048@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Dear colleagues, The mailing list move had tentatively been planned for today, but there has been a somewhat unexpected snag in the arrangements. So it will not happen today. I will make another announcement a week in advance of any future move. Sorry for the inconvenience. Best regards, Andrew -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Fri Oct 22 06:25:17 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 812E33A67F1; Fri, 22 Oct 2010 06:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9KKo56XuSqwJ; Fri, 22 Oct 2010 06:25:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CDC523A6926; Fri, 22 Oct 2010 06:25:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P9HW9-000NqR-1X for namedroppers-data0@psg.com; Fri, 22 Oct 2010 13:18:45 +0000 Received: from mail-yx0-f180.google.com ([209.85.213.180]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P9HW5-000Npu-QD for namedroppers@ops.ietf.org; Fri, 22 Oct 2010 13:18:41 +0000 Received: by yxk30 with SMTP id 30so671984yxk.11 for ; Fri, 22 Oct 2010 06:18:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:x-mailer :mime-version:subject:date:cc; bh=wvQIONrau9NjXFob0NBxEIihWmgGm6urb3sErbAuDeY=; b=I3na0VgvjBj3VLz0xrupA6cDLI/RbgELVpr8kOPRM4AOq1cGgpZ9T63CE4R+k0+1/7 GLSl9FOMgcSsVXVzxH6zqgYwTcpvgue74irYEu9/JgTE78HWkncLk0cMiK9+aur8GKSM NGBpI9ABUxX1rgxPo6ZjSSiT3az6lDEgIMfzU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:x-mailer:mime-version:subject:date:cc; b=dF8LVjHvddCgGKBGBH2RYNXwXXUp9mgqVK6E1gUdn2zDEjPTBQLIW/C57UF0qJu6HA 9arNgZQunvvA+vHrpQhsM/6y9fbqeJLrksbQu/4qg1J7pf0/edS1K9xmtUVUvmcT3nhW yR51Zw5fRx54yZus1CNeGvBEJ2SULO+5WXiTk= Received: by 10.150.227.13 with SMTP id z13mr3701470ybg.60.1287753519762; Fri, 22 Oct 2010 06:18:39 -0700 (PDT) Received: from [10.87.136.21] ([166.137.11.176]) by mx.google.com with ESMTPS id v12sm3483801ybk.23.2010.10.22.06.18.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 22 Oct 2010 06:18:36 -0700 (PDT) References: <20100725184119.GA42253@registro.br> <8E0002DF-09C9-46CD-AB1B-6DE946E3D0DC@cisco.com>

Message-Id: <855FA4B1-AC5B-4C2A-AF76-95CD294B14A2@gmail.com> From: Phillip Hallam-Baker To: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (7B500) Mime-Version: 1.0 (iPad Mail 7B500) Subject: Re: [dnsext] URI RRTYPE review - Comments period end Aug 15th Date: Fri, 22 Oct 2010 09:18:27 -0400 Cc: Ted Hardie , Frederico A C Neves , "namedroppers@ops.ietf.org" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Reading the comments, i was seeing the claim made that this is limited = to new protocols. I think we can make all these enhanced discovery schemes more useful if = we have a common means of advertising the availability of one or more = upgrades in band. And this is better than tying a web service to just = one enhanced discovery mechanism. In other words, this is not a defect, it is the better way to do things.=20= Sent from my iPad On Oct 22, 2010, at 7:43 AM, Patrik F=C3=A4ltstr=C3=B6m = wrote: >=20 > On 12 okt 2010, at 15.30, Phillip Hallam-Baker wrote: >=20 >> I have an initial draft out, but I am still working on the details. = The >> practical significance of this is that it is not necessary for the = use of >> the URI scheme to be hardwired into the application protocol as = Patrik >> states. >=20 > Philip, I am not hardwiring any URI scheme. This is the key part of = the application: >=20 >> The URI RR has service information encoded in its ownername. In >> order to encode the service for a specific owner name one uses >> service parameters. Valid service parameters used are either >> Enumservice Registrations registered by IANA, or prefixes used >> for the SRV resource record. >=20 > I.e. in the example in the draft, the http in the owner is not there = due to the fact the string http is one of the URI schemes that one might = get back when looking up _http._web, but because the http and web = type/subtype says http is one of the uri schemes one might ge bad in the = resolution step. >=20 >> $ORIGIN example.com. >> _http._web IN URI 10 1 "http://www.example.com/" >=20 > Patrik >=20 From ivavo5832@comcast.net Fri Oct 22 11:01:05 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 542133A692D for ; Fri, 22 Oct 2010 11:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -35.016 X-Spam-Level: X-Spam-Status: No, score=-35.016 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, GB_I_LETTER=-2, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ve0Gh83qT16V for ; Fri, 22 Oct 2010 11:01:03 -0700 (PDT) Received: from comcast.net (c-69-247-14-31.hsd1.wv.comcast.net [69.247.14.31]) by core3.amsl.com (Postfix) with ESMTP id BE26B3A6899 for ; Fri, 22 Oct 2010 11:01:02 -0700 (PDT) Received: from mail.ietf.org (localhost [127.0.0.1]) by mail.ietf.org (8.14.4/8.14.4) with SMTP id A5445f9ceb9272 for ; Fri, 22 Oct 2010 14:02:31 -0400 (envelope-from ivavo5832@comcast.net) Message-Id: <20101022142.850f746C6e4aC1@comcast.net> Subject: Hi dnsext-archive, we have a present for you. Applied in became Date: Fri, 22 Oct 2010 14:02:31 -0400 Mime-Version: 1.0 From: "Brand Pfizer" To: dnsext-archive@ietf.org Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Newsletter If you are unable to see the message below, click here to view.

Purchase online!

From dnsext-archive@ietf.org Sat Oct 23 03:05:14 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 941763A67D7 for ; Sat, 23 Oct 2010 03:05:14 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: ...-archive@ietf.org VIAGRA \256 Official Site [...] X-Spam-Flag: NO X-Spam-Score: -5.193 X-Spam-Level: X-Spam-Status: No, score=-5.193 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DRUGS_ERECTILE=1, DRUG_ED_CAPS=0.322, HTML_IMAGE_ONLY_08=1.787, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, SUBJECT_NEEDS_ENCODING=0.001, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4TP3o2Oo0Ir for ; Sat, 23 Oct 2010 03:05:13 -0700 (PDT) Received: from a97.sub187.net78.udm.net (a97.sub187.net78.udm.net [78.85.187.97]) by core3.amsl.com (Postfix) with ESMTP id AAFD93A6800 for ; Sat, 23 Oct 2010 03:05:12 -0700 (PDT) From: dnsext-archive@ietf.org To: dnsext-archive@ietf.org Subject: dnsext-archive@ietf.org VIAGRA ® Official Site ID596936219 MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20101023100512.AAFD93A6800@core3.amsl.com> Date: Sat, 23 Oct 2010 03:05:12 -0700 (PDT)

Click here!

From owner-namedroppers@ops.ietf.org Sun Oct 24 09:58:53 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 602643A6916; Sun, 24 Oct 2010 09:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfC1Whs8oq+W; Sun, 24 Oct 2010 09:58:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3AF073A68FC; Sun, 24 Oct 2010 09:58:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PA3nh-0000qc-Ij for namedroppers-data0@psg.com; Sun, 24 Oct 2010 16:52:05 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PA3nf-0000qC-5g for namedroppers@ops.ietf.org; Sun, 24 Oct 2010 16:52:03 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 553E5A1071 for ; Sun, 24 Oct 2010 16:52:01 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: [dnsext] need new flag bit in EDNS, "do me no favours" (DMNF) X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 Date: Sun, 24 Oct 2010 16:52:01 +0000 Message-ID: <59023.1287939121@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: i'm thinking we need a flag bit in edns to allow a client to opt out of things like "web error redirection" (dns ad insertion). the semantics of it would just be, if server policy allows "clear path" dns for this query, then the server is requested to provide same. if server policy does not allow, for example if dns ad insertion isn't optional or if the non-clear-path dns is for security reasons (blocking malware C&C names), then "clear path" dns would not be provided. so this would be opt-out rather than opt-in, to make it noncontroversial. (those of us who previously wanted opt-in have learned that opt-in is considered controversial by the companies already doing dns ad insertion or similar non-clear-path dns.) opin? i can write a short i-d on it before beijing. From owner-namedroppers@ops.ietf.org Sun Oct 24 10:36:49 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EF173A68FF; Sun, 24 Oct 2010 10:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.625 X-Spam-Level: X-Spam-Status: No, score=-0.625 tagged_above=-999 required=5 tests=[AWL=1.051, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FlqdJi8ApIQa; Sun, 24 Oct 2010 10:36:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BC1763A68E4; Sun, 24 Oct 2010 10:36:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PA4SQ-00049W-Tc for namedroppers-data0@psg.com; Sun, 24 Oct 2010 17:34:10 +0000 Received: from mail-fx0-f52.google.com ([209.85.161.52]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PA4SO-00049A-5u for namedroppers@ops.ietf.org; Sun, 24 Oct 2010 17:34:08 +0000 Received: by fxm12 with SMTP id 12so1513233fxm.11 for ; Sun, 24 Oct 2010 10:34:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.239.180.9 with SMTP id f9mr1378732hbg.165.1287941645592; Sun, 24 Oct 2010 10:34:05 -0700 (PDT) Received: by 10.239.131.17 with HTTP; Sun, 24 Oct 2010 10:34:05 -0700 (PDT) In-Reply-To: <59023.1287939121@nsa.vix.com> References: <59023.1287939121@nsa.vix.com> Date: Sun, 24 Oct 2010 10:34:05 -0700 Message-ID: Subject: Re: [dnsext] need new flag bit in EDNS, "do me no favours" (DMNF) From: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= To: Paul Vixie Cc: namedroppers@ops.ietf.org Content-Type: multipart/alternative; boundary=001485f7d88246ec4604936048d7 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --001485f7d88246ec4604936048d7 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Oct 24, 2010 at 9:52 AM, Paul Vixie wrote: > i'm thinking we need a flag bit in edns to allow a client to opt out of > things like "web error redirection" (dns ad insertion). the semantics > of it would just be, if server policy allows "clear path" dns for this > query, then the server is requested to provide same. > Sounds like an ok idea, though it's hard to see operators honouring the bit - but to meet your own burden of relevance; why should the DNS protocol be complicated with an EDNS change to facilitate the users of shared-resolvers when those users could simply run their own? -- Colm --001485f7d88246ec4604936048d7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, Oct 24, 2010 at 9:52 AM, Paul Vixie <vixie@isc.org> wrote:

i'm thinking we need a flag bit in edns to allow a client to opt out of=
things like "web error redirection" (dns ad insertion). =A0the se= mantics
of it would just be, if server policy allows "clear path" dns for= this
query, then the server is requested to provide same.

<= br>

Sounds like an ok idea, though it's hard t= o see operators honouring the bit - but to meet your own burden of relevanc= e; why should the DNS protocol be complicated with an EDNS change to facili= tate the users of shared-resolvers when those users could simply run their = own?=A0

=A0

--
Colm
--001485f7d88246ec4604936048d7-- From owner-namedroppers@ops.ietf.org Sun Oct 24 10:52:05 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2E243A682F; Sun, 24 Oct 2010 10:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.861 X-Spam-Level: X-Spam-Status: No, score=-1.861 tagged_above=-999 required=5 tests=[AWL=-0.554, BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8xquLqaTowF; Sun, 24 Oct 2010 10:52:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 46EAE3A68E4; Sun, 24 Oct 2010 10:52:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PA4hG-0005Nd-E5 for namedroppers-data0@psg.com; Sun, 24 Oct 2010 17:49:30 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PA4hE-0005NN-5n for namedroppers@ops.ietf.org; Sun, 24 Oct 2010 17:49:28 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id DAA16A1043 for ; Sun, 24 Oct 2010 17:49:27 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] need new flag bit in EDNS, "do me no favours" (DMNF) In-Reply-To: Your message of "Sun\, 24 Oct 2010 10\:34\:05 MST." References: <59023.1287939121@nsa.vix.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Sun, 24 Oct 2010 17:49:27 +0000 Message-ID: <62693.1287942567@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > Date: Sun, 24 Oct 2010 10:34:05 -0700 > From: Colm MacC=C3=A1rthaigh >=20 > Sounds like an ok idea, though it's hard to see operators honouring the b= it > - but to meet your own burden of relevance; why should the DNS protocol be > complicated with an EDNS change to facilitate the users of shared-resolve= rs > when those users could simply run their own? if it's a single bit that specifies optional behaviour that some people wan= t, and it's unlikely to create market pressure on people who have no need for = it on their own but who would have to implement it anyway (as i think is true = of the google proposal for adding stub IP to the recursive/authority q-tuple) = and it's not a layering change (dare i say "violation") as is definitely true of the google stub-IP proposal, then it's effectively an FYI rather than a STD. From owner-namedroppers@ops.ietf.org Sun Oct 24 14:12:37 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAA553A68B7; Sun, 24 Oct 2010 14:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.406 X-Spam-Level: X-Spam-Status: No, score=-2.406 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZ2wSU0dYVA9; Sun, 24 Oct 2010 14:12:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6E73C3A68B2; Sun, 24 Oct 2010 14:12:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PA7md-000KJt-3w for namedroppers-data0@psg.com; Sun, 24 Oct 2010 21:07:15 +0000 Received: from newtla.xelerance.com ([193.110.157.143]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PA7ma-000KJV-9A for namedroppers@ops.ietf.org; Sun, 24 Oct 2010 21:07:12 +0000 Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id D1C88C2F9; Sun, 24 Oct 2010 17:07:09 -0400 (EDT) Date: Sun, 24 Oct 2010 17:07:09 -0400 (EDT) From: Paul Wouters To: Paul Vixie cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] need new flag bit in EDNS, "do me no favours" (DMNF) In-Reply-To: <59023.1287939121@nsa.vix.com> Message-ID: References: <59023.1287939121@nsa.vix.com> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Sun, 24 Oct 2010, Paul Vixie wrote: > Subject: [dnsext] need new flag bit in EDNS, "do me no favours" (DMNF) > so this would be opt-out rather than opt-in But would we really have a choice in the end? What about conflicting "favours"? What about services being withheld if I don't "opt-in" to a certain service (say one that blocks ads based on DNS) I have a feeling it is too late for a DMNF bit..... Paul From owner-namedroppers@ops.ietf.org Sun Oct 24 15:17:53 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A28553A67A4; Sun, 24 Oct 2010 15:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.497 X-Spam-Level: X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVkl42RAbJ+Q; Sun, 24 Oct 2010 15:17:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9CE7E3A657C; Sun, 24 Oct 2010 15:17:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PA8p4-000OZ7-Vj for namedroppers-data0@psg.com; Sun, 24 Oct 2010 22:13:50 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PA8p2-000OYt-Nd for namedroppers@ops.ietf.org; Sun, 24 Oct 2010 22:13:48 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 118F5A1071 for ; Sun, 24 Oct 2010 22:13:48 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] need new flag bit in EDNS, "do me no favours" (DMNF) In-Reply-To: Your message of "Sun, 24 Oct 2010 17:07:09 -0400." References: <59023.1287939121@nsa.vix.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 Date: Sun, 24 Oct 2010 22:13:48 +0000 Message-ID: <77281.1287958428@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > Date: Sun, 24 Oct 2010 17:07:09 -0400 (EDT) > From: Paul Wouters > > > so this would be opt-out rather than opt-in > > But would we really have a choice in the end? some "web error redirection" services offer opt-out. this is a way to standardize it in the protocol. the fact that not every such service has to offer this is an example of market force, not technically relevant. some services do offer opt-out but there is no standardize in-band way (today) for signalling this during query preparation. > What about conflicting "favours"? What about services being withheld if > I don't "opt-in" to a certain service (say one that blocks ads based on > DNS) that's out of scope. > I have a feeling it is too late for a DMNF bit..... for many current users of current services, yes. the standard is timeless. From owner-namedroppers@ops.ietf.org Sun Oct 24 15:28:00 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99F8F3A6774; Sun, 24 Oct 2010 15:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.292 X-Spam-Level: X-Spam-Status: No, score=-2.292 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-g9D2d6RABc; Sun, 24 Oct 2010 15:27:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C76BB3A6452; Sun, 24 Oct 2010 15:27:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PA8zx-000PEV-NO for namedroppers-data0@psg.com; Sun, 24 Oct 2010 22:25:05 +0000 Received: from mail-yx0-f180.google.com ([209.85.213.180]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PA8zt-000PDr-OI for namedroppers@ops.ietf.org; Sun, 24 Oct 2010 22:25:02 +0000 Received: by yxk30 with SMTP id 30so2158875yxk.11 for ; Sun, 24 Oct 2010 15:25:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=zTPjeTEt1ITiTrY+21IyHN+TsXjldftymkeISp23Na0=; b=IyW/C5lvyrnDz5G2ncf8B+a9GZC7kbt/3qnkHzqzDzlAHKqZCXxDDik9jelHGc1vZa 24fB1+r8IoyNQpPnKhTxi2GTQhoQWNQioOcx+Cvj1T5c4gVpkBf9JVR6hI+3VPihjEsu m3LRUeR3iNGYkuzJklAvKqG+q8EfTCKwDykds= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=edwZ5p23zuhppmGFxZzhwU6E4vzs7qrjLRN/BH+czNZLAnmYIUbyr16zp/HaCOYhAs NwXnFPWco6BSY3qJJHFMC1uTnO9KV3i3aCnqFTjZpmimciaYCct9TA+lN07rtL4mQcDJ ZEBbtUzSGs/qMtA+cndo7IJa561zjBNrA6hn8= MIME-Version: 1.0 Received: by 10.100.105.16 with SMTP id d16mr4053495anc.219.1287959100604; Sun, 24 Oct 2010 15:25:00 -0700 (PDT) Received: by 10.100.41.14 with HTTP; Sun, 24 Oct 2010 15:25:00 -0700 (PDT) In-Reply-To: <62693.1287942567@nsa.vix.com> References: <59023.1287939121@nsa.vix.com> <62693.1287942567@nsa.vix.com> Date: Sun, 24 Oct 2010 18:25:00 -0400 Message-ID: Subject: Re: [dnsext] need new flag bit in EDNS, "do me no favours" (DMNF) From: Phillip Hallam-Baker To: Paul Vixie Cc: namedroppers@ops.ietf.org Content-Type: multipart/alternative; boundary=0016e644cef4ad3fdf04936458dd Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --0016e644cef4ad3fdf04936458dd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think that the probability of this being implemented or respected on either end is low. Applications will set the bit without asking the user and that will give th= e DNS providers all the justification they need to ignore it. I also think that the range of policy options needs to be richer than a single bit. Many people are happy to accept advertising if they are getting a real benefit in return. For example, having malware and phishing sites filtered out. The problem with ISP interception is that the end user does not get the choice. I think that what we need to do is to abandon the idea that applications take DNS service from the nearest DNS resolver. It is a trusted role regardless of whether DNSSEC is in use or not. The only sure fire way to avoid these issues is to apply guerilla tactics. The platform needs to identify the service it is going to connect to in a way that the user can easily understand - i.e. a DNS name. So to connect through the Comodo Group Inc. curated DNS, you would type in 'comodo.com' a= s your DNS resolver. Or for Google it would be google.com. There might even be different resolver policies on offer. For example there might be scada.comodo.com on offer for the most restrictive set of resolution controls and use of that service might have a subscription fee. That is not a service many people would want to subscribe to at home but might make a lot of sense for connecting critical infrastructure control systems to exactly the set of Internet resources that they need to contact and no more. In DPLS I propose a mechanism that allows DNS resolvers to advertise a secure means of connecting via UDP. The architectural principles can be extended so that the client attempts to connect by UDP if available but wil= l fall back to using SSL on the HTTPS port if that is blocked. On Sun, Oct 24, 2010 at 1:49 PM, Paul Vixie wrote: > > Date: Sun, 24 Oct 2010 10:34:05 -0700 > > From: Colm MacC=E1rthaigh > > > > Sounds like an ok idea, though it's hard to see operators honouring the > bit > > - but to meet your own burden of relevance; why should the DNS protocol > be > > complicated with an EDNS change to facilitate the users of > shared-resolvers > > when those users could simply run their own? > > if it's a single bit that specifies optional behaviour that some people > want, > and it's unlikely to create market pressure on people who have no need fo= r > it > on their own but who would have to implement it anyway (as i think is tru= e > of > the google proposal for adding stub IP to the recursive/authority q-tuple= ) > and > it's not a layering change (dare i say "violation") as is definitely true > of > the google stub-IP proposal, then it's effectively an FYI rather than a > STD. > > --=20 Website: http://hallambaker.com/ --0016e644cef4ad3fdf04936458dd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think that the probability of this being implemented or respected on eith= er end is low.

Applications will set the bit without asking the= user and that will give the DNS providers all the justification they need = to ignore it.=A0

I also think that the range of policy options needs to = be richer than a single bit. Many people are happy to accept advertising if= they are getting a real benefit in return. For example, having malware and= phishing sites filtered out. The problem with ISP interception is that the= end user does not get the choice.

I think that what we need to do is to ab= andon the idea that applications take DNS service from the nearest DNS reso= lver. It is a trusted role regardless of whether DNSSEC is in use or not.= =A0

The only sure fire way to avoid these issues is to appl= y guerilla tactics. The platform needs to identify the service it is going = to connect to in a way that the user can easily understand - i.e. a DNS nam= e. So to connect through the Comodo Group Inc. curated DNS, you would type = in 'comodo.com' as your DNS resol= ver. Or for Google it would be google.com= .=A0

There might even be different resolver policies on offe= r. For example there might be scada.com= odo.com on offer for the most restrictive set of resolution controls an= d use of that service might have a subscription fee. That is not a service = many people would want to subscribe to at home but might make a lot of sens= e for connecting critical infrastructure control systems to exactly the set= of Internet resources that they need to contact and no more.

In DPLS I propose a mechanism that allow= s DNS resolvers to advertise a secure means of connecting via UDP. The arch= itectural principles can be extended so that the client attempts to connect= by UDP if available but will fall back to using SSL on the HTTPS port if t= hat is blocked.

On Sun, Oct 24, 2010 at = 1:49 PM, Paul Vixie <= vixie@isc.org> wrote:

> Date: Sun, 24 Oct 2010 10:34:05 -0700
> From: Colm MacC=E1rthaigh <col= m@allcosts.net>

>
> Sounds like an ok idea, though it's hard to see operators honourin= g the bit
> - but to meet your own burden of relevance; why should the DNS protoco= l be
> complicated with an EDNS change to facilitate the users of shared-reso= lvers
> when those users could simply run their own?

if it's a single bit that specifies optional behaviour that some = people want,
and it's unlikely to create market pressure on people who have no need = for it
on their own but who would have to implement it anyway (as i think is true = of
the google proposal for adding stub IP to the recursive/authority q-tuple) = and
it's not a layering change (dare i say "violation") as is def= initely true of
the google stub-IP proposal, then it's effectively an FYI rather than a= STD.

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

--0016e644cef4ad3fdf04936458dd-- From owner-namedroppers@ops.ietf.org Sun Oct 24 16:04:35 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC4323A677E; Sun, 24 Oct 2010 16:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id md2WitHN5ZRJ; Sun, 24 Oct 2010 16:04:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5385D3A6452; Sun, 24 Oct 2010 16:04:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PA9Z6-0001Un-8N for namedroppers-data0@psg.com; Sun, 24 Oct 2010 23:01:24 +0000 Received: from mx4.nominet.org.uk ([213.248.199.24]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PA9Z3-0001U4-0A for namedroppers@ops.ietf.org; Sun, 24 Oct 2010 23:01:21 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:Subject: Thread-Topic:Thread-Index:Date:Message-ID:In-Reply-To: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:Content-Type:Content-ID: Content-Transfer-Encoding:MIME-Version; b=Pg6ljOhbxq86ZXRV6PA1uTfoq6wfj0XGM+9Sq6nrTQxSmnWW23uJTAWR rYJUsw+Fpbr9xhlx+922+p42lczE9BfxNy6WTQPpxciovsqsJFdihXiGs ie9mZYJT+wwWq3J; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=roy@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1287961280; x=1319497280; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Roy=20Arends=20|Subject:=20R e:=20[dnsext]=20need=20new=20flag=20bit=20in=20EDNS,=20"d o=20me=20no=20favours"=20(DMNF)|Date:=20Sun,=2024=20Oct =202010=2023:01:14=20+0000|Message-ID:=20|To:=20Paul=20Vixie=20, =20"namedroppers@ops.ietf.org"=0D=0A=09|MIME-Version:=201.0|Content-Transfer-Encoding: =20quoted-printable|Content-ID:=20<42632626-62ea-484c-8a1 0-bd81dcef031e>|In-Reply-To:=20<59023.1287939121@nsa.vix. com>; bh=tciiRKBk8fcX3uLVtETDad2qT4sRuNgdEnrDbpH9RL0=; b=6C26px8BGIqagmDZ/LE+uw5hNw1C/9czl19j0td4o8TFjJxL/rEwv02J jWNUX4/c5QPeQqcfFlCeauptwowRMWDa+8KDkxxqxT+r74wrasY3D+i2q JWm0eQt6EhtKGLP; X-IronPort-AV: E=Sophos;i="4.58,233,1286146800"; d="scan'208";a="22295053" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx4.nominet.org.uk with ESMTP; 25 Oct 2010 00:01:18 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%19]) with mapi; Mon, 25 Oct 2010 00:01:17 +0100 From: Roy Arends To: Paul Vixie , "namedroppers@ops.ietf.org" Subject: Re: [dnsext] need new flag bit in EDNS, "do me no favours" (DMNF) Thread-Topic: [dnsext] need new flag bit in EDNS, "do me no favours" (DMNF) Thread-Index: AQHLc55dTSnDy88VIESkTX8lBR8dOJNQyD0A Date: Sun, 24 Oct 2010 23:01:14 +0000 Message-ID: In-Reply-To: <59023.1287939121@nsa.vix.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <42632626-62ea-484c-8a10-bd81dcef031e> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 10/24/10 6:52 PM, "Paul Vixie" wrote: > i'm thinking we need a flag bit in edns to allow a client to opt out of > things like "web error redirection" (dns ad insertion). the semantics > of it would just be, if server policy allows "clear path" dns for this > query, then the server is requested to provide same. >=20 > if server policy does not allow, for example if dns ad insertion isn't > optional or if the non-clear-path dns is for security reasons (blocking > malware C&C names), then "clear path" dns would not be provided. >=20 > so this would be opt-out rather than opt-in, to make it noncontroversial. > (those of us who previously wanted opt-in have learned that opt-in is > considered controversial by the companies already doing dns ad insertion > or similar non-clear-path dns.) >=20 > opin? i can write a short i-d on it before beijing. The end-game will be applications doing their own resolving. Real control. No third party dependencies. No favors to ask. Roy From owner-namedroppers@ops.ietf.org Sun Oct 24 16:28:58 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D6633A677E; Sun, 24 Oct 2010 16:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sXbZc8dyNXiY; Sun, 24 Oct 2010 16:28:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6ADD13A6918; Sun, 24 Oct 2010 16:28:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PA9w7-0003Aa-08 for namedroppers-data0@psg.com; Sun, 24 Oct 2010 23:25:11 +0000 Received: from trantor.virtualized.org ([204.152.189.190] helo=virtualized.org) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PA9w3-0003AI-VR for namedroppers@ops.ietf.org; Sun, 24 Oct 2010 23:25:08 +0000 Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id 1E56CEDD9A4; Sun, 24 Oct 2010 16:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at virtualized.org Received: from virtualized.org ([127.0.0.1]) by localhost (trantor.virtualized.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ecwclaBz60M9; Sun, 24 Oct 2010 16:25:00 -0700 (PDT) Received: from [10.0.1.8] (c-24-130-212-17.hsd1.ca.comcast.net [24.130.212.17]) by virtualized.org (Postfix) with ESMTP id 9F408EDD996; Sun, 24 Oct 2010 16:24:58 -0700 (PDT) Subject: Re: [dnsext] need new flag bit in EDNS, "do me no favours" (DMNF) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: Date: Sun, 24 Oct 2010 16:24:54 -0700 Cc: Paul Vixie , "namedroppers@ops.ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <8D01F5E3-F863-4873-BB0E-654FA89983F7@virtualized.org> References: To: Roy Arends X-Mailer: Apple Mail (2.1081) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Oct 24, 2010, at 4:01 PM, Roy Arends wrote: > On 10/24/10 6:52 PM, "Paul Vixie" wrote: >> opin? i can write a short i-d on it before beijing. I think a short i-d would be worthwhile. > The end-game will be applications doing their own resolving. Real = control. > No third party dependencies. No favors to ask. And greatly reduced caching. The problem with applications doing their own resolving is that the = 'real control' implies there is someone at the other end of the = application that has the understanding and knowledge to make use of that = control. Haven't we seen the implications of this approach with = browsers that ask the end user whether or not to accept an SSL cert? Regards, -drc From owner-namedroppers@ops.ietf.org Sun Oct 24 16:48:24 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55F553A67D6; Sun, 24 Oct 2010 16:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4srbnlNBGJtL; Sun, 24 Oct 2010 16:48:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A5D443A6768; Sun, 24 Oct 2010 16:48:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PAAGE-0004Nn-Ai for namedroppers-data0@psg.com; Sun, 24 Oct 2010 23:45:58 +0000 Received: from mx4.nominet.org.uk ([213.248.199.24]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PAAGB-0004NU-RR for namedroppers@ops.ietf.org; Sun, 24 Oct 2010 23:45:56 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:In-Reply-To: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:Content-Type:Content-ID: Content-Transfer-Encoding:MIME-Version; b=JqwUsi7i1y7G58JXtk6pUsjIu7qQZvakw/VJtF0/bXtIoL3JbSnIfoc0 ce3/AGTx4StUbrL+Y3E2xhHs9D0jwjxl/0W5QkeGi5+s+8HV67lTGo+Z1 lkEOgfPVMmTdBAT; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=roy@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1287963955; x=1319499955; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Roy=20Arends=20|Subject:=20R e:=20[dnsext]=20need=20new=20flag=20bit=20in=20EDNS,=20"d o=20me=20no=20favours"=20(DMNF)|Date:=20Sun,=2024=20Oct =202010=2023:45:49=20+0000|Message-ID:=20|To:=20David=20Conrad=20|CC:=20Paul=20Vixie=20,=20"namedropp ers@ops.ietf.org"=0D=0A=09 |MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted- printable|Content-ID:=20<8115ea33-82d5-47d7-8083-5dbe814c 6422>|In-Reply-To:=20<8D01F5E3-F863-4873-BB0E-654FA89983F 7@virtualized.org>; bh=HVxT+W6hNriUkb9b71FV8XFF0A4TFiWGLgwxv4IFFvc=; b=YYxSce+EsZoaQmFa0wIvHeszmOVSyQ2yVNunKt/SXli9EuUEjW7BlyG8 mI1LT/BoXERITPYxl2+wu8cxBeu6jW83RKQPTF7fB9NjButXWzBZi79+V EQbxoISeu66RQrR; X-IronPort-AV: E=Sophos;i="4.58,233,1286146800"; d="scan'208";a="22295319" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx4.nominet.org.uk with ESMTP; 25 Oct 2010 00:45:53 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%19]) with mapi; Mon, 25 Oct 2010 00:45:53 +0100 From: Roy Arends To: David Conrad CC: Paul Vixie , "namedroppers@ops.ietf.org" Subject: Re: [dnsext] need new flag bit in EDNS, "do me no favours" (DMNF) Thread-Topic: [dnsext] need new flag bit in EDNS, "do me no favours" (DMNF) Thread-Index: AQHLc55dTSnDy88VIESkTX8lBR8dOJNQyD0A///lFgCAACdfgA== Date: Sun, 24 Oct 2010 23:45:49 +0000 Message-ID: In-Reply-To: <8D01F5E3-F863-4873-BB0E-654FA89983F7@virtualized.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <8115ea33-82d5-47d7-8083-5dbe814c6422> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 10/25/10 1:24 AM, "David Conrad" wrote: > On Oct 24, 2010, at 4:01 PM, Roy Arends wrote: >=20 >> The end-game will be applications doing their own resolving. Real contro= l. >> No third party dependencies. No favors to ask. >=20 > And greatly reduced caching. Yes, and greatly reduced impact of a spoofed cache. > The problem with applications doing their own resolving is that the 'real > control' implies there is someone at the other end of the application tha= t has > the understanding and knowledge to make use of that control. Haven't we = seen > the implications of this approach with browsers that ask the end user whe= ther > or not to accept an SSL cert? The DMNF bit is not user configurable? Roy From owner-namedroppers@ops.ietf.org Sun Oct 24 16:54:43 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA1683A6922; Sun, 24 Oct 2010 16:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[AWL=1.396, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id najmGHQYsuxZ; Sun, 24 Oct 2010 16:54:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C3ECB3A6921; Sun, 24 Oct 2010 16:54:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PAAML-0004mj-D7 for namedroppers-data0@psg.com; Sun, 24 Oct 2010 23:52:17 +0000 Received: from mail-fx0-f52.google.com ([209.85.161.52]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PAAMH-0004mK-Tv for namedroppers@ops.ietf.org; Sun, 24 Oct 2010 23:52:14 +0000 Received: by fxm12 with SMTP id 12so1709895fxm.11 for ; Sun, 24 Oct 2010 16:52:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=i/8Y6yiepDYT48mzdSd/3UE85pw/P3aayR/zHwma2gA=; b=u4VUW/aM8gQq1aKPMCWXPBZHeYyO4SMxdL16ADSYqOCp81FmPeSOfAx+8OWPPwbJFP wrN+VCOKp2PPdBIFoeNCUfre1smh8IBXMIThpL2NyT68YlCtb0q0N0P63g49zlod/4qK /w9EdS/o7SG5VWxSSThExdbHVPGZM8iYG5FtE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=b6MuqkAucNfbTT5VNBbCMLLhKaDfiV1R+905rjJMr64KQQs35zCYIh/uLrCcsb6eNI 1UAGlFnNvZZ6iRBQ+Xebfwe1NdQaTePyL6Q2DZgn4Dj71xRCpdTAoHbianevNHn3EYMC aZOyyNGQtdXZWjCMze8SDtgfrn5waO0xSSLzk= MIME-Version: 1.0 Received: by 10.103.181.5 with SMTP id i5mr301738mup.48.1287964332314; Sun, 24 Oct 2010 16:52:12 -0700 (PDT) Received: by 10.223.114.145 with HTTP; Sun, 24 Oct 2010 16:52:12 -0700 (PDT) In-Reply-To: <8D01F5E3-F863-4873-BB0E-654FA89983F7@virtualized.org> References: <8D01F5E3-F863-4873-BB0E-654FA89983F7@virtualized.org> Date: Sun, 24 Oct 2010 20:52:12 -0300 Message-ID: Subject: Re: [dnsext] need new flag bit in EDNS, "do me no favours" (DMNF) From: Brian Dickson To: David Conrad Cc: Roy Arends , Paul Vixie , "namedroppers@ops.ietf.org" Content-Type: multipart/alternative; boundary=00163641715b82cf2d0493659015 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --00163641715b82cf2d0493659015 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Oct 24, 2010 at 8:24 PM, David Conrad wrote: > On Oct 24, 2010, at 4:01 PM, Roy Arends wrote: > > On 10/24/10 6:52 PM, "Paul Vixie" wrote: > >> opin? i can write a short i-d on it before beijing. > > I think a short i-d would be worthwhile. > > > The end-game will be applications doing their own resolving. Real > control. > > No third party dependencies. No favors to ask. > > And greatly reduced caching. > > s/applications/hosts/, I think. The endgame is a local resolver or stub resolver, or lwres library from a "real" dns package - not cobbled-together application-centric "resolver" code. And yes, caching would be reduced for no real benefit (other than presuming to receive valid replies). At the risk of sounding facetious, I think we already have a "DMNF" bit: DO (plus CD bit, i.e. security-aware stub resolvers). If DNSSEC answers are received, and authenticate properly, by definition, no favors can have been done. This is another reason to support DNSSEC, IMHO. Brian --00163641715b82cf2d0493659015 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sun, Oct 24, 2010 at 8:24 PM, David C= onrad <drc@virt= ualized.org> wrote:

On Oct 24, 2010, at 4:01 PM, Roy Arends wrote:
> On 10/24/10 6:52 PM, "Paul Vixie" <vixie@isc.org> wrote:

>> opin? =A0i can write a short i-d on it bef= ore beijing.

I think a short i-d would be worthwhile.

> The end-game will be applications doing their own resolving. Real cont= rol.
> No third party dependencies. No favors to ask.

And greatly reduced caching.

s/applications/hosts/, I think. The endgame is a = local resolver or stub resolver, or lwres library from a "real" d= ns package - not cobbled-together application-centric "resolver" = code.

And yes, caching would be reduced for no real benefit (other than presu= ming to receive valid replies).

At the risk of sounding facetious, I= think we already have a "DMNF" bit: DO (plus CD bit, i.e. securi= ty-aware stub resolvers).

If DNSSEC answers are received, and authenticate properly, by definitio= n, no favors can have been done.

This is another reason to support D= NSSEC, IMHO.

Brian

--00163641715b82cf2d0493659015-- From owner-namedroppers@ops.ietf.org Sun Oct 24 17:28:11 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1E593A67DF; Sun, 24 Oct 2010 17:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id whbtx7fQFMqb; Sun, 24 Oct 2010 17:26:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0B5BB3A677E; Sun, 24 Oct 2010 17:26:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PAApf-00074u-Ky for namedroppers-data0@psg.com; Mon, 25 Oct 2010 00:22:35 +0000 Received: from paka.besserwisser.org ([192.36.115.43]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PAApc-00074H-As for namedroppers@ops.ietf.org; Mon, 25 Oct 2010 00:22:32 +0000 Received: from paka.besserwisser.org (localhost [127.0.0.1]) by paka.besserwisser.org (8.13.8+Sun/8.13.7) with ESMTP id o9P0MKve009915 for ; Mon, 25 Oct 2010 02:22:20 +0200 (CEST) Received: (from mansaxel@localhost) by paka.besserwisser.org (8.13.8+Sun/8.13.7/Submit) id o9P0MKpI009914 for namedroppers@ops.ietf.org; Mon, 25 Oct 2010 02:22:20 +0200 (CEST) Date: Mon, 25 Oct 2010 02:22:20 +0200 From: Mans Nilsson To: "namedroppers@ops.ietf.org" Subject: Re: [dnsext] need new flag bit in EDNS, "do me no favours" (DMNF) Message-ID: <20101025002220.GD23479@besserwisser.org> References: <8D01F5E3-F863-4873-BB0E-654FA89983F7@virtualized.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eqp4TxRxnD4KrmFZ" Content-Disposition: inline In-Reply-To: X-URL: http://vvv.besserwisser.org X-Purpose: More of everything NOW! X-happyness: Life is good. User-Agent: Mutt/1.5.19 (2009-01-05) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --eqp4TxRxnD4KrmFZ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [dnsext] need new flag bit in EDNS, "do me no favours" (DMNF) = Date: Sun, Oct 24, 2010 at 08:52:12PM -0300 Quoting Brian Dickson (brian.pe= ter.dickson@gmail.com): =20 > At the risk of sounding facetious, I think we already have a "DMNF" bit: = DO > (plus CD bit, i.e. security-aware stub resolvers). ++; --=20 M=C3=A5ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Your CHEEKS sit like twin NECTARINES above a MOUTH that knows no BOUNDS -- --eqp4TxRxnD4KrmFZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (SunOS) iEYEARECAAYFAkzEzZ8ACgkQ02/pMZDM1cXd4ACeJ2xPydxOTi+eCta/3Gf26NoC p3wAnRlE3LUrQQY1qHTTQ3Q1wkm+G+Dp =0QcI -----END PGP SIGNATURE----- --eqp4TxRxnD4KrmFZ-- From owner-namedroppers@ops.ietf.org Sun Oct 24 18:09:10 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9AFA3A67BE; Sun, 24 Oct 2010 18:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.853 X-Spam-Level: X-Spam-Status: No, score=-1.853 tagged_above=-999 required=5 tests=[AWL=-0.546, BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NeKMoFJO0ti; Sun, 24 Oct 2010 18:09:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 88D323A677D; Sun, 24 Oct 2010 18:09:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PABUr-000A9W-7B for namedroppers-data0@psg.com; Mon, 25 Oct 2010 01:05:09 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PABTs-000A36-DK for namedroppers@ops.ietf.org; Mon, 25 Oct 2010 01:04:08 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id C7DFAA1075 for ; Mon, 25 Oct 2010 01:04:07 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie Cc: "namedroppers@ops.ietf.org" Subject: Re: [dnsext] need new flag bit in EDNS, "do me no favours" (DMNF) In-Reply-To: Your message of "Sun, 24 Oct 2010 23:01:14 GMT." References: X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 Date: Mon, 25 Oct 2010 01:04:07 +0000 Message-ID: <87372.1287968647@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > From: Roy Arends > Date: Sun, 24 Oct 2010 23:01:14 +0000 > > > opin? i can write a short i-d on it before beijing. > > The end-game will be applications doing their own resolving. Real > control. No third party dependencies. No favors to ask. since the end game for serious apps is stub validation, i tend to agree. however, for non-serious apps i think ISP-level or even ASP-level rdns, if an rdns operator wants to offer opt-out on web error redirection, i think there ought to be an in-band way for stubs to opt out. it's likely that the BIND resolver would implement DMNF defaulted to "on" but allow it to be set to "off" in /etc/resolv.conf. and it's likely that opendns and possibly other ASP-level rdns operators would respect this setting as part of their opt-out strategy and implementation. and depending on the interpretation -- in other words, this would be left loose deliberately in the standard for DMNF -- an rdns server who normally hides AAAA RRsets from queries coming in on a non-IPv6 transport, would turn this off in the presence of DMNF=1. so there are other applications. From owner-namedroppers@ops.ietf.org Sun Oct 24 18:09:45 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1697C3A68A8; Sun, 24 Oct 2010 18:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.844 X-Spam-Level: X-Spam-Status: No, score=-1.844 tagged_above=-999 required=5 tests=[AWL=-0.537, BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tBI0XNgej96Z; Sun, 24 Oct 2010 18:09:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4C98A3A677D; Sun, 24 Oct 2010 18:09:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PABY3-000AMm-Vh for namedroppers-data0@psg.com; Mon, 25 Oct 2010 01:08:27 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PABY1-000AMO-DS for namedroppers@ops.ietf.org; Mon, 25 Oct 2010 01:08:25 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 0E7D1A1071 for ; Mon, 25 Oct 2010 01:08:25 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie Cc: "namedroppers@ops.ietf.org" Subject: Re: [dnsext] need new flag bit in EDNS, "do me no favours" (DMNF) In-Reply-To: Your message of "Sun, 24 Oct 2010 20:52:12 -0300." References: <8D01F5E3-F863-4873-BB0E-654FA89983F7@virtualized.org> X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 Date: Mon, 25 Oct 2010 01:08:25 +0000 Message-ID: <87750.1287968905@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > Date: Sun, 24 Oct 2010 20:52:12 -0300 > From: Brian Dickson > > At the risk of sounding facetious, I think we already have a "DMNF" bit: > DO (plus CD bit, i.e. security-aware stub resolvers). that's a workaround not a signal. so, if there's a secure path from a trust anchor to the qname AND if the stub is validating THEN this has the same effect as DMNF. however, for unsecured names or nonvalidating stubs, i'd like an explicit signal. thus, DMNF. so far david conrad thinks a short i-d could be worthwhile, so that's two (me and him). anybody else? From owner-namedroppers@ops.ietf.org Sun Oct 24 18:27:06 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09D663A677D; Sun, 24 Oct 2010 18:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EyYZMt7dARn3; Sun, 24 Oct 2010 18:27:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 15B563A6767; Sun, 24 Oct 2010 18:27:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PABnA-000BfB-Pn for namedroppers-data0@psg.com; Mon, 25 Oct 2010 01:24:04 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PABn8-000Ber-Gg for namedroppers@ops.ietf.org; Mon, 25 Oct 2010 01:24:02 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id C8FBCA1078 for ; Mon, 25 Oct 2010 01:24:01 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: "namedroppers@ops.ietf.org" Subject: [dnsext] stub validation In-Reply-To: Your message of "Sun, 24 Oct 2010 16:24:54 MST." <8D01F5E3-F863-4873-BB0E-654FA89983F7@virtualized.org> References: <8D01F5E3-F863-4873-BB0E-654FA89983F7@virtualized.org> X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 Date: Mon, 25 Oct 2010 01:24:01 +0000 Message-ID: <88612.1287969841@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: among many critical defects in DNSSEC as specified, there's no good model for stub validation, and as time goes on there are fewer and fewer trustworthy rdns servers. as kaminsky said, "i'm not going to trust starbucks rdns to tell me the TLS key hash for my bank's HTTPS server". so... > From: David Conrad > Date: Sun, 24 Oct 2010 16:24:54 -0700 > > The problem with applications doing their own resolving is that the 'real > control' implies there is someone at the other end of the application > that has the understanding and knowledge to make use of that control. > Haven't we seen the implications of this approach with browsers that ask > the end user whether or not to accept an SSL cert? ...at the risk of being that guy who just won't shut up about something, let me say that until DNSSEC is commonplace, DNSSEC is a failure. when every apple and microsoft and google and RIM platform including every mobile phone can either validate end-to-end based on trust anchors (using DNSSEC), or validate hop-by-hop based on transaction signatures (using TSIG) from a trusted (and reachable!) rdns, then DNSSEC won't have been worth its (considerable) engineering cost. and it'll have to just work, out of the box, for nontechnical users, with no more or at least no different popups than we get from X.509 failures. but please everybody, don't dilute the DMNF thread with this argument. From owner-namedroppers@ops.ietf.org Sun Oct 24 18:38:12 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FCD23A67FA; Sun, 24 Oct 2010 18:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.837 X-Spam-Level: X-Spam-Status: No, score=-1.837 tagged_above=-999 required=5 tests=[AWL=-0.530, BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lMsJqKYz5oar; Sun, 24 Oct 2010 18:38:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 944DB3A677D; Sun, 24 Oct 2010 18:38:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PABya-000Chb-9y for namedroppers-data0@psg.com; Mon, 25 Oct 2010 01:35:52 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PAByY-000ChN-79 for namedroppers@ops.ietf.org; Mon, 25 Oct 2010 01:35:50 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id F2A2FA1043 for ; Mon, 25 Oct 2010 01:35:49 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie cc: "namedroppers@ops.ietf.org" Subject: Re: [dnsext] stub validation In-Reply-To: Your message of "Mon, 25 Oct 2010 01:24:01 GMT." <88612.1287969841@nsa.vix.com> References: <8D01F5E3-F863-4873-BB0E-654FA89983F7@virtualized.org> <88612.1287969841@nsa.vix.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 Date: Mon, 25 Oct 2010 01:35:49 +0000 Message-ID: <89335.1287970549@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > From: Paul Vixie > Date: Mon, 25 Oct 2010 01:24:01 +0000 > > ...at the risk of being that guy who just won't shut up about something, > let me say that until DNSSEC is commonplace, DNSSEC is a failure. when > every apple and microsoft and google and RIM platform including every > mobile phone can either validate end-to-end based on trust anchors (using > DNSSEC), or validate hop-by-hop based on transaction signatures (using > TSIG) from a trusted (and reachable!) rdns, then DNSSEC won't have been > worth its (considerable) engineering cost. s/won't/will/, sorry. From owner-namedroppers@ops.ietf.org Sun Oct 24 18:46:07 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F2603A68EC; Sun, 24 Oct 2010 18:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.244 X-Spam-Level: X-Spam-Status: No, score=-1.244 tagged_above=-999 required=5 tests=[AWL=1.354, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TbL3HOuiCyJg; Sun, 24 Oct 2010 18:46:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0E8E33A6767; Sun, 24 Oct 2010 18:46:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PAC6S-000DIL-Bn for namedroppers-data0@psg.com; Mon, 25 Oct 2010 01:44:00 +0000 Received: from mail-fx0-f52.google.com ([209.85.161.52]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PAC6P-000DI6-8E for namedroppers@ops.ietf.org; Mon, 25 Oct 2010 01:43:57 +0000 Received: by fxm12 with SMTP id 12so1771967fxm.11 for ; Sun, 24 Oct 2010 18:43:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=03rnPffOPKw+aXndJwE/zVs957Lp+6L+e1VjwskgmqE=; b=OHt6leIKZ8PkVh/EGMyMHcqlWq8FcvvyYOAQSHRF0/1FXdtCR13PXM8yXEZA2eEqVP itZY4J2G4PQUpw9DLAJ6KYDWblYREfOVNKDpSNh05m2nVMSH382VTOP3qikcQEXRXd/D 2FKA+YeM1X9lv1vC+nGKQ3bt/W2ZG/liMrVt4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ojOvoshQPhLiM7bZLRjPcBbVqnn4ufSqXwJ2BzDpKyffrok5TXeQ7GVipKnMhaS8Ki A6jsKFLeBDKReQWYf7EeFRU94eBBmBPcBHZ+zCFzGN9Z1SakLn7DPklPkYwQ35glJYLX OUulhluFaZ77AaO/Upr0yMyygRpzOa7CEljww= MIME-Version: 1.0 Received: by 10.103.161.18 with SMTP id n18mr7458301muo.31.1287971036066; Sun, 24 Oct 2010 18:43:56 -0700 (PDT) Received: by 10.223.114.145 with HTTP; Sun, 24 Oct 2010 18:43:56 -0700 (PDT) In-Reply-To: <87750.1287968905@nsa.vix.com> References: <8D01F5E3-F863-4873-BB0E-654FA89983F7@virtualized.org> <87750.1287968905@nsa.vix.com> Date: Sun, 24 Oct 2010 22:43:56 -0300 Message-ID: Subject: Re: [dnsext] need new flag bit in EDNS, "do me no favours" (DMNF) From: Brian Dickson To: Paul Vixie Cc: "namedroppers@ops.ietf.org" Content-Type: multipart/alternative; boundary=0016e657b59816071a0493672077 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --0016e657b59816071a0493672077 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Oct 24, 2010 at 10:08 PM, Paul Vixie wrote: > > Date: Sun, 24 Oct 2010 20:52:12 -0300 > > From: Brian Dickson > > > > At the risk of sounding facetious, I think we already have a "DMNF" bit: > > DO (plus CD bit, i.e. security-aware stub resolvers). > > that's a workaround not a signal. so, if there's a secure path from a > trust anchor to the qname AND if the stub is validating THEN this has > the same effect as DMNF. > > however, for unsecured names or nonvalidating stubs, i'd like an > explicit signal. thus, DMNF. so far david conrad thinks a short i-d > could be worthwhile, so that's two (me and him). anybody else? > > Sorry, I forgot to also say, I am not opposed, since there's the cases you indicated. I am in favor of an i-d as well, and would happily review it. Brian --0016e657b59816071a0493672077 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sun, Oct 24, 2010 at 10:08 PM, Paul V= ixie <vixie@isc.org> wrote:

> Date: Sun, 24 Oct 2010 20:52:12 -0300
> From: Brian Dickson <brian.peter.dickson@gmail.com>

>
> At the risk of sounding facetious, I think we already have a "DMN= F" bit:
> DO (plus CD bit, i.e. security-aware stub resolvers).

that's a workaround not a signal. =A0so, if there's a secure = path from a
trust anchor to the qname AND if the stub is validating THEN this has
the same effect as DMNF.

however, for unsecured names or nonvalidating stubs, i'd like an
explicit signal. =A0thus, DMNF. =A0so far david conrad thinks a short i-d could be worthwhile, so that's two (me and him). =A0anybody else?

Sorry, I forgot to also say, I am not opposed, since= there's the cases you indicated.

I am in favor of an i-d as well, and would happily review it.

Brian

--0016e657b59816071a0493672077-- From owner-namedroppers@ops.ietf.org Sun Oct 24 19:41:03 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 152B83A67B7; Sun, 24 Oct 2010 19:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.293 X-Spam-Level: X-Spam-Status: No, score=-2.293 tagged_above=-999 required=5 tests=[AWL=0.305, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlQ8k3meQLGK; Sun, 24 Oct 2010 19:41:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C5ED33A67AF; Sun, 24 Oct 2010 19:40:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PACwO-000H8U-1H for namedroppers-data0@psg.com; Mon, 25 Oct 2010 02:37:40 +0000 Received: from mail-gx0-f180.google.com ([209.85.161.180]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PACwK-000H8C-Sz for namedroppers@ops.ietf.org; Mon, 25 Oct 2010 02:37:37 +0000 Received: by gxk8 with SMTP id 8so1526900gxk.11 for ; Sun, 24 Oct 2010 19:37:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=Zmyw7j/2K55OcbSJlED7HdYx6Xz3yrJ0ySTOwCFmEHM=; b=MLmvOItr4RM4T3VY8kxByDqywoj75J3S1JXQvRPaWKSIZK1NNuq9VLWVay6DR4cBNm L28egOkFWFRExu5CG4w56KER3wj3o/cjtRUvHuXpTEDnZNtbDxQsieBARtLS3JruhIhk aSxI65Uvu//YEYzSDWAmy+k4XCg3Grjd0UWtg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=LSLsn1Dj4s0S22J+IvjQbLDOqM5XY5ZwHnpzIzEzVFpX5sFDTHk7FqPEQV8Gy5mXG6 3MzM7Ibxj4B+DzNru2z6EBQ7fbdewgASy2KTBD6bALUNIK/t/Wyn9jDQ1Iy0dMJqgBje JAdIfrq7bSgd6+5QZGJiS5ZzsP6Uo2bLMIx6A= MIME-Version: 1.0 Received: by 10.100.245.38 with SMTP id s38mr4970034anh.144.1287974254883; Sun, 24 Oct 2010 19:37:34 -0700 (PDT) Received: by 10.100.41.14 with HTTP; Sun, 24 Oct 2010 19:37:34 -0700 (PDT) In-Reply-To: References: <59023.1287939121@nsa.vix.com> Date: Sun, 24 Oct 2010 22:37:34 -0400 Message-ID: Subject: Re: [dnsext] need new flag bit in EDNS, "do me no favours" (DMNF) From: Phillip Hallam-Baker To: Roy Arends Cc: Paul Vixie , "namedroppers@ops.ietf.org" Content-Type: multipart/alternative; boundary=0016e68dec97f1321b049367df0a Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --0016e68dec97f1321b049367df0a Content-Type: text/plain; charset=ISO-8859-1 Only if the ISP concerned does not redirect all DNS traffic to their own resolver. That is not necessarily done for evil purposes either. A lot of ISPs are doing that to try to reduce the scope for bots on their network performing DDoS attacks on the DNS. On Sun, Oct 24, 2010 at 7:01 PM, Roy Arends wrote: > On 10/24/10 6:52 PM, "Paul Vixie" wrote: > > > i'm thinking we need a flag bit in edns to allow a client to opt out of > > things like "web error redirection" (dns ad insertion). the semantics > > of it would just be, if server policy allows "clear path" dns for this > > query, then the server is requested to provide same. > > > > if server policy does not allow, for example if dns ad insertion isn't > > optional or if the non-clear-path dns is for security reasons (blocking > > malware C&C names), then "clear path" dns would not be provided. > > > > so this would be opt-out rather than opt-in, to make it noncontroversial. > > (those of us who previously wanted opt-in have learned that opt-in is > > considered controversial by the companies already doing dns ad insertion > > or similar non-clear-path dns.) > > > > opin? i can write a short i-d on it before beijing. > > The end-game will be applications doing their own resolving. Real control. > No third party dependencies. No favors to ask. > > Roy > > > -- Website: http://hallambaker.com/ --0016e68dec97f1321b049367df0a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Only if the ISP concerned does not redirect all DNS traffic to their own re= solver.

That is not necessarily done for evil purposes e= ither. A lot of ISPs are doing that to try to reduce the scope for bots on = their network performing DDoS attacks on the DNS.

On Sun, Oct 24, 2010 at 7:01 PM, Ro= y Arends <roy@no= minet.org.uk> wrote:

On 10/24/10 6:52 PM, "Paul Vixie&quo= t; <vixie@isc.org> wrote:

> i'm thinking we need a flag bit in edns to allow a client to opt o= ut of
> things like "web error redirection" (dns ad insertion). =A0t= he semantics
> of it would just be, if server policy allows "clear path" dn= s for this
> query, then the server is requested to provide same.
>
> if server policy does not allow, for example if dns ad insertion isn&#= 39;t
> optional or if the non-clear-path dns is for security reasons (blockin= g
> malware C&C names), then "clear path" dns would not be p= rovided.
>
> so this would be opt-out rather than opt-in, to make it noncontroversi= al.
> (those of us who previously wanted opt-in have learned that opt-in is<= br> > considered controversial by the companies already doing dns ad inserti= on
> or similar non-clear-path dns.)
>
> opin? =A0i can write a short i-d on it before beijing.

The end-game will be applications doing their own resolving. Re= al control.
No third party dependencies. No favors to ask.

Roy

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

--0016e68dec97f1321b049367df0a-- From owner-namedroppers@ops.ietf.org Sun Oct 24 20:18:48 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E84F3A68A4; Sun, 24 Oct 2010 20:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.389 X-Spam-Level: X-Spam-Status: No, score=-102.389 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEwfdy4GYaiu; Sun, 24 Oct 2010 20:18:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6AABE3A67F6; Sun, 24 Oct 2010 20:18:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PADWR-000JhR-Av for namedroppers-data0@psg.com; Mon, 25 Oct 2010 03:14:55 +0000 Received: from [2001:478:6:0:230:48ff:fe11:220a] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PADWM-000Je2-8K for namedroppers@ops.ietf.org; Mon, 25 Oct 2010 03:14:53 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id o9P3CFfS006797; Mon, 25 Oct 2010 03:12:20 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id o9P3CFaC006796; Mon, 25 Oct 2010 03:12:15 GMT Date: Mon, 25 Oct 2010 03:12:15 +0000 From: bmanning@vacation.karoshi.com To: David Conrad Cc: Roy Arends , Paul Vixie , "namedroppers@ops.ietf.org" Subject: Re: [dnsext] need new flag bit in EDNS, "do me no favours" (DMNF) Message-ID: <20101025031215.GB5614@vacation.karoshi.com.> References: <8D01F5E3-F863-4873-BB0E-654FA89983F7@virtualized.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8D01F5E3-F863-4873-BB0E-654FA89983F7@virtualized.org> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Sun, Oct 24, 2010 at 04:24:54PM -0700, David Conrad wrote: > On Oct 24, 2010, at 4:01 PM, Roy Arends wrote: > > On 10/24/10 6:52 PM, "Paul Vixie" wrote: > >> opin? i can write a short i-d on it before beijing. > > I think a short i-d would be worthwhile. > > > The end-game will be applications doing their own resolving. Real control. > > No third party dependencies. No favors to ask. > > And greatly reduced caching. well, at least a greatly reduced attack surface for any given cache that is compromised. > The problem with applications doing their own resolving is that the 'real control' implies there is someone at the other end of the application that has the understanding and knowledge to make use of that control. Haven't we seen the implications of this approach with browsers that ask the end user whether or not to accept an SSL cert? yes and no. if you posit that more than one application runs on a target platform, then all apps that run there can use the same local resolver & validator. No real need for each app to take resolution into its own hands. didn't we have this conversation about seven years ago? --bill > Regards, > -drc > > From owner-namedroppers@ops.ietf.org Sun Oct 24 21:19:01 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 375A93A6800; Sun, 24 Oct 2010 21:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sp5IHTLBJxjT; Sun, 24 Oct 2010 21:18:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8D7803A6359; Sun, 24 Oct 2010 21:18:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PAERa-000NgS-O0 for namedroppers-data0@psg.com; Mon, 25 Oct 2010 04:13:58 +0000 Received: from trantor.virtualized.org ([204.152.189.190] helo=virtualized.org) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PAERW-000Nfj-VW for namedroppers@ops.ietf.org; Mon, 25 Oct 2010 04:13:56 +0000 Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id 2517EEDE5CA; Sun, 24 Oct 2010 21:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at virtualized.org Received: from virtualized.org ([127.0.0.1]) by localhost (trantor.virtualized.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZgVl8Oizw3RE; Sun, 24 Oct 2010 21:13:47 -0700 (PDT) Received: from [10.0.1.8] (c-24-130-212-17.hsd1.ca.comcast.net [24.130.212.17]) by virtualized.org (Postfix) with ESMTP id C000EEDE5BF; Sun, 24 Oct 2010 21:13:46 -0700 (PDT) Subject: Re: [dnsext] stub validation Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: <88612.1287969841@nsa.vix.com> Date: Sun, 24 Oct 2010 21:13:44 -0700 Cc: "namedroppers@ops.ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <54EE9BB9-3C71-4E04-B0D1-EADDD4748337@virtualized.org> References: <8D01F5E3-F863-4873-BB0E-654FA89983F7@virtualized.org> <88612.1287969841@nsa.vix.com> To: Paul Vixie X-Mailer: Apple Mail (2.1081) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Oct 24, 2010, at 6:24 PM, Paul Vixie wrote: > among many critical defects in DNSSEC as specified, there's no good = model > for stub validation, Stub validation never really made a lot of sense to me since it implies = the stub to do all the work of an iterative resolver each and every time = a lookup is done for each application that links in the stub resolver = library. It seems to me that a local rdns server makes way more sense. > and as time goes on there are fewer and fewer trustworthy rdns = servers. =20 A separate issue. I have as much trust in the rdns server that runs on = my local machine as I do in the application that linked the stub = resolver library. I have slightly less trust in the remote rdns server = that exists within my administrative realm (assuming I can communicate = with it via a trusted channel, e.g., (GSS-)TSIG, SIG(0), IPSEC, TLS, = etc). Even less for the remote rdns server outside of my administrative = realm but with which I have some sort of contractual relationship (and a = trusted channel). Etc.=20 > let me say that until DNSSEC is commonplace, DNSSEC is a failure. I would argue that DNSSEC is a success if it protects against a cache = poisoning attack in which a high value target is involved. As DNSSEC = deployment becomes more commonplace, the probability that it will be = successful increases. > but please everybody, don't dilute the DMNF thread with this argument. Right. Completely separate topics. Regards, -drc From owner-namedroppers@ops.ietf.org Sun Oct 24 21:19:13 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 453D03A692C; Sun, 24 Oct 2010 21:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.403 X-Spam-Level: X-Spam-Status: No, score=-2.403 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5p2qpoCQZROg; Sun, 24 Oct 2010 21:19:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 971303A6359; Sun, 24 Oct 2010 21:19:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PAEUe-000Nsi-FE for namedroppers-data0@psg.com; Mon, 25 Oct 2010 04:17:08 +0000 Received: from mail-gw0-f52.google.com ([74.125.83.52]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PAEUa-000NsJ-VU for namedroppers@ops.ietf.org; Mon, 25 Oct 2010 04:17:05 +0000 Received: by gwj22 with SMTP id 22so2753138gwj.11 for ; Sun, 24 Oct 2010 21:17:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=pEZrv2R8zg1FrlJNIuVl1TZT+11rGVWlZGSLEhnOh6Q=; b=v3gsrrxubQbZoWFDBLT5NXscj6KRcubmRJe+8PioQnpbJtItf/dq8Q0eX6+cHkjv4M 0G/cjV04r2dcX4s39ZiOVfUCJXYegbhaOXXVtTLMxB1FDy+SqgV7aslO0EG2h2/QkaiX pVIxl8+Kyweu2qwg84MCUZhMjf7OhStM8+Eoc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=hJG1r00E7q7euQzPv+QpMj/Z+hq+x5g0rX8HRBk1SEKDKlhZn5epS1B93a/sVjP7s+ NIbzu12jtx4Ts7j9m5N2uyRUlRP+ZZiQM2j+3Vx9jzFPgYObXIXF3A+yge91Liwi9E2M hDPlKRMIbFVg80YlUACwtKGVRXljsnVqD3ApM= MIME-Version: 1.0 Received: by 10.100.17.4 with SMTP id 4mr5035700anq.119.1287980223593; Sun, 24 Oct 2010 21:17:03 -0700 (PDT) Received: by 10.100.41.14 with HTTP; Sun, 24 Oct 2010 21:17:03 -0700 (PDT) In-Reply-To: <88612.1287969841@nsa.vix.com> References: <8D01F5E3-F863-4873-BB0E-654FA89983F7@virtualized.org> <88612.1287969841@nsa.vix.com> Date: Mon, 25 Oct 2010 00:17:03 -0400 Message-ID: Subject: Re: [dnsext] stub validation From: Phillip Hallam-Baker To: Paul Vixie Cc: "namedroppers@ops.ietf.org" Content-Type: multipart/alternative; boundary=0016e646984ab47ce904936943cd Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --0016e646984ab47ce904936943cd Content-Type: text/plain; charset=ISO-8859-1 You probably don't want Starbucks to manage your network security. But what about Symantec, MacAfee, Comodo, Kaspersky and the other companies who specialize in providing security services? The problem with making sense of DNSSEC data is that very little of it makes much sense on its own. Any given observation can be the result of a misconfiguration of a DNS server or an actual attack. It is very difficult to decide how to react at the client end. If instead we view a DNS recursive resolver as being a form of spam filter, DNSSEC becomes one way to authenticate one form of input to that filter. Cached data from previous requests becomes another. Blacklist and whitelist data are yet more sources. In this model the DNS resolver is not merely caching the result of a DNS lookup, it is caching the result of a security risk analysis. And because it is able to amortize that cost over multiple connections it is able to perform a rather more thorough analysis than is possible in the pure end to end discovery model. In the PKI model we distinguish between path discovery and path validation. For most purposes it is sufficient for the recursive resolver to perform both. But for certain applications and certain platforms it makes better sense to have discovery performed at the resolver and for the endpoint to re-validate the path that is returned. I agree on the problem of DNSSEC not being there until it is being used. One of the problems has been that until the root was signed there were many questions that many people did not want to hear raised lest they cast doubt on the viability of DNSSEC as a whole. On Sun, Oct 24, 2010 at 9:24 PM, Paul Vixie wrote: > among many critical defects in DNSSEC as specified, there's no good model > for stub validation, and as time goes on there are fewer and fewer > trustworthy rdns servers. as kaminsky said, "i'm not going to trust > starbucks rdns to tell me the TLS key hash for my bank's HTTPS server". > > so... > > > From: David Conrad > > Date: Sun, 24 Oct 2010 16:24:54 -0700 > > > > The problem with applications doing their own resolving is that the 'real > > control' implies there is someone at the other end of the application > > that has the understanding and knowledge to make use of that control. > > Haven't we seen the implications of this approach with browsers that ask > > the end user whether or not to accept an SSL cert? > > ...at the risk of being that guy who just won't shut up about something, > let me say that until DNSSEC is commonplace, DNSSEC is a failure. when > every apple and microsoft and google and RIM platform including every > mobile phone can either validate end-to-end based on trust anchors (using > DNSSEC), or validate hop-by-hop based on transaction signatures (using > TSIG) from a trusted (and reachable!) rdns, then DNSSEC won't have been > worth its (considerable) engineering cost. > > and it'll have to just work, out of the box, for nontechnical users, with > no more or at least no different popups than we get from X.509 failures. > > but please everybody, don't dilute the DMNF thread with this argument. > > -- Website: http://hallambaker.com/ --0016e646984ab47ce904936943cd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable You probably don't want Starbucks to manage your network security.=A0

But what about Symantec, MacAfee, Comodo, Kaspersky and t= he other companies who specialize in providing security services?