On May 15, 2013, at 3:07 PM, Andy Polyakov <[email protected]> wrote:
>>> 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. Yes, yes you did -- We did get: ---- As list administrator, your authorization is requested for the following mailing list posting: List: [email protected] From: [email protected] Subject: Re: [dane] DANE for OpenSSL Reason: Post by non-member to a members-only list At your convenience, visit: https://www.ietf.org/mailman/admindb/dane to approve or deny the request. ----- I went to go approve the message and got: ----- dane Administrative Database There are no pending requests. Click here to reload this page. ---- I assumed that a: my co-chair had clicked approve or b: you had clicked the "Don't bother" link. Seeing as this didn't hit the list (and seems to have disappeared into the Ether / been eaten by the angry bit gods) can you please resubmit it… Somehow we, or mailman, screwed up... W > >> 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 > -- "Does Emacs have the Buddha nature? Why not? It has bloody well everything else..." _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
