On 29/03/17 15:29, Eric Rescorla wrote:
Hi Mark,
Thanks for your note. Some comments below...
On Wed, Mar 29, 2017 at 8:10 AM, Mark Dunn
<mark.d...@objectiveintegration.uk
<mailto:mark.d...@objectiveintegration.uk>> wrote:
I am trying to implement cookie and finding it a little
underspecified.
I am using the TLS 1.3 specified in github and
draft-rescorla-tls-dtls13-01
1a) Should a client expect to respond to a cookie during
session resumption?
Yes, it has to be ready to. As you say, it kills 0-RTT, but that's how
HRR always behaves.
I understand an HRR cookie should cause an extra round trip, but in this
case because of
"DTLS servers SHOULD perform a cookie exchange whenever a new
handshake is being performed"
And
"Early data is not permitted after HelloRetryRequest."
This results in 2-RTT as the default case, is this what you intended?
1b) If (1a) is false then do you agree that the "cookie"
extension MUST be accompanied by the "key_share" extension?
If I understand you correctly, then I think this is wrong. You only
send key_share to correct
the client's key_share, so if the client sent a key_share but you send
cookie to force
a round-trip, then you don't send key_share, just cookie.
OK, does this mean a change to DTLS 1.3 figure 4?
from
Client Server
ClientHello +----------+
+ key_share* | Flight 1 |
+ pre_shared_key* --------> +----------+
+----------+
<-------- HelloRetryRequest | Flight 2 |
+ cookie +----------+
to
Client Server
ClientHello +----------+
+ key_share* | Flight 1 |
+ pre_shared_key* --------> +----------+
+----------+
<-------- HelloRetryRequest | Flight 2 |
+ cookie +----------+
* + key_share* *
2) I understand this is too late for TLS(only DTLS SHOULD use
cookies) but is there a better solution than a cookie?
This seems like it would be a big restructure of the handshake, and
given the
relatively modest use of client auth in many contexts, I don't think
it would probably
be worth it.
Best,
-Ekr
Many infrastructure devices: smart router, smart switch, virtual switch
and most of the IoT require a
publish / subscribe / notify pattern or an exception pattern. Do these
not qualify?
The following use case is a publish / subscribe / notify excerpt from my
notes, from which I have further questions.
This use case shows that while DTLS 1.3 is provably secure, it has been
optimised to be very asymmetric in the way it delivers this security. *
*(Sorry it is not the exact format you have used in the spec.)
I have used "Accelerometer" and "Brake" in place of "Alice" and "Bob" :)
Unlike people, *things* generally do not browse the web. It is likely
that they will be commissioned, configured and left mostly to perform
their primary function.
Example: The *controller* configures communication between two *things*;
an *accelerometer* and a *brake* to control wheel spin.
The *controller* initiates a three way handshake with the *accelerometer*
ClientHello ----- >
+key_share…
< ----- ServerHello
+key_share…,
{
reference to the *accelerometer’s* certificate
CertificateVerify,
Finished
}
ClientResponse ----- >
{
reference to the*controller's *certificate,
CertificateVerify,
Finished
} ,
[data:command]
< ----- [data:ack]
This establishes an ephemeral Diffie Hellman *shared key* which is used
to encrypt the communication. The controller already knows the
accelerometer and has cached its certificate, so does not require the
*certificate chain* , but does require the CertificateVerify *signature*
to authenticate the *accelerometer*. The *controller* then commands the
*accelerometer* to *authorise* access for the *brake* to monitor it.
Similarly, the*controller *communicates with the *brake* to command it
to monitor the *accelerometer*. This process may provide both *things*
with each other’s *certificates*.
The *brake *initiates a three way handshake with the *accelerometer *to
request a subscription to a value*
*
ClientHello ----- >
+key_share…
< ----- ServerHello
+key_share…,
{
reference to the *accelerometer's *certificate,
CertificateVerify,
Finished
}
ClientResponse ----- >
{
reference to the *brake's* certificate,
CertificateVerify,
Finished
},
[data:request:subscribe]
< ----- [
Ack,
NewSessionTicket,
data:response:ack
]
The *brake* makes a request, encrypted with the *shared key,* to monitor
the *accelerometer* for sudden acceleration.
They agree a *pre-shared key* to use on the next session. A session in
this case is ended when either thing loses its ephemeral memory.
When the *accelerometer* needs to inform the *brake* of high
acceleration (wheel spin)
The accelerometer uses the *shared key* to encrypt the Notification
< ----- [data:notify:value]
*
***
*Subsequent Communications **(0-RTT or Zero Round Trip Time)*
If either of the *things* loses their ephemeral memory, then they need
to use the *pre-shared key *they agreed on earlier. This time the client
is the *accelerometer.*
ClientHello ----- >
+pre_shared_key,
+key_share,
+early_data…
(data:notify:value)
< ----- ServerHello
+pre_shared_key,
+key_share…,
{finished…}
[data:ack]
ClientResponse ----- >
(endOfEarlyData)
{finished}
< ----- [Ack, NewSessionTicket]
*Renegotiation*
If the car is switched off then the next time it is switched on then
full authentication is required once again (without the need for a
certificate chain)
*Further Questions
*3) Is it true that the certificate or certificate chain are not
required to be passed in the handshake, it is the client's ability to
check the CertificateVerify signature against the certificate. This
certificate may have been obtained by other means. If this is the case,
could we have an explicit method to ask for either the certificate or
the certificate chain rather than providing an expensive certificate
chain by default. (I looked at raw certificates, but they do not seem to
provide a path to root of trust)
4) Does the DDOS threat disappear if only certificate references or
certificates are provided, removing the amplification threat and thus
the need for a cookie?
5) I understand for pre_shared_key that we require a If we provide a
CertificateVerify, why do we need a Finished as well?
6) In "Subsequent Communications" It was the old server, but now the new
client that uses the pre_shared_key, what are your thoughts?
7) In TLS 1.3, i think it is implicit that a session corresponds to a
TCP connection or similar, what are your recommendations for what
constitutes a session in DTLS 1.3?
I am still slogging through how to create a cookie, which is an
exceptional version of Transcript-hash (TLS section 4.4.1), which I
still haven't figured out....
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
