Subject: [dnsext] CDS RRTYPE review - Comments period end Mar 29th

From: Roy Arends <[email-masked]>
Date: Tue, 8 Mar 2011 19:33:22 +0000

Dear Colleagues,

Below is a resubmission of a completed template requesting a new
RRTYPE assignment under the procedures of RFC5395.

This message starts a 3 weeks period for an expert-review of the DNS
RRTYPE parameter allocation for URI specified in
http://tools.ietf.org/id/draft-barwood-dnsop-ds-publish-01.txt

If you have any new comments regarding this request that have not yet
being made, please post them here before Mar 29th 18:00 UTC.

Kind Regards,
Roy Arends

--begin 5395 template URI--

   A.    Submission Date: 15 November 2010

   B.    Submission Type:
         [X] New RRTYPE
         [ ] Modification to existing RRTYPE

   C.    Contact Information for submitter:
            Name: George Barwood
            Email Address: [email-masked]
            International telephone number: +44 1452 722670
            Other contact handles: N/A

   D.    Motivation for the new RRTYPE application?

         To allow a copy of the DS RRset [RFC4034] to be published
         in the child zone, which is used to update the parent DS RRset.
         It is expected that this will allow the rollover of a key signing
         key to be automated.

   E.    Description of the proposed RR type.

         The format is identical to the DS record.
         However there is no special processing for servers/resolvers.

   F.    What existing RRTYPE or RRTYPEs come closest to filling that
         need and why are they unsatisfactory?

         None.

   G.    What mnemonic is requested for the new RRTYPE (optional)?

         CDS to stand for "Child DS".

   H.    Does the requested RRTYPE make use of any existing IANA
         Registry or require the creation of a new IANA sub-registry in
         DNS Parameters?

         It uses the same registries as the DS record.

   I.    Does the proposal require/expect any changes in DNS
         servers/resolvers that prevent the new type from being
         processed as an unknown RRTYPE (see [RFC3597])?

         No.

   J.    Comments:
         An RFC describing in detail how the CDS RRset may be used
         to update the parent DS RRset is anticipated. The current draft
         is draft-barwood-dnsop-ds-publish-01.

--end 5395 template URI--

_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Tony Finch <[email-masked]>
Date: Tue, 8 Mar 2011 20:32:05 +0000

>          It is expected that this will allow the rollover of a key signing

Why not just use the child zone's SEP DNSKEY RRs for this purpose?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Humber, Thames, Dover: West or southwest 5 to 7, occasionally 4. Slight or
moderate, occasionally rough. Occasional rain or showers. Moderate or good.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: "George Barwood" <[email-masked]>
Date: Tue, 8 Mar 2011 20:52:04 -0000

----- Original Message ----- 
From: "Tony Finch" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, March 08, 2011 8:32 PM
Subject: Re: [dnsext] CDS RRTYPE review - Comments period end Mar 29th

>From the draft http://tools.ietf.org/html/draft-barwood-dnsop-ds-publish-01

  A new resource record type is preferred to using flags in the DNSKEY
  RRset. It allows the DS to be published without revealing the public
  key, delaying the time at which an attacker can start cryptanalysis;
  the size of the DNSKEY RRset is not changed, which avoids potential
  transport problems with large responses; and it allows arbitrary DS
  records to be published which may have no corresponding DNSKEY, which
  might be useful in future for defining transport parameters.

George

---

From: Miek Gieben <[email-masked]>
Date: Wed, 9 Mar 2011 09:00:06 +0100

[ Quoting George Barwood in "Re: [dnsext] CDS RRTYPE review - Co"... ]
>   key, delaying the time at which an attacker can start cryptanalysis;

So this is the sole reason for adding this new type?

Regards,

--
 Miek

---

From: Jelte Jansen <[email-masked]>
Date: Wed, 09 Mar 2011 09:34:25 +0100

> So this is the sole reason for adding this new type?

disclaimer: I have not read this draft yet, but one other reason I could imagine
is to not have to change your DNSKEY rrset if you want to change what is
published at your parent, even if you do publish the dnskeys themselves.

Jelte

---

From: "George Barwood" <[email-masked]>
Date: Wed, 9 Mar 2011 08:45:51 -0000

----- Original Message ----- 
From: "Miek Gieben" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, March 09, 2011 8:00 AM
Subject: Re: [dnsext] CDS RRTYPE review - Comments period end Mar 29th

