Re: [dns-privacy] Some additional signalling ideas
Ilari Liusvaara wrote: > > Adding another RRtype with needed magic properties would take Standards > Action (as expert review requires RRtype not to be magic) and then > updating parent nameservers to be able to deal with the RRtype (since > it can not be generically handled). Don't forget the implications for EPP and the zoo of registrar UIs and APIs. Tony. -- f.anthony.n.finchhttp://dotat.at/ Malin: Southwest veering west, then becoming cyclonic later, 5 to 7. Moderate or rough, becoming rough or very rough, occasionally high later. Rain then wintry showers. Good, occasionally poor. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Some additional signalling ideas
> On 01/04/2019 07:19, Alexander Mayrhofer wrote: > > I have some experience in creating drafts for "funny" EDNS0-options > > (RFC7830), so I'd volunteer :-P > Actually, that maybe raises a point. If use of DoT to secure recursive to > authoritative traffic also requires padding (and I can't see why that's > different from the stub-recursive situation), then presumably deployment of > this EDNS0-option is needed in any case, so does that imply that a new > option for signalling would actually be just as practical, in deployment > terms? [AM] Hmm.. It's April 1st, so why not abuse the EDNS0 padding payload to convey certificate fingerprints? Oh, well, we excluded the use of Padding for unencrypted transport.. hmm. ;) Best, Alex ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Some additional signalling ideas
On 01/04/2019 07:19, Alexander Mayrhofer wrote: > I have some experience in creating drafts for "funny" EDNS0-options > (RFC7830), so I'd volunteer :-P Actually, that maybe raises a point. If use of DoT to secure recursive to authoritative traffic also requires padding (and I can't see why that's different from the stub-recursive situation), then presumably deployment of this EDNS0-option is needed in any case, so does that imply that a new option for signalling would actually be just as practical, in deployment terms? Cheers, S. 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Some additional signalling ideas
All, > Dear all, > Please rip these ideas to shreds: > 1) An extra bit in a response for "you could have asked over TLS" > 2) An extra field when looking up the nameserver for "you can ask that > server over TLS" > 3) An extra field/bit/convention for "this nameserver supports tls" > (like tls-ns vs ns) [AM] Another "probably bad idea", as mentioned in the WG session... 4) And EDNS0-option "Encryption available" sent from server to client, eventually including flags for which encrypted protocol is available? I have some experience in creating drafts for "funny" EDNS0-options (RFC7830), so I'd volunteer :-P Best, Alex ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
