RFC 6376 (which I think is the latest) includes:
> 3.3.3. Key Sizes
>
>Selecting appropriate key sizes is a trade-off between cost,
>performance, and risk. Since short RSA keys more easily succumb to
>off-line attacks, Signers MUST use RSA keys of at least 1024 bits for
>long-li
Dear Scott,
Signatures normally offer options not easily supported by
DKIM. One being use of a binary keys, rather than base64.
Indeed shorter keys were a mistake. What other mistakes
should be corrected? I can name a few.
Regards,
Douglas Otis
On 5/11/15 10:06 AM, Scott Kitterman wrote:
> R
On Monday, May 11, 2015 12:04:19 PM Douglas Otis wrote:
> On 5/11/15 10:06 AM, Scott Kitterman wrote:
> > RFC 6376 (which I think is the latest) includes:
> >> 3.3.3. Key Sizes
> >>
> >>Selecting appropriate key sizes is a trade-off between cost,
> >>performance, and risk. Since short RS
On Monday, May 11, 2015 07:23:58 PM John Levine wrote:
> >I propose a short draft that updates 6376 to say MUST use at least 1024
> >bits and setting that as the minimum size verifiers must be able to
> >validate. I'm volunteering to write it if people agree it's appropriate.
>
> That seems fine.
On 5/11/15 1:15 PM, Scott Kitterman wrote:
> On Monday, May 11, 2015 07:23:58 PM John Levine wrote:
>>> I propose a short draft that updates 6376 to say MUST use at least 1024
>>> bits and setting that as the minimum size verifiers must be able to
>>> validate. I'm volunteering to write it if pe
> I propose a short draft that updates 6376 to say MUST use at least 1024 bits
> and setting that as the minimum size verifiers must be able to validate. I'm
> volunteering to write it if people agree it's appropriate.
I think it is appropriate - and I agree with others that we shouldn't go beyon
-1
Please stop! No more DKIM code changes ok? The IETF just made it a STD.
Maybe we should remove the STD status first, move it back to proposed
standard or experimental if this and other changes are coming.
If signers want 1024 bits, then can do so ready.
--
HLS
On 5/11/2015 1:06 PM, Scot
On May 12, 2015 7:28:25 AM EDT, Hector Santos wrote:
>-1
>
>Please stop! No more DKIM code changes ok? The IETF just made it a
>STD.
>
>Maybe we should remove the STD status first, move it back to proposed
>standard or experimental if this and other changes are coming.
>
>If signers want 1024 bi
I am not concern about us (Santronics) and our DKIM implementation
with 1024 bit support on both ends per STD. I am concern about
everyone else. In other words, I am not about to begin invalidating,
rejecting perfectly signed DKIM 512 bit hashed messages purely based
on your revised MUST.
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
> boun...@mipassoc.org] On Behalf Of Martijn Grooten
> Sent: Tuesday, May 12, 2015 3:23 AM
> To: ietf-dkim@mipassoc.org
> Subject: Re: [ietf-dkim] DKIM Key Size Constraints
>
> > I
oten
>> Sent: Tuesday, May 12, 2015 3:23 AM
>> To: ietf-dkim@mipassoc.org
>> Subject: Re: [ietf-dkim] DKIM Key Size Constraints
>>
>>> I propose a short draft that updates 6376 to say MUST use at least
>>> 1024 bits and setting that as the minimum size v
PS References that were left out of the version of the email I did not send to
Hector only:
[1]
http://blog.cryptographyengineering.com/2015/03/attack-of-week-freak-or-factoring-nsa.html
[2] http://www.wired.com/2012/10/dkim-vulnerability-widespread/
Virus Bul
> Why remove 512 support from the verification side? Does this mean the
> verifier will take valid 512 signature and make it invalid, no signature
> message? Is there a correlation out there that 512 bits signers are more
> prune to be Bad Guys? Spammers?
The problem here is that 512-bit keys ca
> Apart from that I think we should start a (separate) effort to determine
> where we go from here. For the most part 2048 length keys seem not to be
> a problem in the wild at this time. On the other hand, given the speed
> (or lack thereof) involved in working groups generating useful output,
John R. Levine:
> The only problem I'm aware of is the 512 byte UDP DNS packet size. Is
> anyone aware of actual stats on how often larger packets fail?
for that reason I started using 4096 bit dkim keys years ago.
but message modifications are the only relevant reason of broken dkim
sigs her
> -Original Message-
> From: John R. Levine [mailto:jo...@iecc.com]
> Sent: Tuesday, May 12, 2015 10:44 AM
> To: MH Michael Hammer (5304)
> Cc: ietf-dkim@mipassoc.org
> Subject: Re: [ietf-dkim] DKIM Key Size Constraints
>
> > Apart from that I think we shoul
On 5/12/2015 11:31 AM, Martijn Grooten wrote:
>> Why remove 512 support from the verification side? Does this mean the
>> verifier will take valid 512 signature and make it invalid, no signature
>> message? Is there a correlation out there that 512 bits signers are more
>> prune to be Bad Guys? S
On Tue, May 12, 2015 at 8:31 AM, Martijn Grooten <
martijn.groo...@virusbtn.com> wrote:
> > Why remove 512 support from the verification side? Does this mean the
> > verifier will take valid 512 signature and make it invalid, no signature
> > message? Is there a correlation out there that 512 bi
On Tuesday, May 12, 2015 03:35:37 PM Murray S. Kucherawy wrote:
> On Tue, May 12, 2015 at 8:31 AM, Martijn Grooten <
>
> martijn.groo...@virusbtn.com> wrote:
> > > Why remove 512 support from the verification side? Does this mean the
> > > verifier will take valid 512 signature and make it invali
On Tue, May 12, 2015 at 8:28 PM, Scott Kitterman
wrote:
> > Is it appropriate to change the protocol document for this? Isn't it
> > really more of a BCP?
>
> I think when key size got put in the protocol, then it's a protocol update
> to
> change it.
>
Is it part of the protocol, or is it part
On 05/13/2015 12:27 PM, Murray S. Kucherawy wrote:
> https://sourceforge.net/p/opendkim/bugs/221/) appears to agree with
> what I'm saying above. When talking about unacceptably small keys,
> the "unacceptable" decision is not made by the protocol, but by the
> receiver.
+1
- Roland
On 05/13/2015 06:35 AM, Murray S. Kucherawy wrote:
On Tue, May 12, 2015 at 8:31 AM, Martijn Grooten
mailto:martijn.groo...@virusbtn.com>>
wrote:
You are right to point out that the RFC says that "[t]he security
goals of this specification are modest", which indeed they are,
but I
On Mon, 11 May 2015, Scott Kitterman wrote:
> I propose a short draft that updates 6376 to say MUST use at least 1024
> bits and setting that as the minimum size verifiers must be able to
> validate. I'm volunteering to write it if people agree it's appropriate.
I don't see a benefit. Entities t
On Tuesday, May 12, 2015 09:27:51 PM Murray S. Kucherawy wrote:
> On Tue, May 12, 2015 at 8:28 PM, Scott Kitterman
>
> wrote:
> > > Is it appropriate to change the protocol document for this? Isn't it
> > > really more of a BCP?
> >
> > I think when key size got put in the protocol, then it's a
IMO, this suggestion would be better as an Informational and BCP note.
I don't think it warrants a change to STD76.
We went through this already. We (DKIM WG) were well aware of the
weakness of a smaller key but we had backward compatibility concerns
so the proper verification migration pat
On 5/13/2015 1:25 AM, Roland Turner wrote:
> On 05/13/2015 12:27 PM, Murray S. Kucherawy wrote:
>
>> https://sourceforge.net/p/opendkim/bugs/221/) appears to agree with
>> what I'm saying above. When talking about unacceptably small keys,
>> the "unacceptable" decision is not made by the protocol,
On 5/13/2015 7:31 AM, Scott Kitterman wrote:
>
> DKIM is a security protocol. I find it very odd to claim that the security
> part of a security protocol isn't part of the protocol.
Good point. But we did take it into account. As you point out, the
APIs seem to have limited the size.
> While I
On Wed, May 13, 2015 at 01:21:36PM +0800, Roland Turner wrote:
> (e.g. perhaps measurement discovers that 512 bit keys are only used by
> low-risk domains; does this warrant killing the feature for the good of those
> who are being targeted, or retaining it because it's still in use, with a
> clea
On 5/12/2015 10:25 PM, Roland Turner wrote:
> On 05/13/2015 12:27 PM, Murray S. Kucherawy wrote:
>
>> https://sourceforge.net/p/opendkim/bugs/221/) appears to agree with
>> what I'm saying above. When talking about unacceptably small keys,
>> the "unacceptable" decision is not made by the proto
Apologies for jumping in late; just to note that 1024-bit keys seem to have
been accepted until quite recently:
https://www.sophos.com/en-us/support/knowledgebase/122327.aspx
On Wed 13/May/2015 13:54:04 +0200 Martijn Grooten wrote:
> [...]
>
> I don't think such a BCP should be so broad as to c
On Tue, May 19, 2015 at 11:40:12AM +0200, Alessandro Vesely wrote:
> Apologies for jumping in late; just to note that 1024-bit keys seem to have
> been accepted until quite recently:
> https://www.sophos.com/en-us/support/knowledgebase/122327.aspx
This refers to certificates signed with RSA-1024 k
31 matches
Mail list logo
