Re: [dmarc-ietf] Fwd: New Version Notification for draft-srose-dkim-ecc-00.txt

On Fri, Apr 7, 2017 at 8:33 AM, Peter Goldstein wrote: > Does this initiative include an intention to update the cryptographic > guidance from RFC 6376 sections 3.3 and 3.3.3 ? The proposed charter > speaks of adding new algorithms, but doesn't discuss deprecating/removing >

Re: [dmarc-ietf] I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt

Ned I’m sorry for my late reply. We appreciate your advice as a co-chair. We understood that currently there is no room for our proposal in the current phase of this WG. Best regards, Kouji Okada > 2017/04/02 5:25、ned+dm...@mrochek.comのメール: > > > > Normally I'm not a stickler for avoiding

Re: [dmarc-ietf] Fwd: New Version Notification for draft-srose-dkim-ecc-00.txt

This was forced by the web browser providers for SHA1. It’s being forced by the PCI DSS standard for use of TLS1.0. So it clearly ispossible. Mike From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Terry Zink Sent: Friday, April 07, 2017 2:39 PM To: dmarc Subject: Re: [dmarc-ietf] Fwd:

Re: [dmarc-ietf] Fwd: New Version Notification for draft-srose-dkim-ecc-00.txt

One reason transitions are difficult because of implementation and deprecation ambiguity. If there’s no reason to move other than best practice, then no one will (or not enough will move). Maybe we can build timelines into the updates. By Jan 1, 2019, receivers SHOULD (MUST?) no longer support

Re: [dmarc-ietf] Fwd: New Version Notification for draft-srose-dkim-ecc-00.txt

In article <30f3baa9-f13b-91b4-c931-a2fb68582...@diennea.com> you write: >If we want to put a meaningful value in this new field, I think it would >be more useful to make it the time since when the key was obsoleted, >this would allow for mail dated before that moment (which was correctly >signed

Re: [dmarc-ietf] Fwd: New Version Notification for draft-srose-dkim-ecc-00.txt

Does this initiative include an intention to update the cryptographic guidance from RFC 6376 sections 3.3 and 3.3.3 ? The proposed charter speaks of adding new algorithms, but doesn't discuss deprecating/removing old ones. We haven't decided yet. I'd think that'd be something DCRUP could

Re: [dmarc-ietf] Fwd: New Version Notification for draft-srose-dkim-ecc-00.txt

Ok - nice to know I'm not the only one thinking this (means I'm not totally crazy). I'm willing to drop my draft and just contribute/review this one. There is no reason to have multiple drafts trying to do the same thing. No, don't, we can moosh them together. I don't know much about

Re: [dmarc-ietf] Fwd: New Version Notification for draft-srose-dkim-ecc-00.txt

John, Really glad to see this. Does this initiative include an intention to update the cryptographic guidance from RFC 6376 sections 3.3 and 3.3.3 ? The proposed charter speaks of adding new algorithms, but doesn't discuss deprecating/removing old ones. Some specific concerns are: 1.

Re: [dmarc-ietf] Fwd: New Version Notification for draft-srose-dkim-ecc-00.txt

Should we add more hash algorithms? As far as I know SHA-256 is still adequate for the forseeable future, but I expect the crypto experts will weigh in. Ditto whether we really need three new algorithms since the more ways there are to sign, the more ways there are to have broken

Re: [dmarc-ietf] Fwd: New Version Notification for draft-srose-dkim-ecc-00.txt

Right now we require support for two types of keys: a weak one (sha1) and a strong one (sha256). Rolling out a new type of key should include requiring signers to ditch the weak sha1 key. But you still have a strong sha256 key to use along with the new key. Any examples showing compatibility

Re: [dmarc-ietf] Fwd: New Version Notification for draft-srose-dkim-ecc-00.txt

And again: the problem here is not in the signature, it's in key published. If you publish both weak and strong keys, attacker doesn't need to exploit the stronger key, he can exploit weak key, it doesn't matter if you use the strong one if the weak key is also valid. Attacker will generate

Re: [dmarc-ietf] Fwd: New Version Notification for draft-srose-dkim-ecc-00.txt

Ok - nice to know I'm not the only one thinking this (means I'm not totally crazy). I'm willing to drop my draft and just contribute/review this one. There is no reason to have multiple drafts trying to do the same thing. Scott On 04/06/2017 07:55 PM, John Levine wrote: In article

Re: [dmarc-ietf] Fwd: New Version Notification for draft-srose-dkim-ecc-00.txt

On 04/06/2017 05:28 PM, Vladimir Dubrovin wrote: Hello Scott, it may be good to cover compatibility issues, because otherwise there are little chances to succeed the older but more compatible protocols in nearest future. The possible (but probably not the best one) solution is: 1.

Re: [dmarc-ietf] Fwd: New Version Notification for draft-srose-dkim-ecc-00.txt

I agree that to avoid downgrade attacks there has to be a way to mark a key as obsolete in the DNS, meaning: "don't use this key if you know what this means". But I don't see a need to explicitly put another algorithm name in the field. For example, let's say an obsolete record can be marked

Re: [dmarc-ietf] Fwd: New Version Notification for draft-srose-dkim-ecc-00.txt

Without marking the published key as obsolete, downgrade attack is possible, because attacker can still use a weaker key to spoof signature. пятница, 07 апреля 2017г., 02:58 +03:00 от John Levine jo...@taugh.com : >>1. produce 2 different DKIM-Signatures with 2 different selectors: >>slector1