Re: [TLS] PR#625: Change alert requirements
David Benjamin <davidben@chromium.org> Wed, 07 September 2016 18:46 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 DD7B512B33E for <tls@ietfa.amsl.com>; Wed, 7 Sep 2016 11:46:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.507
X-Spam-Level:
X-Spam-Status: No, score=-3.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] 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 zH1IoEQp0P-Q for <tls@ietfa.amsl.com>; Wed, 7 Sep 2016 11:46:40 -0700 (PDT)
Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (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 9E8B512B240 for <tls@ietf.org>; Wed, 7 Sep 2016 11:46:37 -0700 (PDT)
Received: by mail-it0-x229.google.com with SMTP id i184so214854462itf.1 for <tls@ietf.org>; Wed, 07 Sep 2016 11:46:37 -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=mtXBKwxFzMd1OKrGXr8w9hm8FApbtTliE/cgtxJicag=; b=NKwVM1kcOkpOKEG8UAM02sPQwsgcFf6BC2C/Usp+fbU9iTlk1AZzXYvVH65d6cmuCE sdb4RKDct8FruX+/vcM1FQ7OX8V42w/5DDYSX/45juwn9sjyBPS/WdGM8jzu+UtkTA0G aPjS+P2lQB9VsGcE/L/M2REFUM0J+H1v79P5c=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mtXBKwxFzMd1OKrGXr8w9hm8FApbtTliE/cgtxJicag=; b=kMhNktMuvL7/820Y6eanCUTrmuTY+0QUg2xuPAw0w7HuG2csMIVwljq6inpSrU9mDX GwgF8cGBWh6CEI+sewssBW9H/aMC1t5yDyr1WlvEqRshZ/4HOqaoXSvvZHVhcgU2nQ9v GhwhnBj1DNGyjb6EOmD2hPJZIJik+MQHSFeZfdFdWHJqh4t7ajmCQq9nJRdJEfNOnbL6 VyjZyldJTcqmdkRJlUloxaI4pRRY2h0Z9DM9plQIhI5Evrc8FNOnwQXof5Gse/IJjY/u yyjGEdeW/sLCrwJVQIshCxNo/+kR/BFufe+bWbhBdUnqasdqhc2P2NVVdJuVbVD9k299 tmzA==
X-Gm-Message-State: AE9vXwMaTDBY+3SDMj/lOM2ZoaOwoIGk8gB2l66M+PzTzqGyL1eOwcnSgwVKxS5qDa39ecHDCGum5wU3Q/Q0V5Pd
X-Received: by 10.36.200.134 with SMTP id w128mr9121333itf.92.1473273996842; Wed, 07 Sep 2016 11:46:36 -0700 (PDT)
MIME-Version: 1.0
References: <CABcZeBMeLgqjvr2cjWL=AHTQJbS9siNBB6U2=0654yigbBGkYA@mail.gmail.com> <1558569.9rZYFBiQ0G@pintsize.usersys.redhat.com> <CABcZeBMCkSJ1nGfZDjx3CJcUsLhH4AMZ=0wOc+uNs0YKu6kW1Q@mail.gmail.com> <3902031.op4bE2I96X@pintsize.usersys.redhat.com> <DM2PR0301MB0847A61D65DBF3AEC2149E168CF80@DM2PR0301MB0847.namprd03.prod.outlook.com> <CABcZeBNLSTMT6ARTyXAAXzHJujzxrn7Sc6NwDTSQBS8VCvqe0w@mail.gmail.com>
In-Reply-To: <CABcZeBNLSTMT6ARTyXAAXzHJujzxrn7Sc6NwDTSQBS8VCvqe0w@mail.gmail.com>
From: David Benjamin <davidben@chromium.org>
Date: Wed, 07 Sep 2016 18:46:25 +0000
Message-ID: <CAF8qwaDbroqSfMs5fHeRSWnaZCj=U9dgxDSX9z8Pn_=H9-e3BQ@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>, Andrei Popov <Andrei.Popov@microsoft.com>
Content-Type: multipart/alternative; boundary="94eb2c0579783d66ce053bef559b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/YAAbAX4YaDj5ZMjQvwP7qEPI2qQ>
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: Wed, 07 Sep 2016 18:46:42 -0000
On Wed, Sep 7, 2016 at 2:21 PM Eric Rescorla <ekr@rtfm.com> wrote: > On Wed, Sep 7, 2016 at 11:19 AM, Andrei Popov <Andrei.Popov@microsoft.com> > wrote: > > > > the only popular stack I found that does not seem to send alerts is > > > the schannel from Microsoft > > To clarify, schannel does generate alerts per RFC, but the HTTP stack > (which actually owns the socket) sees no value in sending them. > > > My impression is that this sometimes applies to Chrome as well. > Chrome doesn't send close_notify. I'm not sure if error alerts get swallowed or not. I thought they did, but they do seem to make it through some layers in the stack. Probably whether they manage to get sent depends on how long higher layers happen to hold on to objects when an error is reported. For Chrome, writing to a socket is asynchronous (we have some callback-based interface which ultimately uses select/poll/whatever + non-blocking write/send on POSIX), but tearing down a socket or its owners is synchronous (it's just C++ delete), so we would attempt to post the write but then immediately cancel everything if it's just before everything gets torn down. Trying to wait for that write to actually clear (and then account for timing it out if it takes forever, etc) would be a ton of trouble and not actually do much useful. I imagine Andrei's story with the HTTP stack is similar. David
- [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