Re: [Taps] AD review of draft-ietf-taps-transport-security-08

[Magnus Westerlund <[e-mail]>]

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  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------