Re: [TLS] TLS 1.3 process

["[e-mail]" <[e-mail]>]

If I may intervene as an outsider who has a use case.  My use case is simple:
allow peer to peer secure http connections - i.e. clients communicating with
servers, servers with servers, ... - with decentralised identity,
decentralised access control, using if possible just TLS, DANE and HTTP.
 
  All of this actually can work with current versions of TLS,
as shown by various implementations of the WebId specs 
http://www.w3.org/2005/Incubator/webid/spec/ . ( eg. 
https://github.com/stample/rww-play ) even if I don't doubt that there could
be improvements which closer analysis by members of this group would show up.

But it seems that HTTP2.0 and SPDY is having trouble with it as shown on this thread
  http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0000.html
It would be nice if the speed improvements in SPDY did not come at the cost of
security and a distributed social web.


 
On 2 Apr 2014, at 23:39, Andy Lutomirski <[e-mail]> wrote:

> 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.

I'd like to defend that organisation for having at least got those pieces
into TLS as it currently is. Without their effort we ( a little band of very
poorly funded hackers ) would not have been able to show that the same technology 
when tied in with Linked Data, keygen tag in html, LDP and TLS - can in fact be 
used to get distributed authentication with X509 certificates very cheaply. 

A similar argument can be made for the CA system. It helped get something going
which can be improved greatly with DANE.

>> 
>>  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.)

I always assumed that renegotation was also there to for example allow
say an HTTP client that say was browsing a file system using something like
WebDAV or LDP ( https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html ) 
to move to higher levels of security if a resource required it. But I have 
not come around  to implement anything like this, because doing distributed 
authentication and access control is already a lot of work. ( so I don't 
even know if renegotiation is the right tool for that, but was relying on the
collective wisdom of this group. :-)

> 
>>> 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
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls

Social Web Architect
http://bblfish.net/