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

[Florian Weimer <[e-mail]>]

On 07/02/2015 03:41 PM, [e-mail] wrote:

> 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

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?

> 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 think this is possible if the small change I outlined above is made to
the protocol.

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

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

> I see your point here. I am unsure, however, how highly we should place 
> 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.

-- 
Florian Weimer / Red Hat Product Security
_______________________________________________
ntpwg mailing list
[e-mail]
http://lists.ntp.org/listinfo/ntpwg