Section 3.3.3 includes 512 bit rsa as a MUST. I think that that
might be an error. Is there really any need for anything smaller
than 1024 in any case?
S.
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Stephen Farrell wrote:
Section 3.3.3 includes 512 bit rsa as a MUST. I think that that
might be an error. Is there really any need for anything smaller
than 1024 in any case?
Isn't there something of a calculation which equates effort to
break over time? DKIM lifetimes are normally quite short
Michael Thomas wrote:
Stephen Farrell wrote:
Section 3.3.3 includes 512 bit rsa as a MUST. I think that that
might be an error. Is there really any need for anything smaller
than 1024 in any case?
Isn't there something of a calculation which equates effort to
break over time? DKIM lifetimes
Stephen Farrell wrote:
Michael Thomas wrote:
Stephen Farrell wrote:
Section 3.3.3 includes 512 bit rsa as a MUST. I think that that
might be an error. Is there really any need for anything smaller
than 1024 in any case?
Isn't there something of a calculation which equates effort to
brea
On Thu, Mar 16, 2006 at 09:53:52AM +, Stephen Farrell allegedly wrote:
>
> Section 3.3.3 includes 512 bit rsa as a MUST. I think that that
> might be an error. Is there really any need for anything smaller
> than 1024 in any case?
It might not be significant, but I presume there are deployed
Michael Thomas wrote:
Stephen Farrell wrote:
Michael Thomas wrote:
Stephen Farrell wrote:
Section 3.3.3 includes 512 bit rsa as a MUST. I think that that
might be an error. Is there really any need for anything smaller
than 1024 in any case?
Isn't there something of a calculation whi
Mark Delany wrote:
On Thu, Mar 16, 2006 at 09:53:52AM +, Stephen Farrell allegedly wrote:
Section 3.3.3 includes 512 bit rsa as a MUST. I think that that
might be an error. Is there really any need for anything smaller
than 1024 in any case?
It might not be significant, but I presume the
> get people to change their shorter keys. Or Mark's suggestion
> may be better. Do we have any data on deployed key sizes?
Unfortunately we don't and getting it is non-trivial as it involves
deploying s/w. Maybe someone else does. I expect 512 to be rare, but
768 might be common.
I will note tha
Mark Delany <[EMAIL PROTECTED]> writes:
> Further, that sort of constraint is algorithm dependent. So the true
> test is: if (rsa && keySize < limit)). A new algorithm may well have
> completely different size limits or different safety dimensions to
> check.
>
> Is there experience in similar fiel
At 7:07 AM -0800 3/16/06, Michael Thomas wrote:
Isn't there something of a calculation which equates effort to
break over time?
BCP 86 / RFC 3766
DKIM lifetimes are normally quite short, so
smaller keys are not implausible, especially given the level
of protection DKIM actually provide (weake
Paul Hoffman wrote:
At 3:16 PM + 3/16/06, Stephen Farrell wrote:
Just to be clear though - there
are two lifetimes in DKIM - signature lifetime, related to
message transit times, and key lifetime, related to some unknown
management cycle, and its the latter (and presumably longer) one
that'
Signers SHOULD NOT use keys less that 1024 bits, receivers MAY
accept keys less than 1024.
Let the receivers figure it out
Bill Oxley
Messaging Engineer
Cox Communications, Inc.
Alpharetta GA
404-847-6397
[EMAIL PROTECTED]
___
NOTE WELL: This
At 11:11 AM -0800 3/16/06, Michael Thomas wrote:
Which leads us back to the original question, I guess. I'm fairly
certain that nobody's going to spend any MIPS-years to factor
mtcc.com's public key.
... thousands of MIPS-years for a 512-bit key ...
They might consider it for something more
t
On Mar 16, 2006, at 11:25 AM, Paul Hoffman wrote:
At 11:11 AM -0800 3/16/06, Michael Thomas wrote:
Which leads us back to the original question, I guess. I'm fairly
certain that nobody's going to spend any MIPS-years to factor
mtcc.com's public key.
... thousands of MIPS-years for a 512-bit
> Do we have any data on deployed key sizes?
FYI, none of our deployments are using less than 1024. Our software
generates default keys for the user automatically at 1024.
--
Arvel
___
NOTE WELL: This list operates according to
http://mipassoc.org
Security AD Advice
512-bit RSA keys are too short. They may be acceptable when the
crypto period is very short (say a week). I cannot envision most
administrators accepting the management burden associated with such
short crypto periods.
Proposed text:
Since short RSA keys are susceptible
> Proposed text:
> Since short RSA keys are susceptible off-line attacks, signers MUST
That text sounds good to me but maybe "Since short RSA keys more easily
succumb to off-line attacks, ..." is more precise?
--
Arvel
___
NOTE WELL: This list oper
On Mar 17, 2006, at 8:48 AM, Russ Housley wrote:
Security AD Advice
512-bit RSA keys are too short. They may be acceptable when the
crypto period is very short (say a week). I cannot envision most
administrators accepting the management burden associated with such
short crypto periods.
That is a fine improvement.
Russ
At 01:49 PM 3/17/2006, Arvel Hathcock wrote:
> Proposed text:
> Since short RSA keys are susceptible off-line attacks, signers MUST
That text sounds good to me but maybe "Since short RSA keys more
easily succumb to off-line attacks, ..." is more precise?
--
At 4:20 PM -0800 3/17/06, Douglas Otis wrote:
With respect to 2048 bit keys, there is already a placeholder in the
base draft for developing a much needed binary DKIM key.
Why is a binary representation "much needed"? A 2048-bit key will
only take up 320 of the 512 bytes allowed. Or am I missi
On Sat, Mar 18, 2006 at 09:29:58PM -0600, Paul Hoffman allegedly wrote:
> Why is a binary representation "much needed"? A 2048-bit key will
> only take up 320 of the 512 bytes allowed. Or am I missing something?
Actually, the encoding cost is only a constraint if you want to store
the key in som
On Sat, 2006-03-18 at 21:29 -0600, Paul Hoffman wrote:
> At 4:20 PM -0800 3/17/06, Douglas Otis wrote:
> >With respect to 2048 bit keys, there is already a placeholder in the
> >base draft for developing a much needed binary DKIM key.
>
> Why is a binary representation "much needed"? A 2048-bit k
At 8:27 AM -0800 3/19/06, Douglas Otis wrote:
Of those bytes, 8 bytes are used to the version of the TXT record,
leaving 131 bytes. The "_domainkeys" label consumes another 14 bytes
(assuming pointer compression in the answer section) and that leaves 117
bytes for name space. From this space, o
On Sun, 2006-03-19 at 11:37 -0600, Paul Hoffman wrote:
> At 8:27 AM -0800 3/19/06, Douglas Otis wrote:
> >Of those bytes, 8 bytes are used to the version of the TXT record,
> >leaving 131 bytes. The "_domainkeys" label consumes another 14 bytes
> >(assuming pointer compression in the answer sectio
Defining a new DKIM specific RR type for DNS will take about the same time
as defining a new CERT type! Furthermore adding a unsigned keying information
into the CERT record will run into resistance as this is not a
properly formatted certificate.
As for the 512 size restriction that was address
On Mar 20, 2006, at 2:18 PM, Ólafur Guðmundsson wrote:
Defining a new DKIM specific RR type for DNS will take about the
same time as defining a new CERT type!
Writing the draft, yes. Accessing this RR type, no. The CERT has
made headway since about 1999, where use of this CERT by DKIM
Michael Thomas wrote:
> How about:
>
> Signers SHOULD NOT use keys less that 1024 bits, receivers MUST
> accept keys less that 1024 but MAY consider weaker keys as more
> suspicious.
>
> (where "suspicious" has been used before in the draft to mean
> something along the lines of heightened scrutiny
Jim Fenton wrote:
Michael Thomas wrote:
How about:
Signers SHOULD NOT use keys less that 1024 bits, receivers MUST
accept keys less that 1024 but MAY consider weaker keys as more
suspicious.
(where "suspicious" has been used before in the draft to mean
something along the lines of heightened
28 matches
Mail list logo
