[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 -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
