[Freeipa-devel] FreeIPA and modern requirements on certificates

[Petr Spacek]

On 8.1.2016 16:57, Christian Heimes wrote:
> On 2016-01-08 16:49, Petr Spacek wrote:
>> On 8.1.2016 13:56, Fraser Tweedale wrote:
>>> On Fri, Jan 08, 2016 at 01:26:57PM +0100, Martin Kosek wrote:
>>>>> Hi Fraser and other X.509 SMEs,
>>>>>
>>>>> I wanted to check with you on what we have or plan to have with respect to
>>>>> certificate/cipher strength in FreeIPA.
>>>>>
>>>>> When I visit the FreeIPA public demo for example, I usually see following
>>>>> errors with recent browsers:
>>>>>
>>>>> * Your connection to ipa.demo1.freeipa.org is encrypted using obsolete cypher
>>>>> suite.
>>>>>  - The connection uses TLS 1.2
>>>>>  - The connection is encrypted ising AES_128_CBC, with HMAC-SHA1 for message
>>>>> authentication and RSA as the key exchange mechanism
>>
>> HMAC-SHA1 reminded me recently published paper:
>> http://www.mitls.org/pages/attacks/SLOTH
>>
>> It claims that all MD5 and SHA1 uses should be eliminated if feasible.
> 
> MD5 and SHA-1 should no longer be used for signatures. MACs are a
> completely different story. HMAC-SHA1 and even HMAC-MD5 are still fine
> and believed to be secure.
> 
> https://en.wikipedia.org/wiki/Hash-based_message_authentication_code#Security


Christian, have you read the page (or even better the paper) I linked above?

The page starts with this:
> Introduction
> 
> In response to recent high-profile attacks that exploit hash function collisions, software vendors have started to phase out the use of MD5 and SHA1 in third-party digital signature applications such as X.509 certificates. However, weak hash functions continue to be used in various cryptographic constructions within mainstream protocols such as TLS, IKE, and SSH, because practitioners argue that their use in these protocols relies only on second preimage resistance, and hence is unaffected by collisions. We systematically investigate and debunk this argument.
> 
> We identify a new class of transcript collision attacks on popular cryptographic protocols such as TLS, IKE, and SSH, that significantly reduce their expected security. Our attacks rely on the use of obsolete hash constructions in these protocols. 


If you open the paper, it has this on the very first page:
[...]
> This leaves open the question of what to do about
> other uses of MD5 and SHA-1 in popular crypto-
> graphic protocols. Practitioners commonly believe that
> collisions only affect non-repudiable signatures (like
> certificates), but that signatures and MACs used within
> protocols are safe as long as they include unpredictable
> contents, such as nonces [16], [15].In these cases,
> protocol folklore says that a second preimage attack
> would be required to break these protocols, and such
> attacks are still considered hard, even for MD5.
> Conversely, theoretical cryptographers routinely as-
> sume collision-resistance in proofs of security for
> these protocols. For example, various recent proofs of
>
> TLS [17], [22], [11] assume collision-resistance even
> though the most popular hash functions used in TLS
> are MD5 and SHA-1. Whom shall we believe? Either it
> is the case that cryptographic proofs of these protocols
> are based on too-strong (i.e. false) assumptions that
> should be weakened, or that practitioners are wrong and
> collision resistance is required for protocol security.
> This paper seeks to clarify this situation by systemat-
> ically investigating the use of hash functions in the key
> exchanges underlying various versions of TLS, IPsec,
> and SSH. We demonstrate that, contrary to common
> belief, collisions can be used to break fundamental secu-
> rity guarantees of these protocols.


One thing I remember from my cryptography courses I had on university is that
I should not try to outsmart professional cryptographers when it comes to
assessing security properties :-D

Judging from this: Claims on the Wikipedia page are not sufficient guarantee
for me, sorry.

-- 
Petr^2 Spacek