Mark Andrews wrote:
Thus, we must, anyway, protect cache.
Then, where is the point to introduce DNSSEC only to have another
possibility of security holes?
We still lock doors and windows despite the possiblity of people
breaking in by lifting tiles.
I'm afraid DNSSEC people have been arguing
- Original Message -
From: Adrian Farrel adr...@olddog.co.uk
To: ietf@ietf.org
Cc: ops...@ietf.org
Sent: Thursday, June 04, 2009 11:58 AM
In the discussion of IETF consensus of this document and its position as a
BCP or otherwise, can I throw into the melting pot
So quit trying to be a dead horse that is not even there.
If you are so interested in transport layer security, then
by all means, encourage, promote, and develop solutions.
STCP is one such measure. IPSEC is another. there are
many choices.
transport level security (integrity, authenticity)
Bill Manning wrote:
If you are so interested in transport layer security, then
by all means, encourage, promote, and develop solutions.
The discussion of the paper of David Clark about public key is not
on a transport but on an administrative layer.
The paper says:
However, there is
On Fri, Jun 05, 2009 at 08:10:55AM +0900, Masataka Ohta wrote:
In general, registries welcome DNSSEC, no matter how secure it is,
as long as its complicated operation works as an excuse to increase
(or not to reduce) registration charge and registries' revenue.
That is a serious charge. I've
Shane Kerr wrote:
I think we all understand that it is possible to inject bad data into
the DNS at the parent.
What do you mean the parent?
Do you mean master zone file of the parent or some caching server
expected by a client to have parent data?
What I do not understand about this comment
Ben,
Thanks for your review. With respect to the HTTP issue you raise, is
your claim that the HTTP binding prevents the use of Digest or Basic
based on this sentence from Section 6.3?
HELD error messages MUST be carried by a 200 OK HTTP/HTTPS response.
If so, then I think that's a
On Jun 5, 2009, at 8:43 AM, Richard Barnes wrote:
Ben,
Thanks for your review. With respect to the HTTP issue you raise,
is your claim that the HTTP binding prevents the use of Digest or
Basic based on this sentence from Section 6.3?
HELD error messages MUST be carried by a 200 OK
On Fri, Jun 5, 2009 at 8:32 AM, Masataka Ohta
mo...@necom830.hpcl.titech.ac.jp wrote:
So, let's throw away DNSSEC and the broken-from-the-beginning
idea of bailiwick. Let's move on to lock the doors and windows.
Words of wisdom. I however propose we do not throw it away. I propose it
be
On Tue, 2009-06-02 at 22:38 +0900, Masataka Ohta wrote:
Yes, security of DNSSEC is totally hop by hop.
I am nervous of adding to this debate (and should it really be on ASRG?)
However, I think there is some difference in the way people are using
some terms. My understanding of the terms
Group,
Here are a few stupid/nit questions,
1) What do you do with host naming collisions?
2) Is a blank string blank equal to a string?
3) Is the hostname case sensitive?
4) Since the hostnames are human readable, would
Yes, security of DNSSEC is totally hop by hop.
Thus, you imply a definition of hop by hop along digital signature
relationships. Indeed, DNSSEC security is limited to the weakest link
along the chain from the bottom to the top of the DNS hierarchy. Nothing
new there. I don't think any
Ohta-san,
On Fri, 2009-06-05 at 21:32 +0900, Masataka Ohta wrote:
I mention transport security merely because it is still required
with DNSSEC, because administrative security of DNSSEC is
cryptographically weak.
I think we all understand that it is possible to inject bad data into
the DNS at
Ohta-san,
On Fri, 2009-06-05 at 22:15 +0900, Masataka Ohta wrote:
I think we all understand that it is possible to inject bad data into
the DNS at the parent.
What do you mean the parent?
Do you mean master zone file of the parent or some caching server
expected by a client to have
The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Suite B Certificate and Certificate Revocation List (CRL) Profile '
draft-solinas-suiteb-cert-profile-03.txt as an Informational RFC
The IESG plans to make a decision in the
At 02:06 04/06/2009, Sabahattin Gucukoglu wrote:
On 4 Jun 2009, at 04:06, Mark Andrews wrote:
In message
aaab52ef-ad0a-4d3c-9b28-b864f342d...@sabahattin-gucukoglu.com ,
Sabahattin Gucukoglu writes:
The problem is this: the authoritative servers for a domain can
easily
never be consulted for
Hi all,
As noted last week, the IETF nominating committee process for 2009-10 is
underway. The list of people and posts whose terms end with the March
2010 IETF meeting, and thus the positions for which the nominating
committee is responsible, are summarized in the initial announcement:
On Wed, 3 Jun 2009, Christian Huitema wrote:
Also, it is actually possible to improve on DNSSEC by introducing additional knowledge.
If two domains have an establish relation, their servers can memorize the relevant public
keys. If a host has a relation with a domain, it can memorize that
Hi,
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should
treat these comments just
On Jun 3, 2009, at 12:23 AM, Christian Huitema wrote:
Yes, security of DNSSEC is totally hop by hop.
Thus, you imply a definition of hop by hop along digital signature
relationships. Indeed, DNSSEC security is limited to the weakest
link along the chain from the bottom to the top of the
At 06:39 05-06-2009, The IESG wrote:
The IESG has received a request from the Mobility for IP: Performance,
Signaling and Handoff Optimization WG (mipshop) to consider the following
document:
- 'Locating IEEE 802.21 Mobility Servers using DNS '
draft-ietf-mipshop-mos-dns-discovery-06.txt as
A wiki has been set up for the Stockholm code strint:
http://trac.tools.ietf.org/tools/ietfdb/wiki/IETF75Sprint
The wiki includes a sign-up page. Please add your name to the table
if you are planning to participate.
Thanks,
Russ
IETF Chair wrote:
Stockholm IETF Code Sprint
When: July
At 12:39 PM -0400 6/5/09, Sean Turner wrote:
#1 Non-repudiation bit
During the development of other profiles where the NR bit wasn't set, sometime
after the profile gets developed I've usually gotten questions like so you're
not setting N-R can I use it for non-repudiation services? To answer
All;
The Bidders Conference was held on 3 June and lasted almost 4 hours.
ISI made excellent presentations.
The transcript of the Conference, including handouts and screen shots
can be found under Bidders Conference at:
http://iaoc.ietf.org/rfced-procurement.html
NOTE:
The period for
Pekka:
- 'Nominating Committee Process: Earlier Announcement of Open Positions
and Solicitation of Volunteers'
draft-dawkins-nomcom-dont-wait-03.txt as a BCP
I have two issues with this.
1) This places a new responsibility at the feet of IETF secretariat.
That's a new actor (not
Shane Kerr wrote:
I think we all understand that it is possible to inject bad data into
the DNS at the parent.
I the parent in the same sense as in RFC 1034 - the delegating level.
So, for EXAMPLE.COM this would be COM.
If you mean COM zone, it is not necessary to inject any data into
the
David Wilson wrote:
However, I think there is some difference in the way people are using
some terms.
According to the terminology of David Clark, PKI including DNSSEC
is not secure end to end.
End-to-end security means that the security of that data item does not
depend on the
The IESG has received a request from the Mobility for IP: Performance,
Signaling and Handoff Optimization WG (mipshop) to consider the following
document:
- 'Locating IEEE 802.21 Mobility Servers using DNS '
draft-ietf-mipshop-mos-dns-discovery-06.txt as a Proposed Standard
The IESG plans to
Hi all,
As noted last week, the IETF nominating committee process for 2009-10 is
underway. The list of people and posts whose terms end with the March 2010
IETF meeting, and thus the positions for which the nominating committee is
responsible, are summarized in the initial announcement:
The IESG has approved the following document:
- 'Carrying Location Objects in RADIUS and Diameter '
draft-ietf-geopriv-radius-lo-24.txt as a Proposed Standard
This document is the product of the Geographic Location/Privacy Working
Group.
The IESG contact persons are Cullen Jennings and
A wiki has been set up for the Stockholm code strint:
http://trac.tools.ietf.org/tools/ietfdb/wiki/IETF75Sprint
The wiki includes a sign-up page. Please add your name to the table
if you are planning to participate.
Thanks,
Russ
IETF Chair wrote:
Stockholm IETF Code Sprint
When: July
The IESG has received a request from the S/MIME Mail Security WG (smime)
to consider the following document:
- 'New ASN.1 Modules for CMS and S/MIME '
draft-ietf-smime-new-asn1-05.txt as an Informational RFC
The IESG plans to make a decision in the next few weeks, and solicits
final comments
The IESG has received a request from an individual submitter to consider
the following document:
- 'Nominating Committee Process: Open Disclosure of Willing Nominees '
draft-dawkins-nomcom-openlist-04.txt as a BCP
The IESG plans to make a decision in the next few weeks, and solicits
final
33 matches
Mail list logo
