Re: [Tcpcrypt] Initial questions

[ianG <[e-mail]>]

On 19/06/2014 19:35 pm, Joe Touch wrote:
> 
> 
> On 6/19/2014 11:23 AM, ianG wrote:
>> On 19/06/2014 18:55 pm, Joe Touch wrote:
> ...
>> When did TCP have this 'urgent decision' ?  If it happened several years
>> after 1996, then what you have is a forewarning that was ignored.  If it
>> was after 2004, well, no amount of warning will do, and algorithmic
>> agility is a crutch that should be stripped away in order to focus
>> attention.
> 
> 2004 was the first practical attack on MD5; the first draft of TCP-AO
> was 2007. It took another three years for the IETF sausage mill to
> generate a final result.
> 
> Given that TCP-AO was used mostly for router security, and nobody had
> reported a successful MD5-based attack in the wild, that's not bad IMO.


Right.  So it worked.  The reason it worked fine -- no attacks reported
until 2008 [0] -- was likely due to the lack of collision vulnerability
in a protocol.  There was no urgent decision, just useful caution.


> The primary problem with TCP MD5 was that it wasn't algorithm-agile.


That's to repeat your conclusion.  I'm asserting a different conclusion:
 the problem with the MD5 upgrade was a management one, not a real one.
 The maintenance of the protocol should have started the replacement
sometime before 2004.


> ...
>>> That's why TCP-AO included two 'must implement' algorithms from the
>>> start, and why it's important to do so here as well.
>>
>> I'd like to see some historical evidence of when this actually made a
>> difference?  Yes, we understand the idea.  But we now have 20 years of
>> experience in Internet protocols.  We have data.  What does the data say
>> about algorithmic agility, in the field?
> 
> You're arguing two points at the same time.
> 
> 1) use one algorithm
> 
>     I've already pointed out how that's dangerous; it prevents
>     pre-deploying a backup when a given algorithm is deprecated.


You've pointed out it is dangerous.  Can you provide historical evidence
for this claim?  We've debunked MD5 in TCP-AO.

If it never happened, can it be still called dangerous?

If there is one thing that actually we are quite good at, it is
selecting a single strong suite.  How about we concentrate on what
actually does go wrong, demonstrably, in protocols?

Complexity leads to failure in takeup, anyone?


> 2) don't have algorithm agility
> 
>     This is counter to your earlier post. If you consider
>     that any one algorithm won't last forever, then ultimately
>     we'll want a solution that can support different algorithms.


OK, we're agreed that life moves on.  As do security products.  Versions
upgrade.  Let's look at say SSL.  It has run from v1 - v2 - v3 - TLS 1.0
- 1.1 - 1.2 - 1.4.

At each of those changes, there are incompatibilities within.  In each
case, the client/server conversation has to negotiate which version the
other side is capable of talking, and (generally) prefer the latest.

In each version, there is a chance to move forward.  This chance to move
forward may be taken for:  protocol weaknesses, advances in the science,
features, speed increases, ... *and the cipher suite*.

Now look at the history of important fixes to SSL.  SSL v3 patch,
TLS/SNI, renegotiation bug, heartbleed, gotofail, debian random, etc.

In practice, we're replacing the in-place version because of other bugs,
and improvements, over time, faster than we're seeing any problem with
any of the well chosen algorithms.

So we may as well just do that:  have TLS v+1 ready to go.

Also note that automated upgrade is the way that everyone does stuff
these days, and it can easily move faster than our ability to roll out a
config change.

Anyone got any numbers on how long it takes Apple to upgrade 80% of
clients?  Can they beat the OODA loop of 3.5 years for SSL [1]?


> I don't like either of the above, but they're separate points.


Here's another one:  why do you care?

This is opportunistic encryption, anyway.  We get what we can for free.
 Why bother about the freak occurrence of an algorithm break when it can
be hit by MITM anyway?  When we're losing most of the marketplace to
slowness in install?

How are you going to tell people to switch, given that our problem space
is automatic operation, without people knowing?

Is there anyone here who feels that (say) ChaCha20/Poly1305 is at risk
of a sudden break?  Who doesn't feel safe in an opportunistic protocol
against mass surveillance unless there is a backup inside it?



iang


[0] http://wiki.cacert.org/Risk/History#MD5-Root
[1] http://financialcryptography.com/mt/archives/001210.html