On Wed, 27 May 2020, Peter van Dijk wrote:
DoT authoritatives would need to keep both the old and new certificates
on hand during the transition
keys, not certificates
I would not rule out that people want to run this using a CA chain.
Limiting the signaling to EE-certs or pubkeys is
On Wed, 27 May 2020, Petr Špaček wrote:
- I don't see any traction for draft-ietf-tls-dnssec-chain-extension. Do you
see any evidence it is going to change?
The draft has been resubmitted for the ISE stream (not TLS WG) as
draft-dukhovni-tls-dnssec-chain
Stubby already implements it. We
On Wed, 27 May 2020, Ben Schwartz wrote:
I agree that the TLS DNSSEC chain extension isn't substantially deployed today,
but I don't think that should stop us from using it if
it would help. This use case is important enough to drive deployment.
If people really want to avoid doing an extra
Peter van Dijk wrote:
> On Tue, 2020-05-26 at 09:10 +0200, Ondřej Surý wrote:
> >
> > 1. Bit 7 of the Flags fields needs to be 0.
>
> Definitely [...] I noted earlier that whatever flags we might need, it's
> definitely *not* ZONE and SEP.
>
> > 2. This needs a new Protocol number
>
> I
Thanks for the explanations. Having multiple TLS-DS records during TLS key
rolls does seem like a pretty good solution.
There are still some potential operational rough edges here. For example,
an "emergency" certificate replacement (e.g. in event of compromise) is
difficult, because the old
Hello Ben,
On Tue, 2020-05-26 at 21:27 -0400, Ben Schwartz wrote:
> I like the idea of signalling DoT support in the DS record, but I worry a bit
> about putting the SPKI fingerprint in the DS as well. Having to update the
> parent zone whenever the TLSA key needs to be rotated seems
On 27. 05. 20 3:27, Ben Schwartz wrote:
> I like the idea of signalling DoT support in the DS record, but I worry a bit
> about putting the SPKI fingerprint in the DS as well. Having to update the
> parent zone whenever the TLSA key needs to be rotated seems cumbersome and
> fragile,
