Re: [Dcrup] rsa-sha1 proposals

[Scott Kitterman <[e-mail]>]

On Tuesday, June 20, 2017 07:49:49 PM Hector Santos wrote:
> On 6/20/2017 7:38 PM, Seth Blank wrote:
> > On Tue, Jun 20, 2017 at 4:20 PM, Hector Santos <[e-mail]
> > 
> > <mailto:[e-mail]>> wrote:
> >         Back in 2007 RFC 4871 said "In general, sha256 should always
> >         be used
> >         whenever possible."  I think people have had enough warning,
> >         and if we
> >         want to kill it, we should just kill it.
> >     
> >     Unless whitelisted, this will create invalid SHA1 signatures from
> >     perfectly good domains.  New systems who initially avoid SHA1
> >     legacy support will quickly learn not all systems use SHA256. i.e
> >     a quick support problem.
> > 
> > To me, this is exactly the point. People have had ten years to switch
> > to SHA-256. At this point, people will only move if the threat of
> > breakage is upon them. And this isn't breakage, this is a document
> > that says using SHA-1 is no longer acceptable, and you MUST use
> > SHA-256. If it's the right security recommendation, we should say it
> > explicitly.
> 
> My point is the protocol/document should also discuss how to deal with
> SHA1 legacy operations when dealing with a migration design issue, not
> ignore its existence, i.e. kill it, wipe it out, remove it from
> discussion.  New verifiers following such advice may quickly see a
> problem when they see SHA1.   Should the document suggest to
> invalidate them?  Can a key lookup or DMARC lookup enforce this?
> (Preferred)    If SHA1 can be exploited for a domain, then the domain
> should be able to provide a hint to the verifier about its validity.
> Or should a verifier just completely ignore it, therefore inherently
> invalidating the signature for lack of SHA1 support?

I think it would be useful for DMARC feedback reporting to be extended to 
include the signing algorithm used, but that's off topic for this working 
group.

Scott K