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

From: Magnus Westerlund <[email-masked]>
Date: Fri, 4 Oct 2019 09:20:13 +0000

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-masked]
----------------------------------------------------------------------

---

From: "Philipp S. Tiesel" <[email-masked]>
Date: Fri, 4 Oct 2019 20:44:25 +0200

Hi,

the writeup has been updated to explain the obsolete references. - We can go ahead

> On 4. Oct 2019, at 11:20, Magnus Westerlund <[email-masked]> wrote:
> 
> Thanks for the answers. 
> 
> SE-164 80 Stockholm, Sweden | mailto: [email-masked] <mailto:[email-masked]>

AVE!
  Philipp S. Tiesel / phils…
-- 
   {phils}--->---([email-masked])--->---(http://phils.in-panik.de)----,
      wenn w eine   aube ist dn      man au dran dre en                   |
           o     Schr        an muss     hc         h   (Kurt Schwitters) |
:wq!  <----(phone: +49-179-6737439)---<---(jabber: [email-masked])----'