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

["Murray S. Kucherawy" <[e-mail]>]

Scott may not have had to do that before, so just to be sure: The procedure
I've used there is to email [e-mail] with the content as an
attachment(s) and explain that Alexey will be approving it.

On Fri, Nov 3, 2017 at 3:10 AM, Alexey Melnikov <[e-mail]>
wrote:

> 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.
>
> _______________________________________________
> Dcrup mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dcrup
>