On Mar 17, 2014, at 10:44 AM, Viktor Dukhovni <[email protected]> wrote:
> 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.
Umm, I asked for specific text. :-) If it is in Section 4.1 (which is where it
should be), I'm not seeing it.
>>> 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.
In Section 4.1:
o A TLSA RRSet whose DNSSEC validation state is secure MUST be used
as a certificate association for TLS unless a local policy would
prohibit the use of the specific certificate association in the
secure TLSA RRSet.
And at the end of Section 8:
Generators of TLSA records should be aware that the client's full
trust of a certificate association retrieved from a TLSA record may
be a matter of local policy. While such trust is limited to the
specific domain name, protocol, and port for which the TLSA query was
made, local policy may decline to accept the certificate (for reasons
such as weak cryptography), as is also the case with PKIX trust
anchors.
Crypto choice is definitely a local policy.
--Paul Hoffman
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
