Subject: [dane] draft-ietf-dane-protocol-19.txt typos and minor fixes

From: John Gilmore <[email-masked]>
Date: Thu, 12 Apr 2012 10:30:35 -0700

Typo: s/certifcate/certificate/

Section 7.1: s/will be submitted/has been submitted/  .  I'm surprised
that we don't have an assigned value for the TLSA rrtype yet.

Section 7.3: value 3, "Domain-issued certificate" has an extra space
misaligning its [Reference] value.

Section 8 and 8.1 have serious problems that deserve a whole separate
email message.

Section 8: The last paragraph should be removed, because it
unnecessarily disparages the security of the protocol defined by this
RFC.

Section 8.1: This newly inserted section needs serious work.  It was
inappropriate to insert this inflammatory section into the document
immediately before Last Call, with little mailing list discussion
beforehand.

Appendix A.1 is totally focused on CA-based examples, and provides no
guidance to users who want to deploy non-CA-based DANE.  Nor does it
provide any guidance for domain administrators who are not sure
whether they want CA-based DANE or non-CA-based DANE.  I had written
and submitted text about this, but none of it made it into the
document.

The appendix is written as if there is not even an option in DANE to
avoid using CAs.  One might reasonably come to the conclusion that
committee members associated with CAs are deliberately slanting the
readers of the document toward their business model.  This is not
appropriate in an RFC.

Appendix C:  Is missing examples for usage type 3.

	John

---

From: SM <[email-masked]>
Date: Thu, 12 Apr 2012 10:48:49 -0700

>that we don't have an assigned value for the TLSA rrtype yet.

It's sometimes easier to add the assigned value on publication of a 
document as a RFC.  The request for the TLSA RRTYPE has already been accepted.

Regards,
-sm

---

From: James Cloos <[email-masked]>
Date: Thu, 12 Apr 2012 16:49:41 -0400

>>>>> "S" == SM  <[email-masked]> writes:

S> It's sometimes easier to add the assigned value on publication of
S> a document as a RFC.  The request for the TLSA RRTYPE has already
S> been accepted.

Nonetheless, we need to get the number asap to ensure that the
existing software is updated in time.

I can take *months* for such updates to percolate into the published by
distributions and therefor in active use.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

---

From: SM <[email-masked]>
Date: Thu, 12 Apr 2012 14:18:17 -0700

Hi James,
>distributions and therefor in active use.

It's unlikely that it will take months to assign the number.  You 
could talk to the WG chairs and see whether they can help out if 
there is such an urgency.

Regards,
-sm

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 12 Apr 2012 17:58:55 -0400

> distributions and therefor in active use.

The expert already reported back.  We're waiting for IANA.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Frederico A C Neves <[email-masked]>
Date: Thu, 12 Apr 2012 18:59:21 -0300

John,

> that we don't have an assigned value for the TLSA rrtype yet.

Regarding the 6195 allocation process this is already done.

http://www.ietf.org/mail-archive/web/dnsext/current/msg12420.html

In our recommendation to IANA, based on a criteria the current experts
are following, I've suggested 52 as the value for TLSA, but they have
not yet returned with the actual allocation. Take this with handful of
sault as they could assign a different value if they like.

Fred

---

From: James Cloos <[email-masked]>
Date: Thu, 12 Apr 2012 18:16:08 -0400

>> It can take *months* for such updates to percolate into the published by

S> It's unlikely that it will take months to assign the number.  You
S> could talk to the WG chairs and see whether they can help out if there
S> is such an urgency.

I suppose I was inadvertently ambiguous.  The delay I wrote about is
from when a change is commited to a software repository until it is
included in a published release and then included in a distribution.

Authoritative dns server releases are infrequent; if dane misses this
springs release cycle there is no expectation that the next releases
will be out before late fall or even next year.  And there is no
guarantee that any of the distributions will accept a patch for
whichever version(s) they ship to fix the tlsa rr value.  Especially for
their "stable" series.

-JimC

---

From: Mark Andrews <[email-masked]>
Date: Fri, 13 Apr 2012 10:47:10 +1000

> whichever version(s) they ship to fix the tlsa rr value.  Especially for

You can use TLSA records the moment the number is publish in
*existing* authoritative servers provided they support RFC 3597
(Published September 2003).

I can do the conversion between TLSA presentation format and RFC
3597 format in my head.  The hardest part is counting the number
of octets in the record.  It's a trival awk program to covert the
rdata if the record is all on one line.

