Re: Albrecht/Paterson/Watson's attack

["Mark D. Baushke" <mdb%juniper.net@localhost>]

Mouse <mouse%Rodents-Montreal.ORG@localhost> writes:

> Besides the obvious suggestions made in the paper (basically "don't
> use CBC bulk ciphers"), it occurs to me that there is another defense:
> make it hard to identify packet boundaries by, whenever the connection
> would otherwise go idle, generating an IGNORE packet and sending only
> part of it, holding the rest until something more is available to be
> sent on that connection.

Another alternative is to use an encrypt-then-mac approach.

http://tools.ietf.org/html/draft-gutmann-tls-encrypt-then-mac-05

which has a normative reference to:

    Krawczyk, H., "The Order of Encryption and Authentication
    for Protecting Communications (or: How Secure Is SSL?)",
    Springer-Verlag LNCS 2139, August 2001.

fwiw: I believe that OpenSSL extensions to KEX_DEFAULT_MAC do this:

	"hmac-md5-etm%openssh.com@localhost," \
	"hmac-sha1-etm%openssh.com@localhost," \
	"umac-64-etm%openssh.com@localhost," \
	"umac-128-etm%openssh.com@localhost," \
	"hmac-sha2-256-etm%openssh.com@localhost," \
	"hmac-sha2-512-etm%openssh.com@localhost," \
	"hmac-ripemd160-etm%openssh.com@localhost," \
	"hmac-sha1-96-etm%openssh.com@localhost," \
	"hmac-md5-96-etm%openssh.com@localhost," \

which seems to work for them. I don't know if we want to try to make the
-etm alternatives available as a part of the SSHv2 defined set of MACs.

	-- Mark