On Thu, Apr 05, 2018 at 02:46:12AM -0400, Viktor Dukhovni wrote:
> > On Apr 4, 2018, at 1:50 PM, Joseph Salowey <j...@salowey.net> wrote:
> > A) Recommendation of adding denial of existence proofs in the chain
> > provided by the extension
> > B) Adding signaling to require the use of this extension for a period of
> > time (Pinning with TTL)
> > C) Both
> Therefore, the real choice before us is (C) or not (C), the choices of (A)
> alone or (B)
> alone are unsound half-measures.
I agree that both (A) and (B) are bad idea, while (C) is sound idea.
> (C) is essentially STS for dane chains over TLS with downgrade protection
> after first
> contact, and imposes no burden on the present implementors. If they were
> willing to
> implement without a pin or denial of existence, they can ignore the pin TTL
> and never
> transmit denial of existence (which their clients would not expect to
If one wants to save bandwidth in "cancel pin" case, one could add
a flag into request that tells the server if it should transmit DoE
or not (if it has actual chain, that should be transmitted anyway).
That way, the cancel would only need to be transmitted once to each
client, instead of potentially multiple times, and clients that do
not support pinning would not waste downstream bandwidth downloading
cancels they would ignore anyway.
TLS mailing list