Re: [Sidrops] Ben Campbell's No Objection on draft-ietf-sidrops-rtr-keying-03: (with COMMENT)

[Sean Turner <[e-mail]>]

> On Jan 22, 2019, at 22:26, Ben Campbell <[e-mail]> wrote:
> 
> Ben Campbell has entered the following ballot position for
> draft-ietf-sidrops-rtr-keying-03: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-sidrops-rtr-keying/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> - General: The document says it's intended as BCP, but the data tracker says
> "Proposed Standard". Was this last called with the correct status?  (I agree
> with BCP, by the way.)

Yep - I changed the intended status as a result of a lot of comments, but I guess the buttons didn't get pressed to change it in the datatracker.

> - I share Benjamin's concern about the idea of moving private keys between
> routers as a "need" vs "something people do”.

See the response to BenK.

> §5.2.1: "The router should inform the operator
> whether or not the signature validates to a trust anchor; this
> notification mechanism is out of scope."
> 
> Should that be normative?

I suspect it should be :|

> §9.3: The second paragraph is a single convoluted sentence. Can it be broken
> into simpler sentences?

I suspect it can be but I am hoping the RFC editor can do it’s thing and give me really options.

> §10:
> 
> - "This document defines no protocols. So, in some sense, it introduces
> no new security considerations."
> 
> I think practices can absolutely come with security considerations. For
> example, the practice of moving private keys between routers.

Fair enough, but that’s why there’s more in the SecCon than just that one sentence :)

> - "Private key protection in transit": Is there no expectations that
> transmitted private keys would have object-level encryption?
> 
> §A: I'm curious why this is not part of the main-body security considerations?

See my response to Alissa’s DISCUSS.

spt