Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC

[joel jaeggli]

On 9/11/13 9:39 PM, Lorenzo Colitti wrote:
> On Thu, Sep 12, 2013 at 6:45 AM, joel jaeggli  > wrote:
> 
> The queue for dicussion of this point is closed. If there needs to be an
> appeal on this point now or in the future, then I'll be happy to help
> someone write it, but I consider that dicussion settled for the purposes
> of a draft that has already been tested for wg acceptance/wglc/ietf-lc
> 
> 
> To clarify - you're talking only about the discussion on whether this
> draft is in scope? Or are you saying that you consider all discussion of
> this document in this IETF last call settled?

The discussion of whether the IETF, or this working group is a suitable
location.

It was my opinion that the working group should revist the document
itself given what I saw in the last call.

joel

Re: [DNSOP] Practical issues deploying DNSSEC into the home.

[Masataka Ohta]

Phillip Hallam-Baker wrote:

> 3) A relying party thus requires a demonstration that is secure against a
> replay attack from one or more trusted parties to be assured that the time
> assertion presented is current but this need not necessarily be the same as
> the source of the signed time assertion itself.

> The real design decision is who you decide you are going to rely on for
> (3). TLS is proof against replay attack due to the exchange of nonces.

How can you get secure time to securely confirm that a certificate
of TLS has not expired?

Use yet another PKI?

Masataka Ohta

Re: Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard

[Douglas Otis]

Recommended text is as follows:

4.6.4.  DNS Lookup Limits

Was:
,--
SPF implementations MUST limit the total number of mechanisms and modifiers 
("terms") that cause any DNS query to 10 during SPF evaluation.  Specifically, 
the "include", "a", "mx", "ptr", and "exists" mechanisms as well as the 
"redirect" modifier count against this collective limit.  The "all", "ip4", and 
"ip6" mechanisms do not count against this limit.  If this number is exceeded 
during a check, a "permerror" MUST be returned.  The "exp" modifier does not 
count against this limit because the DNS lookup to fetch the explanation string 
occurs after the SPF record evaluation has been completed.
'--

Change to:
,---
SPF does not directly limit the number of DNS lookup transactions.  Instead, 
the number of mechanisms and the modifier term "redirect" MUST be limited to no 
more than 10 instances within the evaluation process.  The mechanisms "ip4", 
"ip6", and "all" and the "exp" modifier are excluded from being counted in this 
instance limitation. If this instance limit is exceeded during the evaluation 
process, a "permerror" MUST be returned.
'---

5.  Mechanism Definitions

Was:
,--
Several mechanisms rely on information fetched from the DNS.  For these DNS 
queries, except where noted, if the DNS server returns an error (RCODE other 
than 0 or 3) or the query times out, the mechanism stops and the topmost 
check_host() returns "temperror".  If the server returns "domain does not 
exist" (RCODE 3), then evaluation of the mechanism continues as if the server 
returned no error (RCODE 0) and zero answer records.
‘---

Add:
,---
See the recommended limits on "void lookups" defined in Section 4.6.4. DNS 
Lookup Limits.
‘---

3.4.  Record Size

Was:

,---
Note that when computing the sizes for replies to queries of the TXT format, 
one has to take into account any other TXT records published at the domain 
name.  Similarly, the sizes for replies to all queries related to SPF have to 
be evaluated to fit in a single 512 octet UDP packet.
‘---

Change to:
,---
Note that when computing the sizes for replies to queries of the TXT format, 
one has to take into account any other TXT records published at the domain 
name.  Similarly, the sizes for replies to all queries related to SPF have to 
be evaluated to fit in a single 512 octet DNS Message.
‘---

Add to:
11.5.3.  Macro Expansion
,---
It is not within SPF’s purview whether IPv6 or DNSSEC is being used.  IPv6 
(RFC2460) increased the minimum MTU size to 1280 octets.  DNSSEC is deployed 
with EDNS0 (RFC6891) to avoid TCP fallback.  EDNS0 suggests an MTU increase 
between 1280 and 1410 octets offers a reasonable result starting from a request 
of 4096 octets.  A 1410 MTU offers a 2.4 times payload increase over the 
assumed MTU of 576 octets and is widely supported by Customer Premise 
Equipment.  With increased MTUs being used with DNS over UDP, network 
amplification concerns increase accordingly.

SPF macros can utilize SPF parameters derived from email messages that can 
modulate the names being queried in several ways without publishing additional 
DNS resources.  The SPF macro feature permits malefactors a means to covertly 
orchestrate directed DDoS attacks from an array of compromised systems while 
expending little of their own resources.

Since SPF does not make use of a dedicated resource record type or naming 
convention, this leaves few solutions available to DNS operations in offering a 
means to mitigate possible abuse.  This type of abuse becomes rather pernicious 
when used in conjunction with synthetic domains now popular for tracking users 
without using web cookies.