{
        len=0;
        for (i=4; i <= NF; i++) {
                len += length($i);
        }
        len /= 2;
        len += 3;
        printf "\\# %d %02x%02x%02x", len, $1, $2, $3;
        for (i=4; i <= NF; i++) {
                printf "%s", $i;
        }
        printf "\n";
}

It's a little more complicated if you want to support multi-line
records.  Adjust if you want to handle owner, ttl, class and type
fields.

Mark

> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Fri, 13 Apr 2012 10:58:04 +1000

We should recommend that tools that convert certificates to TLSA
records "SHOULD" support emitting the record in RFC 3597 format in
addition to TLSA presentation format.

Mark

---

From: Paul Wouters <[email-masked]>
Date: Thu, 12 Apr 2012 21:51:15 -0400 (EDT)

> addition to TLSA presentation format.

That's what "dane" and "swede" do. For dane I used --draft and --rfc
to make the difference.

Paul

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 13 Apr 2012 17:36:14 -0400

IANA has just published the allocation in
http://www.iana.org/assignments/dns-parameters

Feel free to start releasing code using this allocation!

	Olafur

---

From: Warren Kumari <[email-masked]>
Date: Fri, 13 Apr 2012 19:48:59 -0400

Thank you, Olafur…

W

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 13 Apr 2012 18:14:07 -0700

> Feel free to start releasing code using this allocation!

The document is in IETF Last Call and getting active discussion. After IETF Last Call, the IESG will consider the specification.

*** THE TECHNICAL PART OF THE SPECIFICATION CAN CHANGE BETWEEN NOW AND WHEN IT IS SENT TO THE RFC EDITOR. ***

It would be irresponsible to start releasing code at this point in time. It would be wonderful to start releasing code after the IESG has passed the document on to the RFC Editor.

--Paul Hoffman

---

From: bert hubert <[email-masked]>
Date: Sat, 14 Apr 2012 11:26:11 +0200

> Feel free to start releasing code using this allocation!

Snapshot 2567 of the PowerDNS Authoriative Server, which is identical to
3.1-RC2 except for the move to the IANA code for TLSA, can be found on
http://powerdnssec.org/downloads/ - as deb/rpm for intel/amd64, plus tar.gz.

Paul H, I hear your worry that the RFC Editor might change things, but I
consider the chance of the wire or zone format changing to be very small.

I hope we can put this to rest before we release 3.1-final. 3.1 is slated to
host >1 million DNSSEC domains pretty soon, it would be very cool if we
could get these 1 million domains to be DANE-capable.

3.2 is not predicted to happen within 6 months of 3.1.

	Bert

-- 
PowerDNS Website: http://www.powerdns.com/
PowerDNS Community Website: http://wiki.powerdns.com/
PowerDNS is supported and developed by Netherlabs: http://www.netherlabs.nl

---

From: Olafur Gudmundsson <[email-masked]>
Date: Sat, 14 Apr 2012 08:32:08 -0400

> It would be irresponsible to start releasing code at this point in time. It would be wonderful to start releasing code after the IESG has passed the document on to the RFC Editor.

Paul,

It is safe to release code handles the TLSA DNS record in DNS software 
or translates to and from TLSA record.
Writing code that translates CERT's into TLSA records can proceed.
Writing code that processes and interprets TLSA records should wait.

I would be surprised if the wire format of TLSA will change now.
Yes there is a possibility that a type of certificate support be 
added/deleted, but that will not affect DNS side that much.
DNS infrastructure software changes slowly thus getting an opportunity
to get TLSA into releases between now and when the RFC is published
can only help the long term DANE deployment as there will be some
support for in the beginning.

Bert, ship it.

	Olafur

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 14 Apr 2012 08:12:40 -0700

> consider the chance of the wire or zone format changing to be very small.

You hear wrong. There is no chance that the RFC Editor will change things that would affect the protocol. There is a very real chance the IETF consensus process or the IESG will.

> could get these 1 million domains to be DANE-capable.

The IETF process goes at its own pace, for better or worse.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 14 Apr 2012 08:20:10 -0700

On Apr 14, 2012, at 5:32 AM, Olafur Gudmundsson wrote:

> It is safe to release code handles the TLSA DNS record in DNS software or translates to and from TLSA record.

We disagree on both counts.

> Writing code that processes and interprets TLSA records should wait.

Correct. If you knew that, maybe you could have been a tad more clear in your earlier message.

> I would be surprised if the wire format of TLSA will change now.

You are not the developer of software that has to deal with a change between now and RFC approval. Your recommendation was to people who will seriously damaged by a change, whereas all that would happen to you would be surprise.

