[Curdle] AD review of draft-ietf-curdle-cms-chacha20-poly1305-03

[Stephen Farrell <[e-mail]>]

Hiya,

My AD review of this draft is below. I think
a revised I-D is needed before IETF LC for at
least section 4, but please argue with me if
I'm wrong about that.

Cheers,
S.


(1) section 2: Is it correct to say that BCP107
is a MUST the way you do? I think you need to
say that implementations MUST support some
form(s) of AKM, but I don't think you can say
"MUST use" as I can't see how that could be
enforced at this level of the code.  If it
can't be enforced, then it's not worth the
MUST you have here.

(2) section 3: What does "content authenticated
encryption" mean exactly? You use that phrase
a lot, and I don't know what it means and it
does not occur in [CMS]. Do we need a better
term?  (Apologies if I'm forgetting the WG
discussing that.)

(3) section 4: this is clearly not ready for
publication - why not allocate the OID? But
you at least need to write the text or get rid
of the section.

(4) I hope I remember to add the downref to
the IETF LC:-)


nits...

- Is 1.1 really useful to have here? That text
is basically part of [1] which is what an
implementer would need to read anyway. So it
may be better to omit 1.1 and just point
at [1].

   [1] https://tools.ietf.org/html/rfc7539#section-2.8

- section 2: "...destroys the security
guarantees." That would be better with a
reference to some paper that describes the
issues.

- typo: "I can be extremely..."

- typo: "There is one algorithm identifiers..."

- section 3: I'm not clear what is done with
the "AuthEnvelopedData mac field" here.  Given
we've an AEAD, there's no real need for a
separate MAC, so I find the text confusing.
Can you explain?

- section 6: This says "When using
AEAD_CHACHA20_POLY1305, the resulting
ciphertext is always the same size as the
original plaintext. " What about the extra 128
bit authentication tag?