Re: [TLS] A new consensus call on ALPN vs NPN (was ALPN concerns)

Bill Frantz <frantz@pwpconsult.com> Thu, 12 December 2013 21:53 UTC

Return-Path: <frantz@pwpconsult.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C22D81AE502 for <tls@ietfa.amsl.com>; Thu, 12 Dec 2013 13:53:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NbnXgftvB52h for <tls@ietfa.amsl.com>; Thu, 12 Dec 2013 13:53:08 -0800 (PST)
Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 706341AD694 for <tls@ietf.org>; Thu, 12 Dec 2013 13:53:08 -0800 (PST)
Received: from [173.75.83.15] (helo=Williams-MacBook-Pro.local) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <frantz@pwpconsult.com>) id 1VrEBp-0001af-DR; Thu, 12 Dec 2013 16:53:01 -0500
Date: Thu, 12 Dec 2013 13:52:56 -0800
From: Bill Frantz <frantz@pwpconsult.com>
To: "<tls@ietf.org>" <tls@ietf.org>
X-Priority: 3
In-Reply-To: <CAFewVt4mF_xztqANmC-EDQjnCFgTuNc3F_UHxcinPpPtSbPA_g@mail.gmail.com>
Message-ID: <r422Ps-1075i-C9CF406E1DCB41AA90371BC7446FD122@Williams-MacBook-Pro.local>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Mailsmith 2.3.1 (422)
X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79066ce9d84b5219edf86d03f6cb15cb56350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 173.75.83.15
Subject: Re: [TLS] A new consensus call on ALPN vs NPN (was ALPN concerns)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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 Dec 2013 21:53:11 -0000

On 12/11/13 at 3:59 PM, brian@briansmith.org (Brian Smith) wrote:

>On Wed, Dec 11, 2013 at 11:14 AM, Bill Frantz <frantz@pwpconsult.com> wrote:
>>We should not insist that a client using the new protocol be able to connect
>>of a tls 1.2 server (or below) as a result of tls level negotiation. The
>>fallback mechanisms in most browsers can cover that need. The extra design
>>freedom will allow us to easily encrypt data that was previously sent in the
>>clear without worrying about backward compatibility.
>
>I think us browser people might have unintentionally misled people
>about our eagerness to reconnect with downgraded security properties.
>I, and other browser people I know, consider it mis-feature, and we'd
>love to find a way to stop doing it. So, trying to connect via "TLS
>2.0" that has better security/privacy properties, and then insecurely
>falling back to TLS 1.2 with worse security/privacy properties, is
>something that I'd definitely want to avoid.

Obviously, considering the code that is now being shipped, most 
browser people have held their noses and gone down the retry at 
lower level path. Functionality over the best security.

Of course until quite recently people thought that SSL3 was 
reasonably secure, so the odor wasn't quite as bad.


>...
>
>Besides being an ineffective security/privacy measure (since any MitM
>could induce the fallback to from "TLS 2.0" to TLS 1.2), it would also
>be unacceptable due to the added latency for any site that hadn't
>upgraded to "TLS 2.0." We are many years away from that becoming a
>viable thing for us to do.

I view the added latency as a plus. It gives sites an incentive 
to upgrade.

<rant>
We are now in the situation where much of the end-user security 
software is automatically upgraded regularly. The server side 
software is never* upgraded. To improve net security this 
situation has to change.

* Yes, it's a bit strong. Google, Facebook etc. are leaders in 
improving security. However, never applies to the embedded 
devices using HTTPS for configuration.
</rant>

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | If the site is supported by  | Periwinkle
(408)356-8506      | ads, you are the product.    | 16345 
Englewood Ave
www.pwpconsult.com |                              | Los Gatos, 
CA 95032