Subject: [DNSOP] draft-hzhwm-start-tls-for-dns-00: Starting TLS over DNS

From: Zi Hu <[email-masked]>
Date: Fri, 14 Feb 2014 19:03:31 -0800

We recently posted draft-hzhwm-start-tls-for-dns-00 ("Starting TLS over
DNS") to explore one proposal to add standard TLS over standard DNS to
improve privacy.
http://tools.ietf.org/html/draft-hzhwm-start-tls-for-dns-00

This topic may be of interest to DNSOP and PERPASS.  Some of the authors
will be at the London IETF and can discuss it at the DNS privacy BOF if
there is interest.

An obvious concern about combining DNS and TLS is the performance
implications, both for client latency and server state.  The above i-d
focuses only on the protocol parts, but we have a separate technical
report at ftp://ftp.isi.edu/isi-pubs/tr-688.pdf that evaluates these
questions.

We would love feedback on either document.

thanks
-Zi Hu

---

From: Paul Vixie <[email-masked]>
Date: Fri, 14 Feb 2014 20:58:47 -0800

Zi Hu wrote:
> ...

this is good work. i recommend it be adopted by the working group, and i
will act as a reviewer.

vixie

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sat, 15 Feb 2014 15:01:33 +0100

On Fri, Feb 14, 2014 at 08:58:47PM -0800,
 Paul Vixie <[email-masked]> wrote 
 a message of 76 lines which said:

> this is good work.

I fully agree. But do note we did not discuss yet the alternatives
(draft-wijngaards-dnsop-confidentialdns, DNScrypt or simply
IPsec). The BoF "DNS encryption" in London seems a good start 
<http://trac.tools.ietf.org/bof/trac/wiki/WikiStart> and 
<https://datatracker.ietf.org/wg/dnse/charter/>.

> i recommend it be adopted by the working group, 

DNSOP? Some people say it is outside the charter since it is a
modification of the protocol. I myself are not favorable to an
ultra-strict interpretation of the charter so I'll hummmmmm with you.

---

From: Tony Finch <[email-masked]>
Date: Sat, 15 Feb 2014 15:40:48 +0000

> DNS") to explore one proposal to add standard TLS over standard DNS to

I like this. The general approach of the extension looks sensible to me.

Some comments:

   This document defines only the protocol extensions necessary to
   support TLS negotiation.  It does not describe how DNS clients might
   validate server certificates or specify trusted certificate
   authorities.  Solutions for certificate authentication are outside
   the scope of this document.

This absolutely needs to be defined before the protocol is deployed and I
think it is a huge mistake to rule it out of scope.

SMTP made this mistake (RFC 3207) and as a result most certificates
offered by SMTP servers cannot be validated, and SMTP over TLS is
vulnerable to MITM attacks. Fixing this is a huge headache. I don't
want to see it happen again.

But solving this problem is really hard especially in this context :-(

A DANE-like approach might work for authoritative servers.

Dunno about stub <-> recursive connections...

2.1.2.  Receiving Responses

   A DNS client that receives a response using UDP transport that has
   the TO bit set MUST handle that response as usual.  It MAY record the
   server's support for DNS-over-TLS and use that information as part of
   its server selection algorithm in the case where multiple servers are
   available to service a particular query.  [For discussion: UDP is
   subject to spoofing and a client which depends on TO=1 in a UDP
   response may be tricked into never upgrading to TLS.]

This is also true for DNS over TCP. It would be nice to have some stronger
protection against downgrade attacks. Point 3 in the security
considerations needs more thought.

   A DNS client that receives a response to its initial query using TCP
   transport that has the TO bit clear MUST not initiate a TLS handshake
   and SHOULD utilize the existing TCP connection for subsequent
   queries.

I think in this situation it would be better for the client to go back to
using UDP. Existing DNS servers do not handle TCP queries concurrently, so
the client will suffer much worse performance by continuing to use TCP.

2.4.  Middleboxes

   2.  The DNS client sends a TO=1 query and receives a TO=1 response,
       but the TLS handshake fails because the server's certificate
       cannot be authenticated.  In this case the client SHOULD close
       the established connection and fall back to unencrypted DNS for a
       reasonable period (as discussed in Section 2.1.2).

Having said that certificate validation is really important, I still think
that unauthenticated encryption is strictly better than nothing, since it
defeats passive (but not active) eavesdropping. But this kind of soft
failure is a great way to introduce downgrade attacks.

3.  Performance Considerations

This section should require servers to handle DNS queries over TCP and TLS
concurrently. They should be prepared to send responses as soon as they
are available, and out of order when necessary, to avoid head-of-line
blocking. This minimises the performance penalty relative to UDP.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sat, 15 Feb 2014 17:52:56 +0100

On Sat, Feb 15, 2014 at 03:40:48PM +0000,
 Tony Finch <[email-masked]> wrote 

> A DANE-like approach might work for authoritative servers.

It is mentioned in the draft but it raises an interesting
chicken-and-egg problem when you want to secure DNS with info found in
the DNS.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sat, 15 Feb 2014 17:57:18 +0100

On Sat, Feb 15, 2014 at 08:44:27AM -0800,
 Watson Ladd <[email-masked]> wrote 
 a message of 25 lines which said:

> Fourthly, there is substantial operational knowledge and deployed,
> working, code implementing DNSCurve.

While you raise some interesting points, this specific one pushes me
to ask you a list of domain names secured by DNScurve (DNScrypt is a
bit different).

In exchange, I can produce a list of Web sites secured with TLS.

---

From: Tony Finch <[email-masked]>
Date: Sat, 15 Feb 2014 17:23:57 +0000

> chicken-and-egg problem when you want to secure DNS with info found in

Very interesting :-)

The resolver needs to find out that an auth server supports TLS before it
sends a query. This implies that the information needs to be part of the
referral. It would be wrong to shoe-horn it into the DS RRset (e.g. by
adding semantics to one of the algorithm fields) since DS records relate
to the zone not to the name servers. So it should go into the NS RRset -
but referral NS records aren't signed!

Maybe the resolver could go and ask elsewhere. This could be quite
plausible for out-of-zone name servers, but it does not help for in-zone
server names. Or use the reverse DNS?

No palatable options that I can see :-/

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Malin, Hebrides, Bailey: Northwest 7 to severe gale 9 decreasing 4 or 5,
occasionally variable 3 later. Very rough or high, becoming rough later.
Showers, squally at first. Moderate or poor becoming good.

---

From: Paul Vixie <[email-masked]>
Date: Sat, 15 Feb 2014 10:08:30 -0800

Watson Ladd wrote:
> Dear all,
> This proposal has multiple shortcomings compared to DNSCurve.
>
> First off, it says that the rationale for TLS over DNSCurve is simply
> to "take advantage of TLS". I would respectfully submit that DJB can
> do a better job than the TLS committee, and did. Merely adding bolts
> and nuts onto a design is not improving it.

has mr. bernstein's Curve25519 (see
http://en.wikipedia.org/wiki/Curve25519) been explicitly validated by
other crypto experts? last i knew he was the only one claiming it was
correct and strong enough for production use. this matters, because no
one person ought to be trusted to get something like this right sans
review. mr. bernstein's competence isn't being questioned, it's just the
"second set of eyes" requirement for technology at scale. i'm speaking
as an x.509-hater, which means, i tend to agree with what you said about
committees.

as a bolter-onner of many of dns's nuts including EDNS, i'm ready to
quibble with anyone who says DNS has not been improved by the post-1987
work that's been done to it. i won't claim it's gotten prettier, but
that's not the only metric for "improvement".

> Secondly, this proposal only works on TCP. This imposes latency and
> state requirements that most people would rather avoid. The use of
> keepalive only addresses computational burden, not state burden, and
> with the DH speed records we have today unnecessary.

my understanding is that this is a hop-by-hop cover protocol for adding
confidentiality when needed, and that something like dnssec will still
be needed for end-to-end content authenticity. in that sense the tcp
requirement isn't itself burdensome, though i will certainly recommend a
block-cipher mode so that udp can also be supported. this is not
something we can fix with DTLS or SCTP because of the all-pervasive
"middlebox problem". even getting EDNS options through has proved
difficult, a completely new transport is unthinkable.

> Thirdly, this proposal ignores entirely how to validate the server
> over the TLS connection. Does it need a certificate? Who should be
> allowed to sign it? How should it be validated? DNSSEC provides a PKI,
> and this proposal provides another one. Their interactions will not be
> fun.

see above; i don't think this proposal offers or intends to offer a PKI,
merely a hop-by-hop confidentiality option. DNSSEC will still be required.

> working, code implementing DNSCurve. This does not hold for this
> proposal.

dnscurve was offered to the ietf community but it didn't stick for
reasons unrelated to this newer proposal. i don't see any sense in
comparing their installed bases.

> Sincerely,
> Watson Ladd

warmly,

vixie

---

From: Paul Wouters <[email-masked]>
Date: Sat, 15 Feb 2014 14:57:58 -0500 (EST)

On Sat, 15 Feb 2014, Stephane Bortzmeyer wrote:

(D)TLS for DNS makes a lot of sense to me.

> IPsec). The BoF "DNS encryption" in London seems a good start

