Subject: [sidr] Proposal to remove use of TLS from RPKI provisioning ("up-down") protocol

From: Rob Austein <[email-masked]>
Date: Mon, 26 Apr 2010 22:24:33 -0400

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.

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 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.

---

From: Warren Kumari <[email-masked]>
Date: Tue, 27 Apr 2010 13:15:24 -0400

> draft-ietf-sidr-rescerts-provisioning.

I would like to second this.

> 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

+1.

W

> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: Seiichi Kawamura <[email-masked]>
Date: Wed, 28 Apr 2010 12:30:59 +0900

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

I'll admit that I'm one of the testbed participants that
stumbled over this.

Regards,
Seiichi

Warren Kumari wrote:
> 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

---

From: Terry Manderson <[email-masked]>
Date: Tue, 27 Apr 2010 21:22:56 -0700

> draft-ietf-sidr-rescerts-provisioning.

I second this given my observations from October last year
(http://www.ietf.org/mail-archive/web/sidr/current/msg01256.html) and your
operational trials.

However I'm not sure it should be dropped without providing (noting your
second email) a mechanism to mitigate replay and reorder attacks. Provided
that your timer approach deals with any known attacks and this is adopted as
a defined rule for acceptance of the request I'll happily acquiesce.

Cheers
Terry

---

From: Russ Housley <[email-masked]>
Date: Wed, 28 Apr 2010 03:56:51 -0400

> operational issues, I propose that we remove TLS from the protocol.

This seems quite reasonable to me.

Russ