Re: [Last-Call] Secdir last call review of draft-ietf-perc-dtls-tunnel-08

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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/g
s/"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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux