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

From: [email-masked]
Date: Wed, 1 Jul 2015 15:55:35 +0200

Hi Florian,

we want to prepare the language for the mentioned between the negotiation 
and post-negotiation phases. Do we understand you correctly that your 
proposed opaque blob session ticket is important for the negotiation and 
not for the post-negotiation phase?

Dieter 

From:   Florian Weimer <[email-masked]>
To:     [email-masked]
Cc:     [email-masked]
Date:   05.06.2015 14:28
Subject:        Re: [ntpwg] NTS: The question of CMS vs. (D)TLS
Sent by:        "ntpwg" <ntpwg-bounces+dieter.sibold=[email-masked]>

On 06/05/2015 11:58 AM, [email-masked] wrote:

> (2) Draft for utilization of NTS for NTP 
> (draft-ietf-ntp-using-nts-for-ntp)
> - In this draft, we intend to specify that for bootstrapping, an 
> implementation MUST support the use of the CMS-based message exchanges, 
as 
> described in the informational appendix mentioned above.
> - We will further specify that an implementation MAY also support other 
> methods for bootstrapping, for example exchanging the necessary data via 

> DTLS or DANE. Any such method needs to fulfill the requirements given in 

> the main draft.

This seems okay to me, as long as there is a clean separation between
the negotiation and post-negotation phase, and the session ticket is
treated as an opaque blob (of variable length).  I would have to see the
actual language to be sure.

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

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

---

From: Florian Weimer <[email-masked]>
Date: Wed, 01 Jul 2015 16:13:47 +0200

> not for the post-negotiation phase?

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.

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

---

From: [email-masked]
Date: Wed, 1 Jul 2015 16:32:37 +0200

Thanks for clarification. 

Dieter Sibold

Florian Weimer <[email-masked]> wrote on 01.07.2015 16:13:47:

> To: [email-masked]
> Cc: [email-masked], [email-masked]
> Date: 01.07.2015 16:13
> I used ?session ticket? in the sense of RFC 5077.  From the client
> recover the entire session state from that?which includes the key used