internet-drafts | 1 Jul 17:44 2015
Picon

I-D Action: draft-ietf-dnsop-cookies-03.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Domain Name System Operations Working Group of the IETF.

        Title           : Domain Name System (DNS) Cookies
        Authors         : Donald E. Eastlake
                          Mark Andrews
	Filename        : draft-ietf-dnsop-cookies-03.txt
	Pages           : 30
	Date            : 2015-07-01

Abstract:
   DNS cookies are a lightweight DNS transaction security mechanism that
   provides limited protection to DNS servers and clients against a
   variety of increasingly common denial-of-service and amplification /
   forgery or cache poisoning attacks by off-path attackers. DNS Cookies
   are tolerant of NAT, NAT-PT, and anycast and can be incrementally
   deployed.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-cookies/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dnsop-cookies-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-cookies-03

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
(Continue reading)

Suzanne Woolf | 1 Jul 16:08 2015
Picon

Re: More after onion? was Re: Some distinctions and a request

Ed,

First-- apologies for the misunderstanding.

On Jul 1, 2015, at 9:53 AM, Edward Lewis <edward.lewis <at> icann.org> wrote:
> 
> Trying to be more clear, I have in the past imagined that today someone is
> inventing a new communications technology, in 6 months will need to cobble
> an identifier space and in 2 years the IETF-connected crowd detects
> significant deployment of this and needs to decide whether to register a
> TLD to avoid name collisions.  I've been told that this wouldn't happen
> because the IETF will have rules - which I am skeptical would "prevent"
> the situation from happening.

I don't think we have "rules" or even guidelines now that have any chance of preventing it. 

I agree we'll never prevent it completely; it's the nature of the DNS and the internet that people can do
things with names and they don't have to ask the IETF first.

But I don't think it's impossible that we'll be able to provide guidance, such that developers who follow it
are reasonably sure of avoiding the various types of collisions and ambiguities we're concerned about--
and such that there's a clear basis for saying "You're doing something outside of the guidance we can
provide about how names work in the internet, you're on your own." 

> To underscore - I am not against the innovation.  I am urging that the
> processes put in place are future proof by being "reactionary" - reacting
> to the new names, not trying to fend off the situation.  I.e., in
> agreement with the words below "trying to apply RFC 6761 and finding that
> it remains subjective".

(Continue reading)

internet-drafts | 1 Jul 14:49 2015
Picon

I-D Action: draft-ietf-dnsop-dnssec-roadblock-avoidance-02.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Domain Name System Operations Working Group of the IETF.

        Title           : DNSSEC Roadblock Avoidance
        Authors         : Wes Hardaker
                          Olafur Gudmundsson
                          Suresh Krishnaswamy
	Filename        : draft-ietf-dnsop-dnssec-roadblock-avoidance-02.txt
	Pages           : 16
	Date            : 2015-07-01

Abstract:
   This document describes problems that a DNSSEC aware resolver/
   application might run into within a non-compliant infrastructure.  It
   outline potential detection and mitigation techniques.  The scope of
   the document is to create a shared approache to detect and overcome
   network issues that a DNSSEC software/system may face.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-roadblock-avoidance/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dnsop-dnssec-roadblock-avoidance-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dnssec-roadblock-avoidance-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
(Continue reading)

Edward Lewis | 1 Jul 14:26 2015
Picon

More after onion? was Re: Some distinctions and a request

On 7/1/15, 1:47, "DNSOP on behalf of str4d" <dnsop-bounces <at> ietf.org on
behalf of str4d <at> i2pmail.org> wrote:
>.onion and .i2p (and to my knowledge, the other proposed P2P-Names
>TLDs too) have to conform to DNS rules in order to be usable in legacy
>applications that expect domain names.

I'd been told that "onion." was a one-time thing, that in the future
conflicts wouldn't happen.  What I read in the quoted message is that
"onion."'s request isn't a one-time thing but a sign of things to come.

I'm sympathetic to the use the path of least resistance - e.g., use names
that syntactically are DNS names - instead of building a separate
application base.  I expect innovation to be free-form and thus a stream
of unpredictable requests to reserve names for special purposes, including
DNS-like names.

What DNSOP can comment on is how the DNS "reacts" to names, whether in
protocol or operational convention, once they are known before they
achieve some degree of widespread adoption. To what extent is an effort
made (by whomever) to detect these budding namespaces, is this proactive?
Attachment (smime.p7s): application/pkcs7-signature, 6226 bytes
_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Dan York | 1 Jul 13:43 2015

Want to join the IETF 93 Hackathon to work on DNSSEC, DANE or DNS Privacy?

DNSOP participants,

Will you be in Prague on the weekend before IETF 93? (Or could you get there?)  A number of us will be involved with the hackathon happening on Saturday and Sunday:


