[Fwd: Re: draft-dbider-sha2-mac-for-ssh-03]

[Jeffrey Hutzelman <jhutz%cmu.edu@localhost>]

-------- Forwarded Message --------
From: Jeffrey Hutzelman <jhutz%cmu.edu@localhost>
To: Mark D. Baushke <mdb%juniper.net@localhost>
Cc: jhutz%cmu.edu@localhost, Sean Turner <turners%ieca.com@localhost>, denis bider (Bitvise)
<ietf-ssh2%denisbider.com@localhost>, Stephen Hanna <shanna%juniper.net@localhost>
Subject: Re: draft-dbider-sha2-mac-for-ssh-03
Date: Mon, 23 Jan 2012 12:14:38 -0500

On Fri, 2012-01-20 at 12:35 -0500, Jeffrey Hutzelman wrote:
> "Mark D. Baushke" <mdb%juniper.net@localhost> wrote:
> 
> >fwiw: I have not yet seen the Shepherd write-up.
> >
> >If I have missed a step in the process which I need to do, please do
> >let
> >me know.
> >
> >	-- Mark
> 
> No; I've been lame, and then busy putting out fires.  I'll do something today.

I have a writeup ready to go, but I also have a few comments.  FWIW, the
work you did in -03 to get this ready for publication eliminated the
need for a fairly lengthy list of comments.  Thank you.

-- Jeff

Abstract:
  An abstract is not part of the document it describes, and must stand
  entirely on its own.  As such, it can mention other documents by name
  or RFC number when appropriate, but should not contain references.
  So, please remove the extra [RFC4253] at the end.

  Since this document updates RFC4253 by adding a new RECOMMENDED data
  integrity algorithm, the abstract must say so explicitly.  I suggest
  removing the second paragraph of the abstract and instead adding the
  following sentence to the first paragraph:

  "It also updates RFC4253 by specifying a new RECOMMENDED data
   integrity algorithm."

  Note that the complete list of algorithm names is kept in an IANA
  registry, and merely adding to that list does not constitute an update
  to RFC4253.  However, making one of those RECOMMENDED does.


Section 1:
  s/SSH [RFC4251]/Secure Shell (SSH) [RFC4251]/
  "SSH" must be expanded on first use; the expansion in the abstract
  doesn't count for the body of the document.

Section 2:
  Remind me why the truncated versions are still there?

Section 4:
  "The current attacks on HMAC-SHA1 do not yet seem to indicate a
   practical vulnerability when used as a message authentication code."

  I'm not sure what you're really trying to say here.  I think you're
  talking about current attacks on _SHA1_, not _HMAC-SHA1_, which are
  mitigated when SHA1 is used in an HMAC (though it is the construction,
  not the usage, that is relevant).  In any case, this document defines
  algorithm IDs for SHA2, not SHA1, so I'm not sure how this statement
  is relevant.

References:
  References to RFC2104 and FIPS-180-3 are both normative.