Subject: [sidr] #11: Nit Report - provisioning protocol

From: "sidr issue tracker" <[email-masked]>
Date: Fri, 27 Nov 2009 03:40:59 -0000

#11: Nit Report - provisioning protocol
-----------------------------------+----------------------------------------
 Reporter:  gih@…                  |       Owner:     
     Type:  defect                 |      Status:  new
 Priority:  medium                 |   Milestone:     
Component:  rescerts-provisioning  |     Version:     
 Severity:  In WG Last Call        |    Keywords:     
-----------------------------------+----------------------------------------
 Oppose..

 Firstly, my initial observation is that the 'XML in ANS1 in CMS (signed)'
 transported in mutually validated and authenticated(*) HTTPS/TLS sessions
 appears somewhat weighty to cover MiTM/Repla given other parts of the
 entire
 RPKI system don't seem to have been given the same attention and remain
 untrusted?

 (*) you mean cross-certified? or some other way of mutually authenticated?

 Secondly, since this uses a PKI of some description, where is the
 description of the PKI (and CP?) for the signing of the CMS blobs and the
 PKI (and CP) for the TLS sessions. Are they the same? not the same? RPKI
 certs used? etc.

 Are there multiple fully interoperable server and client codebases based
 on
 this? Why I ask is the XML and the basic operations (list, issue, revoke)
 is
 simple enough - the killer space would be getting the multiple signing
 events right. ie which cert is used for the CMS, which is used for the
 TLS..
 and the ASN.1/CMS combo in order.

 lastly, the draft suggests "the server MUST NOT accept a client's request
 unless it has generated and sent a response to the client's previous
 request" - it appeard the _assumption_ made is that the client deals with
 the resources of only one entity. What if it deals with more? What if the
 ISP is representative of multiple organisations and wishes to do multiple
 updates in parallel?

 On to my nits:

 section 3.2:

 Please specify here the version of XML schema that this draft in its
 common
 message format uses (not just describes) and the section (section 4) that
 contains the xml schema. I think that it needs to be done prior to the
 introduction of the template and template values.

 http://www.apnic.net/specs/rescerts/up-down/ responds with a 404 (a pretty
 404, but a 404 nevertheless) So the namespace is invalid.

 I think I would like to see a summary table of all of the HTTP response
 codes used by this protocol.

 Section 3.5.1

 Looks like a wayward "]":

        ski="encoded hash of the subject public key]" />

 Cheers
 Terry

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/sidr/trac/ticket/11>
sidr <http://tools.ietf.org/sidr/>

---

From: "sidr issue tracker" <[email-masked]>
Date: Fri, 27 Nov 2009 03:42:31 -0000

Comment(by gih@…):

 The combination of TLS and CMS was the result of advice the design
 group got from Steve Bellovin, Steve Kent, and Russ Housley when Randy
 and I asked them to review this protocol, back in 2007.  The two
 mechanisms serve different purposes.

 We use CMS for authentication and authorization (is the entity
 requesting this action authorized to do so? etc).  It's also intended
 to allow for audit: if one is paranoid, one can archive a copy of
 every CMS message and use it (along with archived PKI material) to
 prove at some later date that the action was properly authorized.  So
 I view CMS as the main security mechanism here, and the one that's
 most closely aligned with the underlying semantics.

 TLS is present mostly to protect against replay attacks and other
 naughtiness.  Our advisors saw our initial attempts to include replay
 protection in the CMS-signed XML messages and advised us to use
 existing technology (ie, TLS) instead, which makes some sense.  TLS
 also provides privacy (which it's not clear we need), and helps to
 limit denial of service attacks to known entities.

 At this point, having written my own HTTPS implementation and seeing
 how weak (read: effectively nonexistant) the concept of a session is
 in HTTPS, I'm not convinced that TLS is providing all that much in the
 way of useful replay protection.  At this point, though, we do have
 multiple interoperable implementations of this protocol using TLS, so
 unless it's actively harmful I'd just as soon leave it alone for now.

 FWIW, though, at least in my implementation, all the AAA logic is tied
 to CMS, not TLS.

 The PKI used for this (both CMS and TLS) is not the RPKI, it's a
 separate PKI (which the design group has been calling the "BPKI",
 because it mirrors the business relationships between
 certificate-generating entities).  In the abstract, the BPKI can be
 anything that both parties to a particular conversation are willing to
 use, as this is only used in pairwise conversations and doesn't
 transit to third parties.  The main thing is that the parent in a
 parent-child relationship gets to dictate the BPKI model to be used:
 this pretty much falls out of the hierarchical nature of the system.
 So my implementation, at least, has a particular model that I use when
 I'm the parent, and is (I hope) flexible enough to handle whatever
 model my parent might be using when I'm the child.   I can go into
 more detail on the model I'm using, but I'm not sure that the WG
 really needs to sign off on that level of detail.

 The protocol nesting is tedious but straightforward:

   IP(TCP(TLS(HTTP(CMS(XML(up-down))))))

 As far as different security models between this and the rest of the
 RPKI system: the difference is less extreme than it might at first
 appear.  Other than the TLS wrapper discussed above, everything is
 object security, using either CMS or X.509-derived objects which were
 signed to begin with.

 Hope this helps.

 --Rob

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/sidr/trac/ticket/11#comment:1>
sidr <http://tools.ietf.org/sidr/>

---

From: Randy Bush <[email-masked]>
Date: Fri, 27 Nov 2009 13:34:31 +0900

>  mechanisms serve different purposes.

and mis-attributed copies of email we have already read helps the
technical work how?

randy

---

From: Geoff Huston <[email-masked]>
Date: Fri, 27 Nov 2009 16:25:38 +1100

> and mis-attributed copies of email we have already read helps the

I'm sorry if this caused any confusion to WG members. I copied a message in to the issues tracker to ensure that it was captured in the tracker, and the notification of the action is sent to the WG mailer. There may be more tracker notices as I work through the blacklog of WG last call comments that have been made on the mailing list and attempt to capture them in the tracker.

Geoff 

  Not sure it this is a WG co-chair or not posting. Either way is fine by me.

---

From: Randy Bush <[email-masked]>
Date: Fri, 27 Nov 2009 16:20:21 +0900

> I'm sorry if this caused any confusion to WG members. I copied a
> message in to the issues tracker to ensure that it was captured in the
> tracker, and the notification of the action is sent to the WG
> mailer. There may be more tracker notices as I work through the
> blacklog of WG last call comments that have been made on the mailing
> list and attempt to capture them in the tracker.

before i put this tracker thing in my .procmailrc, where's the win?  the
mailing list archive is broken?

randy

---

From: Geoff Huston <[email-masked]>
Date: Fri, 27 Nov 2009 20:13:07 +1100

> mailing list archive is broken?

The issue tracker was set up in response to requests on the WG mailer:

http://www.ietf.org/mail-archive/web/sidr/current/msg01075.html
http://www.ietf.org/mail-archive/web/sidr/current/msg01076.html
http://www.ietf.org/mail-archive/web/sidr/current/msg01103.html

I understand that Sandy requested the tools team to set it up.

Geoff

  WG co-chair hat ON

---

From: Randy Bush <[email-masked]>
Date: Fri, 27 Nov 2009 19:14:15 +0900

> The issue tracker was set up in response to requests on the WG mailer:

now that we have assigned the blame (and my memory is not that sandy was
the one who pushed it), can we answer my question?  where is the win in
repeating emails already in the archive?

actually, no need.  i have procmailed it.  life is simple.

randy

---

From: Sandra Murphy <[email-masked]>
Date: Fri, 27 Nov 2009 09:50:58 -0500 (Eastern Standard Time)

> repeating emails already in the archive?

Sandy did not "push" it, Sany merely responded to a request from the wg 
to enable access to the tools team's issue tracker service.

There are wg who have found the issue tracking to be useful.  I've no 
experience myself, so have no opinion for or against.

Issue tracking is a way to ensure that comments raised on the list are 
addressed in new versions or remain open.

The post to the wg mailing list of each new issue registered is an 
automatic part of the issue tracking service (I believe).  Issues do not 
need to be raised on the mailing list to be entered into the tracker, so 
the notification to the list is not necessarily redundant.

--Sandy

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