Re: [saag] Gen-art LC review of draft-ietf-dane-ops-12

[Elwyn Davies <[e-mail]>]

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.
>