Re: [Gen-art] Genart telechat review of draft-ietf-trill-over-ip-15

[Donald Eastlake]

Hi Matthew,

On Thu, Mar 8, 2018 at 1:59 AM, Matthew Miller
 wrote:
> Reviewer: Matthew Miller
> Review result: Ready with Nits
>
> 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-trill-over-ip-15
> Reviewer: Matthew A. Miller
> Review Date: 2018-03-07
> IETF LC End Date: 2018-03-06
> IESG Telechat date: 2018-03-08
>
> Summary:  Ready with nits
>
> Major issues: NONE
>
> Minor issues: NONE
>
> Nits/editorial comments:

I find the way you have formatted your comments to be confusing. I
think there should be a clear demarkation where all the material
related to a comment ends and that for the next comment begins. You
seem to use the same unusual triple double quotation mark delimiter
between your comment and your marked up text from the draft related to
that comment.

> * In Section 4.5. "TRILL Over IP Transport IS-IS SubNetwork Point
> of Attachment", the word "of" between ""
>
> """
> The Hellos transmitted out [of] a port indicate what neighbor ports
> that port can see on the link by listing what IS-IS refers to as the
> neighbor port's SubNetwork Point of Attachment (SNPA)
> """
>
> * In Section 5.2. "Encapsulation Agreement", the first sentence is
> difficult to understand; I think it is missing the word "on" between
> "sent out" and "a TRILL over IP":
>
> """
> TRILL Hellos sent out [on] a TRILL over IP transport port indicate the
> encapsulations for which that port is offering full support through a
> mechanism initially specified in [RFC7178] and [RFC7176] that is
> hereby extended.
> """

I do not think the insertions you recommend are necessary but I'm
willing to make them.

> * In Section 5.4. "Native Encapsulation", the word "he" should be
> "the" in the sentence "Where he UDP Header is as follows".

OK

> * In Section 5.6.1. "TCP Connection Establishment", the word
> "connections" should be singular (or the leading "a" dropped) in the
> fragment "try to establish a TCP connections to each of them".

Changing "connections" to "connection" seems best.

> * In Section 5.6.1. "TCP Connection Establishment", the occurrence of
> "P!" should be changed to "P1".

OK.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com

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

Re: [Gen-art] [Uta] Genart last call review of draft-ietf-uta-smtp-tlsrpt-17

[Joel M. Halpern]

A reasonable perspective.  Could that be added to the document?

Yours,
Joel

On 3/8/18 6:33 PM, Viktor Dukhovni wrote:




On Mar 8, 2018, at 5:28 PM, Joel Halpern  wrote:

It is surprising in Section 3 Bullet 4 that reporting via email requires
that the report submitted use DKIM.  Particularly while ignoring any
security errors in communicating with the recipient domain.


Actually, this is not surprising.  The main security risk here is report spam,
that will drown the true signal in noise, making it impossible to notice real
validation failures or operate the service.

Therefore, the report origin domain must be authenticated via DKIM.  I'd
be tempted to go further and require a particular "selector" prefix that
is specifically chosen for "tlsrpt", so that with domains such as "gmail",
where anyone can get an email account, just being a user on the sending
system is not enough to be able to forge a DKIM authenticated report.
But that would create significant complications for the sender to make it
so, and so is probably not needed.

In summary, when sending reports the party that needs to be authenticated
is the sender domain, while the receiving domain is presumed operationally
compromised, and so should be exempt from any authentication requirements.



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

Re: [Gen-art] [Uta] Genart last call review of draft-ietf-uta-smtp-tlsrpt-17

[Viktor Dukhovni]

> On Mar 8, 2018, at 5:28 PM, Joel Halpern  wrote:
> 
>It is surprising in Section 3 Bullet 4 that reporting via email requires
>that the report submitted use DKIM.  Particularly while ignoring any
>security errors in communicating with the recipient domain.

Actually, this is not surprising.  The main security risk here is report spam,
that will drown the true signal in noise, making it impossible to notice real
validation failures or operate the service.

Therefore, the report origin domain must be authenticated via DKIM.  I'd
be tempted to go further and require a particular "selector" prefix that
is specifically chosen for "tlsrpt", so that with domains such as "gmail",
where anyone can get an email account, just being a user on the sending
system is not enough to be able to forge a DKIM authenticated report.
But that would create significant complications for the sender to make it
so, and so is probably not needed.

In summary, when sending reports the party that needs to be authenticated
is the sender domain, while the receiving domain is presumed operationally
compromised, and so should be exempt from any authentication requirements.

-- 
Viktor.

___
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-uta-smtp-tlsrpt-17

[Joel Halpern]

Reviewer: Joel Halpern
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-uta-smtp-tlsrpt-17
Reviewer: Joel Halpern
Review Date: 2018-03-08
IETF LC End Date: 2018-04-02
IESG Telechat date: Not scheduled for a telechat

