Re: DNSSEC is NOT secure end to end

[Simon Josefsson]

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.
>
> That is a serious charge.  I've seen no evidence that DNSSEC
> represents a revenue opportunity for registries.  On the contrary, so
> far as I've seen, most registries are introducing it without any fee,
> even though it represents a substantial additional operational cost.

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 name with DNSSEC.

/Simon

[1] http://www.iis.se/docs/se-dnssec_-_broschyr_eng_ny_.pdf
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Steve Coya

[David Meyer]

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 a great sense
of humor.

Dave


signature.asc
Description: Digital signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: DNSSEC is NOT secure end to end

[Masataka Ohta]

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 to make master
zone files secure not to include forged data.

Other administrators take care of transport security, for example,
to make port numbers randomized, which makes plain old DNS
reasonably secure.

With DNSSEC, however, a new administration mechanism to generate
signatures is mandated, which is NOT automagically secure and
introduces new administrative security holes.

Thus, even if master zone files are administrated as secure as
plain old DNS administration, the signature generation mechanisms
may be hacked.

Unlike forgery on master zone files, which is published and
detected by periodic checking by thid parties, attack by
unpublished forged signature will not be noticed until a victim
is attacked, the victim noticed the (resulting loss by successful)
attack and the victim has sufficient knowledge on DNSSEC.

Still, the victim may be protected, if the victim can not be
injected forged signature through transport.

> Also, how can you create a forged certificate?

By attacking signature generation mechanisms, which is a security
hole specific to DNSSEC not shared by plain old DNS.

Note that DNSSEC does not give any cryptographical protection
against attacks on the signature generation mechanisms.

Masataka Ohta

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: DNSSEC is NOT secure end to end

[Mans Nilsson]

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 name with DNSSEC.
 
Not anymore; it is included with the registration since .SE went to a
registry-registrar model a year ago. However, the registrar may choose
to charge for the work associated with doing DNSSEC.

-- 
Måns Nilsson


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: DNSSEC is NOT secure end to end

[Masataka Ohta]

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 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 name with DNSSEC.

That is the serious charge.

Thank you for the information.

Are there anyone who is not working for registries and is still
interested in deploying DNSSEC for the extra charge despite the
lack of cryptographic security?

If not, let's conclude the thread with a consensus to abandon DNSSEC.

Masataka Ohta

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Steve Coya

[Harald Alvestrand]

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/DeathNotices.asp?Page=Lifestory&PersonId=128055919 


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: DNSSEC is NOT secure end to end

[Simon Josefsson]

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 year to protect a
>> domain name with DNSSEC.
>  
> Not anymore; it is included with the registration since .SE went to a
> registry-registrar model a year ago. However, the registrar may choose
> to charge for the work associated with doing DNSSEC.

That is good to hear.  It would be better if the web pages would reflect
the new order.

/Simon
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Gen-ART LC Review of draft-ietf-geopriv-http-location-delivery-14

