Skip to main content

Last Call Review of draft-ietf-perc-dtls-tunnel-08

Request Review of draft-ietf-perc-dtls-tunnel
Requested revision No specific revision (document currently at 12)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2021-06-07
Requested 2021-05-24
Authors Paul Jones , Paul M. Ellenbogen , Nils Ohlmeier
I-D last updated 2021-05-28
Completed reviews Genart Last Call review of -08 by Russ Housley (diff)
Secdir Last Call review of -08 by Shawn M Emery (diff)
Assignment Reviewer Russ Housley
State Completed
Request Last Call review on draft-ietf-perc-dtls-tunnel by General Area Review Team (Gen-ART) Assigned
Posted at
Reviewed revision 08 (document currently at 12)
Result Almost ready
Completed 2021-05-28
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: draft-ietf-perc-dtls-tunnel-08
Reviewer: Russ Housley
Review Date: 2021-05-28
IETF LC End Date: unknown
IESG Telechat date: unknown

Summary: Almost Ready

Major Concerns:

Section 9:  The document has two different types of keying material:
   (1) keys for hop-by-hop encryption and authentication; and
   (2) keys for end-to-end encryption and authentication.
The first two paragraphs of Section 9 talks about these two types of
keying material.  I think that the discussion should be expanded by a
sentence or two to explain the security consequences of disclosure of
each of theses keying material types.

In addition, a pointer to the very extensive Security Consideration in
RFC 8871 would he helpful.

Minor Concerns:

Section 5.4 says: "Each TLS tunnel established between the media
distributor and the key distributor MUST be mutually authenticated."
Is this a requirement to use DTLS client authentication?  If so,
please be explicit.  If not, what other mechanisms for authentication
are expected?


Section 5.1, paragraph 2:   s/[!@RFC4566]/[RFC4566]/

Section 5.5, paragraph 1:
  s/MUST utilize the same version/MUST contain the same version/

Section 8, last paragraph:
   s/section 4.8 if [!@RFC8126]/Section 4.8 of [RFC8126]/

Section 9, paragraph 1:
  s/keying material This does/keying material. This does/