[ietf-dkim] agenda item on upgrading hash algorithms?
pbaker at verisign.com
Thu Feb 23 13:54:49 PST 2006
Clean room implementation is irrelevant as far as patents are concerned.
I do not believe the 25% inefficiency introduced by base 64 encoding
adds to the problem of small DNS record sizes in a significant or
important manner or that your proposed transition to a binary format
solves the problem to a significant or useful degree.
We know that 4096 bit keys will not fit into a standard DNS record.
The difficulties you raise with TXT records appear to be insignificant
compared to the fact that about half the deployed infrastructure does
not support new binary records and it will be 2009 at the very earliest
before the vendor concerned makes a new server release.
People might not mind your endless confused speculation over
non-problems so much if you appeared to be interested in the real
problems we face.
> -----Original Message-----
> From: Douglas Otis [mailto:dotis at mail-abuse.org]
> Sent: Thursday, February 23, 2006 4:42 PM
> To: Hallam-Baker, Phillip
> Cc: ietf-dkim at mipassoc.org
> Subject: Re: [ietf-dkim] agenda item on upgrading hash algorithms?
> On Feb 23, 2006, at 12:32 PM, Hallam-Baker, Phillip wrote:
> > I think that we are all aware that IP owners have a duty to their
> > shareholders to promote the value of their IP in the best possible
> > light.
> > We do not need point compression for our purposes. Nor is
> > a critical issue. The only crucial criteria is a bit
> length of 1024
> > bits or less.
> The issue raise regarding IPR was not related to point compression.
> In addition to defending against known attacks, Certicom IPR
> claims also relate to basic algorithm improvements which
> makes clean-room development difficult. Is there
> elliptic-curve code within the public domain not encumbered,
> which can be safely used in the near future? If ECC code is
> not ready now, when will it be? Can someone predict whether
> ECC, with its small keys sizes, will not become vulnerable as
> has SHA-1? There is less private key information to leak.
> Although there are text-based conventions for entering binary
> RRs into DNS, this discussion was considering whether space
> was available within the TXT RR to accommodate upgrade
> declarations, or whether a binary structure for DKIM key RR
> should be considered. An ability to accommodate 2048 bit
> keys does not preclude use of ECC, when that proves feasible
> and desirable. However, not having an ability to accommodate
> 2048 bits may create much greater disruption. Why paint DKIM
> into a corner? Surely a binary RR is easier than developing
More information about the ietf-dkim