Thanks Sue, That wording is fine and I've cleared.
Cheers, S. On 29/09/16 13:05, Susan Hares wrote: > Stephen: > > Version 15 has the following added: > > SEC-REQ-16: The I2RS protocol makes use of both > secure and insecure transports, but this use MUST NOT be > done in any way that weakens the secure transport protocol > used in the I2RS protocol or other contexts that > do not have this requirement for mixing secure > and insecure modes of operation. > > I tweaked the English in your text. Does this satisfy your discuss? If so, > will you remove your DISCUSS. I am working on version -16 to resolve your > comments. > > > Sue Hares > > -----Original Message----- > From: Stephen Farrell [mailto:[email protected]] > Sent: Wednesday, September 28, 2016 5:32 PM > To: The IESG > Cc: [email protected]; Jeffrey Haas; > [email protected]; [email protected]; [email protected] > Subject: Stephen Farrell's Discuss on > draft-ietf-i2rs-protocol-security-requirements-14: (with DISCUSS and COMMENT) > > 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? > > >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
