Subject: [TLS] Draft 18 review : Message order

From: Olivier Levillain <[email-masked]>
Date: Tue, 22 Nov 2016 20:08:09 +0100

Hi list,

I am sorry for the very late answer concerning draft 18, but we
(ANSSI) have several remarks after proof-reading the current
specification.

We are sorry for the multiple long messages.

If the WG is interested by some of our concerns/proposals, we would be
glad to propose some PRs.

= Message order =

I believe the message P.27 section 4 is important, but not
sufficient. As already expressed on the list, a formal automaton
should be provided in the spec.

I think Ekr said there was some work in progress in this area.  Is
this a goal for the final specification?

Olivier Levillain

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 22 Nov 2016 11:25:19 -0800

> this a goal for the final specification?

Yes, I will put some sort of more complete state machine in the final spec
(probably in -19)

-Ekr

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

---

From: Olivier Levillain <[email-masked]>
Date: Wed, 23 Nov 2016 18:02:54 +0100

Hi,

> Yes, I will put some sort of more complete state machine in the final spec

I have been working on my black board on the simplest case (pure TLS, no
PSK support), and I stumble upon the late client authentication issue
that was presented in the thread starting with
https://www.ietf.org/mail-archive/web/tls/current/msg21500.html. I agree
with the thread that NST and KU are easy to deal with.

As stated in the thread, as it is currently specified, the mechanism is
kind of a pandora's box :
 - the client must keep the handshake transcript (or its running /
forkable hash) because of the Finished message that must eventually be sent
 - the server can send multiple CertificateRequest, and the client must,
for each, keep the content of the message (for the label, and also for
the hash context required for the Finished message) => the unboundedness
problem
 - there is no way to reject the request gracefully.

As I understand the thread, one idea was to say that the mechanism is
forbidden by default, unless it is activated by some profile. However,
as stated in
https://www.ietf.org/mail-archive/web/tls/current/msg21561.html, since
there are voices to allow it in the HTTP profile, this is problematic
because HTTPS can be used in constrained environments where we would
like to avoid late client auth. I believe the late client auth mechanism
should explicitly be negotiated, either at the TLS level with an
extension, or at the application level via an API callback (not a
profile) and an upper layer nego.

Sorry to dig this up (and sorry for the re-discovery explained at
length), but where does the WG stand on this issue? PR 680 is currently
parked, but I believe the current situation is not acceptable from the
client's point of view, and I fail to see whether unbounded parallel
certificate requests would be used in practice or not.

Best regards,
olivier