>>>>> "Rainer" == Rainer Gerhards <[EMAIL PROTECTED]> writes:
Rainer> I now understand. But wouldn't it then make sense to
Rainer> create a separate document for it? I have the feeling that
Rainer> would focus us better than when the discussion is split
Rainer> among different places/documents. And if I understood Eric
Rainer> Hibbard right, we may even have a volunteer to put it
Rainer> together.
I'm not sure this needs to be in a document although documenting it is
certainly not harmful. It does need to be decided by the WG and the
WG does need to justify that decision.
The protocol document will naturally describe all the threats
(possibly by referring to 3164 for some of them) and will describe
which threats are handled by the mandatory to implement transport.
This can be split across documents as desired provided there is a
reference.
Rainer> Or would it be better to put all of this into -protocol's
Rainer> inside a RFC. My intension is to mandate in -transport-tls
Rainer> that the implementation MUST support anonymous and
Rainer> authenticated TLS (its even easy to do), but that it must
Rainer> be possible that that the operator decides which to
Rainer> use. Now that I have written this sentence, it probably is
Rainer> already the solution. -transport-tls mandates both as two
Rainer> separate modes. So either mode could be configured by the
Rainer> operator. Then, it's security considerations section could
Rainer> document the implications of mode selection.
You can certainly do this.
It's even a reasonable solution if:
1) The people who need integrity are willing to deploy some sort of
credential to the senders. (This is more or less given; without
it, I think you can prove no solution exists).
2) That credential is a valid TLS credential.
In particular note that TLS would not be useful in a Kerberos
environment,an environment where people had ssh public keys, etc.
So, from a theoretical standpoint, your proposed solution works. The
WG needs to consider whether it meets the needs of operators in
practice. If so, then that's a fine direction.
--Sam
_______________________________________________
Syslog mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/syslog
