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 Security Area Directorate (secdir)
Deadline 2021-06-07
Requested 2021-05-24
Authors Paul Jones , Paul M. Ellenbogen , Nils Ohlmeier
I-D last updated 2021-06-06
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 Shawn M Emery
State Completed
Request Last Call review on draft-ietf-perc-dtls-tunnel by Security Area Directorate Assigned
Posted at
Reviewed revision 08 (document currently at 12)
Result Not ready
Completed 2021-06-06
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.

This draft specifies a DTLS tunneling protocol for Privacy-Enhanced RTP
Conferencing (PERC).  This entails a key exchange between the conference
end-points and the key distributor through a delegate, media distributor.

The security considerations section does exist and describes that the media
distributor does not introduce any additional security issues given that it is
just on-path with the key exchange between the endpoint and the key
distributor.  Secondly, the key material between the media distributor and key
distributor is protected through the mutually authenticated connection between
the two entities.  Thirdly, the meta data exchanged between the media
distributor and key distributor is not sensitive information, but is still
protected through the TLS connection.  I agree with the above assertions. 
Besides the concerns described in the genart review about the impact of key
material disclosure, the authors should consider the various other forms of
security issues against the protocol, such as downgrade/DoS attacks from
profile negotiation, etc.  The section could list and simply refer to the base
RFCs, 5764, 8871, etc., to provide remediation against these attacks.

General comments:

The example message flow and binary coding was helpful, thank you.

Editorial comments:

s/might might/might/
s/An value/A value/
s/material This/material.  This/