On Tue, Mar 18, 2014 at 03:20:07PM -0400, Andrew Sullivan wrote:
> I would say this instead as, "We will not be able to stop them anyway,
> so we should focus on interoperability and maybe some sound advice,"
> but I know lots of people will disagree.
On Tue, Mar 18, 2014 at 11:09:31AM -0700, Paul Hoffman wrote:
> [ Lots of misinterpretation and inaccuracies about the proposed mechanism. ]
>
> This is insane. You are creating operational failure cases for servers
> for no benefit until one of the hash algorithms has a significant weakness.
> Even then, the damage you are proposing quite outweighs the chance of any
> real damage from the use of a weakened hash. Hashes weaken very slowly,
> and there is plenty of time to alert people to use stronger hashes.
On Tue, Mar 18, 2014 at 10:38:22AM -0700, Jim Schaad wrote:
> > Stop trying to over engineer this.
>
> +1 - At any given time this is a binary choice. The hash algorithm either
> is or is not acceptable.
I don't think I to need to restate the merits of the incremental
security as stronger digests are added before weaker ones are
disabled.
My sense is that regardless, there is not much enthusias for
negotiating a single digest based on what digests the server offers,
with the client choosing its most preferred one.
Is this an accurate summary of the group's consensus view? Does
anyone want to defend the view of TLSA digests as a menu of options
from which the client can choose one?
If not, I will drop the digest agility portion of the SMTP draft.
In the OPs draft we can encourage server operators (SHOULD) to
apply all digests equally to all objects, because that's more robust
in the face of local policy, and results when this is not done may
not be what the operator wanted.
Anyone else?
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
