Re: Questionnaire to survey opinion concerning a possible redefinition of UTC

[Stephane Bortzmeyer]

On Thu, Aug 25, 2011 at 12:24:01PM +0200,
 Stephane Bortzmeyer  wrote 
 a message of 59 lines which said:

> Since several RFCs rely on UTC and leap seconds (3339, 4765, 5905,
> etc), this questionnaire may be of interest for some persons [the Web
> page mentions two articles, if you are in a hurry, the first one is
> the PRO and the second one the CON]. One more week to comment.
> 
> http://hpiers.obspm.fr/eop-pc/index.php?index=questionnaire

I have also been directed at this meeting in october in Exton, PA,
USA, where the organizers would be glad to have input from people
involved in software and computer networks:

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

Re: Experiment for different schedule for Friday

[Hadriel Kaplan]

+1

-hadriel

On Aug 23, 2011, at 2:04 AM, John C Klensin wrote:

> +1.  I could also happily live with the alternate, more
> compressed, schedule -- I think both are preferable to the
> schedule used in Quebec and earlier.
> 
>   john
> 
> 
> --On Tuesday, August 23, 2011 07:40 +0200 Eliot Lear
>  wrote:
> 
>> 
>> 
>> On 8/22/11 11:24 PM, IETF Chair wrote:
>>> The IESG is considering a different schedule for the Friday
>>> of IETF 82.  The IESG is seeking your input on these
>>> potential changes.
>>> 
>>> The IESG would like to try a schedule experiment on Friday,
>>> using this schedule:
>>> 
>>> 9:00 AM - 11:00 AM - Session I
>>> 11:00 AM - 11:20 AM - Room Change and Cookie Break
>>> 11:20 AM - 12:20 PM - Session II
>>> 12:10 PM - 12:30 PM - Room Change Break
>>> 12:30 PM - 13:30 PM - Session III
>>> 
>>> The IESG has already consulted with the IAOC because of the
>>> cost associated with the additional food and beverage break.
>>> The IAOC believes that the additional cost can be managed
>>> without raising the meeting fee.
>> 
>> I think this is a good experiment to run as proposed.
> 
> 
> 
> 
> ___
> 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

https

[t.petch]

Why does the IETF website consider it necessary to use TLS to access the mailing
list archives, when they all appeared without it, or any other security, in the
first place?

Besides all the usual hassle of TLS, today the certificate is reported by IE as
expired, which sort of sums it up.

Tom Petch

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

Re: Hyatt Taipei cancellation policy?

[Ole Jacobsen]

That's why we've met TWICE in your city!


Ole J. Jacobsen
Editor and Publisher,  The Internet Protocol Journal
Cisco Systems
Tel: +1 408-527-8972   Mobile: +1 415-370-4628
E-mail: o...@cisco.com  URL: http://www.cisco.com/ipj
Skype: organdemo


On Thu, 25 Aug 2011, Michal Krsek wrote:

> Dear sirs,
> I really appreciate your support to US venues, but please keep in mind, there
> are places eastern from Bermuda and western from Kauai. In addition there is
> also some land southern from El Paso.
> 
> Lets say - Internet is for everyone. And, trust me or not, there are people
> that have no budget for intercontinental travel and their input is  to the
> community work is valuable too.
> 
> Sorry for this social two cents in this engineering list.
> 
> Regards
> Michal Krsek
> 
> > How about Fresno?
> >
> > Sent from my iPhone
> >
> >
> > > -Original Message-
> > > From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
> > > Stewart Bryant
> > > Sent: Thursday, August 25, 2011 11:09 AM
> > > To: ietf@ietf.org
> > > Subject: Re: Hyatt Taipei cancellation policy?
> > >
> > > On 25/08/2011 18:12, Mary Barnes wrote:
> > > > I am also a fan of Minneapolis for meetings - the facilities at the
> > > > Hilton are perfect for our needs.  There's lots of food options.  It
> > > > has good air connections and there is decent pubic transport from the
> > > > airport to the city.  However, this seems to be a minority
> > > > perspective. If we were to do votes again, the results might be
> > > > interesting.
> > > >
> > > > Mary.
> > > I like Minneapolis as well, but then, speaking personally, I like US
> > > IETF venues in general.
> > >
> > > Stewart
> > >
> 
> ___
> 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: https

[SM]

Hi Tom,
At 00:18 26-08-2011, t.petch wrote:
Besides all the usual hassle of TLS, today the certificate is 
reported by IE as

expired, which sort of sums it up.


Already reported to ietf-action@.

Regards,
-sm

P.S. My experience of ietf-action@ is that they are responsive and do 
fix problems that are reported. 


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

Re: https

[t.petch]

- Original Message -
From: "SM" 
To: "t.petch" 
Cc: "IETF Discussion" 
Subject: Re: https


> Hi Tom,
> At 00:18 26-08-2011, t.petch wrote:
> >Besides all the usual hassle of TLS, today the certificate is
> >reported by IE as
> >expired, which sort of sums it up.
>
> Already reported to ietf-action@.
>
> Regards,
> -sm
>
> P.S. My experience of ietf-action@ is that they are responsive and do
> fix problems that are reported.

Yup, but why are we using https at all?  Who decided, and please would they
undecide?  Unexpired certificates can be circumvented, but all too often, the
https parts of the web site just do not work and, more importantly, I think it
wrong to use industrial grade security where none is called for.

Tom Petch


>

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

Re: https

[Bert Wijnen (IETF)]

Yup, but why are we using https at all?  Who decided, and please would they
undecide?  Unexpired certificates can be circumvented, but all too often, the
https parts of the web site just do not work and, more importantly, I think it
wrong to use industrial grade security where none is called for.



I agree with Tom here. In my understanding, all IETF communications
and (mailing list) discussions are open and public.
So why do we need to protect/encrypt?

I would say: protect what must be protected
  but don't protect what is not supposed to be protected.

just encrypting everything seems incorrect to me.

Bert


Tom Petch


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

Re: https

[Eliot Lear]

Bert, Tom,


I don't see this as being a matter of encrypting, but rather providing
verifiable information the community.  What's more, in as much as the
IETF is a trusted site by many, it's probably a good idea to have at
least some confidence that when you click on a link, you're not going to
get hacked.  Finally, the IETF designed this system, and if we don't
like the fragility, perhaps we should fix it.  There's a saying about
eating one's own dogfood.  After all, if we won't eat ours, why should
anyone else?

By the way, Tom, you're not quite right.  Mail sent out from the IETF
list (including this one and the one you sent to the list) is signed by
the IETF with DKIM.  Again, eating our own dogfood.

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

Re: https

[Scott Schmit]

On Fri, Aug 26, 2011 at 09:18:41AM +0200, t.petch wrote:
> Why does the IETF website consider it necessary to use TLS to access
> the mailing list archives, when they all appeared without it, or any
> other security, in the first place?

TLS provides more than confidentiality--it also provides authenticity.
If I were living in a hostile regime, I'd appreciate knowing that the
RFCs, etc that I'm getting really come from the IETF unmodified.

Also, as a general principle, I'd rather someone not be able to read
over my shoulder, even if it is harmless stuff. Using encryption only
when I need it makes all of my encrypted traffic less secure.

For example, if I were out to modify the traffic you read to make sure
that you didn't even know that a working group existed, I'd have a lot
easier time of it if you use DNS without DNSSEC, HTTP without TLS, TLS
without HASTLS, DANE, HSTS, etc. Now, not all of that is completed
protocol work, but one step at a time.

> Besides all the usual hassle of TLS, today the certificate is reported
> by IE as expired, which sort of sums it up.

Mistakes happen. Hopefully lessons are learned so that they don't get
repeated.

If it's a protocol problem, whose fault is that but ours?

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

Re: https

[Thomas Narten]

"t.petch"  writes:

> Why does the IETF website consider it necessary to use TLS to access
> the mailing list archives, when they all appeared without it, or any
> other security, in the first place?

Archives have long been and continue to be available at
ftp://ftp.ietf.org/ietf-mail-archive/

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

Re: https

[Eric Burger]

+100

On Aug 26, 2011, at 6:50 AM, Scott Schmit wrote:

> On Fri, Aug 26, 2011 at 09:18:41AM +0200, t.petch wrote:
>> Why does the IETF website consider it necessary to use TLS to access
>> the mailing list archives, when they all appeared without it, or any
>> other security, in the first place?
> 
> TLS provides more than confidentiality--it also provides authenticity.
> If I were living in a hostile regime, I'd appreciate knowing that the
> RFCs, etc that I'm getting really come from the IETF unmodified.
> 
> Also, as a general principle, I'd rather someone not be able to read
> over my shoulder, even if it is harmless stuff. Using encryption only
> when I need it makes all of my encrypted traffic less secure.
> 
> For example, if I were out to modify the traffic you read to make sure
> that you didn't even know that a working group existed, I'd have a lot
> easier time of it if you use DNS without DNSSEC, HTTP without TLS, TLS
> without HASTLS, DANE, HSTS, etc. Now, not all of that is completed
> protocol work, but one step at a time.
> 
>> Besides all the usual hassle of TLS, today the certificate is reported
>> by IE as expired, which sort of sums it up.
> 
> Mistakes happen. Hopefully lessons are learned so that they don't get
> repeated.
> 
> If it's a protocol problem, whose fault is that but ours?
> 
> -- 
> Scott Schmit
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf



smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: https

[Donald Eastlake]

On Fri, Aug 26, 2011 at 4:39 AM, t.petch  wrote:
> - Original Message -
> From: "SM" 
> To: "t.petch" 
> Cc: "IETF Discussion" 
> Subject: Re: https
>
>
>> Hi Tom,
>> At 00:18 26-08-2011, t.petch wrote:
>> >Besides all the usual hassle of TLS, today the certificate is
>> >reported by IE as
>> >expired, which sort of sums it up.
>>
>> Already reported to ietf-action@.
>>
>> Regards,
>> -sm
>>
>> P.S. My experience of ietf-action@ is that they are responsive and do
>> fix problems that are reported.
>
> Yup, but why are we using https at all?  Who decided, and please would they
> undecide?  Unexpired certificates can be circumvented, but all too often, the
> https parts of the web site just do not work and, more importantly, I think it
> wrong to use industrial grade security where none is called for.

The mail archives (and the minutes of the physical meetings) are the
official record of the Working Groups, IETF, etc. Those archives
should be available with a reasonably high level of integrity and
authenticity.

Thanks,
Donald
=
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com

> Tom Petch
>
>
>>
>
> ___
> 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: Routing at the Edges of the Internet

[Eric Burger]

I disagree with the fundamental premise of this concept, that it is a PROBLEM 
that the Internet is not a network.  Um, last I looked, the Internet is an 
interconnection of networks.  Not a network in that sense.

Edge devices can today, in the scenario you portray, pick the "best" network to 
connect to.  Last thing we need is to ossify a method of doing that.  Let the 
edge be the edge and do what it wants.

On Aug 25, 2011, at 9:57 PM, Adam Novak wrote:

> I trust that some of you have seen this article from a while back:
> 
> 
> 
> An informative except:
> 
> "When I open my laptop, I see over ten different wifi access points.
> Say I wanted to send data to my friend in the flat next to mine. It is
> idiotic that nowadays, I would use the bottleneck subscriber line to
> my upstream ISP and my crippled upload speed and push it all the way
> across their infrastructure to my neighbors ISP and back to the Wifi
> router in reach of mine. The Internet is not meant to be used that
> way. Instead, all these wifi networks should be configured to talk to
> each other."
> 
> I also trust that you are aware of what happened to the Internet in
> Egypt (and elsewhere) this spring, where Internet connectivity was
> disrupted by shutting down major ISP networks.
> 
> I would like to bring the attention of the IETF to what I see as a
> fundamental problem with the current architecture of the Internet:
> 
> The Internet is not a network.
> 
> As part of the development of the Internet, fault-tolerant routing
> protocols have been developed that allow a connecdestined fortion to
> be maintained, even if the link that was carrying goes down, by
> routing packets around the problem. Similarly, packets can be
> load-balanced over multiple links for increased bandwidth. However,
> the benefits of these technologies are not available to end users. If
> I have a smartphone with both a 3G and a Wi-Fi connection, downloads
> cannot currently be load-balanced across them. The two interfaces are
> on two different networks, which are almost certainly part of two
> different autonomous systems. Packets must be addressed to one of the
> two interfaces, not the device, and packets addressed to one interface
> have no way to be routed to the other. Similar problems arise when a
> laptop has both a wired and a wireless connection. Wired networks also
> suffer from related difficulties: If I have Verizon and my friend has
> Comcast, and we string an Ethernet cable between our houses, packets
> for me will still all come down my connection, and packets for my
> friend will still all come down theirs.
> 
> The Internet, as it currently appears to end-users, has a logical tree
> topology: computers connect to your home router, which connects to
> your ISP, which connects to the rest of the Internet. Cell phones
> connect to the tower, which connects through a backhaul link to the
> rest of the Internet. Almost all of the devices involved have multiple
> physical interfaces and full IP routing implementations, but only the
> default route is ever used. This results in a brittle Internet: the
> failure of one ISP router can disconnect a large number of end-users
> from the Internet, as well as interrupting communication between those
> users, even when those users are, physically, only a few feet from
> each other.
> 
> My question is this: what IETF work would be needed to add more
> routing to the edges of the Internet? If each home or mobile device
> was essentially it's own autonomous system, what would this do to
> routing table size? To ASN space utilization? How can individuals
> interconnect home networks when RIRs do not assign address and AS
> number resources to individuals? How might individuals interconnect
> home networks without manual routing configuration? Under what
> circumstances could an ISP trust a client's claim to have a route to
> another client or to another ISP? How might packets sent to a device's
> address on one network be routed to that device's address on another
> network, while packets to immediately adjacent addresses take the
> normal path?
> ___
> 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: https

[Tim Bray]

I'm increasingly coming to think that *everything* should be done with
TLS unless you can prove it's harmful.  Call me paranoid, but given
the general state of the world, secure-by-default seems like the way
to go.  -Tim

On Fri, Aug 26, 2011 at 1:39 AM, t.petch  wrote:
> - Original Message -
> From: "SM" 
> To: "t.petch" 
> Cc: "IETF Discussion" 
> Subject: Re: https
>
>
>> Hi Tom,
>> At 00:18 26-08-2011, t.petch wrote:
>> >Besides all the usual hassle of TLS, today the certificate is
>> >reported by IE as
>> >expired, which sort of sums it up.
>>
>> Already reported to ietf-action@.
>>
>> Regards,
>> -sm
>>
>> P.S. My experience of ietf-action@ is that they are responsive and do
>> fix problems that are reported.
>
> Yup, but why are we using https at all?  Who decided, and please would they
> undecide?  Unexpired certificates can be circumvented, but all too often, the
> https parts of the web site just do not work and, more importantly, I think it
> wrong to use industrial grade security where none is called for.
>
> Tom Petch
>
>
>>
>
> ___
> 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: https

[t.petch]

- Original Message -
From: "Donald Eastlake" 
To: "t.petch" 
Cc: "IETF Discussion" 
Sent: Friday, August 26, 2011 3:43 PM
On Fri, Aug 26, 2011 at 4:39 AM, t.petch  wrote:
> - Original Message -
> From: "SM" 
> To: "t.petch" 
> Cc: "IETF Discussion" 
>
>
>> Hi Tom,
>> At 00:18 26-08-2011, t.petch wrote:
>> >Besides all the usual hassle of TLS, today the certificate is
>> >reported by IE as
>> >expired, which sort of sums it up.
>>
>> Already reported to ietf-action@.
>>
>> Regards,
>> -sm
>>
>> P.S. My experience of ietf-action@ is that they are responsive and do
>> fix problems that are reported.
>
> Yup, but why are we using https at all? Who decided, and please would they
> undecide? Unexpired certificates can be circumvented, but all too often, the
> https parts of the web site just do not work and, more importantly, I think it
> wrong to use industrial grade security where none is called for.

The mail archives (and the minutes of the physical meetings) are the
official record of the Working Groups, IETF, etc. Those archives
should be available with a reasonably high level of integrity and
authenticity.


Ys but for the mail archives they provide authenticity and integrity only as
far as the Man In The Middle, namely the IETF server/process; this adds a
spurious, to me, impression of security for e-mails that could have come from
anyone masquerading as anyone.  And when there is some defence against
masquerade - DKIM (and yes I know what it does and its limitations) - then the
DKIM signature is invalidated by the list process, that MITM again.

If there are requirements for archives to be provided with a degree of trust, eg
in response to a subpoena, then that should be a separate process, leaving us
ordinary folk to access them in a simple and straighforward manner.

Tom Petch







Thanks,
Donald
=
Donald E. Eastlake 3rd +1-508-333-2270 (cell)
155 Beaver Street, Milford, MA 01757 USA
d3e...@gmail.com

> Tom Petch
>
>
>>
>
> ___
> 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: https

[John C Klensin]

--On Friday, August 26, 2011 09:43 -0400 Donald Eastlake
 wrote:

>> Yup, but why are we using https at all?  Who decided, and
>> please would they undecide?  Unexpired certificates can be
>> circumvented, but all too often, the https parts of the web
>> site just do not work and, more importantly, I think it wrong
>> to use industrial grade security where none is called for.
> 
> The mail archives (and the minutes of the physical meetings)
> are the official record of the Working Groups, IETF, etc.
> Those archives should be available with a reasonably high
> level of integrity and authenticity.

Don,

If that is the goal, wouldn't we be lots better off just
digitally signing those things, just as we are gradually
starting to create signatures for I-Ds, etc.?  Verifying that
one is talking to the right server and that the content is not
tampered with in transit is all well and good, but it doesn't
protect against compromised documents or a compromised server at
all.

   john



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

