nd as such they fall short of the IETF's
> capabilities to deliver. They also may actually become victims of the
> language barrier
No English. OK. And, Japanese is the best language, of course. Let's
not use English but Japanese, internationally. OK?
er) of personal name.
But, even such people using non-ASCII personal names can't use
non-ASCII for more serious purposes such as mail addresses, if
they want to receive mails internationally.
Masataka Ohta
PS
My children know ASCII characters not
0 years, I have developped a simple and straight
forward theory on what, actually, is unification. I can elaborate, if
you are interested in.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
at RPKI is useless for such
prevention. Read the ML log.
>> after exhaustion is reached.
With A+P, it will be reached in year 3010 or later.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
DF-A file is good but your definition of PDF-A
is bad?
But, broken definition is worse than broken tools, which, even
more strongly, means we must not use profiled subset.
Masataka Ohta
___
Ietf mailing
point.
It's your problem.
> I don't think anything was demonstrated at all.
Again, it's your problem.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Phillip Hallam-Baker;
I can understand that you are seriously worrying about archaeology
of year 3010 and beyond.
However, I'm afraid no one else is interested in.
Masataka Ohta
___
Ietf ma
years time"?
Or?
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
s? Just asking...
Tools does not support restricted profile very well, as was
demonstrated by a circled 'R' character in a
claimed-to-be-pure-ASCII PDF.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Phillip Hallam-Baker wrote:
As was discussed already in this ML, RPKI is useless.
Even if an AS owning an address block is securely known, it does
not secure routing to the address block through other ASes.
Masataka Ohta
gt; Please elaborate.
See above.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Longeivity, guarantee of being able to interpret them in 1000 years
Then, we should use a format available at least 500 years ago.
Were you using HTML 500 years ago?
Masataka Ohta
___
Ietf maili
and there are lots of other bytes in
> this file with the high bit set, if we want to bring that up too.
As we are discussing about text format, let's ignore PDF. PERIOD.
Masataka Ohta
___
d R in
metadata for pdf:Creator.
Thank you for a convincing demonstration to deny yourself.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
nothing but ASCII
characters.
Note also that the wrong conversion is by Tim Bray who says:
> I will commit to offering some cycles to help with tools
> and specs, as appropriate.
How much reliability, do you think, the tools and specs will have?
characters.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
pable PDF.
Q.E.D.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
related topics.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
please don't convert someone else's pure
ASCII message into something else.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
not accountable at all.
That's all.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
enerations. You may also use elliptic curve cryptography,
though I don't prefer it.
But, later, I noticed fundamental fraud in PKI, against which no
technical solution exists. Note that separation of ZSK and KSK
was an impossible attempt make inherently insecure PKI less
insecure.
PKI is a system of fraud.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
ing CA, is not
infallible, which is why PKI is insecure.
Is EV divine?
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Phillip Hallam-Baker wrote:
> Once you have established an SSH relationship
That's the (lack of) security of SSH by return routability. PERIOD.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.o
idence is lack of the concept of "root key" and other
things. If relying on security of root and other zones, which are
not really secure, was seriously considered, there should be
provisions for more complex mechanisms such as key roll over to
make the system a little less insecure.
; cryptographic protection. This is slightly different from plain DH.
No, it is not expected that gtld servers will become
"???.gtld-servers.net",
only to cause message size overflow.
I can teach you that the security you
observe is not of SSH but of return routability.
Return routability over many third party ISPs is not 'verifiable',
of course.
Masataka Ohta
___
ordinary person, are free to assume typical ISPs in
europe secure and packet snooping impossible, which means you must
say simple nonce secure.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
packets, long message ID is just secure.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
ough.
> Except from players that can see the query.
That's not a new cryptographical problem.
As DNSCurve protection is like DH, it is subject to MitM attacks,
which is no different from simple nonce.
Masataka Ohta
___
ugh.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
against
> a MITM attack,
> on the path from the server back to the querying entity?
As DNSSEC is not protected from MitM attacks on zones on the path
between client and server zones, how can you expect plain old DNS
is better protected?
new IP.
It partially is a problem of unnecessarilly long TTL, which
means poor administration of related zones. That is, DNS is
not fully responsible for the problem.
However, it is almost certain that the zones will have poor
administration and, thus, poor security even if DNSSE
nd the
DNS servers and not between the clients and application servers of
the clients.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
x27;t seem to be a particularly useful exercise.
So?
> I'm not sure why you are pretending that useful security is binary.
I'm afraid you are saying "DNSSEC or die", while I'm saying
"reasonable security is good enough". Which, do you think,
is binary?
ce and destination, anyway.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
additional information including glue.
> P.S. Just to mention: I liked Internet 20 years ago much more and a bit
> nostalgic about it.
See above for more than 100 years of history.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
ures.
However, DNSSEC does not technically verify the valid signatures
are obtained legitimately.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
valid signature over the forged key.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
trust DNSSEC-answer which you have got over a network
of poorly managed CAs (zones)?
> Now, the necessity to build the chains of trust is obvious,
Unless the chains are not already there.
Masataka Ohta
.
For security of DNS, social security of trust relationship between
ISPs and between zones are just enough to which additional social
security by PKI is not helpful.
Masataka Ohta
___
Ietf mailing
evidence than PEM or DNSSEC.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
nst which, there is no
protection.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
ksum.
It is an example of how IPv6 was bloated to have many useless
features ignoring corner cases of interactions of the features.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
you say NAT and unicast class E?
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
IPv6 did not take so many years,
it is better to have another IPng which is more easily deployable
than IPv6.
> If we accept these two observations we arrive at a proof that NAT66 is
> unavoidable.
Only if IPv6 were worth deploying.
exchanges of some key
management protocol. :-)
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
most) IP header are
> covered by the protection.
IPv6 specification requires IPSEC, which means outer most IPv6 must
also support IPSEC.
Feel free to laugh at stupid specification.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
would cause for NAT. As a result
> IPSEC was a botched protocol and has required ad hoc, proprietary and
> in many cases patented tweaks to make it fit for its intended purpose.
I'm fine to laugh at IPv6, which declares IPSEC MUST BE an
integral part of IPv6.
only UDP/TCP
of the middlebox may be modified, *IF* you sacrifice end to end
transparency.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
't need IPv6.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
support.
But, IPv6 has been laughed at for more than 10 years.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
eral govt's re-invigorated push towards IPv6 ...
Do you know that USG pushed towards CLNP?
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
k and this shorten the likelyhood of consumers being
> turned off IPv6?
Not at all. Instead, deprecating IPv6 makes sense.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
sts etc.).
> the CGN mess
Fully agreed.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
oy IPv6 merely because it will restore the
end to end transparency.
On the other hand, with NAT, which can be end to end transparent,
IPv4 capable servers can be reached by IPv4 only clients, optionaly
with end to end transparency.
Eliot Lear wrote:
> And that's another question, what precisely DO we make Historic?
IPv6 and all the RFCs reffering IPv6, of course.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.o
, which will not be modified regardless of whatever
RFCs published later.
The only chance to have deployable renumbering mechanism was in
early stages of IPv6 development. It's too late now.
The next chance will be when yet another IPng will be developped.
d, feel free to produce the poor documents.
> If you'd like to start a thread about IPng, can you use a different
> subject header please?
I'm afraid, considering the so poor quality of IPv6, IETF has already
lost power to produce IPngs.
virtually impossible, it is virtually impossible
to change widely deployed improper implementations.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
to continue standardization of MPLS
after the fallacy of topology driven became so obvious.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
expected.
There is no point to use MPLS as L2 forwarding is as expensive as
L3 forwarding and TE at L2 is mostly useless.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
weakly secure, which is the security
of plain old DNS.
> I have fifteen years experience in this business area.
I thought you shun businesses.
: The link you gave was to a paywalled version of the paper. I did not
: bother to read the authors once I discovered it was paywalled.
The following paper discusses about it to some extent.
http://ftp.csci.csusb.edu/ykarant/courses/f2007/csci530/papers/counterpane-ipsec.pdf
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.i
is rather weaker targets.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
said "cryptographic security".
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
n old DNS is a lot easier to manage than PKI.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
is as easy as
plain old DNS by poisoning cache with forged certificate
through glue (e.g. Kaminsky's attack).
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
handling
of glue, without which DNSSEC cache can also be poisoned.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
gt;>Except for glue A.
which makes DNSSEC as insecure as plain old DNS.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
;, however...
And the third parties of certificate authorities constitute
a chain, a channel, hops or whatever terminology you might
use, which is not end to end.
Masataka Ohta
___
Ietf mailing li
With DNSSEC, a security aware resolver will want to check the signature.
Except for glue A.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
n, cloud you teach me the name and
location of the restaurant you have had dinner with David Clark
obviously free of charge?
Free dinner is better than free lunch.
Masataka Ohta
___
Ietf mailing list
I
characteristic that encourages innovation, and this
flexibility should be preserved.
which means the end to end argument is not modified.
Instead, the paper, for example, says for regulations to be
realistic, they should follow the end to end principle.
breaks the end to end
property.
> I get the impression from you that DNSSEC is to be disregarded because
> it is not "end to end".
Being "end to end" has practical advantages.
See above on how useless DNSSEC is to avoid cache poisoning, which
was the m
re anyone who is not working for registries and is still
interested in deploying DNSSEC for the extra charge despite the
lack of cryptographic security?
If not, let's conclude the thread with a consensus to abandon DNSSEC.
Masataka Ohta
_
tection
against attacks on the signature generation mechanisms.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
t has DOI,
assuming that anyone can use search engines and that all the people
who talks about the end to end principle should have read the
original paper in advance.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
not
> depend on the trustworthiness of any intermediate node, or channel.
According to the terminology of David Clark, certificate authorities
are intermediate nodes.
If you have different terminology, use it outside of the Internet
community but not within.
s not necessary to inject any data into
the zone.
You, instead, can inject a forged certificate into some cache used
by your victim.
It will be extremely easy if people are deceived that DNSSEC were
so secure that no proteciton on cache were necessary.
derstand about this comment is how transport security
> can help in that case. Can you please explain?
Explanation depends on your definition of "the parent".
Masataka Ohta
___
Ietf
DNSSEC, because administrative security of DNSSEC is
cryptographically weak.
So, let's throw away DNSSEC and the broken-from-the-beginning
idea of bailiwick. Let's move on to lock the doors and windows.
ck the doors and windows first, before working on
DNSSEC.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
have another
possibility of security holes?
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
In general, registries welcome DNSSEC, no matter how secure it is,
as long as its complicated operation works as an excuse to increase
(or not to reduce) registration charge and registries' revenue.
Masataka Ohta
___
s present because most, if not all,
implementations cache both glue and authoritative answers but
did not distinguish them by appropriate tagging.
As I have been warning on the problem for these 15 years, some
implementation may hopefully be fixed.
uracy and integrity of the data, the payload.
The problem is that the accuracy and integrity of DNSSEC is not
cryptographically but socially secure.
So is plain old DNS.
So, there is no point to deploy DNSSEC.
Masataka Ohta
provement" makes the entire system more complex only to
introduce new difficulties for revocation.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
st the zone administration never issue certificates over
forged keys of child zones.
You know, the former operation is much simpler, thus more secure,
than the latter.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
ecure, it is a cryptographical issue of each hop, having
nothing to do with social security between hops, introduction of
which is inevitable for large infrastructures.
Masataka Ohta
___
Ietf mailing list
Ietf@
PKI is weakly secure.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Thierry Moreau wrote:
That is, security of DNSSEC involves third parties and is not end
to end.
> This is exactly like a chain of PKI CA's (replacing the path from bottom
> to top of zone hierarchy):
> Exactly the same with a compromised intermediate CA.
> Exactly the same with a pri
ey can be generated.
Then, with a private key corresponding to the faked second next
hop key, record signature on the faked third next hop key can be
generated.
Yes, security of DNSSEC is totally hop by hop.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
end do
know him and his argument.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
a general PKI or not,
security of DNSSEC is not end to end.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
mised, which is no
different from compromising cache in a chain of caching
servers/resolvers.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
lark, but, do so with
reasons.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
f PKI is not.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
27;s [RFC2045] and [RFC2046] allow for the transport of
8bit characters and binary data, which has obvious applicability
to true multimedia material.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
201 - 300 of 574 matches
Mail list logo