"simply IPsec"? bootstrapping DNS from IPsec which relies on DNS is not
trivial (and the versign proposal seems to only deal with nameservers
with access to their reverse dns, which excludes the DNS servers that
really need the protection, those supplied by DHCP in coffeeshops,
and completely lacks understanding of IPsec realities such as NAT-T)

> ultra-strict interpretation of the charter so I'll hummmmmm with you.

At ietf87 it was planned to  have a discussion at dnsop about this
continued problem of drafts that fall between operations and extensions
and the fact that dnsext closed down. Nothing happened at ietf87 or
ietf88. I hope to see this as agenda item for dnsop this meeting.

We need a WG to discuss DNS innovation.

Paul

---

From: David Conrad <[email-masked]>
Date: Sat, 15 Feb 2014 18:04:54 -0800

[perpass dropped from ccs]

> We need a WG to discuss DNS innovation.

At the Vancouver DNSOP meeting when there was some discussion I thought was protocol development related, I got up to the mike asked if DNSOP was the right place for that discussion, being righteously indignant that DNSOP would discuss something non-operational.  However, after sitting down someone pointed out to me that one of the common recurrent complaints about the IETF is that operators tend to get excluded and that maybe DNSOP is actually the best place to discuss DNS protocol development since that's where operators go.  

