thanks paul.
That might be draft-hoffman-dnssec-ecdsa. I let it expire earlier this month
because the DNSEXT WG is still not clear on the allowable statuses for crypto
documents, but have today revived it based on your comment.
If you don't consider this to be a good draft, I
On Mon, 25 Jan 2010, Edward Lewis wrote:
Last time I looked (a few months ago) most signed TLDs to use 2048 bit KSKs
and 1024 bit ZSKs. Perhaps there is no reason to have two different sized
keys, I would guess that since a chain is only as strong as its weakest
link all keys could be
At 1:05 PM -0500 1/25/10, Paul Wouters wrote:
On Mon, 25 Jan 2010, Edward Lewis wrote:
Last time I looked (a few months ago) most signed TLDs to use 2048 bit KSKs
and 1024 bit ZSKs. Perhaps there is no reason to have two different sized
keys, I would guess that since a chain is only as strong
At 6:32 PM + 1/25/10, Francis Dupont wrote:
In your previous mail you wrote:
So the real problems are:
- a good draft
- some consensus
- IETF publication delays
IMHO we should ask Russ to nominate a cryptographer (or himself)
to re-initiate the process from the first step: a good draft
Paul Hoffman wrote:
The reason these numbers are never discussed in DNSOP is because
no one is discussing their actual threat model and the estimated
value of the attacks.
The practical threat model is frequent social attacks on a trusted
third party or two, which means there is no such thing
On 1/21/2010 9:24 PM, Eric Rescorla wrote:
On Thu, Jan 21, 2010 at 9:09 PM, Paul Woutersp...@xelerance.com wrote:
On Thu, 21 Jan 2010, Eric Rescorla wrote:
The point is that the numbers depend on your model of the attacker
more than on the cryptography.
Yes, but
On Thu, 21 Jan 2010, Paul Hoffman wrote:
- Regular rolling can give you a false sense of security about your rolling
process
How can you have any sense of security about your rolling process if you
don't exercise it?
Tony.
--
f.anthony.n.finch d...@dotat.at http://dotat.at/
GERMAN BIGHT
At 17:11 -0500 1/21/10, Roy Arends wrote:
I'd recommend that 'exercise the activity' is not done on critical
production systems.
There's a difference between exercise and test/training/etc. You
do want to exercise on the real systems.
At 17:20 -0500 1/21/10, Andrew Sullivan wrote:
You
At 8:18 PM + 1/22/10, bmann...@vacation.karoshi.com wrote:
On Fri, Jan 22, 2010 at 09:13:22AM -0800, Paul Hoffman wrote:
At 4:56 PM + 1/22/10, Tony Finch wrote:
On Thu, 21 Jan 2010, Paul Hoffman wrote:
- Regular rolling can give you a false sense of security about your
rolling
I'm not really an active member of the WG, so I certainly wouldn't say that
my position has much of an affect on consensus, but I'm unconvinced
by the argument offered below.
Sure, the ZSK is at greater risk because operators have access to it, but
so what? If an operator actually steals the key
Perhaps the wording is a bit incorrect in that it an insider attack (the
admin accessing the key) is not the biggest threat. The ZSK is accessed
more often and if it isn't on an HSM (or similar), there could be a risk
that it could be exposed by someone other than the responsible DNS admin. Of
As a reminder: http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ has
the open issues listed and a per issue highlight of their history.
This issue is captured in
http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ZSK-roll-frequency
current content of that page is replicated
On Jan 21, 2010, at 3:09 PM, Rose, Scott W. wrote:
Perhaps the wording is a bit incorrect in that it an insider attack (the
admin accessing the key) is not the biggest threat. The ZSK is accessed
more often and if it isn't on an HSM (or similar), there could be a risk
that it could be
IMHO, the suggested wording is backwards.
It's not that the ZSK effectivity period is shorter than the KSK's,
the KSK effectivity period is longer than the ZSK's. The reason is
operational, not cryptographic.
Way back in time (circa '99-'02)...consensus of those participating
in workshops
On Thu, Jan 21, 2010 at 10:14:41AM -0500, Edward Lewis wrote:
So many assumptions have changed...but the idea of KSK/ZSK hasn't.
Maybe this is the problem?
A
--
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
At 10:39 -0500 1/21/10, Andrew Sullivan wrote:
On Thu, Jan 21, 2010 at 10:14:41AM -0500, Edward Lewis wrote:
So many assumptions have changed...but the idea of KSK/ZSK hasn't.
Maybe this is the problem?
Problem?
Not everyone has an automated registration interface (making that a
reason
On Thu, Jan 21, 2010 at 10:48:52AM -0500, Edward Lewis wrote:
At 10:39 -0500 1/21/10, Andrew Sullivan wrote:
Maybe this is the problem?
Problem?
It that it seems to be the occasion of a lot of disagreement with the
document. That is, in many cases, perhaps the advice should simply
be, The
At 11:02 -0500 1/21/10, Andrew Sullivan wrote:
Not everyone has an automated registration interface (making that a
reason to have a KSK/ZSK still hold).
Sure, but this may well be the exception and not the rule.
And I've heard the opposite. automated-registry[0]-run zones are
in the
On 1/21/10 10:48 AM, Edward Lewis ed.le...@neustar.biz wrote:
At 10:39 -0500 1/21/10, Andrew Sullivan wrote:
On Thu, Jan 21, 2010 at 10:14:41AM -0500, Edward Lewis wrote:
So many assumptions have changed...but the idea of KSK/ZSK hasn't.
Maybe this is the problem?
Problem?
Not
On Thu, Jan 21, 2010 at 11:14:25AM -0500, Edward Lewis wrote:
At 11:02 -0500 1/21/10, Andrew Sullivan wrote:
Sure, but this may well be the exception and not the rule.
And I've heard the opposite. automated-registry[0]-run zones are in
the minority. (I.e., second level domains, third-level
On Thu, Jan 21, 2010 at 08:55:33AM -0800, Paul Hoffman wrote:
But we *can* assume that there are a lot of 1024-bit keys in use
that are much more valuable than the most valuable DNSSEC 1024-bit
key. Thus, as public analysis gets better, we are likely to hear
about it. Even if the first
At 13:03 -0500 1/21/10, Paul Wouters wrote:
Maybe make it more explicit that an intra-organisation key change can
and probably should happen frequently, where-as an inter-organisational
key change, because it involves other organisations, is more difficult
and should be kept to a minimum?
On Thu, 21 Jan 2010, Edward Lewis wrote:
If I were to fit this into the text below...
#t
#The motivation for having the KSK's effectivity period
#longer than the ZSK's effectivity period is rooted in the
#operational consideration that a change in the KSK involves
#
I still don't understand why this implies the need for regular changes
as opposed
to changes triggered by personnel changes.
-Ekr
On Thu, Jan 21, 2010 at 10:03 AM, Paul Wouters p...@xelerance.com wrote:
On Thu, 21 Jan 2010, Edward Lewis wrote:
If I were to fit this into the text below...
On Jan 21, 2010, at 5:28 PM, Tony Finch wrote:
On Thu, 21 Jan 2010, Olaf Kolkman wrote:
I understand EKR's remark (thanks) in addition to the improvement Scott
suggested there is the argument that if a rollover remains a special
event it is bound to go wrong, while if it is part of regular
At 11:38 -0800 1/21/10, Paul Hoffman wrote:
At 2:17 PM -0500 1/21/10, Edward Lewis wrote:
At 11:05 -0800 1/21/10, Eric Rescorla wrote:
I have tried, repeatedly, to do so, but I am not an expert, nor apparently
enough of an authority for you. Ekr is both; let's see if he likes my
response
On Thu, Jan 21, 2010 at 11:38 AM, Paul Hoffman paul.hoff...@vpnc.org wrote:
At 2:17 PM -0500 1/21/10, Edward Lewis wrote:
At 11:05 -0800 1/21/10, Eric Rescorla wrote:
I still don't understand why this implies the need for regular changes
as opposed to changes triggered by personnel changes.
I'm
Edward Lewis wrote:
Also, what was not anticipated was the coming of automated provisioning,
Yes, it was anticipated.
It was obvious from the beginning of DNSSEC that automated provisioning
operationally unavoidable.
At the time too -
HSMs didn't exist in our world, and we still thought
Andrew Sullivan wrote:
I fully agree. I just want to make sure we're not holding ourselves
to an operational standard that is just impossible to reach. If we
want proof and facts about whether something won't ever be
compromised,
Remember that DNSSEC was developed because it was believed
At 3:27 PM -0500 1/21/10, Andrew Sullivan wrote:
On Thu, Jan 21, 2010 at 12:12:50PM -0800, Eric Rescorla wrote:
On Thu, Jan 21, 2010 at 11:38 AM, Paul Hoffman paul.hoff...@vpnc.org wrote:
is still much higher than the value of the broken key. Remember
that a broken signing key is only
Andrew Sullivan wrote:
Remember that DNSSEC was developed because it was believed to make
DNS proven to be secure.
You're equivocating on proof or secure or maybe both.
DNSSEC allows you to prove that, assuming secure keys, you're getting
the the correct (i.e. authoritatively-sourced)
At 12:54 -0800 1/21/10, Paul Hoffman wrote:
...as long as there is no cost to rolling regularly. But there are many:
I'm finding this discussion enlightening and interesting.
If the logic is that the only need to roll is event-based (detecting
a violation) because there is risk of a roll
On Jan 21, 2010, at 1:14 PM, Edward Lewis wrote:
Perhaps monthly rolls aren't needed for crypto-sake, but the more apparent
this is the more apparent we need regular rolls for operations-sake.
Thanks.
While I might agree that _theoretically_ longer keys and/or better algorithms
removes or at
Again, I don't feel strongly about this, but I don't really find this
very convincing.
Presumably there are all sorts of other credentials that control access to the
ZSK (e.g., administrator SSH private keys, root passwords, etc.) Do you also
propose to roll all of these every month? If not, why
On Thu, Jan 21, 2010 at 04:14:03PM -0500, Edward Lewis wrote:
I'm finding this discussion enlightening and interesting.
Me too. I also think that discussion of exactly this sort belongs in
the advice we give to operators. Understanding the trade-offs and the
reason for them is exactly what
As a matter of fact, a lot of the security credentials (SSH keys,
passwords, etc.) are rolled on a regular basis already, as part of
institutional security policies.
But I think a point has been missed - the roll of keys on a periodic
basis is needed to *exercise the activity* if not achieve
At 16:29 -0500 1/21/10, Andrew Sullivan wrote:
One also worries a little that many operations people (me included) so
often think you need to practice this includes in production.
(But I haven't worked many places where I've had a real, true,
complete copy of my production systems just for
On Jan 21, 2010, at 1:42 PM, Edward Lewis wrote:
Presumably there are all sorts of other credentials that control access to
the
ZSK (e.g., administrator SSH private keys, root passwords, etc.) Do you also
propose to roll all of these every month? If not, why not?
...
But I think a point has
At 4:14 PM -0500 1/21/10, Edward Lewis wrote:
At 12:54 -0800 1/21/10, Paul Hoffman wrote:
...as long as there is no cost to rolling regularly. But there are many:
I'm finding this discussion enlightening and interesting.
If the logic is that the only need to roll is event-based (detecting a
Andrew,
On Jan 21, 2010, at 1:29 PM, Andrew Sullivan wrote:
For instance, despite what David says downthread about operational
realities and exercise, such exercise is a complete waste of time if
the person who does the work is different every time (as might well be
the case under a lot of
On Thu, Jan 21, 2010 at 01:57:49PM -0800, David Conrad wrote:
First time a scheduled roll botches, any rational organization would
institute policies and processes to ensure that such a botch does
not reoccur. First time a scheduled roll botches with a new
outsourced contractor, any
On Thu, 21 Jan 2010, Edward Lewis wrote:
What I'd like to hear is:
Crypto-expert __ says an RSA-SHA256 key of 1024 bits is good for
___ signatures/days.
I did ask my local Waterloo based cryptographer (Ian Goldberg) this
question about a year ago for RSA-SHA1. And apart from his
On Jan 21, 2010, at 4:47 PM, David Conrad wrote:
On Jan 21, 2010, at 1:42 PM, Edward Lewis wrote:
Presumably there are all sorts of other credentials that control access to
the
ZSK (e.g., administrator SSH private keys, root passwords, etc.) Do you also
propose to roll all of these every
On Thu, Jan 21, 2010 at 2:24 PM, Paul Wouters p...@xelerance.com wrote:
On Thu, 21 Jan 2010, Edward Lewis wrote:
What I'd like to hear is:
Crypto-expert __ says an RSA-SHA256 key of 1024 bits is good for
___ signatures/days.
I did ask my local Waterloo based cryptographer (Ian
On 1/21/2010 12:12 PM, Eric Rescorla wrote:
On Thu, Jan 21, 2010 at 11:38 AM, Paul Hoffmanpaul.hoff...@vpnc.org wrote:
At 2:17 PM -0500 1/21/10, Edward Lewis wrote:
At 11:05 -0800 1/21/10, Eric Rescorla wrote:
I still don't understand why this implies the need for regular
On 1/21/2010 1:29 PM, Andrew Sullivan wrote:
On Thu, Jan 21, 2010 at 04:14:03PM -0500, Edward Lewis wrote:
I'm finding this discussion enlightening and interesting.
Me too. I also think that discussion of exactly this sort belongs in
the advice we give to operators. Understanding
On Thu, 21 Jan 2010, Eric Rescorla wrote:
The point is that the numbers depend on your model of the attacker
more than on the cryptography.
Yes, but my point is that the safety period depends on your assumptions
about the attacker's resources, which is why this is not really a technical
On Thu, Jan 21, 2010 at 9:09 PM, Paul Wouters p...@xelerance.com wrote:
On Thu, 21 Jan 2010, Eric Rescorla wrote:
The point is that the numbers depend on your model of the attacker
more than on the cryptography.
Yes, but my point is that the safety period depends on your assumptions
about
48 matches
Mail list logo
