[prev in list] [next in list] [prev in thread] [next in thread] 

List:       dns-security
Subject:    Re: General comments on last call DNSSEC drafts
From:       "Donald E. Eastlake 3rd" <dee3 () torque ! pothole ! com>
Date:       1998-08-31 18:50:45
[Download RAW message or body]


Brian,

From:  Brian Wellington <bwelling@tis.com>
Date:  Wed, 29 Jul 1998 11:32:30 -0400 (EDT)
To:  dns-security@tis.com
Message-ID:  <Pine.LNX.3.96.980729110332.31736E-100000@askew.hq.tis.com>

>I read through all of the drafts last week, and have a few minor comments
>on several of them.  None of these are critical (and definitely should not
>prevent recycling at Proposed Standard or movement to Informational), but
>I'd like to discuss them anyway.  Without further ado: 
>
>General question:
>- The "Current DNS implementations are optimized for small transfers"
>  paragraph is present is all of the drafts.  Yes, this is an important
>  cpnsideration, but is such repitition necessary?

Yes, it is present in many of the drafts.  This is partly becasue some
of the drafts were formed by splitting or closing and then modifying
earlier drafts.  It seems to me that the remarks are short enough that
it would not be worth while abstracting them into a separate document.
Perhaps the material can be re-organized at some point in the future
when we go to Draft Standard or the like.

>draft-ietf-dnssec-certs-02.txt:
>- The CERT record contains a "key tag" field to allow the CERT to be more
>  easily paired with a KEY record.  Are multiple CERT with the same
>  name and key tag allowed, and are there special considerations?

Yes, there is no problem with multiple CERTs for the same subject and
the key tag could be the same because they are different types of
CERTs with the same public key in them or just because of random key
tag collisions.  Perhaps this should be explicitly mentioned in the
draft.

>- Is the matching key required to have the same name as the certificate?
>  There could be cases where this is undesirable.

No, although it seems to me it should be common for them to.

>draft-ietf-dnssec-ddi-05.txt
>- Except for the fact that the example scenario uses KEY records, this
>  draft has nothing to do with DNSSEC.  Why is it associated with DNSSEC?

Why not?  TSIG seems like it should be in DNSSEC but its in DNSIND.
The IETF is not too doctrinaire about such things.  And I think a
major use of detached DNS info would be to construte certificate like
chunks that include a KEY RRset and authenticating SIG(s).  What uses
do you think would be common?

>draft-ietf-dnssec-dhk-02.txt
>- In section 2:
>  > If "prime length" field is 1 or 2, then the "prime" field is actually
>  > an unsigned index into a table of up to 65,536 predefined
>  > prime/generator pairs to be defined in which case the generator length
>  > should be zero.
>  I believe this has been brought up before, but this is unimplementable
>  until this table is specified, and any attempt to implement would lead
>  to incompatibility between vendors.

That's why it says "to be defined".  The meaning of a prime length of
1 or 2 is reserved to point into a table to be defined by a future
document.  And I suspect this future document will be revised as more
standard pairs are thought up.  Is IP "unimplementable" because the
meaning of all values of the protocol byte are not yet defined?

>draft-ietf-dnssec-dss-02.txt
>- The DSS KEY record contains a 'T' field, from which the key length can
>  be determined.  Since the key length can be determined from the RR size,
>  this is not necessary.  Also, the meaning is reserved if T > 8.  If the
>  reserved values are designed to allow longer keys, T is still not
>  necessary; if it some other reason, then a new algorithm identifier
>  should be specified for those cases.  As mentioned in the draft, T is
>  irrelevant for SIG records.

The idea is that the DSS KEY record corresponds to the DSA Standard.
This has already been changed once to allow for longer keys.  It is
not clear to me what changes could occur later.  I basicly do not
agree that if later changes were for other than key length, a
different algorithm byte should be used.  I put T in the SIG, as it
says, so such future changes could be indicated within the DSA
algorithm.

>draft-ietf-dnssec-rsa-00.txt
>- The European equivalent of RSAREF is called RSAEURO, not EuroRef.

Thanks, I'll fix that.

>draft-ietf-dnssec-secops-01.txt
>- A small addition to Section 4.2, DSS Key Sizes.  DSS signatures are not
>  only smaller than RSA sigs, they are a fixed size regardless of key
>  size (41 octets currently, 40 if T is removed).

OK.

>draft-ietf-dnssec-secext2-05.txt
>- Transaction signatures have a flaw.  There is no way for a resolver to
>  specify that the response to a query MUST be signed.  A resolver is not
>  required to drop a response with no transaction signature when it
>  expects the response to have one.  Thus, the signature is useful when
>  present, but if not present, it could be the result of an attacker
>  stripping off the signature and modifying the payload.

Since in DNSSEC, these are public key signatures, they are quite
expensive computationally.  It is unreasonable in general to require
that servers sign responses or check signatures on requests.  Perhaps,
instead of just saying that they are "optional", the draft should say
they are only added or checked by mutual agreement...

>Comments?
>
>Brian

Thanks for the comments,

Donald

[prev in list] [next in list] [prev in thread] [next in thread]