On Mon, Mar 17, 2014 at 09:47:46AM -0700, Paul Hoffman wrote:
> >>> * It should be possible for servers to publish TLSA records
> >>> employing multiple digest algorithms allowing clients to
> >>> choose the best mutually supported digest.
> >>
> >> Isn't that already possible?
> >
> > Not based on RFC 6698 alone. With RFC 6698 the client trusts all
> > TLSA records whether "weak" and "strong".
>
> Can you point to the specific text for that? It was not my
> intention, and I doubt it was the intention of the WG.
Per RFC 6698, the client evaluats all "usable" TLSA records until
one matches, regardless of digest algorithm strength.
> > My proposal is essentially the same. The client uses the strongest
> > acceptable digest algorithm. The *client* decides what "strongest"
> > means. It never chooses an unsupported algorithm.
>
> Again, that was at least my intention for 6698. If we need to
> clarify that, that would be much better than adding another layer
> of protocol grease.
There is no text in 6698 that even approximately suggests that clients
get to use only the records with the strongest (local criteria) digest.
> > Stronger clients will never use the published weak records.
>
> I strongly doubt that is the desired outcome. If so, lots of
> zones will go invisible when the "later" in "remove weak digests
> later" stretches to a decade.
One can audit for weak TLSA RRsets on peer systems before deciding
to disable a weak algorithm. My proposal makes it possible to
ramp security before completely disabling an algorithm. Not doing
the proposed agility algorithm makes the problem worse.
> > This works poorly. While the weak algorithm is being phased out
> > (years) even clients that support stronger algorithms are at risk.
>
> At risk of what? Seriously: DANE is additional security over
> non-TLS, so a "weak" algorithm is still better than "no TLS".
> Reduction to absurdity is not helpful here.
Of all people, I am quite surprised to see you say that. DANE IS
NOT additional security over non-TLS. DANE is a specification for
publishing public keys in DNS. It can be used for both opportunistic
and non-opportunistic use-cases. Postfix supports DANE in both
opportunistic and mandatory modes.
Please see also my reply to Paul W.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
