Re: [OPSAWG] [Last-Call] [secdir] Secdir last call review of draft-ietf-opsawg-9092-update-09

[Ben Campbell]

On Jan 26, 2024, at 3:53 PM, Tim Hollebeek 
 wrote:
> 
> Yes, that's the correct paragraph I was referring to.
> 
> Unfortunately, RFC 2119 does actually imply that these words can't
> be used in non-2119 ways:
> 
> "In many standards track documents several words are used to signify
>   the requirements in the specification.  These words are often
>   capitalized.  This document defines these words as they should be
>   interpreted in IETF documents."
> 
> I would also prefer it if the uncapitalized versions retained their original
> English meanings, but these sentences from 2119 are why I recommend
> avoiding such usages.

That was updated by RFC 8174 to say “when capitalized”. 

Ben.

> 
> It is often quite awkward, for example when you're stating mathematical
> truths instead of requirements (a sentence like "If a number does not have 
> any factors less than its square root other than one, then the number must 
> be prime" should never be followed with "how do you audit that?"  But it 
> has happened).
> 
> -Tim
> 
>> -Original Message-
>> From: secdir  On Behalf Of Randy Bush
>> Sent: Friday, January 26, 2024 4:42 PM
>> To: Tim Hollebeek via Datatracker 
>> Cc: sec...@ietf.org; draft-ietf-opsawg-9092-update@ietf.org; last-
>> c...@ietf.org; opsawg@ietf.org
>> Subject: Re: [secdir] Secdir last call review of
> draft-ietf-opsawg-9092-update-
>> 09
>> 
>> tim:
>> 
>>> (1) The following paragraph appears twice in the document (looks like
>>> just a copy/paste error when moving stuff around):
>>> 
>>>  "Identifying the private key associated with the certificate and
>>>   getting the department that controls the private key (which might be
>>>   stored in a Hardware Security Module (HSM)) to generate the CMS
>>>   signature is left as an exercise for the implementor.  On the other
>>>   hand, verifying the signature has no similar complexity; the
>>>   certificate, which is validated in the public RPKI, contains the
>>>   needed public key."
>> 
>> someone caught this the other day, and it has already been fixed in my
> emacs
>> buffer.  good catch anyway; full credit.
>> 
>>> (2) Section 6, paragraph 5: is this intended to be a RFC 2119 "MAY"?
>>> If so, capitalize.  If not, avoid the word.
>> 
>> took me a moment.  i think it is para 6, this one, yes?
>> 
>>   It is good key hygiene to use a given key for only one purpose.  To
>>   dedicate a signing private key for signing a geofeed file, an RPKI
>>   Certification Authority (CA) may issue a subordinate certificate
>>   exclusively for the purpose shown in Appendix A.
>> 
>> that 'may' should probably be 2119ed.  russ, opinion?
>> 
>> aside: i hope that 2119 gives meaning to the CAPITALIZED forms, and does
> not
>> remove the uncapitalized forms from the american/english language.
>> 
>> again, thanks for the review.  they're hard to get.
>> 
>> randy
>> 
>> ___
>> secdir mailing list
>> sec...@ietf.org
>> https://www.ietf.org/mailman/listinfo/secdir
>> wiki: https://wiki.ietf.org/group/secdir/SecDirReview
> -- 
> last-call mailing list
> last-c...@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] Ben Campbell's No Objection on draft-ietf-opsawg-ipfix-bgp-community-11: (with COMMENT)

[Ben Campbell]

Ben Campbell has entered the following ballot position for
draft-ietf-opsawg-ipfix-bgp-community-11: 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-opsawg-ipfix-bgp-community/



--
COMMENT:
--

Please expand IPFIX in the abstract.

§2: Is there a reason not to use the new boilerplate from RFC 8174?

§8:
- "does not directly introduce any new security issues"
What does "directly" mean in context? Should we be concerned about indirectly
introduced issues?

-2nd paragraph: I am skeptical of a claim that, because private information
might be available from other vectors, a mechanism has not introduced new
privacy issues. Is there no possibility that someone who had not deduced
privacy-sensitive information by the other means could now get it via this
mechanism?


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] Ben Campbell's No Objection on draft-ietf-opsawg-mud-20: (with COMMENT)

[Ben Campbell]

Ben Campbell has entered the following ballot position for
draft-ietf-opsawg-mud-20: 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-opsawg-mud/



--
COMMENT:
--

Substantive:

§1.6, 2nd paragraph: Why is the SHOULD not a MUST?

§1.8, 4th paragraph: "The web server is typically run by or on behalf of the
manufacturer.
   Its domain name is that of the authority found in the MUD URL. "

These URLS are likely to be hardcoded, correct? This seems to point to
operational considerations, especially around Thing lifecycle and ownership.

Editorial/Nits:

