In message <[email protected]>, Peter Palfrader writes: > On Thu, 20 Mar 2014, Wes Hardaker wrote: > > > Do you, Mr. System Administrator defining the local policy for the > > *client*, want: > > > > A) Accept any published hashing algorithm out of my "unordered set" > > to validate the remotely presented certificate. [Ordering it > > doesn't buy you anything since you'll simply accept a match and it > > doesn't matter which you try first, since any success in any > > algorithm will equally indicate "ok"; in fact in an implementation > > aiming for speed, it might be best to choose the order based on > > how fast you can execute the algorithm]. If the server fails to > > publish a perfect record set, as long as one matches I'm ok with that. > > > > B) Believe that the server will always publish perfect records, and > > if my "ordered set" of algorithms is [SHA512, SHA256] and they > > publish SHA512, then I never want to accept SHA256 because I fear > > an attack more than I fear a server administrator blowing their > > configuration. > > > But the real question, is what is the *default* that we should suggest > > an implementation do? > > > II) what should we do in SMTP? This is where Viktor, considering case > > #2 above, is wanting to do B ("accept just the 'best' in an ordered set > > of algorithms) instead of A. The arguments, though, from both sides > > are probably talking about different cases (generic vs SMTP) and I > > think that is ending up with some of the confusion. > > I'd like to see the SMTP draft suggest B. (All the others should do B > too, but that's a different story). > > Aloha, > -- > | .''`. ** Debian ** > Peter Palfrader | : :' : The universal > http://www.palfrader.org/ | `. `' Operating System > | `- http://www.debian.org/ > > _______________________________________________ > dane mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dane
Truly, we do not know which of SHA256 and SHA512 will be broken first. Both are more than strong enough for this job at this point in time. When one is broken it will no longer be strong enough. Neither will be broken by brute force. They will be broken by discoveries of flaws in the algorithms. We support multiple algorithms so that when/if one is broken we do not end up in a situation of having no trusted algorithms supported. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