Perhaps DNSOP actually is the DNS innovation WG (if perhaps only as a seeding ground)?

Regards,
-drc

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 16 Feb 2014 08:15:33 +0100

> Perhaps DNSOP actually is the DNS innovation WG (if perhaps only as a seeding ground)?

The largest problem for IETF and DNS innovation is that the consensus in
IETF seems to be that innovation of DNS is not possible unless it
involves reuse of the TXT resource record.

Unless that is put to rest, we can not do much at all.

   Patrik

---

From: Dave Crocker <[email-masked]>
Date: Sun, 16 Feb 2014 05:45:46 -0800

> involves reuse of the TXT resource record.

That assertion is quite wrong on both process and technical grounds

Process:

      There is certainly a long history of very strong resistance from a 
core group of DNS advocates in the IETF; and yes, there is an IAB report 
that doesn't like TXT usage.

      But there is also a long history of other folk adding DNS usage in 
spite of that.

      So a casual claim of "IETF consensus" is simply false.

Technical:

      The use of underscore-based naming variations has provided an 
easy, efficient and safe means of eliminating TXT usage ambiguity.  By 
way of examples, note the SRV record and DKIM, but there are others.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 16 Feb 2014 15:03:22 +0100

On 2014-02-16 14:45, Dave Crocker wrote:
>      The use of underscore-based naming variations has provided an easy,
> efficient and safe means of eliminating TXT usage ambiguity.  By way of
> examples, note the SRV record and DKIM, but there are others.

I think this email make exactly my point.

Q.E.D.

   Patrik

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 16 Feb 2014 07:52:55 -0800

> involves reuse of the TXT resource record.

Sorry, friend, but this is trolling. Or do you believe that DANE is not an innovation?

--Paul Hoffman

---

From: Christian Grothoff <[email-masked]>
Date: Sun, 16 Feb 2014 17:03:02 +0100

> Sorry, friend, but this is trolling. Or do you believe that DANE is not an innovation?

Well, I personally am not so sure that the delta to CERT records (RFC
4398) is all that big,
so is this really the best example you have? ;-).

---

From: Dave Crocker <[email-masked]>
Date: Sun, 16 Feb 2014 08:08:11 -0800

> I think this email make exactly my point.

Please explain.

By way of anticipating your response, I should not have removed your key 
conclusion:

      "Unless that is put to rest, we can not do much at all."

That is demonstrably not true, as well as the claim of consensus about 
not being able to do anything being wrong.

But even at the simple fact level, are you under the impression that SRV 
uses TXT?

d/

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 16 Feb 2014 17:39:33 +0100

> Sorry, friend, but this is trolling. Or do you believe that DANE is not an innovation?

I think so, and I like DANE, I am all in favor of innovation, but I see
strong forces against DANE, inside IETF.

Yes, I am just starting to investigate and try to mitigate, but the
forces against are the ones I see too often:

- We can not use new RR Types, lets use A and TXT
- DNSSEC will never take off
- Lets just use HTTP for transport

My point is that to get innovation, we have to over and over and over
again address these issues.

Ok, I take Daves point that there is no consensus from a process
definition of consensus in the IETF, but the _feeling_ is that there is
consensus as there is no consensus that we CAN add new RR-Types etc.

Just look at the SPF discussion, or the cert-for-secure-xmpp which is
what I refer to regarding "we can not use DANE as DNSSEC is not deployed".

I see too many similarities between the two.

And as I wrote, I claim those views block innovation more than anything
else in IETF at the moment.

   Patrik

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 16 Feb 2014 17:41:08 +0100

On 2014-02-16 17:39, Patrik Fältström wrote:
> I think so,

What I mean is that I *DO* think DANE is an innovation!

> and I like DANE, I am all in favor of innovation, but I see
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Joe Abley <[email-masked]>
Date: Sun, 16 Feb 2014 11:48:32 -0500

> - Lets just use HTTP for transport

I think we are suffering from a knee-jerk instinct to say no to ideas that we assume will never work in the real world.

We can't add more transports (e.g. SCTP), because even if implemented there's just too much middleware in the world that will interact badly.

We can't add more resource records, because there are nameserver implementations that don't deal with opaque types properly, and won't allow the new resource records to be published.

We can't do anything that will cause larger responses, because EDNS support is not widespread, and in any case the network can't reliably deliver fragments.

If we believe all these problems are intractable, then we might as well just accept that overloading TXT records and reflection attacks are a fact of life, and stop worrying about them.

What I would prefer, though, is a more entrepreneurial approach where the likelihood of short-term operational problems (or even long-term failure of the work) should not stop us from trying. Rich people are the ones that realise that you only need one out of ten business ventures to succeed to get a pay out.

So, how about a starting point where we assume that if a particular extension has value to anybody, the operators (the market) will adjust to allow it to work, and if it doesn't, then adjustments are not necessary?

Anybody else feel like working on the specification for SCTP transport? :-)

Joe

---

From: Paul Vixie <[email-masked]>
Date: Sun, 16 Feb 2014 11:44:42 -0800

> If we believe all these problems are intractable, then we might as well just accept that overloading TXT records and reflection attacks are a fact of life, and stop worrying about them.

reflection attacks aren't a fact of life. DNS RRL does not require a
forklift upgrade of the infrastructure, isn't stopped by middleboxes,
and does not change the protocol. i think you should discriminate more
finely as to what we ought and ought not give up about.

