A few of us were chatting after the meeting and I suspect that the 64 octet limit for a label is going to create a problem with using split base32. It sounds as though we would end up limiting the LHS to 40 octets before the encoding.
On 7/20/15, 12:12 PM, "Peter van Dijk" <[email protected]> wrote: >Hello, > >On 20 Jul 2015, at 12:29, Paul Wouters wrote: > >> On Mon, 20 Jul 2015, Wiley, Glen wrote: >> >>> Has there been any recent discussion about using a non-hashed LHS >>> encoding? I don¹t think there has so we probably don¹t want to >>> bring >>> that question into scope here. >> >> There was some interested by the powerdns people for this, as they >> implement an online signer and could deliver custom signed responses. >> John Levine also prefered this approach in the past. > >Indeed - *not* doing the hashing has many potential benefits (most of >which do require online signing to fully reap), and few downsides. Split >base32 massively increases the potential surface area for opportunistic >encryption, while hashing strictly rules out those benefits. Besides the >functional benefits, base32 also is easier for debugging. > >So far I’ve seen two downsides to split base32 mentioned: >(1) split base32 has a longer maximum length than a hash (although in >practice it will actually be shorter than a hash, for most addresses) >(2) privacy > >As Paul mentions further down this thread, if we start caring about >privacy we have more work to do. > >> While I think the non-hash version is uglier, I don't think that is >> a valid reason not to do it. > >I don’t think any of the options look pretty - including base32. This >fate we have to accept when shoehorning things into the DNS! > >Kind regards, >-- >Peter van Dijk >PowerDNS.COM BV - https://www.powerdns.com/ > >_______________________________________________ >dane mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/dane _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