Summary: This document is close to ready for publication as a Proposed Standard
RFC.

Major issues:
Given that the format of the txt record allows for multiple URIs, the ntext
needs to specify what the reader of the record is supposed to do when there
are multiple (using the same or different formats).  I presume the intent
is that the reader may use any of the URIs, and only needs to use 1.  But
it needs to say so.

The field names in section 4.2.1 do not match the field names in the schema
"summary" section in 4.4.

Reading the details of the "failed-session-count" in the "failure details"
section in section 4.4, I infer that the intention is that "failure
details" is to be repeated for each different kind of failure.  That is a
sensible approach.  I can not find where the text actually states that to
be the approach.  (yes, it is represented in the example.)

Minor issues:
The introductory text on the relationship between StartTLS and
Opportunistic Security is confusing.  Niether the term nor the RFC existed
when Starttls was defined.  Maybe instead of  "The protocol design is based
on "Opportunistic Security"..." it could read "The protocol design uses an
approach that has come to be known as "Opportunistic Security"..."?

Section 3, bullet 3, says that submitters using POST can ignore certificate
validation errors when using https.  That seems to undermine the usage of
https.  As such, I would expect to at least see some explanation of when
and why ignoring such errors is appropriate.

It is surprising in Section 3 Bullet 4 that reporting via email requires
that the report submitted use DKIM.  Particularly while ignoring any
security errors in communicating with the recipient domain.

In the formal definition of the txt record, shouldn't the URI format also
indicate that semicolon needs to be encoded?

The reference in section 4.2.1 on treating the success count as a heartbeat
suggests that the intention that these reports are to be filed even when
everything has worked right all day.  If that is the intention, it should
be stated explicitly.  If that is not the intent, then the reference to
heartbeat in 4.2.1 should be removed.

Section 5.1 defines a report filename.  This is probably a naive question,
but what is that for?  If using HTTPS, the earlier text says that the POST
operation goes to the target URI from the txt record.  When using email,
there is no apparent need for a filename.

Most of the security risks described in the Security section (7) do not
seem to have any mitigation.  Should there not be some explanation why
deployment is acceptable with these risks?

Nits/editorial comments:
I presume that the use of DNS text records to convey policy has been
reviewed and approved by the DNS Directorate.


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

Re: [Gen-art] review of draft-ietf-netmod-syslog-model-21.txt

[Clyde Wildes (cwildes)]

Francis,

Thanks for your review. My comments below…

On 3/5/18, 2:53 PM, "Francis Dupont"  wrote:

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-netmod-syslog-model-21.txt
Reviewer: Francis Dupont
Review Date: 20180225
IETF LC End Date: 20180228
IESG Telechat date: unknown

Summary: Ready

Major issues: None

Minor issues: None

Nits/editorial comments: 
(I took my notes on version 21 but I have version 23 in front of me)

 - ToC page 2 and 6 page 27 (title): Acknowledgements -> Acknowledgments

[clw] Accepted

 - 1 page 3: acknowledgement -> acknowledgement

[clw] Accepted

 - 4.1 page 10: do the same than 1.1 page 3: refer to RFC8174 too
  for keywords.

[clw] Accepted 
  
 - 4.1 page 18 (advanced-compare): spectify -> specify

[clw] Accepted

 - 4.1 page 23 (remote transport and tls) (twice):
  specified: an ipv4 address, an ipv6 address, ipv4->IPv4 and ipv6->IPv6

