[Discuss] free SSL certs from the EFF

[me at mattgillen.net (Matthew Gillen)]

On 11/25/2014 06:28 AM, Edward Ned Harvey (blu) wrote:
>> From: discuss-bounces+blu=nedharvey.com at blu.org [mailto:discuss-
>> bounces+blu=nedharvey.com at blu.org] On Behalf Of Matthew Gillen
>>
>> This is not without new attack vectors: you can only trust DNS responses
>> as far as DNS-SEC goes, which unfortunately ends one-hop before
>> end-systems (unless you run your own DNS server and force everything on
>> your home network to use that; which I do but don't know how common
>> that
>> is).
>
> Based on my understanding of DNSSEC, it doesn't add security except
> in esoteric edge cases.  Because your client doesn't have any point
> of trust -

That's what I meant when I said it "ends one hop before end-systems".

> if your client queries DNS, there's no way for your client
> to know *this* response is authentic for your domain.

I won't put the quoted part below in my own words:
https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions
> By checking the digital signature, a DNS resolver is able to check if
> the information is identical (i.e. unmodified and complete) to the
> information published by the zone owner and served on an
> authoritative DNS server. While protecting IP addresses is the
> immediate concern for many users, DNSSEC can protect any data
> published in the DNS, including text records (TXT), mail exchange
> records (MX), and can be used to bootstrap other security systems
> that publish references to cryptographic certificates stored in the
> DNS such as Certificate Records (CERT records, RFC 4398), SSH
> fingerprints (SSHFP, RFC 4255), IPSec public keys (IPSECKEY, RFC
> 4025), and TLS Trust Anchors (TLSA, RFC 6698).

If it can be used for SSH fingerprints and IPSec public keys, it can be 
used for CA certs...

Matt