Re: https

[Joel jaeggli]

It doesn't...

http://www.ietf.org/mail-archive/web/v6ops/current/maillist.html

On 8/26/11 00:18 , t.petch wrote:
> Why does the IETF website consider it necessary to use TLS to access the 
> mailing
> list archives, when they all appeared without it, or any other security, in 
> the
> first place?
> 
> Besides all the usual hassle of TLS, today the certificate is reported by IE 
> as
> expired, which sort of sums it up.
> 
> Tom Petch
> 
> ___
> 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: Hyatt Taipei cancellation policy?

[Mary Barnes]

Henk,

A few responses inline below [MB].

Regards,
Mary.

On Fri, Aug 26, 2011 at 1:22 AM, Henk Uijterwaal
wrote:

> On 25/08/2011 01:03, geoff wrote:
> > On Wed, 2011-08-24 at 15:28 -0400, Sam Hartman wrote:
> >> 1) We don't have to go to any particular location.  There has been an
> >> assumption made by people in this discussion that sometimes when we pick
> >> locations with particularly expensive hotels, we'll get particularly
> >> expensive meetings.  That's great except that we were the ones who chose
> >> to go to those locations.
> >> If we can't meet our cost targets at a location, go somewhere else.
>
> > Sam makes a really good point here.  We didn't have to go to Taipei.
> > For some reason we chose to go to Taipei.
>
> Not quite.  There is a requirement to have meetings all over the world,
> in a ratio of 1:1:1 for Europe, North America and Asia.  Considering
> that we have to go to Asia, Taipei looks like a sensible choice: it
> is in the middle of the region, it well connected, and it is one of
> the bigger economies in the region.
>
> I have a feeling that if we dropped this requirement and went for a
> 0:3:0 schedule because it is much cheaper for the US participants to
> go to M'polis 3 times/year, somebody else would complain.
>

[MB] I've not seen a single person advocate a 0:3:0 schedule and it's only
less cheaper for all participants (not just US) because the hotel rates are
extremely reasonable (<$150 as I recall).It is definitely less expensive
for the vast majority of participants than NA cities like Quebec City and
San Francisco that  travel by air.  BUT, I think you are missing what we are
saying overall - the major reasons some of us prefer Minneapolis is because
it meets what some of us have been saying over and over as far a key factors
for meetings:
http://www.ietf.org/mail-archive/web/ietf/current/msg68656.html
http://www.ietf.org/mail-archive/web/ietf/current/msg68727.html

The expense factor is just one other factor that is higher priority for some
folks than others and certainly shouldn't be ignored in venue selection, but
I don't think there is an accurate way to judge the overall expense burden
for attendees as it is not at all  based on which continent the meeting is
held.  My expenses for  Prague, Quebec City and Beijing were nearly the
same: Prague was $500 less than QC and Beijing - cost for QC and Beijing was
the same!!! [/MB]

>
> > The hotel (and
> > host if there was on) could/should have been told -
> > sorry too expensive.
>
> I've lost track what has been officially announced, but in one of the
> future years, the 1:1:1 requirement has been dropped as there was no
> suitable venue in one of the areas.
>
[MB] I think it's next year that is the exception as we will be in both
Vancouver and Atlanta - although, I would think the West Coast and East
Coast locations ensures that a bit more of the travel burden is shared. I
think what some folks miss is that West Coast meetings in NA are almost as
far away as Western Europe for folks in the Eastern US, so it's really not
at all reasonable to assume that folks in the US have an easier travel
burden only if the meetings are NA. And, you ought to consider that when the
meetings are in the US, the majority of us travel significantly further to
get to meetings than folks in Europe do to get to meetings in Europe.  [/MB]

[MB] So, it's really silly for folks to be assuming that some of us want all
meetings in NA because it's just so much easier and cheaper for us.[/MB]



> Henk
>
> --
>
> --
> Henk Uijterwaal   Email: henk(at)uijterwaal.nl
>  http://www.uijterwaal.nl
>  Phone: +31.6.55861746
>
> --
>
> There appears to have been a collective retreat from reality that day.
> (John Glanfield, on an engineering project)
> ___
> 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: https

[Melinda Shore]

On 8/26/11 5:43 AM, Donald Eastlake wrote:

The mail archives (and the minutes of the physical meetings) are the
official record of the Working Groups, IETF, etc. Those archives
should be available with a reasonably high level of integrity and
authenticity.


I'm not fully sold, but either way it seems to me that a technology
with such a very, very high error rate in deployment probably needs
some reconsideration.

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

RE: Routing at the Edges of the Internet

[Worley, Dale R (Dale)]

> From: Adam Novak [interf...@gmail.com]
> 
> "Say I wanted to send data to my friend in the flat next to mine. It is
> idiotic that nowadays, I would use the bottleneck subscriber line to
> my upstream ISP and my crippled upload speed and push it all the way
> across their infrastructure to my neighbors ISP and back to the Wifi
> router in reach of mine."

This is a valid point, but it's also rather rare that one wants to
send large amounts of data directly to a friend in a neighboring flat
but one has not manually adjusting the local routing to take that into
account.

> If each home or mobile device was essentially [its] own autonomous
> system, what would this do to routing table size? To ASN space
> utilization?

There must be at least a few hundred million mobile phones with data
capability, and a similar number of homes and small businesses with
WiFi systems.  So we can estimate that a large fraction of a billion
entries would be added to the routing tables.  How would that work?

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

Re: Gen-ART review of draft-ietf-krb-wg-otp-preauth-18

[Simon Josefsson]

 writes:

> Some form of identifier will be required for the otp-algID in the
> PA-OTP-CHALLENGE and the PA-OTP-REQUEST and from what I remember about
> when this was first discussed, it was agreed that it would make sense
> to use the registry of identifiers already being established for PSKC
> rather than produce a duplicate one.  My assumption was that a
> registry would be required to ensure that the URIs were unique.
>

I think a separate registry is needed, RFC 6030 requires several things
from a profile that shouldn't be required in order to support Kerberos
OTP.  See below.

/Simon

12.4.  PSKC Algorithm Profile Registry

   IANA has created a registry for PSKC algorithm profiles in accordance
   with the principles set out in RFC 5226 [RFC5226].

   As part of this registry, IANA maintains the following information:

   Common Name:  The name by which the PSKC algorithm profile is
  generally referred.

   Class:  The type of PSKC algorithm profile registry entry being
  created, such as encryption, Message Authentication Code (MAC),
  One-Time Password (OTP), Digest.

   URI:  The URI to be used to identify the profile.

   Identifier Definition:  IANA will add a pointer to the specification
  containing information about the PSKC algorithm profile
  registration.

   Algorithm Definition:  A reference to the stable document in which
  the algorithm being used with the PSKC is defined.

   Registrant Contact:  Contact information about the party submitting
  the registration request.

   Deprecated:  TRUE if this entry has been deprecated based on expert
  approval and SHOULD not be used in any new implementations.
  Otherwise, FALSE.

   PSKC Profiling:  Information about PSKC XML elements and attributes
  being used (or not) with this specific profile of PSKC.

   PSKC algorithm profile identifier registrations are to be subject to
   Specification Required as per RFC 5226 [RFC5226].  Updates can be
   provided based on expert approval only.  Based on expert approval, it
   is possible to mark entries as "deprecated".  A designated expert
   will be appointed by the IESG.

   IANA has added two initial values to the registry based on the
   algorithm profiles described in Section 10.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Routing at the Edges of the Internet

[Scott Brim]

On Fri, Aug 26, 2011 at 11:04, Worley, Dale R (Dale)  wrote:
> There must be at least a few hundred million mobile phones with data
> capability, and a similar number of homes and small businesses with
> WiFi systems.  So we can estimate that a large fraction of a billion
> entries would be added to the routing tables.  How would that work?

You do it in the endpoint.  The original poster should look at all the
work already being done in IETF WGs (and elsewhere), e.g. 6man and
mif, intarea and tsvwg.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Gen-ART review of draft-ietf-krb-wg-otp-preauth-18

[david.black]

> I believe that the WG consensus here was that this security issue only 
> applies if the identity of the
> KDC has not been verified.
> 
> How about the following updated version of the paragraph?
> 
>Therefore, unless the identity of the KDC has been verified,
>anonymous PKINIT SHALL NOT be used with OTP
>algorithms that require the OTP value to be sent to the KDC.  In
>addition, the security considerations should be carefully considered
>before anonymous PKINIT is used with other algorithms such as those with 
> short OTP
>values.

That works for me, as the use of "SHALL NOT" is clear and explicit.

Thanks,
--David

