Note, this "initial support", does not yet perform any verification
based on TLSA records, it just adds a convenience TLSA RR lookup
function that is conditional on libunbound. The application will
need to call SSL_get_tlsa_record_byname() and then provide the output
to the OpenSSL library via a control operation before the handshake.
I've replied to first message and it went to moderator for approval.
A few more comments:
0. The TLSA lookup function does not check the "bogus" field, which is
documented as possibly set together with "secure", indicating a bogus
DNS reply (unbound still returns the data it seems) and lets the caller
decide. So the new TLSA lookup function is not safe.
OK.
1. The introduction of a dependency on libunbound is I think a mistake,
applications should obtain TLSA RRs via whatever library they see fit.
It is sufficient for OpenSSL to specify a suitable encoding of the
TLSA RRs to be passed to the verification routine.
Goal is to have libssl check config file for [libunbound] section and
link to libunbound only if there is such section. In other words
run-time link to libunbound will be optional.
2. The packed encoding chosen is rather unnatural. A data structure
would have been better than a packed array of lenghts and data buffers.
struct SSL_TLSA_DATA {
size_t rrcount;
struct {
size_t len;
unsigned char *data;
} rrdata[1];
}
Rationale behind the unnatural choice is to have possibility to generate
record from scripting languages without having to create glue code.
I don't think Andy Polykov reads this list. I'll forward him my
comments under separate cover.
I've now subscribed to the list.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
