Subject: [Uta] Wording about SSL stripping in RFC 7457

From: Julien ÉLIE <[email-masked]>
Date: Mon, 19 Dec 2016 22:42:48 +0100

Hi all,

In RFC 7457 "Summarizing Known Attacks on Transport Layer Security (TLS) 
and Datagram TLS (DTLS)", shouldn't the second paragraph of Section 2.2 
have been placed in Section 2.1 instead?
I believe it is linked to SSL stripping, and not an injection attack.
I can open an erratum if you confirm that.

RFC 7457 currently reads:

2.1.  SSL Stripping

    Various attacks attempt to remove the use of Secure Socket Layer /
    Transport Layer Security (SSL/TLS) altogether by modifying
    unencrypted protocols that request the use of TLS, specifically
    modifying HTTP traffic and HTML pages as they pass on the wire.
    These attacks are known collectively as "SSL Stripping" (a form of
    the more generic "downgrade attack") and were first introduced by
    Moxie Marlinspike [SSL-Stripping].  In the context of Web traffic,
    these attacks are only effective if the client initially accesses a
    Web server using HTTP.  A commonly used mitigation is HTTP Strict
    Transport Security (HSTS) [RFC6797].

2.2.  STARTTLS Command Injection Attack (CVE-2011-0411)

    Similarly, there are attacks on the transition between unprotected
    and TLS-protected traffic.  A number of IETF application protocols
    have used an application-level command, usually STARTTLS, to upgrade
    a cleartext connection to use TLS.  Multiple implementations of
    STARTTLS had a flaw where an application-layer input buffer retained
    commands that were pipelined with the STARTTLS command, such that
    commands received prior to TLS negotiation are executed after TLS
    negotiation.  This problem is resolved by requiring the application-
    level command input buffer to be empty before negotiating TLS.  Note
    that this flaw lives in the application layer code and does not
    impact the TLS protocol directly.

    STARTTLS and similar mechanisms are vulnerable to downgrade attacks,
    whereby the attacker simply removes the STARTTLS indication from the
    (unprotected) request.  This cannot be mitigated unless HSTS-like
    solutions are added.

-- 
Julien ÉLIE

« Chaque fois que je vois le nombre 1, j'ai envie de l'aider à
   s'échapper… Il a constamment à ses trousses, derrière, le zéro
   qui veut le rattraper et devant, toute la mafia des grands nombres qui
   le guettent. » (Romain Gary)

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 19 Dec 2016 23:48:33 +0200

Actually I think the paragraph reads better in Sec. 2.2 because Sec. 2.1 
is all about HTTP, but we should have picked a more inclusive heading 
for 2.2, maybe "STARTTLS and the STARTTLS Command Injection Attack 
(CVE-2011-0411)".

Thanks,
	Yaron

---

From: Julien ÉLIE <[email-masked]>
Date: Wed, 21 Dec 2016 22:16:26 +0100

Hi Yaron,

> for 2.2, maybe "STARTTLS and the STARTTLS Command Injection Attack

In that case, there would be a reference problem with RFC 7525 because 
Section 3.2 of RFC 7525 mentions Section 2.1 for lack of STARTTLS (and 
not 2.2):

    The following recommendations are provided to help prevent SSL
    Stripping (an attack that is summarized in Section 2.1 of [RFC7457]):

    o  Application protocols typically provide a way for the server to
       offer TLS during an initial protocol exchange, and sometimes also
       provide a way for the server to advertise support for TLS (e.g.,
       through a flag indicating that TLS is required); unfortunately,
       these indications are sent before the communication channel is
       encrypted.  A client SHOULD attempt to negotiate TLS even if these
       indications are not communicated by the server.

-- 
Julien

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 21 Dec 2016 23:33:40 +0200

Well, I guess you're right... Thanks for detecting this error. Could you 
open an erratum please?

Thanks,
	Yaron

---

From: Julien ÉLIE <[email-masked]>
Date: Thu, 22 Dec 2016 16:06:38 +0100

Hi Yaron,

> Well, I guess you're right... Thanks for detecting this error. Could you

Yes, just done.

-- 
Julien ÉLIE