Subject: [dnsext] Possible DNSSECbis clarifications

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 28 Mar 2011 04:12:10 -0400

Dear colleagues,

The following is a result of a side conversation on the interpretation
of RFC403x with number of DNS colleagues.
Any mistakes in the questions are mine.

The questions are:
1) What is the valid order of signed RRsets?
2) How many times SHOULD/MUST RRSIG(SOA) appear in an AXFR?
3) What RRSIG(SOA)'s MUST appear on the wire in an IXFR transaction?

Q1) A: In RFC403x there is no order requirement on an signed RRset thus 
implementations should be ready to handle any combination
Following Examples should be treated as the same RRset
	RR1		RR3		RRSIG2
	RR2		RRSIG1		RR2
	RR3		RR1		RR3
	RRSIG1		RR2		RRSIG1
	RRSIG2		RRSIG2		RR1

Q2) In AXFR the SOA record is used as a marker record to signal the 
beginning of a zone transfer and the end of the zone transfer.
The open question is how many times should RRSIG(SOA) appear in the
AXFR stream ?
	a) Only once
	b) Both times
	c) Does not matter both are ok.

if the answer is a) then the question is when should it appear,
	i) in the beginning after the SOA
	ii) at any time in the AXFR
	iii) just before the final one.
	iv) after the final one.

Q3) In IXFR there are multiple SOA records used as maker both on the 
overall transaction and on each delta.
The questions here are:
Which RRSIG(SOA) i.e. for each serial number, are needed ?
	a) All of them once
	b) all of them each time SOA appears
	b) only the final one, all the other ones are immaterial
	  (open question is how often and where)
	c) The first and last one and each only once,
	   the first one is needed to identify what to delete from
	   the zone, the final one is what is going to be in the
            zone after the IXFR is applied.

Is there need put this information in dnssec-bis (the answer to the AXFR 
question may update RFC5936) and in IXFR-bis document ?

	Olafur

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

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 28 Mar 2011 17:16:33 +0900

> of RFC403x with number of DNS colleagues.

If you are talking about bis, DNSbis with 32 or 64 bit message
ID is the way to go.

						Masataka Ohta

---

From: "George Barwood" <[email-masked]>
Date: Mon, 28 Mar 2011 09:59:06 +0100

My understanding on these questions...

----- Original Message ----- 
From: "Olafur Gudmundsson" <[email-masked]>
To: <[email-masked]>
Sent: Monday, March 28, 2011 9:12 AM
Subject: [dnsext] Possible DNSSECbis clarifications

> Following Examples should be treated as the same RRset

Agreed. Within a section, records may be in any order.
The normal aproach is to have RRSIGs immediately follow that records that
they sign, but this is not required by the standard.

> iii) just before the final one.

RRSIG(SOA) records should be anywhere after initial SOA and before the final SOA record.
 
>            zone after the IXFR is applied.

I'm not familiar with IXFR, so no opinion on this one.

George

---

From: "Marc Lampo" <[email-masked]>
Date: Mon, 28 Mar 2011 11:07:41 +0200 (CEST)

Hello,

Only a feedback on Q2) # times the RRSIG(SOA) should appear in zone
transfer.

I think "b) both times".
Motivation.
While the second SOA might serve as an indicator of "end of zone
transfer",
it also indicates that the transferred zone was not changed (at sender
side)
during the time it took to send the zone file.
Because, if it did change (at sender side) the serial number in the final
SOA would change.
Consequently, since there is a possibility that the second SOA might be
different from the first SOA,
it's RRSIG will be different as well : so, each SOA should be accompanied
by its (own) RRSIG.

Perhaps this brings an additional challenge :
 ? how to link a RRSIG(SOA) with the proper SOA record ?
   --> make it mandatory to have the RRSIG(SOA) immediately follow the SOA
record it signs ?

Kind regards,

Marc Lampo

-----Original Message-----
From: Olafur Gudmundsson [mailto:[email-masked]] 
Sent: 28 March 2011 10:12 AM
To: [email-masked]
Subject: [dnsext] Possible DNSSECbis clarifications

Dear colleagues,

The questions are:

	Olafur

---

From: Mark Andrews <[email-masked]>
Date: Mon, 28 Mar 2011 20:28:46 +1100

> 	iii) just before the final one.

All records with the exception of the SOA should appear once but
multiple should be handled. This is covered in AXFR clarify. The
record should be between the SOA records.  The SOA records bookend
the zone transfer.
 
>             zone after the IXFR is applied.

IXFR contains sets of deltas which consist of the *records* that
have changed in the zone.  Assuming a properly signed zone you
will have the final SOA, the starting SOA, RRSIGs of the starting SOA + any
other changes, the next (possibly final) SOA, the RRSIGs of the SOA
that apply to that and any other changes,  possibly the next delta,
.... then the final SOA.

