Re: Bug#765512: general: distrust old crypto algos and protocols perdefault

[Ian Jackson]

Lars Wirzenius writes ("Re: Bug#765512: general: distrust old crypto algos and 
protocols perdefault"):
> Merely defending one's opinions is a recipe for long threads. A good,
> productive discussion about Debian development requires understanding
> other people's arguments, evaluating one's own point of view, and
> adapting it to produce an improved synthesis position, and iterating
> this a few times to end up with a consensus of an accurate mental
> model of reality and a realistic plan of action, which can be worked
> on, preferably by named people, who agree to it. Such a discussion
> benefits greatly from empathy, sympathy, good will, and the lack of a
> conviction that one is right.

We should frame that.  Thanks, Lars.

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21567.44981.266587.833...@chiark.greenend.org.uk

Re: Bug#765512: general: distrust old crypto algos and protocols perdefault

[Thorsten Glaser]

On Wed, 15 Oct 2014, Christoph Anton Mitterer wrote:

> I see it a bit differently:
> RC4 is broken. Full stop.
> Therefore new versions clients and servers should per default not
> use/enable/accept it.

Sorry, but I *have* to nitpick here.

RC4 as used by SSL is mostly broken. (A server could reset login
cookies to be invalid after, say, 65536 pageloads, so that the
attack cannot be mounted. This would allow the use of RC4 in SSL
for compatibility/interoperability.)

RC4 as used by arc4random is not broken, because arc4random (at
least the more sane implementations) have one or several changes
in effect that prevent the issues from RC4 becoming abused.

RC4 as used by WEP is broken. I think this cannot be phrased
differently, either.

RC4 as used by Kerberos has been described to you already.

RC4 (aRC4) is just a stream cipher with some bad properties,
that can, mostly, be worked around in the protocol. But if the
protocol does not do that, it’s broken, yes.

bye,
//mirabilos
-- 
[16:04:33] bkix: "veni vidi violini"
[16:04:45] bkix: "ich kam, sah und vergeigte"...


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.11.1410160946270.5...@tglase.lan.tarent.de

Re: Bug#765512: general: distrust old crypto algos and protocols perdefault

[Jonathan Dowland]

On Thu, Oct 16, 2014 at 05:42:23AM +0200, Christoph Anton Mitterer wrote:
> On Wed, 2014-10-15 at 18:31 -0700, Russ Allbery wrote: 
> > It feels to me like you're spending lots of time telling other people
> > they're wrong and telling other people what they should be spending time
> > on, and then arguing with anyone who tells you that how you're going about
> > this isn't effective.
> Well isn't that somehow the point of discussion and defending one's
> opinions? Don't you just do the same?

There's no point having an argument unless you are prepared to have *your*
opinion changed.

I work for a University Computing Science department which has a research group
dedicated to Security research. They have a fair amount of success and there
are some very bright people in the group. My former boss, the Head of School,
originally set up the security group. We discuss these issues from time to
time.  He told me that one of the biggest problems they have with new
researchers is getting them to understand that security in the real world is a
matter of compromise. A lot of researchers come in with an attitude quite like
yours: absolutist. This is either insecure and must not be used in any
circumstances ever, or it's secure. The problem is this simply doesn't work,
for many reasons including the ones that Russ has done an excellent job of
explaining. The clients of the research group, including some large companies
and government departments with acronyms for names, know this. The good science
that comes out recognises this.

>From one of your other posts you make it quite clear that you appreciate the
practical difficulties of trying to get any distro-wide change made in Debian:
buy-in. If you want to see security in Debian improved; that's where your
efforts need to go, towards seeking buy-in. Read and carefully consider the
advice people have given you here regarding your approach, using things like
release goals, gaining consensus, altering your argument style, etc., if you
want any hope of achieving your ultimate goals.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141016065249.gc10...@chew.redmars.org

Re: Bug#765512: general: distrust old crypto algos and protocols perdefault

[Arto Jantunen]

Joey Hess  writes:
> In general, I think that Debian needs to identify upstreams that are
> being proactive about dropping old crypto algos, and those that are not.
> Major browsers, openssh upstream, etc are going to be more on top of
> this than we are, and make better decisions. Web servers probably have
> user pressure to keep old crypto available, in order to support broken
> clients that some users care about, and Debian might be able to improve
> the defaults in such cases.

I can't agree here about major browser vendors being an example of
proactively dropping old crypto algos. Browser vendors have strong
incentives to prioritise compatibility above everything else (if a user
can't access a website with your browser but can with a competitors
you've just lost a user). For security the same incentive doesn't really
exist, as when the vendors get caught with their pants down (as happened
here with the POODLE attack) all they need to say is "Well we didn't
know it was actually broken, and besides all the other browsers had it
enabled too".

As Russ said earlier in the thread security is always a compromise with
compatibility, but IMO the browser vendors end up making different
choices than we should. For example I have been running my browser for
over a year with SSLv3 disabled, and have only found one website that
doesn't work. There is no reason this couldn't have been disabled before
it was compromised. The same situation seems to be happening with RC4,
a practical attack needs to appear before it gets dropped.

-- 
Arto Jantunen


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/8761fksfvx@kirika.int.wmdata.fi

Re: Bug#765512: general: distrust old crypto algos and protocols perdefault

[Lars Wirzenius]

On Thu, Oct 16, 2014 at 05:42:23AM +0200, Christoph Anton Mitterer wrote:
> On Wed, 2014-10-15 at 18:31 -0700, Russ Allbery wrote: 
> > It feels to me like you're spending lots of time telling other people
> > they're wrong and telling other people what they should be spending time
> > on, and then arguing with anyone who tells you that how you're going about
> > this isn't effective.
> Well isn't that somehow the point of discussion and defending one's
> opinions?

Merely defending one's opinions is a recipe for long threads. A good,
productive discussion about Debian development requires understanding
other people's arguments, evaluating one's own point of view, and
adapting it to produce an improved synthesis position, and iterating
this a few times to end up with a consensus of an accurate mental
model of reality and a realistic plan of action, which can be worked
on, preferably by named people, who agree to it. Such a discussion
benefits greatly from empathy, sympathy, good will, and the lack of a
conviction that one is right.

-- 
http://gtdfh.branchable.com/ -- GTD for hackers
http://obnam.org/ -- HAVE YOU BACKED UP TODAY?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141016054147.gr21...@exolobe1.liw.fi

Re: Bug#765512: general: distrust old crypto algos and protocols perdefault

[Christoph Anton Mitterer]

On Wed, 2014-10-15 at 18:31 -0700, Russ Allbery wrote: 
> It feels to me like you're spending lots of time telling other people
> they're wrong and telling other people what they should be spending time
> on, and then arguing with anyone who tells you that how you're going about
> this isn't effective.
Well isn't that somehow the point of discussion and defending one's
opinions? Don't you just do the same?


> One, you're preaching to the choir, and two, I don't understand what
> you're trying to accomplish by haranguing me about this.  You seem to have
> entirely missed the point I was trying to get across, which is that many
> upstreams are closely monitoring these issues and have a plan already,
> and, when that's the case, their plan is probably better than something
> Debian would come up with for their software.  (As Brian points out, this
> isn't always the case, but that was partly Joey's point: we need to look
> at whether upstream is engaged and has a plan, or whether they're ignoring
> the problem or unaware.)
Uhm,... wasn't you who sparked the discussion about RC4 safety within
Kerberos?
I think originally I didn't mention kerberos at all.
So either I should have interpreted your following answers then as a
that's Russ' PoV and thus I'm expected to change my own opinion
accordingly, or I could take it as an invitation for discussion.
Or did I get anything wrong here?

My original point was merely that we have a lot of packages where the
situation seems completely unclear and other packages where upstream
makes bad decisions (e.g. Mozilla).
Now of course we can argue back and forth whether Mozilla's decisions
are good or not; I'd say they've waited well too long (and would
consider my point proven by POODLE), others would say it was right.
But I'd expect that neither you, nor Ian nor I'm the only one here who
studied computer science, mathematics and worked in the security areas
and cryptography, and probably we'll find people agreeing with your or
my position and even those with a completely different one.

Alas, a waste of time, for all of us - surely not what I've meant to
gain with #765512.





> If you think upstream's plan is wrong, then you need to go argue with
> *them* about that, not with us, unless upstream is *so* wrong that it
> looks like we should just fork.  For good upstreams, such as the Kerberos
> upstreams, they generally have crypto expertise in their team already and
> can have a detailed discussion with you about exact threat models and
> timelines for deprecating enctypes.  When that sort of expertise exists
> upstream, I'm arguing that this is not the effective place to do
> something.  Diverging from upstream has a rather significant cost,
> particularly if we diverge from upstream and then *get it wrong*, which is
> not outside the realm of possibility.


> And then you go on to put words in my mouth, like this:
> 
> >> If we were making a security-hardened distribution that chooses
> >> security over interoperability across the board, we may well want to
> >> make other decisions.
> 
> > So you suggest against efforts of securing / hardening Debian? What
> > about introduction of hardened compiler flags, apparmor, selinux, etc.?
> 
> > I personally don't think that hardening contradicts being a universal
> > OS.
> 
> which is just frustrating.  I feel like you're turning my opinion into a
> parody of what I said to make it easier to argue with.
Uhm no I really just wanted to understand what you were trying to say.
Your point was (AFAIU) that we're not a specialised distro focusing on
security, right? Next I understood, that we shouldn't place security
above interoperability.
That's why I've asked how that affects those other fields, since usually
all of them mean interoperability problems, or at least that things do
not longer work that straightforward out of the box.


> Of course doing those sorts of things is consistent with being a universal
> operating system.  But you'll notice that Debian did hardening roughly
> around the same time (or even a bit later) than other major distributions,
> which was nowhere near as fast as some of the security-focused
> distributions did it.  And I'd love to have a solid and reliable SELinux
> setup that we could just turn on, but *everyone* in the Linux distribution
> space has found that extremely difficult to achieve.  My point is not
> "don't do security stuff."  My point is "Debian is not going to be on the
> cutting edge of disabling features in the name of security."
I see, well that wasn't clear to me, at least from your previous points.


> In other words, if your primary concern is security, Debian is always
> going to be a little slow for you.  I don't think that's a problem, nor
> does it imply that Debian should *never* push on security.
But I guess you're aware, that an attacker usually doesn't wait till
software or a distro starts defending itself?


> I just hate to see people wasting
> their time writing long re

Re: Bug#765512: general: distrust old crypto algos and protocols perdefault

[Ian Jackson]

Christoph Anton Mitterer writes ("Re: Bug#765512: general: distrust old crypto 
algos and protocols perdefault"):
> So what's wrong about my approach, apart from the paradigm "security
> first"?

Firstly, I agree with everything Russ has said.

But secondly, I would worry that you're perhaps not paying enough
attention to the practicalities surrounding deployment of algorithms
and indeed security technologies more generally.

Your response to Russ about RC4 in Kerberos is an example.

Your comments about SSL are also concerning.  In some applications,
SSL is used opportunistically.  Indeed that's happening now to some of
Debian's web presence.  I often find myself fighting the modern trend
for ever-harder-to-get-past TLS warnings in web browsers.  Those
warnings and the associated hard-to-penetrate UI, which I am pretty
sure you support, are a marvellous example of the kind of thing which
can harm rather than improve security.  Making more things fail,
rather than work in a less-secure way, is often not an improvement.

The biggest threats to the security of our users are not sophisticated
attacks on elderly and half-broken cryptoalgorithms.  The biggest
threat is bugs.  After that comes the many failures to deploy _any_
security technology, because so much of it is hard to use, or to
manage and deploy.  Why is the whole world still using unencrypted
unauthenticated email ?

Now, where upstream have a bad set of defaults, I am totally in favour
of changing that in Debian.  That's not specific to security
questions.  But if we are going to change what upstream did, we should
be sure to know why the upstream package is the way that it is.  We
need to be aware of the security/compatibility tradeoffs - and often
it will be necessary to pick more compatibility over more security.

Ian.

PS: Here's an argument from my own authority: I have a PhD in computer
security; I worked fr many years in the computer security industry; I
have implemented cryptoalgorithms, protocols, and a great deal of
crypto-using application and security software.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21567.9773.962310.657...@chiark.greenend.org.uk

Re: Bug#765512: general: distrust old crypto algos and protocols perdefault

[Russ Allbery]

Christoph Anton Mitterer  writes:

> So what's wrong about my approach, apart from the paradigm "security
> first"?

It feels to me like you're spending lots of time telling other people
they're wrong and telling other people what they should be spending time
on, and then arguing with anyone who tells you that how you're going about
this isn't effective.  I find myself feeling frustrated and demoralized
rather than inspired to go do a bunch of work on something that you care
about.  That energy would be better put into making an actionable plan for
accomplishing something and then inviting people to help you make that
plan reality.

Your response to this message is another good example.  I pointed out that
everyone knows that RC4 needs to go away and that the Kerberos upstreams
have long-term plans for how to do that with a reasonable level of
disruption, and your response was paragraphs about how horrible RC4 is.
One, you're preaching to the choir, and two, I don't understand what
you're trying to accomplish by haranguing me about this.  You seem to have
entirely missed the point I was trying to get across, which is that many
upstreams are closely monitoring these issues and have a plan already,
and, when that's the case, their plan is probably better than something
Debian would come up with for their software.  (As Brian points out, this
isn't always the case, but that was partly Joey's point: we need to look
at whether upstream is engaged and has a plan, or whether they're ignoring
the problem or unaware.)

If you think upstream's plan is wrong, then you need to go argue with
*them* about that, not with us, unless upstream is *so* wrong that it
looks like we should just fork.  For good upstreams, such as the Kerberos
upstreams, they generally have crypto expertise in their team already and
can have a detailed discussion with you about exact threat models and
timelines for deprecating enctypes.  When that sort of expertise exists
upstream, I'm arguing that this is not the effective place to do
something.  Diverging from upstream has a rather significant cost,
particularly if we diverge from upstream and then *get it wrong*, which is
not outside the realm of possibility.

And then you go on to put words in my mouth, like this:

>> If we were making a security-hardened distribution that chooses
>> security over interoperability across the board, we may well want to
>> make other decisions.

> So you suggest against efforts of securing / hardening Debian? What
> about introduction of hardened compiler flags, apparmor, selinux, etc.?

> I personally don't think that hardening contradicts being a universal
> OS.

which is just frustrating.  I feel like you're turning my opinion into a
parody of what I said to make it easier to argue with.

Of course doing those sorts of things is consistent with being a universal
operating system.  But you'll notice that Debian did hardening roughly
around the same time (or even a bit later) than other major distributions,
which was nowhere near as fast as some of the security-focused
distributions did it.  And I'd love to have a solid and reliable SELinux
setup that we could just turn on, but *everyone* in the Linux distribution
space has found that extremely difficult to achieve.  My point is not
"don't do security stuff."  My point is "Debian is not going to be on the
cutting edge of disabling features in the name of security."

In other words, if your primary concern is security, Debian is always
going to be a little slow for you.  I don't think that's a problem, nor
does it imply that Debian should *never* push on security.  Just that
Debian is not a distribution that values security *above everything else*.
There are some distributions out there, including Debian derivatives, that
*do* take that approach, and I think that's very valuable for seeing just
how far one can push security measures and how much breaks.

Anyway, I'm afraid that this whole thread is going to be a waste of time,
so I'm going to stop responding here.  I just hate to see people wasting
their time writing long replies to threads like this that are going to go
nowhere because there's not an effective structure for accomplishing
anything, which is why I (and several other people here) are trying to
nudge you in the direction of something more productive and more likely to
succeed.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87d29sby0g@hope.eyrie.org

Re: Bug#765512: general: distrust old crypto algos and protocols perdefault

[Christoph Anton Mitterer]

On Wed, 2014-10-15 at 23:44 +, brian m. carlson wrote: 
> HIGH:MEDIUM:!aNULL is a better default.
Still allows quite a number of combinations I probably wouldn't want to
entrust my data: RC4 stuff, DSS stuff, even some MD5 combination is in
the list.



smime.p7s
Description: S/MIME cryptographic signature

Re: Bug#765512: general: distrust old crypto algos and protocols perdefault

[Christoph Anton Mitterer]

On Thu, 2014-10-16 at 10:55 +1100, Brian May wrote: 
> What about security updates? Should Debian be releasing wheezy
> security updates for browsers,  web servers, etc, that disable SSLv3
> by default now that SSLv3 is considered insecure?
I'd guess that as soon as the respective vendor issues an update, the
security team from Debian will as usual be amongst the fastest to deploy
it :-)

My thread/bug though was more about how to deal with upstreams which
typically react too slow (well at least in my opinion :) ), and how to
keep track and deal with those, for which it's unknown whether upstream
takes an eye on crypto developments at all (e.g. the small libraries and
Perl/Python/etc. modules coming to my mind).


Cheers,
Chris. 


smime.p7s
Description: S/MIME cryptographic signature

Re: Bug#765512: general: distrust old crypto algos and protocols perdefault

[Christoph Anton Mitterer]

On Wed, 2014-10-15 at 13:58 -0700, Russ Allbery wrote: 
> The approach that you are taking to this discussion is destroying my
> desire and willingness to explain to you all of the nuance that you're
> ignoring.
Well I respect that you have another opinion on security, but I didn't
demand you to explain it to me (if you, as you say, don't like my
approach); admittedly I don't understand your security philosophy.

So what's wrong about my approach, apart from the paradigm "security
first"?

> your view of RC4 is simplistic, and is
> ignoring the fact that Kerberos uses RC4 considerably differently than how
> SSL does.  Many of the SSL attacks on RC4 rely on the properties of HTTPS
> and the nature of the data being encrypted, whereas Kerberos uses RC4 in a
> much different mode.  There's a lot of discussion in the crypto community
> about to what extent the same techniques carry over.
Sure, and the same is true for other algorithms or modes,... e.g. CBC
isn't unsafe per se.
But I guess you wouldn't call RC4 rock solid, would you? Well at least
all crypto folks and paper I know say something in the range from "don't
use it unless you really must" to "stop using it. now."

Of course it depends on how something is used, but I remember some time
ago, when the first attacks in SSL/TLS where found against CBC and the
padding issues, where people said "well, we all know it has it's issues,
but for SSL/TLS it's okay for now". How long did that hold?

And I don't think, that you really believe that this won't happen for
RC4 in other contexts, do you? And can you assure that the publicly
known cryptanalysis (which, as you say, may tell that RC4 is still okay
for krb) is having the last word? Who guarantees that there aren't any
organisations which can already easily break RC4 in the context of krb?

Of course one can always say "the NSA might already know how to break
it" but in case of RC4 we know about enough cracks that one can really
see that it's broken or that this point is at least knocking on the
door.


> Disabling RC4 enctypes breaks interoperability with all Windows XP
> systems.
Which is basically known to be coming to it's end of life for how many
years now... and in the meantime it's fully out of maintenance.

To be honest, I see no reason why to provide interoperability to an
insecure system, which users have known for years that the should act.
I rather feel that all other users, who did their homework or who aren't
using Windows or other incompatible clients at all, have to potentially
suffer from questionable defaults.

I understand you see this different, but I guess I may also have my own
opinion.


> That's clearly going to be the right thing to do soon
I just think it's a big problem if we always wait to the last minute.
That's what I've said in the initial post, that we rather should try to
move on to new algorithms proactively, even if there is not yet strict
need.

Moving onwards earlier is definitely better for security, even if you
have systems that use PFS. Because as practise shows, some people always
need very log to update their stuff, so not starting the migration in
the last minute is surely not the worst idea ever.


> and both
> MIT and Heimdal have future plans to do this, which they're coordinating
> with support cycles and feedback from large sites.
Well especially large sites should have probably had some people dealing
with security, which should have educated themselves about what they
should rather try to phase out.
So again I don't see the point why other users should potentially suffer
for some group being slow.
It's the same as with SSLv3 which was basically kept alive for some
years now just because of a minority still using a long dead browser -
and even if it would have been a large fraction, I still think it wasn't
fair for the others to live with it just because of those wo didn't move
on.

And as you mention large sites... at least sometimes I experienced
exactly the contrary.
I work for the LHC Computing Grid which is probably one (if not the) of
the largest distributed computing networks in the world... hundreds of
computing centres in a three Tier level hierarchy spread over all the
world with many thousands of scientists using its services and depending
on them for their work, thesises, etc..

As you said, often things go extremely slowly, but this also changes
completely if there is enough pressure or someone in charge simply says
"this is going to be done now, and all sites that don't comply are going
to be blacklisted".
Then new versions and even bigger changes are rolled out or activated in
few weeks or even days.



> It's unlikely that you're going to be able to make better cost/benefit
> decisions about these things than well-informed upstreams for general use
> cases.  Debian is targeted for general use cases.
Well as I've said several times before: I never said you should make it
impossible for people to use their older algorithms, if they need.
So what'

Re: Bug#765512: general: distrust old crypto algos and protocols perdefault

[Brian May]

On 16 October 2014 10:44, brian m. carlson 
wrote:

> Unfortunately, not all upstreams make good decisions.  OpenSSL ships
> with a set of default ciphers that is completely insecure.  There is no
> reason that every application using OpenSSL directly or indirectly[0]
> should have to disable exportable ciphers, especially since almost
> nobody uses them (nor wants to).  HIGH:MEDIUM:!aNULL is a better
> default.
>

What about security updates? Should Debian be releasing wheezy security
updates for browsers,  web servers, etc, that disable SSLv3 by default now
that SSLv3 is considered insecure?
-- 
Brian May 

Re: Bug#765512: general: distrust old crypto algos and protocols perdefault

[brian m. carlson]

On Wed, Oct 15, 2014 at 01:58:34PM -0700, Russ Allbery wrote:
> It's unlikely that you're going to be able to make better cost/benefit
> decisions about these things than well-informed upstreams for general use
> cases.  Debian is targeted for general use cases.  If we were making a
> security-hardened distribution that chooses security over interoperability
> across the board, we may well want to make other decisions.

Unfortunately, not all upstreams make good decisions.  OpenSSL ships
with a set of default ciphers that is completely insecure.  There is no
reason that every application using OpenSSL directly or indirectly[0]
should have to disable exportable ciphers, especially since almost
nobody uses them (nor wants to).  HIGH:MEDIUM:!aNULL is a better
default.

It's fine to defer to upstream where they have a history of good,
prudent decision making, but there are upstreams where that's clearly
not the case, and Debian should step in and ship software that doesn't
have security holes by default.

[0] Including virtually every Ruby script that uses HTTPS.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Bug#765512: general: distrust old crypto algos and protocols perdefault

[brian m. carlson]

On Wed, Oct 15, 2014 at 11:47:07PM +0100, Ian Jackson wrote:
> Joey Hess writes ("Bug#765512: general: distrust old crypto algos and 
> protocols perdefault"):
> > Instead, it makes sense to adapt workflows that do not trust git hashes,
> > which mostly means making signed tags and commits, and checking the
> > signatures. This is something Debian could improve in many areas, I'm
> > sure.
> 
> The whole git content-addressable-object-store model relies utterly on
> the hashes.  A signed tag is a (weirdly formatted) GPG-signed text
> file (the tag) containing the sha1 hash of a text file (the commit)
> containing the sha1 hash of a binary file (the tree object) containing
> the sha1 hasshes of the actual files at the top level and of further
> binary files (tree objects) containing further sha1 hashes of further
> files and further tree objects.  All of these hashes are translated
> into their preimiages by looking them up in the object store.

I've expressed interest in the past for changing the hash algorithm in
Git, but the work to do so is significant.  It basically means
converting every place that has a hardcoded "unsigned char[20]" and
moving it to a struct (later, a union) that can be treated more or less
opaquely.

If someone is interested in working with me on this, please let me know
off-list, and I can provide more information about this.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Bug#765512: general: distrust old crypto algos and protocols perdefault

[Russ Allbery]

Christoph Anton Mitterer  writes:
> On Wed, 2014-10-15 at 12:55 -0700, Russ Allbery wrote:

>> For another example, upstream for both Heimdal and MIT Kerberos know
>> very well what the situation is with the RC4 use in the Kerberos
>> protocol and are making well-informed decisions based on compatibility
>> with existing clients

> Okay what does that mean? AFAIU it means: well there are still so many
> people with outdated software out there, we can't just disable RC4, even
> if it's broken.

> I see it a bit differently:
> RC4 is broken. Full stop.
> Therefore new versions clients and servers should per default not
> use/enable/accept it.

> Of course Russ is right, that this would cause interoperability
> issues,... but IMHO that should be manually decided by the admins/users.
> If an kerberos admin says "well I still want/need to provide/trust RC4"
> he should manually need to enable in the configs.  Same for a
> user/client, the other way round.

> So I'm not saying that old broken/algos should be thrown out
> completely[1] - they should just not come into use without user/admin
> intervention.

The approach that you are taking to this discussion is destroying my
desire and willingness to explain to you all of the nuance that you're
ignoring.  But, to try anyway: your view of RC4 is simplistic, and is
ignoring the fact that Kerberos uses RC4 considerably differently than how
SSL does.  Many of the SSL attacks on RC4 rely on the properties of HTTPS
and the nature of the data being encrypted, whereas Kerberos uses RC4 in a
much different mode.  There's a lot of discussion in the crypto community
about to what extent the same techniques carry over.

Disabling RC4 enctypes breaks interoperability with all Windows XP
systems.  That's clearly going to be the right thing to do soon, and both
MIT and Heimdal have future plans to do this, which they're coordinating
with support cycles and feedback from large sites.

It's unlikely that you're going to be able to make better cost/benefit
decisions about these things than well-informed upstreams for general use
cases.  Debian is targeted for general use cases.  If we were making a
security-hardened distribution that chooses security over interoperability
across the board, we may well want to make other decisions.

Security is not an end in and of itself.  People want to use their
computers to do things, not to just be secure.  Security is always a
tradeoff.  This is inherent in the nature of the work.  Different people
are going to want to make that tradeoff in different ways.  Debian can
help push the tradeoffs towards more secure software, but if we go too far
and just break things, people are going to re-enable insecure stuff and
not trust our defaults in the future.  That, in turn, can easily mean that
the deployed systems in the wild end up being *less* secure than if we
maintain users' trust in the defaults.  Debian, as a very large and
widely-used distribution, is necessarily going to be more conservative
than small and security-focused distributions whose users are much more
tolerant of aggressive decisions that break backward compatibility.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87r3y9aw3p@hope.eyrie.org

Re: Bug#765512: general: distrust old crypto algos and protocols perdefault

[Christoph Anton Mitterer]

On Wed, 2014-10-15 at 21:55 +0200, Jonas Meurer wrote: 
> While I appreciate your efforts to raise security-relevant topics within
> the Debian distribution, I have to admit that exactly the same happens
> to quite a few of your "meta-bugreports" as well. There's a lot of
> discussion and a few changes here and there, but then the bugreport is
> forgotten and nobody cares anymore.
Sure, Jonas, I know,... and basically nothing has changed,... or well
not much at least... and the same with the discussion about secure APT,
downgrade/blocking attacks, the stuff about package downloaders, etc..


I mean that's just the problem what I try to explain every time
again,... it won't just work if you have some lone knights trying to do
this on their own, given the vast number of packages and software
affected, it's rather something a larger group would need to do.
Or even better, having guidelines, set up by such expert group, and
maintainers of packages should need to check through them... just like
proper auditing works.

But here comes the difficult part:
It's usually not easy to get people into a security conscious thinking,
so one won't find many people fighting this quest along one's side.
In practise it's even worse,... not rarely you have to fight maintainers
like windmills, endless discussions about what can be considered enough
secure, or whether it's more important to have stuff just being
colourful™ and working out-of-the-box™, rather then secure.

And these are only the problem's to the point, when you may break
peoples' setups which actually should break, because they're highly
insecure.
That's just as with the SSLv3 thingy... Mozilla for sure would argue
"well we had to keep it that long for interoperability".

When you then come to actual technical issues, as there *may* be with my
request to considerably shorten the validity times for Release files...
it's even more difficult to get something going.
Of course the respective developers have their own projects they want to
follow, but of course it should also be clear that one single person
(like me) cannot easily get fully involved in dozens of complex projects
like APT (and the security stuff - at least when one wants to do it
right - usually requires deep knowledge).


So you're absolutely right, when you say that not much comes out,... but
I guess for a single person it's not easily possible to do more than
constantly pointing at such issues, trying to start organising efforts
and then helping along.


> If you feel like keeping track of those distro-wide changes, I think a
> properly maintained wiki page is much more appropriate for that purpose.
Well I had that once[0] ... but the problems above remains,... if there
aren't more people that jump on the train - especially the affected
maintainers - you drive into a dead end


> In most cases your claim is true, but in some cases there might be
> reasons for keeping support for old/broken algorithms.
And as I wrote, I fully agree,... I mean this is basically what Russ
said in the other post:

On Wed, 2014-10-15 at 12:55 -0700, Russ Allbery wrote:
>For another example, upstream for both Heimdal and MIT Kerberos know
>very well what the situation is with the RC4 use in the Kerberos
>protocol and are making well-informed decisions based on compatibility
>with existing clients

Okay what does that mean? AFAIU it means: well there are still so many
people with outdated software out there, we can't just disable RC4, even
if it's broken.

I see it a bit differently:
RC4 is broken. Full stop.
Therefore new versions clients and servers should per default not
use/enable/accept it.

Of course Russ is right, that this would cause interoperability
issues,... but IMHO that should be manually decided by the admins/users.
If an kerberos admin says "well I still want/need to provide/trust RC4"
he should manually need to enable in the configs.
Same for a user/client, the other way round.


So I'm not saying that old broken/algos should be thrown out
completely[1] - they should just not come into use without user/admin
intervention.


> I suggest to file
> individual bugreports against particular packages, ideally already with
> suggestions/patches on how to fix them.
Mhh... nah I don't agree here. Discussing that with every package
maintainer is actually what makes it impossible to ever finish... I
rather think there should be project wide guidelines how to deal with
such questions.
Nothing that needs to be cut in stone and where one cannot make
exceptions in valid cases.

If there was consensus on how we actually want to handle security (here
in the sense of cryto strength: strong, medium, weak, none) then it
makes sense to move to the next step an actually implement it.


But as we've just seen... people's views already differ too much here to
have a staring point: One says interoperability is important and one
musn't break working systems just for security... another one like me
says rather break stuff (and let pe

Re: Bug#765512: general: distrust old crypto algos and protocols perdefault

[Jonathan Dowland]

On Wed, Oct 15, 2014 at 09:44:43PM +0200, Christoph Anton Mitterer wrote:
> Well a bug is at least something, where one has a central log of all
> discussions... and where one can really keep track of...

Only if people remember to copy it. And that's less likely to happen
when you start getting down to the nitty-gritty of changes to actual
packages. Those discussions are more likely to happen on more specific
bugs. It's also a lousy way of keeping track of the current state of
affairs. Just consider the recent mammoth tech-ctte bugs. It must have
been a herculean effort for the tech-ctte to keep track of what had
been considered and what had not. A wiki page would be a much better
way of keeping a summary in place. Something like

https://wiki.debian.org/ReproducibleBuilds

or

https://wiki.debian.org/DebianEdu/Status/Jessie

for good examples.

> The problem with release goals / DEP is, that there is a lot of talking
> but in the end nothing might really happen.

The DEP process, at least, has had some thought put into the design to
address that issue.

> Also, I think that supporting broken algorithms actually *is* a bug :)

Well, it's a meta-bug, of sorts; really it isn't a bug itself. There are
others, that could be theoretically filed and blocking information between
this one and those filed in the BTS. Without that, how would you otherwise
consider when this bug is "fixed"? You can't really leverage the excellent
versioning features of the BTS with the general package.

Another problem with the "general" package is, who is responsible? Are you
prepared to take responsibility to close this bug yourself? If it isn't a
release goal, there's no push to have it resolved in any particular time
frame. It could languish forever.

-- 
Jonathan Dowland


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141015203321.gb1...@chew.redmars.org

Re: Bug#765512: general: distrust old crypto algos and protocols perdefault

[Jonas Meurer]

Hey,

Am 15.10.2014 um 21:44 schrieb Christoph Anton Mitterer:
> On Wed, 2014-10-15 at 20:25 +0100, Jonathan Dowland wrote: 
>> There are a number of mechanisms for proposing and tracking distro-wide
>> changes, such as release goals and DEPs in some cases. But this is not what 
>> the
>> general bug is for. Please choose something and then kindly close this bug.
> Well a bug is at least something, where one has a central log of all
> discussions... and where one can really keep track of...
> 
> The problem with release goals / DEP is, that there is a lot of talking
> but in the end nothing might really happen.

While I appreciate your efforts to raise security-relevant topics within
the Debian distribution, I have to admit that exactly the same happens
to quite a few of your "meta-bugreports" as well. There's a lot of
discussion and a few changes here and there, but then the bugreport is
forgotten and nobody cares anymore.

If you feel like keeping track of those distro-wide changes, I think a
properly maintained wiki page is much more appropriate for that purpose.

> Also, I think that supporting broken algorithms actually *is* a bug :)

In most cases your claim is true, but in some cases there might be
reasons for keeping support for old/broken algorithms. General
statements like that one don't help too much. Instead, I suggest to file
individual bugreports against particular packages, ideally already with
suggestions/patches on how to fix them.

Cheers,
 jonas



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/543ed14d.1020...@freesources.org

Re: Bug#765512: general: distrust old crypto algos and protocols perdefault

[Russ Allbery]

Joey Hess  writes:

> In general, I think that Debian needs to identify upstreams that are
> being proactive about dropping old crypto algos, and those that are not.
> Major browsers, openssh upstream, etc are going to be more on top of
> this than we are, and make better decisions. Web servers probably have
> user pressure to keep old crypto available, in order to support broken
> clients that some users care about, and Debian might be able to improve
> the defaults in such cases.

+1.  This exactly.

For another example, upstream for both Heimdal and MIT Kerberos know very
well what the situation is with the RC4 use in the Kerberos protocol and
are making well-informed decisions based on compatibility with existing
clients, just as they did with DES (which is now disabled by default in
both and likely to be removed entirely in the near future).  I don't think
we're likely to add a lot of value by trying to jump into that process.

Where Debian may be able to help more is with the long tail of software
that doesn't have as active or involved upstreams and may not be tracking
this issue as closely as we are.  And, of course, making sure that our
compilation and configuration defaults are as secure as possible.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87vbnlaz0r@hope.eyrie.org

Re: Bug#765512: general: distrust old crypto algos and protocols perdefault

[Christoph Anton Mitterer]

On Wed, 2014-10-15 at 20:25 +0100, Jonathan Dowland wrote: 
> There are a number of mechanisms for proposing and tracking distro-wide
> changes, such as release goals and DEPs in some cases. But this is not what 
> the
> general bug is for. Please choose something and then kindly close this bug.
Well a bug is at least something, where one has a central log of all
discussions... and where one can really keep track of...

The problem with release goals / DEP is, that there is a lot of talking
but in the end nothing might really happen.

Also, I think that supporting broken algorithms actually *is* a bug :)


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: Bug#765512: general: distrust old crypto algos and protocols perdefault

[Jonathan Dowland]

There are a number of mechanisms for proposing and tracking distro-wide
changes, such as release goals and DEPs in some cases. But this is not what the
general bug is for. Please choose something and then kindly close this bug.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141015192521.gb...@chew.redmars.org