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

[Vladimir Dubrovin <[e-mail]>]

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 single DKIM-Signature by using the comproised weak key.
The fact you are ussing the strong one adds nothing to security in this
case. There is no way for you to indicate you use the stronger one
unless you indicate it with the key itself. So, if you keep the weak key
published for compatibility, somehow you must indicate you are using it
for compatibility purposes only to prevent verifiers from acepting the
messages signed with weak key only if it's not accomplished by a
stronger signature.


07.04.2017 15:09, Scott Rose пишет:
> 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. produce 2 different DKIM-Signatures with 2 different selectors:
>> slector1  with SHA-1 + RSA and selector2 one with SHA-512 + ECDSA
>> 2. add an additional field to either selector1 DKIM DNS record (need
>> to consult RFC if it's allowed) or to DKIM-Signature with selector1
>> (it's allowed but probably is not enough to protect against
>> downgrade) to indicate the selector is legacy-only, e.g.
>> o=sha512/eccp256 to indicate this selector should be ignored if
>> verifier supports sha-512 and eccp256.
>>
>> Legacy verifier has valid DKIM-Signature with sha1+rsa
>> Compatible verifier ignores sha1+rsa and choose sha-512+ECDSA
>>
> Something similar was proposed in the DANE WG, but was not included
> because it isn't up to the sender to tell the receiver which
> algorithms to support - the receiver (likely) has its own list of
> approved or preferred algorithms from which to do validation.  Some
> text could be added to the validation section about how validators
> should select their strongest preferred algorithm, etc. but not
> specify "legacy" algorithms unless there is clear consensus to get rid
> of it for DKIM.
>
> Scott
>
>
>> I can imagine few more ways to resolve compatibility issues, but this
>> one seems to be a simplest.
>>
>>
>> 06.04.2017 20:32, Scott Rose пишет:
>>> This may be of interest to this group, as there isn't an active DKIM
>>> WG anymore.  This is my first attempt to produce a draft about
>>> defining new digital algorithms for DKIM. I'm trying to keep this
>>> short i.e. only define a few IANA registry entries and that's it.
>>>
>>> I'm trying to head off a potential issue for organizations that are
>>> told to migrate to ECDSA or looking for algorithm agility that
>>> doesn't involve using SHA-1.
>>>
>>> Comments welcome and needed. Including being told this isn't needed
>>> (though I think it might be).
>>>
>>> Scott Rose
>>>
>>> NIST
>>>
>>>
>>>
>>> -------- Forwarded Message --------
>>> Subject:     New Version Notification for draft-srose-dkim-ecc-00.txt
>>> Date:     Thu, 6 Apr 2017 10:26:43 -0700
>>> From: [e-mail]
>>> To:     Scott Rose <[e-mail]>
>>>
>>>
>>>
>>> A new version of I-D, draft-srose-dkim-ecc-00.txt
>>> has been successfully submitted by Scott Rose and posted to the
>>> IETF repository.
>>>
>>> Name:        draft-srose-dkim-ecc
>>> Revision:    00
>>> Title:        Defining Elliptic Curve Cryptography Algorithms for
>>> use with DKIM
>>> Document date:    2017-04-06
>>> Group:        Individual Submission
>>> Pages:        6
>>> URL: https://www.ietf.org/internet-drafts/draft-srose-dkim-ecc-00.txt
>>> Status: https://datatracker.ietf.org/doc/draft-srose-dkim-ecc/
>>> Htmlized: https://tools.ietf.org/html/draft-srose-dkim-ecc-00
>>> Htmlized: https://datatracker.ietf.org/doc/html/draft-srose-dkim-ecc-00
>>>
>>>
>>> Abstract:
>>>    DomainKeys Identified Mail (DKIM) uses digital signature to
>>> associate
>>>    a message with a given sending domain.  Currently, there is only one
>>>    cryptography algorithm defined for use with DKIM (RSA).  This
>>>    document defines four new elliptic curve cryptography algorithms for
>>>    use with DKIM.  This will allow for algorithm agility if a weakness
>>>    is found in RSA, and allows for smaller key length to provide the
>>>    same digital signature strength.
>>>
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of
>>> submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>>
>>> The IETF Secretariat
>>>
>>> _______________________________________________
>>> dmarc mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dmarc
>>
>>
>> -- 
>> Vladimir Dubrovin
>> @Mail.Ru
>
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc


-- 
Vladimir Dubrovin
@Mail.Ru