Re: [TLS] TLS 1.3 process

Andy Lutomirski <> Wed, 02 April 2014 21:40 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1E3881A03F0 for <>; Wed, 2 Apr 2014 14:40:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0fcO9jpN2IrP for <>; Wed, 2 Apr 2014 14:40:00 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AE07A1A03EE for <>; Wed, 2 Apr 2014 14:39:58 -0700 (PDT)
Received: by with SMTP id hz1so798123pad.7 for <>; Wed, 02 Apr 2014 14:39:54 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=WrNkkF6+8Rm7ArGXhCHbvg1QfNfqiYsow3HRnuf7FTo=; b=BwiRJO/l6m7IjQVDrdKEFaWwuOmfus3gCZaSNaIGmPEzbrsWGSOH4xNKVguQM54cF5 cGpO2toO96BH+B8lTtg2fmyW3hwIxdzrQvo5VlEYQoIK/t2S5R8xK3Wq3CrdoieSjnsY Z6AwVkpx07iHQzD5CN9JjYKVVZB6CesAVlIQyweL66TAgm+r2KWGXcRNsboySd3e5k5d put1yFz6Dn+1GsOBDh3HZOxTOy/A9QFZEoYJI5PQzytv2W1xW1sc2lzAKuH4p/Abkcz3 W6fEmvWQQM2Agirf4D19sn4UocjMpzkzp79nEjsuqRbS2kpg5F0BfUKPGYeVLkqJrHpW j7UA==
X-Gm-Message-State: ALoCoQk0p2Yckb3twnDB2VEkoVgZ2TjdCS538agWR1pAVp8sW0GW5UweXlrzvGzmimpTbQHTFevF
X-Received: by with SMTP id ti4mr2898358pbc.48.1396474794838; Wed, 02 Apr 2014 14:39:54 -0700 (PDT)
Received: from ( []) by with ESMTPSA id z3sm15033127pas.15.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Apr 2014 14:39:54 -0700 (PDT)
Message-ID: <>
Date: Wed, 02 Apr 2014 14:39:53 -0700
From: Andy Lutomirski <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Dan Harkins <>, Watson Ladd <>
References: <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: "" <>
Subject: Re: [TLS] TLS 1.3 process
X-Mailman-Version: 2.1.15
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, 02 Apr 2014 21:40:05 -0000

On 03/30/2014 11:04 PM, Dan Harkins wrote:
> On Sun, March 30, 2014 9:09 pm, Watson Ladd wrote:
>> On Sun, Mar 30, 2014 at 6:16 PM, Dan Harkins <> wrote:
>>> On Sun, March 30, 2014 4:46 pm, Peter Gutmann wrote:
>>>> Dan Harkins <> writes:
>>>>> But everyone in the WG is concerned about getting encryption to work
>>>>> correctly. We're also all concerned about getting authentication to
>>>>> work
>>>>> correctly. And about getting authenticated encryption to work
>>>>> correctly.
>>>> Some of us are more worried about making it fit for purpose than in
>>>> fiddling
>>>> with crypto details.
>>>   Well if you do not care about encryption working correctly (it's a
>>> direct
>>> quote from the email I was replying to) then don't even bother with it;
>>> your purpose doesn't need encryption. And bringing up a use case that
>>> is happy with incorrect encryption is a waste of time for this WG.
>> But what do you mean by correct? INT-PTXT and IND-CCA2 would be my
>> guess. But TLS of any version doesn't provide that; you have to
>> implement the AES-GCM extension to get that. This still isn't fixed:
>> you have to know the magic workarounds to make the existing, mandatory
>> to implement protocol secure.
>   Yes, IND-CCA is a good definition of encryption "working correctly".

There's a difference between IND-CCA and IND-CCA2.

>> Well, what do you mean by secure? TLS only tells you that you are
>> talking to the possessor of a private key of some X509 certificate,
>> and potentially shows some certificate chain leading there. For client
>> authentication it falls flat: client certificates have ~1 organization
>> using them, and that organization can make anything work by throwing
>> enough billions at it. See the F-35 for details.
>   Excellent, we have an existence proof for client authentication. And no
> justification for spending time enumerating use cases that require it.

If everyone designing TLS 1.3 thought about what the use cases that want
or require client authentication, then maybe TLS 1.3 will come up with a
way of doing client authentication that actually makes sense.

Conversely, maybe if these were an understanding of the use cases that
require actual renegotiation (as opposed to supplementary authentication
of the parties that negotiated the original secret), then TLS might have
avoided supporting renegotiation in the first place.  (Hint: I've never
heard of a legitimate reason that an application would want to
explicitly change keys in the middle of a session.)

>> Everything about TLS is crypto details. What really matters is what
>> TLS is supposed to do. This is not spelled out anywhere, let alone
>> verified for TLS to work. It's the reason Martin Rex can argue BEAST
>> wasn't a bug: with no spec to go against, it didn't violate anything
>> but some sort of implicit understanding about what TLS was supposed to
>> do.
>   You are obviously mistaking a use case document for a specification.

I think that Watson is actually saying that the WG should decide what
security properties TLS 1.3 should actually have.  Then it should
document those properties.  Then people can and should verify that the
eventual specification actually has those properties.