On 2014-10-13 18:27, Stephen Farrell wrote:
> Stephen Farrell has entered the following ballot position for
> draft-ietf-uta-tls-attacks-04: Yes
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> http://datatracker.ietf.org/doc/draft-ietf-uta-tls-attacks/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>
> I have a number of nits. Please treat them as such.
>
These mostly seem ok to me (with my chair hat on) but lets see what the
authors say.
Cheers Leif
> - Is "current" correct in the name for an RFC? Perhaps
> "known" is better.
>
> - intro, para 2: s/is tasked/was tasked/
>
> - s2, 2nd para: "a more systemic solution" is left hanging
> - do you mean TLS1.3? If so, maybe say so?
>
> - 2.5, 2nd para: draft-ietf-tls-prohibiting-rc4 does not
> itself provide those details, maybe say "see the
> references in" that draft?
>
> - 2.6: should the RFC editor wait on the official
> allocation of the BEAST CVE number? I don't think that's
> happened already has it?
>
> - 2.7, is Bleichenbacher really a certificate attack? I
> think its not, but is a pkcs#1 encryption attack. (It
> would apply just as well to OOB keys in TLS.) I'm not sure
> if Klima is or is not the same in that respect. Also the
> timing attacks in the 2nd para, don't seem to be
> certificate related are they? So perhaps only the last
> para is really certificate related?
>
> - 2.8: I forget if this has been discussed - should three
> be a reference to draft-ietf-tls-negotiated-ff-dhe
>
> - 2.10: isn't TRIPLE-HS published yet?
>
> - 2.12: A reference would be good here if we have one,
> esp. for the "It is known" point.
>
> - 2.13, para1: "fully specified" isn't really correct
> there, I think you mean 'properly specified, so that
> implementations should be "secure"' but maybe some other
> wording would be better.
>
> - 2.13: Doesn't that paper also blame hard-to-use APIs as
> well as the IETF protocols and their complexity? Worth a
> mention?
>
>
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
