11–20 of 49 posts
How do you become the crypto officer? What are their credentials? How often do you change the people?
Earlier quoted context omitted.
This was talked about a lot on the last DNSSEC story on HN. I don't have a link to the story but this site was linked to from discussions. http://sockpuppet.org/blog/2015/01/15/against-dnssec/ DNSSEC does seem pretty unnecessary at this point for security. It hands more power over the internet to fewer hands, whilst not providing any improved security.
I have suggested DNSSEC2 several times and it would likely use ECC not RSA. At least the root keys are 2048-bit RSA now, right?
-----BEGIN RSA PUBLIC KEY-----
MIGJAoGBALgVvZmZibtBpha3AIykU0OY4gcCXTcskYJUxGsdmV/awfmKcHlSrjNM
ioSgy4sByj+HpcbsyrZVGPp+JBXzYwwuEF/6w1k7vKYTK6vMSqgVcgooNkfb5MaR
F2y7MEpPxfStnfwu8knE24ExB0hYE1URxJ9CqB3zMSl/vicXYXXlAgMBAAE=
-----END RSA PUBLIC KEY-----
So how is this logically different than the replacement of all CAs with a single one?
Earlier quoted context omitted.
This was talked about a lot on the last DNSSEC story on HN. I don't have a link to the story but this site was linked to from discussions. http://sockpuppet.org/blog/2015/01/15/against-dnssec/ DNSSEC does seem pretty unnecessary at this point for security. It hands more power over the internet to fewer hands, whilst not providing any improved security.
DNSSEC only seems unnecessary under the assumption that you're already making full use of existing security measures everywhere else in the stack. If you live in a world where unencrypted HTTP still exists then it's nice to have some defense against ISPs who like to lie in DNS responses. And even if I am connecting over HTTPS through a shady ISP, I'd prefer not to send any packets at all to the wrong IP rather than w…
As tptacek and others have pointed out numerous times elsewhere on HN (and in the article linked above):
1. DNSSEC doesn't protect against ISPs hijacking DNS responses
2. TLS is easier to deploy than DNSSEC
3. TLS provides more security for the end user than DNSSEC does
3a. If TLS us used, DNSSEC provides essentially no additional security benefits to the end user.
So really, it makes sense to be advocating the use of TLS, which is what projects like Let's Encrypt are all about. DNSSEC is at best a waste of resources that could be better spent on actually securing the Internet through TLS, and at worst actively harmful (because the strongest criticism of TLS is that it centralizes trust in CAs, and DNSSEC centralizes trust even further - in a single entity!)
> I'd prefer not to send any packets at all to the wrong IP rather than wait until it presents the wrong certificate.
I'm not sure what difference it makes to be sending packets to the wrong IP. The whole point of TLS is that it doesn't really matter, because they can't read what you're sending anyway.
Also, the way the Internet works, you're always sending packets through the "wrong" IP addresses, so you should make the assumption that your raw traffic is visible to to any eavesdropper (and therefore encrypt your traffic so that this is not an issue).
Hmm, how sure are they that the OS only allows USB drives (as opposed to keyboards, network controllers, etc.), and contains no exploitable bugs? Is an image of the media the laptop was booted from publicly available, and has it been audited?
I almost feel silly asking, given all the time spent designing this and how smart the people are, but after all that trouble it seems amateurish to use USB...
Earlier quoted context omitted.
DNSSEC only seems unnecessary under the assumption that you're already making full use of existing security measures everywhere else in the stack. If you live in a world where unencrypted HTTP still exists then it's nice to have some defense against ISPs who like to lie in DNS responses. And even if I am connecting over HTTPS through a shady ISP, I'd prefer not to send any packets at all to the wrong IP rather than w…
> If you live in a world where unencrypted HTTP still exists then it's nice to have some defense against ISPs who like to lie in DNS responses. As tptacek and others have pointed out numerous times elsewhere on HN (and in the article linked above): 1. DNSSEC doesn't protect against ISPs hijacking DNS responses 2. TLS is easier to deploy than DNSSEC 3. TLS provides more security for the end user than DNSSEC does 3a. I…
DNSSEC protects signed zones by allowing clients to notice a suspicious lack of a valid signature on responses that should have been signed. DNSSEC doesn't protect unsigned zones, but that shouldn't surprise anyone and isn't really an indictment of DNSSEC's capabilities.
> I'm not sure what difference it makes to be sending packets to the wrong IP.
That malicious IP gets to record what kind of connection my computer was trying to make to that domain, even if the connection attempt is aborted relatively early. That's more information being leaked than if my computer had been able to determine that it got a probably-spoofed DNS response and aborted there.
Playing shenanigans with the DNS server is a lot easier than full-scale snooping and tampering on all traffic, which is why ISPs commonly do the former but the latter is usually only done with NSA involvement.
It needs to be hard for ISPs to direct all mistyped domain names to their own advertising (and in the process, implicitly pretending that the Web is the only use for the Internet) or to claim that sites they don't like don't exist. DNSSEC helps with that.
> The only way to move information from the outside world into the laptop/HSM is via USB drive. Accordingly, the key-signing request is loaded into the laptop via USB. Hmm, how sure are they that the OS only allows USB drives (as opposed to keyboards, network controllers, etc.), and contains no exploitable bugs? Is an image of the media the laptop was booted from publicly available, and has it been audited? I almost…
If that understanding was correctly received, and given the strength of potential motivation involved here, my thought is that the problem presented by the USB drive could only be combated by (a) ensuring that the USB drive was obtained in a random enough fashion that vast numbers would need to be deliberately compromised with this specific target in mind for that approach to be feasible, and (b) ensuring that the USB drive was neither ever unsupervised nor connected to any USB port (except one on a "known-to-be-clean" computer) after the selection occurred.
The problem that I see with those measures is that if compromising the laptop with a compromised USB drive were possible, then the actual security of the process would be purely dependent on the security of measure (b), as established by a single actor at the ceremony: that is, whomever provides the USB with the key-signing request. This last point just by itself would seem to be a degree of risk well beyond the criteria implied by the established protocol.
> The only way to move information from the outside world into the laptop/HSM is via USB drive. Accordingly, the key-signing request is loaded into the laptop via USB. Hmm, how sure are they that the OS only allows USB drives (as opposed to keyboards, network controllers, etc.), and contains no exploitable bugs? Is an image of the media the laptop was booted from publicly available, and has it been audited? I almost…
I too do not know enough to not feel silly for asking this, but I have a similar feeling, and I am not sure if I have misunderstood the past year's worth of popular articles on USB security, the risk posed by the USB in the context of the ceremony, or both. I had gotten the impression that the firmware vulnerabilities of USB flash drives had proven to be inherent, unavoidable, and utterly devastating; that, basically…
1. Use an USB key that doesn't have an updateable firmware. 2. Configure the laptop to only accept a single USB mass storage device on a dedicated port. No keyboard, no mouse. I should be possible with udev rules.
Earlier quoted context omitted.
> If you live in a world where unencrypted HTTP still exists then it's nice to have some defense against ISPs who like to lie in DNS responses. As tptacek and others have pointed out numerous times elsewhere on HN (and in the article linked above): 1. DNSSEC doesn't protect against ISPs hijacking DNS responses 2. TLS is easier to deploy than DNSSEC 3. TLS provides more security for the end user than DNSSEC does 3a. I…
> 1. DNSSEC doesn't protect against ISPs hijacking DNS responses DNSSEC protects signed zones by allowing clients to notice a suspicious lack of a valid signature on responses that should have been signed. DNSSEC doesn't protect unsigned zones, but that shouldn't surprise anyone and isn't really an indictment of DNSSEC's capabilities. > I'm not sure what difference it makes to be sending packets to the wrong IP. That…