Subject: [lisp] New Issue: security text in the document

From: Eliot Lear <[email-masked]>
Date: Thu, 28 Apr 2011 10:05:41 +0200

Joel,

I'm sorry this came up while I was on holiday, but as I told Sam, I
object to the text as proposed in the current version (-12).  I have the
following issues with that text:

    * LISP as an experimental specification should be treated no
      differently than any other experimental specification.  So far as
      I know, that sort of text does not appear in similar works.
    * It states what amounts to the obvious.  Experimental
      specifications are NEVER held up to the same scrutiny as
      standards.  Standards must consider and respond to BCP 107, as
      well as a whole raft of other work.
    * It's the wrong place for this sort of text.  The right place would
      be a charter.  Here what is happening is that people are
      attempting to assert what should be in a future charter. 
      Procedurally, that's inappropriate.
    * Blithely stating that the Security Area has concerns about BCP 107
      does not take into account the nature of the problem at hand, and
      provides no additional guidance to the developers on how to
      correct any potential flaws.

With all of that in mind I propose the following changes:

1.  Remove entirely the new text from Section 1.
2.  Remove Section 12.1, and replace it with a specific concern, and not
some vague statement, perhaps of the following form (assuming I can
divine what they are actually concerned about):

    LISP makes use of a keying approach that is meant to scale in an
    operational environment that cannot on its own rely on additional
    connectivity.  As the approach is new there may be as of yet
    undiscovered threats associated with it.  Further research in this
    area is encouraged.

Eliot

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 28 Apr 2011 09:00:12 -0400

Let me suggest a couple of pieces here:

Firstly, neither I nor Terry claim that this text adds anything useful. 
  Even the folks asking that the text be added do not claim it helps an 
implementor.  Given how little text this is, if it helps some problem, I 
can live with it.

While the specific text was proposed by Sam, the problem is not his.  It 
was the security ADs who, when asked, said that there is a major issue 
with the absence of AKM.  Apparently, the security area has gotten 
really hard nosed about that.  Neither Terry nor I felt that the specs 
should be held up while we develop and document suitable AKM.  So we 
worked with the security ADs to head off a discuss.  This text was 
sufficient.

Reportedly, part of the problem is that other folks have been abusing 
experimental publication.  Therefore, ALL IETF Experimental publication 
should expect to face higher security bars than they have in the past. 
Whether other folks will choose to, and be enabled to, use the same 
strategy we are using is yet to be seen.

Yours,
Joel

On 4/28/2011 4:05 AM, Eliot Lear wrote:
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Terry Manderson <[email-masked]>
Date: Thu, 28 Apr 2011 19:04:06 -0700

To add to Joel's email, and to be quite clear that this text does not
detract from the work which has been put into the LISP experiment.

The plain observation is that this text comes at the request of the Sec-ADs
and the authors have plainly recognized that in the title of "IETF Security
Area Statement".

