Subject: Re: [ntpwg] NTS: The question of CMS vs. (D)TLS

From: [email-masked]
Date: Thu, 2 Jul 2015 15:41:03 +0200

Hello Florian,

regarding your current reply:
 
> I used ?session ticket? in the sense of RFC 5077.  From the client
> perspective, but the server can decrypted it with its secret key, and
> recover the entire session state from that?which includes the key used
> for the MAC (which is shared with the client) and implementation-defined
> data such as information needed for sender address checks used for the
> Photuris DoS protection mechanism.
> 
> In a fixed protocol, the session ticket would take the place of the
> client certificate hash in the post-negotiation messages.  Both the
> shared MAC key and the session ticket would have to be exchanged in the
> negotiation phase.

This seems to be in contrast to the following older conversation 
(2015-Apr-15):

>>> I strongly recommend reusing (D)TLS instead of implementing your own
>>> cryptographic protocol.  I have marked the issues which would go away
>>> with a proper implementation of (D)TLS with ?(D)?.  With DTLS, the
>>> server could just send the client cookie and the HMAC key, 
disregarding
>>> the client certificate.
>> 
>> Do I understand it correctly that you're proposing something like:
>> * do the key exchange via dtls
>> * the server creates a random client cookie and calculates the client 
>> specific key from that (using a server secret as well) and sends both 
to 
>> the client
>> * the time sync packets would just send the rand in the request and the 

>> server can calculate the shared key for the response
>
>Yes, that's the approach I recommend.  You'd have to design something
>pretty much similar to DTLS anyway.

In particular, due to the above conversation, I had always understood your 
proposed approach as follows: 
- use (D)TLS for the negotiation phase, have rand ("key input value" or 
"KIV" in our current terminology) and resulting shared key ("cookie" in 
our current terminology) be part of that negotiation 
- end negotiation phase, end (D)TLS session
- go into post-negotiation phase, where the rand/KIV is included in each 
timesync request (as opposed to a session ticket) and forms the basis for 
the server to generate the cookie which is used as key for the HMAC 
included in a timesync response

I like(d) this approach for its clean distinction of negotiation and 
post-negotiation phase. I especially liked that different methods of 
handling the cryptographic aspects (i.e. CMS-based vs. (D)TLS) would have 
to be specified separately only for the negotiation phase and that the 
post-negotiation phase would not differentiate. 
This reduces complexity for both specification and implementation. 
Additionally, it retains the low cryptographic requirements for a timesync 
response (performing exactly two HMAC operations).

I'm not a big fan of an approach which requires specification and 
implementation to make a differentiation between security approaches 
(CMS-based vs. (D)TLS) for post-negotiation phase (timesync) traffic. 
Also, it seems to me like the use of a session ticket for post-negotiation 
traffic, as described by you currently, would in effect be very similar to 
"just run NTP over (D)TLS, with session resumption using session tickets". 
What am I missing here?

> (I don't think the current protocol with the client certificate hash in
> post-negotiation messages is feasible to deploy because it does not give
> the server sufficient data for DoS protection.)
> 
> -- 
> Florian Weimer / Red Hat Product Security

I see your point here. I am unsure, however, how highly we should place 
the requirement for this kind of DoS protection.

This was a lot of text. Now, to ease communication, some specific 
questions:
1.) How much of a problem do you see with an approach which uses (D)TLS 
exclusively for the negotiation phase (and then continues with the 
HMAC-based timesync protection as described in current NTS drafts)? In 
your opinion, are there other significant weaknesses than lack of DoS 
protection?
2.) How different would you say your currently described approach is from 
"just run regular NTP over (D)TLS, with (D)TLS session resumption using 
session tickets"?
3.) Could you give an estimation of the required cryptographic operations 
required (in your currently described approach) for the server to give a 
timesync response?

Thank you in advance and best regards,
Kristof

_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Florian Weimer <[email-masked]>
Date: Thu, 02 Jul 2015 15:53:54 +0200

> included in a timesync response

This is still fine, except that I would like to replace client
certificate hash with an opaque value of variable length.  The CMS-based
protocol could still put the client-cert hash there, but a DTLS-based
implementation would store a session ticket in this place.

Even for the CMS-based negotiation phase, I suggest to send back this
field to the client.  This means that it's up to the implementation what
to put there.  It could be the client certificate hash, but the server
implementation could use something else (which might provide it with
additional state).

Does this make sense?

> response (performing exactly two HMAC operations).

I think this is possible if the small change I outlined above is made to
the protocol.

> "just run NTP over (D)TLS, with session resumption using session tickets". 

Sorry for the confusion.  It's conceptually a session ticket.  I don't
propose to implement it using DTLS on the server side (although you
probably could, but I wouldn't recommend it).

> the requirement for this kind of DoS protection.

I think it's reasonable to provide space to keep additional state which
can be used to support various (implementation-defined) mechanisms.  It
is not necessary to specify the precise mechanism.  If the server sends
back the ticket that takes the place of the client certificate hash, and
the client includes that instead of the hash in post-negotiation
requests, this would be sufficient for server-side state extensions.
The CMS-based reference implementation could simply send back the client
certificate hash, but the protocol is open to more elaborate approaches
(and these server-side mechanisms would not require client changes).

The exception to this rule is protection of the asymmetric cryptographic
operation in the negotiation phase—this rather expensive operation
should only be reachable after the client has proven control over the
client address it supplied (so that we can assume it has not been
spoofed).  This is what a Photuris-style cookie achieves.

---

From: [email-masked]
Date: Fri, 3 Jul 2015 15:06:45 +0200

> implementation could use something else (which might provide it with

It does, and I think it is a good idea. Do you have a proposal for the 
wording regarding this opaque value? (IMO, "key input value" does not seem 
generic enough anymore.)

> I think this is possible if the small change I outlined above is made to

I think so too, we will have to see if we can include this until monday 
(submission deadline for drafts for IETF 93), so that it would be in the 
next released version of the draft.
 
> operation in the negotiation phase?this rather expensive operation

I think I get what you're saying, but I'm having difficulty following you 
where you talk about the exception to "this rule". What's the rule?

Also, let me try and summarize the use of Photuris cookies:
- For the (D)TLS based approach, we would basically only specify THAT a 
photuris cookie should be used.
- For the CMS based approach, we would specify another exchange in which a 
client gets several Photuris Cookies: one for Association/Certification 
exchange, one for Cookie Exchange, and possibly already one for Broadcast 
Parameter exchange (or, more summarized: one for each message exchange 
that involves expensive cryptographic operations and/or large response 
packets and therefore a large amplification opportunity)

Does that sound about correct? Or am I missing important aspects?
If I understood this correctly, then I would agree that this method has 
small cost and potentially large reward and we should look into it.

Best regards,
Kristof Teichel (PTB)