Re: [Dcrup] AD review of draft-ietf-dcrup-dkim-usage-04.txt

[Scott Kitterman <[e-mail]>]

On Thursday, November 02, 2017 03:06:34 PM Alexey Melnikov wrote:
> On Wed, Nov 1, 2017, at 10:45 PM, Murray S. Kucherawy wrote:
> > Circling back on this, which is the remaining point:
> > 
> > On Thu, Aug 31, 2017 at 3:58 AM, Alexey Melnikov
> > <[e-mail]> wrote:>>
> > 
> >> On Thu, Aug 31, 2017, at 01:11 AM, Murray S. Kucherawy wrote:
> >>> On Wed, Aug 30, 2017 at 11:33 AM, Alexey Melnikov
> >>> <[e-mail]> wrote:>>>>
> >>> 
> >>>> On Wed, Aug 30, 2017, at 07:29 PM, Murray S. Kucherawy wrote:
> >>>>> The first line in Section 4 already says this updates 3.3 of
> >>>>> RFC6376.  You think we need to be more specific?>>>>
> >>>> 
> >>>> As I mentioned: I think sections 3.3.2 and 3.3.4 are still
> >>>> relevant. If this document is replacing 3.3 and its subsections,
> >>>> some of this is lost.>>>>
> >>>> If you really intended to replace 3.3 and its subsections, it would
> >>>> be worth adding "and its subsections" to the draft.>>>
> >>> 
> >>> The draft says "updates", but you're saying "replaces".  I don't see
> >>> those as the same thing.  What this document says is to my mind
> >>> treated as an overlay, not a replacement; read RFC6376, then read
> >>> this for current advice, then act.>>
> >> 
> >> I assume you are replacing the whole sections. If this is not what
> >> you are doing, the document is even less clear and need to be
> >> clarified.>>
> >> 
> >>> If it's better to say this updates a specific subsection, then
> >>> that's also reasonable.  I just thought what we have is sufficient.>>
> >> 
> >> Yes, please be specific. I couldn't be certain which sections are
> >> still in force and which were updated.>
> > 
> > I propose this, replacing our document's current Section 4:
> > 
> > 4. Update to DKIM Signing and Verification Algorithms
> > 
> >    Section 4.1 updates the text in [RFC6376] Section 3.3.
> >    
> >    
> >    
> >    Section 4.2 updates the first paragraph in [RFC6376] Section 3.3.3.
> 
> I want some specific text about what happens to sections:
> 
> 3.3.1.  The rsa-sha1 Signing Algorithm
> 3.3.2.  The rsa-sha256 Signing Algorithm
> 3.3.4.  Other Algorithms
> 
> e.g. "Sections 3.3.1, 3.3.2 and 3.3.4 are not affected" or similar. (Or
>      the correct disposition of these sections if what I suggested is
>      not correct.
> 
> > 4.1. DKIM Signing and Verification Algorithms  DKIM supports multiple
> > 
> >      digital signature algorithms.  Two algorithms are defined by this
> >      specification at this time: rsa-sha1 and rsa- sha256.  Signers
> >      MUST sign using rsa-sha256.  Verifiers MUST be able to verify
> >      using rsa-sha256.  rsa-sha1 MUST NOT be used for signing or
> >      verifying.  DKIM signatures signed with historic algorithms
> >      (currently rsa-sha1) or with insufficient key sizes (currently
> >      rsa-sha256 with less than 1024 bits) have permanently failed
> >      evaluation as discussed in  [RFC6376] Section 3.9[1].  4.2. 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 all keys.  Signers SHOULD use RSA keys of at
> >      least 2048 bits. Verifiers MUST be able to validate signatures
> >      with keys ranging from 1024 bits to 4096 bits, and they MAY be
> >      able to validate signatures with larger keys.  Verifier policies
> >      can use the length of the signing key as one metric for
> >      determining whether a signature is acceptable.  Verifiers MUST
> >      NOT consider signatures using RSA keys of less than 1024 bits as
> >      valid signatures.
> > 
> > Alexey, would this suffice? -MSK
> 
> Links:
> 
>   1. https://tools.ietf.org/html/rfc6376#section-3.9

I added text about 3.3.1, 2, and 4.  See the attached RFC diff.  If that works 
for you, I'll submit -06 and (hopefully) we can call it done.

Scott K