Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-00.txt

Some communities have a larger security policy on algorithms, key 
lengths, etc. that they are compelled to comply to rather than 
per-protocol recommendations. Usually admins follow it out of routine or 
simply to keep auditors from complaining.  Listing what a validator MUST 
be able to support is good, but dictating what a sender MUST use might 
lead to issues.

I agree on only adding 1 (two at most) algorithms to DKIM.  Too many 
algorithms leads to confusion among implementors and deployments as to 
what is the recommended algorithm.  DNSSEC is facing this now and there 
are now several drafts about which algorithms should be mandatory, which 
should be retired, etc.

Scott

On 2 Jun 2017, at 9:15, John Levine wrote:

> In article 
> <CABkgnnX2uQkKiRWgBknXqn6Ho_yP2twcDzS8adsh8RoVWianig@mail.gmail.com> 
> you write:
>> TLS does this for cipher suites.  The policy there is to allow
>> registration of entries with a low bar, but to require a higher bar
>> (Standards Track) for entries that mark the entry as "recommended".
>
> TLS does cipher negotiation, DKIM doesn't, because TLS has a two-way
> path between sender and recipient.  That means that adding new
> algorithm to DKIM is hard and slow, because signers can't use them
> (other than in parallel with older algorithms) until a sufficient
> number of verifiers implement them.  That's why my draft adds one (1)
> new algorithm that is intended to be good enough to last for a long
> time.  The current draft may not have the best algo for that goal, but
> that's why it's still a draft.
>
> I'm also somewhat sceptical of outsourcing key strength advice.  You
> don't pick key strengths in a vacuum and DKIM is in an odd place with
> signatures that last for a week, not a few seconds like in TLS or
> years like S/MIME or PGP signatures.  Writing a new RFC that updates
> key strength advice needn't be hard unless we make it hard.
>
> R's,
> John
>
> _______________________________________________
> Dcrup mailing list
> Dcrup@ietf.org
> https://www.ietf.org/mailman/listinfo/dcrup

===================================
Scott Rose
NIST ITL
scott.rose@nist.gov
+1-301-975-8439
GV: +1-571-249-3671
===================================