[subject changed, as the original bug mail is not relevant]
On 16/04/16 22:27, Viktor Dukhovni wrote:
> 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.
Testcase 5840, subtests 8-10 check this specifically.
Please raise a specific bug if you see one.
>
> * 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?
>
> * TLSA record lookup failures are not handled correctly.
> If the host's A records are signed,
Signed in what fashion?
> 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.
--
Jeremy
