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

[[e-mail]]

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

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

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)

_______________________________________________
ntpwg mailing list
[e-mail]
http://lists.ntp.org/listinfo/ntpwg