starting with "The ideal situation" has been.
I welcome editorial comments off-list.
If the chair believes the current text captures consensus I will move this
issue to the closed issues list.
--Olaf
$Id: cryptography_flawed 14 2009-02-09 18:54:12Z olaf $
20100121
The use of HSM
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
cou
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 belo
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 ex
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 w
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
h
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 to
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,
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 mi
On 1/21/10 10:48 AM, "Edward Lewis" 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 everyone ha
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, thir
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
> operational procedure the operators do not ha
On Thu, Jan 21, 2010 at 04:28:14PM +, Tony Finch wrote:
> Operational routines like this will be automated.
I wish I believed that was universally true. It isn't.
A
--
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc.
___
DNSOP mailing list
DNSOP@
At 11:02 AM -0500 1/21/10, Andrew Sullivan wrote:
>On Thu, Jan 21, 2010 at 10:48:52AM -0500, Edward Lewis wrote:
> > And the key word above is "assumptions" - once we know for a fact that a
>> ZSK of 1024 bits is good for a year no matter how much it is used and
>
>Nobody can ever know that for a f
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 a
(see below). The first two paragraphs are not
> modified, the text starting with "The ideal situation" has been.
>
> I welcome editorial comments off-list.
>
> If the chair believes the current text captures consensus I will move
> this issue to the closed issues list.
>
&
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?
Well
On Thu, 21 Jan 2010, Olaf Kolkman wrote:
In trying to get a reasonable version 2 out of the door before Anaheim I am
trying to identify and where possibly close open issues.
As a reminder: http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ has
the open issues listed and a per issue hig
On Thu, 21 Jan 2010, Edward Lewis wrote:
If I were to fit this into the text below...
#
#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 wrote:
> On Thu, 21 Jan 2010, Edward Lewis wrote:
>
>> If I were to fit this into the text below...
>>
>> #
>> #
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 a bit lost following this thread now.
For the time being, let's ignore personnel changes and whether a key
is in an HSM
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 a bit lost following this thread now.
>
>For the time being, let's igno
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
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 abov
On Thu, Jan 21, 2010 at 11:38 AM, 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 still don't understand why this implies the need for regular changes
>>>as opposed to changes triggered by personnel changes.
>>
>>I'm a bit los
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 bel
On Thu, Jan 21, 2010 at 12:12:50PM -0800, Eric Rescorla wrote:
> On Thu, Jan 21, 2010 at 11:38 AM, Paul Hoffman wrote:
> > is still much higher than the value of the broken key. Remember
> > that a broken signing key is only valuable until the fact that it
> > is broken is discovered and fixed. S
On Fri, Jan 22, 2010 at 05:25:29AM +0900, Masataka Ohta wrote:
> 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
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 wrote:
>
>> > is still much higher than the value of the broken key. Remember
>> > that a broken signing key is only valuable until the
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-sou
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 goi
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 a
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 n
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 m
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 a
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 r
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 po
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 (detectin
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 Jan 21, 2010, at 4:42 PM, Edward Lewis wrote:
> 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 b
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 rat
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 hi
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 th
On Thu, Jan 21, 2010 at 2:24 PM, Paul Wouters 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 Goldb
On 1/21/2010 12:12 PM, Eric Rescorla wrote:
On Thu, Jan 21, 2010 at 11:38 AM, 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 still don't understand why this implies the need for regular changes
as opposed to c
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 th
On 21 Jan 2010, at 22:11, Roy Arends wrote:
I'd recommend that 'exercise the activity' is not done on critical
production systems.
I'd recommend the opposite. Sort of: carry out these drills in the
production environment but clearly not on the systems that are
actually handling the operat
On Thu, 21 Jan 2010, Eric Rescorla wrote:
Also, consider this paper from July 2009:
https://documents.epfl.ch/users/l/le/lenstra/public/papers/ecdl.pdf
Next considering special purpose hardware, the most optimistic
approach suggests that sieving for a 1024-bit RSA modulus can be
done
On Jan 21, 2010, at 6:03 PM, Jim Reid wrote:
> On 21 Jan 2010, at 22:11, Roy Arends wrote:
>
>> I'd recommend that 'exercise the activity' is not done on critical
>> production systems.
>
> I'd recommend the opposite. Sort of: carry out these drills in the production
> environment but clearly
On Thu, Jan 21, 2010 at 3:08 PM, Paul Wouters wrote:
> On Thu, 21 Jan 2010, Eric Rescorla wrote:
>
>>> Also, consider this paper from July 2009:
>>>
>>> https://documents.epfl.ch/users/l/le/lenstra/public/papers/ecdl.pdf
>>>
>>> Next considering special purpose hardware, the most optimistic
>>>
On 21 Jan 2010, at 23:55, Roy Arends wrote:
I'm arguing that the exercising should not be done on critical
production systems.
Argue all you like. :-) But if those procedures, policies and
processes are not exercised on the critical production systems *for
real* there is no way of knowing
On Jan 21, 2010, at 7:57 PM, Jim Reid wrote:
> On 21 Jan 2010, at 23:55, Roy Arends wrote:
>
>> I'm arguing that the exercising should not be done on critical production
>> systems.
>
> Argue all you like. :-) But if those procedures, policies and processes are
> not exercised on the critical
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
issue
On Thu, Jan 21, 2010 at 9:09 PM, Paul Wouters 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 the a
56 matches
Mail list logo
