Subject: [dnsext] RRSIG TTL check in RFC 4035

From: Sean Wells <[email-masked]>
Date: Sat, 18 Dec 2010 22:10:13 -0800

Hi,

In RFC 4035, section 2.2, it is mentioned:

o The RRSIG Original TTL field is equal to the TTL of the RRset.

The reason original TTL is there in RRSIG is because the TTL of the
RRSet may not have the correct value due to caching servers. For
example,

www.isc.org.		588	IN	A	149.20.64.42

www.isc.org.		588	IN	RRSIG	A 5 3 600 20110117233213 20101218233213
14457 isc.org. zy94Qvha84/+ouoEQZH2/c46UBiAcftWb9ULh2+gsbS33a+TRCI0qoAt
rKzMThW3MmM8KzaBX2DjZiRtpUdMI+NClBTuw96qd3q+2GeoU8XtQfPa
bSNFn8xl/1+x3IDojE69ZhQa7M4RF8NDJR3sltwfUVIweumXXM8kV6Vn mR4=

What am i reading wrong ?

-Sean

---

From: Edward Lewis <[email-masked]>
Date: Sun, 19 Dec 2010 09:10:03 -0500

At 22:10 -0800 12/18/10, Sean Wells wrote:
>RRSet may not
>have the correct value due to caching servers. For example,
>
><http://www.isc.org>www.isc.org  588 IN A      149.20.64.42
><http://www.isc.org>www.isc.org. 588 IN RRSIG  A 5 3 600 20110117233213
>                       20101218233213 14457 <http://isc.org>isc.org.
> 
>zy94Qvha84/+ouoEQZH2/c46UBiAcftWb9ULh2+gsbS33a+TRCI0qoAt
> 

I'm not sure.  Perhaps the requirement should be:

o The RRSIG Original TTL field is equal to the original (or 
authoritative) TTL of the RRset.

(The word "original" is important.)

That means, when you get the RR set and signature in order to 
validate you have to assemble the validation data (according to 
another place in the spec) and then make sure you replace the 
received TTL with the authoritative TTL as it appears in the 
signature.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

In going through my family medical history I recently realized I was
born with congenital amnesia.  I couldn't even remember my name at birth.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Sun, 19 Dec 2010 13:23:28 -0500

On 19/12/2010 9:10 AM, Edward Lewis wrote:
>  >www.isc.org <http://www.isc.org>588 IN A 149.20.64.42
>  >www.isc.org <http://www.isc.org>. 588 IN RRSIG A 5 3 600 20110117233213
>  > 20101218233213 14457 isc.org <http://isc.org>.
> That means, when you get the RR set and signature in order to validate
> you have to assemble the validation data (according to another place in
> the spec) and then make sure you replace the received TTL with the
> authoritative TTL as it appears in the signature.
>
> -

<no-hat>

The original reason for the OTTL field was to make validation possible.
The actual value of the TTL on the records verifying and signing does 
not need to have any relationship to what the TTL is in authorative 
servers.
IMHO we should treat this value as a 16 bit random number to make 
potential guessing attacks on future value of RSA signatures harder. 
(along with treating the bottom n bits of the timer values the same way).

For ECC and DSA signatures that already use random number in the 
signing/verification process this is not needed.

	Olafur

	Olafur

---

From: David Blacka <[email-masked]>
Date: Mon, 20 Dec 2010 09:59:51 -0500

On Dec 19, 2010, at 1:23 PM, Olafur Gudmundsson wrote:

> The actual value of the TTL on the records verifying and signing does not need to have any relationship to what the TTL is in authorative servers.
> IMHO we should treat this value as a 16 bit random number to make potential guessing attacks on future value of RSA signatures harder. (along with treating the bottom n bits of the timer values the same way).
> 
> For ECC and DSA signatures that already use random number in the signing/verification process this is not needed.

What?

While the original TTL is absolutely necessary for validation, it is also useful in preventing an attacker from increasing the TTL beyond the original value, thus pinning old data in caches.

--
David Blacka                          <[email-masked]> 
Principal Engineer    Verisign Platform Product Development

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 20 Dec 2010 10:33:33 -0500

