I am with Peter on this one. I could imagine that we add a sentence to that effect, too, and I hope Hannes would like to contribute one?
On 11 December 2014 at 14:52, Peter Saint-Andre - &yet <[email protected]> wrote: > On 12/9/14, 3:36 AM, Hannes Tschofenig wrote: > > Just to explain you a bit more about the concern I have. I am worried >> that readers less involved in the IETF process (i.e., the audience I am >> dealing with) suddenly sees 4 recommendations for TLS/DTLS. They will >> get confused. >> >> They get info about MTI from the TLS spec, one from CoAP (if they use >> CoAP or some other application protocol), another one from the UTA BCP >> document, and yet another from the DTLS profile. >> > > If you implement CoAP, use what the CoAP spec says. > > If you implement XMPP, use what the XMPP spec says. > > If you implement IMAP, use what the IMAP spec says. > > Etc. > > For XMPP, we've written a spec that builds on the UTA BCP (and that > formally updates the core XMPP spec): > > https://datatracker.ietf.org/doc/draft-ietf-uta-xmpp/ > > We could have similar specs for CoAP, IMAP, etc. > > The UTA BCP basically says that this is the best we know at this time, in > general, all other things being equal. But all other things are not always > equal. If things are different for your application protocol, then write an > Internet-Draft. > > Unfortunately, most of the recommendations contradict each other. >> > > That's a strong claim. > > The >> underlying problem is that certain parts of the spec require changes >> over time while others do not. The MTI for ciphersuites seems to change >> somewhat frequently and issuing a new RFC ever time an old ciphersuite >> becomes out-dated seems to be a challenge. >> > > That's an exaggeration. We will keep this as up to date as we can. Step > one is to get a first version of the BCP out the door. > > (Of course, the UTA BCP nor >> the DTLS profile document aim to tackle that problem; just saying...) >> >> In any case, getting the embedded community to use standardized, >> off-the-shelf security protocols is an up-hill battle. Adding confusion >> isn't going to make it easier for us. >> > > It's unrealistic to expect one BCP to cover every particular application > protocol, every implementation limitation, every deployment scenario. We > have done the best we can based on everything we know about TLS in the most > common scenarios and application communities. If the folks in a particular > application community have needs that differ, they need to get organized > and figure out what's best for them. > > Hannes, I appreciate your concerns, but I don't see an actionable > suggestion for what needs to change other than "please remove the > contradictions and more clearly state that this doesn't apply to the > community I represent". If you can propose text, that would be appreciated. > > Peter > > -- > Peter Saint-Andre > CTO @ &yet > > https://andyet.com/ > > _______________________________________________ > Uta mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/uta >
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
