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

From: Yaron Sheffer <[email-masked]>
Date: Sun, 21 Sep 2014 23:15:20 +0300

Dear UTA members,

We have just issued a new version of the BCP. Thanks to all who 
contributed useful criticism or actual text.

Change log:

o Disallow truncated HMAC.	
o Applicability to DTLS.	
o Some more text restructuring.	
o Host name validation is sometimes irrelevant.	
o HSTS: MUST implement, SHOULD deploy.	
o Session identities are not protected, only tickets are.	
o Clarified the target audience.

Thanks,
	Yaron

-------- Forwarded Message --------
Subject: New Version Notification for draft-ietf-uta-tls-bcp-03.txt
Date: Sun, 21 Sep 2014 13:09:20 -0700
From: [email-masked]
To: Yaron Sheffer <[email-masked]>, Peter Saint-Andre 
<[email-masked]>, Ralph Holz <[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-03.txt
has been successfully submitted by Yaron Sheffer and posted to the
IETF repository.

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

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: Viktor Dukhovni <[email-masked]>
Date: Mon, 22 Sep 2014 22:31:47 +0000

> o Host name validation is sometimes irrelevant.	

While it is true that insecurely obtained hostnames are not suitable
"reference identifiers" for peer authentication, it is perhaps not
enough to suggest that the hostname should not be used, the text
perhaps ought to say that something else should be used instead.

However, there is another case in which name checks don't apply at
all, and that is peer authentication via DANE-EE(3) TLSA records,
in which the name to public key binding is via DNSSEC, not the
certificate payload.

> o Session identities are not protected, only tickets are.	

I'm not sure what it means for "resumption information" to be
authenticated, and who is supposed to perform this authentication.

I think what is perhaps meant is that clients (that are in the
target audience of the document) should not cache sessions for
which peer authentication (including any application peername
verification) failed at session establishment.

> o Clarified the target audience.

The acronyms SMTPS, IMAPS, POPS, XMPPS, IRCS are not introduced
anywhere.  While a few of these may in lower-case occur in
/etc/services files on some systems, I am not aware of any standard
protocol called SMTPS (I'll let others speak to the existence of
IMAPS, ...).

Also it is I think inappropriate to suggest that MTA to MTA SMTP
with STARTTLS is in scope for the intended "strict" TLS profile of
the draft.  For quite some time TLS with MTA to MTA SMTP will employ
opportunistic security, with authentication optional.

So draft applies to MUA to MSA mail submission, not MTA to MTA
mail relaying.

-- 
	Viktor.

---

From: Ralph Holz <[email-masked]>
Date: Tue, 23 Sep 2014 00:54:40 +0200

Hi,

> protocol called SMTPS (I'll let others speak to the existence of 

I agree they should be spelled out, and yes, they do not define
protocols (strictly speaking, even HTTPS specifies only a binding of
HTTP to TLS, though). But yes, point taken. In fact, the entire
subsection could be simplified to giving the scenarios and saying which
protocols are used in such cases. That would also address your second point:

> Also it is I think inappropriate to suggest that MTA to MTA SMTP with
> STARTTLS is in scope for the intended "strict" TLS profile of the
> draft.  For quite some time TLS with MTA to MTA SMTP will employ 
> So draft applies to MUA to MSA mail submission, not MTA to MTA mail
> relaying.

Ralph

-- 
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.18010
PGP: A805 D19C E23E 6BBB E0C4  86DC 520E 0C83 69B0 03EF

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 22 Sep 2014 20:03:56 -0600

> opportunistic security, with authentication optional.

Yes, this text might be a bit misleading:

    Concerning deployment, this document targets a wide
    audience, namely all deployers who wish to add authentication,
    confidentiality and data integrity to their communications.  This
    document does not address the rare deployment scenarios where one of
    these three properties is not desired.

Unauthenticated encryption is also quite common for server-to-server 
communication on the XMPP network.

Peter

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 22 Sep 2014 20:17:17 -0600

> o Some more text restructuring.

Service names other than HTTPS (e.g., SMTPS, XMPPS) are not found in the 
wild and I see no reason to invent them here.

Also, I suggest:

OLD

NEW
    document is not intended to directly address deployment scenarios
    where one of these three properties is not desired.

> o Host name validation is sometimes irrelevant.

I suggest:

OLD
    With some protocols, the host name is obtained indirectly and in an
    insecure manner, e.g.  by an insecure DNS query for an MX record.  In
    these cases, the host name SHOULD NOT be used as a trusted identity
    even when it matches the presented certificate.

NEW
    If the host name is discovered indirectly and in an insecure manner
    (e.g., by an insecure DNS query for an MX or SRV record), it SHOULD
    NOT be used as a reference identifier [RFC6125] even when it matches
    the presented certificate.  This proviso does not apply if the host
    name is discovered securely (for further discussion, see for example
    [I-D.ietf-dane-srv] and I-D.ietf-dane-smtp]).

> o HSTS: MUST implement, SHOULD deploy.

The new text says:

    o  Client and server implementations MUST support the HTTP Strict
       Transport Security (HSTS) header [RFC6797], in order to allow Web
       servers to advertise that they are willing to accept TLS-only
       clients.

I think it should say:

    o  HTTP client and server implementations MUST support the HTTP
       Strict Transport Security (HSTS) header [RFC6797], in order to
       allow Web servers to advertise that they are willing to accept
       TLS-only clients.

Since, by definition, HSTS does not apply to IMAP, POP, XMPP, and other 
non-HTTP application protocols.

> o Clarified the target audience.

Thanks, Yaron!

Peter