Hi Martin,
Thanks for raising this issue. Here is a start at proposed text (to be
placed in a new subsection within Section 3 entitled "Multi-Server
Deployments")...
###
Deployments that involve multiple servers or services can increase the
size of the attack surface for TLS. Two scenarios are of interest:
1. Deployments in which multiple services handle the same domain name
(e.g., foo.example.org) via different protocols (e.g., HTTP and IMAP).
In this case an attacker might be able to direct a connecting endpoint
to the service offering a protocol that provides weaker security or that
is more easily exploitable (see [ALPACA] for more detailed information
about this class of attacks). To mitigate this threat, service providers
SHOULD deploy ALPN and to the extent possible ensure that multiple
services handling the same domain name provide equivalent levels of
security that are consistent with the recommendations in this document.
2. Deployments in which multiple servers providing the same service
(e.g., www.example.com) have different TLS configurations. In this case,
an attacker might be able to direct a connecting endpoint to a server
with a TLS configuration that is more easily exploitable (see [DROWN]
for more detailed information about this class of attacks). To mitigate
this threat, service providers SHOULD ensure that all servers providing
the same service provide equivalent levels of security that are
consistent with the recommendations in this document.
###
Feedback is welcome.
Peter
On 5/27/22 5:33 AM, Yaron Sheffer wrote:
Thanks! Opened https://github.com/yaronf/I-D/issues/350
Yaron
On 5/27/22, 09:21, "Martin Thomson" <m...@lowentropy.net> wrote:
I made some comments in discussion of 6125bis that I think this document
should address.
Basically, the document would benefit from a discussion on multi-server
deployments in a few arrangements:
* deployments where multiple servers speak for the same names, but with
different protocols. ALPACA showed us that cross-protocol confusion,
particularly for protocols that do not define the use of ALPN, can be exploited
by directing protocols toward endpoints that use different protocols
* deployments where multiple servers and services with overlapping names
that have different TLS configurations. DROWN showed us that the security of
these servers depends on the *weakest* server configuration. If the weak
instance can be attacked, that affects all services that share the same name.
This depends a little on the nature of the attack. An attack like this can
render ALPN protections useless.
See also https://github.com/richsalz/draft-ietf-uta-rfc6125bis/issues/43
On Fri, May 27, 2022, at 07:26, Yaron Sheffer wrote:
> This version addresses numerous comments, mostly (but not always)
> editorial, by Francesca and Paul W.
>
> As a reminder, the document is in IETF LC until May 30.
>
> Thanks,
> Yaron
>
>
> On 5/27/22, 00:22, "uta-boun...@ietf.org on behalf of
> internet-dra...@ietf.org" <uta-boun...@ietf.org on behalf of
> internet-dra...@ietf.org> wrote:
>
>
> 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
> Peter Saint-Andre
> Thomas Fossati
> Filename : draft-ietf-uta-rfc7525bis-07.txt
> Pages : 39
> Date : 2022-05-26
>
> 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
> years, the industry has witnessed several serious attacks on TLS
and
> DTLS, including attacks on the most commonly used cipher suites
and
> their modes of operation. This document provides the latest
> recommendations for ensuring the security of deployed services
that
> use TLS and DTLS. These recommendations are applicable to the
> majority of use cases.
>
> An earlier version of 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. This document updates the guidance given the new
> environment and obsoletes RFC 7525. In addition, the document
> updates RFC 5288 and RFC 6066 in view of recent attacks.
>
>
> 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-07.html
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-uta-rfc7525bis-07
>
>
> Internet-Drafts are also available by rsync at
> rsync.ietf.org::internet-drafts
>
>
> _______________________________________________
> Uta mailing list
> Uta@ietf.org
> https://www.ietf.org/mailman/listinfo/uta
>
>
> _______________________________________________
> Uta mailing list
> Uta@ietf.org
> https://www.ietf.org/mailman/listinfo/uta
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
