Re: [Gen-art] Genart early review of draft-ietf-drip-auth-24

[Stuart W. Card]

Stu here, chiming in, primarily on those specific issues where Adam 
called me out. My comments are interspersed below and I have trimmed out 
any areas on which I have none.



On 10/13/2022 3:06 PM, Adam Wiethuechter wrote:

*From:* Matt Joras via Datatracker 

Reviewer: Matt Joras
Review result: Ready with Nits

   DRIP Specific Authentication Methods, carried in ASTM Authentication
   Messages (Message Type 0x2) are defined herein.  These methods, when
   properly used, enable a high level of trust in that the content of
   other ASTM Messages was generated by their claimed registered source.

The last sentence here is a bit confusing, consider rewording "enable 
a high

level of trust in that the".


Looks like it was a bad copy paste during a recent reworking of that 
paragraph.


Switched to: "enable a high level of trust in the content of other 
ASTM Messages that was generated by their claimed registered source"




Actually, we want to make clear that we are not encouraging trust in the 
message content itself, only authenticating that the content indeed came 
from the claimed source.


E.g. "enable a high level of trust in that the" => "enable a high level 
of trust that the"


Simple removing the word "in" from the original sentence should fix it?



   [F3411] defines Authentication Message framing only. It does not
   define authentication formats or methods.  It explicitly anticipates
   several signature options, but does not fully define even those.
   [F3411] Annex A1 defines a Broadcast Authentication Verifier Service,
   which has a heavy reliance on Observer real-time connectivity to the
   Internet (specifically into UTM) that is not always guaranteed.
   Fortunately, [F3411] also allows third party standard Authentication
   Types, several of which DRIP defines herein.

"but does not fully define even those." -> "but does not fully define 
those."
I originally wrote that sentence so am to blame. I was attempting to 
draw a distinction between ASTM's explicitly and intentionally declining 
to specify auth formats or methods, and their listing but not fully 
specifying signature options. As it reads, it may seem I was casting 
aspersions. Perhaps we can reword in some manner that does not cast 
aspersions but retains the distinction?


"which has a heavy reliance on Observer real-time connectivity to the 
Internet
(specifically into UTM) that is not always guaranteed." -> "which has 
a heaby

reliance on an Observer's real-time connectivity to the Internet"


Both changes will be taken. The second sentence change may have some 
contension with my co-author who may want to emphasize the link to 
UTM. We shall see how it plays out.




The parenthetical notation was intended only to point out that this 
lookup is dependent upon UTM systems, so they constitute an additional 
point of potential failure. However, the primary issue, from which we do 
not want to distract the reader, is that the Observer may not have 
viable Internet connectivity at the place and time of observing the UA, 
and thus with the on-line authentication service, would not be able to 
authenticate received Broadcast RID messages.




3.1.4.  UAS RID Trust

   Section 3.1.1, Section 3.1.2 and Section 3.1.3 above complete the
   trust chain but the chain cannot yet be trusted as having any
   relevance to the observed UA because reply attacks are trivial.  At
   this point the key nominally possessed by the UA is trusted but the
   UA has not yet been proven to possess that private key.

... Also, I'm not sure what "cannot yet be trusted as
having any relevance to the observed UA" means.


...

I am not sure how to address your second point. Perhaps @Stu Card 
 can help here and come up with some 
better text?

ua


Trust that a key is valid and registered is not proof that a given party 
owns/possesses that key. A sender (typically UA) can broadcast the 
entire chain of links from root to leaf of a key that sender does not 
actually have. Only when the UA signs, using that leaf key, some content 
that is not easily guessed and clearly pertains to the observed UA, does 
the Observer have any reason to believe that and the other information 
signed with that same key pertain to that UA. We can submit this to our 
technical writer here to try to develop alternative text to "cannot yet 
be trusted as having any relevance to the observed UA" to try to make 
that clear?




4.3.1.  Message Count

   When decoding a DRIP Wrapper on a receiver, the number of messages
   wrapped can be determined by checking the length between the UA DET
   and the VNB Timestamp by UA is a multiple of 25-bytes.

Consider rewording. "checking" here sort of implies that an invariant 
is being
checked, rather than the number of messages being calculated (i.e. 
integral

division by 25).


Rewording "checking" to "calculating".



We have conflated 2 issues here.

(1) We want to sanity check that the Wrapper is 

Re: [Gen-art] [Last-Call] Genart last call review of draft-ietf-lamps-5g-nftypes-05

[Robert Sparks]

minor tweak

On 10/13/22 4:44 PM, Robert Sparks via Datatracker wrote:



At:

