[Cryptography] From Nicaragua to Snowden - why no national standards should be considered in cryptosec

[Stephen Farrell]

On 28/02/16 14:18, ianG wrote:
> On 27/02/2016 17:04 pm, Stephen Farrell wrote:
> 
>>> For example, in Russia
>>> we have 4 algorithms of a digital signature, 2 of them are definitely
>>> deprecated
>>> but 2 others are required to be implemented. So smth like "National"
>>> (may
>>> be with
>>> mentioning the countries) will be ok and non-pejorative.
>>
>> There's that. But "national" is also no good as a label, as
>> AES is national and some national algs are less well vetted/known
>> than others.
> 
> 
> (
>    Just as an aside... Belgians designed the algorithm, the code was
> written by a Brazilian, the Java test rig was created by an Australian.
>  The Dutch in Anguilla did something too, can't quite recall what tho.
>  The other 4 contenders (or 29) were from many countries and spent a lot
> of time analysing the 5 leaders.  All 5 leaders were thought to be state
> of the art of the time.
> 
>    Seems non-national to me :)
> 
>    The Americans ran the comp and chose the winner.  The algorithm
> however is only mandated for US Government agencies, not for anyone
> else.  Unlike many other standards bodies that also mandate against
> industry.
> 
> Sure we know there are always going to be conspiracy theories, but
> frankly, the full NIST comp is as open as any other process we can
> invent.  Again, in SHA3.
> )

Well most important about AES is that it's an algorithm in
which we still seem to have confidence and that's widely
deployed and available for use.

However, it still is a national standard and hence a national
algorithm.

> But that's not an interesting point.  An interesting point is that
> labelling a bad process won't save it.

No, that's at best an interesting phrase, but pretty meaningless.

>> And there's also the set of algs that we think are ok, but are
>> not yet needed, e.g. codepoints associated with Curve448 might
>> not be needed right now, but might move to "good" status later.
>>
>> Deprecated also doesn't quite seem right for e.g. integer DH
>> where we might want to prefer ECDH even though integer DH is
>> still fine with sufficient length primes.
> 
> 
> Ya.  So the overall problem with consensus seeking is that everything
> must be considered, everyone must have a say.  As we can see on this
> thread and in every other bikeshed, the result is a grand unified theory
> of cryptopolitics, rather than ... a ciphersuite, which is what users need.
> 
> Anyone can bring a pander-request to the table, and lobby for it.  Crap
> or not.  Anyone can bring a small RFC for no clear purpose, or a RNG
> that is pre-broken, or argue that an opponent isn't following the latest
> academic attack that is still warm from printing, or or or...

Conflating conspiracy and ineptitude and openness like that is
not IMO a useful way to consider issues. (Even when there are
real conspiracies like BULLRUN.)

> 
> Ontologising the inputs or outputs isn't going to help.

That one isn't even an interesting phrase, sorry:-)

> 
> There's no way around this.  If you're going to allow *everyone* a
> voice, then you'll end up with the pander-list.  Which is fine in
> ordinary commercial protocols like HTTP but not good in security
> protocols where we have known, aggressive, enemies that don't follow the
> laws of their land nor the laws of polite IETF society.  AKA the spooks.
>  Add countries to that.

My experience is that there are equivalently capable and highly
motivated folks involved in non-security, non-crypto controversies.
It is true that the spooks are funded with deception as a goal
though, which I agree makes a difference. However, the closest, and
actually very close, analogy here is patents - our best defences
against crap and sneaky patents are the same as our best defences
against BULLRUN, and all involve being more open.

> 
> The only alternatives I can think of are diktat of some form.  Of those,
> I prefer the following diktat:
> 
> One person of known history and pedigree is chosen to design the crypto
> suite.  That person does it.  That suite lasts for 7 years.  If it goes
> down in flames, so does that person's rep.  Sucks, but the incentive to
> take care is clear.

That's not something that'd work at Internet-scale.

The "benevolent dictator" open-source project is a smaller beast where
diktat can work fine, but it breaks down once a large enough set of
folks get seriously engaged.

>> And then (for TLS) there's stuff like SRP where almost nobody
>> cares and we might not want that code in general libraries so
>> maybe that's also better not in the "good" category too.
> 
> 
> If nobody cares, then do an experiment?  

No experiment is needed for SRP. We know the properties of PAKEs
in general and TLS-SRP BTW is documented in RFC5054 from 2007 so
any experiments needed have happened I'd guess. The result is that
almost nobody cares.

> This is why I consistently
> argued in TCPINC that David Mazieres' group should do it. The whole lot.
>  The notion of starting a competition between 2 opposing designs has the
> unfortunate consequence of handing the NSA another 2-4 years grace in
> mass surveillance.

That sentence seems backwards. I guess you mean that by running an
open process we handed NSA two more years by arsing around not really
picking between tcpcrypt and the folks who'd like to re-use TLS for
tcpinc. That's a fair criticism. OTOH, I think that cost (being open)
is one we are better off paying in the end regardless.

> 
> Nobody should care what the suite is in TCPINC because the stuff can be
> MITM'd by definition.  I know that doesn't stop people reaching for the
> paintbrush, but we should hold the line on general security:  choosing
> any suite is good for TCPINC, choosing two suites is to misunderstand
> everything about the general nature of MITM, threat modelling, security.
> 
> ( for others:  TCPINC is the generic name for bootstrapping a
> lightweight opportunistic encryption protocol within TCP so the masses
> can get out from the yolk of permanent global mass surveillance. )
> 

I really like tcpinc but the above oversells it. It'll be a fantastic
thing for folks running TCP applications that can't use TLS and where
your kernel supports tcpinc and both sides enable that. (Later, if all
that works, it might end up as a really good new default, but that'll
be down the road some.)

> 
> ...
>> Anyway, in the IETF the TLS WG have agreed to try to figure this
>> out for TLS ciphersuites. They've not started that work yet, as
>> they're busy with TLS1.3 but the bikeshedding will happen there
>> in the not too distant future.
> 
> 
> TLS is a challenge which cannot be surmounted because the process is
> already too entrenched.  Granted.  No point in arguing about that.

Also fair. The nearly 400 TLS ciphersuites thing we've ended up with
is a joke. Adding an "is-crap" (or whatever) attribute to almost all
of those is an imperfect improvement that is well worth making.

Cheers,
S.

> 
> 
> 
> iang
> 
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3840 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20160228/b0a4f9ba/attachment.bin>