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

From: Sean Turner <[email-masked]>
Date: Tue, 12 Feb 2019 21:26:06 -0500

> On Jan 22, 2019, at 23:09, Adam Roach <[email-masked]> wrote:
> 
> Adam Roach 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:
> ----------------------------------------------------------------------
> 
> Thanks to the authors for a well-written and clear document. I have one
> substantive comment, and a minor editorial nit.
> 
> ---------------------------------------------------------------------------
> 
> §3:
> 
>> - Using FTP or HTTP per [RFC2585], and
> 
> It's not clear from a casual examination whether use of unencrypted and
> non-integrity-protected channels for these operations are safe. I would expect
> to see a discussion of this in this section and/or section 10. The closest I
> could find is the SHOULD-strength (!) recommendation for transport-level
> security for private key transport.
> 
> Without a more thorough analysis, I suspect we should more strongly deprecate
> the use of unencrypted/non-integrity-protected transports. This document is,
> after all, supposed to be calling out best practice; and, in 2019, that really
> does entail transport security except under the most exceptional circumstances.

My initial reaction:

For items that are already integrity protected, certificate and CRLs, it’s not as bad as all that.  See the security considerations in RFC 2585.

But, after a glass of wine on a plane:

Maybe we put something it that says something like:

Despite the fact that Certificates are integrity-protected and do not necessarily need additional protection, transports that also provide integrity protection are RECOMMENDED.

> ---------------------------------------------------------------------------
> 
> §2:
> 
>> Though other configuration mechanisms might be used, e.g.  NetConf
>> (see [RFC6470]), the protected the protected channel between the
> 
> Nit: duplicate "...the protected…"

Fixed!

spt