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

["Philipp S. Tiesel" <[e-mail]>]

Hi,

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

> On 4. Oct 2019, at 11:20, Magnus Westerlund <[e-mail]> wrote:
> 
> 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] <mailto:[e-mail]>
> ----------------------------------------------------------------------

AVE!
  Philipp S. Tiesel / phils…
-- 
   {phils}--->---([e-mail])--->---(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: [phone])---<---(jabber: [e-mail])----'