"The mechanism for an operator to determine whether an ASCII string associate
with a NF Type is unique across operators is outside the scope of this document"

I suggest "string associate with" -> "string is associated with"

That's not right, but you can see what to do I hope. Maybe "string 
associated with" is the better fix.


Apologies for the extra noise.

RjS





___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Genart last call review of draft-ietf-lamps-5g-nftypes-05

[Robert Sparks via Datatracker]

Reviewer: Robert Sparks
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-lamps-5g-nftypes-05
Reviewer: Robert Sparks
Review Date: 2022-10-13
IETF LC End Date: 2022-10-27
IESG Telechat date: Not scheduled for a telechat

Summary: Ready (maybe) for publication as a Proposed Standard RFC, but with
issues to consider before this gets to IESG Evaluation.

Major Issue:

(Apologies if I'm forgetting a well known reason this isn't an issue):

Doesn't IA5String allow all of 0-127 in ascii? Do you want NUL through SP and
DEL in NF Type names?

Minor Issue:
The document says operators need to not use colliding names but then explicitly
declaires on how an operator would know if a name is already in use is out of
scope. Surely there was a discussion about a registry, and the IESG is
certainly going to ask. It would save some time if you could add something to
the shepherd writeup explaining why a registry wasn't pursued in this document?

Nits:

At:

"The 49 NF types that are defined for 3GPP Release 17 listed in Table
6.1.6.3.3-1 of [TS29.510], and each NF type is identified by a short ASCII
string."

the sentence doesn't parse. Do you mean "are listed" or "There are 49 NF types"
or something else?

At:

"The NFTypes MUST contain only an ASCII string, MUST contain at least one ASCII
character, and MUST NOT contain more than 32 ASCII characters."

I suggest "Each NFType MUST"

At:

"The mechanism for an operator to determine whether an ASCII string associate
with a NF Type is unique across operators is outside the scope of this document"

I suggest "string associate with" -> "string is associated with"



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Review Assignments

[Jean Mahoney via Datatracker]

Hi all,

The following reviewers have assignments:

For telechat 2022-10-27

Reviewer   Type  LC end Draft
Pete Resnick   Last Call 2022-10-07 draft-ietf-lpwan-schc-over-nbiot-12

Last calls:

Reviewer   Type  LC end Draft
Stewart Bryant Last Call 2022-10-28 draft-yee-ssh-iana-requirements-01
Joel Halpern   Last Call 2022-10-24 
draft-ietf-lamps-lightweight-cmp-profile-14
Russ Housley   Last Call 2022-10-24 
draft-ietf-ipsecme-ikev2-multiple-ke-07
Matt Joras Last Call 2022-10-10 
draft-ietf-sipcore-multiple-reasons-01
Meral Shirazipour  Last Call 2022-10-27 
draft-ietf-ace-cmpv2-coap-transport-05
Robert Sparks  Last Call 2022-10-27 draft-ietf-lamps-5g-nftypes-05
Dale WorleyLast Call 2022-10-12 draft-ietf-stir-passport-rcd-21

Early review requests:

Reviewer   DueDraft
Francis Dupont 2022-10-03 draft-knodel-e2ee-definition-07
Suhas Nandakumar   2022-09-28 draft-ietf-mls-protocol-16

Next in the reviewer rotation:

  David Schinazi
  Reese Enghardt
  Thomas Fossati
  Tim Evens
  Paul Kyzivat
  Vijay Gurbani
  Linda Dunbar
  Elwyn Davies
  Ines Robles
  Christer Holmberg

The LC and Telechat review templates are included below:
---

-- Begin LC Template --
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document:
Reviewer:
Review Date:
IETF LC End Date:
IESG Telechat date: (if known)

Summary:

Major issues:

Minor issues:

Nits/editorial comments:

-- End LC Template --

-- Begin Telechat Template --
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

.

Document:
Reviewer:
Review Date:
IETF LC End Date:
IESG Telechat date: (if known)

Summary:

Major issues:

Minor issues:

Nits/editorial comments:

-- End Telechat Template --



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart early review of draft-ietf-drip-auth-24

[Adam Wiethuechter]

Matt,

Thanks for your quick and detailed review. Some comments in line. -25 will be 
out in the next 24-hours making corrections based on your comments.

Your comments on the use of Wrapper and Manifest are being fixed throughout the 
document and have been snipped from this reply.


73,
Adam T. Wiethuechter
Software Engineer; AX Enterprize, LLC


From: Matt Joras via Datatracker 
Sent: Wednesday, October 12, 2022 4:28 PM
To: gen-art@ietf.org 
Cc: draft-ietf-drip-auth@ietf.org ; 
tm-...@ietf.org 
Subject: Genart early review of draft-ietf-drip-auth-24

