On Apr 26, 2010, at 10:24 PM, Rob Austein wrote:
I'm writing to propose that we remove all use and mention of TLS from the RPKI "up-down" protocol described in the (expired) draft draft-ietf-sidr-rescerts-provisioning.
I would like to second this.
Background: In June 2007 we had a team of security reviewers (Steve Bellovin, Steve Kent, and Russ Housley) examine the "up-down" protocol. At that time, they recommended that we run the entire protocol under TLS, so we did. In the three years since then, we've started running a testbed with a few friendly volunteers, trying to get some feel for how well the RPKi protocol (and my implementation of it) works. In practice, getting TLS configuration right has turned out to be enough of a problem
As one of the participants in the testbed, I'd like to chime in here -- getting the TLS config correct is really hard, and troubleshooting that various failure modes is seriously non-trivial.
that I asked the same team of security reviewers to take another look at the problem. Their conclusion this time was that TLS is not really buying us anything we don't (or can't) get from CMS. Given this, it seems clear (to me, anyway) that using both TLS and CMS is over-engineering for this protocol, and since CMS is both better suited for the way this protocol works and also easier to get configured correctly, I think we should drop TLS. Note that this is less about TLS in the abstract than it is about TLS as used in the up-down protocol. There are protocols for which TLS is an appropriate tool, this protocol just happens not to be one of them. The basic problem is that we're dealing with a message-based client-server protocol that doesn't really have any concept of a session. The full protocol wrapping, for those who might not have it memorized, is TCP(TLS(HTTP(CMS(XML(up-down))))), that is: the protocol itself is expressed in XML, which we then sign with CMS and pass around via HTTPS POST commands and responses. CMS is well-suited for this, both because the message-based nature of the protocol means that an implementation already has the complete message in hand by the time it's trying to verify the CMS signature. We'd need to use CMS (or something enough like it as to make no difference) anyway, because one of the requirements for this protocol is that the messages be auditable at some future time; with CMS this is trivial, assuming we've preserved the necessary certificates, with TLS this can't be done at all once the TLS session has gone away. TLS, unlike CMS, has to be initiated before we ever see the complete message. This leads to all sorts of complications, whether or not one is using the TLS Server Name Indication extension. It is of course possible to overcome all of these complications, but the result, at least in the context of the up-down protocol, is fragile. As far as I have been able to determine, there are no existing large scale deployments of inter-organizational TLS using mandatory client certificates; most use of TLS is either without client certificates or is within a single organization. We're already making all the authorization decisions based on the results of checking the CMS message signatures, and pretty much have to do it that way (decision has to follow the auditable path), so TLS authentication doesn't buy us much either. As discussed at some length on this mailing list and in WG sessions, TLS as we're using it in this protocol does not protect us from replay attacks. We still need some form of replay protection, but I'll talk about that in a separate message; for the moment, suffice it to say that the presence or absence of TLS isn't likely to change the replay protection mechanism. As far as I know, the up-down protocol does not need confidentiality, but if it did, we could get it easily enough by enabling CMS encryption. I am -not- suggesting that we -should- use CMS encryption, I'd rather be able to debug operational problems, but if we need encryption, we can get it from CMS with the same keys and certificates we're already using. Any attacker who can DoS a server by generating a lot of bogus CMS messages can presumably also generate a lot of bogus TLS messages, so the DoS-prevention argument doesn't apply. If we were keeping long-lived TLS sessions around, we might get some benefit from TLS session caching, but we're not. Given that we're using HTTP, where the semantics of persistent connections were designed to avoid connection bursts rather than support sessions in the normal sense, we can't rely on sessions staying up even if we wanted them to do so. So, since TLS is not adding anything critical, and creates some operational issues, I propose that we remove TLS from the protocol.
+1. W
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
