Subject: [sidr] new agenda uploaded

From: Sandra Murphy <[email-masked]>
Date: Tue, 3 Nov 2015 07:48:00 +0900

A new agenda was uploaded.

Thanks to Tim to catching an error in the header, a holdover from a long ago agenda.

—Sandy

---

From: "John G. Scudder" <[email-masked]>
Date: Thu, 5 Nov 2015 14:42:05 +0900

If you don't mind uploading a new new one to reflect the current plan for Friday, it would be helpful. Thanks!

--John

> On Nov 3, 2015, at 7:48 AM, Sandra Murphy <[email-masked]> wrote:
>

---

From: Sandra Murphy <[email-masked]>
Date: Thu, 5 Nov 2015 16:49:46 +0900

I uploaded a new agenda, moving Rob’s time on Friday to Tuesday without any attempt to represent Tue timing, moved Randy’s presentation on router keying to Friday, and added a presentation of validation reconsidered.

Still on the Friday agenda are Steve Kent and Yu Fu talking about bad CAs.

—Sandy, speaking as a wg co-chair

On Nov 5, 2015, at 2:42 PM, John G. Scudder <[email-masked]> wrote:

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

---

From: Stephen Kent <[email-masked]>
Date: Thu, 5 Nov 2015 10:24:59 -0500

Sandy,

I think "draft-ietf-sidr-rpki-validation-reconsidered served a valuable 
purpose,
highlighting valid concerns about potential fragility in the RPKI, in 
the face of
errors by CAs and in the context of INR transfers. However, I feel that 
this I-D
should not progress.

The topic of INR transfers is being addressed in much grater detail in
draft-ymbk-sidr-transfer (which lists Geoff and George as co-authors). 
This doc.
for which I provided extensive comments over the summer, is examining 
discussing
INR transfers in a more thorough fashion and thus should provide a 
better basis for
selecting a standard mechanism for their support.

The impact of errors by CAs is being examined in a much broader context 
in an I-D that
Di Ma and I have authored: draft-kent-sidr-adverse-actions. This 
document examines
a very wide range of impacts that can result from an error by a CA or an 
attack
against a CA (or an error/attack involving a repository manager). Thus I 
feel that it
will provide a more comprehensive analysis of the sort of concerns raised in
validation-reconsidered.

Finally, the the validation algorithm change proposed in 
validation-reconsidered does
not address the broader range of errors noted in adverse-actions. It 
also is not compatible
with current RP software designs that validates CA (not just EE) certs 
as part of local cache
maintenance.

Once the sidr-transfer and adverse-actions I-Ds are completed, I believe 
the WG
will be a much better position to develop mechanisms that will address 
both sets
of concerns noted above.

Steve

---

From: Declan Ma <[email-masked]>
Date: Fri, 6 Nov 2015 00:26:36 +0800

I agree with Steve.

“RPKI Validation Reconsidered” should not be carried on.

And I believe that our WG should look at RPKI operation security from a wider perspective and pursue countermeasures according to a deliberate threat model as described in draft-kent-sidr-adverse-actions. 

Di Ma

ZDNS Ltd.

> 在 2015年11月5日，23:24，Stephen Kent <[email-masked]> 写道：
> 
> Sandy,
> 
> I think "draft-ietf-sidr-rpki-validation-reconsidered served a valuable purpose,
> highlighting valid concerns about potential fragility in the RPKI, in the face of
> errors by CAs and in the context of INR transfers. However, I feel that this I-D
> should not progress.
> 
> draft-ymbk-sidr-transfer (which lists Geoff and George as co-authors). This doc.
> for which I provided extensive comments over the summer, is examining discussing
> INR transfers in a more thorough fashion and thus should provide a better basis for
> The impact of errors by CAs is being examined in a much broader context in an I-D that
> Di Ma and I have authored: draft-kent-sidr-adverse-actions. This document examines
> a very wide range of impacts that can result from an error by a CA or an attack
> against a CA (or an error/attack involving a repository manager). Thus I feel that it
> Finally, the the validation algorithm change proposed in validation-reconsidered does
> not address the broader range of errors noted in adverse-actions. It also is not compatible
> with current RP software designs that validates CA (not just EE) certs as part of local cache
> maintenance.
> 
> Once the sidr-transfer and adverse-actions I-Ds are completed, I believe the WG
> will be a much better position to develop mechanisms that will address both sets
> of concerns noted above.
> 
> Steve
>