Re: [exim-dev] [Bug 1812] New: Minor fixes and clarification…

Top Page
Delete this message
Reply to this message
Author: Viktor Dukhovni
Date:  
To: exim-dev
New-Topics: [exim-dev] DANE
Subject: Re: [exim-dev] [Bug 1812] New: Minor fixes and clarification of DANE support
On Thu, Apr 07, 2016 at 02:16:29PM +0000, admin@??? wrote:

>            Summary: Minor fixes and clarification of DANE support

>
> I tried to build 4.87 with GnuTLS and Experimental DANE support (Yes now i know
> DANE does not support GnuTLS at the moment).


I think that the DANE support still needs a bit of work even when
using OpenSSL.

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


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


  * TLSA record lookup failures are not handled correctly.
    If the host's A records are signed, 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.


There are likely more issues. One of the developers should get in
touch and we can go over the code, and if necessary make any
required changes to the underlying "danessl" code.

When OpenSSL 1.1.0 appears in May (or if delayed June), we should
chat again, because OpenSSL 1.1.0 has built-in DANE support that
supercedes my 'danessl' library.

-- 
    Viktor.