On 03/22/2013 05:51 PM, Viktor Dukhovni wrote:
On Fri, Mar 22, 2013 at 12:07:25AM +0000, Viktor Dukhovni wrote:
Any comments at all on the below? It is tempting to simply treat
"IN TLSA x 0 0" as "unusable", for all "x", and thereby discourage
the notion that it is a good practice to deliver full certificates
via DNS, instead of the TLS handshake...
>> Are servers that publish their trust anchor details via DNS in full:
>>
>> _25._tcp.mail.example.com. IN TLSA 2 0 0<DER cert in hex>
>>
>> exempt from being obligated to provide the same certificate somewhere
>> in their trust chain? It is far easier to treat the "2 0 0" case
>> as a more specific bulky match blob, than to also arrange for it
>> to be an input into the client's trust chain construction algorithm.
>>
>> The latter is largely impractical with OpenSSL. I thought I saw
>> some text in the RFC about "2 x y" trust-anchors needing to be
>> explicitly provided in the server's trust chain, since clients
>> cannot be expected to already have these on hand. Can't seem
>> to find it any more.
>> I am hoping that the above includes the "2 0 0" case, for though
>> the cert is available in DNS it is not in the trust chain or trust
>> store, and moving it from the DNS into the trust chain or trust
>> store is non-trivial.
>>
>> I am also hoping that almost nobody will use match type 0 certs,
>> and that in practice all TLSA records will be sha2 digests.
>>
>> If verifiers are obligated to attempt to use the certificate in
>> "2 0 0" as part of the trust chain if missing, then I may need
>> to treat "2 0 0" as "unusable" until OpenSSL makes it possible
>> to configure each connection with a private list of additional
>> trust anchors before starting the handshake (without polluting
>> the trust store for future connections that use the same
>> persistent SSL_CTX).
>
> So no new OpenSSL library code is required to support this, if one
> stares at the (lightly documented) OpenSSL API hard enough, but
> still "IN TLSA x 0 0" looks unwieldy.
>
I use the 2-0-0 right now to set the TLS-context to that certificate
only. (No global CA's), so that only server certificates signed with
that certificate will pass validation. The connection fails if the
server certificate doesn't match when my connection is hijacked with a MitM.
If I understand you correctly, dropping TLSA 2 0 0 (full certificates)
means that I would have to connect to a server, learn its certificates
in the handshake and then perform the hash verification against the
TLSA-record. It could tempt some into adding a 'override tlsa-record
validation' button later. That road leads to the madness we give to our
browser users. People who are unable to make a good decision, especially
if the rendered page (with the wrong certificate) looks like a bank-page
with a large transaction pending. (phishing).
I have a very good use case to set the 2-0-0 certificate as the only
certificate in the session connection context. It allows clients to
limit their connections only to servers signed with the certificate from
the TLSA-record.
I call it Cryptographic Same Origin Policy.
Please see: http://witmond.nl/ecca/eccentric-authentication.html
I humble believe that creating a new session context (with just a single
CA-cert) for each session is the way forward. Having a single
certificate store is the old way of the global 'Trusted' CAs.
I remember the pain of doing that in Firefox with NSS. It's easy in Go-lang.
Cheers, Guido.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
