Re: [TLS] TLS 1.3 process

[Andy Lutomirski <[e-mail]>]

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 <[e-mail]> wrote:
>>>
>>> On Sun, March 30, 2014 4:46 pm, Peter Gutmann wrote:
>>>> Dan Harkins <[e-mail]> 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.

--Andy