However, email providers can mitigate this type of abuse by ignoring SPF 
records containing macros.  Very few domains make use of macros, and ignoring 
these records result in neutral handling.  Some large providers have admitted 
they make use of this strategy without experiencing any notable problem.  AOL 
began their support of SPF by saying they would use SPF to construct whitelists 
prior to receipt of email.  Clearly, such whitelisting practices tends to 
preclude benefits derived from macro use.
‘---

Regards,
Douglas Otis

Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC

[Lorenzo Colitti]

On Thu, Sep 12, 2013 at 6:45 AM, joel jaeggli  wrote:

> The queue for dicussion of this point is closed. If there needs to be an
>  appeal on this point now or in the future, then I'll be happy to help
> someone write it, but I consider that dicussion settled for the purposes
> of a draft that has already been tested for wg acceptance/wglc/ietf-lc


To clarify - you're talking only about the discussion on whether this draft
is in scope? Or are you saying that you consider all discussion of this
document in this IETF last call settled?

RE: [CCAMP] Last Call: (Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for the evolving G.709 Optical Transport Networks Contr

[Fatai Zhang]

Hi Adrian,

I would like to propose the following text for the new section and discuss with 
you & WG before I submit a new version.

Further comments are appreciated.


8. Operations, Administration and Maintenance (OAM) Considerations
Regarding OTN OAM configuration, it could be done through either Network 
Management Systems (NMS) or GMPLS control plane as defined in [TDM-OAM]. 
[RFC4783] SHOULD be used for communication of alarm information in GMPLS based 
OTN.
Management Information Base (MIB) may need be extended to read new information 
(e.g, OTN-TDM Generalized Label, OTN-TDM SENDER_TSPEC/ FLOWSPEC) from the OTN 
devices. This is out of scope of this document.
More information about the management aspects for GMPLS based OTN refer to 
Section 5.7 of [OTN-FWK].

===


Best Regards

Fatai

From: Fatai Zhang
Sent: Friday, September 06, 2013 3:33 PM
To: adr...@olddog.co.uk; ietf@ietf.org
Cc: cc...@ietf.org
Subject: RE: [CCAMP] Last Call: 
 (Generalized Multi-Protocol 
Label Switching (GMPLS) Signaling Extensions for the evolving G.709 Optical 
Transport Networks Control) to Proposed Standard

Hi Adrian,

I am updating this draft, but one issue is about the new small section.

You said "adding a small section including all of the statements you made in 
your email", but I really don't know which kind of section should be added to 
cover various aspects including management tools, OAM, alarm, MIB, etc.

I also suspect the value to have this kind of new section to talk about 
something (and nothing new), which may not be related to the subject of this 
draft (ie., RSVP-TE extensions for OTN *connection* establishment).

Therefore, I would like to hear more from you. Could you give a title for this 
new section?


Best Regards

Fatai

From: Adrian Farrel [mailto:adr...@olddog.co.uk]
Sent: Wednesday, August 21, 2013 6:12 PM
To: Fatai Zhang; ietf@ietf.org
Cc: cc...@ietf.org
Subject: RE: [CCAMP] Last Call: 
 (Generalized Multi-Protocol 
Label Switching (GMPLS) Signaling Extensions for the evolving G.709 Optical 
Transport Networks Control) to Proposed Standard

Hi Fatai,

I think you nicely answered your own questions :-)

I would suggest adding a small section including all of the statements you made 
in your email. (Well, no need to refer to Berlin and the CCAMP chairs :-)

Cheers,
Adrian

From: Fatai Zhang [mailto:zhangfa...@huawei.com]
Sent: 21 August 2013 08:40
To: adr...@olddog.co.uk; ietf@ietf.org
Cc: cc...@ietf.org
Subject: RE: [CCAMP] Last Call: 
 (Generalized Multi-Protocol 
Label Switching (GMPLS) Signaling Extensions for the evolving G.709 Optical 
Transport Networks Control) to Proposed Standard


Hi Adrian,



Thanks very much.



I can update the nits and editorial issues quickly, but I would like to discuss 
more with you for the following points to make things clear before I update the 
draft.



=

Please consider and note what updates to GMPLS management tools are needed.



[Fatai]This has been mentioned in [Framework] document. Did you mean that we 
need add one sentence in some place of this document to refer to [Framework] 
document to mention management tools?



Are there any changes to the Alarms that might arise? We have a document for 
that.



[Fatai] No. RFC4783 is still applicable.



Are there any changes to the way OAM is controlled? We have a document for that.



[Fatai] No, it could be done through NMS or 
[draft-ietf-ccamp-rsvp-te-sdh-otn-oam-ext].



Should the new G-PIDs show in the TC MIB managed by IANA at

https://www.iana.org/assignments/ianagmplstc-mib/ianagmplstc-mib.xhtml

This should happen automgically when the feeding registries are updated

but it is probably best to add a specific request for IANA.



[Fatai] Will do that.