> So this is the sole reason for adding this new type?

There are 4 reasons given, why do you quote only one?
Please don't quote selectively.

One could probably add yet more reasons, e.g.
It gives the child control over which Digest Type is used.
It allows new Digest types to be deployed easily.
It allows easy verification (by humans) as to whether the parent and child zones are in sync.
But these are really just examples, fundamentally it's just proper design.
It gives the child zone proper control of the parent DS RRset.

George

---

From: Miek Gieben <[email-masked]>
Date: Wed, 9 Mar 2011 10:05:36 +0100

> Please don't quote selectively.

it is the first reason you give in the introduction in the draft.

> It gives the child zone proper control of the parent DS RRset.

...if the parent cooperates...

Is this proposal aimed at TLDs or at smaller zones? Because for .nl we
are just going to use EPP and let the registrar send in a DNSKEY which
we will convert to a DS (so you can not even choose your own hash
algo).

grtz,

---

From: "George Barwood" <[email-masked]>
Date: Wed, 9 Mar 2011 09:33:27 -0000

----- Original Message ----- 
From: "Miek Gieben" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, March 09, 2011 9:05 AM
Subject: Re: [dnsext] CDS RRTYPE review - Comments period end Mar 29th

> we will convert to a DS (so you can not even choose your own hash

It is not aimed at any particular zones, it is a general mechanism.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Scott Schmit <[email-masked]>
Date: Wed, 9 Mar 2011 08:30:17 -0500

> Why not just use the child zone's SEP DNSKEY RRs for this purpose?

I'm inclined to agree with this, but even if it's decided that the
DNSKEY RRs aren't sufficient, why not just use DS on the client side? I
see that RFC 3658 forbids it, but I'm not sure I understand why.  We
don't have CNS in addition to NS, so why should DS be different? I can
understand that DS must be ignored by a client unless it's signed by the
parent, but if that check doesn't already exist, we're already in
trouble.

So, maybe they didn't think of the use case this draft is trying to
address and forbade it to keep the software implementations simpler? But
that could have been accomplished simply by saying that a DS on the
child side is ignored for validation purposes (it now becomes pointless
(but harmless) to include it, except as a way to securely send DS
records from the child to the parent).

Even if this language tweak were to be applied after the fact, I don't
think there is an interoperability problem.  There are 4 cases:

1) the parent has no DS, nor does the child -- the pre-DNSSEC case

2) the parent has no DS, but the child does -- the DS must be regarded
as fake and ignored by resolvers already, or we have problems.  (Even
with the new draft, the parent MUST NOT attempt to use the DS in the
child to seed anything -- it needs to be supplied by a secure
mechanism, and a child DS signed by an untrusted DNSKEY isn't it)

3) the parent has a DS, but the child doesn't -- the current DNSSEC case

4) the parent has a DS, and so does the child -- this is the new thing
that this draft is trying to enable to support KSK rollover.

I would argue that case 4 should be harmless, unless I've overlooked
something: either nothing is looking for this and should ignore it, or
the DS should be regarded as fake by older software and ignored by
resolvers (if it's not, the software already has a security hole --
simply DOS a zone with an unsigned parent by sending fake DS records
purportedly from the child), or the DS should look valid (because it
fits a chain of signatures) and possibly extra DNSKEYs match & are
regarded as valid.  But since the chain of signatures is valid, it's
still secure.

