Subject: Re: [ntpwg] WG: I-D Action: draft-ietf-ntp-network-time-security-03.txt

From: Stephen Röttger <[email-masked]>
Date: Thu, 26 Jun 2014 15:36:41 +0000

Hey Kurt, sorry for the delay. Comments inline.

> > >- Have you considered keys other than RSA like EC?  Maybe if we
> > >  strongly suggest not to use RSA but something faster like EC
> > >  and sign the reply we we can make things both simpler and reduce
> > >  load on the server.
> >
> > I think we don't specify which algorithms should be used for the
> signatures
> > and encryption. We only say that the server uses X.509 certificates to
> prove
> > his identity, so any protocol supported by X.509 should be possible for
> us.
>
> Which makes me wonder if the client should send which types of
> key's it's willing to support, and if that's already planned or
> not.
>

That would require the Server to maintain multiple certificates. I think we
can let the client just drop the connection if he thinks the algorithm is
not strong enough (e.g. as openssl would do with MD2 certificates).

> The server might for instance want to use ECDSA.  But that's a
> sign only key that doesn't support encryption.  Would this work
> on the server side?  On the client side?  Would it require to
> also do ECDHE in that case?
>

You're right, that's a good point. The Server needs an algorithm in the
certificate that he can use for asymmetric signatures, while the client
needs one suitable for asymmetric encryption.
We don't plan to support DH (especially not ephemeral), since it would
require the server to do this calculation again on every request.
Maybe we can just specify it in the draft like this? (i.e. client's
algorithm must support asymmetric encryption, server's asymmetric
signatures)

> > As per suggestion of Steve Bellovin, we are currently thinking about
> > replacing the public key sent by the client with a X.509 certificate as
> > well, which would allow the client to choose the encryption method
> through
> > the certificate.
>
> We only use assymetric cryptography like RSA?  There is no transtion
> to something like AES?
>

Right, but we only use RSA to encrypt the shared secret.

> > I tried to find out before how OCSP servers handle revoked but expired
> > certificates. I couldn't find any specifics about this but I assume that
> > they can purge their database and remove expired certificates from them
> and
> > then reply with 'certificate not revoked'.
> > Does anyone know more about this?
>
> I think the best information for this is the CA/Browser forum
> baseline requirements.  It has those section in it which I think
> are relevant:
> | 13.2.4 Deletion of Entries
> | Revocation entries on a CRL or OCSP Response MUST NOT be removed
> | until after the Expiry Date of the revoked Certificate.
> [...]
> | 13.2.6 Response for non-issued certificates
> | If the OCSP responder receives a request for status of a
> | certificate that has not been issued, then the responder SHOULD
> | NOT respond with a "good" status. The CA SHOULD monitor the
> | responder for such requests as part of its security response
> | procedures.
>
> I assume that 13.2.6 applies to expired certificates too.
>

I don't know how I could miss until now, but the OCSP RFC actually says
that servers can send a 'good' response for revoked but expired
certificates:
  'The "good" state indicates a positive response to the status inquiry.
   At a minimum, this positive response indicates that no certificate
   with the requested certificate serial number currently within its
   validity interval is revoked.  This state does not necessarily mean
   that the certificate was ever issued or that the time at which the
   response was produced is within the certificate's validity interval.'

So OCSP is not working for people who synchronize their time to a public
server.

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

---

From: Stephen Röttger <[email-masked]>
Date: Mon, 07 Jul 2014 10:52:02 +0000

Asking for clarification sounds good. Do you know how to contact them?
However, as you mentioned, this will only work if the OCSP server supports
the Nonce extension.
On Sat Jul 05 2014 at 11:32:50 AM, Kurt Roeckx <[email-masked]> wrote:

> On Thu, Jun 26, 2014 at 03:36:41PM +0000, Stephen Röttger wrote:
> The RFS might not require it, but it's my understanding that the
> CA/B forum requirements do.  Should we try to make CA/B forum
> clarify it?
>
>
> Kurt
>
>