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