Re: [sidr] WGLC for draft-ietf-sidr-pfx-validate-06

While I think it is a subtle and "fine print" issue, I think it may be
obvious enough that other folks aren't commenting, which is why there are
not a lot of comments on this.

However, this is one case where silence should not be seen as consent.

One good analogy is the DNSSEC method for determining
consistency/completeness: a DNSSEC signature set is expected to contain a
set of NSEC or NSEC3 records which "prove" the existence or non-existence
of every possible name in a given zone. The records form a "ring" which
must be unbroken and complete.

Even if it isn't part of the wire format, and even if some elements of it
are implementation-dependent, there should be at least recommendations, if
not requirements, that any data retrieved be checked for completeness, so
as to prevent downgrade attacks or vulnerabilities introduced by sloppy
implementations.

IMHO.

Brian

On Mon, Jun 18, 2012 at 7:09 AM, Tim Bruijnzeels <tim@ripe.net> wrote:

>
> On 16 Jun 2012, at 22:59, Pradosh Mohapatra wrote:
>
> > Hi Tim,
> >
> >
> >>> Prefix validate assumes full knowledge of all applicable ROAs (or
> other sources of information if they are used) and I believe this should be
> stated more strongly.
> >>>
> >>> The security considerations section addresses the possibility of a
> malicious attacker tampering with the database that is used for validation.
> It does not address the possibility of a database becoming incomplete for
> other reasons.
> >>
> >> This is the main point I wanted to make. I believe this can be easily
> addressed by just stating the requirement in this document. Perhaps
> something along these lines at the end of the first paragraph in the
> security consideration section:
> >>
> >> "Additional or missing records resulting from retrieval and/or
> validation errors can lead to the same problems."
> >>
> >> The following was just a discussion on how RPs can mitigate these
> problems. But.. perhaps this is better addressed in a separate BCP, or
> future work on specifications related to the repository and
> retrieval/validation by RPs.
> >>
> >> If the WG can agree with this then I can support last call..
> >
> >
> > I do not agree this is a "security" issue. I am guessing you meant
> permanent/eventual inconsistencies between the local and global
> repositories (since transient inconsistencies will always be there). That
> kind of inconsistency is most certainly a (protocol) implementation error
> and has to be dealt with at that layer.
> >
>
> I see your point about security, I don't really mind which section
> addresses this.
>
> With inconsistencies I did not mean that the validated cache is out of
> date, which I agree, will always be there even if it could be minimised.
>
> The inconsistencies I refer to are different in nature. It's that the
> snapshot that the RP tool got when it validated is in itself inconsistent:
> surplus or missing ROAs, or the hash of 1 or more ROAs doesn't match.
> Longer discussion omitted, but at this point the RP just doesn't know for
> certain what to do and guidance is needed. This is where *explicitly*
> stating a strong requirement, rather than leaving it implicit, in
> pfx-validate comes in..
>
> Having this will help to either come up with best practices for RP tools,
> or preferably improvements to the repository related standards.
>
> Anyway, I get the feeling that I am the only one here who sees this as a
> problem, so I guess the rough consensus is there..
>
>
>
> Tim
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>