<div dir="ltr">Correction: HTKP (hypertext key pinning) is an HTTP extension not HTTPS/SPDY. SPDY is the <div>foundation for HTTP2 by the way. Lets see what they come up with regarding security. Adam Langley</div><div>(Google) has been pushing in IETF for mandatory encryption (TLS) in HTTP2. The trust issue is still </div><div>unresolved as far as I'm aware of (haven't looked into new HTTPBIS Working Group documents since</div><div>the last IETF meeting).</div><div><br></div><div>HTKP is basically TOFU security with a more user friendly implementation. I do not see it getting </div><div>accepted by IETF consensus, but I might be wrong. </div><div><a href="https://tools.ietf.org/html/draft-ietf-websec-key-pinning">https://tools.ietf.org/html/draft-ietf-websec-key-pinning</a></div><div><br></div><div><br></div><div>Aaron </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Sep 28, 2014 at 8:27 PM, Aaron Zauner <span dir="ltr"><<a href="mailto:azet@azet.org" target="_blank">azet@azet.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="im HOEnZb">* <a href="mailto:mls@xlist.pw">mls@xlist.pw</a> <<a href="mailto:mls@xlist.pw">mls@xlist.pw</a>> [140928 08:18]:<br>
</span><span class="im HOEnZb">> Hi all,<br>
><br>
> creating CSRs is one of the crypto tasks people do often. It would be nice to<br>
> have recommendations in the guide how to generate CSRs with openssl and what<br>
> parameters are recommended from a crypto perspective. Information is available<br>
> on sites like<br>
> <a href="https://shaaaaaaaaaaaaa.com/" target="_blank">https://shaaaaaaaaaaaaa.com/</a> and <a href="https://konklone.com/post/why-google-is-" target="_blank">https://konklone.com/post/why-google-is-</a><br>
> hurrying-the-web-to-kill-sha-1 but it would be helpful to have it consolidated<br>
> in the better crypto guide.<br>
<br>
<br>
</span><div class="HOEnZb"><div class="h5">By the way, back when we started writing the paper (which is still a<br>
draft by the way, contribute please if you want a final document - the<br>
original authors are currently pretty busy with work and different<br>
projects) none of the Certificate Authorities supported a stronger<br>
signture algorithm than SHA1. Some of them still supplied MD5<br>
Certificates (<a href="http://www.win.tue.nl/hashclash/rogue-ca/" target="_blank">http://www.win.tue.nl/hashclash/rogue-ca/</a> - this was<br>
in 2008!). Although TLS supports ECDSA, most Certificate Authories<br>
do not supply ECDSA signed Certificates. Acutally I'm not aware of<br>
any major CA that does supply ECDSA certs.<br>
<br>
<br>
Somewhat offtopic, but relevant:<br>
<br>
I'm repeating myself over and over again; CAs need to die, they have<br>
been snakeoil for security from the very beginning, and everybody<br>
that works in information security knows that being compliant with<br>
some policy/standard does not guaratuee real security (in the case<br>
of CAs it's 'webtrust' - which basically says 'you paid shitloads of<br>
money, you have an HSM [stuff that has been proven to be insecure],<br>
you have insurance: there you're now an offical CA. Inform your<br>
favorite browser vendors and the java truststore that you're legal<br>
now). Unfortunately there's no real alternative as of now, TACK has<br>
not been adopted e.g. because chromium security engineers dislike the<br>
design (they came up with hypertext key pinning instead, which is<br>
the same thing, only limited to HTTPS/SPDY, and it doesn't seem to<br>
get adopted anyway). I was talking to moxie as well as chrome(ium)<br>
security folks about the issue, my best guess is it'll stay a draft<br>
forever, although it's well engineered and the design is inherently<br>
sexy. By the way, they also do not trust the DNSSEC/DANE hierachy<br>
model in comparision to CAs, something I fully agree with (there are<br>
too many attack vectors in DNSSEC hierachy compared to a central<br>
authority, which is something the internet was never designed for<br>
anyway, but unfortunately as of now seems to be the best option).<br>
<br>
So in the end we'd need a couple of really good engineers and<br>
cryptographers to come up with a new protocol for verifiable<br>
distributed online trust that is not based on central authorities<br>
that may be compromised.<br>
<br>
So we're stuck with bullshit CAs and the confidence that google<br>
detects malicous ones, because we can't (and certificate transparency<br>
is still not an actively deployed protocol).<br>
<br>
There's one alternative left, but it doesn't really scale for web:<br>
TOFU (trust on first use) - that's basically what SSH does, you<br>
accept the key once and trust that your initial connection was not<br>
MITM'ed.<br>
<br>
Aaron<br>
<br>
</div></div></blockquote></div><br></div>