On 2/17/15 5:48 PM, Kathleen Moriarty wrote:
Kathleen Moriarty has entered the following ballot position for
draft-ietf-uta-tls-bcp-09: 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-bcp/
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
Thanks for your work on this very helpful draft!
I just have a few comments/questions.
Section 5. Applicability statement:
Should this include application authors (mentioned in section 7.1) and
Developers who can set the defaults for implementations of TLS to help
operators that are mentioned in this applicability statement? I see the
sentence is phrased for 'deployment recommendations', but maybe this
should also have a sentence or two on development recommendations.
On re-reading Section 5 earlier today during discussion with Alissa, I
too felt that an exclusive focus on deployment by operators was a bit
off. Perhaps it would be better to begin Section 5 like so...
###
The recommendations of this document primarily apply to the
implementation and deployment of application protocols that are most
commonly used with TLS and DTLS on the Internet today. Examples
include, but are not limited to:
o Web software and services that wish to protect HTTP traffic with
TLS.
o Email software and services that wish to protect IMAP, POP3, or
SMTP traffic with TLS.
o Instant-messaging software and services that wish to protect XMPP
or IRC traffic with TLS.
o Realtime media software and services that wish to protect SRTP
traffic with DTLS.
###
Not for this draft, but this one raised a question for me.
Section 7.3: If you look at the following text:
Unfortunately, many TLS/DTLS cipher suites were defined that do not
feature forward secrecy, e.g., TLS_RSA_WITH_AES_256_CBC_SHA256. This
document therefore advocates strict use of forward-secrecy-only
ciphers.
Should we be thinking about updates to the TLS registry to reflect this
recommendation? That's probably not this draft, but a follow on to
provide the needed 'specification required'. I'm sure a lot more thought
might be needed for that and maybe support for features like PFS is added
in a table if older recommendations that don't meet this are not
removed.
http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml
That sounds like a worthy effort, but I'm not volunteering to work on it.
HTTPbis went to the trouble of creating a blacklist of cipher suites that
includes ones in the TLS registry. They did take the MTI recommendation
that is in this draft, which is good. See section 9.2 and appendix A.
https://datatracker.ietf.org/doc/draft-ietf-httpbis-http2/
Blacklists aren't always the best idea:
https://pbs.twimg.com/media/B9vc0OmCMAA19Ez.jpg
;-)
Peter
--
Peter Saint-Andre
https://andyet.com/
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