> -Original Message-
> From: Richards, Gareth
> Sent: Friday, August 26, 2011 6:56 AM
> To: hartmans-i...@mit.edu; Black, David
> Cc: gen-...@ietf.org; ietf@ietf.org; ietf-krb...@lists.anl.gov; 
> stephen.farr...@cs.tcd.ie
> Subject: RE: Gen-ART review of draft-ietf-krb-wg-otp-preauth-18
> 
> >
> >
> > > [1] In section 6.1 at the top of p.28, I don't believe that the
> > > use of lower case "recommended" is a strong enough warning about
> > > the danger in using anonymous PKINIT because it exposes the OTP
> > > value:
> >
> > >It is therefore recommended that anonymous PKINIT not be used
> > > with OTP algorithms that require the OTP value to be sent to the
> > > KDC and that careful consideration be made of the security
> > > implications before it is used with other algorithms such as those
> > > with short OTP values.
> >
> > > At a minimum, that warning should be in upper-case:
> >
> > >It is therefore RECOMMENDED that anonymous PKINIT not be used
> > > with OTP algorithms that require the OTP value to be sent to the
> > > KDC. In addition, the security implications should be carefully
> > > considered before anonymous PKINIT is used with other algorithms
> > > such as those with short OTP values.
> >
> > > Beyond that, the security issue in the first sentence may be
> > > severe enough to justify a prohibition, so the following would
> > > also be acceptable:
> >
> > >Therefore anonymous PKINIT SHALL NOT be used with OTP
> > > algorithms that require the OTP value to be sent to the KDC. In
> > > addition, the security implications should be carefully
> > considered
> > > before anonymous PKINIT is used with other algorithms such as
> > > those with short OTP values.
> >
> > I definitely agree that we should use RFC 2119 language.
> > Note that WG participants have questioned this text in last call for
> > other reasons.
> > Many implementations use anonymous pkinit in a mode where the KDC's
> > certificate is verified--that is the client is anonymous but the KDC is
> > identified through a PKI.
> > WG participants believe (and I agree) that the security concern does
> > not
> > apply at all in this case.
> > So, the text needs reworking.
> >
> 
> I believe that the WG consensus here was that this security issue only 
> applies if the identity of the
> KDC has not been verified.
> 
> How about the following updated version of the paragraph?
> 
>Therefore, unless the identity of the KDC has been verified,
>anonymous PKINIT SHALL NOT be used with OTP
>algorithms that require the OTP value to be sent to the KDC.  In
>addition, the security considerations should be carefully considered
>before anonymous PKINIT is used with other algorithms such as those with 
> short OTP
>values.
> 
> 
> --Gareth
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: [Ietf-krb-wg] Gen-ART review of draft-ietf-krb-wg-otp-preauth-18

[david.black]

> Resynchronization in the algorithms I am familiar with involves the server 
> resetting its OTP search
> window and the system in the ID allows the client to send an additional value 
> to help the server do
> this.  This is just as described in RFC4226.
> 
> How about the following clarification text:
> 
> Methods to recover from this type of situation are OTP algorithm specific but 
> may involve the client
> sending a sequence of OTP
> values to allow the server to further validate the correct position in its 
> search window  (see section
> 7.4 of [RFC4226] for an example).

That new text is fine.  My primary concern with the existing text is that the 
server has to do
something like this for all the cases except when the clock in a clock-based 
token is slightly
slow, but the existing text doesn't indicate that such server action may be 
needed.  The proposed
new text does so, and the reference to section 7.4 of RFC 4226 is a good 
addition that makes the
point clear.

Thanks,
--David

> -Original Message-
> From: Richards, Gareth
> Sent: Friday, August 26, 2011 10:45 AM
> To: h...@jpl.nasa.gov
> Cc: Black, David; ietf@ietf.org; hartmans-i...@mit.edu; 
> ietf-krb...@lists.anl.gov
> Subject: RE: [Ietf-krb-wg] Gen-ART review of draft-ietf-krb-wg-otp-preauth-18
> 
> >
> > > In section 2.4, the following sentence is potentially confusing:
> > >
> > >   For example,
> > >   event-based tokens may drift since the counter on the token is
> > >   incremented every time the token is used but the counter on the
> > >   server is only incremented on an authentication.  Similarly, the
> > >   clocks on time-based tokens may drift.
> > >
> > > The confusion arises because the resync mechanism described in that 
> > > section causes
> > > the client to use the next token value.  By itself, that won't help when 
> > > an event based
> > > has gotten ahead of the server; using the next value only puts the token 
> > > further ahead.
> > > Similarly, by itself, this mechanism does not help if the token clock has 
> > > drifted ahead
> > > of the server clock, but does help if the token clock has drifted behind. 
> > >  A little more
> > > explanation of what the server can do to take advantage of this mechanism 
> > > (e.g., how to
> > > deal with an event-based token that is ahead of the server) would reduce 
> > > the confusion.
> >
> > Possibly there is something in RFC4226, section 7.4 which could be
> > referenced or re-used?  It seems to assume that the server itself knows
> > the token seed, which may not be a valid assumption, so perhaps not.
> 
> Resynchronization in the algorithms I am familiar with involves the server 
> resetting its OTP search
> window and the system in the ID allows the client to send an additional value 
> to help the server do
> this.  This is just as described in RFC4226.
> 
> How about the following clarification text:
> 
> Methods to recover from this type of situation are OTP algorithm specific but 
> may involve the client
> sending a sequence of OTP
> values to allow the server to further validate the correct position in its 
> search window  (see section
> 7.4 of [RFC4226] for an example).
> 
> --Gareth
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [Ietf-krb-wg] Gen-ART review of draft-ietf-krb-wg-otp-preauth-18

[Henry B. Hotz]

On Aug 24, 2011, at 5:45 PM, david.bl...@emc.com wrote:

> In section 2.4, the following sentence is potentially confusing:
> 
>   For example,
>   event-based tokens may drift since the counter on the token is
>   incremented every time the token is used but the counter on the
>   server is only incremented on an authentication.  Similarly, the
>   clocks on time-based tokens may drift.
> 
> The confusion arises because the resync mechanism described in that section 
> causes
> the client to use the next token value.  By itself, that won't help when an 
> event based
> has gotten ahead of the server; using the next value only puts the token 
> further ahead.
> Similarly, by itself, this mechanism does not help if the token clock has 
> drifted ahead
> of the server clock, but does help if the token clock has drifted behind.  A 
> little more
> explanation of what the server can do to take advantage of this mechanism 
> (e.g., how to
> deal with an event-based token that is ahead of the server) would reduce the 
> confusion.

Possibly there is something in RFC4226, section 7.4 which could be referenced 
or re-used?  It seems to assume that the server itself knows the token seed, 
which may not be a valid assumption, so perhaps not.
--
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
henry.b.h...@jpl.nasa.gov, or hbh...@oxy.edu



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

RE: Gen-ART review of draft-ietf-krb-wg-otp-preauth-18

[gareth.richards]

>
>
> > [1] In section 6.1 at the top of p.28, I don't believe that the
> > use of lower case "recommended" is a strong enough warning about
> > the danger in using anonymous PKINIT because it exposes the OTP
> > value:
>
> >It is therefore recommended that anonymous PKINIT not be used
> > with OTP algorithms that require the OTP value to be sent to the
> > KDC and that careful consideration be made of the security
> > implications before it is used with other algorithms such as those
> > with short OTP values.
>
> > At a minimum, that warning should be in upper-case:
>
> >It is therefore RECOMMENDED that anonymous PKINIT not be used
> > with OTP algorithms that require the OTP value to be sent to the
> > KDC. In addition, the security implications should be carefully
> > considered before anonymous PKINIT is used with other algorithms
> > such as those with short OTP values.
>
> > Beyond that, the security issue in the first sentence may be
> > severe enough to justify a prohibition, so the following would
> > also be acceptable:
>
> >Therefore anonymous PKINIT SHALL NOT be used with OTP
> > algorithms that require the OTP value to be sent to the KDC. In
> > addition, the security implications should be carefully
> considered
> > before anonymous PKINIT is used with other algorithms such as
> > those with short OTP values.
>
> I definitely agree that we should use RFC 2119 language.
> Note that WG participants have questioned this text in last call for
> other reasons.
> Many implementations use anonymous pkinit in a mode where the KDC's
> certificate is verified--that is the client is anonymous but the KDC is
> identified through a PKI.
> WG participants believe (and I agree) that the security concern does
> not
> apply at all in this case.
> So, the text needs reworking.
>

I believe that the WG consensus here was that this security issue only applies 
if the identity of the KDC has not been verified.

How about the following updated version of the paragraph?

   Therefore, unless the identity of the KDC has been verified,
   anonymous PKINIT SHALL NOT be used with OTP
   algorithms that require the OTP value to be sent to the KDC.  In
   addition, the security considerations should be carefully considered
   before anonymous PKINIT is used with other algorithms such as those with 
short OTP
   values.


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

RE: [Ietf-krb-wg] Gen-ART review of draft-ietf-krb-wg-otp-preauth-18

[gareth.richards]

