On Mon, Jul 20, 2015 at 04:48:49AM +0000, Viktor Dukhovni wrote:

> Section 2.9:
> 
>     [...]
>     
> [ Have to stop here for now, have not read the rest yet. ]

Continuing with material that follows after 2.9:

Section 3.1 first paragraph:

    The sentence:

       It seems like the ability to use an algorithm of one's own
       choosing is very desirable; however, the selection is often
       better left to experts.

    is rather imprecise.  I would suggest something more concrete:

	Explicit selection of concrete cryptographic algorithms
	should generally not be left to end-users.  Rather, end-users
	might select between configuration profiles defined by
	experts.

    The next sentence is too confusing to suggest improvements:

	  Further, any and all cryptographic algorithm choices
	  ought not be available in every implementation.

    The rest of the first paragraph:

	s/that it has/that has/
	s/has alway had/has always had/

    The last sentence of the same paragraph:

	In addition, inclusion of too many alternatives may add
	complexity to algorithm selection or negotiation.

    might be better as:

	Finally, standardization of too many alternatives will
	likely hamper security and interoperability.  When
	standardizing new algorithms it is prudent to consider what
	existing algorithms need to deprecated to make room for
	the new.

    [ For example, I'd like to see deprecation of many legacy DNSSEC
      algorithm code points, once new code points appear based on
      CRFG's new curves. (Of the existing algorithms, I'd keep only
      RSASHA256(8) and ECDSAP256SHA256(13)). ]

Last paragraph of 3.1:

	s/Sometime/Sometimes/
	s/depending of/depending on/

Last paragraph of 3.4:
	
	s/roll out/roll-out/  (the first is the verb, the second the noun).

Section 3.4:

    Amen for disabled by default "national" algorithms.  It would
    be nice to explicitly see this recommendation for GOST in DNSSEC,
    SEED in TLS, ...

Section 4:

       Sometimes application layer protocols can make use of transport layer
       security protocols, such as TLS [RFC5246] or DTLS [RFC6347].  This
       insulates the application layer protocol from the details of
       cryptography, but it is likely to still be necessary to handle the
       transition from unprotected traffic to protected traffic in the
       application layer protocol.  In addition, the application layer
       protocol may need to handle the downgrade from encrypted
       communication to plaintext communication.

    What's the relevance of a possible transition from cleartext
    to encryption (and perhaps back again???).

Overall:

    I found the document to be too "hand-wavy".  I think that it
    could be shorter by leaving out more text where no specific
    recommendations are or can be made.

    The wording could use a lot more polish, my list of nits is
    far from comprehensive.

-- 
	Viktor.