Re: [TLS] Deprecating alert levels

Joseph Salowey <joe@salowey.net> Wed, 19 October 2016 18:24 UTC

Return-Path: <joe@salowey.net>
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 F05991296EF for <tls@ietfa.amsl.com>; Wed, 19 Oct 2016 11:24:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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=salowey-net.20150623.gappssmtp.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 HyFygFkS2yhO for <tls@ietfa.amsl.com>; Wed, 19 Oct 2016 11:24:22 -0700 (PDT)
Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (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 AB27D1296D6 for <tls@ietf.org>; Wed, 19 Oct 2016 11:24:22 -0700 (PDT)
Received: by mail-qk0-x22c.google.com with SMTP id o68so51291650qkf.3 for <tls@ietf.org>; Wed, 19 Oct 2016 11:24:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7nj1dsv10vhfcx4NoXv1KQDxcc+gtbSyQu1j6ntnNyU=; b=t9CNXoYMxg8ynqsA+FofApGKH/TDCRDCRzYdam2jymS00nIeqvXieSB2z6v+2pmmOq eCHR4HZzhby/Lg4CcbAo1PAgL6i8FBXtB/2Cprjm3h7UkHAnDbU3qe6FF3IGh3K4tKGx ErGXDMEUyfQXT63GqMhbYGpKff+pYj9Gz4q5IXBfZe/NqNtiIPT4efGIJhmmWtwotp4A sks1smXKIr70bloe8EaXQ0v+5YSeEo7RWh7hyapQ8as1dpLFNLZ+8weJV5nHX08UqJki 5BU/fo+E30PS4uXOXUGzyA5C9Pqi0bP0YAN1XCMI8wxK1am59EMZAnIAuh82wGvoRS4S QbpQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7nj1dsv10vhfcx4NoXv1KQDxcc+gtbSyQu1j6ntnNyU=; b=SXOUa9vEChw3ZXLix/gXJ7GL4bp2jB9TS908OWspXNA4gHpUXPQ0/XpZIZ6iqA6fbH dJQhNk/5PqrUMqVfyZWVuVglpoy5CcmSqJmdvlHDdg5uf+mKl3QwGSJq6/k3UE68jwO5 JWXZr0EUU/hGDw+ANNJCGZcvUb4QopPYk6ac9LajfQpzjJDHFZwj+HvNg/4v4Of1XvpC yCBgXooEG1uIQlHo+UgnXFmguT3qG75tJJek56TAyNmberdx6Ra8/sO/ui8CTrsHhF15 bosySk3HkCAUwcFStYEXvQAcDSizsFPshnmeuwgw44rsoe4AE3ut3z3lqfNYed2LidCh ObJA==
X-Gm-Message-State: AA6/9Rl45aBzegoREgT+FdaZV3bkMJUCUfv5iGkTEw/QldVObKUrDlCO4WS1jR8Iel5nD6soCGFFAbTH5rMkjg==
X-Received: by 10.55.94.5 with SMTP id s5mr8802348qkb.102.1476901461735; Wed, 19 Oct 2016 11:24:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.22.1 with HTTP; Wed, 19 Oct 2016 11:24:01 -0700 (PDT)
In-Reply-To: <20161019155845.D13E21A564@ld9781.wdf.sap.corp>
References: <MWHPR15MB11829BF852A21F2E9C2B99B6AFD00@MWHPR15MB1182.namprd15.prod.outlook.com> <20161019155845.D13E21A564@ld9781.wdf.sap.corp>
From: Joseph Salowey <joe@salowey.net>
Date: Wed, 19 Oct 2016 11:24:01 -0700
Message-ID: <CAOgPGoAu0AKzf46UpWUSxd3hfFc977Ea9HK0OP77Qwu3aCi69w@mail.gmail.com>
To: mrex@sap.com
Content-Type: multipart/alternative; boundary="001a114e7152fed68a053f3bea21"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/1Sl811rlc1nT3mzs66wuP30qafM>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Deprecating alert levels
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, 19 Oct 2016 18:24:25 -0000

It does not look like we have sufficient consensus to adopt this PR.  While
there is some support for simplifying alerts by removing the alert level,
the current discussion raises some issues about the general approach.

1.  Is it appropriate for all unknown alerts to be treated as fatal? (the
current draft already states this)
2.  Are there cases, such as unrecognized name. where it is useful to
indicate that an alert is not fatal?  If so how should this case be handled?

Cheers,

J&S

On Wed, Oct 19, 2016 at 8:58 AM, Martin Rex <mrex@sap.com> wrote:

> Kyle Nekritz wrote:
> >
> >> This list is already missing the warning-level "unrecognized_name"
> alert,
> >> and such a change would imply that all new/unrecognized alerts are going
> >> to be treated as fatal forever (i.e. that no new warning-level alerts
> >> can ever be defined).
> >
> > That alert is currently defined as a fatal alert (see section 6.2 in the
> > current draft).  RFC 6066 also states "It is NOT RECOMMENDED to send a
> > warning-level unrecognized_name(112) alert, because the client's behavior
> > in response to warning-level alerts is unpredictable.", which I think
> > illustrates the problem. Allowing new non-fatal alerts to be added later
> > would require that existing clients ignore unknown warning alerts,
> > which I think is somewhat dangerous.
>
> It seems that rfc6066 is not clear enough in explaining the issue
> about the situation with the two WELL-DEFINED (but poorly implemented)
> variants of the TLS alerts
>
>   (1)  unrecognized_name(112)  level WARNING
>   (2)  unrecognized_name(112)  level FATAL
>
> See the *ORIGINAL* specification which created *BOTH* of these alert
> variants:
>
> https://tools.ietf.org/html/rfc3546#page-10
>
>
>    If the server understood the client hello extension but does not
>    recognize the server name, it SHOULD send an "unrecognized_name"
>    alert (which MAY be fatal).
>
>
> -Martin
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>