>
> > In section 2.4, the following sentence is potentially confusing:
> >
> >   For example,
> >   event-based tokens may drift since the counter on the token is
> >   incremented every time the token is used but the counter on the
> >   server is only incremented on an authentication.  Similarly, the
> >   clocks on time-based tokens may drift.
> >
> > The confusion arises because the resync mechanism described in that
> section causes
> > the client to use the next token value.  By itself, that won't help
> when an event based
> > has gotten ahead of the server; using the next value only puts the
> token further ahead.
> > Similarly, by itself, this mechanism does not help if the token clock
> has drifted ahead
> > of the server clock, but does help if the token clock has drifted
> behind.  A little more
> > explanation of what the server can do to take advantage of this
> mechanism (e.g., how to
> > deal with an event-based token that is ahead of the server) would
> reduce the confusion.
>
> Possibly there is something in RFC4226, section 7.4 which could be
> referenced or re-used?  It seems to assume that the server itself knows
> the token seed, which may not be a valid assumption, so perhaps not.

Resynchronization in the algorithms I am familiar with involves the server 
resetting its OTP search window and the system in the ID allows the client to 
send an additional value to help the server do this.  This is just as described 
in RFC4226.

How about the following clarification text:

Methods to recover from this type of situation are OTP algorithm specific but 
may involve the client sending a sequence of OTP
values to allow the server to further validate the correct position in its 
search window  (see section 7.4 of [RFC4226] for an example).

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

RE: Gen-ART review of draft-ietf-krb-wg-otp-preauth-18

[gareth.richards]

> > Why should we require that alg-ids be registered URIs?
>
> That's not my concern - the existing first paragraph of the IANA
> considerations section in the draft requires IANA registration (or at
> least tries to) by pointing to the PSKC registry.  My concern is that
> if this is going to be done, it needs to be done right (duh!), and the
> current text is insufficient. Please take the issue of whether to use
> IANA for this purpose up with Gareth and the WG.
>
> > I have no problem with the IETF registering its algorithms there, or
> us
> > encouraging people to register them there, but it's a URI. What
> purpose
> > is served by forcing registration?
>
> Hmm - more than one URI for the same algorithm might cause
> interoperability problems.
>

Some form of identifier will be required for the otp-algID in the 
PA-OTP-CHALLENGE and the PA-OTP-REQUEST and from what I remember about when 
this was first discussed, it was agreed that it would make sense to use the 
registry of identifiers already being established for PSKC rather than produce 
a duplicate one.  My assumption was that a registry would be required to ensure 
that the URIs were unique.

--Gareth



>
> > -Original Message-
> > From: Sam Hartman [mailto:hartmans-i...@mit.edu]
> > Sent: Wednesday, August 24, 2011 10:04 PM
> > To: Black, David
> > Cc: Richards, Gareth; gen-...@ietf.org; ietf@ietf.org; ietf-krb-
> w...@lists.anl.gov; hartmans-
> > i...@mit.edu; stephen.farr...@cs.tcd.ie
> > Subject: Re: Gen-ART review of draft-ietf-krb-wg-otp-preauth-18
> >
> > >writes:
> >
> >
> > > [1] In section 6.1 at the top of p.28, I don't believe that the
> > > use of lower case "recommended" is a strong enough warning
> about
> > > the danger in using anonymous PKINIT because it exposes the OTP
> > > value:
> >
> > >It is therefore recommended that anonymous PKINIT not be
> used
> > > with OTP algorithms that require the OTP value to be sent to
> the
> > > KDC and that careful consideration be made of the security
> > > implications before it is used with other algorithms such as
> those
> > > with short OTP values.
> >
> > > At a minimum, that warning should be in upper-case:
> >
> > >It is therefore RECOMMENDED that anonymous PKINIT not be
> used
> > > with OTP algorithms that require the OTP value to be sent to
> the
> > > KDC. In addition, the security implications should be carefully
> > > considered before anonymous PKINIT is used with other
> algorithms
> > > such as those with short OTP values.
> >
> > > Beyond that, the security issue in the first sentence may be
> > > severe enough to justify a prohibition, so the following would
> > > also be acceptable:
> >
> > >Therefore anonymous PKINIT SHALL NOT be used with OTP
> > > algorithms that require the OTP value to be sent to the KDC. In
> > > addition, the security implications should be carefully
> considered
> > > before anonymous PKINIT is used with other algorithms such as
> > > those with short OTP values.
> >
> > I definitely agree that we should use RFC 2119 language.
> > Note that WG participants have questioned this text in last call for
> > other reasons.
> > Many implementations use anonymous pkinit in a mode where the KDC's
> > certificate is verified--that is the client is anonymous but the KDC
> is
> > identified through a PKI.
> > WG participants believe (and I agree) that the security concern does
> not
> > apply at all in this case.
> > So, the text needs reworking.
> >
> > > [2] In section 5, the first paragraph in the IANA
> considerations
> > > is unclear, and following its reference to section 4.1, I don't
> > > see any clarifying text there either.  I think Sections 4.1 and
> > > 4.2 need to say that the value of otp-algID is a URI obtained
> from
> > > the PSKC Algorithm URI Registry, and the first paragraph in
> > > section 5 should say that URIs for otp-algID are to be
> registered
> > > in that registry, see RFC 6030.
> >
> > Why should we require that alg-ids be registered URIs?  I.E. what is
> > wrong with me using
> > http://algorithms.painless-security.com/otp/best-thing-since-
> unsliced-bread
> > (or a tag URI if you like) for my OTP algorithm?
> > I have no problem with the IETF registering its algorithms there, or
> us
> > encouraging people to register them them, but it's a URI. What
> purpose
> > is served by forcing registration?

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

RE: Gen-ART review of draft-ietf-krb-wg-otp-preauth-18

[gareth.richards]

Could we add a URI list to draft-lha-krb-wg-some-numbers-to-iana?

>
> > Some form of identifier will be required for the otp-algID in the
> > PA-OTP-CHALLENGE and the PA-OTP-REQUEST and from what I remember
> about
> > when this was first discussed, it was agreed that it would make sense
> > to use the registry of identifiers already being established for PSKC
> > rather than produce a duplicate one.  My assumption was that a
> > registry would be required to ensure that the URIs were unique.
> >
>
> I think a separate registry is needed, RFC 6030 requires several things
> from a profile that shouldn't be required in order to support Kerberos
> OTP.  See below.
>
> /Simon
>
> 12.4.  PSKC Algorithm Profile Registry
>
>IANA has created a registry for PSKC algorithm profiles in
> accordance
>with the principles set out in RFC 5226 [RFC5226].
>
>As part of this registry, IANA maintains the following information:
>
>Common Name:  The name by which the PSKC algorithm profile is
>   generally referred.
>
>Class:  The type of PSKC algorithm profile registry entry being
>   created, such as encryption, Message Authentication Code (MAC),
>   One-Time Password (OTP), Digest.
>
>URI:  The URI to be used to identify the profile.
>
>Identifier Definition:  IANA will add a pointer to the specification
>   containing information about the PSKC algorithm profile
>   registration.
>
>Algorithm Definition:  A reference to the stable document in which
>   the algorithm being used with the PSKC is defined.
>
>Registrant Contact:  Contact information about the party submitting
>   the registration request.
>
>Deprecated:  TRUE if this entry has been deprecated based on expert
>   approval and SHOULD not be used in any new implementations.
>   Otherwise, FALSE.
>
>PSKC Profiling:  Information about PSKC XML elements and attributes
>   being used (or not) with this specific profile of PSKC.
>
>PSKC algorithm profile identifier registrations are to be subject to
>Specification Required as per RFC 5226 [RFC5226].  Updates can be
>provided based on expert approval only.  Based on expert approval,
> it
>is possible to mark entries as "deprecated".  A designated expert
>will be appointed by the IESG.
>
>IANA has added two initial values to the registry based on the
>algorithm profiles described in Section 10.

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

Re: https

[ned+ietf]

> --On Friday, August 26, 2011 09:43 -0400 Donald Eastlake
>  wrote:

> >> Yup, but why are we using https at all?  Who decided, and
> >> please would they undecide?  Unexpired certificates can be
> >> circumvented, but all too often, the https parts of the web
> >> site just do not work and, more importantly, I think it wrong
> >> to use industrial grade security where none is called for.
> >
> > The mail archives (and the minutes of the physical meetings)
> > are the official record of the Working Groups, IETF, etc.
> > Those archives should be available with a reasonably high
> > level of integrity and authenticity.

> Don,

> If that is the goal, wouldn't we be lots better off just
> digitally signing those things, just as we are gradually
> starting to create signatures for I-Ds, etc.?  Verifying that
> one is talking to the right server and that the content is not
> tampered with in transit is all well and good, but it doesn't
> protect against compromised documents or a compromised server at
> all.

+1. If you want signatures, do them properly. Don't pretend a transfer
protection mechanism covering exactly one hop provides real object security,
because it doesn't.

And as for the "encrypt so the really secret stuff doesn't stand out" argument,
that's fine as long as it doesn't cause inconvenience to anyone. That's clearly
not the case here. And I'm sorry, the "mistakes were made" notion doesn't
really fly: Certificates aren't a "set it and forget it" thing, so if you
haven't noted expiration dates on someone's to-do list so they can be updated
before expiration, you're not doing it right.

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

