I see that IESG has approved this document, but I am still wondering this:
On 01-12-16 13:20, Matthijs Mekking wrote:
Hi,
I read this again. I still wonder if in the case of DNSSEC Delete
Algorithm it wouldn't be easier to say: In case the DNSSEC algorithm is
0, the Digest/Public Key MUST be ig
On Mon, Jan 09, 2017 at 03:51:31PM +, Vernon Schryver wrote:
> Note that the vast majority of clients of RPZ rewriting resolvers are
> stubs that don't do validation
So far, and at present, correct. Validating resolvers (unbound
and the like) are seeing deployment on servers first, including
> From: Philip Homburg
> 1) If the traver's laptop/phone uses Heathrow Airport resolvers then Heathrow
>4) DNS is not really private so Google may offer their DNS services over HTTPS
> 5) Governments may force Google to block popular sites, so users switch to
>other DNS resolvers, again over
TSIG and SIG(0) (not yet covered by the draft) require reversable
modifications of the message. I would be appending a new additional
record (code TBA) and removing it which contains the addresses. I
would not be modifying an existing OPT record. Nor would I be
adding a new OPT record. Modifyi
>
> > NOTE: I believe that there may be (non-Google) IP associated with
> > this. A lawyer will be filing the IPR disclosure later today (time
> > zone differences, etc).
>
> The two approaches are somewhat different, and so at least one of them
> may not be covered by this patent.
>
> Yup. The
On Tue, Dec 20, 2016 at 7:16 AM, tjw ietf wrote:
> The draft is being present as "Informational", and the point here is to
> document current working behavior in the DNS (for the past several years).
> It is obvious that some feel this draft is a large mistake, but like
> edns-client-subnet, more
>See the recent discovery that Heathrow Airport runs a
>MITM TLS server on torproject.org. Do we want them to run RPZ where they
>can disappear torproject.org alltogether? No. Do we want them to run RPZ
>to prevent travelers from getting malware installed? Yes.
Just my crystal ball:
1) If the trav
On Jan 9, 2017, at 10:51 AM, Vernon Schryver wrote:
> Note that the vast majority of clients of RPZ rewriting resolvers are
> stubs that don't do validation but trust header bits saying that a
> resolver operated by a third party did the validation. I think that's
> wrong, evil, nasty, unethical,
Dear colleagues,
the EDDSA for DNSSEC have been approved by IESG.
Ondřej and Robert, co-editors
--- Forwarded message ---
From: The IESG
Date: 9 January 2017 16:23:28
Subject: [Curdle] Protocol Action: 'EdDSA for DNSSEC' to Proposed Standard
(draft-ietf-curdle-dnskey-eddsa-03.txt)
To: IETF-
> From: Ted Lemon
> I think the main reason attackers won't sign =
> is that it's too much trouble, and provides no real benefit in the =
> presence of an effective RPZ block.
Yes, but there is a reason more important than RPZ for miscreants to
sign their attacks. It
The IESG has approved the following document:
- 'Managing DS records from parent via CDS/CDNSKEY'
(draft-ietf-dnsop-maintain-ds-04.txt) as Proposed Standard
This document is the product of the Domain Name System Operations Working
Group.
The IESG contact persons are Benoit Claise and Joel Jaegg
On Jan 9, 2017, at 10:14 AM, Paul Wouters wrote:
> Apple is getting ready to drop port 80 support. unsigned/unencrypted
> transports are dying. I hope we are moving to a word where DNS without
> DNSSEC will also be seen as bad. So yes, I am assuming in the future,
> attackers will have to sign DNS
On Mon, 9 Jan 2017, Ted Lemon wrote:
On Jan 8, 2017, at 11:49 PM, Paul Wouters wrote:
It is actually the other way around. If an end-node performs DNSSEC
validation, it can only see RPZ modified answers as an attack. It is
in the interest of RPZ to give such clients the confid
On Jan 8, 2017, at 11:49 PM, Paul Wouters wrote:
> It is actually the other way around. If an end-node performs DNSSEC
> validation, it can only see RPZ modified answers as an attack. It is
> in the interest of RPZ to give such clients the confidence that the RPZ
> produced answer is not an attack
I've submitted a -01 revision to address most of the feedback received
so far.
Ray
Forwarded Message
Subject: New Version Notification for draft-bellis-dnsop-xpf-01.txt
Date: Mon, 09 Jan 2017 04:41:53 -0800
From: internet-dra...@ietf.org
To: Ray Bellis
A new version of I-D, d
15 matches
Mail list logo
