<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: Response to GnuTLS in Exim Debate</title>
	<atom:link href="http://blog.josefsson.org/2007/11/09/response-to-gnutls-in-exim-debate/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.josefsson.org/2007/11/09/response-to-gnutls-in-exim-debate/</link>
	<description></description>
	<pubDate>Wed, 20 Aug 2008 14:23:58 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6</generator>
		<item>
		<title>By: Nikos Mavrogiannopoulos</title>
		<link>http://blog.josefsson.org/2007/11/09/response-to-gnutls-in-exim-debate/#comment-2387</link>
		<dc:creator>Nikos Mavrogiannopoulos</dc:creator>
		<pubDate>Sat, 10 Nov 2007 19:31:13 +0000</pubDate>
		<guid isPermaLink="false">http://blog.josefsson.org/2007/11/09/response-to-gnutls-in-exim-debate/#comment-2387</guid>
		<description>Nice post. I only have a comment concerning Bug #390712

&#62; Appears to be triggered by GnuTLS implementing MAC padding to solve a
&#62; security problem in TLS. OpenSSL reportedly does not implement the same
&#62; work around, and would thus appear to be vulnerable to that problem.
&#62;
&#62; Conclusion: Appears to be a ‘wontfix’ bug. Personally, I think GnuTLS could
&#62; provide a simpler mechanism to disable MAC padding if applications deem
&#62; this necessary. Someone could double check how important the MAC padding
&#62; security concern is.

This padding of TLS is not to work-around a TLS security problem. It is the CBC padding described in TLS 1.0 which protects TLS record packets against statistical analysis of data. I.e in ARCFOUR (stream) if you transmit 5 bytes, the encrypted data will be 5 bytes. In openssl CBC (which doesn't use this feature) if you transmit 5 bytes with AES it would output 16 encrypted data. In gnutls the encrypted output varies and can be any number between 16-255 (of course it would be a multiple blocks). 

So in that aspect gnutls is more secure than other alternatives in the sense that no eavesdropper can guess anything about the text by looking the size of the ciphertext. This is a standard TLS 1.0 and if a client cannot support this it is a buggy one.</description>
		<content:encoded><![CDATA[<p>Nice post. I only have a comment concerning Bug #390712</p>
<p>&gt; Appears to be triggered by GnuTLS implementing MAC padding to solve a<br />
&gt; security problem in TLS. OpenSSL reportedly does not implement the same<br />
&gt; work around, and would thus appear to be vulnerable to that problem.<br />
&gt;<br />
&gt; Conclusion: Appears to be a ‘wontfix’ bug. Personally, I think GnuTLS could<br />
&gt; provide a simpler mechanism to disable MAC padding if applications deem<br />
&gt; this necessary. Someone could double check how important the MAC padding<br />
&gt; security concern is.</p>
<p>This padding of TLS is not to work-around a TLS security problem. It is the CBC padding described in TLS 1.0 which protects TLS record packets against statistical analysis of data. I.e in ARCFOUR (stream) if you transmit 5 bytes, the encrypted data will be 5 bytes. In openssl CBC (which doesn&#8217;t use this feature) if you transmit 5 bytes with AES it would output 16 encrypted data. In gnutls the encrypted output varies and can be any number between 16-255 (of course it would be a multiple blocks). </p>
<p>So in that aspect gnutls is more secure than other alternatives in the sense that no eavesdropper can guess anything about the text by looking the size of the ciphertext. This is a standard TLS 1.0 and if a client cannot support this it is a buggy one.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
