Subject: [Uta] I-D Action: draft-ietf-uta-rfc7525bis-03.txt

From: [email-masked]
Date: Mon, 25 Oct 2021 04:52:10 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Using TLS in Applications WG of the IETF.

        Title           : Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
        Authors         : Yaron Sheffer
                          Ralph Holz
                          Peter Saint-Andre
                          Thomas Fossati
	Filename        : draft-ietf-uta-rfc7525bis-03.txt
	Pages           : 35
	Date            : 2021-10-25

Abstract:
   Transport Layer Security (TLS) and Datagram Transport Layer Security
   (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 their
   modes of operation.  This document provides recommendations for
   improving the security of deployed services that use TLS and DTLS.
   The recommendations are applicable to the majority of use cases.

   This document was published as RFC 7525 when the industry was in the
   midst of its transition to TLS 1.2.  Years later this transition is
   largely complete and TLS 1.3 is widely available.  Given the new
   environment, we believe new guidance is needed.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-uta-rfc7525bis/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-uta-rfc7525bis-03.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-uta-rfc7525bis-03

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 25 Oct 2021 14:58:32 +0300

This is a relatively small rev from -02, with more clarity on key limits and mitigation of Triple Handshake (extended_master_secret). 

Our open issues are at https://github.com/yaronf/I-D/issues - fell free to comment or open new ones.

Thanks!

	Peter, Thomas and Yaron

On 10/25/21, 14:53, "[email-masked] on behalf of [email-masked]" <[email-masked] on behalf of [email-masked]> wrote:

    Abstract:

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

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 25 Oct 2021 17:05:50 +0300

On Mon, Oct 25, 2021 at 02:58:32PM +0300, Yaron Sheffer wrote:
> This is a relatively small rev from -02, with more clarity on key
> limits and mitigation of Triple Handshake (extended_master_secret). 
> 

"It is also RECOMMENDED that clients abort the handshake if the server
acknowledges the SNI hostname with a different hostname than the one
sent by the client."

AFAIK, this can not happen. From RFC 6066:

"In this event, the server SHALL include an extension of type
'server_name' in the (extended) server hello.  The 'extension_data'
field of this extension SHALL be empty."

So the server can not acknowledge name different from what the
client sent. Then there are some servers that do take client server_name
into account, but fail to acknowledge that.

Server certificate (if raw public keys are not used) is supposed to
be valid for the SNI hostname, but it can be valid for other names
as well. So it is not really acknowledgement for the SNI hostname.
However, it would make sense for clients to abort if server certificate
is not valid for sent SNI hostname.

-Ilari