If people started writing zone signers to rely on this mechanism to
introduce new keys, I could see there being interoperability issues
(some resolvers would treat the domain as secure, and others wouldn't),
but since this is new behavior, this draft can (and should) explain that
this cannot be relied upon (and DNSKEYs should be used instead for this
purpose).  Alternatively, to keep implementations simple, state that
child DS RRs MUST NOT be used as part of authenticating RR contents, but
they are allowed to exist and be queried for (and I could almost imagine
that the only code this would affect is zone checker tools). The only
place where that would be a problem is for people who want to use this
mechanism, so that's motivation to update the checkers anyway.

I can understand the motivation of introducing a new RRTYPE to avoid
needing to alter existing MUST NOTs, but CDS just seems unnecessary.

Maybe there's another reason to forbid DS on the child side that I've
overlooked?

-- 
Scott Schmit

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 9 Mar 2011 08:57:00 -0500

No hat.

On Wed, Mar 09, 2011 at 08:30:17AM -0500, Scott Schmit wrote:

> see that RFC 3658 forbids it, but I'm not sure I understand why.

I do not think this is the time to debate that design decision.  The
design of DNSSEC uses different RRTYPEs at the parent side of the cut
and the child side.  It is true that we use the same RRTYPE at the
parent and child sides for the NS record.  But even if you think that
was a good design (though I happen not to), the fact is that DNSSEC
did not follow that direction, and it has rules stating that the DS
isn't allowed on the child side.  We can't unmake that decision, and
we can't change it now without introducing a backward incompatible
change; so that is not an option open to us.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: "George Barwood" <[email-masked]>
Date: Wed, 9 Mar 2011 14:04:29 -0000

----- Original Message ----- 
From: "Scott Schmit" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, March 09, 2011 1:30 PM
Subject: Re: [dnsext] CDS RRTYPE review - Comments period end Mar 29th

> Maybe there's another reason to forbid DS on the child side that I've

Besides the fact that the existing standard forbids it, it does not work.

When you send a DS query to a resolver, it will query the parent zone, so you will not discover the DS RRset for the child. There are probably other reasons why it won't work - for example the BIND signer won't sign a zone with DS records at the Apex. It would be chaos.

The data is quite distinct, and you need a way of expressing that in a query.
The proper way is a new RRtype to express that distinction.

George

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 09 Mar 2011 09:19:50 -0500

<hat="RFC3658-editor">

> parent, but if that check doesn't already exist, we're already in

Using SEP bits in DNSKEY records does not work when a zone wants to 
retire an algorithm, the DS MUST be removed before the corresponding 
DNSKEY record is removed.

> records from the child to the parent).

RFC3658 specified for the first time a record that can only live at the 
parent and this required major changes to resolution algorithm 
implementations.
If there is anything we have learned in the last 25+ years of DNS is 
this: "If the same information can appear in two places it will not be 
the same and you have no idea which version resolvers will use"
Just look at what different resolvers do when the parent and child NS 
records differ.

> Maybe there's another reason to forbid DS on the child side that I've

see above, and new types a cheap, and this gives the child full control
over the changes in the DS in parent. Similarly this can be used to 
update trust anchors for an Island of security.

<disclaimer>
I encouraged George to submit this, as I had the same idea about the 
same time as he did, in the context of automating DNS operator 
change/transfer.
</disclaimer>
This record does not change the DNS control plane (resolvers) it is only 
published for information purposes and to be used by zone content 
management tools.

	Olafur

PS: I think that original DNS had NS RRset in two places was the biggest 
design mistake and we have spent lots of time and effort to overcome 
that. This choice was done for expediency and/or optimization reasons. s
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 9 Mar 2011 09:27:58 -0500

> change; so that is not an option open to us.

I think that a change in mid course here would be worse than merely
'incompatible'.

It would work maybe 90% of the time and fail in unpredictable and unexpected
ways the rest of the time.

We really need a design rule to help determine whether something should be a
new RR or not.

In my view, the design should attempt to:

1) Ensure that a query returns all the relevant information
2) Does not return irrelevant information

Here we have the DS record which gives the hash of key in the zone beneath.
I do not see a compelling use case that requires the hash of the subordinate
zone key to be returned at the same time as the hash of the zone key.

So according to the design rule above, this clearly requires separate
records - if there is a compelling use case for the actual record.

I have used the above design rules quite extensively in my attempt to
untangle the issues that result from the interference that occurs between
use of domain prefixes, aliases and wildcards.

-- 
Website: http://hallambaker.com/
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Tony Finch <[email-masked]>
Date: Wed, 9 Mar 2011 14:29:30 +0000

> It gives the child zone proper control of the parent DS RRset.

Thanks for pointing out the part of your draft that I missed. I searched
for KSK and SEP and didn't find any matches.

The reason I asked the question is that there would be a very nice economy
in re-using the existing SEP mechanism for this purpose. There's a certain
parallel between automatically maintaining trust anchors and automatically
maintaining secure delegations.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
South-east Iceland: Mainly northerly or northeasterly 5 or 6, occasionally 4.
Very rough or high. Wintry showers. Good, occasionally poor. Occasional light
icing in north.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Tony Finch <[email-masked]>
Date: Wed, 9 Mar 2011 14:33:25 +0000

On Wed, 9 Mar 2011, Olafur Gudmundsson wrote:
>
> Using SEP bits in DNSKEY records does not work when a zone wants to retire an
> algorithm, the DS MUST be removed before the corresponding DNSKEY record is
> removed.

