headers
Francis Dupont | 4 May 2009 16:16
Picon

Re: [dnsext] I-D Action:draft-ietf-dnsext-tsig-md5-deprecated-02.txt

 In your previous mail you wrote:

   >Abstract

=> changed goal into purpose and added something about MD5 and TKEY.

   >1.  Introduction
   "lower than expected" -> "weaker than expected"?
   (RFC 4635 uses "stronger")

   >    1.  Mark HMAC-MD5.SIG-ALG.REG.INT as optional in the TSIG algorithm
   >        name registry managed by the IANA under the IETF Review Policy
   >        [RFC5226]

   Can we mark it "historic" instead of "optional?"  Or even "deprecated?"

=> about this (and similar other comments): this point was proposed but
was rejected by rough consensus. The two problems are:
 - there is no deprecated or historic requirement keywords
 - there is no crypto reason to ban HMAC-MD5

   >5.  Availability Considerations

   And SHA1 "is [eventually?} likely to suffer" - any time soon?  This 
   doc title is about HMAC-MD5, not SHA1.

=> SHA1 end of life is planned in 2010 (cf NIST, BTW 2010 is next year)
so even there is nothing against HMAC-SHA1 the same availability problem
could occur so between the two remaining "mandatory to support" algos
HMAC-SHA256 is the best candidate.
(Continue reading)

Permalink | Reply | 7 comments |
headers
The IESG | 5 May 2009 18:28
Picon
Favicon

Last Call: draft-ietf-dnsext-dnsproxy (DNS Proxy Implementation Guidelines) to BCP

The IESG has received a request from the DNS Extensions WG (dnsext) to 
consider the following document:

- 'DNS Proxy Implementation Guidelines '
   <draft-ietf-dnsext-dnsproxy-05.txt> as a BCP

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
ietf <at> ietf.org mailing lists by 2009-05-19. Exceptionally, 
comments may be sent to iesg <at> ietf.org instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnsproxy-05.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18026&rfc_flag=0

_______________________________________________
IETF-Announce mailing list
IETF-Announce <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce
Permalink | Reply | 0 comments |
headers
Jeroen Massar | 6 May 2009 22:26
Favicon
Gravatar

[dnsext] Domain "Flag" to indicate (non-)availability of automatic DNS updates for reverse DNS

Hi,

I guess quite a few ISPs who are providing public IP addresses to their
customers must be seeing these and then loads of them on their NS's:

May  5 14:15:14 noc named[26139]: client xxxx:xxxx:xxxx::x#3421046:
update '3.2.1.8.b.d.1.0.0.2.ip6.arpa/IN' denied

or the IPv4 equivalent. Now I know that most of these will come from
Windows as they have this setting activated per default and one could if
running inside an Active Directory turn those off easily, but in the
case where one doesn't have control over the hosts in question it would
be nice if there was a flag for indicating that the zone is able or not
to update, and possibly where to send updates. Is there such a mechanism
already?

If there is no such option, maybe something like:
$ORIGIN 3.2.1.8.b.d.1.0.0.2.ip6.arpa.
 <at> 	DDNS .

or:
 <at> 	DDNS ddns-updates.example.net.

The first indicating there is no updating host, the latter indicating
where to send updates, as otherwise the NS in the SOA will always get
the queries and maybe that is not the correct location.

note: finding the ORIGIN of the zone where that record is available is
of course a tricky thing, IPv6 it is most likely at the /64 level but it
could be higher up, would a per-nibble-scan then be the idea, for IPv4
(Continue reading)

Permalink | Reply | 5 comments |
headers
Mark Andrews | 7 May 2009 01:45

Re: [dnsext] Domain "Flag" to indicate (non-)availability of automatic DNS updates for reverse DNS


In message <4A01F27B.10404 <at> spaghetti.zurich.ibm.com>, Jeroen Massar writes:
> This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
> --------------enigF842B7CDDCA78E6FBBFFED67
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
> 
> Hi,
> 
> I guess quite a few ISPs who are providing public IP addresses to their
> customers must be seeing these and then loads of them on their NS's:
> 
> May  5 14:15:14 noc named[26139]: client xxxx:xxxx:xxxx::x#3421046:
> update '3.2.1.8.b.d.1.0.0.2.ip6.arpa/IN' denied
> 
> or the IPv4 equivalent. Now I know that most of these will come from
> Windows as they have this setting activated per default and one could if
> running inside an Active Directory turn those off easily, but in the
> case where one doesn't have control over the hosts in question it would
> be nice if there was a flag for indicating that the zone is able or not
> to update, and possibly where to send updates. Is there such a mechanism
> already?
> 
> If there is no such option, maybe something like:
> $ORIGIN 3.2.1.8.b.d.1.0.0.2.ip6.arpa.
>  <at> 	DDNS .
> 
> or:
>  <at> 	DDNS ddns-updates.example.net.
>
(Continue reading)

Permalink | Reply | 3 comments |
headers
Ted Lemon | 7 May 2009 02:21

Re: [dnsext] Domain "Flag" to indicate (non-)availability of automatic DNS updates for reverse DNS

On May 6, 2009, at 6:45 PM, Mark Andrews wrote:
> 	The real question is how to do this so that spoofed updates
> 	are not processed.  A update over TCP should be strong
> 	enough for this.

CGA would work nicely for IPv6.   TCP depends on there being good  
isolation between hosts on the local network, which I don't think is a  
valid assumption.

--
to unsubscribe send a message to namedroppers-request <at> ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
Permalink | Reply | 1 comment |
headers
Mark Andrews | 7 May 2009 03:01