[clw] one address is for the UDP case and the other is for the TLS case. I 
think this this is ok.

 - 6 page 27: there is no "and" between the two last names and no
  final dot so I am afraid the list was truncated (BTW obviously iy is
  not the case but please add a final dot, i.e.:
  Aleksandr Zhdankin -> Aleksandr Zhdankin.

[clw] Accepted.

Thanks,

Clyde

Note I trust the Yang tools to have checked the syntax.

Regards

francis.dup...@fdupont.fr


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

[Gen-art] Review Assignments

[Jean Mahoney]

Hi all,

The following reviewers have assignments:

For telechat 2018-04-05

Reviewer   Type  LC end Draft
Brian CarpenterLast Call 2018-03-26 draft-ietf-6tisch-6top-protocol-10 *
Francis Dupont Telechat  2018-03-20 draft-ietf-tls-record-limit-02
Vijay Gurbani  Last Call 2018-03-28 
draft-ietf-teas-scheduled-resources-06
Christer Holmberg  Telechat  None   draft-ietf-core-cocoa-03
Dale WorleyTelechat  2018-02-20 draft-ietf-tram-stunbis-16 *
Dale WorleyTelechat  2018-01-26 
draft-ietf-mmusic-trickle-ice-sip-14 *
Peter Yee  Telechat  2018-03-06 draft-ietf-6lo-rfc6775-update-15 *

For telechat 2018-04-19

Reviewer   Type  LC end Draft
Stewart Bryant Telechat  2018-02-02 
draft-ietf-bmwg-sdn-controller-benchmark-term-09 *
Stewart Bryant Telechat  2018-02-02 
draft-ietf-bmwg-sdn-controller-benchmark-meth-08 *
Linda Dunbar   Telechat  2018-02-14 
draft-ietf-mmusic-sdp-bundle-negotiation-49 *

Last calls:

Reviewer   Type  LC end Draft
Linda Dunbar   Last Call 2018-03-12 draft-ietf-tokbind-https-12
Francis Dupont Last Call 2018-03-16 draft-housley-suite-b-to-historic-04
Roni Even  Last Call 2018-03-30 draft-ietf-core-senml-13
Joel Halpern   Last Call 2018-04-02 draft-ietf-uta-smtp-tlsrpt-17

* Other revision previously reviewed
** This revision already reviewed

Next in the reviewer rotation:

  Paul Kyzivat
  Matthew Miller
  Pete Resnick
  Dan Romascanu
  Meral Shirazipour
  Robert Sparks
  Dale Worley
  Peter Yee
  Jari Arkko
  Stewart Bryant

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 last call review of draft-ietf-core-object-security-08

[Alissa Cooper]

Joel, thanks for your review. Göran, thanks for addressing Joel’s comment. 
Unfortunately I ran out of time to review this document before the telechat.

Alissa

> On Feb 23, 2018, at 9:40 AM, Joel M. Halpern  wrote:
> 
> Yes, that is what I was looking for.
> Thank you,
> Joel
> 
> On 2/23/18 9:38 AM, Göran Selander wrote:
>> How about this (see the last and third to last edit):
>> https://github.com/core-wg/oscoap/commit/8f277d83
>> where the reference is made to COSE instead of AEAD?
>> Best
>> Göran
>> On 2018-02-23 15:32, "Joel Halpern Direct" 
>> wrote:
>>> I guess it is up to you.  Personally, I like the idea of the verify
>>> description including some reference to how one actually does verify.
>>> I will leave it to the authors and WG to decide what degree of clarity
>>> is called for here.
>>> 
>>> Yours,
>>> Joel
>>> 
>>> On 2/23/18 9:30 AM, Göran Selander wrote:
 Hi Joel,
 
 Thanks for quick feedback, inline.
 
 On 2018-02-23 14:59, "Joel M. Halpern"  wrote:
 
> In terms of my concerns, if Step 7 said "Verify and Decrypt the COSE
> object using the Recipient Key as per RFC 5116 Section 2.2" that would
> fill in the confusion for this reader.
 
 Since the AEAD is used throughout the draft, in particular in other
 parts
 of this section I’m thinking that maybe we should add RFC 5116 to the
 list
 of specifications following "Readers are expected to be familiar with”
 in
 Section 1.1. Would that address your comment?
 
 Thanks
 Göran
 
 
 
> 
> Yours,
> Joel
> 
> On 2/23/18 5:26 AM, Göran Selander wrote:
>> Hi Joel,
>> 
>> Thanks for your review. Comments inline.
>> 
>> 
>> On 2018-02-22 04:51, "Joel Halpern"  wrote:
>> 
>>> Reviewer: Joel Halpern
>>> Review result: Ready with Nits
>>> 
>>> 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-core-object-security-08
>>> Reviewer: Joel Halpern
>>> Review Date: 2018-02-21
>>> IETF LC End Date: 2018-03-02
>>> IESG Telechat date: 2018-03-08
>>> 
>>> Summary: This document is ready for publication as a Proposed
>>> Standard
>>> RFC
>>> 
>>> Major issues: N/A
>>> 
>>> Minor issues:
>>>  In section 8.2 on verifying the request, step 5 says to
>>> "compose"
>>> the
>>>  Additional Authentication Data.  I would have expected it to be
>>> "verify"
>>>  the Additional Authentication Data.  I could imagine that the
>>> verification
>>>  consists of composing what it should be, and then comparing with
>>> what
>>> is
>>>  received.  But I do not see the comparison step.  is it
>>> implicit in
>>> some
>>>  other step?  This occurs again in 8.4, so I presume I am simply
>>> missing
>>>  something.  This may suggest some clarification could be useful.
>> 
>> The AAD is indeed “composed" both on encrypting and decrypting side
>> from
>> data which needs to be known to the endpoint at the time when the AEAD
>> operation is performed. The authenticated decryption process is
>> described
>> in:
>> 
>> https://tools.ietf.org/html/rfc5116#section-2.2
>> 
>> So the verification consists of feeding the input, including the AAD,
>> to
>> the authenticated decryption which calculates the plain text or FAIL,
>> and
>> a failure may be - but is not necessarily - caused by wrong AAD.
>> 
>> The AD review also indicated that we should move the reference to RFC
>> 5116
>> to an early section in the draft and that change is already included
>> in
>> the latest version on the CoRE WG Github.
>> 
>> 
>> Best regards
>> Göran
>> 
 
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

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