> > [...] > > However, I think a major problem in this case it that > > draft-ietf-uta-tls-bcp-02 isn't actually clear about its intended scope: > > what does "secure use" actually mean? As pointed out before, the document > > uses the term "completely insecure" in a very fuzzy (and wrong) way -- > > authentication and integrity assurance without confidentiality isn't > > "completely" insecure: it obviously won't give you confidentiality, but > > still achieves other security notions. > > > > "Securing application-layer protocols" versus "specialized purposes" > doesn't > > appear to be a very useful distinction for standardization purposes > > (*everything* that runs on top of TLS is an "application-layer > protocol", as > > far as TLS is concerned anyway), so I essentially agree to Uri -- this > looks > > like an attempt of ending up somewhere in between "MUST NOT" and "SHOULD > > NOT", and is not really acceptable. Also, those using integrity-only > cipher > > suites clearly *do* want to secure their application-layer protocols, > which > > takes us back to the problem about fuzzy "security" terminology in this > I-D. > > > > So shouldn't the BCP document clarify its scope by being explicit that > the > > recommendations only apply if your security goals do include > > confidentiality? In TLS 1.2, confidentiality very clearly is > > *intentionally* optional. If you create recommendations for its use and > > change this underlying assumption, you should be very clear about the > scope > > of your recommendations. > > > > Bodo >
2014-09-04 11:10 GMT+02:00 Yutaka OIWA <[email protected]>: > Dear Bodo, > > I agree, the most important point in my previous mail is > whether the document is applicable for all use cases. > Tracks and WG are not definitive regarding this. > Sorry for any uncleanness. > # The intention of me to include these words was > # just to guess the document's intentions. > > So, the most important point I think is that > we have a fairly broad range of "general use cases" > which need a common strong BCP for TLS configurations. > Current TLS 1.2 specification is too relaxed about this > (intentionally, to support other use cases as well). > > In other words, the UTA draft is actually defining a > secure restricted subset of TLS 1.2 (and 1.3+) for > some subclass of use cases, and intend to force > such restriction to "such use cases" on the Internet, > using a "MUST-NOT" requirement term. > > I think it's quite important to clarify in which class of > use cases UTA is intended to apply such a restriction. > Currently "general use cases" is not well-defined and > may misguide readers (including implementors) that > NULL ciphers are forbidden in ALL use cases of TLS 1.2. I agree, and I think what you're saying here is completely in line with what I said before -- quoted above again just because I'm sending this reply to the UTA mailing list rather than the TLS mailing list. Bodo
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