Will other MIB work be needed (in the future) to make it possible to

read new information (labels, tspecs) from network devices?



[Fatai] I am not sure. I asked the similar question (not on this draft) during 
Berlin meeting. The chairs answered that it could be driven by drafts.







Best Regards



Fatai



-Original Message-
From: ccamp-boun...@ietf.org [mailto:ccamp-boun...@ietf.org] On Behalf Of 
Adrian Farrel
Sent: Wednesday, August 21, 2013 2:51 AM
To: ietf@ietf.org
Cc: cc...@ietf.org
Subject: Re: [CCAMP] Last Call: 
 (Generalized Multi-Protocol 
Label Switching (GMPLS) Signaling Extensions for the evolving G.709 Optical 
Transport Networks Control) to Proposed Standard



As sponsoring AD I have the following last call comments I hope you will take on

board.



Thanks,

Adrian



Please fix the two lines that are too long (see idnits)



---



Please expand "OTN" on first use in the main text.

Please expand "TS" on its first use.



---



6.2



   The ingre

Re: [DNSOP] Practical issues deploying DNSSEC into the home.

[Phillip Hallam-Baker]

On Wed, Sep 11, 2013 at 12:08 PM, Paul Wouters  wrote:

> On Wed, 11 Sep 2013, Joe Abley wrote:
>
>
>>> 1. We only need to know the current time to an accuracy of 1 hour.
>>>
>>
>> [RRSIG expiration times are specified with a granularity of a second,
>> right?
>>
>> I appreciate that most people are generous with signature inception and
>> expiration times in order to facilitate clock skew on validators, but I
>> think "1 hour" needs some qualification.]
>>
>
> The 1h came from the shortest RRSIG validity time in the chain to get to
> pool.ntp.org, but performing a handful of queries now, I cannot find
> that magical RRSIG with the 1h validity period.
>
> Note: I also once ran into bad clocks due to dual boot systems with
> Windows and Daylight Savings Time, so I explicitely set inception time
> to -2h. One hour is not enough on doubly broken systems.


The DNS is the naming infrastructure of the Internet. While it is in theory
possible to use the DNS to advertise very rapid changes to Internet
infrastructure, the practice is that the Internet infrastructure will look
almost exactly the same in one hour's time as it does right now.

Using DNS data from 24 hours earlier might create reliability issues but
should never introduce a security risk. Anyone who is relying on the DNS
for data that is more time sensitive than 1 hour is doing it wrong.



-- 
Website: http://hallambaker.com/

Re: [DNSOP] Practical issues deploying DNSSEC into the home.

[Joe Abley]

On 2013-09-11, at 11:43, Phillip Hallam-Baker  wrote:

> OK lets consider the trust requirements here.
> 
> 1. We only need to know the current time to an accuracy of 1 hour.

[RRSIG expiration times are specified with a granularity of a second, right?

I appreciate that most people are generous with signature inception and 
expiration times in order to facilitate clock skew on validators, but I think 
"1 hour" needs some qualification.]

> 2. The current time is a matter of convention rather than a natural property. 
> It is therefore impossible to determine the time without reference to at 
> least one trusted party.
> 
> 2a) A trusted party that asserts that the current time is set to a date in 
> the future can perform a denial of service attack on a relying party but one 
> that is easily detected.
> 
> 2b) It is a simple matter for the trusted party to provide a signed assertion 
> that the current time is after the Date-Time X. The hard part is ensuring 
> that the relying party can access an up to date version of the current time 
> assertion.
> 
> 2c) DNSSEC already provides an abundance of such assertions. If the 
> signatures on the .com zone are claiming a date in the future then the whole 
> viability of DNSSEC collapses. 
> 
> 3) A relying party thus requires a demonstration that is secure against a 
> replay attack from one or more trusted parties to be assured that the time 
> assertion presented is current but this need not necessarily be the same as 
> the source of the signed time assertion itself.
> 
> 4) In the case of DNSSEC the window of vulnerability is actually fairly small 
> since rewinding the time to a date in the past only helps an attacker if they 
> had compromised the system on that date.

[or if they had intercepted, stored and replayed a signed response at a later 
time when the current response would be different]

> The real design decision is who you decide you are going to rely on for (3). 
> TLS is proof against replay attack due to the exchange of nonces. 

I think that's deeper than where we are right now. Before we consider 
mechanisms for gauging the accuracy of a local clock, we need consensus on the 
general approach, e.g. the state machine implied by 
draft-jabley-dnsop-validator-bootstrap or something different but analogous.


Joe

Gen-Art LC review for draft-cotton-rfc4020bis-01

[Robert Sparks]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

.

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

Document: draft-cotton-rfc4020bis-01
Reviewer: Robert Sparks
Review Date: 2013-09-11
IETF LC End Date: 2013-09-24
IESG Telechat date: not scheduled

Summary: This draft is on the right track but has open issues, described 
in the review.


