zo...@zooko.com (Zooko Wilcox-O'Hearn) on Thursday, October 29, 2009 wrote:
I'm beginning to think that *in general* when I see a random number
required for a crypto protocol then I want to either
deterministically generate it from other data which is already
present or to have it
On 2009 Oct 19, at 9:15 , Jack Lloyd wrote:
On Sat, Oct 17, 2009 at 02:23:25AM -0700, John Gilmore wrote:
DSA was (designed to be) full of covert channels.
one can make DSA deterministic by choosing the k values to be HMAC-
SHA256(key, H(m))
I've noticed people tinkering with (EC) DSA by
At 12:14 PM 10/22/2009, David Wagner wrote:
Back to DNSSEC: The original criticism was that DNSSEC has covert
channels. So what? If you're connected to the Internet, covert
channels are a fact of life, DNSSEC or no. The added risk due to any
covert channels that DNSSEC may enable is somewhere
On Oct 22, 2009, at 16:12, Perry E. Metzger wrote:
I don't think anyone is smart enough to understand all the
implications of this across all the systems that depend on the DNS,
especially as we start to trust the DNS because of the authentication.
We trust the DNS already. As far as I
* Jack Lloyd:
On Sat, Oct 17, 2009 at 02:23:25AM -0700, John Gilmore wrote:
DSA was (designed to be) full of covert channels.
True, but TCP and UDP are also full of covert channels.
And you better randomize some bits covered by RRSIGs on DS RRsets.
Directly signing data supplied by
* Victor Duchovni:
The optimization is for DDoS conditions, especially amplification via
forged source IP DNS requests for . IN NS?. The request is tiny,
and the response is multiple KB with DNSSEC.
There's only one required signature in a . IN NS response, so it
isn't as large as you suggest.
* John Gilmore:
So the standard got sent back to the beginning and redone to deal with
the complications of deployed servers and records with varying algorithm
availability (and to make DSA the officially mandatory algorithm).
Which took another 5 or 10 years.
And it's still not clear that
Florian Weimer fwei...@bfk.de writes:
* Perry E. Metzger:
Actually, there are routine attacks on DNS infrastructure these days,
but clearly they're not cryptographic since that's not
deployed. However, a large part of the point of having DNSSEC is that we
can then trust the DNS to be
Florian Weimer wrote:
And you better randomize some bits covered by RRSIGs on DS RRsets.
Directly signing data supplied by non-trusted source is quite risky.
(It turns out that the current signing schemes have not been designed
for this type of application, but the general crypto community is
On Sat, Oct 17, 2009 at 02:23:25AM -0700, John Gilmore wrote:
DSA was (designed to be) full of covert channels.
True, but TCP and UDP are also full of covert channels. And if you are
worried that your signing software or hardware is compromised and
leaking key bits, you have larger problems, no
On Sat, Oct 17, 2009 at 02:23:25AM -0700, John Gilmore wrote:
Given that they are attempted to optimize for minimal packet size, the
choice of RSA for signatures actually seems quite bizarre.
Each of these records is cached on the client side, with a very long
timeout (e.g. at least a
On Oct 17, 2009, at 5:23 AM, John Gilmore wrote:
Even using keys that have a round number of bits is foolish, in my
opinion. If you were going to use about 2**11th bits, why not 2240
bits, or 2320 bits, instead of 2048? Your software already handles
2240 bits if it can handle 2048, and it's
designed 25 years ago would not scale to today's load. There was a
crucial design mistake: DNS packets were limited to 512 bytes. As a
result, there are 10s or 100s of millions of machines that read *only*
512 bytes.
Yes, that was stupid, but it was done very early in the evolution of
Nicolas Williams wrote:
Getting DNSSEC deployed with sufficiently large KSKs should be priority #1.
I agree. Let's get something deployed, as that will lead to testing.
If 90 days for the 1024-bit ZSKs is too long, that can always be
reduced, or the ZSK keylength be increased -- we too can
On Sat, Oct 17, 2009 at 10:23 AM, John Gilmore g...@toad.com wrote:
Even plain DSA would be much more space efficient on the signature
side - a DSA key with p=2048 bits, q=256 bits is much stronger than a
1024 bit RSA key, and the signatures would be half the size. And NIST
allows (2048,224)
On Tue, Oct 20, 2009 at 09:20:04AM -0400, William Allen Simpson wrote:
Nicolas Williams wrote:
Getting DNSSEC deployed with sufficiently large KSKs should be priority #1.
I agree. Let's get something deployed, as that will lead to testing.
If 90 days for the 1024-bit ZSKs is too long,
ts a fun story, but... RFC 4034 says RSA/SHA1 is mandatory and DSA is
optional.
I was looking at RFC 2536 from March 1999, which says Implementation
of DSA is mandatory for DNS security. (Page 2.) I guess by March 2005
(RFC 4034), something closer to sanity had prevailed.
On 2009 Oct 19, at 9:15 , Jack Lloyd wrote:
On Sat, Oct 17, 2009 at 02:23:25AM -0700, John Gilmore wrote:
DSA was (designed to be) full of covert channels.
And, for that matter, one can make DSA deterministic by choosing the k
values to be HMAC-SHA256(key, H(m)) - this will cause the k
Jerry Leichter leich...@lrw.com writes:
Do we really believe we won't be able to
attack a 1024 bit key with a sufficiently large budget even in 10
years? ...
Currently, the cryptographic cost of an attack is ... 0. How many
attacks have there been? Perhaps the perceived value of owning
On Wed, Oct 14, 2009 at 10:43:48PM -0400, Jerry Leichter wrote:
If the constraints elsewhere in the system limit the number of bits of
signature you can transfer, you're stuck. Presumably over time you'd
want to go to a more bit-efficient signature scheme, perhaps using
ECC.
Even plain
Ekr has a very good blog posting on what seems like a bad security
decision being made by Verisign on management of the DNS root key.
http://www.educatedguesswork.org/2009/10/on_the_security_of_zsk_rollove.html
In summary, a decision is being made to use a short lived 1024 bit key
for the
On Wed, Oct 14, 2009 at 06:24:06PM -0400, Perry E. Metzger wrote:
Ekr has a very good blog posting on what seems like a bad security
decision being made by Verisign on management of the DNS root key.
http://www.educatedguesswork.org/2009/10/on_the_security_of_zsk_rollove.html
In summary,
bmann...@vacation.karoshi.com writes:
On Wed, Oct 14, 2009 at 06:24:06PM -0400, Perry E. Metzger wrote:
Ekr has a very good blog posting on what seems like a bad security
decision being made by Verisign on management of the DNS root key.
On Wed, Oct 14, 2009 at 07:22:27PM -0400, Perry E. Metzger wrote:
bmann...@vacation.karoshi.com writes:
On Wed, Oct 14, 2009 at 06:24:06PM -0400, Perry E. Metzger wrote:
Ekr has a very good blog posting on what seems like a bad security
decision being made by Verisign on management of the
bmann...@vacation.karoshi.com writes:
er... there is the root key and there is the ROOT KEY.
the zsk only has a 90 day validity period. ... meets the
spec and -ought- to be good enough. that said, it is
currently a -proposal- and if credible arguments can be made
to modify the proposal,
At 7:54 PM -0400 10/14/09, Perry E. Metzger wrote:
There are enough people here with the right expertise. I'd be interested
in hearing what people think could be done with a fully custom hardware
design and a budget in the hundreds of millions of dollars or more.
What part of owning a temporary
On Oct 14, 2009, at 7:54 PM, Perry E. Metzger wrote:
...We should also recognize that in cryptography, a small integer
safety
margin isn't good enough. If one estimates that a powerful opponent
could attack a 1024 bit RSA key in, say, two years, that's not even a
factor of 10 over 90 days, and
27 matches
Mail list logo