Aha! Thanks.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Viking, North Utsire, South Utsire: Westerly, becoming cyclonic later, 5 to 7,
occasionally gale 8 except in North Utsire, becoming variable 4 at times.
Rough or very rough. Squally wintry showers, rain or snow later. Good,
occasionally very poor.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 9 Mar 2011 09:34:01 -0500

Like Olafur, I think that this record may well be useful in the context of
automating key management.

As such, it seems to me that it is quantitatively different from the URI and
CAA proposals for new RRs. In those cases the objective is to support
applications that build on top of DNS. So it is probably best to let them
rise or fall on their own merits. The alternative being for DNSEXT to get
into complicated negotiations and synchronizations with other WGs.

In this case the proposal is really one that addresses the DNS
infrastructure itself and so it may require a somewhat higher degree of
scrutiny.

On Wed, Mar 9, 2011 at 9:19 AM, Olafur Gudmundsson <[email-masked]> wrote:

> Using SEP bits in DNSKEY records does not work when a zone wants to retire
> an algorithm, the DS MUST be removed before the corresponding DNSKEY record
> is removed.
>
>
>
> If there is anything we have learned in the last 25+ years of DNS is this:
> "If the same information can appear in two places it will not be the same
> and you have no idea which version resolvers will use"
> over the changes in the DS in parent. Similarly this can be used to update
> trust anchors for an Island of security.
>
> <disclaimer>
> I encouraged George to submit this, as I had the same idea about the same
> time as he did, in the context of automating DNS operator change/transfer.
> </disclaimer>
> published for information purposes and to be used by zone content management
> tools.
>
>        Olafur
>
> design mistake and we have spent lots of time and effort to overcome that.
> This choice was done for expediency and/or optimization reasons. s
>

---

From: Matthew Pounsett <[email-masked]>
Date: Wed, 9 Mar 2011 10:47:06 -0500

> see that RFC 3658 forbids it, but I'm not sure I understand why.

In addition to the reasons given by others for not reworking a decision already made, I'll note a difference you've overlooked in your post.  The NS set in the parent zone is non-authoritative data which the NS set at the apex of the child zone overwrites in a cache.  The DS set in the parent zone is authoritative, and the child zone may not also claim authority for those records.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 09 Mar 2011 13:47:49 -0500