[Mary Barnes]

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 necessarily what MUST be used and the RECOMMENDED mechanism is
actually a "can", there are several lower case MUSTs, etc. Noting in
particular the MAY in terms of the client being able to use an external
mechanism. 
Also, note that the recommended mechanism is the authentication
mechanism as provided by TLS, so there's nothing unusual with this
approach (as I understand it since I'm not a security expert).   So, I
would propose to reword the text in section 9.1 as follows:

OLD:
   When the HELD transaction is
   conducted using TLS [RFC5246], the LIS can authenticate its identity,
   either as a domain name or as an IP address, to the client by
   presenting a certificate containing that identifier as a
   subjectAltName (i.e., as an iPAddress or dNSName, respectively)."
   In the case of the HTTP binding described above, this is exactly the
   authentication described by TLS [RFC2818].  If the client has
   external information as to the expected identity or credentials of
   the proper LIS (e.g., a certificate fingerprint), these checks MAY be
   omitted.  Any binding of HELD MUST be capable of being transacted
   over TLS so that the client can request the above authentication, and
   a LIS implementation for a binding MUST include this feature.  Note
   that in order for the presented certificate to be valid at the
   client, the client must be able to validate the certificate.  In
   particular, the validation path of the certificate must end in one of
   the client's trust anchors, even if that trust anchor is the LIS
   certificate itself.

NEW:

   When the HELD transaction is
   conducted using TLS [RFC5246], the LIS SHOULD authenticate its
identity,
   either as a domain name or as an IP address, to the client by
   presenting a certificate containing that identifier as a
   subjectAltName (i.e., as an iPAddress or dNSName, respectively).
   In the case of the HTTP binding described above, this is exactly the
   authentication described by TLS [RFC2818]. 
   If the client has
   external information as to the expected identity or credentials of
   the proper LIS (e.g., a certificate fingerprint), these checks MAY be
   omitted.  Any binding of HELD MUST be capable of being transacted
   over TLS so that the client can request the above authentication, and
   a LIS implementation for a binding MUST include this feature.  Note
   that in order for the presented certificate to be valid at the
   client, the client MUST be able to validate the certificate.  In
   particular, the validation path of the certificate MUST end in one of
   the client's trust anchors, even if that trust anchor is the LIS
   certificate itself.


And the text that causes you concern in section 8 as:

OLD:
   The LIS MUST NOT
   rely on device support for cookies [RFC2965] or use Basic or Digest
   authentication [RFC2617].

NEW: 
   The LIS SHOULD NOT
   rely on device support for cookies [RFC2965] or use Basic or Digest
   authentication [RFC2617], but rather SHOULD use the mechanism
described 
   in section 9.1. 


I'll respond to your other comments separately.

Thanks,
Mary. 




-Original Message-
From: Ben Campbell [mailto:b...@estacado.net] 
Sent: Friday, June 05, 2009 9:13 AM
To: Richard Barnes
Cc: General Area Review Team; Barnes, Mary (RICH2:AR00);
james.winterbot...@andrew.com; martin.thom...@andrew.com;
barbara.st...@att.com; acoo...@cdt.org; Cullen Jennings; ietf@ietf.org
Subject: Re: Gen-ART LC Review of
draft-ietf-geopriv-http-location-delivery-14


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 HTTP/HTTPS response.

No, I based it on the last sentence, second paragraph in section 8:

"The LIS MUST NOT rely on device support for cookies [RFC2965] or use
Basic or Digest authentication [RFC2617]."

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.

>
> "
>
> If so, then I think that's a misinterpretation that calls for a 
> clarification. The authors should feel free to correct me, but I think

> that HTTP-level errors (e.g., the need for authentication, or even a 
> LIS not listening at a given path) can still generate other HTTP 
> response codes (e.g., 401 or 404).  It's just that if the only thing 
> that's gone wrong is at the HELD layer -- if it's the positioning that

> failed, not the communications -- then you have to use a 200.
>
> Assuming that all the above is

Re: Gen-ART LC Review of draft-ietf-geopriv-http-location-delivery-14

[Ben Campbell]

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 that the lack of client device authentication is  
a problem. The reverse routeability aspect might be sufficient. I'm  
merely pointing it out to make sure people think about it.


On Jun 8, 2009, at 1:35 PM, Mary Barnes wrote:


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 necessarily what MUST be used and the RECOMMENDED mechanism is
actually a "can", there are several lower case MUSTs, etc. Noting in
particular the MAY in terms of the client being able to use an  
external

mechanism.
Also, note that the recommended mechanism is the authentication
mechanism as provided by TLS, so there's nothing unusual with this
approach (as I understand it since I'm not a security expert).   So, I
would propose to reword the text in section 9.1 as follows:

OLD:
  When the HELD transaction is
  conducted using TLS [RFC5246], the LIS can authenticate its  
identity,

  either as a domain name or as an IP address, to the client by
  presenting a certificate containing that identifier as a
  subjectAltName (i.e., as an iPAddress or dNSName, respectively)."
  In the case of the HTTP binding described above, this is exactly the
  authentication described by TLS [RFC2818].  If the client has
  external information as to the expected identity or credentials of
  the proper LIS (e.g., a certificate fingerprint), these checks MAY  
be

  omitted.  Any binding of HELD MUST be capable of being transacted
  over TLS so that the client can request the above authentication,  
and

  a LIS implementation for a binding MUST include this feature.  Note
  that in order for the presented certificate to be valid at the
  client, the client must be able to validate the certificate.  In
  particular, the validation path of the certificate must end in one  
of

  the client's trust anchors, even if that trust anchor is the LIS
  certificate itself.

NEW:

  When the HELD transaction is
  conducted using TLS [RFC5246], the LIS SHOULD authenticate its
identity,
  either as a domain name or as an IP address, to the client by
  presenting a certificate containing that identifier as a
  subjectAltName (i.e., as an iPAddress or dNSName, respectively).
  In the case of the HTTP binding described above, this is exactly the
  authentication described by TLS [RFC2818].
  If the client has
  external information as to the expected identity or credentials of
  the proper LIS (e.g., a certificate fingerprint), these checks MAY  
be

  omitted.  Any binding of HELD MUST be capable of being transacted
  over TLS so that the client can request the above authentication,  
and

  a LIS implementation for a binding MUST include this feature.  Note
  that in order for the presented certificate to be valid at the
  client, the client MUST be able to validate the certificate.  In
  particular, the validation path of the certificate MUST end in one  
of

  the client's trust anchors, even if that trust anchor is the LIS
  certificate itself.


And the text that causes you concern in section 8 as:

OLD:
  The LIS MUST NOT
  rely on device support for cookies [RFC2965] or use Basic or Digest
  authentication [RFC2617].

NEW:
  The LIS SHOULD NOT
  rely on device support for cookies [RFC2965] or use Basic or Digest
  authentication [RFC2617], but rather SHOULD use the mechanism
described
  in section 9.1.


I'll respond to your other comments separately.

Thanks,
Mary.




-Original Message-
From: Ben Campbell [mailto:b...@estacado.net]
Sent: Friday, June 05, 2009 9:13 AM
To: Richard Barnes
Cc: General Area Review Team; Barnes, Mary (RICH2:AR00);
james.winterbot...@andrew.com; martin.thom...@andrew.com;
barbara.st...@att.com; acoo...@cdt.org; Cullen Jennings; ietf@ietf.org
Subject: Re: Gen-ART LC Review of
draft-ietf-geopriv-http-location-delivery-14


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 HTTP/HTTPS response.


No, I based it on the last sentence, second paragraph in section 8:

"The LIS MUST NOT rely on device support for cookies [RFC2965] or use
Basic or Digest authentication [RFC2617]."

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.




"

If so, then I think that's a 

RE: Gen-ART LC Review of draft-ietf-geopriv-http-location-delivery-14

[Mary Barnes]

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, 2009 5:58 PM
To: General Area Review Team; Barnes, Mary (RICH2:AR00);
james.winterbot...@andrew.com; martin.thom...@andrew.com;
barbara.st...@att.com
Cc: Richard Barnes; acoo...@cdt.org; Cullen Jennings; ietf@ietf.org
Subject: Gen-ART LC Review of
draft-ietf-geopriv-http-location-delivery-14

I have been selected as the General Area Review Team (Gen-ART) reviewer
for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-geopriv-http-location-delivery-14
Reviewer: Ben Campbell
Review Date: 2009-06-04
IETF LC End Date: 2009-06-09
IESG Telechat date: (if known)

Summary:

This draft is ready for publication as a proposed standard. I have a few
editorial and clarity comments that might could slightly improve the
draft, but can safely be ignored. Additionally, I have one comment
highlighting a "feature" that is not necessarily a problem, but is
architecturally important enough that I want to make sure the IESG
thinks about it.

Major issues: None.

Minor issues:

-- There is one feature of HELD that the ADs should explicitly think
about: The HTTP binding forbids LIS reliance on HTTP digest or basic
authentication. If I understand correctly, this means effectively that
the _only_ method for client authentication is the built in reverse
routeability test. I am agnostic as to whether this is sufficient.

Nits/editorial comments:

-- section 4, paragraph 1:

Please expand (and reference) PIDF-LO on first mention.
[MB] Okay.

-- Section 6.2, value list:

-- In my previous review, I was confused as to the relationship between
the geodetic/civic and LoBV/LoBR choices. I think it's worth some
clarification in this section that geodetic and civic imply LoBV.  

[MB] Okay, how about the following: 
OLD: 
   geodetic:  The LIS SHOULD return a geodetic location for the Target.
   civic:  The LIS SHOULD return a civic address for the Target.

NEW: 
   geodetic:  The LIS SHOULD return a location by value in the form of a

  geodetic location for the Target.
   civic:  The LIS SHOULD return a location by value in the form of
   a civic address for the Target.

-- section 9.3, 5th paragraph: "A temporary spoofing of IP address could
mean that a device could request a Location Object or Location URI that
would result in another Device's location."

It might be worth clarifying that (if I understand correctly) that this
is more than a spoofing attack, in that the attacker must not only spoof
its source address, but must be able to receive packets sent to the
spoofed address?

[MB] That statement was intended to include both those items, I'd
propose to clarify as follows:
NEW: 
A temporary spoofing of IP address could mean that a device could
request a Location Object or Location URI that would result in receiving
another Device's location if the attacker is able to receive packets
sent to the spoofed address. 


-- same paragraph: "... re-use of the Device's
IP address could result in another Device receiving the original
Device's location rather than its own location."

It seems like this problem is pretty unlikely to occur by _accident_
when HELD is used over TCP (the only binding right now), right? And
certain not to happen over TLS? Might be worth a "mitigating" mention.
[MB] Certainly, it is fairly unlikely (if not impossible in most
situations), but the recommendations in the bullet points further reduce
the potential for problems in the off chance that this occurs.  It's not
entirely clear to me why you suggest this is certain not to happen over
TLS since this is talking about a device that has dropped and thus the
connection would drop and it would seem there's a window for another
device (although quite unlikely) to use that same IP address. But,
perhaps, qualifying the statement as follows would address your concern:
OLD:
  These exposures are limited by the following:

NEW: 
  While these situations are fairly unlikely to occur (in particular
with the use of TCP/TLS), the exposures can be further limited by the
following:


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Gen-ART LC Review of draft-ietf-geopriv-http-location-delivery-14

[Mary Barnes]

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.

And the following: 
   A prerequisite for meeting this requirement is that the LIS must have
   some assurance of the identity of the client.  Since the target of
   the returned location is identified by an IP address, simply sending
   the response to this IP address will provide sufficient assurance in
   many cases.  This is the default mechanism in HELD for assuring that
   location is given only to authorized clients; LIS implementations
   MUST support a mode of operation in which this is the only client
   authentication.

And, then the text goes on to some of the other text in section 9.3 that
you had questions about that I responded to in a separate email.

So, I'm not certain I understand the problem IF I make the proposed
change to the sentence in section 8.

Mary. 

-Original Message-
From: Ben Campbell [mailto:b...@estacado.net] 
Sent: Monday, June 08, 2009 1:47 PM
To: Barnes, Mary (RICH2:AR00)
Cc: Richard Barnes; General Area Review Team;
james.winterbot...@andrew.com; martin.thom...@andrew.com;
barbara.st...@att.com; acoo...@cdt.org; Cullen Jennings; ietf@ietf.org
Subject: Re: Gen-ART LC Review of
draft-ietf-geopriv-http-location-delivery-14

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 that the lack of client device authentication is a
problem. The reverse routeability aspect might be sufficient. I'm merely
pointing it out to make sure people think about it.

On Jun 8, 2009, at 1:35 PM, Mary Barnes wrote:

> 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 necessarily what MUST be used and the 
> RECOMMENDED mechanism is actually a "can", there are several lower 
> case MUSTs, etc. Noting in particular the MAY in terms of the client 
> being able to use an external mechanism.
> Also, note that the recommended mechanism is the authentication 
> mechanism as provided by TLS, so there's nothing unusual with this
> approach (as I understand it since I'm not a security expert).   So, I
> would propose to reword the text in section 9.1 as follows:
>
> OLD:
>   When the HELD transaction is
>   conducted using TLS [RFC5246], the LIS can authenticate its 
> identity,
>   either as a domain name or as an IP address, to the client by
>   presenting a certificate containing that identifier as a
>   subjectAltName (i.e., as an iPAddress or dNSName, respectively)."
>   In the case of the HTTP binding described above, this is exactly the
>   authentication described by TLS [RFC2818].  If the client has
>   external information as to the expected identity or credentials of
>   the proper LIS (e.g., a certificate fingerprint), these checks MAY 
> be
>   omitted.  Any binding of HELD MUST be capable of being transacted
>   over TLS so that the client can request the above authentication, 
> and
>   a LIS implementation for a binding MUST include this feature.  Note
>   that in order for the presented certificate to be valid at the
>   client, the client must be able to validate the certificate.  In
>   particular, the validation path of the certificate must end in one 
> of
>   the client's trust anchors, even if that trust anchor is the LIS
>   certificate itself.
>
> NEW:
>
>   When the HELD transaction is
>   conducted using TLS [RFC5246], the LIS SHOULD authenticate its 
> identity,
>   either as a domain name or as an IP address, to the client by
>   presenting a certificate containing that identifier as a
>   subjectAltName (i.e., as an iPAddress or dNSName, respectively).
>   In the case of the HTTP binding described above, this is exactly the
>   authentication described by TLS [RFC2818].
>   If the client has
>   external information as to the expected identity or credentials of
>   the proper LIS (e.g., a certificate fingerprint), these checks MAY 
> be
>   omitted.  Any binding of HELD MUST be capable of being transacted
>   over TLS so that the client can request the above authentication, 
> and
>   a LIS implementation for a binding MUST include this feature.  Note
>   that in order for the presented certificate to be valid at the
>   client, the client MUST be able to validate the certificate.  In
>   particular, the validation path of the certificate MUST end in one 
> of
>   the client's trust anch

Re: Gen-ART LC Review of draft-ietf-geopriv-http-location-delivery-14

[Ben Campbell]

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 with the fact that the HTTP binding explicitly  
discourages stronger client authentication mechanisms acceptable to  
them. If it is, I am fine with it, and the draft would not need a  
change. If on the other hand I have misunderstood something, that's  
different.


I am a little confused about the proposed change to section 8, though.  
It sounds like it is conflating LIS authentication with device  
authentication. To decompose your proposed language I read it as:


"The LIS SHOULD NOT ... use [device authentication mechanism], but  
rather SHOULD use [LIS authentication mechanism]"


Is it possible I am misunderstanding the direction of the client- 
server relationship in the HTTP binding? I was assuming the device to  
be the HTTP client and the LIS to be the HTTP server--do I have it  
backwards?




On Jun 8, 2009, at 2:12 PM, Mary Barnes wrote:


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.

And the following:
  A prerequisite for meeting this requirement is that the LIS must  
have

  some assurance of the identity of the client.  Since the target of
  the returned location is identified by an IP address, simply sending
  the response to this IP address will provide sufficient assurance in
  many cases.  This is the default mechanism in HELD for assuring that
  location is given only to authorized clients; LIS implementations
  MUST support a mode of operation in which this is the only client
  authentication.

And, then the text goes on to some of the other text in section 9.3  
that

you had questions about that I responded to in a separate email.

So, I'm not certain I understand the problem IF I make the proposed
change to the sentence in section 8.

Mary.

-Original Message-
From: Ben Campbell [mailto:b...@estacado.net]
Sent: Monday, June 08, 2009 1:47 PM
To: Barnes, Mary (RICH2:AR00)
Cc: Richard Barnes; General Area Review Team;
james.winterbot...@andrew.com; martin.thom...@andrew.com;
barbara.st...@att.com; acoo...@cdt.org; Cullen Jennings; ietf@ietf.org
Subject: Re: Gen-ART LC Review of
draft-ietf-geopriv-http-location-delivery-14

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 that the lack of client device authentication  
is a
problem. The reverse routeability aspect might be sufficient. I'm  
merely

pointing it out to make sure people think about it.

On Jun 8, 2009, at 1:35 PM, Mary Barnes wrote:


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 necessarily what MUST be used and the
RECOMMENDED mechanism is actually a "can", there are several lower
case MUSTs, etc. Noting in particular the MAY in terms of the client
being able to use an external mechanism.
Also, note that the recommended mechanism is the authentication
mechanism as provided by TLS, so there's nothing unusual with this
approach (as I understand it since I'm not a security expert).
So, I

would propose to reword the text in section 9.1 as follows:

OLD:
 When the HELD transaction is
 conducted using TLS [RFC5246], the LIS can authenticate its
identity,
 either as a domain name or as an IP address, to the client by
 presenting a certificate containing that identifier as a
 subjectAltName (i.e., as an iPAddress or dNSName, respectively)."
 In the case of the HTTP binding described above, this is exactly the
 authentication described by TLS [RFC2818].  If the client has
 external information as to the expected identity or credentials of
 the proper LIS (e.g., a certificate fingerprint), these checks MAY
be
 omitted.  Any binding of HELD MUST be capable of being transacted
 over TLS so that the client can request the above authentication,
and
 a LIS implementation for a binding MUST include this feature.  Note
 that in order for the presented certificate to be valid at the
 client, the client must be able to validate the certificate.  In
 particular, the validation path of the certificate must end in one
of
 the client's trust anchors, even if that trust anchor is the LIS
 certificate itse

OPSDIR review of draft-dusseault-impl-reports-02

[David B Harrington]

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 requiring their
attention
and spend less time on the trouble-free ones. Improving the documents
is
important, but clearly a secondary purpose.  A third purpose is to
broaden
the OpsDir reviewers' exposure to work going on in other parts of the
IETF.

Reviews from OpsDir members do not in and of themselves cause the IESG
to
raise issue with a document.  The reviews may, however, convince
individual
IESG members to raise concern over a particular document requiring
further
discussion.  The reviews, particularly those conducted in last call
and
earlier, may also help the document editors improve their documents.

draft-dusseault-impl-reports-02 describes updates to existing
processes for
implementation and interoperability reports, and provides
recommendations about the level of detail required.

The document is about IETF standards process, is well written, and
introduces no new operational or management concerns.

>From an opsdir perspective, I would like to see more recommended
discussion of whether the reported implementations are able to be
monitored and configured in a consistent manner, since that is also
part of interoperability, and can be a significant factor in
operational expense and ease of deployment, but is often omitted from
the protocol specification itself. 

David Harrington
dbharring...@comcast.net
ietf...@comcast.net
dharring...@huawei.com


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: DNSSEC is NOT secure end to end

[Phillip Hallam-Baker]

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 applying it to a
network. And it is an argument about the best place to manage
complexity.

No internet security is end to end, no internet security protocol can
be end to end as the ends of the security relationship are PEOPLE and
ORGANIZATIONS.

Depending on your level of abstraction you choose to work at you can
argue that anything is an end.


It would be nice if the paper was available in unencumbered form.
Publication in ACM does not help anything but the author's academic
career. There are real problems with DNSSEC but not those that tend to
gain advancement there,


On Sat, May 30, 2009 at 7:27 PM, Masataka
Ohta wrote:
> Francis Dupont wrote:
>
>> => not only this is very arguable (for instance about the resource
>> exhaustion) but no hop-by-hop/channel security, even something as
>> strong as TSIG, can provide what we need, i.e., end-to-end/object
>> security (*).
>
> Unless your meaning of end-to-end differs from that of David Clark,
> the following argument of his paper is applicable to DNSSEC.
>
>        http://portal.acm.org/citation.cfm?doid=383034.383037
>        Rethinking the design of the Internet:
>        The end to end arguments vs. the brave new world
>
>        The certificate is an assertion by that (presumably
>        trustworthy) third party that the indicated public key
>        actually goes with the particular user.
>
>        These certificates are principal components of essentially
>        all public key schemes,
>
> That is, security of DNSSEC involves third parties and is not end
> to end.
>
>> PS (*): I use the common meaning of end-to-end, not Masataka Ohta's one.
>
> I'm afraid you don't know who David Clark is and how he is related
> to the end to end argument.
>
> However, all the people who are qualified to discuss end to end do
> know him and his argument.
>
>                                                        Masataka Ohta
>
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>



-- 
-- 
New Website: http://hallambaker.com/
View Quantum of Stupid podcasts, Tuesday and Thursday each week,
http://quantumofstupid.com/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [OPSAWG] Last Call: draft-ietf-opsawg-operations-and-management(Guidelines for Considering Operations and Management of NewProtocols and Protocol Extensions) to BCP

[Juergen Schoenwaelder]

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
> consensus".  Perhaps  you're familiar with Douglas  Adams' "The Hitchhiker's
> Guide to the  Galaxy".  To paraphrase, "but the plan  for the destruction of
> earth was clearly posted in  the planning department on alpha centauri, it's
> not our fault you didn't see it".

There is a defined IETF review process and we just go through it and
from what I can tell the process works in making people comment on the
draft that was proposed to become a BCP.

While comments on the content of the draft are fine, I find comments
on the process pretty much out of scope.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: DNSSEC is NOT secure end to end

[Shane Kerr]

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 this would be COM.
> 
> 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?


Also, how can you create a forged certificate?

--
Shane


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Gen-ART LC Review of draft-ietf-geopriv-http-location-delivery-14.txt

[Bernard Aboba]

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 client authentication information if it is 
provided.  How is
this information reflected in the PIDF-LO that is returned in a HELD response? 
 
Ben Campbell said:
 

"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?"

 

There are multiple potential identities that a device (and a user of that 

device) could assert and authenticate against. 

 

Currently the document only talks about use of the IP address as an

identity, and says little about authentication. 

 

However, the PIDF-LO objects that are returned in HELD responses contain 

multiple identification fields.  Currently the document says very little about 

how these fields are filled in.  That leaves the protocol under-specified. 

 

Issues of protocol behavior that are this basic shouldn't be left to an

"extensions" document. 

 

 

 
 

 

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Call for Nomination: RFC Series Editor

[IAB Chair]

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 performance review at the 2 year point and renewal for 3 additional
years for successful performance as RSE in an RFC Editor model.  The
position is open to all with the requisite knowledge, skills and
experience.  The position is not limited to current participants in
the Internet Engineering Task Force.  The incumbent is Bob Braden, who
is not seeking another appointment.

The RSE is responsible for:

   1.  Identifying appropriate steps for RFC Series continuity

   2.  Exercising executive-level management over the implementation of
   policies, processes and procedures established to ensure the
   quality and consistency for the RFC Series.  The RFC Series
   Editor will work with the RSAG, and, where appropriate, the IAB
   and IAOC to develop, new policy and see that contractual
   agreements are met.

   3.  Taking proposed changes to the community, and working with the
   IAB so that the IAB can ensure that there is sufficient community
   review before significant policies or policy changes are adopted.

   4.  Coordinating with IAB and/or IAOC, and together with the IAB
   and/or IAOC participating in reviews of the RFC Publisher, RFC
   Publication Center, and Independent Stream Editor functions to
   ensure the above mentioned continuity.

   5.  Developing, maintaining, and publishing the RFC Style Manual
   for use by authors, editors, the stream managers, the RFC
   Production Center and the RFC Publisher.  publication for use
   by authors, editors, and the RFC publisher.

   6.  Managing the RFC errata process.

   7.  Liaising with the IAB.

   8.  Overseeing consistency of RFCs with the RFC Series and RFC Style
   Manual.


http://iaoc.ietf.org/rfced-procurement.html contains a job description for
this and the
other functions which, together, compose the RFC Editor as described in
http://tools.ietf.org/html/draft-iab-rfc-editor-model

In general, applicants may propose changes to the RSE job description.

The RFC Series Editor is a senior technology professional with the
following qualifications:


   1.  Strong understanding of the IETF and RFC process.

   2.  Executive management experience suitable to managing the
   requirements outlined elsewhere in this document and the many
   aspects of this role and to coordinating the overall RFC Editor
   process.

   3.  Good understanding of the English language and technical
   terminology related to the Internet.

   4.  Good communication skills.

   5.  Experience with editorial processes.

   6.  Independent worker.

   7.  Experience as an RFC author desired.

Nominations are to be submitted to: rse-...@ietf.org in txt format no
later than 8 July 2009 in the form of the package described below.
Individuals may nominate themselves.  The names of all people who
declare themselves willing to serve will be made public on the
ietf-announce at ietf.org and rfc-interest at ietf.org lists after the
end of the solicitation period.  The plan is to post the list of
willing candidates on 13 July 2009.

A nomination package shall consist of:

1. Details about the candidate's background and qualifications for the
   position

2. Explanation of one's view of the role

3. Recommendations to change the position description, if any

4. Thoughts about staffing support requirements, if any

5. Name and contact information for each candidate.

The list of nominated persons will be made public prior to making a
decision, allowing time for the community to pass any relevant
comments.

Interviews will be conducted in person at the IETF 75 meeting in
Stockholm and/or by teleconference before and after the meeting.
Interviews will be conducted by members of an Advisory Committee
appointed by the IAB.  Presence in Stockholm will be at the
individual's own expense. Attendance in Stockholm is optional and will
not be used in the selection criteria.

The Advisory Committee may conduct testing of the candidate performing
the role of the RSE.

The Advisory Committee will submit RSE nominees with its
recommendations to the IAB for its selection and appointment of an RFC
Series Editor.


Timeline:

8 Jun - IAB calls for nominations for RSE position
8 Jul - Nominations close
13 Jul - Nominees announced; community input solicited
23 Jul - Communty input ends
26 Jul - 14 Aug IAB appointed Advisory Committee conducts interviews
18 Aug - Advisory Committee recommends individuals to IAB for 
 RSE position
15 Sep - IAB appoints RSE 
15 Oct - Agreement Executed with IAD for compensation and expenses
15 Oct - Transition begins
1 Jan - Appointments take effect

Compen

Call for Nomination: Independent Submissions Editor

[IAB Chair]

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-year term with a minimal commitment of 2 years, a
performance review at that point and renewal for additional years for
successful performance in an RFC Editor model.  The position is open
to all with the requisite knowledge, skills and experience.  The
position is not limited to current participants in the Internet
Engineering Task Force.  The incumbent is Bob Braden, is not seeking
another appointment.

The ISE is responsible for:

   1.  Maintaining technical quality of the Independent Submission
   stream.

   2.  Reviewing, approving, and processing Independent Submissions.

   3.  Forwarding draft RFCs in the Independent Submission Stream to
   the RFC Production Center.

   4.  Reviewing and approving Independent Submissions RFC errata.

   5.  Coordinating work and conforming to general RFC Series policies
   as specified by the IAB and RSE.

   6.  Providing statistics and documentation as specified by the IAOC
   and/or IAB.



http://iaoc.ietf.org/rfced-procurement.html contains a job description
for this and the
other functions which, together, compose the RFC Editor as described in
http://tools.ietf.org/html/draft-iab-rfc-editor-model

In general, applicants may propose changes to the ISE job description.


The Independent Submission Editor is a senior position for which the
following qualifications are desired:

   1.  Technical competence, i.e., broad technical experience and
   perspective across the whole range of Internet technologies and
   applications, and specifically, the ability to work effectively
   with portions of that spectrum in which no personal expertise
   exists.

   2.  Thorough familiarity with the RFC series.

   3.  An ability to define and constitute advisory and document review
   arrangements.  If those arrangements include an Editorial Board.

   4.  Good standing in the technical community, in and beyond the IETF.

   5.  Demonstrated editorial skills, good command of the English
   language, and demonstrated history of being able to work
   effectively with technical documents and materials created by
   others.

   6.  The ability to work effectively in a multi-actor environment with
   divided authority and responsibility similar to that described in
   this document.


Nominations are to be submitted to: ise-...@ietf.org in txt format no
later than 8 July 2009 in the form of the package described below.


Individuals may nominate themselves.  The names of all people who
declare themselves willing to serve will be made public on the
ietf-announce at ietf.org and rfc-interest at ietf.org lists after the
end of the solicitation period.  The plan is to post the list of
willing candidates for community input on 13 July 2009.

A nomination package shall consist of:
1. Details about the candidate's background and qualifications for the
position 
2. Explanation of one's view of the role
3. Recommendations to change the position description, if any
4. Thoughts about staffing support requirements, if any
5. Name and contact information for each candidate.


The list of nominated persons will be made public prior to making a
decision, allowing time for the community to pass any relevant
comments.

Interviews will be conducted in person at the IETF 75 meeting in
Stockholm and/or by teleconference before and after the meeting.
Interviews will be conducted by members of an Advisory Committee
appointed by the IAB.  Presence in Stockholm will be at the
individual's own expense.  Attendance in Stockholm is optional and
will not be used in the selection criteria.

The Advisory Committee may conduct testing of the candidate performing
the role of the ISE.

The Advisory Committee will submit ISE nominees with its
recommendations to the IAB for its selection and appointment of an
Independent Submissions Editor.

Timeline:

8 Jun - IAB calls for nominations for ISE position
8 Jul - Nominations close
13 Jul - Nominees announced; community input solicited
23 Jul - Community input ends
26 Jul - 14 Aug IAB appointed Advisory Committee conducts interviews
18 Aug - Advisory Committee recommends individuals to IAB for
 ISE position
15 Sep - IAB appoints ISE 
15 Oct - Agreement executed for expenses
15 Oct - Transition begins
1 Jan - Appointments take effect

Compensation

The Independent Submissions Editor is a voluntary position, as are all
stream manager positions, IETF, IAB, and IRTF.  A budget will be
established and expenses provided in negotiations with the IETF
Administrative Oversight Committee, as represented by the IETF
Administrative Director.  Expenses will be provided during th

RE: Gen-ART LC Review of draft-ietf-geopriv-http-location-delivery-14

[Mary Barnes]

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 in question was added in the -12 version when we added a
lot more text on HTTP guidelines and it likely should have been merged
then with the existing text related to security mechanisms. 

You are correct that the device is the HTTP client the the LIS the HTTP
server, so the reference should have been to section 9.3 - sorry.

Mary. 
 
-Original Message-
From: Ben Campbell [mailto:b...@estacado.net] 
Sent: Monday, June 08, 2009 2:27 PM
To: Barnes, Mary (RICH2:AR00)
Cc: Richard Barnes; General Area Review Team;
james.winterbot...@andrew.com; martin.thom...@andrew.com;
barbara.st...@att.com; acoo...@cdt.org; Cullen Jennings; ietf@ietf.org
Subject: Re: Gen-ART LC Review of
draft-ietf-geopriv-http-location-delivery-14

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 with the fact that the HTTP binding explicitly discourages
stronger client authentication mechanisms acceptable to them. If it is,
I am fine with it, and the draft would not need a change. If on the
other hand I have misunderstood something, that's different.

I am a little confused about the proposed change to section 8, though.  
It sounds like it is conflating LIS authentication with device
authentication. To decompose your proposed language I read it as:

"The LIS SHOULD NOT ... use [device authentication mechanism], but
rather SHOULD use [LIS authentication mechanism]"

Is it possible I am misunderstanding the direction of the client- server
relationship in the HTTP binding? I was assuming the device to be the
HTTP client and the LIS to be the HTTP server--do I have it backwards?



On Jun 8, 2009, at 2:12 PM, Mary Barnes wrote:

> 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.
>
> And the following:
>   A prerequisite for meeting this requirement is that the LIS must 
> have
>   some assurance of the identity of the client.  Since the target of
>   the returned location is identified by an IP address, simply sending
>   the response to this IP address will provide sufficient assurance in
>   many cases.  This is the default mechanism in HELD for assuring that
>   location is given only to authorized clients; LIS implementations
>   MUST support a mode of operation in which this is the only client
>   authentication.
>
> And, then the text goes on to some of the other text in section 9.3 
> that you had questions about that I responded to in a separate email.
>
> So, I'm not certain I understand the problem IF I make the proposed 
> change to the sentence in section 8.
>
> Mary.
>
> -Original Message-
> From: Ben Campbell [mailto:b...@estacado.net]
> Sent: Monday, June 08, 2009 1:47 PM
> To: Barnes, Mary (RICH2:AR00)
> Cc: Richard Barnes; General Area Review Team; 
> james.winterbot...@andrew.com; martin.thom...@andrew.com; 
> barbara.st...@att.com; acoo...@cdt.org; Cullen Jennings; ietf@ietf.org
> Subject: Re: Gen-ART LC Review of
> draft-ietf-geopriv-http-location-delivery-14
>
> 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 that the lack of client device authentication is

> a problem. The reverse routeability aspect might be sufficient. I'm 
> merely pointing it out to make sure people think about it.
>
> On Jun 8, 2009, at 1:35 PM, Mary Barnes wrote:
>
>> 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 necessarily what MUST be used and the 
>> RECOMMENDED mechanism is actually a "can", there are several lower 
>> case MUSTs, etc. Noting in particular the MAY in terms of the client 
>> being able to use an external mechanism.
>> Also, note that the recommended mechanism is the authentication 
>> mechanism as provided by TLS, so there's nothing unusual with this
>> approach (as I understand it since I'm not a security expert).   

Re: [Asrg] DNSSEC is NOT secure end to end

[David Wilson]

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. Firstly, it provides the means to digitally
sign RRsets. This provides data origin authentication and data
integrity. As this operates at the DNS application layer, this is
clearly "end to end" within David Clark's terminology. It does not rely
on any security services in the lower communication layers (in the way
that, for instance, relying on TCP would).

This origin authentication and integrity is precisely what is required
to avoid the DNS cache poisoning which is the kind of vulnerability
which prompted this discussion.

This aspect of DNSSEC does not require the use of any PKI. A security
aware resolver can obtain by some out-of-band means the public signing
key for some "island of security", and choose to trust that key.

However, such bilateral arrangements do not scale to the Internet. So,
DNSSEC provides a means for an Authentication Chain, to use the specific
DNSSEC term. A signed zone can authenticate the key of a child zone.
There is a chain here. However, it is of a significantly different
character to a communication network. Whether it is "end to end" or not,
is for a different discussion.

> 
> > "End-to-end" security means that the security of that data item does not
> > depend on the trustworthiness of any intermediate node, or channel.
> 
> According to the terminology of David Clark, certificate authorities
> are intermediate nodes.
> 
> If you have different terminology, use it outside of the Internet
> community but not within.

I get the impression from you that DNSSEC is to be disregarded because
it is not "end to end". However, the opinion of "the Internet community"
as regards DNSSEC has been made clear in the last few days, given these
announcements:

http://www.nist.gov/public_affairs/releases/dnssec_060309.html

http://pir.org/index.php?db=content/Website&tbl=ORG_Advantage&id=2

http://www.networkworld.com/news/2009/022409-verisign-dns-security.html?hpg1=bn

If the Internet community agrees with you that DNSSEC is not "end to
end", then this does not seem to divert them from implementing it.

best regards

David


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [Asrg] DNSSEC is NOT secure end to end

[David Wilson]

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 (Reduced Instruction Set Computer) is
> given as an example of end to end design.

Er, no. The article states:

"The arguments that are used in support of reduced instruction set
computer (RISC) architecture are similar to end-to-end arguments."

I.e. the arguments for end to end are similar to the arguments for RISC.
This is not the same as saying that RISC is an example of end to end
design.

> Both of the papers are freely downloadable.
> 
> The original paper:
> 
> http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf
> 
> The paper in 2001:
> 
> http://www.csd.uoc.gr/~hy558/papers/Rethinking_2001.pdf
> 
> You should have read both of them to make the dinner more valuable.
> 

[Interesting articles, which took me back to discussions 20 years ago as
regards connectionless vs. connection oriented networks.]

It is clear from both of these that the basic subject is data
communication over a communication system. Thus the second article
quotes from the first article thus:

"The function in question can completely and correctly be implemented
only with the knowledge and help of the application standing at the
endpoints of the communications system. Therefore, providing that
questioned function as a feature of the communications systems itself is
not possible."

So the basic object under consideration here is a "communication
system". 

It is clear from the first article that what is envisaged is a layered
model, (c.f. the conclusion). I would not be surprised if this kind of
thinking was input to the development of the OSI model for data
communications, which does set out to assign to each layer an
appropriate function.

The basic thesis of the article is that functions concerned with, for
instance, security and reliability are best done in the upper layers,
even the top (application) layer, as the application cannot rely
entirely on the lower layers to "do their stuff".

Thus "end to end" is about communication from one application layer to
the peer application layer down through the layers at one system, and
then up through the layers at the other system. So, I would paraphrase
the "end to end design principle" as the "application to application"
design principle.

I note that in models like the OSI model, only the lowest layer have
intermediate systems. (That's why layer 3 is called the network layer).
The article in no way implies that it is the existence of intermediate
systems which is the deciding factor in the design. "End to end" is not
in contrast to "hop by hop".

So, applying this to DNSSEC's PKI, this is clearly an application layer
security system. The system does not depend upon the security or
reliability of any lower layers (or, indeed, intermediate systems). So,
it would seem to fit the "end to end design" of this article.

The second article is a discussion about how the end-to-end design
principle might need to be modified in the light of the realities of the
modern Internet. In the present context of DNSSEC, the discussion of
trust is important.

best regards

David

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [Asrg] DNSSEC is NOT secure end to end

[Masataka Ohta]

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 hops of certificate authorities, which
is what is discussed in latter paper of David Clark published in
2001. Read it.

> As this operates at the DNS application layer, this is
> clearly "end to end" within David Clark's terminology. It does not rely
> on any security services in the lower communication layers (in the way
> that, for instance, relying on TCP would).

If you read the paper, you can find the lower layer of PKI consists
of communication with or between certificate authorities.

Compromising a certificate authority in the lower communication
layer breaks the security of data origin authentication and data
integrity.

> This origin authentication and integrity is precisely what is required
> to avoid the DNS cache poisoning which is the kind of vulnerability
> which prompted this discussion.

As has been discussed in the thread, DNSSEC is NOT a protection
against cache poisoning, because caches poisoned with forged
certificate breaks the security.

> This aspect of DNSSEC does not require the use of any PKI.

Read the 2001 paper on why PKI not end to end and why DNSSEC no
exception. The paper explains why scale breaks the end to end
property.

> I get the impression from you that DNSSEC is to be disregarded because
> it is not "end to end".

Being "end to end" has practical advantages.

See above on how useless DNSSEC is to avoid cache poisoning, which
was the motivation to deploy it.

Masataka Ohta

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RISC is end to end (was Re: [Asrg] DNSSEC is NOT secure end to end)

[Masataka Ohta]

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
>>given as an example of end to end design.

> Er, no. The article states:

The paper states:

any attempt by the computer designer to anticipate the
client's requirements for an esoteric feature will
probably miss the target slightly and the client will end
up reimplementing that feature anyway

which is an end to end argument where communication is at high
level between computer designers and their clients.

> It is clear from both of these that the basic subject is data
> communication over a communication system.

That is true only with the widest meaning of "communication". However,
"IN NETWORKING" by Phillip has a lot narrow meaning and even the
original paper says:

A version of the end-to-end argument in a non-communication
application was developed in the 1950's by system analysts
whose responsibility included reading and writing files on
large numbers of magnetic tape reels.

> So, applying this to DNSSEC's PKI, this is clearly an application layer

If you want to draw some conclusion from the 2001 paper, quote
text from the paper. There is no point to reiterate it with
your subtly modified terminology only to give a subtly modified
impression on the content of the paper.

> The second article is a discussion about how the end-to-end design
> principle might need to be modified in the light of the realities of the
> modern Internet.

That is an explanation on the motivation to write the paper and
the conclusion of the paper is:

We argue that the open, general nature of the Net, which
derived from the end to end arguments, is a valuable
characteristic that encourages innovation, and this
flexibility should be preserved.

which means the end to end argument is not modified.

Instead, the paper, for example, says for regulations to be
realistic, they should follow the end to end principle.

Masataka Ohta


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-green-secsh-ecc (Elliptic-Curve Algorithm Integration in the Secure Shell Transport Layer) to Informational RFC

[Sean Turner]

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
final comments on this action.  Please send substantive comments to the
ietf@ietf.org mailing lists by 2009-07-06. Exceptionally, 
comments may be sent to i...@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-green-secsh-ecc-08.txt


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


A couple of comments:

Other ECC documents in the IETF (TLS, SMIME, PKIX) indicate that support 
for compressed keys are MAY while this draft says MUST NOT for ECDSA and 
ECDH keys and MAY for ECMQV.  What was the rationale for this?


Sec 3.1.1: Should the must be MUST in the following: The message hashing 
algorithm must be from the SHA2 family of hash functions [FIPS-180-3] 
and is chosen according to the curve size as specified in Section 6.2.1.


Sec 3.1.2: In TLS/SMIME/PKIX, the signature value (r&s) are integers but 
they are encoded together with the following syntax:

Ecdsa-Sig-Value ::= SEQUENCE {
  r   INTEGER,
  s   INTEGER
}
Any chance of reuse?

Sec 9.1: The TLS, SMIME, and PKIX use the secp* naming for the curves 
instead of nist*.  Any chance we could use the secp* names?


In 9.1: Should the should be SHOULD in the following: These curves 
should always be enabled unless specifically disabled by local security 
policy.


Does the Certicom IPR applies to this ID (it pretty much applies to all 
the other ECC RFCs/IDs)?


spt
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: DNSSEC is NOT secure end to end

[Masataka Ohta]

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.

Thank you for demonstrating a perfect manner for a professional
forum to deny a reference to an ACM article because it is paywalled.

So, we, professionals, should, of course, not discuss about DNS,
because domain registration is not free but badly monopolized.

Before closing the discussion, cloud you teach me the name and
location of the restaurant you have had dinner with David Clark
obviously free of charge?

Free dinner is better than free lunch.

Masataka Ohta


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Gen-ART LC Review ofdraft-ietf-geopriv-http-location-delivery-14.txt

[Thomson, Martin]

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, this constraint was considered 
important.  This prevents use of pre-shared keys such as would be required for 
digest/basic [1] [2].

 

Thus we come to the choice of IP address and return reachability.  I believe 
that the draft addresses the impact of this choice adequately; Section 9.3 
seems most directly applicable here, but other places touch on this choice 
where it’s relevant.  If you do not believe that there are relevant points that 
are not brought up, I’d encourage you to send text.

 

Regarding alternative identifiers, there is an extension document that talks 
about use of alternative identifiers, and I do believe that this particular 
point CAN be addressed in an extension.  For those, authentication (other than 
return reachability, if you consider that to be a form of authentication) can 
be made a requirement.

 

I’ll address the other more substantive point regarding identity in PIDF-LO in 
another (longer) mail.

 

--Martin

 

[1] The document is clear on its use of digest/basic: the LIS MUST NOT rely on 
it being used.  That’s in recognition of the above constraint.  In other words, 
the LIS MUST NOT fail a request because the device did not provide 
authentication.  That doesn’t prevent it from being used in an extension to the 
protocol.

 

[2] Of course, there are networks where the constraint might not be applicable. 
 For instance, access to the network could be restricted using some form of 
authentication.  However, a device that accesses a LIS within those networks 
must also be aware that it needs to present this same authentication 
information when talking to a LIS.  We cannot guarantee that a device will do 
this, since compliance would need to be a prerequisite of network access; 
designers of future access networks might choose to add this to their network 
design.  

 

 

 

From: Bernard Aboba
Sent: Tuesday, 9 June 2009 5:48 AM
To: b...@estacado.net; ietf@ietf.org
Subject: Re: Gen-ART LC Review 
ofdraft-ietf-geopriv-http-location-delivery-14.txt

 

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 client authentication information if it is 
provided.  How is

this information reflected in the PIDF-LO that is returned in a HELD response? 

 

Ben Campbell said:

 
"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?"
 
There are multiple potential identities that a device (and a user of that 
device) could assert and authenticate against. 
 
Currently the document only talks about use of the IP address as an
identity, and says little about authentication. 
 
However, the PIDF-LO objects that are returned in HELD responses contain 
multiple identification fields.  Currently the document says very little about 
how these fields are filled in.  That leaves the protocol under-specified. 
 
Issues of protocol behavior that are this basic shouldn't be left to an
"extensions" document. 
 
 

 

 

 


This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.

[mf2]
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf