Re: [dtn] Éric Vyncke's No Objection on draft-ietf-dtn-bpsec-18: (with COMMENT)

["Eric Vyncke (evyncke)" <[e-mail]>]

Thank you 

-----Original Message-----
From: "Birrane, Edward J." <[e-mail]>
Date: Monday, 2 March 2020 at 16:56
To: Eric Vyncke <[e-mail]>, The IESG <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, Scott Burleigh <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE:  Éric Vyncke's No Objection on draft-ietf-dtn-bpsec-18: (with COMMENT)

    Éric,
    
      I have posted a new version of bpsec (bpsec-21) which I believe addresses the two outstanding comments C1 and C3.
    
    -Ed
    
    Ps. :)
    
    ---
    Edward J. Birrane, III, Ph.D.
    Embedded Applications Group Supervisor
    Space Exploration Sector
    Johns Hopkins Applied Physics Laboratory
    (W) 443-778-7423 / (F) 443-228-3839
      
    
    
    > -----Original Message-----
    > From: Eric Vyncke (evyncke) <[e-mail]>
    > Sent: Tuesday, February 18, 2020 4:18 PM
    > To: Birrane, Edward J. <[e-mail]>; The IESG
    > <[e-mail]>
    > Cc: [e-mail]; Scott Burleigh
    > <[e-mail]>; [e-mail]; [e-mail]
    > Subject: [EXT] Re: Éric Vyncke's No Objection on draft-ietf-dtn-bpsec-18:
    > (with COMMENT)
    > 
    > APL external email warning: Verify sender [e-mail] before
    > clicking links or attachments
    > 
    > Edward,
    > 
    > Thank you for considering the non-blocking comments and, hopefully,
    > improving the quality of the document. But, it seems to me that **C1 should
    > really be addressed in the revised ID (and your text should be enough).
    > 
    > I still believe that **C3 should also be addressed in this document, this is a
    > little too "hand waving" to me
    > 
    > Thank you again for the work done but I hope that the next I-D will address
    > the above
    > 
    > Regards
    > 
    > -éric
    > 
    > PS: thank you for managing to type a "É" on your keyboard __
    > 
    > On 08/02/2020, 01:42, "Birrane, Edward J." <[e-mail]>
    > wrote:
    > 
    >     Éric,
    > 
    >       Thank you for the review of BPSEC.  I have updated a new BpSec (BpSec-
    > 20) and a new interop-sc (ietf-dtn-bpsec-interop-sc-01) which addresses
    > some of your comments below.
    > 
    >       Specific comments are in-line below.  I have enumerated the comment
    > items as **C# to aid in referencing these points going forward.
    > 
    >     Edward J. Birrane, III, Ph.D.
    >     Embedded Applications Group Supervisor
    >     Principal Staff, Space Exploration Sector
    >     Johns Hopkins Applied Physics Laboratory
    >     (W) 443-778-7423 / (F) 443-228-3839
    > 
    > 
    >     -----Original Message-----
    >     From: Éric Vyncke via Datatracker <[e-mail]>
    >     Sent: Thursday, February 6, 2020 6:11 AM
    >     To: The IESG <[e-mail]>
    >     Cc: [e-mail]; Scott Burleigh
    > <[e-mail]>; [e-mail];
    > [e-mail]; [e-mail]
    >     Subject: [EXT] Éric Vyncke's No Objection on draft-ietf-dtn-bpsec-18: (with
    > COMMENT)
    > 
    >     APL external email warning: Verify sender [e-mail] before clicking
    > links or attachments
    > 
    >     Éric Vyncke has entered the following ballot position for
    >     draft-ietf-dtn-bpsec-18: 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-dtn-bpsec/
    > 
    > 
    > 
    >     ----------------------------------------------------------------------
    >     COMMENT:
    >     ----------------------------------------------------------------------
    > 
    >     Thank you for the work put into this document.
    > 
    >     I hope that this helps to improve the document,
    > 
    >     Regards,
    > 
    >     -éric
    > 
    >     -- Section 2.3 --
    >     About
    >       "a waypoint node, representing a
    >        gateway to an insecure portion of the DTN, may receive the bundle and
    >        choose to apply a confidentiality service"
    >     how could the bundle destination could recover the plain text if there is no
    > security association with the encrypting waypoint? Or is it simple hop-by-hop
    > encryption ?
    > 
    >     **C1: The WG decision was to decouple routing and security. A gateway
    > node may encrypt using a BCB and the bundle could get to the destination
    > without going through a decrypting node. In cases where this is a practical
    > problem, the WG recommends encapsulating the bundle into another
    > bundle and addressing the encapsulating bundle to a waypoint known to be
    > able to decrypt. It is not expected that this encryption is only hop-by-hop
    > encryption. If a bundle with a BCB reaches a waypoint which can (and has
    > policy to) decrypt, it is expected that the security context ID plus the values
    > of any security context parameters are sufficient to allow the waypoint to
    > decrypt.
    > 
    >     -- Section 3.2 --
    >     Why not supporting multiple integrity-checks/signatures? After all, this
    > would allow the support of more than 1 integrity check / signature algorithm?
    >     (Obvioulsy, this cannot be done for confidentility -- except if transmitting
    > multiple copies). There are some text related to this in section 3.7.
    > 
    >     **C2: The WG approach was to - later - define a security context that
    > carried these signatures as multiple security results in 1 BIB instead of
    > multiple BIBs.
    > 
    >     -- Section 8.2.4 --
    >     More details about anti-replay of a DTN message would be welcome. E.g.,
    > is the bundle age field used ?
    > 
    >     **C3: It is not clear that any additional analysis for that would change the
    > normative portions of BPSec. There may be some additional analysis here
    > using different extension blocks but that is still analysis ongoing within the
    > WG.
    > 
    >     -- Section 9.2 --
    >     This section is a list of issues with BPsec but are there other WG items
    > attempting to solve those issues ? draft-ietf-dtn-bpsec-interop-sc does not
    > seem to cover those issues.
    > 
    >     **C4: It is envisioned  that the WG will provide multiple security contexts
    > to cover multiple cases. The interop security contexts should  be going to WG
    > last call, and we will draft a security context (1 or more) relating to security on
    > the Internet for BPSec nodes that operate on the Internet.
    >