Re: [dnsext] Domain "Flag" to indicate (non-)availability of automatic DNS updates for reverse DNS


In message <6010D0D0-BA8B-461E-B252-A1913F2F6591 <at> nominum.com>, Ted Lemon writes:
> On May 6, 2009, at 6:45 PM, Mark Andrews wrote:
> > 	The real question is how to do this so that spoofed updates
> > 	are not processed.  A update over TCP should be strong
> > 	enough for this.
> 
> CGA would work nicely for IPv6.

Agreed but that also requires protocol work to add signature method.

> TCP depends on there being good  
> isolation between hosts on the local network, which I don't think is a  
> valid assumption.

It should be reasonable for many situations.  Looking at my cable
connection I can't see any of my neighbor's traffic so to spoof
this requires a blind TCP spoof.  Add some ingress filtering and
this is almost impossible to break.

Mark

--

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews <at> isc.org

--
to unsubscribe send a message to namedroppers-request <at> ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joe Abley | 7 May 2009 07:40
Picon

Re: [dnsext] Domain "Flag" to indicate (non-)availability of automatic DNS updates for reverse DNS


On 6-May-2009, at 22:26, Jeroen Massar wrote:

> I guess quite a few ISPs who are providing public IP addresses to  
> their
> customers must be seeing these and then loads of them on their NS's:
>
> May  5 14:15:14 noc named[26139]: client xxxx:xxxx:xxxx::x#3421046:
> update '3.2.1.8.b.d.1.0.0.2.ip6.arpa/IN' denied
>
> or the IPv4 equivalent. Now I know that most of these will come from
> Windows as they have this setting activated per default and one  
> could if
> running inside an Active Directory turn those off easily, but in the
> case where one doesn't have control over the hosts in question it  
> would
> be nice if there was a flag for indicating that the zone is able or  
> not
> to update, and possibly where to send updates. Is there such a  
> mechanism
> already?

There's a mechanism available which is in use by some people, but  
which when presented to dnsop led to much frowning and the document  
withered on the vine.

   http://tools.ietf.org/id/draft-jabley-dnsop-missing-mname-00.txt

The principle objection from memory was that this approach might cause  
yet more junk traffic to be received by the root servers. There was
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeroen Massar | 7 May 2009 08:45
Favicon
Gravatar

Re: [dnsext] Domain "Flag" to indicate (non-)availability of automatic DNS updates for reverse DNS

Mark Andrews wrote:
[..]
> 	Or realise that end hosts SHOULD have the ability to update
> 	their PTR records to reflect their own names.  Remember
> 	ISP's are leasing the addresses to the hosts.  ISP's don't
> 	own the host and they shouldn't be forcing name constraints
> 	on the hosts.

Well, that is actually the fun part. SixXS actually allows one to
delegate the subnet reverse* DNS to a DNS server of ones own choosing.
Not everybody does that though and thus the updates end up at us.

Coming to think of it, maybe an other route is to per-default set a "NS
." or something like that making the delegation lame? Though that is I
think also not a proper way to solve it.

> 	The real question is how to do this so that spoofed updates
> 	are not processed.  A update over TCP should be strong
> 	enough for this.

As in this case it involves tunnels we can do full RPF checks on the
packets and are sure that when it arrives to us that those packets
really originate from there. In a shared (eg cable) environment or where
one does not have such a strict hierarchy it becomes harder.

The point in this question was simply that we don't want to handle the
DDNS updates, which do end up at our boxes. In these cases people are
not aware that they can configure a reverse DNS server, even though they
have the possibility to do so, and as it is enabled per default on
Windows it still happens.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Scott Rose | 7 May 2009 18:31
Favicon

Re: [dnsext] I-D Action:draft-ietf-dnsext-tsig-md5-deprecated-02.txt


Francis Dupont wrote:
>  In your previous mail you wrote:
> 
>    >5.  Availability Considerations
>    
>    And SHA1 "is [eventually?} likely to suffer" - any time soon?  This 
>    doc title is about HMAC-MD5, not SHA1.
>    
> => SHA1 end of life is planned in 2010 (cf NIST, BTW 2010 is next year)
> so even there is nothing against HMAC-SHA1 the same availability problem
> could occur so between the two remaining "mandatory to support" algos
> HMAC-SHA256 is the best candidate.
> BTW I agree it is far too soon to say more about SHA1.
> 
Minor point-
SHA-1 will no longer be approved for use (within the US Government only)
with digital signing.  HMAC-SHA1 is still acceptable if the secret
string used is a sufficient length and random (i.e. generated using an
approved random number generation technology).

Given the recent news about SHA-1, that might change.

Scott

--

-- 
----------------------------------------
Scott Rose            Computer Scientist
NIST
ph: +1 301-975-8439
(Continue reading)

Permalink | Reply | 6 comments |
headers
Paul Hoffman | 7 May 2009 19:21

Re: [dnsext] I-D Action:draft-ietf-dnsext-tsig-md5-deprecated-02.txt

At 12:31 PM -0400 5/7/09, Scott Rose wrote:
>Minor point-
>SHA-1 will no longer be approved for use (within the US Government only)
>with digital signing.  HMAC-SHA1 is still acceptable if the secret
>string used is a sufficient length and random (i.e. generated using an
>approved random number generation technology).

This is not a minor point, particularly with respect to the draft.

--Paul Hoffman, Director
--VPN Consortium

--
to unsubscribe send a message to namedroppers-request <at> ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
Permalink | Reply | 1 comment |

Gmane