Re: [TLS] Next Protocol Negotiation 03

Adam Langley <agl@chromium.org> Thu, 26 April 2012 17:29 UTC

Return-Path: <agl@google.com>
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 C739721F86B6 for <tls@ietfa.amsl.com>; Thu, 26 Apr 2012 10:29:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Level:
X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 O6beGkRHjwpm for <tls@ietfa.amsl.com>; Thu, 26 Apr 2012 10:29:40 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 44D6721F86B7 for <tls@ietf.org>; Thu, 26 Apr 2012 10:29:40 -0700 (PDT)
Received: by iazz13 with SMTP id z13so2269085iaz.31 for <tls@ietf.org>; Thu, 26 Apr 2012 10:29:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-system-of-record; bh=jqS2mwCqW+2W1UmsEmtlT8B4uewrbTFioFwZP+FCybc=; b=P1Um9z/QbNkZviawmjY6k+2YpGEvSEEY7WRSjPoHaVBP0i0RON65DudDbhrhjwJASe tx0LfCcvkTtqTY/3CxIBPImSDjMrS8rR1f05Fj0sfemp29roXQRLEHbEZZsfr0Xs9A3X Q1bxRjB1Jy96CYJmQ5k12qGNGezrtlGJPOamiNJn6MBhjFXud6XrVJigxhh5M7JAD7VQ HvAhrPAPyckY0/dNqVPn7is6ReY/e+bJV6KooJhg+pezGFznuIDYwUfEfByIuSBX9jVb gZnVUrobZQ5OW+RBC06naRWNK+lmg+2HmXciNIY/HmzcqBry10NwXbZFa6lt/aoxbsG7 ePqg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-system-of-record:x-gm-message-state; bh=jqS2mwCqW+2W1UmsEmtlT8B4uewrbTFioFwZP+FCybc=; b=PjTSj5y3Yp/moGzQyf7RbQWNAJ/cKhkyXxlesJiKtj1nd8YcaXU5p1vyJtxVv+IBRM T3JvVrkeltcfiqaouRsiXwTJwYfs4lKJZQ7gdkcyuahlL0KSPPO3NVnYMLCyKyxviQGG nUUwRHBx5oIHiLgzT0PLvP2HXlsbZ2qW3ieKM7y32u3nQliYMxGimJrccI4t6r3yOvwg wgaueACBbl5mYNncOrQADK3wpda1nTtaJsBiXwwUqidBl1BT60Lf2AINjCglqR7izDNX GntSfehPn9oVOxn1UYaTQPxy1IAeaVaePCpFyGMntxGy99ddd7t9D9YKg0sFrs05uvI6 3xDg==
Received: by 10.50.186.231 with SMTP id fn7mr8166811igc.15.1335461379827; Thu, 26 Apr 2012 10:29:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.50.186.231 with SMTP id fn7mr8166800igc.15.1335461379723; Thu, 26 Apr 2012 10:29:39 -0700 (PDT)
Sender: agl@google.com
Received: by 10.231.189.95 with HTTP; Thu, 26 Apr 2012 10:29:39 -0700 (PDT)
In-Reply-To: <201204261721.q3QHL0lA014062@fs4113.wdf.sap.corp>
References: <4F9981FC.4000205@extendedsubset.com> <201204261721.q3QHL0lA014062@fs4113.wdf.sap.corp>
Date: Thu, 26 Apr 2012 13:29:39 -0400
X-Google-Sender-Auth: 5nO4bxN1oXX8npiU-KD6iOVnipk
Message-ID: <CAL9PXLwkMqyaSfDLssGH_oT5gHFeV2s64v-gTiYFH+dSq9ZvAQ@mail.gmail.com>
From: Adam Langley <agl@chromium.org>
To: mrex@sap.com
Content-Type: text/plain; charset="UTF-8"
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQnVmTwud2DtXh9lTYhRGDi0CLbuSlow5RR+wCkayACdKnN4MVlSVPf23aajT4JftMLCLJgwZGJ5DhQ5RIhScUR8LFhwojpjU5b5mxL+Hpez14QXSihhkDn5hGDq/JLsZGjydRnp
Cc: tls@ietf.org
Subject: Re: [TLS] Next Protocol Negotiation 03
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, 26 Apr 2012 17:29:40 -0000

On Thu, Apr 26, 2012 at 1:21 PM, Martin Rex <mrex@sap.com> wrote:
> Maybe we should define something similar for the encrypted part of
> the handshake, so that we don't have to add new handshake messages
> for every new feature?

Indeed, folks seem to be leaning towards wanting more generic support
for extensions under encryption. Having a "client offers, server
selects" extension exchange after the ChangeCipherSpecs is perfectly
possible, although at the cost of precluding False Starting a full
handshake. False Start isn't a real TLS feature of course, but we're
currently pondering how much we want to be able to support it, and how
much we want NPN under encryption.

Also, if there's a generic "secure" extension exchange after the CCS,
it has the same concerns as False Start. i.e. an attacker can perform
a downgrade attack on it. For False Start we say that if the
ciphersuite isn't strong enough, we simply won't do it. But having a
TLS feature switch on and off like that seems untenable.

So, in short, "still thinking".


Cheers

AGL