Re: [exim-dev] DANE

Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Viktor Dukhovni
Fecha:  
A: exim-dev
Asunto: Re: [exim-dev] DANE
On Mon, Apr 18, 2016 at 03:16:34PM +0100, Jeremy Harris wrote:

> >   * dane_tlsa_load() returns DEFER when after processing all the
> >     TLSA records, no usable records are found (e.g. all have
> >     certificate usage PKIX-TA(0) or PKIX-EE(1)).  The expected
> >     behaviour of opportunistic DANE TLS (rfc7672) in this case is
> >     that the delivery will proceed with *unauthenticated* TLS (TLS
> >     required, but authentication not required).

> >
> >     I don't see the code enforces use of TLS when retrying TLS
> >     without DANE.

>
> Testcase 5840, subtests 8-10 check this specifically.
> Please raise a specific bug if you see one.


I am not *sure* there is an issue, so if you have tests that rule
out cleartext "fallback" when all the TLSA records are unusable,
perhaps the logic is fine. I got as far as noticing that "DEFER"
from the the DANE attempt leads to a retry without DANE.

> >   * In same function, the return value of  DANESSL_add_tlsa()
> >     might not be used quite right.  It returs 0 when the
> >     TLSA record is unusable (say unsupported selector), and
> >     negative when encountering an internal error.  Only
> >     the negative values should trigger errors.

> >
> >     default:
> >     case 0:     /* action not taken */
> >       return tls_error(US"tlsa load", host, NULL);

> >
> >     The 0 case should be treated just like unusable certificate
> >     usages or matching types (continue to next TLSA record).

>
> Seems reasonable. Is documentation for that routine and the
> others used for DANE support available yet?


Touche! The "danessl" library is RTFS-only, because it is a stopgap
for lack of DANE support in OpenSSL itself. With OpenSSL 1.1.0
you get a supported and documented DANE interface.

The API is not too dissimilar and in particular the "add a record"
function has the same return value: +ve for success, 0 for unusable,
and -ve for failure.

    http://www.openssl.org/docs/manmaster/ssl/SSL_CTX_dane_enable.html


> >   * TLSA record lookup failures are not handled correctly.
> >     If the host's A records are signed,

>
> Signed in what fashion?


I should perhaps have said "DNSSEC validated", that is that the A
records are in a "signed zone".

> >     then TLSA record lookup
> >     failure must block connections to the host, whether dane is
> >     "required" or not.  On the other hand, insecure TLSA records,
> >     (CNAME to insecure zone perhaps) should simply be ignored.


-- 
    Viktor.