Our intent is to work on some tools/services related to DANE, DNSSEC and/or DNS privacy - either adding support to existing tools or projects, or developing something new that is useful in some way (and is not a duplicate of something else).   We don't have specific projects lined up yet  (we need to meet and decide what we're going to do)...  but any suggestions are certainly welcome.

If you'd like to join for either one or both days, the link to sign up is on that hackathon page.   Here's what we wrote as an abstract:
  • DANE / DNS Privacy / DNSSEC
    • Contribute to access of end-systems to new developments in DNS
    • Protocols: DANE support for webmail, DNS-over-TLS (application uses), DNS-over-DTLS (stack and uses), TLSA client certs, client privacy election for EDNS client-subnet, getdns language bindings, etc.
    • Tools: portable tool for creating and adding DANE RR’s to zones, changes to existing tools to support new crypto algorithms, etc.
    • Measurement: New tools or sites for measuring DNSSEC or DANE deployment
    • Available environment, support, and diagnostic tools: https://dnssec-tools.org, https://www.opendnssec.org
    • Champions
Anyone is welcome to join with us.  The current list of participants is here:  https://www.ietf.org/registration/ietf93/hackathonattendance.py?sortkey=3&login=%0A  (you can see that some people have listed that they will join in for DNS-related topics...)

See (some of) you in Prague,
Dan

--
Dan York
Senior Content Strategist, Internet Society
york <at> isoc.org   +1-802-735-1624
Skype: danyork   http://twitter.com/danyork




_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
str4d | 1 Jul 07:47 2015

Re: Some distinctions and a request


Andrew Sullivan wrote:
> On Tue, Jun 30, 2015 at 11:43:42AM +0000, Edward Lewis wrote:
>> I'm not aware of "the rule" that declares Onion names as part of
>> the domain name space.  Not an argument, just a data point.  I've
>> always heard, and have been running on this, that Onion names are
>> not part of the DNS name space.
> 
> You're conflating "DNS name space" and "domain name space" again.
> I didn't say they're part of the DNS name space; and given what
> the top-level label onion. does, they can't possibly be.  At the 
> beginning, I claimed that the domain name space was all the
> logically possible domain names, not all the ones in fact possibly
> in the DNS. Under this definition, local. is part of the domain
> name space and not part of the DNS name space (because of local.
> being registered in the special use names registry).
> 
> When I asked about this before, one of the onion proponents told
> me that onion names have to conform to DNS (and, he claimed, LDH)
> rules right now, though that is a possibly temporary convention.

.onion and .i2p (and to my knowledge, the other proposed P2P-Names
TLDs too) have to conform to DNS rules in order to be usable in legacy
applications that expect domain names. In some future where the
percentage of apps requiring this is much lower (by most apps natively
supporting Tor/I2P/etc), the restriction could be removed. But while
domain names are the de-facto standard, I don't see it changing.

>> Alain Durrand and I talked about this a few weeks back.  He made
>> the point that you can distinguish the namespace of an identifier
>> "on the right" or "on the left" imaging the use of names in URLs.
>> I.e., there could be a "http-tor://tor-name.onion/path" and use
>> http-onion to tag this as a Tor identifier or
>> "http://tor-name.onion/path" and assume it's Tor because of the
>> onion where I'd expect(*) a domain name to be.
> 
> I think this is a terrible confusion of URI schemes vs. name-space 
> switches.  It's true that if you treat the URI as an unformatted 
> string you can parse it this way; but there are already rules for 
> that.  But I think anyway that's a distraction.  We don't need 
> uri-schemes to creep into this.

+1. Besides the confusion, this would require native app support,
because URI schemes are generally handled separately to name
resolution - you couldn't just use a SOCKS/HTTP/DNS proxy to handle
legacy applications, like Tor/I2P/GNUnet do now.

str4d

> 
> Best regards,
> 
> A
> 
Suzanne Woolf | 30 Jun 17:51 2015
Picon

reminder on agenda items for DNSOP IETF 93

Dear colleagues,

Just a reminder: 

* The draft cutoff for IETF 93 is next Monday, July 6. 
* WG meeting agendas are due the same day.

Please send agenda requests ASAP. 

When you do, please note that we have quite a number of documents in flight and were unable to get two meeting
slots for Prague (we requested two and then were notified there were more requests than possible slots).
So f2f meeting time will be at something of a premium; if we get as many requests this time as we've had for the
last couple of meetings, we *will* be forced to say no to some of them.

Accordingly, we'll be giving preference to requests regarding work already underway, with a clear goal or
outcome for the f2f time.  

We've been working hard to make sure we aren't relying on f2f meetings to force progress. Much thanks to
authors, reviewers, and WG participants who've kept up the pace since Dallas!

Suzanne & Tim
_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Christian Grothoff | 30 Jun 11:01 2015

Re: P2P Names Draft 03