Abstract: I'm not sure the use of the term "Things" will be obvious to a reader
of the abstract in isolation from the rest of the document. (Abstracts should
be able to stand alone.)

§1.1 : first paragraph: The idea that a Thing might have highly restricted
communication patterns seems core to the document. It would be helpful to
mention that earlier in §1.

§1.3, definition of "Manufacturer": The definition says that "Manufacturer" may
not necessarily be the entity that constructed the Thing. But that's the plain
English meaning of the word "manufacturer". If you don't want it to mean that,
please consider choosing a different term. ( for example, "authority")

§1.4: "... we assume that a device has so few
   capabilities that it will implement the least necessary capabilities
   to function properly."

That's a bit circular. Perhaps one of the two instances of "capabilities"
should have been "requirements"?

§1.8 4th paragraph: The 2nd (and last) sentence is a comma splice, and
otherwise difficult to parse.

§1.9, list item 7:  are we talking about transient disconnect or permanent
removal?

§2: "A MUD file consists of a YANG model ..."
A model instance, right? That is, not the model itself?

§3.8, 2nd sentence: Consider reformulating this as a construction of MUST.

§4: The idea of a "default" in bullet 2 seems in tension with the idea of
"Anything not explicitly permitted is forbidden" in bullet 1.

§14: Please define the concept of "east-west infection".


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Ben Campbell's No Objection on draft-mm-wg-effect-encrypt-17: (with COMMENT)

[Ben Campbell]

Hi Kathleen,

Thanks for your response. Comments inline; I deleted sections that do not seem 
to need further discussion.

Thanks!

Ben.

> On Feb 9, 2018, at 1:18 PM, Kathleen Moriarty 
> <kathleen.moriarty.i...@gmail.com> wrote:
> 
> Hi Ben,
> 
> Thanks again for the comments, responses and proposals are inline.
> 
> On Wed, Feb 7, 2018 at 12:40 AM, Ben Campbell <b...@nostrum.com> wrote:
>> Ben Campbell has entered the following ballot position for
>> draft-mm-wg-effect-encrypt-17: 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-mm-wg-effect-encrypt/
>> 
>> 
>> 
>> --
>> COMMENT:
>> --
>> 
>> This is a considerably better document than the previous versions I have
>> reviewed. Thanks for all that work. But of course, I still have some comments
>> :-)
>> 
>> Substantive Comments:
>> 
>> -2.2.2, 2nd paragraph: "... for example, many
>>   forms of communications (from isochronous/real-time to bulk/elastic
>>   file transfer) will take place over HTTP port 80 or port 443, so only
>>   the messages and higher-layer data will make application
>>   differentiation possible."
>> 
>> I'm confused about the use of port 443 in that sentence; presumably traffic 
>> to
>> 443 will be encrypted and not allow differentiation using higher-layer data.
> 
> TLS 1.2 does leave data exposed for differentiation, SNI for example.
> TLS 1.3 leaves some, but there will be options to encrypt SNI at some
> point in the future.  The response to ALPN will be returned in
> encrypted extensions in TLS 1.3.  These are just the examples that
> come readily to mind and are included in the document.
> 
> Do you think additional text is needed in this section around the port
> 443 example or is this covered enough later in the document?

No, I think that's fine. I was not thinking about information revealed by TLS 
itself.

> 
> 
>> 
>> -2.2.4: This section lacks a discussion of the impact of encryption.
> 
> Good point.  I added one sentence at the edn of the second to last
> paragraph and modified the last paragraph as follows.  Let me know if
> this looks good or you would like to see changes.
> 
>   If impacted by encryption, performance enhancing proxies could make
> use of routing
>   overlay protocols to accomplish the same task, but this results in
> additional overhead.
> 
>   An application-type-aware network edge (middlebox) can further
> control pacing, limit
>   simultaneous HD videos, or prioritize active videos against new videos, etc.
>   Services at this more granular level are limited with the use of
> encryption.

WFM.

> 
>> 
>> -2.2.5, last paragraph: I understand that techniques that require endpoint
>> cooperation might be out of scope, but the tone of this paragraph makes it
>> sound like requiring endpoint cooperation is a negative. Is that the intent?
> 
> Good catch, no that was not the intent and is in conflict with the
> following sentence.  How about the following modification:
> 
>Alternate approaches are in the early phase of being explored to
> allow caching of
>encrypted content.  These solutions require cooperation from
> content owners and
>fall outside the scope of what is covered in this document.
> Content delegation
>allows for replication with possible benefits, but any form of
> delegation has the
>potential to affect the expectation of client-server confidentiality.

WFM.

[…]

