Re: Skipping DNS resolutions with ORIGIN frame

On Tue, Jul 18, 2017 at 10:05 AM, Ilari Liusvaara <ilariliusvaara@welho.com>
wrote:

> On Tue, Jul 18, 2017 at 07:34:24AM +0000, Subodh Iyengar wrote:
> > +1 for the requirement for CT. I feel uncomfortable skipping DNS
> > without requiring at least CT.
> >
> > As for OCSP stapling, I can see the argument for requiring it, but I
> > would also like to offer short lived certificates or delegated
> > credentials (https://tools.ietf.org/html/draft-rescorla-tls-subcerts-01)
> > as equivalent requirement.
>
> Note that delegated credentials do not replace OCSP. E.g., handling key
> compromise of the issued EE certificate.
>
> And yes, short-lived certificates can be used to replace OCSP stapling:
> In WebPKI, if OCSP response valid to EoL of the certificate is signed,
> the certificate becomes effectively impossible to revoke.
>
> Since normal OCSP lifetime in WebPKI (not refresh interval, which must
> be shorter for things to work properly) is 7 days, it follows that
> certificates that are valid for at most 7 days do not need OCSP
> stapling. The 7 days figure also pops up in TLS 1.3, when operation
> independent of certificates is concerned.
>

I imagine that the definition of a strong revocation check is going to vary
from client to client. For example in Chrome I'm not sure that it would be
reasonable to require OCSP/short-lived cert if the certificate is covered
by a fresh CRLSet.


>
>
> > In general I think it's incredibly valuable to define the guidelines
> > for skipping DNS in the specification. This makes it easier for
> > service operators to be able to use this functionality in a uniform
> > manner. These guidelines were missing for PUSH which made it very
> > hard to use.
>
> Are you referring to more exotic ways to use PUSH, e.g. pushed cache
> invalidation? Those look to be rather subtle.
>
> (There are other problems with PUSH, like controlling resources to
> push from web application and guessing what to send, but I think that
> would be much beyond the scope of HTTP/2 RFC).
>
>
> -Ilari
>
>