[Rescert] Notes from RPKI security review

[Rob Austein <sra@hactrn.net>]

Notes from the RPKI security review we had at NANOG last week.  I
think everyone present is (now) on this mailing list, so I trust that
folks involved will correct any misstatements or omissions.

Attendees: Steve Bellovin, Russ Housley, Steve Kent, Tim Christensen,
Matt Ryanczak, Randy Bush, me.

Main result of security review: I owe Rob Loomans a beer for saying
"we should use TLS even though I can't quite tell you why yet."

Our security experts told us that our replay protection mechanism was
the first step towards reinventing TLS, that there were further
pitfalls we hadn't thought about, and that we really should just use
TLS and have done with it.  Consequences of this bit of advice:

- msg_ref can go away entirely now, since replay protection is now
  handled by TLS.

- We want to keep CMS for audit (see discussion December last), but
  we're not relying on CMS timestamps for protocol freshness anymore.

- So the new message format is TLS wrapping HTTP (aka HTTPS) wrapping
  CMS wrapping XML.

- We need to be just as careful checking TLS certs as we are with CMS
  certs.  This includes using TLS client certs when building access
  control lists.  Since I was planning to trace CMS certs all the way
  back to the biz trust anchor anyway, this is not a big deal, but we
  were cautioned that since the traditional check for client certs is
  on the subject name of the client cert (or subjectAltName or
  whatever) and that we should be careful about that, particularly
  when reusing existing code (eg, Apache).

- Using HTTPS means that we should also comply with the HTTPS spec
  regarding things like subjectAltName matching DNS name of server
  even if they don't buy us anything because of all the other checking
  we were doing.

Russ Houseley and Steve Bellovin both dislike having the sender and
recipient fields in the XML because the real sender and recipient IDs
are the crypto keys used to sign the messages.  Russ and Steve are ok
with us saying that the sender and recipient fields are just database
lookup keys that we will use to look up the crypto keys/certs we're
going to check against (ie, mandate tight binding between the XML
identification and the crypto identification) but really want to see
this written in the spec somewhere.

Everybody at this meeting agreed that the error codes must be
completely nailed down in the protocol spec and that changing the
error codes requires updating the spec.  Most people at this meeting
thought that the error codes should be nailed down in the XML schema;
remaining attendees don't much care where the nail is so long as the
error codes are nailed but would want the error codes in the schema if
leaving them out implies that they're in any way not nailed down.

All three security experts (Russ and both Steves) want all the stuff
in the XML portion of the list_class_response that just duplicates
stuff that's already in the ASN.1 removed.  Reason for this is that if
it's in two places it either (a) has to be cross-checked right away or
(b) one has to do same checking later with state to remember the stuff
one was supposed to check.  In either case, one has to commit the
layering violation that this duplication was intended to avoid, so
there's really no point in the duplication.

Steve Bellovin asked whether we need stronger protection on the key
revocation operation than just the business keys; conclusion by the
group was that was just the business key (as currently specified) will
suffice.

Steve Bellovin wants a document on how one rebuilds repositories after
a catastophe (eg, are there operations involving multiple parties that
can only be performed in a particular order?)

Russ and Steve Kent really want preaggregated cache service available
from somebody; RIRs are obvious candidates.  The ARIN folks at this
meeting said that ARIN intends to offer one, dunno about any of the
other RIRs.

Russ would like a picture corresponding to the "entity decompose"
picture (the one Randy put on the t-shirt) but showing the boxes from
the relying party's point of view.

Reviewers noted that my left-right protocol doc is a bit too terse, to
the point where they sometimes weren't sure what I was specifying.

Russ wants us to use the term "raw signing" rather than "blind
signing".

Steve Kent says that the route-origin in my object model (and
left-to-right protocol, and Tim's SQL) doesn't need to support ranges,
only prefixes, because that's the way ROAs are going.  ROAs need to
map to routing, which does prefixes.  Much rejoicing from Tim.

Russ noted that there's an optional seconds-since-epoch representation
for timestamps in CMS which we might prefer over the default, but it
may not be implemented in OpenSSL yet.  I may implement it if it's not
a lot of work but it doesn't look like anything that's on our critical
path.  The new timestamp format is in RFC 4049.

Questions APNIC asked us to ask, with answers:

At Fri, 11 May 2007 17:24:01 +1000, Geoff Huston wrote:
> 
> Regarding the proposed meeting on aspects of attack and protocol aspects of
> resilience of attack with Steve Bellovin and Russ Housley at NANOG early
> next month. Yesterday Randy asked us for any issues that we thought should 
> be covered from our (APNIC's) perspective in this meeting.
> 
> There are a number of items (most of which we suspect that you are already
> well across!):
> 
> a) is msg_ref + CMS timestamp 'good enough' for replay attack protection?

No.  Use TLS.

> b) is preserving strict order of processing important? (we believe it is,
>    but we could be off track here!)

Yes, preserving ordering is important.

> c) is visible disruption of the message exchange harmful?

Yes.  Use TLS.

> d) is parallelizing of requests by the child "unwise", "extremely unwise"
>    or "DON'T"?

DON'T.

If we have an old idle connection and get a new connection, we can
probably just kill the old one (but define "idle", and don't kill the
old connection until the new one has passed authorization checks (see
"use TLS")).

> e) channel security: APNIC has this current model of the up/down protocol
>    that uses https,  using same key/cert as CMS inside object. This
>    probably isn't good (or is it acceptable practice?). It appears to us
>    that the other choices lead to key/cert explosion in business key/cert
>    space. Is it ACCEPTABLE to use a single key for both

Security guys says this is acceptable.  Might require multiple
subjectAltNames (one for each context) but that's ok.

> f) the replies are CMS encrypted. What is the key and cert in the response?

s/encrypted/signed/.  Other than that, it's just the responder's
business key/cert.

> g) is channel security necessarily two-way protected, or (using https as
>    the model) is it acceptable to have only server-side keying?

HTTPS spec does not require client certs, but our usage does require
both client and server certs.