4 ms·

Yes, I've been seeing Needham-Schroeder as a possible optimization in a PQ world, but in order to make it so we'll need a true Kerberos-ish infrastructure. I'v

Yes, I've been seeing Needham-Schroeder as a possible optimization in a PQ world, but in order to make it so we'll need a true Kerberos-ish infrastructure. I've played a lot (in my mind, mainly, though I've done some implementation work) with using PKINIT and DANE to build something like the PKCROSS that never happened. I.e., we could use PKI (DANE preferably, as opposed to x.509) to bootstrap Kerberos symmetric trusts as needed / on demand. There's a lot to think about before jumping in, like: - can we simplify Kerberos V5 and/or fix various problems in it, or start from scratch (and simpler)? (IMO: start from scratch) - think that symmetrically-encrypted JWT is a lot like Kerberos' AP protocol - we should strive to have an RFC 4559 style bearer token profile that can be used with much less code than Kerberos is traditionally implemented with - we should strive to have Needham-Schroeder in TLS so that we don't need all of the awful krb5_...() APIs nor GSS-API - though keep in mind that GSS-API is a good basis for a TLS API (that's what SChannel is: TLS as an SSP using the SSPI, and SSPI is the MSFT equivalent of GSS-API) - let's make sure there's JSON-ish extensibility in token/ticket/whatever metadata - let's make sure various Kerberos V5 mistakes get fixed / not remade > Revocation by CAs is easy and can be immediately effective. This is also true with DANE for the same reason: you're relying on a DNS RR being removed, both from its zone and from caches (so, low TTLs, though not excruciatingly low). It's also true in Kerberos V5 because tickets are typically short-lived. PKIX could do this too (short-lived certificates). > The client finds three of these CA records where the UUID matches a CA that the client trusts. I'm really not fond of the idea that we should repeat the non-hierarchical mistakes of WebPKI. I'd rather we find a way to live with the DNSSEC PKI and increase trust in it by making it harder to subvert: 1) always use QName minification in making DNS queries, 2) add CT to DNSSEC, 3) make client detect and inform users about unexpected changes in zone pubkeys (1) means that an MITMing root zone or TLD zone doesn't get to know [from the query] the full name you're trying to resolve, which means they need to commit to MITMing before knowing how interested they might be in MITMing, and then this forces them to stay in the middle. (2) is obvious: try to catch the root and TLDs MITMing. (3) is also about clients noticing possible MITMing.

tptacek 3y ago
This isn't a rebuttal, because it's good to want things, and DNSSEC would be better with binding transparency, but the reason you don't have DNSSEC CT isn't that nobody has designed it yet, but rather that Mozilla and Google forced CAs to adopt CTs and refuse to accept certificates without SCTs. No such pressure point exists for force DNS registrars --- which are generally controlled by state entities --- to adopt such a thing.
- cryptonector 3y ago
  Registrars will do what the registries say. Registries typically implement DNSSEC even w/o state mandates. I expect that root and TLD zones would support SCTs eventually. I also expect that there are not many MITM attacks in DNSSEC by nation-states. The single most important thing here is QName minimization because it will force MITMing zones to commit to being and staying in the middle early, and that's very risky for them. QName minimization does come at a price: extra DNS round trips, though most of those will be very cacheable and have high cache hit rates, but cold caches hurt.
  - tptacek 3y ago
    Why would .US or .IO support mandatory SCTs? These domains are under de jure control of governments that routinely subvert the DNS for intelligence and criminal justice reasons. It's not like the CA's volunteered to do mandatory CT: they had to get dragged into it, because Mozilla and Chrome could credible threaten to dis-trust them. They can't do that with the DNS.
    - cryptonector 3y ago
      Because businesses that don't want those zones to MITM them will move to zones that do support SCTs. It's not as strong a reason as Mozilla and Chrome arm twisting WebPKI CAs, as sovereigns can resist longer, but eventually it will happen.
      - tptacek 3y ago

tptacek 3y ago

This isn't a rebuttal, because it's good to want things, and DNSSEC would be better with binding transparency, but the reason you don't have DNSSEC CT isn't that nobody has designed it yet, but rather that Mozilla and Google forced CAs to adopt CTs and refuse to accept certificates without SCTs. No such pressure point exists for force DNS registrars --- which are generally controlled by state entities --- to adopt such a thing.

cryptonector 3y ago
Registrars will do what the registries say. Registries typically implement DNSSEC even w/o state mandates. I expect that root and TLD zones would support SCTs eventually. I also expect that there are not many MITM attacks in DNSSEC by nation-states. The single most important thing here is QName minimization because it will force MITMing zones to commit to being and staying in the middle early, and that's very risky for them. QName minimization does come at a price: extra DNS round trips, though most of those will be very cacheable and have high cache hit rates, but cold caches hurt.
- tptacek 3y ago
  Why would .US or .IO support mandatory SCTs? These domains are under de jure control of governments that routinely subvert the DNS for intelligence and criminal justice reasons. It's not like the CA's volunteered to do mandatory CT: they had to get dragged into it, because Mozilla and Chrome could credible threaten to dis-trust them. They can't do that with the DNS.
  - cryptonector 3y ago
    Because businesses that don't want those zones to MITM them will move to zones that do support SCTs. It's not as strong a reason as Mozilla and Chrome arm twisting WebPKI CAs, as sovereigns can resist longer, but eventually it will happen.
    - tptacek 3y ago