Re: [TLS] OPTLS: Signature-less TLS 1.3

On Nov 5, 2014 9:51 AM, "Nico Williams" <nico@cryptonector.com> wrote:
>
> On Wed, Nov 5, 2014 at 11:45 AM, Martin Thomson
> <martin.thomson@gmail.com> wrote:
> > On 5 November 2014 08:27, Hugo Krawczyk <hugo@ee.technion.ac.il> wrote:
> >> The issue of validity period of the static key g^s is not different
than
> >> that of a regular certificate except that the server can choose a
shorter
> >> validity period for g^s than the one for the certificate. That is, if
the
> >> client's clock is skewed by Delta and the validity of g^s is up to
time T,
> >> the client will accept g^s till time T+Delta. Similarly, if the
certificate
> >> expires at time T', the client will accept it until T'+Delta. In either
> >> case, if T<T' the client will accept g^s for less time than it would
accept
> >> the certificate.
> >
> > I think that the core concern is that Delta is basically unbounded in
> > some implementations (see [1]).
> >
> > [...]
> >
> > [1]
https://www.blackhat.com/docs/eu-14/materials/eu-14-Selvi-Bypassing-HTTP-Strict-Transport-Security-wp.pdf
>
> Perhaps we should pin latest datetime advertised by the server for
> which other things are being pinned.  This would prevent time travel
> into the past.  Time travel into the far future is, presumably, not
> that big a deal, even with pinning, because server operators will
> strive to make sure that doesn't happen.

Or kernels can set the flag that stops this from being possible. We should
note the issue, and, as with randomness, let the vendors solve it.

For a problem solved by a configuration change,  we are spending a lot of
time on it.

Sincerely,
Watson Ladd
>
> Nico
> --
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls