Last Call Review of draft-ietf-6tisch-architecture-21
review-ietf-6tisch-architecture-21-secdir-lc-mandelberg-2019-06-28-00

Request Review of draft-ietf-6tisch-architecture
Requested rev. no specific revision (document currently at 28)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2019-06-26
Requested 2019-06-12
Authors Pascal Thubert
Draft last updated 2019-06-28
Completed reviews Intdir Early review of -19 by Carlos Pignataro (diff)
Iotdir Early review of -19 by Eliot Lear (diff)
Rtgdir Last Call review of -21 by Andrew Malis (diff)
Tsvart Last Call review of -20 by Gorry Fairhurst (diff)
Genart Last Call review of -20 by Francis Dupont (diff)
Secdir Last Call review of -21 by David Mandelberg (diff)
Opsdir Last Call review of -22 by Qin Wu (diff)
Secdir Telechat review of -24 by David Mandelberg (diff)
Assignment Reviewer David Mandelberg
State Completed
Review review-ietf-6tisch-architecture-21-secdir-lc-mandelberg-2019-06-28
Posted at https://mailarchive.ietf.org/arch/msg/secdir/tw1aZMDZaUw-32qqI3f8XjcKLaQ
Reviewed rev. 21 (document currently at 28)
Review result Has Nits
Review completed: 2019-06-28

Review
review-ietf-6tisch-architecture-21-secdir-lc-mandelberg-2019-06-28

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

The summary of the review is Ready with nits.

The review deadline for this was really short, so I didn't have a chance 
to read this as closely as I would have liked. That said, from skimming 
the document and reading the sections that looked most interesting, it 
looks pretty good. The security considerations section covers what I 
expected it to. I have only one question/concern:

Sections 4.2.1 and 4.3.4 talk about the security of joining a network, 
and time synchronization, respectively. Do any of the security 
mechanisms in 4.2.1 rely on having an accurate clock? (E.g., to distrust 
old/expired keys.) Is time synchronization done before the join process, 
and is there any way to exploit time synchronization in order to cause a 
node to join a malicious network?