IETF Logo Mail Archive

Re: [TLS] Keeping TLS extension points working

Adam Langley <agl@imperialviolet.org> Wed, 27 July 2016 19:41 UTC

Return-Path: <alangley@gmail.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 BA5BB12D8E6 for <tls@ietfa.amsl.com>; Wed, 27 Jul 2016 12:41:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 EdW3ILN-WUcJ for <tls@ietfa.amsl.com>; Wed, 27 Jul 2016 12:41:08 -0700 (PDT)
Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D12C12D8D0 for <tls@ietf.org>; Wed, 27 Jul 2016 12:41:08 -0700 (PDT)
Received: by mail-qk0-x233.google.com with SMTP id p74so43957354qka.0 for <tls@ietf.org>; Wed, 27 Jul 2016 12:41:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=QcRjEGLxY0PWxJnZNBC4OS72m+a/LF/C1RtIaAmBwnU=; b=tKbD/l/VQDcpC0rKafiD+4mOSh1Qdfa3P9t7gKP7CNYqxSn9WJK8Qd17Y5Puc+I8G7 3ZrQSORQf2q2dpwRQYNKoiBu9wgLma1jFFtJ+40HHrE/LhgJwFCEWd2SKBL4aan/CaYP 8fXD1jcGeOXnwMgNTSaB7df+W2gmse4ieC/nk/notKZkcwhoIo+HirlgGqXzHzFqAT8+ PrVDp5QUY92QemGgYnCvcil9xhzYMwiGaOR0U29L0B2u58W/efi21mfdV7UK4aCkSBUm kBB0WYlGtFYJsOwsgAFJkHs6gbMFPQ4F38+DY3PKoLBSoqNX+A5H5ZUTlJNF8HbvjQAW pnXg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=QcRjEGLxY0PWxJnZNBC4OS72m+a/LF/C1RtIaAmBwnU=; b=IGqkJvJG6TwecEVTKWR1SaphUX2ZUtlMHlGRMWhhkrz3fBdYqJTig75ebfQlscUwlN ChcgGSN1eOe8/qQvxkWKGf4G/G1QiHOp/2olk2dES5HX9Zxjt64HiAsIGAuxQ2k/Xgwf dK5c2twEWm7qpNhiH6C/iRHUu30xx2gpqPdJKoNL9YIG+GzOo3twyFsmTIoEqUxKC7Na 29JxgWiRC74UEA4IC2xpjVFkbTsBZeTDXo+8cfGZMCBIKDWYB0w4WSDMCbTiZYxY5UuB gr2gbXVyxHBkR4BrQj8IANRit3rfWDaYQM8jfWwhLNTnumsMydSxTUYU9epf2r8eveFm uGtQ==
X-Gm-Message-State: AEkoouu6PoAZ3dP6BsA6EQHn/MSQ+atXIUArubInh0UhIGiStSb7dASSe9p+lBnR5Fxhb2328lsufkYd87HXiA==
X-Received: by 10.55.16.222 with SMTP id 91mr5824180qkq.151.1469648467199; Wed, 27 Jul 2016 12:41:07 -0700 (PDT)
MIME-Version: 1.0
Sender: alangley@gmail.com
Received: by 10.200.36.199 with HTTP; Wed, 27 Jul 2016 12:41:06 -0700 (PDT)
In-Reply-To: <CALTJjxHukROs-mrMUCmX1GjmfNAHhcmcVbykJnQ7UPDDiZHUJg@mail.gmail.com>
References: <CAF8qwaCaW2Q+z_JoDqzQZaGCWJ2aqUiyK8_J8_CO4Ck_cqtaSA@mail.gmail.com> <0B0C11B8-CC4A-46C4-A134-881A41005502@sn3rd.com> <CAF8qwaARvrFKhBUi10rEEUWpito3n4OWXuK5JH0ZO4gU6rzK5w@mail.gmail.com> <CALTJjxHukROs-mrMUCmX1GjmfNAHhcmcVbykJnQ7UPDDiZHUJg@mail.gmail.com>
From: Adam Langley <agl@imperialviolet.org>
Date: Wed, 27 Jul 2016 12:41:06 -0700
X-Google-Sender-Auth: mJGkfvuiNTWLgQb4UG0ChOSURmE
Message-ID: <CAMfhd9Uf6hsSba52CKzKXD_G8MTeA72pbxjnOReqVem+8TLwRQ@mail.gmail.com>
To: Wan-Teh Chang <wtc@google.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/BeR_90UsCezVjPOA6aqne0cqkp8>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Keeping TLS extension points working
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 27 Jul 2016 19:41:10 -0000

On Wed, Jul 27, 2016 at 9:50 AM, Wan-Teh Chang <wtc@google.com> wrote:
> Another source of interop failures is the firewall devices that do
> anomaly detection. Some of them will abort TLS handshakes if they see
> unknown TLS protocol versions or extensions in ClientHello. (They all
> seem to allow unknown cipher suite values.) I suspect they will treat
> the GREASE cipher suite, extension, and named group values as "normal"
> and continue to abort the handshake if they see truly new values. I
> can only hope that these network security devices are updated
> regularly.

Sadly there's very little that we can do to address aggressively bad
devices. None the less, there are several instances of unintentional
bugs in implementations that have caused problems with new-feature
deployment that I believe could have been caught with this proposal.
As ever, bugs are much less costly when found earlier and I believe
that applies equally to the developer and the world as a whole.

I have mind the cases of extension intolerance that we've thankfully
mostly managed to drive out now (because new extensions have been
added for other reasons) and the bug that led to the padding extension
(RFC 7685).

On the other hand, we've seen what's happened to the version field,
which is moving too slowly to resist rusting.


Cheers

AGL

-- 
Adam Langley agl@imperialviolet.org https://www.imperialviolet.org

v2.23.0 | Report a Bug | By Email