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.
