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
