-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi
> 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. I'll admit that I'm one of the testbed participants that stumbled over this. Regards, Seiichi Warren Kumari wrote: > > 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 > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkvXq/MACgkQcrhTYfxyMkIQdACghmQ2otCXnNUGhsiqW41I1lt9 qooAnjhtL+RQaQbeGQ4rNN/zxn1+w76h =k5sK -----END PGP SIGNATURE----- _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