Re: https

[t.petch]

- Original Message -
From: "Joel jaeggli" 
To: "t.petch" 
Cc: "IETF Discussion" 
Sent: Friday, August 26, 2011 4:44 PM
Subject: Re: https


> It doesn't...
>
> http://www.ietf.org/mail-archive/web/v6ops/current/maillist.html

Try the source of
http://www.ietf.org/list/discussion.html
where https: outumbers http: or
http://www.ietf.org/list/nonwg.html
where I run out of numbers before I run out of https:

Tom Petch


>
> On 8/26/11 00:18 , t.petch wrote:
> > Why does the IETF website consider it necessary to use TLS to access the
mailing
> > list archives, when they all appeared without it, or any other security, in
the
> > first place?
> >
> > Besides all the usual hassle of TLS, today the certificate is reported by IE
as
> > expired, which sort of sums it up.
> >
> > Tom Petch
> >
> > ___
> > 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: Routing at the Edges of the Internet

[David Morris]

On Fri, 26 Aug 2011, Worley, Dale R (Dale) wrote:

> > From: Adam Novak [interf...@gmail.com]
> > 
> > "Say I wanted to send data to my friend in the flat next to mine. It is
> > idiotic that nowadays, I would use the bottleneck subscriber line to
> > my upstream ISP and my crippled upload speed and push it all the way
> > across their infrastructure to my neighbors ISP and back to the Wifi
> > router in reach of mine."
> 
> This is a valid point, but it's also rather rare that one wants to
> send large amounts of data directly to a friend in a neighboring flat
> but one has not manually adjusting the local routing to take that into
> account.
> 
> > If each home or mobile device was essentially [its] own autonomous
> > system, what would this do to routing table size? To ASN space
> > utilization?
> 
> There must be at least a few hundred million mobile phones with data
> capability, and a similar number of homes and small businesses with
> WiFi systems.  So we can estimate that a large fraction of a billion
> entries would be added to the routing tables.  How would that work?

I don't see this as a routing difficulty since the updated tables would be
highly local to the edge routers which would only need to know about
the more precise route between peers.

BUT I see enormous issues in terms of providing the capability in a secure
form that can be successfully enabled by the average end user. Also,
this is more than a routing issue since most file sharing involves
an itermediary with both edge devices connecting to a remote server. Not
only do the edge routers need to be configured for secure edge routing,
but the systems need to have applications which would deliver data
directly.

I think that folks with a requirement for local sharing will figure out
a local solution, often sharing an AP and uplink. If there is a business
case here, it wouldn't be hard for an enterprising AP vendor to offer
APs which create a shared network, perhaps even providing the 'server'
component. Could also be a device which has two radios and hence can
connect to two (or more) in range networks.

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

Re: https

[Adam Novak]

On Fri, Aug 26, 2011 at 11:14 AM,   wrote:
>
> +1. If you want signatures, do them properly. Don't pretend a transfer
> protection mechanism covering exactly one hop provides real object security,
> because it doesn't.
>

It ensures that what you're getting is the same as what the IETF has
on file, and (assuming you trust the IETF's archive integrity, which
is a separate problem) what everyone else on the list received. It
seems to me it's more important to know that than to know that stuff
sent to the list actually came from who it claims to come from. Does
it really matter if a proposed standard wasn't really designed by who
the archive says it was designed by?

> And as for the "encrypt so the really secret stuff doesn't stand out" 
> argument,
> that's fine as long as it doesn't cause inconvenience to anyone. That's 
> clearly
> not the case here. And I'm sorry, the "mistakes were made" notion doesn't
> really fly: Certificates aren't a "set it and forget it" thing, so if you
> haven't noted expiration dates on someone's to-do list so they can be updated
> before expiration, you're not doing it right.

Yeah, it seems like the IETF would be on top of certificate
expiration, having invented it. But I think having the encryption is a
very good thing. Some government interests would be happy to keep
information about some aspects of IETF business away from their
citizenry, and have the resources to launch a MITM attack. (Of course,
those governments may also have the resources to sign a fake
certificate, but that is, again, a separate problem.)

Once the certificate expiration business is fixed, it should be fairly
simple to make sure it's kept up to date so that this sort of thing
doesn't happen again.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Routing at the Edges of the Internet

[Keith Moore]

On Aug 26, 2011, at 12:03 PM, Scott Brim wrote:

> On Fri, Aug 26, 2011 at 11:04, Worley, Dale R (Dale)  
> wrote:
>> There must be at least a few hundred million mobile phones with data
>> capability, and a similar number of homes and small businesses with
>> WiFi systems.  So we can estimate that a large fraction of a billion
>> entries would be added to the routing tables.  How would that work?
> 
> You do it in the endpoint.  The original poster should look at all the
> work already being done in IETF WGs (and elsewhere), e.g. 6man and
> mif, intarea and tsvwg

In other words, it's not a solved problem, and though there's wide recognition 
that the problem exists, nobody really has found a good solution.  

(Though mtcp strikes me as having broader applicability than most.)

Keith

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

Re: https

[Adam Novak]

On Fri, Aug 26, 2011 at 1:13 PM, Hector Santos  wrote:
> Makes you wonder. Why is the concept of expiration required?  Did the IETF
> expire, die?  Did its value as an Organization go down and only valid on a
> year to year basis?

As I understand it, expiration is supposed to solve the problem of
someone getting their hands on your old certificates and impersonating
you. In order to impersonate you, not only do they have to get into
your system, they have to have done it in the last year or so.

It also keeps certificates for domains from outliving domain
registrations for too long. If you don't have the domain when you go
to renew the certificate, the CA shouldn't renew it.

I guess it also keeps revocation lists short. You only have to
remember that a certain certificate was compromised until it expires,
instead of forever.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: https

[ned+ietf]

> On Fri, Aug 26, 2011 at 11:14 AM,   wrote:
> >
> > +1. If you want signatures, do them properly. Don't pretend a transfer
> > protection mechanism covering exactly one hop provides real object security,
> > because it doesn't.
> >

> It ensures that what you're getting is the same as what the IETF has
> on file,

No, it really doesn't do that. There can be, and usually are, a lot of steps
involves besides the one https hop.

> and (assuming you trust the IETF's archive integrity, which
> is a separate problem)

On the contrary, it's the same problem. You're just pretending that solving an
insignificant subset of that problem is useful. It isn't.

> what everyone else on the list received.

This, OTOH, *is* a separate problem, one that isn't addressed in any way by
https on archive archive access. Nor does a signed archive address this issue.

Nonrepudiation of delivery is in fact a very difficult problem to solve - the
algorithms I'm aware of for it either involve a TTP or are exceptionaly ugly -
and the fact that the architecture of our email services isn't designed for it
doesn't exactly help. (In case you care, it's the nontransactional nature of
POP and IMAP that gets in the way of doing nonrepudiation of delivery at the
email protocol level.)

We're very lucky that we don't operate in a regime where this is actually a
requirement. (And such regimes do exist, although the solutions they actually
use tend to be hacks.)

> It
> seems to me it's more important to know that than to know that stuff
> sent to the list actually came from who it claims to come from. Does
> it really matter if a proposed standard wasn't really designed by who
> the archive says it was designed by?

And now you're talking about yet a third problem - nonrepudiation of
submission. It's completely doable, but only by significantly increasing the
barriers to participation by requiring signed messages. I don't believe the
benefits come even close to the costs.

> > And as for the "encrypt so the really secret stuff doesn't stand out" 
> > argument,
> > that's fine as long as it doesn't cause inconvenience to anyone. That's 
> > clearly
> > not the case here. And I'm sorry, the "mistakes were made" notion doesn't
> > really fly: Certificates aren't a "set it and forget it" thing, so if you
> > haven't noted expiration dates on someone's to-do list so they can be 
> > updated
> > before expiration, you're not doing it right.

> Yeah, it seems like the IETF would be on top of certificate
> expiration, having invented it. But I think having the encryption is a
> very good thing. Some government interests would be happy to keep
> information about some aspects of IETF business away from their
> citizenry, and have the resources to launch a MITM attack. (Of course,
> those governments may also have the resources to sign a fake
> certificate, but that is, again, a separate problem.)

I'm sorry, but the notion that the present use of https provides any
sort of protection against this sort of thing is just silly. The simple
facts that the archives are also available via regular http and that
there is no stated policy about the availability of archives via https
means the present setup is completely vulnerable to downgrade attacks.

Again, if you really care about this sort of stuff, the archives need to be
timestamped and signed. 

> Once the certificate expiration business is fixed, it should be fairly
> simple to make sure it's kept up to date so that this sort of thing
> doesn't happen again.

10+ years of experience with multiple certificates having multiple failures
says this is, at best, a crapshoot.

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

Re: https

[Adam Novak]

On Fri, Aug 26, 2011 at 1:12 PM, Ned Freed  wrote:
>> It ensures that what you're getting is the same as what the IETF has
>> on file,
>
> No, it really doesn't do that. There can be, and usually are, a lot of steps
> involves besides the one https hop.
>

