Re: draft-miller-secsh-umac-00.txt

[Simon Tatham <anakin%pobox.com@localhost>]

Damien Miller  <djm%mindrot.org@localhost> wrote:
> Attached is a draft for the use of Ted Krovetz' UMAC (RFC4418) as
> a SSH MAC. OpenSSH -current implements the umac-64 method described
> in the draft under the name "umac-64%openssh.com@localhost".

Since you don't specify what block cipher is used by your UMAC
methods, I presume it's AES-128, since RFC4418 says that's the
default if not otherwise explicitly stated.

So an obvious question is: is it sensible to mandate a fixed block
cipher, when UMAC helpfully provides flexibility in this area? Is
that flexibility not potentially an advantage? Have you considered
alternative options such as

 (a) calling it umac-64-aes128 and thereby leaving open an obvious
     avenue to introduce UMAC over other ciphers if necessary?

 (b) defining UMAC to use whatever block cipher is chosen by the
     normal key exchange process? (Though I suppose you'd at the
     very least have to introduce a special case to preserve MAC
     functionality when the kex process settles on the `none'
     cipher.)

I think that at the very least I'd be marginally more comfortable if
this draft specifically stated that the default AES-128 was in use.

I note in passing that UMAC might be less useful than HMAC in
crypto-hostile jurisdictions, since you can't implement it without
first implementing a block cipher and so literal-minded crypto laws
which forbid code which implements a block cipher might also forbid
UMAC while being not too unhappy with MDx- or SHA-based HMAC which
are only (in practice) used for integrity protection. Not that that
should be an argument against its _optional_ adoption, of course.
-- 
Simon Tatham         "You may call that a cheap shot.
<anakin%pobox.com@localhost>    I prefer to think of it as good value."