<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Jul 6, 2014 at 10:06 AM, Karanbir Singh <span dir="ltr"><<a href="mailto:mail-lists@karan.org" target="_blank">mail-lists@karan.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 07/06/2014 11:11 AM, Nico Kadel-Garcia wrote:<br>
> First note: in many environments, MITM is how things work normally. In<br>
> others, the routers and proxies and DNS are *not* secured or easily<br>
> re-implemented to be secure, for many, many different reasons. No<br>
> matter how careful you are with <a href="http://git.centos.org" target="_blank">git.centos.org</a> itself, it's going to<br>
> be vulnerable to trojaned intermediate repositories being substituted<br>
> because no one at CentOS or Red Hat has enough control over the<br>
> Internet to fix these.<br>
<br>
</div>You are repeatedly saying this, but failing to actually quantify it.<br>
<br>
your gpg key is pretty much null routed once someone can MITM the<br>
content anyway, and i also assume you realise that a gpg sign is still<br>
with the same sort of code/key as an ssl connection is.<br></blockquote><div><br></div><div><br></div><div>It's may be the same classification of cryptographic functions... but it is not the same. With SSL/SSH you are, at least in theory, authenticating the origin host. This makes no promise about the origin content.</div>
<div><br></div><div>A PGP-signed tag makes a promise about the content but does *not* make a promise about the origin host.</div><div><br></div><div>So, they are not the same.</div><div><br></div><div>In the case of <a href="http://git.centos.org">git.centos.org</a>, somebody who manipulates the repositories could likely fake the repository content being consistent, but would have a more difficult time faking a signature where the public key is stored elsewhere that <a href="http://git.centos.org">git.centos.org</a> (such as one of the PGP key servers). The SSL/SSH for <a href="http://git.centos.org">git.centos.org</a> would continue to pass, but the signature would not.</div>
<div><br></div><div>The other case already mentioned was the case that the content has an intermediate resting point. That is, I clone from <a href="http://git.centos.org">git.centos.org</a>, and then I publish to somebody else. How do they know which content is authentic... mine or <a href="http://git.centos.org">git.centos.org</a>? Being able to point to the signed tag shows cryptographically who signed the content and this could be an important differentiator in determining which source is the "real" source.</div>
<div><br></div><div>Now:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
the bottom line is that unless you can get an authoritative manner of<br>
initial keyexchange, that you can absolutely trust, nothing else down<br>
the line is going to be any more secure than the initial handover. I'm<br>
happy to setup a keysign and keyexchange event at every dojo we run, but<br>
even that is likely to only reach a small fraction of the entire userbase.<br>
<br>
So the only way to get the originating gpg key ( that you'd verify<br>
against ) is over ssl on the internet, which also implies that having<br>
<a href="http://git.centos.org" target="_blank">git.centos.org</a> behind the same leave lof trust puts us no worse off.<br><div class="im HOEnZb"><br></div></blockquote><div><br></div><div>I think you may be dismissing the two scenarios... 1) <a href="http://git.centos.org">git.centos.org</a> gets compromised, 2) intermediate resting point. Both of these require the *content* to be signed. You are only providing authentication of the original source which does not address either of these points effectively.</div>
<div><br></div><div>So, I don't think it is correct that the "bottom line" is as you state above. The real "bottom line" is that SSL/SSH only authenticates the source host. It provides *no* guarantee for the source content.</div>
<div><br></div><div>If you authenticated the content, you wouldn't actually need to authenticate the source host. This is how Bittorrent works in general. It doesn't matter how the bytes get from point A to point B, as long as the final result has the correct *content*. SSL/SSH do not guarantee the correct *content* so it is rather ineffective as a means of authenticating the content. It's saying "trust me... I'm git.centos.org... what could go wrong?"</div>
<div><br></div></div><div><br></div>-- <br>Mark Mielke <<a href="mailto:mark.mielke@gmail.com" target="_blank">mark.mielke@gmail.com</a>><br><br>
</div></div>