On 12/27/2014 01:24 PM, Mark Nottingham wrote:
> Hi Christian and Jake,
>
> We’ve still been discussing this in IETF-land. To reiterate - putting
> all six TLDs into one draft is killing your chances of succeeding.
>
> I’m starting to hear people talking about creating a separate draft
> to do just that. If either or both of you would like to help out with
> that, I’m sure they’d be very welcoming; people don’t want to set up
> competing drafts unnecessarily.
>
> Tell me what you think.

Dear Mark (and other dnsop'ers),

I've now (after discussions with the other authors) followed Mark's
original suggestion and split up the draft into four separate drafts.
Naturally, as ".onion" already exists, we've left this one out. As
".gnu" and ".zkey" are both for the GNU Name system, we've left those
two together for now.  Note that for Tor, we still need ".exit", so this
results in four additional drafts for discussion, hopefully at IETF 93.
Also, please note that the Tor project is working on OnionNS, which
would add another pTLD ".tor", but as this is still a bit premature, we
didn't write a draft for ".tor".

Hellekin was wondering if we should do the split drafts in the
".onion"-style with very little details and justifications, or in the
original style with more explanations.  For now, we have the "long"
versions, but, especially if desired, *friendly* "competing" short
versions without justifications might be prepared a bit later.

A new version of I-D, draft-grothoff-iesg-special-use-p2p-bit-00.txt
has been successfully submitted by Christian Grothoff and posted to the
IETF repository.

Name:		draft-grothoff-iesg-special-use-p2p-bit
Revision:	00
Title:		Special-Use Domain Name for Namecoin
Document date:	2015-06-30
Group:		Individual Submission
Pages:		10
URL:
https://www.ietf.org/internet-drafts/draft-grothoff-iesg-special-use-p2p-bit-00.txt
Status:
https://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-bit/
Htmlized:
https://tools.ietf.org/html/draft-grothoff-iesg-special-use-p2p-bit-00

Abstract:
   This document registers a Special-Use Domain Name for use with the
   Namecoin system, as per RFC6761.

                   A new version of I-D,
draft-grothoff-iesg-special-use-p2p-exit-00.txt
has been successfully submitted by Christian Grothoff and posted to the
IETF repository.

Name:		draft-grothoff-iesg-special-use-p2p-exit
Revision:	00
Title:		The .exit Special-Use Domain Name of Tor
Document date:	2015-06-30
Group:		Individual Submission
Pages:		9
URL:
https://www.ietf.org/internet-drafts/draft-grothoff-iesg-special-use-p2p-exit-00.txt
Status:
https://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-exit/
Htmlized:
https://tools.ietf.org/html/draft-grothoff-iesg-special-use-p2p-exit-00

Abstract:
   This document registers a Special-Use Domain Name for use with the
   Tor Project, as per RFC6761.

A new version of I-D, draft-grothoff-iesg-special-use-p2p-gns-00.txt
has been successfully submitted by Christian Grothoff and posted to the
IETF repository.

Name:		draft-grothoff-iesg-special-use-p2p-gns
Revision:	00
Title:		Special-Use Domain Names of the GNU Name System
Document date:	2015-06-30
Group:		Individual Submission
Pages:		10
URL:
https://www.ietf.org/internet-drafts/draft-grothoff-iesg-special-use-p2p-gns-00.txt
Status:
https://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-gns/
Htmlized:
https://tools.ietf.org/html/draft-grothoff-iesg-special-use-p2p-gns-00

Abstract:
   This document registers a set of Special-Use Domain Names for use
   with Peer-to-Peer (P2P) systems, as per RFC6761.

Name:		draft-grothoff-iesg-special-use-p2p-i2p
Revision:	00
Title:		Special-Use Domain Names for I2P
Document date:	2015-06-30
Group:		Individual Submission
Pages:		9
URL:
https://www.ietf.org/internet-drafts/draft-grothoff-iesg-special-use-p2p-i2p-00.txt
Status:
https://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-i2p/
Htmlized:
https://tools.ietf.org/html/draft-grothoff-iesg-special-use-p2p-i2p-00

Abstract:
   This document registers a Special-Use Domain Name for use with the
   I2P Peer-to-Peer system, as per RFC6761.

Best regards,

Christian

Attachment (0xE29FC3CC.asc): application/pgp-keys, 14 KiB
_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Warren Kumari | 29 Jun 22:48 2015
Picon

Simplified Updates of DNS Security Trust Anchors, for rolling the root key

Hi all,

So, there is a project underway to roll the DNSSEC root key. There has
been much written about this, including SAC063
(https://www.icann.org/en/system/files/files/sac-063-en.pdf[0]), a
DNSSEC Root KSK Rollover Plan Design Team, various consultations with
the community, many presentations at DNS-OARCs, etc.

One of the biggest impediments to actually performing the rollover is
that some set of folk will not have performed RFC5011 style rollover,
whether because their software doesn't support 5011, because they have
statically configured a TA, because the bigger response makes them
sad, whatever. The fact that we cannot tell who has only has the old
key, and who has both makes the keyroll very scary - we cannot predict
who, and how wide scale the outage will be when the old key is
removed.

I've written a draft that proposes a different way of performing root
key rollover that exposes who all has which key - this allows one to
know that 99.8% of resolvers have the new key, who has the old one,
and who will break.
It does this by encoding the current set of TAs that the resolver has
into a query, and using that to fetch the new keys. By watching
queries at the root one can see the population of people with each TA,
and watch that change over time. This was written for root key roll,
but is applicable to any TA in the tree.

I'd appreciate any feedback, the draft announcment is here:
Name:           draft-wkumari-dnsop-trust-management
Revision:       00
Title:          Simplified Updates of DNS Security (DNSSEC) Trust Anchors
Document date:  2015-06-29
Group:          Individual Submission
Pages:          8
URL:
https://www.ietf.org/internet-drafts/draft-wkumari-dnsop-trust-management-00.txt
Status:
https://datatracker.ietf.org/doc/draft-wkumari-dnsop-trust-management/
Htmlized:
https://tools.ietf.org/html/draft-wkumari-dnsop-trust-management-00

Abstract:
   This document describes a simple means for automated updating of
   DNSSEC trust anchors.  This mechanism allows the trust anchor
   maintainer to monitor the progress of the migration to the new trust
   anchor, and so predict the effect before decommissioning the existing
   trust anchor.

   It is primarily aimed at the root DNSSEC trust anchor, but should be
   applicable to trust anchors elsewhere in the DNS as well.

   [ Ed note - informal summary: One of the big issues with rolling the
   root key is that it is unclear who all is using RFC5011, who all has
   successfully fetched and installed the new key, and, most
   importantly, who all will die when the old key is revoked.  A
   secondary problem is that the response sizes suddenly increase,
   potentially blowing the MTU limit.  This document describes a method
   that is basically CDS, but for the root key (or any other trust
   anchor).  Unlike the CDS record though, this record lives at a
   special name - by querying for this name, the recursive exposes its
   list of TAs to the auth server (signalling upstream) . This allows
   the TA maintainer to predict how many, and who all will break.  It
   also allows the pre-publication of a key before using it, and so
   avoids the need to double response sizes...]

   [ Ed note: Text inside square brackets ([]) is additional background
   information, answers to frequently asked questions, general musings,
   etc.  They will be removed before publication.]

   [ This document is being collaborated on in Github at:
   https://github.com/wkumari/draft-wkumari-dnsop-trust-management.  The
   most recent version of the document, open issues, etc should all be
   available here.  The authors (gratefully) accept pull requests ]

W
[0]: Full disclosure: Author.

--

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

internet-drafts | 25 Jun 20:09 2015
Picon

I-D Action: draft-ietf-dnsop-root-loopback-02.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Domain Name System Operations Working Group of the IETF.

        Title           : Decreasing Access Time to Root Servers by Running One on Loopback
        Authors         : Warren Kumari
                          Paul Hoffman
	Filename        : draft-ietf-dnsop-root-loopback-02.txt
	Pages           : 11
	Date            : 2015-06-25

Abstract:
   Some DNS recursive resolvers have longer-than-desired round trip
   times to the closest DNS root server.  Some DNS recursive resolver
   operators want to prevent snooping of requests sent to DNS root
   servers by third parties.  Such resolvers can greatly decrease the
   round trip time and prevent observation of requests by running a copy
   of the full root zone on a loopback address (such as 127.0.0.1).
   This document shows how to start and maintain such a copy of the root
   zone that does not pose a threat to other users of the DNS, at the
   cost of adding some operational fragility for the operator.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-root-loopback/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dnsop-root-loopback-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-root-loopback-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Tim Wicinski | 25 Jun 19:42 2015
Picon

Working Group Last Call for draft-ietf-dnsop-qname-minimisation


All

Stephane has taken in all the comments on the qname-minimisation draft, 
and has addressed everything (the last comments from Mr. Harold are not 
in this draft but are being addressed).  This starts a Working Group 
Last Call  for draft-ietf-dnsop-qname-minimisation

Current versions of the draft is available here:

https://datatracker.ietf.org/doc/draft-ietf-dnsop-qname-minimisation/
https://tools.ietf.org/html/draft-ietf-dnsop-qname-minimisation-04

The Intended RFC Status is "Experimental" as there are still few 
implementations in use.

Please review the draft and offer relevant comments. Also, if someone 
feels the document is *not* ready for publication, please speak out with 
your reasons.

This starts a two week Working Group Last Call process, and ends on 
Thursday July 9th, 2015.

thanks
tim

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Gmane