Re: [TLS] TLS 1.3 process

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

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

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

  Well, unless you can induce a server into reusing a random number
across sessions even a cipher suite using RSA key exchange will produce
a unique master key. And yes, ECDHE is an option. No need to
enumerate protocols from /etc/services to arrive at 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.

  It's easy to bitch about what other people did in the past (while oddly
continuing to use the first person plural). But the discussion is whether
the WG should enumerate use cases to decide whether TLS does what it
needs to do. So far you have not made a compelling case.

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

  Excellent, we have an existence proof for client authentication. And no
justification for spending time enumerating use cases that require it.

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

  Ah-ha! Finally something that is not bluster. Authorization is an
interesting issue. I actually might change my mind on this whole use
case thing if you can express a cogent case for what it should provide
and for whom and why. On the other hand, if there's some application
that requires some granular form of authorization it would behoove the
stakeholders to express that need. A use case document isn't really
necessary for that, but on the other hand it might help.

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

  You are obviously mistaking a use case document for a specification.

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

  A use case document is not "formal methods", it's just a summary of
use cases. And a use case document doesn't really translate into better
definition of features.

  For all the shortcomings of TLS < 1.3 you haven't really explained how
any of them were caused by the lack of a use case document or how a
use case document for TLS 1.3 would ensure that they are not repeated.
It is my experience that "problem statements" and "use case" documents
are waste of at least 12 months and sometimes 18 or more. Now, given
that you have stated that it only takes 30 minutes to write a document
that is ready for publication as an RFC, you may not share that view, but
my opinion has been honed over experience in different working groups
over the years where I've seen it happen.

  regards,

  Dan.