Re: [Lake] WGLC for draft-ietf-lake-reqs-01

[Göran Selander <[e-mail]>]

Hi Chris

On 2020-03-19, 17:47, "Lake on behalf of Christopher Wood" <[e-mail] on behalf of [e-mail]> wrote:

    Thanks to the authors for compiling this list of requirements. I think the
    document is in good enough shape to move forward in LAKE. I have some clarifying
    questions and comments, which I list below. I hope they're helpful.
    
    Best,
    Chris
    
    ~~~
    
    Section 2.1:
    
       Furthermore, there is no assumption of
       dependence between CoAP client/server and AKE initiator/responder
       roles, and an OSCORE context may be used with CoAP client and server
       roles interchanged as is done, for example, in [LwM2M].
    
    Does this imply that a single OSCORE context, which I assume (maybe incorrectly)
    has credentials configured, may be used in both initiator and responder roles?
    If so, should we be mindful of Selfie-style issues? (It's referenced later, so 
    perhaps not.)

GS: The result of the AKE is a single OSCORE context that can be used by both CoAP and client server roles. The client and server has unique identities to protect against reflection attacks etc.  The case with more than two parties legitimately sharing keys has been considered out of scope for the AKE, as is noted in Section 2.3. Is there something else missing?

    
    Section 2.2:
    
       The security of these
       systems can be improved by adding PFS through an AKE authenticated by
       the provisioned PSK.
    
    Is it worth mentioning the hash-based ratchet technique for improving forward 
    secrecy as an alternate?

GS: Included in Section 2.3 (Confidentiality).
    
       In order to allow for these different schemes, the AKE must support
       PSK- (shared between two nodes), RPK- and certificate-based
       authentication.
    
    2.3: 
    
       Moreover, it shall be possible for the receiving endpoint to detect a
       replayed AKE message.
    
    Why is this in the mutual authentication requirements section, and why does it
    need to be a requirement on the AKE? Would it be better to require that replays
    do no affect the security of other AKE sessions?


GS: Rephrased accordingly.
    
    2.4: 
    
       The AKE shall provide a mechanism to use the output of one handshake
       to optimize future handshakes, e.g., by generating keying material
       which can be used to authenticate a future handshake, thus avoiding
       the need for public key authentication in that handshake.
    
    Do we need to constrain how (often) endpoints use this state for future 
    connections?

GS: This is a relevant point for the solution, but I'm not sure the details needs to be specified in the requirements document? The updated text has this added sentence: "The AKE should give recommendations for frequency of re-keying, potentially dependent on the amount of data." 

  
    2.5: 
    
       PAKE and post-quantum key exchange is out of
       scope, but may be supported in a later version.
    
    Hybrid variants likely don't make sense for LAKE deployment scenarios. However, 
    it's unclear if the AKE shall allow hybrid KEX algorithms. (Perhaps this might 
    be mentioned in Section 2.8 instead?)

GS: We assumed hybrid key exchange is out scope for now for the same reason. Noted in this section.
    
    2.6: 
    
       In the case of public key identities, the AKE is required to protect
       the identity of one of the peers against active attackers and the
       identity of the other peer against passive attackers.
    
    Should we be more precise with respect to which role (initiator or responder)
    has passive or active protection? SIGMA-I and SIGMA-R differ in this respect,
    at the cost of an additional flight, so it's probably worth clarifying.

GS: This clarification was added.

    
    On Thu, Mar 19, 2020, at 9:05 AM, Stephen Farrell wrote:
    > 
    > Ping! Today's the deadline day for this. Please do try
    > get your comments in on time.
    > 
    > While this hasn't been controversial in the WG, I would
    > like to see more comment as there hasn't been enough to
    > determine if we have consensus to proceed. So some more
    > mails saying you've read this version and are ok with it
    > would be good if that's the case. Or if not, why not.
    > 
    > Thanks,
    > S.
    > 
    > On 21/02/2020 15:32, Stephen Farrell wrote:
    > > 
    > > Hi all,
    > > 
    > > The authors have asked to start a WGLC for the requirements
    > > document. [1] This mail is to start that. The deadline for
    > > comments is March 19th in order to give the authors time to
    > > prepare for discussion at the upcoming IETF meeting. Since
    > > my co-chair Mališa is a co-author of this draft, I'll be
    > > the one calling consensus on the WGLC. (If that gets tricky,
    > > I'll likely ask for help from our AD.)
    > > 
    > > If you can, it'd be great to get comments in the next week,
    > > to give the authors a chance to publish an update before
    > > the March 9th I-D cutoff, should they think that'll help
    > > us get done.
    > > 
    > > If you think this is ready, sending a comment to that
    > > effect is fine. If you think it's not ready, you do need
    > > to say why and ideally suggest changes that'd, in your
    > > opinion, make it ready.
    > > 
    > > As a reminder - our charter calls for us to park this draft
    > > after WGLC has successfully completed, and we'll not be
    > > sending this on for publication as an RFC at this time. So
    > > please try keep the focus of your comments on the meat of
    > > the content rather than on crossing all the i's and dotting
    > > all the t's:-)
    > > 
    > > Thanks,
    > > Stephen.
    > > 
    > > PS: I'll send my own comments (with no hats) in a separate
    > > mail shortly.
    > > 
    > > [1] https://tools.ietf.org/html/draft-ietf-lake-reqs-01
    > > 
    > > 
    > 
    > -- 
    > Lake mailing list
    > [e-mail]
    > https://www.ietf.org/mailman/listinfo/lake
    > 
    > Attachments:
    > * 0x5AB2FAF17B172BEA.asc
    > * signature.asc
    
    -- 
    Lake mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/lake