>> 
>> -2.3.1: I think it might be worth mentioning that an "intercepting 
>> certificate"
>> requires endpoints to be configured to trust that certificate. (I assume we 
>> are
>> not talking about the more unsavory practice of certificates that 
>> misrepresent
>> their subjects.
> 
> OK, I read this as being covered, but added the following as it must
> not be clear enough to others if you raised this point (thanks for
> doing so):
> 
> Content filtering via a proxy can also utilize an intercepting
> certificate where
> the client's s

Re: [OPSAWG] Ben Campbell's No Objection on draft-mm-wg-effect-encrypt-17: (with COMMENT)

[Ben Campbell]

> On Feb 7, 2018, at 9:08 PM, Spencer Dawkins at IETF 
>  wrote:
> 
> -2.2.1: Please expand "QUIC" and add a citation.
> 
> QUIC started out as an acronym (and went through two or three variations), 
> but sometime during the chartering process, the expansion was dropped. QUIC 
> is both the working group name and abbreviation in 
> https://datatracker.ietf.org/wg/quic/about/.

Ah, good point.

> 
> But citations are good :-)

Yes :-)

Ben.



signature.asc
Description: Message signed with OpenPGP
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] Ben Campbell's No Objection on draft-mm-wg-effect-encrypt-17: (with COMMENT)

[Ben Campbell]

Ben Campbell has entered the following ballot position for
draft-mm-wg-effect-encrypt-17: 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-mm-wg-effect-encrypt/



--
COMMENT:
--

This is a considerably better document than the previous versions I have
reviewed. Thanks for all that work. But of course, I still have some comments
:-)

Substantive Comments:

-2.2.2, 2nd paragraph: "... for example, many
   forms of communications (from isochronous/real-time to bulk/elastic
   file transfer) will take place over HTTP port 80 or port 443, so only
   the messages and higher-layer data will make application
   differentiation possible."

I'm confused about the use of port 443 in that sentence; presumably traffic to
443 will be encrypted and not allow differentiation using higher-layer data.

-2.2.4: This section lacks a discussion of the impact of encryption.

-2.2.5, last paragraph: I understand that techniques that require endpoint
cooperation might be out of scope, but the tone of this paragraph makes it
sound like requiring endpoint cooperation is a negative. Is that the intent?

-2.3, section title: The title is only partially evocative of the section
content. I suggest adding "content filtering".

-2.3.1: I think it might be worth mentioning that an "intercepting certificate"
requires endpoints to be configured to trust that certificate. (I assume we are
not talking about the more unsavory practice of certificates that misrepresent
their subjects.

-2.3.4 I concur with Adam that this section should explicitly mention
"cross-site user tracking" as one of the common motivations for header
insertion/enrichment. I think it should also include a mention of RFC 8165.

-5.2: This section doesn't seem to include discussion of the impact of
encryption.

Editorial and nits:

-IDNits finds a number of unused references, and a few other reference issues.
Please check.

- Abstract: 2nd sentence is hard to parse, and ends with a comma splice.

- 1, 2nd paragraph: " The following informational
   documents consider the end to end (e2e) architectural principle, a
   guiding principle for the development of Internet protocols [RFC2775]
   [RFC3724] [RFC7754]."

Is the comma correct? It currently reads along the lines of "The documents
consider the e2e principle, and we think that it is a guiding principle...",
but I think you might mean "The documents consider the e2e to be a guiding
principle..."

-1, 3rd paragraph: "... (including methods for network
   endpoints where applicable)..."
Should that say "methods that rely on network endpoints"?

-2.1.1: Please expand "CAIDA"

-2.1.1: Paragraph starting with "
   When using increased encryption, operators lose a source of data that
   may be used to debug user issues."
I don't think the operators are the ones using the encreased encryption in that
sentence. Perhaps "When endpoints use increased encryption..." or even (When
increased encryption is used..."

-2.1.3, 2nd paragraph: "The ability to examine layers and payloads
   above transport provides a new range of filtering opportunities at
   each layer in the clear. "
Should "new range" be "increased range"?

-2.1.3, third paragraph: The last sentence seems out of place. Is the point of
the paragraph to point out that the use of these monitoring techniques for DoS
mitigation can't be distinguished from the use of them for privacy violation?

-2.2.1: Please expand "QUIC" and add a citation.

-2.2.3, last sentence: Sentence fragment.

-2.2.4, first sentence: Comma splice.

-2.2.5, first paragraph: " Encryption of packet contents at a given
   protocol layer usually makes DPI processing of that layer and higher
   layers impossible. "

This sentence seems misplaced; the section is not about DPI.

-- same paragraph: I don't understand the point(s) of the last two sentences.

-2.2.5, third paragraph: "The Enhanced Multimedia Broadcast/
   Multicast Services (3GPP eMBMS) - trusted edge proxies facilitate
   delivering same stream to different users, using either unicast or
   multicast depending on channel conditions to the user. "

I can't parse that sentence.

-2.3.3: Please make the "SHOULD" lower case. Since this document does not use
RFC 2119/8174 keywords, a capitalized SHOULD should not appear outside of a