> What I would prefer, though, is a more entrepreneurial approach where the likelihood of short-term operational problems (or even long-term failure of the work) should not stop us from trying. ...

those were my exact words upon the publication of RFC 2671. it's been
fifteen years. i think if any change to the dns protocol was going to be
useful enough to overcome edge corruption and edge inertia, it would be
EDNS0.

however, it's heartening to see another generation of cannon fodder
lining up to enter the trenches. you go, joe. i'll cheer you on. but
i'll be working on a RESTful/JSON API to hide DNS edge traffic inside
TLS, in sessions not managed by any X.509 CA, while cheering you on.

> Anybody else feel like working on the specification for SCTP transport? :-)

go, joe, go!

vixie

---

From: Paul Wouters <[email-masked]>
Date: Sun, 16 Feb 2014 21:03:37 -0500 (EST)

On Sun, 16 Feb 2014, Dave Crocker wrote:

> That is demonstrably not true, as well as the claim of consensus about not 
> being able to do anything being wrong.

Needing TXT records is really a red herring. For instance, look at

http://tools.ietf.org/html/draft-wouters-dane-openpgp-02

and the implementation in:

https://github.com/letoams/openpgpkey-milter

(with supporting https://github.com/letoams/hash-slinger/blob/master/openpgpkey )

It uses a private use RRtype of 65280 and helps you create an RFC 3597
Generic Record type for records. At any time can now, I can ask for
an IANA registration - I've just waited a bit for a discussion and
WG adoption.

At no point in time did I need to use TXT records and at no point in
time did I need to modify DNS software. So yes, innovation via TXT record
has been put to rest a long long time ago.

The problem we have now is purely in process. During the last few IETF
meetings, I was always told I was a "guest" at DNSOPs, that it is the
wrong place for discussion about new RRtypes or EDNS options, and I've
been forced to use the DNSEXT mailing list of a closed WG. DNSOP needs
to broaden its charter, or we need to revive some kind of DNSEXT group.

So let's discuss WG scope and not TXT records.

Thanks,

Paul

---

From: Tim Wicinski <[email-masked]>
Date: Sun, 16 Feb 2014 21:16:12 -0500

> Perhaps DNSOP actually is the DNS innovation WG (if perhaps only as a seeding ground)?
As the co-chair or DNSOP who took this rather liberal view of our 
charter, I attempted to use the focus be the 'operational impacts' of 
several of the proposals, such at Mr. Wouter's too on tcp keepalives and 
query chaining.  I do believe it was the right thing to do, and I 
continue to do so.  We had great discussion on the topic and while 
nothing could be agreed on, there was some solid advice to take back on 
the issues.

One of the things we've been discussing internally (and have been 
negligent in bringing forward to the group) with our glorious ADs is 
expanding the charter.

tim

---

From: Watson Ladd <[email-masked]>
Date: Sat, 15 Feb 2014 08:44:27 -0800

Dear all,

Sincerely,
Watson Ladd

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 15 Feb 2014 10:36:35 -0800

> This proposal has multiple shortcomings compared to DNSCurve.

And some advantages over DNSCurve.

> and nuts onto a design is not improving it.

That is a value judgement that cannot be measured. While DJB's crypto
algorithms have been widely adopted, his crypto protocols have not.

> with the DH speed records we have today unnecessary.

That is a measureable criticism. Note that DNSCurve trades latency and
state for massive amounts more computation by parties who might not care to
do any. Even after many years, there has been no noticeable interest in
DNSCurve from those whom that protocol would hit the hardest.

> over the TLS connection.

True.

> Does it need a certificate?

No.

> Who should be
> allowed to sign it?

"Allowed"? Are we now the identity police?

> How should it be validated?

Using TLS authentication.

> DNSSEC provides a PKI,

They in fact might be fun; they have barely been explored.

> working, code implementing DNSCurve. This does not hold for this
I question "substantial" and  "operational" at the level that is expected
for this protocol. Regardless, there is substantial operational knowledge
of TLS that dwarfs whatever has been done for DNSCurve.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 15 Feb 2014 10:38:34 -0800

Cherry-picking the worst of the assertions...

On Sat, Feb 15, 2014 at 10:08 AM, Paul Vixie <[email-masked]> wrote:

> other crypto experts?

Yes.

> last i knew he was the only one claiming it was
> correct and strong enough for production use.

It has been widely discussed with no papers showing any flaws at all.

The crypto is not in question: the rest of the protocol is.

--Paul Hoffman

---

From: "John Levine" <[email-masked]>
Date: 17 Feb 2014 03:41:14 -0000

>involves reuse of the TXT resource record.

Yes, sort of.  The consensus in one part of the IETF is that adding
new RR types is too hard due to DNS server upgrades and particularly
to the web crudware that most people use to provision their DNS.  The
consensus in another part of the IETF is that adding new RR types is
trivial, and anyone who thinks otherwise is stupid.  (I oversimplify
but not by much.)

I've had a draft kicking around for a while, with recent additions
from Vixie, of an RR config language to allow the DNS to be largely
self-describing, with most new RR types having names and formats
published in a well known place so the servers and crudware can handle
new RRs without software upgrades (after a one-off upgrade to handle
the config language itself) or config changes.

