Re: Last Call: 'Storing Certificates in the Domain Name System (DNS)' to Proposed Standard

[Simon Josefsson <[e-mail]>]

Douglas Otis <[e-mail]> writes:

> When doing a comparison of the two documents, I did notice an error  
> unrelated to this topic.
>
> + The IPKIX, ISPKI and IPGP types indicate a URL which will serve the
> + content that would have been in the "certificate, CRL or URL" field
> + of the corresponding (PKIX, SPKI or PGP) packet types.  These types
> + are known as "indirect".  These packet types MUST be used when the
> + content is too large to fit in the CERT RR, and MAY be used at the
> + implementer's discretion.  They SHOULD NOT be used where the entire
> + UDP packet would have fit in 512 bytes.
>
> In RFC1035 for UDP, a message size is limited to 512 bytes, not the  
> packet size as indicated in this statement.  The data-gram limitation  
> is 576 bytes per RFC879.

Thanks for spotting this.  I have changed the last sentence to:

      They SHOULD NOT be used where the DNS message would have fit in
      a 512 byte UDP packet.

Is that OK with you?

>> I think we generally disagree.
>>
>> First, everyone is welcome to measure a before and after performance
>> characteristic.  If you do this thoroughly, and report your findings,
>> it would be a valuable resource and we could reference it in this
>> document.  However, at this point, I see nothing more than
>> speculations here.  Keep in mind that RFC 2538 has already been
>> published.
>
>
> This draft is recommending multiple owner-names and discusses use of  
> wildcard record synthesis.  This was the point I found alarming when  
> a method to synthesize records for every email message was described  
> in MASS.  This was the reason I suggested there should be some advice  
> given in the performance considerations section.  This version of the  
> draft very much adds to this concern.

Sure.  And I have no problem adding text to mention this potential
problem.  But I think your suggested text was biased and implied that
deploying this on a wide scale would be harmful.  I believe the
opposite would be true.  But let's try to move back to actually fixing
the document...

>>   It is already possible to deploy this mechanism, without
>> RFC 2538bis.  RFC 2538bis can only be based on what we know today, not
>> what we may know in a few years, so if you like to see this wide-scale
>> performance estimate done, please start working on it!
>
>
> I am not the one advocating use of this record, nor am I attempting  
> to embellish use of this record.  In the absence of modeling or  
> testing at projections of possible deployment, then _some_ statement  
> regarding a lack of this review should be made in the performance  
> section.  At least warn that this may cause foot damage. : )

...right.  So how about adding the following under "Performance
considerations"?

  <t>Deploying CERT RRs to support digitally signed e-mail change the
    access patterns of DNS lookups from per-domain to per-user.  If
    digitally signed e-mail, and a key/certificate lookup based on
    CERT RRs, is deployed on a wide scale, this may lead to an
    increase of DNS load.  Whether this load increase will be
    noticable is not known.</t>

Would that address your concerns?  Feel free to adapt and modify the
text, or even merge it with your proposal, then maybe we can get
something we both agree on.

Thanks,
Simon

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>