Thanks for the answers. I will initiate IETF last call of this draft now.
Phillip, please update the writeup regarding the intentional reference to the
obsoleted TCP-AO.
Cheers
Magnus
On Thu, 2019-09-26 at 08:01 +0000, Magnus Westerlund wrote:
> Hi,
>
> Sorry about the delay in getting the AD review done. Below are my comments and
> questions. Note the questions are truly questions and after answering we can
> discuss if there needed to be any changes or not.
>
>
> 1. Section 4.1: Is there a reason to use TLS 1.2 specification (RFC5246)
> rather than TLS 1.3 as the general reference?
>
> 2. Comment on the writeup: Considering that ID nits results in the below
> relevant references warning I would expect some comment in the writeup if they
> are intentional. If not please update the references. If they are intentional,
> please update the writeup to note them.
>
>
>
> -- Obsolete informational reference (is this intentional?): RFC 2385
> (Obsoleted by RFC 5925)
>
> -- Obsolete informational reference (is this intentional?): RFC 4474
> (Obsoleted by RFC 8224)
>
> -- Obsolete informational reference (is this intentional?): RFC 5246
> (Obsoleted by RFC 8446)
>
> -- Obsolete informational reference (is this intentional?): RFC 7539
> (Obsoleted by RFC 8439)
>
> 3. Section 4.1.2: Is there a point to mention that TLS forward secrecy are
> dependent on cipher suit for the key exchange and not ensured prior to 1.3?
>
> 4. Section 4.1.2: Second to last paragraph: Broken reference to DTLS 1.3
> draft: “(Note that this extension is only supported in
> DTLS 1.2 and 1.3 {{?I-D.ietf-tls-dtls13}.)”
>
> 5. Section 4.3.3: “QUIC transport relies on UDP.” Although QUIC is targeting
> UDP as its main deployment vessel, isn’t QUIC in fact dependent on a
> unreliable datagram service. But, maybe writing UDP is more straightforward?
>
> 6. Section 4.5.4: When it comes to variants of SRTP. I think referencing RFC
> 7201 would actually be reasonable, as in the many different options hide some
> transport security options that so far is not discussed in this document. Like
> securing multicasted / broadcasted RTP.
>
> 7. Section 4.5.4: So are ZRTP included as variant because it provides new
> security features? Is that session continuity, or something else?
>
> 8. Section 11: There are a number of references here that I don’t think meets
> the requirement for references. These are the ones that only have a title and
> n.d. All these could include a URL a date when these pages was visited and
> contained the information you want to reference.
>
>
> Cheers
>
> Magnus Westerlund
--
Cheers
Magnus Westerlund
----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB | Phone +46 10 7148287
Torshamnsgatan 23 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email protected]
----------------------------------------------------------------------
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