The responses to the draft have been most educational.

R's,
John

---

From: Jay Daley <[email-masked]>
Date: Mon, 17 Feb 2014 19:38:53 +1300

> So, how about a starting point where we assume that if a particular extension has value to anybody, the operators (the market) will adjust to allow it to work, and if it doesn't, then adjustments a…

Very well put indeed.

The default position currently seems to be that consensus is so hard to achieve because it demands so much that very little can pass.  A particular symptom of that is the increasing calls for a "requirements draft" or "problem statement" (which is obviously wider than DNSOP).

We'd do well from turning that on its head and making the default position that everything passes unless consensus is that it shouldn't, which would generally be because it is truly awful, duplicative, nobody understands it, etc.

As Henry Ford probably didn't say "If I had asked people what they wanted, they would have said faster horses.”.  Or better still a genuine quote from Steve Crocker in the final ICANN board vote on new TLDs:  "The case for new TLDs is a little harder to pin down.  But one of the most important principles in the creation of the Internet from a very long time ago was not to stifle or prejudge what the paths for innovation are.  So the default has to be that, absent a strong case that such things will cause harm, we must move forward.  And I strongly support this."

Jay

-- 
Jay Daley
Chief Executive
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 931 6977
mobile: +64 21 678840
linkedin: www.linkedin.com/in/jaydaley

---

From: Ted Lemon <[email-masked]>
Date: Mon, 17 Feb 2014 11:22:19 -0500

On Feb 16, 2014, at 9:03 PM, Paul Wouters <[email-masked]> wrote:
> DNSOP needs

We would need to find some volunteers to act as co-chair.   I don't think adding the work to the DNSOP charter is the right thing to do, although I am not wedded to that position.   I just suspect that (a) it will make life in DNSOP harder and (b) we will get better review in an intarea working group.   But that's a fairly artificial point to be making, so argue away!   :)

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 17 Feb 2014 11:44:15 -0500

I am not convinced that DNS belongs in the Internet area.  It's an
application.  I think if we need a place to discuss broader DNS
innovation, then it should be in Applications.

But I also have pretty strong doubts that "DNS innovation" needs a
place for such discussion, on the grounds that when we _had_ such a WG
nobody did any work.  It was just a mailing list and WG for people to
say, "Get off my lawn."  Document reviews languished for months or
years.  LCs resulted in no comments. 

Why shouldn't that work go on in the WGs that want the innovations in
question?  Why shouldn't people who know about the DNS involve
themselves in the protocols that want to use these innovations so
that, instead of being Defenders of the Protocol Faith, they are
engineers trying to solve practical engineering problems that others
have, but in a way consistent with the deployed architecture?

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: joel jaeggli <[email-masked]>
Date: Mon, 17 Feb 2014 08:58:43 -0800

On 2/16/14, 8:48 AM, Joe Abley wrote:

> 
> We can't do anything that will cause larger responses, because EDNS
> support is not widespread, and in any case the network can't reliably
> deliver fragments.

in the context of reflection attacks (next paragraph) more packets is
perhaps not the most helpful thing.

> If we believe all these problems are intractable, then we might as
> well just accept that overloading TXT records and reflection attacks
> are a fact of life, and stop worrying about them.
>

---

From: Joe Abley <[email-masked]>
Date: Mon, 17 Feb 2014 12:25:05 -0500

> perhaps not the most helpful thing.

The problem to solve at the DNS end of the equation boils down to good enough client authentication to be able to distinguish between attack traffic and legitimate queries. The problem is not "how to stop putting things in the DNS".

Waiting for the universal implementation of the recommendations in BCP38 doesn't seem like the most proactive approach.

Joe

---

From: Ted Lemon <[email-masked]>
Date: Mon, 17 Feb 2014 12:57:40 -0500

> have, but in a way consistent with the deployed architecture?

Sure.   If dnsop wants to do this work, that's fine.

As for the dysfunction of the dnsext working group, I agreed to close it because as an incoming AD I wasn't entirely clear on what to do when the chairs requested that it be closed.   If I had it to do over, I would probably instead have solicited new chairs and tried to fix the dysfunction, which I agree existed there.

Unfortunately, the dysfunction will arise wherever DNS improvements are suggested, so not trying to fix it is not an option.   And of course I realize that many good IETF contributors have been ground to a nubbin trying to fix the aforementioned dysfunction, and have no particular reason to think I would have been more able to fix it than my predecessors.

---

From: David Conrad <[email-masked]>
Date: Mon, 17 Feb 2014 10:15:16 -0800

Ted,

On Feb 17, 2014, at 9:57 AM, Ted Lemon <[email-masked]> wrote:
> If dnsop wants to do this work, that's fine.

Given the various topics being discussed in DNSOP and the relatively high interest/reviews/comments/etc being shown, I think DNSOP is working fine.

> Unfortunately, the dysfunction will arise wherever DNS improvements are suggested, so not trying to fix it is not an option.   And of course I realize that many good IETF contributors have been gro…

Given experiences, I have to wonder if the whole idea of a long-term working group just leads to dysfunction -- perhaps the IETF version of an echo chamber (or perhaps even inbreeding).  Perhaps a better approach would be to use something like DNSOP which has an operations bent is use to see if there are ideas/interest in particular topics that can drive the creation of working groups that focus on the specific DNS-related issues?