(That summary was taken from the options in RFC6385. I would prefer to say
"There is one minor issue that is bigger than a nit, but it should be 
easy to straighten out")


Issue : Section 2 is very confusing. It starts out listing 4 things that 
look like they all have to be met. But then the last sentence confuses 
things. Is just reinforcing that both a and b have to be met (if so, 
then wouldn't things also stop if c and d weren't met? (see 3.1 step2)).
I suggest replacing "If conditions (a) or (b)" with "If any of the above 
conditions"


Nit 1: Section 3.1 reads harshly at the transition from step 4 to step 
5.  It leaves it implicit that the AD has to approve.
Step 3 has  "if steps 2 and 3 are satisfied". 4020 said "with the 
approval of the Area Director(s)". Adding that text  to step 5 would 
address the nit.


Nit 2: The introduction contains a bit of text that it carried forward, 
slightly modified, from 4020 for which I suggest further modification:

replace
"the IETF community wishes to retain tight control of the protocol"
with
"the IETF community has consensus to retain tight control of the 
registry content"


That way this document is reflecting the actual process point that would 
lead to a tighter registration policy without trying to speculate what 
motivated that consensus.


Nit 3: Several reviewers have pointed to a lack of clarity in section 2 a.
I suggest taking the change John Klensin proposed (with tweaks as below)

The code points must normally be from a space designated
as "RFC Required", "IETF Review", or "Standards Action".
In addition, code points from a "Specification
Required" space are allowed if the specification will be
published as an RFC.

Re: [DNSOP] Practical issues deploying DNSSEC into the home.

[Paul Wouters]

On Wed, 11 Sep 2013, Olafur Gudmundsson wrote:


I think you can avoid that issue by having the device not pass traffic
until the DNSSEC validation is enabled. Only the device needs the special
permissive handling for this to work.


You mean only allow NTP and DNS traffic in the beginning, until checks are done?
In many cases we can get a reasonable time by writing the current time to a 
NVRAM variable every 6 hours or so, but that
only helps for reboot.


And if you think of laptop and/or phone, add "hotspot detection" to this
isolation mode. It's harder because it needs a "private browser window"
type state.

Paul

Re: [DNSOP] Practical issues deploying DNSSEC into the home.

[Phillip Hallam-Baker]

OK lets consider the trust requirements here.

1. We only need to know the current time to an accuracy of 1 hour.

2. The current time is a matter of convention rather than a natural
property. It is therefore impossible to determine the time without
reference to at least one trusted party.

2a) A trusted party that asserts that the current time is set to a date in
the future can perform a denial of service attack on a relying party but
one that is easily detected.

2b) It is a simple matter for the trusted party to provide a signed
assertion that the current time is after the Date-Time X. The hard part is
ensuring that the relying party can access an up to date version of the
current time assertion.

2c) DNSSEC already provides an abundance of such assertions. If the
signatures on the .com zone are claiming a date in the future then the
whole viability of DNSSEC collapses.

3) A relying party thus requires a demonstration that is secure against a
replay attack from one or more trusted parties to be assured that the time
assertion presented is current but this need not necessarily be the same as
the source of the signed time assertion itself.

4) In the case of DNSSEC the window of vulnerability is actually fairly
small since rewinding the time to a date in the past only helps an attacker
if they had compromised the system on that date.


The real design decision is who you decide you are going to rely on for
(3). TLS is proof against replay attack due to the exchange of nonces.

Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC

[joel jaeggli]

On 9/11/13 2:40 AM, Abdussalam Baryun wrote:
> On 9/9/13, Owen DeLong  wrote:
>> I have to agree with Lorenzo here again.
>>
>> This document seems to me to be:
>>
>>  1.  Out of scope for the IETF.
> 
> Please define what is the IETF scope? IMHO, IETF is scoped to do with
> IPv6 devices requirements and implementations. Do you think there is a
> RFC that considers thoes requirements?

The queue for dicussion of this point is closed. If there needs to be an
appeal on this point now or in the future, then I'll be happy to help
someone write it, but I consider that dicussion settled for the purposes
of a draft that has already been tested for wg acceptance/wglc/ietf-lc

> 
>>  2.  So watered down in its language as to use many words to say 
>> nearly
>> nothing.
> 
> No, the draft says things, I think if you read nothing that you did
> not read then. If you read, then what is your definition of saying
> nothing?
> 
>>  3.  Claims to be informational, but with so many caveats about the 
>> nature of
>> that
>>  information that it's hard to imagine what meaningful 
>> information an
>> independent
>>  reader could glean from the document.
> 
> I think this was mentioned clearly in the draft, which readers can understand.
> 
>>
>> Finally, given the spirited debate that has extended into this last call
>> (which I honestly wonder
>> how this ever saw last call over the sustained objections) definitely does
>> not appear to have
>> even rough consensus, nor does it appear to have running code.
> 
> IMHO, the LC is not for consensus, but it is for us to send the IESG
> our comments, and then they decide what is the IETF decision.
>>
>> Why is there such a push to do this?
> 
> Why is there a push to water-down it? I still was not convinced by
> your argument. However, Lorenzo comments should be considered by the
> draft as the authors are working on.
> 
> AB
> ___
> v6ops mailing list
> v6...@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
> 

