[Ach] A few more comments on the draft

[Aaron Zauner]

On 16 Dec 2013, at 10:44, Rainer Hoerbe <rainer at hoerbe.at> wrote:

> OpenSSL: While OpenSSL is widely deployed, it has a few ugly aspects, like poor error messages. In a side-note sysadmins could be encouraged not to ignore other options, e.g. NSS and cryptlib. More competition and flexibility in the cryptolib market should improve the quality over time.
> 
> 
> Message-oriented crypto (SOAP etc.) would fit into the scope, wouldn't it?  Recommendations should include:
> * Protection against XML Signature Wrapping Attacks (what you sign is what you see – often a developer concern, sometimes related to network components such as XML firewalls)
> * Use counter mode to fix broken XML encryption, e.g. in SAML configurations.
> 
> 
> In 10.1 there is a minor formal inconsistence in the definition of the MAC. The MAC-field contains the MAC algorithm, not the MAC. The the definition needs explanation, like adding following sentence:
> "The filed in the cipher string states the algorithm to compute the MAC."
> 
> 
> AES 128 is not considered a strong cipher? IMHO not including AES128 is not in a good balance with the typical RSA-2048 certificate, that is kind of 112-bit symmetric equivalent. I would recommend not only to include AES128 to better support embedded/low-power devices, but even give them priority over AES256.

This is a mistake in the document, our current B configuration has aes128 and camellia128 in them. I too think that aes128 is sufficient.

Aaron

> 
> 
> 10.3.2 /SSLv3. There is a slight inconsistency: The first bullet lists TLS 1.2, 1.1, 1.0, but not SSL3. The cipher string contains +SSLv3.
> BTW, which clients still do not support TLS1.0?
> 
> 
> 10.3.2 "allow SHA-1". The threat is primarily in using certificates signed using SHA-1. Many root CAs still use SHA-1, e.g. the popular Startssl. It should be made clear there are vastly different risks whether an adversary would have to attack SHA-1 in a TLS-session or on the certificate.
> 
> 
> 12.2 SSH key distribution.
> This would be a good place to warn people from using anonymous key exchange on the first access to a server. Sysadmins should act as if GCHQ would intercept any initial ssh connection to quickly root the target system.
> 
> 
> Best regards
> Rainer Hörbe
> 
> _______________________________________________
> Ach mailing list
> Ach at lists.cert.at
> http://lists.cert.at/cgi-bin/mailman/listinfo/ach

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1091 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.cert.at/pipermail/ach/attachments/20131216/840a1655/attachment.sig>