Resending Ralph's mail, with the correct draft name in the subject.
Thanks,
Yaron
On 09/03/2014 08:42 PM, Ralph Holz wrote:
Good day,
I have solicited some feedback on the wording in 4.1, the MUST NOT on
selecting the NULL cipher. I have feedback from members of the TLS WG,
and from operators of Grid centres. My fear was that MUST NOTing the
NULL cipher in the BCP may lead implementers to drop it entirely. I have
a suggested new wording, with a new note, that I think would resolve this:
"Deployments of TLS to secure application-layer protocols MUST NOT
negotiate the NULL cipher.
Note: TLS implementations MAY retain code for the NULL cipher to allow
specialised purposes like debugging, custom solutions, etc."
That will make it clear that implementers are free to retain NULL (and
they will), but that the purpose of the BCP is to propose secure TLS
configurations to protect application-layer protocols, and for those no
deployment should ever negotiate NULL.
As for the feedback - it seemed to be divided into two categories:
1) Kill off the NULL cipher for all deployments.
2) There are some use cases, do not forbid it in
a) implementations
b) deployments
The operators of Grid centres did have some very good use cases
concerning a) - namely European centres having dedicated authentication
mechanisms that rely on code in e.g. OpenSSL to provide exactly this
NULL cipher (but MAC-ed). I can forward their exact use case if there is
interest here. They did emphasise, however, that speed of encryption is
no longer a concern for them.
Concerning b), some people mentioned use cases like
* monitoring traffic in internal networks, especially in VPN settings
* IPC
* some other mechanisms that seem rarely used
I think implementations keeping NULL in code, but not enabling it for
deployments, is the way to go and addresses all uses cases in a) and b).
A note should be sufficient to make this clear.
Ralph
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
