The NGtrans/DNSext chairs would like to make a call for participation
in the upcoming joint meeting.
The goal of the meeting is to facilitate consensus on how IPv6
addresses are represented in DNS and related issues. This meeting
requires extensive homework by participants and the chairs would li
> ``Administrators normally insist on being able to change their records
> with at most a few days notice,'' my web page says, as a starting point
> for analyzing the expiration-date security issues.
Yes, it does indeed say that. It has to say it, because imposing
that ad-hoc restriction is nece
> Matt Crawford writes:
> > So if it's all right for your
> > interface ID and/or subnet information to persist for a month, but
> > you want to be able to change your global prefix(es) on a day's
> > notice, you get a 30-to-1 work savings on almost all of your RRsets.
>
> No. Under your one-mont
1. I won't be at the meeting. However, I strongly support elimination of
A6/DNAME: http://cr.yp.to/djbdns/killa6.html
2. There's a common error in the evaluation of DNSSEC signing costs. I'd
like to draw attention to a new section that I've added to my web page
to analyze this error: http://cr.yp
Matt Crawford writes:
> So if it's all right for your
> interface ID and/or subnet information to persist for a month, but
> you want to be able to change your global prefix(es) on a day's
> notice, you get a 30-to-1 work savings on almost all of your RRsets.
No. Under your one-month assumption,
alain,
you have a bug in your mail system. somehow the line which said that rob
austien's draft will be used as the agenda driver got dropped. you may want
to try to send the agreed message again.
randy
IETF IPng Working Grou
> 2. There's a common error in the evaluation of DNSSEC signing costs. I'd
> like to draw attention to a new section that I've added to my web page
> to analyze this error: http://cr.yp.to/djbdns/killa6.html#signingcosts
Your reasoning is markedly incorrect if applied to A6. If we take
site renu
Correction on the previous announcement:
The NGtrans/DNSext chairs would like to make a call for participation
in the upcoming joint meeting.
The goal of the meeting is to facilitate consensus on how IPv6
addresses are represented in DNS and related issues. This meeting
requires extensive homewo
> The NGtrans/DNSext chairs would like to make a call for participation
> in the upcoming joint meeting.
> ...
> Anybody wishing to make a presentation should send a draft
> to the chairs of this meeting before July 26th 2001, 21:00 UTC
> (that is, 2pm PDT, 5pm EDT, 11pm MEST)
> - Alain Duran
Matt Crawford writes:
> I offer
> http://home.fnal.gov/~crawdad/draft-ietf-dnsext-ipv6-dns-response-00.txt
I would like to comment on section 1.3:
> 1.3. DNSSEC - Aggravation or Amelioration?
>
> An extreme case of A6 deployment (some might say a nightmare case),
> in the A6 record
[EMAIL PROTECTED] writes:
> Pre change:
> example.com SIG KEY expire=200107292257 (1 day)
> host.example.com SIG A expire=200108272257 (30 days)
> Post change:
> example.com SIG KEY expire=200107072258 (1 day)
> host.example.com SIG A expire=200108272258 (30 day
On Sat, Jul 21, 2001 at 12:41:13AM -0700, D. J. Bernstein wrote:
> Of course, the other serious problem with your argument is that your
> one-month assumption is wrong. It is _not_ acceptable for information to
> persist for a month. I addressed this in my previous message, and in my
> ``Extremely
>> 2. There's a common error in the evaluation of DNSSEC signing costs. I'd
>> like to draw attention to a new section that I've added to my web page
>> to analyze this error: http://cr.yp.to/djbdns/killa6.html#signingcosts
>Your reasoning is markedly incorrect if applied to A6. If we take
>site
> [EMAIL PROTECTED] writes:
> > Pre change:
> > example.com SIG KEY expire=200107292257 (1 day)
> > host.example.com SIG A expire=200108272257 (30 days)
> > Post change:
> > example.com SIG KEY expire=200107072258 (1 day)
> > host.example.com SIG A expire=200108272258 (30
> >Your reasoning is markedly incorrect if applied to A6. If we take
> >site renumbering to be the dominant factor controlling
> >signature-validity times, then the signatures on the A6 records
>
> from what I got from reading djb's webpage, djb's point is that
> the dominant factor
Date:Wed, 25 Jul 2001 06:28:32 -0700
From:"D. J. Bernstein" <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| Crawford wants your signatures today to last for a month.
I doubt that Matt cares how long anyone's, but his own, signatures last.
| What happens
[EMAIL PROTECTED] writes:
> there is no requirement to re-sign every record to achieve
> your 1 day expiry. Just change the zone key whenever you change
> zone data and have a 1 day expiry on the zone key's signature.
No. If you maintain the validity of signatures on old records, you're
allowing
> [EMAIL PROTECTED] writes:
> > there is no requirement to re-sign every record to achieve
> > your 1 day expiry. Just change the zone key whenever you change
> > zone data and have a 1 day expiry on the zone key's signature.
>
> No. If you maintain the validity of signatures on old records, yo
>
> > [EMAIL PROTECTED] writes:
> > > there is no requirement to re-sign every record to achieve
> > > your 1 day expiry. Just change the zone key whenever you change
> > > zone data and have a 1 day expiry on the zone key's signature.
> >
> > No. If you maintain the validity of signatures on
Third time lucky ...
> Dan,
>your claim is that you have to re-sign every record in
> a zone daily to achieve a 1 day replay window. I'm stating
> that you can achieve the same protection without re-signing
> every record daily.
>
> Pre change:
``Administrators normally insist on being able to change their records
with at most a few days notice,'' my web page says, as a starting point
for analyzing the expiration-date security issues.
This applies to _all_ records. Existing DNS software assumes, correctly,
that long TTLs are a mistake.
Crawford wants your signatures today to last for a month. What happens
if you decide tomorrow to change a machine's address list---for example,
adding or removing a second address?
Answer: An attacker can interfere with this change for 29 agonizing
days. All he has to do is replay the old data un
Dan,
there is no requirement to re-sign every record to achieve
your 1 day expiry. Just change the zone key whenever you change
zone data and have a 1 day expiry on the zone key's signature.
So daily you re-sign two RRsets.
Mark
--
Mark An
Robert Elz writes:
> The data needs to be somehow carried to the key (which cannot be
> exposed anywhere near any network), the signing done, and then the
> data carried back again. Doing that once a month for most people
> just might be tolerable - once a day and all that will ever exist are
>
24 matches
Mail list logo
