Subject: Re: [TLS] TLS 1.3 process

From: Peter Gutmann <[email-masked]>
Date: Sun, 30 Mar 2014 23:46:57 +0000

Dan Harkins <[email-masked]> 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.  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 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.

TLS has certainly shown some... surprising behaviour over its lifetime.

Peter.

---

From: "Dan Harkins" <[email-masked]>
Date: Sun, 30 Mar 2014 18:16:19 -0700 (PDT)

On Sun, March 30, 2014 4:46 pm, Peter Gutmann wrote:
> 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.

>              The former requires careful thought, for the latter you

  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.

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

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

  Dan.

> Peter.
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Watson Ladd <[email-masked]>
Date: Sun, 30 Mar 2014 21:09:05 -0700

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

> 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.
> work correctly (in response to the arresting statement that "Watson is

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.

> 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

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

---

From: "Dan Harkins" <[email-masked]>
Date: Sun, 30 Mar 2014 23:04:06 -0700 (PDT)

> to implement protocol secure.

  Yes, IND-CCA is a good definition of encryption "working correctly".

> basic negotiations discussed: you have to implement and use the ECDHE

  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.

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

>>>   crypto or code. Oh yes, you think about the crypto all the way
>>> through,
>>> but

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

> completely foreign to the entire bundle of technologies I've discussed

  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.

> but some sort of implicit understanding about what TLS was supposed to

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

> Channel bindings evolved later, and so no one looked to see if they

  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.