Hi Aaron,

Thanks for your review. Please see some responses below. Unfortunately your review came too late to include your points in the presentation today, feel free to raise them during the discussion.

Best,
        Yaron

On 07/22/2014 12:54 AM, Aaron Zauner wrote:
Hi *,

I'm in the process of reviewing the BCP currently and do have a couple
of open questions and remarks before submitting a patch. Please excuse
me if some of them have already been asked before on the mailing list,
although I tried to go through most of the mails, I might have missed some.

    * the document on github seems to be out of sync with the document
      that is currently available on the IETF website.

Yes, sorry about that. As Leif mentioned, the main discussion needs to be on this list.


    * I've found some typos, rhetorical flaws w.r.t phrasing throughout
      the document as well as missing information in reasoning parts. I
      would be willing to submit a patch and a related message
      explaining changes (if need be) to this list. is that acceptable?

    * the document effectively states in 1. that TLS 1.3 will obsolete
      this document. UTA should still give recommendations for legacy
      protocols that will be widely deployed on the internet. although
      faster than it used to be - TLS adoption is still very slow.

Yes, but the situation will change once 1.3 is out. An implementor will need to make a choice whether to spend time/money implementing this BCP, or spend time/money moving to 1.3, or maybe deploy 1.3 and use this draft to close any remaining issues.


    * 3.1. states that SSLv2 has "serious security vulnerabilities"
      while this is true, it does not emphasize how broken SSLv2
      actually is. how about changing the wording to "considered to be
      insecure"?

OK.


    * as for the deployment of "3%", mentioned in 3.2. - previous
      posters have pointed to the scans by j.vehent and sslpulse/qualys.
      there's also a monthly scan being conducted by h.kario of
      redhat [0].

As you point out, there are several scans (and the numbers vary between them...). We might remove the reference altogether.


    * in 3.6 disabling compression is a SHOULD. with the issues currently
      raised by attacks this has to be a MUST in my opinion. and:

    * the document does not mention issues with compression in underlying
      applications when using TLS (e.g. BREACH for HTTP).

Good point, we may need to do that.


    * 4.2: once accepted (and everything looks this way) the draft by DKG
      will obsolete parts of this section [2].

This is a point-in-time document. The DHE draft, as well as fallback SCSV, CT and pinning are important changes. When any of them is standardized and deployed at scale, some sections here will need to change. But we are not there yet.


    * currently the document provides for no reasoning as to why no ECDSA
      ciphersuites have been included. while I agree that they should be
      excluded, one should include a sentence or two on the matter. I'm
      not an expert with DSA/DSS so I can just refer to [1] and the
      sources mentioned therein.

Because VERY few servers use ECDSA certs.


    * the document currently does not mention any views for
      standardization bodies and implementors on key pinning (TACK,
      HTKP).

See above.


    * the document currently does not mention any views for
      standardization bodies and implementors on certificate
      transparency.

Ditto.


That's all for now, I'm pretty sure I'll come up with more.

Thanks for your time,
Aaron

Sources:
[0] - http://securitypitfalls.wordpress.com
[1] - http://blog.cr.yp.to/20140323-ecdsa.html
[2] - http://tools.ietf.org/html/draft-gillmor-tls-negotiated-dl-dhe



_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta


_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta

Reply via email to