Re: [keyassure] Opening issue #21: "Need to specify which crypto algorithms and certificate types are mandatory to implement"

[Warren Kumari <[e-mail]>]

Hi all,

After watching the thread, I'd like to propose this as a strawman:

Mandatory to implement algorithms are SHA-256 and SHA-384. For now, these are all we specify.

My reasoning behind this is:
1: We don't want to support too many algorithms -- it leads to complexity (which leads to weaker security) and opens the door to interoperability issues and fights over why algorithm X was allowed and Y was not.

2: Having more than 1 algorithm forces implementations to understand that there is not just one, and so should help lead towards algorithm agility

3: In order to do DANE, you have to be able to do DNSSEC -- in order to do DNSSEC you should already support the above.

4: (IMO, an important one, even if not technical one) giving people the ability to choose will lead to greater deployment. Some folk will claim that SHA-256 is too short. Some will claim that SHA-384 is excessively long and computationally expensive. Some will claim something completely random. Almost none of them will have any (rational) basis for their claims, but allowing them to use the algorithm they believe is superior will make them more likely to deploy. 

5: 2 algorithms seems like enough. While SHA1 may or may not be suitable (my (and to be completely blunt, your) views don't really matter) -- there are enough strong views on the strength / lifetime that we are likely to get bogged down / splinter over this. If we were already deployed with SHA1 this would be an important decision, but seeing as we're not, I think that avoiding fight (and living to see another day) is best.
Once again, I'm not saying that I think that SHA1 is (or isn't) fine for this, rather that, in order to get deployed, we should avoid the issue.

#4 and #5 might be pandering, but if it doesn't decrease security, and leads to sooner / more deployment it seems like a win....

Does anyone object to this (for any reasons other than "You're running away from the fight, you coward!")? 
Please speak soon, as we'd love to close this out....

<chair hat>
Please don't let this dissolve into a "algorithm X is better than Y, and Z is a pile o' rubble" discussion -- while that may be true, this is not the time or place to have it....
</chair hat>

W


On Feb 25, 2011, at 4:31 PM, Warren Kumari wrote:

> Hi all,
> 
> While we are all ruminating on the other issues, I figured we might as well try address this one:
> 
> Need to specify which crypto algorithms and certificate types are mandatory to implement -- http://trac.tools.ietf.org/wg/dane/trac/ticket/21
> 
> Description:
> Currently, the draft is silent on which crypto algorithms and certificate types must be implemented for interoperability. It should be specific before the document is finished.
> 
> 
> W
> _______________________________________________
> keyassure mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/keyassure
>