> we will convert to a DS (so you can not even choose your own hash

DNS >> TLD's  and even in among your registrars when do you expect the 
last one to support DNSSEC updating of DS records?

This mechanism can be used anywhere in the tree, and all it needs for 
use is a simple DNS lookup.
How the parent is told to perform the lookup or how frequently the 
parent does the lookup is outside the scope of this application.

	Olafur
PS:

---

From: Miek Gieben <[email-masked]>
Date: Wed, 9 Mar 2011 19:54:13 +0100

[ Quoting �lafur Gu�mundsson in "Re: [dnsext] CDS RRTYPE review - Co"... ]
> DNS >> TLD's  and even in among your registrars when do you expect
> the last one to support DNSSEC updating of DS records?

That state will probably never be reached.

But I agree: "new types are cheap"

grtz,

---

From: Paul Wouters <[email-masked]>
Date: Wed, 9 Mar 2011 14:20:03 -0500 (EST)

> ...if the parent cooperates...

yeah, this is "triggers vs timers" all over again. I did not think there was any
broad concensus on that?

If the parent needs to do work, it might as well use the SEP flag in combination
with the revoke bit.

> Is this proposal aimed at TLDs or at smaller zones?

I think TLDs because "smaller zones" tend to have other administrative cuts,
not neccessarilly on the zone cut.

> Because for .nl we

That is less of a concern then the dnsop <-> Registrar communication, which I
have the unfortunate experience of dealing with in non-standard ways precisely
for the DS record updating.

I don't think this issue is technical. SEP and Revoke is a fine solution,  but
an administrative one (parent does not want to kill child without a verified
authentication of child to keep the lawyers happy.

I don't see any method for automating the NS or Glue updates between child and
parent. If we'regoing to introduce new RRtypes for this communication, I'd
suggest tackling them all. And trust me, I'd love not to have to deal with
Registrar APIs in our products :P

Paul

---

From: Mark Andrews <[email-masked]>
Date: Thu, 10 Mar 2011 08:46:34 +1100

> change; so that is not an option open to us.

Additionally DLV, which is bit for bit identical to DS like this
record is, is a different type for exactly the same reasons this
record needs to be a different type.  And no re-using DLV is also
not apporiate.  DLV, CDS and DS can all exist at the same name.

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

---

From: Mark Andrews <[email-masked]>
Date: Thu, 10 Mar 2011 09:06:40 +1100

> DNSKEY record is removed.
 
RFC 5011 really doesn't work for trust anchors.  We should do something
similar with DNSKEY but add <START> <END> <POLL> fields to the front.
However this is not the thread to do this on.

Mark

---

From: "Stephan Lagerholm" <[email-masked]>
Date: Wed, 9 Mar 2011 17:41:25 -0700

>DNSKEY record is removed.
Good point. For the DNSKEY strategy to work, then it would have to be a
new flag.

>Just look at what different resolvers do when the parent and child NS
I agree.

>update trust anchors for an Island of security.
For whom do you feel that new types are cheap? Any provisioning program
that parses/constructs a zone file will have to be rewritten to be able
to understand this new type to be able to display/add/edit/remove it in
a meaningful way. I disagree that this is cheap.

We are just starting to see support in different tools for DNSKEY and
DS. Hopefully they made the flag field configurable. Adding a new flag
to DNSKEY would be cheaper.

/Stephan

---

From: Mark Andrews <[email-masked]>
Date: Thu, 10 Mar 2011 12:13:27 +1100

In message <[email-masked]>, "Ste
> a meaningful way. I disagree that this is cheap.

Adding new types shouldn't be expensive if you have designed your
applications to be extended from the begining and any application
dealing with arbitary DNS records should be so designed.

---

From: "George Barwood" <[email-masked]>
Date: Thu, 10 Mar 2011 07:10:25 -0000

----- Original Message ----- 
From: "Stephan Lagerholm" <[email-masked]>
To: "Olafur Gudmundsson" <[email-masked]>; <[email-masked]>
Sent: Thursday, March 10, 2011 12:41 AM
Subject: Re: [dnsext] CDS RRTYPE review - Comments period end Mar 29th

> to DNSKEY would be cheaper.

Not really.

In either case the software that signs zones has to be updated.

If the output is in text format, the generic text format of RFC3597 section 5
may be used if the serving software for the master server has not been updated.

The software for secondary servers does not need to be updated in any case,
assuming it implements RFC3597 ( that is it can handle unknown types ),
which is of course the case for all mainstream implementations.

---

From: Samuel Weiler <[email-masked]>
Date: Thu, 10 Mar 2011 07:01:43 -0500 (EST)

> There are 4 reasons given, why do you quote only one?

Actually, the TEMPLATE provides no reasons at all why the three 
previously-assigned RR types with the exact same format don't meet the 
need.  Field F in the template needs to include that analysis, whether 
or not it is also in the draft.

I pointed this out in my previous comments on November 16th, and it 
appears that the template is unchanged.

Please update the template.  From today's discussion, it looks like it 
also needs to include analysis of why DNSKEY and all of the other key 
and hash records won't meet the need, too.

(Note that I'm not arguing that we don't need a new type for this, 
just pointing out that this template hasn't met the minimum bar of 
saying why we do.  There's likely some very short language that would 
do the trick, but you do need to include it.)

-- Sam

---

From: "Stephan Lagerholm" <[email-masked]>
Date: Thu, 10 Mar 2011 12:48:30 -0700

George B and Mark A,

>In either case the software that signs zones has to be updated.

If adding a new flag to DNSKEY and if the software already supports the
DNSKEY RR with arbitrary flags, then no update is needed. For example, I
could use an old version of ISC dig and still make sense out of the
DNSKEY record even if a new flag was added. But I had to upgrade ISC dig
if I wanted to figure out details about the CDS record.

>may be used if the serving software for the master server has not been
updated.

The RDATA field would still just be a "blob". How would I for example be
able to verify the Key Tag, Algorithm or Digest Type field unless the
software you are using is programmed to understand that the format the
same as for the DS record?

>which is of course the case for all mainstream implementations.

Agreed, I'm taking about software that interacts with humans and try to
display something meaningful for them (provisioning system, IPAM,
debugging tools, etc)

(For the record, I'm positive to this draft other than using a new RR
type. I would rather like to see an "embryonic" flag to the DNSKEY
similar to what the revoked flag is doing for old keys is RFC5011)

/S

---

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 10 Mar 2011 17:17:22 -0500

> similar to what the revoked flag is doing for old keys is RFC5011)

Stephan,
there is a problem with using a flag as
the flag field is covered both by DNSKEY keytag calculation and DS 
digest calculation.
Thus changing the flag will "revoke" the key and/or its signatures,
unless validators know how to handle the flag change.

For all practical purposes the key flag field is a wasted space
I tried to have it killed when we did the type code rollover
(KEY ---> DNSKEY) along with the protocol field, but ......

	Olafur

---

From: Mark Andrews <[email-masked]>
Date: Fri, 11 Mar 2011 10:33:32 +1100

In message <[email-masked]>, "Ste
> if I wanted to figure out details about the CDS record.

Running DS throug a really old version of DiG produces this:

isc.org.		20h56m50s IN TYPE43  \# 36 (	; unknown RR type
	32 5c 05 02 f1 e1 84 c0 e1 d6 15 d2 0e b3 c2 23 ; 2\.............#
	ac ed 3b 03 c7 73 dd 95 2d 5f 0e b5 c7 77 58 6d ; ..;..s..-_...wXm
	e1 8d a6 b5 )					; ....
