Hi Bernard,
Regarding client authentication, there are a number of constraints on the
solution that lead to the current choice. The most relevant constraint is that
there may be no prior relationship between LIS (network operator) and device.
In designing for arbitrary access networks, thi
Phillip Hallam-Baker wrote:
> Please learn to express your opinions in a manner that is appropriate
> to a professional forum rather than a bar room brawl.
> The link you gave was to a paywalled version of the paper. I did not
> bother to read the authors once I discovered it was paywalled.
Than
The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Elliptic-Curve Algorithm Integration in the Secure Shell Transport
Layer '
as an Informational RFC
The IESG plans to make a decision in the next few weeks, and solicits
f
David Wilson wrote:
>>As you say "IN NETWORKING", I'm afraid you haven't read his original
>>paper "END-TO-END ARGUMENTS IN SYSTEM DESIGN", which is on "system
>>design" in general and not necessarily "in networking". For example,
>>in the original paper, RISC (Reduced Instruction Set Computer) is
David Wilson wrote:
>>According to the terminology of David Clark, PKI including DNSSEC
>>is not secure end to end.
> DNSSEC provides two things. Firstly, it provides the means to digitally
> sign RRsets. This provides data origin authentication and data
> integrity.
The provision is through hop
On Mon, 2009-06-08 at 14:22 +0900, Masataka Ohta wrote:
> As you say "IN NETWORKING", I'm afraid you haven't read his original
> paper "END-TO-END ARGUMENTS IN SYSTEM DESIGN", which is on "system
> design" in general and not necessarily "in networking". For example,
> in the original paper, RISC (
On Sat, 2009-06-06 at 13:09 +0900, Masataka Ohta wrote:
> 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.
DNSSEC provides two things.
I guess I'm still missing your original concern. But, one problem with
that sentence is that it's really out of context and would make more
sense if it were the first sentence in the last paragraph in section 8,
as that then leads to the text on the recommended mechanism (i.e., TLS).
The sentence i
Dear Colleagues,
The Internet Architecture Board (IAB) seeks nominations for the
volunteer position of an Independent Submissions Editor (ISE). The
appointee's term will begin on January 1, 2010. The IAB desires a
lengthy relationship with a successful candidate and would like to
structure a 5-y
Dear Colleagues,
The Internet Architecture Board (IAB) seeks nominations for the
position of an RFC Series Editor (RSE). The appointee's term will
begin on January 1, 2010. The IAB desires a lengthy relationship with
a successful candidate and would like to structure a 5 year term with
a perfor
Mary Barnes said:
"It doesn't explicitly "forbid" the use of digest authn, but if it
can't depend on client support, then it can't really base any decision on
it."
The question isn't just about an authorization decision. There is also the
issue about what
the LIS is supposed to do with
Ohta-san,
On Sat, 2009-06-06 at 12:04 +0900, Masataka Ohta wrote:
> 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 thi
On Thu, Jun 04, 2009 at 10:17:17PM +0200, Eric Rosen wrote:
> Generally, the community (i.e., the folks doing the work in the various
> areas) has never even heard about these proposed requirements until after a
> BCP appears, at which time they are told that the BCP "has community
I was at a dinner with Dave Clarke last week. Those who invoke his
name in these arguments rarely seem to have read his paper on the end
to end principle IN NETWORKING.
The end to end security argument came earlier, it is referenced as an
antecedent to lend support to the then novel idea of applyi
Hi,
I have reviewed draft-dusseault-impl-reports-02 from operations
directorate point of view.
Operations directorate reviews are solicited primarily to help the
area
directors improve their efficiency, particularly when preparing for
IESG
telechats, and allowing them to focus on documents requir
Again, my point was not to say that this was necessarily a problem--I
highlighted it as something the IESG should think about, knowing that
they have a big reading load. I guess my question is, is the statement
that reverse routability provides "sufficient assurance in many
cases", along wi
Hi Ben,
So, you are talking about section 9.3 which does state that the LIS
ensures that the client is authenticated, per the following:
"The LIS MUST
verify that the client is the target of the returned location, i.e.,
the LIS MUST NOT provide location to other entities than the target.
Hi Ben,
Thanks for your third Gen-ART review of this document. My responses are
inline below, with the exception of the Minor issue you highlight to
which I responded in a separate email.
Mary.
-Original Message-
From: Ben Campbell [mailto:b...@estacado.net]
Sent: Thursday, June 04,
Hi Mary,
The part I was trying to highlight was the lack of client device
authentication, not LIS authentication. If I read 9.1 right, it only
covers authentication of the LIS. I assume there is no expectation
that client devices present TLS certs to the LIS, right?
Again, I'm not saying
The wording on this topic in this section and in the security section
(9.1) are not really as consistent as it should be in terms of normative
language - the security section describes the capabilities in terms of
what MUST be provided/implemented by a LIS and client implementation,
but not necessa
Mans Nilsson writes:
> Subject: Re: DNSSEC is NOT secure end to end Date: Mon, Jun 08, 2009 at
> 11:25:36AM +0200 Quoting Simon Josefsson (si...@josefsson.org):
>
>> The organization operating .SE charges for DNSSEC. According to [1] it
>> costs 250 SEK annually (~22 EUR or ~30 USD) extra per
I am sad to hear this. I miss him.
Fred Baker wrote:
Steve Coya, the IETF's Executive Director at CNRI during much of the
1990's and early 2000's, has passed away. His wife, Mary Beth, wanted
folks to know, as the IETF was a big part of his life.
http://www.legacy.com/washingtonpost/DeathNoti
Simon Josefsson wrote:
> Andrew Sullivan writes:
>>>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.
> The o
Subject: Re: DNSSEC is NOT secure end to end Date: Mon, Jun 08, 2009 at
11:25:36AM +0200 Quoting Simon Josefsson (si...@josefsson.org):
> The organization operating .SE charges for DNSSEC. According to [1] it
> costs 250 SEK annually (~22 EUR or ~30 USD) extra per year to protect a
> domain nam
Shane Kerr wrote:
>>If you mean COM zone, it is not necessary to inject any data into
>>the zone.
>>You, instead, can inject a forged certificate into some cache used
>>by your victim.
> You said transport security can help. How can it in this case?
With plain old DNS, zone administrators have
On Sat, Jun 06, 2009 at 02:53:36PM -0400, Steve Crocker wrote:
> This is indeed sad news. Steve was energetic and dedicated, and we all
> benefitted greatly from his contributions.
Very sad. Steve was a great guy, always full of energy,
optimistic, and very dedicated. And he had
Andrew Sullivan writes:
> 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
27 matches
Mail list logo