I should point out that while BCP 107 isn't, from what I could see in a
triage of experimental RFCs (http://www.apps.ietf.org/rfc/explist.html),
specifically mentioned it IS worth noting that vague text highlighting what
hasn't been addressed in an experimental RFCs before they could be
considered for a standarization effort is dotted throughout the set of
experimental RFCs.

It is further worth noting that the LISP work looks more like a standard
track document than any other experimental RFC I have read, and indeed some
standards track RFCs I have read! This is ultimately a huge compliment to
the authors and the LISP working group but that also may lull an unwary
reader into thinking this work is standards track at this point in time. Its
easy to slip into this state given that LISP is an INT area working group,
and not an IRTF research group.

Procedurally, as Joel points out, if this text addresses a discuss item in
publication processing - then I am supportive of it. As I see it the LISP
document(s) are 99.95% done. Lets move forward.

Cheers
Terry

---

From: Eliot Lear <[email-masked]>
Date: Fri, 29 Apr 2011 12:38:16 +0200

Terry, Joel,

I appreciate your efforts to move this work forward.  I also appreciate
the security area's desire to see that work adhere to appropriate
standards.  HOWEVER, the manner which this matter was raised before the
security area without proper consultation of this working group was
entirely inappropriate.  The attempt to bypass the normal charter and
review process for standards remains inappropriate.  No evaluation on
the part of the security area has been demonstrated to indicate that an
automated key process would be appropriate here, so saying one would be
required is factually unsupported.  Having an internal process
discussion in a specification is also confusing, and inappropriate.  It
makes it seem as though that there are two IETFs- the Security Area and
everyone else.  What's more, anyone wishing to take part in the
experiment would likely and rightly say, "Who cares?" 

Statements about how this might change the underlying structure of LISP
are a throwback to people not wanting to pre-determine that this work
will be The Solution.  Our own processes require rough consensus to
begin standardization in a working group, rough consensus to conclude
the work, and a lack of substantial objection from any one area in the
IESG for that work to go forward as a standard.  As that is always true
for any work, mentioning it this document is also inappropriate.

Therefore, I continue to object, for these reasons and those I
previously stated.  In the spirit of compromise, however, I would
propose the following alternative, which would address most of my concerns:

In Section 2:

OLD:

   This experimental specification does not address automated key
   management which would be required for an Internet standard
   equivalent.  See Section 12.1 for further security details.

NEW:

   This experimental specification does not address automated key
   management, which may be required for an Internet standard.
   See Section 12.1 for further security details.

In Section 12.1:

OLD:

12.1.  IETF Security Area Statement

   This document represents the thinking of the LISP working group.  The
   Security Area of the IETF believes there is an open security issue
   how LISP interacts with BCP 107's guidance on automated key
   management.  This and other issues would need to be resolved before
   standardization of LISP.  Accounting for these concerns may change
   the underlying design of LISP.  It is important that deferring these
   discussions in order to publish an experimental protocol sooner not
   restrict a standardized solution that balances concerns of all areas
   of the IETF.

NEW:

12.1.  Automated Key Management

   BCP 107 provides for best practices on automated key management,
   including when it should be used.  This experimental specification
   has not addressed key management. In future work, such as
   standardization, it is anticipated that automated key management will
   be addressed.

This properly leaves deciding how it will be addressed and whether it
MUST be addressed to the standardization process, while at the same time
acknowledging the open issue.  It also gets most of the process
discussion out of the document.  I'd propose that if the security ADs
object to this wording, they bring their objections here, so that a
DISCUSS can be avoided.

Eliot

---

From: Luigi Iannone <[email-masked]>
Date: Fri, 29 Apr 2011 14:56:21 +0200

Hi All,

while I can understand the point raised by the security area people and I can live with such kind of text in the document, I think that the proposed text is rather vague. (see specific comment inline)

>   management.  This and other issues would need to be resolved before

What are the "other issues"? It sounds like there are plenty of other unresolved issues, which IMHO is not the case.

>   standardization of LISP.  Accounting for these concerns may change

Which "concerns"? "other issues" is not a list of concerns.

My personal opinion is that the two points above give the wrong message.

It is my personal opinion that is not fair with respect of the work done by the working group to give such fuzzy message, where it looks like the WG did not do an accurate job.

Having to choose, I prefer the text proposed by Eliot.

Luigi

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 29 Apr 2011 09:30:35 -0400

I would really prefer not to make those changes.

In terms of process, the issue was originally raised quite properly to 
the working group quite a long time ago, by Sam.  The WG did not choose 
to do anything about it, which is reasonable, and in my view the right 
thing to do.  In reviewing open tickets, the chairs looked at this, and 
went and talked to the security ADs to find out how big an issue the 
security area thought this was.  The first answer was "show stopper." 
We then worked with them to develop something that was doable now, did 
not denigrate or interfere with the work, but would remove the roadblock.

There is no question that the security area would insist on AKM for any 
of the keys involved (arguably, the ALT keys could get out of it by 
pointing to BGP, but maybe not even that.)  So the wording changes you 
suggest would, to the extent they matter, mislead people.

Given that we have good reason to believe that the secruity area will 
accept these words (although they will be taking another look during 
IETF last call, as is there right), I would very much prefer to stay 
with what we have.

The work to negotiate wording was not done on the working group mailing 
list.  So?  We can either waste a lot of time trying to negotiate weaker 
words, for no real benefit to us, or we can try to get this done.
I have no desire to become the working group that leads the fight for 
better IESG handling of experimental RFCs.  Terry's and my goal is to do 
enough that a workable document can be published.

Yes, I would like to see better handling at the IESG of experimental 
documents.  It may even be possible to improve that.  It may well be 
that the confusion in the handling of our documents will be a good 
example for them.
But, by being cooperative on this, we are in a better position to deal 
with other issues.  (I only wish I did not expect far larger pushback 
with significantly more difficulty in getting to a resolution that is 
acceptable to us all.  I have seen IESG notes that basically declare 
documents to be bad pieces of work.  Neither Terry nor I will accept 
them doing that to this WG and its products.)

Yours,
Joel

On 4/29/2011 6:38 AM, Eliot Lear wrote:
>> On 28/04/11 11:00 PM, "Joel M. Halpern"<[email-masked]>  wrote:
>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 29 Apr 2011 09:38:03 -0400

There are several reasons I would prefer that we leave the text vague.
The primary one is that I do not want to get into an extended analysis 
and debate about what hypothetical issues we would have to address if we 
sometime in the ill-defined future want to go for PS.  An example of one 
we will probably need in the security area is some variant on the SIDR 
work.  But that is the easy case.  There are also likely to be arguments 
for "refinements" in other areas.  Many of them probably not needed.  We 
can either waste another year having all those fights, or we can have 
vague wording.

Yours,
Joel