Subject: [Uta] Kathleen Moriarty's Yes on draft-ietf-uta-tls-bcp-09: (with COMMENT)

From: "Kathleen Moriarty" <[email-masked]>
Date: Tue, 17 Feb 2015 16:48:13 -0800

Kathleen Moriarty has entered the following ballot position for
draft-ietf-uta-tls-bcp-09: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-uta-tls-bcp/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for your work on this very helpful draft!

I just have a few comments/questions.

Section 5. Applicability statement:
Should this include application authors (mentioned in section 7.1) and
Developers who can set the defaults for implementations of TLS to help
operators that are mentioned in this applicability statement?  I see the
sentence is phrased for 'deployment recommendations', but maybe this
should also have a sentence or two on development recommendations.

Not for this draft, but this one raised a question for me.
Section 7.3: If you look at the following text:
   Unfortunately, many TLS/DTLS cipher suites were defined that do not
   feature forward secrecy, e.g., TLS_RSA_WITH_AES_256_CBC_SHA256.  This
   document therefore advocates strict use of forward-secrecy-only
   ciphers.
Should we be thinking about updates to the TLS registry to reflect this
recommendation?  That's probably not this draft, but a follow on to
provide the needed 'specification required'.  I'm sure a lot more thought
might be needed for that and maybe support for features like PFS is added
in a table if older recommendations that don't meet this are not
removed.
http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml

HTTPbis went to the trouble of creating a blacklist of cipher suites that
includes ones in the TLS registry.  They did take the MTI recommendation
that is in this draft, which is good.  See section 9.2 and appendix A.
https://datatracker.ietf.org/doc/draft-ietf-httpbis-http2/

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 17 Feb 2015 18:31:23 -0700

> http://datatracker.ietf.org/doc/draft-ietf-uta-tls-bcp/

On re-reading Section 5 earlier today during discussion with Alissa, I 
too felt that an exclusive focus on deployment by operators was a bit 
off. Perhaps it would be better to begin Section 5 like so...

###

    The recommendations of this document primarily apply to the
    implementation and deployment of application protocols that are most
    commonly used with TLS and DTLS on the Internet today.  Examples
    include, but are not limited to:

    o  Web software and services that wish to protect HTTP traffic with
       TLS.

    o  Email software and services that wish to protect IMAP, POP3, or
       SMTP traffic with TLS.

    o  Instant-messaging software and services that wish to protect XMPP
       or IRC traffic with TLS.

    o  Realtime media software and services that wish to protect SRTP
       traffic with DTLS.

###

> http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml

That sounds like a worthy effort, but I'm not volunteering to work on it.

> https://datatracker.ietf.org/doc/draft-ietf-httpbis-http2/

Blacklists aren't always the best idea:

https://pbs.twimg.com/media/B9vc0OmCMAA19Ez.jpg

;-)

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 17 Feb 2015 18:31:23 -0700

###

###

;-)

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 17 Feb 2015 20:48:44 -0500

Hi Peter,

On Tue, Feb 17, 2015 at 8:31 PM, Peter Saint-Andre - &yet <[email-masked]>
wrote:

> On re-reading Section 5 earlier today during discussion with Alissa, I too
> felt that an exclusive focus on deployment by operators was a bit off.
> Perhaps it would be better to begin Section 5 like so...
>
> ###
>
> That looks much better, thanks!

> That sounds like a worthy effort, but I'm not volunteering to work on it.

:-)

> Blacklists aren't always the best idea:

Agreed, I made the same point, but the WG didn't seem to care that
blacklists usually revert to white lists, but 10 years later.   I had the
discussion with them, but they were pretty far down the path of a blacklist
and were not convinced.  Regional algorithms and the need to support them
by the way it was setup was my best argument - will be tough for vendors to
do this in multiple regions.  I guess we'll see what happens and if problem
arise for them or not.

Oh well.  Great picture!

Thanks for your work on this and quick response!
Kathleen

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 17 Feb 2015 20:48:44 -0500

Hi Peter,

:-)

Oh well.  Great picture!

-- 

Best regards,
Kathleen