[i2rs] Stephen Farrell's Discuss on draft-ietf-i2rs-protocol-security-requirements-14: (with DISCUSS and COMMENT)

["Stephen Farrell" <[e-mail]>]

Stephen Farrell has entered the following ballot position for
draft-ietf-i2rs-protocol-security-requirements-14: Discuss

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-i2rs-protocol-security-requirements/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------


Thanks for the major revision, this is a lot better.  I have
one discuss point and a bunch of comments.

The discuss is: I think it's an error to mix the secure and
insecure transports in one set of protocol requirements. And
I would definitely put a DISCUSS on any protocol solution
that aims to weaken the security of e.g. port 443 or
equivalent. In other words, I think you need to rule out any
protocol solutions that weaken the secure transports that
you are re-using. I therefore suggest adding a new
requirement along these lines:

"SEC-REQ-NN: While I2RS might need to make use of both
secure and insecure transports, this MUST NOT be done in any
way that weakens the secure transport protocol, either as
used in I2RS, or especially not as used in other contexts
that do not have this requirement for mixing secure and
insecure modes of operation and that depend on security
being as good as we can provide."

So I'd like to discuss adding the above or similar.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------



- The topic of marking things as allowing insecure read
access has been discussed a lot so I won't get into it
again.

- section 4: "Data passed over the insecure transport
channel MUST NOT contain any data which identifies a person
or any "write" transactions." I don't get what identifying a
write transaction might mean?

- 4.1: "AAA protocols MAY be used to distribute these
identifiers, but other mechanism can be used." If I'm doing
TLS with mutual-auth, then I need a private key and
certificate. I don't think AAA protocols can transport those
(and they probably ought not) so I'm not sure what's meant
here.

- 4.2: What do "valid identity" and "valid identifier" mean?
If the same then use the same terms. But I think you need to
define "validity" or else say that work needs to be done
later. 

- 4.3: I think you're saying here that the i2rs client is
trusted to simply assert the secondary identifier. If so,
then saying that would be good. If not, then I don't know
what you mean.

- 4.4: I still don't see why it'd not be better to use a
different protocol for the non-secure stuff and avoid all
the potential discussion and pitfalls of trying to do all
this in one protocol.

- 4.4: "It is mandatory to use (MTU) on any I2RS client's
Write transaction or the configuration of an Event Scope
transaction." Which "it" do you mean?

- 4.4: The BCP107 stuff is still not useful.

- 4.5: "detect when the data integrity is questionable" -
I've no idea what that means. Nor what it could mean.  Can
you explain?