Regards,
-drc

---

From: Ted Lemon <[email-masked]>
Date: Mon, 17 Feb 2014 13:35:47 -0500

> Given experiences, I have to wonder if the whole idea of a long-term working group just leads to dysfunction -- perhaps the IETF version of an echo chamber (or perhaps even inbreeding).  Perhaps a…

Yup.   However, creating working groups is a pretty heavyweight process—I think that's what motivates the long-term model for protocols where frequent extensions are likely.   Possibly rotating working group chairs more frequently would work in such cases.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 17 Feb 2014 10:38:41 -0800

> Unfortunately, the dysfunction will arise wherever DNS improvements are suggested, so not trying to fix it is not an option.   And of course I realize that many good IETF contributors have been gro…

Given your second paragraph, why create a new WG which will be an attractive nuisance? Andrew's proposal of letting WGs that want the innovations seems less likely to rekindle the dysfunction.

(Disclaimer: I an co-chair of a non-DNS WG that is fully manifesting the "lack of interest to even review WG items that people said they wanted" dysfunction that we are speaking of. And I want to shut it down.)

--Paul Hoffman

---

From: Ted Lemon <[email-masked]>
Date: Mon, 17 Feb 2014 13:42:36 -0500

> Given your second paragraph, why create a new WG which will be an attractive nuisance? Andrew's proposal of letting WGs that want the innovations seems less likely to rekindle the dysfunction.

Then you're just moving the dysfunction to the IETF mailing list, as we've seen in the recent past.   I'm not convinced that that's a win.

---

From: David Conrad <[email-masked]>
Date: Mon, 17 Feb 2014 10:44:24 -0800

On Feb 17, 2014, at 10:35 AM, Ted Lemon <[email-masked]> wrote:
> However, creating working groups is a pretty heavyweight process

Perhaps this is the problem that should be solved?

> Possibly rotating working group chairs more frequently would work in such cases.

This seems to imply the working group chairs have a larger role than I suspect is healthy (either for the WG chairs or the IETF as a whole).

Regards,
-drc

---

From: Suzanne Woolf <[email-masked]>
Date: Mon, 17 Feb 2014 13:45:01 -0500

> Given the various topics being discussed in DNSOP and the relatively high interest/reviews/comments/etc being shown, I think DNSOP is working fine.

This hasn't always been the case. At the moment, we've got a couple of high-profile issues by the tail and we're working to get some items that had gone dormant in front of the WG again. I hope the current level of interest can be sustained as needed to get work meaningfully defined and completed. Ask me in Toronto how I think we're doing :)
> Given experiences, I have to wonder if the whole idea of a long-term working group just leads to dysfunction -- perhaps the IETF version of an echo chamber (or perhaps even inbreeding).  Perhaps a…

This seems to me to be the function v6ops has in its charter as "Solicit input from network operators and users to identify operational issues with the IPv4/IPv6 Internet [for us, with DNS], and determine solutions or workarounds to those issues….This work should primarily be conducted by those areas and WGs which are responsible and best fit to analyze these problems, but v6ops may also cooperate in focusing such work."

In preliminary discussion of the re-chartering that will be on the agenda for London, we've already stumbled on the possibility that what's really needed here is something similar to what v6ops does-- a way to support getting a feedback loop closed between DNS operators and the assorted DNS users elsewhere in the IETF. The actual mechanism of that interaction may well include "problem statement" documents to be handed off to other WGs, but I think that's not necessarily a bad thing; the work should go where there are people motivated and able to do it, but still should be informed by focused expertise on the infrastructure, including DNS.

MHO (no hat): The balancing act is not only between operators and vendors/implementors, but also between DNS as an application that needs to evolve with the uses of the Internet and DNS as infrastructure that everyone relies upon and therefore should probably maintain some level of predictability and consistency. If DNSOP can't do anything useful towards managing that balance under its current charter, or a new charter that can get consensus support and action, we can and should shut it down.

Suzanne

---

From: Tim Wicinski <[email-masked]>
Date: Mon, 17 Feb 2014 13:46:40 -0500

> Yup.   However, creating working groups is a pretty heavyweight process—I think that's what motivates the long-term model for protocols where frequent extensions are likely.   Possibly rotating wor…

The two dnsext releated items we covered in DNSOP were EDNS0 options.  
Since OPT codes are now assigned by expert review, putting some of that 
discussion where the largest collection of DNS experts reside has some 
logic to it.

tim

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 17 Feb 2014 13:58:37 -0500

> We would need to find some volunteers to act as co-chair.   I don't think adding the work to the DNSOP charter is the right thing to do, although I am not wedded to that position.   I just suspect…

I think recreating DNS WG is a bad idea. 
We have a few ideas on the table in various that are related to 
	a) DNS transport TCP, SCTP, "tree answer: give me all records need to answer/validate X starting from point above X", 
	Zone transfer improvements 
	aa) DNS "privacy" ie. channel encryption/authentication 
	b) Operational Automation 
	c) Keeping noise out of DNS (AS112) and name spaces/meta-tld/alt TLD.
	d) New protocols adopting DANE
	e) Name server control protocols 