> question may update RFC5936) and in IXFR-bis document ?

No.
 
-- 
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: Antoin Verschuren <[email-masked]>
Date: Mon, 28 Mar 2011 11:35:06 +0200

Nice thought:
Should an SOA record be signed anyway ?
The SOA is only a signaling record, and the result is never going to be
used by any application.
The header (including the ad bit) is also not signed, and the DNSKEY
record does not need to be signed with a ZSK.

>> question may update RFC5936) and in IXFR-bis document ?

- -- 
Antoin Verschuren

Technical Policy Advisor SIDN
Utrechtseweg 310, PO Box 5022, 6802 EA Arnhem, The Netherlands

P: +31 26 3525500  F: +31 26 3525505  M: +31 6 23368970
mailto:[email-masked]  xmpp:[email-masked]
http://www.sidn.nl/
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Joe Abley <[email-masked]>
Date: Mon, 28 Mar 2011 13:53:56 +0200

> While the second SOA might serve as an indicator of "end of zone

It's not the end of the transferred zone if there's an RRSIG following it, surely.

Joe

---

From: Joe Abley <[email-masked]>
Date: Mon, 28 Mar 2011 14:00:29 +0200

> Should an SOA record be signed anyway ?

Yes.

> The SOA is only a signaling record, and the result is never going to be

SOA RDATA is used by two important classes of application -- DNS authority-only servers (REFRESH, RETRY, EXPIRE) and DNS resolvers (MINIMUM, negative cache TTL). Further, the MNAME field is used by DNS UPDATE clients. The utility of the MNAME field in the real world is debatable, but I have seen no data which suggests it is irrelevant.

Joe

---

From: "Marc Lampo" <[email-masked]>
Date: Mon, 28 Mar 2011 14:54:15 +0200 (CEST)

In my opinion, the use of the second SOA to indicate the zone did not
change (at sender side) since the zone transfer started is more important
(then the indication of the end of the zone transfert).

I agree that, if there is a record following that "last SOA", that SOA is
obviously not the last one of the zone transfert.
Which brings us to the question :
 Where to put that RRSIG(SOA), knowing that potentially the SOA may change
between start and end of AXFR.
 (in which case the receiving name server must refuse just downloaded zone
and attempt AXFR again)

Marc 

-----Original Message-----
From: Joe Abley [mailto:[email-masked]] 
Sent: 28 March 2011 01:54 PM
To: Marc Lampo
Cc: [email-masked]; 'Olafur Gudmundsson'
Subject: Re: [dnsext] Possible DNSSECbis clarifications

> While the second SOA might serve as an indicator of "end of zone

It's not the end of the transferred zone if there's an RRSIG following it,
surely.

Joe

---

From: Joe Abley <[email-masked]>
Date: Mon, 28 Mar 2011 15:09:14 +0200

> (in which case the receiving name server must refuse just downloaded zone

Anywhere between the two SOA records seems sensible to me.

Joe

---

From: Michael Graff <[email-masked]>
Date: Mon, 28 Mar 2011 15:20:03 +0200

> (then the indication of the end of the zone transfert).

The AXFR (and IXFR) specs bracket the parts by SOA record, not by other
records.  The purpose is to ensure that the transfer is complete and was
not closed early by the sender.  If you then allow other records on the
end, you will lose that confirmation.

Think of the SOA records as brackets.  That they are also data is the
mistake, but it's one that is in place and can't be changed.  The marker
could have been an empty DNS packet (just header) but unfortunately, it
wasn't.

- --Michael

---

From: "Marc Lampo" <[email-masked]>
Date: Mon, 28 Mar 2011 16:19:07 +0200 (CEST)

But then, how to link a RRSIG(SOA) with *its* SOA ?

Or simply : "try" all available RRSIG(SOA)'s, if at least one validates
the SOA being looked at, then accept it.
(where "validates" includes not only the signature is valid and within
validity period,
 but also : chain-of-trust is OK)

Marc

-----Original Message-----
From: Joe Abley [mailto:[email-masked]] 
Sent: 28 March 2011 03:09 PM
To: Marc Lampo
Cc: [email-masked]; 'Olafur Gudmundsson'
Subject: Re: [dnsext] Possible DNSSECbis clarifications

Joe

---

From: Michael Graff <[email-masked]>
Date: Mon, 28 Mar 2011 16:53:08 +0200

> But then, how to link a RRSIG(SOA) with *its* SOA ?

They are the same SOA in an AXFR.  Identical in every way.

In an IXFR, the delta change IS the data as well, with each section
delimited by an SOA.

So, you have the removed RRSIG(SOA) in the delete section and the new
RRSIG(SIG) in the add section.

There is no guarantee on record order in an AXFR other than the
delimiters.  You could receive:

  example.com SOA
  example.com A
  asdasd.example.com A
  example.com MX
  asdasd.example.com AAAA
  example.com SOA

IMHO, the first SOA could be followed by its RRSIG(SOA), but this is not
required.  The final SOA cannot have any data after it, as per AXFR
spec.  Don't treat the RRSIG as special; for an AXFR or IXFR they are
just records.

- --Michael

---

From: Joe Abley <[email-masked]>
Date: Mon, 28 Mar 2011 17:20:38 +0200

> But then, how to link a RRSIG(SOA) with *its* SOA ?

If there are multiple, different SOAs found in an AXFR response then you throw that response away. RFC 1034 seems fairly clear on that.

  When the poll shows that the zone has changed, then the secondary server
  must request a zone transfer via an AXFR request for the zone.  The AXFR
  may cause an error, such as refused, but normally is answered by a
  sequence of response messages.  The first and last messages must contain
  the data for the top authoritative node of the zone.  Intermediate
  messages carry all of the other RRs from the zone, including both
  authoritative and non-authoritative RRs.  The stream of messages allows
  the secondary to construct a copy of the zone.  Because accuracy is
  essential, TCP or some other reliable protocol must be used for AXFR
  requests.

> the SOA being looked at, then accept it.

Zero or one RRSIG RRSets over the SOA, one SOA RR and one identical copy of the same SOA record. I don't see a validation problem.

Joe

---

From: "Marc Lampo" <[email-masked]>
Date: Mon, 28 Mar 2011 17:55:36 +0200 (CEST)

A "theorical" attack would be a "man-in-the-middle" change the trailing
SOA, thus causing the secondary server to throw away each zone transfer it
attempts (if it "believes" the second SOA is correct, in the absence of a
valid RRSIG for it - that trailing SOA).

If a secondary name server is prevented from downloaded update of the true
zone data, this is a security issue, I would say.

It may not be that easy to set up this kind of attack, but then again,
perhaps in some time somebody might show it can be done.
My feeling is that, with DNSSEC, both SOA's in a zone transfer should be
signed in a proper way (that they can  be validated) even if the SOA's
differ.

Which leaves us with another "hole" :
Suppose potential attacker does indeed change trailing SOA, and fails to
produce a validatable RRSIG, then what should the recipient do with the
zone it downloaded ?  Since it can no longer verify if the content of the
zone did not change, at the master, since the start of the zone transfer.

Marc

-----Original Message-----
From: Joe Abley [mailto:[email-masked]] 
Sent: 28 March 2011 05:21 PM
To: Marc Lampo
Cc: [email-masked]; 'Olafur Gudmundsson'
Subject: Re: [dnsext] Possible DNSSECbis clarifications

> But then, how to link a RRSIG(SOA) with *its* SOA ?

If there are multiple, different SOAs found in an AXFR response then you
throw that response away. RFC 1034 seems fairly clear on that.

> the SOA being looked at, then accept it.

Zero or one RRSIG RRSets over the SOA, one SOA RR and one identical copy
of the same SOA record. I don't see a validation problem.

Joe

---

From: Miek Gieben <[email-masked]>
Date: Mon, 28 Mar 2011 18:13:35 +0200

[ Quoting Marc Lampo at 17:55 on March 28 in "Re: [dnsext] Possible  DNSSECbis cl"... ]
> valid RRSIG for it - that trailing SOA).

If you are scared of mitm attacks you should use tsig to secure the
transfer IMO.

grtz Miek

---

From: Mark Andrews <[email-masked]>
Date: Tue, 29 Mar 2011 03:21:20 +1100

In message <01b701cbed61$61cd3480$25679d80$@[email-masked]>, "Marc Lampo" write
> zone data, this is a security issue, I would say.

And we have solutions a solution to this.  It's called TSIG and has
been deployed for years with both signed and unsigned zones.

> signed in a proper way (that they can  be validated) even if the SOA's

DNSSEC as currently deployed cannot do this as RRSIG's are not
signed.  Early DNSSEC specs had the concept of a zone SIG.  This
covered the signatures.

---

From: Michael Graff <[email-masked]>
Date: Mon, 28 Mar 2011 18:24:26 +0200

> If you are scared of mitm attacks you should use tsig to secure the

+1

DNSSEC is a query thing to me.  I don't know of any servers that
validate the transfer on load, but I am most familiar with BIND 9.

But, suppose there was a MITM attack and data was changed, the server
validated the data during transfer, and the data failed validation.  It
would then reject the transfer, just like if the SOAs don't match.

- --Michael