ne and yet not bury the reader in
unnecessary detail, or in technical detail which might become inaccurate as
implementations improve whilst the outline remains largely unchanged.
-a
--
Alec Muffett
Security Infrastructure
Facebook Engineering
London
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
e >64 characters long, perhaps even >80, when
new code rolls; the principles are likely invariant, however.
-a
—
Alec Muffett
Security Infrastructure
Facebook Engineering
London
signature.asc
Description: Message signed with OpenPGP using GPGMail
__
ffdw9jmntwkdsd.onion # first label
> exceeds 63 characters, hypothetical illustration only
Existing Onion-Address Syntax (facebookcorewwwi.onion) is completely within
existing DNS’s apparent semantics as well as syntax.
Of course, this is orthogonal to the matt
the syntax to do so.
Exactly. I believe that they do.
> I believe that it would be valuable to check the proposed syntax against the
> individual schemes' scheme-specific-parts as part of the deliberations.
Where else would you suggest looking, please?
-a
—
Alec Muffett
Se
a
*aside: using VLC to RTSP to an Onion address will work just fine when SOCKS
(etc) is configured… etc...
—
Alec Muffett
Security Infrastructure
Facebook Engineering
London
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ask what benefit
would be served by doing so, please?
Thanks,
- alec
—
Alec Muffett
Security Infrastructure
Facebook Engineering
London
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
h
cial offering. The git software is
open-source and widely instantiated. :-)
I hope this helps, and I shall be listening with interest to the call later
today. Thanks!
- alec
—
Alec Muffett
Security Infrastructure
Facebook Engineering
London
signature.asc
Description: Message signed wit
supports neither "Host" header nor SNI; but a web browser using HTTP/S will
>> pass a Host header, and thus we may effect virtual hosting over a single
>> ".onion" names.
The really short summary of this is: Onion names are layer-3 analogues, but
they look like domain nam
Come on, GitHub is a corporation, it has NOTHING to do with it. Git is
a version control system. An RFC falls to me exactly in the definition
of "the most current version of foo". When something needs to be
amended, it is: that's what erratas and RFC updates and obsolescence are
for. Please lea
ce to a stable
> specification. The fact that there's any reference at all is a courtesy.
Per my previous e-mail, I would be happy to pluck out specifications,
especially if they are blocking progress, because I see their inclusion as
irrelevant to the matter of registering the special us
> On Sep 9, 2015, at 10:33, hellekin wrote:
> Signed PGP part
> What would a DNS record about .onion in the root zone be used for?
I am advised by people I trust that "root zone database" > "root zone" and that
this "means the DB that IANA uses to keep track of the root zone."
i.e.: the kind
> On Sep 18, 2015, at 14:16, George Michaelson wrote:
>
> My private comment bears repeating in public.
>
> DOMAIN names is about the property of domains. Domains are encompassing,
> set-theory/venn-diagram style. A domain and a prefix are analogous concepts.
> One is expressed syntactically
>> So it's IMO fine to say ".onion addresses are case-insensitive and
>> will comply with existing DNS limitations for label lengths (63) and
>> maximum fqdn lengths (253ish)".
>> Which contradicts draft-lewis-domain-names-00
>
>
> So - and not to be pointed - but in your email I reference, shoul
Hiya!
> On Dec 5, 2015, at 03:44, John Levine wrote:
>
> With onion you get a rather different thing that looks like an open
> TCP connection, a couple of levels up the protocol stack. So if the
> theory is that these special names are doing a protocol switch, it's
> not one switch, it's potent
> On Dec 10, 2015, at 03:08, George Michaelson wrote:
> The 7 Layer model is a useful tool to talk about things, its not a rei-fied
> thing. That said, apparent layer violations invite critique because they
> inherently carry architectural consequence.
Very true. :-)
> I think the overloading
Hi!
I’m Alec Muffett, I am the other author of this document.
I am a software engineer working at Facebook, and am the lead on the
Facebook over Tor project - https://facebookcorewwwi.onion/
I’ll do my best to answer as many of the extant questions as possible, so
far:
On 3/17/15, 1:14 AM
means my future posts will be automatically approved. I guess that
I’m about to find out.
- alec
--
Alec Muffett
Security Infrastructure
Facebook Engineering
London
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Rubens, allow me please to direct your attention to:
https://cabforum.org/2015/02/18/ballot-144-validation-rules-dot-onion-names
/
Aside: EV certificates are what will be issued for Onion addresses, even
wildcard onion address certificates, for reasons explained on the Ballot.
- alec
On
Hi Rubens!
On 3/17/15, 6:34 PM, "Rubens Kuhl" wrote:
>>
>And where in this ballot is there a need for explicit reserving of
>.onion, since CAs already know they shouldn't try using DNS in the
>process of verifying a .onion certificate ?
If I correctly understand the direction of your question,
“concrete” rather than “alleged”
time sensitivity.
- alec
From: Rubens Kuhl mailto:rube...@nic.br>>
Date: Tuesday, March 17, 2015 at 7:15 PM
To: Alec Muffett mailto:al...@fb.com>>
Cc: dnsop mailto:dnsop@ietf.org>>
Subject: Re: [DNSOP] discussion for draft-appelbaum-dnsop-onion-
Hi Ruben,
Perhaps you have some greater point in mind regarding this observation, could I
ask you please to expand on it, so that I understand better what aspect is
interesting you?
- alec
From: Rubens Kuhl mailto:rube...@nic.br>>
Date: Tuesday, March 17, 2015 at 7:44 PM
To: Alec M
Hi Andrew,
If I understand your question correctly, you are asking whether in the
instance that a DNS server receives and caches a NXDOMAIN for some/all
.onion, whether that could impact software which uses Tor?
Software which uses Tor does so via a proxy which internally performs the
resolution
Hi Hellekin!
I would agree that leak avoidance is “a major” rather than “the prime”
point of having .onion reserved as a TLD.
There are many good reasons for reserving “.onion” as a TLD, including but
not limited to:
- avoiding leaks (above)
- not wasting resource on trying to resolve the “.oni
>Alec, would you care to explain
>the differences on the IANA
>considerations between this
>draft and the P2PNames draft
Woo! I'm honoured, but I am a considerably less IANA-informed schmuck than you
take me for. :-)
I've been heads-down in Tor and the wider Tor community for some time now, a
s; this will doubly-kill all the Onion certificates, however the
Ballot-144-compliant “EV” Onion certificates have until…
== 1 November 2015 ==
…which is the CA/B Forum “deadline” for IETF to approve “.onion” as a TLD; if
“.onion” is not approved by this time then the certs will be “turned off” /
on”, I would be most grateful.
I hope to see all of the DNSOP processes - both established and ad-hoc -
interlock in a graceful and well-oiled manner.
Many thanks and best wishes,
- alec
—
Alec Muffett
Security Infrastructure
Facebook Engineering
London
signature.asc
Description: Message signe
Hi Warren!
> "instead of using the DNS infrastructure, .onion names functionally
> correspond to the identity of a given service, thereby combining
> location and authentication."
> to be very confusing.
> After a while I went and looked at the diff and saw that this used to be:
> ".onion names a
Hi Hellekin!
>Since Alec Muffett seems to have better things to do
I'm sorry if you've been waiting for my input - I am not the primary
author of the document; Jacob Appelbaum's name is in the document's
title for a good reason, and my involvement has been one of
1. the users considerations pretend that users must use onion-aware
software in order to access Onionspace, but I assert that you and I can
use an ordinary Web browser, type in a .onion address, and access the
requested service. Not only OnionTLD conflicts with P2PNames on that
point, it also con
> On May 12, 2015, at 7:44 AM, hellekin wrote:
>
> *** So in my understanding of the scope boundaries of RFC6761 IANA
> considerations, which seems to be the main difference between our drafts
> and our respective positions, the former is "an application", while the
> latter bundles "an applicati
> On May 21, 2015, at 4:41 AM, John Levine wrote:
>
> I share the concerns about calling .onion a TLD, but I think that's
> easily fixable by calling it something like a special purpose
> namespace, then going through the document and changing it where
> appropriate.
Not to complicate matters,
31 matches
Mail list logo