Re: was: not really pgp signing in van

[Phillip Hallam-Baker]

On Wed, Sep 11, 2013 at 11:41 AM, SM  wrote:

> Hi Yoav,
> At 03:28 11-09-2013, Yoav Nir wrote:
>
>> I don't think you'd even need the threats.
>>
>
> [snip]
>
>  Notice the important parts of that pitch. A sense of danger; Making the
>> target feel either patriotic or a humanitarian; Sharing a "secret" with the
>> target, making him part of the "inner circle". Making the target feel
>> important, like "only your cooperation can help us stop the next attack".
>> If this pitch is executed correctly, by the end, the target is asking for
>> an NSL as CYA. I've seen this kind of thing done once years ago, but it was
>> done very poorly and didn't work.
>>
>
> Yes.
>
> My reading of Phillip Hallam-Baker's comment is that there isn't anything
> to worry about in relation to Comodo except that he does not have any
> knowledge about the operational side.  John Levine asked how likely they
> would risk their reputation.  Theodore Ts'o mentioned that there really is
> no incentive for them to do a good job.
>

Since the operations side is in Salford UK, a National Security Letter
would have no force there.

I am not aware of any similar provision in UK law which is in any case
constrained by European Union privacy law, European Human Rights law etc.


And it is a firmly established principle of English law that the courts
cannot interfere with any action in parliament and that an injunction
obtained in England has no effect in Scotland (yes really). So if people
are really worried, get me tickets to the Edinburgh festival and return
airfare and we can have a talk. But you would probably be disappointed by
what I had to say. If I did have something to say I would go talk to one of
the members of parliament I know from university, school, family, etc.

Incidentally the worst British judge of the 20th century is no longer on
the bench and the super-injunction stupidity has come to an end with his
career.

-- 
Website: http://hallambaker.com/

Re: [DNSOP] Practical issues deploying DNSSEC into the home.

[Phillip Hallam-Baker]

On Wed, Sep 11, 2013 at 12:26 PM, Nicholas Weaver  wrote:

>
> On Sep 11, 2013, at 9:18 AM, Phillip Hallam-Baker 
> wrote:
> >
> > The DNS is the naming infrastructure of the Internet. While it is in
> theory possible to use the DNS to advertise very rapid changes to Internet
> infrastructure, the practice is that the Internet infrastructure will look
> almost exactly the same in one hour's time as it does right now.
> >
> > Using DNS data from 24 hours earlier might create reliability issues but
> should never introduce a security risk. Anyone who is relying on the DNS
> for data that is more time sensitive than 1 hour is doing it wrong.
>
> I disagree.  DNSSEC is not just DNS: its the only available, deployed, and
> (mostly) accessible global PKI currently in existence which also includes a
> constrained path of trust which follows already established business
> relationships.
>

Except that virtually nobody uses DNSSEC and most of the registrars don't
support it.

And then there is that other PKI that is actually used to support a
trillion odd dollars worth of global e-commerce per year.


DNSSEC has been about to exist ever since I started on the Web over two
decades ago now. It is still not in use to support any business
transactions. So to present it as the only PKI when it isn't yet deployed
is showing a distinct lack of common sense and acceptance of reality.

-- 
Website: http://hallambaker.com/

Re: [DNSOP] Practical issues deploying DNSSEC into the home.

[Randy Presuhn]

Hi -

>From: Olafur Gudmundsson 
>Sent: Sep 11, 2013 7:19 AM
>To: Evan Hunt 
>Cc: "dn...@ietf.org WG" , "ietf@ietf.org TF" 
>Subject: Re: [DNSOP] Practical issues deploying DNSSEC into the home.
...
>RRSIG on the SOA or NS or DNSKEY also is fine timestamp except when it is a 
>replay attack or a forgery, 
...

RFC 3414 separates the notion of timeliness (replay detection)
from authentication without requiring NTP or overly elaborate
clock acquisition dances.  Some of the ideas from that protocol's
design might be useful in addressing this problem.

Randy

was: not really pgp signing in van

[SM]

Hi Yoav,
At 03:28 11-09-2013, Yoav Nir wrote:

I don't think you'd even need the threats.


[snip]

Notice the important parts of that pitch. A sense of danger; Making 
the target feel either patriotic or a humanitarian; Sharing a 
"secret" with the target, making him part of the "inner circle". 
Making the target feel important, like "only your cooperation can 
help us stop the next attack". If this pitch is executed correctly, 
by the end, the target is asking for an NSL as CYA. I've seen this 
kind of thing done once years ago, but it was done very poorly and didn't work.


Yes.

