Re: [TLS] TLS 1.3 process

[Watson Ladd <[e-mail]>]

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.

Furthermore, how do you negotiate the key? Some applications rely on
TLS negotiated keys being unique (channel binding for user
authentication, GSAPI). This property doesn't hold for any of the
basic negotiations discussed: you have to implement and use the ECDHE
extension for that.

So far from being a waste of time, the only applications the product
of the WG is good for are those where encryption doesn't matter. I'm
not even going to touch on the embarrassment of having a working
group, UTA, created to clean up after us.

>
>>              The former requires careful thought, for the latter you
>> just pull a known-good mechanism off the shelf at the end of the design
>> process, plug it in, and you're done.  To quote Peter Fairbrother on the
>> crypto list:
>>
>>   A similar design methodology should be used for security products (and
>>   software products).  Start with the purpose of the product, then the
>> human
>>   and electronic interfaces, then the hardware and last of all the
>> detailed
>>   crypto or code. Oh yes, you think about the crypto all the way through,
>> but
>>   only in terms of what is possible and what resources it will take -
>> worry
>>   about the detailed crypto (or code) last.
>
>   I agree. The purpose of TLS is to secure a network service (as I said
> originally, see /etc/services to see who'll use TLS). If we start listing
> that
> IMAP and POP and HTTP will use TLS-- "what else?"-- it's a distraction.

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.

At best TLS can be a useful tool, letting other people focus on how to
turn X509 into what they really need ala DANE. However, they still
need to deal with client authentication, and authorization is
completely foreign to the entire bundle of technologies I've discussed
here.
>
>>>I fail to see how documenting use cases will help us get encryption to
>>> work
>>>correctly
>>
>> It'll allow us to see whether the encryption is fit for purpose.  Since
>> I'm in
>> a quoting mood I'll do Bob Morris this time:
>>
>>   The behaviour of a system without a specification can never be wrong,
>> only surprising.
>
>   You should try to find quotes that relate to what you're responding to.
> I never said anything about not having a specification and I never said
> we need to immediately start "fiddling with crypto details". I said that
> enumerating applications that use TLS is not a productive use of time
> (I certainly hope you are not equating a use case document with a
> specification), and I said that we are all concerned with making encryption
> work correctly (in response to the arresting statement that "Watson is
> concerned" about it).

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.

>
>> TLS has certainly shown some... surprising behaviour over its lifetime.
>
>   How would an enumerated list of the applications that use TLS, or a
> use case document for that matter, have helped any of that?

Well, it might have made EKR think twice before writing "This timing
difference is believe to be too small to exploit" in an RFC.  Formal
methods could have trivially caught the renegotiation bug. If you look
you will see renegotiation isn't actually defined anywhere: it's just
casually mentioned that the example handshakes in the document aren't
all the possibilities because you can restart them at any time.
Channel bindings evolved later, and so no one looked to see if they
were secure.

Sincerely,
Watson Ladd

>
>   Dan.
>
>> Peter.
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin