headers
Doug Barton | 1 Mar 2010 03:38
Picon

Re: New version of document for review


On 01/15/10 08:16, Michelle Cotton wrote:
> Attn: TSVWG Working Group, DNSOPS Working Group and APPS AREA Working Group
> 
> There is a new version of the Internet Assigned Numbers Authority (IANA)
> Procedures for the Management
> of the Transport Protocol Port Number and Service Name Registry document:
> 
> draft-ietf-tsvwg-iana-ports-04.txt
> 
> Please review and send comments.  Your feedback is much appreciated.

I'm writing to provide both review and support of this draft. Before I
do however it's probably useful for me to make some explicit statements,
some of the "should go without saying" variety and some to provide
context for my comments.

I was the General Manager of the IANA from late 2003 through mid 2005.
In that capacity I was proud to manage Michelle as one of my employees.
One of my responsibilities was to oversee the port number allocation
process, including occasionally making the final decisions on these
assignments myself. Other than her public messages regarding these
drafts I have had no communication from Michelle or anyone else from
ICANN regarding this topic. Other than this message today I've not
communicated with them about it. (IOW, ETINC.) I also have experience
with port numbers from the operating system implementer's perspective as
part of a large group of people who have "commit privileges" to the
FreeBSD code base.

With all that out of the way, I would like to commend Michelle and the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rose, Scott W. | 1 Mar 2010 13:57
Favicon

Re: RFC4641bis version 02.

On 2/26/10 4:51 PM, "Paul Wouters" <paul <at> xelerance.com> wrote:

> On Fri, 26 Feb 2010, Thierry Moreau wrote:

> 
>> Basically, you adhere to (B) and suggest 1024-bits/1-month-cryptoperiod,
>> hence you inflate the requirements over NIST's.
> 
> I am not inflating NIST's requirements. I believe 1024 bit RSA with monthly
> rollover is fine, whereas NIST recommends to migrate to 2048 bit for that.
> 

NIST's recommendations are for 2048 bit RSA, rolled every 1-3 years.  These
recommendations are based on PKI and/or SSL certs mostly, not DNSSEC.  For
DNSSEC, we made a compromise to allow 1024 bit RSA keys around for a while
if we also recommended rolling more frequently.

>> Thus, in *my* opinion, you induce a waste of DNSSEC bandwidth / CPU time /
>> DNS operations overhead (i.e. rollover management).
> 
Depending on the zone, operational overhead is an acceptable cost compared
to having smaller response sizes.

Scott

> Have you crunched the numbers and packet sizes of 768 bit RSA vs 1024 bit
> RSA vs 2048 bit RSA RRSIG's in common DNS packet answers? I believe the
> concensus reached was that differences between 1024 and 2048 bit had a
> significant impact, whereas the difference between 1024 and 768 did not.
> It thus made sense to both play as save as possible within the constraints
(Continue reading)

Permalink | Reply | 5 comments |
headers
Eric Rescorla | 1 Mar 2010 14:07

Re: RFC4641bis version 02.

On Mon, Mar 1, 2010 at 4:57 AM, Rose, Scott W. <scott.rose <at> nist.gov> wrote:
> On 2/26/10 4:51 PM, "Paul Wouters" <paul <at> xelerance.com> wrote:
>
>> On Fri, 26 Feb 2010, Thierry Moreau wrote:
>
>>
>>> Basically, you adhere to (B) and suggest 1024-bits/1-month-cryptoperiod,
>>> hence you inflate the requirements over NIST's.
>>
>> I am not inflating NIST's requirements. I believe 1024 bit RSA with monthly
>> rollover is fine, whereas NIST recommends to migrate to 2048 bit for that.
>>
>
> NIST's recommendations are for 2048 bit RSA, rolled every 1-3 years.  These
> recommendations are based on PKI and/or SSL certs mostly, not DNSSEC.  For
> DNSSEC, we made a compromise to allow 1024 bit RSA keys around for a while
> if we also recommended rolling more frequently.

OK, but I don't understand the technical basis for this recommendation. It just
seems like it makes running 1024-bit keys inconvenient without adding any
significant increase in security. Did NIST provide a rationale?

-Ekr
_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Permalink | Reply | 4 comments |
headers
Rose, Scott W. | 1 Mar 2010 14:26
Favicon

Re: RFC4641bis version 02.

The 1024 bit key guideline is for response sizes (biggest stumbling block
we've encountered so far in .gov deployment).

The rollover frequency is largely based on an extended time frame.  The
extended roadmap is to try and migrate to ECC by 2015, and there is some
belief that 1024 bit RSA might become "breakable" in months (with reasonable
cost - for some definition of "reasonable") by 2015.  I remember some paper
being reference, but I don't recall which one.  And no, I don't fully
understand all of it either, but the near goal (response size) was met,
which was the primary concern for now given the deployment deadlines within
Federal IT security.

Overall, US Federal gov't security policy errs on the side of caution.
Frequent rolling of keys is seen as good practice, even if the evidence on
its effectiveness isn't fully proven.

Scott

On 3/1/10 8:07 AM, "Eric Rescorla" <ekr <at> rtfm.com> wrote:

> On Mon, Mar 1, 2010 at 4:57 AM, Rose, Scott W. <scott.rose <at> nist.gov> wrote:
>> On 2/26/10 4:51 PM, "Paul Wouters" <paul <at> xelerance.com> wrote:
>> 
>>> On Fri, 26 Feb 2010, Thierry Moreau wrote:
>> 
>>> 
>>>> Basically, you adhere to (B) and suggest 1024-bits/1-month-cryptoperiod,
>>>> hence you inflate the requirements over NIST's.
>>> 
>>> I am not inflating NIST's requirements. I believe 1024 bit RSA with monthly
(Continue reading)

Permalink | Reply | 3 comments |
headers
Eric Rescorla | 1 Mar 2010 15:11

Re: RFC4641bis version 02.

On Mon, Mar 1, 2010 at 5:26 AM, Rose, Scott W. <scott.rose <at> nist.gov> wrote:
> The 1024 bit key guideline is for response sizes (biggest stumbling block
> we've encountered so far in .gov deployment).
>
> The rollover frequency is largely based on an extended time frame.  The
> extended roadmap is to try and migrate to ECC by 2015, and there is some
> belief that 1024 bit RSA might become "breakable" in months (with reasonable
> cost - for some definition of "reasonable") by 2015.  I remember some paper
> being reference, but I don't recall which one.  And no, I don't fully
> understand all of it either, but the near goal (response size) was met,
> which was the primary concern for now given the deployment deadlines within
> Federal IT security.

I don't really see how this addresses the question without some definition of
"reasonable". If a key is breakable at cost C in M months, then it's breakable
at cost Cx in M/x months. Since the x values we're talking about here are
on the order of 10, then you're basically claiming that you can estimate
the attacker's capabilities to within a factor of 5-10, which seems fairly
implausible.

Even if you do think this is true, it would be far more effective to simply use
fractionally larger RSA keys. My understanding is that the major obstacle to
using (for instance) 1100-bit RSA keys is that NIST only accepts a small
number of concrete key sizes for FIPS 140. If so, rather than specifying
a short rollover time, perhaps NIST could address that.

> Overall, US Federal gov't security policy errs on the side of caution.
> Frequent rolling of keys is seen as good practice, even if the evidence on
> its effectiveness isn't fully proven.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Chris Thompson | 1 Mar 2010 17:45
Picon
Picon
Favicon

Re: RFC4641bis version 02.

On Mar 1 2010, Eric Rescorla wrote:

> [...] If a key is breakable at cost C in M months, then it's breakable
>at cost Cx in M/x months.

This isn't true in general (although it may be sufficiently so in the
cases under discussion). In particular, not all stages of NFS factorisation
attempts are easily distributable to many small processors. The sieving
stage is, but distributing the matrix reduction stage is much harder (and
a hot research topic).

Recommended background reading: http://eprint.iacr.org/2010/006.pdf

>Even if you do think this is true, it would be far more effective to simply use
>fractionally larger RSA keys. My understanding is that the major obstacle to
>using (for instance) 1100-bit RSA keys is that NIST only accepts a small
>number of concrete key sizes for FIPS 140. If so, rather than specifying
>a short rollover time, perhaps NIST could address that.

Absolutely: the NIST only-powers-of-2 guidelines have had a malign influence
in the DNSSEC context, where the size of the signature so greatly exceeds
that of the data signed.

--

-- 
Chris Thompson               University of Cambridge Computing Service,
Email: cet1 <at> ucs.cam.ac.uk    New Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715       United Kingdom.
_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
(Continue reading)

Permalink | Reply | 1 comment |
headers
Eric Rescorla | 1 Mar 2010 18:07

Re: RFC4641bis version 02.

On Mon, Mar 1, 2010 at 8:45 AM, Chris Thompson <cet1 <at> cam.ac.uk> wrote:
> On Mar 1 2010, Eric Rescorla wrote:
>
>> [...] If a key is breakable at cost C in M months, then it's breakable
>> at cost Cx in M/x months.
>
> This isn't true in general (although it may be sufficiently so in the
> cases under discussion). In particular, not all stages of NFS factorisation
> attempts are easily distributable to many small processors. The sieving
> stage is, but distributing the matrix reduction stage is much harder (and
> a hot research topic).
>
> Recommended background reading: http://eprint.iacr.org/2010/006.pdf

