Russ Allbery wrote:
> Jonathan Nieder <jrnie...@gmail.com> writes:

>>  C. You have transport-level integrity protection, e.g. by using a
>>     protocol like https:// or ssh:// with proper PKI.
>
> I think it's worth being honest with ourselves here that the proper PKI
> part is not really happening with the Vcs-Git field (or Vcs-Browser for
> that matter) in normal usage in the context of Debian packages and random
> remote hosts.
>
> The bar to the attacker is not zero when https with normal public CAs is
> in use, but it's not very high.

There's no point in continuing to discuss this here.  I'll respond
privately in case you want to pursue it.

> I'm fine with including integrity protection in the protocol description
> anyway, but hopefully no one will think that it implies that https is
> providing strong authentication of the Git server here.  There's non-zero
> authentication, but it's pretty weak.

Without authentication, you don't have confidentiality either.  That's
how this comes up in the policy language: I don't understand why https
would be better or worse at providing confidentiality versus integrity.

One kind of authentication is that HTTPS protocol gives you some
assurance that the peer who first responded to is the same as the peer
for the rest of the connection.  That's enough to deter an unreliable
MITM or a passive MITM.

Jonathan

Reply via email to