IETF Logo Mail Archive

Re: [TLS] ETSI releases standards for enterprise security and data centre management

Tony Arcieri <bascule@gmail.com> Thu, 06 December 2018 23:29 UTC

Return-Path: <bascule@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 419DB130E5A for <tls@ietfa.amsl.com>; Thu, 6 Dec 2018 15:29:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 aMgSO08VwU5I for <tls@ietfa.amsl.com>; Thu, 6 Dec 2018 15:29:25 -0800 (PST)
Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) (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 47371131214 for <tls@ietf.org>; Thu, 6 Dec 2018 15:29:25 -0800 (PST)
Received: by mail-oi1-x236.google.com with SMTP id w13so1942345oiw.9 for <tls@ietf.org>; Thu, 06 Dec 2018 15:29:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+MQ6ita8ngRgh2qKX4SgoNx7qcq81U4xfs/uOGgrCBg=; b=DN0av/3K+FtPr9AyU0TBWqE5euR8BMLYAlcT9FUFbTmO6KKkAnQueDC+aIchoIxjpF HrgmfhfHOK9P7GB5whn5Hud0jh570UmlQlGemRL6hnhyJhfxmv2V7bK1rZrN0CMvg52B liIhR4zw8QanakZpEc59odJVYAqZlabdJQ80z68HhV7BlMVBSNy6ZZjwRDMxjPgCbfyv gph4irD9ExvtqkI+WTP3ckiFB2gIVH5tkUqzbTr05lxig/mXg+Zx++od535BfyuKfaFl 2gIQ7AmuujMZR9kpf+y7RD/xIxF3IIhJFYWOQ8Oir+CVko7vQJH10olP9RF5CM6t1i6X FMOQ==
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=+MQ6ita8ngRgh2qKX4SgoNx7qcq81U4xfs/uOGgrCBg=; b=LCV2iXbbfOfBJAZt78Eh1yL3m50fBdhqxajTMBxlDoNxpINW029FXoMj4lix4YOBBh Ba7bPtArMwt5/RfLWakJYRhja1TgLKcbB6VV/89Q2suyuBOIFBL7Mohkimg/BoBgFnkH +baYb7yBlO1kQppXdjkYym1FlQSnYZtTB15GZBov/OUjmPJpgBoZDSIDC9SiNRaz3rUK Fm3ocWGmFiFUUKe6P28GUcfIeXH3bVvCS1/3t9bYKsnWHmzEEg0pKUkSVwgUtHczl5iU s0H2OlMOB9JXpOhcQvR8fQGRD8uJcJXrgELCGRjop7J6w7xkYKvPB6FdMIwKtpdoityV 9O5Q==
X-Gm-Message-State: AA+aEWZd7xTWC2neJCzPdwYrIgMKjBAXu7EPeqGgd/s8+iOtBRhJdvc9 Y1q0DyYz6i7Yk68I5LHS+M/CzRVdAxAumOkzj/qz53FF
X-Google-Smtp-Source: AFSGD/U999GSJNn8QSwhcboDfVYwSRcSK4LEt+kFVTEfWG1m//EFWN5RFY6LCbRQ1v+Vnw7XjHdRigWMrDwoqDGjzm4=
X-Received: by 2002:aca:ba02:: with SMTP id k2mr19830242oif.177.1544138964563; Thu, 06 Dec 2018 15:29:24 -0800 (PST)
MIME-Version: 1.0
References: <CADqLbzKd-AgDRv2suZ-0Nz4jNUqKg0RNT8sgQd-n793t+gEN3g@mail.gmail.com> <CAHOTMVKZT1ScvHeP3=Kv2zodVimHkaAtG-2DTq6ojnF+q-OMSQ@mail.gmail.com> <20181202233553.GD15561@localhost> <CAHOTMV+vPkM-=Qsto-8-ipFuGsNKkH_U=BEY_mB=7CM7tto3Mw@mail.gmail.com> <38D10A65-B4EE-4E81-8EA4-D69514F7F47B@gmail.com> <51754d91-c00c-0cad-ecd6-8db74544d26a@cs.tcd.ie> <A7423BAF-398B-4BBE-81AC-364CE748D6B1@gmail.com> <9344c0e1-f484-2b4b-8594-1d29731f6b7a@cs.tcd.ie> <01429BF7-BF1D-4F1C-9E18-D796A5585E62@gmail.com> <2F72F9A9-1556-4F44-8BBA-4D4CDD1A310C@akamai.com> <cd138d5d-37be-acee-297c-011227e98b99@nomountain.net> <SN6PR2101MB1055D37EB2DD393B9DB042238CA90@SN6PR2101MB1055.namprd21.prod.outlook.com> <87d0qee736.fsf@fifthhorseman.net>
In-Reply-To: <87d0qee736.fsf@fifthhorseman.net>
From: Tony Arcieri <bascule@gmail.com>
Date: Thu, 06 Dec 2018 15:29:13 -0800
Message-ID: <CAHOTMVJ55QNhSP0W5Dn2t2X+Sc3X6OEX3wyZDgDH36+9nEsT+Q@mail.gmail.com>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Cc: Andrei Popov <Andrei.Popov@microsoft.com>, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000777d41057c62de2c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/mCo62e-F7AhQBWsNu6AGtKsfeKE>
Subject: Re: [TLS] ETSI releases standards for enterprise security and data centre management
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: Thu, 06 Dec 2018 23:29:30 -0000

On Thu, Dec 6, 2018 at 12:33 PM Daniel Kahn Gillmor <dkg@fifthhorseman.net>
wrote:

> So it's conceivable that truly malicious servers would do this, of
> course, but they might also just publish the master secret on twitter
> too, and the client wouldn't know how to detect that inband either.  But
> for the misbehavior that we *can* detect in-band, a responsible client
> should be aware of it and avoid it, right?
>

If nothing else, implementations which reuse ephemeral keys for long
periods of time are buggy and contain a vulnerability which violates the
security assumptions of the protocol.

I think it's reasonable for clients to detect and reject this behavior, as
it's an indicator TLS has been deployed in an insecure way and therefore
the connection should be aborted. I think this could detect a wide range of
"real world" TLS implementation failures which have come up in the past,
including bugs in random number generation and bugs in the code in TLS
stacks responsible for rotating ephemeral keys.

-- 
Tony Arcieri

v2.23.0 | Report a Bug | By Email