isc.org.		20h56m50s IN TYPE43  \# 24 (	; unknown RR type
	32 5c 05 01 98 21 13 d0 8b 4c 6a 1d 9f 6a ee 1e ; 2\...!...Lj..j..
	22 37 ae f6 9f 3f 97 59 )			; "7...?.Y

The key id is 0x325c (12892), the algorithm in 5 and the hashs are 2
for the first and 1 for the second.

> same as for the DS record?

Given the blob is printed in hex you could just read two of those fields
directly and the third nearly as easily.

	Digest type: 01 or 02 (currently in use)
	Algorithm: 01 ... 0a  (currently in use)
	Keytag: is a little harder but not much.

Or you could take the TYPEXXX .... and turn in into TYPE43 ... and
put that through any piece of software that understands DS and
unknown types.

---

From: "Stephan Lagerholm" <[email-masked]>
Date: Thu, 10 Mar 2011 18:48:05 -0700

>Thus changing the flag will "revoke" the key and/or its signatures,
Yes, the keytag would change when a key went from Embryonic to KSK, just
like it is doing for RFC5011 revoked (flag 385) keys. The parent would
have to take that into accont when creating the DS record.

>unless validators know how to handle the flag change.
This embryonic key would not be used to sign anything, so validators
would not be affected.

>(KEY ---> DNSKEY) along with the protocol field, but ......
It is not wasted space, RFC5011 is using it. There are programs such as
autotrust that relies on it, we use it to signal what keys are SEP keys,
etc... 

RFC5011 is using it to signal that a key is "dead". Why can we not use
another flag to signal that a key is about to get "born" (prior to the
DS is being published at the parent)?

/S

---

From: "Stephan Lagerholm" <[email-masked]>
Date: Thu, 10 Mar 2011 18:57:31 -0700

Mark,

>for the first and 1 for the second.

Our definition of what "display it in a meaningful way" differs. If a
new flag was used instead, then no changes to dig or any other program
would be needed:

                        VVVV                    VVV
isc.org.                5361    IN      DNSKEY  512 3 5
BEAAAAO6L6BadeFzvt6J63GD
GrFANfJAitCd9Njcj49y6PE1Bv6t33sE
yxSVi4KWbjQgViMCxAArxP0IhDLhYFGbsU2ugkQ4UMFCPgY
IVxC1yvBw 1Gt7p+SBQU9qX+Il/cqYTJWQkWRdDPHJoaMT1+f7e6YLlntxpl+M7yw3
aOEbCByPzw==

/S

---

From: Mark Andrews <[email-masked]>
Date: Fri, 11 Mar 2011 15:07:19 +1100

In message <[email-masked]>, "Ste
phan Lagerholm" writes:
> aOEbCByPzw=3D=3D

The on going costs of trying to do this with DNSKEY flags completely
overwhelms the one off costs of add a new type.  DNSKEY flags change
key ids.  Revoke is already a mess as it changes the keyid.  Adding
a second changing flag to the mix is just not on.

I can add CDS to BIND in 10 minutes once I have the type code.
It would be weeks of work to add the key flags as you need to do
thinks like compute the signatures with and without the flag in
place or fully work out all the timing issues.

Mark