Subject: [Uta] Fwd: New Version Notification for draft-ietf-uta-tls-bcp-02.txt

From: Yaron Sheffer <[email-masked]>
Date: Sun, 24 Aug 2014 22:53:21 +0300

Dear UTA folks,

This is a relatively large revision. The change log:

- Rearranged some sections for clarity and re-styled the text so that 
normative text is followed by rationale where possible.
- Removed the recommendation to use Brainpool curves.
- Triple Handshake mitigation.
- MUST NOT negotiate algorithms lower than 112 bits of security.
- MUST implement SNI, but use per local policy.
- Changed SHOULD NOT negotiate or fall back to SSLv3 to MUST NOT.
- Added hostname validation.
- Non-normative discussion of DH exponent reuse.

Thanks,
	Yaron

-------- Forwarded Message --------
Subject: New Version Notification for draft-ietf-uta-tls-bcp-02.txt
Date: Sun, 24 Aug 2014 12:49:11 -0700
From: [email-masked]
To: Yaron Sheffer <[email-masked]>, Ralph Holz 
<[email-masked]>, Peter Saint-Andre <[email-masked]>, Ralph Holz 
<[email-masked]>, Peter Saint-Andre <[email-masked]>, Yaron Sheffer 
<[email-masked]>

A new version of I-D, draft-ietf-uta-tls-bcp-02.txt
has been successfully submitted by Yaron Sheffer and posted to the
IETF repository.

Name:		draft-ietf-uta-tls-bcp
Revision:	02
Title:		Recommendations for Secure Use of TLS and DTLS
Document date:	2014-08-24
Group:		uta
Pages:		17
URL: 
http://www.ietf.org/internet-drafts/draft-ietf-uta-tls-bcp-02.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-uta-tls-bcp/
Htmlized:       http://tools.ietf.org/html/draft-ietf-uta-tls-bcp-02
Diff:           http://www.ietf.org/rfcdiff?url2=draft-ietf-uta-tls-bcp-02

Abstract:
    Transport Layer Security (TLS) and Datagram Transport Security Layer
    (DTLS) are widely used to protect data exchanged over application
    protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP.  Over the
    last few years, several serious attacks on TLS have emerged,
    including attacks on its most commonly used cipher suites and modes
    of operation.  This document provides recommendations for improving
    the security of both software implementations and deployed services
    that use TLS and DTLS.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 25 Aug 2014 16:13:43 +0200

Reference [I-D.ietf-uta-tls-attacks] is outdated
(draft-ietf-uta-tls-attacks-02 is out, here you still point to 01.)

draft-ietf-uta-tls-bcp-02 should be changed to forbid unsecure use of the
truncated_hmac TLS extension (http://www.isg.rhul.ac.uk/~kp/mee-comp.pdf).
 You're placing anything like this in "SHOULD NOT" land, but some if it
needs to be a clear "MUST NOT".

Bodo

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 25 Aug 2014 19:54:38 +0300

> (draft-ietf-uta-tls-attacks-02 is out, here you still point to 01.)

This is strange. It means the bibxml server is a few days out of date.

>
> draft-ietf-uta-tls-bcp-02 should be changed to forbid unsecure use of
> the truncated_hmac TLS extension
> (http://www.isg.rhul.ac.uk/~kp/mee-comp.pdf).  You're placing anything
> like this in "SHOULD NOT" land, but some if it needs to be a clear "MUST
> NOT".

Do you mean we need to forbid *any* use of "truncated_hmac"? Do you 
think this is a case of MUST NOT?

Thanks,
	Yaron

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 25 Aug 2014 23:09:37 +0200

> Do you mean we need to forbid *any* use of "truncated_hmac"? Do you think
> this is a case of MUST NOT?

Those cases that are insecure as shown by that paper should be a MUST NOT.
 Any other use of truncated_hmac is already a SHOULD NOT (because
truncated_hmac doesn't apply to AEAD ciphersuites), which seems adequate.

Bodo

---

From: Ralph Holz <[email-masked]>
Date: Wed, 27 Aug 2014 23:41:23 +0200

Dear list,

Two remarks from me for now - maybe the second one is minor:

1) Section 6.5 - OCSP stapling as per RFC6066 has a second short-coming:
it does not protect intermediate certs. RFC6961 fixes this.
Unfortunately, I am not sure how many implementations already implement
it (it's from 2013).

Still, if we're going to have stapled OCSP in there, I'd call support
for both RFC6066 and 6961 at least a SHOULD. Opinions?

2) Section 3.3 - We write SHOULD for HSTS. We could think about a MUST -
it seems to be better supported by clients now, is relatively easily
enabled, and its existence ought not harm any clients that do not
understand it. I don't have strong feelings about it, though.

Ralph

On 08/24/2014 09:53 PM, Yaron Sheffer wrote:
> URL: http://www.ietf.org/internet-drafts/draft-ietf-uta-tls-bcp-02.txt
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta

-- 
Ralph Holz
I8 - Network Architectures and Services
Technische Universität München
http://www.net.in.tum.de/de/mitarbeiter/holz/
Phone +49.89.289.18043
PGP: A805 D19C E23E 6BBB E0C4  86DC 520E 0C83 69B0 03EF

---

From: Leif Johansson <[email-masked]>
Date: Thu, 28 Aug 2014 06:57:14 +0200

> understand it. I don't have strong feelings about it, though.

I assume you're talking about a MUST implement, not MUST deploy?

---

From: Ralph Holz <[email-masked]>
Date: Thu, 28 Aug 2014 11:51:24 +0200

Hi,

> I assume you're talking about a MUST implement, not MUST deploy?

Yes, at the minimum. The MUST for implement would only mean that
additional HTTP headers must be supported by Web server software. I
think all popular implementations do that?

The MUST for deploy would mean adding the header to the configuration. I
am slightly in favour of that, but site operators might be afraid of
what happens in case something goes wrong in their SSL config and no-one
can access the site. Then again, it would be a real incentive to deploy
SSL correctly from the start and take care the site actually works.

Ralph

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 29 Aug 2014 17:24:31 +0300

To clarify, the current version of the draft has the whole issue of cert 
revocation in the "discussion" part of the draft, with no normative text 
at all 
(http://tools.ietf.org/html/draft-ietf-uta-tls-bcp-02#section-6.5). The 
conclusion of that section is: "The current consensus appears to be that 
OCSP stapling, combined with a "must staple" mechanism similar to HSTS, 
would finally resolve this problem; in particular when used together 
with the extension defined in [RFC6961].  But such a mechanism has not 
been standardized yet."

Thanks,
	Yaron