Yes, this is correct, but I believe it is true for the values of x under
discussion.

-Ekr
_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Permalink | Reply | 0 comments |
headers
Roy Arends | 1 Mar 2010 19:24
Picon

.UK is DNSSEC signed

Today, Nominet UK, the internet registry for .UK domain names has deployed a signed UK zone. 

We have introduced DNSSEC information into five of the eleven UK nameservers.  The keys have been obscured;
although DNSSEC information is present, it will not be possible to validate it.  For one week we will
monitor the traffic on all our nameservers to look for any significant change in access patterns.

Assuming that nothing untoward is seen, on Monday 8 March, all eleven UK nameservers will serve DNSSEC
information and the zone will contain proper DNSKEY material.  However, we recommend against
configuring the DNSKEY key as a trust anchor or adding it to DLV repositories. The next few months are an
operational test and although we do plan to roll our DNSKEY at some point, we do not plan to announce it
publicly.  When the root zone announces that it is ready to accept DS records, the one for .uk will be
submitted for publication.

Kind regards,

Roy Arends
Sr. Researcher
Nominet UK
_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Permalink | Reply | 0 comments |
headers
bmanning | 2 Mar 2010 05:02

Re: automatic update of DS records


	granted that this discussion is important and folks
	interested in this might be at the IETF77, could we
	either have a bof (formal) or a small lunch mtg 
	during the week of IETF77?

	I'd be glad to attend.

--bill

On Fri, Feb 26, 2010 at 10:12:48AM +0100, Wolfgang Nagele wrote:
> Hi,
> 
> > What are the arguments against using somthing like RFC 5011 to
> > automatically update DS records? (If you can do that I suppose
> > you could update the rest of the delegation too.)
> There has been some work on a draft for this after an inofficial BoF during the
> Stockholm IETF. So far it did not make it to the light of day because of claimed
> intellectual property issues. Anybody interested can contact me for more details.
> 
> Regards,
> Wolfgang
> _______________________________________________
> DNSOP mailing list
> DNSOP <at> ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wolfgang Nagele | 2 Mar 2010 10:04
Picon
Favicon

Re: automatic update of DS records

Hi,

> 	granted that this discussion is important and folks
> 	interested in this might be at the IETF77, could we
> 	either have a bof (formal) or a small lunch mtg 
> 	during the week of IETF77?
> 
> 	I'd be glad to attend.
There has been interest in this at least since IETF75. Anyway, a BoF is a good
idea. I will not be in Anaheim since the DURZ roll-out for K is in that week.
However Matthijs (in CC) has done the heavy lifting on the current draft and is
going to be there and he agreed to attend the BoF.

Cheers,
Wolfgang
_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Permalink | Reply | 26 comments |

Gmane