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
On 9/11/13 9:39 PM, Lorenzo Colitti wrote:
On Thu, Sep 12, 2013 at 6:45 AM, joel jaeggli joe...@bogus.com
mailto:joe...@bogus.com 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
Hi Doug,
At 21:55 11-09-2013, Douglas Otis wrote:
Recommended text is as follows:
Thanks for suggesting text. I'll take this up with the SPFBIS WG
after the (IESG) DISCUSSes have been addressed.
Here are some quick comments. Section 4.6.4 was reviewed again in
response to the DISCUSS
Phillip Hallam-Baker hal...@gmail.com wrote:
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.
Preferably more than one so you can use quorum agreement and minimize
Hi,
there have been several threads related to this draft and not all of
them have taken place on the IETF general list. Let's try and use this
thread to resolve the few issues that have been brought up during the
IETF LC.
1) Informational vs. Historic
This draft documents a mechanism that has
On 9/12/13 3:02 AM, Masataka Ohta wrote:
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
Arturo Servin 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.
On Wed, Sep 11, 2013 at 03:38:21PM -0400, Phillip Hallam-Baker wrote:
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
Theodore Ts'o wrote:
More importantly, what problem do people think DNSSEC is going to
solve?
Insufficient revenue of registries.
It is still a hierarchical model of trust. So at the top, if you
don't trust Verisign for the .COM domain and PIR for the .ORG domain
(and for people who are
Theodore Ts'o ty...@mit.edu wrote:
Their dynamic with their users and the market is the same as with CA's
--- the market virtually guarantees a race to the bottom in terms of
quality and prices. So beyond replacing names like Comodo with Go
Daddy, what benefit do you actually think would
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
On 09/10/2013 01:39 PM, Murray S. Kucherawy wrote:
Hi Patrik,
On Tue, Sep 10, 2013 at 4:04 AM, Patrik Fältström p...@frobbit.se
mailto:p...@frobbit.se wrote:
What we did look at was first of all every query for an MX
resource record. Then we look at +/-1 second from the timestamp of
On Sep 11, 2013, at 9:18 AM, Phillip Hallam-Baker hal...@gmail.com 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
On Sep 11, 2013, at 02:40 , Abdussalam Baryun abdussalambar...@gmail.com
wrote:
On 9/9/13, Owen DeLong o...@delong.com 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,
On Thu, Sep 12, 2013 at 10:22:10AM -0400, Paul Wouters wrote:
Any co-ercing that happens has to be globally visible, if the target
ensures he is using random nameservers to query for data.
Not necessarily. First of all, an active attacker located close to
the target can simply replace the
On Sep 12, 2013, at 7:24 AM, Theodore Ts'o ty...@mit.edu wrote:
It is still a hierarchical model of trust. So at the top, if you
don't trust Verisign for the .COM domain and PIR for the .ORG domain
(and for people who are worried about the NSA, both of these are US
corporations), the whole
On Thu, Sep 12, 2013 at 1:21 PM, Theodore Ts'o ty...@mit.edu wrote:
On Thu, Sep 12, 2013 at 04:46:01PM +, Ted Lemon wrote:
The model for this sort of validation is really not on a per-client
basis, but rather depends on routine cross-validation by various
DNSSEC operators throughout
On Thu, Sep 12, 2013 at 2:07 PM, Ted Lemon ted.le...@nominum.com wrote:
On Sep 12, 2013, at 1:49 PM, Dickson, Brian bdick...@verisign.com
wrote:
In order to subvert or redirect a delegation, the TLD operator (or
registrar) would need to change the DNS server name/IP, and replace the
DS
On Sep 12, 2013, at 2:35 PM, Phillip Hallam-Baker hal...@gmail.com wrote:
It would work just fine if the attacker did not mind if the surveillance was
detected or actually wanted people to know they were being watched to
intimidate them.
Yup,neither PKI nor DNSSEC address that threat model.
On Sep 12, 2013, at 11:07 AM, Theodore Ts'o ty...@mit.edu wrote:
Finally, if you think the target can try to find random caching
nameservers all across the networ to use, (a) there are certain
environments where this is not allowed --- some ISP's or hotel/coffee
shop/airline's networks require
I've reviewed this document and have some comments.
First, an apology, because although I'm an active participant in the SIDR WG,
I'm pretty sure I missed the WGLC on this, so these comments shouldn't
necessarily be construed as me taking my argument to ietf@ietf because I felt
that SIDR
On Sep 12, 2013, at 3:16 PM, Dickson, Brian bdick...@verisign.com wrote:
Excluding the direct methods of acquisition, let us consider the level of
effort involved in recreating the root key, by brute force.
I think we can assume that they would use some fairly subtle attack to get the
key, and
Gonzalo
comments in-line (for context) below
At 05:47 AM 9/12/2013, Gonzalo Camarillo wrote:
Hi,
there have been several threads related to this draft and not all of
them have taken place on the IETF general list. Let's try and use this
thread to resolve the few issues that have been brought
Ted Lemon wrote:
This isn't _quite_ true. DNSSEC supports trust anchors at
any point in the hierarchy, and indeed I think the right
model for DNSSEC is that you would install trust anchors
for things you really care about, and manage them in the
same way that you manage your root trust
robert bownes wrote:
A 1pulse per second aligned to GPS is good to a few ns. Fairly
straightforward to plug into even a OpenWrt type of router. Turn on
the pps
in NTP on the router and you are good to go.
Faking GPS signal is trivially easy.
Iraq successfully captured US unmanned plain,
On Sep 12, 2013, at 1:21 PM, Theodore Ts'o ty...@mit.edu wrote:
Still, I agree with the general precept that perfect should not enemy
of the better, and DNSSEC certainly adds value. I just get worried
about people who seem to think that DNSSEC is a panacea.
Me too. It most certainly is not.
On Sep 11, 2013, at 12:38 PM, Phillip Hallam-Baker hal...@gmail.com wrote:
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
On Thu, Sep 12, 2013 at 04:46:01PM +, Ted Lemon wrote:
The model for this sort of validation is really not on a per-client
basis, but rather depends on routine cross-validation by various
DNSSEC operators throughout the network. This will not necessarily
catch a really focused attack,
On Thu, 12 Sep 2013, Theodore Ts'o wrote:
More importantly, what problem do people think DNSSEC is going to
solve?
It is still a hierarchical model of trust. So at the top, if you
don't trust Verisign for the .COM domain and PIR for the .ORG domain
(and for people who are worried about the
On Thu, 12 Sep 2013, Theodore Ts'o wrote:
Any co-ercing that happens has to be globally visible, if the target
ensures he is using random nameservers to query for data.
Not necessarily. First of all, an active attacker located close to
the target can simply replace the DNS replies with bogus
On Sep 12, 2013, at 1:49 PM, Dickson, Brian bdick...@verisign.com wrote:
In order to subvert or redirect a delegation, the TLD operator (or
registrar) would need to change the DNS server name/IP, and replace the DS
record(s).
Someone who possesses the root key could in principle create a fake
Total of 353 messages in the last 7 days.
script run at: Fri Sep 13 00:53:04 EDT 2013
Messages | Bytes| Who
+--++--+
11.33% | 40 | 9.28% | 281400 | ted.le...@nominum.com
6.80% | 24 | 8.08% | 244815 |
On Wed, 11 Sep 2013, Olafur Gudmundsson wrote:
On Sep 10, 2013, at 8:17 PM, David Morris d...@xpasc.com 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
The IESG has received a request from the ControLling mUltiple streams for
tElepresence WG (clue) to consider the following document:
- 'Use Cases for Telepresence Multi-streams'
draft-ietf-clue-telepresence-use-cases-07.txt as Informational RFC
The IESG plans to make a decision in the next few
The Multipath TCP WG (mptcp) is having an interim (audio) meeting on
Thursday 3rd October at 3pm GMT.
This will concentrate on security in order to make progress on advancing
RFC 6824 on the standards track. The aim is to reach consensus on what
security improvements are needed - and what are
The IESG has received a request from an individual submitter to consider
the following document:
- 'AES-CCM ECC Cipher Suites for TLS'
draft-mcgrew-tls-aes-ccm-ecc-07.txt as Informational RFC
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.
36 matches
Mail list logo
