Hi Alissa, thanks for your feedback. Comments inline.
On 2/17/15 12:49 PM, Alissa Cooper wrote:
Alissa Cooper has entered the following ballot position for
draft-ietf-uta-tls-bcp-09: Discuss
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/
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
Thanks for all your work on this.
I have a quick question about how we expect this document to be used
within the IETF. I note that the bulk of the requirements/recommendations
are directed at implementers, not protocol designers/specs. And Section
4.2.1 also says:
"This document does not change the mandatory-to-implement TLS cipher
suite(s) prescribed by TLS or application protocols using TLS. ...
Implementers should consider the interoperability gain against the
loss in security when deploying that cipher suite. Other application
protocols specify other cipher suites as mandatory to implement
(MTI)."
So my question is whether we should consider this document effectively
silent about the choice of cipher suites to be used when we standardize a
new application protocol in the IETF, or an update to an existing
protocol.
If an application protocol wishes to follow the recommendations here,
someone needs to write a document that says so. As an example,
draft-ietf-uta-xmpp (recently finished WGLC) updates RFC 6120:
https://datatracker.ietf.org/doc/draft-ietf-uta-xmpp/
That is the impression that I get from the text right now, and
it doesn't quite match the way we've been using/citing the document in
some recent discussions of other drafts.
Do you have examples?
On the other hand, if we're
expecting new or updated application protocol specs to conform to or take
into account the recommendations in this document, I think that should be
made more clear.
Given that other folks have been confused on this point, I tend to agree.
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
-- Sec 4.1:
128-bit ciphers are expected to remain secure for at least several years,
and
256-bit ciphers "until the next fundamental technology
breakthrough".
Is the quoted text quoting something? If not, why is it in quotes?
To my knowledge, that is not a quote from another text, but I will
double-check with my co-authors. Conceptually it could refer to
something like a special-purpose "sieving machine" of the sort mentioned
in RFC 3766.
-- Sec 5:
Although the list here is non-exhaustive, it seems odd to me that no DTLS
examples are listed.
Good point. Mentioning, say, SRTP and SCTP seems like a good idea.
Peter
--
Peter Saint-Andre
https://andyet.com/
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
