Re: [TLS] draft-green-tls-static-dh-in-tls13-01

Watson Ladd <watsonbladd@gmail.com> Wed, 19 July 2017 14:48 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 3108F126C0F for <tls@ietfa.amsl.com>; Wed, 19 Jul 2017 07:48:47 -0700 (PDT)
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 EK3p1WTVv-ng for <tls@ietfa.amsl.com>; Wed, 19 Jul 2017 07:48:44 -0700 (PDT)
Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (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 631B2131B11 for <tls@ietf.org>; Wed, 19 Jul 2017 07:48:44 -0700 (PDT)
Received: by mail-pg0-x22f.google.com with SMTP id 125so1232023pgi.3 for <tls@ietf.org>; Wed, 19 Jul 2017 07:48:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aSha9v+4/2VA6s3gqh6zx2VePy24oAnbAlkK5wch22g=; b=UNS32tcTc9mbkFp3+HIbNqdlBOsdvQe5fQUF44qSULJktWoY/WoABTZuFMPBXtHSvr QiaBdfQGE0CrK7C5fc0KOQl/S7LCJhm8HaHTNYE8jafLukDUN6+tSv1Z3SYPbYx0wyGF Gkyzz2kzNosF8gxZPAfOJAQlwxMeAzXAmscOXQ4Tat+4bN/VvcDBV6A8GRvFG5g820rP rigu2Z4Tw30vT+T1UVPXcXBzjt347DOF2l2Lg3u9rlS0o2lLW8R3HFTPAJoeuKIiZHVU Sykng9Ys2YGVzz1hImfb6rPN+0KXeuuVGcOsPWAFezFFN0oecEyhCd2n+ObC8QUkwaqs v3Tw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aSha9v+4/2VA6s3gqh6zx2VePy24oAnbAlkK5wch22g=; b=NZA7WUpJJ/bmiJ24UIYaaA4zWmC/rHOQpp9UCS6k+TaLfjtSXPM3zJtXa2Tmcyd4U/ 9P3iYCpoxSCyo+EmC9pBdDxhpSNlEOLLowgiIvJYLWOQVUSY+P47Bq1iuuyTzwvyWPtB TknnjM7G4L1HKNO1p5/luXsxHHqvotW+3xi2jn68GvQIwLznKD2QmvwRT5ibfl7YDoXS IkWyJau5tpcy7aklnbItFH1BoH23B4rVU1dASVWdrZD4TNLnPIZ7zk/UuQ/ADyp6Azur 91jjGSbeSPpMu1JpT3O3qgcoqzf/7G9E2FMD+ChZmIrVuOT91XvorcIqwgzdNOYOlB+L RO+Q==
X-Gm-Message-State: AIVw112UV8xa5Z5at1iNIoYSlAtLTOmWgNbAWXaRp2dlA7Yr1HQwR8al K9Am5dbllFGurIiVGcXTHbvlwOPmVw==
X-Received: by 10.98.16.203 with SMTP id 72mr357646pfq.290.1500475723941; Wed, 19 Jul 2017 07:48:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.187.77 with HTTP; Wed, 19 Jul 2017 07:48:43 -0700 (PDT)
In-Reply-To: <E5BF12C2-B79A-444B-B4C2-90D28B40CCAC@arbor.net>
References: <CAPCANN-xgf3auqy+pFfL6VO5GpEsCCHYkROAwiB1u=8a4yj+Fg@mail.gmail.com> <CAOjisRxxN9QjCqmDpkBOsEhEc7XCpM9Hk9QSSAO65XDPNegy0w@mail.gmail.com> <CABtrr-XbJMYQ+FTQQiSw2gmDVjnpuhgJb3GTWXvLkNewwuJmUg@mail.gmail.com> <72BACCE6-CCB9-4DE9-84E6-0F942E8C7093@gmail.com> <a0a7b2ed-8017-9a54-fec0-6156c31bbbfa@nomountain.net> <6AF150DF-D3C8-4A4A-9D56-617C56539A6E@arbor.net> <CAN2QdAGRTLyucM1-JPmDU17kQgAv0bPZNASh54v=XoCW+qj48A@mail.gmail.com> <CACsn0cnc0X5++cOvTNsboda8J42qg3VDquZ4Va-X-YDcggnbvA@mail.gmail.com> <7423703D-5277-4F78-A2ED-1B7E152E7B08@arbor.net> <CACsn0cmo0HXBj7MidTTwkgE+Hwed9SrEODSzN8oURzQHJTW1aQ@mail.gmail.com> <E5BF12C2-B79A-444B-B4C2-90D28B40CCAC@arbor.net>
From: Watson Ladd <watsonbladd@gmail.com>
Date: Wed, 19 Jul 2017 07:48:43 -0700
Message-ID: <CACsn0c=_OT8R6SSr0P3RvT7Qx+smfz1DAKjH9Gni+jM8Ue4v5A@mail.gmail.com>
To: Roland Dobbins <rdobbins@arbor.net>
Cc: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a11448bbe850e910554acba40"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/YzYDBn7Qw-efKtzy-NeNADfRLOg>
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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 Jul 2017 14:48:47 -0000

On Jul 17, 2017 12:29 PM, "Roland Dobbins" <rdobbins@arbor.net> wrote:

On 17 Jul 2017, at 21:11, Watson Ladd wrote:

How do you detect unauthorized access separate from knowing what
> authorization is?
>

I think we're talking at cross purposes, here.  Can you clarify?


You said you need to look at packets to see unauthorized access. How do you
that access is unauthorized unless the authorization system is doing the
monitoring?



Yes, but you'll rot13 or rot 128 the file first. Why wouldn't you?
>

Many don't.  And being able to see rot(x) in the cryptostream has value.


As the IRA pointed out to the Prime Minister, she needed to get lucky every
time.




And the endpoints taking logs won't be?
>

Logs are no substitute for seeing the packets on the wire.


Then log the raw plaintext stream.




Applications can rate-limited their own endpoints.
>

There's a lot more to DDoS defense than rate-limiting.  Rate-limiting often
leads to gross overblocking.


You're telling me a dedicated out of stream box can handle this but a beefy
> server cannot?
>

Sadly, in all too many cases, yes.


... something is wrong here.




No one is taking away the ability to log the PMS to a file. That's the
> capacity which exists now.
>

But the capacity in question here is to see the packets on the wire.


Wireshark can use that file to decrypt packets on the wire. Today. What is
the problem with that?



Alternatively it's because you've decided to run your networks in ways very
> different from the public internet and used this as a way to avoid
> organizational battles over giving operations the tools they need to work.
>

I think that some perceptions of how these things are done even on the
public Internet may be a bit circumscribed.

The tools that network engineers and security personnel need analyze
network traffic.  Logs are insufficient.

-----------------------------------
Roland Dobbins <rdobbins@arbor.net>