Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer Security (TLS) Extensions: Extension Definitions) to Proposed Standard

<Pasi.Eronen@nokia.com> Fri, 25 September 2009 09:36 UTC

Return-Path: <Pasi.Eronen@nokia.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1DD43A6899; Fri, 25 Sep 2009 02:36:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.451
X-Spam-Level:
X-Spam-Status: No, score=-6.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xVBdoaiZSJio; Fri, 25 Sep 2009 02:36:57 -0700 (PDT)
Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 696C83A685B; Fri, 25 Sep 2009 02:36:57 -0700 (PDT)
Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n8P9bXTv018052; Fri, 25 Sep 2009 12:37:57 +0300
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Sep 2009 12:37:54 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.7]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Sep 2009 12:37:54 +0300
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Fri, 25 Sep 2009 11:37:53 +0200
From: <Pasi.Eronen@nokia.com>
To: <simon@josefsson.org>, <ietf@ietf.org>, <tls@ietf.org>
Date: Fri, 25 Sep 2009 11:37:52 +0200
Thread-Topic: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer Security (TLS) Extensions: Extension Definitions) to Proposed Standard
Thread-Index: Aco8aNmVf/LeUtrRTDWAROtLKBVd8wBV8+tQ
Message-ID: <808FD6E27AD4884E94820BC333B2DB773C09757F28@NOK-EUMSG-01.mgdnok.nokia.com>
References: <20090824140146.54C2528C1DD@core3.amsl.com> <87ab0lskpf.fsf@mocca.josefsson.org>
In-Reply-To: <87ab0lskpf.fsf@mocca.josefsson.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 25 Sep 2009 09:37:54.0182 (UTC) FILETIME=[DB5ECA60:01CA3DC3]
X-Nokia-AV: Clean
Subject: Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer Security (TLS) Extensions: Extension Definitions) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Sep 2009 09:36:58 -0000

Simon Josefsson wrote:

> I am aware that the IETF-wide last call has ended, but Daniel Black
> provided a suggestion (posted on the gnutls-devel list) for the
> Security Considerations that I agree with and believe can be
> important.  Quoting him, slightly reworded:
> 
>   also maybe 11.1. could say, in response to the last paragraph of
>   section 3, + "Server applications SHOULD validate server_name against
>   any application layer equivalent field."
> 
> The last paragraph of section 3 reads:
> 
>    If an application negotiates a server name using an application
>    protocol and then upgrades to TLS, and if a server_name extension is
>    sent, then the extension SHOULD contain the same name that was
>    negotiated in the application protocol. If the server_name is
>    established in the TLS session handshake, the client SHOULD NOT
>    attempt to request a different server name at the application layer.
> 
> It appears security relevant for the server to actual verify that the
> client do not use another server name at the application layer to
> circumvent authorization decisions.  I cannot find any MUST/SHOULD
> requirement in the document for servers to test this right now.
> 
> One attack could works like this:
> 
> 1) Client establish an client-authenticated HTTPS session with a TLS
> SNI for blog.example.org and sends a HTTP GET with a Host: header
> for internal-website.example.org.

The specification is agnostic about the upper layer protocol, so it
doesn't have any HTTPS-specific details. So strictly speaking,
something like this is allowed by the spec, and could even make sense
with some upper layer protocols (although perhaps not HTTPS).

> 2) The server TLS code authenticate and authorize the client (using the
> certificate) for use with the blog.example.org domain.  The server HTTP
> code serves the internal-website.example.org web page to the client.
>
> This system would be insecure but still compliant with RFC 4366bis as
> far as I can tell, which seems suboptimal.  Adding a requirement for
> servers to check for this attack would solve the problem.

This assumes that all TLS connections are "forwarded" to the same
"server instance" regardless of the SNI value. But it's also possible
that blog.example.org and internal-website.example.org would be, e.g.,
two server processes totally unaware of each other. And they could
even be using different upper-layer protocols (e.g. XMPP and HTTP).

But I agree that this is a detail that an implementor could
conceivably get wrong, and perhaps the spec should warn about it
(although MUST would probably be too strong -- it really depends on
the upper layer protocol).

Can you propose some text?

Best regards,
Pasi
(not wearing any hats)