What other steps are there? HTTPS prevents what the web server sends
from being tampered with on its way to the browser. If the web server
storing the archives is itself trusted, this would seem to be all that
is needed.

Obviously HTTPS is not a solution to long-term preservation of the
integrity of the mailing list database itself. What protections, if
any, are currently in place to protect the archive from tampering on
IETF's end? Perhaps the whole thing should be signed by someone
official at regular intervals?

>
> I'm sorry, but the notion that the present use of https provides any
> sort of protection against this sort of thing is just silly. The simple
> facts that the archives are also available via regular http and that
> there is no stated policy about the availability of archives via https
> means the present setup is completely vulnerable to downgrade attacks.
>

A downgrade attack is certainly possible. But there are measures
available to ensure that, once an HTTPS connection has been
established once, future HTTP sessions will be rejected client-side.
And creating an official policy and going HTTPS-only could be done
relatively easily. If HTTPS everywhere is where the Web should be
going, then IETF should be leading the charge.

> 10+ years of experience with multiple certificates having multiple failures
> says this is, at best, a crapshoot.
>

For what reasons? Is it that things scheduled every year or every ten
years are easy for admins to miss? Or is it that it's hard to stay on
top of certificate revocations when they occur?
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: https

[Keith Moore]

On Aug 26, 2011, at 3:22 PM, Adam Novak wrote:

> On Fri, Aug 26, 2011 at 1:12 PM, Ned Freed  wrote:
>>> It ensures that what you're getting is the same as what the IETF has
>>> on file,
>> 
>> No, it really doesn't do that. There can be, and usually are, a lot of steps
>> involves besides the one https hop.
>> 
> 
> What other steps are there? HTTPS prevents what the web server sends
> from being tampered with on its way to the browser. If the web server
> storing the archives is itself trusted, this would seem to be all that
> is needed.

There can be web proxies on the front end (if the client is configured to use 
them) and the web server itself can be implemented in such a way as to retrieve 
content from other servers (via a number of means, e.g. NFS, CIFS, web services 
calls, sql calls).  Though I don't know whether the latter is the case for 
content served from IETF's servers.

Keith

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

Re: https

[Melinda Shore]

On 08/26/2011 11:22 AM, Adam Novak wrote:

For what reasons? Is it that things scheduled every year or every ten
years are easy for admins to miss? Or is it that it's hard to stay on
top of certificate revocations when they occur?


Firewall researchers have found at least one error of some sort in
99% (yes, really) of the firewall rulesets they've examined.  If
I had to guess how many PKI deployments have problems, I'd put it in
the same ballpark.  They seem to fall into several broad categories
1) naming (including SANs), 2) expiration, 3) faulty trust
establishment.  These may or may not be fixable, but what doesn't
appear to be fixable is that too people don't really understand what 
certificates represent, the difference between a certificate and

a key, or what it means to TLS-protect traffic.

Listen to Ned, Adam.  He's right.

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

Re: https

[Eric Burger]

Two thoughts.

On the one hand, Ned is absolutely correct: the thing we want to make 
absolutely sure of is the integrity of the object. The way of doing that is 
making sure the object itself can prove its integrity.  In the messaging world, 
we do this with S/MIME.  The use of TLS for SMTP or IMAP does not convey any 
integrity assertions for the object.  Note this object should be signed by me 
when you receive it, by the way.

On the other hand, while TLS is not at all sufficient for the integrity of the 
object, it is necessary to protect the individual accessing the object.  There 
are a number of countries where asking for the RFCs relating to privacy, 
security, and threats to such too many times could get you arrested.  Likewise, 
the presumption is the object might be signed, but it would be insane and 
useless to encrypt the object.  However, there are many, many times one would 
want the object encrypted, even if only to compress it.

Given that, the question should not be, "Why are we using TLS if the object is 
not private?," but "What are we not using secure connections for all IETF 
access, over any modality?"

One of the answers seems to be, "Because it sucks."  That is the sentiment of 
the message below.

So we are eating our dog food, and we are getting indigestion.  Sounds like an 
opportunity to fix it!

--
- Eric

On Aug 26, 2011, at 3:32 PM, Melinda Shore wrote:

> On 08/26/2011 11:22 AM, Adam Novak wrote:
>> For what reasons? Is it that things scheduled every year or every ten
>> years are easy for admins to miss? Or is it that it's hard to stay on
>> top of certificate revocations when they occur?
> 
> Firewall researchers have found at least one error of some sort in
> 99% (yes, really) of the firewall rulesets they've examined.  If
> I had to guess how many PKI deployments have problems, I'd put it in
> the same ballpark.  They seem to fall into several broad categories
> 1) naming (including SANs), 2) expiration, 3) faulty trust
> establishment.  These may or may not be fixable, but what doesn't
> appear to be fixable is that too people don't really understand what 
> certificates represent, the difference between a certificate and
> a key, or what it means to TLS-protect traffic.
> 
> Listen to Ned, Adam.  He's right.
> 
> Melinda
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf



smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Routing at the Edges of the Internet

[Doug Barton]

On 08/26/2011 10:20, David Morris wrote:
> I don't see this as a routing difficulty since the updated tables would be
> highly local to the edge routers which would only need to know about
> the more precise route between peers.
> 
> BUT I see enormous issues in terms of providing the capability in a secure
> form that can be successfully enabled by the average end user. Also,
> this is more than a routing issue since most file sharing involves
> an itermediary with both edge devices connecting to a remote server. Not
> only do the edge routers need to be configured for secure edge routing,
> but the systems need to have applications which would deliver data
> directly.

I have a related-but-different example of how end nodes being able to
know/discover direct paths to one another could be useful. Imagine a
busy server network with some web servers over here, some sql servers
over there, etc. All of these systems are on the same network, same
switch fabric, and have the same gateway address. In an ideal world I
would like them to be able to know that they can speak directly to one
another without having to go through the gateway (and without my having
to manually inject static routes on the hosts, which of course is both
painful and un-scale'y.


Doug

-- 

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price.  :)  http://SupersetSolutions.com/

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

Re: Routing at the Edges of the Internet

[Adam Novak]

On Fri, Aug 26, 2011 at 3:49 PM, Doug Barton  wrote:
>
> I have a related-but-different example of how end nodes being able to
> know/discover direct paths to one another could be useful. Imagine a
> busy server network with some web servers over here, some sql servers
> over there, etc. All of these systems are on the same network, same
> switch fabric, and have the same gateway address. In an ideal world I
> would like them to be able to know that they can speak directly to one
> another without having to go through the gateway (and without my having
> to manually inject static routes on the hosts, which of course is both
> painful and un-scale'y.

Shouldn't that be covered by the subnet mask? As long as they know
they're on the same subnet (and ARP broadcasts will reach everyone)
they should just ARP for each other and not involve the router at all.

If they are on different IP subnets, but the same Ethernet, then we
can either come up with a new way to do routing, or tell people not to
number things that way. Perhaps a subnet mask or CIDR prefix is not
expressive enough?
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: https

[Doug Barton]

Joel,

I don't know what "It doesn't" is supposed to mean, but visiting
https://www.ietf.org/* today with firefox it is still reporting that the
certificate expired yesterday.

Given the volume of discussion about the topic starting yesterday when
the problem started one could easily make a case for "it's still broken"
being a significant "issue."

cc'ing the address listed as "Report Website Errors" on the home page.


Doug


On 08/26/2011 07:44, Joel jaeggli wrote:
> It doesn't...
> 
> http://www.ietf.org/mail-archive/web/v6ops/current/maillist.html
> 
> On 8/26/11 00:18 , t.petch wrote:
>> Why does the IETF website consider it necessary to use TLS to access the 
>> mailing
>> list archives, when they all appeared without it, or any other security, in 
>> the
>> first place?
>>
>> Besides all the usual hassle of TLS, today the certificate is reported by IE 
>> as
>> expired, which sort of sums it up.
>>
>> Tom Petch
>>
>> ___
>> 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



-- 

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price.  :)  http://SupersetSolutions.com/

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

RE: Routing at the Edges of the Internet

[Worley, Dale R (Dale)]

