freebsd security - Dec 2017 - http subversion URLs should be discontinued in favor of https URLs

--------
In message <86d13kgnfh.fsf at desk.des.no>,
=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= w
rites:
>"Poul-Henning Kamp" <phk at phk.freebsd.dk> writes:
>> The only realistic way for the FreeBSD project to implement end-to-end
>> trust, is HTTPS with a self-signed cert, distributed and verified
>> using the projects PGP-trust-mesh and strong social network.
>
>Your suggestion does not remove implicit and possibly misplaced trust,
>it just moves it from one place to another.  Instead of trusting a
>certificate authority and DNS, you trust the source of the public key,
>and probably also DNS.  As always, it boils down to a) key distribution
>is hard and b) what's your threat model?
I don't think I agree with any of that ?

With respect to authenticity of the FreeBSD SVN repo I cannot
imagine anybody else being even one percent as qualified and
trustworth as the FreeBSD projects own core-team.

In particular I would never trust any "In the CA-racket for the
money" organization to do so.

If you are worried that the FreeBSD project "staff" cannot
handle a root-cert competently, then the exposure is no
smaller or larger than if it was a CA-signed cert they fumbled.

Trusting DNS doesn't apply it if the project root-cert was
stored on my local machine after I used my best judgement of PGP
signatures to conclude that it was authentic.

And I don't really see distribution of this particular key being
difficult at all:  We already PGP sign release checksums for
authenticity and it the FreeBSD root-cert is just another file to
get same treatment.

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

On 12/12/2017 06:59, Poul-Henning Kamp wrote:
> --------
> In message <86d13kgnfh.fsf at desk.des.no>,
=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= w
> rites:
>> "Poul-Henning Kamp" <phk at phk.freebsd.dk> writes:
>>> The only realistic way for the FreeBSD project to implement
end-to-end
>>> trust, is HTTPS with a self-signed cert, distributed and verified
>>> using the projects PGP-trust-mesh and strong social network.
>> Your suggestion does not remove implicit and possibly misplaced trust,
>> it just moves it from one place to another.  Instead of trusting a
>> certificate authority and DNS, you trust the source of the public key,
>> and probably also DNS.  As always, it boils down to a) key distribution
>> is hard and b) what's your threat model?
> I don't think I agree with any of that ?
>
> With respect to authenticity of the FreeBSD SVN repo I cannot
> imagine anybody else being even one percent as qualified and
> trustworth as the FreeBSD projects own core-team.
>
> In particular I would never trust any "In the CA-racket for the
> money" organization to do so.
>
> If you are worried that the FreeBSD project "staff" cannot
> handle a root-cert competently, then the exposure is no
> smaller or larger than if it was a CA-signed cert they fumbled.
>
> Trusting DNS doesn't apply it if the project root-cert was
> stored on my local machine after I used my best judgement of PGP
> signatures to conclude that it was authentic.
>
> And I don't really see distribution of this particular key being
> difficult at all:  We already PGP sign release checksums for
> authenticity and it the FreeBSD root-cert is just another file to
> get same treatment.
>
> Poul-Henning
Agreed.

Now the question becomes this -- is the proper means to handle this via
TLS (using that root cert) OR should the *transport* be fixed so that
https doesn't need to be used?

I argue the second, because the goal when it comes to source
distributions is ensuring that the code you transfer is bit-wise
identical to the code on the FreeBSD project repositories *which can be
mirrored.*

Attempting to "overload" TLS with this responsibility now requires
that
the project take operational and security responsibility for the
integrity of any *mirror* of said code, which is IMHO flatly
unreasonable and thus is simply not going to happen.? Otherwise you can
have all the assurance you want that the bits you get are the bits that
were on the disk at the other end, but no assurance at all that the bits
on the disk *are the same as the bits on the FreeBSD project's machines!*

Solve the problem at the correct location -- either fix svn to sign and
verify updates or dump it for something that can and use that existing
mechanism (e.g. git)

-- 
Karl Denninger
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4897 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://lists.freebsd.org/pipermail/freebsd-security/attachments/20171212/b20fea93/attachment.bin>

"Poul-Henning Kamp" <phk at phk.freebsd.dk>
writes:
> "Dag-Erling Sm?rgrav" <des at des.no> writes:
> > Your suggestion does not remove implicit and possibly misplaced
> > trust, it just moves it from one place to another.  Instead of
> > trusting a certificate authority and DNS, you trust the source of
> > the public key, and probably also DNS.  As always, it boils down to
> > a) key distribution is hard and b) what's your threat model?
> I don't think I agree with any of that ?
>
> With respect to authenticity of the FreeBSD SVN repo I cannot imagine
> anybody else being even one percent as qualified and trustworth as the
> FreeBSD projects own core-team.  [...]
Let me rephrase: it's not just the source of the key or certificate, but
the path from that source to you.  There is *always* some level of blind
trust, and all your suggestion does is move it from one place to
another.  You trust the certificate because you trust the PGP key that
was used to sign it, but why do you trust the key?  Did someone you know
personally vouch for it?  Do you trust them?  Were they present when the
key was generated, or do they trust it because someone *they* trust told
them it was genuine?  Does your trust in whomever gave you the key
translate to those they trust?  Is there a bottom to this pit?

The bottom line is, once again, that key distribution is hard, and that
you shouldn't make infosec decisions without having at least a vague
outline of a threat model.

DES
-- 
Dag-Erling Sm?rgrav - des at des.no