Re: [TLS] ticket lifetimes

On Tue, Jan 29, 2019 at 4:14 PM Subodh Iyengar <subodh@fb.com> wrote:

> > Wouldn't this issue also be mitigated by requiring the server to
> re-authenticate during resumption with the certificate once in a while?
>
> I think it's probably just easier to drop the resumption completely.
>
> > This two-lifetime thing is actually already what we implement in
> BoringSSL. 😊
>
> Fantastic. Would it help to have an extension to set a lower bound on this
> value, or just make it more painful?
>

(Did you mean upper bound?)

I'd actually interpreted the RFC 8446 text to imply a 7 day upper bound on
the renewability, but apparently that's not how others read it! I don't
care strongly either way about an extension to set a renewal bound, I
think. A client is always free to tighten ticket lifetime policies
unilaterally. We don't need an extension to advertise its policies unless
we want to allow server to change their behavior in response. In the other
direction, if we think the server may also have an opinion on renewability
(you mention keyless things), a NewSessionTicket extension would be easy to
support. The client would then use the more restrictive of the server's
preferences and its local policy.

Though, I guess, having not specified it this way from the start, the
server can't be sure the client honors the extension. I don't know what
consequences that has for server-preference scenario.

(For completeness, BoringSSL doesn't allow TLS 1.2 ticket renewals to
extend lifetime at all, only TLS 1.3, and TLS 1.2 lifetimes are capped much
more tightly. Since TLS 1.2 resumption doesn't involve an ECDH operation,
any concerns about a stale online signature are overshadowed by how much
data the client is willing to make vulnerable to a single session secret.
We'd probably do something similar if we implemented TLS 1.3's
plain psk_ke, but we only do psk_dhe_ke.)

David

> Subodh
> ------------------------------
> *From:* David Benjamin <davidben@chromium.org>
> *Sent:* Tuesday, January 29, 2019 1:02 PM
> *To:* Nick Sullivan
> *Cc:* Subodh Iyengar; tls@ietf.org
>
> *Subject:* Re: [TLS] ticket lifetimes
> This two-lifetime thing is actually already what we implement in
> BoringSSL. :-) We track both a lifetime for the ticket (one day) and also
> for the original authentication the ticket roots up to (one week). The
> lifetime of the ticket is bounded by both these values, and the latter is
> not extendable on renew.
>
> On Tue, Jan 29, 2019 at 2:18 PM Nick Sullivan <nick=
> 40cloudflare.com@dmarc.ietf.org> wrote:
>
> Wouldn't this issue also be mitigated by requiring the server to
> re-authenticate during resumption with the certificate once in a while?
>
>
> Existing servers won't do this, so I see this less as a mitigation and
> more as an optimization to plug the one-week-cliff that the fix produces.
> But, yeah, that would be handy. (Probably something like: "re"-auth'd
> identity apply to tickets, PSK applies to connection. Client sends an
> extension to advertise we're nearing the unrenewable bound.)
>
> David
>
>
> Nick
>
> On Tue, Jan 29, 2019 at 11:00 AM Subodh Iyengar <subodh@fb.com> wrote:
>
> > If by "entire TLS session" you mean the resumed (and renewed)
> sessions, then yep!
>
> Ya I think that'd need a new draft either way. Can definitely write that up
> if people don't think it's the worst idea in the world.
>
> Subodh
> ------------------------------
> *From:* Christopher Wood <christopherwood07@gmail.com>
> *Sent:* Monday, January 28, 2019 10:13:36 PM
> *To:* Subodh Iyengar
> *Cc:* tls@ietf.org
> *Subject:* Re: [TLS] ticket lifetimes
>
> On Mon, Jan 28, 2019 at 10:04 PM Subodh Iyengar <subodh@fb.com> wrote:
> >
> > > Since clients already store tickets, could they not also store the
> > time of original ticket issuance and cap the resumption window to N
> > (7) days from that point? That is, it seems clients could implement
> > this behavior without any protocol support.
> >
> > Correct, however the server currently provides a value for this, and
> clients do not enforce a lower bound on this. 7 days is an upper bound.
> > Servers would provide a much lower value than 7 days practically.
> >
> > If I'm understanding your suggestion correctly, you're suggesting that
> clients change the meaning of ticket_lifetime_hint?
> > That is not just limit it to the scope of the ticket but the entire TLS
> session? That would be fine to by me, however might break some folks.
>
> If by "entire TLS session" you mean the resumed (and renewed)
> sessions, then yep!
>
> Best,
> Chris
>
> >
> > Subodh
> > ________________________________
> > From: Christopher Wood <christopherwood07@gmail.com>
> > Sent: Monday, January 28, 2019 9:57 PM
> > To: Subodh Iyengar
> > Cc: tls@ietf.org
> > Subject: Re: [TLS] ticket lifetimes
> >
> > On Mon, Jan 28, 2019 at 9:43 PM Subodh Iyengar <subodh@fb.com> wrote:
> > >
> > > In TLS 1.3 we added a maximum age to the ticket lifetime to be 7 days.
> This had several original motivations including reducing the time that a
> ticket is reused (for privacy or PFS). Another major motivation for this
> was to limit the exposure of servers that use keyless ssl like mechanisms,
> i.e. if they kept a STEK locally, but the keyless SSL server remotely, then
> the theft of a STEK would presumably limit the MITM capabilities to the
> ticket lifetime.
> > >
> > > However thinking about it some more because of the renewal capability
> of tickets in TLS 1.3, an entity owning the STEK could just re-issue new
> tickets forever on a resumed connection. This would look to the client as a
> new ticket and it would refresh its lifetime on the ticket. Thereby a MITM
> could intercept connections to users that have been to the server with the
> STEK. I'm wondering whether it might be useful to define a mechanism to
> limit the lifetime of all ticket resumption across all resumptions from the
> original connection instead of just the limited per ticket lifetime.
> >
> > Since clients already store tickets, could they not also store the
> > time of original ticket issuance and cap the resumption window to N
> > (7) days from that point? That is, it seems clients could implement
> > this behavior without any protocol support.
> >
> > Best,
> > Chris
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=AeHpkYXwQtF4DjfqdHNluOLIcTHODTihn7i4WBzucjA&s=B4zL6Emv0jyhAsuJyBnxMzO8l1w7SDu5OpB4m8jarMk&e=>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=AeHpkYXwQtF4DjfqdHNluOLIcTHODTihn7i4WBzucjA&s=B4zL6Emv0jyhAsuJyBnxMzO8l1w7SDu5OpB4m8jarMk&e=>
>
>