My reading of Phillip Hallam-Baker's comment is that there isn't 
anything to worry about in relation to Comodo except that he does not 
have any knowledge about the operational side.  John Levine asked how 
likely they would risk their reputation.  Theodore Ts'o mentioned 
that there really is no incentive for them to do a good job.


Over the last few years nobody noticed that there might be a 
problem.  That's not reassuring.  I doubt that people would not 
comply with a NSL.


Regards,
-sm 

Re: [DNSOP] Practical issues deploying DNSSEC into the home.

[Evan Hunt]

On Tue, Sep 10, 2013 at 05:59:52PM -0400, Olafur Gudmundsson wrote:
> My colleagues and I worked on OpenWrt routers to get Unbound to work
> there, what you need to do is to start DNS up in non-validating mode wait
> for NTP to fix time, then check if the link allows DNSSEC answers
> through, at which point you can enable DNSSEC validation. 

That's roughly what we did with BIND on OpenWrt/CeroWrt as well.  We
also discussed hacking NTP to set the CD bit on its initial DNS queries,
but I don't think any of the code made it upstream.

My real recommendation would be to run an NTP pool in an anycast cloud of
well-known v4 and v6 addresses guaranteed to be reliable over a period of
years. NTP could then fall back to those addresses if unable to look up the
server it was configured to use.  DNS relies on a well-known set of root
server addresses for bootstrapping; I don't see why NTP shouldn't do the
same.

(Actually... the root nameservers could *almost* provide a workable time
tick for bootstrapping purposes right now: the SOA record for the root
zone encodes today's date in the serial number.  So you do the SOA lookup,
set your system clock, attempt validation; on failure, set the clock an
hour forward and try again; on success, use NTP to fine-tune. Klugey! :) )

--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.

Re: [DNSOP] Practical issues deploying DNSSEC into the home.

[Nicholas Weaver]

On Sep 11, 2013, at 7:19 AM, Olafur Gudmundsson  wrote:
>> (Actually... the root nameservers could *almost* provide a workable time
>> tick for bootstrapping purposes right now: the SOA record for the root
>> zone encodes today's date in the serial number.  So you do the SOA lookup,
>> set your system clock, attempt validation; on failure, set the clock an
>> hour forward and try again; on success, use NTP to fine-tune. Klugey! :) )
>> 
>> -
> 
> RRSIG on the SOA or NS or DNSKEY also is fine timestamp except when it is a 
> replay attack or a forgery, 


This can actually do it down to 1s precision except in the case of a replay 
attack with a dynamically signed name (and if you are facing a replay attack, 
you can't trust NTP anyway!):

E.g., this name:

dig +dnssec 10sec100ttlsig.netalyzr-dnssec.com @8.8.8.8

has a RRSIG that expires in +10 seconds (ALWAYS), but has a TTL on the record 
that expires in 100 s.  This is an example name on my server designed for 
allowing single-lookup clockdrift testing on DNSSEC validators.

(The signature is also generated on-the-fly every second its requested, and a 
subsequent addition will include the ability to add a NONCE to guarantee 
cache-busting, too).

--
Nicholas Weaver  it is a tale, told by an idiot,
nwea...@icsi.berkeley.edufull of sound and fury,
510-666-2903 .signifying nothing
PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [DNSOP] Practical issues deploying DNSSEC into the home.

[Olafur Gudmundsson]

On Sep 10, 2013, at 8:17 PM, David Morris  wrote:

> 
> 
> On Wed, 11 Sep 2013, Brian E Carpenter wrote:
> 
>> On 11/09/2013 09:59, Olafur Gudmundsson wrote:
>> ...
>>> My colleagues and I worked on OpenWrt routers to get Unbound to work there, 
>>> what you need to do is to start DNS up in non-validating mode
>>> wait for NTP to fix time, then check if the link allows DNSSEC answers 
>>> through, at which point you can enable DNSSEC validation.
>> 
>> Hopefully you also flush the DNS cache as soon as NTP runs. Even so,
>> paranoia suggests that a dodgy IP address might still be cached in
>> some app.
> 
> I think you can avoid that issue by having the device not pass traffic
> until the DNSSEC validation is enabled. Only the device needs the special
> permissive handling for this to work.
> 

You mean only allow NTP and DNS traffic in the beginning, until checks are 
done? 
In many cases we can get a reasonable time by writing the current time to a 
NVRAM variable every 6 hours or so, but that
only helps for reboot. 

Olafur 

Re: Practical issues deploying DNSSEC into the home.

[Olafur Gudmundsson]

On Sep 10, 2013, at 7:17 PM, Brian E Carpenter  
wrote:

> On 11/09/2013 09:59, Olafur Gudmundsson wrote:
> ...
>> My colleagues and I worked on OpenWrt routers to get Unbound to work there, 
>> what you need to do is to start DNS up in non-validating mode
>> wait for NTP to fix time, then check if the link allows DNSSEC answers 
>> through, at which point you can enable DNSSEC validation.
> 
> Hopefully you also flush the DNS cache as soon as NTP runs. Even so,
> paranoia suggests that a dodgy IP address might still be cached in
> some app.
> 
>Brian

Flushing cache is a good idea, and dnssec-trigger does this when it "upgrades" 
the unbound from recursor to validator. 

Olafur

Re: [DNSOP] Practical issues deploying DNSSEC into the home.

[Olafur Gudmundsson]

On Sep 10, 2013, at 6:45 PM, Evan Hunt  wrote:

> On Tue, Sep 10, 2013 at 05:59:52PM -0400, Olafur Gudmundsson wrote:
>> My colleagues and I worked on OpenWrt routers to get Unbound to work
>> there, what you need to do is to start DNS up in non-validating mode wait
>> for NTP to fix time, then check if the link allows DNSSEC answers
>> through, at which point you can enable DNSSEC validation. 
> 
> That's roughly what we did with BIND on OpenWrt/CeroWrt as well.  We
> also discussed hacking NTP to set the CD bit on its initial DNS queries,
> but I don't think any of the code made it upstream.
> 

Not sure if this will work in all cases, as a paranoid resolver might 
only ignore the CD bit for the actual answer not for the DNS records needed
to navigate to the answer. 


> My real recommendation would be to run an NTP pool in an anycast cloud of
> well-known v4 and v6 addresses guaranteed to be reliable over a period of
> years. NTP could then fall back to those addresses if unable to look up the
> server it was configured to use.  DNS relies on a well-known set of root
> server addresses for bootstrapping; I don't see why NTP shouldn't do the
> same.
> 

This is something worth suggesting, and 

> (Actually... the root nameservers could *almost* provide a workable time
> tick for bootstrapping purposes right now: the SOA record for the root
> zone encodes today's date in the serial number.  So you do the SOA lookup,
> set your system clock, attempt validation; on failure, set the clock an
> hour forward and try again; on success, use NTP to fine-tune. Klugey! :) )
> 
> -

