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

[Alexey Melnikov <[e-mail]>]

This looks good to me. Please post a new version.
If you need to do a manual post (due to pre-Singapore draft submission
deadline), please request it and I will authorize it.

On Thu, Nov 2, 2017, at 07:18 PM, Scott Kitterman wrote:
> 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.