> Yes there is a possibility that a type of certificate support be added/deleted, but that will not affect DNS side that much.

You are ignoring the infrastructure code that signs the records and focusing on the server software that publishes them. 

> support for in the beginning.

"can only help" if you ignore the chance that what is being put into the software is wrong.

Also, to be clear, I didn't say "when the RFC is published", I said "when the IESG sends it to the RFC Editor". The latter is way sooner than the former.

--Paul Hoffman

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 16 Apr 2012 11:43:31 -0400

> We disagree on both counts.

Nothing new.

> Correct. If you knew that, maybe you could have been a tad more clear in your earlier message.

Yes if that had stopped Process Orthodoxy jerk reaction from you.

> You are not the developer of software that has to deal with a change between now and RFC approval. Your recommendation was to people who will seriously damaged by a change, whereas all that would h…

If the DNS wire format for the DNS record that DANE needs changes,
I will argue that a new RRtype needs to be allocated.

The TLSA record is a simple thing, the interpretation of the TLSA record 
is the complicated part of DANE.

> You are ignoring the infrastructure code that signs the records and focusing on the server software that publishes them.

DNSSEC signing is on wire-format DNS records, what developers can now do 
is to translate between presentation and wire formats
	===> this enables DNSSEC signing.

> "can only help" if you ignore the chance that what is being put into the software is wrong.

I have asked this question few times in the past:
	"Is the TLSA part of the DANE spec ready ?"
Until recently the answer was always "we think so but we are not sure".
This was a reasonable approach, thus if the TLSA was not ready when the 
early allocation request was made, why not just wait for IANA allocation 
after IESG approval?

The whole point of early allocation was to enable early NATIVE support 
of the TLSA record in the DNS infrastructure!!!
Your attitude on this list seems to be to spread FUD and derail early 
TLSA support.

> Also, to be clear, I didn't say "when the RFC is published", I said "when the IESG sends it to the RFC Editor". The latter is way sooner than the former.

Fair enough, RFC publication takes place about 2 months after IESG 
approval, and how long it takes IESG to process a document is random.

	Olafur

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 16 Apr 2012 12:40:20 -0400

Hi there,

> I will argue that a new RRtype needs to be allocated.

I'm not sure I agree with this.  

The reference in the RRTYPE Registry is neither to a draft nor to an
RFC, but to "Kumari".  That means that the wire format is going to be
whatever Warren says it is until such time as the reference is
stabilized.  We adopted this flexibility for expert assignment of
RRTYPEs in order to permit early assignment even in cases where we
expected the wire format to be less than perfectly stable.  The side
effect of this has to be that those shipping code ought to be
extremely wary of shipping anything without a stable reference.
Experimental features -- and they're necessarily experimental until
the reference is stable -- ought to be treated as such.

So, if I were shipping code, I would not ship a version with TLSA
turned on until I was sure what the wire format would be.  And I
couldn't be sure of that until there was a document in the reference
that specified it in writing.

> The TLSA record is a simple thing, the interpretation of the TLSA
> record is the complicated part of DANE.

The other complicated part of DANE is getting it through the IESG.

> This was a reasonable approach, thus if the TLSA was not ready when
> the early allocation request was made, why not just wait for IANA
> allocation after IESG approval?

Well, one reason is so that people could deploy experimental code
today, with the understanding that, at any moment, the wire format of
RRTYPE 52 could change.  We have reason to suppose it is stable, but
until the RFC is published, we cannot be sure.  That is _always_ true
-- it's true for this case, and it's also true for all the other
non-RFC references in the registry.  Last I checked, none of us had an
unerring ability to predict the future, and I'd hate for people to
interpret "code point in the registry" as some sort of promise about
what will happen when a document goes to the IESG.  Nobody can make
those promises.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 16 Apr 2012 15:24:22 -0400

> stabilized.  We adopted this flexibility for expert assignment of

But the application in this case referenced a particular version of an
Internet draft:
----
   E. Description of the proposed RR type.
      A description of tge RR type is in 
