Hi,
> On 26. Sep 2019, at 10:01, Magnus Westerlund <[email protected]>
> 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.
Sorry, that is my fault. I checked these and discussed them with the authors,
but did not include the discussion in the writeup, as it was not clear to me
that this needs to be part of the writeup.
I wait for further comments on your review and will add a note to the writeup
on the intentional references to deprecated documents.
> 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)
necessary - the RFC is deprecated, but the mechanism still exists and is used.
Its primary use (in BGP) has been deprecated, but is still widely used.
>
> -- Obsolete informational reference (is this intentional?): RFC 4474
> (Obsoleted by RFC 8224)
This is a mistake and has been fixed on github. I did not insist on publishing
a new revision for the AD review.
>
> -- Obsolete informational reference (is this intentional?): RFC 5246
> (Obsoleted by RFC 8446)
This is intentional in Section 9, but debatable in Section 4.1
>
> -- Obsolete informational reference (is this intentional?): RFC 7539
> (Obsoleted by RFC 8439)
This is a mistake and has been fixed on github. I did not insist on publishing
a new revision for the AD review.
>
> 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
--
Philipp S. Tiesel
https://philipp.tiesel.net/
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