On 20/12/2010 9:59 AM, David Blacka wrote:
>>>> www.isc.org<http://www.isc.org>588 IN A 149.20.64.42
>>>> www.isc.org<http://www.isc.org>. 588 IN RRSIG A 5 3 600 20110117233213
>>>> 20101218233213 14457 isc.org<http://isc.org>.
> David Blacka<[email-masked]>

In theory yes, in practice I doubt OTTL has any protective value against 
changes in TTL settings.
I should have been clearer that I want to use the bottom 16 out of 32 
bits TTL as jitter.
16 bits is represents  about 18 hours, thus  by just using the bottom 
bits of the OTTL field then a
Record could be stored for on average 9 hours longer than the TTL in 
authoritative server was
but also sometimes less.

     Olafur

---

From: Edward Lewis <[email-masked]>
Date: Mon, 20 Dec 2010 10:53:21 -0500

(Email readers against over quoting strike again...)

At 10:33 -0500 12/20/10, Olafur Gudmundsson wrote:

>In theory yes, in practice I doubt OTTL has any protective value
>against changes in TTL settings.

Shortening the TTL is one strategy a zone administrator can use to 
lower the Mean Time To Repair (at the expense of raising load) in a 
key compromise.  Lowered TTL's also help when changing data.

Long TTLs means data will stick in a cache longer, if the data was 
poisoned, the poisoning will linger longer in an unmanaged cache.

No protection against changes in TTL?  If software doesn't do the 
right thing, all bets are off.  But you certainly don't want a 
poisoner to up the TTL - even if the attack is merely a replay-style 
attack (meaning, no need to disrupt the crypto stuff, like guessing 
the key or forging data/hash colliding).

>I should have been clearer that I want to use the bottom 16 out of 32 bits
>TTL as jitter.

Why?  You already have a signature.  Why would you want more jitter?

In general, jitter works against one of the goals of operations and 
security - stability and predictability.  Things that are jittered 
are (inherently) less predictable.  Note: this doesn't mean jitter is 
bad.  CZ zone jitters their signature lifetimes, and they manage 
quite well.  But they won't know ahead of time the expiration of a 
particular change, if they wanted to.

More that than, I can't understand why you'd wring out any more bits 
"for jitter."

>16 bits is represents  about 18 hours, thus  by just using the bottom bits
>of the OTTL field then a Record could be stored for on average 9 hours longer
>than the TTL in authoritative server was but also sometimes less.

Huh?

---

From: Paul Vixie <[email-masked]>
Date: Mon, 20 Dec 2010 17:53:55 +0000

> Date: Mon, 20 Dec 2010 10:33:33 -0500
> From: Olafur Gudmundsson <[email-masked]>
> ...
> against changes in TTL settings.  I should have been clearer that I
> want to use the bottom 16 out of 32 bits TTL as jitter.  16 bits is
> represents about 18 hours, thus by just using the bottom bits of the
> OTTL field then a Record could be stored for on average 9 hours longer

this seems like a good idea to me.

---

From: Florian Weimer <[email-masked]>
Date: Mon, 20 Dec 2010 18:07:45 +0000

* Olafur Gudmundsson:

> potential guessing attacks on future value of RSA signatures
> harder. (along with treating the bottom n bits of the timer values the
> same way).

The field is 32 bits.  I think you should check that the observed TTL
is not larger than the original TTL.  This does not conflict with your
intended (ab)use of the field.

As discussed before, for DS records, there's also the possiblity to
stuff in randomness using algorithm 0.  DS records are particularly
sensitive because in DNSSEC, it's the place where attacker-submitted
data is potentially signed.

Has the IETF a general recommendation to use randomized hashing in
digital signature schemes?  Or will there be a DNSSEC-related
presentation at 27C3? 8-)  (The RSAMD5 attack against X.509 should
also work against the DNSSEC protocol.)

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Thierry Moreau <[email-masked]>
Date: Mon, 20 Dec 2010 14:00:23 -0500

Florian Weimer wrote:
> digital signature schemes?

I guess RSASSA-PSS would qualify, see informational RFC3447 section 8.1.

-- 
- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, QC, Canada H2M 2A1

Tel. +1-514-385-5691