a) and aa) should have its own short term WG 
b) Belongs in DNSOP 
c) is above DNSEXT and DNSOP wg it is more of an intersection of many different areas like RAI, APPS, 
OPS and SECURITY  ==> a special WG 
d) DANE WG is handling that 
d) Domain boundaries BOF may turn into a WG. 
e) Belongs in DNSOP 

So Yes I see a need for a focused DNS protocol wg at this time.
The problem with long lived groups is you never know when new useful work will show up,
killing groups or just the threat of killing a WG seems to bring out innovation. 

	Olafur

---

From: Ted Lemon <[email-masked]>
Date: Mon, 17 Feb 2014 14:04:46 -0500

> Perhaps this is the problem that should be solved?

I don't know how practical that is.   Brian and I have talked about doing one-off meetings when we want to discuss DNS extensions at IETF meetings, since we have the dnsext mailing list for email discussions.   But that leads to AD-sponsored documents, which probably isn't the right thing to do on a large scale.

> This seems to imply the working group chairs have a larger role than I suspect is healthy (either for the WG chairs or the IETF as a whole).

Working group chairs are responsible for determining working group consensus.   It's really important (IMHO) for working group chairs to take action when mailing list discussions start to tube on non-consensus-affecting tangents.   I've seen numerous working groups fail when chairs don't do this.

So I really don't know what you mean by "larger role than is healthy."  Chairs are not secretaries.   They have real work to do, and a real leadership role.   They do not decide what the output of the working group should be—they determine consensus based on working group discussions.   But this is a difficult task to do well, and I think it's a pretty large role.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 17 Feb 2014 14:07:04 -0500

> killing groups or just the threat of killing a WG seems to bring out innovation. 

Yup, that's how DNSIND turned into DNSEXT.   :}

---

From: SM <[email-masked]>
Date: Tue, 18 Feb 2014 07:54:52 -0800

Hi Patrik,
>involves reuse of the TXT resource record.

In other words, it is only possible to use one of 
the code points as the people being part of the 
consensus do not work on getting code running. :-)

Seriously, it may take some effort to get things 
deployed but that is not an insurmountable task 
[1].  One of the problems is that there isn't any money in doing that.

Yes.

Regards,
-sm

1. I actually looked into it some time back.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 18 Feb 2014 11:57:10 -0500

> Sure.   If dnsop wants to do this work, that's fine.

No.  This was precisely my point.  For most of the stuff people want,
the work should be in a WG that does not have "DNS" in its name.
That's the _key_ point.  We protocol weenies need to get out of our
comfy chair and go learn why in the world people want to put
_anything_ in the DNS.  Our failure to do that is how we ended up with
the situation we have: we keep stamping our feet and saying that the
DNS works _just fine_ with new RRTYPEs, for instance, except that many
who want to use them cannot.

My view was that if there was something that was DNS-specific that
needed attention, people should have a BoF.  And look!  We have 2 BoFs
on specific DNS topics in London.  The questions are narrow and
focussed, not big floppy "gee, this looks like DNS, so it should be
swatted over to the DNS weenies" ones.  

If the goal is a "Get off my lawn" working group, then big generic
questions are in order.  But I think we can do better.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Suzanne Woolf <[email-masked]>
Date: Tue, 18 Feb 2014 12:10:30 -0500

> swatted over to the DNS weenies" ones.  

I'm sympathetic to this view, assuming I actually understand it, but not entirely sure what it says in terms of our charter discussion: should DNSOP go away, continue to address specific topics per the current charter, or add some kind of v6ops-like requirements/coordination-with-the-people-who-really-have-the-problem function? 

As I see it, we have another problem, complementary to the one you're highlighting, which is the number of situations arising where working groups across the IETF want to do something that makes certain assumptions about, or demands upon, the DNS, without DNS protocol weenies in the room at all. This strikes me as….suboptimal.

Is that a problem you (generically, not just Andrew) see as a concern? If so, do you see any general principles for navigating it? 

thanks,
Suzanne

---

From: SM <[email-masked]>
Date: Tue, 18 Feb 2014 08:19:23 -0800

Hi Andrew,
>innovation, then it should be in Applications.

To say it differently, DNS has a higher impact on applications work 
than work in other areas.  My guess is that things won't get any 
better if DNS is in the Applications Area.  The issue is cross-area 
reviews.  It is a problem when reviews are not being done [1].

Regards,
-sm

1. There are likely good reasons for that.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 18 Feb 2014 13:18:34 -0500

> Is that a problem you (generically, not just Andrew) see as a concern? If so, do you see any general principles for navigating it? 

I certainly think it's an important concern.   We have the same problem with DHCP, which is a much simpler protocol.

---

From: Joe Abley <[email-masked]>
Date: Tue, 18 Feb 2014 13:58:08 -0500

On 2014-02-18, at 10:54, SM <[email-masked]> wrote:

> Seriously, it may take some effort to get things deployed but that is not an insurmountable task [1].  One of the problems is that there isn't any money in doing that.
> 
> [...]
> 

I had some experience with this recently with the document that became RFC 7043.

Code-point assignment was swift. Implementation in major nameservers was swift (although one or two of them left the types commented out in the source until the RFC was published). The RFC publication process was not arduous, even given the privacy concerns with this particular proposal.

I appreciate that knowing the process made things easier (mainly; I was wrong about some things and had to be educated). But I would not describe the process as difficult, and certainly not insurmountable.