Reviewer: Matt Joras
Review result: Ready with Nits

Below is some pseudo-inline review of this document for gen-art.

   Without authentication, an Observer has no basis for trust.  As the
   messages are sent via wireless broadcast, they may be transmitted
   anywhere within wireless range and making any claims desired by the
   sender.

Observer has not yet been defined here, is it expected that the reader knows
what this refers to?


Defined in RFC9153, which should be pre-requisite reading but how exactly do we 
enforce that? I never followed that rule in school. :-)
Perhaps if I add a bit more to Section 2.2 like this:

> This document makes use of the terms defined in 
> [RFC9153].
to
> This document makes use of the terms (such as Observer, USS, UTM, etc.) 
> defined in 
> [RFC9153].


   DRIP Specific Authentication Methods, carried in ASTM Authentication
   Messages (Message Type 0x2) are defined herein.  These methods, when
   properly used, enable a high level of trust in that the content of
   other ASTM Messages was generated by their claimed registered source.

The last sentence here is a bit confusing, consider rewording "enable a high
level of trust in that the".


Looks like it was a bad copy paste during a recent reworking of that paragraph.

Switched to: "enable a high level of trust in the content of other ASTM 
Messages that was generated by their claimed registered source"


   Extended Transports:

  use of extended advertisements (Bluetooth 5.x), service info (Wi-
  Fi NaN) or vendor specific element information (Wi-Fi BEACON) in
  broadcast frames as specified in [F3411].  Must use ASTM Message
  Pack (Message Type 0xF).

Is Wi-Fi NaN supposed to be Wi-Fi NAN?


Yes, good catch.


   HHIT Domain Authority (HDA):

  A class of DIME usually associated with a USS in UTM.

Is it expected that the reader know what DIME, USS, and UTM are?


RFC9153 strikes again. I will expand these out on first use however regardless.


   [F3411] defines Authentication Message framing only.  It does not
   define authentication formats or methods.  It explicitly anticipates
   several signature options, but does not fully define even those.
   [F3411] Annex A1 defines a Broadcast Authentication Verifier Service,
   which has a heavy reliance on Observer real-time connectivity to the
   Internet (specifically into UTM) that is not always guaranteed.
   Fortunately, [F3411] also allows third party standard Authentication
   Types, several of which DRIP defines herein.

"but does not fully define even those." -> "but does not fully define those."

"which has a heavy reliance on Observer real-time connectivity to the Internet
(specifically into UTM) that is not always guaranteed." -> "which has a heaby
reliance on an Observer's real-time connectivity to the Internet"


Both changes will be taken. The second sentence change may have some contension 
with my co-author who may want to emphasize the link to UTM. We shall see how 
it plays out.


3.1.4.  UAS RID Trust

   Section 3.1.1, Section 3.1.2 and Section 3.1.3 above complete the
   trust chain but the chain cannot yet be trusted as having any
   relevance to the observed UA because reply attacks are trivial.  At
   this point the key nominally possessed by the UA is trusted but the
   UA has not yet been proven to possess that private key.

Should "reply" be "replay"? Also, I'm not sure what "cannot yet be trusted as
having any relevance to the observed UA" means.


"replay" is correct. Thanks for the catch.

I am not sure how to address your second point. Perhaps @Stu 
Card can help here and come up with some 
better text?


4.3.1.  Message Count

   When decoding a DRIP Wrapper on a receiver, the number of messages
   wrapped can be determined by checking the length between the UA DET
   and the VNB Timestamp by UA is a multiple of 25-bytes.

Consider rewording. "checking" here sort of implies that an invariant is being
checked, rather than the number of messages being calculated (i.e. integral
division by 25).


Rewording "checking" to "calculating".


[...]

"concatenated together into a single byte object" is a bit confusing -- does
this imply mixing the hashes 

[Gen-art] Genart last call review of draft-ietf-dnsop-rfc5933-bis-10

[Roni Even via Datatracker]

Reviewer: Roni Even
Review result: Almost Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-dnsop-rfc5933-bis-??
Reviewer: Roni Even
Review Date: 2022-10-13
IETF LC End Date: 2022-10-19
IESG Telechat date: Not scheduled for a telechat

Summary:
the document is almost ready for publication as some type of an RFC

Major issues:
The document is meant to be an informational RFC obsoleting RFC5933 a standard
track RFC. why is this change.

Minor issues:

the directive in the IANA consideration   "The entry for Value 3, GOST R
34.11-94 should be updated to have its Status changed to '-'" is not clear.
there is no status field in the table as I see in RFC8624 section 3.3

Nits/editorial comments:



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art