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

[Christopher Wood <[e-mail]>]

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.)

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?

   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?

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?

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?)

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.

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