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.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
