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

From: "Stephen Farrell" <[email-masked]>
Date: Mon, 16 Feb 2015 13:40:28 -0800

Stephen Farrell 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:
----------------------------------------------------------------------

I've a bunch of nits below. The only non-bit is whether or
not this has recently been compared to bettercrypto.org.
Doing so again would be a fine thing if not.

- abstract & intro: nit: maybe s/and modes of
operation/and their modes of operation/ might be better,
as modes are defined by ciphersuites

- intro: maybe s/are/have been/ when you say CBC and RC4
are most common - that's changing fairly quickly

- intro: maybe s/will have/should have/ fewer vulns. when
deploying TLS1.3 - we can't control code quality

- 3.2: SSL stripping could do with a reference maybe

- 3.3: If it is true that compression attacks require the
attacker to control the traffic, then saying so would be
good, but only if there's an easily understood way to
phrase that, and I can't think of one right now;-)

- 3.6: add a reference to where SNI is defined (that's RFC
6066, section 3 I think?)

- section 4: would a reference to bettercrypto.org be good
here - they have specific configs one can use to implement
these recommendations (or at least I hope they do!)

- 4.1: I forget if the WG discussed adding a SHOULD NOT
for RSA key transport. I think that'd be a fine addition,
along with a statement that the justification is the lack
of PFS.

- 4.2.1: nitty, nit, nit: they MTI acronym should be
defined on 1st use, not 2nd:-)

- 4.4: "negotiated parameters" reads somewhat ambiguously
as it could be read to mean chinese menu, and I don't
think that's what you want

- 7.1: did anyone compare this text to the "most dangerous
code" paper? [1] [1]
http://dl.acm.org/citation.cfm?id=2382204

- 7.3: "aka PKIX certificates" isn't correct, I'd delete
the phrase (but leave the ref to 5280) both times

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 16 Feb 2015 18:27:25 -0700

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

Those make sense.

> - 3.2: SSL stripping could do with a reference maybe

The companion document, RFC 7457, contains a plethora of references and 
we hope that people read that in conjunction with this BCP. But a 
cross-reference can't hurt.

> phrase that, and I can't think of one right now;-)

We'll see what we can come up with.

> 6066, section 3 I think?)

Correct.

> these recommendations (or at least I hope they do!)

Perhaps Section 5 is a better place from which to point folks?

> for RSA key transport.

I don't recall discussion on that topic.

> I think that'd be a fine addition,

Yes, that's consistent with consensus calls in the TLS WG. The authors 
will put together some proposed text.

> think that's what you want

Perhaps it would be better to say "Elliptic Curve DHE with a MAC 
algorithm stronger than HMAC-SHA1 [RFC5289]" (I don't think we need to 
mention CBC vs. GCM here).

> http://dl.acm.org/citation.cfm?id=2382204

I have not.

> - 7.3: "aka PKIX certificates" isn't correct,

Oops, that's what we called them in RFC 6125.

> I'd delete

How about "often called PKIX certificates"?

Peter

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

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 16 Feb 2015 18:27:25 -0700

Those make sense.

Correct.

I have not.

Peter

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

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 17 Feb 2015 09:50:47 -0700

A few more notes inline. I will need to check some of the proposed text 
with my co-authors.

> Perhaps Section 5 is a better place from which to point folks?

I found a good place in Section 4.2:

    Typically, in order to prefer these suites, the order of suites needs
    to be explicitly configured in server software (see [BETTERCRYPTO]
    for helpful deployment guidelines).  It would be ideal if server
    software implementations were to prefer these suites by default.

> will put together some proposed text.

Here is proposed text:

    o  Implementations SHOULD NOT negotiate cipher suites based on RSA
       key transport, a.k.a. "static RSA".

       Rationale: These cipher suites, which have assigned values
       starting with the string "TLS_RSA_WITH_*", have several drawbacks,
       especially the fact that they do not support forward secrecy.

>> the phrase (but leave the ref to 5280) both times

That seems fine to me now.

Peter

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

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 17 Feb 2015 09:50:47 -0700

Here is proposed text:

Peter

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

---

From: Ralph Holz <[email-masked]>
Date: Wed, 18 Feb 2015 21:37:13 +1100

Hi,

I went through the document provided by bettercrypto, although I could
invest only so much time.

Primary differences:

* Their application scenario is slightly different - limited to business
devices and openssl on the one hand, extended to all Interfacing services
and "common services" on the other. Compatibility is an explicit concern.
They recommend several different cipher strings and assess them by their
strength.

* Furthermore, they include opportunistic security explicitly for SMTP and
similar protocols. We do not do that.

* They recommend PFS algorithms, as do we.

* They include Elliptic Curve algorithms, but in the openssl string they
are in a position after normal DHE. Our document prefers ECDHE, then DHE.

* Their view on AES-GCM and SHA2 is similar to ours. They do add CAMELLIA
as a cipher.

* They also rule out RC4 and MD5.

* From the document, one can tell that they are suspicious of DSA at 1024
bit - this is the same in our document.

Their document is very nice as it includes sample configurations for many
setups.

Ralph

---

From: Ralph Holz <[email-masked]>
Date: Wed, 18 Feb 2015 21:37:13 +1100

Hi,

Primary differences:

Ralph

---

From: Ralph Holz <[email-masked]>
Date: Wed, 18 Feb 2015 21:44:46 +1100

Hi,

> http://dl.acm.org/citation.cfm?id=2382204
It's been a long time that I've read the paper. I've just skimmed through
it now (and shame on ACM for the paywall). I think our text is consistent
with the findings from the paper, namely that "TLS implementations
frequently do not validate host names", and this is left to developers. The
paper has a long list of vulnerable implementations; our advice is to check
with certain RFCs that describe how to do proper validation in a given
context.

Ralph

---

From: Ralph Holz <[email-masked]>
Date: Wed, 18 Feb 2015 21:44:46 +1100

Hi,

Ralph