Subject: Re: [sidr] WG adoption poll for draft-huston-rpki-validation-01

From: Tom Harrison <[email-masked]>
Date: Mon, 5 May 2014 10:21:18 +1000

On Fri, Apr 25, 2014 at 12:05:14PM -0400, Sandra Murphy wrote:
> The authors of draft-huston-rpki-validation-01.txt, RPKI Validation
> Reconsidered, have requested wg adoption.
> 
> See http://tools.ietf.org/html/draft-huston-rpki-validation-01.
> 
> Please do respond to the list as to whether you support the wg
> adopting this as a work item.  You do not need to comment on the
> content of this draft at this time.  You are asked to indicate if
> you think that this is work that the wg should be doing and whether
> this draft is an acceptable starting point.  Adding whether you
> can/will review or not is useful.
> 
> Note that active support is required for adoption.  Silence is a
> vote against adoption.
> 
> This adoption call will end on 9 May 2014.

I support adoption.

-Tom

---

From: Karen Seo <[email-masked]>
Date: Fri, 09 May 2014 19:13:13 -0400

I'm not yet convinced that the operational costs justify the potential 
weakening of security.  So I do not support adoption of the document as 
is.  I would like to see it split into 2 drafts  -- one describing the 
problem(s) (perhaps including the aspects Rob has mentioned) with an 
analysis of their likely frequency/impact/cost; and then if the WG 
agrees one is needed, a separate draft for a solution that would include 
an assessment of any reduction in security that results from using this 
solution.  Perhaps there are solutions that don't require modifying the 
RPKI validation. I'm willing to review the resulting drafts.

On 4/25/14 12:05 PM, Sandra Murphy wrote:
> The authors of draft-huston-rpki-validation-01.txt, RPKI Validation Reconsidered, have requested wg adoption.
>
> Please do respond to the list as to whether you support the wg adopting this as a work item.  You do not need to comment on the content of this draft at this time.  You are asked to indicate if you think that this is work that the wg should be doing and whether this draft is an acceptable starting point.  Adding whether you can/will review or not is useful.
>
> Note that active support is required for adoption.  Silence is a vote against adoption.
>
> --Sandy, speaking as wg co-chair
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr
>

---

From: Matthew Lepinski <[email-masked]>
Date: Fri, 9 May 2014 23:08:29 -0400

I think that Rob makes an excellent point.

I have no problem with making this draft the focal point of discussions
about changing RPKI path validation. Indeed, I greatly appreciate the
effort that Geoff and George have put into articulating the operational
concern with RFCs 3779 and 6487. There is clearly a CA operational concern
here and I think it is good for the working group to take these types of
concerns seriously.

However, I am not yet sold that the solution outlined in this draft is
necessary (or is the best way of addressing the problem).  I think it is
possible that the cost [in complexity, risk, changes to deployed code] of
the proposed solution is not worth the benefit.

At this point in time, I think it is important to prematurely commit to a
solution. (Indeed, based on discussions on the list, I think there was -
even quite recently -- some confusion about the problem that needs to be
solved.)

Personally, I don't think it is especially important whether or not we
adopt the draft, as long as adopting the draft isn't interpreted as
consensus that the particular solution specified in the draft is definitely
the best way forward. That is, Adoption is generally a commitment by the
working group to spend time working on a particular topic and a transfer of
change control to the working group. Both of these I am comfortable with.

- Matt Lepinski

On Tue, Apr 29, 2014 at 6:01 PM, Rob Austein <[email-masked]> wrote:

> Unfortunately, the binary adopt-or-not question is insufficiently
> nuanced for a case like this.
>
> I think the WG needs a work item to explore the issue of decoupling
> RFC-3779-style[*] path validation from certificate validation.  It may
> be that at the end of that process we will decide not to change the
> base specification, but in addition to whatever sympathy the WG might
> feel for CA operators near the root of the tree, I think there may be
> some real issues lurking here with respect to out-of-order validation
> problems and we need to explore them further.
>
> I really do not know at this point whether the result of the work we
> need to do on this will be a publishable document or not.
>
> I do not support the addition of joins in the RPKI tree, full stop.
>
> The WG chairs asked a couple of specific questions:
>
> > You are asked to indicate if you think that this is work that the wg
> > should be doing
>
> Yes, with the proviso that the end result may be a decision to leave
> well enough alone, in which case the only thing we might publish would
> be a history of our decision not to change anything.
>
> > and whether this draft is an acceptable starting point.
>
> As a problem statement, yes.  With no intent to give offense, it's
> nowhere near being suitable as an amended specification, but such a
> document would be premature at this stage in any case.
>
> Starting with a problem statement seems appropriate, so long as we
> retain the option of keeping the current specification.  Yes, this
> might end up meaning that, after years of work, the WG concludes that
> we should not change the specification.  Sometimes you have to work on
> something for a while before you know whether you should be doing it.
>
> [*] "RFC-3779-style" because, if we change it, it won't be RFC 3779
>     anymore.  It might well reuse all of RFC 3779's syntax and most of
>     RFC 3779's semantics, but since there is deployed code that thinks
>     it knows how to validate with the current semantics, at minimum I
>     would want the hypothetical new thing to use different extnID OID
>     values to flag the change.  So, strictly speaking, this would be a
>     new set of X.509v3 extensions that just happen to look exactly
>     like the ones from RFC 3779.
>