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

Watson Ladd <> Wed, 19 July 2017 19:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 63018131BB5 for <>; Wed, 19 Jul 2017 12:29:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id woeuEjEunZ2u for <>; Wed, 19 Jul 2017 12:29:47 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C57BA131BBC for <>; Wed, 19 Jul 2017 12:29:47 -0700 (PDT)
Received: by with SMTP id s70so3638995pfs.0 for <>; Wed, 19 Jul 2017 12:29:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5cetxLkc2kMzHQ5/aKUf/VDSKblXUEuJ0ljU8jDPVrs=; b=vB85HRcOUpSDGLmcyN6GaVwso+x1eo19wDnbKPCDfYlcq/spSYLtGrgvW035SFttmS 8UTNqz3FDxucMLA86oG4SVzSp+McMnGjkO7KprgYgw5k8/hQBJAtJOQ9zv0IKfdrWYYC PavrBypWOVuj3tLqGs+bqkW1/lpgnwAZiWWY9xeOIehE5nqcYFM9C89rdl4hr8PkMiTe xDgFEjdXaP0ha4utGsQTKbv8nvBVfpvckMF9fuQ8S2WJDH1OLR0Fmmucy4VRPF37PMoe UBZEuqjnE3NezThE0xyPBwjo0Gbw2suZKDKYyZpC2m+VPpR51rHvDC0sqF8cIvJnVfrc C5SA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5cetxLkc2kMzHQ5/aKUf/VDSKblXUEuJ0ljU8jDPVrs=; b=LkDzaYJH3T/HEcj4EVGfxi6rA3trCQatTqCG+jBce/nSUxz+fVA6XmakB2/lcTeJGZ U3D3kWVuaFjQDTOpzrIJg3adG7DeknUPrBwfgyLOqLvhe6lLMbuig+TdxxM+V4bDEgqf QJmGlNtNkH2RumOHpEQrcCihLN1K/OJRvtfyob+US8Wv75klyIrE/+RHPCWx7a/kz1jP 9Lnr5CVYl0vGPBBbtMOEuiI/mjAuMZGyGNvUlsYuGDc6oUB5B97TS4EDC/kVRXT1N55H su19vN/CGRfEvxoA6YS6aLUbSCFBs2Ktz/uU5A43ri5tszzP9TKFqzB23F1XfmykFF94 DzvA==
X-Gm-Message-State: AIVw1130rP6zHeNLq6+CNFyO7+94jfMq9HC9si11Fhe9MKIYLyRwEQSV cC3a59BPM1H/8X5KmDEUbEkxOIIB5g==
X-Received: by with SMTP id t83mr1116831pgb.351.1500492587425; Wed, 19 Jul 2017 12:29:47 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 19 Jul 2017 12:29:46 -0700 (PDT)
Received: by with HTTP; Wed, 19 Jul 2017 12:29:46 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Watson Ladd <>
Date: Wed, 19 Jul 2017 12:29:46 -0700
Message-ID: <>
To: "Dobbins, Roland" <>
Cc: "Blumenthal, Uri - 0558 - MITLL" <>,
Content-Type: multipart/alternative; boundary="94eb2c09b42ca966100554b0a793"
Archived-At: <>
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 19 Jul 2017 19:29:52 -0000

On Jul 19, 2017 11:38 AM, "Roland Dobbins" <> wrote:

On 19 Jul 2017, at 20:29, Watson Ladd wrote:

Now it turns out that the requirements on solutions came from
> organizational issues you never told us about.

The organizational issues have been described previously, both on the list
and in the meetings; and the technical issues are quite separate from the
organizational ones.  The one isn't the cause of the other.

In many cases, the organizational issues do not exist, yet the technical
ones remain.

What are the technical requirements?

There is a serious technical issue here; the only reason the organizational
issues were even mentioned was to provide context.

I still don't see a response to how you determine unauthorized access
> happened without being the authority on what access is authorized.

It's possible to have the relevant access policy information to hand
without being the authority oneself.

Why can't the enforcing mechanism log its enforcement?

Apparently exporting the PMS from clients and servers  isn't possible: I
> find that hard to believe.

It isn't practical from a performance nor a network architecture

We're talking one extra encryption+transmission. How is this not possible?

Let's standardize an extension that exports an encrypted EMS and be done
> with this debate.

That does not meet the technical requirements.

Why not? It enables interception if both ends opt in with the encrypted
packets. (I see I made a typo: I meant PMS) what does the green draft do
this does not?

There's some quite useful and constructive discussion of possible
approaches taking place - I'm observing it with interest.

Roland Dobbins <>