Hi, Viktor.
Thanks for clearing up my misunderstanding.
I think it would be worth a sentence or two along the lines of what you
have written below to clarify why OS is potentially more badly affected
by fragile PKIX-xx behaviour.
Cheers,
Elwyn
On 23/06/2015 14:42, Viktor Dukhovni wrote:
On Tue, Jun 23, 2015 at 01:41:23PM +0100, Elwyn Davies wrote:
Since the OS client is basing the decision to employ DANE on the
presence of TLSA RRs in DNS, no additional security is gained via
the PKIX usages unless they are the only ones supported by the
application protocol (the attacker who compromises DNS can just
inject "3 1 1" records instead). So DANE-xx is more reliable
at no security loss. Thus PKIX-xx is just a needless opportunity
to fail that should be avoided.
Maybe I have misunderstood how OS is intended to behave. I thought I
understood that if the client was able to handle OS and it was not able to
authenticate the server then it would potentially try for encryption only.
No, that is not the case. With opportunistic DANE TLS, when usable
secure (i.e. DNSSEC validated) TLSA records are present, but
authentication fails, there is typically no fallback to unauthenticated
TLS (mitigate downgrade attacks), for example:
https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-19#section-3.2
Is the problem that there is a difference between there being no
authentication available for a domain and an attempted authentication
failing (aside from any explicit policy declared by server or client) when
using OS?
Yes, when no usable secure DANE TLSA records are absent, unauthenticated
TLS is used if possible, and if not perhaps even cleartext. However,
when TLSA records are published authentication must succeed. Thus
PKIX-xx auth are to be avoided, because outside the browser space,
there is no pre-ordained canon of trusted CAs, and in any case
there is no value in using them when DANE-xx usages are also
supported. For most application protocols there should be a clear
statement of which of the two pairs apply (DANE-xx or PKIX-xx) and
the other pair should not be used.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
