Subject: [TLS] Draft 18 review : Hello Retry Request and supported groups cache

From: Olivier Levillain <[email-masked]>
Date: Tue, 22 Nov 2016 20:03:59 +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.

= HRR and supported groups cache =

In 4.2.4 (P.41), a server can send a supported_groups extension to
"update the client's view of its preference" in its ServerHello.
Since this behaviour is completely left to the client's discretion, it
does not seem a very relevant policy from the server: either the
server accepts one of the proposed groups, or it sends an HRR.  We do
not think the middle ground (OK for this group, but I would prefer
this other one) is relevant, so the sentence should be removed.

Moreover, as far as I could understand, there is no indication in the
specification that a client should remember the preference of the
server in case it receives a HRR, which there would definitely make
sense.  Such text could go in 4.1.4.

I can propose a PR for this point.

Olivier Levillain

---

From: Steven Valdez <[email-masked]>
Date: Tue, 22 Nov 2016 19:09:25 +0000

Being able to send supported_groups does allow a server to choose to make a
tradeoff between an extra round trip on the current connection and its own
group preferences. One example where a server might want to do this is
where it believes that X25519 is likely a more future-proof group and would
prefer that, but still believes the client's choice of P256 is suitable for
this connection. Always requiring an extra round trip might end up being
expensive depending on the situation so some servers might prefer to avoid
sending an HRR for a slightly more preferred group.

I think that requiring the client to maintain state from the
supported_groups puts undue requirements on the client, since not all
clients keep state between connections, and those that do usually only keep
session state for resumption.

On Tue, Nov 22, 2016 at 2:01 PM Olivier Levillain <
[email-masked]> wrote:

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

---

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

On Tue, Nov 22, 2016 at 11:09 AM, Steven Valdez <[email-masked]>
wrote:

> Being able to send supported_groups does allow a server to choose to make
> a tradeoff between an extra round trip on the current connection and its
> own group preferences. One example where a server might want to do this is

This matches my view as well.

I agree that the client should not be require to keep state. I do not
believe that the draft requires this, but if someone thinks otherwise,
please send a PR to fix.

-Ekr

---

From: Olivier Levillain <[email-masked]>
Date: Wed, 23 Nov 2016 09:19:44 +0100

Hi,

> believe that the draft requires this, but if someone thinks otherwise,

There were actually two points in my message:
 - I was not convinced by this way of signalling a preference without
enforcing it, but I understand that, if we keep supported_groups, it
does not cost much and the client can safely ignore the server sent
extension;
 - however, I found strange that the specification stated that the
client could update its view when seeing this extension, but that it was
not stated in the case of an HRR where updating its views of the
servers' preference would clearly be useful for the future. I only
proposed to add the same text "The client MAY update its view of the
server's preference when receiving an HRR, to avoid the extra round trip
in future encounters".

olivier

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 23 Nov 2016 05:09:28 -0800

> server's preference when receiving an HRR, to avoid the extra round trip

This is is unsafe, because the HRR is unauthenticated. We could update it
after the handshake completes, but I think this is obvious enough that it
doesn't
need to be stated.

-Ekr

---

From: Olivier Levillain <[email-masked]>
Date: Wed, 23 Nov 2016 14:25:21 +0100

> after the handshake completes, but I think this is obvious enough that it

Unless I am mistaken, EncryptedExtensions is not authenticated either
(even if it is sent in the same flight as the authentication messages),
so updating the client cache can not be done immediately after
interpreting the supported_groups extension.

However, if you believe this does not need to be stated, I am fine with
that.

olivier

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 23 Nov 2016 05:35:19 -0800

> interpreting the supported_groups extension.

That is intended to be covered by the following text:

   by the client.  Clients MUST NOT act upon any information found in
   "supported_groups" prior to successful completion of the handshake,
   but MAY use the information learned from a successfully completed
   handshake to change what groups they use in their "key_share"
   extension in subsequent connections.

My point about HRR is that the client can generally update its opinion
based on what it successfully completed the handshake with. This can
happen either with HRR or when it offered >1 shares and the server
took one. The special case is when supported_versions indicates a
key type you didn't use. So I think if we wanted text around this it would
go somewhere that covered the general case. I'm not sure it's needed
but if the WG feels like we should add some text, I can...

-Ekr