IETF Logo Mail Archive

Re: [TLS] A use of flags

David Benjamin <davidben@chromium.org> Wed, 27 March 2019 17:19 UTC

Return-Path: <davidben@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 0F5961203A7 for <tls@ietfa.amsl.com>; Wed, 27 Mar 2019 10:19:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.499
X-Spam-Level:
X-Spam-Status: No, score=-9.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 faTHehGgcL6r for <tls@ietfa.amsl.com>; Wed, 27 Mar 2019 10:19:22 -0700 (PDT)
Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (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 64D6F12033E for <tls@ietf.org>; Wed, 27 Mar 2019 10:19:22 -0700 (PDT)
Received: by mail-qt1-x833.google.com with SMTP id k2so19813019qtm.1 for <tls@ietf.org>; Wed, 27 Mar 2019 10:19:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OkJUD7Rskyg6zdE4NliXACNHH7Rx4COV6ddo0OinEQg=; b=Rqb7+vNTswTs7bQpnJP7PylKxzAlLjUyAdWxXTWYngz3qy9HhCihfR5/US3N6HhfI2 ff80nqn2SkiMFIhxQz3BTCg/uM39p4tb1Ovw/u8of541NIW0eJkeruHr8wnIIyZjSivG 0u4qg8871FTDRBB/rAfMe50bzmQKFdCLFuFMQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OkJUD7Rskyg6zdE4NliXACNHH7Rx4COV6ddo0OinEQg=; b=FAdK2eAyKaWYSccWW0MwtWEEaT8kmqUQ9bZKg+3VbcHOMLRMhQGXc/MS4V50MOFKf4 R+XeLe0MKKVdQ7k62UyjkZvZ47VMUEEAmnGZZmOsm3+hzgDxJ85tIF7X9isfeKyAOWW8 uP/aA13WUr3s6fnNdRGbDJAajGQC2dP116K7DV228UsV+B+5c6S5i0Rnmh7i1H3v22Ms W/RK5unjcypWM7N5VCPwuGk12GPZInE2JLpqPfBwj2lP7Uzt73I5ATZBQrZasqF60MGi MU0l/EmjYLTDACMKSUZ8h35AFQYXcQ/7aWxRYo2H5gOz/OYdW2Ft7Jg+XytGoJHi3sHW H7fw==
X-Gm-Message-State: APjAAAUDgGu3Ug2A3NXXC83eINFMAUoOoGK7B/gjW5CyI6RHf5+PMkzj U+gFwLPgzxI9G1P0BjiDDo6VpWQIEgQR+LemLvVT
X-Google-Smtp-Source: APXvYqz4mD8HI02tbEtatQJAT3iRaOMYVd1g9078xBZAFFysYHJe2NYjGgkaZ4ZI1VfSJG2/Z/dQEStEKQuUKXatfZw=
X-Received: by 2002:ac8:7513:: with SMTP id u19mr32864334qtq.202.1553707161273; Wed, 27 Mar 2019 10:19:21 -0700 (PDT)
MIME-Version: 1.0
References: <5199904f-8072-480c-9ef0-a64dd2d9f2b8@www.fastmail.com> <12C2FDD9-D6D6-4725-B5B0-9074603B326B@akamai.com>
In-Reply-To: <12C2FDD9-D6D6-4725-B5B0-9074603B326B@akamai.com>
From: David Benjamin <davidben@chromium.org>
Date: Wed, 27 Mar 2019 18:19:05 +0100
Message-ID: <CAF8qwaAUnSiqsUffTkXoHTr+s-BC-LxUyFK9Qp6iUpu1mvR22Q@mail.gmail.com>
To: "Salz, Rich" <rsalz@akamai.com>
Cc: Martin Thomson <mt@lowentropy.net>, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006f5f94058516a33d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/k_ImeE1XuzRRdD594E1WOefBNLE>
Subject: Re: [TLS] A use of flags
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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 Mar 2019 17:19:31 -0000

Is the concern that servers which never renegotiate and do not send any
renegotiation_info are being flagged on ratings systems? That is desired
behavior. See the final paragraph of section 4.3
<https://tools.ietf.org/html/rfc5746#section-4.3>. Those servers should be
sending an empty renegotiation_info. "I never renegotiation" is vacuously
consistent with "all my renegotiations are secure".

This is important because fixing the renegotiation issue requires either:
- The server rejects *all* extension-less renegotiations, or...
- The client rejects *all* extension-less handshakes, including initial
handshakes <https://tools.ietf.org/html/rfc5746#section-4.1>

That second point means that clients cannot protect themselves against
non-strict servers if there are any servers which do not implement at least
the minimal version of the extension. Server implementations which fail to
send the minimal renegotiation_info extension on the initial handshake
should indeed be flagged by ratings systems and fixed.

On Wed, Mar 27, 2019 at 3:39 PM Salz, Rich <rsalz@akamai.com> wrote:

> I would like to define a flag that says "no renegotiation allowed"  This
> has come up (for pre 1.3 of course) a couple of times, that while you can
> signal "defaut" or "only secure" renegotiation, you can't signal "no
> renegotiation" in a way that is visible purely on the wire, to things like
> SSLLabs ratings systems.
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

v2.23.0 | Report a Bug | By Email