[TLS] Next Protocol Negotiation - Some comments

Alfredo Pironti <alfredo.pironti@inria.fr> Thu, 12 July 2012 14:08 UTC

Return-Path: <alfredo@pironti.eu>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8004521F85C6 for <tls@ietfa.amsl.com>; Thu, 12 Jul 2012 07:08:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level:
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zUXx56--bLou for <tls@ietfa.amsl.com>; Thu, 12 Jul 2012 07:08:51 -0700 (PDT)
Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id BF73A21F85C0 for <tls@ietf.org>; Thu, 12 Jul 2012 07:08:51 -0700 (PDT)
Received: by vcqp1 with SMTP id p1so1657001vcq.31 for <tls@ietf.org>; Thu, 12 Jul 2012 07:09:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pironti.eu; s=google; h=mime-version:sender:x-originating-ip:date:x-google-sender-auth :message-id:subject:from:to:content-type; bh=hCraPpy7cpyS0tqbHV9erFYWDPyfGDFgcr7QzE6rvsg=; b=MWQEcDn7UqhYkYHeLku5HtGB5r7IjNOel2ZiEvvarOFTe2vo9T+AfMRJo0xp6hq6ms EAM5I87GDBjZK6vSrLuO4WleU64ZpcFgnJV+9C/INqGE7Yw1nkngzERxvM+XpYDkmDdE bORrOfbE6Y6kbK0SA6oQFu/E+fMSbCJjxcckQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:date:x-google-sender-auth :message-id:subject:from:to:content-type:x-gm-message-state; bh=hCraPpy7cpyS0tqbHV9erFYWDPyfGDFgcr7QzE6rvsg=; b=H5z/2SS8xLfRnImUBaQrnQrwuNr0vgidHY7BmHp9dwYDn9F+01ABU0ZyPpE114CmoV tw2RaQWM8Cdzs8y3oZemVrEu8vR24jlUcKhi9ISS7PpKHkVDy5AFGwB65Q8ywZxozKra yDoj9PpsbKoZNNxOkBXt2BrUMgJKj6ddOXyWJb9ZjVVq+rb8EJcTnYjhqsvauwTuRB3o ZAdq6IOS0WxKs8I7TPMwZpGhZL5lXcohXU1uVLAdF2U/6oNoE7dpIe45RYGMIX4WdU4r QrwPRNYMZ0b9ZPw5iCOYmIkGFQfLa7B/ubDeo9cfjEcPtKjMHOxM7GS0iYpdi4NEBr7r z1Aw==
MIME-Version: 1.0
Received: by 10.52.73.105 with SMTP id k9mr21299205vdv.72.1342102164647; Thu, 12 Jul 2012 07:09:24 -0700 (PDT)
Sender: alfredo@pironti.eu
Received: by 10.220.227.133 with HTTP; Thu, 12 Jul 2012 07:09:24 -0700 (PDT)
X-Originating-IP: [128.93.191.46]
Date: Thu, 12 Jul 2012 16:09:24 +0200
X-Google-Sender-Auth: LLnP9CN5gqfDjmalauiprO-1jl0
Message-ID: <CALR0uiKnJNFx6hF7SQNBA2=h4YUbnQPEyr0kDYbXT6Bpu7bhJg@mail.gmail.com>
From: Alfredo Pironti <alfredo.pironti@inria.fr>
To: tls@ietf.org
Content-Type: text/plain; charset=UTF-8
X-Gm-Message-State: ALoCoQnRYF9RSEGzdKBO/mOQ1dt4LcnRDftk5g48IEyn5ur8ahLdYDQaGPKVfrxcXGetsia3xHy1
Subject: [TLS] Next Protocol Negotiation - Some comments
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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/options/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: Thu, 12 Jul 2012 14:10:44 -0000

Hello all,

It seems to me that the NPN extension is vulnerable to some known
limited version/ciphersuite rollback attack, which was affecting, for
example, the proposed False-Start protocol variation [1].

Briefly, suppose a MItM wishes to know which 'selected_protocol' the
client is sending to the server. He could downgrade protocol
version/ciphersuite in the server hello, let the client send its
encrypted "EncryptedExtensions" message, and then let the session
fail. Decrypting the message once could be enough to spot that the
server is offering a specific 'selected_protocol' (or at least that
the client believes the server can offer it, even if not advertised),
and so ban the server in the future.

If we accept this weakness, I believe it would be at least worth
mentioning it in section 6.

On a related topic, the EncryptedExtension message is padded, to avoid
leaking the length of next-protocol name. I would add an
implementation caveat here. Note that handshake messages can be
fragmented. In particular, if an implementation prepares the
selected_protocol field and sends it to the record, then prepares the
padding field and sends it to the record, we may end up with two
encrypted fragments where the first reveals the length of the
selected_protocol field. An implementation should ensure this message
is not fragmented in the above way (or not fragmented at all). I
believe it's quite unlikely implementations out there would behave
like this, but again, we may want to be explicit on this.

Finally, if I was to implement this extension, I would not know what
to do in case of errors. For example, if I'm the server, and I receive
an unsupported 'selected_protocol' from the client, what should I do?
Send an alert (which one)?

Cheers,
Alfredo

[1] http://www6.ietf.org/mail-archive/web/tls/current/msg06933.html