Thanks! I fixed those.
Paul
------ Original Message ------
From: "Shawn Emery" <shawn.emery@xxxxxxxxx>
To: "Paul E. Jones" <paulej@xxxxxxxxxxxxxx>
Cc: "secdir" <secdir@xxxxxxxx>; draft-ietf-perc-dtls-tunnel.all@xxxxxxxx; last-call@xxxxxxxx; perc@xxxxxxxx
Sent: 6/11/2021 12:20:25 AM
Subject: Re: Secdir last call review of draft-ietf-perc-dtls-tunnel-08
Thank you for incorporating the requested changes into the Security Considerations section. Looks better. A few more nits with the latest update:s/the the/the/gs/"EndpointDisconect"/"EndpointDisconnect"/s/document rely/document relies/Shawn.--On Mon, Jun 7, 2021 at 4:50 PM Paul E. Jones <paulej@xxxxxxxxxxxxxx> wrote:Shawn,
Thanks for the review. Russ also had comments on the security
considerations section. I have changed that substantially and welcome
any additional input. See these changes:
https://github.com/percwg/perc-wg/compare/paulej_ietf_lc
Paul
------ Original Message ------
From: "Shawn Emery via Datatracker" <noreply@xxxxxxxx>
To: secdir@xxxxxxxx
Cc: draft-ietf-perc-dtls-tunnel.all@xxxxxxxx; last-call@xxxxxxxx;
perc@xxxxxxxx
Sent: 6/6/2021 8:54:04 PM
Subject: Secdir last call review of draft-ietf-perc-dtls-tunnel-08
>Reviewer: Shawn Emery
>Review result: Not Ready
>
>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/!@RFC4566/RFC4566/g
>s/An value/A value/
>s/!@RFC8126/RFC8126/
>s/material This/material. This/
>
>
>
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