> From: Doug Barton [do...@dougbarton.us]
> 
> All of these systems are on the same network, same
> switch fabric, and have the same gateway address. In an ideal world I
> would like them to be able to know that they can speak directly to one
> another without having to go through the gateway (and without my having
> to manually inject static routes on the hosts, which of course is both
> painful and un-scale'y.

I'm no expert in this, but isn't this what ICMP Redirect messages are
for?  Aren't routers required to generate them in these cases?

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

Re: Routing at the Edges of the Internet

[Doug Barton]

On 08/26/2011 13:57, Adam Novak wrote:
> On Fri, Aug 26, 2011 at 3:49 PM, Doug Barton  wrote:
>>
>> I have a related-but-different example of how end nodes being able to
>> know/discover direct paths to one another could be useful. Imagine a
>> busy server network with some web servers over here, some sql servers
>> over there, etc. All of these systems are on the same network, same
>> switch fabric, and have the same gateway address. In an ideal world I
>> would like them to be able to know that they can speak directly to one
>> another without having to go through the gateway (and without my having
>> to manually inject static routes on the hosts, which of course is both
>> painful and un-scale'y.
> 
> Shouldn't that be covered by the subnet mask?

Mostly, yes of course, but I'm dramatically simplifying my example for
dramatic effect. :)

> As long as they know
> they're on the same subnet (and ARP broadcasts will reach everyone)
> they should just ARP for each other and not involve the router at all.
> 
> If they are on different IP subnets, but the same Ethernet,

Yes, this is more often the case that I'm dealing with. (Working on
fixing a problem I inherited for a new client, so per your comment below
"don't number that way" may be the right answer.)

Doug


> then we
> can either come up with a new way to do routing, or tell people not to
> number things that way. Perhaps a subnet mask or CIDR prefix is not
> expressive enough?



-- 

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price.  :)  http://SupersetSolutions.com/

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

RE: Routing at the Edges of the Internet

[Michel Py]

> Worley, Dale R wrote:
> I'm no expert in this, but isn't this what ICMP Redirect messages
> are for?  Aren't routers required to generate them in these cases?

Unfortunately, ICMP redirects are often broken. It is a well-known issue
that the introduction of Windows XP SP2 (a while ago) and the Windows
Firewall did that.

The typical setup was a network with multiple subnets/VLANs and a
firewall/NAT/VPN box. The default gateway for the Internet and remote
VPN tunnels was the firewall, the default gateway for other VLANs was
the L3 switch that was doing the inter-VLAN routing. 

In theory, the host would send the traffic for a given destination, if
the traffic was an inside VLAN the firewall would send the redirect to
the host, forward the traffic to the L3 switch, and further traffic
would go directly to the L3 switch as the result of the ICMP redirect.
Before XP SP2 this was straightforward, a "route print" on the host
would indeed show the new route installed by the ICMP redirect.

In practice after XP SP2, the result was that the firewall indeed sent
the redirect to the host but since the host ignored it and kept sending
traffic to the wrong gateway, a large amount of firewall-to-L3switch was
present, effectively clogging the network at times.

Maintaining a correct routing table in hosts has always been the
Achilles' heel of networks with multiple gateways, which is why many
enterprise network operators tend to design a one-gateway solution.

Michel.

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

Re: Routing at the Edges of the Internet

[Brian E Carpenter]

On 2011-08-27 04:03, Scott Brim wrote:
> On Fri, Aug 26, 2011 at 11:04, Worley, Dale R (Dale)  
> wrote:
>> There must be at least a few hundred million mobile phones with data
>> capability, and a similar number of homes and small businesses with
>> WiFi systems.  So we can estimate that a large fraction of a billion
>> entries would be added to the routing tables.  How would that work?
> 
> You do it in the endpoint.  The original poster should look at all the
> work already being done in IETF WGs (and elsewhere), e.g. 6man and
> mif, intarea and tsvwg.

Not to mention shim6, which is already a PS with running code.

Get used to the idea of end systems running with multiple simultaneous
addresses.

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

Re: https

[John C Klensin]

--On Friday, August 26, 2011 16:15 -0400 Eric Burger
 wrote:

> Two thoughts.
> 
> On the one hand, Ned is absolutely correct: the thing we want
> to make absolutely sure of is the integrity of the object. The
> way of doing that is making sure the object itself can prove
> its integrity.  In the messaging world, we do this with
> S/MIME.  The use of TLS for SMTP or IMAP does not convey any
> integrity assertions for the object.  Note this object should
> be signed by me when you receive it, by the way.

And it verifies too... sort of.  Note that the IETF mailing list
machinery tries to prevent it from doing so by appending a
footer to tell everyone who it is (independent of the standard
List-* headers that contain the same information).  Another
separate problem, but definitely falling into the "dogfood...
yum" category.

> On the other hand, while TLS is not at all sufficient for the
> integrity of the object, it is necessary to protect the
> individual accessing the object.  There are a number of
> countries where asking for the RFCs relating to privacy,
> security, and threats to such too many times could get you
> arrested.

Yes, although it isn't entirely clear that TLS actually provides
enough protection in practice.  A sufficiently paranoid
government with those concerns would either force the
connections through proxies that it controlled (see Keith's
note) or would notice connections to IETF servers and "inquire",
through out-of-band means, about what was being retrieved.
There are ways to protect against that risk, but assuming that
unadorned https is sufficient is almost certainly naive.

> Likewise, the presumption is the object might be
> signed, but it would be insane and useless to encrypt the
> object.  However, there are many, many times one would want
> the object encrypted, even if only to compress it.

Sure.  If TLS actually worked for its intended purpose in the
overwhelming number of cases, nothing that Ned or I have said
would argue against using it.  In that regard, the problems are
that it is assumed to solve several problems for which it is
useless and several others, including your example above, for
which its effectiveness is dubious against an attacker with
sufficient non-network resources.

> Given that, the question should not be, "Why are we using TLS
> if the object is not private?," but "What are we not using
> secure connections for all IETF access, over any modality?"
> 
> One of the answers seems to be, "Because it sucks."  That is
> the sentiment of the message below.

> So we are eating our dog food, and we are getting indigestion.
> Sounds like an opportunity to fix it!

I think it is more than that.  If we (and the Secretariat and
IASA) cannot get it together to keep certs up to date, or at
least to get them updated _very_ quickly when someone notices
that they have expired (note that it is now only a few minutes
short of 24 hours since the thing expired), we are sending a
pretty strong message to the community that we don't care and no
one else should either.  Remember that the message browsers pop
up when an invalid or expired certificate is encountered is
totally incomprehensible to a typical luser, offering only
choices of not accessing a site that contains useful information
and that was valid before and accepting the cert, errors and
all.  The more valid sites there are with invalid certificates,
the more we train the user to accept those invalid certificates,
rendering the whole certificate idea (and TLS with it)
pointless.  By choosing to contribute to that problem, the IETF
undermines the utility of TLS for addressing the real issues of
server authentication and client-> server encryption that it was
primarily intended to address.

john

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

Re: Last Call: (IPv6 Support Required for all IP-capable nodes) to Proposed Standard

[Masataka Ohta]

Before requiring IPv6 support, it is necessary to revise obviously
broken parts of IPv6.

For example, ICMPv6 generated agaist multicast packets should be
forbidden or ICMPv6 implosions will occur. It will let ISPs filter
ICMPv6, including but not limited to, those against multicast,
which means PMTUD won't work.

Another example is lack of guaranteed value for payload size.

RFC791 specifies:

The number 576 is selected to allow a reasonable sized data block to
be transmitted in addition to the required header information.  For
example, this size allows a data block of 512 octets plus 64 header
octets to fit in a datagram.  The maximal internet header is 60
octets, and a typical internet header is 20 octets, allowing a
margin for headers of higher level protocols.

and DNS just send 512B messages (520B including UDP header,
which should be a mistake but is safe as no one use IPv4
options).

However, there is no such size specified with IPv6, because
arbitrarily lengthy header options may be inserted. Note that
some header options, such as mobility ones, are inserted by
IP layers without application control.

Thus, applications like DNS can not specify like RFC1035:

   Messages carried by UDP are restricted to 512 bytes (not
   counting the IP or UDP headers).

Masataka Ohta

PS

You have been warned.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: https

[Glen Zorn]

On 8/26/2011 11:14 PM, ned+i...@mauve.mrochek.com wrote:

> +1. If you want signatures, do them properly. Don't pretend a transfer
> protection mechanism covering exactly one hop provides real object security,
> because it doesn't.

I could have sworn that TLS was an e2e mechanism.  Maybe you're using
the term "hop" in a manner unfamiliar to me?

> And as for the "encrypt so the really secret stuff doesn't stand out" 
> argument,
> that's fine as long as it doesn't cause inconvenience to anyone. That's 
> clearly
> not the case here. And I'm sorry, the "mistakes were made" notion doesn't
> really fly: Certificates aren't a "set it and forget it" thing, so if you
> haven't noted expiration dates on someone's to-do list so they can be updated
> before expiration, you're not doing it right.

Isn't "not doing it right" pretty much the definition of "mistake"
(assuming no evil intent)?
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Routing at the Edges of the Internet

[Glen Zorn]

On 8/27/2011 4:08 AM, Doug Barton wrote:

...

>> As long as they know
>> they're on the same subnet (and ARP broadcasts will reach everyone)
>> they should just ARP for each other and not involve the router at all.
>>
>> If they are on different IP subnets, but the same Ethernet,
> 
> Yes, this is more often the case that I'm dealing with. (Working on
> fixing a problem I inherited for a new client, so per your comment below
> "don't number that way" may be the right answer.)

Old joke (but apropos):

Patient: Doctor, it hurts when I do this.
Doctor:  Don't do that.

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