Re: [TLS] PR#625: Change alert requirements
Watson Ladd <watsonbladd@gmail.com> Tue, 06 September 2016 22:00 UTC
Return-Path: <watsonbladd@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 E41A512B411 for <tls@ietfa.amsl.com>; Tue, 6 Sep 2016 15:00:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 XHbFD6SP1Dts for <tls@ietfa.amsl.com>; Tue, 6 Sep 2016 14:59:59 -0700 (PDT)
Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (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 D9C5312B28C for <tls@ietf.org>; Tue, 6 Sep 2016 14:59:58 -0700 (PDT)
Received: by mail-vk0-x230.google.com with SMTP id v189so112692087vkv.1 for <tls@ietf.org>; Tue, 06 Sep 2016 14:59:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Fgo8cuFIphrhaNpuhOlV4WY9Z8Brb1TsgsS9YgZ+XwU=; b=i+MU6xOhlmV+PWo3PeepOBxpP2wUvDC7qtujJCcYrR5/qns0rgY4rXYc/nDe/ZPoPF 0mEm+7Z9Qf25YqsUcSNDwKyyvC6mkbmpc9E8RbFyZggahGoqKhxQoAdTIPynpn1LW4R/ q/O/Cy0A+Q2JMJSOfymEInuJBmJVItmJUDrw6jOE/zyfexknFl2ZP287e1YVug8y/d72 W2GBzmvgLT6KZk21Y0d24CKWDIpgbCoO6X0xhmenlztubUgVG12DwZmaP9ckWUIa0hxG 0rSkmWY52j6m2vyI9Sosfd+g24f9gdNyqznhbzpruE0JpUBbQVNPIoEx5pyUU6JjIAb+ 3oSw==
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=Fgo8cuFIphrhaNpuhOlV4WY9Z8Brb1TsgsS9YgZ+XwU=; b=hoNV+CDuYaBLGl0kU8uv2s3ezI9xlxqGgcfc+tRLzxu04qTcGDCSLhM6fU51H9OzmJ y2nVXgKBkXVV+SE5tQIZ1WlioCQC4HYOo5PyWum3jE1jE6irNeXoyP63m9a3q3zHFcUF 3cReaY3ea10s/7kCLMfaxXEENiRCM3IT4+fdHOSN0JeZhknMsMXB1YUy7ZFdeSPBnRTN 2O4xVQ7wndtTzeRDlfNjqmR7n5HnEbvHlXs2ZRSrQGCDRIUjSmOG7Sx0ulSvmREKKvDY gUF9IxUCcV/J6nnMBsnP9sh09xGQKDexjkh6XBZiBBrcSxNnyg4AP4UX9xNBUEw08Gnn 3Azw==
X-Gm-Message-State: AE9vXwOs3lk6vxK4QmneeamZF2Igg7uXpjKDfgsziw8PQhbbEQ7n4zsWld+a/a8LHuqxhGzSuQgCuGsY5cF3iQ==
X-Received: by 10.31.219.194 with SMTP id s185mr9086551vkg.31.1473199197929; Tue, 06 Sep 2016 14:59:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.83.52 with HTTP; Tue, 6 Sep 2016 14:59:57 -0700 (PDT)
In-Reply-To: <6EA2A272-FB9F-4E0A-A35E-680E531DD757@sn3rd.com>
References: <CABcZeBMeLgqjvr2cjWL=AHTQJbS9siNBB6U2=0654yigbBGkYA@mail.gmail.com> <6EA2A272-FB9F-4E0A-A35E-680E531DD757@sn3rd.com>
From: Watson Ladd <watsonbladd@gmail.com>
Date: Tue, 06 Sep 2016 14:59:57 -0700
Message-ID: <CACsn0ckfVCgvWGTFYtKfHY+LE1SkqhNymOxVnzYTP5cUTMVTow@mail.gmail.com>
To: Sean Turner <sean@sn3rd.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/8kyI6UqfGzj-YGjKjBhEHxIZXGQ>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] PR#625: Change alert requirements
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: Tue, 06 Sep 2016 22:00:01 -0000
On Tue, Sep 6, 2016 at 2:33 PM, Sean Turner <sean@sn3rd.com> wrote: > All, > > The chairs would like to get some eyes on this PR by this Friday (Sept 9th) so that we can draw it to close. So I'd like to know if there are places this PR weakens the requirement beyond what common practice is. Why is the unexpected message alert removed, for instance? Do we always want to permit just terminating as an option? > > Thanks, > > J&S > >> On Sep 05, 2016, at 14:02, Eric Rescorla <ekr@rtfm.com> wrote: >> >> PR: https://github.com/tlswg/tls13-spec/pull/625 >> >> Currently the TLS spec requires implementations to send alerts under various >> fatal conditions. However, many stacks actually don't send alerts but instead >> just terminate the connection. Several people have argued that we should relax >> the requirement. >> >> At the September 2015 interim there was consensus to instead encourage >> sending alerts and require that if you send an alert, you send a specific one. >> I've finally gotten around to producing a PR that does this (link above). This >> PR: >> >> - Harmonizes all the language around alert sending (though perhaps I missed >> a couple of places) >> - Tries to make which alerts to send clearer in the alert descriptions to avoid >> having to specify individually how to handle every decision. >> - Relaxes the requirement as listed above. >> >> Note that these are to some extent orthogonal changes; even if we decide to >> continue mandating sending alerts, that should be listed in one location not >> scattered around the spec. >> >> I know that there wasn't universal consensus on relaxing the requirement to >> send, so I'll await WG discussion and the chairs decision on how to handle this PR. >> >> -Ekr >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Man is born free, but everywhere he is in chains". --Rousseau.
- [TLS] PR#625: Change alert requirements Eric Rescorla
- Re: [TLS] PR#625: Change alert requirements Sean Turner
- Re: [TLS] PR#625: Change alert requirements Watson Ladd
- Re: [TLS] PR#625: Change alert requirements Eric Rescorla
- Re: [TLS] PR#625: Change alert requirements Hubert Kario
- Re: [TLS] PR#625: Change alert requirements Hubert Kario
- Re: [TLS] PR#625: Change alert requirements Andrei Popov
- Re: [TLS] PR#625: Change alert requirements Eric Rescorla
- Re: [TLS] PR#625: Change alert requirements Martin Rex
- Re: [TLS] PR#625: Change alert requirements David Benjamin
- Re: [TLS] PR#625: Change alert requirements Timothy Jackson
- Re: [TLS] PR#625: Change alert requirements Ilari Liusvaara
- Re: [TLS] PR#625: Change alert requirements Salz, Rich
- Re: [TLS] PR#625: Change alert requirements Martin Rex
- Re: [TLS] PR#625: Change alert requirements Salz, Rich
- Re: [TLS] PR#625: Change alert requirements Salz, Rich
- Re: [TLS] PR#625: Change alert requirements Hubert Kario
- Re: [TLS] PR#625: Change alert requirements Hannes Tschofenig
- Re: [TLS] PR#625: Change alert requirements Benjamin Kaduk
- Re: [TLS] PR#625: Change alert requirements Martin Thomson
- Re: [TLS] PR#625: Change alert requirements Ilari Liusvaara
- Re: [TLS] PR#625: Change alert requirements Hubert Kario
- Re: [TLS] PR#625: Change alert requirements Sean Turner
- Re: [TLS] PR#625: Change alert requirements Eric Rescorla
- Re: [TLS] PR#625: Change alert requirements Eric Rescorla
- Re: [TLS] PR#625: Change alert requirements Eric Rescorla
- Re: [TLS] PR#625: Change alert requirements Hubert Kario
- Re: [TLS] PR#625: Change alert requirements Eric Rescorla
- [TLS] (strict) decoding of legacy_record_version? Benjamin Kaduk
- Re: [TLS] (strict) decoding of legacy_record_vers… David Benjamin
- Re: [TLS] (strict) decoding of legacy_record_vers… Eric Rescorla
- Re: [TLS] (strict) decoding of legacy_record_vers… Brian Smith
- Re: [TLS] (strict) decoding of legacy_record_vers… Martin Thomson
- Re: [TLS] (strict) decoding of legacy_record_vers… Brian Smith
- Re: [TLS] (strict) decoding of legacy_record_vers… Martin Thomson
- Re: [TLS] (strict) decoding of legacy_record_vers… Benjamin Kaduk
- [TLS] Treatment of (legacy_record_)version field … Andreas Walz
- Re: [TLS] Treatment of (legacy_record_)version fi… Eric Rescorla
- Re: [TLS] Treatment of (legacy_record_)version fi… Andreas Walz