draft-ietf-dane-protocol-18.txt, Section 2 The TLSA Resource Record
      ( http://tools.ietf.org/id/draft-ietf-dane-protocol-18.txt )
----

Version 18 of the draft says format is (my notation):
	oct, oct, oct, Hex_n
where the value n depends on one of last 8 bit integer  field.

If a theoretical future version says:
	short, int, oct, Hex_32

I would consider that breach of good faith by the applicant to insist on 
using the allocated type code.
If there are changes in the registries that are created by the ID that 
is fine.
Type codes are cheap, interoperability problems are not.

> the reference is stable -- ought to be treated as such.

There is code range for experimentations, see RFC6195 section 2.3
	   0x0F01 - 0x0FFF     Private Use

Andrew I hate to correct you, the whole point of early allocation was to 
avoid having to publish an standards track RFC in order to get
an RR type code.
There is no requirement to even publish anything about the record 
processing anywhere, much less as an RFC.
But if you expect the type code to be in wide use you have a heavier 
burden of acting a responsible manner.

> that specified it in writing.

This is the crux of the matter, when is the expert review allocation 
process RR spec stable?

I argue at the time of expert application. You and Paul argue that the 
record can be tinkered with after that (at least) if it references an 
Internet draft.

> The other complicated part of DANE is getting it through the IESG.

out of scope for this discussion.

> RRTYPE 52 could change.

what is wrong with using 0xf?? values for that ?

all you need to do is to send a email to the wg mailing list saying
"I want to do an experiment and we will use code X here is my format."
the private RRtype either contains version number or you roll the code 
each time there are wire format changes. In this case only consenting 
implementations are at risk.

>  We have reason to suppose it is stable, but

For people that feel like this I say:
"IETF standards track documents SHOULD NOT use the DNS early allocation 
process"

Furthermore I will say:
If a simple building block like DNS record format needs to change during 
IESG review, the whole WG effort is suspect and it should be sent to 
back to the drawing board.

	Olafur

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 16 Apr 2012 15:59:34 -0400

This is really a discussion about an issue for the DNSEXT WG, so it's
cc:d there.  Follow ups should go there, too, unless they're linked
tightly to the DANE issue.  I didn't adjust the Followup header
because in my experience that never works.

> But the application in this case referenced a particular version of an

Yes.  This is why some people have objected to the difficulty of
getting the approved templates.  The template as in the application is
not necessarily what was approved.  I think in this case it is, but as
we see the registry does not actually preserve the link.

> If there are changes in the registries that are created by the ID
> that is fine.

Yes.  Which is rather a good reason to hesitate to ship code that
doesn't have a stable refernence in the registry, if you ask me.

> 	   0x0F01 - 0x0FFF     Private Use

Yes, I'm perfectly aware of that.  The complaint has been that people
want to be able to ship things with what they regard as minor
differences without having to go through the DNS mafia again.  Like it
or not (I'm in the "not" camp), people are engineering around our
community's intransigence.

> Andrew I hate to correct you, the whole point of early allocation
> was to avoid having to publish an standards track RFC in order to
> get
> an RR type code.

That could be better achieved by "specification required".  Expert
review allows us to allocate a type code without any guarantee that
the wire format will remain stable.  There is exactly one way to
guarantee that such a wire format will remain stable, and that is to
publish something in an archival series.  We have a way to do that:
publish an RFC.  Requiring conformance with RRTYPE application
templates or anything else is nonsense, because the references aren't
stable.  This is in fact a much more serious example of the same fight
we had when we tried to be clever with the registry in the
registry-fixes attempt some time ago.  (In that case, I happened to
think we were right, but the objection rested on the same foundation:
if you want a stable reference, put it in an RFC.)

> the private RRtype either contains version number or you roll the
> code each time there are wire format changes. In this case only
> consenting implementations are at risk.

Nothing, of course.  I have no idea why people even want RRTYPE
assignments prior to publishing an RFC with the specification, but
people do.

> If a simple building block like DNS record format needs to change
> during IESG review, the whole WG effort is suspect and it should be
> sent to back to the drawing board.

I fully agree.  But it is one thing to say, "This sure hadn't better
change.  If it does, something is really wrong," and quite another to
say, "This can't possibly change."

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Ondřej Surý <[email-masked]>
Date: Tue, 17 Apr 2012 01:17:40 +0200

> because in my experience that never works.

<dane chair hat on>
Yes, please keep the further discussion off this list.  And everybody
please cool down before responding, or rather do not respond here at all.
</dane chair hat off>

<personal hat on>
Feel free to do whatever you want, but please be aware, that we have
not reached the RFC status yet.  So same rules applies as when you were
using "experimental" allocations in your code.  E.g. if you have tools
which used TYPE655xx, then feel free to use TYPE52, but clearly mark
that as experimental feature, which can change.
</personal hat on>

O.
--
 Ondřej Surý
 vedoucí výzkumu/Head of R&D department
 -------------------------------------------
 CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
 Americka 23, 120 00 Praha 2, Czech Republic
 mailto:[email-masked]    http://nic.cz/
 tel:+420.222745110       fax:+420.222745112
 -------------------------------------------