Re: [Dcrup] rsa-sha1 proposals

[Hector Santos <[e-mail]>]

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?

-- 
HLS