RRSIG on the SOA or NS or DNSKEY also is fine timestamp except when it is a 
replay attack or a forgery, 

Olafur

Re: [Gen-art] Gen-ART LC review of draft-ietf-repute-model-08

[Jari Arkko]

Thanks for your review, Roni. The Gen-ART reviews by you and the rest of the 
team are essential for me to do my work. And thank you authors for writing a 
clear and useful document.

I must say that like Roni, I had some trouble with the document classification. 
It did read more as an informational document, and I think you could have 
referenced it with informational references. That being said, I do not see a 
danger where the document classification would somehow lead to misunderstanding 
somewhere, and if the authors want to refer to the terms defined in this 
document in a normative manner that is OK too. As a result, I took a 
"No-Objection" position for the document's approval in tomorrow's IESG telechat.

Jari

On Sep 7, 2013, at 4:05 PM, Roni Even  wrote:

> Hi,
> My understanding is that you can have a downref to an informational document 
> as long as it is mentioned in the writeup and in the IETF LC. This is not a 
> reason to make this document a standard track document if it should  be 
> informational.
> Roni
>  
> From: Murray S. Kucherawy [mailto:superu...@gmail.com] 
> Sent: 07 September, 2013 10:41 AM
> To: Roni Even
> Cc: draft-ietf-repute-model@tools.ietf.org; ietf; General Area Review Team
> Subject: Re: Gen-ART LC review of draft-ietf-repute-model-08
>  
> Hi Roni, sorry again for the delay.
>  
> On Sat, Aug 31, 2013 at 4:27 AM, Roni Even  wrote:
> I was asked to review the 08 version but my comments from 07 were not 
> addressed and I did not see any response. So I am resending my previous review
> As for making it a standard track document, I am not sure since it looks to 
> me as an overview and not standard. And there is no normative language in the 
> document.
> Roni Even
>  
> It was changed to Proposed Standard because of rules around referencing it 
> normatively from other documents that are seeking Proposed Standard status.
>  
>  
> I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, 
> please see the FAQ at 
> .
> Please resolve these comments along with any other Last Call comments you may 
> receive.
> [...]
> Minor issues:
> I was wondering why the “Further Discussion” section 9.3 is part of the 
> security section. I think it should be a separate section.
>  
> The wording of 9.3 is meant to be security-specific, but that's buried in the 
> word "use".  I'll make it more clear.
>  
> Nits/editorial comments:
> Section 3 the end of 2nd paragraph “mechansisms” to “mechanisms”
>  
> Fixed.
> 
> Thanks again,
> 
> -MSK
> 
> ___
> Gen-art mailing list
> gen-...@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

Re: not really pgp signing in van

[Yoav Nir]

On Sep 11, 2013, at 2:45 AM, Ted Lemon  wrote:

> On Sep 10, 2013, at 6:50 PM, Phillip Hallam-Baker  wrote:
>> Could be but I have been working through what we know versus what would be 
>> required and I really can't see how a group of people who would let Snowden 
>> loose on their innermost secrets would be able to keep a conspiracy that 
>> required CAs or Gmail staff or the like to participate on the scale required.
> 
> You don't need a conspiracy.   You just need to threaten the right person 
> with jail.   

I don't think you'd even need the threats. 

"Hello, Mr. Lemon. Thank you for taking the time to see us. As you know, there 
are a lot of terrorists who as we speak are planning attacks against our 
country. Let me ask you something. Do you love your country? You know what, 
don't answer that. I don't go much for all that flag-waving myself. But you 
remember 9/11? 3000 people died there. And in Iraq 170 were killed in the last 
few months. Those are the same people, and they're as determined as ever. And 
do you think they're all in Iraq and Syria? I'm not supposed to tell you this" 
(looks around the room to make sure you're alone) "but just last month we 
arrested  right in Virginia with bomb 
components in his basement and plans for some key buildings in DC. You know how 
they coordinated their attacks? They used your mail service. And that is why 
we've come to you. Not so that America can win. What's winning, anyway? But 
because we're saving lives, hundreds of lives, both here and abroad. We need 
your help. Will you do this for America? For the innocent victims?"

Notice the important parts of that pitch. A sense of danger; Making the target 
feel either patriotic or a humanitarian; Sharing a "secret" with the target, 
making him part of the "inner circle". Making the target feel important, like 
"only your cooperation can help us stop the next attack". If this pitch is 
executed correctly, by the end, the target is asking for an NSL as CYA. I've 
seen this kind of thing done once years ago, but it was done very poorly and 
didn't work. 

> Nevertheless, your optimism about this problem is not an optimism that I 
> share, and apparently I am not alone in my pessimism.   You can certainly 
> argue that the IETF need not address this threat model, but I don't agree 
> with you, and your assurances that it's all perfectly okay are not swaying 
> me... :)

Yeah, I don't get those references to the NSA being in hot water. Polls get 
different results depending on how the question is asked, but they either show 
a slim majority against massive snooping or a very slim majority accepting 
massive snooping "if it's to fight terrorism". I don't see much in the way of 
massive pressure on the legislative or executive branch to stop it.

Yoav

Re: Equably when it comes to privacy

[Abdussalam Baryun]

I agree with you SM, politics and considering countries names in that
way, that is out of scope of IETF. Comments below,

AB

On 9/8/13, SM  wrote:
> At 07:07 08-09-2013, Jorge Amodio wrote:
>>You mean like Pakistan, Iran, Libya, Syria, Saudi Arabia 
>
> There were people from Pakistan who participated in the IETF.  I
> recall an email exchange where a person from that country received an
> unpleasant comment from someone who is part of the IETF "leadership".

That is rude behavior, which I may experienced in IETF.
>
> In my opinion a discussion about Country X or Country Y would take
> the thread downhill.  It can also have a chilling effect.

I totally agree, by having more participants from all world's
countries, makes the IETF more diverse, and by silence to such rude
behavior means we are welcoming less diversity.
>
> At 05:14 08-09-2013, Phillip Hallam-Baker wrote:
>>Another worrying aspect of [censored] is that it is named
>>after[censored]. They seem to be looking to make [censored] out of
>>us. They certainly seem to be endorsing [censored]. What should we
>>think if the [censored] had a similar program codenamed [censored]?
>
> It would not look good.

It is not good behavior if IETF just watches lists and does not make
mentoring to its participants old/new comers.

AB

>
> Regards,
> -sm
>
>

Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC

[Abdussalam Baryun]

On 9/9/13, Owen DeLong  wrote:
> I have to agree with Lorenzo here again.
>
> This document seems to me to be:
>
>   1.  Out of scope for the IETF.

Please define what is the IETF scope? IMHO, IETF is scoped to do with
IPv6 devices requirements and implementations. Do you think there is a
RFC that considers thoes requirements?

>   2.  So watered down in its language as to use many words to say 
> nearly
> nothing.

No, the draft says things, I think if you read nothing that you did
not read then. If you read, then what is your definition of saying
nothing?

>   3.  Claims to be informational, but with so many caveats about the 
> nature of
> that
>   information that it's hard to imagine what meaningful 
> information an
> independent
>   reader could glean from the document.

I think this was mentioned clearly in the draft, which readers can understand.

>
> Finally, given the spirited debate that has extended into this last call
> (which I honestly wonder
> how this ever saw last call over the sustained objections) definitely does
> not appear to have
> even rough consensus, nor does it appear to have running code.

IMHO, the LC is not for consensus, but it is for us to send the IESG
our comments, and then they decide what is the IETF decision.
>
> Why is there such a push to do this?

Why is there a push to water-down it? I still was not convinced by
your argument. However, Lorenzo comments should be considered by the
draft as the authors are working on.

AB