Joe

---

From: Mark Andrews <[email-masked]>
Date: Wed, 19 Feb 2014 09:19:48 +1100

In message <[email-masked]>, Joe Abley writes
:
> > Seriously, it may take some effort to get things deployed but that is
> not an insurmountable task [1].  One of the problems is that there isn't
> any money in doing that.
> >
> > [...]
> >
> Code-point assignment was swift. Implementation in major nameservers was
> swift (although one or two of them left the types commented out in the
> source until the RFC was published). The RFC publication process was not
> arduous, even given the privacy concerns with this particular proposal.
>
> I appreciate that knowing the process made things easier (mainly; I was
> wrong about some things and had to be educated). But I would not describe
> the process as difficult, and certainly not insurmountable.
>
>
> Joe

The process for getting a new type hasn't been *hard* for a decade
now.

Nameserver developers have been deploying new types quickly for
over a decade now.

Recursive servers have had the bugs w.r.t. handling unknown types
removed over a decade ago.

Being able to lookup a unknown type is a REQUIREMENT of RFC 103[45]
and there have been (stub) resolvers that can do this for the entire
life of DNS (Microsoft just fail to ship one).

We defined how to specify UNKNOWN record types in master files a
decade ago and most nameserver vendors have shipped code that support
unknown types for over a decade now.  Microsoft is the obvious
exception.

There are some load balancers that don't handle unknown types
properly.  Lots of these don't handle anything other than A. Not
AAAA, TXT, SOA, NS. These need to be chased down and removed /
replaced / upgraded with extreme prejudice.

There are the stupid DNS administration panels the don't handle
UNKNOWN types or for that matter anything other that A, NS and maybe
AAAA and TXT.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 19 Feb 2014 00:08:45 +0100

On 2014-02-18 19:58, Joe Abley wrote:
> I appreciate that knowing the process made things easier (mainly; I
> was wrong about some things and had to be educated). But I would not
> describe the process as difficult, and certainly not insurmountable.

Agree, and correct (I did the same with URI RR-Type). But then to start
to define applications using the RR... :-(

   paf

---

From: "Mark Delany" <[email-masked]>
Date: 18 Feb 2014 23:49:46 +0000

> removed over a decade ago.

Apart from the web-panels I'd say that the biggest bugbear is CPE such
as DSL/cable modems. Having conducted some experiments recently, my
observation is that some of these** have pretty atrocious cache/proxy
implementations. I had to drop the idea of using PTR for a particular
application because one implementation of dnsproxy assumes that PTR is
only ever valid in in-addr.arpa space (it had plenty of other bugs
too, but that's another story).

I see now that some newer CPE defaults to 8.8.8.8 - at least that
eliminates the local implementation bugs...

Mark.

** The irony won't be lost on you, Mark, that your neighbours are
   probably running with that bug since I found it in a popular DSL
   modem sold in Australia/SE Asia.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 19 Feb 2014 11:08:57 +1100

In message <[email-masked]>, "Mark Delany"
> eliminates the local implementation bugs...

And I would have gone ahead and implemented it as Autralian Consumer
Law requires a product to be fit for purpose and this modem clearly
wasn't.  The retailer need to refund or replace at the consumers
discression.  Once these !#!@$ boxes get sent back there will be
supply chain presure to fix the problems.

---

From: "Mark Delany" <[email-masked]>
Date: 19 Feb 2014 00:19:50 +0000

> Law

Probably true for most jurisdictions running u-verse modems too as
they too had breakage in my (not very fancy) tests.

I eventually went for a try-this-fall-back-to-that strategy. I won't
say which RR I used as the guaranteed-to-work fallback as I might get
a public flogging :-)

Mark.

---

From: George Michaelson <[email-masked]>
Date: Wed, 19 Feb 2014 11:29:43 +1000

in OID space, It was my experience that Russ ran the registry pretty
open-minded. Its a classic dewey-decimal growing numberfield, so the cost
burden of carving out a new OID is low, and he was minded to ask basic
questions, steer you, but in the end, assign a unique value for the wider
public benefit.

is there a quality to the RR registry that it HAS TO HAVE a high barrier to
entry? I've never tried proposing a new RR. I don't understand if, compared
to OID, it has a higher compliance, consequence, risk-side..

-G

---

From: Mark Andrews <[email-masked]>
Date: Wed, 19 Feb 2014 13:24:50 +1100

In message <[email-masked]>
> to OID, it has a higher compliance, consequence, risk-side..

What high barrier to entry?  Fill out a form and you get it basically
provided you meet the minimal criteria.  You can choose a experimental
type to test code with while you are waiting to the value to be assigned.

	http://tools.ietf.org/html/rfc6895

---

From: SM <[email-masked]>
Date: Tue, 18 Feb 2014 19:41:09 -0800

Hi Joe,
At 10:58 18-02-2014, Joe Abley wrote:
>Code-point assignment was swift. Implementation in major nameservers 
>was swift (although one or two of them left the types commented out 
>in the source until the RFC was published). The RFC publication 
>process was not arduous, even given the privacy concerns with this 
>particular proposal.
>

I was not thinking of the IETF process.  Mark Andrews covered what I 
was thinking of in a message at 
http://www.ietf.org/mail-archive/web/dnsop/current/msg11173.html

Regards,
-sm